좋은 장애 대처란 무엇일까?
어떤 사고에도 끄떡없는 PM의 대처 방식
큰 사고는 순간은 생생합니다.
재작년, 2022년 10월 15일 토요일 오후였습니다. 판교 데이터 센터 화재로 카카오의 모든 서비스가 순식간에 마비된 일이 있었는데요. 제가 담당하는 서비스도 불똥을 정통으로 맞아 난리가 났습니다. 주말이라 친구의 결혼식장 가던 길에 바로 옆 카페로 뛰어들어가 평일보다 10배는 울리던 메신저 알람을 확인했습니다.
장애는 예측하지 못한 때 터집니다. 큰 서비스라면 당연히 이중, 삼중 대비가 있어야겠지만 실무 PM들이 이런 점까지 대비까지 할 수는 없습니다. 결국 현장 PM에게 기대되는 역할이란 장애 상황이 발생했을 때 최대한 빠르고 현명하게 대처하는 것일텐데요. 이번 챕터에서는 올바른 장애 대처 요령에 대해 설명해 보겠습니다.
대처 순서는 크게 1) 장애 발생 전, 2) 장애 발생 중, 3) 장애 발생 후 3단계로 나누고, 그 안에서도 세부 순서를 나누어 PM이 장애상황 중 해야 할 6가지 업무에 대해 이야기해 보겠습니다.
1. 장애 발생 전
1. 상시 대기
PM은 항상 연락이 닿아야 합니다. 야간, 휴일 가리지 않고 장애 상황이 발생하면 가장 먼저 반응할 수 있도록 최소한 신경은 쓰는 상태여야 합니다. 장애 대응 채널의 알림은 항상 켜두고 동료들의 전화번호도 전부 저장해 둡니다. 해외 출장이나 여행처럼 장시간 연락을 받지 못하는 상황이 생기면 반드시 동료 PM을 책임자로 지정해 둡니다.
설, 추석 명절, 연말처럼 동료들이 단체로 긴 휴가를 간다면 비상연락망을 만들어 인지시키는 것도 PM의 역할입니다. 개발자들이 일선에서 불길을 잡는 소방관의 역할이라면 PM은 직접 불을 끄는 것을 제외한 모든 일을 수습하고 책임지는 뒷자리에 있다 하겠습니다. 장애 상황에 PM이 연락이 안 되면 그것만큼 속 터지는 일도 없습니다. PM스스로도 나중에 면목이 서질 않습니다.
2. 장애 발생 중
1. 영향 범위 파악
일단 장애가 발생하면 PM은 영향 범위부터 파악합니다. 가장 쉬운 방법은 CX팀에 물어보는 것입니다. 아래 3가지를 묻습니다.(* CX팀이란? : CRM팀, CEM팀 등 다양한 이름으로 부르며 고객센터 운영을 전담하는 조직.)
1. 최초 발생 시점
2. 총 고객 문의 건수 (실시간 인입량)
3. 고객 문의 종류
위 정보를 알면 1) 장애가 시작된 시점, 2) 장애의 심각성, 3) 주요 장애 지점을 파악할 수 있습니다.
장애 상황마다 영향의 범위는 천차만별입니다. PM은 1) 장애로 영향을 받는 인원, 2) 해당 인원이 보는 피해의 심각성을 고려하여 위기 등급을 판단하고 모든 구성원에게 전파합니다. 빠른 대처를 위해 장애 발생 전에 위기 기준을 세워두는 것이 좋습니다. 예를 들어 비교적 적은 인원에게 발생한 문제일지라도 결제와 관련된 이슈라면 1등급 장애라고 판단하는 식입니다.
2. 공지 작성
영향 범위 파악과 동시에 장애 공지를 준비합니다. 장애 공지를 작성할 때는 “공지를 꼭 작성해야 할지 판단”부터 합니다. 실제 서비스에 장애가 발생하면 80% 이상은 10분 이내로 해결되기 때문입니다. 개발자들도 돌발 상황 대처에 단련되어 있기 때문에 대부분 케이스는 쉽게 종료됩니다.
이럴 때 PM이 판단을 잘못해서 모든 사용자에게 장애 공지가 나가버리면 실 서비스는 정상화되었는데 사용자들에게는 혼선만 주는 결과를 초래합니다. 공지 준비는 그대로 진행하되 정말로 나가야 하는지 여부를 개발 대처 상황을 보고 지혜롭게 판단합니다. 수정 시간이 오래 걸리는 이슈라면 개발팀에서 먼저 공지 좀 내보내달라고 요청이 옵니다.
장애 공지는 크게 6개 요소를 담습니다. 미리 작성해 두고 단어만 교체하는 수준이면 빠른 대응이 가능합니다.
1. 인사말
2. 현상
3. 원인 (추정 or 생략가능)
4. 진행상황
5. 문의창구
6. 사과
예시를 들면 이런 식입니다.
안녕하세요 OO 서비스팀입니다.
현재 카드 결제가 동작하지 않는 문제가 발생하였습니다.
주요 카드사 (3개사) 전산망 마비에 의한 현상으로
현재 시스템 복구를 진행하고 있습니다.
추가 문의사항은 OO@abc.com으로 부탁드리겠습니다.
다시 한번 서비스 이용에 불편을 드려 죄송하며
빠른 복구를 위해 최선을 다하겠습니다.
OO 서비스팀 드림
3. 원인 탐색 및 해결
장애 공지까지 나갔다면 최선을 다해 원인을 찾고 해결합니다. 수정 작업은 개발팀에서 전담하지만 PM도 할 일이 있습니다.
이슈 해결은 방탈출 게임과 매우 비슷합니다. 개발팀이 자물쇠를 따는 사람이라면, PM이 방 이곳저곳을 살피며 힌트를 찾아주는 역할을 합니다. 오류 상황을 재현하여 개발팀에 전달하기도 하고, CX팀에게 묻거나 현장 고객들의 목소리를 정제하여 문제 원인의 실마리를 찾아냅니다. 개발팀이 정책 정리를 요청한다면 빠르게 정리해 줍니다.
더불어 PM은 추가 피해를 막는 의사결정도 합니다. 예를 들어 복구가 진행되는 동안 영향 범위를 최소화하기 위해 추가 주문을 봉쇄한다던지, 진행 중인 주문을 강제 종료할 수도 있습니다. ‘개발팀이 고칠 일이니까 난 그냥 기다리지 뭐’ 하는 PM보다 어떻게든지 해결책을 생각해 보려는 PM이 훨씬 믿음직합니다.
3. 장애 발생 후
1. 피해 규모 확인 및 보상
장애가 끝나면 피해 규모를 확인합니다. 피해규모를 정리할 때는 아래 포맷이 도움이 됩니다.
1. 장애로 영향받은 고객의 수
2. 장애로 영향받은 매출 규모
3. 주요 피해 타입
피해 규모가 확인되면 보상 정책을 세웁니다. 사실 대부분의 장애는 보상이 필요하지 않은 매우 경미한 문제입니다. 다만 보상이 필요하다면 두번 말이 나오지 않도록 꼼꼼히 해야합니다. 보상 수준을 책정할 때는 분노한 고객의 목소리를 전부 받아들이거나, 무조건 보상 규모를 축소하려 하는 것 모두 훌륭한 선택이 아닙니다.
PM은 고객과 계약상 문제 되는 지점을 확인하고, 회사 내 법무팀, 사업팀, 재무팀과 충분히 상의한 뒤 정제된 언어로 보상책을 전달합니다. 보상 재원과 방식을 정하는 것은 의사결정자의 역할이지만 해당 보상을 고객이 납득할 수 있도록 정돈해서 전달하는 것이 PM의 역할입니다.
2. 재발 방지 / 보완책 수립
장애 수습이 끝나면 재발 방지책을 수립합니다.
우선 장애 리포트를 작성합니다. 대개 개발 리더가 작성하지만 큰 장애의 경우 PM이 도와서 쓰는 경우도 있습니다.
1. 유관 부서 전체 태그
2. 장애 상황 1줄 요약
3. 장애 발생 시간 (발생, 인지, 해결)
4. 장애 현상
5. 장애 발생 원인 (복합적이라면 순서대로)
6. 장애 대응 (실제 대응한 방식 전체 요약)
7. 대책 (임시조치와 중장기적인 개편 방향)
장애 리포트를 쓰는 것은 피곤하고 누군가에게는 아주 불편한 일이지만 절대 생략하면 안 됩니다. 기록을 남겨두지 않으면 다음에 이런 일이 또 반복되고, 대응도 똑같습니다. 모두가 한 번쯤은 정제된 언어로 이슈에 대해 생각해 볼 시간을 가져야 합니다. PM은 특히 대책 부분에 집중하여 기존 프로젝트를 미뤄서라도 재발 방지책을 위한 일정을 꼭 빼두어야 합니다.
보완책을 세울 때 중요한 것은 장애를 발생시킨 특정 인물을 지정해서 탓하지 않는 것입니다. 도리어 그런 상황이 발생했다면 PM이 해당 동료를 보호해 주어야 합니다. 회사일은 기본적으로 시스템이기 때문에 1명의 사람이 망칠 수 있었다면 그것부터 문제이기 때문입니다. 악의적인 경우만 아니라면 업무 방식을 손봐야 합니다.
누군가를 찾아 비난하는 행태가 벌어지면 조직이 급속도로 경직됩니다. 사람들은 사고와 뒤따른 비난을 두려워하게 되고 모든 작업을 최대한 보수적으로 진행합니다. 간혹 일부 대기업 중에 속도가 극단적으로 느려진 조직들이 있는데 이런 사건 사고들이 모여 경직된 문화를 형성한 결과입니다.
장애상황은 막으면 좋겠지만 쉽지 막히지 않습니다. 사람이 살다가 가끔씩 아픈 것처럼 일정 수준의 장애는 당연한 현상입니다. 심지어 IT공룡이라고 하는 인스타그램이나 유튜브도 연단위로 크고 작은 장애가 발생하곤 하니까요. 오히려 장애 현상을 상수라고 했을 때 PM의 일은 효과적인 대처라고 할 것입니다.
위와 같이 6개 개념에 대해 PM이 유념하고 있다면 아무리 큰 장애가 발생하더라도 어떻게든 수습할 수 있습니다. 장애상황은 두렵고 어려운 일이지만 PM과 제품 조직은 여러 차례 난관을 극복하면서 묘한 우정도 나눌 수 있습니다. 비 온 뒤 땅이 단단해지는 것처럼 PM이 조직을 살뜰하게 챙긴다면 한두 번의 장애 현상은 제품을 오히려 건강하게 합니다.
