블로그
MCP

게시일 수정일

Shouryamaan 및 Arag

MCP 인프라 stack: server, gateway, 도구, 권한

Markdown으로 읽기

production MCP stack에는 transport, protocol 처리, 인증, routing, 도구 정의, 권한 부여 policy, 실행 자격 증명, 백엔드 API, operation state, telemetry가 포함됩니다. 소규모 배포에서는 여러 계층을 한 process에 합칠 수 있지만 각 책임에는 여전히 소유자가 한 명씩 있어야 합니다.

대부분의 실패는 숨겨진 경계에서 발생합니다. 한 handler가 token을 검증하고 tenant 접근을 판단하고 provider 호출을 재시도하고 결과를 기록하면, 어느 규칙이 실패했는지 아무도 알 수 없습니다.

stack을 한눈에 보기

flowchart TD
    C[MCP clients] --> T[Transport edge]
    T --> S[Protocol server]
    S --> G[Authentication and routing]
    G --> R[Tool registry]
    R --> P[Authorization policy]
    P --> E[Tool executor]
    E --> K[Credential broker]
    K --> B[Backend APIs and data]
    E --> O[Operation state]
    S --> X[Telemetry and evaluations]
    P --> X
    E --> X
    B --> X

이 그림은 책임을 나타낸 지도입니다. 제품을 11개로 나눠야 한다는 뜻은 아닙니다.

Transport edge

edge는 원격 server의 HTTPS 연결을 종료하고, 요청 크기와 origin을 검증하고, 연결 제한을 적용하고, Streamable HTTP session을 routing합니다. 로컬 stdio server는 그 대신 local process와 operating-system 경계를 그대로 사용합니다.

MCP transport 명세는 stdio 및 Streamable HTTP 동작을 정의합니다. tenant rate limit이나 애플리케이션 권한 부여까지 제공하지는 않습니다.

Protocol server

server는 initialization, capability negotiation, JSON-RPC message, pagination, cancellation, notification을 처리합니다. 구현에서 선언한 도구, 리소스, prompt를 제공합니다.

protocol error와 domain failure는 구분해야 합니다. 잘못된 tools/call 요청은 유효한 create_invoice 호출을 비즈니스 policy가 거부한 경우와 다릅니다.

인증과 routing

인증은 client와 그 client가 대신하는 사용자를 확인합니다. routing은 올바른 server, tenant context, tool group을 선택합니다. gateway는 여러 MCP server의 연결 제한과 인증 검색을 중앙화할 수 있지만, 소규모 배포에서 반드시 별도의 서비스로 존재해야 하는 것은 아닙니다.

MCP 권한 부여 가이드는 원격 OAuth 흐름과 audience validation이 이 계층에 속하는 이유를 설명합니다.

Tool registry

registry에는 client에 표시되는 정확한 이름, 설명, schema, output contract, annotation이 들어 있습니다. tenant, role, feature, environment에 따라 목록을 거를 수도 있습니다.

도구 선택과 리소스 권한 부여를 분리하세요. 도구를 숨기면 모델의 선택에는 도움이 되지만, 백엔드는 금지된 요청을 여전히 거부해야 합니다.

MCP 도구 설계 가이드에는 이 계층을 위한 선택 전용 평가가 포함되어 있습니다.

권한 부여 policy

policy는 해당 신원이 지금 이 tenant, 리소스, 작업에 대해 이 도구를 사용할 수 있는지 판단합니다. 승인이 필요한지도 판단합니다.

광범위한 비즈니스 규칙은 리소스를 소유한 서비스에 두세요. 중앙 policy 계층은 요청을 일찍 거부할 수 있지만 한 사용자가 다른 사용자의 invoice를 읽을 수 없다는 사실을 아는 유일한 곳이 되어서는 안 됩니다.

Tool executor와 credential broker

executor는 입력을 검증하고 내부 코드나 업스트림 API를 호출한 뒤 결과 형태를 다듬습니다. credential broker는 가능한 한 가장 좁은 범위의 별도 업스트림 자격 증명을 제공합니다.

모델이 그 자격 증명을 받아서는 안 됩니다. MCP secret 처리 가이드는 prompt, log, error, 생성 artifact에서 유출을 테스트하는 방법을 보여 줍니다.

백엔드와 operation state

백엔드는 데이터 무결성과 최종 권한 부여를 적용합니다. operation state는 논리적 쓰기, 시도, idempotency key, provider request ID, 결과를 기록합니다. session state와 chat history는 이 ledger를 대신하지 못합니다.

timeout 후 executor는 provider를 다시 호출할지 결정하기 전에 operation state를 읽습니다.

Telemetry와 평가

telemetry는 사용자 요청을 도구 호출 및 백엔드 결과와 연결합니다. 평가는 변경을 거치면서도 모델이 올바른 도구를 선택하고 도구를 호출하지 않아야 할 사례를 지키는지 테스트합니다.

안정적인 ID와 범위가 제한된 결과 분류를 기록하세요. 자격 증명, 가공하지 않은 민감한 데이터, 크기가 제한되지 않은 provider payload는 제외하세요.

경계가 도움이 되는 곳만 분리하세요

독립된 trust, scaling, ownership, release 동작이 필요할 때 계층을 별도의 서비스로 분리하세요. 아키텍처 diagram에 box가 있다는 이유만으로 gateway를 추가하지 마세요.

아래 프롬프트는 기존 배포에서 각 계층의 소유자를 찾아내고 실제 위험을 만드는 첫 번째 혼합 책임을 찾습니다.