AI·테크제185호

메타는 왜 장애를 AI에 안 맡길까

AI에 일을 맡기려면, 그 일이 먼저 코드여야 해요

안광섭 (오스왈드)· 오즈의 지식토킹 글쓴이·편집자

메타는 왜 장애를 AI에 안 맡길까

들어가며

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

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

논문이 보고한 평균 성과는 20%였어요. 그리고 더 이상한 건, 그 시스템의 심장이 AI 에이전트가 아니라는 거예요.

결론부터 말씀드릴게요. 병목은 모델이 아니었어요. 조직의 지식이 아직 코드가 아니라는 것, 그게 병목이었어요.

🌙 하루 5만 번 돌아가는 각본을, 전부 사람이 썼어요

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

이 ‘미리 짜둔 조사 절차’를 메타는 분석기(analyzer)라고 불러요. 그리고 여기가 오늘의 출발점이에요. 분석기는 사람이 파이썬이나 PHP로 직접 짠 코드예요. 조건 분기와 데이터 조회가 줄줄이 이어진, 말하자면 장애 조사의 각본이에요.

규모를 볼까요. 분석기 2,000개 이상, 쓰는 팀 300개 이상, 운영 기간 5년, 하루 자동 분석 5만 건. 30일로 환산하면 150만 건이고, 초 단위로 풀면 1.7초에 한 번씩 어딘가에서 각본 하나가 돌아가고 있는 셈이에요.

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

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

⚠️ 논문 9장에 박혀 있는 소제목 하나

여기까지는 익숙한 자동화 성공담이에요. 그런데 논문 9장 ‘배운 것들’로 넘어가면 이런 소제목이 나와요.

“진단을 AI 기반 시스템에 과도하게 기대지 마세요.” (Do not over-index on AI based systems for diagnosis)

지구상에서 손꼽히는 규모의 AI 인프라를 굴리는 회사가, 자기 장애 조사 논문에 이걸 교훈으로 적었어요.

오해는 미리 걷어낼게요. 메타가 AI를 안 쓴다는 뜻이 아니에요. DrP의 SDK 안에는 이상 탐지, 시계열 상관 분석, 차원 분석 같은 통계·머신러닝 라이브러리가 다 들어 있어요. 코드와 설정 변경 이벤트 수천 개를 훑어서 “이게 범인일 확률이 높습니다”라고 순위를 매기는 랭킹 모델도 돌아가고요.

메타가 AI에 맡기지 않는 건 판단의 뼈대예요. 무엇을 어떤 순서로 볼 것인가, 이 조건이면 어디로 갈 것인가. 그 결정 트리는 사람이 씁니다. AI는 그 안에서 한 칸을 채우는 도구로 쓰여요.

이유도 논문에 적혀 있어요. 순수 머신러닝 시스템의 한계는 학습 데이터의 품질, 조사 시점에 실제로 접근 가능한 데이터의 구조, 그리고 팀마다 워크플로를 손보기 어렵다는 것. 그래서 그들이 도달한 결론은 커뮤니티의 전문성에 기반한 룰 기반 제안에 AI를 덧붙이는 조합이었어요.

그런데 저를 더 붙잡은 건 그 옆에 있는 다른 교훈이에요. 제목이 ‘조력이냐 완전 자동화냐’예요.

메타의 원래 목표는 완전 자동화였어요. 그런데 방향을 틀었습니다. 이유는 셋이었어요. 첫째, 시스템이 계속 바뀌니까 각본이 금방 낡아요. 둘째, 통계와 머신러닝은 오탐과 미탐을 냅니다. 그리고 셋째, 문화적으로 엔지니어와 온콜 담당자가 완전 자동화된 시스템을 늘 신뢰하지는 않는다는 것이었어요.

앞의 둘은 기술 문제예요. 세 번째는 아니에요. 5년, 300개 팀, 하루 5만 건을 굴리고 나서 메타가 만난 벽은 정확도가 아니라 신뢰였어요.

논문에 실린 자체 설문이 이걸 뒷받침해요. “DrP가 얼마나 자주 MTTR을 줄여주나요?”라는 질문에 ‘항상’이라고 답한 사람은 5.9%였어요. 가장 많은 답은 ‘가끔’(47.1%)이었고요. 논문은 이걸 “80% 이상이 개선을 보고했다”고 요약했는데, 틀린 말은 아니지만 응답의 무게중심은 분명히 ‘가끔’ 쪽에 있어요. 참고로 백분율을 역산해보니 응답자는 17명 규모예요. 300개 팀이 쓰는 시스템의 설문치고는 표본이 아주 작으니, 이 숫자는 참고 수준으로만 보시는 게 맞아요.

📉 20%와 80% 사이에 있는 것

이제 숫자를 볼 차례인데, 그 전에 짚고 넘어가야 할 게 있어요.

메타의 엔지니어링 블로그는 성과를 이렇게 적었어요. “MTTR을 20~80% 줄였다.” 범위처럼 읽히죠. 보통 40~50%쯤 나오나 보다, 하고 넘어가기 쉬워요.

그런데 논문 초록은 다르게 씁니다. 평균 20%. 일부 팀에서만 80% 이상. 같은 숫자인데 뜻이 완전히 달라요.

논문 7장을 열어보면 이유가 나와요.

  • 분석기 5개 미만 → 10~15%
  • 10개 이상 → 50~80%
  • 전사 평균 → 20%

즉 80%는 시스템의 성능이 아니라 투자량의 함수였어요. 자기 팀의 조사 절차를 코드로 얼마나 많이 옮겼느냐가 성과를 갈랐어요.

논문 7.2.4절의 팀별 표를 보면 더 선명해져요.

  • 1팀: 분석기 136개, 개선율 82%
  • 2팀: 92개, 75%
  • 3팀: 66개, 84%
  • 4팀: 48개, 69%
  • 5팀: 39개, 58%
  • 6팀: 29개, 73%
  • 7팀: 23개, 56%
  • 8팀: 12개, 7%

마지막 행을 보세요. 8팀은 분석기를 12개 만들었어요. 논문이 스스로 정한 ‘10개 이상’ 기준을 넘겼는데, 개선율은 7%에 그쳤어요. 논문의 주장이 논문 자신의 표에서 반증되는 셈이에요. 진짜 절벽은 12개와 23개 사이 어딘가에 있어요.

여기서 제가 직접 계산해본 게 있어요. 분석기 2,000개를 300개 팀으로 나누면 팀당 평균 6~7개예요. 그리고 논문 스스로 5개 미만이면 10~15%라고 했죠. 무슨 뜻일까요. 메타 안에서도 중앙값에 있는 팀은 아직 저수익 구간에 있어요. 전사 평균이 20%에서 멈춘 이유가 여기 있습니다.

시간도 만만치 않아요. 논문에 따르면 단순한 분석기는 하루면 만들 수 있지만, 한 팀의 조사 워크플로를 온전히 담아내려면 몇 달이 걸려요. 도구를 사는 데 걸리는 시간이 아니라, 지식을 옮기는 데 걸리는 시간이에요.

마지막으로 MTTR의 절대값도 짚어둘게요. 1팀은 771시간에서 139시간으로 줄었어요. 32일이 5.8일이 된 거예요. 이건 서비스가 멈춰 있던 시간이 아니라, 사후 리뷰까지 거친 인시던트의 탐지부터 해결까지 전체 사이클이에요. “MTTR 20% 단축”이 작아 보인다면, 기준선이 얼마나 큰지를 함께 보셔야 해요.

한 가지 덧붙이면, 이 표의 7팀 행은 전후 값으로 다시 계산하면 36%가 나오는데 논문에는 56.1%로 적혀 있어요. 나머지 일곱 개 행은 소수점까지 맞아떨어지니 오탈자일 가능성이 높아요. 다만 남의 표를 그대로 옮겨 쓰기 전에 계산기를 한 번 두드려볼 이유는 되죠.

🔁 그래서 왜 지금 ‘AI 네이티브’인가

메타 블로그의 마지막 문단은 이렇게 끝나요. 앞으로 DrP를 AI 네이티브 플랫폼으로 진화시키겠다고요.

이상하지 않나요? “AI에 과도하게 기대지 말라”고 써놓고, 바로 다음 문단에서 AI 네이티브로 가겠다고 해요.

모순이 아니에요. 순서예요.

지난 5년간 메타가 실제로 한 일을 다시 볼게요. 위키 문서와 개인 스크립트와 시니어의 기억 속에 흩어져 있던 조사 지식을 이렇게 바꿔놨어요.

  • 타입이 정의된 코드로 (조사 절차가 분기와 조건으로 명시됨)
  • 구조화된 출력으로 (결과가 기계가 읽을 수 있는 형식으로 나옴)
  • 실행 이력이 남는 데이터로 (과거 30일치 조사 입출력을 보관)

특히 세 번째가 결정적이에요. 메타는 분석기를 수정할 때마다 과거 조사 기록을 다시 흘려보내 검증하는 백테스팅4 체계를 만들었어요. 원래 목적은 버그를 잡는 거였죠. 그런데 결과적으로 장애 조사 과정 자체가 정답이 붙은 데이터셋이 됐어요.

여기서 질문을 뒤집어볼게요. AI 에이전트가 장애를 조사하려면 무엇이 필요할까요.

첫째, 손. 데이터에 접근하는 도구가 필요해요. 둘째, 절차. 무엇을 어떤 순서로 볼지에 대한 지도가 필요해요. 셋째, 정답지. 과거에 어떤 판단이 맞았는지에 대한 기록이 필요하고요. DrP가 5년 동안 만든 게 정확히 이 셋이에요.

논문에는 또 하나의 교훈이 있어요. 제목이 ‘데이터가 전부다’예요. 관측 데이터의 품질, 그리고 서비스 의존성이나 데이터 계보 같은 구조화된 메타데이터. 이게 없으면 상관 분석 자체가 안 돼요. 아무리 좋은 모델을 붙여도 붙일 데가 없어요.

그래서 오늘의 제목에 대한 답은 이렇게 됩니다. 메타는 AI를 못 믿어서 안 맡긴 게 아니에요. 아직 순서가 안 됐던 거예요. 그리고 이제 순서가 됐다고 판단한 거고요.

AI가 대신 일하려면, 그 일이 먼저 코드가 되어야 해요. 모델이 아무리 좋아져도, 조직의 지식이 위키 문서와 누군가의 기억 속에 있으면 AI는 붙을 곳이 없어요.

🇰🇷 그럼 우리는 어디쯤 있을까요

지난 6월 24일 서울에서 열린 한 컨퍼런스에서, 삼성전자 MX사업부 클라우드팀이 자사 로드맵을 공개했어요. 삼성페이, 빅스비, 갤럭시 스토어를 포함해 50개가 넘는 대고객 서비스의 안정성을 책임지는 중앙 SRE5 조직이에요.

이들이 제시한 성숙도 단계는 넷이었어요. 사후 대응, 자동 대응, 예측 운영, 자율 운영. 그리고 스스로 진단한 현재 위치는 첫 번째 단계였어요. 자율 운영 목표 시점은 2028년이고요. 국내 최상위권 SRE 조직의 자기 평가가 이렇다는 건, 나머지 조직들의 좌표도 짐작하게 해줘요.

주목할 지점은 유현성 그룹장이 발표를 마무리한 문장이에요. 자동화 범위를 넓혀도 최종 책임과 판단은 사람의 몫이라는 것. 메타 논문의 ‘조력이냐 완전 자동화냐’와 정확히 같은 결론이에요.

같은 행사에서 변우철 KT 팔란티어사업본부장은 더 직접적으로 말했어요. 경영진의 조급함 때문에 근본 문제를 건드리지 않은 채 AI부터 붙이고, 그래서 성과가 안 나온다고요. 그가 짚은 해법은 데이터를 AI가 읽어낼 수 있는 구조로 정리하는 것이었어요. 메타 논문의 ‘데이터가 전부다’와 같은 말이죠.

실제로 굴러가는 국내 사례도 있어요. 야놀자는 지난 4월, 6개 팀 14명이 6주 동안 운영 에이전트 여섯 개를 만들었다고 공개했어요. 그중 장애 대응 에이전트는 장애 발생부터 사후 리포트까지 걸리던 2주를 24시간으로 줄였고요. 다만 구조를 뜯어보면 여기서도 에이전트는 사내 지식 베이스와 문서를 검색하는 기반 위에서 움직여요. 순서는 같아요.

오스왈드의 시선

논문 9장의 교훈 여섯 개를 다시 세어봤어요. 그중 모델 성능에 관한 건 한 줄도 없어요. 전부 채택에 관한 얘기였어요.

커뮤니티가 직접 만들게 할 것. 사용자가 있는 곳으로 갈 것. 이미 쓰고 있는 워크플로 안에 심을 것. 특히 이 문장이 눈에 걸렸어요. 분석기 개발은 대부분의 소프트웨어 엔지니어에게 본업이 아니라는 것. 그래서 메타는 하루 만에 하나를 만들 수 있게 SDK를 다듬었고, 코드 에디터 안에서 결과를 바로 볼 수 있게 만들었어요.

20년 넘게 GTM 전략을 세우면서 반복해서 본 패턴이 있어요. 조직이 새 도구를 검토할 때 던지는 첫 질문은 늘 “얼마나 정확한가”예요. 그런데 실제로 채택률을 결정하는 건 거의 언제나 “얼마나 귀찮은가”예요. 정확도 95%짜리 도구를 쓰려고 창을 세 개 더 띄워야 한다면, 그 도구는 안 쓰여요. 정확도 70%여도 이미 보고 있는 화면에 결과가 떠 있으면, 그건 쓰여요. 메타가 결과를 알람 페이지 안으로 밀어 넣은 건 기술적 선택이 아니라 GTM 선택이었어요.

그래서 저는 지금 많은 조직이 질문을 잘못 잡고 있다고 봐요. “어떤 AI 에이전트를 도입할까”가 아니에요. 먼저 물어야 할 건 이거예요. 우리 팀이 매번 반복하는 판단 절차 중 몇 개가 코드로 존재하나. 그 숫자가 0에 가깝다면, 어떤 모델을 사와도 붙일 곳이 없어요.

마치며

메타가 5년간 하루 5만 건씩 돌린 장애 조사 시스템의 심장은 AI 에이전트가 아니라 사람이 손으로 짠 2,000개의 각본이에요. 성과를 가른 것도 모델이 아니라 각본을 몇 개나 썼느냐였고요. 지금 메타가 ‘AI 네이티브’를 말할 수 있는 것도, 5년 동안 암묵지를 기계가 읽는 형태로 옮겨뒀기 때문이에요.

더 파보고 싶으시다면 논문 9장 ‘Lessons Learned’만 펴보세요. 세 페이지에 5년치 시행착오가 다 들어 있어요.

구독자님 팀에서 매번 같은 순서로 반복하는 판단 절차를 하나 떠올려보세요. 그게 아직 위키나 누군가의 머릿속에만 있다면, 왜 아직 코드가 되지 못했을까요? 시간이 없어서인가요, 절차가 사람마다 달라서인가요? 가장 큰 걸림돌을 댓글로 들려주시면 다음 호 소재에 반영해볼게요.

💬 위 질문에 대한 경험을 댓글로 남겨주세요. 다음 호에 반영해볼게요. 📨 운영 자동화나 AI 도입을 고민 중인 동료가 있다면, 이 글을 전달해 주세요.

저는 매주 화·목·일에 기술과 경제, 인문을 교차해서 읽고 그 접점에서 발견한 것을 씁니다. 오늘처럼 논문 한 편을 끝까지 파고드는 날도 있어요.

참고자료 & 더 읽기

핵심 출처

  • Shubham Somani 외 13인, “DrP: Meta’s Efficient Investigations Platform at Scale”, arXiv:2512.04250 [cs.SE], 2025년 12월. : 7.2절(MTTR 평가)과 9절(배운 것들)이 오늘 글의 핵심 근거예요. 시간이 없으시면 9절 세 페이지만 읽으셔도 충분해요.
  • Meta Engineering, “DrP: Meta’s Root Cause Analysis Platform at Scale”, 2025년 12월 19일. : 논문의 공식 요약본이에요. 다만 MTTR을 “20~80%“로 압축 표기해 원문과 뉘앙스가 달라요. 숫자를 인용하실 거라면 논문 쪽을 보시길 권해요.

배경 지식

📝 용어 설명

안광섭 프로필 일러스트

필자 안광섭은 세종대학교 경영학과 교수이자 OBF(Oswarld Boutique Consulting Firm) 리드 컨설턴트이다. 대학에서 경영데이터 관리, 비즈니스 애널리틱스 등 통계 및 데이터 분석을 가르치는 한편, 현장에서는 GTM 전략과 인공지능 전략 컨설팅을 이끌며 기술과 비즈니스의 접점을 설계하고 있다. AI 대화 시스템의 기억 아키텍처(HEMA) 연구로 학술 논문을 발표했으며, 매일 글로벌 AI 논문을 큐레이션하는 Daily Arxiv 프로젝트를 운영하고 있다. 고려대학교 기술경영전문대 석사과정와 KMBA을 졸업했다. 지은 책으로 《생각을 맡기는 사람들: 호모 브레인리스》가 있다.

각주

  1. MTTR(Mean Time To Resolution): 장애를 발견한 시각부터 해결된 시각까지의 평균 시간이에요. 메타 논문은 사후 리뷰를 거친 인시던트만 대상으로 계산했기 때문에, 서비스가 멈춰 있던 시간이 아니라 원인 규명과 조치까지 포함한 전체 사이클로 보셔야 해요. ↩

  2. 온콜(On-call): 장애가 나면 즉시 대응하도록 순번을 정해두는 당번 제도예요. 새벽 3시에 알람이 울리면 일어나야 하는 그 사람이 그날의 온콜이에요. ↩

  3. 암묵지(Tribal Knowledge): 문서로 남아 있지 않고 조직 안에서 사람을 통해 전해지는 지식이에요. “그 서버는 이럴 때 저기부터 봐야 해” 같은 것들이죠. ↩

  4. 백테스팅(Backtesting): 과거 데이터를 다시 흘려보내서 바뀐 코드가 예전과 같은 결과를 내는지 검증하는 방식이에요. 메타는 최근 30일치 조사 기록을 보관해두고, 분석기를 고칠 때마다 자동으로 돌려요. ↩

  5. SRE(Site Reliability Engineering): 서비스의 안정성을 소프트웨어 엔지니어링 방식으로 관리하는 직무이자 조직이에요. 2003년 구글에서 시작됐고, 온콜과 장애 대응이 핵심 업무 중 하나예요. ↩

SEND A COFFEE

이 관점이 좋았다면, 다음 글에 커피 한 잔

오스왈드에게 커피와 함께 짧은 쪽지를 보내주세요. 응원은 다음 취재와 집필에 보탭니다.

FOR OSWARLD

커피와 쪽지 보내기

“메타는 왜 장애를 AI에 안 맡길까”을 읽고 떠오른 말을 남겨주세요. 메뉴 이름만큼의 응원금과 함께 전달됩니다.

어떤 커피로 보낼까요?

여러분의 생각이 다음 호를 만듭니다

이번 호에서 가장 공감했거나, 다른 경험을 한 지점은 무엇인가요?

댓글은 무료 회원이면 누구나 남길 수 있어요.

함께 읽으면 좋은 지난 호

제166호AI·테크

검증자가 병목이라는 말, 절반만 맞아요

이름은 문제에 이름표만 붙여요. 검증자를 만드는 건 그대로 당신 숙제예요

제161호AI·테크

20와트짜리 뇌를 꺼두는 사람들

기계가 뇌를 이긴 게 아니에요. 우리가 뇌를 반납하고 있는 거죠.

제160호AI·테크

클로드는 시험인 걸 알고 있었다

겉의 답과 속의 생각이 다를 때, 무엇을 봐야 할까요