MCP란 무엇이며, 왜 모든 AI 도구가 갑자기 그것을 말하기 시작했나
지난 10년의 대부분 동안, AI 모델을 회사 도구에 연결한다는 것은 쌍마다 맞춤 통합을 만든다는 뜻이었다. Anthropic이 2024년 11월에 내놓은 공개 표준 Model Context Protocol은 그 자리를, 어디에나 맞는 하나의 플러그로 바꿨다. OpenAI, Google, Microsoft도 그 이후 이를 채택했다. 실제로 어떻게 작동하는지, 그리고 팀 데이터에 하나를 연결하기 전에 확인할 진짜 체크리스트를 정리한다.
Claude 데스크톱 앱을 열고 팀의 열린 풀 리퀘스트를 확인해 달라고 하면, 그냥 그렇게 한다. Anthropic이 Claude 안에 GitHub 통합을 넣어서가 아니다. 어딘가에서 — 사내 IT, 공급업체, GitHub의 개발자 — 누군가가 MCP라는 프로토콜을 말하는 작은 프로그램을 썼고, Claude는 이미 그것을 말하는 무엇과도 대화할 줄 알기 때문이다. 이제는 ChatGPT, Google의 Gemini, Microsoft Copilot도 마찬가지다. 개별 기능 출시보다, 바로 이 수렴이 거의 모든 AI 공급업체가 지난 한 해 동안 MCP 지원을 만드는 데 시간을 쓴 이유다.
MCP가 실제로 무엇인가
MCP는 Model Context Protocol의 약자다. Anthropic이 설계했고, 2024년 11월 25일 명세와 첫 SDK를 오픈소스로 공개했다. 발표 자료는 남는 비유로 이 생각을 설명했다. MCP를 AI 애플리케이션을 위한 USB-C 포트로 생각하라는 것이다. 액세서리마다 다른 케이블이 아니라, 물리적 커넥터의 표준 하나. 출시 시점에 Anthropic은 자사 제품에 MCP 지원을 이미 넣고 있던 초기 채택자로 엔터프라이즈 소프트웨어 회사 Block과 Apollo, 개발자 도구 제작사 Zed, Replit, Codeium, Sourcegraph를 지목했다. Claude 데스크톱 앱은 같은 날, 한 사람의 자기 컴퓨터에서 MCP 서버를 로컬로 실행할 수 있는 상태로 나왔다.
이것이 푸는 문제: N개의 도구 곱하기 M개의 데이터 소스
MCP가 푸는 문제에는 엔지니어가 가볍게 부르는 이름이 있다. N 곱하기 M 통합 문제다. 한 회사가 회사 데이터에 작용해야 하는 AI 도구를 다섯 개 쓴다고 하자. Claude, ChatGPT, GitHub Copilot, Cursor, 내부 지원 봇. 그 데이터는 여덟 곳에 있다. Slack, GitHub, Postgres 데이터베이스, Salesforce, Notion, Google Drive, Jira, 내부 API. 공유 프로토콜이 없으면, 모든 도구를 모든 소스에 쓸모 있게 연결하는 데 최대 마흔 개의 별도 통합이 필요하다. 다섯 곱하기 여덟이다. 각각 자기 인증 방식, 자기 오류 처리, 그리고 그 API 중 하나의 모양이 바뀔 때마다 드는 자기 유지보수 비용이 있다. 여섯 번째 AI 도구를 더하면 숫자는 마흔여덟으로 뛴다. 실제로는 아무도 마흔 개를 다 만들지 않았다. 각 AI 공급업체는 엔지니어링 시간을 들일 만하다고 본 몇 개만 만들었고, 나머지는 수동으로 남았다. 복사하고, 붙여넣고, 다시 설명하고, 반복한다.
MCP는 곱셈을 덧셈으로 바꾼다. Claude가 자사 Postgres를 읽게 하려는 회사는 Claude 전용 Postgres 커넥터를 만들지 않는다. Postgres를 노출하는 MCP 서버를 하나 만들거나, 다른 사람이 이미 공개한 것을 재사용한다. 그 서버는 추가 코드 없이 Claude, ChatGPT, Gemini, 그 밖의 MCP 호환 에이전트와 동작한다. Anthropic 자신의 목록은 출시 시점에 Google Drive, Slack, GitHub, Git, Postgres, 그리고 Puppeteer라는 브라우저 자동화 도구용 사전 구축 서버를 적었다. 요점은 Anthropic이 전부를 만들겠다는 것이 아니었다. 누구든 만들 수 있다는 것이고, 쓸 수 있는 서버 목록은 한 회사가 인력으로 감당할 수 있는 범위를 훨씬 넘어 자랐다.
프로토콜이 실제로 어떻게 작동하나
틀을 걷어내면 MCP는 꽤 평범한 클라이언트-서버 프로토콜이고, 일부러 화려하지 않다. 역할은 세 가지다. Host는 사람이 실제로 여는 애플리케이션이다. Claude Desktop, Cursor 같은 IDE, ChatGPT 앱. Host는 MCP Client를 품고, 그 클라이언트가 MCP Server로 직접적이고 상태를 유지하는 연결을 연다. MCP Server는 특정 시스템 하나를 노출하는 작은 프로그램이다. 데이터베이스, 티켓 도구, 파일 시스템, 내부 API. 클라이언트와 서버는 JSON-RPC 2.0 형식의 메시지를 주고받는다. 기존 인프라에서도 흔한, 가벼운 원격 프로시저 호출 형식이다. 전송은 둘 중 하나다. stdio는 서버가 같은 컴퓨터에서 로컬로 도는 프로그램일 때, Streamable HTTP는 다른 곳에서 도는 호스팅 서비스일 때다.
서버가 노출할 수 있는 것은 세 가지 프리미티브로 좁혀진다. Tools는 모델이 행동을 위해 호출할 수 있는 함수다. create_task, run_query, send_message. 언제 하나를 호출할지는 대화에 따라 모델이 정한다. Resources는 모델이 묻지 않아도 Host가 가져와 모델에 넘길 수 있는 읽기 전용 맥락이다. 파일 내용, 데이터베이스 스키마, 지원 티켓. Prompts는 사람이 명시적으로 부르는 재사용 템플릿이다. "이 스레드를 요약해" 또는 "상태 업데이트를 초안해" 같은 정해 둔 문장을, 모델이 스스로 하기로 하는 것이 아니라 사람이 호출한다. 잘 만든 서버는 주어진 능력에 대해 셋 중 무엇을 내놓는지 분명히 한다. 그 구분이, 연결된 AI 도구가 무언가를 보기만 하는지 바꿀 수도 있는지를 정확히 결정하기 때문이다.
누가 또 받아들였고, 언제였나
MCP의 처음 몇 달은 Anthropic만의 프로젝트였다. 그것은 빨리 바뀌었고, AI에서는 정말 드문 방식으로 바뀌었다. 직접 경쟁자들이 자기 프로토콜을 내는 대신 한 회사의 프로토콜로 모였다. OpenAI는 2025년 3월 Agents SDK에 MCP 지원을 넣어, 개발자가 OpenAI 전용의 맞춤 도구 통합을 만드는 대신 어떤 MCP 서버에든 에이전트 워크플로를 연결할 수 있게 했다. 다음 달 Google DeepMind는 Gemini와 자사 에이전트 개발 키트도 MCP를 지원한다고 확인했다. Google은 이 움직임을 보완 프로토콜 Agent2Agent와 짝지었다. 독립된 에이전트들이 도구가 아니라 서로와 조율하게 하려는 것이다. 2025년 5월까지 Microsoft는 Windows AI Foundry라 부르는 것을 통해 Windows 11에 네이티브 MCP 지원을 넣었고, GitHub Copilot과 Copilot Studio에도 지원이 들어갔다.
이 네 회사는 모델 아키텍처, 가격, 플랫폼 전략에 관해서는 거의 동의하지 않는다. 그래도 네 회사 모두 이제 에이전트를 도구에 연결하기 위해 같은 프로토콜을 말하는 제품을 내놓는다. 이 업계에서는 그것만으로도 충분히 드물고, 개별 기능보다 이쪽이 실제 이야기다.
왜 이것은 배관이 아니라 신뢰의 문제인가
그 수렴은 정말 유용하고, 바로 그 때문에 MCP는 맹목적 신뢰가 아니라 검증을 받을 만하다. 에이전트가 회사 시스템에 연결되는 일을 사소하게 만드는 프로토콜은, 잘못 만들거나 잘못 설정한 연결이 같은 시스템에 닿는 일도 사소하게 만든다. MCP 자체는 그것을 막지 않는다. 명세는 클라이언트와 서버가 어떻게 말하는지 정할 뿐이다. 누가 연결을 허락할 수 있는지, 그 연결이 무엇을 건드릴 수 있는지, 뭔가 잘못되면 누가 알아차릴지는 말하지 않는다. 그 선택은 눈앞의 특정 서버나 클라이언트를 만들거나 설정한 쪽에 온전히 있다. 어떤 공급업체는 이 전부를 신중히 만든다. 어떤 곳은 아예 만들지 않는다. 프로토콜은 후자를 멈추지 않는다.
MCP는 배선 프로토콜이지, 접근 제어 시스템이 아니다. 에이전트가 도구에게 무언가를 해 달라고 요청하는 방식을 표준화한다. 그 요청이 범위가 정해지고, 기록되고, 철회 가능한지는 그 위에서 누군가가 내린 — 또는 내리지 않은 — 결정이다.
하나를 연결하기 전의 체크리스트
팀이 MCP 서버를 연결하기 전에 — 공급업체 제품이든, GitHub에서 찾은 오픈소스 도구든, 내부에서 만든 것이든 — 여섯 가지 질문이 통제된 연결과 열린 문을 가른다. 어느 것도 명세를 읽을 필요는 없다. 승인 버튼을 누르기 전에 누군가 묻고, 연결 화면이 돌려주는 답을 실제로 읽기만 하면 된다.
| 이것을 묻는다 | 좋은 모습 | 경계할 점 |
|---|---|---|
| 어떤 범위나 tools를 요청하는가 | 항목화 승인 전에 읽을 수 있는, 이름이 붙은 구체적인 목록. "작업을 만들고, 이 채널의 메시지를 읽는다." | 일괄 "계정 전체 접근". 실제로 무엇을 할 수 있는지에 대한 목록이 없다. |
| 읽기 전용인가, 쓰고 행동할 수도 있는가 | 분리 기본은 읽기. 데이터를 바꾸는 동작은 각각 눈에 보이는 허가가 필요하다. | 묶음 쓰기 접근이 자동으로 포함되고, 어느 능력이 무엇을 하는지 알 수 없다. |
| 사람별인가, 팀 전체 공유인가 | 사람별 각자 자기 로그인으로 들어간다. 에이전트는 그 사람이 볼 수 있는 것만 본다. | 공유 팀 전체가 쓰는 API 키나 서비스 계정 하나로, 개인 권한을 우회한다. |
| 무엇을 했는지에 대한 감사 로그가 있는가 | 기록됨 도구 호출마다 남는다. 누가 연결했고, 무엇을 건드렸고, 언제였는지. | 기록 없음 AI 도구 자신이 일어났다고 말하기로 고른 것 외에는 기록이 없다. |
| 즉시 철회할 수 있는가 | 즉시 내가 관리하는 설정 화면의, 바로 적용되는 스위치 하나. | 지연 철회에 지원 티켓이나 공급업체 통화가 필요하거나, 아예 불가능하다. |
| 철회하면 다른 것도 깨지는가 | 격리 그 연결 하나로 한정된다. 끄면 영향은 그것뿐이다. | 얽힘 다른 도구와 자격 증명을 공유해서, 하나를 철회하면 다른 세 개가 조용히 깨진다. |
잘 만든 연결은 실제로 어떻게 생겼나
FabricLoop 자신의 MCP 구성은 그 체크리스트에 대한 구체적인 답이다. 특이해서가 아니라, 각 조각이 위의 여섯 질문에 직접 대응하고, 마케팅 버전이 아니라 실제 작동을 이름 붙일 가치가 있기 때문이다. FabricLoop는 두 역할을 동시에 한다. 바깥 도구가 연결해 들어오는 MCP 서버여서, Cursor, Claude, ChatGPT가 특정 사람 자신의 FabricLoop 권한으로 작업을 만들고, 댓글을 달고, 노트를 읽을 수 있다. 동시에 바깥으로 연결하는 MCP 클라이언트여서, 채널이 GitHub나 Linear 같은 공급업체의 MCP 앱을 들여오고 팀원처럼 @멘션할 수 있다.
어느 방향의 연결이든, 워크스페이스가 아니라 사람에서 시작한다. Cursor 같은 외부 클라이언트를 연결하면 app.fabricloop.com/oauth/consent에서 OAuth 동의 화면이 열린다. 그 사람이 워크스페이스를 고르고, 클라이언트가 요청하는 구체적인 tools를 승인한다. 그 다음 클라이언트는 그 화면에서 부여된 범위 안에서, 그 한 사람의 권한으로만 행동할 수 있다. 공유 서비스 계정으로는 안 된다. 반대 방향도 같다. 관리자가 공급업체의 MCP 앱을 팀 전체에 켤 수 있다. 그래도 각 사람이 자기 로그인을 마쳐야 그 사람에게 작동하고, 관리자는 그 앱을 읽기 전용으로 두거나 공급업체가 노출하는 전부 대신 특정 tools의 허용 목록으로 제한할 수 있다.
연결된 클라이언트는 모두 설정 화면에 나타나고, 바로 끊는 철회 컨트롤이 옆에 있다. 지원 티켓이 아니라 그 사람 자신의 페이지다. Enterprise 요금제에서는 그 활동 — MCP 허가와 연결된 에이전트가 실제로 한 일 — 이 보안 팀이 필요할 때 볼 수 있는 감사 로그에 들어간다. 일이 지난 뒤 채팅 스레드에서 스크린샷을 꺼내는 방식이 아니다.
이 중 어느 것도 특별한 엔지니어링이 아니다. 작고, 일부러 화려하지 않은 결정의 묶음을 일관되게 반복할 뿐이다. 범위를 정하고, 사람에게 묶고, 기록하고, 부수 피해 없이 철회할 수 있게 한다. 이 사이트가 Legibility에 대해 더 넓게 하는 주장과 같다. 이름을 붙이고, 기록하고, 철회할 수 있는 접근이, 아무도 생각할 필요가 없는 접근보다 낫다. MCP가 그것을 내놓는 것은 누군가가 그렇게 만들었을 때뿐이다. 프로토콜은 배관을 표준으로 만든다. 거버넌스를 자동으로 만들지는 않는다.
실제로 중요한 결정
MCP는 사라지지 않는다. 이 시점에 반대하는 것은 USB에 반대하는 것과 조금 비슷하다. 주요 모델 제공자는 이제 모두 이것을 내놓고, 쓸 수 있는 서버 목록은 계속 늘며, 도구에 닿지 못하는 에이전트는 실제 일의 대부분에서 할 수 있는 일이 많지 않은 에이전트다. 흥미로운 결정은 AI 도구가 우리 시스템에 연결되게 둘지 여부가 아니다. 그 결정의 어떤 버전은 이미 여러분 대신 내려지고 있다. 팀이 이미 쓰는 도구가, 작은 글씨를 읽지 않고 클릭한 기능 아래에서 MCP 지원을 통합 하나씩 조용히 더하고 있기 때문이다. 아직 정말로 여러분의 것인 결정은, 승인을 클릭하기 전에 무엇을 확인하느냐다.
MCP는 AI 에이전트가 도구에게 무언가를 해 달라고 요청하는 방식을 표준화했다. 그 요청을 허락해도 안전한지는 아무것도 표준화하지 않았다. 그 부분은 지금도, 앞으로도, "승인"을 클릭하는 사람의 결정으로 남는다.