Unity Catalog의 OpenTelemetry 추적은 분석, 평가 및 모니터링을 통해 AI 에이전트의 지속적인 개선 플라이휠을 만듭니다.
작성자: 피라스 파라, Bruno Faria , Anoop Sunke
AI 애플리케이션이 프로덕션 환경으로 이동함에 따라, 프롬프트, 도구 호출, 응답, 지연 시간 및 실행 경로를 캡처하여 에이전트가 실제로 어떻게 작동하는지 이해하는 가장 명확한 방법 중 하나가 추적입니다. 강력한 추적 없이는 에이전트가 작동하는 이유를 이해하기 어려워 디버깅, 평가 및 거버넌스가 훨씬 더 어려워집니다.
AI 추적은 기존 디버깅 및 관찰 가능성 사용 사례를 넘어 분석, 평가 및 모니터링 워크플로우에 빠르게 유용해집니다. 팀은 이를 더 오래 보관하고, SQL로 분석하고, 비즈니스 및 모델 데이터와 조인하고, 평가 및 모니터링에 재사용하기를 원합니다. 추적이 관찰 가능성 시스템 내에만 있으면 유연성이 제한되고, 거버넌스가 파편화되며, 데이터를 분석 워크플로우로 이동하려면 특히 민감한 프롬프트 데이터가 관련된 경우 추가 파이프라인과 중복이 필요합니다.
Databricks는 이제 OpenTelemetry(OTel) 형식을 사용하여 OTel 추적을 Unity Catalog에 직접 작성하는 것을 지원합니다. 실제로는 추적을 실시간으로 수집하여 Delta 테이블에 저장할 수 있으며, 여기서 데이터의 나머지 부분과 동일한 확장성, 거버넌스 및 도구를 활용할 수 있습니다.
이는 팀이 추적 데이터를 사 용하는 방식을 바꿉니다:
그렇다면 SaaS 관찰 가능성 도구에 전적으로 의존하는 것은 어떨까요?
Databricks는 계측과 스토리지를 분리하기 위해 OTel 표준을 사용하여 OpenTelemetry(OTel) 추적, 로그 및 메트릭을 Unity Catalog 테이블에 직접 수집하는 것을 지원합니다.
Databricks는 Zerobus Ingest를 통해 투명하게 제공되는 관리형 수집 계층을 제공하여 기존의 멀티홉 원격 측정 파이프라인의 운영 복잡성을 제거합니다. Zerobus Ingest는 오픈 소스 수집기를 통해 gRPC를 통한 표준 OpenTelemetry 프로토콜(OTLP)을 기본적으로 지원하는 완전 관리형 서버리스 수집 엔진 역할을 하며, REST API 기능은 MLflow와 같은 애플리케이션 프레임워크와의 원활한 통합을 가능하게 합니다. 애플리케이션은 스팬, 로그 및 메트릭을 Unity Catalog 테이블로 직접 내보낼 수 있으며, 여기서 데이터는 Delta 형식으로 저장됩니다. "단일 싱크" 아키텍처를 통해 Zerobus Ingest는 데이터를 Lakehouse로 직접 스트리밍하여 관찰 가능성을 단순화합니다. 기존 OLTP 호환 수집기는 Kafka와 같은 중간 메시지 버스를 완전히 우회하여 gRPC를 통해 이 엔드포인트에 직접 연결할 수 있습니다. Zerobus Ingest는 인프라 오버헤드 없이 수집 및 내구성을 처리하는 고처리량 원격 측정 파이프라인 역할을 합니다. OTel 호환 클라이언트는 인기 있는 AI 에이전트 프레임워크를 포함하여 이 엔드포인트로 추적을 내보낼 수 있습니다.
여기서부터 추적, 로그 및 메트릭은 Lakehouse의 최우선 데이터가 되어 임시 SQL 분석, 대시보드, 다운스트림 분석 및 MLflow 평가 및 모니터링 워크플로우를 지원합니다. 원격 측정 통합은 프로덕션 동작이 평가 및 분석을 지원하고, 이는 다시 더 빠른 반복과 더 나은 에이전트 성능을 주도하는 지속적인 개선 플라이휠을 만듭니다.

이 블로그에서는 추적을 엔드투엔드로 시연하는 데 사용할 간단한 지원 관리자 도우미를 만들 것입니다. 에이전트는 여기서 수행한 것처럼 Databricks 외부에서 배포할 수 있으며, 이는 추적 수집이 에이전트가 실행되는 위치와 분리되어 있음을 강조합니다.
추론 및 응답 생성을 위해 Databricks 호스팅 Claude Sonnet 4.6 모델을 기반으로 하는 LangGraph 에이전트를 구축했습니다. 에이전트는 도구로 Genie Space를 호출하며, 이는 여기에서 배포할 수 있습니다.
사용자가 데이터 기반 질문을 하면 에이전트는 MCP 도구 API를 통해 Genie를 호출합니다. Genie는 요청을 SQL로 변환하고, 지원 데이터 세트에 대해 실행하고, 결과를 반환합니다. 그런 다음 에이전트는 결과를 요약하고 지원 관리자에게 실행 가능한 통찰력을 제공합니다.

에이전트를 계측하기 전에 먼저 OpenTelemetry 추적을 저장할 UC의 테이블을 구성합니다. 이 예에서는 MLflow를 사용하여 Unity Catalog에 기본 OpenTelemetry 테이블을 생성하고 MLflow 실험에 연결하여 추적을 UI에서 검색, 분석 및 주석 처리할 수 있도록 합니다. 먼저 SQL 웨어하우스와 MLflow 실험을 식별(또는 생성)한 다음 MLflow Python 라이브러리를 사용하여 Unity Catalog 테이블을 프로비저닝하고 스키마를 실험과 연결합니다. 전체 단계는 여기의 문서를 따르세요.
이 설정은 OpenTelemetry 스팬, 로그 및 메트릭에 대한 Unity Catalog 테이블을 생성합니다. 기본 데이터는 OpenTelemetry 호환 테이블 형식으로 저장되며, MLflow 서비스는 쿼리 및 분석을 용이하게 하기 위해 OpenTelemetry 데이터를 MLflow 친화적인 형식으로 변환하는 Databricks SQL 보기를 자동으로 함께 생성합니다. 여기에는 다음이 포함됩니다:
<table_prefix>_otel_spans: 각 요청에 대한 자세한 스팬 수준 실행 데이터<table_prefix>_otel_logs: 실행 중에 캡처된 구조화된 로그/이벤트 데이터<table_prefix>_otel_metrics: 실행 중에 캡처된 숫자 원격 측정<table_prefix>_otel_annotations: 메타데이터, 태그, 평가/피드백, 예상치, 실행 링크를 포함하여 표준 OTel 신호가 아닌 MLflow별 추적 데이터<table_prefix>_trace_unified: 원시 스팬 데이터 및 추적 메타데이터를 포함하여 추적 데이터를 단일 추적당 레코드로 조립하는 통합 보기<table_prefix>_trace_metadata: MLflow 태그, 메타데이터 및 평가가 추적 ID별로 그룹화됩니다. MLflow 추적 메타데이터만 필요한 경우 통합 뷰보다 더 효율적입니다.
실험 설정 후 에이전트 계측은 동일하게 유지됩니다. OTel 호환 계측 라이브러리는 구성된 엔드포인트로 추적을 내보낼 수 있습니다. 자동 및/또는 수동 추적은 여기에 설명된 대로 수행할 수 있습니다. 저희 예시에서는 상세한 LangGraph 실행(모델 호출 및 도구 호출)을 캡처하기 위해 mlflow.langchain.autolog()에 의존합니다. 또한 각 호출을 단일 엔드투엔드 실행으로 관찰할 수 있도록 요청 수준 루트 스팬을 설정하기 위해 @MLflow.trace로 진입점을 래핑합니다.
이제 에이전트가 계측되고 추적이 Unity Catalog로 흐르고 있으므로 실제 실행을 살펴보겠습니다.
이 예시에서는 지원 관리자 어시스턴트에게 다음과 같이 요청했습니다.
"어떤 지원 엔지니어를 승진시켜야 할까요?"
에이전트는 요청을 평가하고, 지원 데이터를 수집하기 위해 여러 번 Genie 스페이스를 호출했으며, 성능 지표를 기반으로 추천을 반환했습니다.

응답은 간단해 보이지만, 추적은 이를 생성한 기본 실행 경로를 보여줍니다. MLflow 실험에서 각 도구 호출과 claude sonnet 모델의 추론 로직을 볼 수 있습니다. 최종 답변을 종합하기 전에 세 번의 genie 스페이스 도구 호출이 있었음을 알 수 있습니다.

각 개별 단계를 클릭하여 입력과 출력 을 연구할 수 있습니다.

추적이 Delta 테이블로 저장되므로 다른 데이터셋과 마찬가지로 쿼리할 수 있습니다. mlflow_experiment_trace_unified 뷰에서 시작하면 요청, 응답, 추적 메타데이터 및 스팬 배열을 포함하는 레코드를 찾을 수 있습니다.

이제 추적이 Unity Catalog에 저장되었으므로 배치 및 스트리밍 분석 모두에 즉시 사용할 수 있습니다.
그러나 프롬프트와 응답에는 민감한 정보가 포함되는 경우가 많으므로 추적 데이터를 거버넌스된 데이터로 취급하는 것이 중요합니다. Unity Catalog에 저장함으로써 추적은 카탈로그 및 스키마 권한부터 열 마스킹 및 행 수준 필터링에 이르기까지 세분화된 액세스 제어를 상속하여 유연성을 제한하지 않고 안전하고 프로덕션 준비가 된 분석을 가능하게 합니다.
액세스가 설정되면 팀은 위에서 수행한 것처럼 SQL을 사용하여 기본 테이블과 뷰를 쿼리하여 안전하게 임시 분석을 실행할 수 있습니다. 또한 대시보드 및 Genie 스페이스 외에도 실행 가능한 비즈니스 통찰력을 얻기 위해 ETL 파이프라인을 구축할 수 있습니다.
MLflow 실험 UI는 이제 추적 볼륨, 오류, 지연 시간, 토큰 사용량 및 비용에 대한 뷰를 포함하여 Unity Catalog의 추적에 대한 기본 관찰 가능성 대시보드를 제공합니다. 대부분의 팀에게는 일상적인 에이전트 상태를 모니터링하기에 충분합니다.

기본 시각화를 넘어서는 보기가 필요할 때 추적 테이블은 여전히 Unity Catalog의 Delta 테이블일 뿐입니다. 사용자 지정 AI/BI 대시보드를 구축하고 AI의 도움을 받아 표준 SQL을 작성하여 팀이 중요하게 생각하는 모든 것을 모델링할 수 있습니다.
사용자 지정 대시보드가 기본 뷰 위에 추가할 수 있는 기능을 보여주기 위해 추적 테이블 위에 AI 운영 센터를 구축했습니다. 언급할 만한 몇 가지 기능은 다음과 같습니다.
계약 가격을 이용한 맞춤형 비용 분석
기본 비용 지표는 표준 목록 가격을 사용하는데, 이는 협상된 요율이 있거나 다른 가격으로 미세 조정된 모델을 실행하는 팀에게는 부정확할 수 있습니다. SQL을 제어하므로 가격 책정 로직을 쿼리에 직접 포함했습니다. 대시보드는 모델 유형별(예: GPT 5.5 대 Claude 4.6 Sonnet) 토큰 사용량을 추적하고 계약 요율을 적용하여 실제 지불하는 비용을 반영하는 추적당 예상 비용을 생성합니다. 이를 통해 검색 루프로 인해 $0.50의 비용이 발생하는 단일 복잡한 쿼리와 같은 비싼 이상치를 쉽게 감지할 수 있습니다.

구성 요소 수준 성능
기본 지연 시간 뷰는 추적 수준에서 P50/P99를 보여줍니다. 한 단계 더 나아가 어떤 도구가 느린지 확인하기 위해 에이전트의 개별 도구(예: retrieve_docs 대 generate_response)별 지연 시간(P50, P99) 및 오류율을 분해하는 도구 성능 위젯을 구축했습니다. 이를 통해 LLM, Genie 도구 호출 또는 다른 단계가 병목 현상인지 여부를 알 수 있으므로 사용자 경험이 저하되는 부분을 정확히 파악할 수 있습니다.

비즈니스 및 기술 이해 관계자 모두 SQL을 작성하지 않고도 에이전트 동작을 탐색하고 싶어하는 경우가 많습니다. 추적 테이블을 Genie를 통해 노출함으로써 팀은 자연어 분석을 원격 측정 데이터에 대해 사용할 수 있게 하여 사용자가 성능, 도구 사용량, 지연 시간 및 모델 동작에 대해 직접 질문할 수 있습니다. 저희 예시에서는 다음과 같은 질문을 포함할 수 있습니다.

추적이 Delta 테이블로 저장되므로 다른 데이터셋과 마찬가지로 다운스트림 ETL 파이프라인에 공급할 수 있습니다. 변경 데이터 피드(CDF)를 사용하면 팀이 전체 테이블을 반복적으로 스캔하지 않고도 배치 또는 스트리밍으로 추적 데이터를 점진적으로 처리할 수 있습니다.
이를 통해 관찰 가능성을 운영할 수 있습니다. 예를 들어, 파이프라인은 추적 패턴을 모니터링하고 지연 시간이 정의된 임계값을 초과하거나, 도구 오류가 급증하거나, 토큰 사용량이 예상 기준선에서 벗어나는 경우 경고를 트리거할 수 있습니다. 이러한 신호는 대시보드, 알림 시스템 또는 자동화된 수정 워크플로에 공급될 수 있습니다.
중요하게도 이는 실시간 보호 기능(예: AI Guardrails)을 보완합니다. Guardrails는 요청 시 정책을 시행하는 반면, ETL 파이프라인은 피드백 루프를 생성하여 팀이 추세를 분석하고, 정책을 개선하고, 에이전트 성능을 지속적으로 개선하는 데 도움을 줍니다.
추적을 사용할 수 있게 되면 전체 MLflow 평가 스택을 지원하여 팀이 전체 수명 주기에 걸쳐 GenAI 애플리케이션의 품질을 측정, 개선 및 유지 관리할 수 있습니다. 평가는 모니터링과 직접적으로 구축되며, 개발, 테스트 및 프로덕션 중에 캡처된 동일한 원격 측정을 LLM 심사관 및 사용자 지정 메트릭을 사용하여 채점할 수 있습니다.
MLflow를 사용하면 평가 데 이터셋에 대해 평가를 실행하고, 내장 또는 사용자 지정 심사관을 적용하여 응답 품질을 채점할 수 있습니다. 한 가지 효과적인 접근 방식은 실제 추적에서 이 데이터셋을 부트스트랩하는 것입니다. 이러한 프롬프트는 실제 사용자 상호 작용에서 비롯되므로 순전히 합성 테스트 사례에 비해 에이전트가 처리해야 하는 시나리오를 더 잘 나타냅니다.
아래에서는 최근 캡처된 추적에서 평가 데이터셋을 만듭니다. MLflow는 SQL 웨어하우스를 사용하여 데이터셋 레코드를 검색하고 구체화하므로 환경에서 웨어하우스 ID를 구성해야 합니다.
데이터셋이 준비되었으므로 애플리케이션을 평가할 심사위원을 정의할 수 있습니다. MLflow는 내장된 심사위원 세트를 제공하며, 에이전트의 예상 동작에 맞춰진 맞춤형 가이드라인을 정의할 수도 있습니다.
이제 MLflow 실험에서 결과를 확인할 수 있습니다.

개발 평가는 출시 전에 동작을 검증하는 데 도움이 되지만, 운영 모니터링은 실제 사용자와의 애플리케이션 성능을 보여줍니다. MLflow는 동일한 심사위원을 사용하여 실시간 추적을 자동으로 평가할 수 있으므로 회귀, 드리프트 및 새로운 실패 패턴을 신속하게 감지하는 데 도움이 됩니다. 이를 통해 평가는 일회성 작업에서 애플리케이션이 발전함에 따라 지속적인 관행으로 전환됩니다.
Experian
Eva 가상 비서 및 Latte 자동 이메일 시스템에 대한 MLflow 추적으로의 전환은 원활했습니다. Unity Catalog의 추적을 통해 데이터 과학 팀은 거버넌스된 Delta 테이블을 통해 수십만 건의 추적을 실행하고 Databricks를 떠나지 않고도 에이전트 품질을 확장하여 평가합니다. 더 많은 중요 평가 워크플로를 온보딩함에 따라, 추적 및 평가가 하나의 거버넌스된 플랫폼에 있다는 것은 에이전트 수명 주기의 각 단계에 대해 별도의 도구를 유지 관리할 필요가 없다는 것을 의미합니다.— James Lin, Head of AI/ML Innovation, Experian
Superhuman (Grammarly)
Superhuman의 모든 AI 에이전트에 대한 관찰 가능성 계층으로 MLflow 추적을 표준화하고 있습니다. 맞춤형 또는 포인트 솔루션을 구축하고 유지 관리하는 것보다 광범위한 플랫폼 통합을 선호합니다. 해당 유지 관리 부담은 저희 팀에게 실질적인 문제였습니다. Unity Catalog의 MLflow 추적을 통해 하루에 수십만 건의 추적으로 확장할 수 있으며, 연구원들은 엔지니어링 지원 없이 MLflow UI에서 직접 에이전트 동작을 셀프 서비스하고 탐색할 수 있습니다. 추적, 평가 및 모니터링이 모두 하나의 거버넌스된 플랫폼에 있다는 것은 에이전트를 자신 있게 운영 환경으로 전환하는 데 필요한 것입니다.— Martin Jewell, Lead MLE AI Infrastructure, Superhuman
SmartSheet
GenAI 플랫폼으로 Databricks를 선택했으며, MLflow는 저희 팀이 AI 에이전트를 구축하고 평가하는 방법입니다. Databricks와의 3일간의 공동 구축 기간 동안 MLflow 추적, 평가, 맞춤형 심사위원 및 레이블 지정을 사용하여 두 개의 운영 에이전트를 구축했습니다. 추적은 Unity Catalog에 저장되므로 수만 건의 평가를 실행하고 확장함에 따라 품질을 자신 있게 반복할 수 있습니다.— Kapil Ashar, VP of Engineering, Smartsheet
The Standard
The Standard는 고객이 재정적 웰빙과 마음의 평화를 달성하도록 돕습니다. 데이터와 AI는 해당 경험을 확장하여 제공하는 데 중요합니다. 중요한 비즈니스 기능에 AI 에이전트 기능(예: 수신 인수 문서 및 청구 제출에서 주요 정보 추출)을 내장함으로써 고객과 파트너에게 탁월한 서비스를 제공할 수 있습니다. 운영 추적 및 모니터링을 통해 저희 팀은 시스템이 어떻게 작동하는지 신속하게 이해하고 안정적인 업데이트를 만들 수 있습니다. Databricks Data Intelligence Platform의 나머지 데이터와 함께 Unity Catalog에서 추적을 거버넌스함으로써, 불필요한 복잡성을 추가하지 않고도 안전하게 쿼리, 모니터링 및 반복할 수 있습니다.— Porter Orr, AVP of AI and Automation, The Standard
Q: Databricks 외부에서 실행되는 에이전 트에 사용할 수 있나요?
A: 예, 에이전트는 어디에서든 실행될 수 있습니다. 실제로 이 블로그에 사용된 지원 도우미 에이전트 예제는 로컬에 배포되었습니다.
Q: 이 솔루션의 처리량 및 스토리지 제한은 어떻게 되나요?
A: 수집 처리량 제한은 200 QPS부터 시작합니다. 스토리지에는 제한이 없습니다. 실험당 추적에 대한 이전 제한은 더 이상 적용되지 않습니다. 더 높은 처리량 제한이 필요한 경우 Databricks 계정 팀에 문의하십시오.
Q: 검색 쿼리, MLflow 실험 경험 및 다운스트림 분석을 성능이 유지되도록 어떻게 할 수 있나요?
A: 최신 제품 업데이트를 통해 테이블은 데이터를 최적으로 구성하기 위해 자동으로 액체 클러스터링됩니다. 그러나 더 큰 추적 볼륨의 경우 파생 뷰 위에 구체화된 뷰를 만들고 점진적으로 새로 고쳐 쿼리 성능을 유지해야 합니다.
Q: 사용자 프롬프트에 포함된 PII는 어떻게 처리되나요?
A: 이 기능은 PII에 대해 특별한 처리를 적용하지 않습니다. 그러나 데이터는 Unity Catalog에 저장되며, 여기서 세분화된 액세스 제어, 열 마스킹 및 행 필터링과 같은 거버넌스 기능을 활용하여 다운스트림 액세스를 관리하고 제한할 수 있습니다.
설명서를 따라 시작하세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.