MCP 서버, 왜 인증 분리가 중요한가요?
요즘 AI 에이전트 개발에서 MCP(Model Context Protocol)는 빠질 수 없는 핵심 기술이 되었습니다. Claude, GPT 같은 LLM이 외부 도구나 데이터에 접근할 때 MCP 서버를 통해 연결하는 구조인데요, 문제는 하나의 MCP 서버를 여러 사용자가 동시에 사용할 때 발생합니다.
사용자 A의 GitHub 토큰으로 사용자 B가 코드를 읽을 수 있다면? 사용자 C의 데이터베이스 자격 증명이 다른 사용자에게 노출된다면? 이런 상황은 보안 사고로 직결됩니다. 그래서 오늘은 다중 사용자 환경에서 MCP 서버의 자격 증명을 안전하게 분리하는 세 가지 패턴을 비교해 드리겠습니다.
패턴 1: 세션 바인딩 방식 (Session-Bound Credentials)
어떻게 동작하나요?
가장 직관적인 방식입니다. 각 사용자가 MCP 서버에 연결할 때 세션을 생성하고, 해당 세션에 자격 증명을 바인딩합니다. 세션이 살아 있는 동안만 자격 증명이 유효하고, 세션이 끊기면 자동으로 폐기됩니다.
- 구현 방식: MCP 서버가 SSE(Server-Sent Events) 또는 WebSocket 연결을 맺을 때 세션 ID를 발급하고, 인메모리 저장소(예: ConcurrentHashMap)에 세션별 자격 증명을 보관합니다.
- 자격 증명 흐름: 사용자 → OAuth 인증 → 토큰 발급 → 세션에 바인딩 → 도구 호출 시 세션에서 토큰 조회
장점과 단점
- ✅ 구현이 단순하고 이해하기 쉬움
- ✅ 세션 종료 시 자격 증명 자동 정리
- ❌ 서버 재시작 시 모든 세션 소실
- ❌ 수평 확장(Scale-Out) 시 세션 공유 문제 발생
- ❌ 메모리에 민감 정보를 보관하므로 메모리 덤프 공격에 취약
적합한 경우: 소규모 팀 내부 도구, 개발 환경, 단일 서버 운영 시 추천합니다.
패턴 2: 토큰 위임 방식 (Token Delegation / OAuth Proxy)
어떻게 동작하나요?
MCP 서버 자체는 자격 증명을 보관하지 않습니다. 대신 각 요청마다 사용자의 토큰을 전달받아 외부 서비스에 위임하는 방식입니다. MCP 서버는 순수한 프록시 역할만 합니다.
- 구현 방식: 클라이언트가 MCP 도구를 호출할 때 Authorization 헤더에 사용자의 액세스 토큰을 포함합니다. MCP 서버는 이 토큰을 그대로 하위 서비스(GitHub API, DB 등)에 전달합니다.
- 자격 증명 흐름: 사용자 → 자체 OAuth 앱 인증 → 토큰을 클라이언트에 보관 → 매 요청 시 토큰 전송 → MCP 서버가 토큰을 외부 API에 전달
장점과 단점
- ✅ MCP 서버에 민감 정보가 저장되지 않음 (Stateless)
- ✅ 수평 확장이 자유로움
- ✅ 서버 침해 시에도 자격 증명 유출 위험 최소화
- ❌ 매 요청마다 토큰 검증 오버헤드 발생
- ❌ 클라이언트 측 토큰 관리 책임 증가
- ❌ 토큰 갱신(Refresh) 로직을 클라이언트가 처리해야 함
적합한 경우: SaaS 환경, 다중 조직 지원, 보안 요구사항이 높은 프로덕션 환경에 적합합니다.
패턴 3: 볼트 기반 중앙 관리 방식 (Vault-Backed Credential Store)
어떻게 동작하나요?
HashiCorp Vault, AWS Secrets Manager 같은 전용 시크릿 관리 시스템을 중앙에 두고, MCP 서버가 도구 호출 시점에 사용자별 자격 증명을 동적으로 조회하는 방식입니다.
- 구현 방식: 각 사용자의 자격 증명을 Vault에 사용자 ID를 키로 저장합니다. MCP 서버는 도구 실행 시 현재 사용자 ID로 Vault에서 해당 자격 증명을 조회하여 사용합니다.
- 자격 증명 흐름: 관리자가 Vault에 사용자별 시크릿 등록 → 사용자 인증 → MCP 서버가 사용자 ID로 Vault 조회 → 자격 증명 획득 → 도구 실행 → 사용 후 메모리에서 즉시 폐기
장점과 단점
- ✅ 자격 증명의 중앙 집중 관리 및 감사(Audit) 추적 가능
- ✅ 자격 증명 자동 로테이션 지원
- ✅ 접근 정책을 세밀하게 제어 가능 (어떤 MCP 도구가 어떤 시크릿에 접근 가능한지)
- ❌ Vault 인프라 자체의 운영 복잡성 증가
- ❌ Vault 장애 시 전체 MCP 서비스 영향
- ❌ 네트워크 지연이 추가로 발생
적합한 경우: 엔터프라이즈 환경, 규정 준수(Compliance)가 필요한 금융·의료 분야, 대규모 사용자 관리 시 적합합니다.
세 가지 패턴 한눈에 비교
아래 표로 핵심 차이를 정리했습니다.
| 비교 항목 | 세션 바인딩 | 토큰 위임 | 볼트 기반 |
|---|---|---|---|
| 자격 증명 저장 위치 | MCP 서버 메모리 | 클라이언트 | 외부 Vault |
| 서버 상태 | Stateful | Stateless | Stateless |
| 수평 확장 | 어려움 | 쉬움 | 쉬움 |
| 보안 수준 | 보통 | 높음 | 매우 높음 |
| 구현 난이도 | 낮음 | 중간 | 높음 |
| 운영 비용 | 낮음 | 낮음 | 높음 |
| 감사 추적 | 제한적 | 제한적 | 완벽 지원 |
실전 팁: 어떤 패턴을 선택해야 할까?
정답은 없지만, 상황별 추천 조합을 알려드릴게요.
- 개인 프로젝트나 소규모 팀: 패턴 1(세션 바인딩)으로 시작하세요. 빠르게 구현하고 동작을 확인할 수 있습니다.
- B2B SaaS 서비스: 패턴 2(토큰 위임)를 기본으로 채택하세요. 고객별 데이터 격리가 자연스럽게 이뤄집니다.
- 금융, 의료 등 규제 산업: 패턴 3(볼트 기반)이 사실상 필수입니다. 감사 로그와 자격 증명 로테이션 요구사항을 충족할 수 있습니다.
물론 하이브리드 접근도 가능합니다. 예를 들어, 기본 인증은 토큰 위임으로 처리하되 데이터베이스 비밀번호 같은 장기 자격 증명은 Vault에서 관리하는 식이죠.
마무리
MCP 서버의 인증 분리는 단순히 기술적 선택이 아니라, 서비스의 보안 수준과 확장성을 결정짓는 아키텍처 결정입니다. 처음에는 단순한 패턴으로 시작하되, 사용자가 늘어나고 보안 요구사항이 강화될 때 점진적으로 발전시키는 것을 추천합니다.
혹시 MCP 서버 구축 중 인증 관련 고민이 있으시다면 댓글로 남겨주세요. 다음 포스팅에서는 실제 Spring Boot 기반 MCP 서버에서 OAuth 2.0을 연동하는 구체적인 코드를 다뤄보겠습니다.
Photo by Leonid Altman on Pexels
