가명처리와 익명처리 — 분석 데이터를 만들 때의 경계선

한 문장 결론

가명정보는 여전히 개인정보라서 추가정보 분리·접근권한 분리·처리 기록 같은 특례 의무를 지키며 통계·연구·공익적 기록보존 목적으로만 동의 없이 쓸 수 있고, 익명정보는 다른 정보를 써도 더 이상 개인을 알아볼 수 없을 때만 법 적용에서 벗어나므로, “이름을 지웠다”는 이유만으로 익명으로 분류하면 안 됩니다.

적용 조건과 예외

가명 vs 익명

구분	가명정보	익명정보
정의	가목·나목 정보를 가명처리하여 추가 정보의 사용·결합 없이는 특정 개인을 알아볼 수 없는 정보(제2조제1호다목)	시간·비용·기술 등을 합리적으로 고려할 때 다른 정보를 사용하여도 더 이상 개인을 알아볼 수 없는 정보(제58조의2)
개인정보 여부	개인정보	법 적용 대상 아님
복원 가능성	추가정보가 있으면 복원 가능	복원 불가능해야 함
동의 없이 처리	통계작성, 과학적 연구, 공익적 기록보존 등(제28조의2제1항)	제한 없음
안전조치	제28조의4, 시행령 제29조의5	법상 의무 없음(재식별 시 다시 개인정보)
처리 기록	작성·보관, 파기 후 3년 이상 보관(제28조의4제3항)	법상 의무 없음(판단 근거 보관 권장)
정보주체 권리	열람·정정·삭제·처리정지·전송 요구 미적용(제28조의7)	해당 없음
유출 통지	제34조제1항·제2항 미적용(제28조의7). 다만 제34조제4항 신고 등 나머지 의무 적용 여부는 review-required	해당 없음

가명정보 특례의 경계

• 목적 제한: 제28조의2제1항의 “통계작성, 과학적 연구, 공익적 기록보존 등”. 과학적 연구는 기술 개발과 실증, 기초·응용연구, 민간 투자 연구 등을 포함합니다(제2조제8호). 상업적 제품 개발이 여기에 해당하는지는 구체 사안별로 검토가 필요합니다(review-required).
• 제3자 제공: 특정 개인을 알아보기 위해 사용될 수 있는 정보(예: 매핑 테이블, 키)를 포함하면 안 됩니다(제28조의2제2항).
• 다른 처리자와의 결합: 지정된 전문기관만 수행할 수 있습니다(제28조의3제1항). 두 회사가 해시 키를 공유해 직접 JOIN하는 방식은 이 조항과 충돌할 수 있습니다.
• 민감정보·고유식별정보의 가명처리: 가명처리했다고 제23조·제24조 적용이 자동으로 배제되는지는 조문만으로 판단하기 어려워 review-required입니다. 주민번호는 가명처리 대상 항목에서 삭제하는 편이 안전합니다(프로젝트 권장사항).

실제 법적 근거

• 제2조제1호의2: “가명처리”란 개인정보의 일부를 삭제하거나 일부 또는 전부를 대체하는 등의 방법으로 추가 정보가 없이는 특정 개인을 알아볼 수 없도록 처리하는 것.
• 제3조제7항: 익명처리로 목적을 달성할 수 있으면 익명, 그렇지 않으면 가명으로 처리될 수 있도록 해야 합니다(원칙).
• 제28조의4제1항 + 시행령 제29조의5제1항 — 가명정보와 추가정보에 대한 안전성 확보 조치:
  1. 시행령 제30조에 따른 안전성 확보 조치
  2. 가명정보와 추가정보의 분리 보관. 추가정보가 불필요하면 파기
  3. 가명정보와 추가정보에 대한 접근 권한의 분리. 소상공인 등 분리가 어려운 정당한 사유가 있으면 최소 권한 부여와 권한 보유 현황 기록으로 관리
• 제28조의4제2항: 처리 목적 등을 고려해 가명정보의 처리 기간을 별도로 정할 수 있음. 기간 경과 시 제21조제1항에 따라 파기 대상.
• 제28조의4제3항 + 시행령 제29조의5제2항 — 기록 사항: 처리 목적, 가명처리한 항목, 이용내역, 제3자 제공 시 제공받는 자, 처리 기간(별도로 정한 경우), 보호위원회 고시 사항. 파기 후 3년 이상 보관.
• 제28조의5: 특정 개인을 알아보기 위한 목적의 처리 금지(위반 시 제71조제8호 형사처벌, 제64조의2제1항제6호 과징금). 처리 중 특정 개인을 알아볼 수 있는 정보가 생성되면 즉시 처리 중지, 지체 없이 회수·파기.
• 시행령 제29조의3: 결합전문기관은 결합 시 특정 개인을 알아볼 수 없도록 해야 하고, 반출은 ① 결합 목적과 반출 정보의 관련성 ② 특정 개인을 알아볼 가능성이 없을 것 ③ 반출 정보 안전조치 계획을 기준으로 반출심사위원회 심사를 거쳐 승인합니다.
• 시행령 제16조제1항제1호 단서, 고시 제13조제3항: 기술적 특성으로 영구 삭제가 현저히 곤란하면 제58조의2에 해당하는 정보(익명정보)로 처리하여 복원이 불가능하도록 하는 것이 파기 방법이 될 수 있습니다.

(현행 법률 제21445호·시행령 제36671호·고시 제2026-9호 기준. 국가법령정보센터 원문과 대조함.)

개발자용 실무 해설

재식별 위험은 어디서 오는가

위험	예시	대응
추가정보 접근	분석가가 토큰 매핑 테이블에도 접근 가능	별도 계정·별도 저장소, 접근 권한 분리(영 제29조의5제1항제3호)
결정적 대체의 역산	솔트 없는 전화번호 해시	비밀 키 기반 HMAC, 키는 추가정보로 분리 보관
준식별자 조합	생년월일 + 성별 + 우편번호 + 직장	일반화(연령대, 시·도), 범주화, 삭제
희귀값	특이 질병, 고액 거래, 소규모 부서	상·하위 코딩, 최소 집계 단위 설정
시계열·위치 패턴	출퇴근 GPS 궤적	시간·공간 해상도 축소, 궤적 절단
외부 데이터 결합	공개 SNS, 유출 데이터와 매칭	반출 전 결합 공격 시나리오 검토
자유 텍스트	상담 메모 속 이름·연락처	텍스트 필드 삭제 또는 개체명 마스킹

구체적인 가명처리 기법의 적정성 판단 기준은 보호위원회 가이드라인을 확인해야 합니다(review-required).

구현 포인트

1. 가명처리 = 변환 + 분리 + 권한 + 기록입니다. 해시 함수 하나로 끝나지 않습니다. 시행령 제29조의5가 요구하는 분리 보관, 권한 분리, 기록 작성까지 포함한 파이프라인으로 만들어야 합니다.
2. 추가정보는 “키와 매핑 테이블”입니다. HMAC 키, 토큰 ↔ 원본 ID 매핑, 암호화 키가 모두 추가정보입니다. 복원 필요가 없으면 파기하라는 것이 시행령 제29조의5제1항제2호입니다.
3. 처리 기록은 파기 후에도 3년 이상 남겨야 하므로, 가명 데이터셋을 지우는 배치가 기록까지 지우지 않게 합니다.
4. 재식별 정보가 생기면 멈추는 장치가 필요합니다. 분석 결과에 개별 레코드가 그대로 드러나거나 소수 집단이 특정되면 처리를 중지하고 회수·파기해야 합니다(제28조의5제2항). 최소 집계 단위(k) 미달 결과를 차단하는 쿼리 가드를 둡니다.
5. 익명 판단은 문서로 남깁니다. 법상 기록 의무는 없지만, 익명정보라는 판단이 틀리면 개인정보를 무단 처리한 것이 됩니다. 평가 방법, 사용한 외부 데이터 가정, 검토자를 남기세요(프로젝트 권장사항).
6. AI 학습 데이터에도 같은 원칙이 적용됩니다. → AI 학습 데이터

권장 설계

원본 영역 (운영 DB)                 가명 처리 영역                     분석 영역
┌──────────────┐  ETL(가명처리)  ┌───────────────────┐            ┌────────────────┐
│ users        │ ─────────────▶ │ token_vault       │  (추가정보) │ analytics.*    │
│ orders       │                │  - HMAC 키(KMS)    │            │  - pid (토큰)   │
└──────────────┘                │  - pid ↔ user_id   │            │  - 연령대, 시도 │
                                └───────────────────┘            │  - 금액 구간    │
                                  접근: 가명처리 담당만             └────────────────┘
                                                                   접근: 분석가
PseudonymizationLog (파기 후 3년 이상 보관)
├─ dataset_id, purpose (통계/연구/공익적 기록보존)
├─ items[] + 처리 방법 (삭제/HMAC/일반화/범주화)
├─ usage_log[] (이용내역)
├─ recipients[] (제3자 제공 시)
├─ retention_until (제28조의4제2항, 정한 경우)
└─ destroyed_at

• 분석 영역 계정은 token_vault에 대한 권한이 없어야 하고, 이 조건을 IaC 정책 테스트로 검증합니다.
• 분석 쿼리 결과는 최소 집계 단위 미만이면 반환하지 않습니다.

위험한 설계

• 분석 웨어하우스에 원본 테이블과 가명 테이블을 같은 권한으로 함께 둠
• 솔트 없는 해시를 “익명 ID”로 부르고 외부 파트너에게 제공
• 두 회사가 같은 해시 키를 공유해 직접 데이터 결합(제28조의3 전문기관 결합 우회)
• 가명 데이터셋 파기 배치가 처리 기록 테이블까지 함께 삭제
• 상세 위치·시간 로그를 “개인 식별 컬럼이 없다”며 익명정보로 분류
• 분석 결과가 특정 개인을 드러내도 계속 사용

Python/TypeScript 구현 예제

# 키 기반 가명처리 + 일반화 + 최소 집계 단위 가드
import hashlib
import hmac
from dataclasses import dataclass
from datetime import date

def pseudonymize_id(user_id: str, key: bytes) -> str:
    # key는 추가정보: 별도 저장소(KMS)에 두고 분석 계정은 접근 불가 (영 제29조의5제1항제2·3호)
    return hmac.new(key, user_id.encode(), hashlib.sha256).hexdigest()[:32]

def age_band(birth: date, today: date) -> str:
    age = today.year - birth.year - ((today.month, today.day) < (birth.month, birth.day))
    return f"{(age // 10) * 10}대"

@dataclass
class PseudoRow:
    pid: str
    age_band: str
    region: str          # 시·도 수준으로 일반화
    amount_bucket: str

MIN_GROUP = 10  # 프로젝트 권장값. 법정 기준 아님

def guarded_aggregate(rows: list[PseudoRow], key=lambda r: (r.age_band, r.region)) -> dict:
    groups: dict = {}
    for r in rows:
        groups.setdefault(key(r), []).append(r)
    small = [k for k, v in groups.items() if len(v) < MIN_GROUP]
    if small:
        # 제28조의5제2항 취지: 특정 개인을 알아볼 수 있는 결과가 생기면 중지
        raise RuntimeError(f"최소 집계 단위 미만 그룹이 있어 결과를 반환하지 않습니다: {small}")
    return {k: len(v) for k, v in groups.items()}

// 가명처리 기록 (제28조의4제3항, 영 제29조의5제2항) — 데이터셋 파기 후에도 3년 이상 보관
interface PseudonymizationRecord {
  datasetId: string;
  purpose: 'statistics' | 'scientific-research' | 'public-archiving';
  items: { field: string; method: 'delete' | 'hmac' | 'generalize' | 'categorize' }[];
  usage: { at: string; by: string; query: string }[];
  recipients: string[];
  retentionUntil?: string;
  destroyedAt?: string;
}

const THREE_YEARS_MS = 3 * 365 * 24 * 60 * 60 * 1000;

export function canDeleteRecord(r: PseudonymizationRecord, now = Date.now()): boolean {
  return Boolean(r.destroyedAt) && now - Date.parse(r.destroyedAt!) >= THREE_YEARS_MS;
}

전체 실행 가능한 예제는 구현 예제를 참고하세요.

개발 체크리스트

• 데이터셋마다 가명정보인지 익명정보인지 분류하고 근거를 남겼다
• 가명처리 목적이 통계작성·과학적 연구·공익적 기록보존 등에 해당하는지 검토했다 (review-required)
• 추가정보(키, 매핑 테이블)가 별도 저장소에 있고 불필요하면 파기한다
• 가명정보와 추가정보의 접근 권한이 분리되어 있고 정책 테스트로 검증한다
• 처리 목적·항목·이용내역·제공받는 자·처리 기간이 기록되고 파기 후 3년 이상 보관된다
• 다른 회사와의 결합은 결합전문기관을 통한다
• 제3자 제공 시 키·매핑 정보가 포함되지 않는다
• 분석 결과에 최소 집계 단위 가드가 있고, 재식별 정보 생성 시 중지·회수·파기 절차가 있다
• 처리방침에 가명정보 처리 사항을 기재했다(제30조제1항제4호의2)
• 익명정보 판단에는 재식별 위험 평가와 검토자 기록이 있다

공식 원문 링크와 확인일

아래 “근거 구분표”와 “공식 원문 링크”를 참고하세요. 법률 제2조·제3조·제28조의2~제28조의7·제58조의2와 시행령 제16조·제29조의3·제29조의5, 안전성 확보조치 기준 제13조는 2026-10-23에 국가법령정보센터 Open API 현행본과 대조했습니다. 가명처리 기법의 적정성 기준, 상업적 연구의 “과학적 연구” 해당 여부, 민감정보 가명처리 시 적용 관계는 안내서·가이드라인 원문 대조 전이라 review-required입니다.