AI 에이전트에게 프로젝트 파일 50개를 분석해 달라고 하면 어떻게 될까요? 에이전트는 파일을 하나씩 읽고, 그 내용을 전부 자신의 기억(컨텍스트 윈도우)에 쌓아 올립니다. 그리고 어느 순간, 처음에 무엇을 요청받았는지조차 잊어버립니다.
이 글은 개발자 Mert Köseoğlu가 자신의 오픈소스 MCP 플러그인 context-mode v1.0.64에 도입한 “Think in Code” 패러다임을 소개한 글입니다. Cloudflare가 같은 문제를 “Code Mode”로 해결하고 있다는 사실을 발견한 그는, 두 팀이 완전히 독립적으로 동일한 결론에 도달했다고 말합니다.
출처: Cloudflare Built Code Mode. We Built Think in Code. Same War, Different Front. – Mert Köseoğlu
AI 에이전트가 토큰을 낭비하는 구조적 이유
지금 대부분의 AI 코딩 에이전트는 LLM을 ‘데이터 프로세서’처럼 다룹니다. 파일을 읽고, JSON을 파싱하고, 함수 수를 세고, 오류를 필터링하는 일을 LLM이 직접 수행합니다. 이 과정에서 읽어들인 원시 데이터가 컨텍스트 윈도우에 그대로 쌓입니다.
저자는 이걸 이렇게 표현합니다. “시니어 엔지니어를 고용해놓고 스프레드시트 행 수를 손으로 세라고 하는 것과 같다.”
반면 “프로그래머”로서의 LLM은 다릅니다. 데이터를 직접 처리하는 대신, 그 작업을 수행할 코드를 작성합니다. 코드는 샌드박스에서 실행되고, LLM에게 돌아오는 건 결과값뿐입니다. 원시 데이터는 LLM의 컨텍스트에 한 번도 들어오지 않습니다.
그 차이는 수치로 드러납니다. 50개 파일을 직접 읽으면 컨텍스트에 500KB 이상이 쌓입니다. 코드를 써서 처리하면 결과만 돌아오기 때문에 같은 작업이 200바이트로 끝납니다.
Cloudflare와 context-mode, 같은 결론에 도달하다
Cloudflare 팀은 또 다른 문제를 풀고 있었습니다. Cloudflare API에는 엔드포인트가 2,500개가 넘는데, 이걸 MCP 툴로 하나씩 노출하면 툴 정의를 읽는 데만 6만 토큰 이상이 소비됩니다. 이들의 해법인 “Code Mode”는 2,500개의 툴을 단 2개로 줄였습니다. LLM이 TypeScript 코드를 작성하면, Dynamic Worker(V8 기반 샌드박스)가 이를 실행하고 console.log() 출력만 반환합니다.
context-mode는 반대쪽 문제를 풀었습니다. API 툴 정의가 아닌, 로컬 파일 분석 과정에서 발생하는 컨텍스트 범람을 막는 데 초점을 맞췄습니다. v1.0.64에서 “Think in Code”는 선택지가 아닌 기본 규칙이 됐습니다. Claude Code, Cursor, Gemini CLI를 포함한 12개 플랫폼 설정 파일 전체에 같은 지시가 삽입됩니다. “분석이 필요하면 코드를 작성해서 실행하라. 원시 데이터를 컨텍스트로 읽어들여 머릿속으로 처리하지 마라.”
두 팀의 구현 방식은 다릅니다. Cloudflare는 클라우드 API 환경에서 작동하고, context-mode는 로컬 파일시스템에서 돌아갑니다. 하지만 핵심 발상은 같습니다. LLM이 선택하게 두지 말고, 패러다임 자체를 기본값으로 만드는 것입니다.
저자가 강조하는 것도 바로 이 지점입니다. 인프라는 이미 수개월 전부터 있었습니다. 변한 건 LLM에게 선택권을 주지 않기로 한 결정이었습니다. 선택지가 있으면 LLM은 거의 항상 파일을 직접 읽는 쪽을 택했다고 합니다.
수렴이 말해주는 것
AI 코딩 도구 시장에서 서로 다른 문제를 풀던 두 팀이 같은 아키텍처에 도달했다는 사실은 단순한 우연이 아닙니다. “LLM은 컴퓨터 역할을 못 한다. 프로그래머 역할은 잘 한다”는 전제가 점점 더 공고해지고 있습니다.
로컬 CPU 연산은 공짜이고, LLM 토큰은 비쌉니다. 에이전트가 직접 처리해야 할 일과 코드에게 위임해야 할 일의 경계를 다시 그을 필요가 있다는 메시지입니다.
참고자료:
답글 남기기