Datadog로 보는 AI agent 개선 사례, trace-평가-실험 루프 만드는 방법

AS-IS 무엇이 문제였나

지원용 agent를 출시하고 몇 달이 지나면 긴 대화 요약이 잘리거나 billing API 호출에서 지연시간이 튀는 문제가 생기곤 합니다. 이때 팀의 첫 반응은 프롬프트를 조정하거나 모델을 업그레이드하는 거예요. 업데이트 후 성능이 나아진 것처럼 보여도 왜 좋아졌는지, 트래픽이 바뀌어도 유지될지는 알기 어렵습니다. Datadog은 이 문제가 telemetry 데이터 부족 때문이 아니라고 짚습니다. agentic 시스템을 만드는 팀들은 리뷰할 수 있는 양보다 훨씬 많은 trace 데이터를 이미 쌓아두고 있는데, 정작 어디를 개선해야 할지 반복 가능한 방식으로 짚어내는 방법이 없다는 거예요.

trace로 가설 세우기

Datadog은 trace 데이터를 집계 단위로 분석하면 반복되는 패턴이 드러나고 다음에 뭘 투자할지 알 수 있다고 설명합니다. trace를 평가 점수와 결과에 연결하면 "에이전트가 더 나아져야 한다" 같은 모호한 우려를 "15개 메시지 넘는 스레드에서 요약 프롬프트 성능이 떨어지고, 그 티켓들은 재오픈율이 두 배" 같은 구체적이고 검증 가능한 주장으로 좁힐 수 있다고 강조합니다. 유용한 신호 세 가지를 제시하는데요, 지연시간 패턴은 특정 프롬프트나 도구 호출에 집중되면 병목을 가리킵니다(billing 도구가 호출될 때마다 느려진다면 모델이 그 도구 응답을 기다리고 있다는 뜻이에요). 비용 이상치는 값비싼 호출이 몰리는 지점을 보면 원인을 추적할 수 있어요(긴 스레드에서 비용이 크다면 매 턴마다 전체 히스토리를 컨텍스트에 로딩하고 있을 가능성이 있습니다). 품질 신호는 지연시간과 비용이 정상이어도 응답이 틀릴 수 있다는 걸 보여주는데, eval 점수, 부정 피드백 비율, 에스컬레이션 정확도, 다운스트림 재오픈 여부와 함께 도구 선택 정확도, 도구 인자 정확성 같은 agentic 시스템 특유의 신호가 중요하다고 짚습니다.

evaluation과 experimentation을 함께 써야 하는 이유

Datadog은 evaluation과 experimentation이 서로 다른 질문에 답한다고 구분합니다. evaluation을 건너뛰면 데이터셋으로 알 수 있었을 것을 고객을 대상으로 실험하게 되고, experimentation을 건너뛰면 프로덕션 트래픽에서 깨질 수 있는 테스트셋을 그냥 믿게 됩니다. evaluation은 실제 시나리오로 구성한 데이터셋에 후보 변경안을 돌려 고객이 보기 전에 품질 기준을 넘는지 확인하는 단계이고, experimentation은 프로덕션에서만 존재하는 지연시간, 비용, 트래픽 분포 조건에서 변형이 실제로 원하는 결과를 개선하는지 확인하는 단계예요. 원문은 변경 범위에 따라 비중을 조절하라고 조언합니다. 작은 카피 수정이면 evaluation과 가벼운 프로덕션 체크로 충분하고, 모든 요청에 영향을 주는 모델 교체라면 철저한 오프라인 벤치마크와 단계적 롤아웃이 모두 필요합니다.

5단계 순환 루프와 실무 적용 포인트

Datadog이 제시한 순환 구조는 trace 관찰, 가설 수립, 오프라인 evaluation, 프로덕션 experimentation, 배포 후 모니터링 순입니다. 원문에서 강조하는 실무 체크포인트를 정리하면 다음과 같아요.

• 가설은 반증 가능해야 합니다. 변경 내용, 대상 세그먼트, 핵심 지표, 회귀를 막을 가드레일 네 가지를 명시해야 강한 가설이라고 원문은 설명합니다.
• evaluation에는 회귀 감지용 데이터셋(프로덕션 분포를 반영)과 엣지 케이스용 커버리지 데이터셋을 따로 써서 각각 채점하라고 권합니다.
• baseline과 variant는 동일한 데이터셋으로 돌리고, 비결정적 출력은 여러 번 실행해 점수 분포를 비교해야 합니다.
• 프로덕션 실험은 feature flag로 트래픽을 나누고, 사전에 정한 stopping rule에 도달할 때까지 지연시간, 비용, 오류율, 보조 품질 지표 같은 가드레일을 지켜봐야 합니다.
• 새로운 실패 유형이 발견되면 다음 사이클의 데이터셋에 추가해서 evaluator를 계속 강화하라고 조언합니다.

Datadog은 이 루프를 자사의 Agent Observability, Experiments, Feature Flags 제품과 연결해 설명하며, trace가 한 시스템에 있고 오프라인 평가 벤치가 다른 시스템에 있고 A/B 테스트가 별도의 flag-analytics 스택에 있고 데이터셋이 CSV로 흩어져 있으면 반복마다 수작업과 오류 가능성이 늘어난다고 지적합니다.

자주 묻는 질문

ai agent란 뜻이 뭔가요

특정 목표를 위해 스스로 도구를 선택하고 여러 단계를 거쳐 작업을 수행하는 AI 시스템을 말합니다. 이 글에서 다루는 지원 agent처럼 프롬프트, 모델, 도구 호출이 결합된 형태가 대표적이에요.

ai agent 성능 비교는 어떻게 하나요

Datadog 원문 기준으로는 baseline과 variant를 동일한 데이터셋으로 evaluation한 뒤 지연시간, 비용, 품질 신호(정답 여부, 도구 선택 정확도 등)를 세그먼트별로 나눠 비교하는 방식을 권합니다. 단일 결과가 아니라 여러 번 실행한 점수 분포를 봐야 한다고 강조해요.

ai agent 만들기 할 때 처음부터 확인할 게 있나요

원문은 instrumentation이 먼저라고 말합니다. 어떤 품질 차원(정확성, 정책 준수, 톤 등)을 우선할지 정하고, 회귀를 진단할 때 세그먼트별로 나눠볼 수 있도록 데이터를 충분히 세밀하게 남겨야 합니다.

ai agent 툴은 trace와 평가를 어떻게 연결하나요

이 글에서는 Datadog의 Agent Observability, Experiments, Feature Flags를 예로 들어 trace 관찰부터 가설, 오프라인 평가, 프로덕션 실험, 배포 후 모니터링까지 한 플랫폼에서 연결하는 구조를 설명합니다. 여러 도구에 데이터가 흩어지면 반복마다 수작업이 늘어난다고 지적해요.