AI 에이전트에 데이터 파이프라인을 맡기려면, 시맨틱 모델만으로는 안 되는 이유

사내 데이터에 질문을 던지는 AI 에이전트가 늘었습니다. 시맨틱 레이어를 붙이면 매출과 주문 같은 지표를 일관된 정의로 답합니다. 문제는 그 답이 운영 현실과 어긋나도 자신 있게 나온다는 점입니다.

Foursquare 데이터 플랫폼을 운영한 엔지니어 Vikram K. Gundeti가 공개한 글이 이 실패 모드를 정면으로 다룹니다. 요지는 에이전트에 지표 정의만 주는 것으로는 부족하고, 파이프라인 상태와 업무 맥락, 권한 경계를 함께 줘야 한다는 것입니다.

근거도 있습니다. 인수합병으로 파편화된 플랫폼을 Apache Airflow와 DataHub 중심으로 다시 세운 뒤, 주요 파이프라인에서 Spark 작업 문제를 진단하고 해결하는 시간이 최대 90% 줄어 몇 시간에서 10분 이내가 됐습니다.

자신 있게 틀리는 답이 나오는 구조

매출 리포트를 만드는 에이전트를 생각해 봅시다. 시맨틱 레이어에서 매출 감소를 정확히 계산하고 “사업이 둔화되고 있다”고 결론 내릴 수 있습니다. 실제로는 상류 수집 파이프라인이 실패해 지난주 데이터가 불완전하거나, 최근 배포가 집계 구간을 바꿨을 수 있습니다.

답을 신뢰하려면 에이전트가 표현 계층 너머를 봐야 합니다. 데이터가 얼마나 최신인지, 빠진 구간이 없는지, 어떤 파이프라인이 만들었는지, 최근 실행이 어땠는지까지 확인해야 합니다. 글은 여기서 세 기둥을 꺼냅니다. 연결된 관측성, 업무를 아는 맥락, 통제된 실행입니다.

로그를 한 번의 실행으로 묶는다

3년 전 Foursquare의 데이터 플랫폼은 인수합병이 겹치며 조각나 있었습니다. S3 데이터 레이크와 자체 수집·전달 시스템, 여러 카탈로그, 서로 다른 오케스트레이션과 컴퓨트 엔진이 한 집에 있었습니다. 운영과 스테이징 데이터를 구분하고 중복 사본을 찾고 권한을 맞추려면 시스템 여러 개를 오가야 했습니다.

Airflow로 오케스트레이션하고 Amazon EMR에서 도는 Spark 작업을 디버깅하려면 Airflow 태스크 로그, EMR 클러스터와 스텝 로그, Spark 드라이버와 익스큐터 로그를 서로 맞춰야 합니다. 시스템마다 식별자가 달라 이 연결 작업은 지금까지 사람 몫이었습니다.

Datadog 같은 관측 도구가 로그와 지표를 모으고 OpenTelemetry가 공통 맥락을 전파해도 집계만으로는 부족합니다. DAG 실행과 태스크 시도, EMR 클러스터와 스텝, Spark 애플리케이션을 이어 주는 매핑이 플랫폼 안에 있어야 합니다. Spark 오류와 EMR 스텝 실패, Airflow 태스크 실패가 같은 사고일 수 있기 때문입니다.

재시도가 섞이면 구분은 더 어려워집니다. 같은 사고가 여러 번 실패로 기록되고, 마지막 재시도가 성공해도 앞선 실패가 남습니다. 원인과 후속 증상이 뒤섞이면 에이전트는 이미 끝난 장애를 진행 중이라고 보고합니다.

Foursquare는 이 연결을 만들어 에이전트가 파이프라인 실패를 조사하게 했습니다. 대화형 분석에서도 같은 연결이 쓰입니다. 일별 매출이 갑자기 떨어졌을 때 사용자 행동이 바뀐 것인지, 주문 처리 파이프라인이 늦어 지표가 불완전한 것인지 구분할 수 있습니다.

계보만으로는 왜를 모른다

실시간 매출 대시보드에서 잠깐 빠진 숫자는 넘어갈 수 있습니다. 같은 숫자가 이사회 보고나 가격 실험, 고객 리베이트 정산에 들어가면 이야기가 달라집니다. 에이전트가 답을 얼마나 단정적으로 말할지, 누구에게 알릴지, 얼마나 급하게 다룰지는 이 차이에서 갈립니다.

관측성은 무슨 일이 일어났는지 알려 주지만, 그 일이 중요한지는 알려 주지 않습니다. 빠진 주문이 모든 채널인지 한 매장과 지역, 결제사인지, 일별 매출이 언제 확정되는지, 그 숫자로 어떤 결정을 하는지가 있어야 답의 강도와 경보 대상이 정해집니다.

DataHub나 Atlan 같은 메타데이터 시스템은 계보를 담습니다. 주문이 어떤 파이프라인을 거쳐 일별 매출이 됐는지는 보여 주지만, 그 파이프라인이 왜 존재하는지는 알려 주지 않습니다. 목적과 다루는 채널·지역, 완료 기준, 소유자를 파이프라인이 직접 선언해야 합니다.

대부분의 카탈로그는 주기적으로 긁어 오는 방식이라 손으로 채워야 하는 칸이 생깁니다. 글은 선언을 코드로 두는 쪽을 권합니다. Foursquare는 Airflow가 실행이 끝날 때마다 DataHub에 게시하게 했고, 여기에 코드 버전과 품질 결과를 함께 실어 카탈로그가 마지막 실행보다 늦지 않게 만들었습니다.

권한은 지시가 아니라 시스템이 막는다

무엇이 실패했고 왜 중요한지 알아도, 에이전트가 무엇을 해도 되는지는 별개입니다. 사람은 코드 리뷰와 변경 관리, 팀 소유권, 개인 책임으로 권한이 제한됩니다. 에이전트에는 그 판단이 없고, 약하게 시행된 통제를 우회할 방법을 찾아낼 수 있습니다.

글은 광고 데이터 클린룸의 역할 분리를 예로 듭니다. 데이터 소유자와 분석 코드 작성자, 실행 환경 운영자를 나눠 한 역할이 다른 역할의 권한을 갖지 않게 합니다. 데이터 플랫폼도 같습니다. 파이프라인 재실행을 요청할 수 있는 에이전트가 코드를 고치거나 원본에 직접 쓸 권한까지 갖으면 안 됩니다.

권한을 문서로 알려 주는 것으로는 부족합니다. 실행 시스템이 허용 범위를 넘는 동작을 실제로 막아야 하고, 위임 범위를 넘는 제안에는 사람 승인을 걸어야 합니다. 재실행은 되지만 코드 수정은 안 되는 식으로 경계를 나누는 것입니다.

오케스트레이터가 세 기둥을 묶는다

세 기둥은 따로 돌면 어긋납니다. 네 시간마다 갱신되는 카탈로그는 낡은 계보를 주고, 늦게 도착한 로그는 성공한 재시도를 진행 중인 장애처럼 보이게 합니다.

Airflow와 Prefect, Dagster 같은 오케스트레이터는 파이프라인 정의와 실행 사이에 있어서 어떤 태스크가 언제 돌았고 상태가 어떻게 바뀌었는지 압니다. 실행 시작 때 공통 식별자를 만들어 모든 시스템에 넘기고, 끝나면 계보와 코드 버전, 상태를 카탈로그에 게시하고, 재시도 전에 정책과 아이덴티티를 확인하는 식입니다. 에이전트는 그 기록 하나로 조사하고, 위임 범위 안에서 조치하고, 결과를 검증합니다.

글의 마지막은 냉정합니다. 이 구멍은 에이전트가 만든 것이 아니라 원래 사람이 플랫폼을 다루기 어렵게 만들던 구멍이라는 것입니다. 사람은 어디를 봐야 하는지, 누구에게 물어야 하는지 알아서 그 구멍을 메우고 일했습니다.

하나씩 닫으면 자율성을 주기 전에도 값이 나옵니다. 로그를 실행 단위로 묶으면 장애 진단이 빨라지고, 목적과 계보를 남기면 영향 분석이 쉬워지고, 실행 단위로 권한을 나누면 모든 조치를 더 안전하게 만듭니다. 에이전트는 숨어 있던 의존 관계를 무시할 수 없게 만들 뿐입니다. 그래서 에이전트를 붙이는 일은 사람이 쓰기 편한 플랫폼을 만드는 일과 같은 방향으로 갑니다.

원문 보기