MCP는 REST를 대체하는 것이 아닙니다. 에이전트가 도구를 사용하는 방식에 대한 사고 모델 전체를 바꾸는 것입니다.

REST는 서비스를 호출하기 위해 코드를 작성하는 인간을 위해 설계되었습니다. 문서를 읽고, 클라이언트를 작성하고, 배포합니다. 이 전체 루프는 개발자가 중간에서 의도를 HTTP 호출로 번역한다는 가정을 전제로 합니다. LLM (Large Language Model)이 운전석에 앉게 되면 그 가정은 완전히 깨지며, 제가 프로덕션 환경에서 본 모든 에이전트 시스템에서 그 균열이 나타나고 있습니다.

실제로 일어난 일

Anthropic이 처음 소개한 Model Context Protocol (MCP)는 제가 지켜본 대부분의 프로토콜 전환보다 더 빠르게 "흥미로운 사양"에서 "실제 채택 압박" 단계로 넘어갔습니다. 이제 생태계 전반에서 그 패턴이 보입니다. Cognizant는 Claude 기반 에이전트를 엔터프라이즈 워크플로우에 도입하기 위해 Anthropic과의 파트너십을 구체적으로 확장했으며, 이러한 워크플로우가 무엇을 요구하는지 살펴보면 MCP는 선택 사항이 아닙니다. 에이전트 루프에 REST를 단순히 덧붙이는 것만으로는 해결되지 않습니다.

MCP가 무엇인지에 대한 짧은 요약: LLM이 각 통합을 위한 커스텀 클라이언트를 인간이 작성하지 않고도 도구를 발견(discover), 협상(negotiate), 호출(invoke)할 수 있게 해주는 표준화된 양방향 프로토콜입니다. 서버는 자신의 기능을 광고합니다. 모델은 이를 읽습니다. 모델은 이를 호출합니다. 글루 코드(glue code), 프롬프트에 쑤셔 넣은 API 문서, 시스템 프롬프트에 전달되어 행운만을 바라는 취약한 JSON schema가 필요 없습니다.

REST가 문제였던 적은 없습니다. HTTP는 괜찮습니다. 문제는 "LLM이 무엇을 원하는지 알고 있는 상태"와 "서비스가 엔드포인트를 노출하는 상태" 사이에 존재해야 했던 통합 계층(integration layer)이었습니다. 그 계층이 프로덕션 환경에서 에이전트의 신뢰성을 떨어뜨리고 있었습니다.

중요한 기술적 세부 사항

MCP가 해결하는 구체적인 실패 모드(failure mode)는 다음과 같습니다. 전형적인 REST 기반 에이전트 통합 방식에서는 도구 설명(tool descriptions)을 컨텍스트 윈도우(context window)에 밀어 넣습니다. 모델은 이를 읽고, 함수 호출(function call)을 생성하며, 사용자는 이를 다시 HTTP 요청으로 파싱(parse)합니다. 이 방식은 잘 작동하다가도 다음과 같은 상황에서 실패합니다. 즉, 스키마(schema)가 어긋나거나, 모델이 파라미터(parameter) 이름을 환각(hallucinate)하거나, 엔드포인트(endpoint)가 예상치 못한 형태를 반환하거나, 작업 중간에 도구가 모델로 상태(state)를 다시 전달해야 할 때입니다.

MCP는 요청-응답(request-response) 방식이 아닌 세션 지향적(session-oriented) 프로토콜입니다. 연결이 계속 열려 있습니다. 서버는 알림(notifications)을 보낼 수 있습니다. 모델은 매 라운드 트립(round trip)마다 컨텍스트를 직렬화(serializing) 및 역직렬화(deserializing)할 필요 없이 여러 도구 호출에 걸쳐 상태를 유지할 수 있습니다. 다단계 에이전트 작업(multi-step agent tasks)이 포함된 모든 경우에 있어, 이는 단순히 있으면 좋은 기능(nice-to-have)이 아닙니다. 이는 실제로 워크플로(workflow)를 완료할 수 있는 에이전트와 작업 중간에 맥락을 놓쳐버리는 에이전트 사이의 차이입니다.

아키텍처 측면에서 중요한 또 다른 요소는 MCP가 기능 발견(capability discovery)과 기능 호출(capability invocation)을 분리한다는 점입니다. 모델은 계획을 확정하기 전에 "무엇을 할 수 있나요?"라고 물을 수 있습니다. 이는 에이전트 오케스트레이션(agent orchestration)을 구축하는 방식을 변화시킵니다. 시스템 프롬프트(system prompt)에 도구 가용성을 하드코딩(hardcoding)하는 대신, 에이전트가 이를 동적으로 발견하도록 하는 것입니다. 멀티 테넌트(multi-tenant) 플랫폼은 고객마다 프롬프트를 새로 작성할 필요 없이, 동일한 에이전트 런타임(agent runtime)에서 서로 다른 테넌트에게 서로 다른 도구 세트를 제공할 수 있습니다.

개발자에게 이것이 의미하는 바

만약 검색(retrieval)을 도구로 노출하는 RAG 파이프라인을 운영하고 있다면, 아마 현재는 함수 호출(function-calling) 스키마를 통해 이를 수행하고 있을 것입니다. 그것도 작동은 하지만, 검색 인터페이스가 변경될 때마다 유지보수 부담을 안게 됩니다. MCP는 에이전트 런타임과 검색 서버가 직접 협상하는 계약(contract)을 제공합니다.

만약 당신이 멀티 테넌트 (multi-tenant) AI 플랫폼을 구축하고 있다면, 기능 검색 (capability discovery) 모델이 진정한 돌파구(unlock)가 될 것입니다. 도구를 정적인 설정 (static config)으로 생각하는 것을 멈추고, 에이전트가 자기 성찰 (introspect)할 수 있는 서비스로 생각하기 시작하게 됩니다. 테넌트 A는 Salesforce 도구에 대한 접근 권한을 얻습니다. 테넌트 B는 Jira 도구를 얻습니다. 에이전트는 세션 (session)마다 무엇을 사용할 수 있는지 스스로 파악합니다. 더 이상 프롬프트 템플릿 (prompt templates)의 매트릭스를 관리할 필요가 없습니다.

만약 당신이 에이전트 프레임워크 (agent frameworks)를 구축하고 있다면, 세션 모델을 통해 웹훅 (webhook) 콜백이나 폴링 (polling) 루프 위에 억지로 구현할 필요 없이, 진행 상황 업데이트, 부분 결과, 취소 등을 포함한 적절한 장기 실행 작업 (long-running task) 패턴을 구현할 수 있음을 의미합니다.

현재의 실질적인 리스크: MCP 서버들의 품질이 매우 다양합니다. 사양 (spec)은 견고하지만 구현체들은 초기 단계입니다. 클라이언트 측에서 방어적인 처리 (defensive handling)를 할 수 있도록 계획하십시오.

오늘 바로 해야 할 일

github.com/modelcontextprotocol/typescript-sdk의 공식 리포지토리에서 MCP TypeScript SDK를 내려받아 로컬에서 예제 서버를 실행해 보세요. 그런 다음, 해당 서버에 연결하여 기능 검색 (capability discovery) 엔드포인트를 호출하고 반환된 내용을 로그로 남기는 최소한의 MCP 클라이언트를 작성해 보십시오. 이 단 한 번의 연습이 이 글을 포함한 그 어떤 블로그 포스트보다 빠르게 도구 통합 (tool integration)에 대한 당신의 사고방식을 재정립해 줄 것입니다.

AI 엔지니어링 분야에서 실제로 일어나고 있는 일들에 대한 일일 분석은 이곳을 팔로우해 주세요.

참고 문헌

• Cognizant and Anthropic expand their partnership to bring Claude to enterprise c, Anthropic News
• OpenAI just open-sourced Codex Security, Hacker News
• Inviting hard questions We're asking the public for their hardest questions abou, Anthropic News