입력 전 판단 기준과 비식별화 실습
2. 입력 전 판단 기준과 비식별화 실습
2.1 입력 전 세 가지 질문
앞 절의 법률 지식을 매번 떠올리며 일할 수는 없습니다. 실무에서는 판단을 세 가지 질문으로 압축합니다. 붙여넣기 전에 3초면 됩니다.
- 이 내용에 사람이 있는가: 이름, 연락처, 이메일뿐 아니라 특정인을 가리키는 어떤 단서라도 있는지 봅니다. 고객, 직원, 지원자, 거래처 담당자 모두 해당합니다.
- 회사 밖으로 나가면 곤란한 정보인가: 개인정보가 없어도 영업비밀, 소스코드, 인증 정보, 비밀유지 대상이면 멈춥니다.
- 원본 그대로일 필요가 있는가: 대부분의 업무 요청은 원본이 아니라 구조와 상황만 있어도 됩니다. 원본이 필요 없다면 가공해서 넣습니다.
세 질문을 표로 정리하면 다음과 같은 3단 구분이 됩니다. 3부에서 만들 사내 가이드라인의 뼈대이기도 합니다.
| 구분 | 예시 | 처리 |
|---|---|---|
| 입력 금지 | 고객 명단, 주민등록번호가 포함된 문서, 상담 녹취 원문, 직원 평가서, API 키 | 어떤 계정으로도 입력하지 않습니다 |
| 가공 후 입력 | 고객 문의 메일, 오류 로그, 계약서 초안 검토 | 개인정보와 식별 단서를 제거·치환한 뒤 입력합니다 |
| 자유 입력 | 공개된 자료, 일반 지식 질문, 개인정보 없는 문서 서식, 집계 통계 | 통상적인 업무 판단으로 사용합니다 |
2.2 비식별화의 네 가지 기법
가공 후 입력 대상을 다룰 때 쓰는 기법은 네 가지입니다. 위에서부터 순서대로 검토하고, 강한 기법을 우선합니다.
- 삭제: 업무 요청에 필요 없는 정보는 지웁니다. 가장 확실합니다. 답장을 쓰는 데 고객 전화번호는 필요 없습니다.
- 치환: 필요하지만 실명일 필요는 없는 정보는 역할로 바꿉니다. "김위니 고객" → "고객", "이라이캣 팀장" → "팀장". 나중에 답변을 받아 실명을 되돌려 넣으면 됩니다.
- 마스킹: 형식이 중요한 경우 일부만 가립니다. "010-1234-5678" → "010-XXXX-XXXX". 다만 마스킹은 다른 정보와 결합하면 뚫리기 쉬우므로 삭제나 치환이 가능하면 그쪽을 택합니다.
- 범주화: 구체 값을 범위로 바꿉니다. "1987년 3월 12일생" → "30대", "서울시 마포구 성산동" → "서울".
2.3 실습 1: 고객 문의 메일
CS 담당자가 가장 자주 겪는 상황입니다. 아래 메일에 대한 정중한 답장을 AI에게 부탁하려 합니다.
원문을 그대로 붙여넣으면 안 되는 상태입니다.
제목: 배송 관련 문의드립니다
안녕하세요, 저는 지난주 화요일에 주문한 김위니입니다.
주문번호 WV-2026-07831이고요, 배송지를 서울시 마포구 성산동 123-45로
입력했는데 아직 배송 조회가 안 됩니다.
급한 건이라 제 번호 010-1234-5678로 연락 부탁드립니다.
세 가지 질문을 적용해 봅니다. 사람이 있고(이름, 주소, 전화번호, 주문번호), 원본 그대로일 필요는 없습니다. 답장을 쓰는 데 필요한 것은 상황뿐입니다. 가공하면 이렇게 됩니다.
다음 상황의 고객에게 보낼 정중한 답장을 써줘.
- 지난주 주문했는데 배송 조회가 아직 안 되는 상황
- 고객이 급하다며 전화 연락을 요청함
- 답장에 포함할 내용: 사과, 배송 상태 확인 후 오늘 중 전화드리겠다는 안내
호칭은 "고객님"으로 하고, 이름이 들어갈 자리는 [고객명]으로 남겨줘.
AI가 써준 답장의 [고객명] 자리에 실명을 채우는 일은 회사 안에서, 여러분의 손으로 합니다. 결과물의 품질은 원문을 통째로 넣었을 때와 거의 차이가 없습니다. AI에게 필요한 것은 고객의 신원이 아니라 상황이기 때문입니다.
2.4 실습 2: 오류 로그 붙여넣기
개발자와 운영 담당자의 흔한 상황입니다. 시스템 오류를 AI에게 물어보려고 로그를 복사했습니다.
2026-07-09 14:23:11 ERROR PaymentService - 결제 실패
user_email=weniv@example.com, phone=010-1234-5678
card_last4=1234, api_key=sk-live-Xj29fKd83hQz
Timeout waiting for response from https://pay.internal.weniv.co/v2/charge
이 다섯 줄에는 개인정보(이메일, 전화번호, 카드번호 일부)와 인증 정보(api_key), 내부 시스템 주소가 모두 들어 있습니다. 질문에 필요한 것은 오류의 구조뿐입니다.
2026-07-09 14:23:11 ERROR PaymentService - 결제 실패
user_email=[이메일], phone=[전화번호]
card_last4=[번호], api_key=[키]
Timeout waiting for response from [내부 결제 API 주소]
특히 API 키는 개인정보가 아니라서 방심하기 쉽지만, 유출되면 즉시 금전 피해로 이어질 수 있는 정보입니다. 로그나 코드를 붙여넣을 때는 개인정보와 인증 정보를 항상 함께 점검하는 습관이 필요합니다.
2.5 가공했는데도 뚫리는 경우
비식별화를 했다고 끝이 아닙니다. 다음 세 가지 함정을 알아야 합니다.
결합 식별: 하나하나는 익명 같아도 조합하면 특정됩니다. "40대, 남성, 우리 회사 부산 지점 근무, 최근 육아휴직"이라는 네 조각이면 이름 없이도 한 사람이 특정될 수 있습니다. 조직이 작을수록, 사례가 드물수록 적은 조각으로도 식별됩니다.
맥락 식별: "저희 회사에서 가장 큰 거래처가 계약을 해지하겠다고 보낸 메일인데"라는 문장은 이름을 다 지워도, 회사가 어디인지 아는 사람에게는 거래처가 특정됩니다. 희귀한 사건일수록 사건 자체가 식별자입니다.
첨부와 화면의 사각지대: 텍스트는 열심히 가렸는데 엑셀 파일을 통째로 업로드하거나, 스크린샷을 찍어 올리는 경우입니다. 스크린샷 구석의 이름, 엑셀의 숨긴 열과 다른 시트, 문서 파일의 작성자 메타데이터까지 함께 전송됩니다. 파일 업로드는 텍스트 붙여넣기보다 항상 더 위험하다고 기억하면 됩니다.
2.6 판단이 서지 않을 때
3초 판단으로 결론이 나지 않는 회색 지대는 반드시 존재합니다. 그럴 때의 규칙은 하나입니다. 혼자 결정하지 말고 개인정보 보호책임자나 보안 담당 부서에 물어봅니다. "물어보면 안 된다고 할 것 같아서" 그냥 진행한 사고가 실제 사고의 대부분입니다. 물어보는 문화를 만드는 것이 3부에서 다룰 회사의 몫입니다.