몇 년 전, 우리는 에이전트(Agents) 및 LLM과 함께 성장한 완전히 새로운 기술인 MCP와 마주했습니다. MCP의 역할은 모델에게 다른 시스템, 프로그램 또는 서버에 접근할 수 있는 인터페이스를 제공하는 것입니다. 초기 MCP 서버들은 로컬 환경에서 작동하는 소박한 수준이었습니다. 계산기를 실행하거나, 캘린더를 확인하거나, 갤러리에서 스팸 사진을 삭제하는 정도였죠. 하지만 이들은 빠르게 원격 서버로 발전했습니다. Claude에 URL을 붙여넣으면, Claude는 즉시 해당 서버가 무엇을 할 수 있는지, 어디에 연결해야 하는지, 그리고 어떻게 통신해야 하는지를 파악합니다. 이는 Anthropic이 2024년 11월에 발표한 프로토콜 덕분입니다. 그리고 MCP가 원격으로 전환되는 순간, 인증(Authentication)은 선택 사항이 아니게 되었습니다. 이것이 바로 이 포스트의 주제입니다.

"MCP 서버에 OAuth를 추가하세요"라는 말은 한정된 작업처럼 들릴 수 있습니다. 하지만 그렇지 않습니다. 당신은 움직이는 목표를 겨냥하고 있습니다. 사양(Spec)은 지난 15개월 동안 서버의 '역할'을 두 번이나 바꾸었으며, 3주 후에는 또 다른 개정판이 출시될 예정이고, 현재 주요 에이전트들은 각각 서로 다른 개정판을 구현하고 있습니다. 이 포스트는 지도 역할을 할 것입니다. 현재 표준이 무엇을 말하고 있는지, 어떻게 여기까지 왔는지, 무엇이 다가오고 있는지, 그리고 각 주요 에이전트가 실제로 당신에게 요구하는 것이 무엇인지 설명합니다.

60초 만에 알아보는 오늘날의 MCP 서버 인증

MCP 인증은 원격 MCP 서버가 도구(Tool)를 실행하기 전에 호출자가 누구인지 파악하는 방법입니다. 한 문장으로 요약하자면: 당신의 서버는 자체적인 자격 증명(Credentials)을 배포하지 않습니다. 대신 별도의 권한 부여 서버(Authorization Server)가 발행한 토큰을 검증하는 일반적인 OAuth 리소스 서버(Resource Server) 역할을 수행합니다.

이 글을 쓰는 시점(2026년 7월 초)을 기준으로, 현재 안정적인 사양 개정판은 2025-11-25이며, 인증 모델은 OAuth 2.1입니다. 인증 전체는 선택 사항이지만, 서버가 인증을 수행할 때 사양은 작업을 두 당사자 간에 분할합니다. MCP 서버는 일반적인 OAuth **리소스 서버 (Resource Server)**이며, 토큰 발행은 별도의 권한 부여 서버 (Authorization Server) (Keycloak, Hydra, Okta, Entra 등 귀사가 이미 운영 중인 것)의 몫입니다.

이 흐름은 거절(refusal)로부터 시작됩니다. 인증되지 않은 요청은 401 응답을 받게 되며, 이 401 응답에는 클라이언트가 스스로 문제를 해결하는 데 필요한 모든 정보가 담겨 있습니다. 즉, 리소스 메타데이터(resource metadata)가 어디에 있는지, 어떤 인증 서버(authorization server)와 통신해야 하는지, 어떤 스코프(scopes)를 요청해야 하는지 등이 포함됩니다. 이를 통해 에이전트(agent)는 등록 방법, 토큰(token)을 얻는 방법, 토큰을 갱신(refresh)하는 방법, 그리고 토큰을 제시(present)하는 방법까지 전체 경로를 알게 됩니다.

MCP 인증이 여기까지 오게 된 과정

그 역사는 개월 수로 따지면 짧지만, 변화의 폭은 매우 컸습니다.

가장 초기 사양(2024-11-05)에서는 인가(authorization)에 대해 전혀 언급하지 않았습니다. 직접 구현하십시오, 행운을 빕니다.

2025-03-26 개정판은 실제 OAuth 2.1을 도입하여 그 실수를 바로잡았지만, 한 가지 운명적인 결정을 내렸습니다. 바로 MCP 서버 자체가 인증 서버(authorization server)가 되는 것이었습니다. 귀하의 서버에 기본 /authorize, /token, /register 엔드포인트(endpoints)를 두는 방식이었죠. 만약 그 뒤에 Keycloak이나 Hydra, 혹은 실제 IdP(Identity Provider)를 두고 싶다면, 모든 것이 귀하의 MCP 서버를 통해 프록시(proxy)되어야 했습니다. 독립적이고 유혹적이었지만, 잘못된 방식이었습니다.

그때 다양한 인증 기업의 전문가들이 이 설계 전체에 대한 비판(takedowns)을 게시하기 시작했습니다:

• Aaron Parecki (Okta), ["Let's fix OAuth in MCP">(https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol) (2025년 4월). 그의 핵심 불만 사항은 스펙이 MCP 서버로 하여금 인증 서버 (Authorization Server, AS) 역할을 강제한다는 것이었습니다. 발견 (Discovery) 과정이 MCP 서버 자체의 베이스 URL에서 OAuth 서버 메타데이터를 가져오는 방식으로 이루어졌기 때문에, 리소스 서버 (Resource Server, RS)는 ID 제공자 (IdP) 역할까지 수행할 수밖에 없었습니다. 그는 이를 두고 "그럴 필요가 없다"라고 표현했습니다. 그가 제안한 수정 사항들은 거의 토씨 하나 틀리지 않고 나중에 채택되었습니다: RFC 9728 보호된 리소스 메타데이터 (Protected Resource Metadata, 서버가 단순히 자신의 AS를 가리키는 방식), 토큰 발급의 외부 AS로의 위임 (delegation), 그리고 클라이언트가 스스로 등록할 수 있는 동적 클라이언트 등록 (Dynamic Client Registration)입니다.
• Christian Posta, ["The updated MCP OAuth spec is a mess">(https://blog.christianposta.com/the-updated-mcp-oauth-spec-is-a-mess/). 더 긴 목록이 이어집니다. 스펙이 AS와 RS의 역할을 혼동했습니다. 서버를 상태 유지형 (stateful)으로 만들도록 강제했습니다: 자체 토큰을 발급하고, 제3자 흐름 (third-party flows)을 위한 토큰 간 매핑을 유지하며, 전체 생명주기를 추적해야 했습니다. 무상태 (stateless)이며 수평적 확장이 가능한 백엔드라는 개념은 무색해졌습니다. 모든 MCP 서버는 기업당 하나의 중앙 집중식 IdP를 갖는 대신, 각자의 /.well-known/oauth-authorization-server를 노출해야 했습니다. 또한 제3자에게 위임하는 과정에서 토큰 체이닝 (token-chaining) 문제, 즉 취소 전파 지연 (revocation propagation delays) 및 타이밍 공격 (timing attacks) 등의 문제가 발생했습니다. 해당 포스트의 댓글 하나는 개발자 경험을 다음과 같이 요약했습니다: "안전하게 구축하는 것은 고사하고, 이것을 설정하는 것만으로도 막막해 보입니다."

이러한 비판은 빠르게 공식화되었습니다. PR #338 (David Soria Parra, Anthropic; 2025년 4월 23일 병합)을 통해 인증 스펙이 재구조화되었으며, PR #734를 통해 RFC 8707 리소스 인디케이터 (resource indicators)가 추가되었습니다.

그리고 마침내, 그 불만들이 접수되었습니다. 2025-06-18 개정판은 지각 변동과도 같은 변화(참고로, 이 과정에서 하위 호환성이 심각하게 깨졌습니다)를 가져왔습니다. 바로 MCP 서버가 리소스 서버 (resource server)가 된 것입니다. 더 정확히 말하자면, RFC 9728+RFC 8707이 필수 사항 (MUST)이 되었으며(클라이언트는 resource를 전송하고, 서버는 토큰의 대상(audience)을 검증합니다), 토큰 패스스루 (token passthrough)는 완전히 금지되었습니다.

그렇게 큰 드라마가 일단락되었고, 우리는 오늘의 안정적인 개정판인 2025-11-25에 도달했습니다. 여기에도 반전은 있었습니다. 건드릴 수 없을 것 같았던 DCR (Dynamic Client Registration)이 기본 등록 방식으로 CIMD (Client ID Metadata Documents)로 대체되었습니다. 차이점은 클라이언트 메타데이터를 누가 옮기느냐에 달려 있습니다. DCR의 경우 클라이언트가 등록 시점에 자신의 메타데이터를 권한 부여 서버 (AS, Authorization Server)로 밀어 넣었지만, CIMD에서는 AS가 클라이언트가 제어하는 URL에서 직접 메타데이터를 가져옵니다. 그 동기는 보안과 단순화였으며, 다음 섹션에서 이것이 어떻게 작동하는지 보여드리겠습니다.

걱정하시는 분들을 위해 말씀드리자면, 하위 호환성을 중요하게 생각하는 우리 같은 평민들을 위해 DCR은 명세(spec)에 여전히 남아 있습니다.

MCP OAuth 디스커버리가 실제로 작동하는 방식

단계별 과정입니다:

1. 클라이언트가 토큰 없이 서버의 문을 두드리면 401 오류를 받습니다. 응답에는 resource_metadata가 포함된 WWW-Authenticate 헤더가 실려 있을 수 있습니다. 2025-11-25부터 이 헤더는 선택 사항이 되었습니다. 만약 헤더가 없다면, 클라이언트는 스스로 /.well-known/oauth-protected-resource를 탐색(probing)하는 방식으로 전환합니다.
2. 클라이언트는 보호된 리소스 메타데이터(Protected Resource Metadata)를 가져와서, 해당 리소스가 신뢰하는 인증 서버(authorization servers) 목록인 authorization_servers를 읽어옵니다.
3. 클라이언트는 AS 메타데이터(RFC 8414 또는 OIDC Discovery)를 가져와 PKCE를 포함한 일반적인 OAuth 2.1 흐름을 실행하며, 이때 resource 파라미터(RFC 8707)를 전송하여 토큰이 이 특정 MCP 서버에 바인딩되도록 합니다.
4. 클라이언트가 토큰을 가지고 돌아오면, 서버는 서명(signature)과 대상(audience)을 검증한 후 비로소 실제 응답을 시작합니다.

이전 개정안과의 주요 차이점은 화살표 하나, 즉 "GET https://client.example/cimd.json"에 있습니다. DCR(Dynamic Client Registration) 하에서는 클라이언트가 이 데이터를 등록 엔드포인트(registration endpoint) 자체에 밀어 넣었지만(push), CIMD 하에서는 AS가 URL로부터 이를 가져옵니다(pull). 간단히 말해, 등록 방식이 푸시 모델(push model)에서 풀 모델(pull model)로 이동한 것입니다. 프로토콜 개발자들에 따르면, 이는 클라이언트 사칭(client impersonation)을 차단합니다. redirect_uris를 이용해 꼼수를 부릴 수 없는데, 왜냐하면 이 URI들은 클라이언트가 실제로 제어하는 서버의 메타데이터 문서에 존재해야 하며, AS가 거기서 이를 가져와 검증하기 때문입니다. 리다이렉트 대상을 자신의 것으로 바꾸려는 공격자는 이제 단순한 등록 요청뿐만 아니라 해당 호스팅 서버까지 제어해야 합니다. Auth0는 이 방식이 정확히 어떤 공격들을 차단하는지에 대해 훌륭한 분석을 제공하고 있습니다.

다음 제안 사항: 2026년 7월 개정안

요약(tl;dr): 프로토콜은 계속 변하고 있으며, 우리는 그에 맞춰 변화해야만 합니다.

다음 개정안은 현재 릴리스 후보 (release candidate) 상태이며, 2026년 5월 21일 이후 내용이 확정되어 2026년 7월 28일에 출시될 예정입니다. 인증 측면에서는 극적인 변화는 없으며, 보안 담당자들이 보안을 강화하는 수준입니다. 모든 것이 표준적인 OAuth 강화 작업이며, 인증 장(auth chapter)에서 호환성 파괴는 발생하지 않을 것으로 예상됩니다 :))

꼼꼼한 분들을 위해, 여섯 가지 변경 사항을 정리하면 다음과 같습니다:

1. 클라이언트는 인증 응답(authorization response)에서 iss 필드를 검증해야 합니다 (RFC 9207, SEP-2468). 이는 믹스업 공격 (mix-up attacks)을 방어하기 위함이며, 이는 하나의 클라이언트가 여러 서버 및 여러 인증 서버 (AS)와 동시에 통신하는 MCP의 배포 패턴에서 매우 중요합니다. 발행자 (issuer) 검증이 없다면, 악의적인 AS가 클라이언트와 정직한 AS 사이에서 중간자 공격 (man-in-the-middle)을 수행할 수 있습니다.
2. 클라이언트는 OIDC 스타일의 동적 등록 (dynamic registration) 중에 application_type을 선언해야 합니다 (SEP-837). 왜일까요? 그래야 AS가 자신이 데스크톱 또는 CLI 클라이언트를 상대하고 있음을 인지하고, 클라이언트의 localhost redirect_uri를 의심스러운 웹 앱으로 간주하여 거부하지 않기 때문입니다.
3. 클라이언트 자격 증명 (Client credentials)은 이를 발급한 AS의 issuer에 바인딩됩니다 (SEP-2352). 하나의 리소스 서버 (resource server) 뒤에 여러 인증 서버가 있을 수 있으며, 한 곳에서 발급된 자격 증명은 다른 곳에서 작동하지 않습니다. 리소스가 다른 AS로 이전되는 경우, 클라이언트는 이전 자격 증명을 재사용하는 대신 새로 등록합니다.
4. OIDC 스타일의 인증 서버로부터 리프레시 토큰 (refresh tokens)을 요청하기 위한 실제 지침 (SEP-2207)이 포함되었습니다. 이전 명세서에서는 이 부분을 독자의 과제로 남겨두었습니다.
5. 단계별 동의 (step-up consent) 시의 스코프 누적 (Scope accumulation) (SEP-2350).

이는 클라이언트가 세션 중간에 추가 권한을 요청하는 경우를 다룹니다. 예를 들어, 처음에는 read 권한을 요청했다가 한 시간 뒤에 사용자가 write 권한이 필요한 도구 (tool)를 실행하는 경우입니다. 두 번째 동의 과정에서 이미 부여된 스코프 (scopes)가 어떻게 되는지 불분명했습니다. 이제 명문화되었습니다: 스코프는 누적됩니다. 새로운 동의는 기존 권한을 삭제하는 대신 기존 권한에 새로운 권한을 추가합니다.
6. .well-known 접미사를 사용하여 디스커버리 URL (discovery URLs)을 구성하는 방법에 대한 명확한 설명 (SEP-2351)이 추가되어, 클라이언트가 경로의 어디에 위치할지 추측하지 않아도 됩니다.

인증 외에도 이번 개정은 매우 방대합니다. 프로토콜이 상태 비저장 (stateless) 방식으로 전환되었습니다: Mcp-Session-Id 헤더와 initialize 핸드셰이크 (handshake)가 제거되었으므로, 이제 어떤 서버 인스턴스라도 스티키 세션 (sticky sessions) 없이 모든 요청에 응답할 수 있습니다.

이 릴리스에는 중대한 변경 사항 (breaking changes)이 포함되어 있습니다. 우리는 이것이 일반적인 상황이 되기를 의도하지는 않습니다.

(c) MCP 스펙 개발자들. 두고 봅시다.

주요 에이전트 간의 MCP 인증 (2026년 중반)

이것이 현대적인 MCP 인증이 형성되어 온 역사였습니다. 이제 인기 있는 에이전트들을 살펴보며 이 규격을 얼마나 잘 따르고 있는지 확인해 보겠습니다. 스포일러를 드리자면: 별로 따르지 않고 있습니다.

이 글을 읽을 때쯤에는 상황이 변했을 수도 있지만, 2026년 7월 초 기준으로 상황은 아래 표와 같습니다.

좋은 소식: 거의 모든 곳에서 현대적인 표준을 지원합니다 (이전 지질 시대의 기술인 OpenAI의 Responses API MCP 도구에게 경의를 표합니다).

나쁜 소식: 모두가 동일한 스펙을 서로 다르게 해석합니다. 어떤 클라이언트는 사용자를 위해 전체 OAuth 흐름 (flow)을 실행하지만, 어떤 클라이언트는 이미 만들어진 베어러 토큰 (bearer token)을 기다렸다가 손을 떼버립니다. 어떤 곳은 DCR을 요구하고, 어떤 곳은 CIMD를 밀어붙이며, 어떤 곳은 정적 자격 증명 (static credentials)과 IAM에 의존합니다.

다음은 상세 매트릭스입니다 (모든 셀은 2026년 7월 초 기본 문서들을 통해 검증되었습니다):