MCP, 조롱받다 부활 — 실무에 붙여보고 남긴 것

한 줄 요약

• MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 2026년 초까지 “설정만 고통스럽고 토큰만 잡아먹는다”며 조롱받았지만, 하반기 들어 공개 서버가 1만 개를 넘고 대형 벤더가 나란히 채택하면서 사실상 표준이 됐다. 결론부터 말하면 “다 붙이면 손해, 골라 붙이면 이득”인 도구다.

MCP는 2026년 초까지만 해도 조롱의 대상이었다. “설정만 고통스럽고 토큰만 잡아먹는다”는 얘기가 커뮤니티에 흔했다. 그런데 하반기 들어 공개 서버가 1만 개를 넘고 OpenAI·구글·마이크로소프트가 나란히 채택하면서 흐름이 뒤집혔다. 결론부터 말하면, MCP는 “다 붙이면 손해, 골라 붙이면 이득”인 도구다. 나는 여러 MCP 서버(검색·파일·메신저 연동 등)를 실무에 붙여보며 검색·파일 연동은 남기고, 상시 로딩되는 무거운 서버는 버렸다. 도구를 붙일 때마다 “이게 내 컨텍스트에서 자리값을 하느냐”를 되물었고, 이 글은 조롱과 부활 사이에서 그 문답으로 뭘 남기고 뭘 버렸는지 정리한 회고다.

MCP는 대체 뭐고, 언제 나왔나?

MCP는 AI 앱과 외부 데이터·도구를 잇는 개방형 표준이다. 앤트로픽이 2024년 11월 25일 오픈소스로 공개했고, AI 모델이 파일·검색·외부 서비스에 안전하게 양방향으로 연결되도록 하는 것이 목표다. 흔히 “AI용 USB-C”에 비유한다. 예전에는 연동할 대상마다 커스텀 코드를 따로 짜야 했는데, 그 자리를 하나의 프로토콜이 대신하는 셈이다.

이 비유가 그냥 홍보 문구만은 아니다. 예전엔 도구마다 붙이는 코드가 제각각이라 모델을 바꾸면 연결을 처음부터 다시 짜야 했다. MCP는 그 접점을 규격 하나로 통일해, 도구를 만드는 쪽과 쓰는 쪽을 분리한다. 그 분리가 바로 뒤에서 다룰 “레지스트리”와 “대형 벤더 채택”이 가능해진 전제다.

구조는 단순하다. 호스트 앱(클라이언트)이 여러 MCP 서버에 연결되고, 각 서버가 특정 도구나 데이터를 노출한다. 클라이언트는 도구 목록을 받아 모델에게 넘기고, 모델이 그중 하나를 고르면 호출을 해당 서버로 중계한다. 여기서 중요한 건 서버 하나가 곧 도구 한 묶음이라는 점이다. 서버를 하나 붙인다는 건 그 서버가 노출하는 도구 전부를 컨텍스트에 얹는다는 뜻이고, 이 사실이 나중에 “무거운 서버는 왜 버렸나”의 핵심이 된다. 초기 파트너로 Block, Apollo, Zed, Replit, Sourcegraph 같은 곳이 이름을 올렸다.

공개 이후의 흐름을 시간순으로 놓으면 부활의 밑그림이 보인다. 2024년 11월 공개, 2025년 9월 공식 레지스트리 프리뷰, 2025년 12월 재단 기부로 이어지는 궤적이다. 하나씩 떼어 보면 사소하지만, 이어 놓으면 “한 회사의 실험”이 “여럿이 기대는 표준”으로 옮겨간 이동선이 드러난다.

MCP는 왜 조롱받았나?

가장 큰 불만은 토큰 오버헤드였다. 도구 스키마가 매 호출마다 컨텍스트에 직렬화돼 들어가서, 사용자가 첫 메시지를 보내기도 전에 이미 수천 토큰을 쓰는 구조다. 일부 사례에선 도구 메타데이터가 가용 컨텍스트의 40～50%를 잡아먹었다는 보고도 있었다. 나도 서버를 서너 개만 붙여도 컨텍스트가 훅 줄어드는 느낌을 받았다. 얄미운 건 쓰지도 않은 도구에까지 비용이 붙는다는 점이었다. 서버 하나에 도구가 열 개 딸려 있으면 그중 하나만 쓰려 해도 열 개 전부의 이름·설명·인자 스키마가 매 턴 컨텍스트에 실린다. 실제로 부르는 도구가 한둘뿐인데도 나머지 명세가 자리를 차지하니, 붙인 서버가 늘수록 이 낭비가 겹으로 쌓였다.

그래서 2026년 상반기에는 MCP 대신 전통적인 API나 CLI(Command Line Interface, 명령줄 인터페이스)로 돌아가는 흐름이 있었다. “그냥 CLI 한 줄 호출이 싸고 빠르다”는 실리론이었고, 일부 유명 개발자와 기업이 이탈을 공개적으로 밝히기도 했다(대표적으로 퍼플렉시티 CTO의 이탈 발언이 회자됐다). 이 실리론에는 뼈가 있었다. 다만 한 번 쓰고 말 작업이면 CLI가 가볍지만 같은 동작을 반복하고 인자가 복잡한 작업이면 얘기가 달라지는데, 조롱의 상당 부분은 이 구분 없이 “MCP는 무겁다”를 통째로 결론 낸 데서 왔다고 본다.

설정과 인증의 고통도 컸다. MCP는 “인증은 각자 알아서” 쪽에 가까운 구조라, 혼자 로컬에서 쓸 때는 몰라도 팀이나 엔터프라이즈로 넘어가면 마찰이 생긴다. 누가 어떤 서버에 어떤 권한으로 붙는지, 키를 어떻게 공유하고 회수하는지를 프로토콜이 강제하지 않으니 각 팀이 알아서 얼개를 세워야 했고, 그 초기 비용이 “설정만 고통스럽다”는 인상으로 남았다. 조롱은 대체로 이 세 지점 — 토큰, CLI 대비 실리, 설정 고통 — 에 몰려 있었고, 셋 다 근거 없는 트집은 아니었다.

그런데 왜 다시 살아났나?

첫 신호는 레지스트리 통합이었다. 공식 MCP 레지스트리가 2025년 9월 8일 프리뷰로 나왔다. 앤트로픽·GitHub·PulseMCP·마이크로소프트 등이 함께 만들었고, 흩어져 있던 공개 서버를 발견하고 설치하는 과정을 표준화했다.

이게 왜 판을 바꿨는지는 “발견 비용”으로 읽어야 이해된다. 그전까지 쓸 만한 MCP 서버를 찾는 일은 커뮤니티 링크와 개인 정리글을 뒤지는 수작업이었고, 어느 게 관리되고 어느 게 방치됐는지 판단하기도 어려웠다. 레지스트리는 그 탐색을 한곳으로 모아, 만드는 쪽엔 발견될 기준점을 쓰는 쪽엔 찾을 출발점을 줬다. 규격만 있고 목록이 없던 상태에 목록이 붙은 셈이라, 표준이 굴러가려면 이 목록이 규격 못지않게 중요했다.

규모도 커졌다. 앤트로픽 2025년 12월 집계 기준으로 공개 MCP 서버는 1만 개를 넘어섰다. 서드파티 인덱스는 그보다 더 많은 수를 세기도 하는데, 집계 방식에 따라 중복과 편차가 있어 여기서는 “1만 개 이상”만 단정한다. 수 자체보다 의미가 큰 건 이 규모가 “붙일 게 없어서 못 쓰는” 상황을 끝냈다는 점이다. 웬만한 연동 대상은 이미 누군가 만들어 뒀을 확률이 높아져, 직접 짜는 대신 골라 쓰는 쪽으로 무게가 옮겨갔다.

거버넌스도 벤더 중립 쪽으로 넘어갔다. 2025년 12월 앤트로픽이 MCP를 리눅스 재단 산하 Agentic AI Foundation에 기부했다. 특정 회사의 프로젝트에서 공동 표준으로 무게가 옮겨간 셈이다. 한 회사가 쥔 규격에 인프라를 얹으면 그 회사의 방향 전환에 내 구성이 휘둘리는데, 중립 재단으로 넘어갔다는 건 “지금 투자해도 한 벤더의 변덕으로 갈아엎을 위험이 줄었다”는 신호였다.

무엇보다 대형 벤더의 채택이 흐름을 굳혔다. OpenAI는 2025년 3월 Agents SDK를 공개하고 Responses API에서 원격 MCP를 지원하기 시작했고, 구글·마이크로소프트·AWS까지 지원 대열에 합류했다. OpenAI Assistants API가 2026년 8월 26일 종료 예정이라는 점도 방향을 상징적으로 보여준다. 이게 실무자에게 왜 큰지는 잠금 해제로 읽힌다. 벤더마다 자기 방식으로 도구를 붙이던 시절엔 모델을 바꾸면 연동을 다시 짜야 했는데, 여럿이 같은 프로토콜을 지원하면 한 번 만든 도구를 여러 모델에 그대로 물릴 수 있다. 채택 하나하나가 “MCP에 시간을 쓸 이유”를 키운 셈이라, 사실상 표준이라는 말이 과장으로 들리지 않는다.

그래서 실무에 뭘 붙였나?

남긴 것은 호출 빈도가 높고 스키마가 가벼운 서버였다. 검색 연동, 파일·문서 접근 계열이 여기에 해당한다.

판단 기준은 세 가지로 정리됐다. 첫째, 컨텍스트 비용 대비 실제 사용 빈도가 높은가. 둘째, CLI로 대체 가능하면 CLI를 먼저 쓴다. 셋째, 인증이 로컬 수준에서 안전하게 닫히는가. 이 세 질문을 순서대로 통과한 것만 붙였다.

첫 번째는 빈도와 무게의 저울질이다. 검색 연동을 왜 남겼는지가 이 기준의 교과서다. 검색은 한 세션에서 몇 번이고 부르고 그 결과가 이후 판단의 재료가 되니 빠지면 티가 크게 나는데, 얹는 스키마는 “질의를 넣으면 결과를 준다”는 구조라 짧게 끝난다. 자주 쓰는데 자리값은 작으니 상시 비용을 호출 빈도가 여러 번 갚는 셈이다. 반대로 세션당 한두 번 쓸까 말까 한 도구가 무거운 스키마를 달고 있으면 저울이 반대로 기운다. 즉 “많이 쓰냐”가 아니라 “얹어 두는 값을 쓰는 횟수가 갚느냐”가 이 기준의 알맹이다.

두 번째는 CLI 우선 원칙인데, 상황을 갈라서 봐야 정확하다. 한 번 하고 말 작업이라면 스키마를 상시 얹을 이유가 없으니 CLI가 이긴다. 하지만 같은 동작을 반복하고 인자가 복잡해 모델이 매번 형식을 틀릴 만한 작업이라면, CLI로 두면 명령을 조립하다 실수를 내지만 MCP로 감싸면 스키마가 그 형식을 붙들어 준다. 로컬 대 팀의 구분도 겹친다. 혼자 쓰는 로컬 작업은 손에 익은 CLI가 빠르지만, 여러 사람이 같은 동작을 반복하는 팀이라면 각자 제 방식으로 치는 것보다 같은 명세를 공유하는 MCP 쪽이 결과가 고르다. 즉 “CLI를 항상 우선”이 아니라 “1회성·로컬이면 CLI, 반복·팀이면 MCP”가 정확하다.

세 번째는 인증이 로컬 수준에서 닫히는가다. 앞서 조롱의 한 축이 인증 고통이었는데, 그 고통이 바로 이 기준의 뒷면이다. 내 키를 내 환경에 두고 그 범위에서 끝나는 서버는 마음 편히 붙였다. 반대로 외부에 별도 인증 체계를 세우거나 남의 자격 증명을 대신 쥐어야 하는 서버는 붙이는 순간 관리할 표면이 넓어진다. 키가 새면 어디까지 열리는지, 회수는 어떻게 하는지를 다 떠안기 때문이다. 편의가 아니라 사고 때의 폭을 재는 질문이라, 앞의 두 기준을 통과해도 여기서 걸리면 붙이지 않았다.

붙이는 방식도 절제했다. 상시 로딩 대신 필요할 때만 켜는 구성으로 두면 오버헤드가 크게 준다. 세 기준을 통과한 서버라도 매 순간 필요한 건 아니다. 검색은 조사하는 작업에서만, 파일 접근은 문서를 다루는 작업에서만 쓰는데 상시 로딩은 이 맥락을 무시하고 언제나 전부를 얹는다. 선택적 활성화는 등록은 해 두되 평소엔 물지 않으니, 목록에서 사라지지 않으면서도 자리값은 필요할 때만 낸다. 이렇게만 해도 컨텍스트 여유가 눈에 띄게 달라졌고, 도구 목록이 짧아지니 모델이 엉뚱한 도구를 고르는 일도 줄었다.

그럼 뭘 버렸나?

버린 것은 상시 켜두면 토큰만 먹는 무거운 서버였다. CLI 한 줄로 끝나는 일에 굳이 얹은 MCP도 걷어냈다. 원칙은 하나다. “붙일 수 있다”와 “붙여야 한다”는 다르다. 도구 수가 늘수록 모델이 올바른 도구를 고르는 정확도와 컨텍스트 여유가 함께 줄어든다. 이 정확도 문제는 토큰 낭비보다 더 은근했다. 비슷한 이름의 도구가 여럿 떠 있으면 모델이 결이 다른 도구를 집는데, 낭비는 눈에 보이지만 오선택은 결과가 틀어진 뒤에야 알아채기 쉬워 더 성가셨다. 그래서 버리는 결정은 “이 서버가 손해냐”만이 아니라 “다른 서버의 선택까지 흐리지 않느냐”까지 봤고, 하나를 덜어내면 남은 것들이 더 또렷해졌다.

보안 경계도 버릴 것을 가르는 기준이 됐다. MCP에는 프롬프트 인젝션과 툴 포이즈닝 위험이 따라온다. 툴 포이즈닝은 도구 메타데이터에 명령을 숨겨 두는 방식으로, 클라이언트 쪽에서 가장 흔한 취약점으로 꼽히고 OWASP에도 등재돼 있다. 왜 무서운지는 구조를 뜯어보면 보인다. 모델은 도구의 설명을 읽고 판단하는데, 그 설명 자체가 모델에게 먹이는 입력이다. 악의적인 서버가 설명 안에 지시를 심어 두면 모델이 그걸 사용자 의도로 착각하고 따를 수 있다. 데이터로 취급해야 할 것이 명령으로 새는 통로다.

그래서 나는 절차를 앞단에 뒀다. 출처가 불분명하거나 관리 이력이 얕은 서드파티 서버는 편의가 아무리 좋아도 후보에서 뺐고, 붙일 서버라면 노출하는 도구 설명을 실제로 읽어 “왜 이런 지시를 품고 있지” 싶은 대목이 걸리면 거기서 멈췄다. 클라이언트에 어떤 가드레일이 있는지 — 도구 호출 전에 확인을 요구하는지, 위험한 동작을 걸러 내는지 — 도 먼저 확인했다. “이 서버가 내 판단을 조용히 대신 내릴 여지가 있는가”를 앞에서 닫아 두는 절차였다.

지금 MCP를 붙일지 고민한다면?

돌아보면 조롱도 부활도 절반씩 맞았다. 토큰 오버헤드와 설정 고통은 실재했고, 레지스트리와 표준화라는 부활 신호도 분명했다. 문제는 “MCP냐 아니냐”가 아니라 “어디까지 붙이냐”였다. 조롱하던 쪽은 무거운 서버를 다 붙여 놓고 손해를 봤고 부활을 반긴 쪽 중 일부는 골라 붙였을 뿐이니, 결론이 갈린 건 도구 탓이 아니라 붙이는 방식 탓이었다.

붙일지 말지 고민이라면 세 줄만 물어보면 된다. 호출 빈도가 높은가. CLI로는 안 되나. 인증이 안전하게 닫히나. 이 셋을 통과하면 붙이고, 하나라도 걸리면 미룬다. 붙이기로 한 것도 상시가 아니라 필요할 때만 켜 두면 남긴 서버조차 자리값을 최소로 낸다.

표준화가 어느 정도 끝난 지금은 “쓸까 말까”보다 “어떻게 절제할까”가 더 실전적인 질문이다. 다음에는 컨텍스트 비용과 보안을 좀 더 파고들어, 선택적 활성화 구성과 서드파티 서버 검증을 실제 절차 단위로 다시 점검해볼 생각이다.

이 글은 AI 업무 자동화 허브의 ‘도구 연결(에이전트)’ 단계 사례다.

참고 자료

• MCP 최초 공개 시점과 정의, 초기 파트너를 확인했다 — Anthropic 공식 발표
• 공식 레지스트리 출시일과 공동 주체를 확인했다 — MCP Registry 프리뷰
• OpenAI의 MCP 채택과 원격 MCP 지원, Agents SDK를 확인했다 — OpenAI Agents SDK 문서
• 구글·마이크로소프트·AWS 등 대형 벤더 지원과 재단 기부 흐름을 확인했다 — WorkOS MCP 2026 정리
• 토큰 오버헤드 사례와 2026 상반기 CLI 회귀 흐름을 확인했다 — Versalence MCP 진화 분석
• 툴 포이즈닝이 흔한 클라이언트측 취약점임과 대응을 확인했다 — OWASP MCP Tool Poisoning
• MCP 스펙의 보안 방어 부재와 프롬프트 인젝션 위험을 확인했다 — Practical DevSecOps MCP 보안

_{기준 시점 2026년 7월 25일 확인. 익명화한 개인 실무 경험을 바탕으로 정리했고, 시점·수치·출처는 사람이 1차 출처로 재검수했다. 공개 서버 수(1만 개 이상)·CLI 회귀 흐름·재단 기부·Assistants API 종료일 등 2차 출처에 기댄 항목은 단정을 피해 “일부 집계”로 완화했으며, 실제 채택 범위와 정책은 벤더·버전·시점에 따라 달라질 수 있으니 적용 전 각 제공자의 최신 문서를 다시 확인해야 한다.}