에이전트 AI - Opik, MCP 서버 최적화

https://www.comet.com/site/blog/mcp-performance-optimization/

2026.7.15
[How We Optimized Opik’s MCP Server for Cost & Performance]

이 글은 Opik 팀이 모델 컨텍스트 프로토콜(MCP) 서버를 최적화하여 AI의 운영 비용을 절감하고 성능을 향상시킨 기술적 여정을 상세히 설명합니다. 기존의 REST 방식처럼 모든 기능을 개별 도구로 나열하는 대신, 개발진은 추상화된 네 가지 핵심 도구로 시스템을 재구축함으로써 불필요한 토큰 소비와 모델의 혼란을 획기적으로 줄였습니다. 특히 동적 스키마 제공을 통한 자가 치유 설계와 데이터 출력의 지능적인 크기 조정은 인공지능이 제한된 컨텍스트 안에서 더욱 효율적으로 사고할 수 있게 돕습니다. 결과적으로 이 텍스트는 복잡한 API 구조를 모델 친화적인 고수준 인터페이스로 전환하는 것이 현대적 AI 에이전트 설계의 핵심임을 강조합니다.

 

MCP 서버 최적화 설계 가이드라인: 성능과 비용 효율을 위한 아키텍처 전략

 

1. 서론: REST의 한계와 LLM 중심 설계로의 전환

현대적인 AI 애플리케이션 아키텍처를 설계할 때, 엔지니어들이 범하는 가장 흔한 실수는 기존의 REST API 원칙을 MCP(Model Context Protocol) 서버에 그대로 투영하는 것입니다. 각 엔드포인트마다 하나의 독립된 도구를 할당하는 'REST 미러링' 방식은 현대 LLM 아키텍처에서 성능 저하와 비용 상승을 초래하는 핵심 요인입니다.

'REST 미러링'의 비판적 분석: 도구 비대화와 인지 부하

전형적인 MCP 서버는 수십 개의 엔드포인트를 노출하여 도구 목록을 비대하게 만듭니다. 이는 다음과 같은 심각한 아키텍처적 결함을 발생시킵니다.

1. 컨텍스트 윈도우 점유(Token Tax): 도구 목록은 모든 요청의 컨텍스트 윈도우에 상주합니다. Anthropic의 도구 선택 가이드라인과 MCPToolBench++ 논문(arXiv:2508.07575)에 따르면, 도구 정의(이름, 설명, 스키마)가 많아질수록 모델의 추론 정확도는 반비례하여 하락합니다. 프롬프트 캐싱(Prompt Caching)이 비용은 낮출 수 있으나, 컨텍스트의 물리적 크기 자체를 줄이지는 못하므로 모델이 실제 논리적 추론에 사용할 수 있는 가용 공간이 잠식됩니다.
2. 도구 선택 오류의 기하급수적 증가: 유사한 기능을 가진 수십 개의 도구가 나열될 경우, 모델은 모든 액션마다 전체 메뉴를 검토해야 합니다. 이는 마치 "매번 에스프레소만 주문하는 손님에게, 주문을 받기 전 30가지의 전체 메뉴를 처음부터 끝까지 읊어주는 웨이터"와 같습니다. 실제로 GitHub의 공식 MCP 서버가 너무 많은 도구를 제공한 나머지 --toolsets 플래그를 통해 그룹별로 기능을 꺼야만 했던 사례는 REST 미러링 방식의 한계를 극복해야 할 반면교사입니다.

이러한 구조적 비효율을 해결하기 위해서는 모델의 인지 부하를 최소화하고 토큰 효율을 극대화하는 '추상화 레이어'로의 전환이 필수적입니다.

 

2. 전략 1: 4가지 범용 도구 중심의 추상화 (Universal Abstraction)

수십 개의 도구를 단 4개의 범용 인터페이스로 압축하는 것은 확장성과 모델 추론 효율을 동시에 잡는 전략적 선택입니다. 복잡한 플랫폼 기능을 엔티티(Entity) 기반의 매개변수 구조로 단순화하여 모델이 학습해야 할 인터페이스의 가짓수를 최소화합니다.

4대 핵심 도구 정의: 온디맨드 스키마와 레이지 로딩

모든 데이터 관리 기능을 다음의 4가지 도구로 통합하며, 특히 schema 도구는 토큰 세금을 획기적으로 줄이는 '레이지 로딩(Lazy-loading)' 메커니즘을 수행합니다.

도구 이름	역할	전략적 메커니즘
list	컬렉션 탐색	특정 엔티티 목록 조회, 이름 필터링 및 페이지네이션 수행
read	상세 정보 추출	엔티티와 ID를 기반으로 특정 레코드의 전체 데이터 호출
write	작업 실행	entity.action 쌍(Closed Enum)을 통해 모든 변경 작업 수행
schema	구조 정보 제공	핵심 전략: 특정 작업에 필요한 스키마를 모델이 요청할 때만 제공하여 초기 컨텍스트 점유 최소화

 

엔티티 레지스트리와 Closed Enum 활용

작업을 trace.create, experiment.update와 같은 entity.action 쌍의 레지스트리로 관리합니다. 모델은 최상위 도구가 아닌 매개변수 수준의 'Closed Enum(폐쇄형 열거형)' 신호를 통해 기능을 파악합니다. 이는 새로운 엔티티가 추가되어도 도구 목록(Context Window)의 크기가 변하지 않는 선형적 확장성을 보장합니다.

비교 항목	전통적인 REST 미러링 방식	4대 범용 도구 방식
컨텍스트 점유율	도구 추가 시 기하급수적 증가	엔티티 증가와 무관하게 고정 유지
확장 방식	신규 엔드포인트마다 신규 도구 정의	레지스트리에 Enum 값만 추가
인지 부하	수십 개의 복잡한 스키마 상시 대기	필요 시 schema 도구로 온디맨드 조회

 

 

3. 전략 2: 자가 치유(Self-healing) 설계 및 인터페이스 가이드

높은 수준의 추상화 인터페이스에서는 모델이 필드명이나 작업을 잘못 추측할 리스크가 존재합니다. 그러나 LLM 아키텍처에서는 완벽한 사전 예방(Prevention)보다 신속하고 정확한 복구(Recovery)가 훨씬 경제적이고 효율적입니다.

 

교육적 인터페이스: 거부(Rejection)를 통한 가이드

전통적인 방어적 프로그래밍이 오류를 차단하는 데 집중한다면, LLM 인터페이스는 오류 메시지를 통해 모델을 '교육'해야 합니다. 모든 것을 사전에 설명하기 위해 수천 토큰을 소비하는 것보다, 필요할 때 단 한 번의 에러 메시지로 교정하는 것이 비용 효율적입니다.

 

[Case Study: 실제 자가 치유 교환 사례]

Model: read(entity="trace", id="...")를 시도하며 필드명을 trace_id로 추측함. Server:

Model (Next Turn): 즉시 read(entity="trace", id="...")로 수정하여 호출 성공.

이처럼 인터페이스가 모델을 가르치는 '브레드크럼(Breadcrumb)' 역할을 수행함으로써, 모델은 단일 턴 내에 스스로 오류를 복구할 수 있게 됩니다.

 

4. 전략 3: 토큰 효율적 응답 엔지니어링 (Token-Aware Response)

관측 데이터(Observability data)는 매우 무겁습니다. 소스 데이터에 따르면 단일 RAG Trace가 131,000 토큰에 달하는 경우도 발생합니다. 이러한 데이터를 정제 없이 반환하면 단 한 번의 호출로 컨텍스트 윈도우가 마비됩니다. "모든 토큰은 제 자리를 증명해야 한다(Every token earns its place)"는 원칙하에 응답 크기를 동적으로 제어해야 합니다.

데이터 규모에 따른 3단계 Response Sizing 전략

1. Whole (전체): 데이터 크기가 작아 추론 공간을 침해하지 않을 때만 전체 반환.
2. Stripped (절삭): 데이터가 임계치를 넘으면 긴 문자열(Payload)을 절삭하고 브레드크럼을 남김. 브레드크럼에는 read 도구로 해당 데이터만 다시 가져올 수 있는 특정 ID나 경로가 포함되어야 합니다.
3. Skeleton (스켈레톤): 10만 토큰 이상의 거대 데이터의 경우, 빈 필드와 래퍼를 제거하고 구조적 뼈대만 노출.

이러한 전략은 컨텍스트 윈도우를 청결하게 유지하며, 소중한 토큰이 단순 데이터 전송이 아닌 실제 추론과 문제 해결에 집중되도록 보장합니다.

 

5. 결론: REST의 관성에서 벗어난 LLM 네이티브 아키텍처

최적화된 MCP 서버 설계의 핵심은 수년간 엔지니어링 팀을 지배해온 'REST 원칙의 폐기(Unlearning REST)'에 있습니다. LLM은 엄격한 규약보다 유연한 추상화와 학습 가능한 피드백을 통해 더 높은 성능을 발휘합니다.

본 가이드라인에서 제시한 3가지 핵심 결정(4개 도구 통합, 자가 치유, 토큰 최적화)은 다음과 같은 비즈니스 가치를 제공합니다.

• 비용 최적화: 불필요한 컨텍스트 점유와 데이터 전송을 제거하여 토큰 비용을 약 30% 이상 절감할 수 있습니다.
• 추론 성능 극대화: 도구 선택 오류를 줄여 에이전트의 작업 성공률을 높입니다.
• 운영 확장성: 플랫폼이 커져도 인터페이스의 복잡도는 일정하게 유지됩니다.

도구 설계의 목표는 잘못된 호출을 처벌하는 계약이 아니라, 모델과 협력하여 올바른 길로 안내하는 지능적인 인터페이스가 되어야 합니다.

 

 

엔지니어링 즉시 실천 체크리스트

• [ ] 노출된 도구의 수가 10개를 초과하는가? 범용 도구(list, read, write) 기반의 추상화 레이어를 도입하십시오.
• [ ] 도구 정의 스키마를 초기 리스트에 포함하고 있는가? schema 도구를 통한 레이지 로딩 방식으로 전환하십시오.
• [ ] 오류 메시지가 단순히 "Invalid"만 반환하는가? 모델이 다음 턴에 바로 수정할 수 있는 구체적인 힌트(사용 가능한 필드명 등)를 포함하십시오.
• [ ] 수만 토큰에 달하는 거대 응답을 그대로 반환하는가? 131k 토큰과 같은 극단적인 사례를 고려하여 'Skeleton' 혹은 'Stripped' 응답 로직을 구현하십시오.
• [ ] 신규 기능 추가 시 MCP 도구 목록을 수정해야 하는가? 레지스트리 업데이트만으로 기능 확장이 가능한지 점검하십시오.