SentinelAI 구축하기: SigNoz와 OpenTelemetry를 사용하여 AI 에이전트의 관찰 가능성(Observability)을 확보하는 방법

블랙박스(black-box) AI 워크플로우에서 실시간 트레이스(traces), 로그(logs), 메트릭(metrics), 보안 모니터링, 그리고 AI 기반의 근본 원인 분석(root cause analysis)까지.

Hook

AI 에이전트는 추론하고, 도구를 호출하며, 지식을 검색하고, 복잡한 워크플로우를 자동화하는 등 점점 더 강력해지고 있습니다. 하지만 프로덕션 환경에서 에이전트가 실패할 때, 가장 큰 과제는 버그를 수정하는 것이 아니라 그것이 왜 발생했는지 이해하는 것입니다.

WeMakeDevs에서 주최한 Agents of SigNoz Hackathon 기간 동안, 저는 바로 이 문제를 해결하고 싶었습니다. 또 다른 AI 챗봇을 만드는 대신, 저는 SigNoz와 OpenTelemetry를 사용하여 개발자에게 AI 에이전트에 대한 완전한 가시성을 제공하는 관찰 가능성(observability) 플랫폼인 SentinelAI를 구축했습니다.

The Problem

AI 애플리케이션을 실험하면서, 기존의 로깅(logging)만으로는 충분하지 않다는 것을 깨달았습니다.

몇 가지 일반적인 질문들이 해결되지 않은 채로 남아 있었습니다:

• 어떤 도구 호출(tool call)이 실패를 유발했는가?
• 왜 갑자기 지연 시간(latency)이 증가했는가?
• 어떤 프롬프트(prompt)가 가장 많은 토큰을 소비했는가?
• 왜 에이전트가 환각(hallucinate)을 일으켰는가?
• 어떤 API가 병목 현상(bottleneck)이 되었는가?

적절한 관찰 가능성(observability) 없이는, AI 시스템이 복잡해짐에 따라 디버깅(debug)이 어려워집니다.

Why SigNoz?

저는 여러 신호(signals)를 한곳에서 수집할 수 있는 관찰 가능성(observability) 플랫폼을 원했습니다.

SigNoz는 다음과 같은 기능을 지원하기 때문에 눈에 띄었습니다:

• OpenTelemetry 네이티브 인스트루멘테이션 (instrumentation)
• 분산 트레이싱 (Distributed tracing)
• 메트릭 (Metrics)
• 로그 (Logs)
• 대시보드 (Dashboards)
• 알림 (Alerts)

서로 다른 모니터링 도구 사이를 오가는 대신, 단일 인터페이스에서 전체 AI 워크플로우를 검사할 수 있었습니다.

Project Architecture

여기에 아키텍처 다이어그램을 포함합니다.

설명:

       User
        ↓
  Frontend (React)
...

Building SentinelAI

서버만을 모니터링하는 대신, AI의 추론(reasoning) 자체를 모니터링하고 싶었습니다.

애플리케이션은 여러 모듈을 포함하고 있습니다.

Dashboard

대시보드는 시스템에 대한 빠른 개요를 제공합니다.

다음 내용을 표시합니다:

• 에이전트 상태 점수 (Agent Health Score)
• 활성 요청 (Active Requests)
• 평균 지연 시간 (Average Latency)
• 토큰 사용량 (Token Usage)
• 예상 비용 (Estimated Cost)
• 에러율 (Error Rate)
• 실시간 알림 (Live Alerts)

상태 점수는 여러 신호를 하나의 지표로 결합하여, 상태가 좋지 않은 AI 에이전트를 더 쉽게 식별할 수 있게 해줍니다.

실시간 에이전트 모니터링 (Live Agent Monitoring)

모든 AI 요청은 개별적으로 추적됩니다.

각 요청에 대해 다음 내용을 기록합니다:

• 프롬프트 (Prompt)
• 응답 (Response)
• 실행 시간 (Execution time)
• 토큰 사용량 (Token usage)
• 사용된 모델 (Model used)
• 도구 호출 (Tool calls)
• 상태 (Status)

개발자는 로그를 수동으로 검색하는 대신, 개별 실행 과정을 처음부터 끝까지 검사할 수 있습니다.

OpenTelemetry 통합 (OpenTelemetry Integration)

이 프로젝트에서 가장 흥미로운 부분 중 하나는 AI 요청을 계측 (instrumenting)하는 것이었습니다.

모든 요청은 나중에 SigNoz 내부에서 시각화할 수 있는 텔레메트리 (telemetry)를 생성합니다.

이를 통해 시간이 어디에 소비되는지 이해할 수 있었습니다:

• 프롬프트 처리 (Prompt processing)
• 검색 (Retrieval)
• LLM 생성 (LLM generation)
• 외부 API 호출 (External API calls)
• 데이터베이스 작업 (Database operations)

SigNoz 사용하기

SigNoz는 SentinelAI의 관찰 가능성 (observability) 중추가 되었습니다.

저는 다음과 같은 용도로 SigNoz를 사용했습니다:

분산 추적 (Distributed Traces)

AI 요청의 모든 단계를 시각화하기 위해 사용합니다.

메트릭 (Metrics)

다음 항목을 모니터링하기 위해 사용합니다:

• 요청 지연 시간 (Request latency)
• 에러율 (Error rate)
• 토큰 소비량 (Token consumption)

로그 (Logs)

실패를 조사하고 문제를 디버깅하기 위해 사용합니다.

대시보드 (Dashboards)

시스템 성능의 개요를 생성하기 위해 사용합니다.

알림 (Alerts)

비정상적인 지연 시간과 실패를 빠르게 식별하기 위해 사용합니다.

보안 모니터링 (Security Monitoring)

제가 구축하면서 특히 즐거웠던 기능 중 하나는 보안 모니터링 (Security Monitor)입니다.

다음 사항들을 탐지합니다:

• 프롬프트 인젝션 (Prompt Injection) 시도
• 탈옥 (Jailbreak) 프롬프트
• 의심스러운 도구 호출 (Suspicious tool calls)
• 고위험 요청 (High-risk requests)

각 요청은 보안 위험 점수 (Security Risk Score)를 부여받으며, 이를 통해 개발자는 조사 우선순위를 정할 수 있습니다.

AI 근본 원인 분석 (AI Root Cause Analysis)

가공되지 않은 로그 (Raw logs)는 여전히 이해하기 어려울 수 있습니다.

그래서 저는 AI 기반 분석 엔진을 추가했습니다.

이상 징후 (Anomaly)가 발생할 때마다, SentinelAI는 자동으로 다음 항목들을 생성합니다:

• 장애 요약 (Incident summary)
• 근본 원인 (Root cause)
• 심각도 (Severity)
• 제안된 해결책 (Suggested resolution)
• 권장되는 다음 단계 (Recommended next steps)

이는 디버깅 (Debugging) 시간을 크게 단축해 줍니다.

분석 및 감사 내보내기 (Analytics & Audit Export)

플랫폼을 디버깅 이상의 용도로 유용하게 만들기 위해, 다음과 같은 기능들도 구현했습니다:

• 지연 시간 분석 (Latency analytics)
• 토큰 사용량 트렌드 (Token usage trends)
• 비용 추정 (Cost estimation)
• JSON 내보내기 (JSON export)
• CSV 내보내기 (CSV export)

이러한 내보내기 기능은 엔지니어링 팀과 텔레메트리 (Telemetry)를 공유하고 컴플라이언스 (Compliance) 워크플로우를 지원하는 것을 더 쉽게 만들어 줍니다.

제가 직면했던 도전 과제들

가장 큰 도전 과제는 UI를 구축하는 것이 아니었습니다.

진정한 도전 과제는 관찰 가능성 (Observability)이 어떻게 작동하는지 이해하는 것이었습니다.

처음에는 로그 (Logs)만으로도 충분할 것이라고 가정했습니다.

SigNoz를 통합하면서, 트레이스 (Traces), 메트릭 (Metrics), 로그 (Logs)를 결합하는 것이 단일 신호에 의존하는 것보다 훨씬 더 풍부한 컨텍스트 (Context)를 제공한다는 것을 깨달았습니다.

또 다른 과제는 개발자들이 이해하기 쉬운 방식으로 AI 텔레메트리 (Telemetry)를 구성하는 것이었습니다.

내가 배운 것들

이번 해커톤은 프로덕션 (Production) AI에 대해 생각하는 방식을 완전히 바꾸어 놓았습니다.

주요 교훈은 다음과 같습니다:

• 관찰 가능성 (Observability)은 AI 모델 자체만큼이나 중요합니다.
• 분산 트레이싱 (Distributed tracing)은 디버깅을 훨씬 쉽게 만듭니다.
• 메트릭 (Metrics)은 사용자가 문제를 인지하기 전에 트렌드를 식별하는 데 도움이 됩니다.
• AI 애플리케이션은 성능 모니터링 외에도 보안 모니터링이 필요합니다.
• OpenTelemetry는 서로 다른 서비스 전반에서 작동하는 유연한 표준을 제공합니다.

향후 개선 사항

SentinelAI 작업을 계속한다면, 다음과 같은 기능을 추가하고 싶습니다:

• 멀티 에이전트 워크플로우 시각화 (Multi-agent workflow visualization)
• Kubernetes 모니터링
• 실시간 이상 탐지 (Real-time anomaly detection)
• 예측적 장애 알림 (Predictive incident alerts)
• Slack 및 Microsoft Teams 알림
• 멀티 테넌트 대시보드 (Multi-tenant dashboards)

결론

SentinelAI를 구축하며 성공적인 AI 애플리케이션에는 정확한 응답 그 이상이 필요하다는 것을 배웠습니다. 즉, 가시성 (Visibility), 신뢰성 (Reliability), 그리고 보안 (Security)이 필요합니다.

OpenTelemetry와 SigNoz를 결합함으로써, 저는 개발자들이 AI 에이전트의 실행을 블랙박스 (Black box)로 취급하는 대신 모든 단계를 이해할 수 있도록 돕는 플랫폼을 구축할 수 있었습니다.

이번 해커톤은 실제 AI 시스템을 위한 실용적인 것을 구축하는 동시에 현대적인 관찰 가능성 (Observability) 관행을 탐구할 수 있는 훌륭한 기회였습니다.