Model Context Protocol (MCP)

MCP는 무엇을 위한 것인가

공통 규약이 없던 시절에는 어시스턴트와 도구의 모든 조합이 각각의 통합이었습니다. 두 번 만들고 영원히 유지해야 했지요. 어시스턴트 다섯에 도구 스무 개면 맞춤 연결이 백 개가 됩니다. MCP는 이것을 곱셈에서 덧셈으로 바꿉니다. 도구를 만드는 쪽은 서버를 하나 쓰고, 애플리케이션을 만드는 쪽은 클라이언트를 하나 쓰면, 한쪽의 무엇이든 반대쪽의 무엇과도 이야기할 수 있습니다. Anthropic이 2024년 말에 개방형 표준으로 공개했고 이후 그 범위를 훨씬 넘어 채택되었습니다. 제품 API보다는 장치 드라이버 인터페이스에 가깝습니다. 가치는 무엇을 할 수 있느냐가 아니라 모두가 형태에 합의했다는 데 있습니다.

구조는 클라이언트·서버입니다. 모델을 품은 애플리케이션이 클라이언트이고, 드러내고 싶은 기능은 각각 서버로 돌면서 무엇을 제공하는지 기계가 읽을 수 있는 형태로 설명합니다. 그래야 모델이 선택지를 보고 고를 수 있습니다. 전송 방식에는 매이지 않아 같은 기계의 로컬 프로세스일 수도 있고 HTTP로 닿는 것일 수도 있습니다. 그래서 같은 통합이 데스크톱 어시스턴트에서도, 서버에서 도는 AI 에이전트에서도, 코딩 도구에서도 다시 쓰지 않고 작동합니다.

서버가 드러내는 것

서버가 제공하는 것은 세 종류이고, 직접 만들 때 이 구분이 중요해집니다.

• 도구 — 모델이 호출할 수 있는 행동. 메시지 보내기, 테이블 조회, 레코드 생성. 결과가 따르는 쪽이며 조심해야 할 대상입니다.
• 리소스 — 클라이언트가 맥락으로 끌어올 수 있는 데이터. 파일, 문서, 한 행, 페이지의 내용. 모델이 하는 일이 아니라 모델에게 주어지는 읽기 전용 재료입니다.
• 프롬프트 — 사람이 의도적으로 고르는 재사용 가능한 매개변수화된 지시. 모델이 스스로 손을 뻗는 것이 아닙니다.

규약이 해결하지 못하는 것

연결 표준은 배관을 걷어낼 뿐, 어려운 부분은 그대로 남깁니다. 실무에서 가장 먼저 만나는 사실은 도구를 갖는 일이 공짜가 아니라는 것입니다. 모델이 호출할 수 있는 모든 기능은 모델에게 설명되어야 하고, 그 설명은 실제 작업과 같은 제한된 맥락을 차지합니다. 목록이 커질수록 조용히 과제와 자리를 다투는 셈입니다. AgentCeres — agentceres.com의 AI 그로스 오피서 — 에서 고객용 에이전트를 만들며 바로 이 지점에 부딪혔습니다. 사용 가능한 기능이 일정 수를 넘으면 목록 자체를 요약해야 겨우 들어가고, 그 말은 통합을 하나 더하는 일이 아무도 쓰지 않아도 무언가를 소모한다는 뜻입니다. 결국 공학적 규율은 에이전트가 무엇에 닿아서는 *안 되는지*를 정하는 일이었습니다.

두 번째 빈틈은 권한입니다. 규약은 도구를 어떻게 부르는지 설명하지만, 이 에이전트가 이 고객을 대신해 지금 그렇게 해도 되는지는 말하지 않습니다. 스프레드시트를 읽는 도구와 회사 소셜 계정에 게시하는 도구는 규약이 보기에 동일하고 사업이 보기에 완전히 다릅니다. 그 경계는 각자의 제품 안에 있어야 하고, 그래서 우리 쪽에서 공개적 결과가 따르는 일은 기능이 어떻게 연결되었든 사람이 지키는 승인 게이트 앞에서 기다립니다.