Track 3: AI & Agent Observability (관측 가능성) — "Agents of SigNoz" Hackathon (WeMakeDevs × SigNoz, 2026년 7월)

문제점 (The Problem)

이런 해커톤에 참여하는 모든 팀은 느리거나 에러가 발생하는 에이전트를 보여줄 것입니다.

• 우리는 그보다 더 나쁘고, 훨씬 더 흔한 상황을 보여주려 합니다.
• 바로 아무것도 실패하지 않는 멀티 에이전트 시스템 (multi-agent system)입니다.
• 예외(Exception)도 없고, 페이지 오류도 없으며, 빨간색 대시보드도 나타나지 않습니다.
• 하지만 시스템은 여전히 멈춰 있습니다.

작업(Task)이 실행자(Executor)와 비평가(Critic) 사이에서 끝없이 핑퐁(bounce)됩니다. 작업이 완료된 후에도 조용히 반복됩니다. 때로는 어떤 에이전트도 작업을 가져가지 않아 작업이 그냥 방치되기도 합니다. 그동안 LLM 토큰은 계속 소모되고 비용은 계속 증가합니다.

전통적인 관측 가능성 (observability)은 개별 에이전트 호출에 집중합니다:

• 지연 시간 (Latency)
• 에러 (Errors)
• 호출당 비용 (Cost per call)

이는 멀티 에이전트 시스템을 실제로 망가뜨리는 요소인 다음 사항을 관측하도록 설계되지 않았습니다:

에이전트 간의 조정 (Coordination).

두 에이전트 사이에서 작업이 끝없이 오가는 것은 실패처럼 보이지 않습니다.

대부분의 관측 도구에게는 모든 것이 여전히 완벽하게 건강해 보입니다.

AgentATC란 무엇인가? (What is AgentATC?)

AgentATC는 경쟁 분석 보고서를 생성하기 위해 협업하는 Planner (기획자), Executor (실행자), Critic (비평가)로 구성된 실제(스크립트가 아닌) 3-에이전트 워크플로우 (workflow)입니다.

워크플로우는 간단합니다:

• Planner가 사용자의 목표를 하위 작업 (subtasks)으로 나눕니다.
• Executor가 검색 도구와 LLM을 사용하여 각 섹션의 초안을 작성합니다.
• Critic이 결정론적 루브릭 (deterministic rubric)에 따라 모든 초안을 평가합니다. 거절된 작업은 피드백과 함께 Executor로 다시 돌아가며, 에스컬레이션(escalation) 전까지 최대 5회 반복됩니다.

그 워크플로우 자체만으로 AgentATC가 흥미로운 것은 아닙니다.

차별점은 에이전트 간의 모든 핸드오프 (hand-off)가 일급 객체인 OpenTelemetry 스팬 (span)이 된다는 점입니다.

타임스탬프를 통해 사후에 조정을 추론하려고 시도하는 대신, AgentATC는 조정을 직접 기록합니다.

다음과 같은 모든 스팬 (span):

• agent.execute
• agent.handoff
• agent.review

은 다음 정보를 포함합니다:

어떤 에이전트가 작업을 시작했는가
어떤 에이전트가 작업을 받았는가
왜 핸드오프가 발생했는가

조율 (Coordination)은 API 호출 사이의 보이지 않는 간극이 아니라 관찰 가능한 데이터가 됩니다.

Swarm이 조율하는 방식

모든 작업에는 다음 사항이 할당됩니다:

하나의 task_id
하나의 루트 스팬 (root span, task.process)
실행 전반에 걸친 하나의 연결된 트레이스 (trace)

이러한 설계 결정이 전체 워크플로우를 연결된 상태로 유지하는 핵심입니다.

이것이 없다면 Orchestrator, Planner, Executor, Critic 사이의 모든 HTTP 요청은 독립적인 트레이스를 생성하여, 실행 과정을 서로 관련 없는 조각들로 파편화할 것입니다.

각 서브태스크 (subtask)는 자체적인 중첩된 스팬 (nested span) 내부에서 실행되며, Executor와 Critic은 수렴 (convergence)할 때까지 반복합니다.

Critic이 초안을 거절할 때마다,

agentatc_handoffs_total{reason="reject"}

값이 증가합니다.

작업이 정체될 때, 아무것도 예외 (exception)를 발생시키지 않습니다.

아무것도 충돌 (crash)하지 않습니다.

대신,

agentatc_task_last_update_timestamp

가 단순히 더 이상 앞으로 나아가지 않으며, 이는 어떤 에이전트도 더 이상 진전이 없음을 나타내는 유일한 지표가 됩니다.

성공적인 실행

목표를 제출합니다:

"세 가지 관측성 (observability) 벤더인 SigNoz, Datadog, New Relic에 대한 경쟁 분석 보고서를 작성하라."

Planner가 세 개의 서브태스크를 생성합니다.

그중 두 개인—

SigNoz
New Relic

—은 즉시 수렴하여 첫 번째 검토에서 Critic을 통과합니다.

이것이 예상된 경로입니다.

지루해 보여야 합니다.

성공적인 조율은 흥분을 불러일으켜서는 안 됩니다.

문제가 발생할 때

Datadog 서브태스크는 의도적으로 다르게 설정되었습니다.

해당 서브태스크의 모의 검색 도구 (mock search tool)는 가격 정보를 절대 가져올 수 없는 반면, Critic의 평가 루브릭 (evaluation rubric)은 초안을 승인하기 위해 가격 정보를 요구합니다.

그 결과, Executor는 결코 Critic을 만족시킬 수 없습니다.

모든 실행은 다음을 보장합니다:

5회의 검토 반복 (review iterations)
5회의 거절 (rejections)
1회의 에스컬레이션 (escalation)

무작위성은 없습니다.

라이브 데모 중에 LLM이 동일하게 동작하기를 바라는 요행도 없습니다.

모든 것이 하나의 트레이스 ID (trace ID)를 공유하기 때문에, 트레이스를 열면 전체 이력이 하나의 연결된 실행으로 드러나며, 모든 서비스에 걸친 모든 Executor ↔ Critic 핸드오프 (hand-off)를 보여줍니다.

SigNoz 대시보드 및 Copilot을 통한 완전한 투명성

Swarm Health Overview 대시보드는 다음을 추적합니다:

• 수렴 속도 (Convergence rate)
• 평균 승인 반복 횟수 (Average approval iterations)
• 진행 중인 하위 작업 (In-flight subtasks)
• 중복된 도구 호출 (Redundant tool calls)

Thrash Leaderboard는 거절 횟수에 따라 하위 작업을 순위 매깁니다.

Datadog이 지속적으로 상위에 나타나며, 이를 통해 조정 실패 (coordination failure)를 즉시 확인할 수 있습니다.

두 가지 프로덕션 알림 (production alerts)은 조정 실패를 조기에 감지하는 데 도움을 줍니다:

작업 스래싱 (Task Thrashing)
작업 정체 (Task Stalled)

두 알림 모두 자동으로 Copilot을 트리거할 수 있습니다.

Copilot은 SigNoz의 MCP Server를 사용하여, 마치 온콜 엔지니어 (on-call engineer)가 하는 방식 그대로 다른 에이전트의 실패를 조사합니다.

Copilot은 다음을 사용하여 텔레메트리 (telemetry)를 검색합니다:

1. signoz_search_traces
2. signoz_get_trace_details
3. signoz_search_logs

가장 중요한 점은, 답변을 지어내는 대신 "데이터를 찾을 수 없음"이라고 말하도록 구축되었다는 것입니다.

한 번의 에스컬레이션된 실행 (escalated execution) 중에 다음과 같은 결론을 내렸습니다:

"Critic이 동일한 이유로 제출물을 지속적으로 거절했습니다: 가격 정보 누락... 이는 도구 격차 (TOOLING GAP)를 나타냅니다. 실행자 (executor)의 데이터 소스가 필요한 가격 정보를 제공하지 않아, Critic에 의한 지속적인 거절로 이어지고 있습니다."

그 차이점이 바로 전체 가치 제안 (value proposition)입니다.

단순히 작업이 다섯 번 실패했다는 사실이 아닙니다.

실제 텔레메트리에 근거하여 '왜' 실패했는지를 알려주는 것입니다.

SigNoz가 중요한 이유

우리는 프로젝트가 끝난 뒤에 대시보드를 덧붙인 것이 아닙니다.

실제 분석 작업을 위해 트레이스 (Traces), 메트릭 (metrics), 로그 (logs)가 모두 SigNoz를 통해 흐릅니다.

조정 메트릭 (Coordination metrics)은 애플리케이션 코드 내부에서 미리 계산되는 대신, SigNoz의 쿼리 레이어 (query layer)에서 원시 텔레메트리로부터 직접 계산됩니다.

대시보드를 쿼리 빌더 (Query Builder)로 마이그레이션하는 동안, 하나의 PromQL 쿼리가 실제로 존재하지 않는 레이블 (label)을 사용하여 결과를 그룹화한다는 사실을 발견했습니다.

대시보드는 성공적으로 렌더링되었습니다.

하지만 데이터는 틀렸습니다.

그것은 SigNoz의 문제가 아니었습니다.

그것은 우리 프로젝트 자체의 계측 (instrumentation) 버그였으며, 렌더링된 그래프가 반드시 정확할 것이라고 가정하는 대신 라이브 텔레메트리를 통해 대시보드를 검증했기 때문에 비로소 드러날 수 있었습니다.

기술 스택 (Technology Stack)

• Backend: FastAPI 마이크로서비스 (Orchestrator, Planner, Executor, Critic, Copilot)
• Frontend: React + Vite
• Observability: OpenTelemetry 자동 계측 (auto-instrumentation)
• Transport: gRPC 기반 OTLP
• Monitoring: Foundry를 통한 자체 호스팅 SigNoz
• Investigation: SigNoz MCP 서버

교훈 (Lessons Learned)

우리가 드러내고자 했던 실패 모드 (failure mode)에는 다음이 포함됩니다:

1. 스래싱 (Thrashing)
2. 중단된 작업 (Stalled tasks)
3. 중복 작업 (Redundant work)

이러한 실패들은 전통적인 모니터링 시스템에서는 거의 유용한 신호 (signal)를 생성하지 못합니다.

이를 관찰하기 위한 메트릭 (metrics)을 구축하면서, 우리는 협업 (coordination)을 단순히 건강한 서비스 호출의 부수 효과 (side effect)로 취급하는 대신, 텔레메트리 (telemetry)로서 생각해야만 했습니다.

대시보드가 올바르게 렌더링될 것이라고 믿는 대신, 라이브 데이터를 통해 대시보드를 다시 검증함으로써, 그렇지 않았다면 인지하지 못한 채 배포되었을 실제 계측 (instrumentation) 버그를 발견할 수 있었습니다.

결론 (Conclusion)

우리는 또 다른 AI 에이전트 데모를 만든 것이 아닙니다.

우리는 모든 멀티 에이전트 (multi-agent) 팀이 고통스러운 과정을 통해 곧 발견하게 될 실패 모드를 위한 계기판 (instrument panel)을 만들었습니다.

다음과 같은 상황 말입니다:

모든 것이 건강해 보이고,
아무것도 실패하지 않으며,
그럼에도 시스템은 어쨌든 멈춰 있는 상황입니다.