데이터 관측성 결여와 AI 에이전트의 오답 메커니즘
모델이나 프롬프트를 수정해도 시간이 지나면 AI 에이전트가 확신을 가지고 오답을 내놓는 현상이 발생한다. 이는 모델의 성능 저하가 아니라, 외부 환경의 변화(가격 변동, 정책 업데이트, 제품 사양 변경 등)가 지식 저장소(Knowledge Store)에 반영되지 않아 발생하는 데이터 엔지니어링의 실패 사례다.
표준 검색 파이프라인은 데이터의 '정확성(Correctness)'이 아니라 '관련성(Relevance)'이나 '가용성(Availability)'을 기준으로 점수를 매긴다. 이 구조에서는 오래된 가격 문서나 일부 필드가 누락된 레코드라도 검색 쿼리와 관련성이 높다면 높은 점수로 추출된다. 모델은 추출된 컨텍스트가 권위 있다고 판단해 높은 확신도로 오답을 출력하며, 파이프라인의 작업 완료 여부만 체크하는 기존 대시보드에서는 이를 감지할 수 없다.
AWS와 스노우플레이크(Snowflake)는 이러한 증상을 해결하기 위해 각각 에이전트 사용 기록을 학습하는 지식 그래프와 'Horizon Context', 'Cortex Sense'를 공개했다. 하지만 이러한 도구들은 비즈니스 로직의 거버넌스를 강화하는 상위 레이어의 해결책일 뿐, 결국 지식 그래프에 입력되는 원천 데이터의 품질 문제라는 상위 단계(Upstream)의 결함은 여전히 남는다.
데이터 신뢰성 확보를 위한 4가지 측정 차원
데이터 관측성(Data Observability)의 핵심은 단순한 백분율 지표가 아니라, 핵심 데이터셋의 계보(Lineage)가 얼마나 쿼리 가능한 형태로 관리되는지의 '커버리지'에 있다. 우버(Uber)는 RAG(검색 증강 생성) 등장 이전부터 통합 데이터 품질 플랫폼을 구축해 2,000개 이상의 핵심 데이터셋을 지원하며, 데이터 품질 사고의 약 90%를 하위 소비 단계에 도달하기 전에 탐지하고 있다.
넷플릭스(Netflix)는 데이터 계보 시스템을 통해 데이터셋의 출처와 변환 과정을 추적한다. 이 시스템은 단순한 웨어하우스 테이블을 넘어 Kafka 토픽, ML 모델, 실험 데이터 간의 의존성을 매핑한다. 이러한 접근 방식은 AI/LLM 애플리케이션의 도입으로 인해 데이터의 출처 확인 필요성이 커지면서 더욱 중요해졌다.
데이터 신뢰성을 측정하기 위해서는 다음 4가지 차원의 검증이 필요하다.
첫째, 정확성(Correctness)이다. 각 레코드가 정의된 스키마와 규칙(필드 타입, Null 값 여부, 값의 범위 등)을 준수하는지 확인한다. Great Expectations나 Soda 같은 도구를 통해 행·열 단위의 자동 검증을 수행하고, 실행당 검증 통과 레코드 비율을 추적한다.
둘째, 최신성(Freshness)이다. 데이터가 원천 소스 대비 최신 상태인지 확인한다. 모든 데이터셋에 동일한 기준을 적용하는 대신, 소스별로 서로 다른 SLA(서비스 수준 협약)를 설정하고 마지막 성공 업데이트 이후 경과 시간을 추적한다.
셋째, 일관성(Consistency)이다. 동일한 사실이 저장되거나 인덱싱된 모든 곳에서 동일하게 읽히는지 확인한다. 이는 서로 다른 두 시스템이 동일한 소스에서 데이터를 공급받을 때 불일치가 발생하는 지점을 주기적으로 교차 체크하여 탐지한다.
넷째, 계보(Lineage)는 출력값이 어떤 소스에서 왔으며 어떤 변환 과정을 거쳤는지 추적하는 능력이다. 이는 데이터 오류 발생 시 원인을 역추적하는 근거가 된다.
데이터 파이프라인 검증 체계 구축과 실무적 적용
소큐어(Socure)는 클라이언트로부터 유입되는 비정형 데이터의 오류가 하위 시스템으로 전파되는 것을 막기 위해 'Write-Audit-Publish(WAP)' 패턴을 도입했다. 데이터가 먼저 스테이징 영역에 적재되면, Great Expectations를 통해 스키마 및 범위 검증, 소스별 최신성 SLA 확인, 시스템 간 일관성 체크, 파일 레벨 계보 확인을 수행한다. 모든 검증을 통과한 데이터만 하위 파이프라인으로 이동시키는 구조다.
이러한 검증 레이어의 구축은 리포팅 파이프라인과 ML 모델, 그리고 AI 검색 결과의 전반적인 정확도 향상으로 이어진다. 이는 인프라의 전면 교체가 아니라 기존 데이터 엔지니어링 공정에 검증 단계를 추가하는 방식으로 구현 가능하다.
RAG 기반 AI 시스템을 운영하는 실무자는 모델 교체나 검색 아키텍처 변경에 앞서 다음 4가지 질문에 답할 수 있어야 한다. '하위 소비자가 요구하는 표준에 따라 데이터가 검증되고 있는가?', '현재 높은 확신도로 제공되는 콘텐츠 중 가장 오래된 것은 무엇인가?', '동일 소스의 두 청크(Chunk)가 검색 결과에서 서로 충돌하지 않는가?', '오답 발생 시 원천 데이터를 역추적할 수 있는가?'. 이 질문에 답할 수 없다면 문제는 모델이 아니라 소스 시스템과 에이전트 사이의 데이터 파이프라인에 있으며, 이는 데이터 엔지니어링 관점의 수정이 필요하다.
