Discrete MCP 도구 vs execute_code: 각각이 승리하는 경우
요약
MCP(Model Context Protocol) 서버 설계 시 단일 'execute_code' 도구를 제공하는 방식과 개별적인 'discrete tools'를 제공하는 방식의 장단점을 비교합니다. 모델의 성능과 실행 환경(프론티어 모델 vs 소형 로컬 모델)에 따른 최적의 설계 전략을 다룹니다.
핵심 포인트
- execute_code 방식은 프론티어 모델에서 토큰 효율성과 유연성이 매우 높음
- 개별 도구 방식은 소형 로컬 모델 및 특정 런타임 환경에 유리함
- 복합 쿼리 처리 시 execute_code는 라운드 트립을 줄여 효율적임
- 설계 결정은 에이전트가 구동되는 모델의 성능과 환경에 따라 달라져야 함
우리의 보트 에이전트(boat agents)가 MCP를 통해 SignalK — 풍향, 위치, 배터리, 수심 — 를 읽기를 원했을 때, 이미 이를 위한 유능한 서버가 있었습니다:
VesselSense/signalk-mcp-server (TypeScript, MIT). 이는 잘 만들어져 있습니다. 우리의 제1 원칙은 직접 만들기 전에 기존 도구를 사용하는 것이며, 우리는 이를 진지하게 받아들입니다. 바로 그 이유로 우리 배의 로그(ship's log)는 다른 사람의 플러그인을 사용하고 있습니다.
그럼에도 불구하고 우리는 별도의 서버를 구축했습니다:
signalk-mcp. 이 포스트는 그 이유에 대한 솔직한 버전입니다. 왜냐하면 이 두 서버는 동일한 설계 질문에 대해 진정으로 다른 두 가지 답변을 나타내며, 어떤 것을 선택할지는 전적으로 무엇이 이를 구동하느냐에 달려 있기 때문입니다.
설계 질문 (The design question)
쿼리(query)의 어느 정도를 _모델(model)_이 작성해야 하는가?
VesselSense의 답변: 전부 다. 이 서버는 단일 execute_code 도구를 노출합니다. 에이전트는 JavaScript를 작성하며, 이는 SignalK 데이터 모델에 접근할 수 있는 샌드박스화된 V8 isolate 환경에서 실행됩니다. 컨텍스트 윈도우(context window) 내의 도구 정의는 하나뿐이지만, 쿼리의 유연성은 무제한입니다. 엔진이 꺼져 있을 때만 세 개의 배터리 뱅크의 평균값을 알고 싶나요? 코드를 작성하면 됩니다. 서버를 새로 배포할 필요도 없습니다.
signalk-mcp의 답변: 전혀 없음. 이 서버는 read_sensor(path), battery_state(bank), depth_state(), get_active_alarms()와 같이 이름이 지정된 개별적인(discrete) 도구들을 노출하며, 각 도구는 하나의 인자 스키마(schema)와 고정된 응답 형태를 가집니다. 유연성의 한계는 서버가 제공하는 도구의 종류에 따라 결정됩니다.
프론티어 모델(frontier models)에서 execute_code가 승리하는 이유
만약 당신의 에이전트가 프론티어 모델(frontier model)이라면, execute_code는 이기기 힘든 강력한 선택지입니다:
- 토큰 효율성 (Token efficiency). 수십 개의 도구 정의 대신 단 하나의 도구 정의만 필요합니다. 긴 에이전트 세션(agent sessions)의 경우, 도구 스키마(tool schemas)는 반복적으로 컨텍스트 윈도우(context-window) 비용을 점유합니다.
- n+1 라운드 트립(round trips) 방지. 복합적인 질문("주택용 전압과 스타터 뱅크 전압 트렌드를 비교해줘")은 네 번의 도구 호출이 아닌, 단 하나의 코드 블록으로 해결됩니다.
- 서버 로드맵과의 결합(coupling) 방지. 모델은 서버 개발자가 전혀 예상하지 못한 질문에도 답할 수 있습니다.
대형 모델은 거의 매번 작은 JavaScript 코드를 정확하게 작성합니다. 이러한 유연성은 실질적이며 비용은 낮습니다.
보트 위에서 개별 도구(discrete tools)가 승리하는 이유
우리의 타겟 런타임(runtime)은 이와 정반대 지점에 있습니다. 바로 보트 위의 음성 비서입니다. 이 시스템은 소형 로컬 모델(small local models)에서 실행되도록 설계되었으며, 텍스트 음성 변환(text-to-speech) 프론트엔드를 갖추고 있고, 선원의 주의력은 에이전트와 바다 사이로 분산되어 있습니다. 이 설계에서 두 가지 요소가 지배적인데, 토큰 효율성은 그중 하나가 아닙니다.
1. 신뢰성 (Reliability). "내 배터리 상태는 어때?"라는 질문은 파도가 치는 상황에서도, 로컬 모델에서도 매번 작동해야 합니다. 검증된 하나의 인자(argument)를 가진 이름 있는 도구(named tool)를 사용하는 것은, 에이전트가 절반만 기억하고 있는 데이터 모델을 대상으로 정확한 JavaScript를 작성하도록 하는 것보다 훨씬 요구 사항이 적습니다. 또한 실패 모드(failure modes)의 성격도 다릅니다. 잘못된 도구 인자는 스키마 검증기(schema validator)에서 명확하게(loudly) 실패하지만, 미묘하게 잘못된 JavaScript는 그럴싸해 보이는 숫자를 내놓으며 조용히(quietly) 실패합니다. 보트 위에서는 이러한 조용한 실패가 가장 위험합니다.
2. 음성 계약(A speech contract). 모든 signalk-mcp 값은 에이전트가 그대로 말하는 display 문자열을 포함합니다 — 예: `
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기