«관측성 (Observability) 도구들은 텔레메트리 (Telemetry)를 수집하는 데 매우 뛰어납니다. 하지만 데이터가 수집된 후에도 개발자는 여전히 로그를 조사하고, 근본 원인 (Root cause)을 식별하며, 무엇을 수정할지 결정해야 합니다. 저는 다른 질문을 탐구하고 싶었습니다: AI 에이전트가 관측성 데이터를 이해하고 개발자가 다음 단계로 더 빠르게 나아갈 수 있도록 도울 수 있을까?»

시작

이 해커톤을 시작했을 때, 저는 AI SRE 에이전트를 만들 계획이 아니었습니다.

저의 첫 번째 과제는 훨씬 간단했습니다. SigNoz를 위한 텔레메트리를 생성할 수 있는 애플리케이션이 필요했습니다.

처음부터 새로운 마이크로서비스 (Microservice)를 만드는 대신, 이전에 구축했던 오래된 PlantNet 식물 식별 백엔드를 재사용했습니다. 목표는 여기에 인스트루멘테이션 (Instrumentation)을 적용하여 SigNoz로 텔레메트리를 보내고, 관측성이 실제로 어떻게 작동하는지 이해하는 것이었습니다.

처음에는 Google Colab에서 실험했지만, SigNoz를 실행하고 백엔드 서비스를 지속적으로 테스트하기에는 적합한 환경이 아니라는 것을 빠르게 깨달았습니다. 저는 모든 것을 GitHub Codespaces로 마이그레이션했고, 그곳에서 작동할 수 있도록 PlantNet 백엔드를 수정했습니다.

SigNoz 학습하기

SigNoz를 실행하는 것은 어려운 부분이 아니었습니다.

의미 있는 텔레메트리를 SigNoz에 넣는 것이 어려웠습니다.

거의 일주일 동안 저는 다음 사항에 집중했습니다:

• SigNoz 설정
• 백엔드 수정
• 텔레메트리가 대시보드에 도달하는 방식 이해
• 데이터가 나타나지 않는 이유 디버깅 (Debugging)

제 코드에 문제가 있다고 생각했던 여러 상황이 있었지만, 알고 보니 SigNoz 서비스가 중단되어 단순히 재시작이 필요한 경우였습니다.

다음 명령어를 사용했습니다:

docker restart signoz-signoz-0

방향 전환

처음 제 계획은 많은 관측성 프로젝트와 유사했습니다:

• 지연 시간 (Latency) 모니터링
• 실패한 요청 조사
• 텔레메트리 시각화

SigNoz를 탐색하며 시간을 보낸 후, 저는 제가 주로 SigNoz가 이미 제공하고 있는 정보를 소비하고 있을 뿐이라는 것을 깨달았습니다.

그것은 또 다른 질문을 던지게 했습니다:

“만약 텔레메트리 (Telemetry) 데이터가 대시보드에 표시되는 것에 그치지 않고, AI 에이전트 (AI agent)에 의해 소비될 수 있다면 어떨까?”

그 질문은 프로젝트의 방향을 완전히 바꾸어 놓았습니다.

또 다른 모니터링 대시보드를 만드는 대신, 저는 텔레메트리 (Telemetry)를 읽고, 장애를 설명하며, 해결책을 제안할 수 있는 AI 어시스턴트 (AI assistant)를 구축하기 시작했습니다.

AI SRE 에이전트 구축하기

최종적인 워크플로우 (Workflow)는 다음과 같습니다:

1. 사용자가 진단 스캔을 시작합니다.
2. 에이전트가 SigNoz에 텔레메트리 (Telemetry)를 요청합니다.
3. SigNoz가 JSON 형식으로 텔레메트리 (Telemetry)를 반환합니다.
4. JSON 데이터가 Llama 3.1 모델을 실행 중인 Groq으로 전송됩니다.
5. 모델이 근본 원인 분석 (Root cause analysis)을 수행합니다.
6. 진단 보고서가 표시됩니다.
7. 사용자는 생성된 코드 수정 사항을 적용하고 업데이트된 서비스를 테스트할 수 있습니다.

*에이전트의 관찰 가능성 확보
*
제가 마음에 들었던 설계 결정 중 하나는 AI 에이전트 (AI agent) 자체를 계측 (Instrumenting)하는 것이었습니다.

에이전트는 단순히 관찰 가능성 (Observability) 데이터를 소비하기만 하는 것이 아니라, 다음과 같은 작업 중에 자체적인 OpenTelemetry 스팬 (Spans)을 생성합니다:

• 텔레메트리 (Telemetry) 가져오기
• 장애에 대한 추론 (Reasoning)
• LLM 호출

이는 진단 에이전트 자체도 SigNoz 내부에서 모니터링될 수 있음을 의미합니다.

이것은 관찰 가능성 (Observability) 워크플로우 (Workflow)의 자연스러운 확장처럼 느껴졌습니다.

자동 수정 워크플로우 (Auto-Fix Workflow)

AI가 분석을 완료하면, 제안된 복구 조치 (Remediation)가 포함된 Python 코드 블록을 생성합니다.

응답을 수동으로 복사하는 대신, 애플리케이션은 생성된 코드를 추출하여 대상 서비스에 추가합니다.

인터페이스는 또한 다음과 같은 기능을 제공합니다:

• 원본 서비스를 복구하는 버튼
• 업데이트된 서비스를 실행하는 버튼
• 검증을 위한 실시간 코드 뷰어 (live code viewer)

목표는 엔지니어를 대체하는 것이 아니라, 문제를 식별한 시점부터 가능한 해결책을 테스트하기까지의 경로를 단축하는 것이었습니다.

엔지니어링 과제 (Engineering Challenges)

프로젝트 구축 과정에는 여러 번의 반복 작업이 포함되었습니다.

가장 주요한 과제들은 다음과 같았습니다:

• Google Colab에서 GitHub Codespaces로의 전환
• SigNoz의 올바른 설정 (configuring)
• 누락된 텔레메트리 (telemetry) 디버깅
• 반복되는 서비스 재시작 처리
• Codespaces 내부의 다중 터미널 프로세스 관리
• LLM이 일반적인 조언 대신 유용한 해결책 (remediation)을 생성하도록 프롬프트 (prompts) 개선
• 중복된 패치 (patches)가 대상 서비스를 반복적으로 수정하는 것을 방지

각 문제는 구현 방식을 변화시켰으며 최종 워크플로 (workflow)를 형성하는 데 도움을 주었습니다.

리포지토리 구조 (Repository Structure)

프로젝트는 몇 가지 주요 구성 요소로 나뉩니다:

• agent2.py — 텔레메트리 (telemetry)를 가져오고, 프롬프트를 구축하며, Groq와 통신합니다.
• app.py — 진단 및 코드 실행을 위한 Streamlit 인터페이스입니다.
• ai_agent_tracer.py — AI 에이전트를 위한 OpenTelemetry 계측 (instrumentation)입니다.
• service.py — 자동 수정 (auto-fix) 시연 중에 사용되는 대상 서비스입니다.

🔗 GitHub 리포지토리: https://github.com/suhaskamde09-lgtm/signoz

현재의 한계점 (Current Limitations)

이 프로젝트는 아직 초기 프로토타입 (prototype) 단계입니다.

현재 기능은 다음과 같습니다:

• 수동 스캔 후 텔레메트리 (telemetry) 분석
• 해결책 제안 (remediation suggestions) 생성
• 생성된 코드를 로컬에 적용할 수 있도록 허용

수정 사항을 자동으로 배포하거나 생성된 패치 (patch)가 정확한지 검증하지는 않습니다. 생성된 코드를 신뢰하기 전에는 여전히 인간의 검토가 필요합니다.

향후 과제 (Future Work)

다음으로 탐구하고 싶은 몇 가지 방향이 있습니다:

• 단일 백엔드 대신 여러 서비스 분석
• 알림 (Alerts)으로부터 진단 자동 트리거
• 로컬 파일을 편집하는 대신 GitHub Pull Request 생성
• 더 신뢰할 수 있는 복구 (Remediation)를 위한 프롬프트 엔지니어링 (Prompt Engineering) 개선
• 생성된 수정 사항을 적용하기 전 검증 수행

*맺음말 (Final Thoughts)
*
이 프로젝트는 기존 백엔드에 계측 (Instrumentation)을 수행하며 SigNoz를 배우려는 시도로 시작되었습니다.

그 과정에서 이 프로젝트는 관측 가능성 (Observability) 데이터를 실행 가능한 권장 사항으로 변환하는 AI 지원 SRE 워크플로라는 다른 형태로 진화했습니다.

관측 가능성 플랫폼을 대체하는 것이 아니라, 그 위에 구축하는 것이 목표입니다. 즉, 엔지니어가 최종 결정권을 유지하면서도 AI를 사용하여 개발자가 장애를 더 빠르게 이해할 수 있도록 돕는 것입니다.