문화 문제가 아니었다: Airbnb의 alert 개발 고도화

**Observability as Code(OaC)**는 대규모 조직에서 기본 전제지만, alert의 실제 동작은 보통 배포 후에야 확인할 수 있었다. 그 결과 노이즈가 심한 alert에 익숙해지거나, 반대로 중요한 신호를 놓치는 문제가 반복됐다. Airbnb는 이를 문화 문제가 아니라 개발 워크플로 문제로 보고, PR 제출 전에 alert 동작을 미리 보고 검증할 수 있는 피드백 루프를 만들었다.

Airbnb의 목표는 플랫폼 팀이 Kubernetes, 서비스 프레임워크, 데이터베이스 같은 구성요소를 도입할 때 zero touch로 검증된 monitoring을 함께 제공하는 것이다. 이 체계는 10년 전 Interferon으로 시작해 1,000개 alert에서 현재 300,000개 alert 규모로 커졌지만, 규모가 커질수록 변경 검증 비용도 급격히 증가했다. 기존 코드 리뷰와 unit test만으로는 “실제 production에서 어떻게 동작할지”, “어떤 noise를 만들지”를 판단할 수 없었고, 개발자들은 side-by-side 배포와 장기 관찰에 의존할 수밖에 없었다.

문제 해결의 핵심은 alert behavior를 가시화하는 것이었다. Airbnb는 Prometheus를 기반으로 local-first workflow를 만들고, 다음 세 단계를 순차적으로 도입했다.

• 1단계: markdown diff를 CLI와 CI에서 보여줘 alert 변경을 텍스트 단위로 즉시 확인
• 2단계: Change Report UI로 production에 반영될 변경 내용을 시각적으로 비교
• 3단계: bulk backtesting으로 역사적 데이터에 alert를 돌려 실제 firing 시점과 원인을 확인

특히 backtesting은 Prometheus의 rule manager에 직접 연결해, proposed alert가 과거 데이터에서 언제, 왜 firing됐는지 보여준다. 변경 목록 전체에 대해 수백~수천 개 alert를 한 번에 backtest하고, noisiness 같은 품질 신호를 함께 노출해 리뷰 우선순위를 정하게 했다. 변경이 많은 경우에는 table view에서 noisiness 기준으로 정렬해 문제 가능성이 큰 alert부터 보게 만든다.

Airbnb는 이 시스템을 만들 때 몇 가지 원칙을 지켰다. 호환성(compatibility) 우선으로 Prometheus의 표준 rule group과 query API를 그대로 활용했고, 각 backtest는 별도 Kubernetes pod에서 돌아가도록 해 자원 경합을 막았다. 또한 guardrails를 강하게 둬서, backtesting 시스템 자체가 production을 흔드는 일이 없도록 했다. recording rule dependency는 완전 자동화하지 못했지만, UI에서 의존성을 감지해 사용자가 먼저 수정하도록 유도하며 80% 해결책을 먼저 shipped했다.

결과는 명확했다. alert 변경은 더 이상 “배포 후 며칠 기다려 보기”가 아니라 단일 PR 안에서 검증 가능한 작업이 됐다. 그 덕분에 Airbnb는 300,000개 alert를 vendor에서 Prometheus로 이전할 수 있었고, 개발 주기는 weeks에서 minutes로 줄었다. 회사 전체의 alert noise는 90% 감소했고, noisy alert를 견디는 문화 대신 alert 품질을 적극적으로 개선하는 문화가 자리잡았다.