AgentOps: 에이전트 관측성과 트레이싱 — 무슨 생각으로 그 도구를 호출했나

에이전트가 프로덕션에서 이상하게 굴 때, 가장 먼저 부딪히는 벽은 **"왜 그랬는지 모르겠다"**입니다. 같은 질문에 어제는 맞는 SQL을, 오늘은 엉뚱한 테이블을 골랐는데, 로그엔 최종 출력만 남아 있습니다. 중간에 무슨 추론을 했고, 어떤 도구를 왜 호출했고, 토큰을 얼마나 태웠는지가 안 보이면 디버깅은 점치기가 됩니다.

이것이 AgentOps — 에이전트 운영 — 의 출발점입니다. 이 글은 데이터 엔지니어링 에이전트를 프로덕션에 올릴 때 강 건너편에 놓아야 할 세 다리 중 첫 번째, **관측(Observability)**을 다루는 운영 3부작의 1편입니다.

이 글에서 배우는 것

• 에이전트 관측이 일반 LLM 모니터링과 무엇이 다른지
• 트레이스·스팬으로 에이전트의 사고 과정을 펼쳐 보는 법
• 토큰·비용·지연시간을 스텝 단위로 추적하는 법
• 실패한 실행을 그대로 재현(replay)하는 법
• Prometheus와 셀프-텔레메트리로 에이전트를 계측하는 실전 패턴

운영 3부작 — 1편 AgentOps 관측성(이 글) · 2편 에이전트 평가 · 3편 에이전트 보안

1. LLM 모니터링과 무엇이 다른가

LLM 모니터링은 보통 한 번의 호출을 봅니다 — 입력 프롬프트, 출력 토큰, 지연시간, 비용. 단발 추론을 다룰 땐 이걸로 충분하죠. 하지만 에이전트는 한 번의 목표를 위해 여러 번의 호출과 도구 실행을 루프로 엮습니다. 관측 단위가 "호출"이 아니라 "궤적(trajectory)"이 되는 겁니다.

그래서 에이전트 관측이 답해야 하는 질문은 LLM 모니터링과 결이 다릅니다.

LLM 추론 최적화가 "한 호출을 빠르고 싸게"라면, AgentOps는 "여러 호출이 엮인 궤적 전체를 보이게"입니다.

2. 트레이스와 스팬 — 사고 과정을 펼치기

에이전트 관측의 기본 자료구조는 분산 트레이싱에서 빌려온 **트레이스(trace)와 스팬(span)**입니다. 하나의 목표 처리 = 하나의 트레이스, 그 안의 각 스텝(추론·도구 호출·관찰) = 하나의 스팬. 스팬이 중첩되면 "어떤 도구 호출이 어떤 추론에서 비롯됐는지"가 트리로 펼쳐집니다.

각 스팬에 최소한 이만큼은 남겨야 나중에 쓸모가 있습니다.

• 입력/출력 — 추론 스팬엔 프롬프트와 응답, 도구 스팬엔 인자와 반환값(민감정보는 마스킹)
• 토큰·비용 — 입력/출력 토큰, 모델, 추정 비용
• 지연시간 — 스팬 시작·종료
• 상태 — 성공/실패/재시도, 에러 메시지
• 상관 ID — trace_id로 모든 스팬을 한 줄로 꿰기

이 데이터를 표준 형식으로 내보내면(OpenTelemetry의 GenAI 시맨틱 컨벤션이 사실상 표준으로 자리잡는 중입니다) 기존 관측 스택에 그대로 얹을 수 있습니다.

3. 토큰·비용·지연 — 스텝 단위로 봐야 하는 이유

에이전트 비용은 궤적 단위로 폭발합니다. 사용자는 질문 하나를 던졌는데, 내부에선 LLM 호출 5번 + Trino 스캔 3번이 돌 수 있거든요. 호출당 비용만 보면 "싸 보이는" 착시에 빠집니다.

그래서 추적해야 할 비용 지표는 다음과 같습니다.

• 궤적당 토큰/비용 — "질문 하나에 평균 얼마"가 진짜 단가
• 스텝 수 분포 — 평균 스텝이 늘면 비효율·루프의 신호
• 재시도율 — 자기수정이 잦다 = 첫 시도 품질이 낮다
• 도구별 비용 — 어느 도구가(특히 풀스캔 쿼리가) 돈을 먹는지

이 지표들은 Prometheus 메트릭으로 그대로 옮겨집니다. 카운터·히스토그램·게이지의 설계 원리는 Prometheus 메트릭 가이드에, 수집기 설치는 Prometheus 설치 가이드에 있습니다. 예를 들면:

# 에이전트 궤적을 Prometheus 메트릭으로 계측
from prometheus_client import Counter, Histogram
 
AGENT_TOKENS = Counter("agent_tokens_total", "토큰 누적", ["model", "phase"])
AGENT_STEPS = Histogram("agent_steps", "궤적당 스텝 수", buckets=[1,2,3,5,8,13])
TOOL_LATENCY = Histogram("agent_tool_seconds", "도구 지연", ["tool"])
 
def record_step(model, phase, in_tok, out_tok):
    AGENT_TOKENS.labels(model, phase).inc(in_tok + out_tok)

예산 임계를 넘으면 알림을 쏘는 규칙은 Prometheus 알림 규칙 가이드를 따르면 됩니다. "궤적당 평균 토큰이 1시간 동안 2배가 됐다" 같은 알림이 루프 폭주를 조기에 잡아줍니다.

4. 실패 재현 — 로그를 보는 게 아니라 다시 돌려보기

에이전트 디버깅의 성배는 **재현(replay)**입니다. 실패한 궤적의 모든 입력 — 프롬프트, 도구 반환값, 모델·파라미터 — 을 저장해 두면, 그 시점을 그대로 재생해 "어디서 길을 잃었는지" 짚을 수 있습니다.

재현이 가능하려면 설계 단계에서 챙겨야 할 것들이 있습니다.

• 결정성 확보 — 가능하면 temperature=0, seed 고정. 완전 결정적이지 않더라도 입력을 보존하면 분석 가치는 충분
• 도구 반환값 저장 — 외부 상태(쿼리 결과 등)는 시점이 지나면 바뀌므로 그때의 반환값을 함께 보관
• 버전 태깅 — 프롬프트·모델·도구 스키마 버전을 궤적에 박아두기(같은 코드인지 확인)

이 재현 데이터셋은 그냥 버려지지 않습니다. 회귀 테스트의 황금 데이터셋이 되거든요 — 과거에 실패한 궤적을 고정 케이스로 묶어 두면, 프롬프트를 고칠 때마다 "예전 버그가 되살아났는지"를 자동으로 검증할 수 있습니다. 이 연결고리가 바로 다음 2편 에이전트 평가의 출발점입니다.

5. 에이전트가 스스로를 계측한다 — 셀프-텔레메트리

관측을 외부에서 덧대는 대신, 에이전트가 자기 자신을 계측 대상으로 등록하게 만들 수도 있습니다. 우리는 이미 이 패턴을 Argus 카탈로그 에이전트에 적용했습니다 — 에이전트가 부팅할 때 자기 자신을 카탈로그 레지스트리에 등록하고, 호출 지표를 텔레메트리로 push 하는 구조죠.

이 설계의 묘미는 관측이 운영의 부산물이 아니라 에이전트의 1급 책임이 된다는 데 있습니다. 구체적인 구현 — 레지스트리 자기등록과 호출 지표 push, 폴링 환경에서의 Pushgateway 활용 — 은 AI가 카탈로그를 거버넌스한다(셀프-텔레메트리 편)와 Prometheus Pushgateway 가이드에 정리돼 있습니다.

한 발 더 나가면, 에이전트의 텔레메트리 자체를 또 다른 에이전트가 분석하게 만들 수도 있습니다. 로그·지표에서 이상 징후를 LLM으로 읽어내는 접근은 LLM 기반 로그 분석·AIOps에서 다룹니다.

6. 관측 가능한 에이전트를 위한 체크리스트

프로덕션 직전, 이만큼은 깔려 있어야 "왜 그랬는지 모르겠다"를 면합니다.

• 모든 목표 처리에 trace_id가 붙고, 모든 스텝이 스팬으로 기록된다
• 각 스팬에 입력·출력·토큰·비용·지연·상태가 남는다(민감정보 마스킹 포함)
• 궤적당 토큰·비용·스텝 수를 메트릭으로 집계한다
• 예산·재시도율 임계 초과 시 알림이 울린다
• 실패 궤적을 입력·도구 반환값까지 포함해 재현할 수 있다
• 재현 케이스가 회귀 테스트 데이터셋으로 축적된다
• 도구 호출이 빠짐없이 감사 로그로 남는다(보안·거버넌스용)

마치며 — 보이지 않으면 고칠 수 없다

에이전트 운영의 첫 번째 진실은 단순합니다. 보이지 않는 것은 고칠 수 없다. LLM 모니터링이 점을 본다면 AgentOps는 궤적을 봐야 하고, 그 궤적을 트레이스·스팬으로 펼쳐 토큰과 비용을 스텝 단위로 추적하고, 실패를 그대로 재현할 수 있을 때 비로소 에이전트를 믿고 맡길 준비가 됩니다.

그런데 관측이 "무슨 일이 있었나"를 보여줘도, "그게 좋은 결과였나"는 여전히 답하지 못합니다. 데이터 엔지니어링 에이전트엔 정답이 하나가 아닌 경우가 많거든요(같은 답을 내는 SQL은 여러 개죠). 그래서 다음 2편 에이전트 평가에서는, 정답이 하나가 아닐 때 에이전트의 품질을 어떻게 측정하는지를 다룹니다.

한 문장으로: 에이전트 관측의 단위는 호출이 아니라 궤적이며, 트레이스·비용·재현이 갖춰져야 디버깅이 점치기에서 공학으로 바뀐다.