팀들이 AI 도입에서 자주 하는 실수가 있습니다. 모델 품질, 프롬프트, 응답 속도는 집요하게 따지면서도, 정작 고객 문의 원문·상담 기록·사내 문서를 어느 시점에 가려야 하는지는 뒤로 미룹니다. 그러다 LLM 앞단, 로그 저장소, 평가 파이프라인 중 어딘가로 원문이 그대로 흘러갑니다.
OpenAI가 공개한 Privacy Filter는 이 문제를 정면으로 겨냥한 도구입니다. 텍스트에서 개인정보와 비밀정보를 찾아 마스킹하는 오픈웨이트 모델로, 온프레미스 실행과 상업적 활용이 가능한 Apache 2.0 라이선스로 배포됐습니다.12 중요한 건 "새 모델이 나왔다"가 아닙니다. 이제 질문은 이겁니다. 당신의 AI 파이프라인에서 프라이버시 강제는 정확히 어디에 있어야 하나?
진짜 결정은 사용 여부가 아니라, 마스킹 위치다
확인된 사실부터 보죠. Privacy Filter는 생성형 LLM이 아니라 양방향 토큰 분류 모델입니다. 1.5B 파라미터 규모지만 추론 시 활성 파라미터는 50M 수준이고, 128K 컨텍스트를 처리하며, 이름·주소·이메일·전화번호·날짜·URL·계좌번호·비밀정보까지 8개 범주를 탐지합니다.23 한 번의 forward pass로 토큰 라벨을 붙이고, Viterbi 디코딩으로 span을 정리하는 구조라 고속 처리용 전처리기에 가깝습니다.2
실무에서 배치 위치는 보통 셋입니다.
첫째, 수집 시점입니다. 티켓, 채팅, 문서를 저장하기 전에 먼저 가립니다. 이 방식의 장점은 명확합니다. 로그, 데이터레이크, 검색 인덱스에 원문이 남을 가능성을 가장 먼저 줄입니다. 규제가 센 조직이라면 기본값이 여기에 가까워야 합니다. 대신 원문 보존이 필요한 운영팀, 법무팀, 조사 대응 프로세스와 충돌할 수 있습니다.
둘째, 프롬프트 직전입니다. 원본은 내부에 보관하되, LLM에 보내기 전에만 마스킹합니다. 가장 현실적인 절충안입니다. 분석 정확도와 내부 운영 유연성을 유지하면서 외부 모델 전송 위험을 줄일 수 있습니다. 다만 "내부는 안전하다"는 가정이 필요하고, 이미 앞단 로그나 모니터링 도구가 원문을 먹고 있다면 늦습니다.
셋째, 출력 후 정리입니다. 모델 응답에 PII가 섞였는지 사후 검토합니다. 이건 보조 장치로는 유용하지만, 단독 방어선으로 두기엔 위험합니다. 입력 단계에서 이미 민감정보가 외부 시스템에 전달됐을 수 있기 때문입니다.
즉, Privacy Filter를 어디에 둘지는 모델 성능보다 리스크 지도에 따라 결정해야 합니다. "클라우드로 나가기 전"이 핵심인 팀과 "내부 저장 자체를 최소화"해야 하는 팀은 정답이 다릅니다.
Regex, Presidio, 클라우드 DLP보다 나은 순간과 아닌 순간
Privacy Filter가 빛나는 지점은 문맥입니다. 정규식은 전화번호, 이메일, 카드번호처럼 형식이 뚜렷한 데이터엔 여전히 강합니다. 싸고 빠르며 설명 가능성도 높습니다. 하지만 자연어 속 이름, 애매한 주소 조각, 비밀 키처럼 문맥이 필요한 경우는 자주 놓칩니다.
반대로 Presidio 같은 규칙+NER 혼합형 오픈소스는 커스터마이징과 조합이 좋습니다. 이미 운영 경험이 있는 팀도 많습니다. 다만 규칙 추가와 튜닝 비용이 쌓이기 쉽고, 긴 문맥에서 일관되게 span을 잡는 일은 손이 많이 갑니다. Privacy Filter는 이 구간을 더 적은 설정으로 처리하려는 선택입니다.
클라우드 DLP나 AWS·GCP 계열 서비스는 관리형 감사 추적, SLA, 조직 내 승인 절차에서 강합니다. 대신 데이터가 외부 서비스 경계를 넘습니다. 반면 Privacy Filter는 로컬, 브라우저, 온프레미스 실행이 가능하다는 점이 분명한 차별점입니다.24 데이터 거주성과 비용 예측 가능성이 중요한 팀엔 이게 더 중요할 수 있습니다.
하지만 여기서 반론도 분명합니다. Privacy Filter의 기본 분류 체계는 8개 범주로 고정돼 있고, 런타임에서 정책을 동적으로 바꾸는 방식이 아니라 추가 파인튜닝이 필요합니다.2 한국 주민등록번호, 의료기관 고유 식별자, 사내 고객번호처럼 도메인 특화 항목이 중요하다면 "그냥 가져다 쓰면 끝"은 아닙니다.
마스킹됐다고 안전해진 것은 아니다
OpenAI도 이 모델을 익명화 보장이나 컴플라이언스 보증 도구로 보지 말라고 명시합니다.2 이 경고는 형식적인 면책이 아니라 실제 설계 포인트입니다.
자동 마스킹은 다섯 군데서 자주 실패합니다. 희귀 식별자, 문맥으로만 드러나는 준식별자, 비영어권 이름·표기, 원문 일부만 가렸을 때 남는 재식별 가능성, 그리고 마스킹 때문에 깨지는 다운스트림 프롬프트입니다. 예를 들어 상담 요약 모델이 "누가 누구에게 무엇을 요청했는지"를 추론해야 하는데 사람 이름을 모두 같은 토큰으로 바꾸면, 개인정보는 줄어도 업무 정확도가 같이 떨어질 수 있습니다.
그래서 실무에선 한 겹 더 필요합니다. 규칙 기반 탐지로 명확한 패턴을 먼저 자르고, Privacy Filter로 문맥성 PII를 보완하고, 고위험 워크플로에는 샘플링 리뷰를 남기는 방식입니다. 마스킹은 버튼이 아니라 계층입니다.
전면 도입보다, 작은 파일럿이 먼저다
도입 판단은 간단한 파일럿으로 충분히 할 수 있습니다. 고객 문의, 상담 기록, 계약 문서처럼 실제 데이터와 닮은 평가셋을 100~300건 정도 만들고, 무엇을 반드시 가려야 하는지 먼저 정의하세요. 그다음 false positive와 false negative를 같이 봐야 합니다. 프라이버시 도구는 놓치는 것만큼 과하게 지우는 것도 문제이기 때문입니다.
성공 기준도 명확해야 합니다. 예를 들면 이렇습니다. "외부 LLM 호출 전 탐지 누락률 감소", "상담 요약 품질 하락 허용 범위", "추가 지연 시간", "예외 처리에 드는 운영 비용". 이 네 가지 없이 정확도 숫자만 보면 실제 운영 판단을 잘못하기 쉽습니다.
지금 Privacy Filter에 가장 먼저 관심을 가져야 할 팀은 두 부류입니다. 외부 LLM을 쓰지만 원문 전송이 늘 불안했던 팀, 그리고 이미 PII 마스킹을 하고 있지만 규칙 기반 한계에 부딪힌 팀입니다. 반대로 강한 감사 추적과 관리형 책임이 더 중요한 조직이라면, 이 모델은 주력 솔루션이라기보다 보완재일 수 있습니다.
결국 핵심은 도구 선택보다 위치 선택입니다. 프라이버시는 모델의 옵션이 아니라 파이프라인의 설계 문제입니다. OpenAI Privacy Filter가 던진 진짜 질문도 바로 그것입니다. 당신의 시스템은 개인정보를 언제, 어디서, 누구 책임으로 지울 것인가.
참고
1Introducing OpenAI Privacy Filter
2openai/privacy-filter · Hugging Face
3GitHub - openai/privacy-filter: OpenAI Privacy Filter · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.