몇 년에 한 번씩, 소프트웨어 컴포넌트 간 통신 방식을 바꾸는 프로토콜이 등장한다. HTTP가 웹에서 그랬다. OAuth가 인증에서 그랬다. GraphQL이 API에서 그랬다. 2025년, Model Context Protocol — MCP — 이 AI 에이전트 도구에서 그 역할을 하고 있다.
MCP가 해결하는 문제는 겉보기에 단순하다. AI 에이전트는 도구를 사용해야 한다 — 웹 검색, 파일 읽기, 데이터베이스 쿼리, API 호출. 표준 프로토콜 없이는 모든 도구 통합이 커스텀 구현이다. 에이전트 프레임워크가 자체 도구 형식을 정의하고, 도구 제공자가 그 형식을 구현하면, 통합은 그 특정 프레임워크와 그 특정 도구에서만 작동한다. 같은 도구를 다른 프레임워크에서 쓰고 싶다면? 통합을 다시 작성해야 한다. 에이전트에 새 도구를 추가하고 싶다면? 커스텀 어댑터를 작성해야 한다.
MCP는 프레임워크별, 도구별 통합 비용을 제거한다. MCP를 지원하는 도구는 MCP를 지원하는 모든 에이전트에서 작동한다. 한 번 작성하면 어디서나 사용. USB-C 비유가 적절하다 — USB-C 이전에는 모든 기기가 자체 충전기를 가졌다. USB-C 이후에는 하나의 케이블로 모든 것이 된다. MCP가 AI 에이전트 도구에 같은 일을 하고 있다.
MCP가 실제로 무엇인가
MCP는 AI 에이전트가 외부 도구를 발견하고, 호출하고, 결과를 받는 방법을 정의하는 JSON-RPC 기반 프로토콜이다. MCP 서버는 타입이 지정된 스키마를 가진 도구 세트를 노출한다 — 각 도구가 무엇을 하는지, 어떤 매개변수를 받는지, 무엇을 반환하는지에 대한 설명. MCP 클라이언트(에이전트)는 서버에 연결하고, 사용 가능한 도구를 발견하고, 대화 중 필요에 따라 호출한다.
프로토콜은 모든 커스텀 통합이 다시 발명해야 하는 메커니즘을 처리한다: 도구 발견(어떤 도구가 사용 가능한가?), 스키마 검증(매개변수가 올바른가?), 호출(도구를 실행하고 결과를 반환), 오류 처리(도구가 실패하면 어떻게 되는가?). 이것들은 모든 통합마다 다시 풀 필요가 없는 해결된 문제다.
Anthropic이 MCP를 개발하고 오픈소스로 공개했지만, Anthropic 전용 프로토콜은 아니다. 어떤 AI 제공업체든 MCP 클라이언트 지원을 구현할 수 있고, 어떤 개발자든 MCP 서버를 만들 수 있다. 생태계는 빠르게 성장하고 있다 — 이미 GitHub, Slack, 데이터베이스, 파일 시스템, 웹 브라우저 등 수십 개의 서비스를 위한 MCP 서버가 있다.
NanoClaw가 MCP를 사용하는 방법
NanoClaw는 Claude Agent SDK와 같은 Anthropic 도구 체인의 일부인 MCP SDK를 통해 MCP를 통합한다. 에이전트가 NanoClaw 컨테이너 안에서 실행될 때, 호스트가 설정한 MCP 서버에 연결하여 NanoClaw 자체에 커스텀 통합 코드 없이 도구에 접근할 수 있다.
이것은 미묘하지만 중요한 아키텍처 포인트다. NanoClaw는 GitHub 통합, Slack 통합, 데이터베이스 통합을 구현할 필요가 없다. MCP만 지원하면 되고, 그러면 어떤 MCP 서버든 그 기능을 제공한다. 통합 표면이 수십 개의 커스텀 어댑터가 아닌 하나의 프로토콜이다.
실제로 이는 에이전트가 GitHub와 상호작용하길 원하는 NanoClaw 사용자가 GitHub MCP 서버(별도 프로세스)를 설치하고, NanoClaw가 연결하도록 설정하면, 에이전트가 즉시 이슈를 생성하고, 풀 리퀘스트를 읽고, 저장소를 검색할 수 있다는 뜻이다. NanoClaw 코드 변경 없음. Claude Code 스킬 필요 없음. 포크 필요 없음.
컨테이너 격리 모델은 MCP와 자연스럽게 작동한다. MCP 서버는 컨테이너 외부의 호스트에서 실행된다. 컨테이너 안의 에이전트는 제어된 채널을 통해 연결한다. MCP 서버는 자체 접근 제어를 시행할 수 있다 — 저장소 읽기 전용 접근, 특정 Slack 채널만, 특정 데이터베이스 테이블 — 에이전트가 무엇을 요청하든 독립적으로. 이것이 심층 방어다: 프롬프트 인젝션이 에이전트를 속여 해서는 안 되는 것을 요청하게 해도, MCP 서버가 자체 정책에 따라 요청을 거부할 수 있다.
MCP가 생태계에 중요한 이유
MCP의 더 넓은 의미는 도구 개발을 에이전트 개발에서 분리한다는 것이다. MCP 이전에는 유용한 AI 에이전트 도구를 만들려면 프레임워크를 선택하고 그 프레임워크의 도구 인터페이스를 구현해야 했다. GitHub 도구가 LangChain에서는 작동하지만 CrewAI에서는 안 됐다. 데이터베이스 도구가 AutoGen에서는 작동하지만 NanoClaw에서는 안 됐다. 모든 프레임워크가 자체 도구 형식을 가졌고, 도구 개발자는 어떤 프레임워크를 지원할지 선택해야 했다.
MCP가 그 결합을 깨뜨린다. 도구 개발자가 하나의 MCP 서버를 만들면, 모든 MCP 호환 에이전트에서 작동한다. 에이전트 개발자가 MCP를 한 번 지원하면, 모든 MCP 서버가 사용자에게 제공된다. 생태계가 선형이 아닌 곱셈적으로 성장한다 — 모든 새 MCP 서버가 모든 MCP 호환 에이전트에 이익이 되고, 모든 새 MCP 호환 에이전트가 모든 기존 MCP 서버의 혜택을 받는다.
NanoClaw에 구체적으로, MCP는 사용자가 원할 수 있는 모든 서비스에 대한 통합을 만들고 유지할 필요가 없다는 뜻이다. Claude Code 스킬 모델이 채널 통합(Telegram, Discord, Slack)을 처리하고, MCP가 도구 통합(GitHub, 데이터베이스, API)을 처리한다. 둘 사이에서 NanoClaw는 대규모 통합 코드베이스의 유지보수 부담 없이 광범위한 사용 사례를 다룬다.
실용적인 설정
NanoClaw에서 MCP를 설정하는 것은 간단하다. MCP 서버를 실행하고 — 직접 만든 것이든 성장하는 오픈소스 서버 생태계의 것이든 — NanoClaw가 그것을 가리키게 한다. 에이전트가 사용 가능한 도구를 자동으로 발견하고 대화에서 사용할 수 있다.
사용자 관점에서 경험은 매끄럽다. WhatsApp 어시스턴트에게 "어제 논의한 로그인 버그에 대한 GitHub 이슈를 만들어줘"라고 요청하면, 에이전트가 GitHub MCP 서버를 사용하여 이슈를 생성하고, 대화 메모리에서 컨텍스트를 가져와 세부 사항을 채운다. MCP가 관여한다는 걸 알 필요가 없다. 그냥 요청하면, 에이전트가 요청한 것을 할 도구를 가지고 있다.
프로토콜은 아직 초기 단계다 — 2025년 초에 채택이 가속화되기 시작했다 — 하지만 궤적은 명확하다. MCP는 AI 에이전트가 외부 서비스와 상호작용하는 표준 방식이 되어가고 있으며, 일찍 채택하는 프로젝트는 어떤 것도 직접 만들지 않고도 성장하는 도구 생태계에 접근할 수 있다. NanoClaw의 MCP 베팅은 생태계가 어떤 커스텀 통합 세트보다 더 가치 있을 것이라는 베팅이다.