동의

가입 화면의 체크박스는 오래 형식이었습니다. 이용약관, 개인정보 수집, 광고 수신을 한 덩어리로 묶어 전체 동의 하나로 받고, 다음 버튼을 누르면 끝이었습니다. 화면을 만든 쪽도 읽히리라 기대하지 않았고 누르는 쪽도 읽지 않았습니다.

그 형식이 문제가 되는 자리는 늘 나중이었습니다. 가입한 지 반년쯤 지나 광고 문자를 받은 사용자가 어디서 번호를 얻었냐고 물으면, 가입할 때 동의하셨다는 답이 돌아옵니다. 기록상 체크는 되어 있으니 회사는 틀린 말을 한 게 아니고, 사용자는 그런 걸 허락한 기억이 없으니 속았다고 느낍니다. 체크는 있는데 허락은 없는 상태입니다.

그래서 동의는 체크 상태가 아니라 조건을 갖춘 허락으로 다시 정의됐습니다. 정보를 다룰 자격을 세우는 방법에는 허락을 받아 두는 쪽과, 허락 없이도 인정받는 쪽인 정당한 이익이 있습니다. 동의는 앞쪽이고, 갖춰야 할 조건이 붙는 대신 가장 넓게 쓰입니다.

받기 전에 알리고, 항목을 갈라 하나씩 고르게 하고, 고른 결과를 기록으로 남기는 순서로 작동합니다.

동의로 인정받으려면 네 가지가 함께 갖춰져야 합니다.

1. 알린 뒤에 받습니다. 수집 항목, 쓰는 목적, 보관 기간을 동의를 받는 그 화면에서 읽을 수 있어야 합니다. 링크만 걸어 두고 내용은 다른 페이지에 있으면 알렸다고 보기 어렵습니다.
2. 갈라서 받습니다. 서비스에 꼭 필요한 항목과 그렇지 않은 항목을 나눠 따로 묻습니다. 문서 협업 도구라면 이메일은 앞쪽이고 직무와 회사 규모는 뒤쪽입니다.
3. 거절해도 서비스를 쓸 수 있어야 합니다. 광고 수신에 체크하지 않으면 가입 버튼이 눌리지 않는 화면은 자유롭게 준 허락이 아니므로, 받아 두어도 근거로 서지 못합니다.
4. 기록을 남깁니다. 누가 언제 어느 문구에 동의했는지를 남겨 둡니다. 문구를 고쳐 목적이 늘어나면 예전 동의가 새 목적까지 덮지는 않습니다.

기본값도 조건에 걸립니다. 미리 체크해 둔 상자는 동의로 보지 않습니다. 아무것도 하지 않은 사람과 허락한 사람이 같은 상태로 기록되어 둘을 구분할 수 없기 때문입니다.

거두는 쪽도 같은 무게로 만들어 둡니다. 두 번 눌러 줄 수 있었던 동의를 거두려면 고객센터에 메일을 보내야 한다면 대칭이 깨진 것이고, 이때는 준 동의의 유효성까지 함께 의심받습니다. 받을 항목을 애초에 줄이는 최소 수집이 동의 화면을 줄이는 가장 빠른 길인 이유가 여기 있습니다.

개인정보를 처음 받는 화면과, 이미 받아 둔 정보를 새 목적에 쓰려는 순간 두 자리에 붙습니다. 실무에서 걸리는 지점은 다섯입니다.

1. 가입 화면 — 필수 항목과 선택 항목을 갈라 따로 받습니다. 여기서 갈라 두지 않으면 뒤의 모든 처리가 같은 근거 하나에 매달립니다.
2. 광고와 마케팅 발송 — 광고성 정보를 보내기 전에 받는 광고 수신 동의가 따로 필요합니다. 문자, 메일, 앱 푸시가 각각이라 한 곳에서 받았다고 다른 곳까지 되지 않습니다.
3. 웹 추적 — 분석이나 광고 목적의 쿠키를 심기 전에 쿠키 동의를 받습니다. 서비스가 도는 데 꼭 필요한 쿠키는 이 대상에서 빠집니다.
4. 앱의 기기 추적 — 앱이 추적 전에 허락을 받게 한 애플의 정책인 앱 추적 투명성 팝업이 따로 뜹니다.
5. 도구를 새로 붙일 때 — 분석 도구 하나를 추가하면 목적이 하나 늘어난 것입니다. 개인정보처리방침의 문장과 동의 문구를 같이 고쳐야 하는데, 코드만 올리고 문서는 그대로 두는 일이 가장 자주 생깁니다.

반대로 동의를 쓰지 않는 자리도 알아 두어야 합니다. 필요한 처리를 전부 동의로 받으려 하면 가입 화면이 체크박스 밭이 되고, 하나만 거절해도 서비스가 멈춥니다. 결제를 위해 카드 정보를 다루는 것처럼 계약을 이행하는 데 필요한 처리는 따로 허락을 받지 않아도 되는 쪽이 맞습니다. 동의는 자격을 세우는 방법 중 하나이지 모든 처리의 기본값이 아닙니다.

"이 항목 필수인가요? 선택으로 빼면 동의 화면이 하나 줄어요."

받을 항목을 줄여 절차 자체를 없애자는 제안입니다.

"광고 동의 안 하면 가입이 안 되는데, 이건 못 받은 동의로 봅니다."

체크 기록은 남지만 근거로는 서지 못한다는 뜻입니다.

"분석 도구 새로 붙였으면 방침이랑 동의 문구도 같이 나가야 해요."

코드 배포와 문서 갱신을 같은 날로 묶자는 요청입니다.

페이지덱에서 이 말이 회의에 오른 것은 새 분석 도구를 붙이는 스프린트였습니다. 규원이 방침 문서를 같이 고쳐야 한다고 짚자 태오가 이미 가입한 사용자는 어떻게 되냐고 물었습니다. 동의는 목적마다 따로 서는 것이라 예전 동의로는 새 목적을 덮을 수 없다는 답이 나왔고, 기존 사용자에게는 다음 접속 때 한 번 묻고 거절한 계정은 이벤트 전송에서 빼는 스위치를 태오가 만들었습니다.

같은 김에 가입 화면도 손봤습니다. 직무와 회사 규모를 필수에서 선택으로 내리고, 광고 수신 체크는 기본 해제로 바꿨습니다. 가입 완료율은 84퍼센트에서 86퍼센트가 됐고 광고 수신 동의율은 71퍼센트에서 38퍼센트로 떨어졌습니다. 보내는 메일 수는 절반 아래로 줄었는데 열람률은 두 배가 됐습니다.

동의만 받아 두면 그 정보로 무엇이든 할 수 있다고 보는 경우가 가장 많습니다. 허락을 받았다는 사실이 통행증처럼 느껴지니 그렇게 읽기 쉽습니다. 하지만 동의는 알린 목적 안에서만 섭니다. 결제를 위해 받은 연락처를 신규 기능 홍보에 쓰면 동의가 있어도 목적을 벗어난 처리입니다. 이 오해를 두면 팀은 동의 문구를 되도록 넓게 써 두는 쪽으로 움직이는데, 넓고 모호한 문구는 알린 것으로 인정되지 않아 오히려 근거가 통째로 흔들립니다.

동의가 가장 안전한 근거라고 보는 것도 흔합니다. 사용자에게 물어서 받아 둔 것이니 나중에 문제가 생겨도 책임이 옮겨 간 것처럼 느껴집니다. 실제로는 동의가 가장 흔들리는 근거입니다. 준 사람이 언제든 거둘 수 있고, 거두면 그 처리는 그날로 멈춰야 합니다. 서비스가 돌아가는 데 꼭 필요한 처리를 동의 위에 세워 두면 한 사람이 거둘 때마다 그 계정에 기능을 줄 수 없게 되고, 그러다 철회 버튼을 찾기 어려운 자리로 옮기는 선택에 이릅니다.