예시로 설명하는 데이터 익명화 기법

주요 데이터 익명화 기법에는 마스킹, 일반화, 집계, 노이즈 추가, 값 교환, 토큰화, 가명처리, 해싱이 있으며, 결과를 측정하는 방법으로 k-익명성과 차등 개인정보 보호가 있습니다. 어느 하나만으로는 충분하지 않습니다. 유럽 규제기관은 모든 기법에 재식별 위험이 남으며, 누구도 합리적으로 해당 기록의 대상이 누구인지 알아낼 수 없을 때만 결과를 익명 정보로 본다고 합니다.

모든 기법을 평가하는 기준

GDPR과 UK GDPR에서 익명 정보는 데이터 보호법의 적용 대상이 아니지만, 개인정보는 적용 대상입니다. 전문 26 에서 그 경계를 제시합니다. 여기에는 누군가를 직접 또는 간접적으로 식별하기 위해 한 사람을 추려내는 등의 방법이 "사용될 가능성이 합리적으로 높은" 모든 수단이 고려됩니다. 같은 전문은 추가 정보가 있으면 개인과 연결될 수 있는 가명처리 데이터도 여전히 식별 가능한 개인에 관한 정보라고 규정합니다.

당시 EU의 데이터 보호 규제기관인 제29조 작업반은 이를 다음 문서에서 세 가지 질문으로 구체화했습니다. 익명화 기법에 관한 의견서 05/2014 (WP216). 누군가 여전히 한 사람을 추려낼 수 있는가? 같은 사람에 관한 두 기록을 연결할 수 있는가? 한 사람에 관한 정보를 추론할 수 있는가? 의견서는 검토한 각 기법이 어떤 상황에서는 이 질문 중 적어도 하나를 통과하지 못한다고 결론 내렸으며, 이것이 기법을 조합하는 이유입니다. 2025년 3월 28일에 발표된 영국 규제기관의 익명화 및 가명처리 지침도 같은 위험 기반 관점을 취합니다.

익명화, 가명처리, 정보 가림(삭제) 처리의 차이부터 알고 싶다면 먼저 AI에 어떤 방법이 필요한지살펴보세요. 이 글에서는 개별 기법을 다룹니다.

표본 기록

아래 예시는 모두 인사 기록에 나올 법한 동일한 가상 기록에서 시작합니다.

Anna Kowalski, born 12.03.1989 (37), 14 Elm Street, Leeds,
anna.kowalski@example.com, staff nurse, 12 days of sick leave

값을 삭제하거나 흐리게 하는 기법

마스킹 및 삭제

마스킹은 값의 일부를 가리고, 삭제는 값이나 열 또는 전체 기록을 지웁니다.

A***** K*******, born **.**.1989, [address removed], staff nurse

직접 식별을 막아 줍니다. 삭제된 값이 필요한 작업은 불가능해지며 결과만으로는 되돌릴 수 없습니다. 남은 정보만으로도 Anna를 알아볼 수 있습니다. 작은 병동이라면 1989년에 태어난 간호사를 찾기 어렵지 않습니다. 마스킹만으로 데이터를 익명화하는 경우는 드뭅니다.

일반화

일반화는 정확한 값을 더 넓은 범주의 값으로 바꿉니다.

age 37 → 30-39; 14 Elm Street, Leeds → Leeds; staff nurse → healthcare worker

많은 사람이 비슷하게 보이도록 만들어 한 사람을 추려내기 어렵게 합니다. 대신 정밀도가 떨어져 누가 더 나이가 많은지 알 수 없게 됩니다. 되돌릴 수 없습니다. 결과가 익명인지 여부는 각 조합을 공유하는 사람이 몇 명인지에 따라 달라지며, 이를 측정하는 것이 k-익명성입니다(아래 참조).

집계

집계는 개인별 행 대신 합계나 평균을 공개합니다.

Ward 4, 2025: 23 nurses, average sick leave 9.4 days

각 집단에 충분한 인원이 있을 때 개인을 보호합니다. 개인 한 명에 관한 모든 질문에는 답할 수 없게 됩니다. 집단이 한두 명뿐이면 평균으로 개인의 수치를 알아낼 수 있으므로, 보통은 규모가 작은 셀을 삭제합니다.

노이즈 추가(교란)

노이즈 추가는 값을 무작위로 조금씩 바꿉니다.

age 37 → 39; sick leave 12 days → 10 days

각 값을 신뢰할 수 없게 만들면서도 통계 수치는 대체로 정확하게 유지합니다. 정확한 수치를 알 수 없게 됩니다. WP216은 정보에 비해 노이즈가 충분히 크지 않으면 단독 익명화 기법으로 사용할 수 없다고 경고합니다. 예를 들어 휴가가 90일인 유일한 사람처럼 특이한 값은 여전히 알아볼 수 있습니다.

값 교환(순열)

값 교환은 기록 간에 값을 바꾸므로 각 열의 합계는 유지되지만 각 행은 더 이상 한 사람의 기록이 아닙니다.

Anna's 12 days of leave ↔ another nurse's 3 days

값과 사람의 연결을 막습니다. 열 간의 관계가 깨지며, WP216은 교환된 값이 다른 열과 연결되어 있으면 이 방법이 실패할 수 있음을 보여 줍니다. 관리자의 급여가 주니어 직급에 들어가면 눈에 띄게 됩니다.

식별자를 대체하는 기법

토큰화

토큰화는 식별자를 임의의 토큰으로 바꾸고, 연결 정보는 별도의 보호된 표에 보관합니다.

anna.kowalski@example.com → TKN-8F3K2Q

ICO에 따르면 임의 토큰은 원래 값과 수학적 관계가 없으므로 토큰만으로는 아무것도 알 수 없습니다. 표를 가진 사람은 원래 값을 복원할 수 있으므로, 그 사람에게는 결과가 여전히 개인정보입니다.

일관된 자리표시자를 이용한 가명처리

각 개인, 회사 또는 주소에 읽기 쉬운 자리표시자를 부여하고, 같은 값에는 항상 같은 자리표시자를 사용합니다.

Person_1, born [Date_1], [Address_1], staff nurse.
Person_1 asked Person_2 to approve the leave.

직접 식별자를 숨기면서 누가 무엇을 했는지는 읽을 수 있게 합니다. 이는 텍스트에서 중요합니다. 문서의 논리적 흐름도 유지됩니다. 대응표가 있으면 되돌릴 수 있고, 전문 26에 따르면 여전히 개인정보입니다. 키 보유자 문제의 자세한 내용은 다음 글을 참조하세요. 가명처리된 데이터도 여전히 개인정보인지 여부.

해싱

해싱은 값을 단방향 함수에 넣고 그 출력을 보관합니다.

anna.kowalski@example.com → 3f9a…c71e (SHA-256)

되돌릴 수 없어 보이지만 이름이나 이메일 주소는 그렇지 않은 경우가 많습니다. 예상 가능한 값 목록을 가진 사람은 각 값을 해시해 비교할 수 있습니다. 직원 이름이나 회사 주소의 종류는 한정되어 있기 때문입니다. WP216은 알려진 입력값 범위와 관련해 이 점을 설명하며, ICO는 솔트, 페퍼 또는 키 없이 해싱하는 것을 권장하지 않습니다 솔트, 페퍼 또는 키 없이 해싱하는 방식과 MD5, SHA-1 같은 오래된 알고리즘은 무차별 대입 공격에 취약하므로 피하라고 권고합니다. 키를 사용하는 해시는 가명처리이며, 이메일의 일반 해시는 가명처리라고 보기조차 어렵습니다.

k-익명성과 차등 개인정보 보호

다음 방법은 값을 바꾸는 기법이 아닙니다. 전체 데이터 세트가 얼마나 잘 보호되는지 확인하거나 보장하는 방법입니다.

k-익명성 은 식별 속성의 조합(연령대, 도시, 직업 등)이 최소 k개의 기록에 공유되어 있음을 뜻합니다. k = 5라면 Anna와 똑같이 보이는 사람이 적어도 다섯 명은 있어 Anna를 그들 사이에 숨길 수 있습니다. 하지만 추론을 막지는 못합니다. 리즈에 사는 30~39세 의료 종사자 다섯 명 모두 휴가를 10일 넘게 썼다면, Anna도 그랬다는 사실을 알 수 있습니다. l-다양성 은 각 집단에 민감한 속성의 서로 다른 값이 최소 l개 포함되어야 한다는 규칙을 추가합니다.

차등 개인정보 보호 는 행이 아니라 답변을 대상으로 작동합니다. 공개되는 각 통계에 노이즈를 더해, 특정 개인 한 명이 데이터에 포함되어 있든 없든 답변이 거의 달라지지 않도록 조정합니다. 보호 수준은 매개변수로 설정하며, 보호를 강화할수록 수치의 정확도는 낮아집니다. 미국 인구조사국은 2020년 인구조사 데이터 제품에 이를 사용했습니다 단, 의석 배분에 사용된 주별 합계는 예외였습니다. 통계에는 적합하지만, 누군가 읽어야 하는 문서에는 아무런 도움이 되지 않습니다.

표 데이터에서는 도구가 이런 측정을 대신해 줍니다. ARX는 무료 오픈소스 데스크톱 도구이자 Java 라이브러리입니다(Apache 2.0 라이선스, 2026년 10월 기준 버전 3.9.2). 구조화된 데이터에 일반화, 삭제, 마이크로집계를 적용하고, k-익명성, l-다양성, t-근접성, 차등 개인정보 보호 기준에 따라 결과를 확인합니다. 재식별 위험도 추정합니다. CSV 파일, Excel 시트, 데이터베이스 표 같은 데이터 세트용으로 만들어졌으며 계약서나 편지용은 아닙니다.

모든 기법 한눈에 비교하기

대부분의 항목이 "상황에 따라 다름"인 이유는 데이터 세트의 익명 여부가 기법별로 결정되는 것이 아니라, 해당 데이터 세트 전체와 그 맥락을 기준으로 결정되기 때문입니다. 익명 정보로 공개하거나 공유할 계획이라면 DPO(데이터 보호 책임자) 또는 데이터 보호 전문 변호사에게 문의하세요.

AI에 제공하는 문서에 적합한 기법

통계용 데이터 세트와 AI 챗봇에 넣을 문서에는 서로 정반대의 요건이 필요합니다. 통계에는 행이 많고 개인을 식별할 수 없어야 합니다. 집계, 일반화, k-익명성, 차등 프라이버시는 바로 그런 목적을 위해 만들어졌습니다. 계약서, 이메일 대화, 고충 신고서는 특정 사람들에 관한 문서이므로 AI가 그 사람들을 구분해 따라갈 수 있어야 합니다.

문서에는 세 가지 기법이 주된 역할을 합니다.

• 이름, 회사, 주소, 이메일, ID 번호에 일관된 자리표시자를 사용하는 가명처리입니다. 전체 텍스트에서 Person_1는 계속 Person_1로 표시되므로 AI는 누가 무엇을 썼고 누가 누구에게 빚을 졌는지 파악할 수 있습니다. 검은 막대나 단일한 "[REDACTED]" 표시는 이런 구분을 없애 버립니다. 다음을 참고하세요. 자리표시자가 더 효과적인 이유.
• 질문에 정확한 날짜나 장소가 필요하지 않다면 일반화하세요. 날짜 대신 "2025년 3월", 거리 이름 대신 "잉글랜드 북부의 한 도시"라고 쓸 수 있습니다.
• 질문에 전혀 필요하지 않은 정보는 삭제하세요. 예를 들어 통지 기간만 묻는 문서라면 건강 관련 세부 정보는 삭제합니다.

노이즈 추가, 데이터 교환, 차등 프라이버시는 여기에 적합하지 않습니다. 문서의 사실을 바꾸면 AI의 답변이 틀리게 됩니다. 해싱하면 이름이 맥락상 누구도, AI조차도 알아볼 수 없는 문자열로 바뀝니다.

결과물은 가명처리된 데이터이므로 데이터 보호 규칙은 여전히 적용됩니다. 달라지는 것은 PC 밖으로 나가는 정보입니다. 이 용도에 쓸 소프트웨어를 고르는 중이라면 다음 체크리스트를 확인하세요. 가명처리 도구를 고를 때 살펴볼 사항 데이터가 어디로 전송되고 이름을 어떻게 되돌리는지 설명합니다.

자주 묻는 질문

가장 효과적인 데이터 익명화 기법은 무엇인가요?

단 하나의 기법만 있는 것은 아닙니다. WP216은 검토한 모든 기법이 어떤 상황에서는 세 가지 기준 중 적어도 하나를 충족하지 못한다고 밝혔습니다. 통계 데이터 세트에는 k-익명성으로 평가한 일반화와 억제, 또는 차등 프라이버시가 가장 강력한 결과를 제공합니다. AI가 읽어야 하는 문서에는 날짜와 장소를 일반화하는 가명처리가 실용적인 선택이지만, 이는 익명화가 아닙니다.

이메일 주소를 해싱하는 것만으로 익명화하기에 충분한가요?

아니요. 이메일 주소는 예측 가능한 패턴을 따르므로 공격자가 예상 가능한 주소 목록을 해싱해 결과를 대조할 수 있습니다. 키를 사용하는 해시나 무작위 토큰이 더 안전하지만, 둘 다 익명화가 아니라 가명처리입니다.

표 형식 데이터용 익명화 도구란 무엇인가요?

ARX는 무료 오픈 소스 도구의 한 예입니다. CSV, Excel 파일 또는 데이터베이스 표를 불러오고, 일반화와 억제 규칙을 설정한 다음 k-익명성과 같은 개인정보 보호 모델을 선택하면 남은 위험을 보고합니다. 이런 종류의 도구는 열과 행을 처리하며, 연속된 문장은 처리하지 않습니다.

익명화된 데이터에도 GDPR이 적용되나요?

Recital 26에 따르면 진정으로 익명인 데이터에는 적용되지 않습니다. 가명처리된 데이터에는 적용됩니다. 아무도 합리적으로 재식별할 수 없다는 점을 입증하기가 어렵기 때문에 규제 기관은 익명화를 단일 단계가 아니라 위험 평가로 다룹니다.

ClientSafe PC에서 문서를 가명처리합니다. 이름, 회사, 주소, 전화번호, 이메일 주소, 계좌번호와 ID 번호, 생년월일을 Person_1과 같은 자리표시자로 바꾸며, 한 사건에 속한 모든 문서에서 같은 이름에는 같은 자리표시자를 사용합니다. 탐지가 완벽하지는 않으므로 복사하기 전에 목록을 검토하세요.