📚 지식 노트

개인정보, 민감정보, 식별자와 준식별자

개인정보 보호법은 개인정보를 살아 있는 개인에 관한 정보로서 성명·주민등록번호·영상처럼 개인을 알아볼 수 있는 정보, 그리고 그것만으로는 알아볼 수 없어도 다른 정보와 쉽게 결합하여 알아볼 수 있는 정보라고 정의한다(제2조 제1호). 쉽게 결합할 수 있는지는 다른 정보를 구할 가능성, 알아보는 데 드는 시간·비용·기술을 합리적으로 고려해 정한다. 또 사상·신념, 노동조합·정당의 가입·탈퇴, 정치적 견해, 건강, 성생활 등에 관한 정보는 민감정보로 따로 묶어, 별도 동의나 법령의 근거가 없으면 처리하지 못하게 한다(제23조).

기술 쪽에서는 열을 세 갈래로 본다. 그것만으로 사람을 가리키는 식별자(이름, 전화번호), 혼자서는 여러 사람에게 해당하지만 몇 개를 합치면 한 사람으로 좁혀지는 준식별자(우편번호, 생년월일, 성별), 그리고 보호하려는 대상인 민감 속성(진단, 소득)이다. 이 노트의 거의 모든 기법은 준식별자를 어떻게 다루느냐의 이야기다.

가명화와 익명화

가명처리는 개인정보의 일부를 삭제하거나 일부 또는 전부를 대체해 추가 정보 없이는 특정 개인을 알아볼 수 없게 하는 것이고, 그 결과가 가명정보다(제2조 제1호의2, 제1호 다목). 이름을 일련번호로 바꾸고 대응표를 따로 잠가 두는 것이 전형적인 예다. 가명정보는 여전히 개인정보다. 대응표(추가 정보)와 합치면 되돌아오기 때문이다. 대신 통계 작성, 과학적 연구, 공익적 기록 보존 등을 위해서는 정보 주체의 동의 없이 처리할 수 있고(제28조의2), 처리하는 사람은 특정 개인을 알아보려는 목적으로 쓰면 안 되며, 처리 중에 개인을 알아볼 수 있는 정보가 생기면 즉시 멈추고 회수·파기해야 한다(제28조의5).

익명정보는 시간·비용·기술 등을 합리적으로 고려할 때 다른 정보를 써도 더는 개인을 알아볼 수 없는 정보이고, 법은 이런 정보에 적용되지 않는다(제58조의2). 법은 원칙으로 익명처리로 목적을 이룰 수 있으면 익명으로, 그렇지 않으면 가명으로 처리하라고 정한다(제3조 제7항). GDPR도 구조가 같다. 전문 26은 추가 정보로 사람과 이을 수 있는 가명 처리 정보를 식별 가능한 사람에 관한 정보로 보고, 익명 정보에는 데이터 보호 원칙을 적용하지 않는다고 적는다.

재식별 위험: 준식별자의 결합

이름을 지운 표가 위험한 이유는 다른 표가 있기 때문이다. 같은 준식별자를 가진 공개 명부(선거인 명부, 회원 목록, SNS 프로필)와 이어 붙이면 지운 이름이 돌아온다. Sweeney(2000)는 1990년 미국 인구조사 요약 자료로 계산해, 우편번호 5자리·성별·생년월일 셋만으로 미국 인구의 87%(2억 4,800만 명 중 2억 1,600만 명)가 유일할 가능성이 높다고 보고했다. 그는 k-익명성 논문(2002)에서 이름을 지우고 공개된 매사추세츠의 의료 보험 자료(GIC)를 선거인 명부와 이어 당시 주지사의 의료 기록을 찾아낸 사례도 적었다.

열이 많은 데이터는 더 위험하다. Narayanan과 Shmatikov(2006)는 익명으로 공개된 넷플릭스 영화 평점 기록을 IMDb의 공개 평점과 맞춰 사람을 찾아냈다. 구매 기록, 위치 기록, 검색어처럼 한 사람에게 값이 많이 쌓이는 데이터는 몇 개만 알아도 사실상 지문이 된다. 위치 기록이 특히 그렇다는 것은 GIS와 지도 노트의 개인정보 절에 있다.

k-익명성: 일반화와 억제

k-익명성은 공개하는 표의 모든 행이 준식별자로 보면 적어도 k−1개의 다른 행과 같도록 만드는 기준이다. 그러면 공격자가 누군가의 나이·우편번호·성별을 알아도 후보가 k명 아래로 줄지 않는다. 같은 준식별자를 가진 행의 묶음을 동치류라 하고, 가장 작은 동치류의 크기가 그 표의 k다. 값을 넓은 범주로 바꾸는 일반화(23살 → 20대, 13481 → 134**)와 튀는 행을 아예 빼는 억제로 k를 올린다.

단계마다 대가가 있다. 일반화할수록 분석에 쓸 정밀도가 줄고, 억제한 행은 정보를 통째로 잃는다. 드문 집단(고령, 희귀 질환)이 가장 먼저 억제되므로, 바로 그 집단을 연구하려는 분석이 망가지기 쉽다. 그래서 실무에서는 k 하나만이 아니라 어떤 열을 얼마나 일반화했는지, 몇 행을 억제했는지를 함께 기록한다.

l-다양성과 t-근접성

k-익명성은 "어느 행인지"는 숨기지만 "무엇인지"는 숨기지 못할 수 있다. 묶음 안의 민감 값이 모두 같으면 묶음만 알아도 값이 드러난다(동질성 공격). 공격자가 배경지식으로 몇 값을 지울 수 있을 때도 마찬가지다. l-다양성은 동치류마다 민감 값이 적어도 l가지(가장 단순한 '구별되는' 정의 기준)이도록 요구한다. 아래 두 표는 둘 다 k = 2이지만, 표 B는 40대 여성 묶음의 진단이 모두 고혈압이라 l = 1이다.

다양하기만 해도 부족할 수 있다. 전체 환자의 1%만 앓는 병이 어떤 묶음에서는 절반이라면, 그 묶음에 속한다는 사실만으로 위험이 크게 오른다. t-근접성은 묶음 안 민감 값의 분포가 전체 분포와 거리 t 이상 다르지 않게 한다. 기준이 강해질수록 표는 더 뭉개진다. 이 계열의 기법은 모두 "공격자가 무엇을 아는가"를 가정해야 하는데, 그 가정이 틀리면 보장도 사라진다는 한계가 있다. 다음 절의 차분 프라이버시는 이 가정을 없애는 쪽으로 나아갔다.

차분 프라이버시

차분 프라이버시(differential privacy)는 데이터가 아니라 질의에 답하는 방법에 거는 약속이다. 한 사람의 기록이 있든 없든(이웃한 두 데이터베이스) 어떤 답이 나올 확률이 최대 e^ε배까지만 달라지게 한다. 그러면 답을 본 사람은 그 한 사람이 데이터에 있었는지 거의 알 수 없다. ε = 1이면 그 비율이 2.72배, ε = 0.1이면 1.11배다. 공격자의 배경지식을 가정하지 않는다는 것이 앞 절의 기법과 다른 점이다.

가장 기본인 라플라스 메커니즘은 참값에 척도 b = Δf/ε인 라플라스 분포의 노이즈를 더한다. Δf(민감도)는 한 사람이 답을 바꿀 수 있는 최대 크기로, "몇 명인가" 같은 개수 질의는 1이다. ε = 0.1이면 b = 10이고, 노이즈는 95% 확률로 ±30.0 안에 든다. 수천 명 단위의 개수라면 충분히 쓸 만하지만 몇 명짜리 칸이라면 노이즈가 값을 덮는다. 차분 프라이버시가 큰 집계에 잘 맞고 작은 집단에는 비싼 이유다.

같은 데이터에 질의를 여러 번 하면 노이즈를 평균 내 참값에 다가갈 수 있다. 그래서 차분 프라이버시는 프라이버시 예산으로 운영한다. 같은 데이터에 ε₁, ε₂를 쓴 답을 함께 공개하면 전체는 (ε₁ + ε₂)-차분 프라이버시다(순차 합성). 총예산을 정하고, 질의마다 나눠 주고, 다 쓰면 더 답하지 않는다.

노이즈를 서버가 아니라 사용자 기기에서 넣는 방식은 로컬 차분 프라이버시다. 가장 오래된 형태가 무작위 응답이다. 민감한 질문에 동전을 던져 앞면이면 참말을, 뒷면이면 다시 던져 나온 대로 "예/아니요"를 답하게 하면 참말 확률이 3/4이고 ε = ln 3 ≈ 1.10이다. 개인의 답은 믿을 수 없지만 모으면 되돌릴 수 있다. 관측된 "예"가 35%라면 실제 비율은 20%로 추정된다.

가장 큰 실제 사용 예는 미국 인구조사국이다. 인구조사국은 2020년 인구조사 자료를 공개하면서 차분 프라이버시에 기반한 공개 회피 시스템으로 노이즈를 넣었다. 다만 인구조사국의 해당 안내 페이지에는 2026년 10월 현재 "더는 최신이 아니다"라는 표시와 함께, 노이즈 주입을 금지한 상무부 지시에 따라 대안을 검토 중이라는 설명이 붙어 있다(Census Bureau). 정확도와 보호 사이의 선택이 기술만이 아니라 정책의 문제라는 것을 보여 준다. 정의와 정리는 Dwork와 Roth의 교과서에 있다.

동형 암호

앞의 기법들이 데이터를 흐리게 해 공개한다면, 암호 쪽 기법은 데이터를 보이지 않게 한 채 계산한다. 동형 암호는 암호문끼리 연산한 결과를 복호화하면 평문끼리 연산한 결과가 나오는 암호다. 고객은 값을 암호화해 보내고, 서버는 키 없이 암호문으로 계산해 결과의 암호문만 돌려준다. 교과서판 RSA가 곱셈에 대해 이런 성질을 갖는다는 것은 암호학 노트의 RSA 절에서 본 그대로다(그 성질이 바로 패딩 없는 RSA가 위험한 이유이기도 하다).

한 가지 연산만 되는 부분 동형 암호는 오래전부터 있었고, 덧셈과 곱셈을 임의 횟수로 할 수 있는 완전 동형 암호는 2009년 Gentry가 처음 구성했다. 격자 문제에 기댄다는 점에서 양자내성 암호와 뿌리가 같다. 지금도 평문 계산보다 크게 느리고 암호문이 커서, 집계·통계·간단한 모델 추론처럼 계산이 짧고 데이터가 민감한 곳부터 쓰인다.

안전한 다자간 계산과 연합 학습

안전한 다자간 계산(MPC)은 여러 참여자가 자기 입력을 서로 보이지 않고 함수의 결과만 함께 얻는 방법이다. 가장 쉬운 예가 덧셈 비밀 분산이다. 각자 값을 무작위 조각으로 나눠 한 조각씩 나눠 주면, 조각 하나는 무작위 수와 구별되지 않는다. 각자 받은 조각을 더한 부분합만 공개하고 부분합을 모두 더하면 총합만 드러난다. 회사들이 서로의 고객 명단을 보지 않고 겹치는 수만 세거나, 직원 연봉을 보지 않고 평균만 내는 데 쓸 수 있다.

연합 학습은 같은 생각을 머신러닝에 옮긴 것이다. McMahan 외(2016)가 제안한 방식에서 서버는 모델을 기기에 보내고, 기기는 자기 데이터로 학습한 갱신만 돌려보내며, 서버는 갱신을 평균 내 모델을 고친다. 원본 데이터는 기기를 떠나지 않는다. 다만 갱신 자체에서 학습 데이터가 새어 나올 수 있어, 갱신을 서버가 개별로 보지 못하게 하는 보안 집계(MPC)나 갱신에 노이즈를 넣는 차분 프라이버시를 함께 쓴다. 모델 학습의 기본은 머신러닝 노트에 있다.

합성 데이터

합성 데이터는 원본의 분포와 상관을 배운 생성 모델로 실존하지 않는 행을 만들어 대신 공유하는 방법이다. 개발·테스트 환경, 외부 협업, 교육용 데이터에 특히 쓸모가 있다. 하지만 "가짜니까 안전하다"는 자동으로 성립하지 않는다. 생성 모델이 원본 행을 외워서 거의 그대로 내놓을 수 있고, 드문 사람일수록 그렇다. 그래서 합성 데이터는 쓸모(분포·상관이 맞는가, 합성으로 학습한 모델이 원본에서도 잘 되는가)와 위험(원본 행을 베끼거나 지나치게 가까운 행이 있는가)을 함께 검사하고, 강한 보장이 필요하면 생성 모델을 차분 프라이버시로 학습한다.

데이터 최소화, 보존 기한, 목적 제한

가장 확실한 보호는 갖지 않는 것이다. 개인정보 보호법 제3조는 처리 목적을 명확히 하고 그 목적에 필요한 범위에서 최소한의 개인정보만 수집할 것(제1항), 목적 외의 용도로 활용하지 말 것(제2항)을 원칙으로 둔다. 제21조는 보유 기간이 지나거나 목적을 이루는 등 개인정보가 불필요해지면 지체 없이 파기하고, 복구·재생되지 않게 하며, 다른 법령 때문에 보존해야 하면 다른 개인정보와 분리해 보관하라고 정한다.

• 모으기 전에 묻는다. 생년월일 대신 "성인 여부", 주소 대신 "시·군·구"로 충분한지 본다. 쓰지 않는 열은 나중에 새는 열이 된다.
• 기한을 코드로 둔다. 테이블마다 보존 기한을 메타데이터로 적고, 기한이 지난 행을 지우는 작업을 정기 배치로 돌린다. 백업과 분석 웨어하우스의 사본도 같은 기한을 따라야 한다.
• 목적별로 나눈다. 결제·배송에 쓴 주소를 마케팅 분석이 그대로 읽지 않도록 접근 권한과 뷰를 목적별로 나눈다.

개인정보 보호 중심 설계(Privacy by Design)

Privacy by Design은 캐나다 온타리오주 정보·프라이버시 위원이던 Ann Cavoukian이 정리한 일곱 원칙이다. 핵심은 보호를 나중에 덧붙이는 기능이 아니라 처음부터 설계에 넣고, 사용자가 아무것도 하지 않아도 보호되는 것을 기본값으로 삼는 것이다. GDPR 제25조는 이 생각을 컨트롤러의 의무로 옮겨, 가명처리·데이터 최소화 같은 조치를 설계 단계부터 넣고 기본값으로는 목적에 필요한 개인정보만(수집량·처리 범위·보관 기간·접근 범위 모두) 처리하도록 정했다.

로그와 분석 도구에서 새는 개인정보

데이터베이스를 아무리 잘 지켜도 개인정보는 옆길로 샌다. 요청 하나가 접근 로그, 애플리케이션 로그, 오류 추적 서비스, 분석 SDK, 세션 녹화 도구, 백업으로 복제되고, 사본마다 접근 권한과 보존 기한이 따로다. OWASP 로깅 치트 시트는 세션 식별자, 접근 토큰, 비밀번호, 민감한 개인정보, 결제 카드 데이터, 동의하지 않은 정보 등을 로그에 그대로 남기지 말고 지우거나 가리라고 권한다.

• URL에 개인정보를 넣지 않는다. 쿼리 문자열은 접근 로그, 프록시, 브라우저 기록, Referer 헤더로 퍼진다. 이메일·전화번호·토큰은 본문이나 헤더로 보낸다.
• 로그는 허용 목록으로 찍는다. 요청·응답 본문을 통째로 찍지 말고, 기록할 필드를 정해 그것만 남긴다. 금지 목록은 새 필드가 생길 때마다 뚫린다.
• 오류 추적 도구에 보내기 전에 가린다. 예외 메시지와 지역 변수에 사용자 입력이 섞인다. SDK의 마스킹 훅에서 지운다.
• 분석 이벤트를 설계한다. 페이지 제목·URL·검색어에 개인정보가 섞이지 않는지 보고, 사용자 ID 대신 서비스 안에서만 통하는 가명 ID를 쓴다.
• 세션 녹화는 입력란을 기본으로 가린다. 비밀번호뿐 아니라 이름·주소·메모 칸도 마찬가지다.
• 사본의 기한을 맞춘다. 로그·백업·분석 웨어하우스의 보존 기한을 원본과 같은 정책으로 관리한다. 운영 쪽 로그 설계는 관측성 노트에 있다.

흔한 오해

• "해시하면 익명이다" — 해시는 같은 입력에 늘 같은 값을 내는 결정적 함수다. 입력의 가짓수가 적으면 전부 해시해 보면 된다. 010으로 시작하는 휴대폰 번호는 뒤 8자리, 곧 100,000,000가지뿐이라 초당 10억 번 해시하는 장비(가정)라면 0.1초, 초당 1만 번으로 느리게 만든 해시라도 2.8시간이면 끝난다. 되돌리지 않아도 같은 번호는 같은 해시라 사람을 이어 추적하는 데는 그대로 쓰인다. 미국 FTC도 2024년 글에서 해시가 데이터를 익명으로 만들지 않는다고 못 박았다(FTC). 해시나 비밀 키를 쓴 HMAC으로 바꾼 값은 잘해야 가명정보다.
• "이름만 지우면 된다" — 준식별자 몇 개로 대부분의 사람이 유일해진다(재식별 절).
• "집계 통계는 안전하다" — 작은 칸(한 명짜리 셀)이나 두 집계의 차이로 개인 값이 드러난다. 차분 프라이버시가 이 문제를 다루려고 나왔다.
• "동의를 받았으니 무엇이든 해도 된다" — 동의는 정해진 목적에 대한 것이고, 목적 제한과 최소화 원칙은 여전히 적용된다.
• "암호화했으니 개인정보가 아니다" — 키를 가진 쪽에게는 그대로 개인정보다. 암호화는 유출 피해를 줄이는 보호 조치이지 익명화가 아니다.

핵심 자료

요지는 직접 정리한 한 줄이다. 암호 기법의 원리는 암호학 노트, 보안 전반은 보안 노트, 결제 데이터의 보관 규칙은 결제 시스템 노트에 있다.