한 독자가 LLM에 프롬프트를 보내기 전 PII(개인정보)를 비식별화(Redaction)하는 것에 관한 제 지난 포스트에 날카로운 질문을 남겼습니다. 의역하자면 다음과 같습니다: "만약 '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-identify)을 유발하는 정보는 삭제하십시오.

위협에 맞춰 보호 수준을 결정하십시오. 유일한 목표가 제어할 수 없는 로그에 직접적인 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)을 완전히 사용하지 마세요. 삭제(Redaction)는 바닥(Floor)이지, 천장(Ceiling)이 아닙니다.

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