에이전트가 당신의 새로운 고객입니다

오늘 아침 WorkOS Auth.md 영상을 보고 두 가지 감정을 동시에 느꼈습니다.

경이로움, 그리고 짜증.

이것이 현실이라는 점에 경이로움을 느꼈습니다. 동시에, 제가 기술의 최전선(frontier)에 더 가까이 있고 싶다는 생각에 짜증이 났습니다. 제가 몇 달 동안 조용히 작업해 온 카테고리의 용어를 다른 누군가가 먼저 출시하는 것을 보는 것은 그런 기분을 들게 합니다.

Auth.md는 WorkOS에서 내놓은 새로운 오픈 프로토콜(open protocol)로, AI 에이전트가 브라우저 없이, 가입 양식 없이, 인간의 개입(human in the loop) 없이 사용자를 대신하여 서비스에 인증(authenticate)할 수 있게 해줍니다. 이것은 당신의 도메인에 게시하는 마크다운(Markdown) 파일입니다. 에이전트는 이를 읽고, 흐름을 파싱(parse)하며, 등록 경로를 선택한 다음, 신뢰할 수 있는 제공자로부터 검증된 신원 주장(identity assertion)을 제시하거나 사용자에게 6자리 OTP 인증 과정을 안내합니다. 그 결과로 표준 OAuth 자격 증명(credentials)이 생성됩니다.

그것이 메커니즘입니다. 하지만 제 머리를 깨뜨린 문장은 기술적인 것이 아니었습니다.

바로 이것이었습니다: "에이전트가 당신의 새로운 고객입니다."

모든 것을 뒤집어 놓은 문장

"에이전트가 당신의 새로운 고객입니다. 에이전트가 필요로 하는 것을 만들고, 에이전트가 원하는 것을 만드세요."

이것은 스타트업의 만트라(mantra)인 "고객을 알라(know your customer)"를 완전히 뒤집은 것입니다. 지난 20년 동안 "고객"은 인간을 의미했습니다. 브라우저를 사용하는 사람. 양식을 채우고, 버튼을 클릭하고, 온보딩(onboarding) 이메일을 읽는 사람 말입니다. 인프라(infrastructure)는 바로 그런 사람들을 위해 구축되었습니다.

Auth.md는 당신의 API를 호출하는 엔티티(entity)가 더 이상 그 사람이 아닐 수도 있다고 주장합니다. 그것은 사용자를 대신하여 실행되는 자율적인 프로세스(autonomous process)일 수 있습니다. 만약 당신이 해당 프로세스를 수용할 수 있도록 API를 설계하지 않았다면, 프로세스는 당신의 시스템에서 튕겨 나갈 것입니다. 401 에러를 반환할 것입니다. 프로세스는 포기하거나, 마치 2014년처럼 인간에게 하던 일을 멈추고 API 키를 수동으로 붙여넣으라고 요청할 것입니다.

그 변화의 범위는 TCP/IP 규모에 달합니다. 인터넷이 등장했을 때, 우리는 기계들이 서로 통신할 수 있게 해주는 기본 요소(Primitives)인 TCP, IP, HTTP를 정의했습니다. Auth.md는 에이전트 시대를 위한 기본 요소를 제안하고 있습니다. 즉, 자신을 알지 못하는 서비스에 자율적인 행위자(Autonomous actor)가 자신을 제시할 수 있는 표준화된 방식입니다. 독점적인 핸드셰이크(Proprietary handshakes)도, 벤더별 통합(Per-vendor integrations)도 필요 없습니다. 그저 다음과 같이 전달할 뿐입니다: '나는 누구이며, 누구를 대신해 행동하고 있는지, 그리고 여기 내 인증 정보(Credential)가 있다'라고 말이죠.

WorkOS Auth.md는 개방되어 있습니다. WorkOS 전용이 아닙니다. 어떤 앱이든 auth.md 파일을 게시할 수 있고, 어떤 에이전트든 이를 읽을 수 있습니다. 이 프로토콜은 여러분이 이미 알고 있는 표준인 OAuth 2.0, OIDC, 보호된 리소스 메타데이터 (Protected Resource Metadata, RFC 9728), JWT 기반의 신원 주장(Identity assertions)을 기반으로 구축되었습니다. 새로운 암호화 기술(Crypto)이나 새로운 키 배포 방식도 필요하지 않습니다. 핵심적인 부분은 발견 계층(Discovery layer)과 기존 OAuth가 처리할 수 없었던 사례들을 다루는 두 가지 흐름(Flows)입니다. 기존 OAuth는 항상 인간이 개입(Human in the loop)한다는 것을 전제로 했기 때문입니다.

나는 이미 여기에 있었다

Auth.md가 내게 적절한 용어를 제공하기 전부터 내가 구축해 오던 에이전트 우선(Agent-first) 인프라의 세 가지 요소: MeshWire, Hookflows, 그리고 콘텐츠 암호화(Content encryption).

여기서 다르게 다가온 부분이 있습니다.

나는 몇 달 동안 에이전트 우선(Agent-first) 인프라를 구축해 왔습니다. 어떤 이론(Thesis)이 있어서가 아니었습니다. 그저 문제들이 그것을 요구했기 때문입니다.

Meshwire — 저는 에이전트들이 세션(Session)을 넘어 서로를 발견하고 연결할 수 있도록 이를 구축했습니다. 엔지니어가 설정 파일(Config file)에 그래프를 연결하기 위함이 아닙니다. 에이전트를 위한 것입니다. 즉, 한 Copilot CLI 세션에서 실행 중인 에이전트가 네트워크를 통해 다른 세션에서 실행 중인 다른 에이전트를, 두 에이전트 모두 상대방의 존재를 미리 알지 못하는 상태에서도 찾아내어 대화할 수 있도록 하는 것입니다. 저의 MeshWire 출시 포스트 제목은 말 그대로 "에이전트를 하나씩 연결하는 것을 멈추세요"입니다. 이는 에이전트 인프라에 인간 중심의 연결 모델(Human-centric wiring model)이 적용되고 있는 것에 대한 불만입니다.

Hookflows — 인간이 아닌 에이전트를 위한 거버넌스(Governance)입니다. 훅플로우(Hookflow)의 핵심은 에이전트가 정의된 체크포인트(Checkpoint)에서 훅(Hook)을 트리거하면, 플랫폼이 사람이 터미널을 지켜보지 않고도 다음에 일어날 일을 관찰, 검증 또는 차단할 수 있다는 점입니다. 저는 자율적으로 작동하는 에이전트 군단(Fleet) 전체에 걸쳐 행동 계약(Behavioral contracts)을 강제할 방법이 필요했기 때문에 이것들을 구축했습니다. 인간의 승인 게이트(Approval gates)는 없습니다. 에이전트 간의 책임성(Agent-to-agent accountability)입니다.

콘텐츠 암호화 (Content encryption) — 저는 콘텐츠를 단순히 비밀번호를 가진 인간뿐만 아니라, 검증된 권한을 가진 에이전트가 소비할 수 있도록 이 기술을 구축했습니다. 전체 모델은 다음과 같습니다: 에이전트가 자격 증명(Credentials)을 제시하고, 복호화된 콘텐츠를 받아, 그에 따라 행동합니다. 저는 인간의 로그인 흐름을 의도한 적이 없기 때문에 인간을 위한 로그인 흐름은 존재하지 않습니다.

Auth.md는 제가 하고 있던 일에 대해 가지고 있지 않았던 어휘(Vocabulary)입니다.

저는 "백엔드 서비스가 일부 부착된 AI 도구"를 만들고 있었던 것이 아닙니다. 저는 주요 소비자가 에이전트가 될 서비스들을 만들고 있었습니다. 단지 그 지향점(Orientation)을 일컫는 단어가 없었을 뿐입니다. 저는 Auth.md 명세(Spec)를 가리키며 "이것이 내가 처한 문제 공간(Problem space)이다"라고 말할 수 없었습니다. 이제는 그럴 수 있습니다.

Auth.md가 실제로 해결하는 문제

Auth.md의 두 가지 등록 흐름: 에이전트 검증됨 (Agent Verified, 신뢰할 수 있는 제공자 증명) 및 사용자 점유 (User Claimed, OTP 바인딩). 두 방식 모두 범위가 제한되고 취소 가능한 OAuth 자격 증명(credentials)으로 종료됩니다.

Auth.md가 해결하는 문제는 기만적일 정도로 단순합니다: 에이전트가 당신의 API를 호출했는데, 401 에러를 받았습니다. 그다음 에이전트는 무엇을 해야 할까요?

Auth.md 이전에는 선택지들이 좋지 않았습니다. 에이전트가 포기하거나, 에이전트가 사용자에게 개입하여 수동으로 계정을 생성하도록 방해하거나, 혹은 다른 어떤 에이전트도 이해하도록 훈련되지 않은 맞춤형 에이전트 등록 엔드포인트(endpoint)를 앱에 구축해야 했습니다. 이 중 어느 것도 확장 가능(scale)하지 않습니다.

Auth.md는 두 가지 흐름으로 이 문제를 해결합니다:

에이전트 검증됨 (Agent Verified) — 신뢰할 수 있는 에이전트 제공자(예: 인증된 사용자를 대신하여 에이전트가 동작하는 모든 플랫폼)가 사용자를 보증하는 신원 주장(identity assertion)인 ID-JAG에 서명합니다. 에이전트는 이를 당신의 /agent-auth 엔드포인트에 제시합니다. 당신은 제공자의 JWKS를 통해 JWT를 검증합니다. 당신은 JIT(Just-In-Time) 방식으로 사용자 레코드를 프로비저닝(provision)합니다. 그리고 범위가 제한된 자격 증명을 발급합니다. OTP도 필요 없고, 인간의 개입(human in the loop)도 필요 없습니다. 만약 Google Sign-In을 통해 사용자를 JIT 프로비저닝해 본 적이 있다면, 이는 구조적으로 동일합니다. 단지 브라우저 대신 에이전트가 신뢰 중개자(trust intermediary) 역할을 할 뿐입니다.

사용자 점유 (User Claimed) — 신뢰할 수 있는 제공자의 증명이 없는 경우를 위한 방식입니다. 당신의 앱이 점유 토큰(claim token)을 발급하고, 사용자에게 일회용 링크를 보내며, 6자리 OTP를 렌더링하면, 에이전트가 사용자를 대신하여 바인딩(binding)을 완료합니다. 관리해야 할 상태(state)는 약간 더 많지만, 결과는 동일합니다: 에이전트가 이후의 모든 요청에서 제시할 수 있는, 실제 사용자와 연결된 범위 제한 및 취소 가능한 자격 증명을 얻게 됩니다.

이 방식이 우아한 이유는 하지 않는 것들에 있습니다. 새로운 암호화 기술(crypto)도, 새로운 사용자 모델도 필요하지 않습니다. auth.md 파일 자체는 일반적인 마크다운(Markdown) 형식입니다 — https://yourapp.com/auth.md에서 확인할 수 있으며, 문서를 읽을 수 있는 어떤 에이전트(agent)라도 파싱(parse)할 수 있습니다. 이 프로토콜은 여러분이 이미 보유하고 있는 표준(standards) 위에 구축됩니다. 통합을 위한 작업량은 단 5단계와 수십 줄의 코드면 충분합니다.

첫 번째 문제

인증(Authentication)은 사실 더 큰 문제로 들어가는 진입점입니다: 에이전트가 접근 가능한 서비스가 어떻게 신뢰를 구축하고, 자격 증명(credentials)을 발급하며, 궁극적으로 결제를 처리할 것인가?

Auth.md는 인증 계층(authentication layer) 문제를 해결합니다. 에이전트를 위한 결제 및 과금(Payment and billing)은 여전히 해결되지 않은 더 어려운 문제이지만, 인증이 기본 요소(primitive)가 된 이후에는 자연스러운 다음 단계가 될 것입니다. 에이전트의 API 호출 비용은 누가 지불할까요? 에이전트가 대행하는 사용자일까요? 아니면 에이전트 플랫폼일까요? 서비스는 자율 프로세스(autonomous process)에 발급된 자격 증명에 어떤 조직의 과금 컨텍스트(organizational billing context)를 연결해야 하는지 어떻게 알 수 있을까요?

이 질문들은 다음과 같은 전제를 받아들이는 순간 나타납니다: 에이전트가 당신의 새로운 고객이다. 이는 먼 미래의 목표가 아닙니다. 2030년의 문제도 아닙니다. 바로 지금의 문제입니다.

고객에 대한 재고

에이전트에게 필요한 것들을 그것을 지칭할 용어가 생기기도 전에 구축하고 있는 것은 저뿐만이 아닙니다. 에이전트 친화적인 엔드포인트(endpoints)를 조용히 추가하거나, 플릿 관리(fleet-management) 도구를 구축하거나, 인간 중심의 플레이북(human-centric playbook)에는 유사한 사례가 없는 거버넌스 에이전트 시스템(governed agent systems)을 위한 동의 모델(consent models)을 설계해 온 엔지니어들로부터 정기적으로 이와 유사한 이야기를 듣곤 합니다.

용어(vocabulary)는 중요합니다. 용어 없이도 구축할 수 없기 때문이 아니라 — 분명히 구축할 수 있습니다 — 용어를 갖는 것이 여러분이 무엇을 지향하는지를 바꾸기 때문입니다. 그것은 여러분이 제안(pitch)하는 방식을 바꿉니다. 누구와 함께 구축하는지를 바꿉니다. "이것은 에이전트 우선 인프라(agent-first infrastructure)입니다"라는 말은 "이것은 API를 갖춘 개발자 도구입니다"라는 말과는 다른 대화입니다. 이는 다른 설계 방향성, 다른 일련의 트레이드오프(tradeoffs), 그리고 다른 종류의 얼리 어답터(early adopter)를 의미합니다.

Auth.md는 우리에게 공통된 언어를 제공합니다. '그렇다, 이것은 실제적인 문제이며, 여기에는 이러한 흐름(flows)과 기본 요소(primitive)가 있으니, 이를 바탕으로 구축하라'고 말하는 사양(spec)입니다.

만약 이 글을 읽으면서 '맞아, 바로 내가 느껴왔던 게 이거야'라는 생각이 든다면, 당신만 그런 것이 아닙니다. '고객으로서의 에이전트(agents-as-customer)'로의 전환은 이미 일어나고 있습니다. 당신은 그것을 명명하지 않았을 뿐, 이미 그것을 위해 무언가를 구축해 왔을지도 모릅니다. 괜찮습니다. 뒤처진 것이 아닙니다. 당신은 이미 그 흐름 속에 있습니다.

핵심 요약 (The Bottom Line)

WorkOS의 Auth.md는 에이전트 시대에 출시된 가장 중요한 개발자 기본 요소(developer primitives) 중 하나입니다. 이것이 복잡해서가 아니라, 의도적으로 단순하기 때문입니다. 우리가 이미 신뢰하고 있는 표준들 위에서, "에이전트가 한 번도 본 적 없는 서비스에 어떻게 인증(authenticate)할 것인가?"라는 질문에 대한 최초의 표준화된 해답이기 때문입니다.

더 중요한 것은, 이것이 하나의 카테고리를 명명했다는 점입니다.

"에이전트가 당신의 새로운 고객이다"라는 말은 과장(hype)이 아닙니다. 이는 이미 점점 더 많은 서비스에 적용되고 있는 사실을 재정의한 것입니다. Auth.md는 그 문장을 실행 가능하게 만드는 인프라입니다. 즉, 플랫폼이 대신 해주기를 기다리는 것이 아니라, 오늘 바로 구현할 수 있는 무언가입니다.

저는 이 분야에서 무언가를 구축하고 있습니다. 만약 당신도 이 분야에서 작업 중이거나, 이쪽으로 끌리는 느낌을 받기 시작했다면, 이제 용어(vocabulary)가 준비되었습니다. GitHub의 Auth.md 사양부터 시작해 보세요. 당신의 auth.md를 게시하세요. 문을 열고 들어오려는 에이전트의 눈에 당신의 서비스가 어떻게 보이는지 확인해 보세요.

당신은 생각보다 에이전트 우선(agent-first) 방식에 더 가까이 있을지도 모릅니다.

제 작업과 관련된 맥락: Stop Connecting Your Agents One by One — MeshWire의 탄생 이야기. Hookflows: Governed Git for AI Agents — 인간이 아닌 에이전트를 위한 거버넌스(governance) 구축. Three Layers Your AI Agent Is Missing — 에이전트 우선 시스템을 어렵게 만드는 인프라 격차.