MCP 보안 (권한, 인증, 모범사례)
MCP를 도입하면서 가장 자주 듣는 우려가 "AI가 내 데이터·시스템에 접근하는데 안전한가"이다. 이 의문은 막연한 두려움이 아니라 매우 합리적인 질문이며, 다행히 MCP는 처음부터 이 문제를 표준 프로토콜의 핵심에 배치해 설계되었다. 이 글에서는 MCP의 3계층 보안 모델, 권한 동의 흐름, 그리고 실전에서 토큰을 안전하게 관리하는 모범 사례를 정리한다(출처: MCP 공식 사양 2025-11-25). 제가 처음 MCP를 사내 시스템에 붙이려 했을 때 가장 먼저 막힌 게 보안 검토였고, 결국 이 표준 보안 모델 덕분에 검토를 통과한 경험이 있다. 솔직히 그때까지는 "AI 도구"라는 단어 자체가 보안팀에게 거의 거부 반응을 일으키는 표현이었는데, MCP의 명시적 동의 흐름을 한 줄씩 보여주고 나서야 분위기가 바뀌었다.
MCP 보안 모델의 3계층
MCP의 보안 모델은 사용자, 호스트, 서버 세 계층의 명확한 책임 분리에 기반한다. 가장 바깥에 있는 사용자는 모든 행위의 최종 승인자이며, 호스트(Claude Desktop 같은 앱)는 사용자의 동의를 대신 묻고 결과를 모델에게 전달하는 게이트키퍼 역할을 한다. 서버는 자신이 노출한 도구·리소스를 호스트가 호출할 때만 응답하며, 호스트의 승인이 없는 한 외부에 어떤 부수 효과도 발생시키지 않는다. 여기서 게이트키퍼란 권한이 있는 요청만 통과시키고 그렇지 않은 요청은 막아내는 통제 지점을 의미하는데, MCP에서는 호스트가 그 역할을 표준화해 가져갔다는 점이 핵심이다.
이 3계층 분리의 가장 큰 장점은 보안 사고의 영향 범위가 자연스럽게 제한된다는 점이다. 만약 어떤 MCP 서버가 악의적으로 작성되었더라도, 그 서버가 사용자의 시스템에 직접 손을 댈 방법이 없다. 모든 호출은 호스트를 거치고, 호스트는 사용자에게 확인을 받기 때문이다. 또한 서버 자체는 호스트가 spawn(자식 프로세스 생성)하는 형태로 동작하므로, 서버 프로세스의 권한은 호스트를 띄운 사용자 권한 안에 갇힌다. 즉 시스템 관리자(root) 권한이 자동으로 부여되는 일은 절대 발생하지 않는다.
추가로 MCP는 LLM 자체의 위험인 환각(hallucination)과 프롬프트 인젝션(Prompt Injection)을 구조적으로 완화하는 장치를 가진다. 환각이란 모델이 사실이 아닌 내용을 생성하는 현상을, 프롬프트 인젝션이란 외부 입력에 숨겨진 명령으로 모델의 행동을 탈취하는 공격을 가리킨다. MCP는 도구 호출 결과를 모델이 직접 실행하지 않고 호스트가 사용자에게 다시 한 번 보여주도록 만들기 때문에, 모델이 잘못된 명령을 만들어 내더라도 사용자가 마지막에 승인하지 않으면 실행되지 않는다(출처: OWASP LLM Top 10).
권한 동의 흐름과 사용자 승인
MCP의 동의 모델은 단순하지만 효과적이다. 호스트는 도구 호출이 발생할 때마다 사용자에게 어떤 도구를 어떤 인자로 호출할지를 미리 보여주고 승인을 받는다. Claude Desktop의 경우 망치 모양 버튼 옆에 호출 예정 도구의 이름과 파라미터가 표시되며, 사용자는 한 번씩 또는 "이 세션 동안 자동 승인" 같은 옵션을 선택할 수 있다. 제 경험상 처음에는 모든 호출을 일일이 승인하는 흐름이 번거롭게 느껴졌는데, 며칠 사용해 보니 오히려 "AI가 무엇을 하려는지 매번 한 줄 요약으로 보여주는 효과"가 생겨 신뢰도가 올라갔다.
승인 흐름에는 세 단계가 있다. 첫째, 도구의 메타데이터(이름·설명·인자 스키마)를 호스트가 사용자에게 보여 준다. 둘째, 사용자가 승인하면 호스트가 서버에 호출을 전달한다. 셋째, 서버의 응답을 호스트가 다시 사용자에게 보여 준 뒤 모델 컨텍스트에 합친다. 이 3단계가 모두 표준 프로토콜에 정의되어 있어, 어떤 호스트·서버 조합을 사용하더라도 일관된 보안 경계를 유지할 수 있다.
또한 MCP는 리소스(Resource) 접근에도 동일한 동의 모델을 적용한다. 모델이 "이 파일을 읽어와" 같은 요청을 만들면 호스트는 어떤 리소스 URI를 읽으려 하는지를 사용자에게 보여 주고 동의를 받는다. 솔직히 이 부분이 가장 안심되는 지점이었는데, 모델이 사용자가 모르는 사이에 임의의 파일을 슬쩍 읽어 가는 시나리오가 표준 단계에서 차단되어 있다는 점은 보안팀과 대화할 때 가장 결정적인 카드였다.
토큰 관리와 실전 모범 사례
실전에서 가장 자주 발생하는 사고는 사실 프로토콜 자체보다 외부 SaaS 인증 토큰 관리 부주의에서 비롯된다. GitHub PAT(Personal Access Token), Slack Bot Token 같은 토큰은 한 번 유출되면 곧 그 권한 범위 안의 모든 데이터에 접근할 수 있게 되기 때문이다. 여기서 PAT란 비밀번호 대신 사용하는 임시 발급 키로, 발급 시 권한 범위(scope)를 좁게 설정해야 안전하다.
가장 기본적인 모범 사례는 다음 네 가지다. 첫째, 최소 권한 원칙을 적용해 토큰 발급 시 필요한 스코프만 체크한다. 예를 들어 GitHub MCP가 코드 리뷰만 한다면 repo 스코프 전체가 아니라 read-only 권한으로 시작한다. 둘째, 환경 변수와 OS 비밀 저장소를 활용하고 토큰을 코드·설정 파일에 평문으로 두지 않는다. macOS 키체인, Windows 자격 증명 관리자, 1Password CLI 등이 표준 도구로 많이 쓰인다. 셋째, 정기적인 토큰 회전(rotation)을 적용해 90일 또는 30일 단위로 새 토큰을 발급하고 옛것을 폐기한다. 회전이란 같은 권한의 새 토큰을 발급해 갈아 끼우는 절차로, 유출 시 악용 가능 기간을 짧게 만든다. 넷째, 감사 로그(audit log)를 활성화해 누가 언제 어떤 도구를 호출했는지를 기록한다.
제가 직접 사이드 프로젝트에 적용한 흐름을 예로 들면, GitHub PAT는 1Password에 저장하고 환경 변수로 주입하며 30일 회전을 캘린더에 등록해 두었다. 이 셋업을 한 번 갖춰두니 이후 새 MCP 서버를 추가할 때마다 같은 패턴을 재사용하면 되어 운영 부담이 거의 없었고, 솔직히 이건 예상 밖이었는데 보안팀과의 후속 미팅에서도 이 표준화된 토큰 관리 흐름이 가장 환영받는 자료가 되었다. MCP의 보안은 결국 프로토콜이 절반, 토큰·키 관리가 나머지 절반이라는 점을 기억하면, 도입 초기에 보안 검토를 통과하는 일은 의외로 어렵지 않다.
메타 디스크립션: MCP의 3계층 보안 모델, 권한 동의 흐름, 그리고 외부 SaaS 토큰을 안전하게 관리하는 실전 모범 사례를 정리합니다.