Anthropic 엔지니어 세 명이 MCP(Model Context Protocol)의 현재와 미래를 이야기하는 대담 유튜브 영상이 있습니다. Claude Relations의 Alex Albert, MCP팀의 John Welsh, API팀의 Michael Cohen이 출연했고, 내용이 매우 알찹니다.
핵심 조언을 요약하면 이렇습니다.
"MCP 서버와 툴은 본질적으로 프롬프트다. description 몇 줄 바꾸면 결과 품질이 달라진다."
"MCP 서버에 툴 15~20개보다 1~2개가 모델에게 훨씬 도움이 된다."
"API와 달리 계약(contract)에 덜 집착해도 된다. 15개 툴에서 2개로 바꿔도 breaking change가 아니다."
"앞으로 MCP 서버 품질이 벤더 평가 기준이 될 것이다."
전부 맞는 말입니다. 저도 직접 여러 제품의 API를 MCP로 감싸서 Claude에 붙여보면서 이 조언들이 유효하다는 걸 체감했습니다. 그런데 한 가지가 걸렸습니다. 이 조언들이 전부 공유하는 전제 조건이 있는데, 대담에서 한 번도 명시하지 않았습니다.
"뒤에 있는 제품이 잘 만들어져 있어야 한다."
직접 붙여보면서 이 전제가 빠졌을 때 무슨 일이 벌어지는지 경험했습니다.
MCP tool description 최적화가 성립하려면
대담에서 API팀 Michael Cohen이 예시를 하나 듭니다. 이미지 생성 MCP 서버에 Generate Image라는 도구가 있고 Description 필드만 있었는데, "귀여운 강아지"를 요청하면 Claude가 그대로 cute puppy만 넘깁니다. 그런데 도구 설명을 바꿔서 "이 도구는 XXX diffusion model을 호출하며, 이런 스타일로 프롬프트해야 최적의 결과가 나옵니다"라고 써두면, Claude가 언어를 바꿔서 훨씬 풍부한 프롬프트를 생성합니다. 결과 품질이 확 올라갑니다.
맞는 얘기입니다. 그런데 이게 가능한 건 뒤에 있는 diffusion model이 잘 만들어져 있기 때문이에요. Claude에게 "넌 지금 diffusion model과 대화하고 있어"라고 알려주면 Claude가 전략을 바꿉니다. 뒤에 있는 시스템이 정확하게 반응하니까 description 개선이 곧바로 결과 개선으로 이어지는 거죠.
뒤에 있는 시스템이 엉망이면 얘기가 달라집니다. description을 아무리 다듬어도 시스템이 엉뚱하게 반응하면, 더 정교한 요청이 더 정교한 오류를 만들 뿐입니다.
MCP 서버 도구 수 설계: "1~2개가 낫다"의 숨겨진 전제
대담에서 MCP팀 John Welsh가 MCP 서버 설계 원칙을 제시합니다. "서버에 도구 15~20개보다 1~2개를 두는 것이 모델에게 훨씬 도움이 됩니다." 예시로 Gmail을 듭니다. read_emails 도구와 write_email 도구를 분리할 필요 없이 get_info 하나만 두면 LLM이 description을 보고 알아서 판단한다는 겁니다.
저도 여러 제품의 API를 MCP로 감싸보면서 이 원칙을 시험해봤습니다. 결론부터 말하면 맞는 경우와 위험한 경우가 나뉩니다.
Salesforce의 경우. SOQL이라는 자체 쿼리 언어가 있습니다. 이 언어는 데이터 간의 관계를 언어 자체가 이해하고 있어서, SELECT Name, (SELECT LastName FROM Contacts) FROM Account처럼 한 문장으로 Account와 그 아래의 Contact을 동시에 끌어올 수 있습니다. Salesforce 공식 문서에 따르면 하나의 SOQL 쿼리에 최대 20개의 parent-to-child subquery를 넣을 수 있고, 5단계 깊이까지 nested subquery가 가능합니다. 이런 API 위에서는 도구를 줄여도 모델이 헤맬 이유가 없습니다. 언어 자체에 "데이터를 어떻게 읽어야 하는가"가 내장되어 있으니까요.
반대 경우도 있었습니다. 직접 경험한 한 B2B CRM(익명)에서는, 목록 엔드포인트에 필터가 없었습니다. 담당자별, 상태별, 날짜별 같은 기본 필터 없이 cursor만 제공했어요. 조건부 검색 API는 따로 있었지만, MCP 서버에 "전체 목록 가져오기" 도구와 "조건부 검색" 도구가 나란히 노출되어 있으니 Claude가 전체 목록 쪽을 택해서 20페이지 넘게 반복 호출했습니다. 매 페이지의 JSON이 컨텍스트에 누적되면서 즉사했어요. 검색 도구로 조건 하나만 걸면 끝날 일이었는데, 필터 없는 목록 도구가 "일단 전부 가져와서 필터하자"는 잘못된 경로를 열어둔 겁니다. 이런 API 위에 도구를 하나로 뭉쳐두면 오작동이 기본값이 됩니다. 오히려 필터 없는 목록 도구는 MCP에서 아예 빼거나, description에 "이 도구는 전체 목록을 반환합니다. 특정 조건이 있으면 반드시 search 도구를 사용하세요" 같은 가드레일을 박아야 합니다.
John Welsh의 원칙은 틀린 게 아닙니다. 전제 조건이 빠져 있었을 뿐입니다. underlying API가 잘 설계되어 있을수록 도구 수를 줄여도 안전하고, 엉성할수록 도구를 쪼개고 가드레일을 걸어야 합니다.
MCP의 느슨한 계약이 프로덕션에서 만드는 문제
대담에서 John Welsh가 MCP와 전통적 API의 핵심 차이를 짚습니다. "모든 게 fuzzy하고 LLM이 충분히 똑똑해서 알아서 합쳐주기 때문에, 계약에 훨씬 덜 신경 써도 됩니다." 15개 도구에서 2개로 완전히 재구성해도 사용자에게 고지할 필요 없이 그냥 롤아웃하면 된다는 겁니다. 전통적 API였다면 breaking change 처리, 사용자 커뮤니케이션, 버전 관리를 전부 해야 했을 텐데요.
MCP 서버 제공자 입장에서는 맞습니다. 운영이 편해지죠.
소비자 입장에서는 다른 세계가 펼쳐집니다. 제가 직접 겪은 사례입니다. 한 서드파티 통합 도구에서 Salesforce 레코드 업데이트를 제공하는 MCP 도구가 있었습니다. 겉으로는 모든 Salesforce 오브젝트에서 UPDATE가 되는 것처럼 보였습니다. 그런데 내부적으로는 Salesforce UI API를 사용하고 있었고, UI API는 Event와 Task 오브젝트를 지원하지 않습니다.
무슨 일이 벌어졌냐면, Account나 Contact에서는 UPDATE가 잘 되는데 Event나 Task에서는 조용히 실패합니다. HTTP 400 에러가 명시적으로 나는 게 아니라, "되는 척하면서 안 되는" 상황이었습니다. 문제의 원인은 중간 레이어가 underlying API의 제약을 가린 것이에요. 그런데 느슨한 계약 구조가 이 문제를 발견할 수 없게 만들었습니다. 전통적 API에서는 에러 코드와 문서로 이런 제약이 명시적이었는데, MCP에서는 그 명시성이 사라지거든요. 문제를 만든 건 중간 레이어이고, 문제를 숨긴 건 느슨한 계약입니다.
느슨한 계약은 프로토타입 단계에서 축복이지만, 프로덕션에서 소비자가 디버깅할 때는 "뭐가 바뀌었는지, 왜 안 되는지를 추적할 단서가 없다" 는 대가를 치릅니다.
MCP가 드러내는 것: API 설계 품질의 두 가지 축
위의 경험들을 관통하는 구조가 보입니다. MCP는 제품의 API 설계 품질을 증폭기처럼 드러냅니다. UI는 나쁜 API를 시각적 정리, lazy loading, 자동 번역으로 가릴 수 있지만, MCP를 붙이면 그 화장이 벗겨집니다.
API 설계 품질이 AI 성능을 좌우하는 축은 두 가지입니다.
관계 표현력: 데이터 간의 관계를 API 레벨에서 얼마나 표현하는가
SOQL처럼 쿼리 언어 자체가 오브젝트 간 관계를 이해하면, 한 번의 요청으로 관계가 내장된 구조화된 응답이 돌아옵니다. SELECT Name, (SELECT LastName FROM Contacts), (SELECT Amount FROM Opportunities) FROM Account WHERE Id = 'X'라고 쓰면, Account 아래에 Contact 목록과 Opportunity 목록이 관계 구조를 가진 채로 한꺼번에 옵니다. 모델이 별도의 조립 작업 없이 바로 해석할 수 있습니다.
대부분의 REST API 구현은 리소스별 엔드포인트로 설계되어 있어서 사정이 다릅니다. Company를 가져오고, 그 ID로 Deal을 가져오고, Contact을 가져오는 순차 과정을 거쳐야 합니다. 각 응답이 독립적이라 모델이 직접 ID를 매칭하고 관계를 추론해서 조립해야 하거든요. REST 아키텍처가 이걸 금지하는 건 아닙니다 — 잘 설계된 REST API는 연관 데이터를 함께 반환할 수 있습니다. 다만 대다수의 구현에서 그렇게 하고 있지 않을 뿐입니다.
핵심 차이는 API 호출 횟수가 아니라 응답의 구조화 수준이에요.
세일즈 미팅으로 비유하면 이렇습니다. 관계 표현력이 높은 API는 미팅 전에 원페이저를 받는 것과 같습니다. 고객사명, 주요 딜, 핵심 담당자, 최근 활동이 관계 구조를 가진 채로 정리되어 있습니다. 미팅에서 질문과 전략에 집중할 수 있죠. 관계 표현력이 낮은 API는 담당자 명함 파일, 딜 히스토리 엑셀, 미팅 노트 폴더를 따로따로 받는 것과 같습니다. 정보의 총량은 비슷할 수 있어요. 그런데 "이 담당자가 저 딜의 의사결정권자인가?"를 파악하려면 세 파일을 직접 대조해야 합니다. 정보를 조립하는 데 시간을 쓰느냐, 정보를 활용하는 데 시간을 쓰느냐의 차이입니다.
(이 주제를 더 깊이 다룬 글이 있습니다 — 4개 CRM의 데이터 모델이 왜 이렇게 다르게 생겼는지를 설계 철학 관점에서 비교한 적 있는데, 각 CRM의 창업 질문이 데이터 구조를 결정했고 그 구조는 20년이 지나도 쉽게 안 바뀝니다.)
응답 크기 제어: 필드 선택, 페이지네이션, 필터링이 되는가
관계 표현력과는 별개의 축이에요. 이게 안 되면 모델이 필요한 정보 10줄을 얻기 위해 1만 줄을 받아야 합니다.
같은 세일즈 상황으로 비유하면, 관계 표현력은 "원페이저에 관계 구조가 정리되어 있느냐"의 문제였다면, 응답 크기 제어는 "고객사 A의 최근 딜 현황을 물었는데 CRM 데이터베이스 전체 백업 파일이 날아오는" 문제입니다. 실제로 경험한 한 B2B CRM에서 목록 엔드포인트에 기본 필터(담당자, 상태, 날짜)가 없어서, "내 담당 딜만"을 가져오려면 전체를 페이지 넘기며 다 불러와야 했습니다. UI에서는 화면 단위로 보여주니까 문제가 안 보였는데, MCP로 감싸서 Claude에 직접 호출시키니 20페이지 넘게 누적되면서 컨텍스트 윈도우가 즉사했습니다.
이 두 축 모두에서 높은 점수를 받는 제품이 AI 시대에 강한 제품이고, UI를 아무리 잘 만들어도 대체할 수 없는 백엔드 아키텍처의 본질적 경쟁력이에요.
그래서 Headless가 가능한 제품과 불가능한 제품이 나뉩니다
Salesforce가 Headless 360을 밀 수 있는 이유가 여기에 있습니다. UI를 걷어내도 뒤에 남는 것이 충분히 강합니다. SOQL이라는 자체 쿼리 언어, 오브젝트 간 relationship이 언어 레벨에서 정의된 데이터 플랫폼 — 이게 있으니까 "UI 없이 API와 MCP만으로 쓰라"고 자신 있게 말할 수 있습니다.
반대로 UI에 의존해서 나쁜 API를 가려온 제품은 headless로 갈 수가 없습니다. 가리개를 벗기는 순간 민낯이 나옵니다.
MCP는 이 headless 전환의 리트머스 시험지입니다. MCP를 붙였을 때 AI가 잘 작동하면 그 제품은 headless-ready입니다. 기존에 UI가 숨겨왔던 결함이 터져 나오면, 그 제품은 아직 UI라는 화장 없이는 세상에 나갈 수 없는 상태입니다.
Anthropic 대담의 조언을 현장 경험으로 보정하면
대담의 모든 조언은 유효합니다. 다만 하나의 전제 조건을 붙여야 합니다.
"description만 잘 쓰면 된다" — 뒤에 있는 시스템이 정확하게 반응할 때 맞습니다.
"도구 1~2개가 낫다" — underlying API가 잘 설계되어 있을 때 맞습니다. 엉성한 API 위에서는 도구를 쪼개고 가드레일을 거는 게 오히려 안전합니다.
"느슨한 계약이 괜찮다" — 제공자 관점에서 맞습니다. 소비자는 명시성을 잃는 대가를 치릅니다.
"MCP 서버 품질이 벤더 경쟁력이 된다" — 방향은 맞지만 더 정확하게 말하면, 제품 아키텍처 품질이 MCP를 통해 비로소 가시화되는 것입니다.
MCP가 새로운 경쟁력을 만드는 게 아니라, 원래 있던 경쟁력의 차이를(UI가 그동안 가려왔던 차이) 드러냅니다. 이 전환을 가장 먼저 체감하는 사람은 SaaS 위에 에이전트를 만들어야 하는 사람들이에요.
AI 시대에 "제품이 잘 만들어져 있다"의 정의가 바뀌고 있습니다. UI가 예쁜 게 아니라, 백엔드 아키텍처와 API가 기계가 읽기에 정확하고 효율적인가로요.
여러분이 사용중인 B2B SaaS의 API 문서를 활용해서 직접 MCP를 붙여보세요. 제품의 민낯이 보일 겁니다.