제14장 — 벤치마킹, 테스트, 성능

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 열다섯 번째이자 마지막 글입니다. 아키텍처가 마침내 감정 없는 질문에 답해야 합니다 — 시스템이 실제로 작동하는가? — 그 답은 실제 벤치마크, 두 가지 시스템적 실패 모드, 그리고 대부분의 팀이 프로덕션 출시일에 발견하는 10배 처리량 절벽을 통해 도착합니다.

이 장이 존재하는 이유

신중히 설계되고, 안전하게 하드닝되고, 프레임워크에 깔끔히 감싸진 프로토콜은 여전히 감정 없는 질문에 답해야 합니다. 시스템이 실제로 작동하는가? 에이전트는 그것이 지어진 작업을 푸는가? 부하가 두 배가 될 때 유지되는가? 우아한 저하를 정전으로 바꾸는 성능 절벽은 어디인가? 이전 장들은 아키텍처를 올바르게 만드는 일에 관한 것이었습니다. 이 장은 한 번 지어진 아키텍처가 전달하는지를 측정하는 일에 관한 것입니다. MCP-Universe 벤치마크 — 실제 LLM을 실제 MCP 서버에 대해 돌리는 첫 공개 테스트 하니스 — , 벤치마크가 드러낸 두 가지 시스템적 실패 모드와 작동하기 시작한 완화책, 그리고 잘 엔지니어링된 세션 풀과 순진한 요청당 패턴 사이의 격차가 자릿수 하나인 처리량 측면을 걸어 갑니다.

14.1 MCP-Universe: 실제 서버 위에서 에이전트 측정

2024년 대부분과 2025년 초까지 공개 에이전트 평가는 이상한 곳에 살았습니다. 도구 사용 벤치마크는 모델이 합성 API에 대해 구문적으로 올바른 호출을 내는지를 측정했습니다. 에이전트 벤치마크는 샌드박스 환경에서 작업 완료를 측정했습니다. 빠져 있던 것은 모델을 실제 MCP 서버에 대해 실제 인증, 실제 비율 제한, 실제로 표류하는 실제 스키마, 가끔 빈 결과를 반환하는 실제 도구와 함께 행사하는 벤치마크였습니다. Salesforce AI Research가 2025년에 출시한 MCP-Universe는 첫 진지한 시도였습니다. 11개 실제 프로덕션 MCP 서버 — Google Maps, GitHub, Yahoo Finance, Blender, Playwright, 실제 검색 엔진 — 에 걸친 6개 평가 도메인, 그리고 모델이 도중에 「올바른」 도구 호출을 냈는지가 아니라 최종 상태가 예상 결과와 맞는지를 자동 평가기가 확인하는 231개 작업.

헤드라인 결과는 모델 갱신에 걸쳐 유지되었습니다. 합성 벤치마크에서 80점대를 기록하는 Claude 3.5 Sonnet은 MCP-Universe 전체에서 40점대 초중반에만 도달했습니다. GPT-4o, Gemini 1.5 Pro, Llama-3 70B 변종은 비슷한 영역에 모였습니다. 폐쇄 코스 도구 사용 성능과 실제 MCP 성능의 격차는 약 40 절대점이었고, 스케일만으로는 닫히지 않았습니다. 실패는 인지 가능한 범주로 모입니다. 도구 출력이 윈도를 채우면서의 긴 컨텍스트 저하, 모델이 익숙하지 않은 스키마를 잘못 읽으면서의 미지 도구 탐색, 출력 형식이 어긋나고 의미적 다리가 없는 서버 간 조율, 그리고 모델이 알맞은 도구를 고르고, 올바르게 호출하고, 알맞은 답을 받지만 도구 출력을 더 넓은 추론에 통합하지 못해 잘못된 최종 결론에 도착하는 작업별 추론. MCP-Universe를 진지한 도구로 만드는 구조적 결정은 실행 기반 평가(참조 추적과 비교가 아니라 실제 서버에 대해 호출을 돌림), 실시간 데이터(라이브 시장 데이터, 평가기가 실행 시점의 답을 추적), 그리고 다중 턴 평가(각 단계가 아니라 최종 상태에 등급)입니다. 유용한 부작용: 벤치마크는 서버 설계에 대한 간접 품질 신호로 작동하며, 에이전트 성능에 관심 있는 서버 저자는 이제 공개 목표를 가집니다.

14.2 두 가지 시스템적 도전과 작동하는 것

긴 컨텍스트 저하와 미지 도구 탐색은 신중한 처우를 받을 만큼 큰 두 실패 모드입니다. 완화책이 비명백하기 때문입니다. MCP 에이전트에서 긴 컨텍스트 저하는 특정 모양을 가집니다. 컨텍스트가 어떤 의미에서 모두 관련 있는 — 각각이 모델이 내리기로 한 호출의 결과인 — 도구 출력으로 차지만, 각자가 부피가 크고 안에 실제로 부담을 지는 사실은 작습니다. 완화책은 정보 제시 수준에서 작동합니다. 도구 결과 요약은 결과가 에이전트의 컨텍스트에 떨어지기 전에 원시 도구 출력에 대해 저렴한 모델(Haiku, GPT-4o-mini, Gemini Flash)을 돌립니다. 프로덕션 배포는 긴 컨텍스트 완료율에서 2~3배 개선을 보고하며, 호출당 비용은 저렴한 모델이 지배합니다. JSON 페이로드 옆에 summary 필드가 있는 구조화된 도구 출력 — 2025년 프로토콜 개정에 형식화 — 은 추가 모델 호출 없이 비슷한 일을 합니다. 에이전트 루프에서의 컨텍스트 압축은 압축에서 그대로 살아남는 에이전트 관리 스크래치패드와 짝지어, 대화 자체가 너무 길게 자란 경우를 처리합니다. 프로덕션 배포는 20~40 단계마다 압축을 촉발하고 원래 컨텍스트의 약 3분의 1을 보존합니다.

미지 도구 탐색은 다른 모양을 가집니다. 에이전트가 학습되지 않은 도구를 가진 서버에 연결할 때 모델의 첫 호출은 자주 실패합니다 — 잘못된 타입, 잘못된 순서, 가끔 완전히 잘못된 도구. 완화책은 주 루프 전의 탐색 단계입니다. 프레임워크는 모델에게 각 도구의 기술을 읽고, 그것이 무엇을 하는지 요약하고, 예제 호출을 생성하고, 확신하지 못하는 파라미터를 표시하도록 요청합니다. 결과 노트가 에이전트의 컨텍스트에 앞당겨집니다. 비용은 세션 시작 시 몇 번의 저렴한 호출입니다. 이점은 MCP-Universe 같은 벤치마크에서 20~30 퍼센트포인트의 완료 개선과, 나중의 실패를 귀속시키는 데 도움이 되는 에이전트의 표명된 이해에 대한 감사 가능한 기록입니다. 패턴은 변경된 도구로 확장됩니다. 연결 시 도구 표면을 해시하고, 해시가 바뀔 때마다 워밍업을 돌리면, 조용한 표류 실패 모드(서버 갱신됨, 에이전트는 누군가 알아채기 전까지 수 주 실패)가 사라집니다. 이름 붙일 만한 세 번째 관련 문제: 도구 기술 품질. 많은 서버가 사람 개발자를 위해 쓰인 기술을 출하했습니다 — 간결하고, 전문 용어가 무거우며, 컨텍스트를 가정. 시스템을 본 적 없는 인턴을 위한 듯 다시 쓰인 서버는 에이전트 코드 변경 없이 같은 모델에 대해 측정 가능한 개선을 보입니다. 도구에 대한 모델의 유일한 창은 기술이며, 홀로 서지 않는 기술은 도구를 쓸 수 없는 모델을 만듭니다.

14.3 세션 풀 처리량 절벽

정확성은 이야기의 절반입니다. 프로덕션 현실은 에이전트를 빠르게 만드는 설계 선택이 자주 정확성 함의를 가지며 그 반대도 그렇다는 것입니다. 2025~2026 MCP 배포에서 단일 가장 큰 처리량 문제는 Streamable HTTP 세션을 관리하는 두 방식 사이의 격차이고, 격차는 약 10대 1입니다. 세션당 요청은 에이전트 요청당 새 세션을 열고, 그 안에서 도구 호출을 돌리고, 완료 시 닫습니다. 공유 세션 풀은 장수명 세션 풀을 유지하고 각 요청을 풀에서 하나에 할당합니다. 표준 서버에서 대표 워크로드에 대한 처리량 차이는 약 10배에 일관되게 착지합니다 — 상용 하드웨어에서 세션당 요청은 초당 약 30 요청, 풀은 초당 약 290~300 요청. 격차를 모르는 팀은 어렵게 발견합니다. 스테이징은 잘 돌고, 프로덕션 출시는 세션 생성 오버헤드가 지배하는 요청률에서 벽에 부딪힙니다.

메커니즘은 직설적입니다. 세션 생성은 비싸 — 상태 할당, 능력 협상, 자격 증명 검증, 정리 등록, 구조화된 로깅 — 며, MCP 수준 악수가 전송이 피할 수 없는 프로토콜 라운드트립을 더합니다. 세션당 요청은 매 단일 요청에서 이 비용을 지불합니다. 풀은 세션당 한 번 지불하고 분산합니다. 풀이 실제로 작동할지 결정하는 구현 세부 사항. 격리(요청당 상태는 세션 안의 하위 컨텍스트로 요청별로 만들어지고 파괴되며, 세션당 상태는 공유), 풀 크기(버스트를 위한 자동 확장과 함께 p95 동시 수), 건강 확인(유휴 세션에 대한 백그라운드 확인, 할당 시 빠른 확인), 그리고 상태가 여러 호출에 걸치는 도구를 위한 스티키 세션을 통한 요청 친화도. 그 위에 층진 HTTP/2 또는 HTTP/3 연결 다중화 — 많은 동시 스트림을 운반하는 하나의 기저 연결 — 가 인용된 처리량 숫자를 만듭니다. 단독 풀 층만으로는 훨씬 작은 개선을 만듭니다. 꼬리 지연 시간 차원도 중요합니다. 세션당 요청 서버는 생성 동안의 운 나쁜 순간에서 긴 꼬리 지연 시간을 가지고, 풀은 생성 비용이 요청 핫 경로에서 비동기이기에 꽉 조여진 것을 가집니다. P99는 일반적으로 3~4배 개선됩니다 — 처리량보다 큰 이득이고, 실제로 사용자 경험을 형성하는 이득입니다.

14.4 시리즈가 지은 것

네 권은 의도적 호를 걸어왔습니다. 제1권은 모델 안에 관한 것이었습니다. 제2권은 프롬프트와 추론에 관한 것이었습니다. 제3권은 검색 증강 생성에 관한 것이었습니다. 이 권은 에이전트와 도구에 관한 것이었으며, MCP를 중심으로 조직되었습니다. MCP가 에이전트 아키텍처를 일관되게 만든 기술적 기질이기 때문입니다. 그 안을 세 가닥이 흘렀습니다. 첫째는 인지와 운영의 분리입니다. 모델은 인지 층이고, 프레임워크와 MCP 서버는 운영 층이며, 대부분의 프로덕션 실패는 둘을 함께 무너뜨리는 데서 옵니다. 둘째는 유한 컨텍스트 예산입니다. 컨텍스트는 희소 자원이고, 신뢰성 있는 에이전트를 만드는 아키텍처적 선택은 이 희소성을 존중하는 선택입니다. 셋째는 경계로서의 프로토콜입니다. MCP는 단지 와이어 포맷이 아니라 능력이 흐르고, 신뢰가 협상되어야 하며, 미래 진화가 계속 일어날 경계입니다. 엔지니어링 압력 아래 유지되는 프로토콜은 인프라가 됩니다. MCP는 그렇게 하고 있는 듯합니다.

제4권이 준비하는 것

이것이 이 권의 마지막 장이므로 준비하는 것은 다음 장이 아니라 다음 권입니다. 제5권 — 실세계 LLM 애플리케이션 구축 — 은 제1권부터 제4권에 걸쳐 놓인 토대를 가져와 특정 애플리케이션 원형으로 조립합니다. 소프트웨어 엔지니어링을 위한 어시스턴트, 비즈니스 자동화를 위한 에이전트, 수직 애플리케이션 안의 코파일럿, 자율 연구 도구. 처우는 기저 메커니즘(이전 권이 다룬)보다 애플리케이션 수준 엔지니어링 선택에 관한 것이 될 것입니다 — LLM 애플리케이션의 범위를 신뢰성 있게 가치를 전달하도록 정하는 법, 프로덕션에서 평가하는 법, 애플리케이션이 진화하며 프롬프트·도구·메모리의 생명 주기를 관리하는 법. 제5권을 마친 독자는 단일 어텐션 헤드에서 실제 인프라 위의 실제 MCP 서버 스택에 대해 에이전트를 행사하는 배포된 애플리케이션까지의 길을 걸었을 것이며, 각 층이 왜 그렇게 지어졌는지 알 만한 엔지니어링 판단을 갖췄을 것입니다.

시리즈는 LLM Primer V — 실세계 LLM 애플리케이션 구축에서 이어집니다.