고유식별정보와 주민등록번호 — 받지 않는 설계가 기본

한 문장 결론

주민등록번호는 정보주체가 동의해도 처리할 수 없고 법령이 구체적으로 요구·허용할 때만 처리할 수 있으므로, 기본 설계는 “받지 않는다”이고, 본인확인이 필요하면 본인확인 서비스의 결과값처럼 주민번호가 아닌 대체 수단을 쓰며, 법령상 꼭 필요한 경우에만 암호화된 별도 저장소에 둡니다.

적용 조건과 예외

고유식별정보 (제24조, 시행령 제19조)

정보	근거 법률(시행령 제19조)	처리 가능 근거
주민등록번호	「주민등록법」 제7조의2제1항	제24조의2제1항만 (동의 불가)
여권번호	「여권법」 제7조제1항제1호	제24조제1항: 별도 동의 또는 법령의 구체적 요구·허용
운전면허의 면허번호	「도로교통법」 제80조	위와 같음
외국인등록번호	「출입국관리법」 제31조제5항	위와 같음

시행령 제19조 단서: 공공기관이 법 제18조제2항제5호~제9호에 따라 처리하는 경우는 제외합니다.

주민등록번호 처리가 허용되는 경우 (제24조의2제1항)

1. 법률·대통령령·국회규칙·대법원규칙·헌법재판소규칙·중앙선거관리위원회규칙·감사원규칙에서 구체적으로 주민등록번호의 처리를 요구하거나 허용한 경우
2. 정보주체 또는 제3자의 급박한 생명, 신체, 재산의 이익을 위하여 명백히 필요하다고 인정되는 경우
3. 제1호·제2호에 준하여 처리가 불가피한 경우로서 보호위원회가 고시로 정하는 경우 (고시 원문 미확인, review-required)

정보주체의 동의는 목록에 없습니다. 제24조제1항의 별도 동의 예외는 제24조의2제1항 “제24조제1항에도 불구하고”에 의해 주민번호에는 적용되지 않습니다.

어떤 법령이 “구체적으로” 허용하는지(예: 세법상 원천징수, 금융거래 실명확인, 의료 관련 법령 등)는 각 법령을 확인해야 하며, 이 사이트에서는 해당 법령 원문을 대조하지 않았습니다(review-required).

실제 법적 근거

• 제24조의2제2항: 주민등록번호가 유출등이 되지 아니하도록 암호화 조치를 통하여 안전하게 보관해야 합니다. 시행령 제21조의2: 적용 대상은 주민등록번호를 전자적인 방법으로 보관하는 개인정보처리자. 적용 시기는 100만명 미만 보관자 2017.1.1., 100만명 이상 보관자 2018.1.1.로 이미 지났으므로 현재 모두 적용됩니다.
• 제24조의2제3항: 주민번호를 처리할 수 있는 경우에도 인터넷 홈페이지 회원가입 단계에서는 주민번호를 사용하지 않고도 가입할 수 있는 방법을 제공해야 합니다.
• 제24조제3항 + 시행령 제21조제1항: 고유식별정보의 안전성 확보 조치는 시행령 제30조(내부 관리계획, 접근권한, 접근통제, 암호화, 접속기록 등)를 준용합니다.
• 시행령 제21조제2항·제3항: 공공기관 외의 자로서 5만명 이상의 정보주체에 관하여 고유식별정보를 처리하는 자 등은 보호위원회가 안전성 확보 조치 이행 여부를 3년마다 1회 이상 조사합니다. 개인정보 보호 인증을 받은 경우 등은 조사를 실시한 것으로 봅니다(제4항).
• 안전성 확보조치 기준 제7조:
  • 제2항: 이용자의 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호(및 신용카드번호, 계좌번호, 생체인식정보)는 안전한 암호 알고리즘으로 암호화하여 저장.
  • 제3항: 이용자가 아닌 정보주체(예: 직원)의 고유식별정보는 인터넷망 구간·DMZ에 저장 시 암호화, 내부망 저장 시에도 주민번호는 암호화(그 외 고유식별정보는 영향평가 또는 위험도 분석 결과에 따라 적용 여부 결정 가능).
  • 제5항: 이용자의 개인정보 또는 이용자가 아닌 정보주체의 고유식별정보를 취급자 PC·모바일·보조저장매체에 저장할 때 암호화.
  • 제6항: 일정 규모 이상 처리자는 암호 키 생성·이용·보관·배포·파기 절차를 수립·시행.
• 제34조의2제1항: 고유식별정보가 정보통신망을 통해 공중에 노출되지 않도록 해야 합니다.
• 제재: 제64조의2제1항제4호(과징금), 제71조제5호(고유식별정보 위반 처리 시 형사처벌).

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

개발자용 실무 해설

1. “주민번호로 본인확인”이라는 요구사항은 다시 씁니다. 대부분 필요한 것은 ① 실명인지 ② 같은 사람의 중복 가입인지 ③ 성인인지입니다. 본인확인 서비스(휴대전화 본인확인 등)의 결과값(이름, 생년월일, 성별, 서비스별 연계 식별값 등)으로 대체할 수 있는지 먼저 검토하세요. 본인확인기관 제도와 연계 식별값의 법적 성격은 정보통신망법 등 다른 법률 확인이 필요합니다(review-required).
2. 생년월일을 위해 주민번호 앞자리를 받지 않습니다. 앞 6자리+뒤 1자리도 주민번호의 일부이므로 처리 제한 대상이 될 수 있습니다(해석 review-required). 생년월일이 필요하면 생년월일 필드로 받습니다.
3. 법령상 필요한 경우(예: 급여 원천징수)에도 분리합니다. 주민번호는 별도 테이블·별도 키·별도 권한으로 두고, 업무 화면에는 마스킹(900101-1******)해 표시합니다. 원문 조회는 사유 입력 + 접속기록으로 남깁니다.
4. 로그·에러 메시지·검색 인덱스에 들어가지 않게 합니다. 요청 바디 전체를 로깅하는 미들웨어, 검증 실패 메시지에 입력값을 그대로 넣는 코드가 대표적인 유출 경로입니다. → 로그 마스킹
5. 여권번호·운전면허번호·외국인등록번호도 고유식별정보입니다. 외국인 회원 본인확인, 렌터카 예약 등에서 받는다면 별도 동의(제24조제1항제1호) 또는 법령 근거가 필요하고, 서면 동의 시 중요한 내용으로 표시해야 합니다(시행령 제17조제3항제2호나목).
6. 5만명 기준을 기억합니다. 고유식별정보 5만명 이상 처리 시 정기 조사 대상(시행령 제21조제2항제3호), 수집 출처 통지 대상(시행령 제15조의2제1항제1호)이 됩니다.

권장 설계

주민번호가 필요한가?
├─ 아니오 (대부분) → 수집하지 않음. 본인확인 결과값·생년월일·성인 여부 플래그로 대체
└─ 예: 근거 법령 조문을 설계 문서에 기재 (제24조의2제1항제1호)
    ├─ rrn_vault 테이블 (별도 스키마)
    │   ├─ subject_id
    │   ├─ rrn_ciphertext     ← AES-GCM 등, 키는 KMS
    │   ├─ rrn_lookup_hmac    ← 중복 검사용 (키 분리), 필요할 때만
    │   └─ legal_basis: "법령명 제N조"  ← 법무 확인값
    ├─ 화면 표시: 마스킹 기본, 원문 조회는 권한 + 사유 + 접속기록
    └─ 보존기간 경과 시 파기 배치

• 회원가입 경로에는 주민번호 입력란이 존재하지 않도록 하고(제24조의2제3항), 이를 E2E 테스트로 고정합니다.
• 파일 업로드(신분증 사본)를 받는 경우 이미지 안의 주민번호도 같은 수준으로 보호해야 합니다. 뒷자리 마스킹 업로드를 안내하거나 OCR 후 원본을 즉시 파기하는 방안을 검토하세요(프로젝트 권장사항).

위험한 설계

• “고객이 동의했으니” 주민번호를 수집 — 동의는 근거가 되지 않습니다
• 중복가입 방지를 위해 주민번호를 솔트 없는 SHA-256으로 저장 — 주민번호 공간은 작아 전수 대입으로 복원 가능하며, 이는 처리 제한을 피하는 방법이 아닙니다
• 주민번호를 사용자 기본 키·조인 키로 사용
• 신분증 사본 이미지를 일반 파일 스토리지에 공개 URL로 저장(제34조의2 공중 노출)
• 입력 검증 오류 로그에 주민번호 원문 기록

Python/TypeScript 구현 예제

# 주민번호 패턴을 요청 로깅·에러 메시지에서 제거하고, 회원가입 스키마에 주민번호 필드가 없음을 테스트한다
import re
from pydantic import BaseModel

RRN_PATTERN = re.compile(r"\b(\d{6})[- ]?([1-8])\d{6}\b")

def mask_rrn(text: str) -> str:
    return RRN_PATTERN.sub(lambda m: f"{m.group(1)}-{m.group(2)}******", text)

class SignupRequest(BaseModel):
    email: str
    password: str
    birth_date: str | None = None   # 생년월일이 필요하면 별도 필드로

FORBIDDEN_FIELDS = {"rrn", "resident_number", "jumin", "ssn"}

def test_signup_has_no_rrn_field():
    # 제24조의2제3항: 회원가입 단계에서 주민번호 없이 가입 가능해야 함
    assert FORBIDDEN_FIELDS.isdisjoint(SignupRequest.model_fields.keys())

def test_mask_rrn():
    assert mask_rrn("주민번호 900101-1234567 오류") == "주민번호 900101-1****** 오류"

// 법령 근거가 있어 주민번호를 보관할 때: 암호화 저장 + 마스킹 표시 (Node.js crypto)
import { createCipheriv, randomBytes } from 'node:crypto';

export function encryptRrn(rrn: string, key: Buffer): { iv: string; tag: string; data: string } {
  const iv = randomBytes(12);
  const cipher = createCipheriv('aes-256-gcm', key, iv); // 키는 KMS에서 가져온다
  const data = Buffer.concat([cipher.update(rrn, 'utf8'), cipher.final()]);
  return { iv: iv.toString('base64'), tag: cipher.getAuthTag().toString('base64'), data: data.toString('base64') };
}

export const maskRrn = (rrn: string) => rrn.replace(/^(\d{6})-?([1-8])\d{6}$/, '$1-$2******');

암호 알고리즘 선택과 키 관리는 암호화를, 전체 예제는 구현 예제를 참고하세요.

개발 체크리스트

• 주민등록번호를 수집하는 모든 경로에 근거 법령 조문이 문서화되어 있다(법무 확인, review-required)
• 회원가입 경로에 주민번호 입력이 없음을 테스트로 고정했다
• 본인확인·연령확인·중복가입 방지를 주민번호 없이 구현했다
• 여권번호·운전면허번호·외국인등록번호는 별도 동의 또는 법령 근거가 있다
• 고유식별정보는 별도 저장소에 안전한 알고리즘으로 암호화되고 키가 분리되어 있다
• 화면·다운로드·로그·에러 메시지에서 고유식별정보가 마스킹된다
• 신분증 사본 등 이미지 내 고유식별정보도 같은 수준으로 보호한다
• 고유식별정보 처리 규모가 5만명 이상인지 확인했다(정기 조사·통지 대상)
• 고유식별정보 처리 시스템의 접속기록을 2년 이상 보관한다(고시 제8조제1항제2호)

공식 원문 링크와 확인일

아래 “근거 구분표”와 “공식 원문 링크”를 참고하세요. 법률 제24조·제24조의2·제34조의2와 시행령 제19조·제21조·제21조의2, 안전성 확보조치 기준 제7조·제8조는 2026-10-23에 국가법령정보센터 Open API 현행본과 대조했습니다. 제24조의2제1항제3호의 보호위원회 고시, 주민번호 처리를 허용하는 개별 법령, 본인확인 대체 수단의 법적 성격은 원문 대조 전이라 review-required입니다.