Daily News Korea

[태그:] robots.txt

  • robots.txt AI 학습 거부, 4개사 공통 토큰

    robots.txt AI 학습 거부, 4개사 공통 토큰

    3줄 요약

    • 오픈AI·구글·마이크로소프트·앤트로픽이 robots.txt에 넣는 공통 ‘정책 토큰’을 따르겠다고 밝히면서, AI 학습 거부를 회사마다 따로 적던 방식이 한 줄 선언으로 바뀌는 길이 열렸어요.
    • 앤트로픽은 이미 적용했고 구글·마이크로소프트는 발표 이듬해, 오픈AI는 수개월 안에 지원할 계획이라 전환기에는 회사별 차단 줄을 함께 남겨 둬야 해요.
    • AI 학습 거부와 검색 노출은 별개의 스위치라서, 검색용 크롤러까지 막지 않도록 robots.txt를 그룹별로 나눠 쓰는 게 핵심이에요.

    오픈AI, 구글, 마이크로소프트, 앤트로픽. AI 회사 네 곳이 robots.txt에 넣는 신호 하나를 함께 따르겠다고 밝혔다. 더버지 보도에 따르면 이들이 채택하기로 한 것은 이른바 ‘정책 토큰(policy token)’이다. robots.txt에 이 토큰을 넣어 두면 여러 AI 회사에 “내 콘텐츠를 학습에 쓰지 말라”는 뜻이 한 번에 전달된다. 블로그나 사이트를 직접 운영하며 AI 학습을 막아 본 사람에게는 반가운 변화다. 지금까지는 robots.txt에 AI 회사 크롤러 이름을 줄줄이 적어 넣고, 새 크롤러가 나올 때마다 목록을 다시 고쳐야 했다. 기존 설정을 당장 지울 단계는 아니다. 회사마다 적용 시점이 달라서다. 운영자가 지금 할 일은 지우기보다 더하기에 가깝다.

    robots.txt는 자물쇠가 아니라 크롤러에게 건네는 안내문

    robots.txt는 사이트 주소 맨 뒤에 /robots.txt를 붙이면 열리는 평범한 텍스트 파일이다. 검색엔진이나 AI 회사가 보내는 크롤러(웹 페이지를 자동으로 돌아다니며 수집하는 프로그램)는 사이트를 수집하기 전에 이 파일부터 읽고, 어떤 경로를 가져가도 되는지 확인한다. 출발점은 검색 색인과 웹 아카이빙을 위한 안내였다. 지금은 AI 학습용 수집을 허용할지 말지 알리는 창구 역할까지 떠안았다.

    문법은 단순하다. User-agent 줄에 대상 크롤러 이름을 쓰고, 그 아래 Disallow 줄에는 수집을 막을 경로를, Allow 줄에는 허용할 경로를 적는다. 크롤러는 자기 이름과 일치하는 그룹이 있으면 그 규칙을 따르고, 없으면 모든 크롤러를 뜻하는 별표(*) 그룹의 규칙을 따른다.

    놓치면 안 되는 성질이 하나 있다. robots.txt는 강제력 있는 차단 장치가 아니다. “이렇게 해 달라”는 요청일 뿐이고, 지키기로 한 크롤러만 지킨다. AI 회사들이 “이 신호를 보면 수집을 멈추겠다”고 약속했다는 사실 자체가 무게를 갖는 이유가 여기 있다. 효력이 미치는 방향도 한쪽뿐이다. robots.txt는 앞으로의 방문을 안내하는 파일이어서, 이미 수집된 데이터를 되돌리지는 못한다.

    AI 학습을 막는 기존 방식은 철저히 회사 단위였다. 각 회사가 공개한 크롤러 이름을 하나하나 User-agent로 지정해야 했고, AI 회사가 늘수록 운영자가 챙길 목록도 길어졌다. 하나만 빠뜨려도 그 회사 크롤러에는 거부 의사가 닿지 않는 구조. 공통 토큰이 손대려는 곳이 바로 이 대목이다.

    정책 토큰은 크롤러 목록 대신 ‘학습 허용 여부’를 적는다

    정책 토큰은 앤트로픽의 표준 담당 기술 리드인 케빈 켈리가 인터넷 표준을 다루는 IETF(국제인터넷표준화기구)에 제안한 방식이다. 발상은 간단하다. “어느 크롤러를 막을지”를 나열하는 대신 “내 콘텐츠를 AI 학습에 써도 되는지”를 robots.txt 안에 공통 신호로 적는다. 신호를 읽은 AI 회사가 각자 크롤러 접근을 제한하니, 운영자가 회사별로 줄을 계속 덧붙일 필요가 없어진다.

    오픈AI, 구글, 마이크로소프트, 앤트로픽은 이 토큰을 발견하면 자사 AI 크롤러의 사이트 접근을 제한하겠다고 밝혔다. 메타도 목소리를 보탰다. 커뮤니케이션 책임자 앤디 스톤은 여러 제공자에게 이런 선호를 한꺼번에 전하는 공통 신호를 만드는 일이 중요한 한 걸음이라며 지지 의사를 냈다. 정작 메타가 이 신호를 실제로 따를지에 대해서는 말이 없었다. 지지와 준수는 별개의 문제다. 회사별 입장과 일정을 표로 묶으면 다음과 같다.

    회사 공통 토큰 적용 시점 함께 밝힌 내용
    앤트로픽 이미 적용 토큰을 제안한 케빈 켈리가 소속된 회사
    구글 발표 이듬해 지원 계획 이전부터 AI 검색 기능 노출·AI 학습 사용을 검색 노출과 분리해 제어하는 기능 운영
    마이크로소프트 발표 이듬해 지원 계획 AI 학습과 AI 그라운딩을 따로 거부하는 세분화 제어 제공, 빙 검색 노출은 유지
    오픈AI 수개월 안에 적용 토큰 발견 시 자사 크롤러 접근 제한
    메타 준수 여부 언급 안 함 업계 공통 신호 마련에 지지 의사 표명

    지원 시점은 제각각이다. 앤트로픽은 이미 적용했고, 오픈AI는 수개월 안, 구글과 마이크로소프트는 발표 이듬해를 내걸었다. 공통 토큰만 넣어 두면 아직 지원을 시작하지 않은 회사의 크롤러에는 신호가 통하지 않을 수 있다. 네 회사가 모두 적용을 마치기 전까지는 기존 회사별 차단 줄과 공통 토큰을 함께 두는 편이 안전하다. 가장 늦은 일정이 ‘발표 이듬해’인 만큼, 회사별 줄을 관리하는 수고는 적어도 그때까지 이어진다고 보는 게 현실적이다.

    AI 학습·그라운딩·검색 노출은 서로 다른 스위치

    robots.txt로 AI를 막을 때 가장 흔한 착각은 “AI를 막는다”와 “검색에서 사라진다”를 같은 일로 여기는 것이다. 실제로는 성격이 다른 세 가지 쓰임이 한데 얽혀 있다.

    • 검색 노출: 검색엔진 결과에 내 페이지가 뜨는 것. 검색 유입에 기대는 블로그라면 무엇보다 먼저 지켜야 할 부분이다.
    • AI 학습: 내 글이 AI 모델을 훈련시키는 데이터로 들어가는 것.
    • AI 그라운딩: AI가 답변을 만들 때 환각(그럴듯한 오답)을 줄이려고 검증된 출처를 참고하게 하는 과정. 마이크로소프트가 쓰는 표현이다.

    마이크로소프트는 AI 학습과 AI 그라운딩을 각각 거부할 수 있는 세분화된 제어를 제공하겠다고 했다. 어느 쪽을 고르든 빙 검색 결과 노출은 그대로 유지된다는 설명이다. 구글은 한발 먼저 움직였다. AI 검색 기능에 노출될지, AI 학습에 쓰일지를 검색 노출과 분리해 정하는 제어를 이미 운영해 왔다. 두 회사 기준으로는 AI 쪽 문을 닫아도 검색 유입은 지킬 수 있다는 얘기다.

    어떤 스위치를 끌지는 사이트 성격에 따라 갈린다.

    • 검색 유입이 수익의 중심인 블로그: 검색용 크롤러는 건드리지 않고 AI 학습 거부만 설정하는 정도면 무난하다.
    • AI 답변에 출처로 언급되길 원하는 사이트: 학습은 막고 그라운딩은 열어 두는 조합을 고려할 만하다. 그라운딩은 AI가 검증된 출처를 참고하는 과정이라, 이걸 거부하면 AI 답변에 출처로 등장할 기회도 함께 줄어들 공산이 크다.
    • 콘텐츠 자체가 상품인 사이트(유료 원고, 사진, 강의 자료): 학습과 그라운딩을 모두 막고, 필요하면 마지막 소제목에서 다룰 과금형 라이선스까지 검토하는 쪽이 맞다.

    용도별로 잘게 나눠 막고 싶다면 공통 토큰과 별도로 각 회사가 내놓은 세분화 제어 안내를 따로 챙겨 둬야 한다. 마이크로소프트가 학습과 그라운딩을 굳이 나눠 놓은 것만 봐도, ‘AI 거부’는 한 덩어리로 처리할 문제가 아니다.

    내 사이트 robots.txt, 다섯 단계로 손보기

    순서는 ‘현재 파일 확인 → 편집 위치 찾기 → 회사별 차단 → 공통 토큰 추가 → 검증’이다. 아래 메뉴 경로는 서비스 업데이트에 따라 표기가 바뀔 수 있으니, 같은 뜻의 항목을 찾아 들어가면 된다.

    1단계. 현재 파일 열어보기
    브라우저 주소창에 ‘내도메인/robots.txt’를 입력한다. 텍스트가 뜨면 이미 파일이 있다는 뜻이다. 페이지를 찾을 수 없다는 오류가 나오면 파일이 없는 것이고, 이때는 모든 크롤러가 허용된 상태다.

    2단계. 편집 위치 찾기

    • 자체 서버·웹호스팅: 호스팅 관리 페이지 → 파일 관리자(또는 FTP 접속) → 웹 루트 폴더(public_html, www 같은 이름)에서 robots.txt를 만들거나 고친다. 하위 폴더에 두면 크롤러가 읽지 않는다. 반드시 최상위에 둬야 한다.
    • 워드프레스: 실제 파일이 없으면 워드프레스가 가상 robots.txt를 자동으로 보여준다. 고칠 때는 SEO 플러그인의 편집 메뉴를 쓰는 게 간단하다. 플러그인 메뉴 → 도구 → 파일 편집기(플러그인에 따라 ‘일반 설정 → robots.txt 편집’) 순서. 루트에 실제 파일을 올리면 그 파일이 우선 적용된다.
    • 구글 블로거: 설정 → 크롤러 및 색인 생성 → ‘맞춤 robots.txt 사용 설정’ 켜기 → ‘맞춤 robots.txt’에 내용 입력(한국어 메뉴 표기는 확실하지 않음, 영문 화면은 Crawlers and indexing → Enable custom robots.txt).
    • 가입형 블로그 플랫폼: 플랫폼이 robots.txt를 직접 관리해 편집 메뉴 자체가 없는 경우가 많다. 이 경우는 바로 다음 소제목에서 따로 다룬다.

    3단계. AI 크롤러 그룹을 검색엔진 그룹과 분리해 추가
    AI 회사들은 자사 크롤러 이름을 개발자 문서나 고객 지원 페이지에 공개해 두고 있다. 그 이름을 철자 그대로 복사해 아래처럼 별도 그룹으로 넣는다.

    # 검색엔진 크롤러는 기존처럼 허용
User-agent: *
Allow: /

# AI 학습용 크롤러는 회사별로 따로 차단
User-agent: [A사가 공개한 AI 학습용 크롤러 이름]
Disallow: /

User-agent: [B사가 공개한 AI 학습용 크롤러 이름]
Disallow: /

    별표 그룹에 ‘Disallow: /’를 쓰는 것만은 절대 피해야 한다. AI 크롤러뿐 아니라 검색엔진 크롤러까지 몽땅 막혀 검색 유입이 끊긴다. 구글이나 마이크로소프트처럼 검색과 AI를 함께 하는 회사도 마찬가지다. 검색용 크롤러 자체를 막으면 그건 학습 거부가 아니라 검색 노출 포기다. 각 회사가 AI 학습 제어용으로 안내한 항목만 골라 써야 하는 이유다.

    4단계. 공통 정책 토큰 줄 추가
    각 회사가 지원을 시작하면 robots.txt에 공통 토큰 줄을 넣는다. 걸리는 건 표기법이다. 토큰의 정확한 표기 문법은 이 단계에서 확실하지 않으므로, IETF 제안 문서와 각 회사 크롤러 안내 페이지에 적힌 형태를 그대로 복사하는 게 안전하다. 철자가 어긋나면 크롤러가 신호로 읽지 못할 수 있다. 3단계에서 넣은 회사별 줄은 네 회사가 모두 적용을 마칠 때까지 지우지 않는다.

    5단계. 저장 후 검증
    저장한 뒤 ‘내도메인/robots.txt’를 새로고침해 바뀐 내용이 보이는지 확인한다. 구글 쪽 반영 상태는 구글 서치 콘솔 → 설정 → 크롤링 → robots.txt ‘보고서 열기’에서 가져오기 상태와 오류를 볼 수 있다(이 경로는 확실하지 않음). 반영에는 시차가 있다. 크롤러는 robots.txt를 주기적으로 다시 읽기 때문에, 고치자마자 모든 크롤러에 적용되지는 않는다.

    국내 운영자, robots.txt 편집 권한이 있느냐가 갈림길

    robots.txt를 직접 고칠 수 있는 운영자에게는 변화가 비교적 선명하다. 워드프레스나 자체 서버, 구글 블로거로 사이트를 꾸렸다면, 네 회사가 모두 공통 토큰을 지원하는 시점부터 회사별 크롤러 목록을 계속 업데이트하는 부담이 줄어들 전망이다. 광고 수익을 검색 유입에 기대는 블로그도 한시름 놓을 만하다. 구글·마이크로소프트가 검색 노출과 AI 학습을 분리해 둔 덕분에, 학습을 거부했다고 구글·빙 검색 노출이 떨어질 걱정은 덜 수 있다.

    포털 블로그처럼 플랫폼이 도메인과 robots.txt를 함께 관리하는 가입형 서비스는 사정이 다르다. 개인이 robots.txt를 직접 고치기 어려운 구조여서, 공통 토큰을 넣을지, 넣는다면 블로그별로 선택하게 할지는 플랫폼 운영사의 결정에 달린 문제로 보인다(추측). 이런 플랫폼 사용자라면 운영사 공지나 고객센터 안내에서 AI 학습 관련 정책을 찾아보는 게 현실적인 방법이다. 개인이 손쓸 수 있는 범위가 사실상 거기까지라는 뜻이기도 하다.

    참여 명단도 따져 볼 대목이다. 공통 토큰을 따르겠다고 밝힌 곳은 오픈AI, 구글, 마이크로소프트, 앤트로픽 네 곳. 메타는 지지 의사만 냈고, 국내 포털이나 국내 AI 회사의 이름은 명단에 없다. 공통 토큰이 자리를 잡더라도 국내 서비스의 크롤러는 지금처럼 회사별로 따로 지정해야 할 가능성이 커 보인다(추측). 같은 이유로, 이번 발표만 놓고 국내 검색 노출에 미칠 영향을 가늠하기는 어렵다.

    쇼핑몰 운영자도 처지가 비슷하다. 임대형 쇼핑몰 솔루션을 쓴다면 관리자 화면에 robots.txt 편집 메뉴가 있는지부터 확인해야 하고, 없다면 솔루션 업체의 지원을 기다리는 수밖에 없다. 상품 상세 설명이나 구매 후기처럼 공들인 텍스트가 많은 몰일수록 이 확인을 먼저 해 두는 게 순서다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 오픈AI·구글·마이크로소프트·앤트로픽이 공통 정책 토큰을 채택하고, 토큰을 발견하면 자사 AI 크롤러의 접근을 제한하겠다고 밝힘
    • 토큰은 웹사이트의 robots.txt 파일 안에 들어가는 방식
    • 앤트로픽 표준 담당 기술 리드 케빈 켈리가 IETF에 제안
    • 앤트로픽은 이미 적용, 구글·마이크로소프트는 발표 이듬해 지원 예정, 오픈AI는 수개월 안에 적용 예정
    • 마이크로소프트는 AI 학습과 AI 그라운딩을 따로 거부하는 제어를 제공하고, 선택과 무관하게 빙 검색 노출은 유지
    • 구글은 이전부터 AI 검색 기능 노출과 AI 학습 사용을 검색 노출과 분리해 제어하는 기능을 운영
    • 메타는 커뮤니케이션 책임자 앤디 스톤을 통해 지지 의사 표명

    아직 불확실한 것

    • 정책 토큰의 정확한 표기 문법과 robots.txt 안의 작성 위치
    • 메타의 실제 준수 여부와 적용 시점
    • 오픈AI의 구체적인 적용 시기
    • 공통 토큰 하나로 학습·그라운딩 같은 세부 용도까지 구분할 수 있는지 여부
    • 네 회사 밖 AI 크롤러, 특히 국내 서비스의 참여 여부
    • IETF 정식 표준 확정 여부와 그 시점

    약속을 안 지키는 크롤러엔 CDN 차단과 과금형 라이선스

    공통 토큰은 신호를 지키겠다고 약속한 회사에만 통한다. robots.txt 자체가 강제력 없는 요청인 만큼, 규칙을 무시하고 긁어 가는 크롤러에는 다른 수단이 필요하다. 퍼블리셔들이 AI 크롤러의 무단 수집에 계속 시달리면서 대안도 이미 몇 가지 나와 있다.

    • CDN 단계 차단: 클라우드플레어는 AI 크롤러를 기본으로 차단하고 있다. 클라우드플레어를 쓰는 사이트라면 대시보드 → 도메인 선택 → 보안 → 봇 메뉴에서 AI 크롤러 차단 상태를 확인할 수 있다(이 경로는 확실하지 않음, ‘AI Crawl Control’처럼 AI 크롤러 관리가 별도 메뉴로 나뉜 화면도 있음). 요청을 서버 앞단에서 거절하는 방식이라, 크롤러가 robots.txt를 지키든 말든 상관없이 작동한다는 점이 다르다.
    • 과금형 라이선스: RSL(Really Simple Licensing) 표준은 사이트를 방문하는 크롤러에 요금을 매길 수 있게 해 준다. 무조건 막기보다 “쓰려면 대가를 내라”는 선택지를 원하는 운영자에게 맞는 방식이다.
    • 서버 설정 차단: 웹 서버 설정에서 특정 User-agent의 요청을 거절하는 방법도 있다. 다만 크롤러가 이름을 바꾸거나 숨기면 빠져나갈 수 있어 보조 수단에 가깝다.

    방어선은 세 겹으로 쌓을 수 있다. 먼저 robots.txt에 회사별 차단과 공통 토큰을 함께 적어 ‘약속을 지키는 크롤러’를 관리한다. 그래도 불안하면 CDN 차단으로 ‘약속을 안 지키는 크롤러’를 거른다. 콘텐츠로 수익을 내고 싶다면 라이선스로 ‘대가를 내는 크롤러’만 받는다. 공통 토큰이 자리 잡으면 첫 번째 층의 관리 부담은 가벼워질 것으로 보인다. 하지만 토큰을 따르겠다고 밝힌 곳이 아직 네 회사뿐이라, 나머지 두 층이 필요 없어지지는 않는다. 공통 토큰은 울타리를 대신하는 장치가 아니다. 울타리에 붙이던 여러 장의 표지판을 한 장으로 합친 것에 가깝다.

    출처: The Verge

    관련 기사

  • AI 학습 거부 공통 신호, 오픈AI·구글·MS 합류

    AI 학습 거부 공통 신호, 오픈AI·구글·MS 합류

    3줄 요약

    • 오픈AI·구글·마이크로소프트·앤트로픽 4곳이 robots.txt에 넣는 공통 ‘AI 학습 거부’ 신호를 따르기로 했어요.
    • 앤트로픽의 표준 담당자가 IETF에 제안한 방식이에요. 앤트로픽은 이미 적용했고, 오픈AI는 수개월 내, 구글·MS는 내년 지원이 목표예요.
    • 회사마다 따로 설정하던 번거로움은 줄어들 전망이에요. 메타는 지지만 밝혔고 실제로 따를지는 말하지 않았어요.

    robots.txt에 공통 신호 하나만 넣어 두면 오픈AI, 구글, 마이크로소프트(MS), 앤트로픽의 AI 크롤러가 사이트 접근을 제한하게 돼요. 네 회사가 ‘AI 학습 거부’ 공통 표준을 따르겠다고 나란히 이름을 올렸거든요. 지금까지는 사이트를 AI 학습에서 빼려면 회사마다 따로 신호를 보내야 했으니, 운영자 입장에선 일이 꽤 줄어드는 변화예요. 다만 지금 이 신호가 실제로 통하는 곳은 앤트로픽 한 곳. 서치 엔진 라운드테이블이 처음 보도했고, 더버지가 회사별 입장과 일정을 덧붙여 전했어요.

    새 파일 없이 robots.txt에 얹는 ‘정책 토큰’

    이름은 ‘정책 토큰(policy token)’이에요. 앤트로픽에서 표준 분야 기술 리드를 맡고 있는 케빈 켈리(Kevin Kelley)가 국제인터넷표준화기구(IETF) 논의의 일부로 내놓았어요.

    토큰이 들어갈 자리는 robots.txt예요. 검색 색인이든 아카이빙이든 AI 학습이든, 목적을 가리지 않고 어떤 크롤러가 사이트를 긁어가도 되는지 알려주는 데 오래 써 온 파일이죠. 새 시스템을 따로 만드는 게 아니에요. 운영자들이 이미 관리하고 있는 파일에 공통 어휘 하나를 더하는 방식이라, 도입이 어려울 이유는 별로 없어 보여요.

    문제는 지금까지의 방식이었어요. AI 학습에 대한 선호를 회사별로 하나하나 적어야 했는데, AI 크롤러는 계속 늘어나고 있어요. 회사가 하나 늘 때마다 운영자가 챙겨야 할 항목도 하나씩 쌓이는 구조였던 셈이죠.

    • 공통 신호 하나로 여러 AI 회사에 학습 선호를 한 번에 전달
    • 신호가 들어가는 곳은 기존 robots.txt 파일
    • 참여 4개사는 이 토큰을 발견하면 자사 AI 크롤러의 사이트 접근을 제한하겠다고 밝힘

    앤트로픽은 이미 적용, 구글·MS는 내년부터

    ‘토큰이 있으면 멈추겠다’는 데는 네 회사가 뜻을 모았어요. 일정은 제각각이고요. 회사별로 밝힌 내용을 표로 묶으면 이래요.

    회사 지원 시점 함께 밝힌 내용
    앤트로픽 이미 적용 표준을 제안한 케빈 켈리가 속한 회사
    오픈AI “수개월 내” 구체적인 날짜는 밝히지 않음
    구글 내년 검색 노출과 상관없이 AI 검색 기능 노출과 AI 학습 이용을 따로 제어하는 기능을 이미 운영
    마이크로소프트 내년 AI 학습과 AI 그라운딩을 각각 거부할 수 있는 세분화 제어 제공, 설정과 무관하게 빙 검색 결과 노출 유지
    메타 미정 지지를 표명했지만 준수 여부는 언급하지 않음

    MS 설명에 나오는 ‘그라운딩’은 AI 모델이 답을 만들 때 검증된 정보원을 참고하게 해서 환각을 줄이는 과정이에요. 내 사이트 글이 학습 데이터로 쓰이는 것과 답변의 근거 자료로 쓰이는 것을 따로 고를 수 있다는 얘기죠. ‘전부 열거나 전부 막거나’ 둘 중 하나만 고르는 것보다 운영자에게 훨씬 현실적인 선택지예요. 학습에 쓰이는 건 싫지만 AI 답변의 근거로 쓰이는 건 괜찮다는 사이트도 분명 있을 테니까요.

    메타는 입장이 애매해요. 메타 커뮤니케이션 책임자 앤디 스톤은 “여러 제공업체에 이런 선호를 한 번에 전달하는 공통 신호를 만드는 건 중요한 진전”이라고 말했어요. 표준을 만들고 업계 전반에 적용하는 일도 다른 AI 회사들과 함께하고 싶다고 덧붙였고요. 그런데 정작 메타 크롤러가 이 신호를 실제로 따를지는 말하지 않았어요. 지지한다는 것과 지킨다는 건 다른 문제라서, 표에서 메타 칸이 ‘미정’으로 남을 수밖에 없어요.

    국내 사이트 운영자, 기존 설정은 아직 지우지 말 것

    자체 도메인으로 사이트를 운영하는 국내 언론사, 개인 블로거, 기업 웹 담당자라면 실제 작업 방식이 바뀌는 얘기예요. 네 회사가 모두 지원을 시작하면 AI 학습을 막을 때 회사별 항목을 일일이 적지 않고 공통 토큰 하나로 처리할 수 있거든요.

    문제는 타이밍이에요. 지금 이 신호를 반영한 곳은 앤트로픽뿐이에요. 오픈AI는 수개월 뒤, 구글과 MS는 내년이 목표예요. 그 사이에 회사별 설정부터 지워버리면 아직 토큰을 지원하지 않는 크롤러에는 거부 의사가 제대로 전달되지 않을 수 있어요. 한동안은 회사별 설정과 공통 토큰을 나란히 두는 편이 안전해요.

    검색 유입이 줄까 봐 AI 차단을 미뤄 왔다면 그 걱정은 조금 내려놔도 될 듯해요. MS는 설정과 상관없이 빙 검색 결과 노출을 유지한다고 했고, 구글도 검색 노출과 AI 학습 이용을 나눠서 제어하는 기능을 이미 운영하고 있거든요.

    • 앤트로픽 크롤러: 지금부터 공통 토큰 적용 대상
    • 오픈AI·구글·MS: 지원이 시작될 때까지는 기존 회사별 설정을 유지하는 게 무난 (공개된 일정을 기준으로 한 판단)
    • 국내 포털·AI 기업 크롤러: 이번 참여 명단에 없음. 같은 토큰을 따를지는 각 회사가 정할 문제로 보임 (추측)

    확인된 것과 아직 불확실한 것

    확인된 것

    • 오픈AI·구글·MS·앤트로픽 4곳의 공통 정책 토큰 채택 의사
    • 앤트로픽 표준 기술 리드 케빈 켈리가 IETF 논의의 하나로 제안
    • 토큰이 들어가는 위치는 robots.txt
    • 적용 일정: 앤트로픽 이미 적용, 오픈AI 수개월 내, 구글·MS 내년
    • MS의 AI 학습·그라운딩 구분 제어와 빙 검색 노출 유지 방침
    • 메타의 지지 표명(준수 여부는 언급 없음)

    아직 불확실한 것

    • 토큰의 구체적인 문법과 robots.txt 작성 예시
    • IETF 표준으로 최종 확정되는 시점
    • 오픈AI의 정확한 적용일과 구글·MS의 세부 일정
    • 메타 크롤러의 실제 준수 여부
    • 오픈AI·앤트로픽도 학습과 그라운딩을 나눈 세분화 옵션을 제공할지 여부
    • 이미 수집된 데이터에도 신호가 적용되는지와 그 범위
    • 국내 포털·AI 기업 크롤러의 동참 여부

    요금도 차단도 아닌, ‘약속’에 기대는 세 번째 방식

    AI 크롤러의 무단 수집에 맞서는 방법이 이번에 처음 나온 건 아니에요. RSL(Really Simple Licensing) 표준은 사이트를 찾아오는 크롤러에 요금을 물릴 수 있게 했고, 클라우드플레어는 AI 크롤러를 기본으로 차단하고 있어요.

    공통 토큰은 방식이 달라요. 요금을 받지도 않고, 네트워크 단에서 막지도 않아요. AI 회사들이 ‘이 신호가 있으면 멈추겠다’고 약속한 신호, 그게 전부예요. robots.txt 자체가 크롤러가 스스로 지켜야 의미가 생기는 장치라는 걸 생각하면, 이 표준의 무게는 몇 곳이 약속하고 그 약속을 얼마나 지키느냐로 정해질 수밖에 없어요. 그런 면에서 오픈AI·구글·MS·앤트로픽이 한꺼번에 이름을 올린 건 출발로는 나쁘지 않은 구성이에요.

    남은 관전 포인트는 두 가지. 첫째는 메타처럼 지지만 밝힌 회사가 실제로 신호를 따르게 되느냐예요. 둘째는 IETF 논의가 마무리되면서 더 많은 크롤러 운영사가 같은 신호를 받아들이느냐고요.

    출처: The Verge

    관련 기사

  • AI 크롤러 차단 설정법, 봇 트래픽이 사람 추월

    AI 크롤러 차단 설정법, 봇 트래픽이 사람 추월

    3줄 요약

    • 클라우드플레어 집계에서 자동화 트래픽이 사람 트래픽을 앞질렀다. 증가를 이끄는 건 AI 수집기와 AI 에이전트다.
    • 사이트 운영자가 고를 수 있는 길은 AI 봇 전면 차단, 전면 허용, 대가를 내는 봇만 허용하는 것 세 가지다. 수익이 방문에서 나오는지, AI 답변에 이름이 나오는 게 이득인지를 따져 고르면 된다.
    • 클라우드플레어 사용자는 대시보드의 봇 설정에서, 비사용자는 robots.txt와 서버 규칙으로 제어한다. robots.txt에는 강제력이 없다는 점을 전제로 깔고 가야 한다.

    클라우드플레어는 봇 트래픽이 사람 트래픽을 넘어서는 시점을 두 번 내다봤다. 두 번 다 빗나갔다. 처음 잡은 시점을 한 차례 앞당겼는데, 실제 역전은 그 앞당긴 예측보다도 일찍 찾아왔다. 전 세계 350개 이상 도시에 수천 개 데이터센터를 깔아 두고 인터넷의 상당 부분을 지켜보는 회사의 집계다. 같은 집계에서 봇은 이미 인터넷 트래픽의 절반을 넘었다. 트래픽을 이만큼 넓게 들여다보는 회사조차 속도를 두 번이나 잘못 읽었다. 그만큼 증가세가 가팔랐다는 얘기다.

    매슈 프린스 클라우드플레어 CEO가 더버지 팟캐스트 ‘디코더’에 나와 한 이야기에서 숫자는 출발점일 뿐이다. 핵심은 그다음에 나온다. 웹사이트를 읽는 쪽이 사람에서 기계로 넘어가면, 사람 눈에 광고를 띄워 돈을 버는 웹의 기본 구조가 흔들린다. 사이트를 운영하는 입장이라면 설정 화면은 잠시 미뤄 두자. AI 봇을 막을지, 받을지, 돈을 받고 들일지부터 정하는 게 순서다.

    방문자가 기계로 바뀌면 사이트는 광고와 통계를 함께 잃는다

    웹은 적어도 30년 동안 광고로 먹고살았다. 구글은 검색 회사로 머물지 않았다. 더블클릭을 사들이고 구글 애널리틱스를 만들면서 ‘누가 내 사이트에 왔는지 확인하고, 그 방문에 광고를 붙이는’ 생태계를 통째로 설계했다. 이 판 전체가 방문자는 사람이라는 전제에 기대고 있다. 광고는 사람이 봐야 매출이 되고, 방문 통계도 사람이 다녀갔다는 신호일 때만 쓸모가 있다.

    봇은 이 전제 바깥에 있다. 사이트로 들어오는 자동화 트래픽은 성격에 따라 세 갈래로 나눠 보면 정리가 쉽다.

    • 검색 크롤러: 페이지를 색인해 검색 결과에 올린다. 사용자가 결과를 누르면 방문으로 돌아온다. 사이트 입장에서도 손해 보지 않는 거래다.
    • AI 학습·수집용 크롤러: 페이지 내용을 긁어 가 모델 학습이나 답변 생성의 재료로 쓴다. 방문이 되돌아온다는 보장은 없다.
    • AI 에이전트: 사람이 맡긴 일을 대신 처리하러 사이트에 들어온다. 가격 비교, 예약, 정보 요약 같은 작업. 사람 대신 페이지를 읽으니 광고가 노출되지 않는 경우가 많다.

    걸리는 건 뒤의 두 부류가 계속 불어난다는 점이다. 서버 비용과 대역폭은 사이트가 고스란히 떠안는데, 광고 노출과 방문은 줄어든다. 방문 통계에 봇이 섞이면 애널리틱스 숫자만 보고 어떤 콘텐츠가 성과를 냈는지 판단하기도 어려워진다. 프린스 CEO가 클라우드플레어를 설명하는 방식도 달라졌다. 예전엔 ‘인터넷을 빠르게 하고 나쁜 이들로부터 지키는 서비스’였는데, 이제는 ‘처음부터 이렇게 지어졌어야 할 인터넷을 다시 짓는 회사’라고 말한다. 트래픽을 지키는 일이 인터넷의 사업 모델을 다시 짜는 일로 커졌다고 보기 때문이다. 회사 소개 문구를 바꿀 만큼 판이 달라졌다는 인식이기도 하다.

    막을지, 열지, 돈 받고 열지는 수익원이 가른다

    클라우드플레어가 사이트 운영자에게 내놓는 선택지는 크게 세 가지. AI 도구를 전부 막거나, 전부 들이거나, 접근 대가를 치를 의향이 있는 봇만 들이는 것이다. 셋 중 정해진 정답은 없다. 사이트가 무엇으로 돈을 버느냐에 따라 답이 갈린다.

    선택지 맞는 사이트 얻는 것 감수할 것
    전면 차단 광고·구독 수익이 방문에 달린 매체, 유료 자료가 핵심인 사이트 무단 수집 억제, 서버 부담 감소 AI 답변·에이전트 경로로 생길 노출 포기
    전면 허용 브랜드 노출이 목적인 기업 사이트, 제품·기술 문서 AI 답변에 인용·언급될 기회 방문 없이 내용만 소비될 가능성, 트래픽 비용 증가
    대가 지불 봇만 허용 독자 자료나 데이터를 쌓아 둔 사이트 수집을 수익으로 바꿀 여지 과금 구조가 아직 자리 잡는 중이라 실제 수익은 불투명

    표에서 가장 흐릿한 칸은 유료 허용의 ‘감수할 것’이다. 과금 구조가 아직 자리 잡는 중이니, 당장 이 선택지에 수익 기대를 크게 거는 건 이르다. 판단 기준은 세 가지 질문으로 좁혀진다.

    1. 수익이 방문에서 나오는가? 광고 단가나 구독 전환이 방문 수에 묶여 있다면, 방문을 돌려주지 않는 수집기는 비용만 남기고 간다. 차단 쪽으로 무게가 기운다.
    2. AI 답변에 이름이 오르는 게 이득인가? 제품 설명서, 고객지원 문서, 회사 소개처럼 널리 읽히는 것 자체가 목적인 콘텐츠라면 허용이 낫다. 누군가 AI에게 물었을 때 우리 제품 이름이 나오는 편이 유리하니까.
    3. 다른 데서 구할 수 없는 정보인가? 직접 취재한 기사, 자체 조사 데이터, 전문 리뷰처럼 대체재가 없는 콘텐츠라면 유료 허용을 따져 볼 만하다. 프린스 CEO가 디코더에서 ‘앞으로 어떤 정보가 가치를 가질지’를 비중 있게 다룬 것도 이 지점과 맞닿아 있다.

    한 사이트 안에서도 답은 갈린다. 블로그 글은 막고 제품 문서는 열어 두는 식으로 경로마다 정책을 따로 두는 게 현실적인 절충이다. 셋 중 하나를 사이트 전체에 일괄 적용하는 것보다 손은 더 가지만, 잃는 것도 적다.

    클라우드플레어 대시보드에서 AI 봇 막는 다섯 단계

    클라우드플레어를 이미 쓰고 있다면 코드를 짤 일은 없다. 대시보드에서 끝난다. 다만 대시보드 개편이 잦아 메뉴 이름과 위치가 요금제, 계정, 화면 버전마다 다르다. 아래 경로는 흐름을 잡는 참고용이다. 메뉴가 안 보이면 봇(Bots)이나 AI라는 단어가 들어간 항목을 찾으면 된다.

    1. 현황 확인: 대시보드 로그인 → 대상 도메인 선택 → 분석(Analytics) 또는 보안(Security) 영역의 트래픽·이벤트 화면. 여기서 자동화 트래픽의 비중과 자주 들어오는 봇을 본다. 무엇이 들어오는지 알고 막아야 검색 크롤러까지 막아 버리는 사고를 피한다.
    2. 일괄 차단: 보안(Security) → 봇(Bots)으로 가서 ‘AI 봇 차단’이나 ‘AI 스크레이퍼·크롤러 차단’ 같은 이름의 항목을 켠다. 클라우드플레어가 AI 수집기로 분류해 둔 봇을 한꺼번에 막는 방식이다. 분류를 클라우드플레어에 맡기는 셈이라 가장 빠르지만 세밀하진 않다.
    3. 크롤러별 선별: AI 크롤러를 하나씩 허용하거나 차단하는 관리 화면이 있는 계정이라면 거기서 봇마다 정책을 따로 준다. 대가를 내는 봇만 들이는 설정도 이 계열 메뉴에 들어 있다. 제공 여부와 메뉴 이름은 계정마다 다르다.
    4. 경로별 규칙: 보안(Security) → WAF → 사용자 지정 규칙(Custom rules). ‘User-Agent에 특정 문자열 포함’과 ‘URI 경로가 /blog/로 시작’ 같은 조건을 묶고, 동작은 차단(Block)이나 챌린지(Challenge) 중에서 고른다. 블로그만 막고 문서는 여는 정책이 이렇게 만들어진다.
    5. 적용 후 점검: 규칙을 켜고 며칠은 검색 유입과 검색엔진 관리 도구의 크롤링 오류를 지켜본다. 검색 노출이 떨어졌다면 규칙이 검색 크롤러까지 붙잡고 있는 건 아닌지 확인한다.

    클라우드플레어가 없다면 robots.txt, 다만 요청문일 뿐이다

    클라우드플레어를 쓰지 않는 사이트의 첫 수단은 robots.txt다. 사이트 최상위 경로에 두는 파일로, 크롤러 이름(User-agent)별로 들어와도 되는 경로를 적는다.

    User-agent: [차단할 AI 크롤러 이름]
Disallow: /

User-agent: [일부만 허용할 AI 크롤러 이름]
Disallow: /blog/

User-agent: *
Allow: /

    첫 블록은 해당 크롤러를 사이트 전체에서 막는다. 둘째 블록은 블로그 경로만 막고, 마지막 블록은 나머지 크롤러를 모두 들인다. 크롤러 이름은 AI 회사마다 제각각이고 새로 생기거나 바뀌기도 한다. 각 회사가 공개한 공식 문서에서 이름을 확인하고, 목록은 주기적으로 손봐야 한다.

    한계는 분명하다. robots.txt는 ‘들어오지 말아 달라’는 요청문이지 자물쇠가 아니다. 규칙을 지키는 크롤러는 따르지만, 무시하는 봇 앞에서는 아무 효력이 없다. User-Agent 역시 봇이 스스로 밝히는 이름이라 얼마든지 사칭이 가능하다. robots.txt만 고쳐 두고 안심하는 건 절반짜리 대응이다.

    강제력이 필요하면 한 단계 더 들어가야 한다. 웹서버 설정 파일에서 User-Agent 조건에 걸리는 요청에 접근 거부 응답을 돌려주거나, 호스팅 업체가 제공하는 방화벽 기능을 쓰는 방법이 있다. 사칭까지 걸러내려면 IP 대역 대조나 행동 기반 탐지가 필요한데, 개인이 직접 구축하기엔 부담이 크다. 클라우드플레어 같은 중간 계층 서비스가 이 영역을 쥐고 있는 이유가 여기 있다.

    한국어 사이트도 똑같이 긁힌다, 손댈 수 있는 범위만 다르다

    AI 수집은 언어를 가리지 않는다. 한국어 글도 같은 방식으로 긁혀 가니, 봇 트래픽 증가가 국내 사이트의 서버 비용과 방문 통계에도 그대로 반영된다고 보는 게 합리적이다. 차이는 운영자가 손댈 수 있는 범위에서 난다. 사이트 형태에 따라 꽤 크게.

    • 가입형 블로그 플랫폼: robots.txt나 봇 차단 설정을 운영자가 직접 고치지 못하는 경우가 많다. 이때 AI 봇 정책은 플랫폼 회사가 정하고, 개인은 플랫폼 공지와 이용약관 변경을 지켜보는 게 사실상 전부다. 플랫폼별 세부 정책은 각 서비스 공지에서 확인해야 한다.
    • 자체 도메인 사이트·설치형 블로그: robots.txt 수정, 클라우드플레어 연결, 서버 규칙까지 전부 운영자 몫이다. 앞에서 본 설정 순서를 그대로 가져다 쓰면 된다.
    • 온라인 쇼핑몰: 판단이 제일 까다롭다. AI 에이전트가 사람 대신 상품을 찾고 비교하는 흐름이 커지면, 에이전트를 전부 막는 건 고객 한 부류를 문 앞에서 돌려보내는 셈이 될 가능성이 있다(추측). 상품 정보 페이지는 열고 회원·결제 경로는 막는 식으로 나누는 게 무난해 보인다.

    국내 포털의 검색 로봇을 실수로 막지 않는 것도 챙길 부분이다. 사용자 지정 규칙을 넓게 잡아 User-Agent에 bot이 들어간 요청을 통째로 막아 버리면 국내 검색 노출까지 사라진다. 대시보드 표시 언어에 따라 메뉴 이름이 달리 보이기도 한다. 이 글에서 괄호로 병기한 영문 명칭을 기준으로 찾는 편이 덜 헷갈린다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 클라우드플레어 집계 기준으로 봇은 인터넷 트래픽의 절반을 넘었고, 자동화 트래픽이 사람 트래픽을 앞질렀다.
    • 역전은 클라우드플레어가 두 차례 내놓은 예측보다 빨리 일어났다.
    • 클라우드플레어는 사이트 운영자에게 AI 도구 전면 차단, 전면 허용, 대가를 내는 봇만 허용하는 선택지를 제공한다.
    • 클라우드플레어 네트워크는 전 세계 350개 이상 도시, 수천 개 데이터센터에 걸쳐 있다.

    아직 불확실한 것

    • 대가 지불 방식의 가격 책정과 정산 구조가 어떤 모습으로 자리 잡을지
    • 유료 접근 기능이 어느 요금제와 계정까지 열릴지, 대시보드 메뉴가 어떻게 바뀔지
    • 어떤 종류의 정보가 AI 회사에게 돈을 낼 만한 가치로 인정받을지
    • AI 회사들이 차단 설정과 robots.txt를 얼마나 일관되게 지킬지
    • 에이전트 트래픽이 광고 중심의 웹 사업 모델을 얼마나 빠르게 대체할지

    차단 토글보다 먼저 정할 것은 사이트의 수익 구조

    AI 봇 대응은 보안 설정처럼 생겼지만 실은 사업 결정이다. 광고로 먹고사는 사이트, 브랜드 노출이 목적인 사이트, 독자 데이터를 쥔 사이트는 같은 토글 앞에서 서로 다른 답을 내야 한다. 순서는 네 단계. 지금 들어오는 봇을 확인하고, 수익이 방문에 묶여 있는지 판단하고, 경로별로 정책을 나눈 다음, 적용 후 검색 유입을 점검한다.

    프린스 CEO는 사람이 아닌 트래픽이 웹의 주 사용자가 되는 흐름을 보면서, 대가를 내는 봇만 들이는 모델을 인터넷의 다음 사업 모델 후보로 밀고 있다. 이 모델이 광고만큼 넓게 퍼질지는 아직 모른다. 설정 한 번으로 끝날 문제가 아니라는 것만은 분명하다. AI 회사의 크롤러 목록은 계속 바뀌고, 사이트의 수익 구조도 가만히 있지 않는다. 정책을 한 번 정해 두고 잊기보다 분기마다 봇 현황을 다시 열어 보는 습관이 더 오래 간다.

    출처: The Verge

    관련 기사

  • AI 크롤러 차단, robots.txt가 못 막는 것

    AI 크롤러 차단, robots.txt가 못 막는 것

    3줄 요약

    • 봉인이 풀린 소송 문건에서 마이크로소프트 내부 인사는 AI 학습용 데이터 수집을 “인류 역사상 가장 큰 노동 절도”라고 표현했다.
    • 법적 쟁점의 무게중심은 “복제했느냐”가 아니라 “AI 답변이 원본 콘텐츠의 시장을 대체하느냐”로 옮겨가 있다.
    • 사이트 운영자가 직접 통제할 수 있는 건 robots.txt와 서버·CDN 차단인데, 둘 다 법적 강제력이 아니라 자율 규약과 트래픽 차단에 가깝다.

    숫자부터. 91,692건. 오픈AI의 중간 학습 데이터셋 한 곳에서 확인된 뉴욕타임스·데일리뉴스·탐사보도센터 발행 저작물의 사본 수다. Common Crawl에서 파생된 데이터셋에는 nytimes.com 한 도메인에서 나온 문서만 200만 건 넘게 들어 있었다. 뉴욕타임스가 오픈AI와 마이크로소프트를 상대로 낸 저작권 소송에서 가림막이 걷힌 문건에 적힌 값들이다.

    승패를 점치는 건 이 글의 관심사가 아니다. 문건이 유용한 이유는 따로 있다. 웹에 글을 올리는 사람이면 누구나 걸리는 질문 세 개를 한자리에 모아 놓았다는 점. 내 콘텐츠는 어떤 경로로 학습 데이터가 되는가. 그걸 막는 스위치는 어디에 붙어 있는가. 그 스위치는 실제로 작동하는가.

    쟁점은 복제가 아니라 대체다

    AI 기업이 저작물을 학습에 써도 되는지, 확립된 답은 아직 없다. 미국에서 이들이 기대는 논리는 공정이용(fair use)이다. 패러디, 뉴스 보도, 비평처럼 일정한 경우에 허락 없이 저작물을 쓰는 것을 허용하는 법리다. 지금까지 법원은 “학습은 공정이용”이라는 AI 기업 주장에 대체로 우호적이었고, 미 행정부도 오픈AI의 비허가 저작물 학습을 옹호하는 의견서를 냈다. 방어하는 쪽 지형이 나쁘지 않았다는 뜻이다.

    공정이용 판단에서 늘 걸리는 항목은 하나다. 그 이용이 원저작물의 시장을 대체하거나 훼손하지 않는가. 이번에 공개된 내부 발언이 겨냥하는 지점이 정확히 여기다. 오픈AI에서 챗GPT를 총괄하는 닉 털리는 내부 커뮤니케이션에서 챗봇 같은 제품이 발행사에 “실존적 위협”이며 “상당 부분 대체적”이고 “성능이 좋아질수록 더 대체적으로 변한다”고 썼다. 그레그 브록만 오픈AI 사장은 모델이 “뉴스에 탁월하다”고 표현했다. 사티아 나델라 마이크로소프트 CEO는 증언에서 챗봇과의 대화가 “원 출처 웹사이트로 이동하는 대신 AI 플랫폼에서 바로 정보를 주는 방식으로 대체해 왔다”는 데 동의했다.

    변형적 이용이라는 방어선은 “원본과 다른 무언가를 만든다”는 전제 위에 서 있다. 회사 안에서 스스로를 대체재라고 부른 문장이 증거로 나오면 그 전제가 흔들린다. 상대편 변호인이 굳이 전문가 증인을 부를 필요가 없는 종류의 자료다. 개념 하나만 쥐고 가면 된다. 이 분쟁의 무게추는 긁어갔느냐가 아니라 원본 대신 소비되느냐에 걸려 있다.

    문건이 보여준 수집 규모와 경로

    문건에 흩어진 숫자를 한자리에 모으면 규모가 잡힌다. 아래 값은 모두 소송 서면에 인용된 내용이다.

    항목 수치 설명
    오픈AI 중간 학습 데이터셋 91,692건 뉴욕타임스·데일리뉴스·탐사보도센터 발행물 사본 수
    Common Crawl 파생 데이터셋 200만 건 이상 nytimes.com 한 도메인에서 나온 문서 수
    Project Mango 데이터셋 최소 160,903건 언론사 고유 저작물 수
    코파일럿 답변 엔진 최대 93% 감소 기존 빙 검색 대비 뉴욕타임스 도메인 클릭률

    경로도 뭉뚱그려 적혀 있지 않다. 빙 인덱스에서 콘텐츠를 긁어왔다는 대목, 오픈AI가 GPT-3 학습 데이터셋 전체를 마이크로소프트에 넘겼고 마이크로소프트는 자사 상용 제품에 모델을 어떻게 넣을지 평가하는 데 그 데이터를 썼다는 서술, Project Taxi·Project Mango라는 이름의 작업으로 마이크로소프트가 오픈AI에 학습 데이터를 제공했다는 내용까지 코드명과 함께 나온다. 뉴스 콘텐츠 비중이 큰 WebText, WebText2 같은 데이터셋을 별도로 만들었다는 주장도 붙어 있다.

    수집 방식 쪽 서술은 날이 더 서 있다. 오픈AI 연구원 닉 라이더가 브록만에게 “뉴욕타임스 페이월을 우회하는 방법”을 알렸고 브록만이 “오 좋네”라고 답했다는 인용. 학습 데이터가 모델에 들어가기 전에 저작권 고지를 의도적으로 제거했다는 서술. 이유는 연구자들이 “모델이 저작권 고지를 출력하기를 원치 않았다”는 것으로 적혀 있다. 마이크로소프트 응용과학 디렉터 브렌트 헥트는 내부 메모에서 이를 “전례 없는 규모의 놀라운 절도”, “인류 역사상 가장 큰 노동 절도”라고 불렀다.

    같은 문서에 공급망 경고도 함께 실렸다. 헥트는 클릭률 하락을 “둠 루프”로 부르며 “우리 모델의 성능과 웹 전체를 동시에 해칠 것”이라고 썼다. “최종 제품이 핵심 공급자의 경제적 기반을 위협하는 일은 매우 이례적인데, 우리가 LLM 사업의 콘텐츠 공급망에 만들어 낸 상황이 그렇다”는 문장도 나온다. 생성형 AI가 “학습 데이터를 만들어 낸 바로 그 사람들의 고용을 크게 무너뜨릴 실질적 위험”을 안고 있다는 표현까지. 외부 비판자가 아니라 이 사업을 만든 쪽 사람이 남긴 기록이라는 점이 이 대목의 무게다.

    학습에서 내 사이트를 빼는 네 단계

    1단계는 권한 확인이다. 브라우저 주소창에 “내도메인/robots.txt”를 넣어 파일이 뜨는지부터 본다. 자체 호스팅이면 웹 루트에 텍스트 파일로 올리면 끝난다. 워드프레스는 사정이 다르다. 플러그인이나 SEO 테마 설정이 파일 내용을 덮어쓰는 구조가 흔해서, 서버에 올려둔 파일이 아니라 관리자 화면에서 고쳐야 반영된다.

    2단계는 검색 크롤러와 학습 크롤러를 갈라내는 일이다. 이 구분을 놓치면 AI 학습을 막으려다 검색 유입까지 함께 끊긴다. 구글은 검색 색인용 크롤러와 생성형 AI 학습 옵트아웃 토큰을 따로 두고 있고, 오픈AI도 학습용 크롤러 이름을 공개 문서로 안내한다. 봇 이름과 정책은 사업자가 수시로 바꾼다. 차단 목록을 확정하기 전에 각 사업자의 공식 크롤러 문서에서 현재 이름을 대조하는 절차가 빠지면 안 된다.

    User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

    3단계는 규약을 무시하고 들어오는 트래픽을 서버나 CDN에서 끊는 것. 클라우드플레어를 쓴다면 대시보드에서 도메인을 고른 뒤 Security → Bots 영역에 AI 크롤러 차단 스위치가 있는지 본다. 요금제와 대시보드 개편에 따라 메뉴 위치와 이름이 달라지므로, 한눈에 보이지 않으면 보안 하위 메뉴를 전부 훑는 편이 빠르다. 웹서버를 직접 운영한다면 User-Agent 문자열을 보고 403을 돌려주는 규칙을 Nginx나 Apache 설정에 넣는 방법도 있다.

    4단계는 검증이다. 서버 접근 로그에서 User-Agent 문자열을 검색해, 차단 대상 봇이 여전히 200 응답을 받아 가고 있는지 확인한다. 파일만 올려두고 손을 떼면 지켜지는지 아닌지 알 방법이 없다. 앞의 세 단계는 한 번 해두면 당분간 유지되지만, 봇 이름이 바뀔 때마다 다시 밟아야 하는 건 이 4단계다.

    robots.txt가 막지 못하는 세 가지

    첫째, 강제력. robots.txt는 법이 아니라 자율 규약이다. 크롤러가 읽고 따를지는 운영 주체의 선택이고, 파일 자체가 접근을 집행하지는 않는다. 3단계의 서버·CDN 차단을 굳이 따로 떼어 적은 이유가 여기 있다. 실질적인 방어선은 그쪽이다.

    둘째, 과거 데이터. 차단 규칙을 오늘 넣어도 어제까지 수집된 스냅샷은 회수되지 않는다. Common Crawl은 누구나 내려받을 수 있는 무료 공개 웹 크롤 저장소이고, 문건에 따르면 여기서 파생된 데이터셋에 nytimes.com 문서만 200만 건 넘게 들어 있었다. 공개 아카이브에 한번 들어간 페이지는 설정 변경으로 되돌릴 수 없다. robots.txt는 앞으로를 위한 장치지 과거를 지우는 버튼이 아니다.

    셋째, 우회. 문건의 서술대로라면 페이월 뒤 콘텐츠를 탐지되지 않게 가져오는 방법을 논의한 정황까지 있다. 로그인과 결제벽도 완전한 방벽은 아니라는 뜻이다. 그래서 남는 수단이 계약이다. 나델라는 증언에서 “페이월 뒤에 있는 것은 그라운딩이든 학습이든 쓰려는 쪽이 라이선스해야 한다”고 말했고, 오픈AI가 페이월 뒤 콘텐츠를 긁어 학습한 사실을 알았다면 모델을 다시 학습시키도록 요구할 권리를 발동했을 것이라고 했다. 기술적 차단이 닿지 않는 구간을 계약서가 메우는 구조다.

    국내 독자가 챙길 것

    호스팅형 블로그 이용자가 먼저 부딪히는 벽은 robots.txt 접근 권한이다. 플랫폼이 제공하는 블로그 서비스는 루트에 파일을 직접 올릴 수 없는 경우가 많다. 관리 화면에서 검색 엔진 수집 허용 여부를 켜고 끄는 스위치가 있는지 찾고, AI 학습 관련 별도 옵션이 있는지는 플랫폼 공지와 약관에서 확인해야 한다. 메뉴 이름과 위치는 플랫폼 개편 때마다 달라지므로 화면 그대로의 경로를 외우는 건 의미가 없다.

    클릭률 수치는 그대로 옮겨 쓰면 곤란하다. 93%는 마이크로소프트 자체 데이터에서 코파일럿 답변 엔진과 기존 빙 검색을 비교했을 때 뉴욕타임스 도메인에 나타난 하락 폭이다. 한국 검색 환경이나 다른 도메인에 같은 비율이 적용된다는 근거는 문건 어디에도 없다. 자기 사이트의 변화는 서치 콘솔과 접근 로그로 직접 재는 수밖에 없다.

    국내 법·제도는 단정하기 어려운 영역이다. 저작권법에 텍스트·데이터 마이닝 관련 면책 조항을 두자는 논의가 이어져 왔다는 점은 알려져 있으나, 입법 확정 여부와 세부 요건은 국회 의안정보시스템이나 소관 부처 자료로 직접 확인하는 편이 안전하다. 국내 언론·콘텐츠 사업자와 AI 기업 사이의 라이선스 협상 상황 역시 이번 문건에 담겨 있지 않다.

    협상 재료로서의 가치는 분명하다. “페이월 뒤 콘텐츠는 라이선스 대상”이라는 취지의 CEO 증언, “대체적”이라는 내부 표현. 콘텐츠 보유자가 계약 테이블에서 그대로 인용할 문장들이다. (추측) 유료 구독 기반 매체를 중심으로 학습 데이터 이용 조건을 계약서에 명시하라는 요구가 강해지는 흐름으로 이어질 여지가 있다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 봉인 해제된 문건에서 마이크로소프트 응용과학 디렉터 브렌트 헥트가 학습 데이터 수집을 “인류 역사상 가장 큰 노동 절도”로 표현했다.
    • 오픈AI 중간 학습 데이터셋에 세 언론사 저작물 사본 91,692건, Project Mango 데이터셋에 최소 160,903건의 고유 저작물이 포함됐다는 서술이 있다.
    • 마이크로소프트 자체 데이터에서 코파일럿 답변 엔진이 뉴욕타임스 도메인 클릭률을 기존 빙 검색 대비 최대 93% 낮췄다는 내용이 제시됐다.
    • 페이월 우회 방법 공유, 저작권 고지 제거, 빙 인덱스 기반 수집에 관한 서술이 서면에 포함됐다.

    아직 불확실한 것

    • 공개된 내용 상당 부분은 뉴욕타임스 측 서면에서 나왔고, 근거가 된 증거물 자체는 봉인 상태다. 인용문은 원래 맥락 없이 제시됐다.
    • AI 학습이 공정이용인지에 대한 최종 판단은 나오지 않았다. 법원은 그동안 AI 기업 논리에 대체로 우호적이었다.
    • 오픈AI와 마이크로소프트는 논평 요청에 답하지 않았다. 반박 논리의 구성은 알 수 없다.
    • 한국어 사이트가 각 데이터셋에 어떤 규모로 포함됐는지, 국내 법·계약 관행이 어떻게 정리될지는 이 문건으로 알 수 없다.

    값이 정해질 지점은 세 곳이다

    첫째는 시장 대체 판단이다. 내부 문서의 “대체적”이라는 표현과 클릭률 데이터가 법정에서 어느 정도 무게를 갖는지가 이후 분쟁의 기준선을 만든다. 둘째는 봉인이 풀릴 증거물. 서면 인용과 원문 맥락이 얼마나 맞아떨어지는지에 따라 같은 문장도 다르게 읽힌다. 셋째는 라이선스 시장이다. 콘텐츠 이용에 값이 붙기 시작하면 사이트 운영자의 선택지는 차단이냐 허용이냐에서 “얼마에 파느냐”로 옮겨간다.

    그 사이 개인이 할 일은 소박하다. robots.txt를 실제로 갖고 있는지 확인하고, 학습용 크롤러와 검색용 크롤러를 구분해 적고, 로그로 지켜지는지 본다. 판결이 어느 쪽으로 기울든 이 세 가지는 그대로 유효하다. 판결을 기다렸다 손대기에는, 그사이에도 크롤러가 계속 돈다.

    출처: TechCrunch

    관련 기사