저는 AI 에이전트가 저의 개인 WhatsApp을 사용할 수 있게 해주는 MCP 서버를 구축했습니다. 채팅 검색, 메시지 전송, 음성 메모 전사 등을 수행하며, 모두 셀프 호스팅(self-hosted)되어 메시지 기록이 제 기기를 절대 벗어나지 않습니다. 하지만 가장 흥미로운 문제는 WhatsApp과는 전혀 상관없는 것이었습니다. 바로 도구(tools)의 개수였습니다.

아무도 언급하지 않는 세금

MCP는 요청이 해당 도구를 사용하든 안 하든, 매 요청마다 모든 도구 정의를 모델의 컨텍스트(context)에 주입합니다. 제 서버는 96개의 도구로 늘어났습니다. 이는 모델이 아무것도 하기 전에 컨텍스트에 약 20k 토큰이 자리 잡고 있다는 의미입니다.

토큰 비용은 짜증 나는 부분이었지만, 진짜 문제는 아니었습니다. 96개의 도구를 모델에게 한꺼번에 넘겨주었을 때, 모델은 적절한 도구를 선택하는 능력이 좋아지기는커녕 오히려 나빠졌습니다. 선택지가 많아질수록 틀릴 확률도 높아졌습니다.

점진적 공개 (Progressive disclosure)

도구를 삭제하는 것은 당연한 선택지처럼 보이지만, 이는 기능을 상실하게 만듭니다. 그래서 대신 다음과 같은 방식을 택했습니다: 소수의 핵심 도구(hot core)를 직접 제공하고, 나머지 방대한 도구들(long tail)은 검색을 통해 접근할 수 있도록 유지하는 것입니다.

이제 모델은 29개의 핵심 도구와 2개의 메타 도구(meta-tools)를 봅니다:

find_tool(query)는 전체 96개 도구 라이브러리의 순위를 매겨 이름, 설명, 파라미터 시그니처(parameter signatures)를 반환합니다.
call_tool(name, arguments)는 이 중 어떤 도구로든 실행을 전달(dispatch)합니다.

항상 유지되는 비용이 약 20k 토큰에서 약 8k 토큰으로 줄어들었으며, 아무것도 삭제되지 않았고 모든 것은 검색 한 번으로 접근 가능합니다. 검색(Retrieval)은 기본적으로 어휘적(lexical) 방식(IDF + 어간 추출(stemming) + 유의어 맵)을 사용하며, 제공자 키가 있는 경우 임베딩(embeddings)을 혼합합니다.

당신을 물어뜯을 부분

call_tool은 프로세스 내부에서 도구 호출 시 통상적으로 실행되는 미들웨어 체인(middleware chain)을 건너뛰고 실행됩니다. 따라서 해당 체인이 수행했을 작업을 다시 적용해야 합니다: 도구별 범위 제한(per-tool scope enforcement) 및 감사 로깅(audit logging)입니다. 이를 건너뛰면 검색 레이어가 조용히 권한 우회(scope-bypass) 및 감사 공백(audit hole)이 되어버립니다. 권한 부여를 건너뛰는 도구 라우터는 라우터가 없는 것보다 더 나쁩니다.

느낌이 아니라 측정하세요.

"기분이 더 좋다"는 숫자가 아닙니다. 검색(retrieval)이 올바른 도구에 도달하는지를 점수화하는, 작게 라벨링된 평가(eval)(골드 도구(gold tool)를 향한 자연어 작업, 결정론적 라벨)가 있습니다. 적대적 문구(adversarial phrasing)에 대해 어휘적(lexical) 방식은 recall@8 기준 약 75%의 상한선을 보이며, 하이브리드(hybrid) 방식은 이를 더 높입니다. 이 평가는 규모가 작고 제가 개인적으로 만든 것이므로, 증거가 아닌 방향성으로 간주하십시오.

시사점 (Takeaway)

LLM을 거대한 API에 연결하고 있다면, 도구 목록(tool list)은 사후 고려 사항이 아니라 일급 디자인 문제(first-class design problem)입니다. 핵심 도구는 직접 제공하고, 나머지는 검색 가능하게 만들며, 인증(auth) 체계를 디스패치 경로(dispatch path)에 반영하고, 검색 성능을 숫자로 측정하십시오.

코드, 평가 하네스(eval harness), 그리고 디자인 노트: https://github.com/HalemoGPA/whatsapp-mcp-server