에이전트에게 도구를 쥐여주는 방식은 지난 1~2년 사이 몇 차례 방향을 바꿔 왔다. 한쪽에는 MCP(Model Context Protocol) 같은 프로토콜로 커스텀 도구를 모델 컨텍스트에 미리 올려두는 방식이 있고, 다른 한쪽에는 "결국 코드와 셸이면 충분하다"며 CLI와 bash 조합을 선호하는 흐름이 있었다. Flask를 만든 아르민 로나허는 후자를 강하게 밀어 온 인물인데, 그가 자신이 참여한 에이전트 하네스 Pi 1.0에 MCP 지원을 'Codemode'라는 형태로 추가하면서 이 둘을 어떻게 화해시켰는지를 설명했다. 핵심 질문은 글의 부제에 압축돼 있다. 'bash만 있으면 되는데, 왜 Codemode가 필요한가.'
bash가 못 하는 것
CLI와 bash를 선호하는 이유는 분명하다. 호출을 서로 조합하기 쉽고, 모델이 학습 과정에서 파일 시스템의 동작을 함께 익히기 때문이다. echo foo > /tmp/test.txt를 실행하면 그 다음부터 /tmp에 파일이 생겼다는 사실을 모델이 자연스럽게 안다. 그러나 bash에는 근본적 한계가 있다. 실행 가능한 '프로그램'만 조합할 수 있다는 점이다. 반면 멀티모달 모델이 이미지를 읽거나 서브 에이전트를 띄워 조율하는 일은 프로그램 실행이 아니라 LLM에 고유한, 하네스가 제공해야만 하는 기능이다. 이미지를 cat으로 읽을 수는 없다. 하네스가 실제 이미지 페이로드를 모델 프로토콜에 직접 주입해야 하기 때문이다.
여기서 '두 개의 시스템'이라는 구도가 중요해진다. 하나는 판단을 담당하는 하네스, 즉 '두뇌'로 신뢰받는 쪽이다. 다른 하나는 실제로 도구가 실행되는 '손', Pi의 표현으로는 실행 환경(execution environment)이다. 둘은 같은 기계일 수도 있지만 파일 시스템과 신뢰 수준이 다르다. Gondolin 같은 샌드박스를 쓰면 bash 쪽은 격리되지만 하네스 자체는 격리되지 않는다. 이 경계선이 Codemode의 존재 이유를 규정한다.
Codemode는 '두뇌 쪽'에서 도는 코드
Codemode는 LLM이 복잡한 작업을 표현하고 조율하되, 실행 환경이 아니라 하네스 쪽에서 돌리게 하는 장치다. Pi에서는 WASM 런타임 위의 QuickJS에서 JavaScript로 동작하며 네트워크·파일 시스템·타이머가 없고 RAM도 제한된다. 할 수 있는 일은 오직 더 많은 도구를 호출하는 것뿐이다. 명칭은 Cloudflare에서 왔고, 요지는 LLM 컨텍스트를 매번 거치지 않고도 언어 안에서 도구 호출을 조합하는 것이다. 실무적으로 눈에 띄는 차이가 몇 가지 있다. 일반 bash 도구 호출은 출력 뒤쪽 2,000줄만 컨텍스트에 들어가고 나머지는 오버플로 파일을 모델이 직접 열어야 하지만, 같은 호출을 Codemode로 하면 더 큰 출력이 구조화된 형태로 전달된다.
더 중요한 것은 JavaScript이기에 동시 실행과 간단한 워크플로를 표현할 수 있다는 점이다. 에이전트가 먼저 도구 응답에서 5~10개 항목만 찍어 형태를 파악한 뒤, 나머지 n개를 처리하는 스크립트를 작성하는 패턴이 실제로 관찰된다. 또 store()로 실행 결과를 세션 트랜스크립트에 넣어 두면 다음 Codemode 호출이 이를 다시 읽을 수 있는데, 이 상태가 샌드박스가 아니라 하네스 호스트에 남는다는 점이 핵심이다. 이미지 생성이나 Jev 같은 원샷 분류 모델처럼 일반 도구로 노출하면 컨텍스트만 낭비하는 내부 API도 Codemode를 통해 호출된다. 글에는 Jev로 깃허브 이슈를 대량 감성 분석하거나, tankctl 명령 위에 30단계 루프를 만들어 게임 엔진 디버깅을 돕는 실제 세션 사례가 제시된다. 동시 도구 실행은 Pi가 자체적으로 최대 4개로 제한하고 나머지는 큐로 관리하므로 Promise.all을 써도 문제가 없다.
MCP와의 궁합, 그리고 남은 숙제
Codemode는 MCP 서버 호출에도 유용하다. Pi는 MCP 도구를 LLM에 직접 노출하지 않고, 에이전트가 Codemode 안에서 도구 검색을 먼저 실행해 연결된 서버로 무엇을 할 수 있는지 점진적으로 발견하게 한다. 다만 솔직한 자평은 '아직 썩 매끄럽지 않다'이다. 상당수 MCP 서버가 Codemode를 쓰는 하네스를 염두에 두고 설계되지 않았기 때문이다. 임시방편으로 Cloudflare처럼 MCP 서버 안에 Codemode를 넣는 방식이 쓰이는데, 그러면 'Codemode 안의 Codemode'가 되어 JSON을 이중으로 이스케이프해야 하고 작은 모델이 혼란에 빠지기 쉬우며 안쪽 코드가 바깥 도구를 부르지 못한다. 저자는 이를 1년 전 주장의 번복이 아니라고 본다. MCP 생태계가 결국 '코드가 답'이라는 지적을 받아들인 것이며, Codemode는 거기서 한발 더 나아가 하네스 안에서 에이전트에게 더 큰 자유를 주는 장치라는 것이다.
한국의 실무자 관점에서 Codemode는 두 가지로 읽을 수 있다. 첫째, 도구를 모두 컨텍스트에 올려 토큰을 소모하는 대신 '필요할 때 코드로 호출·조합한다'는 설계 원칙은 자체 에이전트를 만드는 팀에게 참고할 만한 토큰 경제학이다. 둘째, 신뢰받는 하네스와 격리된 실행 환경을 분리하는 사고방식은 샌드박싱 전략을 세울 때 유용한 틀을 제공한다. 동시에 한계도 분명하다. 저자는 Codemode의 내구성(durability) 확보가 까다로워 지속형 워크플로 엔진의 스냅숏 개념이 필요할 수 있고, 결정론적 성격 덕에 JavaScript보다 Starlark 같은 언어가 더 나은 조합 언어일 수 있다고 본다. 이미지·바이너리 데이터 처리와 작은 모델에서의 동작 역시 아직 다듬어야 할 부분으로 남아 있다. 완성된 해법이라기보다, 앞으로 더 적극적으로 활용될 '유망한 패턴'으로 보는 편이 정확하다.