웹은 게이트키퍼를 필요로 하지 않음: Cloudflare의 새로운 "서명된 에이전트" 제안

(positiveblue.substack.com)

1P by GN⁺ 7일전 | ★ favorite | 댓글 1개

Cloudflare의 Signed Agents 정책은 안전을 명분으로 하지만, 실제로는 웹 접근을 허가제로 만드는 폐쇄적 시도임
웹은 역사적으로 개방성과 표준 덕분에 성장했으며, Flash·Silverlight 같은 폐쇄 기술은 결국 HTML5 같은 오픈 표준에 밀려 사라짐
앞으로 웹의 주요 사용자는 AI 에이전트가 될 것이며, 이를 위해서는 분산되고 검증 가능한 인증 체계와 작업 단위의 권한 부여가 필요함
올바른 모델은 체인 기반 위임 + 요청 단위 증명을 결합해, 신뢰 가능한 인증과 세분화된 권한 제어를 구현하는 것임
특정 기업이 키를 쥐는 게 아니라, 개방적 프로토콜과 표준을 통해 모두가 참여하고 혁신할 수 있는 웹을 지켜야 함

Cloudflare의 Signed Agents 비판

Cloudflare는 새로운 서명된 에이전트(Signed Agents) 시스템을 제안했지만, 이는 사실상 허가 목록 기반의 접근 통제
특정 기업이 에이전트 등록 여부를 판단하는 것은 인터넷 프로토콜이 아니라 벤더 승인제에 불과
이는 인터넷의 개방적 특성과 충돌하며, “폼을 작성해 허가받는 것”은 표준이 될 수 없음

웹은 개방되어야 한다

90년대 Microsoft의 “embrace and extend” 전략은 실패했으며, 이는 웹이 개방성을 유지했기 때문에 가능
Flash와 Silverlight 같은 폐쇄 런타임은 결국 HTML5라는 개방 표준에 의해 대체됨
역사는 항상 개방형 표준이 혁신을 촉진한다는 사실을 증명

에이전트 시대의 도래

AI 에이전트는 앞으로 웹의 핵심 사용자로, 정보 검색, 자동화, 결제, 계약 협상 등을 수행
인간과 에이전트의 행위 경계가 모호해질 것이며, 이는 위임 기반 인증 체계를 필수적으로 요구

인증(Authentication)과 권한(Authorization)

인증: 누가 행동하는가?
권한: 무엇을 할 수 있는가?
Cloudflare는 두 개념을 혼동해 “패스포트”로 모든 문제를 해결하려 하지만, 이는 근본적으로 불가능
올바른 인증은 위임 체인과 요청 단위 서명을 통해 구현되어야 하며, DNS 기반 공개키 발행 같은 분산적 검증 메커니즘을 활용해야 함

권한 관리

기존 소프트웨어는 제한된 스코프 덕분에 OAuth 스코프 모델이 잘 작동했음
그러나 에이전트는 범용적이므로 작업 단위(Task-Scoped) 권한 부여가 필요
예: “저녁 결제” 권한과 “3개월 지출 내역 조회” 권한은 같은 에이전트라도 서로 다른 토큰을 가져야 함
이를 위해 Macaroons, Biscuits 같은 제약 기반 토큰, OPA/AWS Cedar 같은 정책 엔진 활용 가능

프로토콜 우선, 게이트키퍼 배제

인증, 권한 부여, 수익화는 특정 기업이 아닌 개방적이고 상호운용 가능한 표준 위에서 이루어져야 함
소수 기업이 에이전트 유효성을 판정한다면 웹은 곧 폐쇄된 정원(Walled Garden) 으로 전락
따라서 체인 기반 위임, 요청 단위 증명, 작업 스코프 권한 부여를 오픈소스로 제안해 누구나 구현할 수 있도록 공유

결론

웹의 미래는 “누가 게이트를 통제하는가”가 아니라, 모두가 함께 구축하고 혁신할 수 있는 프로토콜에 달려 있음

▲

GN⁺ 7일전 [-]

Hacker News 의견

모두가 완전히 자유롭고 오픈된 웹을 꿈꾸지만, 실제로는 작은 블로그나 콘텐츠를 가진 사람이 AI 트레이닝 봇으로부터 보호받을 방법이 거의 없음에 실망함, Agent와 Training 봇을 구분해서 robots.txt를 진짜로 존중해줄 것이라는 믿음은 현실적이지 않음, 만약 robots.txt를 지킨다 하더라도 ‘licensed data’라는 명목으로 데이터를 간접적으로 사들이는 콘셉트는 계속됨, Reddit, X, Google, Meta 같이 법적 자원이 무한에 가까운 기업이 아닌 한 개인은 권력이 없음, 관련해서 재밌는 동영상도 추천함
- 모든 사람이 원하는 자유롭고 개방된 웹과, AI 트레이닝 봇을 차단하고 싶어 하는 마음이 서로 모순적으로 느껴짐, 모두에게 개방된 웹이라면 AI 트레이닝 봇도 예외 없이 접근할 수 있어야 맞음
- (오픈웹의 꿈에 대해) 인터넷에서 오픈 콘텐츠를 꾸는 꿈은 현실임, 내 블로그는 누구든—사람이든 기계든—자유롭게 접근 가능하도록 하고 있음, 내 서버 역시 집에서 직접 호스팅하기 때문에 굳이 인간과 AI를 구분할 필요성을 못 느끼겠음, 만약 웹사이트에 접속자가 너무 많아지는 상황이 걱정된다면, 사실 인간이든 AI든 과도한 트래픽 자체가 문제임, robots.txt로 봇이 루프에 빠지지 않도록는 최소한의 가이드만 두고 자유롭게 크롤링하게 열어둠, Amazonbot도 내 사이트를 자주 들르는데 언제든 환영임
- 적대적인 소프트웨어에 맞서 싸우는 자유 소프트웨어를 개발해야 한다고 생각함, 대기업들은 적대적인 AI 에이전트를 개발하고, 이에 맞서서 유능한 해커들은 anti-AI-agent를 개발해야 한다고 봄, '우리는 힘이 없다'는 패배주의에 동의하지 않음
- 이곳 해커뉴스에는 수많은 대형 IT기업 엔지니어들이 있음에도 불구하고 자기들 업무에는 프라이버시와 데이터 거버넌스에 대해 다루지 않은 채 언제나 다른 이슈에 대해서만 외치는 현실을 지적함, 자기반성을 위한 거울이 필요하다면 내가 구매 의사 있음
- 소규모 블로그나 콘텐츠를 AI 트레이닝 봇에서 보호해야 한다는 질문 자체가 왜 나오는지 모르겠음, 만약 기본적인 HTML 생성조차 어려워 무겁고 복잡한 프레임워크를 써야 하고, 그 결과 CPU 리소스가 너무 많이 든다면 그것이 진짜 문제라고 봄, 아니면 자신의 온라인 글이 콘텐츠 크리에이터라는 부와 명성의 길로 가는 것으로 생각하고 있다면야 걱정할 만하겠지만, 그게 아니라면 문제 자체가 없다고 생각함
현실적으로 “웹”은 이미 한참 전부터 오픈이 아니라고 생각함, 대다수의 상호작용, 게시, 정보 유통은 인증(로그인) 뒤에서 이루어짐, 주요 SNS, 신문사 등 대부분이 인증되지 않은 접근을 제한하거나 차단함, 블로그는 일반인이 소비하는 정보 전체에서 극히 적은 비중에 불과함
- “웹이 더 이상 오픈이 아니다”라는 주장엔 동의하지 않음, 웹이 굳이 게이트키퍼를 늘릴 필요 없고 이미 많다면 오히려 줄여야 한다고 생각함
나도 AI Agent 자체에는 신경 쓰지 않음, 뒤에 실제 사용자가 존재한다면 괜찮음, 하지만 Meta, Perplexity, OpenAI 등이 내 사이트를 심하게 크롤링하는 건 큰 불만임, 실제 유저나 구글 검색보다도 많은 리소스를 AI 크롤링이 차지함, CPU 코어가 AI 크롤링에 묶여버리는 현상은 정말 짜증남
- 나도 개인용 앱이 온라인에 여러 개 있는데, 지난달에 한 AI 봇이 1.6TB 데이터를 긁어가서 Cloudflare AI bot protection 기능을 켜야만 했음, 하루 130만 회가 넘게 끊임없이 요청이 들어와서 감당할 수 없었음
- 내 마케팅 사이트 중 일부에서는 초당 200~300회 수준으로 요청이 들어옴, 심지어 존재하지 않는 URL까지 무작위로 만들어서 호출하는 등 통제가 불가능할 수준임
- AI 기업이 웹 크롤링 때문에 발생시키는 CPU 사이클(컴퓨팅 리소스 소모)이 얼마나 될지 궁금해짐, 보통 AI의 환경적 영향이라 하면 트레이닝이나 서비스 인퍼런스만 따지는데, 사실상 웹 크롤링이 추가로 부하를 준다는 부분도 감안해야 함, 정확한 비교를 하려면 만약 인간 사용자가 직접 해당 동작을 할 때와 비교해서 봇이 더 효율적으로 트래픽을 발생시키도록 설계하면 의미가 있음, 즉 트래커, 이미지 등 부가 요소는 최소한만 호출해서 목표 질의에 필요한 것만 긁는다면 인류 전체가 브라우저로 직접 방문하는 것보다 CPU 부하가 오히려 적어질 수 있음
- 나도 마찬가지임, AI agent를 사용하는 데 뒷배에 유저가 실제로 있고, 비정상적으로 과도하게 접근하지 않으면 별로 신경 안 씀, (내가 AI agent 사용을 의도한 것은 아니지만 누가 어떻게 쓰든 상관없음), 다만 과도한 크롤링은 싫음, 한편 더 중요한 것은 누군가 단순히 curl로 파일 하나 다운로드하거나 Lynx 등의 텍스트 기반 브라우저를 쓸 수도 있다는 점임, 이런 시나리오도 계속 지원되어야 한다고 생각함
- Cloudflare는 어떤 '유저가 시도한 agent'는 허가하고 다른 agent는 막는 방식으로 실제 사용자가 아니라 트레이닝 데이터 수집을 위한 무차별 크롤링과 구분하고 있음, Meta, Perplexity, OpenAI이 보내는 대부분 요청들은 실제 유저 프롬프트에 따라 동작하는 웹검색 기능이고, 이 요청이 다음 LLM 모델의 트레이닝에 사용되는 것은 아님, Cloudflare는 양쪽의 차이를 애매하게 만들어 놓고, 공식적으로는 '크리에이터 보호'를 내세우는데 사실상 LLM 프로바이더로부터 ‘통행세’를 받아 자신들의 이익을 남기는 시스템 구축임, 결국 공정함 때문이 아니라 금전적 동기라고 생각함
나는 개인정보를 많이 노출하지 않는 희귀 브라우저를 사용하는데, Cloudflare 입장에서는 나도 봇이나 다름 없게 보임, 호스트(웹사이트 소유자)가 액세스 권한을 결정하는 환경에서는 프라이버시가 존재할 수 없다고 생각함, 서버 부하 방지를 위한 rate limiting은 동의하지만 자동화 접근 자체를 막기는 실질적으로 불가능하며, 결국 이렇게 막다 보면 실제 사용자의 액세스까지 어려워짐
- 혹시 현재 Cloudflare나 turnstile 때문에 자주 차단되는 경험이 있는지 궁금함, 위에서 이미 암시했지만 명확히 확인하고 싶음
- 만약 독재적 국가에 사는 사람들 입장에서 프라이버시와 자유를 위해 VPN을 써야 한다면, 인터넷은 2-3개 기업이 운영하는 captcha지옥이 됨, 나 스스로 만든 bot으로 Cloudflare 보호 웹사이트에 접근할 때보다, 오히려 VPN과 프라이버시 브라우저로 일반 인터넷 서핑할 때가 더 많은 문제가 생김, 참고로 마이크로소프트가 만약 웹 게이트키핑을 담당했다면 더 끔찍했을 것임, 특히 VPN 쓰고 마이크로소프트의 captcha를 통과하려면 논문 한 편 쓸 각오로 5분 이상 집중해야 겨우 넘길 수 있음
- 웹사이트 주인도 당연히 권리가 있음, 운영에 필요한 재정적 지속 가능성을 위해 gatekeeping을 선택하지 말라는 건 무리한 주장임
- 나도 희귀 브라우저를 쓰면서 bot blocker에 걸릴 때가 많음, 다만 호스트가 내 요청을 자유롭게 다룰 수 있는 권리 역시 있다고 생각함, 특히 정부 사이트의 경우 모든 사람에게 공정하게 서비스할 책임이 훨씬 더 크다고 생각함
혹시 더 오픈된 방식에 좋은 대안이 있다면 듣고 싶음, 하지만 현재 Cloudflare가 하는 방식은 AI bot의 현실적인 문제를 잘 해결하고 있음, 그동안 IP 차단이나 user agent로도 막으려고 해봤지만 한계가 있었음, 그리고 실제로 다른 보안 문제들도 이렇게 다소 중앙화된 방식으로 해결되어 왔음, 인증서 발급기관(certificate authority)도 오픈된 시스템이 아니고, attestations 제공자들도 오픈 시스템이 아니지만 잘 동작함
- 좀 더 오픈된 솔루션을 원한다면 규제가 답일 수 있음, 웹사이트 운영자가 robots.txt에서 명시적으로 허용하지 않은 크롤러의 요청을 법적으로 금지시키고, 현행기관이 직접 단속하도록 만들면 됨, 만약 운영자가 bot 트래픽 입증하면 정부에 신고해서 거액의 벌금을 매길 수 있음, 클라우드 서비스 사업자는 누가 어떤 IP 썼는지 기록을 남기도록 강제 가능함, 100% 해결책은 아니지만 잘 시행되면 충분히 강력한 억제 효과를 줄 수 있음
- 이 방식이 최고의 해결책은 아닐 수 있지만 현실적으로 어느 정도 기능하는 솔루션임, 중앙화 문제 지적은 많지만 Cloudflare가 주요 AI 업체와 CDN을 모두 참여시키는 데 성공한다면 사실상 표준으로 굳어질 수 있다고 생각함
- 인증서는 사람을 봇으로 오인했다고 해서 차단하지는 않음
- 오히려 AI poisoning(데이터에 일부러 잘못된 정보를 섞어 AI를 방해하는 방식)이 더 효과적인 보호라고 생각함, Cloudflare 자체가 AI bot에게 잘못된 데이터를 일부러 주는 서비스도 가능함
- 사실 CA는 Let's Encrypt가 나오기 전까지는 일반 기업 웹사이트, 그것도 로그인 페이지 일부에만 쓰였던 적이 많았음, 만약 Let's Encrypt의 오픈 정책이 아니었으면 우리 개인정보는 여전히 ISP나 중간자에게 그대로 노출됐을 것임, Attestation 제공자들도 기기 취약점이 널리 알려져도 비즈니스 의사결정 때문에 인증 취소를 거부하는 등 무력함, 결론적으로 대다수 논의에서 진짜 대안을 잘 못 찾은 것 같음, Cloudflare가 인터넷 게이트키퍼 되는 건 나쁜 해법이지만, 문제 자체가 훨씬 더 심각한 상황임, 완전히 분산된 솔루션도 이미 존재하긴 함(예. remote attestation, 유료 방문/구독 모델, 셀프호스팅 파이어월 등), AI의 부작용을 무시하고 비용만 지불하라고 하는 태도가 Cloudflare를 더욱 키워온 원인임, 만약 ISP 등이 스푸핑, DDoS, 봇넷 같은 문제를 무시하지 않았다면 Cloudflare는 단지 Akamai 같은 경쟁자 정도로만 머물렀을 것임
이미 게이트키퍼가 너무 많은 세상임, 그 어떤 추가적인 gatekeeper 시도도 공격적인 행동으로 봐야 함, Cloudflare, Google 모두 자신들의 gatekeeper 포지션을 더욱 강하게 밀어붙이고 있음, 만약 이 경향이 지속된다면 둘 다 완전히 무너지는 걸 보고 싶음
- 여러 회사들이 AI bot 문제 해결책을 내놓으려 하는데, Cloudflare가 선택된다면 엄청난 수익을 얻게 됨, 하지만 Cloudflare가 물러난다고 해서 문제가 사라지는 건 아니고 다른 회사의 안 좋은 대안이 채택될 뿐임, gatekeeping은 사실상 웹사이트 주인이 본인의 선택으로 택하는 옵션임(예: paywall, 직접 만든 bot 감지, ID 인증 등), Cloudflare가 이미 이런 서비스를 제공 중이고, 만약 표준화까지 된다면 선택지는 늘어나고 시장도 더 열림(부작용 포함), 진정한 오픈웹의 자유는 방문자 뿐만 아니라 사이트 주인에게도 똑같이 적용되는 것임
- Google이 미래의 gatekeeper가 되겠다는 '욕망'은 지나침, 이미 구글은 Chrome 브라우저 점유율로 수년째 gatekeeper 역할을 해오고 있음, Firefox 역시 존재감이 미미해짐, 구글이 www 전체를 원하는 방향으로 이끌고 있다는 관점임(uBlock 금지, .webp 포맷 강요 등)
단일 회사가 운영하는 allowlist를 문제로 지적하기 전에, 사실 사이트 운영자가 직접 그 서비스를 선택했다는 사실이 있음, 재미있는 것은 ‘공정함’에 대한 이념적 관점을 논하며 블로그에는 AI 툴로 만든 만화를 올리는 등 실생활에선 이미 AI가 깊게 들어와 있다는 모순적 현실임
- Cloudflare는 emerging Web Bot Auth 표준을 구현 중이며, 우리 Stytch도 IsAgent.dev에서 같은 표준을 적용하고 있음, 현재의 논의가 꽤 과열된 측면이 있어 조심스럽지만, 결국 allowlist는 Cloudflare의 고객에게 제공하는 옵션일 뿐이고, HTTP Message Signature 같이 코어는 오픈/분산식으로 설계돼 누구나 쓸 수 있음
- 한 회사의 allowlist를 자신의 선택으로 사용하는 건 별문제 없지만, 그것만으로 프로토콜이 되진 않음, 그리고 공정함에 대한 논쟁과 AI 만화 사용은 논리적으로 관계가 없어 보임
- frying pan/fire(최선이 아닌 차악) 상황에서 특정 회사의 솔루션이 공공연한 표준처럼 남을 우려가 있음, 이번 기회에 진짜 프로토콜/표준 기반 솔루션이 만들어질 수도 있었는데 Cloudflare는 자신의 블루 오션을 만들려는 시도임, 그리고 ‘공정함’을 주장하면서 실제로는 AI 활용을 생활 곳곳에서 하고 있는 점이 재치 있게 꼬집힘
이메일 구조와 유사하다고 봄, 이메일은 인터넷 표준에 기반하지만 대부분 Gmail 등 극소수 서비스 제공자가 대부분 사용자를 갖고 있음, Cloudflare도 오픈 표준 자체를 밀고 있지만 실제 파워는 대규모 고객 숫자에서 나옴, (좋은 대체재가 뭐가 있냐는 질문도 던짐), 또 이메일도 스팸 필터링과정에서 배달 신뢰성이 낮고 구현이 어려운 문제처럼, 웹도 비슷한 길을 걷게 될 여지가 있음
- 실질적으로 무료 CDN으로 Cloudflare를 대체할만한 대안이 없음, 전 세계에 서버를 설치하고 무료로 퍼주고, 프리미엄 서버리스 서비스로 수익을 냄, 그리고 대형 클라우드 서비스 업체들은 트래픽 이그레스(egress) 요금이 비정상적으로 비쌈
웹은 attestation, signed agent, Cloudflare가 누가 ‘진짜’ 에이전트인지 결정하는 것을 원하지 않음, 모두가 “public”의 의미를 다시 인지하고 트래픽 처리가 힘들면 그저 기본적인 rate limiting만 하면 최적임, 웹은 인간인지, 봇인지, 개인지 따질 필요가 없이, 적정 리소스 내에서 요청자 모두에게 바이트를 제공하면 되는 것임, 이런 '오픈웹'의 본질이 사라지면 모두 아쉬워할 것임
- 기본적 rate limiting도 공격에 취약함, 봇넷을 무시할 수도 없고, IPv6로 넘어가면 유용한 rate limiting은 사실상 불가능해짐, 대역폭(buckets)을 잘못 잡으면 일부 네트워크 사업자는 /48 대역을 너무 쉽게 줘버려서 limit이 무력화되거나, 모바일 사용자는 수십만 명이 하나의 rate limit에 묶임
- 이런 방식은 결국 수많은 소규모 웹사이트가 트래픽을 감당 못해서 닫으라는 소리와 다름없음, '오픈 인터넷'이라는 슬로건과 모순됨
- 최신 AI 크롤러는 이제는 악성 봇넷과 구별이 불가능해짐, 정상적인 rate limiting은 더 이상 의미 없으며, 이 지점이 Cloudflare가 문제를 해결하려고 나선 이유임
- “public은 곧 PUBLIC”이라는 주장은 기본적인 rate limiting만으로 운영이 가능하면 좋겠지만, 실제로는 허용 가능한 접근 속도를 명시하고 공개해야 함, 하지만 ‘user-agent’가 다르다고 그냥 한 번만 요청해도 차단을 당하는 사례가 많음, 결국 운영자는 bot 행동이 아니라 신원(identity)만 보고 어떤 요청도 차단하는 경향이 있음, 판단 기준이 거칠어서 잘못된 긍정(오탐)을 양산하고, 그런 경우에도 어떤 시도나 맥락은 전혀 검토하지 않고 단순히 신원만 보고 차단 결정을 내림
- 기본적인 rate limiting 자체도 구현이 쉽지 않을 때가 많음, 특정한 인증/권한 위임이 필요한 경우가 아니라면 퍼블릭 파일 접근에는 인증, 권한 위임 등이 별도로 필요치 않다고 생각함, 이런 위임 이슈가 있더라도 실제 위임자의 역할 외엔 Cloudflare 등 제3자가 개입할 필요 없음
글쓴이의 의견에 대부분 동의함, 엔터프라이즈 환경에서 복잡한 사설 네트워크에서 agent의 행위를 어떻게 통제할지가 고민임, 최근 biscuit 기반 “identity token” 시스템을 직접 만들어봄, 이 token을 통해 자신이 인증을 받고, 그 다음에는 위임 token을 만들어 하위 agent에게도 건넬 수 있음, 내 시스템에선 authorization token이 없으면 뭘 할 수 없음(싱글 스코프, 싱글 유즈 개념), 인터넷에서라면 identity token + 소액 결제(예: 아주 작은 crypto 거래)를 교환하면 authorization token을 줄 수도 있을 것으로 상상해봄, 그러면 인간 유저는 거의 비용이 없어 문제없고, AI 크롤러만 많이 지불하게 됨

답변달기