EDPB가 스크래퍼를 위한 규격을 발표했습니다
유럽의 개인정보 보호 당국은 AI 모델에 대해 많은 의견을 내놓았습니다. 하지만 이번 여름 전까지는 스크래퍼가 첫 페이지를 가져오기 전에 무엇을 해야 하는지 엔지니어에게 알려주는 지침이 없었습니다.
생성형 AI 맥락에서의 웹 스크래핑에 관한 지침 03/2026이 이를 바꾸었습니다. 유럽 데이터 보호 이사회(EDPB)는 2026년 7월 7일에 이 초안을 채택했으며, 공개 협의는 2026년 10월 30일에 마감됩니다. 표면적인 적용 범위는 좁습니다. 생성형 AI를 훈련하거나 미세 조정하기 위해 개인 데이터를 스크래핑하는 민간 기업입니다. 실제로 이는 규제 기관이 발표한 방어 가능한 스크래핑 작업 구축 방식에 대한 가장 상세한 설명입니다. 첫 요청 전에 작성하는 기준부터 마지막 레코드의 타임스탬프까지 다룹니다.
23페이지 전체를 검토한 우리의 판단은 이렇습니다. 초안은 사용자가 어떤 도구를 사용하는지 신경 쓰지 않습니다. 무엇을, 어디서, 언제 수집했는지 명확히 설명할 수 있는지가 핵심입니다. 한 번의 쿼리로 이에 답할 수 있는 스크래퍼는 문제가 없습니다. 범위가 정해지지 않은 크롤링은 거의 모든 문단에서 어려움을 겪을 것입니다.
(면책 조항: 이것은 법률적 조언이 아닙니다. 우선 우리는 초안을 참조하고 있으며, 코드의 관점에서 이것이 무엇을 의미하는지 읽고 있는 엔지니어입니다.)
타깃팅 여부가 중요한 기준입니다
8번 문단은 "사용된 기술적 도구가 아니라" 수집이 얼마나 구체적이고 제한적인지에 따라 스크래핑을 두 가지 종류로 나눕니다. 타깃 스크래핑은 도메인, 언어, 주제와 같은 수집 기준을 따릅니다. 비타깃 스크래핑은 발견한 모든 링크를 따라가는 크롤러입니다. 이사회의 우려는 명확합니다. 대기열이 늘어남에 따라 제어자는 "어떤 개인 데이터가 수집되고 처리되는지에 대한 지식이 제한적"이라는 점입니다.
이러한 구분은 텍스트 전체에 걸쳐 이어집니다. 데이터 최소화는 수집이 시작되기 전에 "정확한 수집 기준을 정의"하고 "데이터 매핑 및 인벤토리 프로세스"를 실행할 것을 요구합니다(37번 문단). 정당한 이익에 따른 필요성 테스트는 "인터넷의 광범위한 부분을 스크래핑하기보다는" 기준을 좁히는 것이 처리 자체를 필요하게 만드는 요인이 될 수 있다고 말합니다(52번 문단). 투명성은 이상적으로 도메인 이름, URL, 수집 날짜를 포함한 공개된 소스 목록을 요구합니다(30번 및 31번 문단).
수십 개 소매 도메인의 고정된 제품 페이지 목록을 가진 가격 추적기는 config 파일에서 이러한 모든 결과물을 생성할 수 있습니다. 너비 우선 탐색 크롤링은 불가능합니다. Privacy World의 초안 비평은 이러한 긴장감을 잘 짚어냅니다. 이사회가 비타깃 크롤링에 인벤토리화할 수 없는 개인 데이터가 포함될 수 있음을 인정한 직후, 규제 의무는 자신이 무엇을 수집하는지 알고 있는 제어자를 위해 작성되었다는 점입니다.
의미하는 바: 개인과 관련된 데이터(사용자명이 포함된 리뷰, 중개인의 이름 및 전화번호가 포함된 매물 정보, 포럼 스레드 등)를 스크래핑하는 경우, 수집 기준 자체가 컴플라이언스 대상 산출물이 됩니다. 이를 누군가의 머릿속이 아닌 스크래퍼 코드 옆의 버전 관리 시스템에 보관하십시오.
사이트의 거부 신호는 법적 불리함으로 작용합니다
이 부분이 대다수 파이프라인에 가장 큰 변화를 가져올 것입니다. 초안에는 사이트가 스크래핑을 명확히 반대하고 있음을 나타내는 기술적 조치가 나열되어 있습니다. robots.txt, ai.txt, "콘텐츠 열람을 위한 로봇 인증", 그리고 "인간만이 수행할 수 있는 동작을 요구하는 검증"(37항)이 이에 해당합니다. 학습 데이터에 대한 권고안은 이러한 사이트를 대상에서 제외하는 것입니다.
동일한 신호들이 법익 균형 평가(balancing test)에서도 다시 적용됩니다. 초안에 따르면, 사용자가 사이트에서 이러한 조치를 사용 중임을 인지하고 있음에도 사이트가 스크래핑되는 경우, 사용자는 자신의 데이터 처리를 예상하기 어렵다고 봅니다(64항). 예시 5에서 이를 구체화합니다. robots.txt 제외 설정, 인간 검증, AI 학습 금지가 명시된 플랫폼의 사용자는 제3자가 해당 목적으로 자신의 데이터를 스크래핑할 것이라고 "합리적으로 기대할 수 없습니다". 반대의 경우는 성립하지 않습니다. robots.txt가 없다고 해서 동의를 의미하는 것은 아닙니다(45항).
프랑스 CNIL이 이 원칙을 가장 먼저 도입했습니다. 2025년 6월 처음 발행된 정당한 이익과 웹 스크래핑에 관한 핵심 지침에 따르면, 관리자가 robots.txt나 인간 전용 검증을 통해 거부 의사를 밝힌 사이트를 제외하지 않은 경우 해당 처리는 "정보주체의 합리적인 기대 범위 내에 있을 수 없습니다".
경감 조치(66c항) 중에는 덜 직관적인 두 가지 항목도 포함되어 있습니다. 하나는 로그인 후에만 표시되는 개인정보를 제외하는 것입니다. 다른 하나는 스크래퍼의 User-Agent에 일반 브라우저와 다른 결과를 반환하는 사이트에 관한 것으로, "특히 스크래핑 서비스가 일반인이 볼 수 있는 것보다 더 많은 데이터를 수신하는 경우"를 다룹니다. 스크래퍼가 화면에 표시되는 것보다 더 풍부한 내부 API 데이터를 읽고 있다면 바로 이 사례에 해당합니다.
당사는 Search, Agent, Training: The Web's New Bot Rules에서 기계 판독 가능한 측면(robots.txt 확장, 서명된 에이전트, 콘텐츠 신호)을 검토했으며, Pay-Per-Crawl Is Splitting the Web in Two에서는 거부 대신 과금을 선택하는 게시자들을 다루었습니다. 규제 기관이 이러한 신호를 사용자 기대에 대한 증거로 취급한 것은 이번 EDPB 초안이 처음입니다.
의미하는 바: 도메인별 수집 시점의 robots.txt(사이트에 있는 경우 ai.txt 포함) 상태를 데이터와 함께 기록하십시오. 1년 뒤 누군가 특정 소스가 학습 세트에 포함된 이유를 묻는다면, 기록해 둔 경우에만 "수집 당일에는 허용되어 있었습니다"라고 답변할 수 있습니다.
스크래퍼는 처리자(processor)로 간주될 수 있습니다
Section 3.2.1은 짧아서 무심코 지나치기 쉽습니다. 하지만 클라이언트를 위해 스크래퍼를 구축한다면 절대 넘겨서는 안 됩니다. 개발자의 "문서화된 지침에 따라" 대행으로 학습 데이터셋을 생성한다면, 당신은 처리자(processor)이고 개발자는 관리자(controller)가 될 수 있습니다(문단 18). 클라이언트와 수집 기준을 함께 정한다면 공동 관리자(joint controllers)가 될 수 있습니다(문단 20, 예시 1). 자체적으로 데이터셋을 스크래핑한 후 타인이 이를 재사용한다면, 각자 자신의 처리에 대해 책임을 집니다(문단 19).
초안에 대한 Brian Hengesbaugh의 IAPP 칼럼은 비즈니스 관점의 핵심을 짚습니다. 계약서에 벤더가 처리자로 명시되어 있다면 가이드라인이 명시한 컴플라이언스 책임은 클라이언트가 부담하며, 벤더 자체의 직접적 의무는 "통상적인 생각보다 더 좁고 덜 위안이 될 수 있습니다." 이는 양날의 검입니다. 클라이언트는 스크래퍼를 개발한 프리랜서에게 컴플라이언스를 떠넘길 수 없으며, 소스 목록을 임의로 결정한 프리랜서는 본의 아니게 관리자가 될 위험이 있습니다.
데이터 팀이 지금 변경해야 할 사항
대부분의 상업적 스크래핑은 이번 지침의 영향을 받지 않습니다. 가격, 재고 수준, 제품 사양, 일정표는 일반적으로 개인정보가 아니므로 GDPR이 적용되지 않습니다. 초안은 "혼합" 데이터셋의 경우 개인정보 부분에만 적용된다고 명확히 명시합니다(문단 13). 따라서 판매자 이름이 포함된 목록이나 사용자 이름이 포함된 리뷰는 해당 부분이 적용 대상이 됩니다.
개인정보를 수집하는 작업의 경우, 초안의 요구 사항을 파이프라인에 적용하는 방법은 다음과 같습니다.
| 초안 요구 사항 | 파이프라인 적용 방식 |
|---|---|
| 수집 기준 | 작업별 URL 패턴 |
| 구문 기반 필터링 | 파싱 시 Regex 제외 처리 |
| 타임스탬프 기록 | 각 행의 fetched_at |
| 소스 목록 | config 내 도메인 설정 |
| 거부(opt-out) 준수 | robots.txt 상태 로깅 |
표의 내용 중 두 항목은 더 자세히 살펴볼 필요가 있습니다.
몇 주 후의 정제 작업이 아니라 파싱 시점에 필터링하십시오. 문단 38은 주민등록번호나 전화번호 같은 형식에 대해 수집 중 정규식을 적용하도록 언급합니다. 저장하지 않은 데이터는 해명할 필요도 없으며, 문단 60은 이것이 AI에 중요한 이유를 직설적으로 지적합니다. 한번 모델이 학습되면 그 안에서 개인정보를 "쉽게 삭제할 수 없기" 때문입니다.
모든 레코드에 소스 URL과 수집 시각을 유지하십시오. 문단 42는 정확성을 위해 타임스탬프를 요구하지만, 이 두 필드는 추후 데이터 출처에 대한 모든 질문에 대응할 수 있는 근거가 됩니다. 학습 데이터 규정은 AI Act에 따라 이미 강화되고 있었으며(4월에 다룬 내용 참조), 이들 역시 동일한 질문을 지속적으로 던지고 있습니다.
클라이언트를 위해 구축하는 경우 소스, 필드, 제외 항목 등의 지침을 서면으로 작성해야 합니다. 초안에서는 문서화된 지침의 유무를 공동 관리자가 아닌 처리자로 분류되는 기준으로 보며, 한 페이지짜리 사양서가 추후 역할에 대한 분쟁을 방지하는 가장 확실한 방법입니다.
10월 30일 이후 진행 상황
최종 문안은 변경될 예정이며, 더 큰 변화는 위원회(Board)가 아닌 브뤼셀에서 비롯될 수 있습니다. 2026년 10월 21일, 이사회(Council)는 GDPR을 개정하는 패키지 법안인 디지털 옴니버스(Digital Omnibus)에 대한 협상 입장을 확정했습니다. IAPP의 위임 사항 보고서에 따르면, 회원국들은 AI 훈련 데이터와 관련해 "개인정보 처리의 적법한 근거 및 적절한 안전조치 유지 필요성에 대한 명확화"를 추가했습니다. 다음 단계는 유럽 의회와의 협상입니다. 어떤 문구가 최종 도출되든 회원국들은 안전조치 유지를 원하고 있으며, 이는 이번 초안과 유사한 법익 형량 평가(balancing test)를 가리킵니다.
우리는 표적 수집(targeted)과 비표적 수집(untargeted)의 구분이 두 입법 과정 모두에서 살아남을 것으로 봅니다. 이 초안에서 법률이 아닌 엔지니어링에 관한 유일한 부분이기 때문입니다. 규제 당국이 크롤러 코드를 직접 읽지는 않습니다. 수집 기준, 소스 목록, 타임스탬프를 요구할 수는 있으며, 당일 오후에 이를 바로 제출할 수 있는 팀이라면 규제 당국과 논쟁할 거리가 거의 남지 않습니다.
따라서 개인정보 규제 당국이 스크래퍼에 던질 다음 질문은 "어떻게 작동하는가"가 아니라, "무엇을 수집하도록 지시받았는가"가 될 것입니다.