한 독자가 LLM에 프롬프트를 보내기 전 PII(개인정보)를 비식별화(Redacting)하는 것에 관한 제 지난 포스트에 날카로운 질문을 남겼습니다. 의역하자면 다음과 같습니다: "만약 'ACME의 John'을 '[NAME] from [COMPANY]'로 비식별화한다면, 모델이 여전히 그가 누구인지 추론할 수 있을까요?"

네, 가능합니다. 그리고 이 문제를 파헤쳐 볼 가치가 있는데, 이는 많은 팀이 놓치고 있는 실제적인 한계를 지적하기 때문입니다. 비식별화는 모델이 볼 수 있는 식별자(Identifiers)를 처리할 뿐입니다. 모델이 당신이 남겨둔 나머지 정보들을 바탕으로 추론하는 것을 막지는 못합니다.

사람들이 하나로 취급하는 두 가지 문제
사람들이 "내 프롬프트에서 PII를 제외하라"고 말할 때, 보통은 서로 다른 두 가지를 걱정하고 있습니다:

1. 제3자의 로그에 그대로 남아 있는 직접적인 개인 데이터. 이메일, 전화번호, SSN(사회보장번호) 또는 카드 번호가 당신의 통제 범위를 벗어나 OpenAI나 Anthropic의 시스템에 그대로 남는 경우입니다. 이것이 대부분의 팀에게 실질적인 GDPR 및 HIPAA 노출 위험입니다.
2. 명백한 식별자가 사라진 후에도, 남겨진 정보를 통해 모델이 누군가를 추론하거나 재식별(Re-identifying)하는 경우.

비식별화는 첫 번째 문제를 완벽하게 해결합니다. 직접적인 식별자를 플레이스홀더(Placeholders)로 교체하면, 당신이 소유하지 않은 로그에 해당 정보가 그대로 나타나지 않습니다. 실제 컴플라이언스(Compliance) 작업의 상당 부분은 이 작업만으로 충분하며, 비용도 저렴합니다.

두 번째 문제는 성격이 다르며 더 어렵습니다. 이것은 사실 비식별화의 문제가 아닙니다.

추론 유출(Inference leakage)이 실제로 발생하는 방식
당신이 제거한 데이터가 다시 드러나는 세 가지 일반적인 방식은 다음과 같습니다:

준식별자(Quasi-identifiers). 단일 필드는 개인을 식별하지 못하지만, 여러 필드의 조합은 가능합니다. Latanya Sweeney의 유명한 연구 결과에 따르면, 우편번호(ZIP code), 생년월일, 성별의 조합은 미국인의 약 87%를 고유하게 식별할 수 있습니다. 이름과 이메일을 삭제하더라도 "3월에 합류한 Boise의 41세 심장 전문의"라는 정보를 남겨둔다면, 당신은 정확히 단 한 명의 인물을 묘사하게 될 수도 있습니다.

빈칸을 드러내는 문맥(Context). 주변 텍스트가 모델에게 정답을 알려준다면 플레이스홀더는 도움이 되지 않습니다. "[NAME]은 Austin에 있는 전기차 회사를 운영한다"라는 문장은 추측할 여지를 거의 남기지 않습니다. 당신이 모델에게 방법을 알려주었기 때문에, 모델은 빈칸을 채워 넣습니다.

희귀한 세부 정보. 특이한 직함, 구체적인 금액, 고객 지원 티켓에서 발췌된 독특한 문구 등입니다. 세부 정보가 독특할수록, 그것은 한 사람을 더 명확하게 가리킵니다.

실제로 취해야 할 조치
이것은 단순히 켜고 끄는 설정의 문제가 아니라 아키텍처(Architecture) 결정의 문제입니다. 몇 가지 실질적인 계층적 접근법은 다음과 같습니다:

식별자뿐만 아니라 컨텍스트(Context)를 최소화하십시오. 작업에 필요한 정보만 모델에 전달하십시오. 불만 사항을 요약하는 작업이라면, 고객의 나이, 직장, 도시 정보까지는 필요하지 않을 가능성이 높습니다. 데이터 최소화(Data minimization)는 가장 영향력이 큰 조치이지만, 대부분의 사람들이 간과하는 부분이기도 합니다.

필요한 준식별자(Quasi-identifiers)를 일반화하십시오. 작업이 허용하는 범위 내에서 구체적인 정보를 범주화(Bucket)하십시오. 정확한 나이는 연령대로, 도시는 지역으로 바꿉니다. "Boise의 심장 전문의"는 "의사"로 바꿉니다. 모델이 작업을 수행하는 데 필요한 정보는 유지하되, 재식별(Re-identification)을 유발하는 정보는 제거하십시오.

위협에 맞춰 보호 수준을 결정하십시오. 유일한 목표가 제어할 수 없는 로그에 직접적인 PII(개인 식별 정보)가 남지 않도록 하는 것이라면, 비식별화(Redaction)만으로 충분하며 거기서 멈춰도 됩니다. 만약 콘텐츠 자체가 추론(Inference)이 문제가 될 정도로 민감하다면, 이는 의도적인 설계 선택의 문제이며 비식별화 계층 위에서 이를 처리해야 합니다.

가장 엄격한 사례의 경우, 공유 모델을 사용하지 마십시오. 추론이 진정으로 용납될 수 없는 상황이라면, 명확한 해답은 자체 호스팅(Self-hosted) 또는 로컬 모델을 사용하는 것입니다. 텍스트가 제3자에게 전달되지 않는다면, 타인의 시스템에서 추론할 수 있는 것도 없습니다.

복구는 귀하의 측에서 수행하고 출력을 확인하십시오. 모델은 세부 정보를 다시 도입하거나 추측할 수 있습니다. 복구 단계를 직접 수행하고, 결과물이 사용자에게 도달하기 전에 검토함으로써 해당 위험을 통제할 수 있습니다.

비식별화의 위치
비식별화(Redaction)는 필수적인 첫 번째 계층입니다. 이는 명시적인 이메일, 전화번호, SSN(사회보장번호), 카드 번호, 이름 등이 귀하가 제어할 수 없는 로그에 그대로 남지 않도록 보장하며, 이는 구체적인 컴플라이언스(Compliance) 이점이자 가장 빠르게 적용할 수 있는 방법입니다. 추론 보호(Inference protection)는 콘텐츠의 민감도에 따라 선택하는 두 번째 계층입니다. 대부분의 팀에는 첫 번째 계층이 필요하며, 규제를 받는 고민감도 워크로드(Workload)에는 두 계층 모두가 필요합니다.

*제 도구에 대해 명확히 말씀드리자면: 제가 구축한 API는 첫 번째 계층을 수행합니다. 이 API는 직접 식별자(Direct identifiers)를 빠르게 프로세스 내에서 탐지 및 토큰화(Tokenize)하고, 응답 시 이를 복원합니다. 이 도구는 추론(Inference)을 차단한다고 주장하지 않는데, 그 이유는 추론이 프롬프트(Prompt)를 어떻게 설계하느냐와 어떤 컨텍스트(Context)를 전송하기로 선택하느냐에 달려 있기 때문입니다. 단순히 비식별화(Redaction) 단계만으로 LLM을 "프라이빗(Private)"하게 만든다고 말하는 사람은 무언가를 팔려고 하는 것입니다.
*

첫 번째 계층 처리가 필요하다면 LLM Privacy Shield on RapidAPI를 확인하세요. 두 번째 계층은 여러분의 몫이며, 이제 그것이 무엇인지 알게 되셨을 것입니다.

마치며
비식별화(Redaction)는 필요조건이지만 충분조건은 아닙니다. 직접 식별자를 제거하여 여러분이 소유하지 않은 로그에 남지 않도록 하세요. 추론할 수 있는 내용을 줄이기 위해 컨텍스트(Context)를 최소화하세요. 유지해야 하는 준식별자(Quasi-identifiers)는 일반화(Generalize)하세요. 그리고 가장 민감한 작업의 경우, 공유 모델(Shared models) 사용을 완전히 피하세요. 비식별화는 바닥(Floor)이지 천장(Ceiling)이 아닙니다.

'비식별화 후 복원(Redact then restore)' 패턴에 관한 첫 번째 게시물을 놓치셨다면, 여기에서 확인하실 수 있습니다: How to redact PII before sending prompts to OpenAI, Claude, or Gemini