메타가 장애 조사 판단을 AI에 맡기지 않는 이유

하루 5만 건 장애 조사, 핵심은 사람이 짠 코드였어요

2026년의 장애 대응 도구 시장은 이런 문장들로 가득해요. “MTTR¹ 최대 70% 단축.” “알람이 뜨면 수십 초 만에 근본 원인을 짚어드립니다.” “잠들지 않고, 맥락을 놓치지 않는 시니어 엔지니어 한 명을 채용하는 것과 같습니다.”

그런데 이 약속을 5년째 실제로 검증해온 회사가 있어요. 메타예요. 300개가 넘는 팀이 쓰고, 하루 5만 건의 장애 조사를 자동으로 돌리고 있어요. 지난해 12월 그 시스템의 논문을 공개했고요.

논문이 보고한 평균 성과는 MTTR 20% 단축이었어요. 그리고 이 시스템을 실제로 움직이는 것은 AI 에이전트가 아니라, 엔지니어들이 직접 작성한 조사 절차 코드예요.

성과를 가로막은 것은 모델 성능이 아니었어요. 조직의 조사 지식이 아직 코드로 옮겨지지 않았다는 점이 걸림돌이었어요.

---

🌙 하루 5만 번 돌아가는 조사 절차를, 전부 사람이 코드로 썼어요

메타가 공개한 시스템의 이름은 DrP예요. 하는 일은 단순해요. 알람이 울리면 미리 짜둔 조사 절차를 자동으로 실행하고, 결과를 알람 페이지에 붙여줘요. 새벽 3시에 깬 온콜² 엔지니어가 대시보드 다섯 개를 띄우고 로그를 뒤지는 대신, 이미 페이지에 올라와 있는 분석 결과를 읽는 것으로 조사를 시작해요.

이 ‘미리 짜둔 조사 절차’를 메타는 분석기(analyzer)라고 불러요. 분석기는 사람이 파이썬이나 PHP로 직접 짠 코드예요. 조건 분기와 데이터 조회가 줄줄이 이어져 있어서, 장애가 났을 때 무엇을 어떤 순서로 확인할지 미리 적어둔 절차서 역할을 해요.

규모를 볼까요. 분석기 2,000개 이상, 쓰는 팀 300개 이상, 운영 기간 5년, 하루 자동 분석 5만 건. 30일로 환산하면 150만 건이고, 평균 1.7초마다 분석기 하나가 실행되는 셈이에요.

이 분석기들이 대체한 건 세 가지예요. 아무도 업데이트하지 않는 위키 문서, 각자 노트북에 흩어져 있는 개인 스크립트, 그리고 시니어 엔지니어의 머릿속에만 있는 암묵지³. 논문의 표현을 그대로 옮기면, 이들의 접근법은 조직에 퍼져 있는 수동 플레이북과 암묵지를 코드로 옮기는 것이었어요.

효과는 조사가 복잡할수록 커졌어요. 논문이 세 가지 시나리오(단순한 서비스 오류, 컨테이너 장애, AI 모델의 피처 문제)를 놓고 수동 방식과 비교했더니, 온콜 엔지니어가 밟아야 하는 단계 수가 4배에서 20배까지 줄었어요. 가장 복잡한 시나리오에서 엔지니어가 해야 할 일은 딱 하나로 압축됐고요. 알람 페이지에서 결과를 읽는 것.

---