인시던트 조사를 구조화하는 옵저버빌리티 플랫폼 설계
프로덕션 인시던트가 발생했을 때 가장 큰 비용은 "무엇이 문제인가"를 파악하는 시간이다. 로그, 메트릭, 트레이스가 분산된 상태에서 엔지니어는 수십 개의 대시보드를 뒤지며 원인을 추론해야 한다. Expedia Group은 이 과정을 구조화하기 위해 **STAR(Service Telemetry Analyzer)**라는 내부 옵저버빌리티 플랫폼을 구축했다.
STAR는 FastAPI를 HTTP 레이어로, Celery와 Redis를 비동기 워크플로우 큐로 활용한다. 인시던트가 감지되면 Datadog으로부터 관련 텔레메트리 데이터를 수집하고, 정해진 워크플로우 단계에 따라 서비스 상태를 분석해 Root Cause Assessment(RCA) 보고서를 자동으로 생성한다. Langfuse는 분석 파이프라인의 실행 흐름을 추적하고 품질을 모니터링하는 역할을 담당한다.
Human-in-the-Loop 구조가 실무에서 중요한 이유
STAR 설계에서 주목할 점은 자동화 수준을 "완전 자율"이 아닌 의사결정 지원 수준으로 의도적으로 제한했다는 것이다. 엔지니어는 자동 생성된 RCA를 검토하고 최종 판단을 내리는 역할을 유지한다. 이는 단순히 안전장치를 두는 것이 아니라, 오탐(false positive) 또는 분석 맹점이 있을 때 실제 운영 결정에 오류가 전파되는 위험을 방지하는 아키텍처 철학이다.
4년차 이상 백엔드 개발자라면 이 구조에서 중요한 설계 원칙을 읽어야 한다. 자동화 파이프라인이 실패하거나 잘못된 신호를 보낼 때, 시스템이 조용히 오답을 내리지 않도록 사람이 확인하는 게이트를 어느 지점에 두는가가 신뢰도 있는 내부 도구의 핵심이다.
기술 스택 선택과 설계 시사점
[Incident Trigger]
→ FastAPI (API Layer)
→ Celery + Redis (Async Workflow Queue)
→ Datadog (Telemetry Source)
→ Analysis Pipeline
→ RCA Report (Engineer Review)
→ Langfuse (Pipeline Observability)
각 컴포넌트의 역할 분리가 명확하다. FastAPI는 외부 요청을 받는 엔트리포인트로만 두고, 실제 분석처럼 시간이 걸리는 작업은 Celery로 위임해 응답 지연을 방지한다. Redis는 Celery의 브로커이자 결과 백엔드로 활용되며, 이 조합은 Java 생태계의 Spring + @Async + 메시지 큐 구조와 유사한 관심사 분리 패턴이다.
Langfuse를 파이프라인 관찰 계층으로 별도로 둔 점도 실무적으로 참고할 만하다. 분석 워크플로우 자체도 "관찰 대상"으로 취급해 각 단계의 입출력과 실행 시간을 추적한다. 이는 일반적인 APM 도구가 커버하지 못하는 워크플로우 단위 가시성을 확보하는 방법이다.
정리
- 인시던트 대응 자동화는 "완전 자동화"보다 사람이 검토하는 구조적 워크플로우로 설계하는 것이 신뢰성 측면에서 더 안전하다.
- Celery + Redis 조합으로 분석 작업을 비동기화해 API 응답성과 처리 파이프라인을 분리하는 패턴은 Java 백엔드 설계에도 직접 적용 가능하다.
- 자동화 파이프라인 자체에 별도 관찰 계층(Langfuse 등)을 두어 워크플로우 품질을 지속 모니터링하는 것이 운영 성숙도의 핵심이다.