텔레메트리에서 자동화된 인시던트 대응까지: 나의 DevOps 및 관측 가능성 여정

설명: OpenTelemetry, Prometheus, Loki, Tempo, Grafana, 그리고 Codex CLI를 사용하여 FastAPI 주문 추적 애플리케이션에 관측 가능성 및 자동화된 인시던트 대응 기능을 구축하는 실습 기반 학습 여정.

텔레메트리에서 자동화된 인시던트 대응까지

DataTalksClub AI Dev Tools Zoomcamp의 일환으로, 저는 간단하지만 실용적인 과제에 참여했습니다. 바로 단순한 FastAPI 애플리케이션을 관측 가능한 시스템과 자동화된 인시던트 대응 기능을 갖춘 시스템으로 변모시키는 것이었습니다.

이 프로젝트는 SQLite 기반의 기본적인 주문 추적기(Order Tracker) 애플리케이션으로 시작되었습니다.

최종적으로 이 시스템은 다음 작업을 수행할 수 있도록 진화했습니다:

• 메트릭, 로그, 트레이스를 수집하고
• Grafana에서 텔레메트리를 시각화하며
• **알림(alerting)**을 통해 애플리케이션 오류를 감지하고
• 인시던트를 인시던트 대응 서비스로 전송하며
• 조사를 위한 증거를 제공하고
• 문제를 조사하고 해결하기 위해 코딩 에이전트를 트리거합니다.

저에게 가장 가치 있는 교훈은 관측 가능성(observability)이 단순히 데이터를 수집하는 것만이 아니라는 점입니다.

그것은 **감지(detection) → 조사(investigation) → 해결(remediation) → 검증(verification)**을 연결하는 것입니다.

문제점

기본 애플리케이션도 개발 중에는 완벽하게 작동하다가 실제 운영 환경(production)에서 실패할 수 있습니다.

주문 추적 API의 경우, 실패는 다음과 같이 간단해 보일 수 있습니다:

GET /api/orders/express-1002

이 서버 오류를 반환하는 경우입니다.

관측 가능성이 없다면 워크플로우는 종종 다음과 같은 형태가 됩니다:

뭔가 고장 났다
        ↓
애플리케이션 로그 확인
...

이 방법도 작동하지만, 시스템이 커질수록 점점 더 어려워집니다.

저는 텔레메트리가 이러한 단계들을 연결하는 데 도움을 줄 수 있는 워크플로우를 구축하고 싶었습니다.

해결책

최종 아키텍처는 여러 구성 요소를 도입했습니다:

이 아키텍처는 텔레메트리 수집, 저장, 시각화, 알림 및 인시던트 대응을 분리합니다.

애플리케이션에 계측(Instrumenting the Application) 추가하기

첫 번째 단계는 FastAPI 애플리케이션에 OpenTelemetry 계측을 추가하는 것이었습니다.

저는 각 주문 조회(order lookup)가 다음을 포함한 유용한 텔레메트리를 생성하도록 만들고 싶었습니다:

• HTTP 라우트 (HTTP route)
• HTTP 상태 코드 (HTTP status code)
• 요청 정보 (request information)
• 로그 (logs)
• 추적 (traces)
• 요청 지표 (request metrics)

예를 들어:

GET /api/orders/standard-1001
→ 200

그리고:

GET /api/orders/standard-1002
→ 404

중요한 부분은 단순히 요청이 발생했다는 것을 아는 것이 아니었습니다.

텔레메트리는 다음 질문에 답할 수 있을 만큼 충분한 컨텍스트가 필요했습니다:

어떤 엔드포인트에서 실패했는지, HTTP 상태 코드는 무엇이었는지, 그리고 요청 중에 무슨 일이 일어났었는지?

관측 가능성 스택(Observability Stack) 추가하기

다음 단계는 애플리케이션을 관측 가능성 스택에 연결하는 것이었습니다:

• OpenTelemetry Collector: 텔레메트리를 수신하고 라우팅합니다.
• Prometheus: 지표 (metrics)
• Loki: 로그 (logs)
• Tempo: 추적 (traces)
• Grafana: 시각화 및 알림 (visualization and alerting)

OpenTelemetry Collector가 중앙 텔레메트리 파이프라인 역할을 했습니다.

개념적으로:

Application
    │
    │ OTLP
...

그런 다음 Grafana는 이러한 신호들을 탐색하기 위한 단일 인터페이스를 제공합니다.

이것은 프로젝트에서 얻은 중요한 교훈 중 하나였습니다:

지표(Metrics)는 무언가가 일어나고 있음을 알려줍니다.
로그(Logs)는 무슨 일이 일어났는지 설명하는 데 도움을 줍니다.
추적(Traces)은 어디서 일어났는지 보여주는 데 도움을 줍니다.

이 세 가지를 함께 사용하면 단일 신호에 의존하는 것보다 훨씬 더 유용한 운영 컨텍스트를 제공합니다.

Grafana 알림 (Grafana Alerting)

텔레메트리가 사용 가능해진 후, 저는 서버 측 실패에 대한 Grafana 알림을 구성했습니다.

목표는 5xx 응답을 감지하는 것이었습니다.

예를 들어:

GET /api/orders/standard-1002
→ 404

와 같은 404 응답은 5xx 인시던트 워크플로우를 트리거해서는 안 됩니다.

이러한 구분은 단순히 모든 실패 요청에 대해 알림을 보내는 것보다 경고 조건(alert conditions) 자체를 생각하도록 강제했기 때문에 유용했습니다.

또한, 이 알림은 워크플로우의 다음 단계를 위해 충분한 정보를 제공해야 했습니다.

자동화된 인시던트 대응 (Automated Incident Response)

다음 단계는 전용 인시던트 대응 서비스(incident-response service)를 추가하는 것이었습니다.

이 서비스는 다음과 같은 엔드포인트를 노출합니다:

POST /alerts

Grafana가 알림을 보내면, 응답기(responder)는 인시던트 정보를 저장하고 유용한 증거를 수집합니다.

아이디어는 다음을 변환하는 것입니다:

Grafana Alert

다음과 같은 구조의:

Incident
├── endpoint
├── status
...

이것은 관측 가능성(observability)과 자동화된 복구(automated remediation) 사이에 다리 역할을 합니다.

AI 코딩 에이전트 연결 (Connecting an AI Coding Agent)

이번 연습에서 가장 흥미로웠던 부분은 인시던트 워크플로우를 코딩 에이전트(coding agent)에 연결하는 것이었습니다.

단순히 개발자에게 알리는 대신:

🚨 500 error detected

시스템은 코딩 에이전트에게 인시던트에 대한 컨텍스트를 제공할 수 있습니다.

의도된 워크플로우는 다음과 같습니다:

5xx detected
     ↓
Grafana alert
...

이는 AI의 역할을 단순히 코드를 생성하는 것에서 운영 워크플로우에 참여하는 것으로 변화시킵니다.

버그 찾기 (Finding the Bug)

마지막 연습에서는 Express 주문 조회(order lookup)에 의도적으로 버그를 노출했습니다.

문제의 구현은 다음과 같이 추정 배송 날짜를 계산했습니다:

estimated_at = placed_at.replace(day=placed_at.day + 2)

이는 언뜻 보기에는 합리적으로 보입니다.

하지만, 이 코드는 결과적인 날짜가 같은 월에 존재한다고 가정합니다.

월 말 근처에 생성된 주문의 경우, 이러한 가정이 실패할 수 있습니다.

수정 사항은 대신 날짜 산술(date arithmetic)을 사용하는 것이었습니다:

estimated_at = placed_at + timedelta(days=2)

이것은 Python의 datetime 구현이 월 경계를 올바르게 처리하도록 허용합니다.

중요한 부분은 단순히 코드 라인을 찾는 것만이 아니었습니다. 관측 가능성 및 인시던트 대응 워크플로우가 다음 경로를 제공했습니다:

HTTP failure
    ↓
Telemetry
...

제가 배운 점 (What I Learned)

1. 관측 가능성은 로깅 그 이상입니다

이 프로젝트를 진행하기 전에는 관측 가능성(observability)을 다음과 같이 생각하는 것이 쉬웠습니다:

"로그 몇 개 추가하기."

하지만 이 프로젝트는 그러한 시각을 변화시켰습니다.

유용한 관측 가능 시스템은 여러 신호들을 결합하고, 이를 실행 가능한 형태로 만듭니다.

2. 알림에는 맥락이 필요합니다

다음과 같은 알림은:

뭔가 잘못되었습니다

별로 유용하지 않습니다.

실행 가능한 인시던트(incident)는 조사를 시작할 수 있을 만큼 충분한 맥락을 제공해야 합니다.

예를 들어:

엔드포인트 (Endpoint)
HTTP 상태 코드 (HTTP status)
로그 (Logs)
...

3. 자동화는 검증과 연결되어야 합니다

코드를 자동으로 변경하는 것만으로는 충분하지 않습니다.

복구(remediation) 워크플로우는 또한 변경 후 애플리케이션이 제대로 작동하는지 검증해야 합니다.

그렇게 되면 워크플로우가 단순히:

감지 → 복구

라기보다는:

감지(Detect) → 조사(Investigate) → 수정(Fix) → 검증(Verify)

에 더 가까워집니다.

4. AI 에이전트는 운영 맥락이 필요합니다

코딩 에이전트가 단순히 눈을 가리고 조사하라는 요청을 받는 것보다, 시스템으로부터 증거를 받을 때 훨씬 유용해집니다.

텔레메트리(Telemetry)는 에이전트가 실제로 무슨 일이 일어났는지 이해하는 데 필요한 맥락을 제공할 수 있습니다.

기술 스택 (Technology Stack)

이 프로젝트는 여러 도구들을 결합했습니다:

검증 (Verification)

완성된 워크플로우는 숙제 과제를 통해 검증되었습니다.

중요한 결과는 단순히 각 개별 구성 요소가 작동했다는 사실만이 아니었습니다.

완전한 워크플로우가 하나의 사슬처럼 작동했다는 것이 중요했습니다.

최종 요약 (Final Takeaway)

이 프로젝트를 통해 얻은 가장 큰 교훈은 관측 가능성이 행동과 연결될 때 훨씬 더 가치로워진다는 것입니다.

성숙한 워크플로우는 다음과 같은 모습을 보일 수 있습니다:

애플리케이션 (Application)
     ↓
텔레메트리 (Telemetry)
...

이 프로젝트를 통해 저는 이 조각들을 개별 기술로 배우는 것이 아니라, 서로 연결하는 실질적인 경험을 할 수 있었습니다.

저에게 있어 이것이 바로 **공개 학습(Learning in Public)**의 진정한 가치입니다. 제가 무엇을 만들었는지뿐만 아니라, 어떤 문제에 직면했는지, 발견한 근본 원인은 무엇인지, 그리고 그 과정에서 저의 이해가 어떻게 바뀌었는지를 기록하는 것입니다.

감사의 말 (Acknowledgments)

이 프로젝트는 **DataTalksClub AI Dev Tools Zoomcamp — 숙제 4: AI 기반 앱을 위한 DevOps 및 관측 가능성(DevOps and Observability for AI-Built Apps)**의 일환으로 완료되었습니다.

소프트웨어 개발, DevOps, 관측 가능성(observability), 그리고 AI 지원 엔지니어링을 연결하는 실용적인 연습 문제를 만들어준 DataTalksClub 커뮤니티에 감사드립니다.

Github: order-tracker-v2