OpenAI가 텍스트에서 개인정보를 찾아 가리는 오픈웨이트 모델 'Privacy Filter'를 공개했다. Apache 2.0 라이선스이며, 로컬 환경이나 브라우저에서도 실행할 수 있고, 이름·이메일·전화번호·주소·계좌번호·날짜·URL·비밀정보까지 8개 범주를 탐지한다는 것이 확인된 사실이다.123
중요한 건 "PII 제거 기능이 하나 더 생겼다"가 아니다. 진짜 변화는 개인정보 보호가 정책 문서나 사후 통제의 문제가 아니라, AI 파이프라인 앞단에 들어가는 실행 인프라의 문제가 되고 있다는 점이다. 특히 원문 데이터를 클라우드에 보내기 전에 로컬에서 먼저 걸러낼 수 있다는 점 때문에, 이 도구는 기능보다 "신뢰를 어디에 둘 것인가"를 다시 묻게 만든다.14
질문은 "잘 가리나?"보다 "위험을 어디로 옮기나?"다
Privacy Filter는 토큰 분류 방식의 모델이다. 일반 LLM처럼 한 토큰씩 생성하지 않고, 입력 전체를 한 번에 읽어 각 토큰에 개인정보 라벨을 붙인다. 총 1.5B 파라미터지만 추론 시 활성 파라미터는 50M 수준이고, 문맥 길이는 128,000 토큰까지 지원한다.23
이 스펙이 실무에서 뜻하는 바는 분명하다. 긴 이메일 스레드, 상담 기록, 계약서 초안, 내부 위키 같은 비정형 텍스트를 "쪼개기 전에" 한 번에 훑을 수 있다. 즉, 기존 정규식 기반 필터가 문맥을 잃고 놓치던 케이스를 줄이려는 설계다.
하지만 여기서 판단 기준은 정확도 수치 하나가 아니다. 더 중요한 건 필터가 어디에 배치되느냐다.
업로드 전에 로컬에서 돌리면 원문이 외부 서버에 닿지 않는다. 이 경우 줄어드는 건 주로 데이터 이전 위험, 로그 유출 위험, 제3자 처리 위탁에 대한 부담이다. 반대로 이미 클라우드에 올린 뒤 서버 측에서 가리면, 저장·전송·감사 범위는 이미 넓어진 뒤다. 기능은 비슷해 보여도 위험의 위치가 다르다.
그래서 도입 전에 먼저 그려봐야 할 건 모델 성능표가 아니라 데이터 흐름도다. 민감 텍스트가 어디서 생기고, 어디서 복사되고, 어떤 로그에 남고, 어느 시점에 외부 모델 호출이 일어나는지. Privacy Filter는 그 흐름의 가장 앞에 둘 때 가치가 가장 크다.
Privacy Filter가 틀린 도구가 되는 순간들
OpenAI도 이 모델을 "익명화 보장"이나 "컴플라이언스 인증"으로 보지 말라고 명시했다.2 이 경고는 형식적인 면책 조항이 아니다. 실제 실패 방식이 꽤 뚜렷하기 때문이다.
첫째, 라벨 taxonomy 바깥의 민감정보는 기본적으로 못 잡는다. 이 모델의 기본 범주는 8개다.2 내부 고객 ID, 환자 차트 번호, 사번, 특정 사건번호처럼 조직 특화 식별자는 별도 파인튜닝 없이는 새기 어려울 수 있다.
둘째, 문맥적 재식별 문제는 남는다. 이름과 이메일을 지웠다고 해서 텍스트가 안전해지는 건 아니다. 작은 단서 몇 개만으로 개인을 다시 특정할 수 있다는 반론은 프라이버시 연구자들도 계속 제기해왔다.5 즉 "PII 제거"와 "프라이버시 보호"는 같은 말이 아니다.
셋째, 과잉 마스킹도 비용이다. 분석·검색·요약 품질이 떨어질 수 있다. 예를 들어 날짜를 모두 지우면 상담 이력의 타임라인 해석이 망가지고, URL을 전부 가리면 보안 분석 로그의 가치가 줄어든다. 프라이버시 필터는 보호 계층이지만, 동시에 데이터 손실 계층이기도 하다.
넷째, 다국어·비정형·짧은 문장에서 성능 저하 가능성이 있다. OpenAI는 주 사용 언어를 영어로 두고 있으며, 비영어권·비라틴 문자·분포 밖 데이터에서 성능이 떨어질 수 있다고 적었다.2 한국어 워크플로에 넣는다면 "글로벌 벤치마크 점수"는 거의 참고치일 뿐이다.
30분 안에 해볼 수 있는 현실적인 검증법
벤치마크만 보고 넣기엔 위험하다. OpenAI는 PII-Masking-300k 기준 F1 96% 수준을 제시했고, 수정 버전에선 97.43%까지 보고했다.4 다만 이런 숫자는 내부 문서, 고객 메일, 콜센터 요약, 슬랙 대화처럼 실제 데이터 분포를 대신하지 못한다.
빠르게 검증하려면 작은 사내 테스트셋이면 충분하다. 30~50개만 모아도 된다. 대신 반드시 "현실적인 텍스트"여야 한다. 복붙된 문의 메일, 실수 많은 상담 메모, 서식이 깨진 로그, 영어와 한국어가 섞인 문장처럼 실제 운영 데이터를 닮아야 한다.
평가는 단순 정답률보다 "놓쳤을 때의 피해"로 봐야 한다. 예를 들어 API 키 미검출은 즉시 실패, 이름 하나 누락은 조건부 통과처럼 심각도 기준을 먼저 정하는 식이다. 그리고 로컬 선행 필터링과 클라우드 후처리를 비교해보면 좋다. 어느 쪽이 더 많이 잡느냐보다, 어느 시점에서 원문 노출을 줄이느냐가 핵심이다.
실무적으로는 세 가지면 충분하다.
누락이 치명적인가.
과잉 마스킹이 제품 가치를 해치나.
파인튜닝과 운영 비용을 감수할 만큼 앞단 차단 효과가 큰가.
AI 입력의 '스팸 필터'가 될 가능성
Privacy Filter 자체보다 더 큰 신호는, 프라이버시 필터링이 앞으로 기본 계층이 될 수 있다는 점이다. 스팸 필터가 메일의 부가 기능이 아니라 필수 인프라가 된 것처럼, AI 앱도 입력 전처리 단계에 개인정보 필터를 붙이는 방향으로 갈 가능성이 크다.
특히 기업용 코파일럿, 브라우저 기반 AI, 고객지원 자동화, 내부 검색형 RAG에서는 고객이 "우리 데이터가 먼저 어디로 가는가"를 점점 더 따질 것이다. 이런 맥락에서 Privacy Filter는 완성형 해법이라기보다, 로컬 우선 프라이버시가 제품 기본값이 될 수 있음을 보여주는 사례에 가깝다.16
지금 이 변화를 가장 진지하게 봐야 하는 사람은 AI 기능을 붙이려는 팀 중에서도, 민감 텍스트가 이미 업무 흐름 속에 섞여 있는 팀이다. 법무, 헬스케어, 금융만이 아니다. 고객지원, 세일즈 운영, HR, 개발자 도구도 마찬가지다. 판단 기준은 간단하다. "PII를 가릴 수 있는가"가 아니라, "원문이 외부에 닿기 전에 위험을 줄여야 하는가"다. 그 답이 예라면, Privacy Filter 같은 로컬 우선 계층은 꽤 현실적인 선택지가 된다.
참고
1OpenAI releases open-source model that strips personal data from text
2openai/privacy-filter · Hugging Face
3GitHub - openai/privacy-filter: OpenAI Privacy Filter · GitHub
4OpenAI tackles a bad habit people have when interacting with AI
5OpenAI Releases Privacy Filter Model to Redact Personal Data (2)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.