짧게 말하면: GDPR이 웹 스크래핑 자체를 전면 금지하는 건 아닙니다. 하지만 스크래퍼가 식별 가능한 사람에 관한 정보를 수집, 저장, 정리, 재사용한다면 그건 개인정보 처리에 해당합니다. “공개된 정보였으니 문제없다”는 식의 접근은 gdpr 준수 전략이 될 수 없습니다.
이 구분은 지금 더 중요해졌습니다. 2026년 7월, 유럽개인정보보호이사회(EDPB)는 웹 스크래핑이 개인정보 처리 작업을 포함할 때 GDPR이 적용된다고 밝히면서, 목적 제한과 투명성을 핵심 쟁점으로 짚었습니다. 새 웹 스크래핑 가이드라인은 아직 의견 수렴 단계지만, 방향은 분명합니다. 페이지를 기술적으로 수집하는 건 컴플라이언스 검토의 출발점일 뿐입니다. EDPB 업데이트
이 가이드는 법률 자문이 아니라 실무 운영 프레임워크입니다. 제품과 엔지니어링 의사결정을 더 잘 내리는 데 활용하고, 실제 위험이 있는 사안은 개인정보 보호 자문이나 DPO와 함께 다시 확인하세요.
먼저, “스크래핑 가능”과 “활용 가능”을 구분하세요
아래 세 가지 질문은 자주 한데 묶이지만, 사실은 완전히 다른 문제입니다.
| 질문 | 확인하는 내용 |
|---|---|
| 접근 | 해당 사이트와 자료에 접근하고 수집할 권한이 있는가? |
| 데이터 보호 | 사람이 식별 가능하다면 GDPR에 따라 데이터를 처리할 수 있는가? |
| 재사용 | 그 데이터를 보관, 보강, 판매, 학습, 공개, 연락 용도로 써도 되는가? |
한 가지 기준을 통과했다고 해서 나머지 기준까지 자동으로 해결되는 건 아닙니다. 페이지는 누구나 볼 수 있어도, 그 안의 데이터는 여전히 개인정보일 수 있습니다. 기술적으로 크롤링이 성공하더라도 GDPR, 계약, 지식재산권, 데이터베이스 권리, 소비자 보호, 마케팅 법규 문제가 동시에 생길 수 있습니다.
그러니 컴플라이언스는 나중에 개인정보처리방침 한 줄 덧붙이는 일이 아니라, 작업을 시작하기 전의 업무 절차로 봐야 합니다.
1. GDPR 적용 대상인지 먼저 판단하세요
두 가지 질문부터 시작하세요.
데이터셋에 개인정보가 포함되어 있나요?
개인정보는 이름이나 이메일보다 훨씬 넓은 개념입니다. 식별된 개인 또는 식별 가능한 개인과 관련된 정보라면 모두 해당될 수 있습니다. 예를 들면 프로필 사진, 사람과 연결 가능한 사용자명, 위치 정보, IP 주소, 경력 이력, 리뷰, 또는 단독으로는 평범해 보여도 조합하면 개인을 드러내는 항목들이 여기에 들어갑니다. EDPB 정의
기업 단위 데이터는 경우에 따라 문제가 없을 수 있습니다. 하지만 ‘비즈니스 연락처’ 기록도 개인사업자의 실명, 직원의 직통 이메일, 휴대전화 번호, 연결된 프로필이 들어가면 바로 개인정보가 될 수 있습니다. 이상적인 데이터가 아니라 실제로 수집될 데이터를 기준으로 설계하세요.
귀사와 목적에 GDPR이 적용되나요?
처리가 EU 내 사업장과 연결되어 있다면 GDPR이 적용될 수 있습니다. 또 EU 밖의 조직이라도 EU 거주자에게 상품이나 서비스를 제공하거나 그들의 행동을 모니터링하면 GDPR 대상이 될 수 있습니다. 유럽연합 집행위원회 개요
두 답이 모두 예라면, 해당 스크래핑은 문서화된 GDPR 절차가 필요하다고 보세요. 판단이 애매하다면, 애매하다는 이유만으로 진행 신호로 보지 말고 반드시 상위 검토로 올려야 합니다.
2. 크롤러를 돌리기 전에 한 페이지짜리 수집 브리프를 작성하세요
가장 단순하면서도 효과적인 통제는, 수집 전에 무엇이 필요한지 분명하게 적는 것입니다.
브리프에는 다음을 포함하세요.
- 목적: 어떤 의사결정, 서비스, 분석을 위해 이 데이터가 필요한가?
- 대상과 필드: 어떤 범주의 사람이 등장할 수 있고, 정확히 어떤 필드가 꼭 필요한가?
- 출처와 접근: 콘텐츠는 공개되어 있는가? 이용약관, robots 설정, 로그인 장벽, 기타 기술적 제약에 의해 제한되는가?
- 사용 및 수신자: 결과를 누가 볼 것인가? 데이터는 보강, 내보내기, 공유, 직접 마케팅, 모델 학습에 사용될 것인가?
- 보관 기간: 원본 데이터, 작업 파일, 파생 기록은 언제 삭제하거나 다시 검토할 것인가?
- 책임: 데이터 컨트롤러는 누구이고, 프로세서는 누구이며, 권리 요청은 누가 처리하는가?
이건 형식만 갖추기 위한 절차가 아닙니다. GDPR 원칙은 분명한 목적과, 꼭 필요한 최소한의 적절하고 관련성 있는 데이터만 처리할 것을 요구합니다. 유럽연합 집행위원회 원칙
3. 법적 근거를 선택하고 문서화하세요. 절대 가정하지 마세요
모든 개인정보 처리에는 법적 근거가 필요합니다. 동의는 일부 제품에는 맞을 수 있지만, 공개 웹 데이터의 기본 해답은 아닙니다. 일부 민간 조직에서는 정당한 이익이 제한된 범위의 스크래핑에 대한 가능한 근거가 될 수 있지만, 실질적인 보호조치가 전제되어야 합니다. 자동으로 인정되는 건 아닙니다.
설득력 있는 정당한 이익 평가에는 세 가지 질문이 필요합니다.
- 그 이익은 합법적이고, 구체적이며, 실제로 존재하고, 현재도 유효한가?
- 이 목적을 위해 정말 이 수집이 필요한가, 아니면 덜 침해적인 방법이 있는가?
- 해당 개인의 이익, 권리, 합리적 기대가 귀사의 이익보다 우선하는가?
CNIL은 스크래핑으로 수집된 공개 데이터가 일반적으로 정당한 이익 관점에서 검토될 수 있지만, 사람에게 미치는 영향을 줄이기 위한 추가 조치가 필요하다고 설명합니다. 또 포괄적으로 허용되는 게 아니라 사례별 분석이 필요하다고 강조합니다. CNIL 가이드
분석 내용, 전제, 선택한 완화 조치를 문서화하세요. “프로필이 공개돼 있었다”는 균형 판단의 참고 요소일 뿐, 판단 그 자체는 아닙니다.
4. 최소 수집을 기술 요구사항으로 만드세요
가장 잘 지켜지는 기록은 애초에 스크래퍼가 수집하지 않은 데이터인 경우가 많습니다.
수집 작업에 다음 안전장치를 넣으세요.
- 필드 허용목록 사용. 필요한 필드만 정하고, 편하다고 화면에 보이는 모든 항목을 긁지 마세요.
- 민감 범주 차단. 건강, 정치, 종교, 노동조합, 성생활, 생체정보 및 기타 특별 범주 신호는, 자문을 통해 별도의 합법 경로가 설계된 경우가 아니면 제외하세요. 일반 텍스트도 예상치 못하게 이런 범주를 드러낼 수 있습니다.
- 고위험 출처 제외. 지원단체, 건강 포럼, 아동 관련 공간처럼 재사용이 놀랍거나 해로울 수 있는 맥락은 기본 제외 목록으로 관리하세요.
- 불필요한 데이터는 신속 삭제. 관련 없는 개인정보가 수집되면 “혹시 몰라서” 그냥 보관하지 말고, 분리해서 삭제하세요.
- 출처 이력 기록. 각 데이터셋마다 출처 URL, 수집 날짜, 관련 수집 설정을 저장하세요. 정확성, 삭제, 권리 요청 처리에 도움이 됩니다.
CNIL은 수집 전에 관련 범주를 미리 정하고, 불필요하거나 민감한 데이터를 필터링하고, 관련 없는 데이터는 삭제하며, 수집에 대한 기술적·법적 반대를 존중하라고 명시적으로 권고합니다. CNIL 보호조치
5. 투명성을 제품의 일부로 보세요
웹사이트에서 수집한 데이터는 보통 간접 수집에 해당합니다. 즉, GDPR 제14조의 투명성 의무가 문제될 수 있습니다. 누구인지, 목적은 무엇인지, 데이터 범주와 출처는 무엇인지, 법적 근거는 무엇인지, 보관 기간, 수신자, 이전 여부, 그리고 개인의 권리는 무엇인지 설명해야 합니다.
유럽연합 집행위원회 요약에 따르면, 다른 출처에서 데이터를 얻은 경우에는 일반적으로 한 달 이내, 첫 연락 시, 또는 최초 공개 시점 중 해당되는 시점에 정보 제공이 필요합니다. 통지가 불가능하거나 과도한 노력이 드는 경우 같은 예외는 있지만, 이는 조건부이며 단순한 추측이 아니라 평가와 문서화가 필요합니다. 유럽연합 집행위원회 의무
광범위한 수집에서는 숨겨진 법적 고지보다, 명확한 공개 안내문, 데이터셋 페이지, 전용 문의 경로, 이의제기·열람·정정·삭제를 쉽게 신청할 수 있는 안내가 더 실효적일 수 있습니다. 적절한 형식은 처리 방식과 위험 수준에 따라 달라집니다.
6. 출시 전에 삭제 및 권리 요청 워크플로를 구축하세요
대규모 스크래핑은 나중에 정리 비용이 큽니다. 데이터에 식별자를 부여하고, 출처와 레코드의 대응 관계를 통제하며, 원본 수집본, 데이터베이스, 내보내기, 색인, 하위 처리 시스템 전반에서 개인 데이터를 찾아 삭제하거나 비표시 처리할 수 있어야 합니다.
최소한 다음은 정해 두세요.
- 권리 요청을 누가 접수하고 검증하는가;
- 불필요한 추가 정보를 요구하지 않고 레코드를 어떻게 찾는가;
- 삭제 또는 이의제기가 하위 시스템으로 어떻게 전파되는가;
- 비표시 처리로 재수집을 어떻게 막는가;
- 로그와 백업이 해당 기록을 얼마나 보관하는지, 예외 처리 절차는 무엇인지.
데이터셋이 모델, 보강 그래프, 프로파일링, 직접 마케팅으로 이어진다면 이 계획은 더 엄격해야 합니다. 데이터가 더 멀리 이동할수록, 권리를 실질적으로 보장하기는 더 어려워집니다.
7. 데이터셋을 보호하고, 고위험 사례는 일찍 평가하세요
GDPR은 무단 접근, 손실, 파괴, 불법 처리를 막기 위한 위험 수준에 비례한 조치를 요구합니다. 개인정보 보호 설계와 기본값 보호는 사고가 난 뒤가 아니라, 처음부터 그 통제를 선택하는 것을 의미합니다. 유럽연합 집행위원회 의무
기본적으로 유용한 통제로는 역할 기반 접근제어, 전송·저장 시 암호화, 비밀정보 관리, 감사 로그, 벤더 검토, 데이터 내보내기 통제, 검증된 사고 대응 절차가 있습니다. 가명처리는 위험을 줄일 수 있지만, 익명화와 같지 않으며 보통 GDPR 의무를 자동으로 없애주지 않습니다.
다음 요소가 함께 있으면 고위험 처리로 이어질 가능성이 높으므로, 처리 전에 DPIA를 검토해야 합니다.
- 대규모 수집 또는 모니터링;
- 사람에게 영향을 주는 프로파일링 또는 의사결정;
- 특별 범주 또는 매우 민감한 데이터;
- 아동 또는 기타 취약한 사람;
- 새로운 추론을 위해 데이터셋을 결합하는 경우;
- 지속적 식별, 위치 데이터, 또는 데이터 브로커식 재사용;
- AI 학습 또는 개인정보를 기억하거나 노출할 수 있는 모델.
집행위원회는 체계적이고 광범위한 자동 평가, 대규모 민감정보 처리, 대규모 체계적 모니터링을 DPIA가 필요한 사례로 제시합니다. DPIA 가이드
웹 스크래핑 팀을 위한 출시 체크리스트
프로덕션 작업을 실행하기 전에 아래 항목을 모두 확인하세요.
- 수집에 개인정보가 포함되는지, 그리고 GDPR이 왜 적용되거나 적용되지 않는지 알고 있다.
- 정확한 서면 목적과 필요한 필드의 허용목록이 있다.
- 법적 근거를 문서화했으며, 필요하다면 정당한 이익 평가도 갖추고 있다.
- 민감하거나 고위험인 출처 및 범주는 기본적으로 제외했다.
- 출처 제한을 검토했으며 접근 통제를 우회하지 않는다.
- 투명한 공개 설명과 권리 요청·이의제기를 처리할 수 있는 경로가 있다.
- 컨트롤러/프로세서 역할이 정리되어 있고, 적절한 벤더 계약이 있다.
- 보관, 삭제, 비표시 처리, 하위 전파 절차가 마련되어 있다.
- 위험에 맞는 보안 통제와 사고 대응 책임자가 있다.
- DPIA와 국외 이전 평가를 완료했거나, 왜 필요하지 않은지 의도적으로 문서화했다.
실무적 결론
웹 스크래퍼의 gdpr 준수는 robots.txt에서 마법 같은 한 줄을 찾거나, 제품에 면책 문구를 붙이는 일이 아닙니다. 명확한 목적에 맞게 수집 범위를 적정 수준으로 제한하고, 사람들에게 의미 있는 가시성과 통제권을 제공하며, 나중에 그 선택을 증명할 수 있어야 합니다.
범위는 좁게 시작하세요. 적게 수집하세요. 출처와 타임스탬프를 남기세요. 삭제를 데이터 모델에 포함시키세요. 민감 데이터, 대규모 처리, 프로파일링, AI 학습 용도는 데이터가 하위 시스템으로 흘러가기 전에 반드시 상향 검토하세요. 이런 습관은 스크래퍼의 신뢰도를 높이고, 첫 번째 개인정보 질문이 들어왔을 때도 훨씬 운영하기 쉽게 만듭니다.
이 글은 일반 정보 제공용이며 법률 자문이 아닙니다. 귀사의 사실관계, 관할권, 데이터 범주, 사용 목적에 대해서는 자격 있는 전문가의 조언을 받으세요.
더 알아보기
