Codemode란 무엇인가

이 글과 Cloudflare 글 모두 분량에 비해 시스템 수준의 단순한 큰 그림이 부족함. 내가 보기에는 핵심이 세 가지임. 동형성(homoiconicity) 으로 코드인 도구 호출과 데이터인 자연어를 토큰 스트림으로 일관되게 다루고, 액터 의미론으로 격리·캡슐화·동시성을 구현하며, 객체 역량(object capability)으로 참조를 주입하고 암묵적 권한을 없애는 것임. 역량 기반 리플렉션과 내부 검사는 인터페이스와 가능한 작업을 탐색하는 깔끔한 방법임. codemode는 수십 년간 쌓인 컴퓨터과학의 설계 원칙에서 출발하기보다 LLM 토큰 스트림에 기능을 덧붙이며 이를 재발견하는 과정으로 보임. LLM을 임시방편 인터프리터인 하네스에 연결된 텍스트 생성기가 아니라, 프로그래밍 언어 런타임의 참여자로 다루기 시작한 셈임. 기존 구현에 이런 기능이 없다면 결국 그 지점까지 임시방편을 계속 쌓게 될 것으로 예상함.
Dan Ingalls가 “운영체제는 언어에 들어맞지 않는 것들의 집합이며, 그런 것은 없어야 한다”고 했던 것 같은데, 하네스도 LLM과 프로그래밍 환경 어느 쪽에도 제대로 속하지 않는 어색한 중간 계층으로 보임. 차라리 LLM을 Common Lisp, Scheme 파이버, Spritely Goblins, Erlang BEAM과 연결하면 되지 않을까?

실제 핵심은 컨텍스트 관리임. MCP 도구를 호출하면 거대한 JSON이 컨텍스트 창에 들어와 압축을 유발할 수 있음. 하위 에이전트를 쓰면 조금 낫지만 여전히 비싸고, 모든 호출을 그렇게 처리할 수도 없음.
MCP 클라이언트 CLI가 있으면 결과를 jq 등에 파이프로 넘겨 필요한 부분만 추출하거나 여러 호출을 연결할 수 있음. 중간 결과를 임시 파일에 저장할 수는 있지만, 에이전트가 그 중간 텍스트를 전부 받을 필요는 없음. 셸 스크립트보다 JSON 처리에 적합한 JavaScript나 Python을 쓰자는 것이 codemode임.
에이전트와 프로그래밍 언어의 통합은 타당하지만, 지금은 하네스를 비교적 쉽게 교체할 수 있음. 구성 요소를 강하게 결합할수록 종속성 고착도 심해짐. Claude Code가 생태계에 강한 종속성을 갖게 될 때의 혼란을 떠올려 보면 됨.

하네스는 빠르게 시스템 프로그래밍의 새로운 개척지가 되고 있음. 브라우저를 플랫폼이나 운영체제에 비유했듯 하네스에도 운영체제 비유가 잘 맞음. 에이전트와 하위 에이전트는 스레드·프로세스와 닮았고, 동시성·공유 자원 접근·협력적 멀티태스킹 문제가 다시 나타남.
정리되기까지 시간이 걸리겠지만 오래된 아이디어들이 다시 새로워지고 있음. 나도 하네스를 설계하면서 Lisp 머신, 동형성, 액터 모델 등을 파고드는 중임.

글과 댓글을 읽고도 codemode가 뭔지 모르겠다면, 하네스에 작은 JavaScript 샌드박스를 제공해 도구 호출을 조합하고, 반환 데이터를 컨텍스트에 넣기 전에 가공하게 하는 것임.

codemode는 결국 bash를 샌드박스 안의 JavaScript로 대체하는 것임.

얻는 것에 비해 지나치게 복잡한 장치를 도입하는 듯함. 내게는 MCP나 에이전트가 코드로 조합할 수많은 도구 호출이 필요하지 않음. 애초에 pi의 약속은 bash만 있으면 되고 다른 도구는 거의 필요 없다는 것이었음.
가장 덜 침습적인 방법은 도구 호출을 가상 bash 명령으로 주입하는 것임. codemode나 손과 뇌의 이분법 없이도 LLM이 원하는 언어로 도구와 상호작용할 수 있음.

파일 40개 중 삭제할 쓸모없는 파일을 골라야 한다고 해보자면, 하나씩 처리할 때는 파일마다 여러 차례 상호작용해 40×n번의 턴과 거대한 컨텍스트가 필요할 수 있음. 대신 “뇌” 안에서 실행되고 자체적으로 LLM을 호출할 수 있는 스크립트를 작성하게 하면 됨.
파일을 순회하며 llm.model("is this file trash?", [f])로 판단하고 해당 파일을 삭제하는 식임. 병렬 실행도 가능하며, 각 호출에는 전체 컨텍스트 대신 목적에 맞는 프롬프트와 훨씬 작은 모델만 필요하므로 토큰 비용을 줄일 수 있음.

거의 모든 codemode 구현이 왜 JavaScript를 선택하는지 모르겠음. 나는 bash 기반 에이전트를 시제품으로 만들었는데 똑같이 잘 작동한다고 봄. codemode를 가르치는 프롬프트도 전혀 필요 없고, 이름이 bash인 도구만 있으면 LLM이 사용법을 알아서 이해함. https://github.com/ylxdzsw/mu

글에서 설명한 bash의 근본적인 한계는 실행 가능한 프로그램만 조합할 수 있다는 것임. 하지만 일부 도구는 프로그램이 아니라 LLM 고유 도구여야 함.
대표적으로 read나 view_image가 있음. 멀티모달 모델이 이미지를 읽을 때는 하네스가 실제 이미지 데이터를 LLM 프로토콜에 주입해야 하므로 cat으로 대체할 수 없음. 만든 시제품은 이 한계를 극복했는지?

모델이 JavaScript 기반 codemode를 학습했기 때문에 훨씬 적은 지시로도 사용할 수 있음. 동시성을 표현하기에도 전역 Promise가 잘 맞음.
특히 codemode는 하네스 쪽에서 실행되므로 bash를 실행 언어로 삼기가 까다로움.

거의 모든 모델은 JavaScript도 충분히 학습했으므로 별도로 가르칠 필요가 없음. 샌드박스 구성도 just-bash나 brush 기반 bash보다, 임베딩 도구가 훌륭한 JavaScript나 Lua 쪽이 더 쉬움.

bash에서 도구나 MCP를 호출할 수 있는지?

pi에서 codemode를 영구적으로 비활성화하려면 어떻게 해야 하는지? settings.json에서 이미 껐는데도 비활성화되지 않음. {"source":"npm:pi-mcp-adapter","extensions":["-index.ts","-builtin:codemode"]}와 "autoEnableCodemode": false를 설정한 상태임.

MCP와 codemode는 자동으로 활성화되지 않으므로 왜 켜졌는지부터 pi에 조사하게 해보면 좋겠음. codemode를 완전히 끄는 데는 {"extensions":["-builtin:codemode"]} 만 있으면 됨. 별도로 -builtin:mcp를 지정하면 MCP도 완전히 제거할 수 있음.

제목은 “What is codemode”인데, codemode를 모르던 입장에서는 “Orchestrating The Harness” 절까지 읽어야 “어떤 언어, 여기서는 JavaScript 안에서 도구 호출을 실행하는 방법”이라는 정의를 만날 수 있었음. 예제를 보고 대략 이해는 했지만 제목과 본문이 맞지 않음.

시제품에서 codemode를 쓰다가 작은 로컬 LLM의 토큰 사용량이 늘어 다시 제거했음. 도구 호출을 코드로 우아하게 묶는 것은 기대대로였지만, 내부 호출 하나가 매개변수 검증 등에서 실패하면 상위 코드 실행 도구 호출 전체도 실패함. 그러면 LLM이 원래 코드 블록의 상당 부분을 계속 다시 작성했음.
검증되지 않은 코드를 안전하게 실행해야 한다면 Pydantic 팀의 Monty가 쓰기 좋음. 단순화된 Python 방언이며, 기억이 맞다면 JavaScript에서도 사용할 수 있음.

작은 모델에서 codemode가 어떨지 직접 검증하지는 못했지만 걱정하던 부분이 드러난 셈임. Opus와 Sol에서는 아주 잘 작동하지만, 작은 모델까지 얼마나 잘 적용될지는 늘 궁금했음.

LLM 기반 Lisp만 있으면 코드가 데이터이고 데이터가 코드라는 순환을 마침내 완성할 수 있음.

codemode는 처음 들었고 이름은 별로지만, 개념 자체는 아주 타당해 보임. 처음 데이터베이스 MCP를 연결한 뒤로 이런 기능을 원했음.
원래는 표준 데이터 과학 도구와 데이터베이스 MCP를 함수로 쓸 수 있는 Python 런타임을 만들 생각이었고, 앞으로도 그렇게 할 수 있겠지만 지금은 JavaScript로 잘 쓰고 있음.