2026. 6. 2. 14:39ㆍ카테고리 없음
MCP(Model Context Protocol)를 처음 접할 때는 보통 로컬 개발 환경에서 시작합니다. AI 에이전트가 파일을 읽고, GitHub 이슈를 보고, 사내 문서를 검색하고, 테스트를 실행하는 식입니다. 이 단계에서는 “어떤 도구를 제공할 것인가”가 가장 먼저 보입니다.
하지만 MCP 서버가 로컬을 넘어 원격 서비스가 되는 순간 질문이 바뀝니다. 이제 중요한 것은 도구 목록만이 아닙니다. 누가 이 서버에 접근할 수 있는지, 어떤 사용자의 권한으로 실행되는지, 토큰이 어디까지 허용되는지, AI 에이전트가 실수했을 때 어디서 멈출 수 있는지가 더 중요해집니다.
특히 HTTP 기반 원격 MCP 서버를 운영한다면 인증과 권한 부여를 단순 API Key 수준으로 생각하기 어렵습니다. MCP 공식 Authorization 문서는 OAuth 2.1 기반 흐름과 보안 요구사항을 다룹니다. 이번 글에서는 원격 MCP 서버를 만들거나 도입할 때 OAuth 2.1 권한 설계를 어떤 실무 기준으로 봐야 하는지 정리해보겠습니다.
로컬 MCP와 원격 MCP는 위험 모델이 다르다
로컬 MCP 서버는 보통 개발자의 컴퓨터 안에서 실행됩니다. 위험이 없다는 뜻은 아니지만, 접근 경로와 사용자가 비교적 제한적입니다. 개발자가 명령을 실행하고, 로컬 파일이나 특정 계정의 도구를 연결합니다.
반면 원격 MCP 서버는 네트워크를 통해 여러 클라이언트가 접근할 수 있습니다. 회사 내부 도구, SaaS 계정, 클라우드 리소스, 고객 데이터와 연결될 가능성도 커집니다. 이때 AI 에이전트는 단순한 채팅 상대가 아니라 사용자를 대신해 도구를 호출하는 실행 주체가 됩니다.
그래서 원격 MCP의 보안 질문은 다음처럼 바뀝니다.
- 이 요청은 어떤 사용자를 대신하는가?
- 클라이언트는 신뢰할 수 있는가?
- 토큰은 이 MCP 서버에만 쓰이도록 제한되어 있는가?
- 도구별로 필요한 최소 권한만 허용되는가?
- 위험한 작업은 추가 확인이나 별도 정책을 거치는가?
- 누가 언제 어떤 도구를 호출했는지 추적할 수 있는가?
이 질문에 답하지 못한 채 MCP 서버를 열면, 편리한 자동화 도구가 곧바로 권한 확장 지점이 됩니다. AI가 잘못 판단한 문제와 공격자가 악용한 문제를 구분하기도 어려워집니다.
OAuth 2.1은 로그인 기능이 아니라 권한 흐름이다
OAuth를 “소셜 로그인에 쓰는 것” 정도로 생각하면 MCP 권한 설계가 흐려집니다. 원격 MCP에서 OAuth 2.1의 핵심은 사용자를 인증하는 것뿐 아니라, 클라이언트가 제한된 권한으로 리소스에 접근하도록 만드는 흐름입니다.
MCP Authorization 문서에서는 HTTP 기반 전송에서 제한된 MCP 서버에 접근하기 위한 권한 흐름을 정의합니다. 여기서 MCP 서버는 보호된 리소스 역할을 하고, 클라이언트는 사용자의 승인을 받아 액세스 토큰을 사용합니다.
실무적으로는 세 역할을 분리해서 봐야 합니다.
| 역할 | 질문 |
|---|---|
| 사용자 | 이 작업을 허용할 실제 주체는 누구인가? |
| 클라이언트 | 토큰을 받아 MCP 서버를 호출하는 애플리케이션은 무엇인가? |
| MCP 서버 | 어떤 도구와 데이터를 보호하는 리소스 서버인가? |
| Authorization Server | 사용자 인증과 토큰 발급을 담당하는 곳은 어디인가? |
이 구분이 없으면 API Key 하나를 여러 자동화 도구에 공유하는 식으로 흘러가기 쉽습니다. 그 순간 토큰이 유출되었을 때 회수 범위도 넓어지고, 특정 사용자의 행위인지 시스템 공용 계정의 행위인지도 흐려집니다.
OAuth 2.1을 쓰는 이유는 복잡해 보이는 표준을 위한 것이 아닙니다. 사용자 동의, 클라이언트 식별, 토큰 만료, 권한 범위, 리다이렉트 검증, PKCE 같은 보안 장치를 한 흐름 안에서 다루기 위해서입니다.
토큰은 “무엇을 할 수 있는가”보다 “어디에 쓸 수 있는가”가 중요하다
원격 MCP 서버에서 자주 놓치는 부분은 토큰의 대상입니다. 토큰이 단순히 “읽기 권한”, “쓰기 권한”만 가지고 있으면 부족할 수 있습니다. 그 토큰이 어떤 리소스 서버를 위한 것인지도 명확해야 합니다.
예를 들어 어떤 AI 클라이언트가 사내 업무 도구용 토큰을 받았다고 가정해보겠습니다. 이 토큰이 여러 API에서 모두 받아들여진다면, 한 MCP 서버에서 얻은 권한이 다른 서비스 호출로 이어질 수 있습니다. 공격자 입장에서는 토큰을 재사용할 수 있는 표면이 넓어집니다.
이 문제를 줄이기 위해 OAuth에서는 Resource Indicators 같은 개념이 중요해집니다. 토큰이 특정 리소스 서버를 대상으로 발급되도록 하여, 다른 곳에서 재사용되지 않게 만드는 방식입니다.
MCP 서버를 설계할 때는 다음을 확인해야 합니다.
- 액세스 토큰의 audience 또는 resource가 MCP 서버에 맞게 제한되어 있는가?
- 토큰이 다른 내부 API에서 그대로 받아들여지지 않는가?
- 클라이언트별로 허용된 redirect URI가 엄격하게 검증되는가?
- public client라면 PKCE를 사용하고 있는가?
- refresh token을 발급한다면 저장 위치와 회수 정책이 있는가?
토큰은 짧고 편리한 문자열처럼 보이지만 실제로는 권한의 압축본입니다. 그래서 “이 토큰으로 무엇을 할 수 있나”와 함께 “이 토큰은 어디에서만 쓸 수 있나”를 반드시 봐야 합니다.
도구 권한은 scope만으로 끝나지 않는다
OAuth scope는 권한을 표현하는 중요한 수단입니다. 예를 들어 issues:read, issues:write, deploy:read, deploy:execute 같은 식으로 도구별 권한을 나눌 수 있습니다. 하지만 MCP 서버에서는 scope만으로 충분하지 않은 경우가 많습니다.
AI 에이전트가 호출하는 도구는 사람이 직접 누르는 버튼보다 더 빠르고 반복적입니다. 한 번 잘못된 판단이 여러 도구 호출로 이어질 수 있습니다. 따라서 권한은 최소한 세 층으로 나누어 보는 것이 좋습니다.
첫째, 토큰 레벨 권한입니다. 사용자가 승인한 범위와 클라이언트가 가진 scope입니다. 둘째, 서버 정책입니다. MCP 서버가 특정 도구 호출을 허용할지 판단하는 내부 규칙입니다. 셋째, 실행 시점의 컨텍스트입니다. 요청 대상, 환경, 변경 범위, 위험도를 보고 추가로 막거나 확인하는 단계입니다.
예를 들어 배포 관련 도구를 MCP로 노출한다고 해보겠습니다.
readDeploymentStatus
listRecentDeployments
createPreviewDeployment
promoteToProduction
rollbackProduction이 도구들을 모두 deploy:write 하나로 묶으면 위험합니다. createPreviewDeployment와 promoteToProduction은 영향도가 다릅니다. 실무에서는 다음처럼 나누는 편이 안전합니다.
| 도구 | 기본 허용 기준 |
|---|---|
| 배포 상태 조회 | 읽기 scope로 허용 |
| 최근 배포 목록 | 읽기 scope로 허용 |
| 프리뷰 배포 생성 | 쓰기 scope와 프로젝트 권한 확인 |
| 운영 배포 승격 | 별도 고위험 권한 또는 승인 단계 필요 |
| 운영 롤백 | 감사 로그와 추가 확인 필요 |
MCP 서버는 “AI가 요청했으니 실행”하는 얇은 프록시가 되면 안 됩니다. 도구마다 위험도를 나누고, 위험한 도구는 더 좁은 권한과 더 강한 검증을 요구해야 합니다.
실무 체크리스트: 원격 MCP 서버를 열기 전에 볼 것들
원격 MCP 서버를 만들 때는 다음 체크리스트를 기준으로 점검할 수 있습니다.
1. 클라이언트 등록과 리다이렉트 검증
- 허용된 클라이언트를 식별할 수 있는가?
- redirect URI가 정확히 등록된 값과 일치하는가?
- 개발용 redirect URI가 운영에 남아 있지 않은가?
- public client와 confidential client를 구분하고 있는가?
OAuth 흐름에서 redirect URI 검증은 기본처럼 보이지만, 실제 사고에서는 기본 설정이 느슨해서 문제가 생기는 경우가 많습니다. 특히 AI 도구가 여러 환경에서 실행된다면 개발, 스테이징, 운영 클라이언트를 분리하는 것이 좋습니다.
2. PKCE와 짧은 수명의 토큰
- Authorization Code 흐름에서 PKCE를 사용하는가?
- 액세스 토큰 수명이 과하게 길지 않은가?
- refresh token 회수 정책이 있는가?
- 토큰 저장 위치가 클라이언트 특성에 맞는가?
AI 클라이언트가 데스크톱 앱, 웹 앱, CLI, 서버형 도구 등 다양해질수록 토큰 저장 방식도 달라집니다. 모든 클라이언트에 같은 기준을 적용하기보다 public client는 더 보수적으로 보는 편이 안전합니다.
3. scope와 도구 매핑
- MCP tool마다 필요한 scope가 문서화되어 있는가?
- 읽기 도구와 쓰기 도구가 분리되어 있는가?
- 삭제, 배포, 결제, 권한 변경 같은 고위험 도구가 별도 권한으로 나뉘어 있는가?
- scope가 너무 넓어서 사실상 관리자 권한처럼 쓰이지 않는가?
scope 이름은 개발자에게도 운영자에게도 이해 가능해야 합니다. admin 하나로 모든 것을 해결하면 편하지만, 나중에 감사와 회수가 어려워집니다.
4. 사용자 컨텍스트와 대리 실행
- 도구 호출이 어떤 사용자의 권한으로 실행되는지 남는가?
- 서비스 계정으로 실행한다면 실제 요청 사용자를 함께 기록하는가?
- 사용자가 접근할 수 없는 프로젝트나 리소스를 AI가 우회해서 접근하지 못하는가?
- 조직, 팀, 프로젝트 단위 권한이 도구 실행 전에 다시 검증되는가?
MCP 서버는 기존 백엔드 권한 모델을 우회하면 안 됩니다. AI가 호출하더라도 최종적으로는 동일한 권한 검사를 통과해야 합니다.
5. 감사 로그와 재현 가능성
- 어떤 클라이언트가 어떤 사용자를 대신해 어떤 tool을 호출했는가?
- 입력 파라미터와 결과 상태가 기록되는가?
- 실패한 권한 요청도 남는가?
- 민감한 값은 마스킹되는가?
- 문제가 생겼을 때 특정 토큰이나 클라이언트를 빠르게 차단할 수 있는가?
AI 에이전트 기반 자동화에서는 “왜 이 작업이 실행되었는가”를 나중에 추적하는 일이 중요합니다. 모든 프롬프트를 그대로 저장할 필요는 없지만, 도구 호출 단위의 감사 로그는 반드시 필요합니다.
흔한 실수
원격 MCP 서버에서 자주 나오는 실수는 다음과 같습니다.
- 내부망에서만 쓴다는 이유로 인증을 약하게 둔다.
- 모든 도구를 하나의 API Key 또는 관리자 토큰으로 실행한다.
- 읽기 도구와 쓰기 도구의 scope를 나누지 않는다.
- AI 클라이언트를 일반 웹 클라이언트와 같은 위험 모델로 본다.
- 토큰의 audience/resource를 제한하지 않는다.
- 감사 로그 없이 “에이전트가 실행했다” 정도만 남긴다.
- 운영 배포, 삭제, 결제 같은 고위험 작업에 추가 확인 단계가 없다.
특히 공용 서비스 계정 하나로 모든 MCP 호출을 처리하는 방식은 처음에는 편하지만 오래 유지하기 어렵습니다. 권한 회수도 어렵고, 누가 실제로 요청했는지 추적하기도 어렵습니다.
도입 판단 기준: 언제 OAuth 기반 원격 MCP가 필요한가
모든 MCP 서버가 처음부터 복잡한 OAuth 구성을 가져야 하는 것은 아닙니다. 로컬 개발 전용 도구나 개인 자동화라면 단순한 구성이 더 적절할 수 있습니다. 하지만 다음 조건 중 하나라도 해당한다면 원격 MCP 권한 설계를 진지하게 봐야 합니다.
- 여러 사용자가 같은 MCP 서버를 사용한다.
- 사내 문서, 고객 정보, 결제, 배포, 인프라 리소스에 접근한다.
- 외부 SaaS 계정과 연결된다.
- 브라우저나 데스크톱 앱처럼 다양한 클라이언트가 접근한다.
- 조직 단위 권한, 프로젝트 권한, 역할 기반 접근 제어가 필요하다.
- 호출 이력을 감사해야 한다.
이런 상황에서는 단순히 “토큰을 헤더에 넣는다”로 끝내기 어렵습니다. 사용자, 클라이언트, 리소스 서버, 권한 범위, 감사 로그를 모두 설계해야 합니다.
결론: MCP 서버는 도구 목록보다 권한 경계가 먼저다
MCP의 매력은 AI 에이전트가 실제 개발 환경과 업무 도구를 사용할 수 있게 해준다는 점입니다. 하지만 원격 MCP 서버에서는 그 장점이 곧 위험이 될 수 있습니다. AI가 더 많은 일을 할수록, 권한 경계도 더 명확해야 합니다.
실무 기준으로 정리하면 다음과 같습니다.
- 로컬 MCP와 원격 MCP의 위험 모델을 분리한다.
- OAuth 2.1을 단순 로그인 기능이 아니라 권한 흐름으로 본다.
- 토큰의 scope뿐 아니라 audience/resource를 제한한다.
- MCP tool별로 읽기, 쓰기, 고위험 작업을 나눈다.
- 기존 백엔드 권한 검사를 MCP 서버에서도 다시 적용한다.
- 도구 호출 단위의 감사 로그를 남긴다.
- 운영 배포, 삭제, 결제 같은 작업은 추가 확인 단계를 둔다.
원격 MCP 서버를 안전하게 운영하려면 “AI가 무엇을 할 수 있는가”보다 “AI가 어디까지 할 수 있고, 어디서 멈춰야 하는가”를 먼저 정해야 합니다. 좋은 MCP 서버는 도구를 많이 제공하는 서버가 아니라, 필요한 도구를 명확한 권한 경계 안에서 제공하는 서버입니다.