SigNoz 텔레메트리(Telemetry)를 AI 런타임 안전 지능(Runtime Safety Intelligence)으로 전환하기

AI 에이전트(AI agents)는 일반적으로 전통적인 소프트웨어처럼 실패하지 않습니다. 이들은 종종 동일한 도구 호출을 재시도하거나, 계획 단계(planning steps)를 반복 루프 돌거나, 너무 많은 토큰을 사용하거나, 응답하지 않는 종속성(dependency)에서 멈춰 서는 등, 조용히 상태가 악화되는 동안에도 계속 실행되는 경우가 많습니다. 외부에서 보기에는 아무것도 완전히 고장 난 것처럼 보이지 않습니다. 하지만 내부적으로는 워크플로(workflow)가 안전하지 않은 상태로 변하고 있습니다.

그 간극을 메우기 위해 Sentinel이 구축되었습니다.

Sentinel은 SigNoz와 OpenTelemetry를 기반으로 구축된 AI 런타임 안전 감독관(AI Runtime Safety Supervisor)입니다. 관측성(observability)을 대체하는 대신, 그 위에 안전 계층(safety layer)을 추가합니다. SigNoz는 무엇이 일어났는지를 알려줍니다. Sentinel은 해당 워크플로가 안전한지, 왜 문제가 발생했는지, 그리고 엔지니어가 다음에 무엇을 해야 하는지를 알려줍니다.

저는 Agents of SigNoz 해커톤을 위해 Sentinel을 구축했으며, 이는 단순하지만 중요한 아이디어를 탐구하기 위한 방법이었습니다: 텔레메트리(telemetry)는 단순한 트레이스(traces) 목록이 아니라, 증거에 기반한 행동(evidence-backed action)이 될 때 가장 가치 있다는 것입니다.

Sentinel이 하는 일

Sentinel은 런타임 텔레메트리(runtime telemetry)를 설명 가능한 엔지니어링 지능(explainable engineering intelligence)으로 전환합니다.

높은 수준(high level)에서 Sentinel은 다음과 같은 작업을 수행합니다:

• 데모 생성기(demo generator) 또는 라이브 SigNoz 배포 환경으로부터 텔레메트리(telemetry)를 수집하고,
• 트레이스(traces), 메트릭(metrics), 로그(logs)를 내부 워크플로 증거(internal workflow evidence)로 변환하며,
• 결정론적 런타임 안전 점검(deterministic runtime safety checks)을 실행하고,
• 런타임 안전 점수(Runtime Safety Score)를 생성하며,
• 증거 참조(evidence references)와 함께 결과를 설명하고,
• 엔지니어링 팀이 다음에 무엇을 검토해야 하는지 권장합니다.

목표는 또 다른 관측성 대시보드(observability dashboard)를 만드는 것이 아닙니다. 목표는 자율 워크플로(autonomous workflow)가 언제 안전하지 않은 동작으로 표류하고 있는지 팀이 이해하도록 돕는 것입니다.

이 문제를 선택한 이유

AI 시스템이 더욱 자율적으로 변함에 따라, 실패 모드(failure modes)는 덜 명확해집니다.

워크플로는 여전히 응답을 반환할 수 있지만, 조용히 너무 많은 토큰을 소비하거나, 동일한 도구를 계속 두드리거나, 차단된 종속성(blocked dependency)에서 멈추거나, 재귀 루프(recursive loop)에 진입할 수 있습니다. 전통적인 관측성 도구(observability tools)는 필수적이지만, 대개 최종 판단을 엔지니어의 몫으로 남겨둡니다.

Sentinel은 해당 텔레메트리 (Telemetry) 위에 구조화된 안전 계층 (safety layer)을 추가합니다.

이것이 중요한 이유는 실제 시스템에서 문제는 종종 단순히 "무슨 일이 일어났는가?"가 아니라 다음과 같기 때문입니다:

이 워크플로 (workflow)가 여전히 건강한가?
왜 이러한 동작이 위험한가?
그 결론을 뒷받침하는 증거는 무엇인가?
지금 무엇을 해야 하는가?

Sentinel은 이러한 질문들에 대해 반복 가능하고 추적 가능한 방식으로 답하기 위한 저의 시도입니다.

아키텍처 (Architecture)

Sentinel은 직관적인 파이프라인 (pipeline)을 사용합니다:

AI 에이전트 (AI Agent) → OpenTelemetry → SigNoz → SigNoz MCP → Sentinel → 런타임 안전 점수 (Runtime Safety Score) → 설명 (Explanation) → 권장 사항 (Recommendation)

중요한 점은 Sentinel이 자체적인 텔레메트리 (telemetry) 소스를 만들어내지 않는다는 것입니다. Sentinel은 SigNoz로부터 증거를 소비하여 이를 런타임 분석 (runtime analysis)으로 변환합니다.

주요 계층은 다음과 같습니다:

텔레메트리 수집 (Telemetry ingestion): 데모 또는 라이브 텔레메트리를 수신합니다.
런타임 상관관계 분석 (Runtime correlation): 트레이스 (traces), 메트릭 (metrics), 로그 (logs)를 일관된 워크플로 증거로 연결합니다.
런타임 평가 (Runtime assessment): 결정론적인 안전 점수 (deterministic safety score)를 계산합니다.
설명 생성 (Explanation generation): 점수를 사람이 읽을 수 있는 추론으로 변환합니다.
권장 사항 생성 (Recommendation generation): 다음 엔지니어링 조치를 제안합니다.
결과 게시 (Result publication): 분석 내용을 대시보드와 워크플로 페이지에 노출합니다.

이러한 구조는 시스템을 설명 가능하게(explainable) 유지하며 디버깅을 용이하게 만듭니다.

SigNoz 활용 방법

SigNoz는 라이브 텔레메트리 경로의 기반입니다.

저는 세 가지 용도로 SigNoz를 사용했습니다:

1. OpenTelemetry 내보내기 (export)

Sentinel의 애플리케이션은 OpenTelemetry를 통해 트레이스 (traces)를 방출할 수 있습니다. 해당 트레이스들은 SigNoz로 내보내지며, 그곳에서 관측 가능한 런타임 데이터의 일부가 됩니다.

2. SigNoz MCP 서버

텔레메트리를 수동으로 직접 스크래핑하는 대신, Sentinel은 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)을 사용하여 SigNoz MCP 서버에 연결합니다. 이를 통해 Sentinel은 트레이스, 트레이스 상세 정보, 로그 및 메트릭을 구조화된 방식으로 요청할 수 있습니다.

3. 런타임 분석 (Runtime analysis)

MCP 결과는 Sentinel의 내부 워크플로 모델로 매핑됩니다. 여기서 Sentinel은 안전 점수를 계산하고 증거에 기반한 설명과 권장 사항을 생성합니다.

이 부분이 프로젝트의 핵심 통합 지점이었습니다. 파서(Parser)가 실제 MCP 응답 형태와 일치하게 되자, 라이브 트레이스(Live traces)가 대시보드로 올바르게 흐르기 시작했습니다.

데모 모드(Demo mode)와 라이브 모드(Live mode)

Sentinel은 두 가지 운영 모드를 지원합니다.

데모 모드 (Demo mode)

데모 모드는 현실적인 AI 워크플로 텔레메트리(Telemetry)를 함께 제공하므로, 실제 SigNoz 설정 없이도 전체 제품을 탐색할 수 있습니다. 이를 통해 예측 가능한 환경에서 시스템을 시연하고 안전 파이프라인(Safety pipeline)을 테스트하기가 용이합니다.

라이브 SigNoz 모드 (Live SigNoz mode)

TELEMETRY_SOURCE=signoz로 설정하면, Sentinel은 로컬 SigNoz MCP 서버에 연결하여 실제 트레이스를 로드하고, 라이브 데이터에 대해 동일한 런타임 분석 파이프라인(Runtime analysis pipeline)을 보여줍니다.

가장 좋은 점은 두 모드 모두에서 분석 경로가 동일하게 유지된다는 것입니다. 오직 텔레메트리(Telemetry)의 소스만 바뀔 뿐입니다.

덕분에 디버깅이 훨씬 쉬워졌습니다. 먼저 데모 데이터로 파이프라인을 검증한 다음, MCP 통합이 준비되면 라이브 SigNoz로 전환할 수 있었기 때문입니다.

구축하며 배운 몇 가지 사항들

가장 큰 교훈은 통합 작업이란 종종 가정이 아닌 현실을 맞추는 과정이라는 점이었습니다.

처음에는 MCP 응답이 단순하고 평면적(Flat)일 것이라고 가정했습니다. 하지만 그렇지 않았습니다. 실제 응답은 중첩된 데이터(Nested data)로부터 파싱(Parsing)이 필요했으며, 실제 행(Row) 구조를 Sentinel의 워크플로 모델로 매핑하기 위해 파서를 업데이트해야 했습니다.

또한 폴백 동작(Fallback behavior)이 중요하다는 것도 배웠습니다.

MCP 서버를 사용할 수 없을 때, Sentinel은 충돌하거나 깨진 상태를 보여서는 안 됩니다. 사용자에게 어떤 일이 일어났는지 알리면서, 폴백 데이터(Fallback data)를 사용 중임을 명확히 보여주어야 합니다. 이 덕분에 대시보드의 사용성이 훨씬 높아졌습니다.

상태(State)에 관한 또 다른 중요한 교훈도 있었습니다.

새로고침 후 대시보드에 오래된 소스 정보가 표시되는 버그를 발견했습니다. 이는 소스 상태를 새로고침하지 않고 캐시된 증거(Cached evidence)를 재사용했기 때문에 발생했습니다. 이를 수정함으로써 데모의 신뢰성을 훨씬 높일 수 있었습니다.

이러한 문제들은 개별적으로는 작았지만, 이들이 모여 프로토타입과 신뢰할 수 있는 프로젝트 사이의 차이를 만들어냈습니다.

대시보드 표시 내용

Sentinel의 대시보드는 기본적인 운영 질문에 빠르게 답할 수 있도록 설계되었습니다.

다음 내용을 확인할 수 있습니다:

• 얼마나 많은 워크플로 (workflows)가 정상(healthy), 주의(watch), 경고(warning) 또는 심각(critical) 상태인지
• 활성화된 텔레메트리 (telemetry) 소스
• Sentinel이 SigNoz에 연결되어 있는지 또는 폴백 (fallback) 상태인지
• 얼마나 많은 트레이스 (traces)가 로드되었는지
• 각 워크플로에 대한 런타임 안전 점수 (Runtime Safety Score)
• 각 결론 뒤에 있는 증거 체인 (evidence chain)
• 그리고 권장되는 다음 조치 (recommended next action)

워크플로 상세 페이지는 한 단계 더 나아가 점수 공식, 타임라인, 뒷받침하는 증거, 그리고 최종 권장 사항 뒤에 있는 추론 과정을 보여줍니다.

이것은 저에게 매우 중요했습니다. 왜냐하면 Sentinel이 블랙박스 (black box)처럼 느껴지는 것을 원하지 않았기 때문입니다.

증거가 중요한 이유

안전 점수는 신뢰할 수 있을 때만 유용합니다.

이것이 바로 Sentinel이 모든 평가, 설명 및 권장 사항에 evidenceRefs를 연결하여 유지하는 이유입니다. 이러한 참조는 스팬 (spans), 메트릭 (metrics), 로그 (logs)와 같은 특정 텔레메트리 항목을 가리킵니다.

이를 통해 시스템은 몇 가지 중요한 속성을 갖게 됩니다:

• 관찰 가능성 (observable)
• 설명 가능성 (explainable)
• 추적 가능성 (traceable)
• 검증 가능성 (verifiable)
• 인간 주도 (human-governed)

Sentinel의 권장 사항은 조언일 뿐입니다. 워크플로를 종료하거나 자동화된 제어 조치를 취하지 않습니다. 대신 엔지니어가 더 나은 컨텍스트 (context)를 바탕으로 더 나은 결정을 내릴 수 있도록 돕습니다.

스크린샷

프로젝트의 스크린샷 몇 장을 소개합니다:

대시보드 개요 (Dashboard Overview)

데모 모드 (Demo Mode)

런타임 평가 (Runtime Assessment)

증거 추적 가능성 (Evidence Traceability)

증거 추적 가능성 (Evidence Traceability)

증거 체인 (Evidence Chain)

실시간 SigNoz 통합 (Live SigNoz Integration)

기술 스택 (Tech stack)

Sentinel은 다음 기술로 구축되었습니다:

Next.js 15
TypeScript
Tailwind CSS
OpenTelemetry
SigNoz
MCP (Model Context Protocol)
deterministic heuristic analysis를 통한 런타임 안전 점수화

다음 개선할 사항 (What I would improve next)

만약 Sentinel 개발을 계속한다면, 다음 단계는 다음과 같습니다:

더 풍부한 역사적 분석(richer historical analysis),
더 진보된 다중 에이전트 상관관계 분석(more advanced multi-agent correlation),
정책 기반 안전 규칙(policy-based safety rules),
실시간 텔레메트리로부터의 개선된 워크플로우 명명(better workflow naming from live telemetry),
그리고 강화된 예측 위험 점수화(stronger predictive risk scoring).

이 모든 것은 자연스러운 확장 과정이지만, 현재 버전만으로도 핵심 아이디어를 보여줍니다. 즉, 관측 가능성(observability)을 실행 가능한 런타임 안전 지능으로 전환할 수 있다는 것입니다.

마지막 생각 (Final thoughts)

Sentinel을 구축하면서 깨달은 것은, 관측 가능성이 명확한 의사 결정 계층과 연결될 때 훨씬 더 강력해진다는 것입니다.

SigNoz는 원시적인 가시성(raw visibility)을 제공합니다. Sentinel은 그 가시성을 엔지니어가 조치할 수 있는 구조화된 안전 신호로 변환합니다.

자율 시스템의 경우, 이 추가 계층이 중요합니다. 이는 팀들이 시스템이 무엇을 했는지뿐만 아니라 계속 실행하기에 여전히 안전한지까지 이해하도록 돕습니다.

링크
GitHub 저장소: [https://github.com/25cs249-create/Sentinel-Runtime-Safety]
데모 비디오: [https://drive.google.com/file/d/1kgzIOSTd5pY-geeudHDrfz0KxJf2pJxD/view?usp=drivesdk]