MCP(Model Context Protocol)가 사실상 표준이 됐다. 주요 코딩 에이전트가 죄다 네이티브로 읽고, 거버넌스는 Linux Foundation 산하로 갔다. 그러자 다들 “우리도 MCP 서버를 만들자”로 뛰어든다.
그런데 한발 떨어져서 보면, 사람들이 몰리는 곳은 정작 쉬운 쪽이다. 프로토콜은 어려운 적이 없었다. 에이전트가 실제로 잘 도느냐 마느냐는 프로토콜이 아니라 그 위에 얹는 Tool 설계에서 갈린다. 그리고 그 설계는 새로 배우는 기술이 아니다.
프로토콜은 공짜다
MCP의 골격은 하루면 머리에 들어온다. 메시지는 JSON-RPC 2.0, 노출하는 건 프리미티브 세 개 — 모델이 호출하는 [Tools], 앱이 컨텍스트로 끌어오는 [Resources], 사용자가 고르는 [Prompts]. 전송은 로컬이면 stdio, 원격이면 HTTP에 OAuth. 끝이다. 공식 SDK를 깔면 서버 한 개 띄우는 건 정말 며칠 일이다.
그래서 “MCP 서버를 만들 줄 안다”는 건 자랑거리가 못 된다. 어셈블리를 짜던 시대도 아니고, 프로토콜을 말하게 하는 건 이미 도구가 다 해준다. 여기서 멈추면, 잘 도는 척하다가 실전에서 모델이 엉뚱한 도구를 부르고 헤매는 서버가 나온다.
진짜 승부는 Tool 설계에서 난다
모델은 사람처럼 도구를 쓰지 않는다. 사람은 함수 이름이 모호해도 문서를 뒤져 맥락을 채우지만, 모델은 이름과 설명만 보고 “이걸 쓸까 말까”를 그 자리에서 판단한다. 그래서 같은 기능이라도 설계가 결과를 가른다.
핵심은 몇 가지로 좁혀진다. 이름은 행동이 즉시 읽히게(search_orders지 do_action이 아니다). 설명은 사람용 주석이 아니라 모델에게 주는 지시문이다 — 언제 쓰고 언제는 다른 걸 쓰라고까지 적는다. 에러는 스택 트레이스를 던지지 말고 “왜 틀렸고 어떻게 고치는지”를 자연어로 줘서 모델이 스스로 복구하게 한다. 삭제·결제처럼 되돌리기 어려운 작업엔 반드시 사람 승인을 한 번 거치게 한다.
그리고 가장 흔히 놓치는 것 — 도구는 많을수록 나쁘다. 50개를 던지면 모델은 엉뚱한 걸 고른다. 선택지가 늘수록 오선택이 늘고 비용도 는다. “있는 기능 다 노출”이 아니라 “지금 필요한 것만”이 원칙이다.
그래서 이건 옛 기술의 부활이다
여기까지 읽고 나면 익숙할 것이다. 좋은 이름, 명확한 계약, 엄격한 타입, 최소 권한, 되돌릴 수 없는 작업의 가드 — 전부 API를 잘 설계하던 사람이 이미 갖고 있던 감각이다. Tool 설계는 새 분야가 아니라 소비자가 모델로 바뀐 API 설계다.
딱 두 가지가 다르다. 첫째, 설명을 사람이 아니라 모델이 읽는다 — 그래서 설명이 곧 프롬프트다. 둘째, 잘못 설계하면 모델이 “에러를 던지는” 게 아니라 “알아서 헤맨다”. 조용히 틀린 도구를 부르고, 그럴듯한 실패를 만든다. 그래서 예전에 「계약을 먼저 합의한다」에서 본 것과 같은 자리에 무게가 실린다 — 인터페이스를 어떻게 정의하느냐가 협업의 동기화 지점이 된다. 상대가 사람 팀이 아니라 모델일 뿐이다.
가장 흔한 실수 두 개
현장에서 거의 모든 서버가 같은 데서 넘어진다.
하나, 이미 있는 걸 또 만든다. 깃허브·슬랙·DB 같은 주요 시스템은 공식·커뮤니티 서버가 대개 이미 있다. 만들기 전에 레지스트리부터 뒤지는 게 첫 단계다. 둘, 기존 REST API를 1:1로 노출한다. 엔드포인트 50개를 도구 50개로 옮긴다. 모델은 사람과 다르게 쓰는데, 그러면 도구가 잘게 쪼개져 너무 많아진다. get_user + get_orders를 따로 두지 말고 get_customer_summary 하나로 모델의 “의도” 단위에 맞춘다.
왜 하필 지금 MCP인가
타이밍도 우연이 아니다. 지난 글에서 OKF를 보며 모델이 무엇을 “아는가”의 표준이 바닥에서 수렴하는 걸 봤다면, MCP는 그 옆 칸이다 — 모델이 무엇을 “하는가”의 표준. 에이전트가 똑똑해질수록 사람들이 원한 건 더 많이 아는 모델이 아니라 실제로 뭔가를 하는 모델이었고, MCP는 그 수요에 붙은 배관이다.
그래서 질문은 “MCP 서버를 어떻게 만드나”가 아니다. 그건 며칠이면 푼다. 진짜 질문은 “모델이 헤매지 않는 도구를 어떻게 설계하나”다. 그 답을 한 장으로 정리한 MCP & Tool 설계 가이드를 따로 만들어 뒀다 — 3가지 프리미티브, 동작 원리, 그리고 Tool 설계 10원칙까지.