OpenAI가 Privacy Filter를 오픈소스로 공개했다. 1.5B 파라미터 규모지만 실제 추론에선 50M만 활성화되는 구조이고, PII 탐지와 마스킹에 특화된 토큰 분류 모델이다.12 표면적으로는 "새 PII 필터 모델 출시"지만, 실무에서 더 중요한 질문은 다르다. 이걸 어디에 둘 것인가다.
지금 이 발표가 중요한 이유도 여기에 있다. 기업들이 걱정하는 것은 모델 성능 그 자체보다, 민감한 원문이 프롬프트로 나가기 전에 새는지, 저장소와 로그에 남는지, 혹은 사람이 보기 전에 통제가 되는지다. Privacy Filter는 그 문제를 "모델 추가"가 아니라 "입력 경계 재설계"로 다루게 만든다.13
먼저 분류해야 할 것: 무엇을 막고 싶은가
Privacy Filter는 이름, 주소, 이메일, 전화번호, URL, 날짜, 계정번호, 그리고 비밀번호·API 키 같은 secret까지 8개 범주를 탐지한다.2 긴 문서를 한 번에 처리할 수 있도록 128K 컨텍스트를 지원하고, 텍스트를 생성하는 대신 한 번의 forward pass로 토큰 라벨링을 수행한다.2
이 사실이 뜻하는 바는 분명하다. 이 도구는 "대화형 AI의 축소판"이 아니라, 대량 텍스트 정제용 부품에 가깝다. 그래서 도입 판단도 세 가지로 나뉜다.
첫째, 외부 LLM에 보내기 전 프롬프트를 정리하려는 경우다. 이때는 Privacy Filter가 꽤 잘 맞는다. 온프레미스에서 돌릴 수 있고, 원문을 외부 API로 보내기 전에 1차 마스킹을 걸 수 있기 때문이다.24
둘째, 내부 문서나 로그를 저장하기 전에 민감정보를 줄이려는 경우다. 여기서도 유용하다. 특히 긴 로그, 콜센터 대화록, 문서 덤프처럼 비정형 텍스트가 많은 환경에서 정규식보다 문맥을 더 본다는 점이 장점이다.
셋째, 규제 대응까지 한 번에 해결하려는 경우다. 여기서는 기대를 낮춰야 한다. OpenAI도 이 모델을 익명화 도구, 컴플라이언스 보증, 안전 보장의 대체재로 보지 말라고 명시한다.2 즉 "적절한 첫 번째 레이어"일 수는 있어도, "최종 보증 장치"는 아니다.
이 모델은 스택 어디에 놓을 때 가장 효과적인가
가장 실용적인 위치는 대체로 ingress, 즉 데이터가 시스템에 들어오는 초입이다. 사용자가 문서를 붙여넣거나, 사내 시스템이 로그를 수집하거나, 외부 AI 호출 직전에 텍스트를 스캔하는 지점이다. 이 배치는 원문이 프롬프트, 서드파티 API, 관찰용 로그로 퍼지기 전에 위험을 줄인다.
저장 전 단계에 두는 것도 효과적이다. 데이터 레이크, 분석 저장소, 벡터DB에 들어가기 전에 마스킹하면 이후 재사용과 재학습, 검색 노출 리스크를 함께 낮출 수 있다. 특히 "일단 저장하고 나중에 정제"하는 조직에는 이쪽이 더 중요할 수 있다.
반면 출력 단계에만 두는 것은 방어선으로는 약하다. 응답에서 개인정보가 다시 튀어나오는지 잡는 용도로는 쓸 수 있지만, 이미 원문이 프롬프트나 로그에 남았다면 늦다. 즉 출력 필터는 보완책이지, 주 방어선이 아니다.
운영 관점의 트레이드오프도 있다. 초입에 둘수록 전체 노출면은 줄지만, 모든 입력에 지연과 운영 복잡도가 추가된다. 저장 전 배치는 배치 처리에 유리하지만 실시간 대화 보호에는 약하다. 그래서 보통은 "프롬프트 전 + 저장 전" 조합이 가장 현실적이고, 출력 필터는 고위험 업무에서만 덧대는 편이 낫다.
regex, Presidio, 클라우드 DLP보다 항상 나은가? 꼭 그렇진 않다
Privacy Filter의 장점은 문맥 인식, 로컬 실행, 장문 처리, 그리고 Apache 2.0 라이선스다.2 하지만 그 자체가 "무조건 더 좋은 선택"은 아니다.
정형 패턴이 분명한 데이터라면 regex가 여전히 가장 싸고 설명 가능하다. 전화번호, 이메일, 카드 번호처럼 형식이 강한 경우엔 과한 모델이 필요 없을 수 있다. 반대로 문서 길이가 길고, 이름·주소처럼 문맥 해석이 필요한 경우엔 Privacy Filter 쪽이 유리하다.
Presidio나 클라우드 DLP와 비교하면 선택 기준은 더 분명해진다. 정책 설명 가능성과 규칙 기반 커스터마이징이 중요하면 기존 DLP가 낫다. 반대로 온프레미스, 저비용, 비정형 텍스트, LLM 전처리가 중요하면 Privacy Filter가 강하다. 다만 라벨 정책을 런타임에서 동적으로 바꾸기 어렵고, 조직별 정책 차이는 파인튜닝으로 해결해야 한다는 제약이 있다.2
즉 "더 똑똑한 모델"보다 "충분히 위험을 낮추는 가장 단순한 도구"를 고르는 게 맞다. 보안과 프라이버시에서는 성능 수치보다 운영 예측 가능성이 더 중요할 때가 많다.
불편한 진실: 개인정보 필터링은 곧 프라이버시 안전이 아니다
여기서 가장 큰 오해를 피해야 한다. Privacy Filter가 잡는 것은 8개 범주의 텍스트 신호다.2 하지만 실제 리스크는 더 넓다.
예를 들어 비PII 기밀은 빠질 수 있다. 내부 프로젝트명, 미공개 계약 조건, 전략 문서 조각은 개인정보가 아니어도 치명적이다. 또 재식별 위험도 남는다. 이름을 지워도 날짜, 지역, 직책, 사건 맥락이 남으면 특정인을 다시 추정할 수 있다.
로그와 보관 정책도 별개 문제다. 필터링 전 원본이 애플리케이션 로그, APM, 디버그 덤프, 고객지원 툴에 남아 있으면 필터 도입 효과는 크게 줄어든다. 일부 현장 반응에서 오탐 문제가 지적된 것도 같은 맥락이다. 과검출은 문맥을 망가뜨리고, 실사용 신뢰를 떨어뜨린다.5
그래서 체크리스트는 모델보다 길어야 한다. 원문 로그 차단, 저장 전 마스킹, 고위험 워크플로의 사람 검수, 도메인별 평가셋, 그리고 "무엇을 개인정보로 볼 것인가"에 대한 내부 정책이 함께 있어야 한다.
Privacy Filter는 꽤 실용적인 공개 모델이다. 하지만 더 중요한 해석은 이것이다. OpenAI가 내놓은 것은 또 하나의 모델이 아니라, AI 파이프라인에서 프라이버시를 어디에 걸 것인지 다시 묻게 만드는 인프라 부품이다. 지금 신경 써야 할 사람은 새 모델을 찾는 팀보다, 이미 프롬프트·로그·문서 저장이 뒤섞인 채 운영 중인 팀이다. 그들에게 필요한 판단 기준은 "정확도가 몇 %인가"보다 "우리 데이터가 처음 노출되는 지점이 어디인가"다.
참고
2openai/privacy-filter · Hugging Face
3OpenAI Privacy Filter는 왜 '개인정보 차단'보다 에이전트 입력 경계 재설계에 가깝나
4GitHub - openai/privacy-filter: OpenAI Privacy Filter · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.