슬롭의 시대에서 나만의 코딩 에이전트 'Pi'를 만들다
이 영상은 게임 개발자 마리오 제크너(Mario Zechner)가 기존 코딩 에이전트 도구들의 한계에 좌절하며 자신만의 에이전트 'Pi'를 만든 과정, 오픈소스를 파괴하는 AI 봇('클랭커') 문제, 그리고 에이전트에게 모든 것을 맡기는 무분별한 개발 문화에 대한 경고를 3막 구조로 풀어낸 강연입니다. 핵심 메시지는 "속도를 줄이고, 코드를 직접 읽고, 에이전트가 아닌 인간이 결정권을 가져야 한다"는 것입니다.
1. 1막: Pi를 만들게 된 이유
마리오는 자신을 "늙은 개발자"라고 소개하며, 왜 기존 코딩 에이전트 도구들을 떠나 직접 Pi를 만들었는지 이야기합니다. 먼저 그는 Cloud Code(Anthropic의 코딩 에이전트)에 대한 이야기로 시작합니다.
"2025년 4월쯤 Cloud Code를 쓰기 시작했어요. 피터가 '에이전트가 이제 제대로 작동한다'고 알려줬거든요."
처음에는 단순하고 예측 가능했고, 자신의 워크플로에 잘 맞았다고 합니다. 하지만 시간이 지나면서 팀이 커지고, 토큰 열풍에 휩쓸려 수많은 기능이 추가되었습니다. 쓰지 않는 기능은 무시할 수 있지만, 빠른 속도와 많은 기능은 더 많은 버그를 동반했습니다.
"저는 예전에 건설 현장에서 일했는데, 제 망치가 매일 부서지면 정말 화가 나요. 개발 도구가 매일 부서져도 마찬가지죠." 🔨
Cloud Code가 게임 엔진이 됐다는 농담이 돌 정도로 불안정해졌고, 렌더러만 세 번째 재작성 중이었다고 합니다. 하지만 이런 것들은 증상에 불과했습니다.
진짜 문제: 컨텍스트의 통제권 상실
마리오가 가장 크게 느낀 문제는 "내 컨텍스트가 내 것이 아니었다"는 점이었습니다.
"Cloud Code가 내 뒤에서 컨텍스트에 이것저것 합니다. 시스템 프롬프트는 매 릴리스마다 바뀌고, 도구 정의도 변경되고, 도구를 삭제하기도 하죠."
특히 시스템 리마인더를 컨텍스트의 엉뚱한 위치에 삽입하면서 "이 정보는 당신이 하는 일과 관련이 있을 수도 있고 없을 수도 있습니다"라고 적어놓는 바람에 모델이 혼란에 빠지고, 자신의 워크플로가 깨졌다고 합니다.
그 외에도 세 가지 근본적 한계가 있었습니다:
- 관찰 가능성 제로: 에이전트가 뭘 하는지 알 수 없음
- 모델 선택권 제로: Anthropic의 Claude만 사용 가능
- 확장성 거의 제로: 훅이 있긴 하지만 얕고, 매번 새 프로세스를 스폰하는 비효율적 구조
대안 탐색: Open Code의 문제점
마리오는 AMP와 Factory Droid를 "코딩 에이전트의 포르쉐와 람보르기니" 🏎️ 라고 부르며 추천했지만, 오픈소스 성향의 자신은 Open Code로 향했습니다. 역시 훌륭한 팀이었지만, 컨텍스트 처리를 뜯어보니 문제가 있었습니다.
특정 조건에서 도구 출력을 일정 토큰 이후 잘라버리는 것은 모델의 능력을 심각하게 훼손했고, LSP 서버가 편집 도구 호출마다 에러를 체크해 결과에 주입하는 방식도 문제였습니다.
"생각해 보세요. 코드를 짤 때 한 줄 쓰고 에러 확인, 다음 줄 쓰고 에러 확인 이렇게 안 하잖아요. 작업을 끝내고 나서 에러를 확인하죠. 이게 모델을 혼란스럽게 합니다."
심지어 기본 설정으로 서버가 뜨면 CORS 헤더 때문에 브라우저에서 열린 아무 웹사이트가 Open Code 서버에 접근할 수 있는 보안 문제도 있었습니다. 😬
Terminal Bench가 알려준 것
이런 문제들을 탐색하던 중, 마리오는 Terminal Bench라는 벤치마크를 발견합니다. 놀라운 점은, 이 벤치마크가 모델에게 주는 도구가 tmux 세션에 키 입력을 보내고 출력을 읽는 것뿐이라는 것이었습니다. 파일 도구도, 서브 에이전트도 없었습니다.
"그런데 이게 리더보드에서 가장 성능이 좋은 하네스 중 하나에요. 모델 계열에 상관없이, 심지어 그 모델의 네이티브 하네스보다 더 높은 점수를 받았습니다."
이것이 말해주는 바는 명확했습니다: 우리는 아직 코딩 에이전트의 "삽질하고 배우는" 단계에 있고, 현재 형태가 최종 형태가 아니라는 것. 그리고 더 나은 실험을 위해서는 자기 수정이 가능하고 유연한 에이전트가 필요하다는 것이었습니다.
2. Pi의 구조와 철학
이런 깨달음을 바탕으로 마리오는 불필요한 것을 모두 걷어내고, 최소한의 코어에 극도의 확장성을 가진 에이전트를 만들었습니다. 그것이 바로 Pi입니다.
"Pi는 당신의 워크플로에 적응하는 에이전트입니다. 그 반대가 아니라요."
Pi는 네 개의 패키지로 구성됩니다:
- AI 패키지: 프로바이더 간 추상화와 컨텍스트 핸드오프
- 에이전트 코어: while 루프와 도구 호출로 이루어진 단순한 구조
- UI 프레임워크: 게임 개발 배경을 살려 깜빡임 없이 만든 터미널 UI
- 코딩 에이전트: 실제 코딩 에이전트 기능
극도로 작은 시스템 프롬프트
Pi의 시스템 프롬프트는 놀라울 정도로 짧습니다. 마리오는 슬라이드에 전체 시스템 프롬프트를 보여주며 "이게 전부입니다"라고 말합니다. 그 이유는 명확합니다:
"모델들은 이미 강화 학습으로 엄청나게 훈련되어 있어요. 코딩 에이전트가 뭔지 알고 있습니다. 포스트 트레이닝 때 바로 그걸 훈련하니까요. '당신은 코딩 에이전트입니다'라고 1만 토큰을 써서 알려줄 필요가 없어요. 그들은 이미 코딩 에이전트니까요."
도구도 단 네 개뿐입니다: 읽기(read), 편집(edit), bash, 그리고 하나 더. 도구 정의의 크기 자체가 매우 작다는 것을 슬라이드로 강조합니다.
YOLO 보안 철학과 확장성 🎯
Pi는 기본적으로 YOLO 모드(승인 없이 실행)로 동작합니다. bash를 호출할 때마다 승인 팝업이 뜨는 것이 스마트한 보안이 아니라고 생각하기 때문입니다.
"대신 저는 여러분에게 충분한 밧줄을 줍니다. 자신의 보안 요구에 맞는 것을 뭐든 만들 수 있도록요."
서브 에이전트 지원, 플랜 모드, MCP 지원 같은 것들은 내장되어 있지 않습니다. 필요하면 Pi에게 만들어달라고 하면 됩니다.
확장은 TypeScript 모듈로 이루어집니다. 가장 간단한 경우 디스크에 있는 TypeScript 파일 하나를 Pi에 연결하면 됩니다. 확장 API를 통해 모든 것에 훅을 걸 수 있고, 도구를 정의하고, 슬래시 커맨드를 만들고, 이벤트를 수신하고, 세션에 상태를 저장하고, 커스텀 컴팩션과 프로바이더를 구현할 수 있습니다.
가장 멋진 부분은 핫 리로드입니다. 🔥 게임 개발에서 온 철학으로, 확장을 개발하면서 세션 안에서 바로 변경사항을 반영하고 효과를 즉시 확인할 수 있습니다.
재미있는 확장 사례들
Anthropic이 출시한 /by the way 기능(에이전트가 메인 작업 중일 때 대화할 수 있는 기능)을 마리오가 트위터에 프롬프트로 올렸더니, 누군가가 5분 만에 더 많은 기능을 가진 확장으로 만들어버렸습니다. Pi를 포크하거나 클론할 필요도 없이, 에이전트에게 프롬프트 기반으로 확장을 쓰게 했을 뿐입니다.
가장 활발한 확장 개발자인 니코(Nico)는 자신의 모든 Pi 에이전트가 서로 대화하는 채팅방을 만들었습니다. 😂 마리오는 "이걸 쓸 일은 절대 없겠지만"이라면서도, 커스텀 UI까지 포함된 이 확장의 존재 자체가 Pi의 확장성을 증명한다고 말합니다. 심지어 NES 게임을 하거나 Doom을 플레이할 수도 있습니다. 🎮
"Pi 확장은 어떻게 만드나요? 직접 만들지 않습니다. Pi에게 여러분의 사양에 맞춰 만들어달라고 하세요. 그리고 핫 리로드하면서 반복하세요."
Terminal Bench에서 Pi는 컴팩션 기능이 없던 시절에도 6위를 기록했습니다. 하지만 마리오는 이것이 Pi 자체에 관한 이야기가 아니라고 강조합니다.
"저는 근본적으로 여러분이 도구와 워크플로의 통제권을 되찾길 바랍니다. 직접 만드세요."
3. 2막: 클랭커가 오픈소스를 파괴하고 있다
피터가 OpenClaw의 에이전틱 코어로 Pi를 채택하면서, 마리오의 오픈소스 프로젝트는 예상치 못한 상황에 놓입니다. 수많은 OpenClaw 인스턴스들이 사용자도 모르게 Pi의 이슈 트래커에 쓰레기 같은 이슈와 풀 리퀘스트를 쏟아내기 시작한 것입니다. 🤖💩
"클랭커(Clankers)가 오픈소스를 파괴하고 있습니다."
TL;Draw는 이슈와 풀 리퀘스트 트래커를 아예 닫아버렸고, OpenClaw의 트래커도 난장판이 됐습니다. 마리오의 트래커도 절반이 오픈소스 인스턴스가 올린 쓰레기였습니다.
마리오는 이에 맞서 독창적인 방어 시스템을 구축합니다:
- 자동 닫기 필터: 풀 리퀘스트가 오면 자동으로 닫히고, "인간의 목소리로, 화면 하나 분량 이하의 텍스트로 이슈를 작성해주세요"라는 코멘트가 달립니다. 마리오가 확인 후 "LGTM"을 쓰면 해당 계정이 허용 목록에 추가됩니다.
"클랭커는 그 코멘트를 읽지 않아요. 풀 리퀘스트를 올린 후 다시 돌아오지 않죠. 완벽한 필터입니다."
- 라벨링: OpenClaw과 상호작용한 이력이 있으면 이슈의 우선순위를 낮춤
- 3D 시각화: 이슈와 풀 리퀘스트 텍스트를 임베딩해서 3D 공간에서 클러스터를 확인
- OSS 휴가: 원할 때 트래커를 그냥 닫아버림 🏖️
"OSS 휴가를 발명했습니다. 원할 때 트래커를 닫아요. 그래서 제 삶을 되찾았습니다."
미첼(Ghostty 개발자)은 이 방식을 Vouch라는 도구로 발전시켰다고 합니다.
4. 3막: 제발 속도를 줄여라
마리오의 마지막 막은 현재 개발 문화에 대한 강력한 경고입니다.
"모든 것이 망가져 있습니다."
"그리고 '우리 제품은 100% 에이전트로 만들었습니다'라고 하는 사람들이 있죠. 네, 그래서 그게 형편없다는 걸 우리는 알고 있습니다. 축하합니다." 👏
마리오는 현재 에이전트 사용 방식의 문제를 하나씩 짚어갑니다. Beats on Been(사실상 제거 불가능한 멀웨어)을 쓰는 에이전트 군대, Anthropic이 만든 "대충 작동하지만 사실은 안 되는" C 컴파일러, Perplexity의 망가진 브라우저... 그리고 "다음 세대 모델이 고쳐줄 거야"라는 희망.
"SaaS는 죽었다, 소프트웨어는 6개월 안에 해결된다, 우리 할머니가 OpenClaw로 Spotify를 만들었다... 좀 진정하세요, 여러분."
에이전트는 에러를 복리로 쌓는다 📈
마리오는 에이전트가 만드는 문제를 "부우우스(boooos)"라는 자신만의 용어로 에러를 표현하며, 세 가지 특성을 지적합니다:
- 연쇄 학습: 이전 에러 위에 새 에러를 쌓음
- 병목 없음: 인간과 달리 속도 제한이 없음
- 지연된 고통: 문제가 나중에야 드러남
인간 한 명, 에이전트 하나, 에이전트 열 개를 비교하면서 묻습니다: 에이전트가 생성한 코드를 얼마나 리뷰할 수 있을까? 하루에 쌓이는 에러 수를 생각하면, 얼마나 많은 에러를 찾을 수 있을까?
"'리뷰 에이전트가 있어요'라고 하시겠죠? 오로보로스의 경이로운 세계에 오신 걸 환영합니다."
리뷰 에이전트도 일부 이슈만 잡을 수 있을 뿐입니다. 근본적인 문제는 에이전트와 모델이 학습한 복잡성이 인터넷의 낡은 쓰레기 코드에서 왔다는 것입니다. 인터넷에는 훌륭하게 설계된 시스템도 있지만, 90%는 우리의 오래된 쓰레기 코드입니다.
에이전트의 모든 결정은 로컬합니다. 코드베이스가 컨텍스트에 다 들어가지 않을 정도로 크면 특히 그렇습니다. 그래서 얽힌 추상화, 중복, 불필요한 하위 호환성, 과도한 방어적 코딩이 넘쳐납니다.
"두 명의 인간과 열 개의 에이전트로 2주 만에 엔터프라이즈급 복잡성을 달성합니다. 축하합니다." 🎉
"상세한 스펙이 있으면 되지 않나요?"
"충분히 상세한 스펙을 뭐라고 부르는지 아세요? 그건 프로그램입니다."
스펙에 빈칸을 남기면 모델은 인터넷에서 학습한 쓰레기에서 중간 수준의 코드로 그 빈칸을 채웁니다.
인간이 여전히 중요한 이유 🧠
인간도 실수를 하는 존재이지만, 에이전트와 결정적으로 다른 점이 있습니다:
"인간은 병목입니다. 하루에 코드베이스에 추가할 수 있는 에러의 양에 한계가 있어요."
"그리고 인간은 고통을 느낍니다. 이것은 매우 흥미로운 속성이에요. 인간은 고통을 싫어하거든요."
고통이 너무 쌓이면 인간은 퇴사하거나, 누군가에게 떠넘기거나, 다 함께 모여 코드베이스를 리팩토링합니다. 하지만 에이전트는?
"에이전트는 여러분의 코드베이스에 기꺼이 계속 똥을 쌓아갈 것입니다."
agents.md나 복잡한 메모리 시스템도 도움이 되지 않습니다. 에이전트는 우리가 학습하는 방식으로 학습하지 않기 때문입니다.
"'저는 코드를 더 이상 읽지도 않아요.' 축하합니다. 뭔가 망가지고 사용자들이 비명을 지르면, 누구를 부르실 건가요? 코드를 안 읽었으니 자기 자신은 아니겠죠."
에이전트에게 맡기려 해도, 코드베이스가 너무 거대해져서 필요한 컨텍스트를 모두 가져올 수 없습니다. 100만 토큰 컨텍스트 윈도우도, 에이전틱 검색도 실패합니다.
"에이전트는 로컬하게 패치하고 글로벌하게 망가뜨립니다. 이걸 코드베이스에서 발견하면, 끝난 겁니다."
테스트도 에이전트가 작성했으므로 코드베이스도, 테스트도 신뢰할 수 없습니다. "Good game(게임 끝)."
5. 에이전트와 올바르게 일하는 법
마리오는 비판만 하지 않고, 에이전트를 효과적으로 활용하는 실질적인 방법도 제시합니다.
좋은 에이전트 작업의 특성:
- 스코프가 명확한 작업: 에이전트가 필요한 모든 것을 찾을 수 있도록 범위가 정해진 작업 → 코드베이스를 모듈화하세요
- 평가 함수가 있는 작업: 에이전트가 얼마나 잘했는지 측정할 수 있으면 더 좋음 (힐 클라이밍, 자동 연구)
- 미션 크리티컬하지 않은 작업: 마음껏 맡기세요
- 지루한 작업: 마음껏 맡기세요
- 사용자 이슈 재현 케이스: 정보가 불완전한 재현 작업에 완벽
"아침 시간을 그런 데 더 이상 쓰지 않아요."
- 러버덕: 가까이에 인간이 없으면 대화 상대로 활용
작업이 끝나면 평가하고, 합리적인 부분만 취하고(대부분은 아님), 최종 마무리는 직접 합니다.
마지막 당부 ✋
"제발 속도를 줄이세요. 무엇을 만들고 있는지, 왜 만드는지 생각하세요. 에이전트가 할 수 있다고 해서 만들지 마세요. 그건 바보 같은 짓입니다."
"'아니오'라고 말하는 법을 배우세요. 지금 여러분의 가장 가치 있는 능력입니다."
더 적은 기능, 하지만 중요한 것만. 그리고 에이전트를 써서 그것을 끝내주게 다듬으세요. 사용자를 기쁘게 하세요, 토큰 소비 욕구를 만족시키지 말고.
비핵심 코드는 슬롭으로 채워도 괜찮지만, 핵심 코드는 모든 줄을 읽으세요. 그렇다면 무엇이 핵심인지 어떻게 알 수 있을까요?
"코드를 읽으면 됩니다."
"중요한 것은 직접 손으로 쓰세요. 클랭커를 도우미로 쓸 수는 있지만, 결정을 대신 내리게 하지 마세요. 모든 결정은 인터넷에서 학습한 것이니까요."
그 마찰과 불편함이 바로 시스템에 대한 이해를 머릿속에 쌓는 과정이고, 새로운 것을 배우는 순간이기도 합니다.
"이 모든 것에는 규율과 주체성이 필요합니다. 그리고 이 모든 것에는 여전히 인간이 필요합니다."
마치며
마리오 제크너의 이 강연은 단순히 자신의 도구 Pi를 소개하는 것을 넘어, 현재 AI 코딩 에이전트 생태계의 근본적인 문제들을 날카롭게 짚어냅니다. 기존 도구들의 컨텍스트 통제 문제, AI 봇이 오픈소스 커뮤니티를 잠식하는 현실, 그리고 무엇보다 에이전트에게 모든 것을 맡기면 복잡성은 기하급수적으로 늘고 이해는 사라진다는 경고가 핵심입니다. 결국 중요한 것은 속도가 아니라 이해와 통제권, 그리고 "아니오"라고 말할 수 있는 인간의 판단력입니다. 🧭