기업 환경에서의 MCP: 액세스 제어 및 감사 로깅 (Access Control and Audit Logging)

준수 사항(compliance requirements)이 엄격한 기업에서 MCP 서버를 배포하면 모든 팀이 직면하는 동일한 벽에 부딪히게 됩니다. 이 프로토콜은 AI 에이전트(AI agent)를 도구(tools)와 아름답게 연결해 주지만, 일단 연결되고 나면 해당 에이전트가 무엇을 건드릴 수 있는지 제어할 수 있는 수단은 거의 제공하지 않습니다.

이러한 격차는 버그가 아닙니다. MCP는 거버넌스(governance)가 아닌 연결성(connectivity)을 해결하기 위해 구축되었습니다. 하지만 만약 당신의 에이전트가 데이터베이스(database), 티켓팅 시스템(ticketing system), 또는 실제 고객 데이터가 포함된 지원 편지함(support inbox)에 접근한다면, 거버넌스 없는 연결성은 보안 팀과의 매우 불편한 회의를 초래하는 정확한 원인이 됩니다.

MCP란 무엇이며 무엇을 연결하는가 (빠른 요약)

MCP (Model Context Protocol)는 AI 에이전트가 외부 도구 및 데이터 소스(data sources)와 통신하는 방식을 표준화합니다. 모든 통합(integration)을 위해 매번 맞춤형 글루 코드(glue code)를 작성하는 대신, 일련의 도구들을 노출하는 MCP 서버를 구축하면, MCP 호환 클라이언트(MCP compatible client, 예: 에이전트, IDE, 채팅 앱)가 동일한 방식으로 이를 호출할 수 있습니다.

이것이 핵심 제안이며, 실제로 잘 작동합니다. 하지만 여기에 포함되지 않은 것은 사용자별 권한(per user permissions)과 유사한 그 어떤 기능도 아닙니다.

기본 보안 태세: 모든 것을 위한 단일 서비스 계정

다음은 팀들을 당혹스럽게 만드는 부분입니다. 기본 MCP 구현은 단일 서비스 계정(service account)으로 인증하며, 해당 계정은 설정 시 부여받은 모든 권한을 갖게 됩니다. 프로토콜 자체에는 "이 특정 사용자는 자신의 기록만 볼 수 있어야 한다"라는 개념이 내장되어 있지 않습니다.

따라서 만약 당신의 MCP 서버가 모든 레코드에 대한 읽기 및 쓰기 권한을 가진 하나의 API 키를 사용하여 CRM에 연결된다면, 해당 서버를 통한 모든 에이전트 호출은 그 키의 전체 영향 범위(blast radius)를 상속받습니다. 요청의 반대편에 있는 사람이 오직 자신이 담당하는 5개의 열린 티켓만 다뤄야 하는 지원 담당자(support rep)라 할지라도 상관없습니다. 에이전트, 그리고 결과적으로 에이전트에 접근할 수 있는 모든 사람은 사실상 서비스 계정과 동일한 도달 범위를 갖게 됩니다.

자신의 샌드박스(sandbox)와 통신하는 주말 프로젝트용으로는 괜찮습니다. 하지만 HIPAA, GDPR 또는 SOX 규제 대상 데이터를 다루는 운영 환경(production system)에서는 괜찮지 않으며, 이는 기업의 MCP 도입이 보안 검토 단계에서 중단되는 가장 흔한 단일 원인입니다.

MCP가 기본적으로 제공하지 않는 6가지 기업용 제어 기능

기업의 MCP 거버넌스(governance) 요구사항을 충족하려면, 기본 프로토콜이 구현자의 과제로 남겨둔 최소한의 6가지 요소가 필요합니다:

1. OAuth 2.0 인증 (authentication). 단순히 정적인 키(static key)가 아니라, 요청을 통해 실제 사용자 신원(identity)이 흐르는 방식입니다.
2. 작업별 RBAC 또는 ABAC. 서버 전체가 아닌, 특정 도구 호출(tool call)에 범위가 제한된 역할 기반 액세스 제어(RBAC, Role-based Access Control) 또는 속성 기반 액세스 제어(ABAC, Attribute-based Access Control)입니다.
3. 귀속 수준의 감사 로깅 (audit logging). 단순히 실행을 담당한 서비스 계정이 아니라, 호출을 트리거한 사람과 모든 호출을 연결하는 것입니다.
4. 경로 및 범위 제어 (Path and scope controls). 에이전트가 사용하도록 허용된 도구 내에서라도, 특정 호출이 도달할 수 있는 리소스에 제한을 두는 것입니다.
5. 속도 제한 (Rate limiting). 루프에 빠져 다운스트림 시스템(downstream system)을 계속해서 타격하는 에이전트로부터 시스템을 보호하는 것입니다.
6. 민감도 레이블 평가 (Sensitivity label evaluation). 하위 자격 증명(credential)이 기술적으로 허용하는지 여부와 별개로, 요청된 데이터가 해당 호출자가 볼 수 있는 종류의 데이터인지 확인하는 것입니다.

이 중 어느 것도 무료로 제공되지 않습니다. MCP 서버 주변에 직접 구축하거나, 이미 이러한 기능을 갖춘 무언가를 서버 앞에 배치해야 합니다.

MCP 게이트웨이가 제공하는 것과 필요한 시점

MCP 게이트웨이(gateway)는 에이전트와 MCP 서버 사이에서 중앙 브로커(broker) 역할을 수행합니다. 모든 에이전트가 모든 서버와 직접 통신하는 대신, 호출은 먼저 게이트웨이를 통해 라우팅되며, 게이트웨이는 정책을 강제하고 발생한 모든 일에 대해 단일화된 통합 감사 로그(audit log)를 기록합니다.

실질적으로 이는 매번 새로운 MCP 서버를 구축할 때마다 위 6가지 제어 기능을 다시 만들 필요 없이, 게이트웨이에서 한 번만 구현하면 된다는 것을 의미합니다. 새로운 서버가 추가되어도 그 앞에는 동일한 게이트웨이 정책 계층이 존재합니다. 이것이 바로 핵심입니다.

둘 이상의 팀이 독립적으로 MCP 서버를 배포하거나, 단 하나의 MCP 서버라도 규제 대상인 요소에 접근하는 순간부터는 반드시 이것이 필요합니다. 민감한 데이터가 없는 소규모 팀을 위한 내부 도구 하나만 운영하고 있다면, 당분간은 이것 없이도 버틸 수 있을지 모릅니다. 하지만 실제 기업 환경에서는 그 기회의 창이 매우 빠르게 닫힙니다.

최소 실행 가능한 감사 로그(Audit Log) 캡처 세트

게이트웨이가 존재하기 전에 직접 이를 구축하고 있다면, 방어 가능한 감사 로그가 모든 호출에 대해 캡처해야 할 최소한의 기준(floor)은 다음과 같습니다. 이는 상한선(ceiling)이 아니라 최저 기준입니다:

• 호출자의 신원 (단순한 서비스 계정(Service Account)만이 아닌 실제 사용자)
• 호출된 도구(Tool)의 이름
• 요약이 아닌 전달된 전체 인자(Arguments)
• 실행 결과 (성공, 실패, 거부)
• 호출이 허용된 권한 컨텍스트 (Authorization Context)
• 이를 트리거한 상위 LLM 요청으로의 계보 (Lineage)
• 로그 자체가 사후에 몰래 수정될 수 없도록 하는 암호화된 무결성 해시 (Cryptographic Integrity Hash)

이 중 하나라도 누락한다면, 데모에서는 안심시켜 주는 것처럼 보일지 몰라도 감사관(Auditor)이 후속 질문을 던지는 순간 무너져 버리는 로그를 갖게 될 것입니다.

컴플라이언스 영향: 단순한 MCP 구현에서의 HIPAA, GDPR, SOX 격차

MCP의 네이티브 로깅은 최소한(Minimal)이며 휘발성(Ephemeral)입니다. 이 문구에는 많은 의미가 담겨 있습니다. '최소한'이라는 말은

MCP는 기업 환경에서 안전한가요?
MCP 자체는 연결 프로토콜 (Connectivity Protocol)이며, 보안 프레임워크 (Security Framework)가 아닙니다. MCP는 인증 (Authentication), 인가 (Authorization), 그리고 감사 로깅 (Audit Logging)을 주변에 추가했을 때만 기업 환경에서 안전하게 실행될 수 있습니다. 기본 설정인 단일 서비스 계정 (Single Service Account) 구성으로 배포될 경우, 그 자체만으로는 기업용으로 준비되었다고 할 수 없습니다.

MCP 게이트웨이 (Gateway)란 무엇인가요?
에이전트 (Agents)와 MCP 서버 사이에 위치하는 브로커 계층 (Broker Layer)으로, 액세스 정책 (Access Policy)을 강제하고 감사 로깅 (Audit Logging)을 중앙 집중화하여 모든 개별 서버 내부에서 해당 제어 기능들을 매번 다시 구축할 필요가 없도록 합니다.

MCP 도구 호출 (Tool Calls)을 어떻게 감사하나요?
모든 호출 시 호출자 신원 (Caller Identity), 도구 이름 (Tool Name), 전체 인자 (Full Arguments), 실행 결과 (Execution Outcome), 인가 컨텍스트 (Authorization Context), 그리고 요청 계보 (Request Lineage)를 캡처해야 하며, 로그가 나중에 몰래 변경되지 않도록 암호화 해시 (Cryptographic Hash)를 포함해야 합니다. 게이트웨이는 이를 서버마다 구현하는 대신 한 번에 구현할 수 있는 실질적인 장소입니다.

프로덕션 환경에서 에이전트 배포를 보안화하는 방법에 대해 더 깊이 알고 싶다면, 제 블로그에서 더 자세히 다루고 있습니다.

이것을 귀하의 스택에 엔드 투 엔드 (End-to-End)로 연결하고 싶다면, 바로 제가 수행하는 업무의 종류입니다.

다른 팀들이 프로덕션에서 MCP 액세스 제어를 어떻게 처리하고 있는지 궁금합니다. 귀하의 설정이 다르다면, 특히 잘 작동하는 게이트웨이 패턴 (Gateway Pattern)을 채택했다면 댓글을 남겨주세요.