user agent 허용 목록은 웹에서 가장 오래된 패턴 중 하나입니다. 신뢰하는 크롤러와 클라이언트 이름을 목록으로 유지합니다. 요청이 일치하는 User-Agent 헤더와 함께 들어오면 통과시키거나, 챌린지를 건너뛰게 하거나, 더 가벼운 페이지를 제공합니다. 설정은 몇 분이면 끝나고, 팀원 누구나 이해할 수 있습니다.
이 패턴은 주로 자동 방문자가 몇 개의 검색 크롤러와 일부 모니터링 도구에 불과하던 시절에는 더 타당했습니다. 오늘날에는 AI 에이전트, 어시스턴트, 자동 클라이언트가 점점 더 많은 수로 애플리케이션에 접근하고, 그들 중 많은 수가 이름을 밝힙니다. 그 이름 중 일부는 실제입니다. 일부는 복사된 것입니다. 헤더만으로는 구분할 수 없습니다.
Proof of Actor는 다른 접근법을 사용합니다. User-Agent 문자열을 있는 그대로, 즉 선언으로 취급하고, 더 강한 증거가 있을 때는 그것과 함께 표시합니다. 이 페이지에서는 이름 기반 허용 목록의 한계, 네트워크 수준 검사가 도움이 되는 지점, 그리고 검증된 서명과 명시적인 Unknown 클래스가 어떻게 상황을 바꾸는지 설명합니다.
짧은 요약
| user agent 허용 목록 | Proof of Actor | |
|---|---|---|
| 주요 증거 | User-Agent 헤더의 이름 | 서명, 선언, 신호, 각각 근거와 함께 표시됨 |
| 클라이언트가 위조할 수 있나요? | 예, 같은 문자열을 보내면 됩니다 | 선언된 근거는 주장할 수 있지만, 검증된 근거에는 서명 키가 필요합니다 |
| 출력 | 목록에 있음 또는 없음 | Human, Human + AI, Agent 또는 Unknown, 그리고 근거 |
| 불분명한 트래픽 | 허용 목록에 없음으로 처리되거나 기본 허용 | Unknown, 라우트별로 선택하는 대체 동작 포함 |
| AI를 함께 사용하는 사람 | 보이지 않음, 일반 브라우저를 사용함 | 선언되거나 관찰되면 별도 클래스인 Human + AI |
| 유지 관리 | 이름이 바뀔 때 수동으로 목록 갱신 | 에이전트 운영자가 공개한 키, 귀사 코드의 정책 |
| 설치 직후 기본값 | 목록이 허용하는 그대로 | 관찰, 정책을 추가하기 전까지는 아무 것도 바뀌지 않음 |
| 가장 적합한 용도 | 잘 알려진 정상 클라이언트의 저비용 라우팅 | 제품 및 정책 결정을 위한 증거 기반 actor 컨텍스트 |
나머지 내용에서는 각 행을 설명합니다.
User-Agent 기반 허용 목록이 위조 가능한 이유
User-Agent 헤더는 클라이언트가 설정합니다. 브라우저가 설정하고, 스크립트가 설정하고, 에이전트 프레임워크가 설정합니다. HTTP에는 그 값이 사실인지 확인하는 장치가 없습니다. 허용 목록이 문자열 하나를 신뢰한다면, 그 문자열을 복사한 누구나 같은 대우를 받게 됩니다.
이것을 user agent spoofing이라고 하며, 이유는 단순합니다. 비용이 들지 않기 때문입니다. 챌린지를 피하려는 스크레이퍼는 신뢰하는 크롤러의 이름을 빌리기만 하면 됩니다. 문제가 있는 클라이언트는 인기 있는 어시스턴트인 척할 수 있습니다. 합법적인 도구조차 라이브러리 기본값 때문에 일반 브라우저 문자열을 보낼 수 있습니다.
그 결과 user agent 허용 목록에는 두 가지 실패 모드가 생깁니다.
- 잘못된 신뢰: 신뢰할 수 없는 클라이언트가 신뢰받는 이름을 주장해 통과합니다.
- 잘못된 의심: 합법적인 클라이언트가 예상 밖이거나 일반적인 문자열을 보내 실패합니다.
헤더만으로는 어느 쪽도 보이지 않습니다. 이것이 핵심 한계이며, 목록을 아무리 관리해도 사라지지 않습니다.
그래도 헤더가 유용한 경우
이렇다고 해서 User-Agent 문자열을 무시해야 한다는 뜻은 아닙니다. 정상적으로 동작하는 크롤러와 에이전트는 자신을 솔직하게 밝히며, 이름은 라우팅, 분석, 디버깅에 유용한 단서가 됩니다. 클라이언트가 자신을 무엇이라고 말하는지 알려 주기 때문입니다.
이 정보는 그 자체로 접근을 여는 키가 아니라, 다른 증거와 함께 평가되는 선언으로 두는 것이 맞습니다. Proof of Actor는 이를 정확히 그렇게 기록합니다.
reverse DNS와 IP 목록: 부분적인 수단
많은 팀이 네트워크 검사로 허용 목록을 강화합니다. 이것도 도움이 되며, 정확히 이해할 가치가 있습니다.
reverse DNS 검증
일부 크롤러 운영자는 검증 절차를 문서화합니다. 요청의 IP 주소에 대한 호스트 이름을 조회하고, 그것이 운영자의 도메인에 속하는지 확인한 뒤, 그 호스트 이름을 다시 조회해 같은 IP로 되돌아오는지 확인합니다. 이 왕복이 성공하면, 요청이 운영자 인프라에서 왔다는 실제 증거를 얻은 것입니다.
한계는 실무적입니다. 문서화하고 지원하는 운영자에게만 적용됩니다. 캐시해야 하는 DNS 조회가 추가됩니다. 그리고 네트워크에 대해 알려 줄 뿐, 그 네트워크에서 어떤 제품이나 에이전트가 요청했는지는 알려 주지 않습니다.
공개된 IP 범위
다른 운영자는 자동 클라이언트가 사용하는 IP 범위를 공개합니다. 요청을 그 범위와 대조하는 것은 빠르며 reverse DNS와 비슷한 증거를 제공합니다. 현재 IETF에서 이러한 범위를 게시하는 표준 형식에 대한 논의가 진행 중이지만, 2026년 11월 기준으로 확정된 표준은 없으며, 범위 공개 여부는 각 운영자의 선택에 달려 있습니다.
IP 증거는 더 많은 에이전트가 공유 클라우드 인프라, 프록시 뒤, 또는 사용자의 기기에서 직접 실행될수록 약해집니다. 하나의 클라우드 주소에는 서로 무관한 여러 클라이언트가 있을 수 있고, 사람의 브라우저에서 동작하는 에이전트는 그 사람의 네트워크처럼 보입니다.
네트워크 검사가 더해 주는 것
reverse DNS와 IP 목록은 잘 알려진 일부 운영자에 대해서는 일부 선언을 더 강한 것으로 바꿔 줍니다. 하지만 에이전트와 도구의 긴 꼬리 부분을 모두 포괄하지 못하고, AI와 함께 일하는 사람에는 전혀 도움이 되지 않습니다. 이것은 부분적인 수단입니다. 사용하기는 좋지만, 단독으로는 부족합니다.
서명과 선언의 차이
더 강한 증거는 암호학적 서명입니다. HTTP Message Signatures는 RFC 9421에 정의되어 있으며, 클라이언트가 각 요청의 선택된 부분에 개인 키로 서명합니다. 검증자는 운영자가 공개한 공개 키를 가져와 서명을 확인합니다. 검증되면 요청은 그 키의 소유자가 서명한 것이며, 서명된 부분이 전달 과정에서 변경되지 않았다는 뜻입니다.
IETF Web Bot Auth 워킹 그룹은 자동 클라이언트가 이러한 서명을 어떻게 사용하고 키를 어떻게 공개하는지 표준화하고 있습니다. 제품 팀을 위한 Web Bot Auth 설명 글에서 현재 상태를 다룹니다.
Proof of Actor는 유효한 서명을 Verified 증거로 사용합니다. User-Agent 문자열, 클라이언트 힌트, 또는 요청 본문에 들어 있는 자기 설명은 Declared로 간주합니다. 행동 및 맥락 신호는 Inferred로 간주하며, 그렇게 표시합니다. 모든 결과는 어떤 근거에 기반하는지 명시하므로, 팀이 주장과 검사를 혼동하지 않습니다. 전체 정의는 evidence basis 항목을 참고하세요.
검증된 증거에도 한계는 하나 있습니다. 유효한 서명은 어떤 키가 요청에 서명했는지만 증명합니다. 그 에이전트가 요청한 작업을 수행할 권한이 있는지는 증명하지 않습니다. 그것은 agent authorization의 문제이며, 애플리케이션 안에 남아 있습니다.
추측 대신 Unknown 처리하기
허용 목록은 모든 요청을 두 가지 중 하나로만 분류합니다. 목록에 있거나, 없거나입니다. 실제로는 불분명한 트래픽이 기본값을 따르게 되며, 그 기본값은 보통 사이트 전체에 대해 한 번만 정해집니다.
Proof of Actor는 Unknown을 일급 결과로 취급합니다. 증거가 신뢰할 수 있는 판정을 뒷받침하지 못하면, 추측하지 않고 그렇게 말합니다. 그런 다음 정책이 각 라우트에서 Unknown이 무엇을 의미하는지 결정합니다.
- 공개 문서나 마케팅 페이지에서는 허용합니다.
- 검색 또는 목록 조회 endpoint에서는 일반 rate limit과 함께 허용합니다.
- 계정 변경에서는 기존 검사를 유지합니다.
- 영향이 큰 작업에서는 review로 보내거나 더 강한 신호를 요청합니다.
Unknown 트래픽 처리 가이드와 unknown classification 항목에서 패턴을 살펴볼 수 있습니다. 또한 시간에 따른 Unknown 비율을 추적하면, 얼마나 많은 트래픽이 여전히 약한 증거에 의존하는지도 알 수 있습니다.
AI를 함께 사용하는 사람은 어떻게 되나요?
user agent 허용 목록은 일반 브라우저 안에서 AI 어시스턴트를 사용하는 사람에 대해 아무 말도 하지 못합니다. 이들의 User-Agent는 일반적인 브라우저 문자열입니다. 그런데 많은 제품은 AI가 작성한 제출물을 표시하거나, AI를 함께 사용하는 사용자가 온보딩을 어떻게 통과하는지 이해하는 등, 이런 상호작용을 인식하고 싶어 합니다.
Proof of Actor는 지원되는 통합을 통해 도움을 받았다고 선언되거나 관찰된 경우 이러한 상호작용을 Human + AI로 보고합니다. 문체만 보고 추측하지는 않습니다. 자세한 내용은 AI-assisted interaction를 참고하세요.
허용 목록에서 증거 기반 정책으로 이동하기
첫날부터 허용 목록을 제거할 필요는 없습니다. 안전한 전환 경로는 다음과 같습니다.
- 관찰 모드로 설치합니다. Proof of Actor는 아무것도 바꾸지 않습니다. 허용 목록은 계속 동작합니다.
- 비교합니다. 각 라우트에서 허용 목록에 있는 요청 중 어떤 것은 검증된 증거를 갖고, 어떤 것은 선언만 있으며, 어떤 것은 Unknown으로 끝나는지 확인합니다.
- 정책을 미리 봅니다. 검증된 에이전트, 선언된 에이전트, Unknown을 다르게 처리하는 정책 초안을 만들고, 실제 트래픽에 미치는 영향을 미리 봅니다.
- 라우트별로 적용합니다. 위조된 이름의 영향이 가장 큰 라우트부터 시작합니다.
- 허용 목록은 단서로 남깁니다. 이름은 여전히 라우팅과 분석에 유용하며, 이제는 그 근거도 함께 보입니다.
actor-aware 정책을 안전하게 배포하기 가이드에서 각 단계를 다루며, verified automated requests에서는 서명된 클라이언트가 어떻게 들어오는지 설명합니다.
허용 목록만으로 충분한 경우
공개 콘텐츠에서 알려진 크롤러에게 더 가벼운 페이지를 제공하는 것처럼 위험이 낮은 라우팅에는 user agent 허용 목록만으로도 충분한 경우가 많습니다. 위조된 이름의 비용이 작기 때문입니다.
하지만 결정에 결과가 따르는 경우, 예를 들어 챌린지를 건너뛰거나, 더 풍부한 데이터를 노출하거나, write를 허용하는 경우에는 검증할 수 있는 증거가 필요합니다. 이것이 Proof of Actor가 필요한 지점이며, 이미 운영 중인 네트워크 검사와 edge control과 함께 작동합니다.
시작하기
Proof of Actor는 private beta 단계에 있습니다. 선정된 founding developer 팀은 합의된 사용 한도 내에서 최대 12개월 동안 무료로 이용할 수 있으며, 자동 청구는 없습니다. early access 신청하기를 통해 현재 어떤 클라이언트를 허용 목록에 두고 있는지, 그리고 어떤 라우트를 더 나은 증거로 보호하고 싶은지 알려 주세요.