API 이후

API는 소프트웨어를 연결했다. 이제 에이전트는 어떤 소프트웨어에 연결할지 스스로 결정해야 하는 소프트웨어를 등장시켰다.

전통적인 통합은 지식에서 시작된다. 개발자가 엔드포인트를 선택하고, 스키마를 살펴보고, 그 주변에 결정론적인 코드를 작성한다. 호출자는 서비스를 알고 있고 보통 작업(operation)도 알고 있다. 에이전트형 소프트웨어는 이 가정을 바꾼다. capability를 발견하고, 그 설명을 이해하고, 그중에서 선택하며, 경계를 넘어 컨텍스트를 이어가야 할 수 있다.

호출에서 디스커버리로

REST, RPC, 이벤트 스트림은 여전히 필수적이다. MCP는 이들을 구식으로 만들지 않는다. MCP가 다루는 것은 다른 계층이다. 공유 인터페이스를 통해 모델 기반 클라이언트에 도구, 리소스, 프롬프트를 제공하는 계층이다. 그 아래의 실제 작업은 여전히 API 호출, 데이터베이스 쿼리, 로컬 프로세스일 수 있다.

이 구분은 중요하다. 디스커버리는 단지 더 편리한 SDK가 아니다. capability를 선택하는 기계에는 올바른 추론을 뒷받침하는 이름과 설명, 입력을 제약하는 스키마, 명시적인 보안 경계가 필요하다. 모호한 도구 설명은 아키텍처상의 결함이다. 선택 동작을 바꾸기 때문이다.

MCP 사양은 클라이언트-호스트-서버 아키텍처와 capability 협상을 정의한다. 또한 구현자에게 동의, 데이터 프라이버시, 도구 안전성을 지키라고 경고한다. 이는 새로운 계층에 대한 단서다. 컨텍스트 교환은 권한과 분리될 수 없다.

내가 관심을 갖는 것은 MCP가 최종 프로토콜이 되느냐가 아니다. 에이전트와 시스템 간 상호작용이 프로토콜 계층을 필요로 할 만큼 중요해졌다는 사실이다. 프로토콜은 바뀔 수 있다. 하지만 그 필요성은 남을 것이다.

도구를 둘러싼 컨트롤 플레인

유용한 에이전트 도구 생태계에는 카탈로그 이상이 필요하다. 수명 주기와 거버넌스가 필요하다. 누가 도구를 등록했는가? 어떤 버전이 활성 상태인가? 어떤 테넌트가 그것을 볼 수 있는가? 디스커버리가 권한을 의미하는가, 아니면 단지 인지에 불과한가? 결과는 어떻게 신뢰할 수 없음으로 표시되는가? 워크플로 도중에 서버가 사라지면 어떻게 되는가?

이것들은 분산 시스템의 질문이다. 서비스는 독립적으로 장애를 일으킨다. 스키마는 진화한다. 재시도는 부수 효과를 중복시킬 수 있다. 에이전트는 오래된 컨텍스트를 들고 있을 수 있다. 모델에는 원자적으로 보이는 도구 호출도 그 아래에서는 여러 개의 비원자적 작업에 걸쳐 있을 수 있다.

텔레메트리 읽기, 인시던트 생성, 용량 변경 도구 중에서 선택하는 운영 에이전트를 상상해 보자. 디스커버리는 세 가지 capability를 모두 노출해야 하지만, 인가(authorization)는 균일해서는 안 된다. 읽기는 넓게 허용할 수 있다. 인시던트 생성은 멱등적이어야 한다. 용량 변경은 더 강력한 정책을 요구하고 제한된 범위를 포함해야 한다. 공유 프로토콜은 인터페이스를 기술하는 데 도움이 되지만, 경계의 강제는 플랫폼이 해야 한다.

벤더 경계는 이를 더욱 중요하게 만든다. 조직은 여러 모델 제공자와 수백 개의 내부 및 외부 서비스를 사용할 것이다. 맞춤형 어댑터는 양방향으로 결합을 만든다. 프로토콜 계층이 있으면 모든 클라이언트가 각자의 비공개 통합 방식을 배우지 않고도 도구를 진화시킬 수 있고, 각 서비스를 다시 작성하지 않고도 클라이언트를 바꿀 수 있다.

신화 없는 표준화

중요한 생태계는 인터페이스가 예측 가능해질 때 종종 가속화된다. 하지만 비유는 설명하는 것보다 더 많은 것을 가릴 수 있다. MCP는 단순히 "새로운 HTTP"가 아니다. HTTP는 네트워크로 연결된 컴포넌트 간에 표현(representation)을 전송한다. MCP는 모델을 향한 컨텍스트와 capability를 위한 규약을 정의하며, 그 아래에서는 흔히 기존 전송 방식을 사용한다.

유용한 아키텍처 주장은 더 좁다. 표준 인터페이스는 컴포넌트가 협력하는 데 필요한 양자 간 합의의 수를 줄여준다. 레지스트리, 게이트웨이, 정책 엔진, 테스트 하네스, 관측 가능성 같은 도구를 위한 공간을 만든다. 또한 장애를 비교 가능하게 만든다.

표준화가 자동으로 상호운용성을 만들지는 않는다. 두 서버가 같은 프로토콜을 구현하면서도 호환되지 않는 의미 체계를 사용할 수 있다. `search`라는 이름의 도구가 고객 문서를 검색할 수도, 공개 웹을 검색할 수도, 운영 데이터베이스를 검색할 수도 있다. 의미적 품질, 출처, 신뢰는 여전히 시스템 차원의 과제다.

이는 계층화된 설계를 시사한다. 디스커버리와 교환에는 프로토콜을 사용하라. 인가에는 신원(identity)과 정책을 사용하라. 의미에는 도메인 계약을 사용하라. 책임 추적에는 트레이싱과 감사 기록을 사용하라. 신뢰할 수 있는 실행에는 일반적인 API와 큐를 사용하라. 어떤 단일 계층도 다른 계층의 문제를 해결하는 척해서는 안 된다.

따라서 개발자에게 MCP의 즉각적인 가치는 범용성의 약속이 아니다. 모델 클라이언트를 도구 구현으로부터 분리하도록 이끄는 실용적인 압력이다. 그것은 실험 비용을 낮추고 교체를 더 가역적으로 만든다.

프로토콜이 중요한 이유는 시스템이 독립적으로 진화할 수 있게 해주기 때문이다.

출처

• Model Context Protocol 사양
• MCP 보안 모범 사례