쿠키 옵트인 구현 예시.

무엇이 어려운가.

이용자 행동 측정이나 라이브 채팅, 외부 업체의 문의 양식 같은 외부 구성요소를 켜서 쓰기 전에는 이용자의 동의가 필요합니다. 왜일까요. 외부 업체의 서버에 연결되는 그 순간, 실제 이용이 시작되지 않았더라도 개인에 관한 정보가 이미 전송되기 때문입니다. 가장 단순한 예가 IP 주소이고, 이것이 외부 업체의 서버로 전달됩니다.

가능한 해법.

외부 업체의 서버로 요청이 나가기 전에 동의를 받아야 합니다. 그것도 방문자나 이용자가 스스로 하는 동의여야 합니다. 그 동의는 언제든 철회할 수 있어야 합니다. 즉, 현재 상태를 저장해 두어야 한다는 뜻입니다. 이를 위해서는 이루어진 옵트인을 데이터베이스에 저장하고 고유한 ID와 묶어 두는 방식이 적절합니다. 웹사이트를 방문하면 어차피 ID가 만들어지므로 (예: PHP 세션 ID), 이 예시에서는 바로 그것을 사용합니다.

이용에 앞서 먼저 개인정보의 저장과 처리에 대한 동의를 구합니다. 그 전에는 옵트아웃 방식이 자리 잡고 있었고, 흔히 „쿠키 고지“라고 불렸습니다. 쿠키를 쓴다는 사실과 해제 방법을 알리는 것만으로 충분했죠. 그것도 대개는 개인정보 처리방침 안쪽에 숨어 있었습니다. 그 결과 이제는 옵트인이 필요합니다. 옵트인이 없으면 개인정보를 수집하고 저장할 수 없습니다.

„필수“와 „선택“ — 두 영역.

애플리케이션을 돌리는 데 반드시 필요한 장치와, 나중에 분석하기 위해 개인정보를 의도적으로 모으는 기능은 구분해야 합니다. 여기서 보여드리는 입력 화면에서는 이 둘을 단순하게 „필수“와 „선택“으로 나눴습니다. 필수 기능은 끌 수 없습니다. 그것이 없으면 애플리케이션을 쓸 수 없기 때문입니다. 예를 들어 여기서 정한 설정 자체도 „필요한“ 쿠키로 저장됩니다.

선택 기능은 사용성을 높이거나 애플리케이션의 방향을 이용자에게 맞추는 데 쓰입니다. 그러려면 이용 행태나 이용 강도 같은 행동 데이터가 유용합니다. 그 과정에서 광고가 노출되지는 않으며, 이름이나 생일 같은 개인적인 내용도 다루지 않습니다. 필요한 데이터를 가명 처리하거나 익명 처리하면 내용을 이용자에 맞출 수도 있습니다. 처리 지점에서 그 사람과 연결 지을 수 없는 ID를 쓰는 방식입니다.

이 데이터를 처리하려면 이용자의 동의가 필요합니다. 이 예시는 애플리케이션의 내용을 개선하기 위한 데이터 수집을 다룹니다. 데이터는 익명으로도 수집되며, IP 주소는 가려집니다 (192.168.0.100 은 192.168.XXX.XXX 가 됩니다).

이용자가 체크를 하고 „현재 설정 사용“을 누른 뒤에야 해당 JavaScript가 불러와지고 외부 업체와의 연결이 만들어집니다. 이른바 온프레미스 방식은 GDPR 아래에서의 구현을 한결 쉽게 해 줍니다. 예를 들어 행동 측정 도구 Matomo는 자체 서버에 설치해 운영할 수도 있습니다.

모든 것이 운영자의 손안에.

여기서 보여드린 입력 화면은 자체 JavaScript와 CSS 호출로 불러옵니다. 프로그램 전체를 자체 서버에 두고 운영할 수 있으므로, 옵트인 대화상자를 위해 외부 업체를 쓸 필요가 없습니다. 옵트인 내용은 JavaScript 호출을 통해 데이터베이스에 저장되고, 그 데이터베이스도 자체 서버에서 돌아갑니다. 그래서 수집된 데이터는 모두 운영자의 손안에 남습니다 — 그리고 그 데이터에 대한 책임도 언제나 운영자에게 있습니다.

이해해 두어야 할 점은, 외부 업체의 모든 기능에 대해 이상적으로는 옵트인이 있어야 한다는 것입니다. 삽입한 영상이나 문의 양식, 그 밖의 외부 콘텐츠에서도 경우에 따라 개인정보가 전송됩니다. 그것은 이용자의 동의가 있을 때만 허용됩니다. 옵트인이 없다면 해당 콘텐츠는 불러오지 않아야 합니다.