MCP와 도구 사용에 대해 내가 잘못 알고 있었던 5가지

일 때문에 에이전트 프롬프트를 엄청나게 써대는데, 반년 정도 MCP 서버랑 Claude Code를 테스트베드로 굴려봤거든. 처음에 내가 가졌던 생각들 중 상당수가 그냥 틀린 거였어. 시간 낭비 제일 심했던 거 5개 추려봤으니까, 너네는 시간 좀 아껴라.

1. "컨텍스트 윈도우가 크면 도구를 더 많이 연결할 수 있겠지?"

이게 제일 최악이었음. 컨텍스트 윈도우를 무슨 옷장처럼 생각했거든. 공간이 넓으니까 이것저것 다 때려 넣으면 되는 줄 알았지. 근데 실제로는 연결된 모든 서버의 도구 설명이 매 턴마다 컨텍스트에 다 올라가. 모델은 뭘 하기도 전에 그 긴 걸 다 읽어야 함. 도구 많이 넣는다고 에이전트가 똑똑해지는 게 아니더라. 어느 선 넘어가면 오히려 성능 떡락함. 정작 써야 할 도구는 안 쓰는 수백 개 정의들 사이에 파묻혀 버리거든.

2. "모델이 도구를 잘못 고르는 건 멍청해서 그런 거다."

올바른 도구를 쓰게 하려고 몇 주 동안 프롬프트만 길고 장황하게 썼는데, 완전 헛짓거리였음. 모델이 볼 수 있는 도구 개수를 확 줄여버리니까 프롬프트는 건드리지도 않았는데 정확도가 확 올라가더라. 어디 벤치마크 보니까 작은 로컬 모델도 도구 100개짜리 카탈로그에서 관련 있는 것만 추려서 보여주니까 성능이 그냥 미친 듯이 좋아짐. 모델이랑 가중치는 그대로인데 말이야. 결국 모델 문제가 아니라 메뉴판이 너무 길었던 거임.

3. "도구 설명은 문서니까 최대한 자세하게 써야지."

도구 설명은 사람이 읽는 문서가 아님. 프롬프트의 일부고, 매 턴마다 토큰 비용으로 다 나가는 거임. 내가 쓴 도구 중에 시스템 프롬프트보다 설명이 더 긴 게 있었는데, 알고 보니 대부분은 개발자가 그냥 복붙해둔 마케팅 문구였음. 모든 설명을 동사 위주의 한 문장으로 다 뜯어고쳤는데, 이번 분기에 한 일 중 제일 효율 좋았음.

4. "도구 순위 매길 땐 당연히 시맨틱 임베딩 써야지."

이건 너무 당연한 거라 의심도 안 했는데, 이 케이스에선 완전히 틀린 접근이었음. 도구 이름이랑 설명은 긴 문단이 아니라 짧은 구조화된 문자열이라, 내가 돌려본 모든 테스트에서 단순 키워드 랭킹(BM25)이 임베딩을 압살함. RAG 국룰이랑은 정반대인데, 임베딩 API도 필요 없고 오프라인에서 완벽하게 돌아가니까 개꿀임.

5. "도구 앞에 라우팅 레이어 두려면 서비스 하나를 따로 띄워야겠지?"

게이트웨이 같은 거 만들려면 컨테이너 새로 파고, 포트 열고, 새벽 2시에 알람 울리면 깰 거 생각하고... 다 귀찮은 일인 줄 알았음. 근데 그냥 인프로세스로 다 돌릴 수 있더라. 내가 짠 방식은 Rust 코어를 Node 프로세스에 컴파일해서 넣는 건데, 모델은 전체 리스트를 보는 게 아니라 '카탈로그 검색'이랑 '선택한 도구 실행' 딱 두 가지만 보게 됨. 설치도 명령어 한 줄이면 기존 설정 읽어서 백업까지 해주고 알아서 다 바뀜. 오픈소스고, 2번 포인트에서 말한 벤치마크랑 레포는 여기 있음: http://github.com/ratel-ai/ratel/tree/main/benchmark

뭐 엄청 대단한 통찰은 아님. 5개 다 관통하는 핵심은 이거야. 도구는 공짜가 아님. 연결하는 순간 컨텍스트랑 모델의 주의력 측면에서 계속 비용이 발생함. 결국 이기는 법은 더 똑똑한 모델을 쓰는 게 아니라, 덜어내는 거임. 너네도 삽질하면서 배운 거 있으면 좀 알려줘라. 나도 아직 틀린 게 많을지도 모르니까.