LLM 입력을 위한 토큰화: AI가 보지 않고 읽는 방법

이 맥락에서 대체가 실제로 하는 일

엔터프라이즈 문서와 외부 LLM 사이에 놓이는 변환 단계는 개념적으로 단순합니다. 경계를 넘길 수 없는 요소를 식별하고, 구조적 역할을 보존하는 대체어로 바꾼 뒤, 그 결과를 모델에 보냅니다. 실제로는 이 단순함 뒤에 접근 방식이 프로덕션 규모에서 작동할지, 부하가 걸릴 때 깨질지를 가르는 아키텍처 결정들이 숨어 있습니다.

이 글은 그 결정들을 하나씩 짚어봅니다. 특정 라이브러리나 제품 튜토리얼이 아닙니다. LLM에 넘기기 전 단계에서 민감값 대체를 도입하는 모든 팀이 명시적으로 내려야 하는 선택들과, 각 선택이 수반하는 트레이드오프입니다.

여기서 다루는 대체는 데이터 보호 관점의 작업입니다. 민감한 값을 나중에 다시 매핑할 수 있는 비민감 대체어로 바꾸는 것을 뜻합니다. 모델 입력을 서브워드 단위로 쪼개는 NLP 처리와는 이름이 겹칠 뿐 사실상 별개의 작업입니다.

CUBIG의 아키텍처에서 이 대체는 감지, 형식 보존, 선택적 통계적 보호까지 포함하는 더 넓은 문맥 보존 데이터 레이어(context-preserving data layer)의 핵심 치환 메커니즘입니다. 이 글은 그 치환 메커니즘 자체에 집중합니다. 구현이 이 메커니즘을 어떤 이름으로 부르든 설계 결정은 대체로 동일합니다.

엔터프라이즈 문서를 외부 LLM에 넘길 때의 목표는, 모델이 작업에 필요한 것은 모두 남기고 경계 안에 있어야 할 것은 모두 걷어낸 문서 버전을 모델에 보여주는 것입니다. 대체는 그 두 번째 절반을 담당하는 메커니즘입니다. 민감한 요소를 식별해 대체어로 치환합니다.

유용한 프레임이 하나 있습니다. LLM은 고객의 이름이 Marlene Schmidt라는 사실을 알 필요가 없습니다. 고객이 있다는 것, 그 고객이 문서 세 곳에서 참조된다는 것, 모든 참조가 같은 엔티티를 가리킨다는 것만 알면 됩니다. CUST-7F2A 같은 대체어는 신원을 담지 않으면서 바로 그 정보를 전달합니다. 여러 곳에 일관되게 나타나는, 참조 가능한 엔티티라는 정보입니다.

이것이 이 대체가 제공하는 핵심 속성입니다. 의미론적 공개 없는 참조적 무결성입니다. 대체어가 문서 전체에 일관되게 이어지므로 모델은 문서 전반에서 “고객”에 대해 추론할 수 있습니다. 대체어가 신원을 인코딩하지 않으므로 모델은 신원을 복원할 수 없습니다.

이 글의 나머지는 그 속성을 구현하는 여러 방식과, 그 위에 어떤 속성이 더 쌓이는지를 다룹니다.

그림 1 · 동일한 고객의 세 가지 다른 언급이 모두 하나의 일관된 대체어로 해소됩니다. LLM은 문서 전체에서 “고객”에 대해 추론할 수 있고, 실제 신원으로의 매핑은 엔터프라이즈 내부에 유지됩니다.

결정적 대체 vs 무작위 대체

첫 번째 아키텍처 결정은, 주어진 민감한 값이 항상 같은 대체어를 만들어내는지 아니면 매번 다른 대체어를 만들어내는지입니다.

결정적 대체

결정적 대체는 Marlene Schmidt가 모든 문서, 모든 워크플로우에서 항상 CUST-7F2A가 된다는 뜻입니다. 대체어는 값(그리고 보통 비밀 키)의 함수입니다.

이점은 문서 간 일관성입니다. 두 티켓이 같은 고객을 참조하면 LLM은 두 곳에서 같은 대체어를 보고, 문서 간 연결에 의존하는 분석이 그대로 작동합니다. 문서 전체를 집계하거나 비교하는 워크플로우, 즉 사기 감지 패턴, 고객 이력 요약, 코호트 분석에서는 결정적 방식이 보통 유일하게 실행 가능한 선택입니다.

비용은 결정론이 재식별 표면을 만든다는 점입니다. 충분히 많은 대체 처리된 문서를 관찰하고, 어떤 고객이 어디에 나타나는지에 대한 부가 정보를 가진 공격자는 대체어를 신원과 연관지을 수 있습니다. 이 위험은 대용량 워크플로우, 또는 같은 엔티티가 시간이 지나며 많은 대체 처리 출력에 반복해 나타나는 경우에 실재합니다.

무작위 대체

무작위 대체는 같은 값이라도 나올 때마다 다른 대체어를 만듭니다. Marlene Schmidt가 한 문서에서는 CUST-7F2A가 되고 다른 문서에서는 CUST-3B91이 될 수 있습니다.

이점은 문서 간 연결이 드러나지 않는다는 점입니다. 대체 처리된 각 문서는 독립된 시스템입니다.

비용은 문서 간 분석이 깨진다는 점입니다. LLM은 두 대체어가 같은 고객을 참조하는지 알 수 없습니다. 구조적 수준에서 그렇게 되어 있지 않기 때문입니다. 문서 간 연결이 필요 없는 워크플로우, 즉 단일 문서 요약이나 단일 계약에서의 조항 추출에는 무작위 방식이 잘 맞습니다. 연결이 필요한 워크플로우에서는 무작위 방식 탓에 LLM이 응답한 뒤에 연결을 복원해야 하므로 복잡성이 늘어납니다.

대부분의 프로덕션 배포가 쓰는 하이브리드 패턴

대부분의 프로덕션 배포는 하이브리드로 수렴합니다. 워크플로우 범위 안에서는 결정적(한 고객에 대한 멀티턴 대화가 일관성을 유지하도록), 워크플로우 범위 사이에서는 무작위(한 워크플로우의 분석이 다른 워크플로우와 상호 참조되지 않도록). 범위의 경계 자체가 설계 결정입니다. 세션별, 사용자별, 문서별, 테넌트별로 정의되며, 아키텍처가 라이브되기 전에 팀이 반드시 정해두어야 할 사항 중 하나입니다.

형식 보존 대체 — 단순 플레이스홀더 문자열로는 부족한 이유

단순한 구현은 민감한 값을 밋밋한 플레이스홀더로 바꿉니다. [CUSTOMER], [ACCOUNT_NUMBER], [DATE] 같은 것입니다. LLM은 이런 마커로 가득 찬 문서를 받아 추론을 시도합니다.

이 방식은 특정한 이유로 실제로는 잘 작동하지 않습니다. LLM의 추론은 입력의 표면 형태에 크게 좌우됩니다. “고객 Marlene Schmidt가 2026-03-15에 계정 4471-9028에 관해 연락했습니다”로 읽히는 문서는 모델에게 일관된 운영 기록으로 보입니다. 반면 플레이스홀더가 박힌 같은 문서, 즉 “고객 [CUSTOMER]가 [DATE]에 계정 [ACCOUNT_NUMBER]에 관해 연락했습니다”는 템플릿이나 검열 통지처럼 읽힙니다. 모델은 그 신호에 민감하게 반응하고, 그만큼 출력이 나빠집니다. 요약은 더 추상적이 되고, 추출은 덜 정확해지며, 모델이 이따금 검열 자체를 논평하는 쪽으로 새어 나갑니다.

형식 보존 대체는 교체 대상 값처럼 보이는 대체어를 만듭니다. 이름은 그럴듯한 이름 대체어가 됩니다. Lyra Vesper처럼요. 날짜는 그럴듯한 범위 안의 실제 날짜가 되고, 계정 번호는 실제 번호는 아니되 같은 길이·같은 형식의 숫자가 됩니다.

이렇게 하면 LLM이 보는 문서는 익명이지만 현실적인 대역이 들어간 일관된 운영 문서로 읽힙니다. 모델의 출력은 “템플릿을 두고 추론하라는 요청”이라는 인식으로 저하되지 않고, 모델이 실제로 낼 수 있는 품질로 돌아옵니다.

형식 보존에도 나름의 설계 선택이 있습니다. 대체어를 얼마나 그럴듯하게 만들지, 고정된 가짜 이름 풀에서 뽑을지 즉석에서 생성할지, 값 자체가 분석적 의미를 갖는 날짜·숫자를 어떻게 다룰지(정확한 날짜가 민감하더라도 2019년 날짜와 2024년 날짜의 차이는 분석에 중요할 수 있습니다) 같은 것들입니다. 일반 원칙은, 대체어가 원래 값이 가진 분석적 속성을 그 이상도 이하도 아닌 딱 그만큼만 보존해야 한다는 것입니다.

매핑의 위치

이 대체가 실제 효력을 갖는 것은 매핑, 즉 대체어를 원래 값에 연결하는 테이블이 엔터프라이즈 환경 내부에 유지될 때뿐입니다. 접근 방식이 실제로 원본을 경계 안에 두는지를 가장 일관되게 결정하는 부분이 바로 이 아키텍처입니다.

매핑의 세 가지 속성이 반드시 유지되어야 합니다.

1. 엔터프라이즈의 독점적 통제 아래 둡니다. 매핑은 사실상 데이터를 재식별하는 키입니다. 환경을 벗어나는 순간 원본 값은 새 위치의 통제 수준에 놓이게 됩니다. 데이터가 EU 리전이나 다른 정의된 경계 안에 있어야 하는 워크플로우에서는, 매핑도 같은 경계 안에, AI 엔드포인트가 아니라 소스 시스템 곁에 두어야 합니다.
2. 무결성을 보호합니다. 매핑을 변조하면 LLM의 응답이 돌아왔을 때 복원되는 내용이 바뀝니다. 매핑을 수정할 수 있는 공격자는 출력에서 신원을 바꿔치기할 수 있습니다. 표준 관행은 매핑 자체에 무결성 검사를 적용하는 것입니다. 서명된 항목과 접근 감사 로그로 변조를 감지할 수 있게 합니다.
3. LLM 워크플로우와 분리해 접근을 통제합니다. LLM 연동을 운영하는 팀에게 매핑에 대한 읽기 권한이 필요한 것은 아닙니다. 복원 단계는 프로그래밍 방식으로 매핑에서 값을 가져옵니다. 사람이 원래 값을 볼 필요가 없습니다. 두 접근 경로를 분리하면 매핑을 LLM 워크플로우 자체보다 더 엄격한 통제 아래 둘 수 있습니다.

저장 기술은 이 속성들에 비하면 부차적입니다. 매핑은 전용 데이터베이스, 키-값 저장소, 암호화된 파일, 또는 하드웨어 기반 보안 저장소 어디에 두어도 됩니다. 아키텍처 선택은 볼륨, 지연 요구 사항, 기존 인프라에 따라 달라집니다. 중요한 것은, 위의 세 속성이 구성 가능한 옵션이 아니라 협상 불가의 설계 제약이라는 점입니다.

대체어 일관성 — 동일 엔티티에는 동일 대체어

더 미묘한 설계 문제가 있습니다. 엔티티가 문서 안에서 서로 다른 방식으로 불리더라도, 같은 엔티티에는 일관되게 같은 대체어가 배정되도록 보장하는 일입니다.

서비스 티켓은 “고객”, 이어서 “Schmidt 씨”, 그다음 “Marlene”, 또 “가입자”라고 언급할 수 있습니다. 모두 같은 사람을 가리킵니다. 단순한 대체 엔진은 이 네 가지 언급을 각각 다르게 보고 네 개의 서로 다른 대체어를 만들어, LLM이 이 모두가 하나의 엔티티라는 사실을 추적하지 못하게 방해합니다. 돌아오는 요약이 이들을 네 사람으로 처리할 수도 있습니다.

이를 풀려면 대체 이전에 엔티티 해소가 필요합니다. 문서에서 어떤 언급이 같은 기저 엔티티를 가리키는지 식별하고, 모두 같은 대체어로 매핑되도록 보장하는 단계입니다. 일반적으로 간단치 않은 문제이고, 엔티티 해소는 그 자체로 하나의 연구 분야입니다. 다만 실무에서는 대체로 다룰 만합니다. 엔터프라이즈 문서에는 구조적 단서가 있기 때문입니다. 자유 텍스트 언급을 이어주는 헤더의 고객 ID, 운영 로그의 공식 명명 규칙, 구조화된 레코드의 스키마 정의 관계 같은 것들입니다.

일관성의 나머지 절반은 워크플로우 범위 안의 문서들 사이에 있습니다. 두 티켓이 같은 고객을 참조하고 워크플로우가 이들을 관련된 것으로 다뤄야 한다면, 대체는 두 곳에서 그 고객에 대해 같은 대체어를 만들어야 합니다. 앞서의 결정적 대 무작위 선택이 바로 여기서 맞물립니다. 범위 내 결정적 방식이야말로, LLM이 고객이 누구인지 알지 못하면서도 “같은 고객이 세 티켓에 나타난다”는 사실을 볼 수 있게 해주는 장치입니다.

잘 설계된 대체 레이어는 이 두 가지 일관성, 즉 문서 내 일관성과 범위 내 일관성을 변환 과정의 일부로 함께 처리합니다. 부차적으로 얹는 것이 아닙니다. 언급 단위로만 동작하는 대체 엔진에 일관성을 나중에 덧붙이는 팀은, 겉보기에는 모델 품질 문제 같지만 실은 데이터 준비 문제인 방식으로 워크플로우가 저하되는 것을 흔히 발견합니다.

추가 보호 레이어 — 대체만으로 부족할 때

대체는 치환 문제를 해결합니다. 대부분의 워크플로우에서는 매핑을 엔터프라이즈의 독점적 통제 아래 두고 잘 구현된 대체만으로 충분합니다. 다만 일부 워크플로우에서는 그 위에 보호 레이어를 더 얹을 가치가 있습니다.

추가 보호가 필요해지는 경우는, 잔여 위험이 대체어 자체가 아니라 대체어가 형성하는 패턴에 있을 때입니다. 대체 처리된 문서에는 빈도, 공동 발생, 시퀀스, 비율 같은 구조적 정보가 충분히 남아 있어서, 정교한 상관관계 분석기라면 원시 값 없이도 엔티티를 재식별할 수 있습니다. 이 위험은 고카디널리티 데이터, 긴 시계열, 대체 처리 출력이 시간이 지나며 많이 쌓이는 워크플로우에서 특히 두드러집니다.

표준 대응은 대체 처리된 데이터에 적용하는 차분 프라이버시, k-익명성, 그리고 유사한 통계적 보호입니다. 각각은 분석 정밀도를 어느 정도 희생하는 대신, 공격자가 대체 처리 출력에서 학습할 수 있는 양을 제한하는 제어된 방식으로 노이즈나 집계를 더합니다. 이 트레이드오프가 값어치를 하는지는 위협 모델과 워크플로우의 노이즈 허용 범위에 달려 있습니다.

대부분의 엔터프라이즈 AI 워크플로우에서 이 레이어는 선택 사항입니다. 데이터가 매우 민감하거나, 볼륨이 높거나, 데이터 태세가 심층 방어를 요구하는 워크플로우라면 복잡성을 감수할 가치가 있습니다. 이 결정은 전역 설정이 아니라 워크플로우별로 내리는 것이 가장 좋습니다.

대체하지 말아야 할 것

자주 얼떨결에 답해버리는 마지막 설계 질문이 있습니다. 무엇을 대체하지 말아야 하는가입니다.

엉뚱한 것을 대체하면 보호는 나아지지 않으면서 AI 출력만 나빠집니다. 모든 고유 명사를 바꾸는 대체 엔진은 읽을 수 없는 문서를 만들어냅니다. 모든 숫자 필드를 바꾸는 대체 엔진은 분석 신호를 파괴합니다. 흔한 유혹은 공격적으로 접근하는 것입니다. “개념적으로 민감할 여지가 있는 것은 전부 대체하라”는 식입니다. 하지만 그 비용은 곧바로 출력 품질로 나타납니다.

규율 있는 접근은, 엔터프라이즈 자신의 용어로 민감도를 명시적으로 정의하고 거기에 해당하는 요소만 대체하는 것입니다. 일반 PII 카테고리는 출발점이지 완전한 목록이 아닙니다. 내부 프로젝트 코드, 고객 세그먼트 식별자, 섹터별 참조처럼 엔터프라이즈의 데이터 태세가 보호 대상으로 다루는 모든 것이 목록에 들어갑니다. 나머지는 그대로 둡니다.

이 목록은 버전 관리되어야 합니다. 무엇을 민감하다고 볼지가 시간이 지나며 바뀌기 때문입니다. 또한 감사 가능해야 합니다. 워크플로우의 감사 검토는 무엇이 언제 어떤 정의로 대체되었는지 알고 싶어 하기 때문입니다. 이 정의 레이어야말로 이 아키텍처의 장기 운영 비용이 대부분 몰려 있는 곳이고, 대부분의 팀이 초기에 충분히 투자하지 않는 곳입니다.

워크플로우의 다음 단계

대체는 외부 모델을 위해 문서를 준비합니다. 모델은 대체 처리된 문서를 처리해 대체어가 담긴 응답을 반환합니다. 그 응답 자체는 아직 워크플로우에 그대로 쓸 수 없습니다. 출력이 사용자에게 닿기 전에, 대체어가 엔터프라이즈 환경 내부에서 원래 값으로 다시 매핑되어야 합니다.

그 복원 단계는 이 시리즈의 다음 아티클에서 다룹니다. 이 글이 속한 더 넓은 패턴은 민감한 엔터프라이즈 데이터에서 외부 LLM 실행하기 필러 개요를 참고하십시오. 운영 워크플로우에서 마스킹과 삭제가 이 대체를 대신하지 못하는 이유는 AI 워크플로우가 운영 데이터에서 막히는 이유 아티클을 참고하십시오.