PII(개인 식별 정보)란? AI에 넣기 전 알아야 할 개인정보 개념
TL;DR
PII는 이름, 이메일, 전화번호, 주민등록번호, 얼굴 사진, 위치 정보처럼 특정 개인을 알아보거나 추적할 수 있는 정보입니다.
AI에 문서, 회의록, 고객 문의, 코드 로그를 넣을 때 PII가 섞여 있으면 개인정보 노출과 보안 사고로 이어질 수 있습니다.
AI를 안전하게 쓰려면 입력 전에 PII를 찾고, 꼭 필요 없는 정보는 삭제, 익명화, 가명처리, 마스킹한 뒤 사용해야 합니다.
핵심 3줄 요약
- 핵심 1
PII는 단독으로 또는 다른 정보와 결합했을 때 개인을 식별할 수 있는 정보입니다. - 핵심 2
AI 도구는 긴 문서와 대화 속 숨은 개인정보까지 처리할 수 있으므로 업로드 전 점검이 필요합니다. - 핵심 3
이름만 지웠다고 안전한 것은 아니며, 이메일, 위치, 직무, 계정 ID, 얼굴, 음성, 로그도 개인을 드러낼 수 있습니다.
이 글에서 다룰 내용
- PII의 한 문장 정의
- 왜 AI 사용자와 자동화 담당자가 꼭 알아야 하는지
- 챗GPT, 제미나이, 클로드에 자료를 넣기 전 떠올릴 쉬운 예시
- 개인정보, 민감정보, 익명화, 가명처리와의 차이
- 실전에서 PII를 줄이는 방법과 주의할 점
한 문장 정의
PII는 단독으로 또는 다른 정보와 결합해 특정 개인을 식별하거나 추적할 수 있는 정보입니다.
NIST CSRC 용어집은 personally identifiable information을 개인의 신원을 구별하거나 추적하는 데 쓸 수 있는 정보, 또는 특정 개인과 연결되거나 연결될 수 있는 정보로 설명합니다. 예로 이름, 사회보장번호, 생체정보, 생년월일, 출생지, 의료, 교육, 금융, 고용 정보가 포함됩니다. EU GDPR 원문은 personal data를 식별되었거나 식별 가능한 자연인과 관련된 모든 정보로 정의하며, 이름, 식별번호, 위치 데이터, 온라인 식별자 등을 예로 듭니다. Google Cloud Sensitive Data Protection 문서도 이메일 주소, 여권 번호, 얼굴 이미지, 금융 ID, 의료 데이터 같은 다양한 infoType을 민감 데이터 탐지 대상으로 다룹니다.
한 줄 정리: PII는 "이 정보가 누구의 것인지 알 수 있게 만드는 단서"입니다.
왜 PII가 AI 사용에서 중요한가
AI를 쓸 때 우리는 생각보다 많은 자료를 그대로 붙여 넣습니다. 고객 문의를 요약하고, 회의록을 정리하고, 채용 이력서를 비교하고, 상담 녹취를 분석하고, 오류 로그를 디버깅합니다. 이 자료 안에는 이름, 이메일, 전화번호, 계정 ID, 회사 내부 식별자, IP 주소, 위치, 결제 정보, 건강 정보가 섞일 수 있습니다.
문제는 AI가 이런 정보를 아주 잘 읽는다는 점입니다. 사람이 대충 넘기는 긴 문서 안에서도 AI는 개인을 나타내는 단서를 찾아 연결할 수 있습니다. 고객 이름을 지웠더라도 이메일 주소, 주문번호, 지역, 회사명, 직무, 날짜가 함께 있으면 특정 사람을 다시 추정할 수 있습니다.
AI 시대의 개인정보 관리는 "비밀번호만 넣지 않으면 된다"보다 넓습니다. 공개 AI 도구에 무엇을 입력하는지, API 요청과 로그가 어디에 저장되는지, 외부 앱이나 플러그인이 어떤 정보에 접근하는지까지 함께 봐야 합니다.
핵심 인사이트: PII는 법무팀만 다루는 용어가 아니라, AI에 자료를 넣는 모든 사람이 입력 전 확인해야 할 기본 체크포인트입니다.
쉬운 예시로 이해하기
예시 1. 고객 문의 요약
다음 문장을 그대로 AI에 넣는다고 생각해 보겠습니다.
"김민수 고객님이 010-1234-5678 번호로 연락했고, 6월 18일 주문한 상품을 강남구 사무실로 배송해 달라고 요청했습니다."
여기에는 이름, 전화번호, 주문 날짜, 배송 지역이 들어 있습니다. 이름과 전화번호는 직접 식별자에 가깝고, 주문 날짜와 지역은 다른 정보와 결합될 때 개인을 좁혀 가는 단서가 될 수 있습니다.
AI에 요약을 맡기려면 이렇게 바꾸는 편이 안전합니다.
"고객 A가 최근 주문 건의 배송지를 사무실 주소로 변경해 달라고 요청했습니다."
예시 2. 회의록 정리
회의록에는 참석자 이름, 직책, 발언 내용, 건강 상태, 인사 평가, 영업 기회, 내부 일정이 함께 들어갈 수 있습니다. 단순한 이름보다 "어떤 팀의 어떤 사람이 어떤 이슈를 겪고 있는지"가 더 민감할 수 있습니다.
예시 3. 개발 로그 분석
오류 로그에는 이메일, 사용자 ID, IP 주소, 세션 ID, API 키 일부, 파일 경로, 결제 식별자가 섞일 수 있습니다. 개발자는 로그를 기술 자료로만 보기 쉽지만, 실제로는 PII와 보안 정보가 함께 들어 있을 수 있습니다.
실전 팁: AI에 넣기 전에는 "이 문장만 보고도 사람, 계정, 고객, 위치, 건강, 결제, 직장 정보를 유추할 수 있는가"를 먼저 확인하세요.
헷갈리는 용어와 차이
PII와 개인정보의 차이
한국어로는 PII를 보통 개인 식별 정보 또는 개인정보에 가깝게 설명합니다. 다만 법률과 지역에 따라 범위가 다를 수 있습니다. 미국식 문맥의 PII는 개인을 식별하거나 추적할 수 있는 정보에 초점을 두고, GDPR의 personal data는 식별 가능한 사람과 관련된 모든 정보라는 넓은 표현을 씁니다. 실무에서는 좁게 해석하기보다 넓게 보호하는 편이 안전합니다.
PII와 민감정보의 차이
민감정보는 건강, 생체정보, 정치적 견해, 종교, 금융 정보처럼 노출될 때 피해가 큰 정보입니다. 모든 PII가 같은 수준으로 민감한 것은 아니지만, 민감정보는 대개 더 강한 보호가 필요합니다. 예를 들어 이메일 주소도 PII가 될 수 있지만, 질병 이력이나 계좌 정보는 더 높은 위험으로 봐야 합니다.
PII와 익명화의 차이
익명화는 개인을 다시 알아볼 수 없도록 식별 가능성을 제거하는 처리입니다. 이름만 지우는 것은 익명화가 아닐 수 있습니다. 나이, 지역, 직무, 날짜, 희귀한 사건이 남아 있으면 다시 특정 개인을 찾을 가능성이 생깁니다.
PII와 가명처리의 차이
가명처리는 이름을 "고객 A"처럼 바꾸는 방식입니다. 하지만 별도 표를 통해 고객 A가 누구인지 다시 연결할 수 있다면 완전한 익명화가 아닙니다. AI 입력에는 가명처리가 도움이 되지만, 연결 키와 원본 데이터 관리가 함께 필요합니다.
PII와 API 키의 차이
API 키는 사람의 신원을 직접 나타내는 정보라기보다 서비스 접근 권한을 주는 비밀 값입니다. 하지만 계정과 연결되어 있으면 보안 사고와 개인정보 사고를 함께 일으킬 수 있습니다. 그래서 PII와 API 키는 둘 다 AI 입력에서 제거해야 할 고위험 정보입니다.
비교 정리: PII는 개인을 알아볼 수 있는 단서, 민감정보는 노출 피해가 큰 정보, 익명화는 재식별 가능성을 제거하는 처리, 가명처리는 이름을 다른 표식으로 바꾸는 처리입니다.
실전에서 어떻게 쓰이나
PII 개념은 AI를 쓰는 거의 모든 업무에 들어갑니다.
- 고객 상담 요약 전에 이름, 전화번호, 주문번호를 제거할 때
- 채용 자료를 AI로 비교하기 전에 지원자 식별 정보를 가릴 때
- 회의록을 요약하기 전에 참석자와 민감 발언을 정리할 때
- 개발 로그를 AI에 넣기 전에 이메일, IP, 세션 ID, 토큰을 마스킹할 때
- 내부 지식 검색이나 RAG 시스템에 문서를 넣기 전에 접근 권한과 개인정보 포함 여부를 점검할 때
- AI 에이전트가 이메일, 캘린더, 드라이브에 접근하기 전에 어떤 정보가 외부 도구로 전달되는지 확인할 때
Google Cloud 문서는 Sensitive Data Protection이 정보 유형, 즉 infoType을 기준으로 이름, 이메일, 전화번호, 식별번호, 신용카드 번호 같은 민감 데이터를 탐지한다고 설명합니다. 이런 접근은 AI 자동화에서도 유용합니다. 사람이 먼저 감으로 판단하는 대신, 탐지 규칙과 검토 절차를 만들어 두면 반복 업무에서 실수를 줄일 수 있습니다.
실전 팁: AI 입력 전 점검 순서는 간단합니다. 첫째, 원문에서 PII를 찾습니다. 둘째, 작업에 필요 없는 PII를 삭제합니다. 셋째, 필요한 경우 가명이나 범주로 바꿉니다. 넷째, 결과물에 PII가 다시 나타나지 않았는지 확인합니다.
주의할 점
PII 관리는 "이름을 지우기"로 끝나지 않습니다.
첫째, 여러 약한 단서가 합쳐지면 개인을 식별할 수 있습니다. 직장, 팀, 날짜, 지역, 사건, 직책이 함께 있으면 이름이 없어도 사람을 좁혀 갈 수 있습니다.
둘째, AI 입력뿐 아니라 출력도 확인해야 합니다. 모델이 원문에 있던 개인정보를 요약문, 표, 이메일 초안에 다시 노출할 수 있습니다.
셋째, 자동 탐지 도구는 완벽하지 않습니다. Google 문서도 built-in infoType detector가 규제 준수를 보장하는 완전한 탐지 방법은 아니며, 조직이 민감 데이터와 보호 방식을 직접 결정해야 한다고 안내합니다.
넷째, 서비스 약관과 데이터 처리 방식을 확인해야 합니다. 같은 AI 기능이라도 개인 계정, 기업 계정, API, 외부 앱 연결, 로그 보관 설정에 따라 데이터 처리 조건이 달라질 수 있습니다.
다섯째, 실제 개인정보 보호 의무는 국가, 산업, 데이터 종류에 따라 달라질 수 있습니다. 의료, 금융, 교육, 채용, 미성년자 데이터는 일반 업무 문서보다 더 엄격하게 다뤄야 합니다.
주의: 이 글은 법률 자문이 아닙니다. 실제 서비스 운영, 고객 데이터 처리, 해외 사용자 데이터, 고위험 산업 데이터는 조직의 보안, 법무, 개인정보 담당 기준을 따라야 합니다.
자주 묻는 질문
Q1. 이메일 주소도 PII인가요?
대부분의 실무 맥락에서는 PII로 봐야 합니다. Google Cloud 문서도 이메일 주소를 infoType으로 다루며 PII 그룹에 포함합니다. 회사 이메일처럼 공개되어 보이는 정보도 특정 개인이나 계정과 연결되면 보호 대상이 될 수 있습니다.
Q2. 이름만 지우면 AI에 넣어도 안전한가요?
항상 안전하지는 않습니다. 이름을 지워도 전화번호, 주소, 주문번호, 직무, 날짜, 지역, 고유 사건이 남아 있으면 개인을 다시 추정할 수 있습니다. 중요한 자료는 여러 식별 단서를 함께 제거해야 합니다.
Q3. 고객 문의를 AI로 요약하려면 어떻게 해야 하나요?
고객명, 연락처, 주소, 주문번호, 계정 ID를 먼저 제거하거나 가명으로 바꿉니다. 요약에 꼭 필요한 맥락만 남기고, 결과물에도 개인정보가 다시 나오지 않았는지 확인합니다.
Q4. 내부 문서에 있는 직원 이름도 PII인가요?
예, 특정 개인을 식별할 수 있으면 PII로 다루는 편이 안전합니다. 특히 인사 평가, 건강 정보, 급여, 징계, 고충 처리처럼 개인에게 영향을 줄 수 있는 내용은 더 조심해야 합니다.
Q5. AI가 PII를 자동으로 가려 주면 충분한가요?
도움은 되지만 충분하다고 단정하면 안 됩니다. 자동 탐지는 놓치는 항목이 있을 수 있고, 조직마다 민감하게 보는 데이터가 다릅니다. 자동 탐지, 사람 검토, 접근 권한, 로그 관리가 함께 필요합니다.
Q6. PII와 비밀번호, API 키는 같은 범주인가요?
같은 말은 아닙니다. PII는 개인 식별 단서이고, 비밀번호와 API 키는 접근 권한을 주는 비밀 정보입니다. 하지만 둘 다 AI 입력에 그대로 넣으면 피해가 클 수 있으므로 제거해야 합니다.
출처
마무리
PII는 AI를 안전하게 쓰기 위한 가장 기본적인 데이터 보안 용어입니다. 한 문장으로 다시 정리하면, PII는 단독으로 또는 다른 정보와 결합해 특정 개인을 알아보거나 추적할 수 있는 정보입니다.
챗GPT, 제미나이, 클로드에 자료를 넣기 전에는 "이 안에 사람을 알아볼 수 있는 단서가 남아 있는가"를 먼저 보세요. AI 활용이 많아질수록 좋은 프롬프트보다 먼저 필요한 습관은 개인정보를 줄이고, 필요한 정보만 안전하게 남기는 것입니다.
