새벽 3시에 온콜 알림이 울립니다. 결제가 안 된다는 겁니다. 로그를 뒤지고, 롤백하고, 20분 만에 서비스를 복구합니다. 안도의 한숨을 쉬고 다시 잠듭니다. 그리고 2주 뒤, 거의 똑같은 장애가 또 터집니다. (이 장면이 익숙하시다면, 문제는 대응 속도가 아닙니다.) 결론부터 말씀드리겠습니다. 장애 대응의 진짜 성과는 서비스를 얼마나 빨리 복구했는가가 아니라, 같은 장애가 다시 오지 않도록 팀이 무엇을 배웠는가입니다. 복구는 절반입니다. 나머지 절반은 복구 버튼을 누른 다음에 시작됩니다. 그런데 우리는 대개 그 버튼을 누르는 순간 장애가 끝났다고 착각합니다.
복구는 장애 대응의 절반이다
먼저 인정할 게 하나 있습니다. 장애는 막을 수 없습니다. 규모가 어느 선을 넘은 시스템에서 장애는 예외가 아니라 상수입니다. 그러니 목표를 “장애 제로”로 잡는 순간 이미 진 게임을 하는 겁니다. 현실적인 목표는 두 가지입니다. 얼마나 빨리 복구하는가, 그리고 같은 장애를 얼마나 확실히 막는가.
앞의 절반, 복구 속도는 이미 업계 표준 지표가 있습니다. DORA의 2024년 보고서는 배포 실패 복구 시간(과거의 MTTR)을 소프트웨어 전달 성과의 안정성 축으로 봅니다. 숫자는 냉정합니다.
| 구분 | 복구 시간 | 변경 실패율 |
|---|---|---|
| 엘리트 팀 | 1시간 이내 | 약 5% |
| 저성과 팀 | 1주 이상 | 약 40% |
몇 년 전 실시간 송금 서비스를 운영하던 시절, 저는 이 앞의 절반에만 매달렸습니다. 국내 정산 기관과 여러 해외 파트너사를 연동하는 구조라 장애가 잦았고, 장애가 날 때마다 불을 끄기 바빴습니다. 모니터링 체계와 원인 보고 체계를 세우고 나서야 복구 시간이 눈에 띄게 줄었습니다. 그런데 이상하게도 장애 자체는 줄지 않았습니다. 빨리 끄는 데는 능숙해졌는데, 같은 불이 계속 났습니다. 뒤의 절반, 즉 학습을 건너뛰고 있었기 때문입니다.
‘근본 원인’이라는 착각
장애 회고에서 가장 먼저 버려야 할 말은 “근본 원인이 뭐였죠?”입니다. 이 질문은 답이 하나 있다고 전제하지만, 복잡한 시스템은 그렇게 고장 나지 않습니다.
시스템 안전 연구자 리처드 쿡은 1998년 논문 「How Complex Systems Fail」에서 이렇게 정리합니다. 겉으로 드러난 장애가 일어나려면 여러 개의 결함이 필요하다. 각각의 결함은 그 자체로는 장애를 일으키기에 부족하다. 이들이 동시에 겹칠 때만 장애가 된다. 따라서 하나의 근본 원인을 분리해내는 것은 불가능하다(Cook, 1998). 쿡은 한 발 더 나아가, 근본 원인을 굳이 하나로 지목하려는 태도는 기술적 이해가 아니라 특정 대상을 탓하려는 사회적 필요에서 나온다고 지적합니다.
그 탓의 대상은 대개 사람입니다. 배포한 사람, 알림을 놓친 사람, 설정을 잘못 건드린 사람. 하지만 안전과학자 시드니 데커의 표현을 빌리면, 인적 오류는 원인이 아니라 더 깊은 곳에 있는 문제의 증상입니다. 그는 사후확신편향(hindsight bias)을 이렇게 경고합니다. 사후에 돌아보면 결함으로 보이지 않을 인간의 판단은 거의 없다(Dekker, 2014). 장애가 터진 뒤에 보면 “그때 왜 그걸 몰랐지”가 뻔해 보이지만, 그 사람은 사고 시점에 가진 정보로는 합리적으로 행동한 겁니다. 우리가 고쳐야 하는 것은 그 사람이 아니라, 그 시점에 잘못된 정보를 그럴듯해 보이게 만든 시스템입니다. 이건 방치된 기술 부채가 장애의 기여 요인으로 쌓이는 방식과 정확히 같습니다.
범인을 찾으면 학습이 멈춘다
비난이 왜 위험한지는 심리학이 명확하게 답합니다. 하버드의 에이미 에드먼슨은 병원 팀을 연구하면서, 성과가 좋은 팀일수록 오류를 더 적게 보고할 거라 예상했습니다. 결과는 정반대였습니다. 좋은 팀이 오류를 더 많이 보고했습니다(Edmondson, 1999). 오류를 더 많이 낸 게 아니라, 보고해도 안전하다고 느꼈기 때문입니다. 차이는 오류율이 아니라 검출율이었습니다.
장애도 똑같습니다. 회고가 범인 색출로 흘러가는 순간, 팀은 다음 장애를 숨기는 법을 배웁니다. 위험 신호를 늦게 공유하고, 실수를 축소하고, “제 잘못 아닙니다”를 준비합니다. 그렇게 조직은 학습 능력을 잃습니다. 이것이 구글 SRE 팀이 비난 없는 포스트모템(blameless postmortem)을 문화의 기본값으로 삼은 이유입니다. 그들의 원칙은 한 문장으로 요약됩니다. 사람은 고칠 수 없지만, 사람이 옳은 선택을 하도록 시스템은 고칠 수 있다(Google SRE). 회고는 처벌이 아니라 회사 전체를 위한 학습 기회라는 겁니다.
결국 관건은 어떤 질문을 던지느냐입니다. 같은 장애를 놓고도 질문을 바꾸면 회고의 방향이 바뀝니다.
| 비난을 부르는 질문 | 학습을 부르는 질문 |
|---|---|
| 누가 배포했나 | 어떤 조건에서 이 배포가 안전해 보였나 |
| 왜 못 막았나 | 어떤 신호가 있었고, 왜 늦게 도달했나 |
| 근본 원인이 뭔가 | 어떤 기여 요인들이 겹쳤나 |
| 다시는 안 그러겠다는 다짐 | 오너와 기한이 붙은 액션 아이템 |
이런 회고가 가능하려면 팀에 심리적 안전감이 먼저 깔려 있어야 합니다. 안전감 없는 블레임리스는 구호일 뿐입니다.
배우는 회고를 설계하는 법
비난 없는 회고는 마음가짐이 아니라 절차입니다. 실무에서 제가 쓰는 순서는 이렇습니다.
먼저 판단을 빼고 타임라인부터 적습니다. “누가 실수해서”가 아니라 “몇 시 몇 분에 무슨 일이 있었다”는 사실만. 그다음 근본 원인 한 줄 대신 기여 요인 여러 개를 나열합니다. 부족한 알림, 놓친 모니터링 지표, 애매한 롤백 절차, 몰려 있던 배포. 각각은 사소하지만 겹쳐서 장애가 된 것들입니다.
그리고 모든 질문을 사람이 아니라 시스템으로 돌립니다. “왜 그 시점에 그 정보로는 그 판단이 합리적이었나.” 마지막으로 액션 아이템에 반드시 오너와 기한을 붙입니다. 이게 없으면 회고는 잘 쓴 문서로 남았다가 조용히 죽습니다. 이 감각은 결함을 찾는 검사가 아니라 이해를 전달하는 대화라는 점에서 코드 리뷰의 본질과 닮았습니다.
여기에 하나를 더합니다. 감지 시간 자체를 줄이는 것. 아무리 좋은 회고도 장애를 늦게 아는 문제는 못 고칩니다. 예전에 한 팀에서 온콜 알림 체계를 다시 잡아 장애 인지 시간을 40% 가까이 줄인 적이 있습니다. 복구가 빨라진 게 아니라, 사람이 장애를 알아차리는 시점이 당겨진 겁니다. 그만큼 대응할 시간과 학습할 여유가 늘어납니다. 특히 AI가 만든 코드가 커밋의 상당 부분을 차지하는 지금, 사람이 미처 예상 못 한 실패 모드를 빨리 감지하는 능력은 더 중요해졌습니다.
결론
복구는 실력의 끝이 아니라 시작입니다. 불을 빨리 끄는 팀은 많지만, 같은 불이 다시 나지 않게 만드는 팀은 드뭅니다. 그 차이를 가르는 건 대응 매뉴얼의 두께가 아니라, 장애를 대하는 태도입니다. 근본 원인 하나를 지목하고 범인을 찾아 회고를 닫을 것인가, 아니면 여러 기여 요인을 드러내고 시스템을 고쳐 다음을 대비할 것인가.
다음 장애가 터지면 스스로에게 물어보시기 바랍니다. 우리는 이번에 무엇을 복구했고, 무엇을 배웠는가. 복구만 있고 학습이 없다면, 그 장애는 곧 다시 찾아옵니다.
참고 자료
- Richard I. Cook, 「How Complex Systems Fail」, 1998/2000
- Sidney Dekker, 『The Field Guide to Understanding “Human Error”』 및 Just Culture, 2014
- Amy C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams”, Administrative Science Quarterly, 1999
- Google, 『Site Reliability Engineering』 — Postmortem Culture, sre.google
- DORA, “2024 Accelerate State of DevOps Report”, dora.dev
