비식별 처리

분석용 테이블에는 오랫동안 이름과 이메일, 전화번호가 그대로 들어 있었습니다. 가입 기록을 복사해 쌓았으니 당연한 결과였습니다. 문제는 그 표를 열어야 일이 되는 사람이 회사 안에 꽤 많다는 점이었습니다. 이탈률 하나를 보려던 사람이 고객 3만 명의 연락처를 같이 보게 되는 구조였습니다.

어느 칸이 개인 식별 정보인지 표시하고 열람 권한을 좁히는 데까지는 많은 팀이 도달했습니다. 하지만 거기서 막힙니다. 권한을 좁히면 분석이 멈추고, 분석을 돌리려면 다시 열어야 하니까요.

실제로는 이런 장면으로 나타났습니다. 마케터가 "지난달 해지한 사람들 목록 좀 주세요" 하고 요청하면 개발자가 조회 결과를 CSV 로 내려받아 메신저로 보냅니다. 파일에는 이름과 이메일이 그대로 들어 있고, 분석이 끝난 뒤에도 누군가의 노트북에 남습니다. 한 달 뒤에는 그런 파일이 몇 개이고 어디에 있는지 아무도 모릅니다.

비식별 처리는 여기서 질문을 바꿉니다. 이탈 분석에 정말 필요한 것은 해지한 사람이 누구인지가 아니라 어떤 조건의 계정이 몇 개나 해지했는지입니다. 분석에 쓰는 정보와 사람을 가리키는 정보가 같지 않다는 관찰이 출발점입니다.

표의 칸을 하나씩 보며 사람을 가리키는 칸을 추려 내는 것으로 시작합니다. 다섯 단계입니다.

1. 식별자를 목록으로 만듭니다. 이름·이메일·전화번호·계정 ID 처럼 그 자체로 한 사람을 가리키는 칸이 직접 식별자입니다. 생년월일·성별·우편번호처럼 혼자서는 수천 명이 겹치는 칸은 준식별자라고 부르는데, 이쪽이 더 자주 빠집니다. 셋만 모여도 한 사람으로 좁혀지는 경우가 드물지 않습니다.
2. 칸마다 남길 정도를 정합니다. 필요한 것이 연령대라면 생년월일은 출생 연도까지만, 지역별 비교가 목적이라면 상세 주소 대신 시·도까지만 남기고 나머지는 버립니다.
3. 칸별로 방법을 고릅니다. 통째로 지우는 삭제, 앞뒤 일부만 남기는 마스킹(010-****-1234), 값을 범위로 묶는 일반화(34세를 30대로), 되돌릴 수 없는 값으로 바꾸는 해싱이 흔히 쓰입니다.
4. 같은 사람을 이어 세야 하는지 정합니다. "한 사람이 몇 번 결제했는가" 를 보려면 누구인지는 몰라도 같은 사람인지는 알아야 합니다. 이때는 계정 ID 를 임의의 값으로 바꾸고 대응표를 따로 보관합니다. 대응표가 남아 있으니 이 상태는 익명이 아니라 가명이고, 법적으로도 개인정보로 다룹니다.
5. 다시 식별되는지 확인합니다. 남긴 칸들의 조합마다 몇 명이 속하는지 세어 보고 한두 명뿐인 조합이 나오면 그 칸을 더 뭉갭니다. 1995년생·여성·강남구·프로 요금제에 두 명이 걸린다면 지역을 서울시까지 올립니다.

마지막으로 이 절차를 파이프라인에 고정합니다. 요청받을 때마다 손으로 칸을 지우면 기준이 매번 달라지고 급한 날에는 한 칸이 빠집니다. 처리된 표를 따로 만들어 분석 도구는 그 표만 보게 하고, 원본 표의 열람 권한은 회수합니다. 어느 칸을 어디까지 뭉갤지는 데이터 거버넌스에서 정해 둔 규칙을 따릅니다.

집계를 내는 일에는 대체로 잘 맞습니다. 요금제별 해지율이나 기능별 사용 빈도처럼 사람을 묶어서 세는 작업은 누구인지 몰라도 답이 나옵니다. 외부에 넘기는 데이터, 영업 데모용 샘플, 개발자가 쓰는 테스트 데이터베이스, 오래 보관하는 기록도 여기 해당합니다.

반대로 개인을 되찾아야 하는 일에는 쓸 수 없습니다. 고객 문의에 답하려면 그 사람의 이용 기록을 봐야 하고, 개인화 추천이나 메일 발송도 받는 사람이 누구인지 알아야 합니다. 이런 흐름은 비식별 대상이 아니라 접근 권한과 암호화로 다룹니다. 암호화는 키가 있으면 원문이 그대로 돌아오는 방식이라 목적이 다릅니다.

한계는 두 가지입니다. 하나는 정보를 잃는다는 점입니다. 생년월일을 연 단위로 뭉개면 월별 생일 캠페인은 영영 못 돌립니다. 나중에 필요해져도 되돌릴 방법이 없습니다.

다른 하나는 되돌아올 수 있다는 점입니다. 해싱은 한 방향 계산이지만, 전화번호처럼 가능한 값이 한정된 칸은 모든 후보를 해싱해 대조하면 원래 값이 나옵니다. 그래서 해싱한 전화번호는 익명이 아닙니다. 이 구분이 문제가 되는 이유는 가명 상태의 데이터에 삭제 요구권 같은 정보주체의 권리가 그대로 적용되기 때문입니다. 완전히 익명이 된 데이터는 지울 대상 자체가 없어 그 요구의 범위 밖입니다.

"분석 계정은 비식별 테이블만 보게 돼 있어요. 원본은 권한 따로 신청하셔야 해요."

일상 분석과 개인정보 열람을 아예 다른 경로로 갈라 뒀다는 뜻입니다.

"이거 해싱만 해 둔 거라 비식별했다고 하기 어려워요."

되돌릴 수 있는 상태라 개인정보 취급을 계속해야 한다는 지적입니다.

"데모용 샘플은 비식별 처리해서 내보내 주세요."

고객 실데이터를 회사 밖으로 내보내기 전에 가공하라는 요청입니다.

페이지덱에서는 그로스 마케터 현우가 이탈 원인을 보려고 지난 6개월 해지 계정 목록을 요청하면서 시작됐습니다. 태오가 이름과 이메일을 뺀 표를 만들고 가입일을 주 단위로 뭉개 넘겼습니다. 지현이 요금제와 지역 조합으로 세어 보니 세 명짜리 묶음이 나와서 지역 칸을 구에서 시·도로 올렸습니다.

규원이 투자자 미팅 화면에도 같은 표를 쓰자고 했을 때 태오가 바로 그러자고 답할 수 있었던 것이 이 작업의 결과입니다. 절차가 파이프라인에 들어 있으니 매번 누가 무엇을 지웠는지 확인하지 않아도 됩니다.

이름과 이메일만 지우면 끝났다고 보는 경우가 가장 많습니다. 사람을 가리키는 것이 이름이라고 배웠으니 자연스러운 생각입니다. 하지만 남은 칸의 조합이 이름을 대신합니다. 가입일과 요금제와 지역과 기기 종류를 겹치면 계정 하나로 좁혀지는 일이 흔합니다. 이 상태를 개인정보가 아니라 믿고 외부에 넘기면 유출됐을 때 그대로 개인정보 유출이 됩니다.

해싱하면 익명이 된다는 오해도 뿌리가 같습니다. 되돌릴 수 없는 계산이라고 들었기 때문입니다. 실제로는 계산이 한 방향인 것과 원래 값을 알아낼 수 없는 것이 다릅니다. 휴대폰 번호는 만들 수 있는 값이 정해져 있어 전부 계산해 두면 대조표가 만들어집니다. 이 차이를 놓치면 가명정보를 익명정보로 취급하게 되고, 삭제 요구를 받고도 지울 것이 없다고 답했다가 뒤늦게 뒤집힙니다.