Why AI Can Write Code But Can''t Keep It Running (Yet)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Why AI Can Write Code But Can’t Keep It Running (Yet)를 중심으로, 코드 생성과 운영 판단에는 서로 다른 정보가 필요하다. 분산 시스템의 성능·가용성·정확성은 데이터, 설정, 접근 패턴과 트를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 코드 생성과 운영 판단에는 서로 다른 정보가 필요하다. 분산 시스템의 성능·가용성·정확성은 데이터, 설정, 접근 패턴과 트래픽에 좌우된다. 코드를 이해하는 것만으로 적절한 메모리 할당이나 일관성·가용성의 절충까지 결정하기는 어렵다.
2. 개발 속도가 빨라질수록 인간의 설계와 검증이 중요해진다. 데이터 레이크 자동 컬럼화 기능을 약 10일 만에 구현했다는 사례가 제시된다. 다만 과거라면 약 6개월이 걸렸을 것이라는 비교는 추정이며, 요구사항 정의·작업 분해·테스트·변경 통합에는 인간의 판단이 계속 필요했다.
3. 관측 데이터를 많이 모으는 것과 신뢰성을 높이는 것은 다르다. 대화에서는 기업들이 인프라 지출의 약 5~20%를 관측 가능성에 쓰지만, 추가 지출의 신뢰성 개선 효과는 둔화됐다고 설명한다. 수집 단계에서 신호와 잡음을 구분하면 저장·전송 비용을 줄이고 AI 조사에 필요한 입력을 만들 수 있다.
4. 운영 AI의 현실적인 역할은 신호를 받아 조사 절차를 수행하는 것이다. 별도의 탐지 모델이 새로운 패턴을 찾고, AI가 관련 코드와 과거 발생 여부를 조사하며 가설을 검증하는 구조다. 실제 쿼리와 벤치마크, 명확한 구현 제약, 실행 실험이 추론의 근거가 된다.
5. 기술적 가능성과 구매를 이끄는 가치는 구분해야 한다. 쿼리 최적화의 자동화는 가깝다는 전망이지만, 분산 클러스터 운영 전체를 맡기는 단계에는 이르지 못했다는 평가다. 고객 대화에서는 장애 예방보다 데이터독 요금 90% 절감처럼 분명한 비용 효과에 구매 의사가 집중된 사례가 소개된다.

🧩 배경과 문제 정의

• AI 코딩은 자동완성을 넘어 복잡한 소프트웨어 구현으로 확장됐지만, 코드를 생성하는 능력과 실제 운영 환경에서 시스템의 동작을 예측·관리하는 능력 사이에는 간극이 있다.
• 분산 시스템의 성능·가용성·정확성은 코드뿐 아니라 데이터, 설정, 접근 패턴과 트래픽에도 좌우된다. 운영에 필요한 정보를 AI가 어떻게 이해하고 추론하게 할지가 핵심 문제다.
• 기업이 관측 가능성 도구에 투자하는 목적은 서비스 신뢰성 확보지만, 수집 데이터와 비용이 늘어나는 만큼 신뢰성이 개선되지는 않는 상황이 출발점이다.
• 개발 생산성 향상과 운영 자동화의 가능성은 소규모 팀의 경험과 구체적인 사례를 바탕으로 논의된다. 인간의 설계 판단, 벤치마크, 실제 환경의 실험이 여전히 중요한 조건으로 남는다.

🕒 시간순 섹션별 상세정리

1. 보안 복구가 드러낸 운영 상태의 경계 문제

• 게스트는 스탠퍼드에서 OpenFlow와 하드웨어 보안을 연구한 뒤, MIT에서 애플리케이션 보안 연구와 창업으로 경험을 넓혔다 [04:22]
• 당시 복구 기술은 공격받은 애플리케이션과 관련된 전체 상태를 되돌리고, 패치된 버전에 그 상태를 다시 적용해 공격의 영향을 제거하려는 접근이었다 [04:46]

2. 조직 확장 경험에서 비용과 신뢰성 문제로 이동

• AppDynamics에서 약 3년 반 동안 회사가 약 200명에서 2,000명으로 커지는 과정을 경험했다. 이후 VC를 거쳐 최고제품책임자로 일하며 제품·엔지니어링·정보보안·디자인 조직을 약 15명에서 90명 이상으로 확장했다 [06:47]
• 2023년 엔지니어링 리더들과 나눈 대화에서는 지출 축소가 공통 과제였다. 주요 비용 항목으로 인프라와 관측 가능성이 거론되면서, 관측 가능성 비용을 비싸게 느끼는 이유를 탐색하기 시작했다 [07:25]

3. 관측 가능성 지출의 신뢰성 개선 효과가 둔화

• 기업들은 인프라 지출의 약 5~20%를 관측 가능성에 쓰고 있었지만, 실제로 구매하려던 가치는 인프라와 애플리케이션의 신뢰성이었다 [07:48]
• 마이크로서비스 중심의 구조와 계층별 데이터 수집이 확대되면서, 관측 데이터와 비용이 제공 기능의 증가보다 빠르게 늘었다. 추가 지출이 가져오는 신뢰성 개선 효과는 점차 평평해졌다 [08:30]

4. 수집 단계의 신호 추출을 비용 절감과 AI 운영에 연결

• 관측 데이터에서 신호와 잡음을 상류 단계에서 구분하면, 대부분 보험처럼 보관하던 데이터를 하류로 보내는 비용을 크게 줄일 수 있다는 구상이 나왔다 [09:15]
• 실시간으로 추출한 신호는 비용 절감뿐 아니라 다른 시스템에 공급해 신뢰성 운영을 구동하는 입력으로도 활용할 수 있다 [09:28]

5. AI 활용 능력은 모델과 도구에 적응하면서 형성

• 초기에는 Copilot이 테스트를 자동완성하는 수준이었지만, 뛰어난 엔지니어들은 AI를 작업에 통합하면서 질문 방식과 결과를 끌어내는 방법을 학습했다 [11:44]
• 모델마다 차이가 있고, 실행 도구마다 컨텍스트 관리와 하위 에이전트 사용 방식도 다르다. 효율적인 활용에는 모델과 도구가 함께 작동하는 방식을 이해하는 과정이 필요하다 [12:35]

6. 복잡성을 이해하는 엔지니어의 생산성 격차 확대

• 팀의 채용 경험에서는 보통 엔지니어와 뛰어난 엔지니어 사이의 격차가 약 10배로 커졌다고 평가한다. AI가 부족한 역량을 자동으로 채우기보다 기존에 뛰어난 엔지니어를 더 강하게 만드는 양상이었다 [13:41]
• 이 판단은 소규모 팀과 분산 시스템·분산 알고리즘 개발 경험에 한정된다. 복잡한 구조를 이해하고 작업을 분해하는 능력은 여전히 인간에게 필요하다고 본다 [14:26]

7. 코드의 표현과 실제 시스템 동작 사이의 차이

• 구문은 입력한 문자와 코드의 형태이고, 의미는 그 코드가 뜻하는 바와 기계가 실제로 수행하는 동작을 가리킨다. 서로 다른 표현이 같은 의미를 가질 수도 있다 [15:59]
• 코드만으로 실행 결과의 모든 특성을 알 수는 없다. SQL의 실행 시간은 스키마와 데이터에 좌우되지만, 이를 의미 자체로 볼지 성능 특성으로 구분할지를 두고 견해 차이가 있었다 [17:13]

8. 개발 환경보다 중요해진 대량 변경의 검증

• 개인 개발 환경은 Windows의 WSL에서 Linux 명령줄을 사용하고 Claude Code를 실행하는 구성이다 [19:54]
• 최근에는 자막에서 ‘Opus 5.5’로 언급한 모델을 사용해 여러 PR로 구성된 큰 변경을 만들었다. 팀원들도 비슷하게 많은 PR을 작성하며 서로 검토하는 상황이다 [20:36]

9. 지속 세션을 가진 에이전트와 인간의 컨텍스트 한계

• 기본 하위 에이전트 대신 명령줄에서 별도 에이전트를 실행하면 세션을 지속할 수 있다. 다른 세션에서도 다시 접근할 수 있어 컨텍스트를 더 효율적으로 활용할 수 있다고 본다 [21:17]
• 동시에 다루는 세션 창은 보통 서너 개다. 그 이상이면 인간이 작업별 맥락을 놓치고, 먼저 끝난 에이전트가 다음 지시를 기다리게 된다 [21:38]

10. 설계 검토와 변경 통합은 인간이 통제

• 구현 에이전트에 기술 리드 역할의 검토자를 붙여 설계의 타당성과 PR을 반복 검토하게 한다. 요구사항과 설계 문서도 이 과정에 포함한다 [22:12]
• 인간은 요구사항·설계 문서, 알고리즘, 작업 분담, PR 간 관계를 세부적으로 확인한 뒤 구현을 시작시킨다. 병렬화 가능한 작업은 추가 에이전트에 나누도록 한다 [22:39]

11. 데이터 레이크 자동 컬럼화의 개발 기간 단축

• 실제 제품 코드의 사례는 데이터 레이크의 자동 승격, 즉 반정형 로그의 각 필드를 독립적으로 필터링할 수 있는 컬럼으로 만드는 기능이다. 이를 자동 승격 또는 슈레딩이라고 부른다 [24:02]
• 구현에는 메타데이터 시스템과 커밋 방식의 이해, 여러 작성자 사이의 조정이 필요하다. 게스트는 이 작업을 혼자 약 10일에 완료했다고 보여준다 [24:34]

12. 운영의 설계 선택은 워크로드 정보에 의존

• 분산 시스템의 성능·가용성·정확성은 코드 형태뿐 아니라 워크로드, 접근 패턴과 트래픽에 좌우된다 [25:42]
• 잠금은 일시적으로 가용성을 제한할 수 있고, 최종 일관성을 택하면 읽기 시점에 최신 상태가 반영되지 않을 수 있다. 캐시 사용 역시 성능과 설계 선택에 영향을 준다 [26:04]

13. 운영 추론의 출발점은 명확한 제약과 벤치마크

• 핵심 과제는 프로덕션에서 일어나는 현상을 AI가 추론할 수 있는 형태로 바꾸는 것이다. 진행자의 분산 가우시안 스플랫 렌더러 경험에서는 수백만 개 요소의 반입·반출과 스트리밍이 실행 환경에 의존해 모델들이 좋은 결과를 내지 못했다 [27:56]
• 게스트의 팀은 성능 벤치마크, 기대하는 실행 방식, 스트림 처리기 안에서 지켜야 할 구현 제약을 명확히 정의해 AI 작업의 기준으로 사용한다 [28:16]

14. 쿼리 최적화는 구체적인 지적과 측정 근거가 필요

• SQL에 대응하는 코드를 파이프라인에서 실행하는 작업에서, 모델은 처음에 최적화가 빠져 있어도 코드가 괜찮다고 판단했다 [28:49]
• 인간이 논리곱 조건 안에 반복된 항이 남아 있다고 지적하자, 모델은 개선 가능한 항목들에 대한 가설을 만들며 최적화를 탐색했다 [29:11]

15. 메모리 산정은 실제 실험이 필요한 영역

• 시스템에 메모리를 얼마나 할당해야 하는지는 모델이 알지 못했고, 답을 얻으려면 프로덕션에서 실제 실험을 해야 한다고 본다 [29:46]
• 현재 운영 작업에서 긍정적으로 보는 능력은 답하기 어려운 질문임을 인식하고 실험을 시도하려는 태도다. 다만 이 구간에서는 그 실험의 구체적인 방법이나 결과까지 제시되지는 않는다 [29:59]

16. 장애 이후의 원인 역추적에서 환경 변화 탐지로 전환

• 지표 급등이나 경보 같은 후행 신호에서 복잡한 시스템의 근본 원인을 역추적하기는 어렵다. 대안은 대규모 군집화 등을 이용해 환경에서 새롭게 달라진 패턴을 먼저 찾는 것이다 [31:21]
• 정상적인 트래픽 변화도 탐지 대상이 될 수 있다. 연결 고갈, 메모리 초과, 자원 버퍼 소진 같은 초기 메시지를 포착한 뒤 실제 조사와 대응이 필요한 문제인지 판단한다 [32:08]

17. 폭증하는 운영 상태와 관측되지 않는 지식의 한계

• 프로그램에 비트가 추가될 때 가능한 상태가 두 배로 늘어난다는 비유처럼, 운영 상태 공간은 빠르게 거대해진다. 이 때문에 충분한 구성과 장애 사례를 학습시켜 분산 클러스터 운영을 맡길 수 있는지 의문이 남는다 [33:47]
• 사람도 런북을 따라 대응하므로 AI가 운영 대응의 일부를 시작할 여지는 있다. 그러나 동료에게 비공식적으로 들은 배포 정보처럼 시스템 상태에 드러나지 않는 지식은 인간 개입을 요구할 수 있다 [34:29]

18. 변화 탐지 모델과 생성형 AI의 역할 분리

• 생성형 AI가 직접 이상을 예측하는 구조가 아니다. 별도의 탐지 모델이 변화 신호를 만들고, 대규모 로그에서 이전에 없던 패턴이 나타나면 AI에 전달한다 [35:58]
• AI는 해당 메시지가 발생한 코드, 코드의 동작, 과거 발생 여부를 조사한다. 여러 가설과 휴리스틱을 검토해 신호의 의미와 필요한 대응을 판단한다 [36:34]

19. 쿼리 최적화와 클러스터 전체 운영 사이의 거리

• 사람이 하던 쿼리 최적화를 AI가 맡는 시점은 매우 가깝다는 전망이다. 반면 회사의 서비스 가동을 책임지는 분산 클러스터 운영 전체를 맡길 수준에는 아직 이르지 못했다 [37:07]
• 코딩 AI가 자동완성에서 출발해 복잡한 소프트웨어 작성으로 확장된 경험은 낙관론의 근거다. 다만 그 발전 경로가 운영에도 그대로 적용될지는 확인되지 않았다 [37:36]

20. 드문 예외와 자원 과잉 확보가 뒷받침하는 운영 회의론

• 코드의 학습 분포는 비교적 다룰 만해도, 운영은 드문 예외와 긴 꼬리 분포가 지배하는 영역일 수 있다. 이런 특성은 모델이 학습하기 어려운 문제로 남는다 [38:08]
• 메모리 관리나 적응형 라우팅에서는 정교한 예측보다 RAM과 네트워크 용량을 넉넉히 확보하는 방식이 반복적으로 선택됐다는 지적이다. 예측 실패와 진동을 피하려는 운영상의 선택이다 [38:48]

21. 모든 장애를 학습하는 대신 디버깅 절차를 실행

• 낙관적인 접근은 새로운 예외나 워크로드 변화가 관측 데이터에 잡힌다는 전제에 선다. AI는 로그를 한꺼번에 읽고 답을 내는 대신 실험을 수행하며 실제 환경에 맞는 인과관계를 조사해야 한다 [40:24]
• 가능한 장애 상태가 방대하더라도, 원인을 좁히는 디버깅 절차는 상대적으로 다룰 만할 수 있다. 적절한 신호를 받은 AI가 사람이 하던 조사 단계를 실행하는 것이 핵심이다 [41:15]

22. 보안 조사로의 확장과 의도적인 공격자의 난점

• 보안에서도 행동 통계나 개체 구성의 변화가 조사 신호가 된다. AI는 가능한 인과관계 후보를 만들고 실제 데이터 패턴과 부합하는지 검증한다 [42:15]
• 보안에는 드문 오류 상태뿐 아니라 모델이 다루기 어려운 상태를 의도적으로 찾는 공격자가 존재한다. 따라서 코드 생성, 운영, 보안 순으로 해결에 더 긴 시간이 필요할 수 있다는 전망이다 [43:00]

23. 유한한 상태 공간도 실무에서는 사실상 무한할 수 있다

• 시스템의 상태와 가능한 경로가 이산적이라는 관점이 있지만, 유한하다는 사실만으로 탐색이 쉬워지지는 않는다. 일정 크기의 MP3 파일도 가능한 비트 조합이 엄청나게 많다는 비유가 이 차이를 보여준다 [44:56]
• 운영 자동화 기업들이 코드 생성 기업보다 어려움을 겪는다는 투자 현장의 관찰은, 운영 문제가 더 어렵다는 판단의 근거가 된다 [45:20]

24. 코드에서 시작한 자동화가 더 큰 복잡성으로 확장될 가능성

• 코드에서 AI가 작동한다면 복잡성을 조금씩 높이고 계층을 추가해, 여러 사람이 관여하는 문제까지 확장할 수 있다는 낙관적인 전망이 있다 [46:41]
• 반대편에서는 코딩의 성공이 더 넓은 현실 문제의 해결을 보장하지 않으며, 그런 확장이 가능한지는 아직 답이 나오지 않았다고 본다 [46:56]

25. 현실의 압축된 표현과 실험을 통한 정보 획득

• 언어는 고차원 현실을 모델이 다루기 쉬운 표현으로 줄인 결과이며, 코드도 기계의 운영 상태를 실행 지시로 압축한 것이다. 그 표현을 학습하는 일과 실제 시스템을 운영하는 일 사이에는 간극이 있다 [48:31]
• 일부 문제는 실제로 실행해야 결과를 알 수 있는 계산적 비환원성을 가진다는 지적이다. 모델이 직접 시뮬레이션하지 않아도 답을 얻을 수 있는 영역에서 특히 강할 가능성이 있다 [48:53]

26. 벤처투자에서 분석 자동화와 관계 형성의 차이

• 벤처투자의 핵심을 관계와 접근성으로 보는 관점에서는, 좋은 기업을 발견하는 것보다 자금 모집, 투자 경쟁에서의 승리, 투자 이후의 지원이 중요하다. 고위 임원 채용 지원처럼 스타트업이 혼자 하기 어려운 일을 돕는 역량도 포함된다 [51:09]
• AI의 분석 결과는 함께 일했던 분석가와 비슷하거나 더 나은 수준으로 평가된다. 그러나 이런 분석 능력이 신뢰 관계 구축과 거래 확보까지 대체한다는 뜻은 아니며, 분석 자체가 투자 성과를 얼마나 좌우하는지도 회의적으로 평가된다 [52:05]

27. 제한된 디지털 영역과 현실 문제의 경제성 차이

• AI의 학습 데이터가 구성하는 디지털 세계와 실제 세계는 자주 다르다. 운영과 자율주행처럼 그 간극을 넘어야 하는 분야가 코드 다음의 확장 가능성을 시험한다 [53:29]
• 해답의 분포가 학습 데이터와 가까운 코드 문법이나 이미지 생성에서는 빠른 발전이 이어질 전망이다. 자연 세계의 분포를 다뤄야 하는 문제는 더 어렵고 오래 걸리며 경제성 확보도 까다로울 수 있다 [54:10]

28. AI에 맞게 환경을 바꾸는 자동화 전략

• 기존 세계에 AI를 맞추는 것뿐 아니라, 자동화할 수 있도록 세계를 바꾸는 방법도 있다. 로보틱스와 창고 자동화처럼 환경 전체를 자동화에 맞추는 방식이 그 사례다 [56:10]
• 현실 문제의 해결에는 연산과 비용이 들며, 환경과 시스템을 제한하면 그 경제성을 바꿀 수 있다. AI 자체의 성능 향상과 함께 적용 환경을 재설계하는 일이 중요해진다 [56:45]

29. 고객이 구매하는 것은 AI보다 분명한 비용 절감 효과

• 고객 접점에서는 장애 예방과 신뢰성 향상보다 데이터독 요금을 90% 줄일 수 있다는 설명에 구매 의사가 집중된 사례가 있다. 이 수치는 고객 대화에서 제시된 절감 효과이며, 모든 환경에서의 성과로 일반화되지는 않는다 [57:46]
• 코딩 AI는 큰 비용 항목인 엔지니어링 생산성과 직접 연결돼 가치를 설명하기 쉽다. 운영 AI는 생산성 향상이나 장애 예방의 가치를 금액으로 환산해 구매로 연결하기가 상대적으로 어렵다 [58:22]

🧾 결론

• AI 코딩의 발전은 운영 자동화의 가능성을 보여주지만, 같은 발전 경로가 운영에서도 재현된다는 증거는 아니다.
• 운영 자동화는 모든 장애를 미리 학습하는 방식보다, 변화 신호를 포착하고 원인을 좁히는 디버깅 절차를 실행하는 방향으로 제안된다.
• 인간의 역할은 요구사항과 설계 판단, 평가 기준 설정, 변경 통합, 관측되지 않는 조직 지식의 보완에 남아 있다.
• AI의 능력 향상과 함께 적용 환경과 시스템을 자동화하기 쉽게 재설계하는 일도 중요하다.

📈 투자·시사 포인트

• 운영 AI 기업은 탐지·진단 능력과 고객이 실제로 지불할 가치를 함께 입증해야 한다. 비용 절감은 장애 예방보다 구매 효과를 설명하기 쉬운 출발점으로 제시된다.
• 관측 가능성 제품의 가치는 수집 데이터의 양보다 같은 비용으로 확보하는 신뢰성 개선과 연결해 평가할 필요가 있다.
• 코딩 AI의 생산성 수치를 운영 AI의 성장 전망에 그대로 적용하기는 어렵다. 운영에는 드문 예외, 부족한 데이터, 실제 환경 실험이라는 추가 부담이 있다.
• 범용 AI를 현실에 적용하는 사업에서는 모델 성능뿐 아니라 실행 비용과 적용 환경의 제약이 경제성을 좌우할 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 엔지니어 간 약 10배 격차와 개발 생산성 약 10~20배 향상은 소규모 팀의 경험과 과거 작업 기간에 대한 추정에 근거한다. 일반적인 조직의 성과로 확대 해석하기 어렵다.
• 텔레메트리 또는 데이터독 비용 90% 절감은 서비스 소개와 고객 대화에서 제시된 수치다. 적용 환경, 비교 기준, 신뢰성에 미친 영향은 별도로 확인해야 한다.
• 변화 탐지의 긍정적 평가는 내부 시스템과 일부 고객 환경에 한정된다. 탐지 정확도, 오탐, 장애 예방 효과를 판단할 정량 자료는 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• AI에 운영 작업을 맡기기 전에 워크로드, 접근 패턴, 설정, 기대 동작과 구현 제약을 명시한다.
• 실제 사용자 쿼리와 성능 벤치마크를 준비하고, 변경 전후의 결과와 자원 사용을 비교한다.
• 관측 데이터의 수집·전송·저장 비용을 파악하고, 상류 신호 추출이 비용과 조사 품질에 미치는 영향을 함께 확인한다.
• 변화 탐지 모델과 AI 조사 단계를 구분하고, AI가 가설·확인 근거·실험 결과를 남기는 절차를 설계한다.

❓ 열린 질문

• 드문 장애와 새로운 워크로드 변화까지 다루려면 어떤 신호와 실험 절차가 충분한가?
• AI가 수행한 쿼리 최적화의 성공을 클러스터 전체의 안정적인 운영으로 확장할 수 있는가?
• 자원을 넉넉히 확보하는 방식과 AI로 운영을 정교하게 제어하는 방식 중 어느 쪽이 더 경제적인가?