Claude MCP as Code로 컨텍스트 부담 줄이고 토큰 절약하기?

Claude와 MCP를 쓰다 보면, 어느 순간부터 대화 내용보다 도구 정의가 더 많은 토큰을 차지하고 있다는 느낌이 들 때가 있습니다. Anthropic가 최근 논문에서 이 문제를 공식적으로 짚었고, 이를 해결하기 위한 MCP as Code라는 방식까지 제안했습니다.

아래에서는 기존 MCP가 왜 점점 부담이 되는지, Anthropic이 제시한 새로운 접근이 무엇인지, 실제로 어떤 이점과 한계를 가지는지까지 한 번에 정리합니다.

MCP가 컨텍스트 창을 갉아먹는 구조적 문제

MCP를 몇 개만 연결해도, 작업을 시작하기도 전에 전체 컨텍스트 창의 상당 부분이 이미 소모되는 경우가 많습니다. 이유는 단순합니다. MCP 툴 정의와 툴 호출 결과가 모두 컨텍스트에 그대로 남기 때문입니다.

일반적인 MCP 사용 흐름에서는:

• 각 MCP 서버가 여러 개의 툴 정의를 노출하고

• 이 정의들이 사용 여부와 상관없이 컨텍스트에 포함되며

• 툴을 한 번 호출하면, 그 결과까지 이후 대화 내내 계속 쌓입니다.

영상 속 예시처럼, 메시지는 0%만 차지해도 MCP 세 개만 붙여도 컨텍스트의 약 10%가 이미 툴 정의에 의해 점유됩니다. MCP 수가 늘어날수록 이 비율은 기하급수적으로 올라가고, 실제로 중요한 사용자 메시지나 작업 맥락이 들어갈 공간이 줄어듭니다.

여기에 더해, MCP 호출 결과도 모두 컨텍스트에 남습니다. 특히 데이터 도구(Google Sheets, DB, 파일 시스템 등)를 다루면, 툴 호출 한 번으로 수천 행, 수만 토큰이 통째로 들어오는 상황이 쉽게 발생합니다.

이렇게 되면:

• 모델은 불필요한 정보 속에서 필요한 부분을 찾기 더 어려워지고

• 비용은 늘고

• 긴 세션일수록 품질이 점점 떨어지는 현상이 나타납니다.

Anthropic는 이 문제를 "툴 정의와 결과가 컨텍스트 창을 과부하시킨다"는 표현으로 정리하고, 아예 구조를 바꾸는 방향을 제안했습니다.

MCP를 코드로 감싸기: MCP 서버를 도구가 아닌 API로 취급

Anthropic의 핵심 제안은 간단합니다. "MCP 서버를 직접 컨텍스트에 올리지 말고, 코드로 래핑해서 백엔드 API처럼 쓰자"는 것입니다.

기존 방식에서는:

• MCP 서버가 하나의 "툴 세트"처럼 모델에 바로 노출되고

• 모든 툴 정의가 시스템 메시지 형태로 컨텍스트에 들어갑니다.

새로운 방식(MCP as Code)에서는:

• MCP 서버와의 상호작용을 TypeScript 같은 코드 파일로 추상화하고

• 모델은 이 코드 파일을 읽고, 필요한 부분만 불러와 사용하는 형태로 바꿉니다.

구체적으로는:

• 프로젝트에 servers 폴더를 만들고

• 각각의 MCP 서버를 하나의 하위 폴더로 두고

• 폴더 안에 툴별 코드 파일과, 전체 툴 목록과 시그니처를 정리한 index.ts 파일을 둡니다.

모델은 MCP 도구 정의 전체를 컨텍스트에 올리는 대신,

• 파일 시스템 내에서 어떤 도구가 있는지를 index.ts로 파악하고

• 실제 호출 시점에 해당 툴 코드 파일만 부분적으로 컨텍스트에 로딩합니다.

Cloudflare는 이런 아이디어를 "code mode"라는 이름으로 먼저 소개하며, 모든 MCP 도구를 TypeScript API로 감싸고 LLM이 그 위에 코드를 쓰도록 하자는 제안을 하기도 했습니다. Anthropic의 MCP as Code는 같은 흐름 위에서, Claude 에이전트 사용 경험에 맞게 정리한 버전에 가깝습니다.

파일 구조 기반의 점진적 정보 노출: 필요한 것만 보여주기

Anthropic가 첫 번째 장점으로 제시한 것은 점진적 노출(progressive disclosure)입니다. 핵심은 "한 번에 다 보여주지 말고, 필요할 때 조금씩 보여주자"입니다.

MCP as Code 구조에서는:

• 각 MCP는 하나의 폴더로 표현되고

• 폴더 안에 툴별 파일이 각각 존재하며

• index.ts가 "어떤 툴이 있고, 어떤 역할을 하는지"를 정리한 가이드 파일 역할을 합니다.

Claude는:

1. 먼저 index.ts만 읽어

   • 어떤 툴들이 있는지

   • 어떤 인자를 받는지

   • 어떤 용도로 쓰이는지 개략적으로 파악하고

2. 실제로 특정 툴이 필요하다고 판단되면

   • 그때 해당 툴의 코드 파일을 불러와

   • 정의와 구현 세부 내용을 컨텍스트에 올립니다.

이 방식의 장점은 명확합니다. "모든 MCP 툴 정의를 한 번에 컨텍스트 창에 올리지 않아도 된다"는 점입니다.

이로 인해:

• 컨텍스트 창에서 정의가 차지하는 비중이 크게 줄고

• 길고 복잡한 프로젝트에서도 실제 작업 내용이 더 많은 비중을 차지할 수 있습니다.

툴 결과 요약·가공으로 컨텍스트 효율 극대화

두 번째 장점은 툴 결과를 컨텍스트 효율적으로 다룰 수 있다는 점입니다.

기존 MCP 방식에서는:

• 툴을 호출하면, 그 결과가 거의 그대로 컨텍스트에 다시 들어옵니다.

• 예를 들어, Google Sheets MCP가 10,000행을 반환하면, 그 10,000행이 고스란히 토큰으로 소비됩니다.

MCP as Code에서는 툴 호출과 결과 처리가 코드 레벨에서 이뤄지기 때문에, 중간에 원하는 형태로 데이터를 가공한 뒤, 정말 필요한 일부만 모델에 노출할 수 있습니다.

예를 들면:

• 시트 전체가 아니라 처음 5행만 전달해 데이터 구조를 파악하게 하거나

• 통계치를 미리 계산해 합계, 평균, 최대·최소 값만 모델에 넘기거나

• 검색 결과 중 상위 N개만 요약해서 전달하는 것도 가능합니다.

이렇게 하면:

• 토큰 사용량이 크게 줄어들고

• 모델은 핵심 정보만 보고 판단할 수 있어, 작업 품질도 향상될 가능성이 큽니다.

핵심 포인트는 "툴 결과를 그대로 노출하는 대신, 코드에서 한 번 걸러서 넘긴다"는 구조입니다.

코드 기반 제어 흐름: 순차 호출과 환각 줄이기

세 번째 장점은 제어 흐름을 모델이 아닌 코드가 담당한다는 점입니다.

기존 MCP 사용 패턴에서는:

• 모델이 어떤 툴을 언제 호출할지 스스로 결정하고

• 각 툴 호출이 순차적으로 이어지는 체인을 형성합니다.

• 이 과정에서 툴 선택을 잘못하거나, 불필요하게 여러 번 호출하는 환각(hallucination)성 도구 사용이 발생하기 쉽습니다.

반면 MCP as Code에서는:

• if, switch, loop 같은 일반 프로그래밍 제어 구조를 활용해

• "어떤 조건에서 어떤 툴을 몇 번 호출할지"를 코드에 명시할 수 있습니다.

그 결과:

• 모델은 "로직을 발명하는 역할"보다는 이미 존재하는 로직을 활용하는 역할에 집중하게 되고

• 호출 순서, 분기, 재시도 조건 등을 코드가 관리하면서

• 불필요한 도구 호출과 토큰 낭비를 줄이는 효과가 나타납니다.

즉, 툴 체이닝의 책임을 모델에서 코드로 옮겨 예측 가능한 실행 흐름을 확보하는 방식입니다.

프라이버시 보호: 민감 데이터는 코드 안에 가두기

데이터 프라이버시가 중요한 환경에서는, 모델이 내부 DB나 로그 전체를 보는 것이 큰 리스크가 됩니다. MCP as Code는 이 부분에서도 이점을 제공합니다.

이 방식에서는:

• 모델은 코드가 반환하거나 로그로 출력한 정보만 볼 수 있습니다.

• 실제 DB 쿼리, 인증 정보, 민감 필드는 코드 내부에서만 처리되고, 컨텍스트로 노출되지 않습니다.

예를 들어:

• DB 쿼리 결과 전체 대신,

  • "레코드 개수: 152개"

  • "최근 수정일: 2025-11-20" 정도만 모델에 전달하도록 코드를 설계할 수 있습니다.

또는:

• 사용자 실명/이메일을 실제 값 대신 마스킹된 토큰으로 바꿔서 넘기고

• 모델은 그 토큰 단위로만 사고를 진행하게 만들 수 있습니다.

이렇게 하면:

• 모델이 민감 정보를 직접 보지 않고도

• 필요한 업무 로직(집계, 필터링, 알림 생성 등)을 수행할 수 있습니다.

핵심은 "모델이 접근 가능한 데이터 범위를 코드 설계 단계에서 강하게 통제할 수 있다"는 점입니다.

상태 유지와 '스킬' 축적: 에이전트가 학습 가능한 작업 환경

마지막 장점으로 Anthropic가 강조하는 부분은 상태(state) 유지와 재사용 가능한 스킬(skill) 축적입니다.

MCP as Code는:

• 파일 시스템 기반 구조를 사용하고

• 에이전트가 메모리 도구를 통해 코드와 중간 결과를 파일로 저장할 수 있도록 가정합니다.

이렇게 하면:

• 한 번 잘 작동한 MCP 연동 코드 조각을 그대로 파일로 남겨두고

• 이후 유사한 작업에서 재사용할 수 있습니다.

Anthropic는 이를 기존의 Claude Skills와 연결해서 설명합니다.

• Skills는 skill.md 같은 문서와 여러 리소스를 포함한 넓은 개념의 능력 묶음이고

• MCP as Code는 MCP 서버 도구를 실행 가능한 코드로 감싸는 데 초점을 둔 구조입니다.

두 접근을 결합하면 다음과 같은 흐름이 가능합니다.

1. 에이전트가 MCP를 활용하는 코드를 작성해 작업을 성공적으로 수행한다.

2. 이 코드를 파일로 저장하고, 어떻게 쓰는지 skill 파일로 문서화한다.

3. 이후 비슷한 요청이 들어오면, 에이전트는 기존 스킬을 참고해 처음부터 다시 고민할 필요 없이 빠르게 활용한다.

이렇게 프로젝트가 진행될수록 "에이전트 전용 내부 라이브러리"가 쌓이는 효과를 기대할 수 있습니다.

MCP as Code의 현실적 한계와 고려해야 할 선택지

한편, Anthropic도 이 방식이 만능은 아니라는 점을 분명히 짚습니다. 가장 큰 현실적인 제약은 "에이전트가 생성한 코드를 실제로 실행하기 위한 인프라"입니다.

MCP as Code를 제대로 활용하려면:

• 코드 실행을 위한 안전한 샌드박스 환경

• 리소스 사용량을 모니터링하고 제어할 수 있는 실행 관리 시스템

• 악성 코드나 의도치 않은 외부 호출을 막기 위한 보안 장치가 필요합니다.

즉, 토큰 비용과 모델 호출 횟수는 줄어들 수 있지만:

• 인프라 설계·운영 복잡도는 증가합니다.

• 특히 에이전트가 쓴 코드를 곧바로 실행하는 구조에서는,

  • 파일 시스템 접근 범위

  • 네트워크 호출 제한

  • 시간·메모리 리밋 같은 세밀한 통제가 필수입니다.

또 하나의 현실적인 제약은 개발 역량 요구 수준입니다.

• 기존 MCP 방식은 "툴을 연결해두면 모델이 알아서 써준다"는 느낌에 가까웠다면

• MCP as Code는 툴을 사용하기 전에 먼저 API 래퍼를 설계하고 코드 구조를 잡는 작업이 필요합니다.

소규모 팀이나 비개발자 중심 환경에서는:

• 컨텍스트 비용이 조금 늘어나더라도

• 인프라를 단순하게 유지하는 편이 더 현실적일 수 있습니다.

결국 Anthropic가 제시한 MCP as Code는 "토큰 비용 vs 인프라 복잡도" 사이에서 어느 쪽을 선택할지 고민하게 만드는 제안에 가깝습니다.

프롬프트 엔지니어링만으로 해결하기 어려운 컨텍스트 창 한계를, 소프트웨어 공학에서 오래 써오던 방식(코드 모듈화, API 래핑, 제어 흐름 분리)을 AI 에이전트 세계에 그대로 가져온 시도라고 볼 수 있습니다.

마무리하자면, MCP as Code는 대규모 에이전트 시스템에서 특히 의미가 큽니다. MCP가 많아질수록, 컨텍스트 창은 언젠가 병목이 되고, 이 지점에서 "코드로 빼서 다루자"는 발상은 자연스러운 다음 단계에 가깝습니다.

다만, 실제 도입을 고민한다면:

• 예상되는 토큰 사용량

• 에이전트가 사용할 MCP 종류와 개수

• 팀의 인프라·보안 설계 역량

이 세 가지를 기준으로 "지금은 단순 MCP로 충분한가, 아니면 MCP as Code로 넘어갈 시점인가"를 냉정하게 판단하는 과정이 필요해 보입니다.

출처 및 참고 :