💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 왜 지금 에이전트 웹이 화제인가

2026년 상반기 내내 Hacker News와 GeekNews의 상단을 번갈아 차지한 주제가 하나 있습니다. 바로 "AI 에이전트가 사람을 대신해 웹 서비스에 가입하고, 로그인하고, 결제하고, 행동하는 세계를 우리는 어떻게 설계해야 하는가"라는 질문입니다.

지난 2년 동안 우리는 AI 에이전트가 "읽는" 단계를 충분히 경험했습니다. 검색하고, 문서를 요약하고, 코드를 작성했습니다. 그런데 2026년에 들어서면서 분위기가 바뀌었습니다. 에이전트가 "쓰는" 단계, 즉 외부 서비스에 계정을 만들고 양식을 채우고 구독을 신청하고 API 키를 발급받는 일을 사용자 대신 수행하기 시작한 것입니다.

여기서 근본적인 마찰이 생깁니다. 오늘날의 웹은 철저히 "사람이 브라우저로 클릭한다"는 가정 위에 세워져 있습니다. CAPTCHA, 이메일 인증, 약관 동의 체크박스, 휴대폰 본인 확인. 이 모든 것은 반대편에 사람이 있다고 전제합니다. 에이전트는 이 가정을 깨뜨립니다. 그래서 누군가는 에이전트를 차단하려 하고, 누군가는 에이전트를 정식 손님으로 맞이할 표준을 만들려 합니다.

그 표준 논의의 한가운데에 등장한 것이 바로 auth.md 같은 "도메인 루트 규약" 제안입니다. WorkOS를 비롯한 인증 인프라 진영에서 흘러나온 이 아이디어는, 사이트가 자신의 인증 정책을 기계가 읽을 수 있는 형태로 도메인 루트에 게시하자는 것입니다. 마치 robots.txt가 크롤러에게 "여기는 들어와도 되고 저기는 안 된다"고 알려주듯이 말입니다.

이 글에서는 에이전트 웹이라는 흐름의 정체를 짚고, auth.md 제안을 robots.txt와 sitemap의 계보 위에서 해석합니다. 그 다음 OAuth와 위임 토큰이라는 기존 권한 위임 기술이 이 그림에 어떻게 들어맞는지, 봇 구분과 악용 우려는 무엇인지, 표준화의 과제와 설계 시 고려 사항은 무엇인지를 차례로 정리합니다.

미리 한 가지 관점을 제시하자면, 이 모든 논의의 밑바탕에는 단순한 비대칭이 있습니다. 에이전트는 사람이 아닌데도 사람을 위해 설계된 관문을 통과해야 한다는 비대칭입니다. 이 비대칭을 해소하는 방법은 둘 중 하나입니다. 에이전트를 더 사람처럼 만들거나(위장), 관문을 에이전트도 통과할 수 있게 다시 설계하거나(표준). auth.md는 명백히 후자의 길입니다. 그리고 이 글의 입장도 후자가 장기적으로 더 건강하다는 쪽입니다.

에이전트 웹이란 무엇인가 — 읽기에서 행동으로

세 단계의 에이전트 진화

에이전트가 웹과 맺는 관계는 대략 세 단계로 나눌 수 있습니다.

1단계: 읽기 (Read)

- 검색, 요약, 정보 추출

- 부작용 없음, 멱등적

- 예: "이 페이지 요약해줘"

2단계: 상호작용 (Interact)

- 양식 채우기, 클릭, 탐색

- 세션 내 일시적 상태 변경

- 예: "이 항공편 검색해서 가격 비교해줘"

3단계: 행동 (Act / Commit)

- 가입, 결제, 구독, 게시, 삭제

- 영속적이고 되돌리기 어려운 변경

- 예: "이 서비스에 가입하고 월 구독 신청해줘"

1단계와 2단계는 이미 익숙합니다. 진짜 문제는 3단계입니다. 가입은 한 번 일어나면 데이터베이스에 사용자 레코드가 생기고, 결제는 돈이 실제로 빠져나갑니다. 이 단계에서는 "누가 이 행동을 승인했는가"와 "이 행동의 책임은 누구에게 있는가"가 결정적으로 중요해집니다.

에이전트 가입 시나리오의 현실

구체적인 시나리오를 떠올려 봅시다. 사용자가 자신의 개인 비서 에이전트에게 이렇게 말합니다. "다음 달 출장에 쓸 협업 도구를 알아보고, 괜찮으면 무료 체험에 가입해줘."

에이전트는 후보 서비스를 찾고, 가입 페이지에 도달합니다. 그런데 거기서 막힙니다.

+------------------------------------------+

| 무료 체험 시작하기 |

| |

| 이메일: [ ____________________ ] |

| 비밀번호: [ ____________________ ] |

| [ ] 만 14세 이상이며 약관에 동의합니다 |

| |

| [ 사람인지 확인하세요: CAPTCHA ] |

| |

| [ 가입하기 ] |

+------------------------------------------+

여기서 에이전트는 네 가지 벽에 부딪힙니다.

1. **이메일 인증**: 가입 후 메일함의 링크를 클릭해야 한다면, 에이전트가 그 메일함에 접근할 권한이 있는가.

2. **약관 동의**: 약관에 법적으로 동의할 권한이 에이전트에게 있는가. 사용자가 위임한 권한의 범위는 어디까지인가.

3. **CAPTCHA**: 사람임을 증명하라는 요구. 에이전트는 사람이 아니다.

4. **결제 정보**: 유료 전환 시 카드 정보를 입력할 권한이 있는가.

오늘날 많은 에이전트는 이 벽을 "사람처럼 위장해서" 넘으려 합니다. 헤드리스 브라우저로 픽셀을 클릭하고, CAPTCHA 우회 서비스를 쓰고, 사용자의 이메일 비밀번호를 직접 보관합니다. 이것이 바로 문제의 핵심입니다. 명시적 표준이 없으니 에이전트는 사람 흉내를 내고, 사이트는 그 흉내를 탐지해 차단하려 하고, 양쪽 모두 군비 경쟁에 빠집니다.

에이전트 웹 표준화 논의의 출발점은 단순합니다. "에이전트가 사람인 척하지 않아도 되는 정직한 통로를 만들자."

auth.md 제안 — 도메인 루트 규약의 발상

robots.txt와 sitemap의 계보

auth.md를 이해하려면 먼저 그 조상을 봐야 합니다. 웹에는 오래전부터 "도메인 루트에 약속된 파일을 두어 기계와 대화한다"는 패턴이 있었습니다.

| 파일 | 등장 시기 | 대상 | 역할 |

| --- | --- | --- | --- |

| robots.txt | 1994년 | 크롤러 | 어디를 크롤링해도 되는지 알림 |

이 계보를 보면 패턴이 분명합니다. 새로운 기계 행위자가 등장할 때마다, 웹은 도메인 루트에 그 행위자를 위한 안내문을 추가해 왔습니다. 크롤러에게는 robots.txt, 검색엔진에게는 sitemap, 보안 연구자에게는 security.txt를 주었듯이, 이제 인증 에이전트에게는 auth.md를 주자는 것입니다.

auth.md가 담을 수 있는 것

auth.md의 핵심 발상은 "이 사이트에 에이전트가 어떻게 정당하게 인증하고 가입할 수 있는지"를 기계가 읽을 수 있는 형태로 기술하는 것입니다. 아직 확정된 표준은 아니므로, 논의되는 항목을 개념적으로 정리하면 다음과 같은 형태가 될 수 있습니다.

https://example.com/auth.md (개념 예시 — 확정 표준 아님)

Agent Sign-up Policy

Agents allowed: yes

Human-in-the-loop required: for-payment

Identity verification: oauth, did

Endpoints

Registration: https://example.com/.well-known/agent-register

Token endpoint: https://example.com/oauth/token

Scopes supported: read, create-account, subscribe

Terms

Terms URL: https://example.com/terms

Machine-readable terms: https://example.com/terms.json

Agent must present: delegation-token

Rate and Abuse

Max accounts per delegated principal: 1

Contact: agents@example.com

여기서 핵심은 세 가지입니다.

1. **정책의 명시**: 사이트가 에이전트 가입을 허용하는지, 결제 같은 민감 행동에 사람의 개입을 요구하는지를 기계가 읽을 수 있게 선언합니다.

2. **엔드포인트의 안내**: 에이전트가 사람 흉내 대신 호출할 정식 등록 엔드포인트와 토큰 엔드포인트를 가리킵니다.

3. **약관의 기계 판독**: 약관을 사람이 읽는 HTML뿐 아니라 기계가 파싱할 수 있는 형태로도 제공해, 에이전트가 동의 조건을 이해하고 위임 범위를 확인할 수 있게 합니다.

왜 마크다운인가

이름이 auth.md인 이유는 형식으로 마크다운을 택했기 때문입니다. llms.txt가 그랬듯, 마크다운은 사람도 읽기 쉽고 LLM이 파싱하기도 쉽습니다. JSON이나 XML보다 사람 친화적이면서, 에이전트의 LLM 코어가 자연스럽게 해석할 수 있다는 절충안입니다. 다만 기계 파싱의 엄밀성을 위해 구조화된 블록(예: 위 예시의 키-값)이나 별도의 JSON 보충 파일을 병행하자는 의견도 있습니다.

이 형식 논쟁 자체가 에이전트 웹 표준화의 특징을 보여줍니다. 한쪽 끝에는 사람 친화성(마크다운, 자연어)이 있고 다른 쪽 끝에는 기계 엄밀성(JSON 스키마, 서명된 토큰)이 있습니다. 에이전트는 이 둘 사이에 있는 존재라서, 표준도 그 사이 어딘가에 자리 잡으려 합니다.

권한 위임의 기술 — OAuth와 위임 토큰

auth.md가 "정책 게시판"이라면, 실제로 에이전트에게 권한을 안전하게 넘기는 일은 OAuth 계열 기술이 담당합니다. 여기서 핵심 질문은 이것입니다. "사용자가 에이전트에게 자신을 대신할 권한을 주되, 그 범위를 어떻게 제한하고 추적할 것인가."

OAuth 위임 모델의 재해석

OAuth 2.0은 원래 "사용자가 제3자 앱에게 자기 데이터 접근을 위임"하기 위해 만들어졌습니다. 에이전트 웹은 이 모델을 한 단계 더 밀어붙입니다. 위임받는 주체가 사람이 설치한 앱이 아니라, 사람을 대신해 자율적으로 행동하는 에이전트라는 점이 다릅니다.

전통적 OAuth와 에이전트 위임의 차이를 정리하면 다음과 같습니다.

| 측면 | 전통적 OAuth 앱 | 자율 에이전트 |

| --- | --- | --- |

| 위임 주체 | 사용자가 명시적으로 설치/승인한 앱 | 사용자의 자연어 지시로 동적 생성 |

| 행동 예측성 | 앱의 기능 범위 내 고정 | LLM 추론에 따라 가변적 |

| 권한 범위 | 설치 시점에 스코프 확정 | 작업마다 필요한 스코프가 달라짐 |

| 책임 추적 | 앱 단위 | 에이전트-작업-위임자 체인 단위 |

이 차이 때문에, 에이전트 위임에서는 스코프를 더 잘게 쪼개고, 토큰의 수명을 짧게 하고, 위임 체인을 명확히 기록하는 일이 더 중요해집니다.

위임 토큰의 구조

에이전트가 사이트에 "나는 이 사용자의 위임을 받아 가입하려 한다"고 증명하려면, 위임 사실을 담은 토큰이 필요합니다. 개념적으로 위임 토큰은 다음과 같은 주장을 담습니다.

{

"iss": "https://agent-platform.example",

"sub": "agent-instance-7f3a",

"act": {

"sub": "user:alice@personal.example",

"delegation_id": "del-2026-06-25-abc"

"aud": "https://example.com",

"scope": "create-account subscribe:trial",

"constraints": {

"max_monthly_spend": "0",

"human_approval_for": ["payment", "data-deletion"]

"exp": 1782000000,

"iat": 1781996400

}

여기서 act 클레임이 핵심입니다. 이것은 OAuth 토큰 교환 표준(RFC 8693)에 정의된 "actor" 개념으로, "이 토큰을 들고 행동하는 주체(에이전트)가 실제로는 다른 주체(사용자)를 대신하고 있다"는 위임 관계를 표현합니다. 즉 "에이전트 7f3a가 사용자 alice를 대신해 행동 중"이라는 사실이 토큰 자체에 박혀 있습니다.

constraints 블록은 위임의 한계를 못 박습니다. 월 지출 한도를 0으로 두고, 결제와 데이터 삭제처럼 위험한 행동에는 사람의 승인을 요구합니다. 사이트는 이 토큰을 검증함으로써, 사람 흉내를 탐지하는 군비 경쟁 대신 "정직하게 선언된 위임"을 받아들일 수 있습니다.

토큰 교환과 위임 체인

실제 흐름에서는 토큰이 여러 단계로 교환됩니다. 사용자가 에이전트 플랫폼에 로그인하고, 플랫폼이 특정 작업을 위한 좁은 위임 토큰을 발급하고, 에이전트가 대상 사이트의 토큰 엔드포인트에서 이를 교환하는 식입니다.

사용자(Alice)

| 1. 자연어 지시 + 본인 인증

에이전트 플랫폼

| 2. 작업별 위임 토큰 발급 (좁은 스코프, 짧은 수명)

에이전트 인스턴스

| 3. 대상 사이트 토큰 엔드포인트로 교환 (RFC 8693)

대상 사이트(example.com)

| 4. 위임 토큰 검증 -> 가입 허용 또는 거부

사용자 레코드 생성 (위임자=Alice, 행위자=에이전트)

이 체인이 명확하면, 나중에 "누가 이 계정을 만들었는가"를 추적할 수 있습니다. 계정 레코드에 "위임자는 Alice, 실제 가입을 수행한 행위자는 에이전트 인스턴스 7f3a, 위임 ID는 del-2026-06-25-abc"가 남기 때문입니다. 이것이 책임 추적의 토대가 됩니다.

봇 구분과 악용 우려 — 정직한 에이전트와 악성 봇

좋은 봇과 나쁜 봇을 어떻게 가르나

에이전트 웹의 가장 큰 난제는 "정직하게 선언한 에이전트"와 "사람인 척하는 악성 봇"을 구분하는 일입니다. auth.md와 위임 토큰은 정직한 에이전트에게 정문을 열어주지만, 악성 봇은 여전히 뒷문으로 들어오려 합니다.

+---------------------------+

| 에이전트의 4분면 |

+-------------+-------------+

| 정직 + 선언 | 정직하지만 |

| (auth.md | 미선언 |

| 준수) | (그냥 봇) |

+-------------+-------------+

| 악의 + 위장 | 악의 + 선언 |

| (스팸/사기, | 위반 |

| CAPTCHA | (선언 후 |

| 우회) | 약관 위반) |

+-------------+-------------+

이상적인 세계에서는 모든 에이전트가 왼쪽 위, 즉 정직하게 선언하고 정문으로 들어옵니다. 하지만 현실에는 네 분면이 다 존재합니다. 표준의 목표는 정직한 에이전트의 정문 통과를 너무나 쉽고 매력적으로 만들어, 위장의 유인을 줄이는 것입니다. 정문이 뒷문보다 편하면 굳이 위장할 이유가 없어집니다.

검증 가능한 에이전트 신원

정직한 선언만으로는 부족합니다. "나는 정직한 에이전트입니다"라고 누구나 말할 수 있기 때문입니다. 그래서 검증 가능한 신원이 필요합니다. 여기에는 몇 가지 접근이 있습니다.

1. **플랫폼 증명(attestation)**: 신뢰받는 에이전트 플랫폼이 자기 에이전트에 서명을 해줍니다. 사이트는 그 플랫폼의 공개키로 서명을 검증합니다.

2. **분산 신원(DID)**: 에이전트가 탈중앙 식별자와 검증 가능한 자격증명을 제시합니다. 특정 플랫폼에 종속되지 않는 방식입니다.

3. **mTLS와 클라이언트 인증서**: 에이전트가 상호 TLS로 자신을 인증합니다. 기업 간 통신에서 익숙한 방식입니다.

핵심은 "에이전트가 누구의 위임을 받았고, 어떤 플랫폼이 그 에이전트를 보증하는가"를 암호학적으로 검증할 수 있어야 한다는 점입니다. 검증 가능한 신원이 있어야, 사이트는 악용 시 책임을 추적하고 신뢰를 철회할 수 있습니다.

악용 시나리오와 방어

에이전트 웹이 열어줄 수 있는 악용 시나리오를 솔직하게 짚어 봅시다.

| 악용 | 메커니즘 | 방어 |

| --- | --- | --- |

| 대량 계정 생성 | 봇이 한 사람 위임으로 수천 계정 생성 | 위임자당 계정 한도(auth.md 명시), 위임 ID 추적 |

| 무료 체험 남용 | 에이전트가 체험만 반복 가입 | 위임자 단위 중복 탐지, 결제 사람 승인 강제 |

| 약관 우회 동의 | 에이전트가 읽지 않고 무조건 동의 | 기계 판독 약관 + 위임 범위 명시, 동의 책임 위임자 귀속 |

| 자동 스팸/게시 | 에이전트가 콘텐츠 대량 생성 | 게시 스코프 분리, 레이트 리밋, 행위자 추적 |

| 사회공학 | 에이전트가 다른 사용자 사칭 | 검증 가능한 신원 강제, 사칭 불가 |

방어의 공통 원리는 "익명의 사람 흉내"를 "추적 가능한 선언된 위임"으로 바꾸는 것입니다. 익명 봇은 차단하기 어렵지만, 위임 ID와 검증 가능한 신원이 붙은 에이전트는 악용 시 그 위임자와 플랫폼까지 거슬러 올라갈 수 있습니다.

동의와 책임 — 에이전트가 약관에 동의할 수 있는가

위임의 법적 무게

기술 문제를 넘어, 에이전트 웹에는 까다로운 동의 문제가 있습니다. 에이전트가 사용자를 대신해 약관에 "동의" 버튼을 누를 때, 그 동의는 법적으로 유효한가. 사용자가 "알아서 가입해줘"라고 한 마디 했을 뿐인데, 그것이 50페이지짜리 약관에 대한 유효한 동의가 되는가.

이 문제는 위임의 범위와 명확성에 달려 있습니다. 위임 토큰의 scope와 constraints가 "이 에이전트는 무료 체험 가입만, 결제는 사람 승인"처럼 명확할수록, 그 범위 내 행동에 대한 동의는 위임자에게 귀속된다고 보기 쉽습니다. 반대로 범위가 모호한 "전권 위임"은 분쟁의 씨앗이 됩니다.

사람의 개입이 필요한 지점

그래서 많은 설계가 "사람의 개입(human-in-the-loop)"을 특정 행동에 강제합니다. 위 토큰 예시의 human_approval_for 필드가 그것입니다. 일반적으로 다음 행동은 사람의 명시적 확인을 요구하는 것이 안전합니다.

자동 위임 OK 사람 확인 필요

--------------- ---------------

- 정보 조회 - 결제/구독 확정

- 무료 가입 - 개인정보 제3자 제공 동의

- 양식 임시 저장 - 데이터 영구 삭제

- 비교/추천 - 법적 구속력 있는 계약 체결

- 읽기 전용 API - 평판에 영향 주는 공개 게시

이 경계선은 고정된 것이 아니라, 위임자의 신뢰 수준과 행동의 되돌릴 수 없음에 따라 조정됩니다. 핵심 원칙은 "되돌리기 어렵고 영향이 큰 행동일수록 사람의 손가락이 실제로 버튼을 눌러야 한다"는 것입니다.

실무 적용 — 사이트와 에이전트 양쪽의 설계

사이트 운영자를 위한 체크리스트

당신이 서비스를 운영한다면, 에이전트 웹에 대비해 다음을 점검할 수 있습니다.

[ 정책 게시 ]

[ ] 에이전트 가입을 허용/조건부 허용/금지 중 무엇으로 할지 결정했는가?

[ ] auth.md 같은 기계 판독 정책을 게시할 계획이 있는가?

[ ] 약관을 기계 판독 형태로도 제공할 수 있는가?

[ 정문 만들기 ]

[ ] 사람 흉내 대신 호출할 정식 등록/토큰 엔드포인트가 있는가?

[ ] 위임 토큰(RFC 8693 actor 클레임)을 검증할 수 있는가?

[ ] 위임자당 계정 한도, 레이트 리밋을 정의했는가?

[ 추적과 책임 ]

[ ] 계정 레코드에 위임자와 행위자를 분리 기록하는가?

[ ] 악용 시 위임 ID로 추적하고 신뢰를 철회할 수 있는가?

[ ] 민감 행동에 사람 승인을 강제하는 게이트가 있는가?

흥미로운 점은, 에이전트를 환영하든 차단하든 auth.md 같은 정책 명시는 둘 다에게 유용하다는 것입니다. 차단하려는 사이트는 "에이전트 가입 금지"를 명시할 수 있고, 환영하려는 사이트는 정문을 안내할 수 있습니다. robots.txt가 크롤링을 허용하는 사이트와 금지하는 사이트 모두에게 쓸모 있었던 것과 같은 이치입니다.

에이전트 개발자를 위한 원칙

반대로 에이전트를 만든다면 다음 원칙을 권합니다.

1. **정직하게 선언하라**: User-Agent와 위임 토큰으로 "나는 에이전트이며 누구의 위임을 받았다"를 명시하라. 사람 흉내는 단기 이득, 장기 부채다.

2. **auth.md를 먼저 읽어라**: robots.txt를 존중하듯, 사이트의 인증 정책을 먼저 확인하고 정문으로 들어가라.

3. **스코프를 최소화하라**: 작업에 필요한 최소 권한만 요청하라. 전권 위임은 위험하고 거부되기 쉽다.

4. **사람을 적절히 부르라**: 결제처럼 위험한 지점에서는 위임 범위를 넘지 말고 사용자에게 확인을 구하라.

점진적 채택 경로

이 모든 것이 한꺼번에 표준화되지는 않습니다. 현실적인 채택 경로는 점진적입니다.

지금 (2026):

- 일부 사이트가 llms.txt/실험적 auth.md 게시

- 주요 에이전트 플랫폼이 위임 토큰 시범 도입

- RFC 8693 토큰 교환은 이미 성숙

다음 단계:

- well-known 경로 표준화 시도 (IETF/W3C 논의)

- 기계 판독 약관 포맷 합의

- 검증 가능한 에이전트 신원 생태계 형성

성숙기:

- 정문 통과가 뒷문보다 쉬워짐

- 사람 흉내 군비 경쟁의 유인 감소

지금 단계에서 개인 개발자가 할 수 있는 가장 실용적인 일은, 이미 성숙한 OAuth 토큰 교환과 스코프 설계를 제대로 익혀 두는 것입니다. auth.md가 어떤 형태로 표준화되든, 그 아래에서 권한을 안전하게 위임하는 일은 결국 OAuth 계열 기술이 담당할 것이기 때문입니다.

자주 나오는 질문

**Q1. auth.md는 robots.txt처럼 강제력이 있나요?**

없습니다. robots.txt가 그렇듯 auth.md도 자율적 규약입니다. 강제력은 표준 자체가 아니라 검증 가능한 신원과 토큰 검증에서 나옵니다. 사이트가 위임 토큰을 실제로 검증하고, 정문 통과를 정직한 에이전트에게만 허용한다면, 그것이 사실상의 강제력이 됩니다. auth.md는 "어디로 들어오라"는 안내문이고, 강제는 그 정문에서 일어납니다.

**Q2. CAPTCHA는 이제 사라지나요?**

당분간은 아닙니다. auth.md와 위임 토큰은 정직한 에이전트를 위한 정문이지, 악성 봇을 막는 도구를 대체하지 않습니다. 오히려 정문이 생기면 CAPTCHA는 "선언하지 않은 트래픽"에만 집중할 수 있게 됩니다. 정직한 에이전트는 토큰으로 통과하고, 정체불명 트래픽만 CAPTCHA를 만나는 식으로 역할이 분담됩니다.

**Q3. 작은 사이트도 이걸 구현해야 하나요?**

당장은 아닙니다. 대부분의 작은 사이트는 표준이 성숙할 때까지 기다려도 됩니다. 다만 에이전트 가입을 명시적으로 금지하고 싶다면, 그 의사를 표시할 수단이 생긴다는 점은 알아 둘 가치가 있습니다. 환영이든 거부든, 명시적 선언이 양쪽 모두에게 이롭습니다.

**Q4. 위임 토큰과 일반 OAuth 액세스 토큰의 차이는?**

핵심 차이는 act(actor) 클레임입니다. 일반 액세스 토큰은 "이 토큰의 주체가 행동한다"고만 말하지만, 위임 토큰은 "주체(에이전트)가 다른 주체(사용자)를 대신해 행동한다"는 위임 관계를 명시합니다. 이로써 책임 추적이 가능해집니다.

**Q5. 에이전트가 사람보다 더 신뢰받게 되는 역설이 가능한가요?**

흥미롭게도 그렇습니다. 검증 가능한 신원과 명시적 위임 범위를 가진 에이전트는, 익명으로 가입하는 사람보다 오히려 추적 가능하고 책임이 명확할 수 있습니다. 정직하게 선언된 에이전트가 익명의 사람보다 더 "1급 시민"에 가까워지는 미래도 상상할 수 있습니다.

함정과 비판적 시각

균형을 위해 에이전트 웹과 auth.md 제안에 대한 회의론도 정리합니다.

1. **표준이 또 하나 늘어날 뿐이라는 비판**: 도메인 루트에 파일을 또 추가하는 일이 정말 문제를 푸는가. robots.txt는 강제력이 없어 악성 크롤러는 무시한다. auth.md도 정직한 에이전트만 따를 것이고, 악성 봇은 여전히 사람 흉내를 낼 것이다. 즉 표준은 정직한 쪽의 비용만 늘리고 악성 쪽은 막지 못할 수 있다.

2. **검증 인프라의 부재**: 위임 토큰과 검증 가능한 신원이 작동하려면, 누가 신뢰받는 발급자인지에 대한 합의와 인프라가 필요하다. 이 신뢰 앵커 문제는 아직 풀리지 않았다. 소수 빅테크 플랫폼만 신뢰받으면 중앙집중화 우려가 생긴다.

3. **동의의 형해화**: 에이전트가 약관에 자동 동의하는 관행이 굳어지면, 가뜩이나 아무도 안 읽는 약관이 더욱 형식화된다. 기계 판독 약관이 오히려 "에이전트가 알아서 동의했으니 됐다"는 면피 수단이 될 위험이 있다.

4. **중앙집중과 게이트키핑**: 사이트가 "검증된 플랫폼의 에이전트만 허용"하기 시작하면, 소수의 거대 에이전트 플랫폼이 웹의 새로운 관문이 된다. 이는 개방형 웹의 정신과 충돌할 수 있다.

5. **시기상조 논란**: 아직 에이전트가 사람 대신 가입하는 일이 보편적이지도 않은데 표준부터 만드는 것은 과잉 대응이라는 시각. 반대로, robots.txt가 그랬듯 사실상의 관행이 자리 잡기 전에 표준을 논의해야 파편화를 막는다는 반론도 있다.

6. **포맷 난립의 위험**: 이미 llms.txt, security.txt, ads.txt 등 도메인 루트 파일이 늘어나고 있다. auth.md가 또 하나 추가되면, 사이트 운영자는 관리할 파일이 늘고 일관성을 유지하기 어려워진다. 하나의 통합된 well-known 메타데이터로 수렴해야 한다는 의견과, 용도별로 분리하는 것이 낫다는 의견이 갈린다.

이 비판들은 대부분 타당합니다. 특히 1번, "표준은 정직한 쪽만 따른다"는 지적은 robots.txt의 역사가 증명한 약점입니다. 다만 반론도 있습니다. auth.md의 진짜 가치는 악성 봇을 막는 것이 아니라, 정직한 에이전트의 정문을 너무 편하게 만들어 다수를 정문으로 유도하는 데 있다는 것입니다. 군비 경쟁을 끝내지는 못해도, 정직한 행동의 비용을 낮춰 생태계의 무게중심을 옮길 수는 있다는 논리입니다.

마치며 — 사람 흉내를 끝내는 표준을 향해

에이전트 웹의 핵심 문제는 기술이 아니라 정직함의 인센티브입니다. 오늘날 에이전트가 사람 흉내를 내는 이유는, 정직하게 "나는 에이전트입니다"라고 말할 정문이 없기 때문입니다. auth.md와 위임 토큰의 진짜 목표는 그 정문을 만드는 것입니다.

웹의 역사는 새로운 행위자가 등장할 때마다 그를 위한 정직한 통로를 만들어 온 역사이기도 합니다. 크롤러에게 robots.txt를, 검색엔진에게 sitemap을 준 것처럼, 이제 에이전트에게 정문을 줄 차례입니다. 그 정문이 robots.txt처럼 불완전하더라도, 통로를 만드는 시도 자체가 위장과 탐지의 악순환에서 벗어나는 첫걸음입니다.

정리하면 다음과 같습니다.

1. 웹은 사람이 클릭한다는 가정 위에 세워졌지만, 에이전트가 "행동" 단계로 들어오면서 그 가정이 깨지고 있습니다.

2. auth.md는 robots.txt와 sitemap의 계보를 잇는 도메인 루트 규약으로, 사이트가 에이전트에게 인증 정책을 기계 판독 형태로 알리자는 제안입니다.

3. 실제 권한 위임은 OAuth 토큰 교환(RFC 8693)의 actor 클레임과 좁은 스코프, 짧은 수명의 위임 토큰으로 구현할 수 있습니다.

4. 핵심은 "익명의 사람 흉내"를 "추적 가능한 선언된 위임"으로 바꾸어, 악용 시 위임자와 플랫폼까지 책임을 거슬러 올라갈 수 있게 하는 것입니다.

5. 비판도 타당합니다. 표준은 정직한 쪽만 따르고, 신뢰 앵커는 미해결이며, 중앙집중 우려가 있습니다. 그럼에도 정직한 행동의 비용을 낮추는 일은 가치가 있습니다.

에이전트가 사람을 대신해 행동하는 세계는 이미 시작됐습니다. 질문은 그 세계를 사람 흉내와 탐지의 군비 경쟁으로 채울 것인가, 아니면 정직한 위임과 추적 가능한 책임의 구조로 채울 것인가입니다. auth.md는 그 후자를 향한 작은 한 걸음입니다. 그리고 그 한 걸음의 방향을 정하는 것은 표준 문서가 아니라, 지금 에이전트와 서비스를 만드는 우리의 설계 결정입니다.

당신이 다음에 에이전트나 서비스를 설계할 때, 한 가지만 자문해 보십시오. "이 시스템은 에이전트가 정직하게 자신을 밝히도록 유도하는가, 아니면 숨도록 강요하는가." 이 작은 질문이 모여 에이전트 웹의 성격을 결정합니다.

참고 자료

- [WorkOS Blog — The Agentic Web and authentication standards](https://workos.com/blog)

- [GeekNews — auth.md와 에이전트 웹 인증 논의](https://news.hada.io/)

- [Hacker News](https://news.ycombinator.com/)

- [RFC 8693 — OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)

- [RFC 6749 — The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749)

- [robots.txt 표준 (RFC 9309 — Robots Exclusion Protocol)](https://datatracker.ietf.org/doc/html/rfc9309)

- [security.txt (RFC 9116)](https://datatracker.ietf.org/doc/html/rfc9116)

- [llms.txt proposal](https://llmstxt.org/)

- [W3C Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/)

- [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/)