MCP 서버, API 아니라 UI처럼 설계하라

AI에 도구를 붙이는 MCP(모델 컨텍스트 프로토콜)가 "문맥 창을 잡아먹는다"는 비판에 시달려왔다. 이에 대해 한 개발자가 "문제는 MCP 자체가 아니라 우리가 서버를 잘못 짓는 방식"이라며 실무형 설계 4원칙을 정리한 글을 냈다. 배경엔 최근 개발자 사이에서 번진 "MCP는 죽었고 스킬(Skills)+CLI 조합이 낫다"는 주장이 있는데, 글쓴이는 스킬+CLI가 개발자용으로는 훌륭하지만 제품 기능을 일반 사용자에게 AI로 노출할 때는 여전히 MCP가 낫다고 본다.

무슨 일인가

MCP 서버는 쓰기도 전에 도구 정의만으로 모델의 문맥을 차지한다. 글에 인용된 측정에 따르면 MCP 서버 일곱 개가 첫 질문을 넣기도 전에 6만7,000토큰 넘게 소비했고, 깃허브(GitHub) MCP 서버 하나가 도구 27개로 약 1만8,000토큰을 차지했다. 이 "문맥 비대화"가 MCP의 오명이 된 원인이다. 하지만 글쓴이는 이것이 MCP의 숙명이 아니라 설계 선택의 결과라고 짚는다. 도구를 너무 많이 노출하고, 설명을 장황하게 쓰고, 응답을 과하게 키우고, 무엇보다 MCP를 API처럼 다룬 탓이라는 것이다.

핵심 짚어보기

제시된 네 가지 원칙은 이렇다. 첫째, MCP는 API가 아니라 사용자 인터페이스(UI)이니 UI처럼 설계하라. API 엔드포인트를 하나씩 도구로 옮기지 말고, "사용자가 무엇을 이루려 하는가"에서 출발하라는 것이다. 사용자의 의도가 도구가 되고, 요청 방식이 프롬프트 예시가 되며, 필요한 정보가 입력 스키마, 돌려줄 정보가 출력이 된다. 둘째, 도구 개수를 줄이고 각각을 최적화하라. 모델은 매 상호작용마다 도구 목록·설명·입력 스키마를 통째로 받으므로 도구가 많을수록 초기 문맥이 커진다. 셋째, 지시문도 문맥이다. 넷째, 출력을 걸러 덩치를 줄여라. 글쓴이는 첫 서버라면 범위를 좁혀 읽기 전용으로 시작하고, 가능한 한 빨리 실제 모델에 물려 시험하라고 권한다.

1인기업 실전 적용 포인트

• 내 서비스에 MCP를 붙일 때 기존 API를 그대로 도구로 노출하지 말자. "사용자가 우리 도구로 끝내려는 일 3~5가지"를 먼저 적고, 그 의도 단위로만 도구를 만든다.
• 도구 설명과 응답을 짧게 유지해 토큰을 아낀다. 6만 토큰이 낭비되면 그만큼 실제 대화에 쓸 여력과 비용이 줄어든다. 응답에서 모델이 안 쓰는 필드는 잘라낸다.
• 새 서버는 반드시 읽기 전용부터 만들어 클로드(Claude) 등에 붙여 즉시 테스트하고, 잘 도는 걸 확인한 뒤에만 쓰기·삭제 기능을 더한다.
• 도구가 10개를 넘어가면 정말 다 필요한지 점검한다. 적은 도구로 같은 일을 시키는 편이 정확도와 비용 모두에 유리하다.

전망 / 주의점

MCP를 둘러싼 "죽었다/아니다" 논쟁은 당분간 이어질 전망이다. 다만 이 글의 요지는 도구 논쟁이 아니라 설계 태도에 있다. 무엇을 붙이느냐보다 얼마나 절제해서 붙이느냐가 AI 도구의 실사용 품질과 비용을 가른다는 점은, 규모가 작아 토큰 한 푼이 아쉬운 1인기업일수록 새겨둘 만하다.

출처: Hacker News (https://bump.sh/blog/4-rules-to-build-an-efficient-mcp-server/)