MCP 코드 모드 실험, 토큰 줄였지만 속도는 졌다

CI 인프라 기업 블랙스미스(Blacksmith)가 자사 코딩 에이전트 코드스미스([code]smith)를 만들며 겪은 실험 결과를 8월 24일 공개했다. MCP(Model Context Protocol) 도구를 JSON 스키마 대신 타입스크립트 코드로 노출하는 '코드 모드'가 이론상 유리한데도 첫 대결에서 기존 방식에 시간으로 밀렸다는 내용이다. 원인은 대부분의 MCP 서버가 '입력 형식'만 알려주고 '무엇을 돌려주는지'는 알려주지 않는다는 데 있었다.

무슨 일인가

전통적인 MCP 호출 방식에서는 에이전트가 도구별 JSON 정의를 통째로 컨텍스트에 실은 채, 호출하고 결과를 받고 다시 호출하는 반복을 거친다. 코드 모드는 같은 도구를 클래스와 메서드 형태로 보여주고, 에이전트가 필요한 도구만 검색해 스크립트 한 편을 짜서 샌드박스에서 실행하게 한다. 중간 결과는 샌드박스 안에서만 오가고 최종 요약만 모델로 돌아온다. 모델이 수십억 줄의 타입스크립트로 학습된 반면 도구 호출 형식은 비교적 새롭다는 점도 근거였다.

글쓴이 마크 헤더링턴(Mark Hetherington)은 리니어(Linear)에서 최근 수정된 열린 이슈 8개를 찾아 각각의 댓글 수와 최근 작성자를 보고하는 과제로 두 방식을 붙였다.

핵심 짚어보기

결과는 예상과 달랐다. 기존 방식은 77.5초, 6턴, 컨텍스트 10만 1,100토큰, 비용 2.01달러였다. 코드 모드는 116.6초, 8턴, 컨텍스트 6만 100토큰, 비용 1.91달러였다. 컨텍스트는 40% 가까이 줄고 비용도 소폭 낮았지만 시간은 절반 이상 더 걸렸다.

패인은 '반환 타입 미상(unknown)'이었다. 리니어 MCP 서버의 이슈 목록 도구는 입력 스키마만 제공하고 응답 구조는 알려주지 않는다. 기존 방식에서는 응답이 그대로 컨텍스트에 들어와 모델이 읽으면 그만이었지만, 코드 모드에서는 스크립트가 한 번도 본 적 없는 필드 이름을 미리 써야 한다. 모델은 응답 형태를 추측했고, 작성자는 틀리고 ID는 비어 나왔으며, 실제 필드를 알아내느라 스크립트 세 편을 더 썼다. 그 낭비 턴이 시간 차이를 만들었다.

그럼에도 컨텍스트 절감은 첫 턴부터 확인됐다. 기존 방식은 리니어 도구 스키마를 전부 실어 5만 2,800토큰에서 시작한 반면, 코드 모드는 실행 도구 하나로 감싸 4만 4,200토큰에서 출발했다. 시작만으로 9천 토큰이 절약된 셈이다. 글 제목이 말하는 '근육 기억'은 한 번 파악한 응답 구조를 다음번에 재사용하게 하는 개선으로 보인다.

1인기업 실전 적용 포인트

• 직접 MCP 서버를 만들고 있다면 입력 스키마와 함께 출력 스키마(outputSchema)나 응답 예시를 꼭 넣자. 에이전트가 첫 시도에 맞는 필드를 쓰면 턴 수가 줄고, 그게 곧 비용과 시간이다.
• 클로드 코드 같은 에이전트에 외부 API 연동을 시킬 때는 "먼저 샘플 응답 1건을 받아 구조를 확인한 뒤 스크립트를 작성하라"고 지시 순서를 정해 두면 이번 실험의 헛도는 턴을 미리 막을 수 있다.
• 도구가 수십 개 붙은 에이전트라면 코드 모드 계열(도구 검색 + 실행 샌드박스)로 컨텍스트 상한선을 낮추는 것이 장기적으로 유리하다. 단, 응답 구조 문서화가 안 된 서버부터 정리하는 것이 순서다.
• 벤치마크는 자기 과제로 직접 재현하자. 이번 결과도 "이슈 8개+댓글"이라는 특정 과제 기준이며, 과제가 길어질수록 컨텍스트 절감 효과가 시간 손실을 앞지를 가능성이 크다.

전망

MCP 생태계는 '무엇을 받는지'는 표준화했지만 '무엇을 돌려주는지'는 느슨하게 남겨 두었다. 코드 모드처럼 모델이 응답을 직접 읽지 않고 처리하는 방식이 퍼질수록 이 공백은 비용으로 되돌아온다. 앞으로 MCP 서버의 품질은 입력 스키마가 아니라 응답 계약이 얼마나 정확한지로 갈릴 것으로 보인다. 도구를 만드는 쪽도, 고르는 쪽도 이 기준을 체크리스트에 넣을 때다.

출처: 블랙스미스 블로그 (https://www.blacksmith.sh/blog/code-smith-code-mode)