LLM 코드 생성 에이전트, 어디서 무너지는가 — PostHog Wizard 운영 경험에서 배운 것들
📺 원본 영상: LLM codegen fails and how to stop ‘em — Danilo Campos, PostHog 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-01 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
PostHog의 엔지니어 Danilo Campos는 자신이 직접 운영하는 자율 코딩 에이전트(Autonomous Coding Agent) 서비스인 ‘PostHog Wizard’를 통해 얻은 생생한 실전 경험을 공유한다. 매달 15,000명이 사용하는 이 서비스는 원래 2시간짜리 PostHog 연동 작업을 8분 안에 처리해주는 마법 같은 도구로, 그 마법의 이면에는 “로봇에게 코를 얻어맞은” 수많은 실패와 그로부터 터득한 대응 전략이 존재한다. 강연자는 LLM 코드 생성이 실패하는 네 가지 주요 원인과 각각에 대한 구체적 해법을 제시하며, 마지막에는 에이전트 시대의 패러다임 전환에 대한 통찰로 마무리한다.
PostHog Wizard란 무엇인가
Danilo가 만든 PostHog Wizard는 사용자의 프로젝트에 PostHog(제품 분석 도구) 연동을 자동으로 완료해주는 자율 코딩 에이전트다. 강연자에 따르면 이 작업을 수동으로 하면 “당신의 인생에서 돌려받지 못할 2시간의 고통”이 소요되는데, Wizard는 이것을 8분짜리 유사 엔터테인먼트 경험으로 압축해버린다. 놀라운 점은 이 서비스가 단순히 동작하는 것을 넘어, 사용자들이 실제로 블루스카이(Bluesky)와 트위터에 자발적으로 만족 후기를 올릴 만큼 긍정적인 반응을 끌어낸다는 사실이다.
이처럼 로봇이 타인의 코드베이스에 직접 손을 대는 구조는 무한한 가능성을 제공하지만, 동시에 무한한 위험도 수반한다. 강연자가 “이미 코를 너무 많이 얻어맞아서 더 이상 아프지도 않다”고 자조하는 데서 알 수 있듯, PostHog Wizard가 지금의 신뢰성에 도달하기까지는 수많은 실패 모드를 직접 경험하고 하나씩 봉쇄하는 과정이 필요했다.
실패 원인 1 — 모델 부패(Model Rot)
LLM 모델을 훈련하는 것은 시간과 자본이 엄청나게 소요되는 작업이다. Anthropic이 주말에 취미로 모델을 훈련하는 것이 아니라는 강연자의 말처럼, 이는 심각한 자본 지출(Capital Expenditure)이다. 그 결과 모델은 훈련이 완료된 시점의 웹과 소프트웨어 생태계를 스냅샷처럼 담고 있는데, 그 스냅샷은 보통 6개월에서 18개월 전의 것이다.
02:18 - Model Rot 설명 섹션 — 모델 훈련 비용과 지식 만료 문제를 다루는 슬라이드
빠르게 진화하는 소프트웨어 프레임워크와 라이브러리 생태계에서 이 시간 차이는 치명적이다. 약 1년 전, 사람들이 초기 에이전트(예: Cursor)에게 PostHog 연동을 요청했을 때 에이전트는 존재하지 않는 API 키를 지어내고, 없는 패턴을 만들어내며, 아예 허구의 API를 호출했다. PostHog의 잘못이 아니었지만, 그 문제는 PostHog의 것이 될 수밖에 없었다.
강연자가 선택한 해법은 RAG(Retrieval-Augmented Generation)보다도 더 직접적인 방법이다. 오늘날의 컨텍스트 윈도우(Context Window)가 충분히 넓어진 덕분에, 그냥 최신 마크다운 파일을 컨텍스트에 밀어넣는 것으로 충분하다. PostHog Wizard는 에이전트가 통합 작업을 시작할 때 posthog.com에서 방금 생성된 따끈한 최신 문서를 메뉴 형태로 제공한다. 에이전트는 “지금 어떤 프레임워크를 연동하려 하는가”에 따라 필요한 문서를 직접 선택해 컨텍스트에 로드하고, 그 상태에서 코드를 작성하기 때문에 구식 정보로 인한 오류를 원천 차단할 수 있다.
03:43 - PostHog Wizard의 문서 컨텍스트 주입 방식 — 에이전트가 최신 마크다운 문서를 선택하는 흐름
실패 원인 2 — 이상한 아키텍처와 ‘모델 에어플레인(Model Airplane)’
모델이 훈련 과정에서 수많은 오픈소스 프로젝트를 학습했겠지만, 그 프로젝트들이 모두 훌륭한 아키텍처를 가지고 있지는 않았을 것이다. 이 때문에 에이전트는 기술적으로는 작동하지만 이상적이지 않은 방식으로 코드를 구성하는 경향이 있다. 매달 15,000건의 통합이 이뤄지는 상황에서 에이전트가 매번 다른 방식을 선택한다면, 지원 부담이 기하급수적으로 늘어나는 마법사의 제자(Sorcerer’s Apprentice) 상황이 펼쳐진다.
이를 해결하기 위해 PostHog 팀이 도입한 개념이 ‘모델 에어플레인(Model Airplane)‘이다. 진짜 비행기처럼 보이지만 실제로 날지는 않는 모형 비행기처럼, 모델 에어플레인은 PostHog가 연동된 얇은 예제 프로젝트다. 다양한 프레임워크와 언어로 작성되어 있지만, 실제 프로덕션 애플리케이션과는 다르게 인증(Auth) 로직이 단순화되어 있다. 어떤 비밀번호를 입력해도 로그인이 되는 구조지만, 그 인증 흐름은 실제 인증 코드와 동일한 ‘모양(shape)‘을 하고 있다. 에이전트는 이 모델 에어플레인을 통해 “로그인이 일어나는 이 자리에 이런 이벤트 트래킹 코드를 삽입하면 된다”는 올바른 패턴을 학습하게 된다.
05:34 - Model Airplane 개념 소개 — 얇은 예제 프로젝트의 구조 또는 코드 예시
모델 에어플레인의 또 다른 장점은 토큰 효율성이다. 실제 프로덕션 코드베이스를 통째로 컨텍스트에 넣는 것보다 훨씬 가볍기 때문에, 비용 효율적으로 에이전트가 올바른 통합 패턴을 매번 일관되게 재현할 수 있도록 유도할 수 있다.
실패 원인 3 — 즉흥(Improvisation)과 ‘빵 부스러기(Breadcrumbing)’ 전략
에이전트에게 목표를 너무 명확하게 알려주는 것도 문제가 될 수 있다. 강연자는 Claude Code를 사용할 때의 경험을 예로 든다. 해야 할 다섯 가지 작업을 미리 모두 알려주면, 에이전트는 처음 네 가지를 마치 Claude Code 형태의 구멍을 뚫듯이 빠르게 처리하다가 다섯 번째에서 갑자기 지나치게 완벽주의적으로 변하는 경향이 있다는 것이다. 결과적으로 에이전트는 15,000가지 방식으로 PostHog 통합을 완료하게 되고, 이는 지원 악몽으로 이어진다.
이를 막기 위해 PostHog 팀이 사용하는 전략이 ‘빵 부스러기(Breadcrumbing)‘다. 에이전트를 단계적으로 안내하되, 한 번에 전체 그림을 보여주지 않는 방식이다. 구체적으로는 다음과 같은 순서로 진행된다.
먼저 에이전트에게 PostHog 통합을 한다는 사실조차 알리지 않은 채, “이 프로젝트에서 비즈니스적으로 가치 있는 파일들이 어디에 있는가?”라고 묻는다. 로그인 로직, Stripe 결제 인터페이스, 이탈 가능성을 나타내는 코드가 있는 파일들을 찾아달라는 것이다. 흥미롭게도 비즈니스 로직은 코드베이스에서 거대한 그림자를 드리우기 때문에, 에이전트는 이런 파일들을 매우 안정적으로 찾아낼 수 있다.
다음으로, 찾아낸 파일들을 토대로 “어떤 이벤트들을 트래킹하면 좋겠는가? 지금 당장 코드는 작성하지 말고, 이벤트 이름과 설명만 생각해보자”라고 요청한다. 이렇게 만들어진 이벤트 목록은 작은 파일로 저장되고, 이것이 다음 단계의 출발점이 된다. 그제서야 에이전트는 PostHog 문서와 함께 실제 코드 수정을 시작하며, 이때의 수정은 엉뚱하지 않고 사용자도 불쾌해하지 않는 방식으로 이루어진다.
07:36 - Breadcrumbing 전략 도식 — 에이전트를 단계적으로 안내하는 순서
실패 원인 4 — 인간 오류, 그리고 에이전트에게 피드백 구하기
강연자는 에이전트 아웃컴에 대한 가장 큰 위협은 에이전트 자체가 아니라 인간이라고 단언한다. 인간의 두뇌에도 컨텍스트 한계가 있고, 그것은 커피를 마신 지 얼마나 됐는지, 아침을 먹었는지에 따라 달라지는 불안정한 것이다. 엔지니어들은 코드를 수정하고 에이전트를 둘러싼 도구들을 진화시키면서 자신도 모르게 중요한 무언가를 빠뜨리곤 한다.
실제로 PostHog 팀은 MCP(Model Context Protocol) 도구 지시 사항이 서로 모순되는 상황을 경험했고, 에이전트에게 “반드시 사용해야 한다”고 지시해놓은 도구가 MCP에는 존재하지 않는 채로 수백 번의 실행이 이루어지는 사태도 겪었다. 이런 오류들은 물어보지 않으면 알 수 없다.
그래서 PostHog 팀이 도입한 것이 간단하지만 강력한 ‘추론 시점 심문(Inference-Time Interrogation)‘이다. 매 실행이 끝나는 정지 훅(Stop Hook)에서 에이전트에게 단 하나의 질문을 던진다. “이번 실행에서 우리가 당신의 성공을 위해 더 잘 할 수 있었던 것은 무엇인가?” 이 간단한 질문을 통해 팀은 “접근 권한이 없는 도구가 있었다”, “Python 프로젝트인데 JavaScript 지시사항을 계속 받았다” 같은 구체적인 문제들을 발견할 수 있었다. 사용자 리서치와 동일한 방법론을 에이전트에게 적용한 셈이다.
11:15 - Stop Hook에서 에이전트에게 피드백을 요청하는 질문 예시 또는 결과 화면
보안 위협 — 에이전트의 ‘셰나니건(Shenanigans)’
타인의 컴퓨터에서 에이전트를 실행하는 것은 막대한 신뢰를 요구한다. PostHog Wizard의 초기 버전은 .env 파일을 읽는 기능이 있었는데, 에이전트가 파일에 쓰기 작업을 하려면 먼저 읽어야 하는 것은 기술적으로 필연적인 구조다. 그러나 사용자의 .env 파일 내용이 클라우드로 전송되어 어딘가의 로그에 저장된다는 것은 명백히 문제가 있었다.
이 문제를 해결하기 위해 팀은 에이전트의 도구 사용을 세밀하게 제한했다. .env 파일 관련 작업은 딱 두 가지만 허용된 전용 도구로만 수행하도록 제한했다. 첫째, 특정 키가 존재하는지 확인하기. 둘째, 특정 키에 새 값을 쓰기. 이것이 전부다. .env 파일의 내용 자체는 추론 과정에서 어디에도 전송되지 않는다.
13:09 - .env 파일 접근 제어 — Fine-Grained Tool 제한 방식 설명 슬라이드
강연자는 이를 교훈으로 삼아, 에이전트가 문제를 해결하는 방식이 기술적으로는 옳더라도 사용자 관점에서 나쁜 인상을 줄 수 있음을 항상 경계해야 한다고 강조한다.
패러다임의 전환 — 코드보다 프로즈(Prose)가 중요해진 세계
강연의 가장 핵심적인 통찰은 마지막에 등장한다. 강연자는 우리가 평생 ‘코드를 더 많이, 더 영리하게, 더 정교하게 작성하는 것’으로 보상받아온 세계에서 살아왔다고 말한다. 그러나 오늘 좋은 코드를 작성해도 내일 새로운 모델이 출시되는 순간, 그 코드의 가치는 변하지 않는다. 오히려 코드는 언제나 감가상각되는 자산(Depreciating Asset)이었다.
반면 프로즈(Plain Text Prose), 즉 잘 쓰인 자연어 문서는 다르다. 오늘 훌륭한 프로즈를 작성하면, 내일 더 나은 모델이 등장했을 때 그 모델이 동일한 프로즈로 훨씬 더 많은 것을 할 수 있게 된다. 이것이 강연자가 말하는 근본적인 전환이다. 실제로 PostHog Wizard의 구성 비율은 전체의 90%가 마크다운 파일, 8%가 마크다운 파일을 전달하고 처리하는 도구, 나머지가 에이전트 하네스(Agent Harness) 코드라고 한다.
15:21 - Wizard 구성 비율 — 90% 마크다운, 8% 도구, 나머지 에이전트 하네스를 보여주는 차트 또는 도식
에이전트를 강연자는 문어(Octopus)에 비유한다. 좁은 틈새를 비집고 들어가 문제를 해결하는 유연한 존재다. 개발자의 역할은 에이전트의 행동을 코드로 빽빽하게 스캐폴딩(Scaffolding)하는 것이 아니라, 한 발 물러서서 충분한 정보를 적절한 순서로 제공함으로써 에이전트가 스스로 올바른 일을 하도록 이끄는 것이다. 이는 에이전트 시대의 엔지니어링이 ‘더 많이 쓰기’에서 ‘더 잘 설명하기’로 무게 중심이 이동했음을 의미한다.
Q&A 주요 내용
강연 후 질의응답에서 청중은 Wizard가 어떻게 컨텍스트를 제공하는지 물었다. 강연자에 따르면, Wizard는 ‘스킬 파일(Skill File)‘이라는 개념을 사용하며, 이 스킬 파일은 컨텍스트 서비스로부터 생성된다. 컨텍스트 서비스는 앞서 설명한 모델 에어플레인들을 하나의 마크다운 파일로 평탄화(flatten)한 후 스킬 파일에 참조로 포함시킨다. 이 방식을 통해 에이전트는 항상 완전한 모델 에어플레인과 최신 문서 모두에 접근할 수 있다.
기술 스택과 관련하여, PostHog Wizard는 Claude Agent SDK를 기반으로 구축되었으며, 이를 CLI로 감싸 사용자가 단일 명령어로 실행할 수 있도록 했다. PostHog 계정으로 로그인하면 토큰 비용을 PostHog이 대신 부담하는 구조인데, 이 LLM 게이트웨이를 구현하는 과정에서 Claude Code가 예상치 못한 위치에 정보를 저장하여 서비스가 중단되는 문제 등 다양한 초기 서비스 운영의 어려움이 있었다고 한다.
마무리 — 로봇에게 코를 얻어맞은 이들을 위한 다섯 가지 교훈
Danilo Campos의 강연은 자율 코딩 에이전트를 실제 프로덕션 서비스로 운영한 경험에서 나온 살아있는 지식의 집합이다. 그 핵심을 정리하면 다음과 같다.
첫째, 모델은 반드시 낡아간다. 최신 문서를 컨텍스트에 직접 주입하여 모델 부패를 예방하라. 둘째, 올바른 패턴을 보여주는 얇은 예제 프로젝트(모델 에어플레인)는 에이전트의 일관성을 담보하는 가장 효과적인 도구다. 셋째, 에이전트에게 모든 것을 미리 말하지 말고, 빵 부스러기처럼 단계적으로 안내하라. 넷째, 가장 큰 실패 원인은 에이전트가 아니라 인간이며, 에이전트에게 직접 피드백을 물어보는 것이 가장 싸고 빠른 디버깅 방법이다. 다섯째, 도구 사용에 대한 세밀한 제어(Fine-Grained Control)로 에이전트가 ‘셰나니건’을 저지르지 못하도록 막아라.
그리고 이 모든 것의 바탕에는 하나의 철학적 전환이 있다. 코드를 쓰는 시대에서 에이전트에게 올바른 정보를 올바른 순서로 전달하는 프로즈를 쓰는 시대로의 전환. 강연자가 90%의 마크다운으로 15,000명을 매달 행복하게 만드는 서비스를 운영하고 있다는 사실은, 이 전환이 이미 시작되었음을 증명한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | LLM codegen fails and how to stop ‘em — Danilo Campos, PostHog |
| 채널 | AI Engineer |
| 강연자 | Danilo Campos (PostHog) |
| 리포트 작성 | 2026-05-01 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- Why (Senior) Engineers Struggle to Build AI Agents — Philipp Schmid, Google DeepMind
- Bounded Autonomy — Between Free Will and Determinism, Angus J. McLean, Oliver
- Self Driving Products - Product Signals to Pull Requests — Joshua Snyder, PostHog
- Ralph Wiggum (and why Claude Code’s implementation isn’t it) with Geoffrey Huntley and Dexter Horthy