모델 컨텍스트 프로토콜(MCP) 분석하기

MCP의 클라이언트-서버 아키텍처

MCP는 AI 모델이 외부 데이터 소스를 검색하고 상호 작용하는 방식을 구조화하는 클라이언트-서버 모델을 기반으로 구축됩니다.

• MCP 클라이언트는 AI 에이전트, 애플리케이션 또는 구조화된 데이터를 요청하는 모든 시스템입니다.
• MCP 서버는 다양한 API, 데이터베이스 또는 엔터프라이즈 시스템에서 데이터를 가져와서 일관된 형식으로 반환하는 중개자 역할을 합니다.

AI 모델이 직접 API 요청을 하는 대신 MCP 서버가 복잡한 인증, 데이터 검색, 응답 정규화를 처리합니다. 즉, AI 에이전트는 더 이상 여러 API 자격 증명, 다양한 요청 형식 또는 일관되지 않은 응답 구조를 관리할 필요가 없습니다.

예를 들어 AI 모델이 Google 드라이브, Slack, 데이터베이스와 같은 여러 서비스에서 정보를 가져와야 하는 경우 각 API를 개별적으로 쿼리하지 않습니다. 하나의 구조화된 요청을 MCP 서버로 보내면, 서버는 요청을 처리하고 필요한 소스에서 데이터를 수집한 후 잘 정리된 응답을 반환합니다.

MCP 요청-응답 수명 주기

일반적인 MCP 상호 작용은 구조화된 요청-응답 주기를 따르기 때문에 중복 API 호출을 없애고 데이터 검색을 표준화합니다.

1. AI 에이전트가 구조화된 요청을 MCP 서버로 전송합니다. 에이전트는 개별 API 요청을 작성하는 대신 필요한 데이터를 통일된 형식으로 정의합니다.

{

  "요청_id": "xyz-987",

  "쿼리": [

    {"source": "github", "action": "get_recent_commits", "repo": "company/project"},

    {"source": "slack", "action": "fetch_unread_messages", "channel": "engineering"}

  ]

}

2. MCP 서버는 인증 유효성 검사, 권한 확인, 쿼리할 외부 시스템 결정 등을 통해 요청을 처리합니다.

3. 쿼리가 병렬로 실행되므로 여러 서비스의 데이터가 순차적으로 검색되지 않고 동시에 검색되므로 전체 지연 시간이 줄어듭니다.

4. 다양한 소스의 응답을 AI 모델이 쉽게 처리할 수 있는 구조화된 형식으로 표준화합니다.

{

  "github": {

    "최근_커밋": [

      {"author": "Alice", "message": "Refactored AI pipeline", "timestamp": "2024-03-12T10:15:00Z"}

    ]

  },

  "slack": {

    "unread_messages": [

      {"user": "Bob", "text": "Hey, can you review the PR?", "timestamp": "2024-03-12T09:45:00Z"}

    ]

  }

}

수동 구문 분석이 필요한 원시 API 응답과 달리 MCP는 검색된 모든 데이터가 예측 가능하고 구조화된 형식을 따르기 때문에 AI 모델이 더 쉽게 이해하고 활용할 수 있습니다.

쿼리 실행 및 응답 집계

MCP는 구조화된 실행 프로세스를 도입하여 AI 모델이 외부 시스템과 상호 작용하는 방식을 최적화하도록 설계되었습니다.

1. 요청 유효성 검사는 데이터를 검색하기 전에 AI 모델에 필요한 권한이 있는지 확인합니다.
2. 쿼리 라우팅은 어떤 외부 서비스에 액세스해야 하는지 결정합니다.
3. 병렬 실행은 여러 소스에서 동시에 데이터를 검색하여 순차적인 API 요청으로 인한 지연을 줄여줍니다.
4. 응답 집계는 구조화된 데이터를 단일 응답으로 통합하여 AI 모델이 여러 개의 원시 API 출력을 수동으로 처리할 필요가 없도록 합니다.

중복 요청을 줄이고, 응답을 정규화하고, 인증을 중앙에서 처리함으로써 MCP는 불필요한 API 오버헤드를 없애고 AI 기반 자동화를 더욱 확장할 수 있도록 지원합니다.

인증 과제

MCP의 가장 큰 약속 중 하나는 AI 에이전트가 API별 통합에 덜 의존하도록 만드는 것입니다. 하지만 인증(AuthN)은 여전히 주요 과제로 남아 있습니다.

오늘날 API 인증은 파편화된 프로세스로 일부 서비스는 OAuth를 사용하고, 다른 서비스는 API 키에 의존하며, 세션 기반 인증이 필요한 서비스도 있습니다. 이러한 불일치로 인해 새로운 API를 온보딩하는 데 많은 시간이 소요되며, 현재 MCP에는 이러한 복잡성을 처리할 수 있는 인증 프레임워크가 내장되어 있지 않습니다.

MCP는 여전히 API 요청을 인증하기 위해 일부 외부 메커니즘이 필요하며, 이는 MCP를 사용하는 AI 에이전트가 API 자격 증명을 관리하기 위해 Composio와 같은 추가 솔루션에 의존해야 함을 의미합니다. 인증은 MCP의 로드맵에 포함되어 있지만 완전히 구현될 때까지는 개발자가 여러 시스템에서 인증을 처리하기 위한 해결 방법이 필요합니다.

불명확한 신원 관리

또 다른 해결되지 않은 문제는 신원 관리로, AI 에이전트가 MCP를 통해 요청을 할 때 외부 시스템에서 누구를 볼 수 있을까요?

예를 들어, AI 어시스턴트가 MCP를 통해 Slack 문의하는 경우 Slack 해당 요청을 수신한 것으로 인식해야 합니다:

• 최종 사용자? (AI가 인간을 대신하여 행동한다는 의미입니다.)
• AI 에이전트 자체? (이 경우 Slack AI 기반 상호 작용을 별도로 처리해야 합니다.)
• 공유 시스템 계정? (보안 및 액세스 제어 문제가 발생할 수 있습니다.)

액세스 제어 정책에 따라 누가 어떤 데이터를 검색할 수 있는지 결정되는 엔터프라이즈 환경에서는 이 문제가 훨씬 더 복잡해집니다. 명확한 ID 매핑이 없으면 MCP 통합은 여러 플랫폼에서 제한된 액세스, 보안 위험 또는 불일치에 직면할 수 있습니다.

신원 처리를 명확히 하는 데 도움이 될 수 있는 OAuth 지원이 MCP에 계획되어 있지만, 완전히 구현될 때까지는 AI 모델이 타사 서비스에 대한 권한 기반 액세스에 어려움을 겪을 수 있습니다. 

공급업체 종속 및 생태계 파편화

MCP는 현재 앤트로픽이 주도하는 이니셔티브이기 때문에 장기적인 표준화에 대한 의문이 제기되고 있습니다. AI 생태계가 발전함에 따라 OpenAI DeepSeek와 같은 다른 주요 업체들이 AI와 시스템 간의 상호작용을 위한 자체 프로토콜을 개발할 가능성이 높습니다.

여러 경쟁 표준이 등장하면 업계가 분열되어 개발자가 서로 호환되지 않는 여러 접근 방식 중 하나를 선택해야 할 수도 있습니다. MCP가 여전히 지배적인 접근 방식으로 남을지 아니면 단순히 여러 경쟁 옵션 중 하나가 될지는 아직 지켜봐야 합니다.