12. 사고를 쳐도 혼나지 않는 회사
너의 실수를 부검한다 - 포스트모템(Postmortem)
우리는 모두 크고 작은 실수를 경험한다. 기업의 활동이 사람들의 크고 작은 결정들로 이루어지다 보니 작은 실수로 인해 큰 손실이 발생하는 일을 막을 수 없다. 어느 증권회사에서 $1,000짜리 1주를 팔아야 하는 상황에서 실수로 $1에 1,000주를 팔았다면 말 그대로 밀리언 달러의 손실을 입게 된다 (그런데 그것이 실제로 일어났습니다).
내가 다니던 회사에서도 한 엔지니어의 단순한 실수로 데이터베이스가 복구 불가능한 상황이 되어, 클라우드 서비스가 24시간 가까이 정지된 일이 있었는데, 이 일로 회사에서 추정한 손실은 6억 원 정도였다. 아마도 회사의 신뢰도 손상으로 인한 기업 가치의 하락은 그것보다 더 크지 않았을까 싶다.
한 사람의 의도하지 않은 단순한 실수가 큰 손실을 초래하기도 하지만, 여러 사람이 의논을 통해 결정한 내용이 천천히 시간을 두고 좋지 않은 결과로 나타나는 경우도 있다. 이러한 일을 방지하기 위해 ‘실수는 병가지 상사이니 다음에 잘하자'라고 다짐을 하는 것으로 충분한 것일까? 또는 책임자를 문책하는 것이 재발을 효과적으로 방지하는 방법일까?
포스트모템 (Postmortem)
실리콘밸리 기업들은 포스트모템을 통해 왜 문제가 일어났는지 분석하고 그 대책을 수립한다. 포스트모템(Postmortem), 우리말로 부검 또는 검시라고도 한다. Post는 “후”, 모르템은 “죽음”이라는 뜻이다. 즉, 피해자(?)를 사망에 이르게 한 직,간접적인 원인을 사후에 총체적으로 알아내기 위한 방법이다.
회사에서 일어나는 사고를 분석하고 예방하기 위한 방법론을 얘기할 때 왜 이런 차가운 느낌의 단어를 쓰는지 잘 모르겠지만, 비교적 캐주얼한 분위기의 실리콘밸리 기업들에서 엄중한 분위기의 미팅을 지칭하기에 알맞은 이름이라는 생각이 든다. 위키피디아의 포스트모템 페이지에 링크되어 있는 ZDNet의 기사에 성공적인 포스트모템의 포인트들이 잘 설명되어 있는데, 그 몇 가지를 아래에 정리해 보았다.
1. 모든 관계자를 초대하는 미팅
포스트모템은 관련자 모두가 참가하는 것이 바람직하다. 관리자들만 모이거나 팀의 일부만 모일 경우 핵심적인 정보나 통찰(insight)을 놓칠 수 있기 때문이다. 이를 위해 중요도가 높은 공식 미팅으로 일정을 잡되 가급적 사고 수습이 이루어진 직후에 하는 것이 좋다.
2. 시간 분석 (timeline)
사고가 일어난 과정과 그 대응 과정을 상세하게 기술한다. 언제 누가 어떤 정보를 접하고 어떤 결정을 내렸는지, 각 결정을 내리게 된 배경에 어떤 이유가 있었는지를 기술하다 보면, 시간을 거슬러 올라가 근원적 문제점(root cause)을 찾아내거나 복합적인 원인 분석을 하는데 한 발짝 더 가까이 다가갈 수 있다.
3. 잘된 일과 잘못된 일을 모두 인식한다
잘된 일은 모범 사례(best practice)로서, 잘못된 일은 보완해야 할 시스템의 약점을 찾아내는데 꼭 필요하다.
4. 책임자를 문책하는 미팅이 아니다
실수한 사람 또는 문제의 책임자에게 비난의 화살이 돌아간다면, 그 조직은 점점 책임을 회피하기 위해 정보를 각 팀(혹은 각 개인)의 입장에서만 해석하게 된다. 이렇게 되면 진정한 원인 분석을 통한 다음 사고를 예방한다든지, 시스템을 팀 차원에서 개선한다든지 하는 일이 힘들게 된다.
5. 개선책을 도출한다
단순히 피상적인 개선책만 세운다면 다음 사고를 앉아서 기다리는 것과 같다. 근원적 문제점을 찾기 위해 '5 Why'라고 하는 비교적 간단한 기법을 쓰기도 하는데, 이는 계속해서 다시 묻는 것이다. ‘그렇다면 그것은 왜 일어났는가?’ 껍질을 다섯 번 정도 벗기고 나면 우리는 양파의 속에 무엇이 있는지 알아볼 수 있다. 이렇게 해서 찾아낸 가장 근저에 있는 원인에 대한 개선책을 내는 것이다.
6. 공개한다
가능하다면 회사 전체와 공유하는 것이 좋다. 어떤 실수의 위험에 노출되어 있는지, 그를 예방하기 위해 어떤 노력을 하고 있는지, 여러 사람이 알 수록 업무 프로세스나 시스템을 개선하는데 정보 공유나 협조를 구하기 쉽다. 실수를 조직 전체가 지성적인 방법으로 간접 경험하는 그 자체로 가치가 있다.
포스트모템의 예: 집에서 일어나는 실수
우리 동네 초등학교에서는 아이들의 점심을 미리 온라인으로 주문하도록 되어 있다. 우리는 보통 한 달치를 아이들과 상의해서 주문한다. 열 몇 개의 메뉴가 매일 조금씩 바뀌는데, 그 중 아이들이 좋아하는 메뉴를 너무 반복했더니 아이들이 쉽게 질려해서, 가급적 다양한 메뉴를 접해볼 수 있도록 하고 있다.
어느 월요일, 팀원들과 함께 코드 리뷰를 하고 있었는데 모르는 번호로부터 전화가 왔다. 전화를 받아보니 학교였다. 아이가 교무실에 와 있는데, 아이 앞으로 점심식사가 준비되어 있지 않다는 것이다. 아차. 점심 주문을 잊고 있었다. 다행히 직장이 가까워서 회사의 카페에서 아이들 입맛에 맞게 샌드위치를 만들어서 학교로 달려갔다. 입을 삐죽 내밀고 기다리고 있던 둘째는 얼른 샌드위치를 들고 다른 아이들이 먹고 있는 테이블로 달려갔고, 다행히 점심식사 시간이 늦은 첫째는 이제 막 교실에서 나오는 길이라 중간에 만나서 전해줄 수 있었다. 아이들이 내가 만들어주는 샌드위치를 좋아해서 다행이다.
회사로 돌아간 나는 그 달치의 점심을 주문했지만, 이틀 전에만 주문이 가능하기 때문에 다음날 아침 아이들 도시락을 따로 준비해야 했다. 이런 일이 두 번째 일어났을 때, 우리는 이것을 문제로 인식하고, 간단한 예방책을 마련했다. 회사에서 일하던 도중 아이들 도시락을 부랴부랴 챙겨서 학교로 달려가는 일은 부모 입장에서나 아이 입장에서 즐거운 일은 아니다. 지금에서야 드는 생각이지만, 우리의 가장 큰 실수는 이 일이 처음 일어났을 때 문제로 인식하지 않은 일이다. 이 사건을 간단한 포스트모템의 형식으로 재구성하면 아래와 같다.
Post-mortem: 학교에서 아이의 점심이 준비가 안 되었음.
Overview
우리 아이는 학교에서 제공하는 점심을 먹는다. 그 점심은 미리 부모가 주문해 놓아야 제공되는데, 지난 달 말에 부모가 주문을 하는 것을 깜빡했다. 점심이 준비가 안 되어 아이가 점심을 굶을 위기에 처했다. 회사에서 전화를 받은 아빠는 급히 회사 카페에서 샌드위치를 만들어서 학교에 있는 아이에게 가져다주었다.
Timeline
11:45 아이가 점심이 없는 것을 알게 되었다
11:47 아이가 교무실에 달려가 점심이 없다고 말함
11:48 아이 아빠가 전화를 받는다
11:55 아빠가 회사 카페에서 샌드위치를 만든다
12:10 샌드위치가 아이에게 배달되었다
Immediate Action
가장 빨리 준비할 수 있는 음식을 직접 배달한다.
옵션 1: In-N-Out 햄버거 가게에서 햄버거를 사서 배달한다. 예상 소요시간 35분
옵션 2: 샌드위치를 만들어서 배달한다. 예상 소요시간 25분
Root Cause Analysis
점심을 오더 하는 것은 잊기 쉬운 일이다.
5 Why Analysis:
아이들의 점심 주문이 되어 있지 않았다.
Why? 점심은 최소 2일 전에 미리 주문해야만 한다.
Why? 매월 말일 전날에 주문을 해야 했는데 잊었다.
Why? 아이들의 의견을 물어봐서 하려고 하다가 잊었다.
Why? 한 달에 한번 있는 일이라 잊기가 쉽다.
Why? 습관적으로 반복되지 않는 일은 잊기가 쉽다.
Discussions
한 달에 한 번 해야 하는 일이다 보니 잊기 쉽다. 하지만 더 자주 오더 하도록 바꾸면 실수를 더 자주 하게 되는 위험에 노출된다. 한 학기 치를 오더 하게 되면 아이의 입맛에 맞추기 어렵다는 단점이 있다. 휴대전화의 리마인더 기능을 이용하면 좋을 것 같다.
Preventative Measures
한 달에 한 번 한 달치를 아이들과 함께 상의해서 주문한다.
점심 주문은 아빠와 엄마가 같이 하는 것으로 해서 한 사람이 잊더라도 다른 사람이 기억하도록 한다.
두 사람의 휴대전화에 월간 리마인더를 설정하고 런치 주문이 완료되었을 때 해제한다.
Monitoring
주말에 아이들과 학교의 점심에 대화를 하고, 다음 주간 분량의 점심 메뉴를 같이 검토하는 것으로 전체적인 아이들의 점심 식사 만족도에 대한 모니터링을 한다.
구글의 포스트모템
구글이 공개한 “Site Reliability Engineering” 책에 예시로 등장한 실제 포스트모템 문서는 훨씬 전문적이다.
Summary
셰익스피어의 새로운 소네트가 발견되는 바람에 셰익스피어 검색이 폭증했고, 셰익스피어 검색이 66분 동안 다운되었다.
Impact
약 1.21 billion 검색 요청이 손실되었으나 매출에 영향 없음.
Root Causes
등록되어 있지 않은 검색어에 대한 검색 폭증과 시스템 리소스 누수의 복합적 원인으로 시스템이 단계적으로 다운됨.
Trigger
보통 발견되기 힘든 시스템 리소스 누수 버그가 단시간에 집중된 검색 트래픽 증가에 의해 발현됨.
Resolution
임시 클러스터로 용량 10배 증가. 검색 오류가 나지 않도록 검색 인덱스를 업데이트. 시스템 리소스 누수 버그 패치 완료.
Detection
모니터 시스템이 비정상적으로 증가한 시스템 에러(HTTP 500 응답 코드)를 감지하고 시스템 담당자를 호출함.
Action Items
시스템 단계적 다운에 대한 업무 매뉴얼 개선 - 완료
클러스터 간 부하 배분 개선
시스템 단계적 다운에 대한 테스트
검색어를 연속적으로 업데이트하는 방법 조사
검색 랭크 서브시스템의 리소스 누수 버그 잡기 - 완료
셰익스피어 검색의 부하를 완화하는 기능 추가
검색 다운 시 서버가 응답하는 시나리오에 대한 시스템 테스트 추가
검색 랭크 서브시스템 패치 - 완료
시스템 오류 버짓 완전 소모로 인해 한 달간 프로덕션 시스템 업데이트 동결
Lesson Learned
잘 된 일
모니터 시스템이 빠르게 엔지니어들을 호출함
새로운 키워드를 포함한 셰익스피어 검색 시스템을 신속하게 설치함
잘 안 된 일
시스템이 단계적으로 다운되는 상황에 대한 연습 부족
이 일로 시스템 오류 버짓 완전히 소모됨
운이 좋았던 일
셰익스피어 애호가들로부터 새로운 소네트를 입수할 수 있었다
시스템 로그로부터 시스템 다운의 시작점을 찾아냄
새로운 검색어를 인덱스에 포함시키자 시스템 다운이 해결됨
Timeline (2015-10-21)
14:51 셰익스피어의 소네트가 새로 발견되었다는 뉴스 리포트
14:53 셰익스피어 검색 인덱스 트래픽이 88배 증가 (하지만 인덱스에 소네트 없음)
14:54 시스템 다운 시작
14:55 모니터 시스템이 담당자 호출 폭풍
14:57 셰익스피어의 모든 검색 트래픽에 검색 실패
14:58 시스템 담당자가 백엔드 검색 시스템 실패율이 비정상적으로 높은 것을 인지
15:01 사고 접수. Incident commander에 Jennifer.
15:02 누군가 우연히 shakespeare-discuss@ 이메일 리스트에 이메일을 보냈는데 셰익스피어 애호가인 Martym의 눈에 띔
15:03 Jennifer가 shakespeare-incidents@ 리스트에 사고 보고
15:04 Martym이 새로운 소네트를 찾아내고 검색 시스템 업데이트 문서를 찾기 시작
15:06 엔지니어들이 시스템 로그로부터 원인 분석 시작
15:07 Martym이 문서를 찾고 검색 시스템 업데이트 준비 작업 시작
15:10 Martym이 소네트를 추가하고 인덱스 작업 시작
15:18 Clarac 리소스 누수 버그 찾아냄
15:20 인덱스 작업 완료
15:28 트래픽을 더 많은 서버가 소화할 수 있도록 재분배
(중략)
15:36 시스템 회복 시작
(중략)
16:00 시스템 회복 완료
16:30 사고 해결 완료 (시스템 회복 후 30분 동안 정상 운영 조건 만족)
포스트모템을 하지 않은 실수는 좀비가 되어 돌아온다
앞에서 본 구글의 포스트모템의 예에서 아주 자세히 설명된 timeline만큼이나 눈에 띄는 부분이 9개의 action items다. 단순히 버그를 잡는데 그치지 않고, 시스템 다운에 대한 체계적인 테스트를 하는 등의 프로세스 개선, 비슷한 사고가 일어났을 때 증상을 완화할 수 있는 시스템 개선안을 찾아내었다.
Martym이 새로운 소네트를 추가한 검색 시스템 패치가 완료된 순간 시스템 다운 현상이 해결되었는데 이때 ‘문제 해결'이라며 손 털고 일어났다면 어찌 되었을까. 유명 인물의 새로운 관련 검색어가 발견될 때마다 구글은 이 일을 다시 겪어야 했을 것이다. 아마도 다음엔 그다지 운이 좋지 않아, 금방 문제를 해결할 수 없을지도 모른다. 다행히 사고 지휘자 Jennifer가 Clarac에게 연락하였고 시스템 로그로부터 리소스 버그를 발견했다. 다음에 대량의 검색 오류가 일어나더라도 시스템이 다운되는 일은 없을 것이다.
이번 사건이 발현시킨 숨어있던 버그는 시스템을 단계적으로 다운시켜 66분간 특정 검색이 안 되는 결과를 낳았다. 만약 여태 발견되지 않은 (또는 새로 만들어진) 버그가 발견되었는데 시스템을 단계적으로 다운되는 상황에 대한 대응이 안되어 있다면 어떻게 될까. 오류가 발생했을 때 시스템이 부하를 능동적으로 해결하고 사용자에게는 정상적인 대응이 될 수 있도록 고안된 장치들이 정상적으로 작동하는지, 시스템 테스트를 정기적으로 반복하고 있다면 이와 같이 상황이 악화되지 않을 것이다.
좀비는 영화관이나 TV에서만 볼 수 있는 것이 아니다. 같은 문제가 해결하고 잊을만하면 다시 나타난다면, 좀비를 마주치는 일보다 더 고통스러운 일이다. 근원적인 문제점을 찾아내고 그를 예방하는 일은 HBO 인기 TV 프로그램 ‘왕좌의 게임’의 Ned Stark의 입버릇처럼 반복되어야 한다. “Winter is coming”.
모두와 공유한다
실수를 회사의 회사의 모든 사람들과 공유한다는 것은 어찌 보면 꽤 큰 위험을 감수하는 일이다. 어떤 포스트모템은 고객사 또는 일반 대중과 공유하기도 하는데, 회사의 프로세스나 기술의 취약점을 드러내서 경쟁사에게 반사이익을 주지 않을까 걱정될 듯도 싶다. 공유의 범위를 넓히는 것이 주는 장기적 이익이 단기적 손실보다 더 크다는 것을 실리콘밸리의 기업들이 경험을 통해 알아낸 것이 아닐까.
전체 회사와 공유해야 하는 이유는 분명해 보인다. 복잡한 업무를 반복적으로 수행하다 보면 언젠가 누군가는 실수를 하기 마련이다. 어떤 실수가 얼마만큼 큰 손실을 가져올 수 있는지 다 같이 이해한다면 실수를 예방하는 일 역시 모두의 것이 된다. 부서 A에서 일어난 실수에 대해 예방책을 세웠을 해때 이를 공유하지 않았다면 비슷한 일을 하고 있는 부서 B와 C는 고스란히 같은 위험에 노출되고 있는 것이다. 더 많은 사람들이 참여할 때 원인을 분석하는 일도 더 깊이 있게 파고들 수 있다.
전에 다니던 광고 플랫폼 회사가 한참 성장하고 있던 시절 Overspend라 불리는 사고가 자주 있었는데, 수 천명의 광고주들이 설정한 수십만 개의 광고 아이템들의 실시간 옥션에서 각 아이템에 설정해 놓은 사용 금액 한도를 조금씩 넘기는 것이었다. 이는 마치 수십만 대의 차량이 움직이고 있는 도로 시스템에서 각 차량의 브레이크를 중앙 통제실에서 조정하는 것과 비슷한 일로, 모든 차량의 속도와 위치를 정확하게 파악하기 위한 복잡한 시스템 중 하나만 잠시 느려지면 수많은 교통사고를 일으키게 되는 일과 비슷했다. Overspend가 이런저런 이유로 일어날 때마다 각 부서에서는 사고 예방책을 세우고 안정성에 문제가 있는 소프트웨어 부품을 개선했지만 작은 사고들이 계속되던 중, 약 1억 정도를 손해 보게 된 큰 사고가 일어나자 모든 부서의 시스템 담당자들이 모여 Post-mortem을 실시했다. 여러 엔지니어가 모여 토론을 하고 그동안 일어난 모든 사고를 정리하다 보니, 이 제어시스템의 설계를 다시 해야 하게 되는 것이 분명해졌다. 단계적으로 설계를 변경하는 동안 다양한 방법으로 시스템 각 단계의 안정성을 모니터링하는 아이디어들이 속출했다. 약 2개월 후, 월별 2~3% 정도 발생하던 Overspend는 0.01% 수준으로 제어되었다. 그 후 내가 회사를 옮길 때까지 Overspend가 총 한도 금액의 0.5%를 넘는 ‘대형 사고'는 한 건도 일어나지 않았다.
이와 같은 개선을 이루어내게 된 바탕에는 많은 사람들이 모여 원인 분석(root cause analysis)을 통해 문제를 정확히 인지한 것이 큰 도움이 되었다. 만약 제어시스템 설계 자체에 문제가 있다고 인정하지 않았다면 이 회사는 그 문제를 푸는데 더 오래 걸렸을 것이고, 현재의 크기로 성장하기 어려웠을 것이다.
외발 자전거로 피자를 배달하다 떨어뜨린 배달원은 잘못이 없다
우리가 알지 못하는 어떤 세상에서는 모든 피자 배달원들이 외발 자전거를 사용한다고 상상해 보자. 충분한 훈련을 통한다면 불가능한 일은 아니다. 문제는 가끔 배달원들이 넘어진다는 것인데, 더욱 확실한 훈련을 통해 극복할 수 있다. 이런 상황에서 피자집주인이나 피자를 시킨 고객이 실수를 한 배달원에게 화를 내는 것이 당연한 것일까?
반복되는 사고나 실수가 일어나는 환경을 자세히 관찰하면, 그 시스템이 마치 사고가 쉽게 일어날 수 있도록 디자인된 것처럼 보인다. 실리콘밸리의 기업들에서 실수를 빨리 인정하고 다 같이 공유할 수 있는 문화가 마련된 바탕에는, 이와 같은 통찰이 경험을 통해 깔려 있다. 사고를 누군가 냈더라도 그 사고를 낸 사람은 어쩌다 그 자리에서 그 일을 하고 있었던 것 뿐, 그 사람의 책임은 아니다. 하지만, 사고가 반복되어 일어나는 곳에서 시스템을 개선하지 않았다면, 그 관리자에게 분명히 책임이 있다. 훌륭한 관리자일수록 책임을 빨리 자신의 것으로 인정하고 (own it), 모든 사람들로부터 정보와 아이디어를 모아서 비슷한 사고가 반복되지 않도록 시스템과 프로세스를 개선하는데 열중하는 것이 사고 예방 캠페인을 벌이는 것보다 효과적이다.
두 사람 이상이 같은 목적으로 모여서 일하는 곳에서 나쁜 일이 일어났을 때 누구나 책임을 회피하고 싶은 유혹을 느낀다. 이 때 책임을 회피하는 행동은 전체 조직에 이로울 수 없다. 마치 몸 어느 한 부분이 병에 걸렸는데 통증을 느끼지 못한다면 제 때 치료를 받지 못해 전체 조직의 생명이 위태롭게 될 수 있는 처럼, 조직의 문제는 빨리 공유하고 빨리 치료하는 것이 최선의 방법이다. 이를 위해 실리콘밸리의 기업들은 큰 문제가 발생하면 다 함께 회의실에 모여 화이트보드에 timeline을 써 나가는 것으로 일을 시작한다.
포스트모템을 작성하고 배포하는 과정에서 중요한 것은 포스트모템에 관련자를 색출하여 처벌하거나 비난하려는 의도가 없다는 것이다. 실수에 대해 비난하는 문화에서는 실수를 안 하려고 노력도 하는 반면 실수가 생기면 숨기려고 할 수밖에 없다. 이러한 심리적 위축으로 실수에 대해 정확히 조사하고 그 문제의 해결책을 공론화하지 않으면 실수는 반복될 수밖에 없다. 그래서 실리콘밸리 기업들에서는 “Blameless” Postmortem, 즉 서로 비난하지 않고 혼내지 않는 사유서 작성을 강조한다.
글: Aiden. 엔지니어링 매니저. 데이터 수집을 통한 프로세스 개선에 관심이 많음.
그림: Chili. 디자이너. 생각을 그림으로 요약하는데 관심이 많음.
Project Group 실리콘밸리를 그리다 / 페이스북
