Claude Code와 MCP 서버의 공유 인프라 전환 시 발생하는 문제와 해결책

커뮤니티 반응

공유 인프라 전환 시 겪는 실질적인 보안 및 운영 문제를 구체적인 수치와 함께 제시하여 매우 유익하다는 반응이다.

주요 논점

01찬성다수

에이전트의 무분별한 탐색과 리소스 과부하를 막기 위해 게이트웨이 계층 도입이 필수적이다.

합의점 vs 논쟁점

합의점

에이전트는 기본적으로 접근 가능한 모든 경로를 탐색하려는 성질이 있어 권한 제어가 필수적이다.
MCP 서버 자체의 기능만으로는 엔터프라이즈급 보안 및 운영 요구사항을 충족하기 어렵다.

논쟁점

게이트웨이 도입으로 인한 시스템 복잡도 증가와 단일 장애점(SPOF) 발생 가능성에 대한 우려가 있다.

실용적 조언

팀 단위로 MCP를 배포하기 전에 Gravitee나 Kong 같은 게이트웨이를 앞에 두어 사용자별 권한을 설정하라.
데이터베이스 연결 MCP 사용 시 반드시 사용자별 쿼리 속도 제한(Rate Limit)을 설정하여 백엔드 부하를 방지하라.

섹션별 상세

로컬 환경에서 공유 인프라로 전환 시 가장 먼저 인증(Auth) 문제가 발생했다. 로컬에서는 단일 사용자라 인증이 필요 없었으나, 공유 환경에서는 파일 시스템 MCP가 접속자를 식별하지 못해 에이전트가 권한 없는 디렉토리를 탐색하는 현상이 나타났다. 이를 해결하기 위해 사용자별로 MCP 서버 접근 권한을 제어하는 스코핑 작업이 필수적임이 확인됐다.

다수 사용자가 동시에 MCP를 사용할 때 발생하는 속도 제한(Rate Limiting) 부하 문제가 심각했다. 6명의 개발자가 Postgres MCP를 통해 분당 200건의 쿼리를 실행하며 스테이징 데이터베이스에 과도한 부하를 주었으나, MCP 서버 자체에는 이를 제어할 기능이 없었다. 게이트웨이 계층에서 도구별, 사용자별로 요청 속도를 제한함으로써 데이터베이스 안정성을 확보했다.

규제 준수를 위한 감사 추적(Audit Trails) 기능의 부재가 운영상의 걸림돌이 되었다. 특정 시점에 어떤 에이전트 세션이 어떤 데이터에 접근했는지 기록이 남지 않아 보안 검토 요청에 대응할 수 없는 상태였다. 모든 MCP 호출에 대해 호출자와 시간을 기록하는 로깅 시스템을 구축하여 투명한 데이터 접근 관리가 가능해졌다.

Gravitee를 게이트웨이 계층으로 도입하여 인증, 속도 제한, 로깅 문제를 통합적으로 해결했다. 이 방식은 도구 호출당 약 5~10ms의 지연 시간을 추가했으나 실제 사용자가 체감하기 어려운 수준이었으며, 5개의 MCP 서버를 설정하는 데 약 일주일이 소요됐다. 다만 게이트웨이가 단일 장애점(SPOF)이 될 수 있으므로 이중화 구성이 필수적이라는 실무적 교훈을 얻었다.

용어 해설

모델 컨텍스트 프로토콜(Model Context Protocol (MCP)): — AI 모델이 로컬 데이터나 외부 도구에 안전하게 접근할 수 있도록 돕는 개방형 표준 프로토콜이다. 클라이언트와 서버 간의 통신 규약을 정의하여 에이전트가 파일 시스템, 데이터베이스 등에 직접 연결되도록 지원한다.
API 게이트웨이(API Gateway): — 클라이언트와 여러 백엔드 서비스 사이에서 인증, 권한 부여, 트래픽 제어 등을 통합 관리하는 진입점이다. 분산된 환경에서 보안과 모니터링을 중앙 집중화하여 시스템의 안정성을 높이는 역할을 한다.
속도 제한(Rate Limiting): — 특정 시간 동안 허용되는 요청의 수를 제한하여 시스템 자원을 보호하는 기술이다. 다수의 사용자가 동시에 AI 에이전트를 사용할 때 데이터베이스나 API 서버에 과부하가 걸리는 것을 방지한다.
감사 추적(Audit Trail): — 시스템 내에서 발생한 모든 활동과 데이터 접근 기록을 시간 순서대로 기록한 로그이다. 보안 사고 발생 시 원인을 파악하거나 규제 준수 여부를 증명하는 데 필수적인 근거 자료가 된다.

언급된 도구

Gravitee추천

MCP 서버와 클라이언트 사이에서 인증, 속도 제한, 로깅을 담당하는 게이트웨이

Postgres MCP중립

PostgreSQL 데이터베이스와 AI 에이전트를 연결하는 서버