LLM에 개인정보를 보내지 않고도 문맥을 유지하는 방법

프로젝트

이 글은 아이디어가 아니라 유민수 개발자가 만든 공개 구현체에 대한 설명이다

데포르매틱(Deformatic)의 유민수 개발자는 OPENAI Privacy Filter: Reversible Tokenization Layer를 공개했습니다. 이 프로젝트는 OpenAI의 Privacy Filter를 새 모델로 대체하려는 시도가 아닙니다. 이미 잘 정의된 개인정보 탐지 경로 위에, 기업 업무에서 필요한 복원 가능한 토큰화 레이어를 얹은 구현체입니다.

핵심은 간단합니다. 탐지는 OpenAI Privacy Filter가 맡고, 추가 레이어는 탐지된 민감 구간을 안정적인 토큰으로 바꾸며, 원문값은 별도의 볼트에 저장합니다. 이렇게 하면 LLM, RAG, 에이전트 워크플로우에는 원문 개인정보를 보내지 않고도 같은 사람, 같은 계좌, 같은 연락처가 문서 안에서 어떻게 연결되는지 유지할 수 있습니다.

핵심 문제

마스킹하면 안전하지만, 일이 안 된다

개인정보가 섞인 문서를 그대로 외부 시스템에 보내는 것은 어렵습니다. 고객명, 전화번호, 이메일, 계좌번호, 계약 상대방, 내부 URL, 접근 토큰 같은 값은 조직의 보안 정책과 컴플라이언스(compliance, 규정 준수) 검토를 바로 통과하지 못합니다.

그래서 많은 팀이 레닥션(redaction, 비가역 마스킹)을 먼저 떠올립니다. 이름을 지우고, 이메일을 지우고, 전화번호를 지우면 안전해 보입니다. 하지만 그 순간 업무 맥락도 같이 사라집니다. 같은 사람이 문서 안에서 여러 번 등장했는지, 특정 고객과 특정 계약이 연결되는지, 처리 후 원래 시스템에 어떤 값으로 되돌려야 하는지 알 수 없게 됩니다.

대안

필요한 것은 삭제가 아니라 분리다

이 문제의 좋은 중간 지대는 복원 가능한 가명처리(pseudonymization, 식별값을 다른 값으로 바꾸되 권한이 있으면 복원 가능한 처리)입니다. 원문 문서에서 민감값을 토큰(token, 대체 식별자)으로 바꾸고, 원래 값은 별도의 볼트(vault, 민감값 저장소)에 둡니다.

예를 들어 Alice emailed Bob. Alice called 555-1111.은 <PRIVATE_PERSON_1> emailed <PRIVATE_PERSON_2>. <PRIVATE_PERSON_1> called <PRIVATE_PHONE_1>.처럼 바뀝니다. 중요한 점은 같은 값이 같은 토큰으로 유지된다는 것입니다. LLM은 원문 개인정보를 보지 않아도 관계를 읽을 수 있습니다.

기존 구조

OpenAI Privacy Filter의 기본 경로는 비가역 레닥션이다

OpenAI Privacy Filter는 입력 문서에서 개인정보 span을 탐지하고, 해당 구간을 <PRIVATE_PERSON>, <PRIVATE_EMAIL> 같은 타입 기반 플레이스홀더로 바꿉니다. 이 기본값은 안전합니다. 원문값을 되돌릴 수 없도록 지우는 레닥션에는 이 방식이 맞습니다.

하지만 기업 업무에서는 이것만으로 부족한 순간이 생깁니다. 같은 고객이 여러 문장에 등장한다는 사실, 특정 이메일과 특정 계약이 연결된다는 사실, 승인 이후 원래 시스템에 다시 써야 하는 값이 사라집니다. 안전하지만 업무 처리가 끊기는 것입니다.

확장 구조

우리가 추가한 것은 탐지 모델이 아니라 복원 가능한 운영 레이어다

이 구현은 Privacy Filter의 모델 경로를 바꾸지 않습니다. 체크포인트, 디코더, 학습, 평가 경로를 건드리지 않고, 탐지된 span 이후에만 Reversible Tokenization Layer를 추가합니다.

• Token Resolver: 같은 라벨과 같은 원문값을 같은 토큰으로 재사용합니다.
• Reversible Vault: 토큰과 원문값의 매핑을 별도 저장소로 분리합니다.
• Restore Path: 권한이 있는 경계 안에서만 토큰화된 문서를 원문에 가깝게 복원합니다.

구현 구성

코드에는 API, CLI, 볼트, 테스트가 들어 있다

이 프로젝트는 발표 자료가 아니라 설치하고 읽을 수 있는 코드입니다. 공개 저장소에는 Python API, CLI 옵션, 볼트 직렬화, 복원 함수, 테스트가 함께 들어 있습니다.

중요한 설계 원칙은 opt-in입니다. 기존 redact() 동작은 그대로 두고, 명시적으로 OPF.tokenize()나 opf --recoverable을 호출할 때만 복원 가능한 토큰화가 동작합니다.

• opf/_core/reversible.py: ReversibleVault, VaultEntry, restore_text()를 구현합니다.
• Python API: OPF.tokenize()와 restore()로 애플리케이션 코드에서 바로 호출할 수 있습니다.
• CLI: --recoverable, --vault-in, --vault-out으로 배치 처리와 재사용을 테스트할 수 있습니다.
• 테스트: 안정적인 토큰 재사용, 라벨 간 분리, 볼트 저장/로드, 복원, 토큰 충돌 회피를 검증합니다.

주의점

볼트는 원문 개인정보와 같은 등급으로 보호해야 한다

이 구조를 익명화(anonymization, 원칙적으로 개인을 다시 알아볼 수 없게 만드는 처리)라고 부르면 안 됩니다. 더 정확한 표현은 복원 가능한 가명처리입니다. 토큰화된 문서만 있으면 원문을 알기 어렵지만, 볼트가 함께 유출되면 원문 복원이 가능합니다.

따라서 프로덕션(production, 실제 운영 환경)에서는 JSON 파일로 볼트를 저장하는 수준에서 멈추면 안 됩니다. KMS 기반 암호화, 테넌트(tenant, 고객 또는 조직 단위) 분리, TTL, 삭제 정책, 감사 로그, 복원 요청 승인 흐름이 함께 있어야 합니다.

업무 적용

이 구조가 열어주는 업무

도입 체크리스트

도구보다 먼저 물어야 할 질문

• 어떤 민감값은 복원이 필요하고, 어떤 값은 영구 삭제해야 하는가?
• 볼트 접근 권한은 LLM 호출 권한과 분리되어 있는가?
• 복원 요청은 누가 승인하고, 어떤 로그로 남는가?
• 테넌트별 볼트, 키, 보존 기간, 삭제 정책은 분리되어 있는가?
• 모델이 놓친 민감 구간을 사람이 검토하거나 정책으로 보완할 수 있는가?

전환 지점

담당자가 지금 결정해야 할 것은 모델이 아니라 데이터 경계다

이 글을 읽고 “우리도 비슷한 구조가 필요하다”고 느꼈다면, 바로 모델 비교표부터 볼 필요는 없습니다. 먼저 우리 조직의 상담 로그, 계약서, CRM 메모, 내부 지식 문서에서 어떤 값은 삭제하고, 어떤 값은 토큰화하고, 어떤 값은 승인된 경계 안에서만 복원해야 하는지 정해야 합니다.

데포르매틱(Deformatic)의 유민수 개발자는 이 오픈소스 구현을 기준으로 개인정보 탐지, 토큰화, 볼트 분리, 복원 승인, 감사 로그까지 이어지는 AI 데이터 경계 설계를 함께 검토할 수 있습니다. 핵심 질문은 하나입니다. “LLM이 봐야 하는 정보와 절대 보면 안 되는 정보를 어디서 나눌 것인가?”

AI 데이터 경계 설계 상담하기

결론

좋은 AI 도입은 “무엇을 보낼지”보다 “무엇을 안 보낼지”를 먼저 정한다

기업의 AI 도입은 더 강한 모델을 붙이는 문제만이 아닙니다. 어떤 데이터가 외부 처리 단계로 나갈 수 있고, 어떤 데이터는 내부 경계에 남아야 하며, 어떤 경우에만 복원할 수 있는지 정하는 운영 아키텍처 문제입니다.

레닥션은 출발점입니다. 하지만 실무 자동화까지 가려면 문맥을 살리는 토큰화와 원문을 지키는 볼트가 필요합니다. 유민수 개발자가 이 오픈소스를 공개한 이유는 하나입니다. 개인정보를 LLM에 보내지 않아도, 기업 업무는 충분히 이어질 수 있어야 합니다.

참고 자료

구현과 원자료

• 프로젝트 GitHub: 복원 가능한 토큰화 레이어 구현체.
• Hugging Face: OpenAI Privacy Filter 모델 가중치.
• OpenAI Model Card: Privacy Filter 모델 설명.