핵심 요약

  • 대담에 참여한 창업자는 과거 혼자 약 6개월이 걸렸을 것으로 보는 데이터 처리 기능을 AI와 약 10일 만에 구현했다고 설명했다. 다만 복잡한 설계와 최종 검토는 사람이 맡았다.
  • 코드를 생성하는 능력과 실제 서비스의 성능·정확성·가용성을 판단하는 능력은 다르다. 운영 판단에는 실제 작업 부하와 실험 결과가 필요하다.
  • 창업자가 제안한 접근은 별도 시스템이 로그의 변화를 감지하고, AI가 그 신호를 바탕으로 가설을 세워 조사하는 방식이다. 분산 시스템을 전적으로 맡길 단계에 이르렀다는 주장은 아니다.
  • 운영 자동화의 기술적 가능성과 고객의 구매 의사는 별개다. 창업자가 만난 고객들은 AI를 통한 신뢰성 개선보다 당장 확인할 수 있는 비용 절감에 더 관심을 보였다.

개발 속도를 높여도 설계 책임은 남는다

a16z 대담에서 창업자와 진행자가 나눈 논쟁의 중심은 코드 작성과 운영 사이의 간극이었다. AI가 복잡한 소프트웨어를 만드는 데 도움을 주더라도, 그 소프트웨어가 실제 환경에서 어떻게 움직일지까지 이해하는지는 다른 문제라는 것이다.

창업자는 AI를 도입하면서 자신의 작은 팀 안에서 뛰어난 엔지니어와 그렇지 않은 엔지니어의 격차가 커졌다고 관찰했다. 복잡한 문제를 이해하고 작업을 나눌 수 있는 사람이 AI도 더 잘 활용했다는 설명이다. 다만 수백 명을 대상으로 확인한 결과가 아니라, 분산 시스템과 알고리즘을 만드는 소규모 팀의 경험이라는 한계를 밝혔다.

그의 작업 방식에서도 사람의 역할은 뚜렷했다. 구현 에이전트와 기술 검토를 맡는 에이전트가 설계와 코드 변경을 검토하게 하되, 자신도 요구사항과 설계 문서를 읽고 알고리즘, 작업 분담, 변경 사항 사이의 관계를 확인했다. 병렬 작업을 진행한 뒤에는 결과를 다시 모아 사람이 하나씩 살펴봤다. 동시에 다루는 세션도 보통 서너 개였다. 그 이상이면 자신의 맥락 파악이 어려워졌기 때문이다.

구체적인 사례는 데이터를 모아 저장하는 데이터 레이크의 자동 승격 기능이었다. 반정형 로그의 각 필드를 독립적으로 필터링할 수 있는 열로 바꾸는 작업으로, 메타데이터 갱신과 여러 쓰기 주체 사이의 조율이 필요했다. 그는 이 기능을 혼자 약 10일 만에 구현했으며, 이전이었다면 약 6개월이 걸렸을 것으로 추정했다. 이는 특정 프로젝트에 대한 경험과 비교 추정이지, 모든 개발 작업에 적용되는 생산성 수치는 아니다.

코드가 맞아도 운영 결과는 달라진다

진행자는 AI가 코드를 생성하는 능력과 실행 중인 시스템을 이해하는 능력을 구분했다. 분산 시스템의 가용성이나 정확성, 성능은 코드뿐 아니라 실제 접근 패턴과 트래픽, 잠금이나 캐시를 사용하는 방식에도 영향을 받는다. 작업 부하를 모르면 설계상의 절충이 적절한지 판단하기 어렵다는 지적이다.

창업자의 쿼리 최적화 경험은 가능성과 한계를 함께 보여준다. 데이터 조회 요청인 쿼리를 실행 코드로 바꾸는 과정에서, AI는 처음에 불필요하게 반복되는 조건을 문제로 인식하지 못했다. 사람이 이를 짚어주자 개선 가설을 세우고 최적화를 진행했다. 이때 기준이 된 것은 명확한 성능 측정 기준과 실제 사용자 쿼리 데이터였다.

반면 시스템에 메모리를 얼마나 배정해야 하는지에 대해서는 AI가 답을 알지 못했다고 설명했다. 그 정보는 실제 운영 환경에서 실험해 얻어야 했다. 그가 긍정적으로 본 변화는 AI가 모든 답을 미리 아는 것이 아니라, 모르는 문제에 대해 실험으로 정보를 얻으려 한다는 점이었다.

로그 전체를 읽히기보다 변화를 찾아 전달한다

창업자가 운영 문제에 접근한 출발점은 관측 비용이었다. 관측 가능성은 로그와 지표 등으로 시스템 내부 상태를 파악하는 능력을 뜻한다. 그는 2023년 엔지니어링 리더들과 대화하면서, 이들이 인프라 지출의 5~20%에 해당하는 돈을 관측 도구에 쓰고 있다고 들었다.

그의 해석으로 고객이 궁극적으로 구매하려던 것은 데이터 자체가 아니라 서비스의 신뢰성이었다. 그러나 마이크로서비스 구조가 확산되면서 수집 데이터와 비용이 늘어나는 속도에 비해, 추가 지출로 얻는 신뢰성 개선은 둔화했다. 그는 데이터가 흘러가는 상류에서 필요한 신호를 추출하면 저장·분석 비용을 줄이는 동시에, 그 신호를 운영 자동화에 활용할 수 있다고 봤다.

이 접근은 장애 경보가 울린 뒤 복잡한 시스템을 거슬러 올라가 원인을 찾는 방식과 출발점이 다르다. 먼저 환경에서 이전과 다른 패턴을 찾는다. 연결 고갈이나 메모리 초과처럼 문제의 조짐일 수 있는 메시지를 포착한 뒤, 조사할 가치가 있는지 판단하는 것이다.

여기서 변화 감지와 생성형 AI의 추론은 별개 역할이다. 별도 감지 모델이 로그에서 새로운 패턴을 찾아 AI에 전달한다. AI는 메시지가 발생한 코드를 확인하고, 과거 발생 여부를 살피며, 가능한 원인에 대한 가설을 검토한다. 로그를 통째로 건네고 이상 여부를 알아서 판단하라고 요청하는 방식이 아니다.

창업자는 이를 내부 시스템과 일부 고객 환경에서 시험했으며, 경고를 무시한 몇몇 사례가 실제 운영 장애로 이어졌다고 말했다. 다만 대담에서 광범위한 정확도나 장애 예방률을 입증하는 수치는 제시하지 않았다.

모든 장애를 외우는 대신 조사 절차를 수행한다

진행자의 핵심 의문은 운영 중 발생할 수 있는 상태가 지나치게 많다는 것이었다. 드물게 일어나는 오류의 종류도 많고, 외부 부하나 예고되지 않은 배포, 여러 사건의 조합으로 생기는 교착 상태까지 고려해야 한다. 필요한 지식이 여러 사람에게 흩어져 있다는 점도 문제다.

그는 시스템 분야에서 영리한 예측 알고리즘 대신 자원을 넉넉하게 배정하는 선택을 반복해 왔다고 주장했다. 운영 자동화가 코드 생성보다 훨씬 어려울 수 있다는 근거였다. 보안에서는 공격자가 의도적으로 취약한 상태를 찾기 때문에 문제가 더 까다로워질 수 있다고도 봤다.

창업자의 반론은 모든 장애 상태를 모델이 미리 학습해야 하는 것은 아니라는 것이었다. 사람도 운영 절차서를 따르고, 신호를 확인하고, 가설을 세워 조사한다. 가능한 오류의 수는 매우 많더라도 원인을 좁혀 가는 절차는 AI가 수행할 수 있는 범위로 만들 수 있다는 주장이다.

그는 충분한 운영 데이터를 수집하고 변화가 드러나게 만들 수 있다는 전제를 뒀다. 그러나 사람끼리 나눈 대화에만 남아 있는 배포 정보처럼 시스템에 드러나지 않은 상태도 존재한다는 점을 인정했다. 쿼리 최적화의 자동화에는 상당히 가까워졌다고 평가했지만, 분산 클러스터 운영을 AI에 맡길 수 있느냐는 질문에는 아직 아니라고 답했다.

기술적 가능성과 경제성은 다른 기준이다

두 사람의 전망은 끝내 완전히 일치하지 않았다. 창업자는 코드 작성에서 다루는 복잡성이 확장됐듯 운영에서도 점진적인 진전이 가능하다고 봤다. 진행자는 학습 데이터가 표현하는 세계와 실제 실행 환경 사이에는 간극이 있으며, 어떤 문제는 직접 실행하거나 실험해야만 답을 얻을 수 있다고 지적했다.

이에 창업자는 AI가 즉시 답을 내놓는 대신, 필요한 정보를 얻을 실험을 계획하고 수행할 수 있다고 반박했다. 진행자도 그 가능성을 인정했지만, 운영 문제가 얼마나 해결될지는 아직 답이 나오지 않았다는 입장을 유지했다.

환경 자체를 자동화에 맞게 바꾸는 방안도 논의됐다. 창업자는 창고 자동화를 예로 들며, 기존 환경에 도구를 끼워 맞추기보다 전체 환경을 자동화에 맞춰 재구성하는 선택을 언급했다. 진행자는 시스템과 환경의 범위를 제한하면 필요한 계산과 비용에 영향을 줄 수 있다고 봤다. 이 관점에서 관건은 해결 가능성뿐 아니라 고객이 지불할 만한 비용으로 해결할 수 있느냐는 것이다.

고객은 신뢰성의 약속보다 비용 절감에 반응했다

창업자가 전한 영업 경험은 구매 기준을 보여준다. 그는 고객에게 데이터 최적화와 비용 절감, 장애로 이어지기 전 문제를 찾아 해결하는 AI 기능을 함께 설명했다. 그러나 고객은 관측 도구 비용을 90% 줄일 수 있다는 설명에 대화를 되돌렸다. 당장 사고 싶은 것은 그 비용 절감이라는 반응이었다.

90%는 창업자가 제시한 절감 효과다. 대담에서는 모든 고객에게 적용되는 검증 결과가 제시되지는 않았다. 그럼에도 이 일화는 AI 운영 기능의 가치를 설명하는 일과, 고객이 즉시 가격을 매길 수 있는 효과 사이의 차이를 보여준다.

진행자는 코드 생성의 경우 큰 비용 항목인 엔지니어링 생산성과 직접 연결되므로 구매 이유가 비교적 명확하다고 봤다. 반면 장애를 예방하거나 운영 신뢰성을 높이는 효과는 고객이 금액으로 환산하기 더 어렵다는 것이 두 사람의 관찰이었다.

대담에서 확인된 운영 AI의 가능성은 변화를 감지하고, 가설과 실험으로 원인을 좁히는 데 있었다. 시스템 전체를 자율 운영하는 수준은 아직 도달하지 못했다는 평가였으며, 그 사이의 진전을 고객이 구매할 수 있는 가치로 바꾸는 과제도 남아 있었다.