글: Miloš Duraković

웹사이트 GDPR: 만드는 팀을 위한 실무 가이드

laptop screen showing encrypted data and a padlock

GDPR은 2018년 5월 25일부터 적용되고 있습니다. 8년이 지난 지금 대부분의 회사는 자신이 준수하고 있다고 믿고, 우리가 살펴본 대부분의 웹사이트는 준수하지 않습니다.

이건 보통 무관심 때문이 아닙니다. GDPR 작업이 문서 형태로 한 번만 이뤄졌고, 그 뒤로 시스템이 그 옆을 지나쳐 계속 움직였기 때문입니다. 새 분석 도구, 새 CRM, 새 챗봇, 새 마케팅 자동화. 각각이 처리 기록이 결코 담지 못한 처리를 더했습니다.

이 가이드는 만드는 팀으로서 당신이 실제로 소유한 쪽에 초점을 맞춥니다. 데이터 모델, 연동, 권리 요청, 그리고 코드 안에서 실제로 일어나는 일. 법률 자문이 아니며, 변호사에게 속하는 해석 문제에서는 의도적으로 거리를 둡니다.

짧은 기초부터

규정 (EU) 2016/679은 개인정보의 처리를 다룹니다. 개인정보란 식별되었거나 식별 가능한 자연인과 관련된 모든 정보이고, "식별 가능"은 대부분의 팀이 가정하는 것보다 넓은 개념입니다. IP 주소, 쿠키 식별자, 기기 식별자, 해시된 이메일, 사용자 계정 ID 모두 포함됩니다.

EU에 사업장이 있다면 이 규정이 적용되고, 없더라도 EU 내 사람들에게 상품이나 서비스를 제공하거나 그들의 행동을 모니터링한다면 적용됩니다.

컨트롤러는 처리의 목적과 수단을 결정합니다. 프로세서는 컨트롤러를 대신해 처리합니다. 대부분의 웹사이트 소유자는 컨트롤러이고 대부분의 SaaS 공급업체는 프로세서이지만, 공급업체가 독립 컨트롤러가 되는 경우도 있고 그러면 필요한 계약이 달라집니다.

여섯 가지 처리 근거, 그리고 오용되는 것

모든 처리 활동에는 제6조의 근거 하나가 필요합니다.

  1. 동의. 자유롭게 주어지고, 특정되고, 정보에 기반하며, 명확한 것. 준 것만큼 쉽게 철회할 수 있어야 합니다.
  2. 계약. 정보주체와의 계약 이행에 필요한 경우.
  3. 법적 의무. 법이 요구하는 경우.
  4. 중대한 이익. 웹사이트 맥락에서는 드뭅니다.
  5. 공익. 주로 공공 부문.
  6. 정당한 이익. 정보주체의 권리에 우선하지 않는, 당신 또는 제3자의 이익.

실무에서 오용되는 것은 정당한 이익입니다. 실재하는 근거이지만, 그것을 성립시키는 균형 평가 없이 원용되는 일이 잦습니다. 쓸 생각이라면 이익을 특정하고, 필요성을 평가하고, 정보주체의 권리를 형량한 문서화된 평가가 필요합니다. 한 페이지면 충분합니다. 아무것도 없으면 부족합니다.

추측해서는 안 되는 지점이 하나 있습니다. 사용자 기기의 데이터에 접근하거나 저장하는 것은 GDPR만이 아니라 e프라이버시 지침의 범위에 들어갑니다. 그래서 데이터 자체에 어떤 처리 근거를 원용하든, 필수적이지 않은 쿠키에는 동의가 필요합니다.

웹사이트가 실제로 실패하는 지점

8년간의 수리 끝에도 같은 목록이 반복됩니다.

동의 전에 스크립트가 로드된다

고전입니다. 동의 배너는 렌더링됐는데 Google Analytics, Meta 픽셀, 채팅 위젯은 이미 <head>에서 로드됐습니다. 사용자는 아무것도 누르지 않았는데 제3자 셋이 이미 그의 IP를 받았습니다.

이건 플랫폼 문제가 아니라 코드 문제입니다. 동의 플랫폼은 자기가 아는 스크립트를 막을 수 있지만, 당신이 직접 넣은 script 태그는 조건을 걸지 않으면 어차피 로드됩니다. 진짜 수정은 조건부 로딩입니다. 동의 상태를 알기 전에는 스크립트를 주입하지 않는 것.

감독기관이 하듯 테스트하세요. 깨끗한 프로필로 브라우저를 열고, 네트워크 탭을 열고, 페이지를 로드하고, 배너를 건드리지 말고, 무엇이 나가는지 보세요. 그게 감사입니다.

동의 배너가 무효다

요건은 굳어졌고, 대부분의 배너는 적어도 하나를 위반합니다.

  • 거부는 수락만큼 쉬워야 합니다. 같은 층위의 버튼으로, 메뉴 안에 숨기지 않고.
  • 미리 체크된 상자는 동의가 아닙니다.
  • "계속 탐색하면 동의한 것으로 봅니다"는 동의가 아닙니다.
  • 동의는 목적별로 분리 가능해야 합니다. 하나의 포괄 스위치로는 안 됩니다.
  • 철회는 부여만큼 쉬워야 하며, 설정을 다시 열 수 있는 상시 링크가 필요합니다.
  • 동의 증거를 보관해야 합니다. 무엇에, 언제, 어떤 버전의 배너로 동의했는지.

마지막 항목이 가장 많이 잊힙니다. 동의 로그가 없으면 "사용자가 동의했다"는 주장은 증명할 수 없습니다.

규칙은 바뀌는 중입니다. 디지털 옴니버스가 제안한 제88a조와 제88b조는 이 규칙들을 GDPR로 옮기고, 거부 후 6개월의 침묵 기간을 더하고, 기계가 읽을 수 있는 신호에 법적 구속력을 부여합니다. 아직 협의 중이며 현재 상황은 디지털 옴니버스 이후의 쿠키 동의에서 다룹니다.

정보주체 요청을 이행할 수 없다

사용자가 자기 데이터 사본을 요청합니다. 전부가 필요하고, 전부란 모든 시스템을 의미합니다. 운영 데이터베이스, 분석, CRM, 헬프데스크, 이메일 플랫폼, 파일 저장소, 로그, 백업, 데이터 웨어하우스.

대부분의 조직은 운영 데이터베이스에서 답하고 나머지는 짐작합니다. 그건 컴플라이언스가 아니라 운입니다.

기한은 요청 접수로부터 1개월이고, 복잡한 경우 2개월 연장할 수 있지만 첫 달 안에 연장을 알려야 합니다.

구현해야 하는 권리는 이렇습니다.

  • 열람권. 데이터 사본과 처리에 관한 정보.
  • 정정권. 부정확한 데이터의 수정.
  • 삭제권. 요건이 충족될 때의 삭제.
  • 처리 제한권. 데이터를 보관하되 처리는 중단.
  • 이동권. 구조화되고 일반적으로 사용되며 기계가 읽을 수 있는 형식으로, 기술적으로 가능하면 다른 컨트롤러로 직접 전송.
  • 반대권. 특히 직접 마케팅에 대해서는 중단이 무조건적입니다.
  • 오로지 자동화된 결정의 대상이 되지 않을 권리(법적 효과나 유사한 중대한 영향을 미치는 경우).

이를 위해 만드는 이동권 API는 데이터법이 제품 데이터에 대해 요구하는 것과 상당 부분 동일한 인프라입니다. 한 번 만들 가치가 있습니다.

보유 기간이 사실상 영구다

GDPR은 개인정보를 수집 목적에 필요한 기간만 보관하도록 요구합니다. 실무에서는 삭제를 만든 사람이 없어서 대부분의 시스템이 모든 것을 영원히 보관합니다.

작동하는 접근은 보유를 정책 문서가 아니라 데이터 모델의 속성으로 만드는 것입니다. 개인정보를 담은 모든 테이블에 보유 규칙을 주고, 규칙마다 예약 작업을 주고, 작업은 무엇을 지웠는지 기록합니다. 그게 없으면 "이걸 얼마나 보관하시나요"라는 감독기관의 질문에 대한 답은 "누군가 기억할 때까지"가 되고, 그건 답이 아닙니다.

백업은 계속되는 질문입니다. 복원된 데이터가 다시 처리되지 않도록 보장하고 백업 순환과 함께 사라지게 하는 문서화된 절차가 있다면, 백업이 표적 삭제를 지원할 필요는 없다는 것이 널리 받아들여지는 입장입니다. 그 입장은 필요해지기 전에 적어둬야 합니다.

국제 이전이 피상적으로 다뤄진다

데이터가 EU 밖으로 나간다면 이전 메커니즘이 필요합니다. 적정성 결정, 표준계약조항, 또는 구속력 있는 기업 규칙. 표준계약조항을 쓴다면 이전 영향 평가도 필요합니다.

실무의 난점은 목록화입니다. 대부분의 팀은 큰 공급업체는 알고 작은 것들을 놓칩니다. 폰트 호스팅, CDN, 오류 추적, 이메일 발송, 지원 위젯, A/B 테스트 플랫폼. 공급업체가 EU 밖에서 처리한다면 각각이 이전입니다.

계속 옳은 상태로 만드는 방법

컴플라이언스를 유지하는 사이트와 어긋나는 사이트의 차이는 구조적입니다.

처리 활동 기록을 살아 있는 산출물로 만드세요. 제30조 요건이고, 대부분의 곳에서는 기한이 지난 스프레드시트입니다. 코드 가까이에 두고, 새 연동이 추가될 때마다 검토하고, 공급업체 도입 절차의 일부로 만드세요.

개인정보를 집중시키세요. 개인정보가 흩어진 시스템이 많을수록 권리 요청 하나하나가 비싸집니다. 참조를 가진 정규 인물 엔티티 하나, 사본이 아니라.

요청 처리를 한 번, 제대로 만드세요. 모든 시스템에 질의하고, 결과를 모으고, 무엇을 했는지 기록하는 하나의 워크플로. 수작업이면 느리고 일관성이 없고, 가장 중요한 순간에 기한을 놓칩니다.

동의 상태를 일급 개념으로 만드세요. 애플리케이션은 동의 상태를 프로그램으로 조회하고 서버 측에서 그에 따라 판단할 수 있어야 합니다. 브라우저에서 스크립트가 로드되는지 여부만이 아니라요.

결정은 내리는 순간에 기록하세요. 왜 정당한 이익을 골랐는지, 왜 보유가 24개월인지, 왜 이 공급업체가 컨트롤러가 아니라 프로세서인지에 대한 짧은 메모. 이 기록들이 바로 감독기관이 요구하는 것이고, 1년 뒤에 재구성하기는 거의 불가능합니다.

유출

개인정보 유출을 인지한 때로부터 72시간 내에 감독기관에 통지해야 합니다. 위험을 초래할 가능성이 낮은 경우는 제외됩니다. 고위험 유출에는 부당한 지체 없이 정보주체에게도 통지해야 합니다.

조직이 NIS2나 사이버 복원력법 의무도 진다면, 문턱이 다른 여러 기관에 대해 시계가 나란히 돌아갑니다. 함께 설계하세요. 둘 다 여기서 썼습니다. NIS2 가이드사이버 복원력법 가이드입니다.

과징금, 그리고 실제로 방아쇠를 당기는 것

상한은 가장 중대한 위반에 대해 2천만 유로 또는 전 세계 연간 매출액의 4% 중 높은 쪽이고, 다른 위반에는 1천만 유로 또는 2%입니다.

실무에서 집행의 방아쇠는 예측 가능합니다. 답변을 받지 못한 정보주체의 민원, 감독기관이 업종별로 벌이는 쿠키 배너 일제 점검, 더 넓은 감사로 이어지는 신고된 유출, 그리고 경쟁사가 신고하는 애드테크 관련 사이트.

패턴은 이렇습니다. 작은 일이 문을 열고, 감사가 전부를 덮습니다.

현실적인 시작 순서

불확실한 지점에서 시작한다면 이 순서가 가장 빨리 성과를 냅니다.

  1. 동의 전에 무엇이 로드되는지 확인하세요. 한 시간이면 되고, 가장 흔한 발견입니다.
  2. 시스템별로 개인정보를 목록화하세요. 완벽하지 않아도 정직하게. 대부분의 조직은 아무도 목록에 넣지 않았던 시스템을 발견합니다.
  3. 정보주체 요청을 직접 해보세요. 자기 데이터를 요청하고, 얼마나 걸리고 무엇이 빠지는지 보세요.
  4. 공급업체 목록을 이전과 계약 관점에서 검토하세요. 개인정보에 닿는 모든 공급업체에는 데이터 처리 계약이 필요합니다.
  5. 데이터가 가장 빨리 자라는 곳에 보유 기간을 설정하세요. 로그, 분석, 지원 티켓.

몇 주 작업이지 분기 작업이 아니며, 짐작에서 파악으로 옮겨줍니다.

우리가 들어가는 지점

우리는 유럽에서 사업하는 회사들을 위해 소프트웨어를 만들고 유지보수하며, 이건 우리가 일상적으로 하는 작업입니다. 서버 측에서도 성립하는 동의 아키텍처, 모든 시스템을 아우르는 정보주체 요청 워크플로, 보유 자동화, 그리고 도입 절차에 연결돼 있어서 계속 맞는 상태로 남는 데이터 지도.

우리는 로펌이 아니고 법률 자문도 하지 않습니다. 당신의 변호사가 정한 입장을 작동하는 시스템으로 바꾸는 것이 우리 일입니다.

웹사이트나 제품에 이런 작업이 필요하다면 office@c9group.dev 로 연락 주세요. 더 넓은 규제 지형은 2026년 EU 디지털 규제 가이드에, 유럽에서의 작업은 EU 시장 진입 페이지에 있습니다.