AI에게 "개인정보 좀 지워줘" — 심어둔 571건 중 136건이 그대로 남았습니다
개인정보를 심어둔 문서를 AI에 지우게 하고 결과물을 처음 열었을 때, 대괄호가 예쁘게 박혀 있길래 다 끝난 줄 알았습니다. 낭패였습니다. 그 대괄호 바로 옆에 원래 번호가 그대로 붙어 있었거든요. 결국 결과물 전량을 한 줄씩 기계로 대조하는 고생을 했고, 그러길 잘했습니다.
일꾼에게 서류 파쇄를 맡겼더니 파쇄기를 돌리는 대신 서류에 '파쇄함' 도장을 찍어서 돌려준 셈입니다. 문제는 사장이 한 장씩 뒤집어보지 않으면 알 수가 없다는 거죠. 그래서 한국형 개인정보 7종을 일부러 심은 문서 6종을 만들고, 지시 방식을 세 갈래로 나눠 108회 시켜봤습니다. 심어둔 개인정보는 모두 571건입니다. 2026년 8월 6일, 로컬 gemma3:4b와 qwen3-vl:8b 기준입니다.
문서·이름·번호는 전부 제가 지어낸 가상값입니다. 주민등록번호와 카드번호는 형식만 맞춘 무효값이고, 전자우편은 문서 예시 전용으로 예약된
.example도메인을 썼습니다. 실존 인물·계좌·카드와는 아무 관계가 없습니다.
개인정보 7종을 심고 세 가지로 시켜본 테스트 설계
월급 안 나가는 일꾼 둘에게 파쇄 업무를 맡기고 뒤를 캐는 설계입니다. 다만 이 녀석들이 지웠는지 안 지웠는지를 눈으로 세면 측정은 그 자리에서 무의미해집니다. 그래서 심은 값의 원본 문자열이 결과물에 남아 있는지를 기계가 대조하게 했습니다. 사람이 점수를 적어 넣을 자리는 없습니다.
문서는 여섯 갈래입니다. 입사 지원서, 임대차 계약서 발췌, 배송 안내, 사내 회의록, 고객 문의 접수, 동호회 명단. 각각에 이름·주민등록번호·휴대폰·전자우편·계좌번호·주소·카드번호를 섞어 심었습니다.
지시 방식은 이렇게 세 갈래로 나눴습니다.
- 막연히 — "이 문서에서 개인정보를 지워 주세요."
- 유형 열거 — 지울 일곱 가지를 이름부터 카드번호까지 하나하나 적어줍니다.
- 열거 + 표기 지정 — 위에 더해 "지운 자리는
[이름]처럼 대괄호로 바꾸고, 그 밖의 문장·날짜·금액·문서번호는 한 글자도 바꾸지 마세요."
세 갈래 모두 "처리한 문서 전체를 출력해 주세요"라는 같은 꼬리말을 붙였습니다. 이걸 안 붙이면 팔 사이 차이가 '무엇을 지우라 했는가'가 아니라 '문서를 돌려줬는가'로 오염되니까요.
여기에 축을 하나 더 뒀습니다. 지우면 안 되는 것도 같이 셌습니다. 접수번호, 계약금액, 회의 날짜, 상품명처럼 문서에 남아 있어야 정상인 토큰 499건을 따로 표시해두고, 그게 사라졌는지도 판정했습니다. 개인정보를 잘 지웠다는 말과 문서를 통째로 뭉갰다는 말은 전혀 다르니까요. 서류를 못 지운 일꾼도 문제지만 멀쩡한 계약금액까지 먹칠해 온 일꾼도 다시 시켜야 하는 건 마찬가지입니다.
결과: 넷 중 하나가 그대로 남았습니다
108회 중 한 모델이 빈 응답을 낸 1회를 빼고 107회를 집계했습니다.
| 항목 | 수치 |
|---|---|
| 심은 개인정보 | 571건 |
| 그대로 남은 것 | 136건 (23.8%) |
| 지우면 안 될 것을 지운 것 | 1 / 499건 (0.2%) |
| 개인정보 0건 유출로 끝난 회차 | 56 / 107회 (52.3%) |
| 작업 거부 | 0건 |
| 문서를 그대로 되돌려준 회차 | 0건 |
넷 중 하나가 살아남았습니다. 반대로 문서를 뭉개는 쪽은 거의 없었습니다. 보존해야 할 토큰 499건 중 사라진 건 딱 하나였고요. 즉 이 녀석들은 지나치게 조심스러워서 다 지워버리는 쪽이 아니라, 대충 훑고 넘어가는 쪽으로 틀립니다. 겁 많은 인턴이 아니라 대충 하는 인턴이라는 뜻이고, 결과물이 멀쩡해 보이는 이유가 여기 있습니다.
반쯤은 완벽했다는 점도 같이 봐야 공정합니다. 절반이 조금 넘는 회차에서는 심은 것을 하나도 안 흘렸습니다. 문제는 나머지 절반을 사람이 눈으로 골라내야 한다는 것이고, 그럴 거면 애초에 사람이 지우는 편과 뭐가 다른지 따져봐야 합니다.
가장 자세히 시킨 쪽이 가장 많이 샜습니다
지시를 꼼꼼히 쓸수록 잘 지울 거라고 생각했는데, gemma3:4b에서는 정반대가 나왔습니다.
| 지시 방식 | gemma3:4b 유출 | qwen3-vl:8b 유출 |
|---|---|---|
| 막연히 "지워줘" | 40 / 96 = 41.7% | 4 / 96 = 4.2% |
| 유형 7종 열거 | 29 / 96 = 30.2% | 2 / 91 = 2.2% |
| 열거 + 대괄호 표기 지정 | 59 / 96 = 61.5% | 2 / 96 = 2.1% |
가장 공들여 쓴 지시문이 가장 많이 흘렸습니다. 원문을 열어보니 이유가 한눈에 보입니다. 회의록에서 나온 실제 출력입니다.
- 입사 예정자 [주민등록번호] 950430-134**** 확인 완료
- 담당자 직통 010-7788-**** 으로 문의 접수
- 공용 계좌 110-233-**** 유지[주민등록번호]라는 표시는 붙였는데 원래 번호를 그 옆에 그대로 뒀습니다. 대괄호로 바꾸라는 지시를 "대괄호를 추가하라"로 알아듣고 치환이 아니라 삽입을 한 겁니다. 파쇄를 맡겼더니 서류에 '파쇄함' 도장만 찍어서 돌려준 꼴인데, 이 녀석은 그러고도 일을 끝냈다고 보고합니다.
이게 왜 제일 위험하냐면, 결과물이 가장 그럴듯해 보이기 때문입니다. 막연히 시킨 팔은 지운 자리가 빈칸으로 남아서 "어? 여기 뭐 있었는데" 하고 사람이 다시 보게 됩니다. 대괄호가 예쁘게 박힌 문서는 처리가 끝난 것처럼 보여서 그냥 넘어가게 되고요.
덩치 큰 일꾼(qwen3-vl:8b)에게서는 이 현상이 없었습니다. 같은 지시문인데 2.1%였으니까요. 즉 "자세히 쓰면 나빠진다"는 일반 법칙이 아니라, 작은 모델이 복잡한 지시를 절반만 알아듣는 방식이라고 읽어야 맞습니다.
무엇을 놓치는지는 유형마다 갈립니다
전체 571건을 유형별로 끊으면 이렇습니다.
| 유형 | 그대로 남음 | 비율 |
|---|---|---|
| 주소 | 30 / 71 | 42.3% |
| 계좌번호 | 19 / 53 | 35.8% |
| 카드번호 | 15 / 54 | 27.8% |
| 이름 | 38 / 143 | 26.6% |
| 휴대폰 | 31 / 125 | 24.8% |
| 주민등록번호 | 3 / 53 | 5.7% |
| 전자우편 | 0 / 72 | 0% |
전자우편은 한 건도 안 놓쳤습니다. 주민등록번호도 5.7%로 낮고요. 생긴 모양이 뚜렷한 것은 이 녀석들도 잘 잡습니다. @가 있으면 전자우편이고, 여섯 자리에 하이픈이 붙고 일곱 자리가 이어지면 주민등록번호니까요.
반대로 주소가 42.3%로 가장 많이 남았습니다. 주소는 정해진 모양이 없고, 무엇보다 개인정보처럼 안 생겼습니다. 실제로 흘린 자리는 대개 "집결지: 인천광역시 남동구 예술로 213, 5층 회의실" 같은 줄이었습니다. 사람이 봐도 이건 개인 주소가 아니라 모임 장소로 읽히죠.
문서 종류로 봐도 같은 결이 나옵니다. 이력서(11.1%)와 배송 안내(10.0%)처럼 연락처: 주소: 라벨이 칸마다 붙은 문서는 잘 지웠고, 회의록(35.6%)과 동호회 명단(38.2%)처럼 문장과 목록 사이에 개인정보가 흩어진 문서에서 크게 샜습니다. 회의록에서는 참석자 줄에 적힌 "총무팀 최민호 과장, 인사팀 정예린 대리"를 세 팔 모두 그대로 뒀습니다. 직함이 붙으면 이름이 아니라 직무 정보처럼 보이니까요. 일꾼 눈에는 그게 사람이 아니라 조직도로 읽힌 겁니다.
모델을 바꾸는 쪽이 지시를 고치는 쪽보다 컸습니다
두 모델을 나란히 놓으면 차이가 이렇습니다.
| 모델 | 유출 | 비율 | 0건으로 끝낸 회차 |
|---|---|---|---|
| gemma3:4b | 128 / 288 | 44.4% | 12 / 54 |
| qwen3-vl:8b | 8 / 283 | 2.8% | 44 / 53 |
16배 차이입니다. 같은 서류를 같은 지시서로 같은 날 시켰는데, 일꾼만 갈아 끼웠더니 이렇게 벌어졌습니다. 지시 방식을 바꿔서 얻은 최대 개선폭이 gemma3:4b 안에서 11.5%p(41.7%→30.2%)였던 것과 비교하면, 프롬프트를 다듬는 노력보다 모델을 갈아 끼우는 쪽이 훨씬 크게 작용했습니다.
반복 3회를 따로 봐도 24.6% / 24.0% / 22.9%로 흔들림이 없었습니다. 이 녀석들을 세 번 굴려 세 번 다 비슷했으니, 한 번 잘 나온 걸 붙잡고 쓴 숫자가 아닙니다.
그래도 마지막 하나는 둘 다 놓쳤습니다
qwen3-vl:8b가 흘린 8건을 열어보면 그중 7건이 같은 한 줄입니다. 동호회 명단의 집결지 주소요. 막연히 시켜도, 유형을 열거해도, 대괄호 표기를 지정해도 그 줄만은 계속 남았습니다. 잘하는 일꾼도 자기 눈에 안 보이는 자리는 끝까지 못 봅니다.
정리하면 두 모델의 공통 사각지대는 이렇습니다.
- 장소·조직처럼 보이는 주소 — "집결지", "사무실 위치"로 적힌 줄
- 직함이 붙은 이름 — "총무팀 최민호 과장"
- 라벨 없이 문장 안에 섞인 번호 — "공용 계좌 110-233-**** 유지"
공통점은 하나입니다. 개인정보 칸에 안 들어 있는 개인정보. 라벨이 붙은 칸은 두 녀석 다 잘 처리합니다. 문장 속에 녹아 있으면 못 봅니다. 로컬 RAG로 내 문서 검색 실측에서 문서를 통째로 밀어 넣을 때 확인했던 것과 같은 성격의 한계입니다.
그래서 어떻게 지울 것인가 — 상황별 추천
- 모양이 뚜렷한 것은 AI 말고 정규식으로 지우세요. 전자우편·주민등록번호·휴대폰·카드번호는 패턴이 고정돼 있어 정규식 다섯 줄이면 100% 잡힙니다. 이번 측정에서 AI가 흘린 휴대폰 31건도 전부
01[016789]-\d{3,4}-\d{4}한 줄에 걸립니다. 일꾼을 안 써도 되는 일에 일꾼을 붙이면 4분의 1이 새는 겁니다. - AI는 정규식이 못 잡는 것에만 쓰세요. 이름·주소처럼 모양이 없는 것 말입니다. 다만 이번 결과로는 그 둘이 제일 많이 새는 유형이기도 하니, 이 녀석에게 맡기되 결과물은 반드시 사람이 한 번 더 봐야 합니다.
- 대괄호 표기를 지정할 거면 "치환"이라고 못 박으세요. "
[이름]처럼 바꾸세요" 대신 "원래 값을 지우고 그 자리에[이름]만 남기세요. 원본은 결과물에 한 글자도 남기지 마세요"라고 쓰는 겁니다. 이번에 61.5%가 샌 원인이 정확히 이 한 문장의 애매함이었습니다. - 지운 뒤 반드시 역검사를 돌리세요. 원본 문서에서 지우려던 값 목록을 뽑아놓고, 결과물에 그 문자열이 남아 있는지 기계로 대조하는 겁니다. 이 글의 숫자를 낸 방식이 정확히 그거고, 코드로 치면 열 줄이 안 됩니다. 눈으로 검수하면 대괄호가 박힌 문서를 그냥 통과시킵니다.
- 진짜 개인정보라면 애초에 올리지 마세요. 이번 실험에서는
gemma3:4b와qwen3-vl:8b를 로컬에서 실행해 입력 문서를 외부 서비스로 보내지 않았습니다. 클라우드 서비스에 남의 주민등록번호를 붙여넣는 것은 마스킹 정확도 이전의 문제입니다. AI 회의록 정리 실측에서도 같은 이야기를 했습니다.
일반화할 것은 유출률이 아니라 사각지대의 형태입니다
비교 범위는 gemma3:4b와 qwen3-vl:8b 두 모델뿐입니다. 월급 한 푼 안 나가는 4B·8B짜리 일꾼이라 상용 대형 모델에 그대로 옮겨 적을 수 없습니다. 두 모델 사이에서만도 16배가 벌어졌으니, 모델이 바뀌면 숫자는 크게 달라진다고 보는 편이 맞습니다. 이 글에서 옮겨갈 수 있는 것은 비율이 아니라 "무엇을 놓치는가"의 성격 쪽입니다.
문서는 제가 만든 것입니다. 실제 업무 문서는 더 길고 지저분하고, 개인정보가 더 깊이 숨어 있습니다. 문서가 짧고 정갈할수록 유리한 조건이었으니, 실무 문서에서는 이보다 나빠질 가능성이 큽니다.
한 문서에 심은 개수가 4~8건입니다. 유형별 분모가 53~143건이라 주민등록번호 5.7% 같은 낮은 숫자는 한두 건이 뒤집히면 몇 %포인트씩 움직입니다. 단단한 것은 소수점이 아니라 순서입니다. 전자우편·주민등록번호가 잘 지워지고 주소·계좌가 잘 남는다는 순서는 두 녀석을 세 팔로 세 번씩 굴린 내내 일관됐습니다.
법적 기준을 다룬 글이 아닙니다. 어디까지 지우면 비식별 처리로 인정되는지는 이 측정의 범위 밖이고, 그건 기술 문제가 아니라 규정 문제입니다. 실제 업무에 적용할 때는 소관 규정을 따로 확인하세요.
정리
지워야 할 571건 중 136건이 살아남았고, 가장 자세히 시킨 지시가 가장 많이 흘렸습니다. 지금 쓰는 방식이 "일꾼에게 붙여넣고 지워달라고 한 뒤 눈으로 훑기"라면, 오늘 바꿀 것은 두 가지입니다. 모양이 뚜렷한 개인정보는 정규식으로 넘기고, AI가 지운 결과물은 원본 값 목록과 기계로 대조하는 것. 이 둘만 붙여도 이번에 샌 136건은 대부분 걸립니다. 인턴을 믿지 말고 검수 절차를 믿으라는, 사무실에서 늘 하던 이야기입니다.
이 글은 cinevyze 운영자가 해당 도구를 직접 테스트하고 결과를 비교·검수해 정리·편집했습니다. 판단·사실확인은 모두 사람이 했고, 글 다듬는 일부 과정에 AI 도구의 도움을 받았습니다.
댓글
댓글 쓰기