MCP 코드 실행으로 에이전트 성능 폭발: 토큰·속도·보안까지
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구와 시스템에 “표준 방식”으로 연결되도록 만든 오픈 프로토콜입니다. 2024년 11월 이후 빠르게 확산되면서, 이제는 특정 벤더나 프레임워크에 묶이지 않고도 다양한 도구를 조합한 에이전트를 만들 수 있는 기반이 됐죠.1
그런데 MCP를 제대로 쓰다 보면 곧 한 가지 벽에 부딪힙니다. “도구가 많아질수록 모델이 느려지고 비싸진다”는 현실입니다. 오늘은 그 병목이 왜 생기는지, 그리고 MCP 서버를 ‘툴 호출’이 아니라 ‘코드 실행’ 관점으로 재구성하면 어떻게 토큰 효율, 응답 속도, 보안, 확장성까지 한 번에 끌어올릴 수 있는지 정리해보겠습니다.1
MCP란? 에이전트-도구 연결을 표준화한 ‘멀티 어댑터’
MCP를 한 문장으로 요약하면 “에이전트가 도구를 붙이는 방법을 표준 인터페이스로 통일한 것”입니다. 예전에는 슬랙, 지라, 구글 드라이브, 사내 DB 같은 도구를 연결할 때마다 에이전트마다 커스텀 통합을 해야 했습니다. 기능이 늘어날수록 연결 코드가 누더기가 되고, 다른 팀이 만든 도구를 재사용하기도 어려웠죠.
MCP가 등장하면서 상황이 바뀌었습니다. MCP 서버만 잘 만들어두면 에이전트는 같은 방식으로 다양한 도구를 호출할 수 있고, 개발자는 특정 도구의 연결 방식보다 “어떤 작업을 시킬지”에 집중할 수 있습니다. 그래서 지금은 수천 개의 MCP 서버와 여러 언어용 SDK가 빠르게 늘며, 사실상 “도구 생태계의 공용 규격” 같은 위치를 차지하고 있습니다.1
도구가 많아질수록 토큰이 새는 이유: 정의 + 중간결과의 폭주
MCP가 표준이 됐다고 해서 성능 문제가 저절로 해결되진 않습니다. 오히려 잘 나가는 에이전트일수록 이런 경험을 합니다.
첫째, “도구 정의”가 컨텍스트를 잡아먹습니다. 에이전트가 사용할 수 있는 툴이 수백 개가 되면, 모델이 의사결정을 하기 위해 각 툴의 설명(스키마, 파라미터, 예시 등)을 컨텍스트에 올려야 합니다. 이걸 무작정 전부 로드하면 컨텍스트 창이 도구 설명으로 가득 차고, 정작 사용자의 문제를 풀 공간이 줄어듭니다.1
둘째, “중간 결과”가 컨텍스트를 터뜨립니다. 예를 들어 2시간짜리 회의록, 대형 로그, 긴 문서 같은 결과물을 툴이 반환하면, 그 덩어리가 계속 모델로 전달되면서 토큰이 기하급수로 늘어납니다. 특히 반복적인 작업 흐름(검색→요약→추출→검증)을 돌리면 결과가 매 단계마다 누적되어 속도와 비용이 같이 치솟죠.1
결국 “도구가 많고, 데이터가 크고, 단계가 길수록” MCP 에이전트는 도구 확장성은 얻는 대신 토큰 효율을 잃기 쉬운 구조를 갖습니다.
해결의 핵심: MCP를 ‘툴 목록’이 아닌 ‘코드 API’로 다루기
여기서 접근을 바꾸면 길이 보입니다. 도구를 모델 컨텍스트에 한꺼번에 들이붓는 대신, MCP 서버를 코드에서 호출 가능한 API로 취급하고, 에이전트가 코드 실행 환경에서 필요한 것만 골라 쓰는 방식입니다.1
이 구조에서 모델은 “무슨 작업을 할지”와 “어떤 전략으로 코드를 실행할지”에 집중합니다. 그리고 실제 데이터 처리(필터링, 정렬, 집계, 변환)나 도구 선택은 코드가 맡습니다.
쉽게 말해, 모델에게는 ‘결정’만 맡기고, ‘노가다’는 코드가 하는 형태입니다. 이때 가장 큰 이득이 두 가지로 터집니다.
첫째, 필요한 도구만 선택 로드가 가능합니다. 파일 시스템 탐색처럼 “도구 카탈로그”를 코드에서 찾아서 정말 필요한 정의만 올리면, 컨텍스트가 도구 설명으로 잠식되는 일을 크게 줄일 수 있습니다. 실제로 전체 도구 정의를 미리 넣는 방식 대비 토큰 사용량이 극적으로 감소(예: 15만 토큰 수준 → 2천 토큰 수준)하는 사례가 소개됩니다.1
둘째, 중간 결과를 모델에 계속 들이밀지 않아도 됩니다. 큰 데이터는 코드 실행 환경에서 요약·필터링·집계한 뒤, 모델에는 “결론에 필요한 최소 정보”만 전달하면 됩니다. 모델 컨텍스트는 얇아지고, 응답은 빨라지며, 비용도 예측 가능해집니다.1
코드 실행이 주는 성능 이점: 반복문·조건문이 ‘툴콜 지옥’을 끝낸다
툴 호출 방식으로 복잡한 작업을 만들면 종종 이런 상황이 벌어집니다. “이 결과가 만족스러우면 다음 단계, 아니면 다시 검색” 같은 흐름이 필요한데, 모델이 매번 판단하고 매번 툴을 부르다 보니 호출 횟수가 늘고 컨텍스트가 불어납니다. 일종의 툴콜 지옥이죠.
코드 실행 기반이면 이 흐름을 훨씬 자연스럽게 바꿀 수 있습니다. 반복문, 조건문, 예외 처리, 캐싱 같은 기본 제어 흐름을 코드가 담당하고, 모델은 중간중간 중요한 선택만 합니다. 체감 성능이 좋아지는 이유는 단순합니다. “긴 대화”로 돌던 것을 “짧은 실행”으로 바꾸기 때문입니다.1
또 하나의 장점은 장기적으로 에이전트가 똑똑해진다는 점입니다. 잘 만든 처리 코드를 파일로 저장해두면, 다음 작업에서 재사용할 수 있습니다. 즉, 일회성 프롬프트가 아니라 반복 가능한 스킬(작업 코드)이 축적되면서 에이전트의 역량이 쌓입니다.1
보안과 개인정보(PII): 민감 데이터는 모델에 안 올리는 게 정답
현업에서 진짜 골치 아픈 건 성능보다 보안일 때가 많습니다. 고객 정보, 계정 식별자, 내부 문서 같은 민감 데이터가 모델 컨텍스트로 들어가는 순간, 관리 포인트가 급격히 늘어나죠.
코드 실행 방식은 이 지점을 정면으로 해결합니다. 중간 결과와 민감 데이터는 코드 실행 환경(클라이언트 측)에서 처리하고, 모델에는 필요한 “요약/집계”만 전달합니다. 더 나아가 MCP 클라이언트 레벨에서 토큰화·복호화를 활용해, 모델이 원문 데이터를 보지 않고도 작업을 진행하도록 설계할 수도 있습니다.1
정리하면, “모델은 최소 정보만 받는다”를 아키텍처 수준에서 강제하기 쉬워집니다. 이건 보안 감사나 컴플라이언스 대응에서도 큰 차이를 만듭니다.
단점도 있다: 코드 실행은 ‘인프라 숙제’를 함께 가져온다
물론 공짜 점심은 없습니다. 코드 실행 기반은 성능과 보안에서 강력하지만, 그만큼 운영 책임도 커집니다.
코드를 안전하게 실행하려면 샌드박싱, 권한 통제, 리소스 제한(CPU/메모리/시간), 모니터링, 로깅, 이상 행동 탐지 같은 인프라 요소가 필요합니다. 쉽게 말해 “툴콜만 하던 시절”에는 모델이 대신 떠안던 복잡성을, 이제는 플랫폼이 직접 관리해야 합니다.1
그래서 선택 기준은 명확합니다. 도구 수가 많고 데이터가 크며 장기 작업이 잦은 에이전트라면 코드 실행 패턴의 이득이 크고, 단순한 자동화나 도구 수가 적은 작업은 기존 방식이 더 가벼울 수 있습니다.
시사점: MCP 시대의 에이전트, ‘컨텍스트’보다 ‘실행’에 투자하자
MCP 덕분에 에이전트는 수백~수천 개 도구를 연결할 수 있는 시대가 됐습니다. 하지만 연결이 쉬워질수록, 컨텍스트 창은 도구 정의와 중간 결과로 비대해지기 쉽습니다.
해답은 의외로 단순합니다. “모델이 모든 걸 들고 생각하게” 만들지 말고, “코드가 들고 처리하게” 만들면 됩니다. 필요한 도구만 선택적으로 불러오고, 큰 데이터는 코드에서 정리해 요점만 모델에 전달하세요. 그러면 토큰 효율, 속도, 보안, 확장성이라는 네 마리 토끼를 동시에 잡을 수 있습니다.1
개인적으로는 팀 안에서 작은 실험부터 시작해보길 권합니다. 가장 토큰을 많이 먹는 작업 한 가지를 골라 “중간 결과를 모델에 넘기지 말고 코드에서 처리”하도록 바꿔보세요. 성능 차이가 눈에 보이면, 그 다음부터는 패턴이 됩니다. 그리고 그 경험을 MCP 커뮤니티에 공유하면, 생태계 전체의 베스트 프랙티스가 더 빨리 성숙할 겁니다.1