Slop의 시대에 pi를 만들다 — Mario Zechner
📺 원본 영상: Building pi in a World of Slop — Mario Zechner 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-17 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
게임 개발 출신 엔지니어 Mario Zechner는 자신이 Claude Code를 떠나 직접 코딩 에이전트 pi를 만들기까지의 여정을, 그리고 오픈 소스 생태계가 AI 에이전트의 자동화된 기여로 몸살을 앓는 현실을, 마지막으로 에이전트를 맹목적으로 신뢰하는 현재 업계 풍조에 대한 날선 경고를 세 개의 막(Act)으로 엮어 전달한다. 이 강연은 단순한 툴 소개가 아니라 에이전트 시대에 엔지니어로서 어떤 철학과 태도를 가져야 하는지에 대한 성찰이다.
Act 1: Claude Code를 떠나 pi를 만들다
Claude Code가 처음엔 좋았던 이유
Zechner는 강연 초반부터 자신이 Claude 팀을 존경한다는 점을 분명히 했다. “로스트(roast, 비난)가 아니라”는 그의 표현처럼, 이 이야기는 비판을 위한 비판이 아니다. 2025년 4월경 동료 Peter의 권유로 Claude Code를 쓰기 시작했고, 당시에는 단순하고 예측 가능했으며 그의 워크플로에 자연스럽게 녹아들었다. 게임 개발 출신 특유의 빠른 반복(iteration) 감각을 가진 그에게, 초기 Claude Code는 도구답게 작동하는 도구였다.
왜 떠났는가 — 컨텍스트는 내 것이 아니었다
그러나 시간이 지나면서 문제들이 쌓이기 시작했다. 팀이 커지고 기능이 늘어나면서 버그도 증가했는데, Zechner의 비유는 직설적이다. “공사 현장에서 일했을 때 망치가 매일 부러지면 화가 나듯이, 개발 도구가 매일 고장 나면 나도 화가 난다.” Claude Code가 화면 깜빡임(flicker) 문제로 게임 엔진처럼 동작한다는 논쟁이 커뮤니티에서 오갈 때 — Tariq는 “Claude Code는 게임 엔진”이라 했고, Ghostty 터미널 개발자 Mitchell Hashimoto는 이를 부정했다 — 결국 깜빡임은 수정됐지만 다른 문제들이 터져 나왔다.
그러나 Zechner가 꼽는 핵심 문제는 기능 버그가 아니라 컨텍스트의 주도권이었다. Claude Code는 사용자 몰래 컨텍스트를 조작한다. 릴리즈마다 시스템 프롬프트가 바뀌고, 툴 정의가 추가되거나 삭제되며, 심지어 시스템 리마인더가 컨텍스트 한복판에 삽입되는데 그 내용이 “지금 하는 작업과 관련이 있을 수도, 없을 수도 있습니다”라는 식이었다고 한다. 이런 불확실한 삽입이 모델을 혼란스럽게 만들고 그의 워크플로를 망가뜨렸다. 거기에 더해 에이전트가 무엇을 하는지 들여다볼 수 없는 제로 관측성(zero observability), 기본적으로 Claude 모델만 써야 하는 제로 모델 선택권, 그리고 훅(hook)의 수와 깊이가 매우 얕은 거의 제로에 가까운 확장성이 복합적으로 작용했다. 훅이 발동할 때마다 실제로 일어나는 일은 별도의 프로세스가 생성되어 지정한 커맨드를 실행하는 것이었는데, 그것을 효율적이라고 보기는 어려웠다.
OpenCode를 들여다보며
다른 선택지들을 살펴보던 Zechner는 프리미엄 상용 제품으로 Amp와 Factory.ai의 Droids를 주목했다. 그는 이 둘을 “코딩 에이전트 하네스의 포르쉐와 람보르기니”라고 표현하며, 여유가 된다면 사용을 권장했다. 그러나 자신은 오픈 소스 경험이 있는 사람으로서 자연스럽게 OpenCode 쪽으로 기울었다. 뛰어난 팀과 빠른 실행력, 허세 없이 작동하는 도구를 파는 점이 인상적이었다.
하지만 그는 OpenCode의 코드를 열어 컨텍스트 처리 방식을 분석했고, 몇 가지 심각한 패턴을 발견했다. 특정 조건에서 최소 토큰 수를 초과하면 툴 출력을 통째로 잘라버리는 로직이 있었는데, 이는 사실상 모델을 “부분 절제(lobotomize)“하는 것과 다름없다. 또한 LSP 서버 지원이 코드 편집 툴과 연동되어 있어, 에이전트가 편집 툴을 호출할 때마다 LSP 서버에 오류 여부를 물어보고 그 결과를 편집 결과에 주입하는 구조였다. Zechner는 이를 인간의 코딩 방식과 비교하며 문제를 지적한다. “코드 한 줄 쓰고 오류 확인, 다음 줄 쓰고 오류 확인은 아무도 안 한다. 작업을 끝내고 나서 오류를 확인하는 것이다.” 그 외에도 세션의 개별 메시지를 각각 별도의 JSON 파일로 디스크에 저장하는 방식, 그리고 기본 설정으로 CORS 헤더가 열려 있어 브라우저에서 접근한 임의의 웹사이트가 로컬 OpenCode 서버에 접근할 수 있는 잠재적 보안 이슈도 발견됐다.
TerminalBench가 말해주는 것
이즈음 Zechner는 코딩 에이전트 하네스 벤치마크를 조사하다가 TerminalBench를 발견했다. 이 벤치마크의 역설적인 특징은, 모델에게 제공하는 것이 tmux 세션에 키스트로크를 보내고 출력을 읽는 단 하나의 툴뿐이라는 점이다. 파일 편집 툴도, 서브 에이전트도, 복잡한 컨텍스트 관리도 없다. 그럼에도 2025년 12월 기준 TerminalBench는 모델 패밀리에 무관하게 대부분의 경쟁 하네스를 앞서는 성능을 보였다.
05:18 - TerminalBench 리더보드 (2025년 12월 기준)
이 발견에서 Zechner는 두 가지 테제를 도출한다. 첫째, 현재 코딩 에이전트는 “fuck around and find out(해보면서 배우는)” 단계에 있으며 현재 형태가 최종 형태가 아니다. 둘째, 그러므로 우리에게는 더 나은 방식으로 실험할 수 있는 도구, 즉 자기 수정 가능(self-modifying)하고 유연한(malleable) 에이전트가 필요하다.
pi의 철학과 구조
이러한 배경에서 탄생한 것이 pi다. pi의 핵심 철학은 “워크플로가 도구에 맞추는 것이 아니라, 도구가 워크플로에 맞추는” 것이다. Zechner는 불필요한 모든 것을 걷어내고 최소한의 코어만 남긴 뒤, 그 코어를 극도로 확장 가능하게 만들었다. pi는 네 개의 패키지로 구성된다. AI 패키지는 여러 AI 프로바이더에 대한 추상화 레이어이자 프로바이더 간 컨텍스트 핸드오프를 담당하고, 에이전트 코어는 본질적으로 while 루프와 툴 콜링이 전부다. 게임 개발 경험을 살려 깜빡임 없이 설계한 **TUI(Terminal UI)**와 코딩 에이전트 본체가 그 뒤를 잇는다.
06:24 - pi의 시스템 프롬프트 전체 화면
07:05 - pi의 툴 정의 크기 비교
pi가 기본으로 갖는 툴은 딱 네 가지다. 현대 코딩 에이전트들의 비대해진 툴 정의와 극명하게 대비되는 크기인데, 그 이유가 있다. 모델은 이미 포스트 트레이닝(post-training) 과정에서 코딩 에이전트 하네스를 활용해 훈련되었기 때문에, “당신은 코딩 에이전트입니다”라고 수만 토큰으로 설명할 필요가 없다. 모델은 이미 알고 있다.
확장성 — pi가 스스로를 수정하는 방법
pi를 특별하게 만드는 것은 에이전트 스스로 자신을 수정할 수 있다는 점이다. 이를 위한 열쇠는 문서화다. Zechner는 pi의 확장 방법에 대한 문서와 코드 예제를 직접 작성하여 pi와 함께 제공한다. 에이전트에게 “여기 문서가 있고, 여기 확장을 작성하는 코드 예제가 있다. 이것을 참고해서 네 자신을 수정하라”고 알려주기만 하면 된다.
pi의 확장(extension)은 가장 단순한 경우 TypeScript 파일 하나다. 해당 파일을 가리키기만 하면 하네스에 로드된다. 확장 API를 통해 개발자는 모든 것에 훅을 걸고, 하네스가 모델에게 노출하는 툴과 슬래시 커맨드 단축어를 정의하고, 이벤트를 구독하고, 세션 상태를 저장할 수 있다. 커스텀 컨텍스트 컴팩션(compaction), 커스텀 프로바이더 정의, 컨텍스트의 양방향 완전 제어도 가능하다. 완성된 확장은 npm 또는 GitHub에 그대로 배포하면 된다. “우리는 이미 패키지 매니저를 갖고 있는데 굳이 또 다른 마켓플레이스 사일로를 만들 필요가 없다”는 것이 그의 생각이다.
개발 경험(DX)도 설계에 반영됐다. **핫 리로드(hot reload)**를 지원하기 때문에 세션 도중 확장을 개발하면서 변경 사항을 즉시 반영해 효과를 확인할 수 있다. 게임 개발에서 짧은 반복 주기가 핵심이듯, pi의 확장 개발도 같은 원칙을 따른다. 실제로 Zechner가 Twitter에 장난 삼아 올린 짧은 프롬프트를 누군가가 5분 만에 확장으로 구현했는데, pi를 포크하거나 클론할 필요도 없었다. 에이전트 자체가 확장을 작성했기 때문이다. 또 다른 사용자는 여러 pi 에이전트가 서로 채팅하는 채팅룸 UI를 만들었고, 누군가는 pi 안에서 DOOM을 실행했다. 커스텀 UI까지 포함한 이 모든 것이 확장으로 구현된다.
💡 [영상 참조] 강연자는 이 시점에서 pi의 다양한 확장 사례들 — 에이전트 채팅룸, DOOM 실행 등 — 을 화면으로 보여줍니다. 📺 원본 영상에서 확인하세요.
TerminalBench 리더보드에서 pi는 컨텍스트 컴팩션 기능 추가 전 버전 기준으로 6위를 기록했다.
10:30 - TerminalBench 리더보드 (2025년 10월 기준, pi 포함)
Act 2: 클랭커 시대의 오픈 소스
오픈 소스 리포지토리를 오염시키는 클랭커들
pi가 Peter에 의해 OpenCode의 에이전트 코어에 포함되면서, pi의 GitHub 리포지토리는 갑자기 수많은 OpenCode 인스턴스의 타깃이 됐다. 해당 인스턴스를 운영하는 사용자들은 이를 인지하지도 못한 채였다. Zechner는 AI 에이전트가 자동으로 생성한 이슈와 풀 리퀘스트를 “클랭커(clankers)“라고 부르며, 이것이 오픈 소스 생태계를 파괴하고 있다고 주장한다. 이슈와 PR 트래커가 클랭커로 도배되면서 실제 인간 기여자들의 목소리가 묻히고, 메인테이너의 시간과 에너지가 바닥난다.
11:09 - 오픈 소스 트래커 사용량 비교
클랭커에 맞서는 전략들
Zechner는 이에 맞서 몇 가지 실용적인 전략을 개발했다. 풀 리퀘스트가 들어오면 자동으로 닫으면서, 인간적인 목소리로 쓴 짧은 이슈를 남겨달라는 코멘트를 남기는 것이다. 사람이라면 그 코멘트를 읽고 따르지만, 클랭커는 읽지 않는다 — 한번 PR을 올리고 나면 뒤를 돌아보지 않기 때문이다. 이것이 완벽한 필터가 된다. 이 과정을 통과한 인간 사용자의 계정 이름은 리포지토리의 특정 파일에 기록되고, 이후 그 사람의 PR은 바로 통과된다.
Ghostty 터미널 개발자 Mitchell Hashimoto가 이 메커니즘을 게임화하기도 했고, Zechner는 추가적으로 이슈와 PR 텍스트를 3D 공간에 임베딩해 이슈 클러스터를 시각화하는 툴도 만들었다. 그리고 때로는 아예 이슈 트래커를 닫아버리는 “OSS 방학(OSS vacation)” 전략을 택하기도 한다. “내 삶을 되찾았다”고 그는 말한다.
Act 3: 속도를 늦춰라
100% 에이전트 코드베이스의 현실
강연의 마지막 막은 가장 직설적이고 강렬하다. 업계 곳곳에서 “우리 제품은 에이전트가 100% 만들었습니다”라는 자랑이 들려오는데, Zechner의 반응은 냉정하다. “그거 엉망이라는 거 우리도 알아요. 축하합니다.” Anthropic이 만든 C 컴파일러는 어느 정도 작동하지만 실제로는 그렇지 않고, Cursor가 만든 브라우저도 심각하게 망가졌는데 모두들 다음 세대 모델이 고쳐주길 바라고 있다는 식으로 그는 업계 풍경을 묘사한다. 에이전트들은 오류를 학습 없이, 병목 없이, 고통의 지연과 함께 무한히 누적한다는 것이 핵심 문제다. Zechner는 에이전트가 만들어내는 버그를 유쾌하게 “boo-boo”라고 부르는데, 에이전트는 이 boo-boo를 쌓아가면서 아무것도 배우지 않는다. 그리고 그 고통은 나중에 사용자에게 전가된다.
13:13 - 코드베이스 boo-boo 시각화
리뷰 에이전트는 오우로보로스다
“리뷰 에이전트를 도입하면 되지 않나?”라는 반론에 Zechner는 자기 꼬리를 먹는 뱀 **오우로보로스(Ouroboros)**를 떠올리라고 한다. 에이전트가 생성한 코드를, 비슷한 코드를 인터넷에서 학습한 또 다른 에이전트가 리뷰한다는 것 자체가 순환 논리다. 리뷰 에이전트가 일부 문제를 잡아내더라도 근본적인 한계는 해결되지 않는다.
에이전트가 학습한 원천을 생각해보면 왜 그런지 알 수 있다. 인터넷에 있는 코드의 90%는 “우리의 낡은 쓰레기 코드”다. 잘 설계된 시스템이 물론 존재하지만 소수다. 에이전트의 모든 결정은 로컬(local)하다. 코드베이스가 에이전트의 컨텍스트에 다 들어오지 않을 만큼 커지면 에이전트는 전체 구조를 파악하지 못하고, 추상화를 도처에 추가하고, 중복을 만들어내며, 하위 호환성 코드를 쌓아간다. 그 결과는 단 두 명의 인간과 열 개의 에이전트가 2주 만에 만들어낸 엔터프라이즈 수준의 복잡성이다.
인간은 왜 중요한가 — 고통을 느끼기 때문이다
Zechner는 “인간도 버그를 만들지 않느냐”는 반론을 예상하고 직접 답한다. 맞다. 인간도 실패하는 존재다. 그러나 인간에게는 두 가지 결정적인 특성이 있다. 하나는 학습 능력이고, 다른 하나는 고통을 느끼는 능력이다. 고통은 언뜻 이상한 특성처럼 들리지만, 코드베이스에 문제가 쌓이면 인간은 불편함을 느끼고 행동에 나선다. 회사를 그만두거나, 남 탓을 하거나, 아니면 팀이 합심하여 리팩토링에 돌입한다. 에이전트는 코드베이스가 아무리 망가져도 개의치 않고 계속해서 코드를 추가한다. 또한 인간은 하루에 추가할 수 있는 boo-boo의 수에 자연스러운 **병목(bottleneck)**이 존재하는데, 에이전트에는 그런 병목이 없다.
**긴 컨텍스트 윈도우는 해결책이 아니라 임시방편(hack)**이다. Zechner는 많은 팀이 이 사실을 100만 토큰 컨텍스트 윈도우로 전환하면서 직접 경험하게 될 것이라고 예측한다. 에이전트의 검색(agentic search)도 실패하고, 에이전트는 로컬 수정이 글로벌 문제를 야기해도 인식하지 못한다. 이 지경에 이르면 코드베이스도, 에이전트가 작성한 테스트도 신뢰할 수 없게 된다. 그 상태에서 무언가 망가지면 에이전트에게 도움을 요청하지만, 에이전트는 이미 코드베이스가 너무 방대해 필요한 컨텍스트를 전혀 확보할 수 없는 상황에 놓인다.
에이전트를 제대로 활용하는 방법
그렇다면 에이전트를 어떻게 활용해야 할까? Zechner는 “좋은 에이전트 태스크”의 특성을 제시한다.
16:16 - 좋은 에이전트 태스크의 특성 슬라이드
에이전트가 작업에 필요한 모든 것을 반드시 찾을 수 있도록 스코프를 한정할 수 있어야 한다. 이것이 가능하다면 코드베이스를 잘 모듈화했다는 방증이기도 하다. 나아가 에이전트가 작업을 얼마나 잘했는지 평가할 수 있는 함수, 즉 평가 기준을 제공할 수 있다면 더욱 좋다. 이는 일종의 힐 클라이밍(hill climbing) 알고리즘처럼 에이전트가 스스로 개선할 수 있는 토대가 된다. 조사 리서치, 미션 크리티컬하지 않은 보조 코드, 지루한 반복 작업, 사용자 이슈의 재현 케이스(reproduction case) 작성 등이 에이전트가 탁월하게 처리할 수 있는 영역이다. 혼자 일할 때 “러버덕 디버깅(rubber duck debugging)“의 상대로 에이전트를 활용하는 것도 좋다. 그러나 이 모든 작업이 끝나면 반드시 직접 평가하고, 합리적인 것만 골라내고, 최종화하는 과정이 필요하다. 에이전트 출력 대부분은 그대로 쓸 수 없다는 것을 전제해야 한다.
마무리 — 에이전트 시대의 엔지니어링 철학
Mario Zechner의 강연은 단순한 툴 소개를 넘어 하나의 선언에 가깝다. 그의 최종 메시지는 명쾌하다. 에이전트가 할 수 있다는 이유만으로 무언가를 만드는 것은 어리석으므로, 왜 만드는지 먼저 생각하라. 거절하는 법을 배워라 — 이것이 현재 가장 가치 있는 역량이다. 더 적은 기능을 만들되 그것을 에이전트로 철저히 다듬어라. 생성된 코드 중 검토해야 할 양을 의식적으로 줄여라. 미션 크리티컬하지 않은 코드는 에이전트에게 맡겨도 되지만, 크리티컬한 코드는 한 줄 한 줄 읽어라. 그리고 중요한 것을 만들 때는 직접 손으로 작성하라. 에이전트를 보조 도구로 활용할 수는 있지만, 결정을 내리게 해서는 안 된다. 에이전트의 모든 결정은 결국 인터넷의 낡은 코드에서 학습된 것이기 때문이다.
코드를 직접 작성하면서 발생하는 **마찰(friction)**이야말로 시스템에 대한 이해를 쌓는 과정이다. 그것이 곧 학습이고, 새로운 것을 발견하는 방법이다. 에이전트가 아무리 강력해져도 그 과정은 인간을 필요로 한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Building pi in a World of Slop — Mario Zechner |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-04-17 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.