문제점: AI 에이전트는 블랙박스입니다

AI 에이전트는 결정을 내리기 위해 LLM (Large Language Model) 호출과 도구(tool) 호출을 체인(chain)으로 연결합니다. 하지만 느린 응답, 예상치 못한 답변, 통제 불능의 비용 발생 등 무언가 잘못되었을 때, 여러분은 추측만 할 뿐입니다. 보이지 않는 것은 디버깅할 수 없습니다.

"Agents of SigNoz" 해커톤을 위해, 저는 이 문제를 직접적으로 해결하는 것을 목표로 했습니다. 즉, 전체 의사 결정 과정이 엔드 투 엔드(end-to-end)로 완전히 관측 가능한(observable) AI 에이전트를 만들고 싶었습니다.

내가 만든 것

장애 대응 에이전트 (Incident Triage Agent) — 운영 중인 장애 상황에서 온콜(on-call) 엔지니어의 조수가 할 법한 일을 시뮬레이션하는 작은 AI 에이전트입니다:

1. 조사 방식 계획 (LLM 호출)
2. 관련 에러 로그 검색 (도구 호출)
3. 일치하는 장애 유형에 대한 런북(runbook) 확인 (도구 호출)
4. 발견된 내용을 바탕으로 심각도 점수 산정 (도구 호출)
5. 엔지니어를 위한 권장 조치 요약 (LLM 호출)

이 다섯 단계 각각은 고유한 OpenTelemetry 스팬(span)으로 감싸져 있습니다. 따라서 단일 장애 조사가 SigNoz에서 다섯 개의 자식 스팬(child span)이 중첩된 하나의 연결된 트레이스(trace)로 나타납니다.

기술 스택

• Python: 에이전트 로직용
• Google Gemini API (gemini-3.5-flash): 두 번의 LLM 호출용
• OpenTelemetry SDK: OTLP/gRPC를 통한 스팬 내보내기
• SigNoz: 새로운 Foundry 설치 프로그램을 통해 로컬에 셀프 호스팅

SigNoz 활용 방법

트레이스 (Traces)

각 스팬은 기본값 외에 커스텀 속성(custom attributes)을 포함합니다 — 토큰 수, 초 단위 지연 시간(latency), 예상 비용, 에이전트가 할당한 심각도 수준, 그리고 잠재적 환각(hallucination)에 대한 간단한 휴리스틱 플래그(최종 요약이 로그나 런북에 없던 내용을 참조하는지 여부) 등이 포함됩니다. SigNoz의 플레임 그래프(flame graph) 뷰에서 트레이스를 열면 시간이 어디에 소요되었는지 즉시 확인할 수 있습니다. 제 경우에는 두 번의 LLM 호출이 각각 지속적으로 10~15초가 소요된 반면, 세 번의 도구 호출을 모두 합쳐도 1초 미만이 걸렸습니다. 이는 코드를 읽어서는 명확히 알 수 없지만, 트레이스를 통해서는 명확히 알 수 있습니다.

대시보드 (Dashboards)

대시보드 (Dashboards)

SigNoz의 쿼리 빌더(query builder)를 사용하여 트레이스 데이터로부터 두 개의 대시보드를 직접 구축했습니다:

• 단계별 지연 시간 (Latency by Step) — 스팬 이름(span name)별로 그룹화된 평균 지속 시간을 보여주어, 에이전트 파이프라인의 어느 부분이 병목 현상(bottleneck)을 일으키는지 정확히 알 수 있습니다.
• 심각도 분포 (Severity Distribution) — 에이전트가 할당한 심각도별로 인시던트 건수(count of incidents)를 그룹화하여, 여러 실행 전반에 걸친 패턴을 파악하는 데 유용합니다.

알림 (Alerts)

계획 LLM 호출(planning LLM call)에 임계값 기반 알림(threshold alert)을 설정했습니다. 만약 agent.llm.plan이 평균적으로 15초보다 오래 걸리면 경고가 발생합니다. 이는 실제 프로덕션 환경에서 실제로 필요할 법한 기능입니다. 즉, 사용자가 체감하는 증상(user-facing symptom)이 나타나기 전에 에이전트의 성능 저하를 알 수 있는 방법입니다.

제가 배운 점 (What I learned)

솔직히 가장 흥미로웠던 발견은 SigNoz에 관한 것이 아니라, 제 자신의 에이전트에 관한 것이었습니다. 트레이스 분석(trace breakdown)을 볼 수 있게 되자, 이 파이프라인의 지연 시간 전체가 툴 호출(tool calls)에서 오는 것이 아니라 본질적으로 두 LLM 호출에서 온다는 것이 명확해졌습니다. 이는 멋지하지는 않지만 중요한 통찰입니다. 만약 제가 이 에이전트를 최적화하고 싶다면, 시간을 투자해야 할 곳은 툴 호출 부분이 아닙니다.

에이전트 관측성(agent observability)의 핵심 가치가 바로 여기에 있습니다.