Data Agent Correctness Layer는 데이터 엔지니어링 에이전트에서 LLM이 잘하는 창의적 작업과 코드가 해야 하는 결정론적 검증을 분리하는 아키텍처다. 핵심은 에이전트가 SQL을 “그럴듯하게” 판단하지 않고, AST·스키마·lineage·row diff 같은 도구를 호출해 검증하게 만드는 것이다.
왜 데이터 엔지니어링에 중요할까
데이터 파이프라인의 위험은 에러가 아니라 조용히 틀린 숫자다. 쿼리는 성공하고 dbt 테스트도 통과했지만 join grain이 바뀌어 매출이 중복 집계될 수 있다. 일반 코딩 에이전트는 이런 문제를 텍스트 추론만으로 판단하기 어렵다.
| 수준 | 설명 | 한계 |
|---|---|---|
| 채팅 단계 | ChatGPT·Claude에 맥락을 붙여 질문 | 프로젝트 구조와 실제 데이터 검증 부족 |
| 자율 에이전트 | Claude Code·Codex가 CLI, DB, 파일을 사용 | 더 강하지만 도메인 검증 로직은 직접 구성해야 함 |
| 전용 데이터 에이전트 | dbt·SQL parser·lineage·warehouse 도구를 내장 | 검증 계층을 제품/하네스에 포함 |
probabilistic agent와 deterministic core
사용자 의도
↓
확률적 에이전트: 전략 선택, SQL 초안, 설명, 복구
↓
결정론적 하네스: tool call 라우팅, 권한, 입력 검증
↓
결정론적 코어: SQL parse, validate, transpile, equivalence, lineage, row diffLLM은 “이 두 쿼리가 같은가”를 추측하지 않는다. 대신 SQL AST와 스키마를 알고 있는 함수가 equivalence check를 수행한다. LLM은 그 결과를 해석하고 다음 행동을 고른다.
blast radius 분석
대표 유스케이스는 컬럼명 변경, 단위 변경, join 변경 같은 데이터 모델 수정 전의 blast radius 분석이다.
- 어떤 downstream model, dashboard, metric이 영향을 받는지 확인
- rename이나 계산식 변경이 lineage를 통해 어디까지 전파되는지 추적
- SQL diff와 row diff로 의미 변경을 검증
- 사람이 승인해야 할 위험 지점을 보고서로 정리
이 접근은 agent-harness 관점에서도 중요하다. 에이전트에게 더 많은 자유를 주는 대신, 결정론적 검증 도구와 승인 지점을 하네스 안에 넣어야 한다.
적용 대상
- dbt 프로젝트를 유지보수하는 데이터 플랫폼 팀
- warehouse migration, SQL dialect 변환, semantic layer 정비를 하는 팀
- AI로 데이터 파이프라인 변경 PR을 만들지만 리뷰 비용이 커진 조직
- “LLM이 쓴 SQL”보다 “검증된 변경 세트”가 필요한 분석 엔지니어링 팀
관련 문서
- agent-harness — 에이전트 실행 기반과 검증 계층
- code-as-agent-harness — 코드 자체를 에이전트 하네스로 보는 관점
- geosql — 지리공간 SQL을 지도 피드백 루프로 검증하는 에이전트 스킬
참고 자료
- Where AI Agents Belong in Data Engineering: The Correctness Layer — Altimate AI (2026-06-29)