장애 대응

서비스가 멈췄을 때 무엇을 해야 하는지가 아무 데도 적혀 있지 않던 시절이 있었습니다. 문제를 가장 먼저 아는 쪽은 대개 회사가 아니라 고객이었습니다. 문의 창구에 "저장이 안 돼요" 가 다섯 건쯤 쌓이고 나서야 누군가 이상하다고 느꼈고, 그 누군가가 마침 자리에 앉아 있었는지가 복구 시각을 결정했습니다.

그래서 장애가 나면 회사는 늘 같은 모양으로 움직였습니다. 개발자 대화방에 "지금 접속 안 되는 것 같은데 맞나요" 한 줄이 올라오고, 그 줄을 본 사람 셋이 각자 서버에 들어가 각자 짐작한 곳을 손댑니다. 한 사람이 되돌려 놓은 설정을 다른 사람이 모르고 다시 바꾸고, 그사이 밖에서는 고객이 아무 안내도 받지 못한 채 새로고침만 누릅니다. 어찌어찌 화면이 돌아오면 거기서 끝이었습니다. 무엇이 문제였는지 글로 남기는 사람이 없었고, 두 달 뒤 같은 원인으로 다시 멈췄을 때 사람들은 처음 보는 문제처럼 다시 헤맸습니다.

헤맨 자리가 둘이라는 점이 중요합니다. 하나는 불이 났을 때 누가 무엇을 하느냐가 정해지지 않은 것이고, 다른 하나는 불이 꺼진 뒤 아무것도 남지 않은 것입니다. 장애 대응은 이 둘을 각각 다른 방법으로 없앱니다. 앞쪽은 사람의 순발력 대신 미리 정해 둔 역할과 순서로 덮고, 뒤쪽은 복구를 끝으로 보지 않고 기록을 남기는 데까지를 한 건의 일로 묶어 덮습니다. 그래서 이 말은 고치는 기술이 아니라 고치는 방식을 정해 둔 약속에 가깝습니다.

엔지니어링 축에서 서비스가 도는 동안을 보는 갈래는 셋으로 나뉩니다. 관측성은 지금 시스템 안에서 무슨 일이 벌어지는지 밖에서 알 수 있게 기록과 지표를 미리 심어 두는 일이고, 장애 대응은 실제로 멈췄을 때 누가 먼저 움직이고 무엇부터 되살릴지를 다루며, DORA 지표는 이 조직이 얼마나 자주 안전하게 내보내는지를 네 개의 값으로 잽니다. 셋은 앞뒤로 물려 있습니다. 심어 둔 기록이 없으면 장애 대응은 시작 신호조차 받지 못하고, 고객 문의가 곧 탐지 수단이 됩니다.

페이지덱에서도 같은 일이 있었습니다. 어느 토요일 오후 문서 저장이 18분 동안 실패했는데, 태오가 알게 된 것은 수아가 고객사 담당자에게 전화를 받고 나서였습니다. 그때까지 아무 알림도 울리지 않았습니다. 그날 저녁에 서비스는 돌아왔지만 규원이 물은 것은 다른 쪽이었습니다. 다음에 같은 일이 토요일 새벽 세 시에 벌어지면 누가 몇 분 만에 알게 되느냐는 질문이었고, 그 자리에서 답할 수 있는 사람이 없었습니다. 답이 없었던 이유는 실력이 모자라서가 아니라 그 답을 미리 정해 둔 적이 없어서였습니다. 토요일에 서버를 들여다본 사람이 태오였던 것도 당번이어서가 아니라 마침 연락이 닿아서였습니다.

이 아래 묶인 용어는 네 갈래입니다. 무엇을 사고로 셀지 정하는 개념, 누가 언제 움직일지 정하는 체계, 불이 꺼진 뒤에 무엇을 할지 정하는 사후, 그리고 잘하고 있는지를 재는 지표입니다. 네 갈래의 순서가 곧 장애 한 건이 흘러가는 순서이기도 합니다.

개념은 셀 것과 세지 않을 것을 가르는 갈래입니다. 인시던트는 서비스에 실제로 영향을 준 사고를 가리킵니다. 이름을 따로 둔 이유는 오류가 곧 사고는 아니기 때문입니다. 서버 로그에 하루 수천 줄씩 쌓이는 오류 가운데 사용자가 하려던 일을 못 하게 만든 것만 사고로 셉니다. 판정 기준을 미리 글로 정해 두지 않으면 같은 상황을 두고 한 사람은 사고라 부르고 다른 사람은 아니라고 불러서, 나중에 숫자를 세는 일 자체가 성립하지 않습니다. 대개는 영향 범위와 심각도로 등급을 나눕니다. 전체 사용자가 저장을 못 하면 1등급, 특정 브라우저에서만 글자가 깨지면 3등급 하는 식이고, 등급이 곧 누구를 언제 부를지를 결정합니다. 등급을 나누지 않으면 두 방향으로 어긋납니다. 모든 이상을 같은 무게로 다루면 사람이 금세 지쳐 정작 큰 사고에 반응이 느려지고, 반대로 모든 이상을 가볍게 넘기면 큰 사고를 늦게 알아챕니다.

체계는 사람을 배치하는 갈래입니다. 두 용어가 각각 다른 질문에 답합니다.

1. 온콜 — 정해진 기간에 장애 연락을 받기로 한 당번입니다. 대개 일주일 단위로 돌아가고, 알림을 받으면 몇 분 안에 응답한다는 약속이 함께 붙습니다. 당번을 지정하는 이유는 알림이 모두에게 가면 아무도 자기 일로 여기지 않기 때문입니다. 열 명에게 동시에 울린 알림은 열 명 모두가 다른 누군가 보고 있겠거니 하고 넘기는 알림이 됩니다. 당번표에는 대개 예비 당번을 한 명 더 적어 둡니다. 첫 당번이 지하철 안이거나 전화를 못 받는 상황을 사고가 피해 가지는 않기 때문입니다.
2. 에스컬레이션 — 당번이 감당하지 못할 때 위나 옆으로 넘기는 절차입니다. 넘기는 조건을 시간으로 미리 박아 둡니다. 30분 안에 원인을 좁히지 못하면 무조건 상위 담당자를 부른다는 식입니다. 조건을 숫자로 정해 두는 이유는 새벽 세 시에 "지금 이 사람을 깨워도 되나" 를 혼자 고민하게 두지 않으려는 데 있습니다. 고민하는 시간만큼 복구가 밀립니다.

사후는 불이 꺼진 뒤를 다루는 갈래입니다. 세 용어가 기록·분석·태도를 하나씩 맡습니다.

1. 포스트모템 — 사고 한 건을 되짚어 남기는 기록입니다. 언제 시작됐고 언제 알아챘고 무엇을 해서 돌아왔는지를 시간 순으로 적고, 마지막에 무엇을 고칠지와 누가 언제까지 할지를 적습니다. 기억이 흐려지기 전에 쓰려고 보통 며칠 안에 마감합니다. 읽는 사람이 그 자리에 없던 동료라는 점이 이 문서의 형식을 정합니다. 무슨 로그를 봤고 어느 화면에서 무엇을 눌렀는지까지 적어야 반년 뒤 비슷한 증상을 만난 사람이 이 기록에서 답을 찾습니다.
2. 근본 원인 분석 — 증상이 아니라 그 뒤의 원인을 찾아 들어가는 분석입니다. 디스크가 가득 차서 멈췄다는 답에서 멈추지 않고, 왜 가득 찼는지, 왜 차기 전에 아무도 몰랐는지까지 내려갑니다. 대개 진짜로 고쳐야 할 것은 마지막 답에 있습니다. 디스크를 비우는 것은 복구이고, 남은 용량이 줄면 알림이 울리게 만드는 것이 재발 방지입니다.
3. 책임 추궁 없는 회고 — 사람을 탓하는 대신 구조를 고치는 데 집중하는 태도입니다. 없어도 될 규칙처럼 보이지만 이것이 빠지면 앞의 두 가지가 같이 무너집니다. 실수한 사람이 불려 나가는 자리를 한 번 겪으면 다음 사람은 자기가 무엇을 눌렀는지 정확히 적지 않고, 정확하지 않은 기록에서는 원인이 나오지 않습니다.

지표는 결과를 숫자로 되돌려 주는 갈래입니다. MTTR은 장애가 시작된 뒤 복구될 때까지 걸린 시간의 평균입니다. 네 시간에서 40분으로 줄었다면 당번과 절차가 자리를 잡았다는 뜻으로 읽습니다. MTBF는 장애와 장애 사이의 평균 간격입니다. 두 값은 반드시 같이 봅니다. MTTR만 보면 팀은 불을 빨리 끄는 데만 능숙해지고 불은 계속 나며, MTBF만 보면 한 번 났을 때 온종일 멈춰 있어도 숫자가 괜찮아 보입니다. 두 값을 줄이는 수단도 서로 다릅니다. 앞쪽은 롤백처럼 이전 버전으로 되돌리는 조치로 빠르게 줄고, 뒤쪽은 사후 갈래에서 나온 개선 항목이 실제로 처리돼야 늘어납니다.

네 갈래는 줄 세운 단계가 아니라 고리로 물립니다. 개념이 무엇을 셀지 정해 주지 않으면 지표가 아무 값이나 내놓고, 체계가 없으면 사고가 시작된 시각과 알아챈 시각 사이가 길어져 MTTR이 먼저 망가지며, 사후가 형식만 남으면 같은 원인이 분기마다 돌아옵니다. 반대로 고리가 한 바퀴 제대로 돌면 그 결과가 다음 바퀴의 입력이 됩니다. 이번 사고에서 나온 개선 항목 하나가 다음 사고의 탐지 시각을 앞당기고, 앞당겨진 시각이 다시 복구 시간을 줄입니다.

"지금 1등급이고 이번 주 온콜은 태오예요. 30분 안에 원인 못 좁히면 바로 올릴게요."

등급과 당번과 넘기는 시점이 이미 정해져 있어서 그 자리에서 협의할 것이 없다는 뜻입니다.

"원인은 나중에 찾고 일단 되돌립시다. 지금은 복구가 먼저예요."

장애가 진행 중인 동안에는 이해보다 정상화를 앞에 둔다는 원칙을 확인하는 말입니다.

"이번 회고는 누가 잘못했는지 가리는 자리가 아니라 그 배포가 아무 제동 없이 통과된 경로를 보는 자리입니다."

사람이 아니라 그 사람이 실수할 수 있게 열려 있던 구조를 보자는 선언입니다.

페이지덱은 그 토요일 이후 한 달에 걸쳐 이 절차를 세웠습니다. 태오가 개발자 네 명으로 주간 당번표를 짜고, 규원이 등급 기준을 한 장으로 정리했습니다. 1등급이면 당번이 5분 안에 응답하고 지현이 제품 안에 안내 문구를 띄우며, 수아가 계약 규모가 큰 고객사에 먼저 연락합니다. 처음에는 마흔다섯 명짜리 회사에서 이 정도를 문서로 적는 일이 과하다는 말도 나왔습니다. 적어 둘 내용이 한 장을 넘지 않는다는 점이 오히려 설득이 됐습니다.

다음 장애는 두 달 뒤 수요일 밤에 왔습니다. 태오는 알림을 받고 7분 만에 응답했고, 원인은 못 찾았지만 직전 배포를 되돌려 22분 만에 서비스를 살렸습니다. 원인을 찾은 것은 그다음 날 낮이었습니다. 지현이 그날 회고에서 꺼낸 문장은 22분이 아니라 다른 쪽이었습니다. 토요일 사고 때는 아무도 몰랐던 18분이 이번에는 7분으로 줄었고, 그 차이를 만든 것은 더 뛰어난 사람이 아니라 당번표 한 장이었다는 이야기였습니다.

장애 대응을 빨리 고치는 일로만 읽는 경우가 가장 많습니다. 급한 쪽이 눈에 먼저 들어오니 자연스러운 오해입니다. 실제로는 절반이 불이 꺼진 뒤에 벌어집니다. 사후 갈래를 통째로 건너뛰면 팀은 같은 장애를 점점 빨리 끄는 데만 능숙해집니다. 한 해 동안 복구 시간이 두 시간에서 25분으로 줄었는데 장애 건수는 분기마다 같은 원인으로 늘어나는 상태가 그렇게 만들어집니다.

장애 건수를 0으로 만드는 것을 목표로 잡는 것도 자주 보이는 오해입니다. 사고가 없는 편이 좋으니 그렇게 적고 싶어집니다. 그런데 이 숫자는 두 가지 방법으로 0에 가까워집니다. 진짜로 안정된 경우와, 사고를 사고라고 부르지 않게 된 경우입니다. 뒤쪽이 더 쉽습니다. 건수가 평가에 걸리면 사람들은 애매한 것을 등급에 올리지 않고, 위험한 변경을 미루다 한꺼번에 내보내며, 20분쯤 멈춘 일은 조용히 넘깁니다. 그러면 기록에 남는 사고는 줄지만 고객이 겪는 사고는 그대로이고, 남지 않은 사고에서는 배울 것도 나오지 않습니다. 그래서 건수 자체를 목표로 두는 대신 복구까지 걸린 시간이나 같은 원인이 다시 나온 횟수처럼 숨기기 어려운 값을 봅니다.