개요
평면 마스킹과 문서 구조 보존 처리는 모두 AI에 데이터를 넘기기 전에 민감 정보를 처리한다는 같은 출발점에서 시작합니다. 목표도 비슷합니다. 원본 값을 고객 환경 밖으로 그대로 내보내지 않으면서, 그 데이터를 AI가 쓸 수 있게 만드는 것입니다. 하지만 두 방식이 문서 구조와 엔터티 관계, 의미적 맥락을 다루는 방법은 근본적으로 다릅니다. 그리고 이 차이가 AI가 내놓은 결과물을 실제 업무에 그대로 쓸 수 있는지, 아니면 사람이 다시 손봐야 하는지를 가릅니다.
엔터프라이즈 문서는 단순한 텍스트 덩어리가 아닙니다. 표에는 열과 행의 관계가 있고, 계약서에는 여러 당사자가 서로 다른 역할로 반복 등장하며, 보고서는 앞 섹션에서 정의한 항목을 뒤에서 다시 참조합니다. 데이터를 준비하는 방식이 이 구조를 살리느냐 무너뜨리느냐에 따라, 같은 AI 모델이라도 전혀 다른 품질의 결과를 내놓습니다.
평면 마스킹은 어떻게 동작하는가
평면 마스킹은 문서에서 민감한 패턴을 스캔하고, 각 일치 항목을 일반 자리표시자(placeholder)로 대체합니다. 대체 방식은 균일합니다. 모든 이름은 [NAME], 모든 숫자는 [NUMBER], 모든 날짜는 [DATE]가 됩니다. 마스킹 엔진은 각 민감 값이 문서 구조에서 어떤 역할을 하는지 고려하지 않고 값을 독립적으로 처리합니다.
이 접근은 원래 문서 공개나 로그 정리처럼 사람이 읽되 특정 정보만 가리면 되는 상황을 위해 만들어졌습니다. 한 건의 필드를 가리는 데는 충분합니다. 문제는 AI에게 넘길 데이터에는 이 방식이 잘 맞지 않는다는 점입니다. AI는 값 하나가 아니라 값들 사이의 관계를 읽고 추론하기 때문입니다.
평면 마스킹의 한계
같은 문서를 AI 워크플로에 넣는 순간, 균일한 자리표시자는 다음과 같은 문제를 일으킵니다.
엔터티 붕괴
다자간 계약에서는 모든 당사자명이 [NAME]으로 합쳐집니다. AI는 인수자와 대상, 대출자와 차입자, 원고와 피고를 구별할 수 없습니다. 역할이 사라지면 누가 무엇을 했는지 추적하는 모든 추론이 무너집니다.
테이블 파괴
[FIELD]로 마스킹된 열 헤더와 [VALUE]로 마스킹된 셀 값은 AI가 정확한 추출에 필요한 스키마 정보를 제거합니다. 어느 열이 금액이고 어느 열이 기한인지 알 수 없으면, 표에서 특정 값을 뽑아내는 작업 자체가 불가능해집니다.
상호 참조 파괴
문서가 섹션 사이에서 같은 엔터티를 참조할 때, 평면 마스킹은 같은 엔터티에 서로 다른 자리표시자를 할당해 이 연결을 끊습니다. 위 조항의 당사자가 어느 당사자를 가리키는지 AI가 되짚을 수 없게 됩니다.
비일관적 대체
같은 엔터티가 문서의 다른 위치에서 다른 자리표시자를 받을 수 있어, 섹션 사이에서 엔터티를 추적하는 AI의 능력이 무너집니다. 문서가 길고 반복 참조가 많을수록 이 문제는 커집니다.
문서 구조 보존 처리는 무엇이 다른가
문서 구조 보존 처리는 민감한 값을 고객 환경 밖으로 원본 그대로 내보내지 않으면서 문서 무결성을 유지합니다. 핵심은 값을 가리는 것이 아니라, 값을 문맥을 보존하는 대체 표현으로 바꾸는 것입니다.
엔터티별 일관된 대체
엔터티별로 일관된 대체가 전체 문서에 걸쳐 적용됩니다. 같은 엔터티는 문서 전체와 여러 문서에 걸쳐 동일하고 고유한 대체 표현을 받습니다. A사는 항상 같은 대체 표현으로, B사는 또 다른 고유한 표현으로 나타납니다. 그래서 AI는 여전히 누가 누구인지를 구별할 수 있습니다.
구조와 관계 유지
테이블 구조, 상호 참조, 의미적 관계가 그대로 보존됩니다. 열과 행의 관계, 섹션 사이의 참조, 당사자 사이의 역할이 살아 있어 AI는 구조적으로 완전한 문서를 받습니다. 그 결과 정확한 추론을 뒷받침하는 입력을 얻게 됩니다.
결과가 실제 업무로 돌아온다
AI 결과물은 고객 환경 내부에서 원본 엔터프라이즈 데이터로 자동 복원됩니다. 사람이 대체 표현을 원래 값으로 일일이 되맞출 필요가 없기 때문에, 분석 결과를 곧바로 실제 업무로 되돌릴 수 있습니다. LLM Capsule의 AI Enablement Data Layer는 민감한 원본 값을 그대로 내보내지 않으면서, AI가 정확한 결과를 내는 데 필요한 문서 구조를 함께 보존합니다.
Comparison
| Capability | Flat Masking | LLM Capsule (AI Enablement Data Layer) |
|---|---|---|
| Entity handling | All entities → same placeholder | Consistent per-entity mapping |
| Table structures | Destroyed | Preserved |
| Cross-references | Broken | Maintained |
| Multi-document consistency | ✗ | ✓ |
| AI output accuracy | Degraded | High fidelity |
| Restoration support | ✗ | ✓ |
엔터프라이즈 워크플로 예시
투자 은행이 세 당사자(주 투자자, 공동 투자자, 대상 기업)가 관련된 텀시트를 분석합니다. 각 텀시트에는 서로 다른 역할을 맡은, 겹치는 엔터티명이 들어 있습니다.
평면 마스킹은 세 당사자를 모두 [NAME]으로 바꾸기 때문에, AI가 조건을 올바른 당사자에게 귀속시킬 수 없습니다. 문서 구조 보존 처리는 각 당사자에게 일관되고 고유한 표현을 할당해, 당사자별 조건을 정확히 추출할 수 있게 합니다. 복원 단계에서는 분석 결과물에 실제 당사자명이 다시 채워집니다.
같은 패턴은 다른 업무에서도 반복됩니다. 여러 조항이 서로를 참조하는 계약 검토, 환자 식별 정보와 임상 수치가 표로 얽힌 의료 기록 요약, 장비와 담당 팀이 반복 등장하는 운영 로그 분석 모두 마찬가지입니다. 엔터티가 반복되고 구조가 의미를 담고 있는 문서일수록, 균일한 자리표시자와 문맥을 보존하는 대체 표현의 차이는 결과 품질에서 더 크게 벌어집니다.
언제 이 차이가 가장 중요한가
모든 문서가 구조 보존을 필요로 하는 것은 아닙니다. 단일 값 하나만 가리면 되는 단순 작업이라면 평면 마스킹으로도 충분할 수 있습니다. 하지만 다음 조건 중 하나라도 해당한다면 구조 보존 처리가 결과 품질을 좌우합니다.
- 같은 엔터티가 문서 안에서 여러 번, 서로 다른 역할로 등장할 때
- 표의 열과 행 관계에서 값을 추출해야 할 때
- 여러 문서에 걸쳐 같은 대상을 일관되게 추적해야 할 때
- AI 결과물을 사람 손을 거치지 않고 곧바로 업무 시스템으로 되돌려야 할 때
이 조건들은 대부분의 엔터프라이즈 문서 업무에 그대로 해당합니다. 그래서 데이터를 준비하는 방식을 고를 때는 민감 값을 처리했는가만이 아니라, AI가 그 문서를 여전히 이해할 수 있는가를 함께 물어야 합니다.