---
id: HARNESS-RES-2026-05-013
title: 스키마 표류 (Schema Drift)
category: "10_Wiki/Topics/Infrastructure"
status: verified
confidence_score: 0.96
tags: [harness, data-quality, schema-drift, governance, data-contract]
created_at: 2026-05-05
updated_at: 2026-05-08
---

# 스키마 표류 (Schema Drift)

## 📌 한 줄 통찰 (The Karpathy Summary)
> "에이전트 신뢰성의 소리 없는 파괴자: 데이터 소스의 구조가 예고 없이 변경되어 에이전트가 오염된 컨텍스트를 읽게 만듦으로써, 작업 완료 시점에야 발견되는 치명적 오작동을 유발하는 현상."

## 📖 구조화된 지식 (Synthesized Content)
*   **에이전트 생산 실패의 주요 원인**: 스키마 표류는 엔터프라이즈 환경에서 에이전트 실패를 유발하는 가장 흔한 근본 원인 중 하나이다 [1]. 실제로 프로젝트의 약 88%가 생산 단계 도달에 실패하는데, 이는 모델의 지능 부족보다 스키마 불일치 및 컨텍스트 표류 등 하네스 환경의 결함 때문인 경우가 많다 [5].
*   **오케스트레이션 프레임워크의 한계**: LangGraph, Semantic Kernel 등은 에이전트의 실행 방식(어떻게)은 관리하지만, 읽어 들이는 데이터(무엇을)는 검증하지 않는다 [1, 2]. 따라서 스키마가 변형된 데이터가 아무런 유효성 검사 없이 에이전트에게 전달되는 구조적 공백이 존재한다 [4, 6].
*   **데이터 컨트랙트(Data Contracts)의 필요성**: 문제를 해결하려면 데이터가 컨텍스트 윈도우에 진입하기 전 스키마 계약을 강제하는 거버넌스 계층이 필수적이다 [3]. 이를 통해 에이전트가 잘못된 결과를 출력하기 전, 데이터를 읽는 시점에 선제적으로 스키마 표류를 감지할 수 있다 [3].

## ⚖️ 트레이드오프 및 고려사항
*   **사후(Post-hoc) 모니터링의 한계**: AgentOps나 Langfuse는 실행 이후를 기록하므로 잘못된 결과의 '발생'은 알 수 있으나, 불량 입력 데이터(스키마 표류 등) 자체를 방지하거나 근본 원인을 즉각 식별하는 데는 한계가 있다 [4].
*   **아키텍처 복잡성 증가**: 스키마 표류를 막기 위해서는 오케스트레이션 고도화 외에도 별도의 거버넌스된 데이터 기저(Governed data substrate)가 요구된다. 이는 데이터 계약 및 인증 인프라 구축을 위한 초기 비용과 시스템 복잡성을 증가시킨다 [3, 4, 8].

## 🔗 지식 연결 (Graph)
- **상위 개념**: [[Data Quality Layer]], [[Data Governance]]
- **유사 개념**: [[Active Metadata]], [[Data Contracts]], [[Hallucination (환각)]]
- **관련 프로젝트**: [[Atlan]], [[ConnectAI]]

---
*Last updated: 2026-05-08*