AI는 코드를 배웠지만, 소프트웨어는 운영에서 배운다

AI는 인류가 오랫동안 쌓아온 엄청나게 많은 지식을 흡수하고 있습니다.

논문, 문서, 코드, 튜토리얼, 질의응답, 설계 논의, 장애 회고, 책, 블로그, API 참조, 커밋 이력 같은 자료가 AI의 학습 재료가 됩니다. 그 안에는 기초적인 문법과 패턴도 있고, 첨단의 깊이 있는 지식도 있습니다. 이제 AI는 사람이 평생 읽기 어려운 양의 자료를 바탕으로 코드를 설명하고, 생성하고, 고치고, 비교합니다.

이 글은 앞서 쓴 AI가 코드를 써도, 소프트웨어는 퇴고가 필요하다의 다음 질문에서 출발합니다. AI가 만든 결과물이 초고라면, 그 초고를 계속 고치게 만드는 피드백은 어디에서 오는가. 이 글의 답은 운영입니다.

특히 코딩에서는 이 변화가 매우 선명합니다.

사람이 특정 언어와 프레임워크의 모든 변경 이력, 수많은 라이브러리의 사용법, 에러 메시지의 패턴, 공개 코드의 관용구를 모두 따라가기는 어렵습니다. 어떤 영역에서는 이미 사람이 AI의 코드 생성 속도와 탐색 폭을 따라가기 어려운 것이 현실입니다.

그런데 여기서 한 가지를 구분해야 합니다.

AI가 많이 배운 것은 주로 “기록된 지식”입니다. 텍스트, 코드, 이미지, 로그, 문서처럼 어떤 매체로 남은 지식입니다. 코딩 모델의 세계에서는 그 지식이 대개 글자와 토큰의 형태로 들어옵니다.

이것은 책으로 춤을 배우는 것과 닮았습니다.

춤의 역사, 동작의 이름, 발의 순서, 무게 중심의 이동, 좋은 무대의 조건을 글로 아주 많이 배울 수 있습니다. 골프도 마찬가지입니다. 스윙 궤적, 손목 각도, 체중 이동, 클럽 페이스의 방향을 책과 이미지로 거의 완벽하게 설명할 수 있습니다.

하지만 책으로 춤을 배운 사람이 곧바로 무대에서 잘 추는 것은 아닙니다. 골프 스윙을 이론으로 완벽하게 이해한 사람이 필드에서 바로 좋은 샷을 치는 것도 아닙니다.

몸이 실제 바닥을 만나고, 균형이 흔들리고, 리듬이 어긋나고, 공의 위치와 바람과 긴장감이 들어오는 순간부터는 다른 종류의 배움이 시작됩니다.

소프트웨어도 그렇습니다.

이 글의 핵심은 AI가 운영을 전혀 모른다는 단정이 아닙니다. AI는 운영 신호를 읽고 가설을 만드는 데 강력한 도구가 될 수 있습니다. 다만 소프트웨어 품질을 바꾸는 가장 중요한 근거는 실행 중인 시스템이 남기는 피드백에서 나온다는 점입니다.

소프트웨어는 코드로만 존재하지 않는다

우리는 종종 소프트웨어를 코드로 생각합니다.

저장소
  -> 소스 코드
  -> 빌드
  -> 산출물

이 흐름은 중요합니다. 하지만 운영 관점에서 소프트웨어는 코드 파일로 존재하지 않습니다. 실제 소프트웨어는 실행되고 있는 인스턴스로 존재합니다.

실행 중인 프로세스
  -> 설정
  -> 데이터
  -> 네트워크
  -> 저장소
  -> 사용자 행동
  -> 의존성 상태
  -> 알림과 장애

같은 코드라도 어떤 설정으로 실행되는지, 어떤 데이터와 만나는지, 어떤 트래픽 패턴을 받는지, 어떤 외부 시스템에 의존하는지에 따라 완전히 다른 소프트웨어가 됩니다.

로컬에서 잘 동작한 API가 운영에서는 느려질 수 있습니다. 테스트에서는 충분했던 타임아웃 값이 실제 네트워크에서는 너무 짧을 수 있습니다. 데모 데이터에서는 자연스러웠던 화면이 수십만 건의 데이터 앞에서는 불편해질 수 있습니다. 정상 흐름에서는 깔끔했던 로직이 재시도, 중복 요청, 부분 실패, 권한 변경, 스키마 마이그레이션과 만나면 다른 얼굴을 드러냅니다.

이것은 코드만 읽어서는 끝까지 알 수 없습니다.

AI가 코드를 아주 잘 읽고 쓸 수 있어도, 실제로 실행 중인 소프트웨어가 놓이는 모든 상황을 직접 겪는 것은 다른 문제입니다. 운영은 문서로 남기기 전까지는 외부에서 관찰하기 어렵고, 문서로 남겨도 현장의 맥락이 모두 보존되지는 않습니다.

운영은 소프트웨어가 현실과 만나는 곳이다

개발 단계에서는 우리가 문제를 정의합니다.

이 입력을 받으면
이 검증을 하고
이 데이터를 저장하고
이 응답을 돌려준다

운영 단계에서는 현실이 문제를 다시 정의합니다.

사용자는 같은 버튼을 두 번 누른다.
배치 작업과 API 요청이 같은 DB 인덱스에 몰린다.
특정 고객의 데이터만 유난히 크다.
외부 API가 200 OK와 빈 응답 본문을 함께 준다.
디스크는 가득 차지 않았지만 inode가 먼저 바닥난다.
로그는 많지만 장애 원인을 설명하는 필드는 빠져 있다.

이런 상황은 설계 문서에 늘 들어 있지 않습니다. 테스트 케이스에도 빠질 수 있습니다. 코드 리뷰에서 발견되지 않을 수도 있습니다.

하지만 운영에서는 반드시 드러납니다.

그래서 운영은 개발의 부록이 아닙니다. 소프트웨어가 현실과 만나는 본문입니다. 우리가 만든 가정이 맞았는지, 어떤 경로가 자주 쓰이는지, 어떤 실패가 반복되는지, 어떤 기능이 운영자를 힘들게 하는지 알려주는 피드백 시스템입니다.

개발은 길게는 1년이나 2년이면 주요 기능이 만들어질 수 있습니다. 하지만 그 소프트웨어는 5년, 10년, 때로는 그보다 오래 운영됩니다. 실제 품질은 첫 릴리스보다 그 이후의 운영 기간에 더 많이 결정됩니다.

처음 만든 구조가 완벽해서 오래 살아남는 것이 아닙니다. 운영 피드백을 받아 고치고, 관찰 지점을 늘리고, 경계 조건을 발견하고, 데이터 모델을 조정하고, 배포 방식을 다듬기 때문에 살아남습니다.

AI가 어려워하는 것은 경험의 표면 아래에 있다

AI는 공개된 장애 회고를 읽을 수 있습니다. 잘 정리된 장애 사후 분석을 요약할 수 있고, 비슷한 패턴의 원인을 추론할 수도 있습니다. 로그를 붙이면 의심 지점을 빠르게 좁혀줄 수 있습니다.

이것은 큰 도움입니다.

하지만 운영 경험의 많은 부분은 글로 완전히 옮겨지지 않습니다.

• 특정 팀이 왜 이 설정을 무서워하는지
• 이 알림이 왜 밤마다 무시되는지
• 이 기능이 왜 특정 고객에게만 자주 깨지는지
• 이 데이터베이스 마이그레이션이 왜 이번 분기에는 위험한지
• 이 로그가 왜 많지만 쓸모없는지
• 이 장애가 기술 문제가 아니라 권한과 책임 경계의 문제인지

이런 것들은 코드와 문서 사이의 빈칸에 있습니다. 조직의 기억, 운영자의 감각, 사용자의 습관, 데이터의 편향, 인프라의 오래된 타협, 배포 이력 속에 숨어 있습니다.

AI가 이 모든 것을 모른다는 뜻은 아닙니다. 오히려 AI는 이런 빈칸을 찾는 질문을 던지는 데 도움을 줄 수 있습니다. 하지만 그 질문에 답할 수 있는 근거는 운영 중인 시스템 안에 있습니다.

그래서 좋은 AI 지원 개발은 AI가 운영을 대체하게 하는 방식이 아닙니다. 운영에서 나온 신호를 더 잘 읽고, 더 빠르게 가설을 만들고, 더 안전하게 수정안을 검토하는 방식에 가깝습니다.

운영 피드백은 어떻게 소프트웨어를 바꾸는가

운영 피드백은 단순히 “버그를 고친다”로 끝나지 않습니다. 좋은 운영 피드백은 소프트웨어의 구조를 바꿉니다.

예를 들어 이런 변화가 생깁니다.

느린 API가 반복된다
  -> 인덱스를 추가한다
  -> 쿼리 형태를 바꾼다
  -> 페이지네이션 정책을 바꾼다
  -> 화면에서 불필요한 즉시 로딩을 없앤다

장애 원인을 찾기 어렵다
  -> 상관관계 ID를 심는다
  -> 로그 필드를 구조화한다
  -> 메트릭 레이블을 조정한다
  -> 런북을 만든다

특정 작업이 운영자를 긴장시킨다
  -> 모의 실행을 추가한다
  -> 권한과 승인 단계를 나눈다
  -> 롤백 경로를 만든다
  -> 위험한 기본값을 제거한다

이 변화들은 코드 변경입니다. 하지만 출발점은 코드가 아니라 운영입니다.

운영 피드백은 소프트웨어에게 이렇게 묻습니다.

너는 실제 데이터 앞에서도 버티는가?
실패했을 때 사람이 이해할 수 있는가?
반복되는 작업이 안전한가?
문제가 생겼을 때 원인을 좁힐 수 있는가?
오래 운영될수록 더 다루기 쉬워지는가?

이 질문에 답하면서 소프트웨어는 좋아집니다.

AI 시대의 개발자는 무엇을 더 봐야 하나

AI가 코드를 잘 쓸수록 개발자의 역할은 코드 입력량에서 멀어집니다.

중요해지는 것은 이런 일입니다.

• 실제 운영 신호를 읽는 것
• 사용자 행동과 시스템 동작을 연결하는 것
• 로그와 메트릭을 코드 변경으로 되돌리는 것
• 실패를 재현 가능한 테스트로 바꾸는 것
• 운영자가 반복해서 겪는 불편을 제품 구조로 해결하는 것
• “잘 돌아간다”와 “오래 운영할 수 있다”를 구분하는 것

AI는 이 과정의 동료가 될 수 있습니다. 로그를 요약하고, 의심 지점을 나열하고, 테스트 후보를 만들고, 리팩터링 경로를 제안하고, 릴리스 노트를 정리할 수 있습니다.

하지만 운영 중인 소프트웨어가 어떤 신호를 내고 있는지, 그 신호가 정말 중요한지, 어떤 수정이 조직과 사용자에게 안전한지는 사람이 판단해야 합니다.

이런 관점은 Konduo에서도 중요하게 다룹니다. Konduo는 여러 IT 인프라의 상태 확인, 메트릭·로그 근거, 알림 대응, 권한과 운영 이력을 하나의 화면 흐름으로 연결하는 통합 관리 운영 플랫폼입니다. 소프트웨어를 코드가 아니라 운영 중인 시스템으로 바라보려면, 상태와 근거와 대응 흐름이 함께 보여야 합니다.

소프트웨어는 운영에서 다시 배운다

AI는 코드를 배웠습니다. 그것도 아주 빠르게, 아주 넓게 배웠습니다.

그러나 소프트웨어는 코드로만 존재하지 않습니다. 소프트웨어는 실행되고, 실패하고, 느려지고, 복구되고, 사용자와 운영자를 만나며 계속 바뀝니다.

책으로 춤을 배운 사람에게 무대가 필요하듯, 책으로 스윙을 배운 사람에게 필드가 필요하듯, 코드로 만들어진 소프트웨어에는 운영이 필요합니다.

운영은 개발이 끝난 뒤의 관리 업무가 아닙니다. 운영은 소프트웨어가 현실에서 다시 배우는 과정입니다.

이전 글에서 말한 퇴고가 첫 결과물을 다듬는 일이라면, 운영 피드백은 그 퇴고를 가장 오래 지속시키는 재료입니다.

AI 시대에도 이 사실은 더 중요해질 가능성이 큽니다. 코드는 더 빨리 만들어질 수 있습니다. 하지만 오래 운영되는 좋은 소프트웨어는 여전히 운영 피드백을 통해 만들어집니다.

함께 읽기 좋은 글

• AI가 코드를 써도, 소프트웨어는 퇴고가 필요하다 - AI가 만든 결과물을 초고로 보고 계속 고쳐야 하는 이유를 다룹니다.
• JVM 메트릭만으로는 컨테이너를 설명할 수 없다 - 코드 안의 지표만으로는 운영 중인 시스템을 설명하기 어렵다는 관점을 이어갑니다.
• Kafka Broker가 느려졌지만 Kafka가 원인은 아니었다 - 실제 운영 신호가 코드 바깥의 원인으로 이어지는 사례입니다.