chore: update graph view scale and set workspace default tab to graph view

10_Wiki/Topics/Harness_Research_2026-05/Schema Drift (스키마 표류).md

@@ -0,0 +1,32 @@
+---
+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*