도구와 MCP 모의 시나리오

도구 설계와 MCP 통합 도메인은 18퍼센트를 차지한다. 출제의 핵심은 도구를 "동작하게" 만드는 것이 아니라 "에이전트가 적게 헤매고 정확히 쓰도록" 설계하는 데 있다. 도구 설명 토큰 비용, 대규모 도구 집합의 컨텍스트 부담, 입력 스키마의 엄격성, MCP 전송 방식 선택이 단골 함정이다. 이 절은 세 문항으로 그 판단을 훈련한다.

모의 문항 1 — 도구가 너무 많을 때

상황. 한 에이전트에 200개가 넘는 MCP 도구가 연결되어 있다. 그런데 일반적인 대화에서 실제로 쓰이는 도구는 소수다. 모든 도구 정의가 매 요청의 시스템 프롬프트에 실리면서 토큰이 크게 낭비되고, 모델이 비슷한 도구 사이에서 자주 혼동한다. 어떻게 개선하는가.

후보. 첫째, 모든 도구 설명을 한 줄로 줄여 토큰을 아낀다. 둘째, 자주 안 쓰는 도구에 지연 로딩을 적용해 초기 시스템 프롬프트에서 빼고 필요할 때 불러오게 한다. 셋째, 도구 개수를 강제로 50개 이하로 잘라 낸다. 넷째, 더 큰 컨텍스트 창 모델로 바꿔 토큰 여유를 만든다.

정답은 둘째다. 도구 정의를 초기 프롬프트에서 제외하고 호출이 필요한 시점에 로딩하면, 평소에는 토큰을 점유하지 않으면서도 도구 자체는 살아 있다. 대규모 도구 집합의 컨텍스트 부담 문제에 대한 정석 해법이 지연 로딩이다.

오답을 보자. 첫째는 설명을 과하게 줄이면 모델이 도구의 용도와 인자를 오해해 오히려 정확도가 떨어진다. 도구 설명은 토큰을 아끼되 충분히 명확해야 하는 균형의 문제이지, 무조건 짧게가 정답이 아니다. 셋째는 기능을 임의로 버리는 손실적 해법이고, 넷째는 앞 절과 마찬가지로 더 큰 창으로 구조 문제를 덮는 전형적 함정이다. 비용 문제를 모델 업그레이드로 푸는 보기는 거의 항상 오답이다.

모의 문항 2 — 구조가 깨지면 안 되는 도구

상황. 한 도구가 결제 시스템에 금액과 통화 코드를 넘긴다. 모델이 가끔 금액을 문자열로 보내거나 통화 코드 필드를 빠뜨려 결제가 실패한다. 호출 입력의 형식을 반드시 보장해야 한다. 어떤 설계가 옳은가.

후보. 첫째, 도구 설명에 "반드시 숫자로 보내라"는 문장을 추가한다. 둘째, 입력 스키마에 엄격 검증을 켜서 스키마에 맞지 않는 호출을 구조적으로 막는다. 셋째, 잘못된 입력이 오면 도구 내부에서 적당히 보정한다. 넷째, 호출 후 결과를 보고 모델이 알아서 다시 시도하게 둔다.

정답은 둘째다. 입력 스키마에 엄격 검증을 적용하면 모델 출력이 스키마를 따르도록 보장되어, 타입이 어긋나거나 필수 필드가 빠진 호출 자체가 발생하지 않는다. 형식을 "반드시 보장"해야 한다는 제약이 엄격 스키마를 정확히 가리킨다.

오답을 보자. 첫째는 자연어 지시라 확률적 준수에 그쳐 "반드시"라는 요구를 충족하지 못한다. 프롬프트 문장으로 형식을 강제하려는 보기는 보장이 필요한 맥락에서 함정이다. 셋째는 도구가 잘못된 입력을 임의 보정하면 결제 금액 왜곡 같은 위험한 부작용을 낳고, 넷째는 실패 후 재시도라 지연과 비용이 늘 뿐 형식 보장과 무관하다.

모의 문항 3 — MCP 전송 방식 선택

상황. 사내 개발자 PC에서 로컬 파일과 로컬 데이터베이스에 접근하는 MCP 서버를 붙이려 한다. 별도의 네트워크 서버를 운영하지 않고 같은 머신에서 프로세스로 실행하는 것이 가장 단순하다. 한편 다른 팀은 여러 사용자가 원격에서 동시에 접속하는 사내 공용 MCP 서버를 만들려 한다. 각각 어떤 전송 방식이 적합한가.

후보. 첫째, 로컬 단일 사용자에는 표준 입출력 전송, 원격 다중 사용자에는 스트리밍 가능한 HTTP 전송. 둘째, 둘 다 표준 입출력으로 통일. 셋째, 둘 다 원격 HTTP로 통일. 넷째, 원격 다중 사용자에 이미 권장에서 물러난 옛 단방향 이벤트 스트림 방식을 쓴다.

정답은 첫째다. 같은 머신의 단일 프로세스 통신에는 표준 입출력 전송이 가장 단순하고, 여러 사용자가 원격 접속하는 환경에는 스트리밍을 지원하는 HTTP 전송이 맞다. 전송 방식은 로컬·단일이냐 원격·다중이냐에 따라 갈린다.

오답을 보자. 둘째는 표준 입출력으로는 원격 다중 접속을 감당하지 못하고, 셋째는 로컬 단일 사용자에 굳이 네트워크 서버를 세워 복잡도를 키운다. 넷째는 권장에서 물러난 구식 전송을 고른 함정으로, 신규 설계에서 옛 방식을 그대로 답으로 내미는 보기는 의심해야 한다.

정리

• 도구가 많아 토큰을 낭비하고 모델이 혼동하면 지연 로딩으로 초기 프롬프트에서 도구 정의를 빼는 것이 정석이며, 더 큰 창으로 덮으려는 보기는 함정이다.
• 도구 설명은 무조건 짧게가 아니라 토큰을 아끼되 용도와 인자가 명확하도록 균형을 잡는 문제다.
• 입력 형식을 반드시 보장해야 하면 엄격 스키마 검증이 정답이며, 자연어 지시로 형식을 강제하려는 보기는 확률적 준수에 그쳐 오답이다.
• 도구가 잘못된 입력을 임의로 보정하는 설계는 위험한 부작용을 낳으므로 피한다.
• MCP 전송은 로컬 단일 사용자에 표준 입출력, 원격 다중 사용자에 스트리밍 HTTP가 맞고, 권장에서 물러난 구식 전송을 답으로 내미는 보기는 함정이다.