에이전트 관측성 (Agent Observability): 프로덕션 환경에서 AI 에이전트를 모니터링하는 방법

LLM API 호출은 하나의 함수와 같습니다. 입력이 들어가면 출력이 나오고, 소요 시간(duration)은 제한되어 있습니다. 반면 AI 에이전트는 루프(loop)입니다. 에이전트는 계획을 세우고, 도구(tools)를 실행하며, 결과를 관찰하고, 다음에 무엇을 할지 결정합니다. 이 과정은 잠재적으로 수십 번의 반복(iterations)을 거칠 수 있습니다. 이 루프는 에이전트를 유용하게 만드는 요소인 동시에, 관측성 (observability) 없이 프로덕션 환경에서 실행할 경우 위험하게 만드는 요소이기도 합니다.

전통적인 LLM 관측성 (LLM observability)은 토큰 사용량, 지연 시간 (latency), 에러율 (error rates), 종료 사유 (finish reasons)와 같이 개별 모델 호출을 추적합니다. 에이전트 관측성 (Agent observability)은 **루프 자체의 동작 (behavior of the loop itself)**을 추적합니다. 즉, 루프가 몇 번의 반복을 수행하는지, 어떤 도구를 호출하는지, 세션당 비용이 얼마나 드는지, 진행 중인지 아니면 제자리걸음을 하고 있는지, 그리고 정의된 경계 내에서 유지되고 있는지를 추적합니다.

코딩 어시스턴트, 고객 지원 봇, SRE 자동화, LLM 단계가 포함된 데이터 파이프라인 등 프로덕션 환경에서 에이전트를 실행한다면 두 가지 계층이 모두 필요합니다. 이 가이드는 에이전트 전용 계층을 다룹니다.

에이전트를 다르게 만드는 것

API 호출은 예측 가능한 비용 상한선이 있습니다. 하나의 프롬프트, 하나의 완성 (completion), 하나의 청구서로 끝납니다. 하지만 에이전트는 이러한 보장이 전혀 없습니다.

무제한 반복 (Unbounded iteration). 에러에 직면한 에이전트는 실패한 동일한 접근 방식을 무한히 재시도할 수 있습니다. 테스트 실패를 잘못 읽은 코딩 에이전트는 진전 없이 50번의 수정-테스트(edit-test) 사이클을 반복할 수 있습니다. 각 반복은 토큰 비용을 발생시킵니다.

도구 호출 체인 (Tool-call chains). 에이전트는 데이터베이스 쿼리, API 요청, 파일 작업, 웹 검색과 같은 외부 도구를 호출합니다. 각 도구 호출은 지연 시간 (latency), 비용, 그리고 새로운 실패 모드 (failure mode)를 유발합니다. 예상치 못한 출력을 반환하는 도구는 에이전트를 완전히 잘못된 조사 경로로 빠뜨릴 수 있습니다.

상태 축적 (State accumulation). 각 반복은 에이전트의 컨텍스트 윈도우 (context window)에 내용을 추가합니다. 15번의 조사 턴을 거친 후, 에이전트는 50,000개 이상의 누적된 컨텍스트 토큰을 바탕으로 추론하게 됩니다. 이로 인해 성능은 저하되고 비용은 증가하며, 에이전트가 초기 컨텍스트를 "망각"할 위험이 커집니다.

비결정론적 동작 (Non-deterministic behavior). 에이전트에 동일한 두 입력을 주더라도 완전히 다른 도구 호출 (tool-call) 시퀀스가 생성될 수 있습니다. 어떤 실행은 3번의 턴 안에 문제를 해결할 수도 있지만, 다른 실행은 20번이 걸릴 수도 있습니다. 입력값만으로는 실행 비용이나 소요 시간을 예측할 수 없습니다.

네 가지 기둥 (The four pillars)

1. 실행 트레이스 (Execution traces)

모든 에이전트 실행은 전체 의사결정 체인을 보여주는 트레이스 (trace)를 생성해야 합니다. OpenTelemetry GenAI semantic conventions는 이를 위한 스팬 (span) 유형을 다음과 같이 정의합니다:

invoke_agent — 에이전트 세션의 루트 스팬 (root span)으로, gen_ai.agent.name 및 gen_ai.agent.id를 포함합니다.
chat — 세션 내의 각 LLM 호출 (

감사 추적(Audit trail)은 두 가지 목적을 수행합니다: 디버깅 (debugging) (에이전트가 왜 그렇게 행동했는가?) 및 거버넌스 (governance) (에이전트가 이러한 인자(arguments)로 이 도구들을 호출할 권한이 있었는가). 쓰기 작업(write operations)의 경우, 실행 전 인간의 승인을 요구하는 것을 고려하십시오. 즉, 에이전트가 행동을 제안하면 인간이 이를 확인하는 방식입니다.

3. 비용 및 토큰 추적 (Cost and token tracking)

에이전트 비용 추적은 단일 호출 비용 추적보다 어렵습니다. 비용이 여러 턴(turn)에 걸쳐 누적되기 때문입니다:

세션 비용 내역:
  Turn 1: 800 input + 200 output = $0.008
  Turn 2: 1,200 input + 350 output = $0.014
...

패턴을 주목하십시오: 에이전트가 컨텍스트(context)를 누적하기 때문에 매 턴마다 입력 토큰(input tokens)이 증가합니다. 20번째 턴에 도달하면 턴당 20,000개 이상의 입력 토큰을 보낼 수도 있습니다. 비용 곡선은 턴 수에 따라 선형(linear)이 아닌 이차 함수(quadratic) 형태로 증가합니다.

세션별로 다음 지표를 추적하십시오:

총 토큰 수 (Total tokens) (입력 + 출력)
총 비용 (Total cost) (제공업체의 가격 책정 기준 계산)
턴당 토큰 수 (Tokens per turn) (성장 곡선 모니터링)
턴 횟수 (Turn count) (에이전트가 실행한 반복 횟수)
도구 호출당 비용 (Cost per tool call) (어떤 도구가 비용이 많이 드는가?)

다음 항목에 대해 알림(alerts)을 설정하십시오:

단일 세션 비용이 임계값(예: $5)을 초과하는 경우
일일 총합 비용이 예산(예: $50)을 초과하는 경우
세션당 평균 턴 수가 전주 대비 증가하는 경우 (에이전트의 효율성이 떨어지고 있음을 나타냄)

4. 안전 경계 모니터링 (Safety boundary monitoring)

에이전트에게는 경계가 필요합니다. 경계가 없다면 잘못 해석된 지시나 환각(hallucination)으로 인한 도구 호출이 실제 피해를 입힐 수 있습니다. 다음 경계들을 모니터링하십시오:

턴 예산 (Turn budget). 세션당 최대 반복 횟수를 제한하십시오. AI SRE 조사를 수행할 때, 저희는 25턴의 엄격한 제한을 설정합니다. 만약 에이전트가 25턴 내에 조사를 해결하지 못하면, 실행을 중단하고 인간에게 업무를 인계합니다. 세션이 턴 예산에 도달하는 빈도를 추적하십시오. 도달률이 높다는 것은 예산이 너무 낮거나 에이전트가 특정 유형의 문제를 해결하는 데 어려움을 겪고 있음을 의미합니다.

비용 차단기 (Cost circuit breaker). 모든 에이전트 세션에 대해 일일 지출 한도를 설정하십시오. 총 지출이 한도를 초과하면, 새로운 세션은 자동으로 실행되는 대신 사람의 승인을 위해 대기열에 추가됩니다. 차단기 활성화 빈도를 추적하십시오.

도구 허용 목록 (Tool allowlist). 에이전트가 호출할 수 있는 도구와 호출 시 사용할 인자 패턴 (argument patterns)을 정의하십시오. 코딩 에이전트는 파일을 읽을 수는 있어야 하지만 디렉토리를 삭제해서는 안 될 수도 있습니다. SRE 에이전트는 메트릭 (metrics)을 조회할 수는 있어야 하지만 프로덕션 서비스를 재시작해서는 안 될 수도 있습니다. 허용 목록에 의해 차단되었으나 시도되었던 모든 도구 호출을 로그로 남기십시오.

출력 가드레일 (Output guardrails). 에이전트가 사용자에게 노출되는 출력을 생성하는 경우, LLM 호출 (LLM calls)에 사용하는 것과 동일한 안전 필터를 거치도록 하십시오. 에이전트 유형별 가드레일 위반율을 추적하십시오.

시작하기

현재 관측성 (observability) 없이 에이전트를 운영하고 있다면 다음 단계를 따르십시오.

1단계: 세션 수준의 비용 추적 추가. 에이전트 루프 (agent loop)를 턴 (turn) 간의 입력 및 출력 토큰을 합산하는 카운터로 감싸십시오. 세션 종료 시 총합을 로그로 남기십시오. 일일 비용에 대한 알림을 설정하십시오. 이 작업은 30분 정도 소요되며, 가장 비용이 많이 발생하는 실패 모드(폭주하는 루프 (runaway loops))를 방지할 수 있습니다.

2단계: OTel 자동 계측 (auto-instrumentation) 추가. 사용 중인 LLM 제공업체에 대한 OTel 계측 라이브러리(opentelemetry-instrumentation-openai, opentelemetry-instrumentation-anthropic)를 설치하십시오. 이를 통해 호출당 스팬 (spans)을 자동으로 생성할 수 있습니다. 기존의 트레이싱 백엔드 (tracing backend)로 내보내십시오.

3단계: 도구 호출을 위한 커스텀 스팬 추가. 각 도구 호출을 gen_ai.tool.name과 도구의 입출력을 속성 (attributes)으로 갖는 스팬으로 감싸십시오. 이를 통해 실행 트레이스 (execution trace)를 완성할 수 있습니다.

4단계: 경계 모니터링 추가. 턴 예산 (turn budgets)과 비용 차단기를 구현하십시오. 이들이 얼마나 자주 활성화되는지 추적하십시오. 실제 세션 데이터를 기반으로 임계값 (thresholds)을 조정하십시오.

투입되는 비용은 몇 시간 정도의 계측 작업으로 적은 편이지만, 그 대가는 "우리 에이전트가 하룻밤 사이에 200달러의 청구서를 발생시켰다"와 "우리 에이전트가 10달러 차단기에 걸려 세션을 대기열에 넣었고, 우리는 아침에 이를 검토했다"의 차이만큼 큽니다.

에이전트가 의존하는 인프라 — 모델 제공업체 엔드포인트 (model provider endpoints), 벡터 데이터베이스 (vector databases), 도구 API (tool APIs) — 를 app.devhelm.io의 외부 체크를 통해 모니터링하세요. OpenAI API가 503 오류를 반환하여 에이전트 세션이 실패할 때, 에이전트 로직을 디버깅하기 시작하기 전에 이것이 제공업체의 문제임을 미리 알아야 합니다.

원문은 DevHelm에 게시되었습니다.