대부분의 관측성 (Observability) 플랫폼은 무엇이 고장 났는지를 알려줍니다. 저는 왜 고장 났는지를 파악할 수 있는 무언가를 만들고 싶었습니다.

첫 번째 해커톤 기간 동안, 저는 단순해 보이지만 믿기지 않을 정도로 흥미로운 도전을 스스로에게 부여했습니다:

AI가 SRE (Site Reliability Engineer)처럼 운영 환경의 문제를 조사할 수 있을까?

수천 개의 로그가 포함된 거대한 프롬프트를 읽는 방식이 아닙니다.
하드코딩된 스크립트를 따르는 방식도 아닙니다.
그 대신, 조사 과정을 사고(thinking through) — 다음에 어떤 정보가 필요한지 결정하고, 관측성 (Observability) 플랫폼에서 증거를 수집하며, 최종적으로 근본 원인 분석 (Root-cause analysis)에 도달하는 방식입니다.

그 아이디어가 바로 SigNoz, OpenTelemetry, FastAPI, 그리고 Gemini function calling을 기반으로 구축된 자율형 장애 조사관인 AI SRE Agent가 되었습니다.

문제점 (The Problem)

현대의 관측성 (Observability) 도구들은 텔레메트리 (Telemetry)를 수집하는 데 매우 뛰어납니다. 이 도구들은 다음을 알려줍니다:

• 어떤 서비스가 느린지
• 어떤 요청이 실패하고 있는지
• 어떤 트레이스 (Traces)의 지연 시간 (Latency)이 높은지
• 어떤 로그에 에러가 포함되어 있는지

하지만 그 이후부터 진짜 작업이 시작됩니다. 엔지니어는 여전히 다음과 같은 과정을 수동으로 수행해야 합니다:

• 트레이스 (Traces) 열기
• 로그 검색
• 서비스 비교
• 의존성 (Dependencies) 추적
• 가설 수립
• 가설 검증

대시보드는 단서를 제공할 뿐입니다. 미스터리를 해결하는 것은 엔지니어의 몫입니다.

저는 AI가 이러한 조사를 자동으로 수행할 수 있는지 확인하고 싶었습니다.

아이디어 (The Idea)

LLM (Large Language Model)에게 모든 로그와 트레이스를 하나의 거대한 프롬프트로 전달하는 대신, 저는 엔지니어처럼 행동하는 AI를 구축했습니다. 이 AI는 거의 아무런 정보가 없는 상태에서 시작하여 다음과 같이 결정합니다:

"무엇을 먼저 점검해야 할까?"

해당 정보를 받은 후, 다음과 같이 결정합니다:

"이제 다음에 무엇을 점검해야 할까?"

진단을 내릴 수 있을 만큼 충분한 확신이 생길 때까지 증거를 계속 수집합니다. 중요한 점은 조사 경로가 절대 하드코딩되지 않는다는 것입니다. 모든 결정은 모델에 의해 동적으로 이루어집니다.

아키텍처 (Architecture)

이 애플리케이션은 FastAPI로 구축된 4개의 마이크로서비스 (Microservices)로 구성됩니다:

                 ┌─────────────────────┐
                 │  frontend-service   │
                 │      Port 8001      │
...

모든 서비스는 OpenTelemetry를 통해 계측(Instrumented)되며, 트레이스(Traces), 로그(Logs), 메트릭(Metrics)을 셀프 호스팅되는 SigNoz 인스턴스로 내보냅니다.

환경을 현실적으로 만들기 위해, 각 서비스는 의도적으로 실제 운영 환경과 유사한 장애를 주입합니다:

• 무작위 지연 시간 급증 (Random latency spikes)
• HTTP 500 및 502 오류
• 느린 데이터베이스 쿼리 (Slow database queries)
• 커넥션 풀 고갈 (Connection pool exhaustion)
• AI 응답 실패
• 시뮬레이션된 트랜잭션 데드락 (Simulated transaction deadlocks)

목표는 또 다른 이커머스 데모를 만드는 것이 아니었습니다. 결점까지 포함하여 실제 운영 환경처럼 작동하는 시스템을 만드는 것이었습니다.

SigNoz를 통한 실시간 관측성 (Live Observability)

서비스가 실행되면 SigNoz는 즉시 모든 서비스로부터 텔레메트리(Telemetry)를 수집하기 시작합니다. 단순히 요청이 느리다는 것을 보는 것에 그치지 않고, 모든 서비스에 걸쳐 P99 지연 시간, 에러율, 초당 작업 수, 분산 트레이스(Distributed traces), 구조화된 로그(Structured logs)를 한눈에 파악할 수 있습니다.

SigNoz 서비스 대시보드 — AI가 개입하기도 전에 이미 원인을 포착할 수 있습니다: frontend-service와 order-service는 동일하게 16.35%의 에러율을 공유하고 있는 반면, diagnosis-agent(AI 자체)는 0%의 에러율과 10.6s의 P99를 기록하고 있습니다. 이는 AI가 단순히 빠른 요청을 처리하는 것이 아니라 다단계 추론(Multi-step reasoning)을 수행하고 있다는 힌트입니다.

AI 조사관 (AI Investigator) 구축

여기서부터 프로젝트가 흥미로워집니다. AI 에이전트는 정답을 알고 있지 않습니다. 오직 세 가지 도구에만 접근할 수 있습니다:

get_slow_traces()
get_error_logs(service_name)
get_error_traces()

그게 전부입니다. LLM은 어떤 도구를 호출할지, 어떤 서비스를 조사해야 할지, 추가 쿼리가 필요한지, 그리고 언제 충분한 증거가 수집되었는지를 스스로 결정합니다. 이로 인해 모든 조사는 고유한 과정을 거치게 됩니다.

실제 조사 (A Real Investigation)

다음은 하나의 조사 세션이 처음부터 끝까지 진행되는 과정입니다.

1단계 — 넓은 그물 던지기 (cast a wide net). AI는 먼저 가장 느린 트레이스 (traces)를 요청합니다:

get_slow_traces()

AI는 여러 개의 느린 요청을 찾아내며, 이들은 모두 동일한 방향인 frontend-service, GET /checkout, 각각 약 6초 정도를 가리키고 있습니다. 흥미로운 지점이지만, 느리다는 것이 반드시 범인임을 의미하지는 않습니다.

2단계 — 검색 범위 좁히기 (narrow the search). 모든 서비스를 하나씩 확인하는 대신, 모델은 범위를 좁힙니다:

get_error_logs(frontend-service)

로그에는 동일한 실패가 반복적으로 나타납니다: order-service가 502 에러로 실패하고 있습니다. 이제 상황이 명확해집니다. 프론트엔드 (frontend)가 실패하고 있었던 것이 아니라, 다운스트림 (downstream)의 무언가를 기다리고 있었던 것입니다.

3단계 — 진단 (the diagnosis). AI는 다음과 같이 결론을 내립니다:

• 결제 (Checkout) 지연 시간이 높음
• frontend-service가 order-service를 기다리는 중
• order-service가 HTTP 500/502를 반환함
• 근본 원인 (root cause)은 order-service 내부 또는 그 다운스트림 의존성 (downstream dependencies) 중 하나에 있을 가능성이 높음

그리고 모든 것을 다 아는 척하는 대신, 다음 조사 단계를 권장합니다.

전체 실행 과정 — 세 번의 에이전트 단계, 두 번의 도구 호출 (tool calls), 그리고 권장되는 다음 조치가 포함된 최종 진단까지, 이 모든 것이 하드코딩된 조사 스크립트 없이 생성되었습니다.

AI를 관찰 가능하게 만들기 (Making the AI Observable)

이것을 구축하면서 또 다른 생각이 들었습니다. 만약 AI가 의사결정을 내린다면, AI 자체를 어떻게 디버깅 (debug)할 수 있을까?

그래서 저는 다른 마이크로서비스 (microservice)와 똑같이 에이전트에 계측 (instrumented)을 수행했습니다. 모든 조사는 분산 트레이스 (distributed trace)를 생성합니다:

agent.investigation
│
├── agent.step.1
...

모든 LLM 요청은 프롬프트 토큰 (prompt tokens), 완료 토큰 (completion tokens), 총 토큰 (total tokens), 응답 지연 시간 (response latency), 그리고 도구 실행 타이밍 (tool execution timing)을 기록합니다. 내 애플리케이션을 디버깅하는 것과 동일한 플랫폼이 내 AI도 디버깅합니다. 이것은 이 프로젝트에서 제가 가장 좋아하는 부분이 되었습니다.

3단계의 추론 (reasoning) 과정을 거친 총 10.6초의 조사 과정입니다. 시간이 어디에 소요되는지 정확히 확인할 수 있습니다. 마지막 합성 (synthesis) 단계인 agent.step.3이 4.33초(전체 실행 시간의 40.78%)를 차지한 반면, 이전의 도구 호출 (tool-calling) 단계들은 더 빨랐습니다. 이것이 바로 채팅 기록만으로는 얻을 수 없는 통찰입니다.

운영 트래픽 시뮬레이션 (Simulating Production Traffic)

시스템을 제대로 평가하기 위해, 저는 체크아웃 요청을 지속적으로 보내는 부하 생성기 (load generator)를 구축했습니다. 일부는 성공하고, 일부는 실패하며, 일부는 매우 느려집니다. 이를 통해 SigNoz로 현실적인 트레이스 (traces), 로그 (logs), 메트릭 (metrics)이 계속 흐르게 하여, AI 조사관이 합성된 예시 대신 항상 실제 운영 환경과 유사한 형태의 텔레메트리 (telemetry)를 분석할 수 있도록 했습니다.

4개의 서비스와 부하 생성기가 나란히 실행되고 있습니다. 요약 패널(195회 시도, 158회 성공, 37회 실패, 성공률 81.03%)은 실제 온콜 (on-call) 엔지니어가 파악해야 하는 노이즈가 섞이고 부분적으로 성능이 저하된 신호의 전형적인 모습이며, 에이전트가 추론을 통해 해결해야 할 과제입니다.

가장 큰 도전 과제들 (The Biggest Challenges)

아이러니하게도, 해커톤 시간의 대부분은 AI 코드를 작성하는 데 쓰이지 않았습니다. 대신 인프라 문제를 해결하는 데 쓰였습니다. 기억에 남는 문제들은 다음과 같습니다:

• 손상된 WSL 설치 복구
• SigNoz의 새로운 Foundry 설치로의 마이그레이션 (migrating)
• Docker Desktop 대 네이티브 WSL 엔진 문제
• ClickHouse 시작 문제
• OpenTelemetry 설정
• SigNoz의 새로운 Roles Beta API 관련 인증 (auth) 문제

이러한 문제들은 개발 속도를 늦췄지만, 솔직히 말해 프로젝트를 더욱 현실적으로 만들어 주었습니다. 관측성 (Observability) 도구를 구축한다는 것은 애플리케이션 코드만큼이나 인프라에 많은 시간을 할애해야 함을 의미합니다.

배운 점

가장 큰 교훈은 AI에 관한 것이 아니라, 관측성 (Observability)에 관한 것이었습니다.

대시보드 (Dashboards)는 이미 질문할 내용을 알고 있을 때 답을 줍니다. 조사는 다음에 어떤 질문을 던져야 할지 모를 때 시작됩니다. 바로 그 지점이 AI가 가치를 발휘하는 곳입니다. 엔지니어를 대체하는 것이 아니라, 장애 조사 (Incident investigation)의 반복적인 첫 단계를 자동화함으로써 말이죠.

다음 단계는?

시간적 여유가 더 있다면, 다음과 같은 기능들을 추가하고 싶습니다:

• 에러율이 임계값을 초과할 때 자동으로 조사를 트리거하는 지속적 모니터링 (Continuous monitoring)
• 더 현실적인 운영 환경의 장애 시나리오 (Production failure scenarios)
• 모든 조사 후에 자동으로 생성되는 장애 보고서 (Automatic incident reports)
• 직접 작성한 API 도구 대신 SigNoz MCP 서버 지원
• 전문화된 에이전트들이 로그, 메트릭, 트레이스를 독립적으로 조사한 뒤 결과를 결합하는 멀티 에이전트 협업 (Multi-agent collaboration)

마치며

이번 프로젝트는 저의 **첫 해커톤 (Hackathon)**이었으며, 프로젝트 전체를 혼자서 구축했습니다. 실제 초점은 애플리케이션이 아니라 조사 프로세스에 있었기 때문에, 의도적으로 마이크로서비스 (Microservices)를 단순하게 유지했습니다.

제가 가장 자랑스럽게 생각하는 점은 텔레메트리 (Telemetry)를 분석할 수 있는 AI를 구축했다는 것이 아닙니다. **AI 자체가 관측 가능해졌다 (Observable)**는 점입니다. 모든 결정, 모든 도구 호출 (Tool call), 모든 LLM 요청, 모든 추론 단계가 SigNoz 내부에서 분산 트레이스 (Distributed trace)로 나타납니다.

우리는 단순히 애플리케이션을 관측하는 것을 넘어, 애플리케이션을 운영하는 책임이 있는 AI 시스템까지 관측하는 미래로 진입하고 있습니다. 저는 이것이 현대적인 SRE 도구의 매우 흥미로운 방향이라고 생각합니다.

GitHub 저장소

🔗 github.com/polikeybhuvan/signoz-ai-sre-agent

제안이나 아이디어, 피드백이 있다면 언제든 환영합니다!