최소 수집

가입 화면이 길던 시절이 있었습니다. 이름과 이메일만 있으면 되는 서비스가 생년월일과 성별과 주소와 직업까지 받았습니다. 받는 쪽에 물으면 답은 늘 비슷했습니다. 나중에 쓸지도 모르니까, 이왕 한 번 받는 김에.

기획 회의에서 그 말은 아무 저항 없이 통과됐습니다. "성별도 받아 두죠, 나중에 마케팅에서 나눠 볼 수도 있으니까" 라는 제안에 반대할 근거가 없었습니다. 받아서 손해 볼 일이 없어 보였기 때문입니다. 그렇게 3년을 모은 회사의 회원 표에는 한 번도 조회된 적 없는 칸이 여섯 개쯤 남아 있었습니다.

손해는 사고가 나는 날 한꺼번에 드러났습니다. 서버 하나가 뚫리면 이메일만 새어 나갈 수 있었던 일이 생년월일과 주소까지 함께 나가는 일이 됩니다. 쓰지도 않던 항목 때문에 피해자가 받을 2차 피해의 폭이 넓어집니다. 최소 수집은 이 계산을 뒤집어 놓은 원칙입니다. 모아도 되는지를 묻는 대신 이 항목이 없으면 무엇이 안 되는지를 묻고, 답이 없으면 아예 받지 않습니다.

항목 하나하나에 목적을 붙여 보고 목적이 붙지 않는 항목을 지우는 것으로 시작합니다. 순서는 네 단계입니다.

1. 목적을 먼저 적습니다. 회원 식별, 결제, 고객 문의 응대처럼 이 서비스가 개인정보를 쓰는 이유를 문장으로 씁니다. 항목에서 출발해 목적을 갖다 붙이면 무엇이든 그럴듯해지므로 방향을 반대로 잡습니다.
2. 목적마다 필요한 항목을 적습니다. 결제라면 카드 정보와 청구 주소가 붙고, 회원 식별이라면 이메일 하나로 끝납니다.
3. 어느 목적에도 붙지 않은 항목을 뺍니다. 가입 화면뿐 아니라 서버가 남기는 기록과 분석 도구로 보내는 값까지 같이 봅니다. 화면에서만 지우면 뒤쪽에서 계속 쌓입니다.
4. 남긴 항목에 보유 기간을 붙입니다. 얼마나 오래 갖고 있을지도 수집량의 일부라서, 기간을 정하지 않은 항목은 결국 영원히 남습니다.

항목을 통째로 빼기 어려우면 정밀도를 낮추는 방법이 있습니다. 생년월일 대신 연령대를 받고, 정확한 좌표 대신 시와 구까지만 받고, 접속 기록에 남기는 주소를 뒤 자리를 지운 형태로 남깁니다. 연령대별 이용 패턴을 보는 데는 1994년 3월 12일이라는 값이 필요 없고 30대라는 값이면 충분합니다. 같은 분석을 하면서 유출됐을 때 개인을 특정할 힘은 줄여 두는 겁니다.

개인정보를 새로 받거나 밖으로 내보내는 모든 지점에서 걸립니다. 실무에서 자주 걸리는 자리는 다섯입니다.

1. 가입과 결제 화면. 동의 항목을 나눌 때 필수와 선택을 가르는 기준이 곧 최소 수집입니다. 서비스에 없어도 되는 항목을 필수로 두면 동의를 받아도 문제가 됩니다.
2. 분석 이벤트 설계. 어떤 버튼이 눌렸는지 기록하면서 사용자 이메일을 속성에 통째로 넣는 일이 흔합니다. 개인 식별 정보는 개인을 특정할 수 있는 값이고, 이런 값은 분석 도구까지 따라가면 회수하기가 훨씬 어려워집니다.
3. 서버 기록. 오류를 추적하려고 요청 내용을 통째로 남기면 거기에 전화번호와 주소가 섞여 들어갑니다. 남길 항목을 고르는 일이 코드 쪽에서도 필요합니다.
4. 외부에 넘기는 항목. 수탁자에게 일을 맡길 때 넘기는 항목은 그 일에 필요한 것으로 한정합니다. 협력사 보안 점검에서 실제로 무엇을 넘기고 있는지 목록으로 확인합니다.
5. 공개 문서. 개인정보처리방침에는 수집 항목이 그대로 적힙니다. 목적을 댈 수 없는 항목은 여기에 적을 문장이 나오지 않아서, 방침을 쓰다가 항목을 빼게 되는 경우가 많습니다.

"이 항목 목적이 뭐예요? 방침에 그대로 적을 문장으로 한 줄 써 주세요."

목적을 문장으로 쓸 수 없으면 받지 말자는 뜻입니다.

"생년월일 말고 연령대만 받으면 안 되나요?"

분석 목적은 그대로 두고 식별력만 낮추자는 제안입니다.

"이벤트에 이메일 통째로 넣지 말고 계정 번호만 보냅시다."

분석 도구 쪽으로 개인정보가 흘러가는 경로를 끊자는 말입니다.

페이지덱은 기업 고객을 받기 시작하면서 가입 화면을 다시 봤습니다. 규원이 계약 심사를 받다가 수집 항목 목록을 제출해야 했고, 그 자리에서 회사 규모와 직함 칸이 한 번도 쓰인 적 없다는 사실이 드러났습니다. 2년 전 어느 회의에서 세일즈가 참고용으로 받아 두자고 해서 들어간 칸이었습니다.

지현이 두 칸을 지우는 대신 먼저 조회 기록을 확인했습니다. 실제로 그 칸을 읽는 쿼리가 하나도 없다는 것을 확인한 뒤에 화면에서 빼고, 이미 받아 둔 값도 지웠습니다. 현우가 나중에 기업 고객 분석에 직함이 필요하다고 했을 때는 다시 받는 대신 필요한 계정에만 따로 물어보는 쪽으로 정했습니다. 전원에게 받아 두고 일부에만 쓰는 구조를 되돌린 겁니다.

최소 수집을 분석을 막는 규칙으로 읽는 경우가 많습니다. 데이터를 다루는 쪽에서는 나중에 어떤 질문이 올지 모르니 일단 다 쌓아 두는 게 안전해 보이고, 지워 버린 항목은 되살릴 수 없으니 더 그렇습니다. 하지만 이 원칙이 막는 것은 목적 없는 수집이지 목적 있는 수집이 아닙니다. 연령대별 이용 패턴을 보겠다는 목적이 서면 그 항목은 받습니다.

그대로 두면 두 가지가 따라옵니다. 하나는 사고가 났을 때 나가는 항목이 늘어나는 것이고, 다른 하나는 삭제 요구권 요청이 들어왔을 때 어디까지 지워야 하는지 아무도 모르게 되는 것입니다. 목적 없이 받은 항목은 어디로 복사됐는지도 관리되지 않아서, 회원 표 한 줄을 지워도 같은 사람의 값이 분석 도구와 백업본에 남습니다.