개요
이 글은 주말 이틀 동안 자산 관리 도구를 SQLite 기반 CLI + MCP 서버로 옮긴 경험을 바탕으로, MCP 도구 설계가 왜 RPC와 본질적으로 다르게 느껴지는지를 설명한다.
핵심 발견은 단순하다.
코드보다 오래 붙잡게 되는 것은 함수 본문이 아니라 함수 설명(description) 이었다.
한 줄 요약
“MCP 도구 설계에서는 시그니처가 무엇을 받는지 말해주지만, 설명은 언제 이 도구를 써야 하는지를 설득해야 한다.”
핵심 주장
1. 시그니처는 충분하지 않다
함수의 시그니처는:
- 인자 타입
- 반환값
- 호출 형태
는 말해주지만, 어떤 사용자 의도에서 이 도구를 써야 하는지는 거의 말해주지 못한다.
예:
add_txnadd_balanceadd_flow
이름과 타입은 명확해도, LLM은 실제 발화에서 어떤 도구를 선택할지 자주 헷갈린다.
그래서 description에:
Use this when...Do NOT use this for...
처럼 호출 시점과 다른 도구와의 경계를 써줘야 안정된다.
2. MCP는 RPC처럼 보이지만 다르다
형태만 보면 MCP는:
- JSON-RPC 계보
- 함수 시그니처
- 스키마
를 가진다.
하지만 결정적인 차이는 신뢰의 방향이다.
- RPC: 호출자가 호출 대상을 신뢰
- MCP: 도구를 만든 쪽이 호출자(LLM)를 신뢰해야 함
즉, 함수 설계가 “강제된 계약”에서 “설득 가능한 사용 설명”으로 이동한다.
3. SRP보다 어포던스가 중요해질 수 있다
전통적인 소프트웨어 설계에서는 get_holdings, get_prices, get_pnl처럼 잘게 쪼개는 것이 미덕일 수 있다.
하지만 LLM 호출자에게는:
- 호출 횟수가 늘고
- 조합 오류 가능성이 커지고
- 응답 지연이 생기기 쉽다
그래서 show_portfolio, get_brief처럼 의도에 직접 닿는 무거운 도구가 더 잘 작동할 수 있다.
즉:
- SRP는 만드는 사람의 미덕
- 어포던스는 쓰는 사람의 미덕
이라는 관점 전환이 필요하다.
4. 쓰기 도구에서는 책임 분담이 더 중요하다
예를 들어 add_txn에:
Always confirm with the user before recording
를 넣으면, LLM이 매번 확인 질문을 하게 되어 자연어 인터페이스의 장점이 사라질 수 있다.
그래서 더 실용적인 설명은:
- 즉시 기록하라
- 모호할 때만 물어라
- 잘못되면 되돌릴 수 있다
처럼 운영 원칙과 책임 분담을 포함하는 형태가 된다.
이건 더 이상 형식적 스키마 설명이 아니라, 호출자에게 주는 행동 규칙이다.
왜 중요한가
이 글의 통찰은 MCP를 “함수 호출을 LLM에게 열어주는 기술” 정도로 보는 관점을 넘어선다.
핵심은:
- 시그니처에서 설명으로
- 강제에서 설득으로
- 친밀한 호출자 가정에서 거리 인식으로
인터페이스 설계의 무게중심이 이동하고 있다는 점이다.
즉, 함수 호출은 사실 아주 특수하고 친밀한 관계였고,
LLM 시대에는 다시 도구의 어포던스를 설명하는 시대로 회귀하고 있다는 주장이다.
실무적 교훈
- 함수 이름만 믿지 말 것
- description에
언제 써야 하는지와언제 쓰지 말아야 하는지를 함께 적을 것 - 잘게 쪼갠 도구보다 의도 중심의 무거운 도구가 더 나을 수 있음
- 쓰기 도구는 확인 절차보다 책임 분담 원칙을 더 잘 설계해야 함
- MCP 도구 설계는 스키마 설계가 아니라 행동 유도 설계에 가깝다
의미
MCP 도구 설계는 단순히 RPC를 LLM에 붙이는 문제가 아니다.
더 정확히는, 타입 시스템과 IDE가 대신해주던 친밀함을 description과 affordance로 다시 만들어주는 작업이다.
그래서 좋은 MCP 도구는 “엄격한 함수”이면서 동시에 “잘 설명된 도구”여야 한다.