🔥 코딩 에이전트는 무엇을 빼야 작동하는가

내가 처음 Playwright MCP를 깔았을 때, 첫 호출에서 13.7k 토큰이 도구 정의로 사라졌다. Chrome DevTools MCP를 같이 깔면 18.0k 토큰이 또 사라진다. 작업을 시작하기도 전에 컨텍스트의 7~9%가 이미 비어 있다.

이 숫자는 Mario Zechner가 11월 초 자기 블로그에서 직접 측정한 값이다. 같은 글에서 그는 같은 일을 하는 CLI + README 구성이 225토큰이면 충분하다고 적었다. 60배 차이다. 시스템 프롬프트와 도구 정의가 커지는 동안 코딩 에이전트가 정말 더 나아졌는지는 나도 확신하지 못한다. 그래서 Mario가 그 반대 선택을 실제 도구에 적용한 글이 더 눈에 들어왔다.

한 사람이 만든 코딩 에이전트

Mario Zechner는 pi라는 코딩 에이전트를 혼자 만들었다. 그의 글이 다루는 핵심은 4개 패키지로 짜인 모노레포다(이후 pi-web-ui 같은 패키지를 더 얹었다). pi-ai는 Mario가 정리한 네 가지 핵심 LLM API(Anthropic Messages, OpenAI Completions, OpenAI Responses, Google Generative AI)를 한 인터페이스로 묶는다. pi-agent-core는 에이전트 루프와 도구 실행, 검증, 이벤트 스트리밍을 담당한다. pi-tui는 synchronized output 시퀀스(CSI ?2026h / CSI ?2026l)로 깜빡임 없는 터미널 UI를 그려낸다. 마지막으로 pi-coding-agent가 이 셋을 묶어 CLI 한 개로 발행한다.

Mario는 자기 글에서 짧게 단언한다. "Context engineering is paramount"(컨텍스트 설계가 전부다). 모델 출력의 품질은 결국 컨텍스트 안에 무엇이 들어 있는지가 결정한다는 입장이다. 그래서 그는 자기 도구 안에 들어가는 모든 항목을 한 번씩 다 의심했다.

그 결과 Mario가 측정한 pi의 시스템 프롬프트는 1000 토큰 안쪽이다(verified 2026-05-08). 도구도 4개뿐이다. read, write, edit, bash다. 비교 대상은 cchistory.mariozechner.at에서 시간 순으로 추적할 수 있는 Claude Code의 1년치 시스템 프롬프트 변천이다. Codex, Cursor, Amp도 같은 길로 갔다. pi는 그 반대 선택을 했다.

그가 빼기로 결정한 일곱 가지

Mario가 자기 글에 적은 부정 항목은 일곱 가지다. 각 항목마다 그가 어째서 뺐는지에 대한 짧은 정당화가 같이 있다. 정당화 없이 빼기만 한 게 아니라, 빼면서 대안을 같이 제시했다.

No MCP. Playwright MCP가 21개 도구로 13.7k 토큰을 차지하고, Chrome DevTools MCP가 26개 도구로 18.0k 토큰을 차지한다는 측정값이 그의 입장의 근거다(2025-11 시점 측정). 두 개만 깔아도 모델 컨텍스트의 7~9%가 작업 시작 전에 사라진다. 대안은 단순하다. CLI 도구와 README 한 장. 모델은 필요할 때 bash로 README를 읽고, 필요한 만큼만 컨텍스트로 가져온다. 항상 켜진 도구 카탈로그와 다르다.

No Plan Mode. Claude Code의 Plan Mode는 읽기 전용 서브에이전트를 띄워 코드베이스를 탐색하고 결과를 메인 세션으로 돌려보낸다. Mario는 그 결과가 세션 메모리에만 살아 있어 다른 세션과 공유하거나 버전 관리하기 어렵다고 본다. 그가 내미는 답은 짧다. 계획은 PLAN.md 파일로 적어 둬라. 텍스트 파일이라 git이 추적하고, 다른 세션에서 다시 읽고, 사람이 직접 수정할 수도 있다.

No built-in to-dos. 모델 안에 박아 놓은 todo 트래커는 자주 모델을 헷갈리게 만든다는 게 그의 관찰이다. 대안 역시 파일이다. TODO.md에 체크박스를 적고, 모델이 항목을 끝낼 때마다 직접 체크한다. 휘발성 상태가 영구 파일로 옮겨 가는 같은 패턴이다.

No background bash. pi의 bash 도구는 동기 실행만 한다. dev 서버나 REPL이나 테스트 watcher처럼 백그라운드로 돌리고 싶은 것은 tmux에 맡긴다. Mario가 든 예시도 같은 식이다. tmux 세션 안에 LLDB 같은 디버거를 띄워 두고, 모델이 그 세션에 명령을 흘려 넣어 주고받는다. 메인 세션에서 백그라운드 프로세스가 무슨 상태인지 늘 보인다.

No sub-agents. Mario는 병렬 서브에이전트 자체를 반대한다. 그의 표현을 그대로 옮기면 "an anti-pattern in my book"(내 기준에서는 좋지 않은 패턴이다)다. 이유도 단순하다. "Models are still poor at finding all the context needed for implementing a new feature"(모델은 아직 새 기능 구현에 필요한 컨텍스트를 다 잘 못 모은다)고 보기 때문이다. 그래서 그는 메인 세션이 먼저 컨텍스트를 모으고 파일로 남긴 뒤, 새 세션이 그 파일을 읽고 이어받는 순서를 권한다.

No safety rails. pi는 권한 게이트나 명령 사전 검사 없이 파일 시스템과 셸을 그대로 모델에 넘긴다. Mario의 입장은 분명하다. 모델이 데이터를 읽고 코드를 적고 명령을 실행할 수 있는 시점에서 "true security is impossible"(진짜 보안은 불가능하다)라고 본다. 그래서 bash 명령을 미리 검사해도 근본적인 보호가 되지 않는다고 적었다. pi가 처음부터 YOLO 모드 하나만 두는 이유도 그 판단에 있다. 단, 이 입장에 동의하지 않는 환경이라면 그의 도구를 fork해서 정책을 바꾸는 편이 자연스럽다.

No fancy system prompt. pi의 시스템 프롬프트 전문은 그의 글에 그대로 실려 있다. 16줄 남짓이다. 첫 줄은 "You are an expert coding assistant."(너는 숙련된 코딩 도우미다)다. 본문 가이드라인 사이에 "Be concise in your responses"(응답은 간결하게) 같은 한 줄짜리 권고가 끼어 있고, 그 뒤로 도구 사용법과 문서 위치 안내가 한두 줄씩 더 붙어 있다. 비교 대상은 Claude Code의 시스템 프롬프트가 cchistory.mariozechner.at에 시기별로 쌓인 1년치 변천이다. 둘 사이의 길이 차이가 그의 입장을 가장 선명하게 보여 준다.

1인 도구가 정교한 하니스와 견줄 수 있을까

여기까지 읽고 나는 한 가지가 궁금했다. 한 사람이 빼기만 해서 만든 도구가 Anthropic, OpenAI, Cursor가 팀 단위로 다듬은 하니스와 정말 견줄 수 있을까. Mario는 Terminal-Bench 2.0으로 측정값을 들고 왔다. 89개 작업으로 모델이 실제 터미널 환경에서 일을 처리하는지 보는 벤치마크다.

Terminus 2의 하니스는 예상보다 단순하다. Terminal-Bench 운영팀은 Terminus 2에서 tmux 세션 한 개만 도구로 쓴다. 별도 전용 도구도 없고, MCP도 없고, 서브에이전트도 없다. 그런데도 같은 모델을 같은 task에 끼워 보면 정교한 하니스와 점수 차이가 생각만큼 크지 않다. 같은 GPT 5.5로 비교하면 Codex의 자체 하니스가 Terminal-Bench 2.0에서 82.0%이고, Terminus 2가 Terminal-Bench 2.1에서 78.2%다(verified 2026-05-08). 4 포인트 차이를 위해 얼마나 많은 도구와 프롬프트를 더 끼워야 했는지 묻는 셈이다.

Mario는 벤치마크 점수에 큰 무게를 두지 않는다. 그는 벤치마크 결과가 우스워 보인다고까지 적었다. 더 중요하게 보는 근거는 실사용 기록이다. pi 안에서 한 세션에 수백 번 주고받아도 대화 압축 없이 끝까지 돌아간다고 했다. 처음부터 컨텍스트에 넣는 항목이 적으니 그렇게 버틴다는 설명이다.

그래서 다음에 도구를 깔 때

Mario의 글이 나에게 남긴 변화는 한 가지다. 새 도구나 새 MCP 서버를 깔기 전에 한 번 더 묻는다. 이걸 컨텍스트의 7%와 바꿀 만한가. 그 7%가 작업 시작 전에 사라진다는 사실을 잊지 않는다. 도구 한 개가 늘어나면 모델이 그 도구의 이름과 인자를 항상 기억해야 한다. 그만큼 다른 정보가 차지할 공간이 줄어든다.

나도 PLAN과 TODO를 다시 둔다. 세션 안에 가둬 두지 않고 파일로 적어 둔다. git이 추적하고, 다른 세션에서 다시 읽고, 사람이 직접 수정할 수 있는 곳에 둔다. 이게 pi의 일관된 패턴이다. 휘발성 상태를 영구 파일로 옮기면 잃어버릴 일도 없고, 모델 컨텍스트도 그만큼 줄어든다.

서브에이전트를 띄우기 전에 나는 한 가지를 먼저 묻는다. 내가 한 세션에서 끝낼 수 있는 구조인가. Mario의 표현대로, 모델은 아직 한 기능을 구현하는 데 필요한 컨텍스트를 다 못 모은다. 그렇다면 메인 세션이 직접 컨텍스트를 모아 파일로 떨군 다음, 새 세션이 그 파일을 입력으로 시작하는 순서가 더 안전하다. 병렬 서브에이전트는 그다음 선택지다.

Mario가 글 끝에서 남긴 메시지도 단순하다. "If pi doesn't fit your needs, I implore you to fork it. I truly mean it."(pi가 안 맞으면 꼭 fork해서 바꿔라. 진심이다.) 다음에 무언가를 더할 때는 같은 양만큼 무엇을 잃는지도 같이 봐야 한다. 이 글에서 Mario가 끝까지 밀어붙이는 판단 기준도 그 점이다. 코딩 에이전트의 성능은 대개 더하는 쪽보다 빼는 쪽에서 올라간다.

참고 자료

• What I learned building an opinionated and minimal coding agent (Mario Zechner): 이 글의 원전. pi의 설계 철학과 일곱 가지 NO 항목이 모두 들어 있다.
• What if you don't need MCP? (Mario Zechner): Playwright MCP / Chrome DevTools MCP 토큰 측정값의 1차 출처.
• badlogic/pi-mono GitHub repo: pi 모노레포 본체. 4 패키지 구현과 시스템 프롬프트 전문이 들어 있다.
• Terminal-Bench 2.0 leaderboard / 2.1 leaderboard: Codex agent harness와 Terminus 2 점수 비교 데이터.
• Terminus 2 agent (terminal-bench): raw tmux 만 쓰는 neutral test-bed harness 구현.
• Claude Code subagents docs: Plan Mode가 read-only 서브에이전트로 작동한다는 공식 문서.
• Synchronized Output Terminal Spec: pi-tui가 쓰는 CSI ?2026h / l 깜빡임 방지 시퀀스 사양.
• Claude Code system prompt history (cchistory.mariozechner.at): Claude Code 시스템 프롬프트의 1년치 변천을 시기별로 추적한 사이트.