목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 11월 4일 게재된 “Code execution with MCP: Building more efficient agents” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/code-execution-with-mcp
한 줄로 말하면 #
도구를 LLM이 직접 호출하지 말고, 코드를 짜게 해서 코드가 호출하게 하니 토큰이 98.7% 줄었다.
어떤 문제를 해결하려 했나 #
구체적인 시나리오 하나가 모든 걸 설명합니다.
“Google Drive에서 회의록 받아서 Salesforce에 고객 기록 업데이트해줘.”
이걸 전통 MCP 방식으로 하면 어떻게 될까요?
- 모든 MCP 도구 정의(수백 개)를 시작부터 컨텍스트에 로드
- Google Drive에서 회의록 본문(예: 2시간짜리 5만 토큰) 가져옴 → 컨텍스트에 들어감
- 에이전트가 본문을 보고 요약 → 컨텍스트에 다시 들어감
- Salesforce 호출 파라미터 만들기 → 컨텍스트에 또…
회의 한 건에 15만 토큰이 쉽게 소비됩니다. 큰 자료가 컨텍스트를 여러 번 통과하기 때문이에요.
해결책: 코드 실행 모델 #
1. 도구를 ‘API’가 아니라 ‘파일시스템’으로 본다 #
MCP 서버를 직접 호출 가능한 도구로 노출하는 대신, 타입스크립트/파이썬 파일이 든 폴더 로 노출합니다.
servers/
├── google-drive/
│ └── getDocument.ts
├── salesforce/
│ └── updateRecord.ts
└── other-server/
└── ...에이전트는 필요한 도구 파일만 파일시스템 탐색으로 찾아 로드합니다. 시작부터 수백 개 정의를 다 안고 있을 필요가 없어요.
2. 에이전트가 코드를 짠다 #
핵심 발상의 전환. 에이전트가 도구를 직접 호출하는 대신, 코드를 짜고 그 코드가 도구를 호출합니다.
// 에이전트가 작성한 코드 (샌드박스에서 실행)
const doc = await googleDrive.getDocument({ id: "..." });
const summary = doc.transcript
.split('\n')
.filter(line => line.includes('action item'))
.join('\n');
await salesforce.updateRecord({ id: "...", notes: summary });회의록 5만 토큰이 컨텍스트를 통과하지 않습니다. 샌드박스 안에서 처리되고, 에이전트는 로그·반환값만 봅니다.
3. Before / After 토큰 사용량 #
[Before — 직접 도구 호출]
모든 도구 정의 로드 + 큰 데이터 컨텍스트 통과
→ 150,000 토큰
[After — 코드 실행]
필요한 도구만 로드 + 데이터는 샌드박스에서 처리
→ 2,000 토큰 (98.7% 감소)결과 / 효과 #
- 토큰 절감: 150,000 → 2,000 (예시 시나리오, 약 98.7% 감소)
- 점진적 공개: 도구 정의를 필요할 때만 로드
- 제어 흐름 효율: 반복·조건·에러 처리를 코드로 → “첫 토큰까지의 지연” 감소
- 데이터 프라이버시: 중간 결과가 모델 컨텍스트로 들어가지 않음 (명시적으로 log/return한 것만 노출)
- 상태 지속성: 중간 결과를 파일로 기록 → 재개 가능
- 재사용 가능 스킬: 잘 동작한 코드를 함수로 저장해 다음에 재활용
트레이드오프 #
좋기만 한 건 아닙니다.
- 샌드박스 환경 필요 (보안 격리, 자원 한도, 모니터링)
- 인프라 복잡도 증가 — 직접 도구 호출보다 셋업 부담 큼
- 조직 규모와 시나리오에 따라 비용-효과 판단 필요
핵심 결론 #
LLM 비용·지연 문제를 풀려고 할 때 사람들은 “모델 작은 걸 쓰자” 또는 “프롬프트 압축하자"를 떠올립니다. 이 글의 답은 다릅니다.
“비용 문제가 모델인 줄 알았는데, 사실은 큰 데이터가 컨텍스트를 여러 번 통과하는 구조가 문제였다.”
도구 호출을 코드로 감싸면, 데이터는 샌드박스에 머물고 결과만 LLM에 돌아옵니다. 토큰 두 자릿수 배 차이가 여기서 나옵니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
데이터 분석에서 가장 흔한 토큰 낭비는 “큰 데이터셋 전체를 LLM에 보여주기” 입니다.
[Before — 모두 컨텍스트로]
"CSV 100MB 분석해줘" → 전체를 LLM 컨텍스트에 붙이기
→ 토큰 폭발, 분석 흐트러짐
[code execution 패턴 적용]
[데이터는 코드 환경에]
- 원본 CSV는 파일시스템에 둠
- LLM은 스키마·기본 통계만 봄
[LLM이 코드 짜기]
- pandas/SQL 쿼리 생성 → 샌드박스 실행
- 결과(요약 통계, 이상치 목록 등)만 LLM에 반환
[중간 결과는 파일]
- 분석 단계별 결과를 파일로 저장 → 누적핵심: “데이터는 데이터답게 보관하고, LLM에는 결과 요약만” 이라는 분리가 토큰과 분석 품질을 동시에 살립니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화도 마찬가지입니다. 로그·메트릭·콘텐츠 전체를 LLM이 직접 볼 필요가 없어요.
[Before — 모든 데이터 컨텍스트로]
"오늘 로그 분석하고 이상 있으면 알려줘"
→ 로그 전체를 LLM 컨텍스트에 (GB급)
→ 분석 불가능
[code execution 패턴 적용]
[로그·메트릭은 파일/DB에]
- LLM은 인덱스·요약만 봄
[LLM이 쿼리 코드 짜기]
- grep/awk/SQL 쿼리 생성 → 샌드박스 실행
- "에러 빈도 상승 구간 + 패턴 5개" 같은 요약만 반환
[운영 동작도 코드로]
- 배포·롤백·알림을 코드로 실행
- LLM은 결과(성공/실패, 영향 범위)만 받음핵심: 운영 자동화의 효율은 “LLM이 직접 손대지 않고, 코드를 짜게 한다” 는 분리로 결정됩니다. 큰 데이터는 코드 환경에 머무르게 두세요.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
