LLM 기반 에이전트가 폭넓게 보급되면서, 모델과 외부 도구를 잇는 연결 표준에 대한 관심이 빠르게 커지고 있다. 그 표준으로 자리잡은 MCP(Model Context Protocol)는 단순한 프로토콜 이상의 의미를 갖는다. 바로 도구 설계의 품질이 에이전트의 행동 품질을 결정한다는 점이다. 이 글에서는 AWS ML Blog가 제시한 실전 사례를 바탕으로, 컨텍스트 엔지니어링 관점에서 MCP 도구를 어떻게 설계해야 하는지 정리한다.
- MCP는 LLM과 외부 도구를 잇는 개방형 표준이며, 도구 설계 품질이 곧 에이전트 정확도와 비용을 좌우한다.
- AWS ML Blog 사례에서 도구 남용, 모호한 설명, 스키마 중복이 도구 선택 오류와 토큰 낭비를 키우는 전형적 실패 패턴으로 진단된다.
- 컨텍스트 엔지니어링 기반의 도구 분리, 메타데이터 축소, 복구형 표현을 적용하면 호출 정확도와 비용 효율을 동시에 개선할 수 있다.
도구의 수는 줄이고, 설명의 의미는 높이며, 실패는 견디게 설계하는 것이 MCP의 핵심 트레이드오프다.
MCP, 왜 지금 중요한가
개방형 표준으로서의 MCP
MCP는 LLM과 도구, 외부 자원 사이의 호출 계약을 표준화하기 위해 등장한 개방형 프로토콜이다. 기존에는 프롬프트 안에 함수 호출 스펙을 박아 넣거나 프레임워크별 플러그인을 따로 작성해야 했지만, MCP는 서버-클라이언트 모델을 통해 도구 카탈로그를 분리된 인터페이스로 노출한다. 이는 Model Context Protocol 공식 문서에서 정의하는 핵심 약속으로, 표준을 따르는 도구라면 어떤 에이전트 런타임에서도 같은 정의를 재사용할 수 있다. 즉, 한 번 규격을 따르면 어떤 에이전트 런타임에서도 같은 도구 정의를 재사용할 수 있다는 의미로 해석된다.
에이전트 도구 생태계의 확장 흐름
최근 1년 사이 사내 데이터베이스 조회, 사내 메신저 연동, 빌링 시스템 호출 같은 사내 자산을 도구로 등록하는 팀이 늘었다. MCP의 보급 속도가 이를 가속한다는 평가가 나오고 있으며, AWS ML Blog도 이런 확장 흐름이 도구 카탈로그의 비대화라는 부작용을 낳고 있다고 진단한다. 도구가 많아질수록 모델은 도구 선택에서 더 자주 혼동하고, 결과적으로 토큰 비용과 응답 지연이 동시에 증가한다는 것이다.
AWS ML Blog가 본 설계 실패의 전형
너무 많고 모호한 도구 노출
AWS ML Blog가 제시하는 첫 번째 실패 패턴은 도구를 한 서버에 너무 많이 등록하는 것이다. 모든 데이터를 조회할 수 있는 mega tool 하나보다는, 목적별로 잘게 쪼갠 도구 여러 개가 모델 입장에서는 명확해 보이지만, 역설적으로 그 작은 도구들의 경계가 모호하면 선택 오류가 누적된다. 도구 카탈로그는 발견 가능한 검색 엔진이 아니라 모델이 매 호출마다 직접 읽는 목록이라는 점을 떠올리면 직관과 다르다.
설명문 중심 설계의 함정
두 번째는 설명문에 모든 정보를 채워 넣는 태도다. 예시는 다음과 같다.
- 한 도구의 description이 800 토큰을 넘어 모델 컨텍스트의 상당 부분을 선점
- 사용 예시, 변경 이력, 주의 문구가 섞여 핵심이 흐려짐
- 다른 도구와 설명 문장이 비슷해 모델이 구분하지 못함
결과적으로 모델은 설명을 다 읽은 뒤에도 어떤 도구를 골라야 할지 확신하지 못해 선택 오류가 누적된다신하지 못한다. 이는 도구 선택 정확도가 설명의 길이와 비례하지 않음을 보여주는 사례로 분석된다.
스키마와 컨텍스트 비용의 충돌
세 번째는 입력 스키마의 과잉 명세다. 옵셔널 필드를 20개 이상 열어두거나, 중첩 객체를 깊게 설계하면 호출 전 도구 정의 자체가 컨텍스트 윈도우를 빠르게 소진한다. AWS ML Blog는 이 구간에서 도구 호출 횟수가 늘고 응답 비용이 2~3배까지 치솟는 사례가 관찰된다고 언급한다. 정확한 수치는 사례별 편차가 크므로 추정임을 밝힌다. 핵심은 스키마의 엄격함과 컨텍스트 비용 사이에 명확한 트레이드오프가 존재한다는 점이다.
컨텍스트 엔지니어링 기반 실용 설계 원칙
도구 목적 입력 출력의 명확한 분리
첫 번째 원칙은 한 도구가 한 가지 결정을 내리게 만드는 것이다. 입출력을 다음 표처럼 분리해 보면 모델이 선택에 쓰는 추론 비용이 줄어든다.
| 구분 | 느슨한 설계 | 컨텍스트 엔지니어링 기반 설계 |
|---|---|---|
| 목적 표현 | 데이터 가져오기 | 특정 고객 ID의 최근 주문 5건 조회 |
| 입력 스키마 | 키 자유, 옵션 다수 | customer_id 필수, limit 기본값 |
| 출력 형태 | 원본 레코드 그대로 | 주문 ID, 일시, 금액 요약 객체로 정규화 |
느슨한 설계에 익숙한 팀에게는 답답해 보일 수 있지만, 도구 설명이 짧고 결정적일수록 모델의 선택 신뢰도는 오르는 것으로 관찰된다.
불필요 메타데이터 축소와 토큰 효율화
두 번째 원칙은 메타데이터를 줄이는 것이다. 사용 예시는 별도 문서로 빼고, description에는 동사 하나로 시작하는 한 문장 요약만 남기는 방식이 자주 추천된다. 옵셔널 파라미터는 최소한으로 자르되, 응답 스키마는 모델이 다음 행동을 결정하는 데 필요한 필드만 노출하도록 정규화한다. 이렇게 정의된 도구는 컨텍스트 윈도우를 절반 가까이 아끼면서도 호출 정확도를 유지한다는 평가가 AWS ML Blog 사례에서 반복된다. 수치는 환경에 따라 달라질 수 있다는 점을 함께 고려해야 한다.
호출 실패를 견디는 복구형 도구 설계
세 번째는 실패를 전제로 한 설계다. 도구가 잘못 호출되면 모델이 어떻게 복구할지를 설명에 살짝 녹여 두는 것이다. AWS ML Blog는 다음 두 표현을 병기할 것을 제안한다.
- 어떤 입력이 잘못되면 어떤 메시지를 돌려주는지 명시
- 복구 가능한 다음 도구 후보를 짧게 안내
표면적으로는 설명이 조금 길어지지만, 잘못된 호출을 다시 시도하는 추가 호출이 사라져 전체 토큰 비용은 줄어드는 경우가 많다고 분석된다.
실무 적용을 위한 자가 진단 체크리스트
도구 카탈로그 점검 질문 10선
- 한 도구의 description이 200 토큰을 넘는가, 넘는다면 핵심 동사 한 문장으로 줄일 수 있는가?
- 두 도구의 이름과 설명이 거의 같은가, 같다면 경계를 좁혀 합치는 것이 옳은가
- 옵셔널 파라미터가 5개 이상인가, 기본값으로 흡수할 수 있는 것은 무엇인가
- 응답 스키마에 모델이 다음 행동을 결정하는 데 쓰지 않는 필드가 남아 있는가
- 호출 실패 시 반환되는 에러 메시지에 모델이 다음에 시도해 볼 수 있는 행동이 포함되어 있는가
- 하나의 도구가 여러 결정을 동시에 내리게 하고 있지 않은가
- 서버 단위로 도구 수를 제한해 모델이 한 번에 보는 카탈로그 크기를 통제하고 있는가
- 도구 정의를 모델 외부의 문서로 분리해 두어 사람이 먼저 검토할 수 있는가
- 주요 도구에 대해 호출 성공률과 재시도 비율을 측정하고 있는가
- 새 도구를 추가하기 전에 기존 도구의 활용도를 확인하는 절차가 있는가
이 10개 질문은 AWS ML Blog가 제안하는 점검 항목과 MCP 공식 문서의 도구 정의 명세를 함께 반영한 것이다. 모두 예, 라고 답하기 어려운 항목이 있다면 그 지점이 개선 후보로 해석된다.
팀 내 MCP 설계 표준화 제안
개인 차원의 개선만으로는 한계가 있다. 다음 세 가지를 팀 표준으로 정해 두는 것이 효과적이라는 견해가 있다.
- 도구 1개당 description 상한 토큰 수를 명시한 가이드라인 작성
- 새 도구 머지 리퀘스트 시 체크리스트 10선 충족 여부 검토
- 주 단위로 도구 카탈로그 크기와 호출 실패율 리포트 자동화
이 절차를 따르면 도구가 자연 증가해도 일정한 품질이 유지되고, 신규 합류자도 같은 기준으로 작업할 수 있다.
마무리와 다음 학습 포인트
MCP는 도구를 만들어 연결하는 시대에서, 어떻게 잘 만들어 모델의 인지 비용을 줄이느냐의 시대로 넘어가고 있다. 컨텍스트 엔지니어링은 이 전환기의 핵심 키워드라 할 수 있다. 오늘 소개한 도구 분리, 메타데이터 축소, 복구형 표현의 세 가지 원칙과 자가 진단 체크리스트는 AWS ML Blog의 사례를 토대로 저자가 정리한 관점이며, 모든 환경에서 동일 효과가 보장된다는 의미는 아니다. 다만 도구를 많이 노출하는 것이 곧 확장이라고 생각하던 관점을 한 발 물러서게 만드는 데는 충분하다. 더 깊이 들어가고 싶다면 MCP 공식 문서의 도구 명세와 AWS ML Blog의 원문 사례를 함께 읽어 보면 좋다.
- 도구 수는 모델이 매 호출 읽는 카탈로그라는 점을 기준으로 조정한다.
- description은 동사 한 문장 요약으로 압축하고 예시는 외부 문서로 분리한다.
- 입출력 스키마는 모델의 다음 의사결정에 필요한 필드만 정규화해 노출한다.
- 실패 메시지에 복구 경로를 넣어 재호출로 인한 토큰 낭비를 줄인다.
- 설계 품질은 팀 표준과 체크리스트로 관리해 인적 의존도를 낮춘다.
- MCP 공식 문서와 AWS ML Blog 사례를 함께 읽으며 표준과 현장 사례를 교차 검증한다.
참고 자료