지식

레지덴셜 프록시와 GDPR: 컴플라이언스 개요

IP 주소는 개인정보에 해당할 수 있으며, 프록시는 어떤 것도 익명화하지 않습니다. 컴플라이언스 팀이 레지덴셜 프록시에 대해 실제로 물어야 할 GDPR 관련 질문들입니다.

Matt Brown

Matt Brown

2026년 7월 20일 · 9 분 소요

이는 법률 자문이 아닙니다. GDPR 하에서 프록시 사용에 대해 컴플라이언스 및 법무 팀이 더 나은 질문을 던질 수 있도록 돕기 위한 실용적인 개요입니다. 정확한 답변은 귀사의 데이터, 목적, 관할권에 따라 달라지므로, 이를 자격을 갖춘 법률 자문가 및 DPO와의 대화를 시작하기 위한 출발점으로 여기시기 바라며, 그 대체물로 삼지 마시기 바랍니다.

데이터 수집 프로젝트가 법률 검토 단계에 이르면, 프록시 계층에는 대개 두 가지 오해가 따라붙습니다. 엔지니어링 팀은 때때로 프록시를 컴플라이언스 팀이 볼 필요가 없는 중립적인 배관 정도의 세부사항으로 가정합니다. 컴플라이언스 팀은 때때로 프록시를 반드시 적신호여야 하는 회피 도구로 가정합니다. 둘 다 틀렸으며, 진실은 어느 쪽보다 더 유용합니다.

프록시는 합법적인 라우팅 기술입니다. 요청이 어느 IP 주소에서 시작되는지를 바꿀 뿐, 그 외에는 아무것도 바꾸지 않습니다. 수집하는 데이터를 익명화하지 않으며, 컨트롤러로서의 의무를 줄이지 않으며, 그렇지 않았다면 불법적이었을 처리를 합법으로 만들지도 않습니다. 프록시가 실제로 하는 일은 GDPR이 중요하게 여기는 몇 가지 구체적인 질문을 제기하는 것입니다. 관련된 IP 주소가 개인정보에 해당하는지, 누가 컨트롤러이고 누가 프로세서인지, 데이터가 국경을 넘는지, 그리고 제공업체가 귀사에 연결해주는 IP를 어떻게 소싱하는지 등입니다.

이 글은 컴플라이언스 검토 시 일반적으로 필요한 순서대로 이러한 질문들을 다룹니다. 데이터 보호를 넘어선 더 넓은 법적 그림에 대해서는, 웹 스크래핑이 합법인가에서 다른 프레임워크(계약, 저작권, 데이터베이스 권리, 컴퓨터 오남용)를 다루고 있습니다.

먼저: 초기에 없애야 할 오해

프록시를 사용한다고 해서 GDPR 노출이 줄어들지 않습니다.

귀사의 수집이 개인정보를 수집한다면, 요청이 사무실 IP에서 나갔든 프랑크푸르트의 레지덴셜 출구에서 나갔든 귀사의 의무는 동일합니다. GDPR은 귀사의 개인정보 처리에 적용되는 것이지, 요청이 거친 네트워크 경로에 적용되는 것이 아닙니다. 프록시는 가명처리 조치도, 익명화 기법도, 개인정보 영향평가를 위한 완화 통제 수단도 아닙니다.

이 점을 초기에 명확히 하면 두 가지 실패 유형을 방지할 수 있습니다. 프록시를 컴플라이언스 지름길로 취급하는 팀(그렇지 않습니다), 그리고 실제 위험이 무엇을 수집하는지에 있는데도(프록시가 이를 만들지도 치유하지도 않습니다) 반사적으로 프록시를 금지하는 팀입니다.

질문 1: IP 주소는 개인정보인가?

대개 그렇습니다. Breyer 사건(C-582/14)에서 CJEU는 동적 IP 주소가, 그 뒤에 있는 개인을 식별하는 데 합리적으로 사용될 가능성이 있는 법적 수단을 보유한 당사자의 손에서는 개인정보를 구성할 수 있다고 판시했습니다. 규제 기관들은 그 이후 대부분의 실무적 맥락에서 IP 주소를 대체로 개인정보로 취급해 왔습니다.

이것이 프록시 사용에 왜 중요한지, 두 가지 방향에서 살펴보겠습니다.

  • 귀사가 수집하는 IP. 스크래핑이 IP 주소를 캡처한다면(로그에서, 페이지 콘텐츠에서, API 응답에서), 이는 범위에 속하는 개인정보일 가능성이 높습니다.
  • 귀사가 경유하는 IP. 레지덴셜 출구 IP는 실제 개인의 가정 연결에 속합니다. 그 IP, 그리고 그것과 연관된 트래픽은 식별 가능한 개인에 관한 데이터이며, 바로 이 때문에 제공업체의 소싱(질문 5)이 단순히 윤리 문제가 아니라 진정한 컴플라이언스 문제가 됩니다.

질문 2: 역할은 무엇이며, DPA가 필요한가?

이는 컴플라이언스 팀이 가장 답을 필요로 하는 질문이며, 가장 자주 건너뛰는 질문이기도 합니다.

GDPR 하에서 컨트롤러는 처리의 목적과 수단을 결정하며, 프로세서는 컨트롤러를 대신하여 개인정보를 처리합니다. 일반적인 수집 설정에서 귀사는 수집하기로 결정한 개인정보와 그 이유에 대한 컨트롤러입니다.

제공업체의 역할은 벤더의 마케팅이 보통 인정하는 것보다 더 사실관계에 따라 달라집니다. 그 계약 방식과 제공업체가 귀사를 대신하여 처리하는 개인정보의 내용에 따라, 프록시 제공업체는 프로세서 역할을 할 수도 있고, 자체 운영 데이터(자체 네트워크 로그, 피어 관계, 청구)에 대해서는 독립적인 컨트롤러 역할을 할 수도 있습니다. 가정하지 말고, 판단하고 문서화하십시오.

  • 제공업체가 실제로 귀사를 대신하여 처리하는 개인정보가 무엇인지 매핑하고, 있다면 무엇인지, 그리고 제공업체 자체 목적으로 처리하는 것이 무엇인지 파악합니다.
  • 역할을 서면으로 확립합니다. 제공업체가 그중 일부에 대해 프로세서인 경우, 제28조는 명시된 조건이 담긴 서면 계약, 즉 DPA를 요구합니다.
  • 제공업체의 문서를 요청합니다. 진지한 제공업체라면 자신의 역할을 알려줄 수 있어야 하고, 해당되는 경우 DPA를 제공하거나 논의할 수 있어야 하며, 하위 프로세서를 설명할 수 있어야 합니다.

제공업체가 역할 관련 질문에 명확히 답하지 못한다면, 그 자체가 귀사의 검토에서 하나의 발견 사항입니다.

질문 3: 국제 이전이 관련되는가?

제5장은 적절한 메커니즘(적정성 결정, 표준계약조항 등) 없이 EEA 외부로 개인정보를 이전하는 것을 제한합니다.

프록시 아키텍처는 이를 그냥 가정하기보다 확인해볼 가치가 있게 만듭니다. 트래픽이 의도적으로 선택된 국가로 나가며, 제공업체 자체의 인프라와 지원 기능은 다른 곳에 위치할 수 있기 때문입니다. 평가해야 할 두 가지 별개의 흐름이 있습니다.

  1. 다양한 관할권의 출구를 통해 전송하거나 수신하는 개인정보.
  2. 제공업체가 귀사의 계정과 트래픽에 대해 처리하는 개인정보, 그리고 해당 제공업체(및 하위 프로세서)가 설립되고 이를 저장하는 위치.

특정 흐름이 메커니즘을 필요로 하는 “이전”에 해당하는지 여부는 기술적 판단이 아니라 귀사의 법률 자문이 내려야 할 법적 판단입니다. 귀사의 팀이 할 수 있는 일은 법률 자문이 평가할 수 있도록 정확한 데이터 흐름도를 작성하는 것입니다. 실무적인 비대칭성에 유의하십시오. EU 출구를 선택한다고 해서 제공업체나 그 하위 프로세서가 EEA 외부에 있다면 처리 자체가 EEA 내부에 머무는 것은 아닙니다.

질문 4: 합법적 근거, 투명성, 그리고 어려운 문제

귀사의 수집이 개인정보에 관련된다면, 핵심 의무가 전면적으로 적용됩니다.

합법적 근거(제6조). 근거가 필요합니다. 공개 웹 수집의 경우, 정당한 이익(제6조 제1항(f))이 일반적인 후보이며, 이는 귀사의 이익과 개인의 권리 및 합리적 기대를 저울질하는 문서화된 형량 테스트를 요구합니다. “공개적으로 이용 가능했다”는 것은 합법적 근거가 아니며, 이는 이 분야에서 가장 흔한 오해입니다.

투명성(제14조)이 어려운 부분입니다. 개인정보를 간접적으로, 즉 본인으로부터가 아니라 수집하는 경우, 제14조는 일반적으로 통상 한 달 이내에 이를 통지할 것을 요구합니다. 그렇게 하는 것이 불균형한 노력을 수반하는 경우 예외가 있으며(제14조 제5항(b)), 이는 대규모 수집에서 자주 원용되며 규제 기관이 이를 심하게 조사해 왔습니다. 이 분야의 집행 조치는 반복적으로 바로 이 지점에서 갈렸으므로, 귀사의 계획이 그 예외에 의존한다면 이를 제대로 평가받고 근거를 문서화하십시오.

제5조 원칙들. 목적 제한(명시된 목적을 위해 수집), 데이터 최소화(필요한 것만, 이는 보통 사용할 데가 없는 개인 필드는 수집하지 않는다는 것을 의미합니다), 보관 제한(보관 일정), 정확성.

정보주체의 권리(제15조~제22조). 개인정보를 보유하고 있다면, 개인은 접근, 삭제, 이의제기 등을 요청할 수 있으며, 스크래핑한 데이터를 포함하여 이를 이행할 수 있는 실행 가능한 프로세스가 필요합니다.

**특별 범주(제9조)**는 실질적으로 더 높은 기준을 수반하며, **DPIA(제35조)**는 대규모 또는 체계적인 처리에 대해 요구될 수 있습니다. 두 가지 모두 법률 자문이 판단할 문제입니다.

질문 5: 제공업체는 IP를 어떻게 소싱하는가?

이는 프록시에 특화된 실사 질문이며, 컴플라이언스 검토에서 실질적인 비중을 가져야 합니다.

레지덴셜 IP는 실제 사람들에게 속합니다. 그 개인들은 정보주체이며, 그들이 어떻게 프록시 네트워크의 일부가 되었는지가 중요합니다. 명확히 고지받았는지, 진정하고 정보에 기반한 동의를 했는지, 자신의 연결을 통해 어떤 트래픽이 라우팅될지 이해했는지, 그리고 철회할 수 있는지 여부입니다. 불명확하거나 숨겨진 동의 위에 구축된 네트워크는 실사 측면과 평판 측면 모두에서 고객인 귀사에게 흘러오는 컴플라이언스 위험입니다.

저희를 포함하여 모든 제공업체에게 물어봐야 할 것들:

  • 피어는 어떻게 모집되며, 정확히 무엇을 고지받는가? 동의는 명시적이고, 정보에 기반하며, 철회 가능한가?
  • 제공업체 자체의 개인정보 보호 문서는 무엇인가? Shifter의 경우, 저희 개인정보 보호정책이용약관이 이에 해당합니다.
  • 제공업체는 어떤 역할을 맡으며, 프로세서로 행동하는 경우 DPA를 제공할 수 있는가?
  • 하위 프로세서는 누구이며, 어디에 위치하는가?
  • 수용 가능한 사용 정책은 무엇을 금지하며, 어떻게 집행되는가? 무엇이든 허용하는 제공업체는 네트워크가 무엇에든 사용되는 제공업체입니다.

저희는 마케팅 문구를 액면 그대로 받아들이기보다, 저희와 귀사가 평가하는 다른 누구에게든 이러한 질문을 던지고 문서화된 답변을 받으시기를 바랍니다. 레지덴셜 프록시 소싱의 윤리는 소싱 측면에서 동일한 내용을 다루고 있습니다.

실무적인 검토 체크리스트

프록시 기반 수집 프로젝트를 평가하는 컴플라이언스 팀을 위한 체크리스트입니다.

  • 수집이 애초에 개인정보와 관련이 있는가? 많은 프로젝트(가격, 재고 수준, 공개 제품 사양)는 이를 피하도록 범위를 정할 수 있으며, 이것이 단연 가장 깔끔한 입장입니다.
  • 문서화된 합법적 근거, 제6조 제1항(f)에 의존하는 경우 정당한 이익 평가 포함.
  • 제14조 관련 입장을 평가하고 문서화하며, 불균형한 노력 예외에 의존하는 경우 이를 포함.
  • 데이터 흐름도: 어떤 개인정보가, 어디에서 수집되어, 어떤 관할권을 거쳐, 어디에 저장되는가.
  • EEA를 벗어나는 모든 것에 대한 이전 평가, 필요한 경우 메커니즘 적용.
  • 제공업체와 서면으로 확립된 역할; 프로세서로 행동하는 경우 DPA 마련.
  • IP 소싱 및 동의, 하위 프로세서, AUP 집행에 대한 제공업체 실사.
  • 최소화 적용: 진정으로 필요한 경우가 아니면 개인 필드는 수집에서 제외.
  • 보관 일정 및 삭제가 문서상으로만이 아니라 실제로 구현됨.
  • 스크래핑된 데이터에도 도달할 수 있는 DSR 프로세스.
  • 처리가 대규모, 체계적, 또는 고위험인 경우 DPIA.

이 목록에서 가장 좋은 결과는 대개 첫 번째 항목입니다. 애초에 개인정보를 수집하지 않도록 프로젝트의 범위를 정하는 것입니다. 대부분의 상업적 수집, 가격, 가용성, 카탈로그 데이터, 경쟁사 모니터링에는 개인정보가 필요하지 않으며, 개인 필드를 제거하면 위험을 관리하는 것이 아니라 위험 표면 자체를 대부분 없앨 수 있습니다.

프록시가 실제로 도움이 되는 부분, 그리고 되지 않는 부분

도움이 되지 않는 것: 귀사의 합법적 근거, 투명성 의무, 보관 의무, 또는 컨트롤러로서의 지위. 그중 어떤 것도 네트워크 라우팅에 따라 바뀌지 않습니다.

도움이 되는 것: 정확성이며, 이는 과소평가된 컴플라이언스 측면을 가지고 있습니다. 제5조 제1항(d)는 개인정보가 정확할 것을 요구합니다. 지역 맞춤형 사이트는 위치에 따라 다른 콘텐츠를 제공하므로, 잘못된 국가에서 어느 시장의 데이터를 수집하면 단순히 잘못된 레코드가 생성됩니다. 데이터셋이 사람이나 시장에 관한 결정을 이끈다면, 올바른 관점에서 수집하는 것은 기술적 선호만큼이나 데이터 품질 의무입니다. 이것이 컴플라이언스 맥락에서 레지덴셜 프록시를 사용해야 하는 정당한 이유입니다. 은폐가 아니라 정확성 때문입니다.

자주 묻는 질문

레지덴셜 프록시를 사용하면 제 스크래핑이 GDPR을 준수하게 되나요? 아니요. 프록시는 요청이 나오는 IP를 바꿀 뿐, 그 이상은 아닙니다. 컨트롤러로서의 의무, 합법적 근거, 투명성, 최소화, 보관, 정보주체 권리는 어느 경우든 동일합니다. 컴플라이언스는 네트워크 경로가 아니라 무엇을 왜 수집하는지에 의해 결정됩니다.

IP 주소는 GDPR 하에서 개인정보인가요? 대개 그렇습니다. CJEU의 Breyer 판결은 보유자가 개인을 식별하는 데 합리적으로 사용될 가능성이 있는 수단을 가지고 있는 경우 동적 IP 주소가 개인정보가 될 수 있다고 판시했습니다. 달리 결론지을 신중한 근거가 없는 한 IP를 개인정보로 취급하십시오.

프록시 제공업체와 DPA가 필요한가요? 제공업체가 귀사를 대신하여 개인정보를 처리한다면, 제28조는 서면 계약을 요구합니다. 그것이 해당되는지 여부는 계약 방식에 따라 달라지므로, 가정하지 말고 역할을 명시적으로 확립하고 제공업체에 문서를 요청하십시오.

“데이터가 공개적으로 이용 가능했다”는 것이 합법적 근거인가요? 아니요. 공개 가용성은 제6조의 근거 중 하나가 아닙니다. 여전히 합법적 근거, 보통은 문서화된 형량 테스트를 동반한 정당한 이익이 필요하며, 공개 가용성은 그 평가에서 하나의 요소일 뿐 대체물이 아닙니다.

GDPR 문제를 완전히 피할 수 있나요? 종종 가능합니다. 개인정보를 수집하지 않으면 됩니다. 가격, 가용성, 카탈로그 데이터는 보통 개인 필드 없이도 사업 목적을 충족합니다. 프로젝트에서 개인정보를 범위 밖으로 정하는 것이 이용 가능한 가장 깔끔한 컴플라이언스 입장입니다.

결론

레지덴셜 프록시가 제기하는 GDPR 질문들은 팀들이 두려워하는 것보다 좁고, 기대하는 것보다 구체적입니다. 프록시는 아무것도 익명화하지 않으며 귀사의 의무를 줄이지도 않으므로, 컴플라이언스 입장의 실체는 어떤 개인정보를 수집하는지, 합법적 근거가 무엇인지, 그리고 투명성, 최소화, 보관 관행에 달려 있습니다. 프록시 계층이 추가하는 것은 구체적인 짧은 목록입니다. IP 주소는 개인정보일 가능성이 높다는 것, 제공업체와의 역할을 서면으로 확립해야 한다는 것, 국경 간 흐름을 매핑해야 한다는 것, 그리고 제공업체의 IP 소싱이 진정한 실사를 받을 가치가 있다는 것입니다.

이 목록을 검토하고, 사업 목적이 허용하는 한 개인정보를 범위 밖으로 정하고, 그 근거를 문서화하십시오. 저희를 이러한 질문들에 대해 평가하고 계시다면, 저희 개인정보 보호정책이용약관이 출발점이며, 저희 팀은 귀사의 구체적인 사용 사례에 대한 역할과 문서화에 관해 논의할 수 있습니다. 그리고 위의 어떤 것도 법률 자문이 아니므로, 이에 의존하기 전에 결론을 자격을 갖춘 법률 자문가에게 확인받으시기 바랍니다.

시작할 준비가 되셨나요?

205M개 이상의 IP, 195개 이상의 국가를 지원하는 Shifter의 레지덴셜 프록시를 $0.75/GB부터 이용해보세요.

시작하기