핵심 답변: 개인정보 마스킹은 개인정보의 일부를 * 같은 문자로 가려 화면·문서·로그에서 개인을 바로 알아보지 못하게 하는 처리입니다. 법에 정의된 가명처리·익명처리와는 다른 실무 기법이며, 생성형 AI에서는 사람이 보는 화면뿐 아니라 프롬프트·RAG 문서·응답·로그까지 마스킹 범위를 넓혀야 합니다.
- 무엇을 가릴지 정합니다: 이름, 주민등록번호, 전화번호, 이메일, 주소, 카드·계좌번호, API 키 등 항목 목록을 만듭니다.
- 어디까지 보일지 정합니다: 업무에 필요한 최소 자릿수만 남기는 항목별 마스킹 기준을 문서로 정합니다.
- 어떻게 찾을지 정합니다: 형식이 정해진 값은 정규식, 이름·주소처럼 문맥이 필요한 값은 NER·AI 탐지를 함께 씁니다.
- 어디에 적용할지 정합니다: LLM 입력 전, 출력 후, 로그 저장 전 세 지점에 마스킹을 둡니다.
- 얼마나 잘 되는지 측정합니다: 놓친 값(미탐)과 잘못 가린 값(오탐)을 테스트 세트로 주기적으로 확인합니다.
최종 업데이트: 2026년 11월
개인정보 마스킹이란? 뜻과 가명처리·익명처리·암호화와의 차이
개인정보 마스킹은 값의 일부를 가려 노출을 줄이는 표시·처리 기법이며, 가명처리·익명처리·암호화와는 목적과 법적 지위가 다릅니다.
「개인정보 보호법」 제2조는 개인정보를 "살아 있는 개인에 관한 정보"로서 성명·주민등록번호 등으로 개인을 알아볼 수 있는 정보, 다른 정보와 쉽게 결합하여 알아볼 수 있는 정보, 그리고 가명정보로 정의합니다. 같은 조 제1호의2는 가명처리를 "개인정보의 일부를 삭제하거나 일부 또는 전부를 대체하는 등의 방법으로 추가 정보가 없이는 특정 개인을 알아볼 수 없도록 처리하는 것"으로 정의합니다. 반면 '마스킹'이라는 용어 자체는 법률 정의 조항에 없습니다. 마스킹은 가명처리를 할 때 쓰는 기법 중 하나가 될 수도 있고, 단순히 화면에 덜 보여 주는 조치일 수도 있습니다.
익명처리는 법 조문에 별도 정의가 있지는 않지만, 제58조의2는 "시간·비용·기술 등을 합리적으로 고려할 때 다른 정보를 사용하여도 더 이상 개인을 알아볼 수 없는 정보"에는 이 법을 적용하지 않는다고 규정합니다. 실무에서는 이런 상태로 만드는 처리를 익명처리라고 부릅니다. 암호화는 키가 있으면 원래 값으로 되돌릴 수 있는 보호 조치로, 제24조의2는 주민등록번호를 암호화 조치를 통해 안전하게 보관하도록 요구합니다.
| 구분 | 무엇을 하나 | 원래 값 복원 | 법적 지위(개인정보 보호법 기준) | 주 사용처 |
|---|---|---|---|---|
| 마스킹 | 일부 문자를 * 등으로 가림 | 가린 값만으로는 불가(원본은 보통 별도 보관) | 법률 정의 용어는 아님. 남은 정보로 알아볼 수 있으면 여전히 개인정보 | 상담 화면, 출력물, 로그, LLM 프롬프트 |
| 가명처리 | 일부 삭제·대체로 추가 정보 없이는 식별 불가하게 처리 | 추가 정보(매핑표 등)가 있으면 가능 | 제2조 제1호의2 정의. 가명정보는 여전히 개인정보이며 제28조의2~제28조의7 특례 적용 | 통계작성, 과학적 연구(AI 학습 포함), 공익적 기록보존 |
| 익명처리 | 다른 정보를 써도 더 이상 개인을 알아볼 수 없게 처리 | 불가 | 제58조의2에 따라 법 적용 제외 대상 | 공개 통계, 외부 공개 데이터 |
| 암호화 | 키로 값을 변환해 저장·전송 | 키가 있으면 가능 | 안전조치 수단. 주민등록번호는 제24조의2에 따라 암호화 보관 의무 | DB 저장, 전송 구간 |
정리하면, 마스킹을 했다고 해서 자동으로 가명정보나 익명정보가 되지는 않습니다. "홍동, 010-1234-**, 서울 종로구"처럼 남은 정보를 조합하면 특정인을 알아볼 수 있는 경우가 많기 때문입니다. 가명정보로 다루려면 개인정보보호위원회의 「가명정보 처리 가이드라인」이 안내하는 절차(사전 준비 → 위험성 검토 → 가명처리 → 적정성 검토 → 안전한 관리)를 따라야 합니다.
개인정보 마스킹 기준: 어떤 항목을 어디까지 가려야 하나
모든 업무에 똑같이 적용되는 단일 법정 마스킹 표준은 없으며, 업무에 필요한 최소 정보만 남긴다는 원칙에 따라 항목별 기준을 조직이 정해야 합니다.
참고할 만한 공식 자료로는 개인정보보호위원회가 2026년 10월 29일 고객센터 사전 실태점검 결과와 함께 발표한 「고객센터 개인정보 보호 4대 행동수칙」이 있습니다. 이 수칙은 상담 화면에서 이름은 첫 글자와 세 번째 글자만, 주소는 도로명 또는 법정동까지, 전화번호는 가운데 번호까지, 이메일은 아이디의 첫 두 글자와 도메인만 표시하고 나머지는 마스킹하는 방안을 권고합니다. 고객센터 업무를 대상으로 한 자율 권고이지만, 다른 업무 화면의 기준을 정할 때도 출발점으로 쓸 수 있습니다.
아래 표에서 이름·전화번호·이메일·주소 행은 위 개인정보위 권고를 옮긴 것이고, 주민등록번호·카드번호·계좌번호·API 키 행은 국내에서 흔히 쓰이는 일반적인 관행 예시입니다. 예시 값은 모두 가상의 값입니다.
| 항목 | 마스킹 예시(가상 값) | 남기는 부분 | 근거 |
|---|---|---|---|
| 이름 | 홍동 / 남궁동 | 첫 글자, 세 번째 글자 | 개인정보위 고객센터 행동수칙(2026.10.) |
| 전화번호 | 010-1234-* | 앞자리와 가운데 번호 | 개인정보위 고객센터 행동수칙(2026.10.) |
| 이메일 | ab@example.com | 아이디 첫 두 글자, 도메인 | 개인정보위 고객센터 행동수칙(2026.10.) |
| 주소 | 서울시 종로구 세종대로 | 도로명 또는 법정동까지 | 개인정보위 고객센터 행동수칙(2026.10.) |
| 주민등록번호 | 900101-1** | 생년월일, 성별 자리 | 일반적인 관행 예시 |
| 카드번호 | 1234-56--0000 | 앞 6자리 중 일부, 끝 4자리 | 일반적인 관행 예시 |
| 계좌번호 | 123--0000 | 앞 일부, 끝 일부 | 일반적인 관행 예시 |
| API 키·토큰 | sk-… | 접두어 정도만, 또는 전부 가림 | 일반적인 관행 예시(비밀값은 전체 차단 권장) |
기준을 정할 때는 다음을 함께 확인합니다.
- 항목 간 조합: 이름과 전화번호를 각각 가려도, 같은 화면의 다른 필드에서 가린 부분이 드러나면 의미가 없습니다. 항목마다 가리는 위치를 따로 정하지 말고 화면 단위로 검토합니다.
- 마스킹 해제 절차: 개인정보위 행동수칙은 상세 조회나 마스킹 해제가 필요하면 사유 입력, 추가 인증 같은 보호 절차를 두도록 권고합니다. 해제 기록은 접속기록으로 남깁니다.
- 업종별 규정: 금융·의료·공공 등은 별도 감독 기준이나 내부 규정이 있을 수 있으므로, 해당 기관의 최신 기준을 함께 확인합니다.
개인정보 마스킹 방법: 정규식, AI 탐지, 토큰화, 형식 보존
마스킹은 '찾기(탐지)'와 '바꾸기(치환)' 두 단계로 나뉘며, 값의 종류에 따라 탐지 방식과 치환 방식을 다르게 골라야 합니다.
1) 규칙·정규식 기반 탐지
주민등록번호, 전화번호, 카드번호, 이메일처럼 형식이 정해진 값은 정규식이 빠르고 결과를 설명하기 쉽습니다. 아래는 주민등록번호와 휴대전화 번호를 찾는 간단한 예시입니다.
import re
# 주민등록번호: YYMMDD-[1-8]XXXXXX (하이픈·공백 생략 허용)
RRN = re.compile(r"(?<!\d)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])[-\s]?[1-8]\d{6}(?!\d)")
# 휴대전화: 010 등 + 3~4자리 + 4자리
PHONE = re.compile(r"(?<!\d)01[016789][-.\s]?\d{3,4}[-.\s]?\d{4}(?!\d)")
def mask(text):
text = RRN.sub(lambda m: m.group()[:-6] + "******", text) # 성별 자리까지 남김
text = PHONE.sub(lambda m: m.group()[:-4] + "****", text)
return text
print(mask("고객 홍길동, 주민번호900101-1234567, 연락처 010-1234-0000"))
# 고객 홍길동, 주민번호900101-1******, 연락처 010-1234-****여기서 단어 경계 \b 대신 (?<!\d), (?!\d)를 쓴 이유가 있습니다. 파이썬 등 유니코드 정규식에서는 한글도 단어 문자로 취급되어 "주민번호900101-…"처럼 한글과 숫자가 붙어 있으면 \b가 일치하지 않습니다. 한국어 텍스트에서 흔히 생기는 미탐 원인입니다. 또 정규식은 "90.01.01" 같은 날짜나 주문번호를 주민등록번호·전화번호로 오인할 수 있으므로, 앞뒤 문맥 단어("주민", "연락처" 등)를 보조 조건으로 쓰면 오탐을 줄일 수 있습니다.
2) NER·AI 기반 탐지
이름, 주소, 소속처럼 형식이 일정하지 않은 값은 개체명 인식(NER) 모델이나 LLM 분류기로 찾아야 합니다. 한글 이름은 대부분 2~4글자이고 "김", "이" 같은 성이 일반 단어와 겹치며, 띄어쓰기 없이 "홍길동님", "김과장" 형태로 붙어 나오기 때문에 정규식만으로는 정확도를 확보하기 어렵습니다. 반대로 AI 탐지는 결과가 확률적이므로 같은 입력에도 판단이 흔들릴 수 있고, 처리 지연이 생깁니다. 실무에서는 형식 값은 정규식, 문맥 값은 AI로 나누는 하이브리드 구성이 일반적입니다.
3) 치환 방식 선택
| 치환 방식 | 예시 | 복원 | 적합한 경우 |
|---|---|---|---|
| 부분 마스킹 | 010-1234-* | 불가 | 사람이 보는 화면, 로그 |
| 전체 삭제·라벨 치환 | [전화번호] | 불가 | LLM 프롬프트, 학습 데이터 |
| 토큰화(가역 가명화) | <PERSON_1> ↔ 매핑표 | 매핑표가 있으면 가능 | LLM 응답 후 원래 값으로 되돌려야 하는 업무 |
| 형식 보존 치환 | 010-0000-0000 형태의 가짜 번호 | 방식에 따라 다름 | 테스트 데이터, 형식 검증이 있는 시스템 |
토큰화는 LLM 활용에서 특히 유용합니다. 프롬프트의 "홍길동"을 <PERSON_1>로 바꿔 모델에 보내고, 응답에 나온 <PERSON_1>을 사내 시스템 안에서만 원래 이름으로 되돌리면, 외부 모델에는 실제 이름이 전달되지 않습니다. 다만 매핑표는 원래 상태로 복원하는 추가 정보에 해당하므로, 법 제28조의4가 가명정보에 요구하는 것처럼 별도로 분리 보관하고 접근을 통제하는 것이 바람직합니다.
LLM·생성형 AI에서 개인정보가 새는 지점
생성형 AI에서는 사용자 프롬프트, RAG 검색 문서, 모델 응답, 로그, 학습·미세조정 데이터의 다섯 지점에서 개인정보가 노출될 수 있습니다.
OWASP는 「Top 10 for LLM Applications 2025」에서 민감정보 노출(LLM02:2025 Sensitive Information Disclosure)을 주요 위험으로 꼽고, 예방책으로 데이터 정제(sanitization)와 패턴 매칭 기반 토큰화·삭제(redaction)를 제시합니다. 개인정보보호위원회도 2025년 8월 6일 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」를 공개해, 생성형 AI 생애주기를 목적 설정, 전략 수립, 학습 및 개발, 적용 및 관리의 4단계로 나누고 단계별 안전조치를 안내했습니다. 이 안내서는 ChatGPT API 연계 같은 서비스형 LLM 활용, 오픈소스 LLM 활용, 자체 개발 등 유형별 기준도 다룹니다. 이용자 쪽에서는 개인정보위가 2026년 5월 발간한 「생성형 AI 서비스 이용자를 위한 개인정보 보호 가이드」가 업무 자료 입력 시 주의사항과 학습 활용 거부(옵트아웃) 설정 등을 안내합니다.
- 프롬프트: 직원이 고객 문의 원문, 계약서, 이력서를 그대로 붙여 넣는 경우입니다. 외부 LLM API를 쓰면 개인정보가 사외로 전송됩니다.
- RAG 문서: 사내 문서를 벡터 DB에 넣을 때 개인정보가 함께 색인되면, 권한이 없는 사용자의 질문에도 검색되어 응답에 인용될 수 있습니다.
- 모델 응답: 모델이 학습 데이터나 검색 결과에 있던 전화번호·이메일을 그대로 출력할 수 있습니다.
- 로그: 디버깅·품질 분석용으로 저장한 프롬프트와 응답 로그에 원문 개인정보가 남습니다. 로그는 접근 권한이 느슨한 경우가 많습니다.
- 학습·미세조정 데이터: 대화 기록을 미세조정에 재사용하면 모델이 개인정보를 기억해 재출력할 위험이 생깁니다.
사내 생성형 AI 사용 원칙을 먼저 정리하려면 생성형 AI 활용 가이드라인과 보안 체크리스트를, 온프레미스 LLM·RAG 구조 자체를 설계 중이라면 사내 AI 구축 방법을 참고하십시오.
LLM 개인정보 마스킹 적용 방법: 입력·출력·로그 세 지점
LLM 개인정보 마스킹은 모델 호출 전(입력), 응답 전달 전(출력), 저장 전(로그)의 세 지점에 각각 검사 단계를 두는 방식으로 구현합니다.
- 입력 단계: 사용자 프롬프트와 첨부 문서, RAG로 검색된 문서 조각을 모델에 넣기 전에 검사합니다. 주민등록번호·카드번호·API 키처럼 업무상 모델에 보낼 이유가 없는 값은 차단하거나 라벨로 치환하고, 이름처럼 응답에 다시 필요한 값은 토큰화합니다.
- RAG 색인 단계: 문서를 벡터 DB에 넣기 전에 마스킹하는 것이 검색 시점마다 가리는 것보다 안전합니다. 원본이 필요한 문서는 권한 기반 필터를 함께 적용합니다.
- 출력 단계: 모델 응답을 사용자에게 보내기 전에 같은 탐지기를 한 번 더 통과시킵니다. 입력에서 가렸더라도 모델이 다른 경로로 개인정보를 생성하거나 인용할 수 있기 때문입니다.
- 로그 단계: 프롬프트·응답 로그는 마스킹된 버전만 저장하고, 원문 보관이 필요하면 별도 저장소에 접근 통제와 보관 기간을 둡니다.
- 예외·해제 처리: 마스킹 해제나 차단 우회가 필요한 업무는 사유 기록과 승인 절차를 둡니다.
프롬프트 인젝션으로 시스템 프롬프트나 다른 사용자의 데이터를 빼내려는 공격도 결국 출력 단계에서 개인정보 노출로 이어지므로, 개인정보 마스킹과 인젝션 탐지는 같은 검사 지점에서 함께 운영하는 편이 효율적입니다. 구체적인 방어 구성은 프롬프트 인젝션 방어 방법: LLM 가드레일 구축 실전 가이드와 LLM 가드레일 구축 가이드(AX 4편)에서 다룹니다.
씨커스랩의 KYRA AI Guardrail은 이 입력·출력 검사 지점에 위치하는 LLM 가드레일로, 프롬프트 인젝션 차단과 함께 주민등록번호, 전화번호, 이메일, 카드번호, API 키 등 개인정보·민감정보를 탐지해 마스킹합니다. 직접 구축할지 도입할지 고민 중이라면 AI 가드레일 자체 구축 vs 도입 비교도 함께 보시기 바랍니다.
한국어 개인정보 탐지의 어려움과 테스트 방법
한국어 텍스트의 마스킹 품질은 미탐(놓친 개인정보)과 오탐(잘못 가린 일반 정보)을 함께 측정해야 판단할 수 있습니다.
한국어에서 자주 생기는 문제
- 주민등록번호 형식 변형: 하이픈 없이 13자리로 쓰거나, "900101 1234567"처럼 공백을 넣거나, 전각 숫자·한글 숫자를 섞는 경우가 있습니다. 외국인등록번호도 비슷한 13자리 형식이므로 함께 다룰지 정해야 합니다.
- 한글 이름: 성씨와 일반 단어가 겹치고("이번", "정리", "한국"), 호칭·직함이 붙으며("김대리님"), 외자 이름이나 복성(남궁, 선우)도 있습니다.
- 숫자 오탐: 주문번호, 송장번호, 날짜, 금액이 전화번호나 계좌번호 패턴과 겹칩니다.
- 문서 형식: 표, PDF, 이미지 속 텍스트는 줄바꿈과 칸 나눔 때문에 한 값이 여러 조각으로 쪼개질 수 있습니다.
테스트 절차
- 실제 업무 문서 형식을 본뜬 테스트 세트를 만들고, 개인정보 값은 모두 가상의 값으로 채웁니다.
- 항목별로 정답 위치를 표시해 두고, 탐지 결과와 비교해 재현율(놓치지 않은 비율)과 정밀도(올바르게 가린 비율)를 따로 계산합니다.
- 하이픈 생략, 공백 삽입, 한글과 숫자 붙여 쓰기 같은 변형 케이스를 의도적으로 추가합니다.
- 규칙이나 모델을 바꿀 때마다 같은 세트로 회귀 테스트를 돌립니다.
- 운영 중에는 차단·마스킹 로그를 표본으로 검토해 새로운 오탐·미탐 유형을 테스트 세트에 추가합니다.
주민등록번호, API 키처럼 노출 시 피해가 큰 항목은 오탐이 조금 늘더라도 미탐을 줄이는 쪽으로, 이름처럼 업무 문장에 자주 나오는 항목은 오탐이 업무를 방해하지 않는 수준으로 기준을 따로 잡는 것이 현실적입니다.
한눈에 정리
- 마스킹은 법률 정의 용어가 아니며, 마스킹만으로 가명정보·익명정보가 되지는 않습니다.
- 가명처리는 개인정보 보호법 제2조 제1호의2, 익명정보의 적용 제외는 제58조의2, 주민등록번호 암호화 보관은 제24조의2에 근거가 있습니다.
- 개인정보위는 2026년 10월 고객센터 행동수칙에서 이름·주소·전화번호·이메일 마스킹 권장 방식을 제시했습니다.
- 형식 값은 정규식, 이름·주소 같은 문맥 값은 NER·AI 탐지를 함께 쓰는 것이 일반적입니다.
- LLM 환경에서는 입력, RAG 색인, 출력, 로그의 네 지점을 모두 마스킹 대상에 포함합니다.
- 테스트 세트로 미탐과 오탐을 따로 측정하고, 규칙을 바꿀 때마다 회귀 테스트를 합니다.
자주 묻는 질문
개인정보 마스킹 기준은 법으로 정해져 있나요?
모든 업무에 적용되는 단일 법정 마스킹 표준은 없습니다. 개인정보 보호법은 안전성 확보조치 의무(제29조)와 주민등록번호 암호화(제24조의2) 등을 규정하고, 구체적인 표시 범위는 업무별로 정하도록 되어 있습니다. 개인정보위가 2026년 10월 고객센터 대상으로 제시한 마스킹 권장 방식이 참고할 수 있는 공식 예시입니다.
마스킹한 데이터는 가명정보인가요?
자동으로 그렇게 되지는 않습니다. 가명정보로 처리하려면 추가 정보 없이는 특정 개인을 알아볼 수 없어야 하고, 가명정보 처리 가이드라인의 위험성 검토와 적정성 검토 절차를 거쳐야 합니다. 화면 표시용 부분 마스킹은 대개 여전히 개인정보로 보고 관리해야 합니다.
ChatGPT 같은 외부 LLM에 고객 데이터를 넣어도 되나요?
처리 목적과 적법 근거, 위탁·국외 이전 여부, 서비스의 학습 활용 설정 등을 먼저 확인해야 합니다. 개인정보위의 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」가 서비스형 LLM 활용 유형의 고려 사항을 다룹니다. 기술적으로는 입력 전에 불필요한 개인정보를 차단·마스킹하는 것이 기본입니다.
정규식만으로 개인정보 마스킹을 할 수 있나요?
주민등록번호, 전화번호, 카드번호, 이메일처럼 형식이 일정한 값은 정규식으로 상당 부분 처리할 수 있습니다. 하지만 한글 이름, 주소, 자유 서술 속 개인정보는 정규식으로 찾기 어렵기 때문에 NER이나 AI 기반 탐지를 함께 쓰는 것이 일반적입니다.
개인정보 마스킹 솔루션을 고를 때 무엇을 확인해야 하나요?
한국어 형식(주민등록번호, 한글 이름) 탐지 품질, LLM 입력·출력·로그에 모두 적용할 수 있는지, 토큰화 후 원래 값 복원 지원 여부, 처리 지연, 탐지 규칙의 사용자 정의 가능 여부, 마스킹·차단 이력 기록 기능을 확인합니다. 가능하면 자사 문서 형식의 테스트 세트로 직접 오탐·미탐을 측정해 보는 것이 좋습니다.
참고 자료
- 국가법령정보센터, 「개인정보 보호법」(법률 제20897호, 2025. 10. 2. 시행) — 제2조, 제24조의2, 제28조의2, 제28조의4, 제29조, 제58조의2
- 개인정보보호위원회 보도자료(2026. 10. 29.), 「고객센터 개인정보, 불필요한 조회·이용과 일괄 노출 막도록 보호 강화」 — 고객센터 개인정보 보호 4대 행동수칙
- 개인정보보호위원회 보도자료(2025. 8. 6.), 「생성형 인공지능(AI) 개발·활용 위한 개인정보 처리 기준 제시한다」 — 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」
- 개인정보보호위원회 보도자료(2026. 3. 31.), 「가명정보 처리 가이드라인 전면 개정, '위험도 기반' 판단 체계 확립」
- 개인정보보호위원회 보도자료(2026. 5. 19.), 「생성형 AI 서비스 이용자를 위한 개인정보 보호 가이드」 발간
- OWASP, LLM02:2025 Sensitive Information Disclosure
