아무 일도 안 했는데 토큰 18,000개가 사라졌다: 코딩 에이전트 Pi가 MCP 연동 방식을 통째로 바꾼 기술적 이유

아무 명령도 내리지 않았는데 프롬프트 창 9%가 사라지는 이유

인공지능 코딩 에이전트에 외부 도구를 붙여주는 표준 규격으로 ‘모델 컨텍스트 프로토콜(MCP, Model Context Protocol)‘이 빠르게 자리를 잡았다. 브라우저를 직접 띄워 테스트하거나 사내 깃허브 저장소를 조회하는 작업 등을 규격화된 서버 연결 하나로 끝낼 수 있다는 점 덕분이다. 하지만 현장 엔지니어들이 실제로 서버를 붙여본 뒤 마주한 현실은 심각했다. 에이전트에게 단 한 줄의 코드 작성도 시키지 않은 채 빈 브라우저 제어 서버 하나만 연결했을 뿐인데, 거대언어모델(LLM)의 프롬프트 창에서 무려 18,000개에 달하는 토큰이 흔적도 없이 사라졌기 때문이다.

이 같은 토큰 낭비의 진원지는 개발 도구 제어를 돕는 크롬 데브툴스 MCP(Chrome DevTools MCP)였다. 200,000개 토큰을 처리할 수 있는 대형 컨텍스트 창 기준으로 약 9%에 달하는 공간이 에이전트가 무슨 일을 하기도 전에 도구 사용법 설명서로 채워진 셈이다. 플레이라이트 MCP(Playwright MCP) 역시 21개 도구의 기능과 매개변수를 모델에게 가르치느라 기본 프롬프트에서만 약 13,700개(전체 창의 6.8%)의 토큰을 집어삼켰다. 도구 서버 서너 개만 연동해도 실제 작업에 써야 할 모델의 기억 용량이 절반 가까이 날아가는 구조였다.

코딩 에이전트 파이(Pi)를 만든 마리오 체흐너(Mario Zechner)는 이 거대한 낭비를 목격하고 지난 1년 동안 MCP 공식 연동을 완강히 거부해 왔다. 그는 단순히 토큰이 많이 소모되는 문제를 넘어, 도구들이 서로 결과를 주고받는 과정(조합성)이 치명적으로 비효율적이라는 점을 지적했다. 도구 A가 웹페이지를 긁어온 결과를 디스크에 저장하거나 도구 B로 넘기려면, 그 방대한 중간 데이터가 무조건 모델의 프롬프트 창을 거쳐서 나와야만 했다. 마치 옆 책상 동료에게 서류 한 장을 전달하기 위해 건물 대표실을 경유해 결재를 받아야 하는 식이었다.

체흐너의 초기 대안은 지극히 실용적인 리눅스 배시(Bash) 스크립트였다. LLM은 이미 터미널 명령어를 능숙하게 다룰 줄 알기 때문에 수만 개짜리 복잡한 도구 명세서를 새로 읽어줄 이유가 없었다. 225개 토큰짜리 간단한 사용 설명서(README) 하나만 쥐여주고 파이프라인(|) 기호로 결과를 연결하면, 모델의 머릿속을 어지럽히지 않고도 중간 데이터를 디스크에 곧바로 저장할 수 있었다.

그러나 개발 생태계 전체가 MCP 중심으로 재편되면서 파이 역시 이를 무조건 외면할 수 없게 되었다. 파이를 인수한 이아렌딜(Earendil)은 정식 1.0 버전을 출시하면서 MCP를 코어 엔진에 전격 도입했다. 단, 업계의 표준 방식을 그대로 따르지 않았다. 모델과 도구 사이에 가벼운 자바스크립트 샌드박스를 끼워 넣는 독자적인 중계 계층 ‘코드모드(Codemode)‘를 배치하여, 토큰 낭비와 중간 데이터 경유 문제를 동시에 해결해 냈다.

프롬프트 용량과 실행 비용으로 본 도구 연동 방식 비교

기존 MCP 연동 방식의 가장 큰 맹점은 정적 사전 주입 방식에 있다. 모델이 이번 작업에서 쓰지도 않을 수십 가지 세부 도구의 정의와 입력 규격을 프롬프트가 시작할 때부터 모조리 집어넣는다. 반면 파이의 코드모드는 시스템 프롬프트에 각 MCP 서버당 단 한 줄짜리 요약 설명만 남겨둔다.

에이전트는 실제 작업 과정에서 도구가 필요해지면 자바스크립트 코드를 짜서 해당 도구를 찾고(Discovery), 격리된 자바스크립트 엔진 안에서 실행한 뒤 최종 가공된 결과물만 모델에게 돌려준다. 덕분에 기본 프롬프트 토큰은 획기적으로 줄어들고 불필요한 입출력 비용도 막아낸다.

구분 항목	기존 MCP 직접 연동 (일반 에이전트)	Pi 1.0 코드모드 연동 (QuickJS 격리)	Bash CLI 스크립트 방식 (체흐너 초기 모델)
초기 토큰 소모량	13,700 – 18,000개 (서버당)	서버당 1줄 (수십 토큰 수준)	225개 토큰 (README 1장)
도구 결과 결합 방식	모델 컨텍스트를 반드시 경유	샌드박스 내부에서 변수로 직접 전달	리눅스 파이프라인(|) 및 리다이렉션
보안 격리 환경	호스트 머신 권한 직접 상속 위험	시스템 자원 완벽 차단 QuickJS 엔진	샌드박스 없는 원시 셸 실행 권한
도구 노출 제어 단위	서버 단위 전체 허용/차단	개별 도구별 3단계 노출 정책 제어	스크립트 파일 단위 권한 제어
도구 선언 기본 예산	제한 없음 (프롬프트 한도까지 잠식)	3,000토큰 상한선 (초과분 동적 검색)	0토큰 (모델 사전 지식 활용)
대규모 작업 시 TCO	고가 모델 입력 토큰 비용 급증	프롬프트 크기 축소로 입력 비용 절감	토큰 비용 최소화 / 유지보수 공수 증가

실무 엔지니어링 관점에서 백엔드 서버 비용을 따져보아도 차이는 뚜렷하다. 예를 들어 RunPod 같은 서버리스 GPU 환경에서 시간당 0.79달러 선의 인프라를 띄워 자체 추론 엔진을 돌리든, 상용 LLM API를 호출하든 매 호출마다 불필요한 18,000개 토큰이 누적되는 것은 치명적이다.

만약 개발팀이 에이전트와 하루에 50번의 도구 호출 대화를 주고받는다면, 기존 방식에서는 순수 도구 명세 주입으로만 매일 900,000개의 입력 토큰이 낭비된다. 백만 토큰당 입력 단가가 2.50달러 수준인 고급 추론 모델을 쓸 경우, 에이전트 1대당 매달 60달러 이상의 순수 거품 비용이 도구 설명서 읽는 데에만 버려지는 셈이다. 파이는 이 거품을 걷어냈다.

기업 현장의 개발 공급망과 모델 운영에 미치는 직접적 파급력

에이전트가 도구를 다루는 방식의 변화는 단순한 기술적 취향의 차이가 아니다. 기업이 소프트웨어 개발 자동화를 사내에 도입할 때 직면하는 운영 비용, 응답 대기 시간, 그리고 시스템 안정성 전반에 직접적인 영향을 미친다.

1. 운영 비용(OPEX): 고가 추론 모델의 입력 토큰 누수 차단

기존 MCP 방식에서는 도구 서버를 추가할 때마다 프롬프트의 기본 크기가 비례하여 늘어난다. 사내 지식 베이스 검색용 서버, 깃허브 연동 서버, 클라우드 배포 서버를 한꺼번에 붙이면 실제 코드 작성 지시문이 들어가기도 전에 40,000개 이상의 토큰이 증발한다.

파이 1.0은 코드모드의 기본 도구 선언 예산을 3,000개 토큰으로 강제 제한했다. 이 한도를 넘어가는 세부 도구들은 프롬프트에 미리 적어두지 않고, 코드가 실행되는 시점에 필요할 때만 찾아 쓰는 동적 검색 상태로 남겨둔다.

파이 개발진의 배포 데이터에 따르면, 차세대 주력 모델 테스트 환경에서 기본 도구와 코드모드를 함께 얹었을 때 발생하던 프롬프트 토큰이 기존 약 5,300개에서 3,300개로 37% 이상 줄어들었다. 코드모드 자체의 설명 문구를 간추리고, 모델 API 문서를 프롬프트 밖으로 빼냈으며, 자바스크립트 코드가 이미 접근할 수 있는 도구의 중복 선언을 없앤 결과다. 호출 횟수가 수만 건에 달하는 엔터프라이즈 환경에서 이는 모델 이용료 청구서를 직접적으로 낮추는 결정적 요인이다.

2. 처리 속도와 지연 시간(Lead Time): 불필요한 왕복 없는 동시 병렬 처리

도구의 조합성 문제는 에이전트의 작업 속도와 직결된다. 브라우저로 특정 페이지 10곳을 순회하며 에러 로그를 수집해야 하는 상황을 가정해보자.

전통적인 MCP 구조에서는 다음과 같은 병목이 일어난다:

• 에이전트가 페이지 1을 방문하는 도구를 호출한다.
• 웹서버가 거대한 HTML 텍스트를 MCP를 통해 돌려준다.
• 이 원시 텍스트 전체가 모델의 프롬프트 창 안으로 밀려 들어간다.
• 모델이 텍스트를 읽고 에러 로그를 뽑아낸 뒤, 다시 페이지 2를 방문하는 도구를 호출한다.

이 지루한 과정을 10번 반복하면 모델 추론 시간이 기하급수적으로 늘어나며, 토큰 창도 순식간에 포화 상태에 이른다.

반면 코드모드는 이 작업을 QuickJS 샌드박스 안의 자바스크립트 코드로 위임한다. 코드가 반복문이나 동시 실행 문법을 사용해 10개 페이지의 로그를 한 번에 긁어오고, 정규표현식으로 필요한 에러 메시지만 골라낸 뒤, 최종 5줄짜리 요약본만 모델에게 반환한다. 모델은 수 메가바이트짜리 생짜 HTML을 보지도 않으며, 불필요한 입출력 왕복이 완전히 사라져 전체 작업 완료 시간이 절반 이하로 줄어든다.

3. 공급 안정성과 보안: 세밀한 도구 노출 제어와 호스트 격리

기존 MCP 서버는 호스트 머신의 시스템 권한을 무방비로 열어두기 쉽다. 에이전트가 오작동하여 위험한 삭제 명령을 내리거나 악성 코드를 받아올 경우 이를 방어할 수단이 마땅치 않았다.

파이의 코드모드는 노드(Node.js) 기본 API, 파일 시스템, 외부 네트워크 접근, 타이머 기능이 완벽히 거세된 경량 자바스크립트 엔진인 QuickJS 샌드박스 안에서만 돌아간다. 코드가 제멋대로 로컬 디스크를 뒤적이거나 이상한 외부 주소로 데이터를 빼돌릴 수 없다.

여기에 더해 개발자가 도구 노출 수준을 제어할 수 있는 도구 노출 제어(toolExposure) 옵션을 제공한다. 동일한 깃허브 MCP 서버를 연결하더라도 다음과 같이 세부 도구마다 접근 권한을 쪼갤 수 있다:

• search_code: 모델 프롬프트에 직접 노출하여 가장 빠른 속도로 즉시 호출
• get_*: 코드모드 샌드박스 뒤에 숨겨두어 필요할 때만 스크립트를 통해 안전하게 조회
• delete_*: 노출 목록에서 완전히 차단하여 모델이 해당 도구의 존재 자체를 인지하지 못하도록 격리

이러한 세분화된 통제권은 기업 내부의 보안 규정을 준수하면서도 자율 에이전트를 프로덕션 레벨에 투입할 수 있게 만드는 단단한 안전판 역할을 한다.

에이전트 생태계의 완충벽: 코드 모드 패턴과 경량화 흐름

파이가 선보인 이 구조는 소프트웨어 엔지니어링 업계에서 주목받고 있는 ‘코드 모드(Code Mode)’ 패턴의 대표적 사례다. 에이전트에게 세상의 모든 도구 규격을 JSON 형태로 일일이 설명하는 대신, 프로그램을 짤 수 있는 최소한의 실행 환경만 쥐여주고 스스로 스크립트를 짜서 외부 도구를 부리게 만드는 발상의 전환이다.

이러한 접근법은 최근 복잡한 워크플로우를 자동화하는 클라우드 환경에서도 폭넓게 관찰된다. Make 같은 노코드 자동화 도구가 수백 개의 API 모듈을 시각적으로 연결하듯, 코딩 에이전트 영역에서는 경량화된 자바스크립트 샌드박스가 복잡한 도구들을 하나로 꿰어주는 가상 허브 역할을 대신하고 있다.

체흐너가 처음 제시했던 Bash 스크립트 방식이 ‘단순함과 극단적 효율’의 승리였다면, 파이 1.0의 QuickJS 코드모드는 ‘표준 규격(MCP) 수용과 비용 통제’ 사이에서 찾아낸 실용적인 타협점이다.

개발팀 입장에서는 오픈소스 진영에서 쏟아져 나오는 수많은 MCP 서버 생태계를 그대로 활용하면서도, 그동안 MCP의 최대 약점으로 꼽히던 비효율적인 토큰 소모와 중간 데이터 병목을 사내 인프라 단에서 깔끔하게 걸러낼 수 있게 되었다.

기술 성숙도에 따른 도입 판단과 기업 실무 액션 플랜

MCP 프로토콜이 개발 도구 시장의 대세로 자리 잡은 것은 분명하지만, 이를 아무런 완충 장치 없이 현장에 직접 연결하는 것은 값비싼 토큰을 길바닥에 버리는 것과 같다. 엔지니어링 리더들은 자사 워크플로우의 복잡도와 예산 규모를 엄밀히 따져 도입 전략을 수립해야 한다.

지금 즉시 도입해야 할 기업 (Fit 조건 3가지)

• 도구 호출 대화가 하루 수백 건 이상 누적되는 엔지니어링 조직: 고가 LLM API 요금에서 순수 프롬프트 유지비가 차지하는 비중이 30%를 넘는다면, 도구 정의를 샌드박스 뒤로 숨기는 파이의 코드모드 아키텍처를 도입하는 즉시 가시적인 인프라 비용 절감 효과를 거둘 수 있다.
• 수 메가바이트 단위의 원시 데이터를 다루는 자동화 파이프라인: 웹 크롤링 데이터, 대용량 시스템 로그, 수천 줄의 코드베이스를 읽어 들여 분석해야 하는 팀은 중간 데이터가 모델의 컨텍스트 창을 경유하지 않는 구조를 필수적으로 확보해야 한다.
• 보안 감사 및 도구 실행 권한의 엄격한 분리가 필요한 엔터프라이즈: 깃허브나 데이터베이스 연동 시 쓰기 및 삭제 명령을 시스템 프롬프트 수준에서 원천 차단하고, 읽기 명령만 샌드박스로 선별 격리해야 하는 엄격한 사내 보안 가이드라인이 있는 조직에 최적이다.

도입을 보류하고 지켜봐야 할 기업 (Non-Fit 리스크 3가지)

• 에이전트에게 2–3개 수준의 단순한 단발성 도구만 쥐여주는 환경: 연동할 도구 수가 적고 각 도구의 명세서가 500토큰 미만인 단순 환경에서는 굳이 QuickJS 샌드박스를 세팅하고 자바스크립트 실행 환경을 유지하는 것이 오히려 오버엔지니어링이 된다.
• 초경량 소형 언어 모델(sLLM)을 사내 온프레미스로 돌리는 환경: 코드모드 방식은 모델이 필요에 따라 정확한 자바스크립트 호출 코드를 직접 작성할 수 있는 지능을 갖추고 있어야 한다. 코드 생성 능력이 떨어지는 매개변수 7B–14B 이하의 소형 모델을 쓸 경우 샌드박스 스크립트 작성 단계에서 문법 오류를 일으켜 전체 작업이 멈출 위험이 크다.
• Node.js 네이티브 모듈이나 C 기반 바이너리 직접 제어가 필수인 환경: 파이의 코드모드는 시스템 보안을 위해 노드 표준 라이브러리와 네이티브 바인딩을 의도적으로 제거했다. 호스트 환경의 특정 드라이버나 복잡한 시스템 레벨 명령을 직접 때려야 하는 하드웨어 제어 중심 프로젝트라면 기존의 단순 셸 스크립트 방식이 훨씬 안정적이다.