"Trust the Machine"의 파트 3 -> 설계 단계부터 보안이 유지되고, 규정을 준수하며, 통제 가능한 AI 인프라를 구축하는 시리즈입니다.

데이터가 연료가 아닌 병목 현상인 이유

AI 시스템의 성능은 모델, 아키텍처, 벤치마크 점수와 같이 대부분의 관심을 끄는 요소들에 집중됩니다. 하지만 해당 시스템의 신뢰성은 눈에 잘 보이지 않는 요소, 즉 그 이면에 있는 데이터에 의해 크게 결정됩니다. 모델은 학습 및 검색 데이터의 압축된 표현입니다. 해당 데이터가 무엇을 포함하고 있는지, 무엇이 결여되어 있는지, 혹은 무엇을 포함해서는 안 되었는지에 따라 모델의 동작과 조직의 리스크로 직접 전파됩니다.

이는 단순한 이론적 우려가 아니라 도입을 가로막는 실질적인 제약이 되었습니다. 2026년 산업 보고서에 따르면, 상당수의 기업(약 81%)이 데이터 권한 및 거버넌스 문제로 인해 AI 이니셔티브를 지연시키거나, 축소하거나, 혹은 포기한 것으로 나타났습니다. 데이터는 더 이상 AI를 가속화하는 연료가 아닙니다. 많은 조직에게 데이터는 AI를 멈추게 하는 병목 현상(Bottleneck)이 되었습니다.

이 포스트에서는 왜 데이터 거버넌스(Data Governance)가 AI 신뢰의 근간에 위치하는지, 그리고 리니지(Lineage)와 프로비넌스(Provenance)가 어떻게 보안, 컴플라이언스(Compliance), 거버넌스 요구 사항을 동시에 충족하는 단일 통제 수단을 제공하는지 살펴봅니다.

데이터가 신뢰를 저해하는 세 가지 방식

AI 시스템에서의 데이터 관련 실패는 세 가지 범주로 나뉘며, 각 범주는 뚜렷한 결과를 초래합니다.

무단 사용 (Unauthorized use)

조직이 사용할 권한이 없는 데이터를 사용하여 학습하거나 검색하는 경우입니다. 법적 근거가 없는 개인 데이터, 이용 약관을 벗어난 라이선스 콘텐츠, 또는 관련 없는 목적으로 수집된 정보 등이 이에 해당합니다. 이러한 데이터가 모델의 가중치(Weights)에 흡수되면 정밀하게 제거할 수 없으며, 해결을 위해 재학습(Retraining)이 필요할 수도 있습니다. 이는 앞서 언급한 이니셔티브 중단 통계의 주요 실패 모드입니다.

유출 (Leakage)

훈련(Training) 또는 검색(Retrieval) 데이터에 포함된 민감한 정보가 출력물에 다시 나타나는 현상입니다. 모델은 일반적인 생성 과정이나 의도적인 추출 시도에 대응하는 과정에서 개인 데이터, 자격 증명(Credentials) 또는 기밀 자료를 재현할 수 있습니다. 이러한 노출은 시스템에 입력된 데이터가 무엇인지에 따른 직접적인 결과입니다.

오염 (Poisoning)

훈련 또는 검색 데이터에 영향을 미칠 수 있는 공격자는 모델의 동작을 형성하여 백도어(Backdoors), 편향(Biases) 또는 표적화된 실패를 유도할 수 있습니다. 데이터 파이프라인(Data pipeline)은 종종 애플리케이션 코드보다 검토가 덜 이루어지기 때문에, 매력적이면서도 방어가 미흡한 공격 대상이 될 수 있습니다.

이러한 각각의 실패는 데이터 계층(Data layer)에서 기인하며, 이것이 추론(Inference) 단계에서만 적용되는 통제 방식이 불충분한 이유입니다. 신뢰는 상류(Upstream) 단계에서 구축되어야 합니다.

리니지(Lineage)와 프로비넌스(Provenance)의 정의

데이터 신뢰를 뒷받침하는 두 가지 관련 개념이 있습니다.

**프로비넌스 (Provenance)**는 데이터 조각의 기원과 이력입니다. 즉, 데이터가 어디에서 왔는지, 어떻게 수집되었는지, 어떤 조건 하에 있었는지, 그리고 어떻게 변형되었는지를 의미합니다. 프로비넌스는 "우리가 이것을 사용할 권한이 있는가, 그리고 어떤 용도로 사용할 수 있는가?"라는 질문에 답합니다.

**리니지 (Lineage)**는 데이터가 시스템을 통해 흐르는 과정의 엔드 투 엔드(End-to-end) 추적입니다. 소스(Source)로부터 시작하여 처리 및 변형을 거쳐, 훈련 세트(Training sets)나 검색 인덱스(Retrieval indices)로 들어가고, 최종적으로 모델이나 출력물에 도달하는 전 과정을 의미합니다. 리니지는 "만약 이 소스가 침해되거나 제거되어야 한다면, 무엇이 영향을 받는가?"라는 질문에 답합니다.

프로비넌스와 리니지는 함께 데이터 계층을 판독 가능하게(Legible) 만듭니다. 이들이 없다면 조직은 모델이 무엇으로부터 학습했는지 증명할 수 없고, 침해된 소스의 영향 범위를 파악할 수 없으며, 삭제 또는 동의 철회 요청에 대응할 수 없습니다. 이들이 있다면, 이러한 작업들은 수사(Investigation)가 아닌 쿼리(Query)의 영역이 됩니다.

훈련 및 검색 데이터를 위한 프로비넌스 구축

프로비넌스는 컨텍스트(Context)를 여전히 사용할 수 있는 시점인 수집(Ingestion) 단계에서 캡처되어야 합니다. 나중에 이를 재구성하는 것은 신뢰할 수 없으며 종종 불가능합니다.

• 수집(Ingestion) 시점에 출처와 권한을 기록하십시오. 모든 데이터셋은 그 기원, 수집 방법, 라이선스 또는 동의 근거, 그리고 허용된 목적을 구조화된 메타데이터(Metadata)로서 포함해야 합니다. 이는 첫 번째 포스트에서 소개된 AI-BOM의 데이터셋 필드와 직접적으로 연결됩니다.
• 데이터 카테고리를 구분하십시오. 개인정보(Personal data), 기밀 자료(Confidential material), 자유롭게 사용 가능한 콘텐츠를 분리하고 각각을 적절히 추적하십시오. 카테고리에 따라 어떤 다운스트림(Downstream) 제어 기능이 적용될지가 결정됩니다.
• 동의 및 목적 제한 사항을 보존하십시오. 데이터가 동의하에 사용되거나 특정 목적을 위해 사용되는 경우, 해당 제약 사항은 파이프라인 전체에서 준수될 수 있도록 데이터와 함께 이동해야 합니다.
• 프로비넌스(Provenance)를 검색 소스(Retrieval sources)까지 확장하십시오. 검색 증강(Retrieval-augmented) 시스템은 추론(Inference) 시점에 데이터를 활용합니다. 검색 인덱스(Retrieval index)에 공급되는 소스들은 훈련 데이터와 마찬가지로 출력에 직접적인 영향을 미치기 때문에 동일한 프로비넌스 규율이 필요합니다.

개인정보 및 민감 데이터 처리

파이프라인 내에서 민감한 데이터를 최소화하면 유출 위험과 컴플라이언스(Compliance) 부담을 모두 줄일 수 있습니다.

• 기본적으로 최소화하십시오. 시스템의 목적을 위해 진정으로 필요한 경우에만 개인정보 및 민감 데이터를 포함하십시오. 유출에 대한 가장 확실한 방어책은 데이터의 부재입니다.
• 삭제(Redact), 마스킹(Mask), 또는 합성(Synthesize)하십시오. 민감한 필드가 필수적이지 않은 경우, 훈련 또는 인덱싱 전에 이를 제거하거나 변환하십시오. 합성(Synthetic) 데이터나 익명화된 대체재를 사용하면 노출을 줄이면서도 유용성을 유지할 수 있습니다.
• 2차 제어로서 출력 단계에서 필터링하십시오. 출력 측면의 탐지 및 삭제는 잔여 유출을 줄여주지만, 이는 상류(Upstream)에서의 최소화 조치를 대체하는 것이 아니라 보완하는 용도여야 합니다.
• 삭제 및 철회를 지원하십시오. 리니지(Lineage)를 통해 특정 개인의 데이터가 어디에 영향을 미쳤는지 식별할 수 있으며, 이는 점점 더 강력하게 요구되는 규제 사항인 삭제 및 동의 철회 요청을 이행하기 위한 전제 조건입니다.

데이터 파이프라인에 대한 포이즈닝(Poisoning) 방어

데이터 파이프라인은 프로덕션 코드(production code)와 동일한 수준의 보안 엄격성을 요구합니다.

• 소스 검증 및 심사 (Validate and vet sources). 수집된 데이터에 대해 프로비넌스 (Provenance) 체크와 무결성 검증 (integrity validation)을 적용하며, 특히 외부 또는 제3자 소스에 대해 면밀한 조사를 수행합니다.
• 이상 징후 탐지 (Detect anomalies). 통계적 불규칙성, 예상치 못한 분포, 그리고 조작(tampering)을 나타낼 수 있는 예상 패턴에서 벗어난 콘텐츠를 모니터링합니다.
• 쓰기 권한 제어 (Control write access). 누가, 무엇이 학습 세트(training sets)와 검색 인덱스(retrieval indices)에 기여할 수 있는지 제한하고, 모든 수정 사항을 로그로 기록합니다. 이는 포스트 2에서 다룬 최소 권한 원칙 (least-privilege principle)을 데이터 계층에 적용한 것입니다.
• 데이터셋 버전 관리 및 체크포인트 (Version and checkpoint datasets). 불변(Immutable)의 버전 관리된 데이터셋을 통해 오염된 상태를 식별하고 롤백(roll back)할 수 있으며, 재현성 (reproducibility)을 지원합니다.

세 가지 분야를 아우르는 통제 수단으로서의 리니지 (Lineage)

위의 관행들은 단순히 컴플라이언스 (compliance)만을 위한 것으로 보일 수 있습니다. 사실, 완전한 리니지 (lineage) 및 프로비넌스 (provenance) 역량은 보안, 컴플라이언스, 그리고 거버넌스 (governance) 통제 수단으로서 동시에 작동합니다.

• 보안 (security) 통제 수단으로서, 리니지는 영향 분석 (impact analysis)을 가능하게 합니다. 소스가 오염되거나 포이즈닝 (poisoning)된 것으로 판명될 때, 리니지는 정확히 어떤 데이터셋, 모델, 출력이 영향을 받았는지 식별하여 대응 범위를 설정합니다.
• 컴플라이언스 (compliance) 통제 수단으로서, 프로비넌스는 규제 기관이 점점 더 요구하고 있는 적법한 데이터 사용에 대한 증거를 제공하며, 리니지는 삭제 및 동의 철회 의무를 지원합니다.
• 거버넌스 (governance) 통제 수단으로서, 이들의 결합은 조직에 모델이 무엇을 기반으로 구축되었는지에 대한 방어 가능한 설명(defensible account)을 제공하며, 이는 배포 및 사용에 관한 책임 있는 결정을 내리기 위한 토대가 됩니다.

이것이 데이터 계층에 적용된 본 시리즈의 논지입니다. 한 번 구축된 단일 역량이 세 가지 요구 사항을 모두 충족합니다. 데이터를 엔드 투 엔드 (end to end)로 추적할 수 있는 조직은 보안 태세, 컴플라이언스 위치, 그리고 거버넌스 성숙도를 동시에 강화한 것입니다.

데이터 거버넌스 체크리스트

• 프로비넌스 (Provenance)가 수집 단계에서 구조화된 메타데이터로 캡처됩니다: 출처, 수집 방법, 라이선스 또는 동의 근거, 그리고 허용된 목적 포함.
• 데이터 카테고리(개인정보, 기밀, 자유 사용 가능)가 구분되고 추적됩니다.
• 동의 및 목적 제한 사항이 파이프라인 전반에 걸쳐 데이터와 함께 이동합니다.
• 검색 소스(Retrieval sources)가 학습 데이터와 동일한 프로비넌스 (Provenance) 표준을 준수합니다.
• 민감한 데이터는 기본적으로 최소화되며, 필수적이지 않은 경우 비식별화 (Redaction), 마스킹 (Masking) 또는 합성 (Synthesis) 처리가 이루어집니다.
• 엔드 투 엔드 리니지 (End-to-end lineage)가 소스에서 데이터셋, 모델, 그리고 출력물까지 연결합니다.
• 파이프라인은 소스 검증, 이상 탐지 (Anomaly detection), 액세스 제어 (Access control), 그리고 데이터셋 버전 관리를 통해 데이터 오염 (Poisoning)으로부터 방어합니다.
• 리니지 (Lineage)가 삭제 및 동의 철회 요청을 지원합니다.

다음 단계

포스트 4: 정책에서 파이프라인으로: 컴플라이언스를 엔지니어링 속성으로 만들기. 마지막 포스트는 본 시리즈를 마무리하며, EU AI Act, NIST AI 리스크 관리 프레임워크 (NIST AI Risk Management Framework), 그리고 ISO/IEC 42001의 요구사항을 포스트 1~3에서 구축된 구체적인 통제 항목에 매핑하고, 컴플라이언스가 별도로 관리되는 문서가 아닌 파이프라인 자체의 속성이 될 수 있음을 보여줍니다.

핵심 요약

데이터는 모델 신뢰성의 진정한 원천이며, 리니지 (Lineage)와 프로비넌스 (Provenance)는 데이터 계층의 책임성을 부여하는 통제 수단입니다. 자신의 모델이 무엇으로부터 학습했는지 설명할 수 없는 조직은 모델을 보안하거나, 거버넌스를 적용하거나, 인증한다고 주장할 수 없습니다.