기업 데이터 수집 정책 작성하기: 실무 템플릿

웹 데이터를 수집하는 대부분의 팀에는 이에 대한 문서화된 규칙이 없다. 범위, 승인, 출처, 개인정보, 삭제 요청까지 다루는 실무 정책 템플릿.

대부분의 회사는 웹 데이터를 수집하는 방식에 대해 문서화된 규칙을 갖고 있지 않다. 한 개발자가 가격 조사 프로젝트를 위해 스크레이퍼를 만들면, 다른 팀은 리드 조사를 위해 그것을 복사하고, 또 다른 계약자가 세 번째 스크레이퍼를 추가한다. 그러면 어떤 사이트가 수집 대상인지, 어떤 개인 데이터가 저장되는지, 사이트 소유자의 항의에 누가 답할지 아무도 말할 수 없게 된다. 작업 자체는 대체로 문제가 없다. 문제는 그것이 문제없다는 것을 아무도 증명할 수 없다는 점이다.

짧은 사내 정책 하나로 이를 해결할 수 있다. 엔지니어에게는 명확한 기본값을 제공하고, 법무 및 보안 팀에게는 매번이 아니라 한 번만 검토하면 되는 기준을 제공하며, 고객이나 감사자, 웹사이트가 데이터 수집 방식을 물을 때 회사가 답할 수 있게 해준다. 이 글은 그러한 정책이 다뤄야 할 내용을 설명하고, 참고할 수 있는 템플릿을 제공한다.

핵심 요약

수집 정책은 엔지니어가 실제로 읽을 수 있을 만큼 짧아야 한다: 범위, 승인 절차, 출처에 관한 규칙, 개인 데이터에 관한 규칙, 그리고 누군가 이의를 제기했을 때의 대응 방안.
안전한 경로를 기본값으로 삼는다. 공개된, 로그인하지 않아도 보이는 페이지, 정직한 신원 표시, 적절한 속도, robots.txt 준수는 별도 승인이 필요 없어야 하며, 그 외의 모든 것은 승인이 필요하다.
이의 제기를 이의 제기로 취급한다. 예를 들어 프랑스 개인정보보호 당국은 robots.txt나 CAPTCHA를 통해 이의를 제기한 사이트는 수집 대상에서 제외할 것을 기대한다.
개인 데이터는 모든 것을 바꾼다: 무엇을 수집할 수 있는지 정의하고, 수집 시점에 최소화하며, 보관 기간을 설정하고, 삭제가 가능하도록 한다.
책임자를 지정하고 삭제 요청(takedown) 절차를 마련한다. 첫 번째 항의가 들어왔을 때 누가 답할지 정하는 것은 이미 늦다.
이 템플릿은 출발점일 뿐 법률 자문이 아니다. 각자의 관할권과 계약서에 맞춰 법률 자문을 받아 검토해야 한다.

문서화된 정책이 중요한 이유

실용적인 이유는 세 가지다.

일관성. 문서화된 규칙이 없으면 각 프로젝트는 robots.txt, 속도 조절, 개인 데이터, 보관 기간에 대해 각자 판단을 내린다. 어떤 프로젝트는 신중하고 어떤 프로젝트는 그렇지 않을 것이며, 회사는 가장 부주의한 프로젝트의 위험을 떠안게 된다.

속도. 명확한 기본값이 있는 정책이 있으면 대부분의 프로젝트는 별도 회의 없이 시작할 수 있다. 법무와 보안은 정책을 한 번 검토한 뒤, 예외 사항만 추가로 검토하면 된다.

증거. 개인정보 보호 규제 기관은 컨트롤러가 어떤 안전장치를 적용하는지 증명할 수 있기를 기대한다. 예를 들어 프랑스 개인정보보호 당국인 CNIL은 웹 스크레이핑을 통한 개인 데이터 수집에 관한 가이드를 발표했는데, 여기에는 수집 기준을 사전에 정의할 것, robots.txt나 CAPTCHA 등을 통해 명백히 이의를 제기한 사이트는 제외할 것, 불필요한 데이터를 걸러낼 것, 민감 데이터는 식별 즉시 삭제할 것과 같은 조치가 나열되어 있다. 문서화된 정책은 이러한 조치가 실제로 존재함을 보여주는 방법이다.

정책이 다뤄야 할 내용

항목	답해야 할 질문
목적과 범위	어떤 활동과 팀에 적용되는가?
역할	누가 정책을 소유하고, 누가 프로젝트를 승인하며, 누가 항의에 답하는가?
기본 규칙	어떤 프로젝트든 별도 승인 없이 할 수 있는 것은 무엇인가?
승인	무엇이 승인을 필요로 하며, 누구에게서, 어떤 정보와 함께 받아야 하는가?
출처	어떤 사이트와 페이지가 수집 범위 안에 있으며, 그들의 신호를 어떻게 다룰 것인가?
개인 데이터	사람에 대해 어떤 데이터를 수집할 수 있으며, 어떻게 최소화하고 보호할 것인가?
기술적 수행 방식	수집 주체는 어떻게 신원을 밝히고, 요청 속도를 조절하며, 인증 정보를 다루는가?
공급업체	프록시 및 데이터 공급업체에 무엇을 요구하는가?
저장 및 보관	수집된 데이터는 어디에 보관되며, 누가 접근할 수 있고, 얼마나 오래 보관하는가?
이의 제기와 삭제 요청	사이트 소유자, 개인, 규제 기관이 이의를 제기하면 어떤 일이 벌어지는가?
기록과 검토	무엇을 로그로 남기며, 정책은 언제 검토하는가?

템플릿

문구는 자사에 맞게 조정하고, 해당하지 않는 부분은 삭제하며, 짧게 유지한다. 대괄호 안의 텍스트는 직접 채워 넣는 부분이다.

1. 목적과 범위

이 정책은 [회사명]과 그 직원 및 계약자가 웹사이트와 온라인 서비스로부터 자동으로 데이터를 수집하는 행위를 규율한다. 여기에는 스크레이퍼, 크롤러, 브라우저 자동화, 그리고 제3자가 우리를 대신해 수집한 데이터 구매가 포함된다. 자사 사용자가 직접 제공한 데이터나, 각자의 이용약관 하에 사용되는 공식 API는 6항이 적용되는 경우를 제외하고 다루지 않는다.

2. 역할

정책 소유자: [역할, 예: 데이터 책임자]가 이 정책과 수집 프로젝트 등록부를 관리한다.
승인자: [법무 담당자]와 [보안 담당자]가 4항에 따라 승인이 필요한 프로젝트를 승인한다.
프로젝트 책임자: 모든 수집 프로젝트는 이 정책 준수를 책임지는 한 사람을 지정한다.
삭제 요청 담당자: [역할 및 공용 메일박스]가 10항에 따른 이의 제기를 접수하고 응답한다.

3. 모든 프로젝트에 적용되는 기본 규칙

다음 조건을 모두 충족하면 추가 승인 없이 진행할 수 있다:

로그인 없이 방문자 누구나 볼 수 있는 공개 페이지만 수집한다;
수집 대상에 적용되는 robots.txt 및 기타 기계 판독 가능한 거부(opt-out) 신호를 준수한다;
수집 주체를 정직하게 밝히며, 자동화된 트래픽을 특정 개인으로 위장하지 않는다;
대상 서버에 눈에 띄는 부하를 주지 않도록 요청 속도를 조절한다;
6항에서 허용하는 범위를 넘는 개인 데이터는 수집하지 않는다;
시작 전에 프로젝트 등록부에 기록된다.

4. 승인이 필요한 프로젝트

다음에 해당하는 프로젝트는 시작 전에 승인자로부터 서면 승인을 받아야 한다:

업무 목적으로 공개된 업무용 연락처 정보를 넘어서는 개인 데이터를 수집하는 경우;
건강, 종교, 정치적 견해 등 특수 범주 데이터를 수집하는 경우;
로그인, 유료 구독(paywall) 또는 기타 접근 제어가 있는 페이지에서 수집하는 경우;
robots.txt, CAPTCHA, 차단, 계약 조항, 직접 요청 등을 통해 사이트가 이의를 표명한 이후에도 수집을 계속하는 경우;
머신러닝 모델의 학습, 미세조정(fine-tuning) 또는 평가를 위해 수집하는 경우;
수집한 데이터를 [회사명] 외부에 판매, 라이선스 제공 또는 공유하는 경우.

요청서에는 목적, 출처, 데이터 항목, 개인 데이터 여부와 그 법적 근거, 예상 수집량, 보관 기간, 프로젝트 책임자를 명시한다.

5. 출처와 그 신호

요구사항을 충족하는 공식 API, 데이터 피드, 라이선스가 존재하면 그것을 우선 사용한다.
수집을 시작하기 전에 각 출처의 관련 이용약관을 읽고 기록한다.
robots.txt, 속도 제한, CAPTCHA, 차단, 공개된 예약 신호를 사이트의 의사 표시로 취급하며, 우회해야 할 장애물로 취급하지 않는다.
접근 제어, 기술적 보호 조치, 인증을 우회하지 않는다.
사이트가 이의를 제기하면 즉시 해당 출처에서의 수집을 중단하고, 등록부에 중단 사실을 기록한다.

6. 개인 데이터

명시된 목적에 필요한 개인 데이터만 수집하며, 가능하면 수집 시점에 그 외 개인 데이터를 걸러낸다.
4항에 따라 승인되지 않는 한 특수 범주 데이터는 절대 수집하지 않으며, 실수로 수집된 경우 식별 즉시 삭제한다.
분석에 신원 자체가 필요하지 않은 경우 식별자를 가명 처리한다.
승인 없이는 수집한 데이터를 다른 출처와 결합하여 개인을 식별하지 않는다.
요청 시 특정 개인의 데이터를 찾아 삭제할 수 있도록 한다.

7. 기술적 수행 방식

프록시, API, 대상 계정의 인증 정보는 코드에 넣지 않고 승인된 비밀 관리 시스템(secrets manager)에 저장한다.
8항을 충족하는 프록시 및 데이터 공급업체만 사용한다.
각 수집 실행마다 시간, 출처, 수집 위치, 사용된 구성을 기록한다.
요청량과 오류율을 모니터링하고, 출처가 요청을 거부하기 시작하면 자동으로 수집을 일시 중단한다.

8. 공급업체

프록시 및 데이터 공급업체는 자사 네트워크나 데이터의 출처와 그에 대한 동의 방식을 증명할 수 있어야 하고, 고객 확인(know-your-customer) 절차를 운영해야 하며, 허용 사용 정책(acceptable use policy)을 집행해야 하고, 이 정책과 부합하는 계약 조건에 서명해야 한다. 정책 소유자는 승인된 공급업체 목록을 관리한다.

9. 저장 및 보관

수집한 데이터는 [승인된 시스템]에만 저장하며, 접근 권한은 필요한 사람으로 제한한다.
승인에서 별도 기간을 정하지 않는 한, 원본 수집 페이지는 [기간] 이상, 추출된 데이터는 [기간] 이상 보관하지 않는다.
보관 기간이 끝나면 데이터를 삭제하고 삭제 사실을 기록한다.

10. 이의 제기와 삭제 요청

사이트 소유자, 개인, 당국으로부터 접수된 모든 이의 제기는 [영업일 기준 1일] 이내에 삭제 요청 담당자에게 전달된다.
법무팀이 달리 권고하지 않는 한, 이의가 검토되는 동안 해당 수집은 중단된다.
삭제 요청 담당자는 [기간] 이내에 응답하고, 이의 제기 내용, 결정 사항, 삭제된 데이터를 기록한다.
같은 프로젝트에 대해 이의 제기가 반복되면 해당 프로젝트의 승인을 재검토한다.

11. 기록과 검토

정책 소유자는 프로젝트 등록부, 승인 내역, 공급업체 목록, 삭제 요청 로그를 관리하며, 최소 [매년] 그리고 법률이나 회사 활동에 중대한 변화가 있을 때마다 이 정책을 검토한다.

실제로 정착시키기

공유 드라이브에만 보관된 정책은 아무것도 바꾸지 못한다. 다음과 같은 습관이 정책을 실질적으로 작동하게 만든다:

프로젝트가 시작되는 곳에 등록부를 둔다. 엔지니어가 이미 사용하는 도구 안에 기본 규칙을 체크박스로 넣은 짧은 양식을 두면, 프로젝트가 생긴 뒤가 아니라 생기기 전에 포착할 수 있다.
기본값을 코드에 내장한다. robots.txt를 준수하고, 정직한 User-Agent를 설정하고, 요청 속도를 조절하며, 수집 맥락을 기록하는 공용 수집 라이브러리를 만들면 정책 준수가 추가 단계가 아니라 쉬운 경로가 된다. robots.txt와 AI 거부(opt-out) 신호 준수하기에서 어떤 신호를 읽어야 할지 다룬다.
데이터가 관찰된 위치를 기록한다. 실행마다 시간, 위치, 구성을 로그로 남기는 것이야말로 나중에 수집된 데이터를 방어 가능하게 만드는 요소이며, 이는 수집 지점(vantage point) 표준을 위한 제언에서도 주장하는 바다.
공급업체를 점검한다. 프록시 공급업체에 IP 출처를 물어보고, 공급업체가 레지덴셜 IP를 윤리적으로 조달하는 방법과 저렴한 프록시 뒤에 숨은 멀웨어 경제를 참고하여 그것이 왜 중요한지 확인한다.
비밀 정보를 코드 밖에 둔다. CI/CD에서 스크레이퍼 운영하기에서 프록시 인증 정보를 안전하게 다루는 방법을 보여준다.
구축하기 전에 신호를 읽는다. 안티봇 스택 조회 가이드처럼 대상을 보호하는 요소를 간단히 확인하면, 해당 프로젝트가 기본 규칙에 해당하는지 승인이 필요한지 미리 알 수 있다.

더 넓은 법률적 맥락은 웹 스크레이핑은 합법인가와 레지덴셜 프록시와 GDPR을, 실무에서의 모범 사례는 웹 스크레이핑 모범 사례를 참고한다.

결론

데이터 수집 정책이 길 필요는 없다. 명확한 범위, 대부분의 작업을 진행할 수 있게 하는 안전한 기본값, 위험한 경우를 위한 승인 절차, 개인 데이터에 관한 확고한 규칙, 그리고 누군가 이의를 제기했을 때 답할 지정된 책임자만 있으면 된다.

한 번 작성하고, 그 기본값을 엔지니어가 사용하는 도구에 내장하며, 등록부를 최신 상태로 유지하라. 그러면 다음에 누군가 회사가 웹 데이터를 어떻게 수집하는지 물을 때, 그 답은 허둥대는 것이 아니라 하나의 문서가 될 것이다. 템플릿을 상황에 맞게 조정하고, 채택하기 전에 법률 자문을 받아 검토하라.