Agents of SigNoz 해커톤을 위해 저희 팀이 구축한 자가 치유(self-healing) SRE 에이전트에 대하여: SigNoz에서 문제를 감지하고, 앱을 수정하며, 다시 SigNoz를 사용하여 복구를 증명합니다.

SigNoz의 새로운 MCP 서버를 포함한 모든 관측성 (observability) 도구는 한 가지를 매우 잘합니다. 바로 무엇이 고장 났는지 알려주는 것입니다. "이 엔드포인트가 느립니다. 여기 트레이스 (traces)가 있습니다."라고 말이죠. 하지만 그 이후에는 여전히 사람이 데이터를 읽고, 원인을 추측하고, 수정 사항을 적용하며, 실제로 작동하는지 확인해야 합니다.

Agents of SigNoz 해커톤(Team TraceBandits — Jay Bamroliya & Kaushal Karkar)을 위해, 저희는 다른 질문을 던졌습니다. 만약 에이전트가 이 전체 루프를 수행한다면 어떨까요? 단순히 장애를 설명하는 것이 아니라, 장애를 수정하고 — 그 다음 관측성 (observability)을 사용하여 수정이 성공했음을 증명하는 것 말입니다.

마지막 부분이 핵심 아이디어입니다. 결과적으로: 4.2초가 소요되던 엔드포인트가 **수십 밀리초 (milliseconds)**로 단축되었으며, 사람의 개입 없이 클릭 한 번으로 감지 → 수정 → 검증이 이루어졌습니다.

SigNoz Self-Healing Agent dashboard showing 4.21s to 36ms recovery

치유 직후의 에이전트 대시보드: 느려진 /about 엔드포인트를 감지하고, 결함을 비활성화한 뒤 재테스트했습니다 — 4.21초에서 36ms로 단축되었으며, 자체적인 장애 보고서(incident report)를 작성했습니다.

기능 설명

이 에이전트는 폐쇄 루프 (closed loop)를 실행합니다:

1. 감지 (Detect) — SigNoz에서 서비스 메트릭 (metrics)을 읽어 성능이 저하된 서비스를 찾아냅니다.
2. 조사 (Investigate) — 작업별 지연 시간 (per-operation latency, 내부 DB 스팬 (spans) 포함)을 추출하여 시간이 실제로 어디에서 소요되는지 찾아냅니다.
3. 수정 (Fix) — 실행 중인 앱에 범위가 지정된 복구 조치 (remediation)를 적용합니다.
4. 검증 (Verify) — 엔드포인트를 재테스트하여 복구를 확인한 후, 자체적인 장애 보고서 (incident report)를 작성합니다.

대부분의 "AI + 관측성 (observability)" 데모는 2단계에서 멈춥니다. 3단계와 4단계 — 즉, 행동하고 그 다음 관측성을 통해 검증하는 것 — 이 차별점을 만드는 요소이며, 이것이 바로 온콜 (on-call) 엔지니어가 실제로 원하는 기능입니다.

App degraded while the agent investigates the incident

클릭 한 번: 제가 지연(latency) 장애를 주입하면, 앱은 성능 저하(DEGRADED) 상태가 되고, 에이전트는 SigNoz를 통해 실시간 조사를 시작합니다.

아키텍처 (The architecture)

Architecture: instrumented app streams to SigNoz, agent reads via tools and fixes the app

전체 시스템: OTel(OpenTelemetry)로 계측된 앱이 SigNoz로 스트리밍을 보내고, 에이전트는 도구(tools)를 통해 SigNoz를 읽으며 앱에 다시 동작을 수행합니다.

• 에이전트 (Agent): Spring Boot (Java). 대부분의 에이전트는 Python으로 작성되지만, Java로 구현함으로써 우리가 복구하려는 앱과 밀접하게 유지하고 추론(reasoning)하기 쉽게 만들었습니다.
• 두뇌 (Brain): Groq 상의 Llama-3.3-70B (무료 티어, OpenAI 호환 함수 호출 (function calling)). LLM이 어떤 도구를 어떤 순서로 호출할지 결정합니다.
• 관측성 (Observability): SigNoz (데모를 위해 Cloud 버전 사용; 리포지토리에는 Foundry를 통해 셀프 호스팅할 수 있는 casting.yaml이 포함되어 있습니다).
• 데모 대상 (Demo target): 런타임 장애 주입 제어 평면 (runtime fault-injection control plane)을 갖춘 OpenTelemetry 계측 Spring Boot 앱입니다. 이를 통해 실제적이고 제어 가능한 장애 상황을 연출할 수 있습니다.

에이전트가 SigNoz를 사용하는 방법

이것이 프로젝트의 핵심이므로, LLM이 호출할 수 있는 실제 도구들을 소개합니다. 각 도구는 SigNoz Query API(서비스 계정 키로 인증됨) 호출입니다:

• get_services → POST /api/v1/services — 서비스별 p99 지연 시간 (latency), 에러율 (error rate), 처리량 (throughput). 성능이 저하된 서비스를 찾아냅니다.
• get_top_operations → POST /api/v1/service/top_operations — 작업(operation)별 p50/p95/p99. 내부 스팬 (internal spans) (DB 호출, 리포지토리 메서드 등)을 포함합니다. 이를 통해 에이전트는 단순히 요청이 느리다는 것을 아는 것을 넘어, 지연이 발생하는 정확한 _위치_를 찾아냅니다.
• apply_fix → 앱의 제어 평면(control plane)을 호출하여 장애를 비활성화합니다.
• verify_recovery → 엔드포인트를 직접 재테스트하고 새로운 지연 시간을 보고합니다.

루프 내에서 SigNoz가 두 번 사용된다는 점에 주목하세요. 한 번은 _탐지 및 진단 (detect and diagnose)_을 위해, 그리고 — 수정 후에는 — 복구를 확인하기 위해 다시 사용됩니다. 관찰 가능성 (Observability)을 통한 이 검증 단계가 제가 가장 자랑스럽게 생각하는 부분입니다.

SigNoz Cloud showing the /about endpoint latency

SigNoz가 보여주는 /about 엔드포인트의 지연 시간(latency) — 이것이 에이전트가 병목 현상 (bottleneck)을 찾기 위해 읽는 정보입니다.

다음은 에이전트가 실행 중에 작성한 실제 원문 결론입니다:

_"장애 요약: 'smartcontactmanager' 서비스의 '/about' 엔드포인트에서 비정상적으로 높은 지연 시간(p99 ≈ 4.2 s)이 발생했습니다. 적용된 수정 사항은 주입된 지연 결함 (latency fault)을 비활성화하는 것입니다. 수정 후 엔드포인트를 재테스트한 결과 평균 응답 시간이 36 ms로 나타나 복구가 확인되었습니다."

구축 과정에서 발생한 문제 (유용한 부분)

1. Spring 빈 이름 충돌 (Spring bean-name clashes). 저는 groqClient, demoAppClient라는 이름의 RestClient 빈 (bean)을 등록했는데, 이것이 동일한 이름의 @Component 클래스들과 충돌했습니다. Spring은 "a bean with that name has already been defined." 라는 오류를 내며 시작을 거부했습니다. 해결 방법: @Bean 메서드 이름을 (groqRestClient, demoRestClient) 변경하고 생성자 매개변수 이름을 일치시켰습니다. 여러 개의 RestClient 빈이 있을 경우 Spring은 매개변수 이름으로 모호성을 해소하기 때문입니다.

2. Llama가 숫자를 문자열로 변환함 (Llama stringifies numbers). 저의 첫 번째 도구 스키마 (tool schema)에는 정수형 minutes 매개변수가 있었습니다. Groq의 검증 과정에서 모델의 출력이 계속 거부되었습니다: "expected integer, but got string" — Llama가 {"minutes": "60"}를 출력했기 때문입니다. 해결 방법: 불안정한 숫자 매개변수를 제거했습니다. 도구들은 문자열만 받도록 하고 시간 범위는 서버 측 기본값으로 설정했습니다. 스키마를 단순화하니 검증 실패가 전혀 발생하지 않았습니다.

3. 수집 지연 (Ingestion delay) vs. 실시간 증명 (real-time proof). SigNoz Cloud는 수집 지연 (ingestion lag)이 짧지만, 수정 직후에는 집계된 p99 값이 아직 업데이트되지 않았을 수 있습니다. 결정론적인 증명을 위해, verify_recovery는 엔드포인트를 직접 재테스트하고 측정된 지연 시간(latency)을 보고합니다. 이는 즉각적이고 정직한 방식인 반면, SigNoz의 대시보드는 동일한 복구 상태를 약간의 시차를 두고 보여줍니다.

배운 점

• 관측성 (Observability)은 더 이상 인간만을 위한 것이 아닙니다. 깔끔한 API(또는 MCP 서버)를 통해 텔레메트리 (telemetry)를 노출하는 순간, 에이전트는 이를 바탕으로 추론하고 — 그리고 _행동_할 수 있습니다.
• 검증 (verify) 단계는 과소평가되어 있습니다. 어떤 에이전트든 수정안을 제안할 수는 있습니다. 하지만 실제 신호 (signals)를 바탕으로 자신의 작업 내용을 스스로 확인하는 에이전트야말로 실제로 신뢰할 수 있는 에이전트입니다.
• 무료 도구들의 위력은 대단합니다. Groq의 무료 Llama + SigNoz + OpenTelemetry — 이 전체 스택은 비용이 전혀 들지 않으며 6GB 노트북에서도 실행됩니다.

시도해보기

코드, 재현 가능한 SigNoz 배포를 위한 casting.yaml, 피치 덱 (pitch deck), 그리고 전체 데모 영상이 모두 리포지토리에 있습니다. 리포지토리를 클론(clone)하고, .env 파일에 SigNoz와 Groq 키를 넣은 뒤, 앱과 에이전트를 실행하고, 대시보드를 열어 Self-Heal을 클릭해 보세요.

SigNoz의 MCP 서버는 AI가 당신의 시스템을 볼 수 있게 해줍니다. 이 에이전트는 AI가 시스템을 치유하게 하고 — 그 사실을 증명하게 해줍니다.

— Team TraceBandits · Agents of SigNoz (WeMakeDevs × SigNoz)