솔직하게 말씀드리겠습니다. OAuth 2.0은 아무리 훌륭하더라도, 반대편의 "사용자"가 아무도 지켜보지 않는 상황에서 분당 50개의 결정을 내리는 소프트웨어 에이전트일 수 있다는 생각으로 만들어진 것이 아닙니다. 우리는 사실 스펙(spec)이 브라우저 앞에 앉아 "허용(Allow)"을 클릭하는 인간을 가정하고 있음에도 불구하고, 에이전트에 맞추기 위해 스펙을 억지로 구부려 왔습니다. 그 가정이 이제 무너지고 있으며, AI 에이전트를 구축하는 대부분의 팀은 그것이 얼마나 심각한지 완전히 이해하지 못하고 있습니다.

제가 무엇을 의미하는지 설명하겠습니다.

OAuth에 내재된 인간에 대한 가정

전형적인 OAuth 2.0 권한 부여 코드 흐름 (authorization code flow)은 다음과 같습니다. 사용자가 로그인을 클릭하면 ID 제공자 (identity provider)로 리다이렉트되고, 동의 화면을 본 뒤 "허용(Allow)"을 클릭하면 앱이 이를 토큰 (token)으로 교환할 수 있는 권한 부여 코드 (authorization code)를 가지고 돌아옵니다. 이 흐름의 모든 단계는 화면을 보고 판단을 내릴 인간이 존재한다는 것을 가정합니다.

이제 그 루프에 AI 에이전트를 넣어보겠습니다. 에이전트 측에는 기다리고 있는 브라우저 세션 (browser session)이 없습니다. "이 앱이 귀하의 캘린더와 이메일에 접근하려고 합니다"라는 문구를 읽는 인간의 눈도 없습니다. 에이전트는 "허용(Allow)"을 클릭하는 것이 아니라 API를 호출하며, 이는 아무도 없는 새벽 2시에 수행되어야 하고, 때로는 몇 초 만에 서로 다른 서비스에 대한 5~6개의 호출을 연쇄적으로 수행해야 합니다.

3-legged OAuth 댄스는 정확히 한 가지를 위해 만들어졌습니다. 바로 인간이 특정 액세스 권한 부여에 대해 그 순간에 충분한 정보를 바탕으로 동의 (informed consent)를 하는 것입니다. 에이전트는 적어도 세 가지 방식으로 이를 깨뜨립니다.

실제로 문제가 발생하는 지점

1. 요청 시점에 동의를 위한 인간이 부재함. 에이전트는 작업 중간에 멈춰서 누군가가 버튼을 클릭하기를 기다릴 수 없기 때문에, 동의는 사전에 캡처되거나 미리 위임되어야 합니다. 이는 동의를 상호작용적이고 요청 시점에 발생하는 작업에서, 사전에 정의되어야 하는 정책 (policy)으로 변화시킵니다.

2. 정체성은 단일한 것이 아니라 계층화됩니다. 전통적인 OAuth에서 토큰은 "이 사용자, 이 앱에 의해 권한 부여됨, 이 범위 (scope)에 대해"를 나타냅니다. 에이전트(agent)의 경우, 실제로 세 가지 정체성이 함께 쌓이게 됩니다: 작업을 시작한 인간, 이를 실행하는 에이전트, 그리고 때로는 첫 번째 에이전트가 더 작은 작업을 수행하기 위해 생성한 하위 에이전트 (sub-agent)입니다. 표준 OAuth 토큰은 이러한 체인을 전달하도록 설계되지 않았습니다.

3. 세션 수명에 대한 가정이 유효하지 않습니다. 인간의 세션은 노트북을 닫는 것과 같은 자연스러운 경계와 함께 한 시간, 길어야 하루 정도 지속될 수 있습니다. 에이전트의 "세션"은 장기 실행 워크플로 (workflow)에 걸쳐 지속될 수 있고, 병렬 하위 작업 (sub-tasks)을 생성할 수 있으며, 인간의 합리적인 세션 패턴보다 더 오래 지속될 수 있는 반면, 인간이 받는 것과 동일한 범위가 지정되고 취소 가능한 권한 (scoped, revocable access)을 여전히 필요로 합니다.

먼저 네 가지 필수적인 홉 (hop)으로 축소된 전통적인 흐름을 살펴보겠습니다:

[

시작 시점에 단 한 번의 인간의 결정 지점이 있고, 앱에서 리소스 (resource)로의 한 번의 홉이 있습니다. 단순합니다.

이제 에이전트 위임 체인 (delegation chain)이 실제로 무엇을 필요로 하는지 살펴보십시오. 인간은 여전히 사전에 단 한 번만 결정하지만, 그 하류 (downstream)의 모든 것은 또 다른 클릭 대신 토큰을 통해 전달되고 강제되어야 합니다:

[

상단에는 동일하게 한 번의 인간 결정이 있습니다. 하지만 그 아래에는 인간이 실시간으로 보거나 승인하지 않는 두 개의 추가적인 홉이 있으며, 각각은 화면을 지켜보는 사람이 아니라 자신이 운반하는 토큰을 통해 스스로에 대해 책임을 져야 합니다.

여기서 실제로 도움이 되는 것

좋은 소식은 우리가 처음부터 시작하는 것은 아니라는 점입니다. OAuth 2.0 Token Exchange 규격인 RFC 8693은 이미 "on-behalf-of" (대리 수행) 토큰을 위한 패턴을 제공하고 있습니다. 이 패턴을 통해 한 당사자는 누가 누구를 위해 행동하는지에 대한 체인을 유지하면서, 토큰을 더 좁은 범위의 다운스트림 (downstream) 토큰으로 교환할 수 있습니다. 만약 팀들이 에이전트마다 단순히 새로운 정적 키 (static key)를 발행하는 대신 이 방식을 실제로 사용한다면, 이는 에이전트 위임 (agent delegation) 모델과 거의 완벽하게 일치합니다.

실제 적용 시 모습에 대한 대략적인 버전은 다음과 같습니다:

# 에이전트가 원래 작업을 위임한 사용자를 대신하여,
# 다운스트림 API를 호출하기 위한 더 좁은 범위의 수명이 짧은 토큰을 요청합니다.

...

여기에 명시적인 "acting on behalf of" (누구를 대신하여 행동함) 필드를 포함하는 JWT 기반 클레임 (claims, RFC 7519)을 결합하면, 6개월 후 감사인이 던질 질문인 "어떤 에이전트가, 누구의 권한으로, 어떤 범위 (scope)로 이 작업을 수행했는가?"에 실제로 답할 수 있는 토큰을 얻을 수 있습니다.

또한 MCP (Model Context Protocol) 서버를 위한 인증 패턴에 대해서도 실질적인 움직임이 일어나고 있습니다. MCP는 에이전트가 도구 및 데이터 소스와 통신하는 표준 방식으로 빠르게 자리 잡고 있기 때문입니다. 이 분야를 면밀히 지켜볼 가치가 있습니다. 왜냐하면 여기서 승리하는 패턴이 에이전트 대 도구 인증 (agent-to-tool auth)의 업계 표준이 될 가능성이 높기 때문입니다.

요점 (The takeaway)

OAuth는 고장 난 것이 아닙니다. 단지 이러한 새로운 유형의 행위자 (actor)에게는 불완전할 뿐입니다. 해결책은 OAuth를 버리는 것이 아니라 확장하는 것입니다. 즉, 대화형 동의 (interactive consent) 대신 사전 동의 (upfront consent)를, 단일한 평면적 토큰 (flat token) 대신 계층적 신원을 위한 토큰 교환 (token exchange)을, 그리고 환경 파일에 6개월 동안 머무는 정적 키 대신 수명이 짧은 범위 제한 권한 (scoped grants)을 사용하는 것입니다.

만약 당신의 에이전트 아키텍처가 여전히 에이전트를 수명이 긴 키를 가진 "단순한 또 다른 OAuth 클라이언트"로 취급하고 있다면, 당신은 단 한 번의 사고만으로도 왜 OAuth의 인간 중심적 가정들이 애초에 중요했는지를 뼈아프게 깨닫게 될 것입니다.