운영 환경에서의 MCP: AI 에이전트를 위한 보안, 권한 및 공급망 (Supply Chain)

MCP는 에이전트가 실제 도구(tools)를 사용할 수 있게 해줍니다. 이것이 MCP의 강점이자 동시에 위험 요소이기도 합니다. 새로운 서버가 추가될 때마다 공격 표면(attack surface)이 확장되기 때문입니다.

Model Context Protocol (MCP)은 실질적인 문제를 해결합니다. 각 에이전트는 도구, 저장소(repositories), 데이터베이스(databases), 브라우저(browsers), CRM, 티켓(tickets) 또는 문서(documentation)에 대한 접근 권한이 필요합니다. 공통 프로토콜이 없다면, 각 통합(integration)은 감사(audit)하기 어려운 임시방편(ad hoc)적인 조각이 되어버립니다.

주요 위험: 약속과 위험. 하지만 MCP는 에이전트를 시스템 운영자로 변모시킵니다. 만약 어떤 서버가 파일을 읽고, 명령을 실행하며, 고객 정보를 조회하거나 운영 환경(production)에 데이터를 쓸 수 있다면, 문제는 더 이상 프롬프트 엔지니어링(prompt engineering)만의 문제가 아닙니다. 보안(security), 권한(permissions), 신원(identity), 로깅(logging) 및 공급망(supply chain)의 영역으로 넘어갑니다.

브리핑: 올바른 사고 모델. MCP 서버를 단순하고 무해한 플러그인으로 봐서는 안 됩니다. 권한을 가진 실행 가능한 의존성(dependency)으로 취급해야 합니다. 질문은 '서버가 작동하는가'가 아니라, '무엇을 할 수 있는가, 어떤 신원으로, 어떤 데이터에 대해, 어떤 승인을 거쳐, 어떤 추적 가능성(traceability)을 가지고 수행하는가'가 되어야 합니다. 공식 레지스트리는 서버를 찾는 데 도움을 주지만, 발견하는 것이 승인하는 것과 같지는 않습니다. 운영 환경에서는 데이터를 다루거나 작업을 자동화하는 모든 패키지와 마찬가지로 각 서버에 대한 검토가 필요합니다.

실무 지침: 최소 권한 원칙. 작은 범위(scopes)부터 시작하십시오. 에이전트가 이슈(issues)를 읽기만 하면 된다면, 이슈를 닫을 수 있는 권한을 주지 마십시오. 로그를 조회하기만 하면 된다면, 인프라를 수정할 수 있는 자격 증명(credentials)을 주지 마십시오. 만약 워크플로우(workflow)에 쓰기 작업이 필요하다면 읽기, 제안, 그리고 최종 실행을 분리하십시오. 건강한 패턴은 계층적 방어(defense in depth)입니다: 서버 권한, 토큰(token) 권한, 사용자 권한, 도구 허용 목록(allowlists), 파괴적인 작업에 대한 확인 절차, 그리고 누가 무엇을 요청했는지 재구성할 수 있는 로그를 구축하는 것입니다.

인증(Authorization) 및 토큰 패스스루(token passthrough)

MCP의 보안 명세는 토큰 패스스루 (token passthrough)를 위험 요소로 취급하며 명확한 기준을 제시합니다. 올바른 대상(audience) 설정 없이 구성 요소 간에 토큰을 전달하는 것은 격리 (isolation)를 깨뜨립니다. 즉, 특정 서비스용으로 발급된 토큰이 다른 컨텍스트에서 사용될 수 있습니다.

중요한 운영 환경에서는 각 서버가 적절한 대상(audience)과 범위(scope)를 가진 토큰을 수신해야 합니다. 또한 인간의 신원 (human identity)과 에이전트의 신원 (agent identity)을 분리하는 것이 바람직합니다. 만약 모든 작업이 권한이 광범위한 개인용 토큰 하나로 수행된다면, 정당한 자동화와 남용을 구분할 수 없게 됩니다.

체크리스트 (Checklist)

MCP 서버의 공급망 (Supply chain)

위험은 단지 악의적인 서버에만 있는 것이 아닙니다. 방치된 서버, 전이적 의존성 (transitive dependencies), 정제되지 않은 쉘 명령 (shell commands), 검토되지 않은 마켓플레이스, 그리고 예제에서 그대로 복사해온 설정값들도 위험 요소입니다. 유용해 보이는 MCP가 로컬 실행 (local execution)의 통로로 변질될 수 있습니다.

설치하기 전에 저장소 (repository), 유지 관리자, 요청된 권한, 사용된 전송 방식 (transport), 실행되는 명령, 의존성 및 릴리스 빈도를 검토하십시오. 만약 서버가 필요한 것보다 더 많은 권한을 요구한다면, 이는 격리하거나 폐기해야 한다는 신호입니다.

실무 지침: 채택 체크리스트, 승인된 MCP 서버 인벤토리, 서버 및 환경별 스코프 (scopes), 분리된 대상 (audience)을 가진 토큰, 모든 관련 도구 호출 (tool call)에 대한 로그, 민감한 쓰기 작업에 대한 인간의 승인, 신뢰할 수 없는 서버를 위한 샌드박스 (sandbox) 또는 컨테이너, 의존성이 안전하지 않게 될 경우를 대비한 철회 프로세스.

결론 (Conclusion)

MCP는 에이전트 스택 (agent stack)의 중요한 구성 요소가 되겠지만, 단순히 편의를 위해 설치된 플러그인 집합으로서 운영 환경에 도입되어서는 안 됩니다. MCP 서버가 유용해질수록 더 많은 권한을 필요로 하는 경우가 많습니다.

검토 사항

확인해야 할 사항

• 실무 규칙: 만약 특정 MCP 서버가 무엇을 할 수 있는지 한 문장으로 명확하게 설명할 수 없다면, 해당 서버는 아직 실제 데이터에 접근할 수 있는 에이전트에 연결되어서는 안 됩니다.

편집자 결론: 최소 정책 (Minimum Policy), 관리형 계정 (Managed Account), 컨텍스트 제한 (Context Limits) 및 명시적 인간 검토 (Explicit Human Review)가 필요합니다. 이 세 가지 요소가 없다면 개인정보 보호는 해석의 여지가 너무 많이 남게 됩니다.

출처 및 참고 문헌

• Model Context Protocol: Registry

• MCP Authorization specification

• MCP Security Best Practices

• NSA: MCP security design considerations

함께 읽어볼 만한 글

Serena MCP: 시맨틱 검색 (Semantic Search)RAG를 위한 실시간 청킹 (Real-time chunking)RTK: 토큰 절감을 위한 CLI 프록시 (Proxy CLI)

개발자를 위한 AI 도구 주간 뉴스레터를 받아보세요

매주 화요일: Claude Code, Cursor, Copilot, MCP, 에이전트 및 새로운 도구들을 군더더기 없이 전달합니다.

무료 구독하기