제16화. 시스템 장애가 터졌을 때, 범인을 찾지 말고 '길'을 찾으렴
아들아, 오픈 초기에는 네가 아무리 완벽을 기했어도 예상치 못한 장애가 터지기 마련이란다. 화면이 멈추고 고객의 항의 전화가 빗발치는 그 순간, PM인 네가 가장 먼저 해야 할 일은 누구의 잘못인지 가려내는 것이 아니야. 침몰하는 배에서 범인을 찾는 사이 배는 가라앉고 만단다. 지금 당장 배의 구멍을 막고 나갈 '길'을 찾는 법을 알려줄게.
장애가 발생하면 누구나 당황해서 상황을 숨기거나 혼자 해결하려 들지. 하지만 장애는 시간이 흐를수록 눈덩이처럼 불어난단다. 문제가 생겼음을 인지하는 즉시 관련자들에게 알리고 도움을 청하는 것이 피해를 최소화하는 유일한 방법이란다.
보고가 늦어지는 1분이 복구에 걸리는 1시간을 늦춘다는 사실을 잊지 마라.
아빠의 노하우: 아빠는 장애가 터지면 5분 안에 상황을 공유했단다. "원인은 파악 중이지만 현재 서비스가 중단되었습니다"라고 먼저 알리는 거야. 그래야 고객사도 대응 시나리오를 가동할 수 있고, 너는 뒤에서 쏟아질 비난을 방패 삼아 복구에만 집중할 수 있는 시간을 벌 수 있단다.
회의실에 모인 사람들이 "누가 코딩을 이렇게 했냐", "기획이 문제 아니냐"며 서로를 탓할 때, 너는 그 흐름을 끊어야 해. 지금 중요한 건 '과거의 실수'가 아니라 '현재의 복구'와 '미래의 방지'란다. 팀원들이 위축되지 않고 기술적인 해법을 낼 수 있는 환경을 만들어주렴.
범인을 잡는 데 쓰는 에너지는 팀을 죽이지만, 길을 찾는 데 쓰는 에너지는 팀을 살린단다.
아빠의 노하우: 아빠는 비난이 쏟아질 때 "책임은 내가 질 테니, 지금은 어떻게 하면 정상화할 수 있는지 대안만 말해달라"라고 팀원들의 앞을 막아섰어. PM이 방패가 되어줄 때, 개발자들은 비로소 공포에서 벗어나 최선의 복구 로직을 찾아내기 시작한단다. 실제로 누군가를 탓하기 시작하면, 개발자들은 혼날까 봐 장애 로그를 숨기게 된단다. 그게 복구를 더 늦추는 진짜 재앙이지. 그렇게 되면 원인 찾는데 시간과 노력이 훨씬 많은 노력이 필요하게 된단다.
실제 “책임은 내가 진다”고 하면 고객사나 상사로부터 엄청난 압박이 올 거야… ‘실제 책임을 어떻게 질 건데’... 등의 이야기로 공격을 받을 거야… 그래도. 비록 네가 욕을 먹을지언정 팀을 지키는 것이 결국 프로젝트를 살리는 길이란다
장애 상황에서는 마음이 급해서 당장 에러만 안 나게 코드를 덧대고 싶어 지지. 하지만 그건 또 다른 장애를 예약하는 일이야. 일단 서비스를 정상화하는 '워크어라운드(Workaround)'를 실행한 뒤, 숨을 돌리고 나서 반드시 뿌리를 뽑는 근본 대책을 세워야 한단다.
불을 끄는 것과 불이 난 원인을 제거하는 것은 전혀 다른 차원의 작업이란다.
아빠의 노하우: 아빠는 임시 조치로 서비스가 돌아간다고 해서 상황을 종료시키지 않았어. "왜 이런 예외 케이스가 발생했는가?"를 집요하게 추적했지. 장애는 시스템의 약점을 알려주는 가장 고마운 신호이기도 하단다. 그 신호를 무시하면 똑같은 이유로 다시 무너지게 된단다.
장애가 수습된 후 쓰는 보고서는 단순히 잘못을 비는 종이가 아니야. 무엇이 문제였고, 어떻게 해결했으며, 다시는 같은 일이 생기지 않도록 어떤 방어 로직을 추가했는지 기록하는 '성장 기록'이란다.
잘 정리된 장애 보고서 한 장은 열 번의 성공 사례보다 팀의 실력을 더 크게 키워준단다.
아빠의 노하우: 아빠는 장애 보고서를 쓸 때 '사람의 실수'로 결론 내지 않았어. "실수를 유발할 수밖에 없었던 시스템 구조"를 지적하고 이를 개선하는 방향으로 보고했지. 실수는 누구나 하지만, 그 실수를 시스템으로 막지 못한 것을 반성할 때 진짜 전문가가 된단다.
한 마디
"장애는 프로젝트를 망치러 온 불청객이 아니라, 네 시스템을 더 단단하게 만들어주러 온 스승이란다. 당황하지 마라. 네가 침착하게 길을 찾는다면, 그 장애는 너를 대체 불가능한 전문가로 증명해 주는 기회가 될 거란다."
상황이 터졌을 때, 당황하지 말고 다음 5단계를 차례대로 실행해 보렴.
[1단계: 즉시 전파] 장애 인지 즉시 채널을 통해 유관 부서 및 의사결정권자에게 현황 공유.
[2단계: 영향도 파악] 전체 서비스 중단인지, 특정 기능의 오류인지 피해 범위를 데이터로 확인.
[3단계: 우회로 확보] 근본 원인 파악 전이라도 서비스를 임시 정상화할 수 있는 방법(서버 재시작, 기능 차단 등) 실행.
[4단계: 집중 복구] 핵심 개발 인력과 함께 로그 분석을 통해 원인을 규명하고 패치 적용.
[5단계: 사후 리포트] 복구 완료 후 타임라인별 조치 사항과 재발 방지 대책을 문서화하여 공유.