벤더에서 선봉으로: Airbnb가 관찰 가능성 주도권을 쥐기까지의 교훈

Airbnb는 외부 벤더에 맡겼던 observability를 Prometheus 기반의 인하우스 플랫폼으로 옮기며, 메트릭 수집·저장·질의·시각화 전 과정을 직접 소유하게 됐다. 이 전환은 단순한 시스템 교체가 아니라, 데이터와 사용자 경험에 대한 통제권을 되찾는 작업이었다.

이 마이그레이션은 1,000개 서비스, 3억 개 timeseries, 3,100개 dashboard, 30만 개 alert를 옮겨야 하는 대규모 작업이었다. 처음에는 가장 복잡한 서비스를 먼저 옮기는 방식이 자연스러워 보였지만, 실제로는 첫 고객에게 과도한 불확실성과 교육 부담을 떠안기 쉬운 전략이었다.

대신 성공한 접근은 더 단순하고 실행 가능한 목표부터 시작하는 것이었다. 새 저장 엔진이 감당할 수 있는지 검증하고, dashboard와 alert를 옮기는 translator를 만들고, 문서화·교육을 강화하며, 새로운 visualization tool에 소수 사용자부터 적응시키는 방식이 효과적이었다.

핵심 전환점은 쿼리의 의도(intent) 를 옮기는 데 있었다. 단순히 기존 쿼리를 1:1로 번역하는 대신, 예를 들어 p95 같은 계산이 있으면 중간의 잘못된 집계를 무시하고 표준화된 histogram query 로 재작성했다. 이를 위해 metric 이름만으로 타입을 추론할 수 없어서, 번역 계층 안에 메타데이터 엔진을 넣고 내부 라벨인 otel_metric_type 을 기반으로 metric type 매핑을 유지했다.

사용자 경험 측면에서는 PromQL 을 채택해 기존보다 널리 알려진 쿼리 언어와 생태계를 활용했다. 여기에 AI 도구용 in-house skill을 붙여 metric의 타입, 단위 같은 의미 정보를 제공했고, 덕분에 에이전트가 더 정확한 PromQL을 생성해 incident 디버깅과 dashboard 작성에 드는 시간을 크게 줄였다.

마지막으로, 기존 alert framework도 그대로 두지 않았다. alert를 설정 파일이 아니라 개발 workflow로 다루는 새 authoring 경험을 도입해 autocomplete, builder-style 도움말, backtesting, diffing을 제공했고, 이 변화는 migration의 가치를 비용 절감 이상의 것으로 끌어올렸다. 결론적으로 이 프로젝트는 저장소를 바꾸는 일이 아니라, 관찰 가능성의 소유권과 개발자 경험 자체를 다시 설계한 작업 이었다.