장애를 막은 사람은 왜 칭찬받지 못할까 — 25년째 회자되는 MIT의 '소방수 조직' 논문

새벽 3시에 터진 서버 장애를 밤새 복구한 개발자는 다음 날 영웅이 돼요. 슬랙에는 박수 이모지가 쏟아지고, 팀장님은 회의에서 공개적으로 칭찬하죠. 그런데 애초에 그 장애가 일어나지 않도록 미리 모니터링을 손보고 테스트를 보강해 둔 개발자는요? 아무 일도 일어나지 않았으니, 아무도 모릅니다. 2001년 MIT 슬론 경영대학원의 넬슨 리페닝과 존 스터먼 교수가 쓴 논문 'Nobody Ever Gets Credit for Fixing Problems that Never Happened'(일어나지 않은 문제를 고친 사람은 아무도 인정받지 못한다)가 다루는 게 바로 이 이야기인데요. 25년이 지난 지금도 개발자들 사이에서 계속 다시 읽히는 데는 이유가 있어요.

조직은 왜 '불 끄기'에 중독될까

논문의 핵심은 '능력의 함정(capability trap)'이라는 개념이에요. 이게 뭐냐면, 조직이 단기 성과 압박 때문에 개선 활동을 줄이고, 그 결과 문제가 더 많이 터지고, 그래서 더더욱 개선할 시간이 없어지는 악순환을 말해요. 일하는 방식에는 크게 두 가지가 있죠. 하나는 '더 열심히 일하기'. 야근하고, 급한 불을 끄고, 일단 돌아가게 만드는 거예요. 다른 하나는 '더 똑똑하게 일하기'. 프로세스를 개선하고, 자동화하고, 근본 원인을 제거하는 거고요. 문제는 두 방식의 효과가 나타나는 속도가 다르다는 거예요. 불 끄기는 효과가 바로 보이는데, 개선 투자는 몇 주, 몇 달 뒤에야 결실이 나타나거든요. 마감 압박이 오면 누구나 당장 효과가 보이는 쪽을 선택하게 되고, 개선에 쓸 시간을 빼서 불 끄기에 넣게 돼요. 그러면 시스템은 점점 더 망가지고, 불은 더 자주 나고... 이 사이클이 한 번 돌기 시작하면 빠져나오기가 정말 어렵다는 게 논문의 분석이에요.

더 무서운 건 '사람 탓'으로 보인다는 것

논문이 지적하는 또 하나의 함정은 '자기확증적 귀인 오류'예요. 말이 어려운데, 풀어보면 이래요. 시스템이 망가져서 생산성이 떨어지는 건데, 관리자 눈에는 '직원들이 열심히 안 해서'로 보인다는 거예요. 그래서 더 쥐어짜고, 개선 시간은 더 줄어들고, 상황은 더 나빠지고, 관리자는 '거 봐, 역시 사람이 문제야'라고 확신하게 되죠. 자기 판단이 상황을 악화시키면서 동시에 그 판단을 강화하는 구조라서 '자기확증적'이라고 부르는 거예요. 저자들이 실제 제조업 현장을 연구해 보니, 개선 프로그램이 실패하는 이유는 기법이 나빠서가 아니라 이 역학 구조 때문이었다고 해요.

소프트웨어 업계는 이 논문을 어떻게 소화했나

이 논문의 통찰은 이후 소프트웨어 업계 곳곳에 스며들었어요. 구글 SRE 조직이 '운영 잡무(toil)는 업무 시간의 50%를 넘기면 안 된다'는 규칙을 만든 것도, 기술 부채라는 개념이 보편화된 것도 같은 문제의식이거든요. 테스트 코드 작성이나 리팩터링이 '일정에 여유 있을 때 하는 것'으로 취급되는 팀과, 스프린트에 개선 작업을 명시적으로 박아 넣는 팀의 1년 뒤 모습이 어떻게 갈라지는지, 경험해 본 분이라면 다들 아실 거예요.

그래서 우리는 뭘 해야 할까

논문이 주는 실무 교훈은 두 가지로 정리할 수 있어요. 첫째, 예방 작업을 가시화하세요. 장애가 안 난 건 운이 아니라 누군가의 작업 덕분이라는 걸 숫자로 보여줘야 해요. 배포 빈도나 장애 복구 시간 같은 지표를 추적하고, 개선 작업도 기능 개발과 똑같이 티켓으로 만들어 회고에서 공유하는 거죠. 둘째, 악순환은 개인의 의지로 못 끊어요. '이번 분기만 버티고 다음에 갚자'는 말이 반복된다면, 그건 누가 게을러서가 아니라 시스템이 그렇게 설계된 거예요. 개선 시간을 제도적으로 보호하는 장치, 예를 들어 정기적인 기술부채 정리 스프린트 같은 게 필요해요.

한 줄로 정리하면 이래요. 불 끄는 영웅만 칭찬하는 조직은 계속 불이 나고, 불이 안 나게 만든 사람을 찾아내 칭찬하는 조직만이 악순환을 끊는다. 여러분 팀은 어느 쪽인가요? 장애를 미리 막은 동료의 공로를 어떻게 드러나게 만들 수 있을지, 경험과 아이디어를 댓글로 나눠주세요.