AI 프롬프트로 유출되는 것은 코드뿐만이 아닙니다. 고객 명단이 담긴 Excel 파일, Word 계약서, 인사 관련 이메일 스레드 등도 함께 유출됩니다. 실제 이름이 기기 외부로 단 하나도 나가지 않으면서 AI가 해당 문서들을 작업할 수 있게 하는 방법을 소개합니다.

이 논의를 시작하게 된 요청

AI 어시스턴트를 도입하는 모든 기업에서는 보통 몇 주 이내에 다음과 같은 패턴이 나타납니다:

"이 계약서를 요약해 줄 수 있나요?"
"이 워크북(Workbook)을 정리하고 지역별 합계를 추가해 주세요."
"이 이메일 스레드에 대한 답장을 초안으로 작성해 주세요."

이러한 문서들은 기업이 제3자에게 절대 넘겨서는 안 되는 데이터, 즉 고객 이름, 이메일 주소, 전화번호, IBAN(국제 은행 계좌 번호), 급여, 협상된 가격, 내부 제품 코드명 등으로 가득 차 있습니다. 단 하나의 송장(Invoice) 워크북만으로도 수십 명의 자연인을 식별할 수 있으며, 동시에 귀사의 전체 가격 구조를 드러낼 수 있습니다.

GDPR(일반 데이터 보호 규정)에 따르면, 해당 문서를 원격 AI API로 전송하는 것은 **제3자에 의한 개인정보 처리 (processing of personal data by a third party)**에 해당하며, 종종 EU 외부로의 전송을 수반합니다. 영업 비밀 보호에 관한 어떤 합리적인 해석을 따르더라도, 이는 귀사가 통제할 수 없는 인프라에 상업적 조건을 넘겨주는 행위입니다. 컴플라이언스(Compliance) 측면의 해답이 "AI를 사용하지 마라"가 될 수는 없습니다. 생산성 격차가 너무 크며, 사람들은 어쨌든 채팅창에 문서를 붙여넣을 것이기 때문입니다. 그림자 사용(Shadow usage)은 통제된 사용(Governed usage)보다 더 위험합니다.

따라서 이 프로세스를 승인해야 하는 사람들이 요구하는 실제 요건은 다음과 같습니다:

1. AI는 여전히 문서에 대해 **추론 (Reasoning)**할 수 있어야 합니다. 즉, 금액을 합산하고, 스레드에서 누가 무엇을 말했는지 추적하며, 동일한 인물이 세 개의 시트에 등장한다는 점을 이해할 수 있어야 합니다.
2. 개인을 식별하거나 민감한 값을 드러내는 그 어떤 것도 기기 외부로 나가서는 안 됩니다.
3. AI의 답변 — 텍스트 요약이나 수정된 문서 — 은 반드시 실제 값이 정확하게 복원된 상태로 돌아와야 합니다.

첫 번째 요구사항은 단순한 삭제(redaction) 방식이 실패하는 이유입니다. 모든 이름을 ███████로 바꾸면 AI는 계약의 두 당사자를 더 이상 구분할 수 없게 됩니다. 모든 금액을 [REDACTED]로 바꾸면 "지역별 합계를 구하라"는 요청은 의미가 없어집니다. 문서는 반드시 그럴듯한(plausible) 상태를 유지해야 합니다.

이것이 바로 가명화 (pseudonymization)입니다. 각 값은 **로컬에 보관된 단사 함수적 매핑 (bijective mapping)**을 통해 **동일한 형식의 대리 값 (same-format surrogate)**으로 교체됩니다. Jean Dupont은 또 다른 그럴듯한 사람 이름이 되고, 내부 이메일은 또 다른 유효한 이메일 주소가 되며, IBAN은 올바른 구조를 가진 다른 IBAN이 되고, 날짜는 일정한 오프셋(offset)만큼 이동된 날짜가 됩니다. 동일한 원본은 어디에서나 동일한 대리 값으로 변환되므로, 상호 참조 (cross-references)가 유지됩니다. 매핑 파일은 절대 기기를 벗어나지 않으며, 복원은 정확한 역치환 (reverse substitution) 방식으로 이루어집니다. 이때 '가장 긴 일치 항목 우선 (longest match first)' 방식을 사용하여, Jean-Pierre Dupont이 Jean Dupont 항목에 의해 절반만 복원되는 일이 발생하지 않도록 합니다.

탐지: 패턴, NER, 그리고 전수 조사

탐지는 세 가지 계층에서 실행됩니다. 각 계층이 실패하는 방식이 서로 다르기 때문입니다.

**검증된 패턴 (Validated patterns)**은 이메일 주소, 전화번호, IBAN, 카드 번호, 날짜와 같이 검증 가능한 구조를 가진 값들을 잡아냅니다. 공유할 만한 주의 사항이 하나 있습니다. 기성 인식기(off-the-shelf recognizers)는 종종 공개 접미사 목록(public suffix list)을 기준으로 이메일 도메인을 검증하는데, 이로 인해 내부 도메인(user@company.local, admin@host.internal)의 주소를 _거부_하게 됩니다. 이러한 주소들은 인프라를 드러내기 때문에 가명화가 가장 절실히 필요한 주소들입니다. 해결책은 로컬 부분/도메인 형태 요구 사항은 유지하되(코드 스니펫의 @decorator 등이 매칭되지 않도록), 공개 접미사 검증은 생략하는 허용적인 인식기(permissive recognizer)를 사용하는 것이었습니다.

NER (개체명 인식 (named-entity recognition), 로컬 Presidio + spaCy 사이드카를 통해 수행 — 탐지를 위해 클라우드로 전송되는 데이터는 전혀 없음)은 사람 이름, 조직, 위치와 같이 구조가 전혀 없는 값들을 잡아냅니다. 스프레드시트 조각에 대한 NER은 노이즈가 많습니다. 예를 들어 "Téléphone"과 같은 단일 단어 열 헤더가 개체로 태깅될 수 있습니다. 따라서 제외 목록 (exclusion list)은 사후 고려 사항이 아닌, 핵심 기능 (first-class feature)으로 다뤄져야 합니다.

**사전 스윕 (A dictionary sweep)**은 탐지 후에 실행됩니다. 매핑된 모든 값은 단어 경계(word boundaries)를 기준으로 모든 텍스트 조각을 대상으로 다시 검색되어, 탐지기가 놓친 사례(워크북의 제목 속성에 포함된 조직 이름, 셀 주석 중간에 언급된 인물 등)를 잡아냅니다. 승인된 엔티티(entities)는 대소문자 변형에 걸쳐 확장됩니다. 예를 들어 Acme Industries를 한 번 탐지하면 헤더에 있는 ACME INDUSTRIES도 대소문자 형태의 대리값(surrogate)을 통해 처리되며, 각 변형은 정확하게 복구됩니다.

숫자에는 별도의 규칙 시스템이 적용됩니다. 왜냐하면

실패 시 폐쇄(Fail-closed)가 다른 협상 불가능한 원칙입니다: 가명화될 수 없는 문서는 보류되고 명시적인 플레이스홀더로 대체됩니다. 개인정보 보호 도구의 실패 모드는 결코 '평문으로 전송'이어서는 안 됩니다.

전체 팀을 위해 작동시키기: 정책 팩 및 suggest

패턴과 NER은 귀사를 알지 못합니다. 내부 제품 코드명인 Project Nightingale은 어떤 모델의 학습 데이터에서도 민감한 용어로 존재하지 않습니다. 그리고 모든 프로젝트 관리자에게 정규 표현식(regex)을 유지하도록 요청할 수는 없습니다.

이것을 해결하는 두 가지 구성 수준이 있습니다:

• 문서 카테고리별 정책 패키지(policy pack) (재무, 인사, 가격 책정 등)를 중앙에서 관리하고 URL을 통해 배포하여 모든 장치에서 실행되는 모든 가명화 작업이 최신 버전을 사용하도록 합니다. 이 패키지는 정책(NER 활성화/비활성화, 언어, 금액 및 이미지 처리 방식), [용어] 사전, 그리고 [숫자] 규칙을 묶습니다. 전송은 https 전용이며, 패키지는 캐시됩니다 (접근 불가능한 서버는 캐시된 사본으로 폴백하며, 캐시도 없고 서버도 없으면 회사 정책 없이 실행하는 대신 오류가 발생합니다). 또한 각 패키지는 게시 시 **서명(signed)**되며 — 공개 키가 장치에 설치되면 서명이 없거나 변조되었거나 롤백된 패키지는 거부됩니다. 이 패키지는 로컬 파일과의 모든 충돌에서 우선권을 가집니다: 사용자의 제외 항목이 회사가 강제하는 용어를 무효화할 수 없습니다.
• 개인의 문서 옆에 위치한 로컬 파일(report-terms.txt, report-numeric.txt)이 이 패키지를 보완합니다.

'사전에는 무엇이 포함되어야 할까?'라는 콜드 스타트(cold-start) 문제는 suggest 명령어로 처리됩니다: 해당 카테고리의 대표 문서 몇 개를 입력하면, 후보 용어 파일(발생 횟수와 함께 NER 결과, 주석 처리된 '불확실' 섹션에 모든 대문자/약어 후보가 포함되며 보통 내부 코드가 숨겨지는 곳)과 후보 숫자 규칙 파일(숫자 열당 하나의 scale 라인으로 헤더가 주석 처리됨)을 출력합니다. 사람이 오탐지 항목을 제거하고, 수량 및 연도에 대해 scale을 keep으로 변경하며, 파일을 이름 지정하여 — 완료됩니다. 빈 페이지를 보는 대신 10분 만에 검토가 가능해집니다.

AI 워크플로우에 통합하는 세 가지 방법

CLI(Command Line Interface): 일회성 작업의 경우 pseudonymize report.docx는 report-pseudonymized.docx와 로컬 매핑 파일을 작성합니다; AI의 텍스트 답변은 depseudonymize를 통해 파이프라인으로 전달되며, 수정된 문서는 같은 방식으로 복원됩니다.

HTTP 프록시 (HTTP proxy), 투명한(transparent) 케이스를 위한 방식: AI 클라이언트의 API 트래픽이 양방향으로 가명화(pseudonymize)를 수행하는 로컬 프록시를 통과합니다. 첨부 파일은 외부로 나가기 전에 변환되며, 첨부된 문서의 값을 언급하는 프롬프트 텍스트는 문서가 사용하는 것과 동일한 대리값(surrogate)으로 AI에 전달됩니다(그렇지 않으면 사용자의 질문 자체가 첨부 파일의 익명성을 해제하게 됩니다). 문서 파일에 대한 도구(tool) 읽기 작업은 정화(swept)되며, AI의 스트리밍 응답은 실시간으로 복원됩니다. 사용자는 실제 이름을 입력하고 실제 이름을 읽지만, 서비스 제공업체(provider)는 오직 대리값만을 저장합니다.

MCP 서버 (MCP server), 네트워크 경로를 프록시할 수 없는 클라이언트(Claude Desktop)를 위한 방식: 하나의 도구는 로컬 문서를 읽어 가명화된 콘텐츠를 대화로 반환하며, 두 번째 도구는 답변을 복원하여 로컬 파일에 작성합니다. 이때 복원된 텍스트를 대화로 반환하지는 않는데, 이는 대화로 반환되는 모든 정보가 다음 턴(turn)에 서비스 제공업체로 다시 전송되기 때문입니다.

GDPR 관점에서의 정의 — 그리고 정의되지 않는 것

여기서는 정밀함이 중요합니다. 왜냐하면 "GDPR 준수 AI"는 마케팅 문구인 반면, 이 글은 엔지니어링 기술 문서이기 때문입니다.

이 기술이 구현하는 것은 GDPR의 의미에서의 가명화 (pseudonymization in the GDPR sense) (제4조 제5항)입니다. 즉, 별도로 분리되어 사용자의 통제하에 로컬에 보관되는 추가 정보(additional information) — 매핑(mapping) — 없이는 더 이상 특정 개인에게 귀속될 수 없는 개인정보를 의미합니다. 이는 데이터 최소화(data-minimization) 원칙 (제5조 제1항 (c)), 설계에 의한 데이터 보호(data-protection-by-design) (제25조), 그리고 처리 보안 조치 (제32조)를 뒷받침합니다. 서비스 제공업체가 받는 데이터는 사용자의 기기를 떠난 적이 없는 파일 없이는 그 누구도 식별할 수 없습니다.

이는 익명화 (Anonymization)가 아닙니다. 문맥을 통해 여전히 재식별이 가능할 수 있습니다. 예를 들어, 문서에 "[작은 마을]에 본사를 둔 회사의 CEO"라고 적혀 있다면, 이름에 가명을 사용하더라도 추론을 막을 수 없습니다. 탐지는 본질적으로 최선의 노력을 다하는 과정(best-effort)입니다. 바로 그렇기 때문에 잔여 채널(residual channels)은 침묵 대신 경고를 생성하며, 실패한 문서는 전달되는 대신 차단되는 것입니다. 가명 처리된 데이터는 GDPR(일반 데이터 보호 규정) 하에서 여전히 개인 데이터로 간주됩니다. 변환은 리스크를 줄이고 규정 준수(compliance)를 지원할 뿐, 규정 준수 의무를 면제해주지는 않습니다. 이와 다르게 주장하는 도구가 있다면 과장된 것입니다.

핵심 요약 (Takeaways)

1. 개연성(Plausibility)은 모든 것을 결정짓는 요구사항입니다. AI가 문서에 기반해 추론할 수 있어야 하므로, 대리 값(surrogates)은 형식, 상호 참조, 그리고 수치적 일관성(변환된 값에 따라 재계산되는 수식 등)을 유지해야 합니다. 편집(Redaction) 방식은 구축하기는 더 쉽지만 실무에서는 무용지물입니다.
2. 파일 형식은 가장 까다로운 난관(boss fight)입니다. 공유 문자열 테이블(Shared-strings tables), 서식 런(formatting runs), 슬라이드 마스터(slide masters), .rels 파트, RTF 이스케이프(RTF escapes) 등 원본 값은 시각적 검토로는 잡아낼 수 없는 곳에 숨어 있습니다. 원본 아카이브에 대해 '심고 검색하는(plant-and-grep)' 테스트로 커버리지를 확보하고, 다시 쓸 수 없는 모든 채널에 대해 강력하게 경고하십시오.
3. 팀 규모의 프라이버시는 배포의 문제입니다. 실패 시 차단(fail-closed) 검증 기능이 포함된 중앙 집중식 서명 정책 팩, 문서별 로컬 재정의(overrides), 그리고 suggest 부트스트랩을 활용하면, 아무도 하지 않는 번거로운 작업이었던 "사전 유지 관리"를 10분 내외의 검토 작업으로 바꿀 수 있습니다.

여기에 설명된 문서 가명화 기술은 코드 난독화 파이프라인과 함께 PromptCape에 포함되어 제공됩니다. CLI, 프록시(proxy), MCP 서버는 하나의 엔진과 하나의 세션 매핑을 공유합니다. 실제 작동 예시와 샘플 문서는 동반 리포지토리인 gitlab.com/gbreton7/promptcape-docs에서 확인할 수 있으며, 도구는 promptcape.com에서 3개월 동안 무료로 체험할 수 있습니다.