Auth for Agents: Let AI Sign Up for Your Product with auth.md — Michael Grinich, WorkOS

한 줄 핵심

에이전트가 사람 대신 서비스에 가입하고 사용하도록 하려면 기존 로그인·가입 흐름을 넘어선 ‘agent-native registration’이 필요하며, 이를 위해 auth.md라는 개방형 규격으로 등록 단계만 먼저 해결하자는 제안이다.

시간별 요약

1. 0:00
   소개 에이전트가 더 자율적으로 동작하면서 웹의 더 많은 서비스에 접근할 수 있도록 만드는 방법을 다루는 발표의 문제의식을 제시한다.
2. 0:32
   사람 개입형 코딩에서 자율 코딩으로 모델 성능 향상으로 한 번의 지시만으로도 에이전트가 장시간 코드를 작성하고 기능이나 제품 전체를 만들 수 있게 되었고, 병렬 실행까지 가능해지면서 소프트웨어 개발 방식 자체가 바뀌고 있다.
3. 2:22
   자율주행차에서 얻는 교훈 자율주행차처럼 인터페이스와 사람의 개입을 줄인 시스템이 보편화되듯, 에이전트도 낮은 수준의 조작보다 더 높은 수준의 목표 설정과 판단을 맡는 방향으로 진화한다.
4. 3:27
   에이전트가 성공하려면 필요한 것 에이전트가 일을 끝내려면 안전한 실행 환경, 실제로 행동할 수 있는 도구, 목표와 시스템을 이해할 맥락, 결과를 검증하는 피드백, 그리고 최종적인 인간 검토가 모두 필요하다.
5. 4:27
   모델은 엔진, 하네스는 자동차 LLM은 단독으로는 쓸 수 없고 차체·전송계·바퀴에 해당하는 하네스와 결합될 때 비로소 유용해지며, 모델이 좋아질수록 실행 환경 설계의 중요성도 함께 커진다.
6. 5:27
   에이전트가 벤더를 고르는 시대 에이전트가 서비스 구축 과정에서 이메일, 배포, 저장소, 미디어 처리 같은 벤더를 직접 선택하고 연구하기 시작하면서, 제품은 사람보다 에이전트를 위한 설계가 더 중요해지고 있다.
7. 6:17
   에이전트가 원하는 것을 만들어야 한다 미래의 소비자는 사람만이 아니라 더 빠르게 생성되고 더 많은 결정을 대신하는 에이전트이므로, 제품은 사람들이 원하는 것뿐 아니라 에이전트가 쉽게 선택하고 사용할 수 있는 것도 제공해야 한다.
8. 6:52
   빠져 있는 기본 요소: 에이전트 등록 웹과 모바일은 열려 있어도 서비스 가입 단계는 여전히 사람 중심이라서, 에이전트가 처음부터 시스템에 합법적으로 들어오는 등록 절차가 부재한 것이 가장 큰 병목으로 남아 있다.
9. 7:32
   가입 흐름이 에이전트를 막는 이유 기존 가입·로그인 흐름은 봇 차단, 캡차, 이메일 확인, API 키 복사 같은 사람 전용 가정 위에 만들어져 있어, 좋은 에이전트와 나쁜 에이전트를 구분하면서도 에이전트 친화적으로 열어주기가 어렵다.
10. 9:12
    에이전트 네이티브 등록에 필요한 것 에이전트 등록에는 서비스 발견 가능성, 기능 선언, 등록 의도, 위험 평가, 신원 검증, 조직·권한·감사 가능성 같은 요소가 필요하며, 인간 가입을 그대로 옮겨서는 해결되지 않는다.
11. 10:26
    MCP만으로는 충분하지 않다 MCP는 도구, 스킬, 맥락 연결에는 강하지만 등록 단계 자체를 해결하지 못하며, 오늘날의 MCP 인증은 결국 사람이 승인과 로그인을 대신해야 하므로 에이전트 네이티브 등록과는 다르다.
12. 11:06
    auth.md 소개 auth.md는 서비스에 합법적으로 가입하기 위한 절차를 에이전트에게 알려주는 개방형 명세로, 기존 표준 위에서 등록 단계만 먼저 해결하려는 좁고 실용적인 제안이다.
13. 12:16
    auth.md 파일이 설명하는 것 auth.md에는 서비스 설명, 허용되는 신원 증명 방식, SSO·email·MFA 같은 가입 흐름, 스코프와 권한, 무료 티어 제한, 사후적인 인간 또는 조직의 인계 방식이 담긴다.
14. 13:01
    Cloudflare에 에이전트가 가입하는 데모 에이전트가 auth.md를 읽고 Cloudflare 같은 서비스를 찾아 스스로 가입한 뒤, ID-JAG라는 신원 진술을 전달해 계정을 만들고 Wrangler로 배포까지 이어가는 흐름이 실제로 동작한다.
15. 15:56
    등록 흐름과 ID-JAG 에이전트 하네스가 사용자 신원 서비스와 연결되어 탐색 요청을 보내고, 서명된 ID-JAG를 전달해 접근 토큰을 받은 뒤, 이후에는 일반 API 호출과 MCP 사용을 그대로 이어갈 수 있다.
16. 17:01
    빌더와 제공자에게 주는 이점 빌더는 긴 계획과 가입 작업 없이 바로 동작하는 프로토타입을 얻고, 제공자는 에이전트라는 새로운 고객층을 확보해 성장 퍼널을 넓힐 수 있으며, 결제는 가입보다 뒤에 두는 편이 자연스럽다.
17. 18:46
    Salesforce의 헤드리스 전환 Salesforce처럼 대형 SaaS도 UI를 줄이고 API, MCP, CLI를 전면에 두는 방향으로 움직이고 있어, 에이전트를 중심에 둔 제품 설계가 더 이상 주변적이지 않음을 보여준다.
18. 19:26
    GitHub의 공개 명세 이 규격은 GitHub의 오픈 스펙으로 공개되어 있어 특정 벤더에 종속되지 않고 각자의 시스템에 직접 구현하거나 자체 호스팅할 수 있다.
19. 19:51
    마무리 iPhone이 새로운 소프트웨어 플랫폼을 열었듯 에이전트도 다음 세대의 플랫폼이 될 것이므로, 지금부터 auth.md 같은 기반을 함께 만들어가자는 메시지로 마무리한다.

실무 인사이트

• 에이전트용 제품 전략은 기능 추가보다 먼저 ‘가입과 권한 부여’부터 다시 설계해야 하며, 이 지점이 열리면 사용량과 전환이 함께 커질 가능성이 높다.
• MCP나 도구 연동이 잘 되어 있어도 등록 단계가 막혀 있으면 자동화는 중단되므로, 도구 연결과 등록 규격을 분리해서 봐야 한다.
• 초기에는 결제를 앞세우기보다 무료·제한적 접근을 허용한 뒤 신뢰와 사용량을 쌓는 방식이 에이전트 경제에 더 잘 맞는다.