스키마 표류 (Schema Drift)

📌 한 줄 통찰 (The Karpathy Summary)

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

에이전트 생산 실패의 주요 원인: 스키마 표류는 엔터프라이즈 환경에서 에이전트 실패를 유발하는 가장 흔한 근본 원인 중 하나이다 [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].

Last updated: 2026-05-08