Agents of SigNoz 해커톤 제출작 (Track 1 — AI & Agent Observability).

문제점: 우리는 모든 것에 AI 에이전트를 붙이지만, 무엇을 보는지 모른 채 날아다닌다

AI 에이전트는 이제 LLM 호출 체인을 연결하고 도구를 자율적으로 호출합니다. 만약 이 중 하나가 프로덕션 환경에서 느리거나, 비용이 많이 들거나, 잘못된다면, 당신은 막히게 됩니다. 볼 수 없는 것은 디버깅할 수 없기 때문입니다. 한편 온콜(on-call) 엔지니어는 이미 대시보드에 파묻혀 있습니다. 불투명한 AI 에이전트를 위에 추가하는 것은 보통 관찰 가능성(observability)을 더 나쁘게 만들 뿐, 좋게 만들지는 못합니다.

그래서 Agents of SigNoz 해커톤에서 저는 스스로에게 질문했습니다: 만약 AI 에이전트가 블랙박스의 _반대_라면 어떨까? 만약 이것이 당신의 관찰 가능성 데이터를 읽어 도움을 주고, 모니터링을 수정하기 위한 행동을 취하며, 그리고 그 자체도 같은 플랫폼에서 완전히 관찰 가능하다면 어떨까?

이것이 바로 SRE Sidekick입니다.

SRE Sidekick은 트레이스 (traces), 메트릭 (metrics), 로그 (logs), 대시보드 (dashboards), 알림 (alerts), 그리고 MCP 서버에 이르기까지 모든 면에서 SigNoz에 의존합니다. 각 요소가 어떻게 결합되는지 소개합니다.

1. Foundry를 이용한 재현 가능한 설치

SigNoz와 그 MCP 서버는 단일 casting.yaml 파일로부터 생성됩니다:

apiVersion: v1alpha1
kind: Installation
metadata
...

curl -fsSL https://signoz.io/foundry.sh | bash
foundryctl cast -f casting.yaml   # 단 한 번의 명령으로 SigNoz UI + MCP 서버 실행

2. 에이전트의 두뇌와 손

**두뇌 (brain)**는 Groq에서 호스팅되는 LLM (gpt-oss 제품군; 하나의 환경 변수를 통해 Ollama 또는 다른 호스팅 모델로 제공자 교체 가능)입니다. **손 (hands)**은 SigNoz MCP 서버가 노출하는 41개의 도구 (tools)입니다. 저의 코드는 이들을 루프(loop)로 연결하는 신경계 역할을 합니다:

생각 (LLM이 도구 선택) → 행동 (MCP를 통해 호출) → 관찰 (결과를 다시 피드백) → 반복 → 답변

그 누구도 이 순서를 하드코딩하지 않습니다. LLM이 각 단계를 결정합니다. 이러한 자율성이 바로 이 시스템을 단순한 챗봇이 아닌 _에이전트 (agent)_로 만드는 핵심입니다.

3. 자기 관찰성 루프 (제가 가장 좋아하는 부분)

에이전트는 OpenTelemetry를 사용하여 _자기 자신_을 계측 (instrument)하고 동일한 SigNoz로 데이터를 내보냅니다:

with tracer.start_as_current_span("agent.run"):
    ...
    with tracer.start_as_current_span("llm.call") as span:
...

SigNoz를 열고 Services 섹션으로 가면 sre-sidekick이 바로 보입니다. 트레이스 (trace)를 열면 agent.run → llm.call → tool.signoz_* 과정을 볼 수 있으며, 각 단계에는 토큰 수와 비용 정보가 포함되어 있습니다. 관찰 가능성 (observability)을 읽는 에이전트는 그 자체로도 관찰 가능합니다.

또한 각 단계가 자신의 트레이스 (trace)와 연관된 로그 한 줄을 남길 수 있도록 OpenTelemetry를 통해 **로그 (logs)**를 연결했으며, 시간에 따른 토큰 사용량과 비용을 보여주는 작은 "에이전트 상태 (Agent Health)" 대시보드를 구축했습니다. 이로써 에이전트 자체를 위한 트레이스 (traces) + 메트릭 (metrics) + 로그 (logs) + 대시보드 (dashboards) 체계를 완성했습니다.

4. SigNoz에서 안전하게 행동하기

읽기 도구는 자율적으로 실행됩니다. 반면 쓰기 (write) 도구(대시보드 가져오기, 알람 생성 등)는 실행하기 전에 사용자의 명시적인 **승인 / 거절 (Approve / Reject)**을 기다리며 일시 중지됩니다. 이는 책임감 있는 에이전트 자율성을 모델링한 것으로, 에이전트가 사용자의 모니터링 환경을 몰래 변경하는 일이 없도록 합니다.

5. 알람(Alert) → 자동 진단

제가 생성한 알람은 에이전트 자체 서버의 웹훅 (webhook)으로 라우팅됩니다. 알람이 발생하면 에이전트는 새로운 조사를 시작하고 근본 원인 가설을 게시합니다. 즉, 탐지(detect)에서 진단(diagnose)으로 이어지는 폐쇄형 루프를 형성합니다.

잘 작동한 점과 어려웠던 점

잘 작동한 점: 모든 답변을 실제 MCP 도구 호출에 근거(grounding)하게 함으로써, 중간 규모의 모델에서도 에이전트가 신뢰할 수 있게 동작했습니다. 지능은 단순히 LLM에서 나오는 것이 아니라 데이터에서 나옵니다.

어려웠던 점 (그리고 배운 점):

• 너무 많은 도구가 컨텍스트를 초과함 (Too many tools overflow the context): 41개의 MCP 도구를 한꺼번에 노출하자 모델의 요청 예산(한 번의 호출에 약 43k 토큰)을 초과했습니다. 이를 약 10개의 핵심 도구로 선별하고 장황한 스키마 설명(schema descriptions)을 제거하여 약 1.4k 토큰으로 줄였더니, 비용이 저렴해졌을 뿐만 아니라 적절한 도구를 선택하는 능력도 향상되었습니다.

• 에이전트가 기억에 의존해 답변함: 대화가 진행됨에 따라 에이전트가 실시간 데이터를 쿼리(query)하는 대신 이전 컨텍스트에서 답변하는 경우가 발생했습니다. 이로 인해 마치 SigNoz를 전혀 사용하지 않는 것처럼 보였습니다. 각 질문에 새로운 컨텍스트를 부여함으로써 매번 실제 도구 호출(tool call)이 이루어지도록 강제했습니다.

• 잘못된 수치 표시: SigNoz는 span 지속 시간을 나노초(nanoseconds) 단위로, 에러율을 백분율(percentage)로 반환합니다. 초기 버전에서는 단위 표기에 오류가 있었습니다. 수치 변환 로직을 LLM이 아닌 코드 내부로 옮겨 수치가 항상 정확하도록 수정했습니다.

• 복잡한 쓰기 API (Complex write APIs): create_dashboard/create_alert 페이로드(payload) 구조가 깊어서 모델이 형식을 잘못 맞추는 경우가 있었습니다. 이를 Python에서 올바른 페이로드를 조립하는, 오용하기 어려운 작은 도구들로 래핑(wrap)했습니다. 이는 앞으로도 재사용할 신뢰성 패턴(reliability pattern)입니다.

• 공유 컨텍스트 버그: 자동 진단(auto-diagnosis) 기능이 채팅 에이전트의 이력을 먼저 재사용하면서 단계 제한(step limit)까지 루프(loop)를 도는 문제가 있었습니다. 새로운 에이전트를 할당함으로써 이 문제를 해결했습니다.

시도해보기 / 링크

• 코드: https://github.com/subanu-dev/sre-sidekick
• 데모:

Python, OpenTelemetry, SigNoz MCP 서버, 그리고 Foundry로 구축되었습니다. 이 프로젝트는 코딩 및 문서화를 위한 AI 코딩 어시스턴트로서 Claude Code (Anthropic)의 도움을 받아 구축되었습니다. 모든 아키텍처, 테스트 및 통합은 제가 직접 지시하고 검증했습니다.

요약 (Takeaway)

SigNoz는 플랫폼과 MCP 도구를 제공합니다. 진정한 재미는 이를 '휘두르는' 에이전트를 구축하는 것, 그리고 해커톤의 정신에 따라 에이전트가 스스로를 관찰하게 만드는 것에 있습니다. 에이전트를 관찰할 수 없다면, 당신은 에이전트를 제어하고 있는 것이 아닙니다. SRE Sidekick은 에이전트를 완전히 가시화(visible)합니다.