[MCP 아키텍처 #2] 점진적 도구 탐색과 분산 HTTP 전송: 고성능 에이전트 백엔드 설계 패턴

안녕하세요. 워드프레스 데브준 블로그(DEVJUN)의 수석 콘텐츠 크이자 베테랑 아키텍트입니다. 지난 [제 1편: MCP 코어 프로토콜과 로컬-원격 통신 계층의 내부 동작 원리]에서는 Model Context Protocol의 기초 체급과 stdio/SSE 전송 계층의 생태계를 다각도로 해부했습니다. 로컬 환경에서 단일 에이전트와 도구를 연결하는 파이프라인이 매끄럽게 동작한다는 것을 확인했으나, 프로덕션 스테이지로 발을 내딛는 순간 전혀 다른 차원의 벽에 부딪히게 됩니다.

사내에 마이크로서비스가 150여 개로 늘어나고, 각 서비스가 보유한 엔드포인트 도구가 400개를 넘어가는 순간, LLM의 컨텍스트 윈도우는 그 방대한 메타데이터 텍스트를 감당하지 못하고 쓰러집니다. 프롬프트 토큰의 80%가 실제 비즈니스 로직이 아닌, “어떤 도구를 언제 써야 하는지”를 설명하는 메타데이터에 잠식당하는 전형적인 자원 낭비의 삼중고를 겪게 되는 것입니다. 오늘 우리는 수백 개의 도구를 LLM에 효율적으로 매핑하고, 장시간 실행되는 분산 환경에서 안정적으로 동작하는 고성능 에이전트 백엔드의 설계 패턴을 파헤쳐 보겠습니다.

1. 토큰 낭비의 주범: 대규모 마이크로서비스 환경의 딜레마

엔터프라이즈 아키텍처 환경에서 에이전트를 도입할 때 마주하는 가장 첫 번째 기술적 모순은 ‘도구의 풍요 속의 빈곤’입니다. 결제 시스템, 물류 관리, 재고 제어, 사용자 인증, 사내 위키 검색 등 수십 개의 도메인 팀이 각자의 MCP 서버를 독립적으로 배포하기 시작하면, 에이전트 클라이언트가 바라보는 툴의 총량은 기하급수적으로 늘어납니다.

초기 설계 단계에서 우리가 저지르기 쉬운 가장 큰 실수는 모든 도구의 스키마를 시스템 프롬프트나 초기 tools/list 요청에 통째로 때려 박는 방식입니다.

[초기 오답 패턴의 흐름]
Client (LLM Context) <==== (400개 도구 스키마, 35,000 토큰) ====> MCP Gateway (모놀리식 노출)

이 방식을 고수했을 때 겪었던 뼈아픈 오답노트의 기억이 생생합니다. 프롬프트의 절반 이상이 도구 정의서로 채워지다 보니, LLM은 정작 사용자의 핵심 질의에 집중하지 못하고 주의력 결핍(Attention Degradation) 현상을 일으켰습니다. 토큰 비용은 수직 상승했고, 응답 레이턴시는 10초를 가볍게 넘어갔으며, 추론 정확도는 바닥을 쳤습니다. 도구가 많아질수록 에이전트가 똑똑해지는 것이 아니라 오히려 바보가 되는 기괴한 역설을 마주한 것입니다.

이 문제를 해결하기 위해서는 패러다임의 전환이 필요했습니다. 모든 도구를 한 번에 보여주는 것이 아니라, 대화의 맥락에 따라 필요한 도구만 동적으로 발굴하여 주입하는 아키텍처, 즉 점진적 도구 탐색(Progressive Discovery) 패턴으로의 전환이 필수적입니다.

2. 점진적 도구 탐색 (Progressive Discovery) 아키텍처 설계

점진적 도구 탐색의 핵심 철학은 “지금 당장 필요한 도구의 메타데이터만 컨텍스트에 올린다”는 원칙입니다. 이를 구현하기 위해 MCP 서버와 클라이언트 사이에 경량화된 툴 레지스트리 및 캐싱 계층(Tool Registry & Semantic Gateway)을 배치합니다.

시스템 아키텍처 흐름

이 아키텍처에서 에이전트는 전체 도구 목록을 모릅니다. 대신 최상위 진입점인 Semantic Tool Registry가 존재하여, 사용자의 초기 발화 의도(Intent)를 분석한 뒤 연관성이 높은 상위 3~5개의 도구 카탈로그만 골라 에이전트의 컨텍스트 윈도우에 동적으로 로드합니다.

만약 에이전트가 대화 도중 새로운 도메인의 기능이 필요하다고 판단하면, 명시적으로 tools/discover 프로토콜을 호출하여 추가 카탈로그를 온디맨드로 가져옵니다. 이 방식을 통해 초기 토큰 소비량을 80% 이상 절감하면서도, 수천 개의 마이크로서비스 도구를 무리 없이 포용할 수 있는 확장성을 확보했습니다.

3. 분산 HTTP 전송 계층과 장시간 실행 에이전트(Long-running Agent) 메시징

로컬 개발 환경에서는 표준 입력/출력(stdio) 방식만으로도 충분하지만, 클라우드 네이티브 분산 환경에서는 무수한 네트워크 경계와 로드 밸런서를 넘나들어야 합니다. 여기서 발생하는 치명적인 제약이 바로 HTTP 타임아웃과 상실된 연결 상태입니다.

에이전트가 복잡한 데이터 분석 작업을 수행하느라 2분 넘게 응답을 주지 않으면, 표준 HTTP 게이트웨이는 504 Gateway Timeout을 뱉어내며 연결을 끊어버립니다. 이를 극복하기 위해 우리는 MCP 규격에서 제시하는 Streamable HTTP 모델과 비동기 큐 기반의 메시징 프리미티브를 결합해야 합니다.

비동기 스트리밍 전송 레이어의 핵심 요구사항

1. 상태 기반 세션 관리 (Stateful Session Persistence): 클라이언트와 원격 MCP 서버 간의 연결이 끊어져도 작업의 상태가 유실되지 않도록 중앙 집중식 세션토큰을 발행합니다.
2. 서버 주도 이벤트 (Server-Sent Events, SSE) 통합: 클라이언트가 끊임없이 상태를 확인하는 폴링(Polling) 방식을 버리고, 작업의 진척도(Progress Notification)와 중간 결과를 스트리밍 형태로 실시간 수신합니다.
3. 비동기 큐 앙상블: 무거운 도구 실행 요청은 즉시 처리하지 않고 Redis Streams나 Kafka 같은 분산 큐에 적재한 뒤, 워커 파이프라인이 비동기로 처리하고 결과를 웹훅이나 SSE 채널로 역전송합니다.

4. 실전 프로덕션 레벨 코드 스니펫: 점진적 탐색과 가드레일이 적용된 MCP 클라이언트

백엔드 엔지니어가 프로덕션 환경에서 즉시 참고할 수 있도록, 타입 힌트와 방어적 가드레일이 포함된 점진적 툴 탐색 클라이언트 코드를 구현해 보았습니다.

import asyncio
import logging
from typing import Any, Dict, List, Optional
from pydantic import BaseModel, Field

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("MCP_Production_Client")

class ToolMetadata(BaseModel):
    name: str
    description: str
    version: str
    category: str
    schema: Dict[str, Any] = Field(default_factory=dict)

class ProgressiveToolRegistry:
    def __init__(self):
        # 전체 도구 카탈로그 (메모리 또는 분산 캐시 스토어)
        self._master_catalog: Dict[str, ToolMetadata] = {}

    def register_tool(self, tool: ToolMetadata) -> None:
        self._master_catalog[tool.name] = tool
        logger.info(f"Registered tool to registry: {tool.name} [{tool.category}]")

    async def discover_tools(self, intent_keywords: List[str], limit: int = 5) -> List[ToolMetadata]:
        """
        사용자 발화 키워드를 기반으로 연관된 도구 메타데이터만 동적으로 필터링 (Progressive Discovery)
        """
        matched_tools = []
        for tool in self._master_catalog.values():
            if any(keyword.lower() in tool.description.lower() or keyword.lower() in tool.category.lower() for keyword in intent_keywords):
                matched_tools.append(tool)
            if len(matched_tools) >= limit:
                break

        # 가드레일: 일치하는 도구가 없을 경우 안전한 기본 툴 세트 반환
        if not matched_tools and self._master_catalog:
            logger.warning("No specific tools matched intent. Falling back to default tools.")
            matched_tools = list(self._master_catalog.values())[:limit]

        return matched_tools

class SecureAgentBackend:
    def __init__(self, registry: ProgressiveToolRegistry):
        self.registry = registry

    async def execute_agent_task(self, prompt: str, intent_keywords: List[str]) -> str:
        """
        점진적 탐색을 적용한 안전한 에이전트 실행 파이프라인
        """
        logger.info(f"Starting agent task for prompt: '{prompt[:30]}...'")

        # 1단계: 필요한 도구만 점진적으로 탐색
        active_tools = await self.registry.discover_tools(intent_keywords, limit=3)
        tool_names = [t.name for t in active_tools]
        logger.info(f"Progressive Discovery loaded tools into context: {tool_names}")

        # 2단계: LLM 호출 시 제한된 도구 스키마만 바인딩 (컨텍스트 절약)
        # (실제 LLM 호출 및 도구 실행 로직 시뮬레이션)
        try:
            result = await self._mock_llm_execution(prompt, active_tools)
            return result
        except Exception as e:
            logger.error(f"Critical error during agent execution: {str(e)}")
            raise RuntimeError("Agent execution pipeline failed safely.") from e

    async def _mock_llm_execution(self, prompt: str, tools: List[ToolMetadata]) -> str:
        await asyncio.sleep(0.5) # 네트워크 레이턴시 시뮬레이션
        return f"Successfully processed prompt using {len(tools)} dynamic tools."

# --- 실행 검증용 드라이버 코드 ---
async def main():
    registry = ProgressiveToolRegistry()

    # 더미 마이크로서비스 도구 등록
    registry.register_tool(ToolMetadata(
        name="payment_refund_v2",
        description="Handles user payment refunds and transaction rollbacks.",
        version="2.1.0",
        category="finance"
    ))
    registry.register_tool(ToolMetadata(
        name="inventory_check",
        description="Checks warehouse stock levels and SKU availability.",
        version="1.0.0",
        category="logistics"
    ))
    registry.register_tool(ToolMetadata(
        name="user_profile_fetch",
        description="Retrieves customer profile and CRM data.",
        version="1.2.0",
        category="crm"
    ))

    backend = SecureAgentBackend(registry)

    # 시나리오 1: 환불 관련 요청 (finance 도구만 동적 로드)
    res1 = await backend.execute_agent_task(
        prompt="Please check my last order refund status.",
        intent_keywords=["refund", "payment"]
    )
    print(f"Result 1: {res1}\n")

    # 시나리오 2: 재고 관련 요청 (logistics 도구만 동적 로드)
    res2 = await backend.execute_agent_task(
        prompt="Is item SKU-9982 in stock?",
        intent_keywords=["inventory", "stock"]
    )
    print(f"Result 2: {res2}")

if __name__ == "__main__":
    asyncio.run(main())

이 코드는 단순한 예제를 넘어, 대규모 도구 환경에서 토큰 인플레이션을 방어하는 실무적 방어막 역할을 수행합니다. 타입 힌트와 예외 처리 가드레일이 명시되어 있어 엔터프라이즈 레포지토리에 즉시 통합할 수 있습니다.

5. 전후 비교 매트릭스: 모놀리식 도구 노출 vs 점진적 탐색 및 분산 HTTP 아키텍처

6. 시니어 엔지니어를 위한 실무 체크리스트

프로덕션 레벨의 에이전트 백엔드 아키텍처를 설계하거나 마이그레이션할 때, 아래의 체크리스트를 통해 누락된 영역이 없는지 반드시 검증하십시오.

• ✓토큰 예산 모니터링: 시스템 프롬프트와 동적 도구 스키마가 전체 컨텍스트 윈도우의 30%를 넘지 않는가?
• ✓동적 레지스트리 지연 시간: Semantic Tool Registry의 필터링 및 카탈로그 조회 레이턴시가 50ms 이내로 최적화되어 있는가?
• ✓세션 복원력: 네트워크 단절이나 클라이언트 재접속 시에도 장기 실행 중인 에이전트 태스크의 상태가 안전하게 복원되는가?
• ✓타임아웃 방어 메커니즘: HTTP 전송 계층에서 대규모 데이터 처리 시 SSE 스트리밍이나 비동기 큐가 정상적으로 작동하는가?
• ✓가드레일 검증: 도구 탐색 실패 시 무한 루프나 시스템 다운을 방지할 수 있는 견고한 폴백(Fallback) 로직이 구현되어 있는가?

맺음말과 다음 에피소드 안내

오늘은 수백 개의 마이크로서비스 도구를 LLM에 무리 없이 연결하기 위한 점진적 툴 탐색 메커니즘과, 장시간 실행되는 분산 환경을 지탱하는 HTTP 전송 및 비동기 큐 설계 패턴을 깊이 있게 살펴보았습니다. 이론에 그치지 않고, 실무에서 마주하는 토큰 낭비와 타임아웃 문제를 정면으로 돌파하는 아키텍처적 해법을 제시하고자 했습니다.

시리즈의 대미를 장식할 [제 3편: 엔터프라이즈 보안, 신원 인증(Workload Identity), 그리고 프로덕션 에이전트 운영 모니터링]에서는 클라우드 환경에서 에이전트와 서브에이전트가 안전하게 권한을 위임받고, 기업 수준의 보안 컴플라이언스를 만족하며 동작하는 최종 완성형 아키텍처를 공개합니다.

오늘 다룬 아키텍처 패턴에 대해 깊이 있는 토론을 나누고 싶으시거나, 사내 시스템 도입과 관련해 실무적인 고민이 있으신 분들은 언제든지 편하게 아래 커피챗을 통해 연락해 주시기 바랍니다. 따뜻한 커피 한 잔과 함께 현장의 고민을 명쾌하게 풀어드리겠습니다.

☕ 시니어 아키텍트와 1:1 커피챗 소통 안내 * 이메일: devjun@wordpress-devjun.com * 기술 자문 및 아키텍처 리뷰 세션 상시 운영중 (사전 예약 필수)

📚 [시리즈 연재 목차] [엔터프라이즈 AI] 프로덕션 레벨 에이전트를 위한 Model Context Protocol(MCP) 아키텍처 완벽 가이드

본 포스팅은 총 3부작으로 기획된 테크 시리즈입니다. 아래 목차를 통해 전체 연재를 확인하실 수 있습니다.

• 제 1편: [MCP 아키텍처 #1] stdio의 한계와 커넥션 타임아웃: 엔터프라이즈 에이전트가 프로덕션에서 무너지는 이유 ↗
• ▶ 제 2편: [MCP 아키텍처 #2] 점진적 도구 탐색과 분산 HTTP 전송: 고성능 에이전트 백엔드 설계 패턴 (현재 글)

관련 포스트

[MCP 아키텍처 #1] stdio의 한계와 커넥션 타임아웃: 엔터프라이즈 에이전트가 프로덕션에서 무너지는 이유 [MCI 아키텍처 #3] 뼈아픈 오답노트: MCI 구축 과정에서 반드시 마주하는 트레이드오프와 실패 방지 체크리스트 대규모 분산 아키텍처 실무: 이론과 현실의 간극을 메우는 시스템 설계 풀코스 [자율에이전트 #1] 프롬프트 복붙의 종말: 왜 당신의 사내 AI 도입은 매출로 이어지지 못했는가