심각도

결함 목록이 쌓이면 무엇을 먼저 고칠지 정해야 합니다. 그런데 결함을 적어 올리는 사람은 대개 자기가 찾은 것이 가장 급하다고 느낍니다. 그래서 목록에는 버그, 즉 의도와 다르게 도는 결함이 팔십 건 올라와 있고 여든 건 모두 "빨리 확인 부탁드립니다" 가 붙어 있는 상태가 됩니다.

이런 목록에서는 결제가 안 되는 문제와 문구 오타가 같은 줄에 놓입니다. 고치는 사람은 올라온 순서대로 손을 대고, 열두 번째 줄의 결제 실패는 사흘 뒤에 발견됩니다. 그 사흘 동안 유료 전환을 시도한 사람들은 그냥 나갔습니다.

회의도 같은 자리에서 막혔습니다. 급하다는 말과 나중에 해도 된다는 말이 맞붙으면 판정 근거가 목소리 크기밖에 남지 않습니다. 세일즈가 방금 통화한 고객의 문제를 가져오고 개발자가 고치기 쉬운 것을 고르면, 매출이 막히는 결함은 둘 사이에서 밀립니다.

심각도는 이 판정을 사람에서 기준으로 옮긴 값입니다. 결함이 무엇을 얼마나 못 쓰게 만드는지만 보고 등급을 붙이고, 그 등급이 누가 언제 대응할지를 정합니다.

등급은 두 가지만 보고 정합니다. 영향을 받는 사용자의 범위와, 그 사용자가 하려던 일이 완전히 막혔는지 아니면 다른 길이 있는지입니다. 고치는 데 며칠이 걸릴지, 누가 만든 기능인지, 누가 신고했는지는 보지 않습니다.

네 단계로 두는 경우가 가장 흔합니다.

1. S1 — 서비스가 전체적으로 멈추거나 데이터가 사라지거나 돈과 보안이 걸린 경우입니다. 전 사용자가 로그인을 못 하거나 결제가 두 번 빠져나가는 상황입니다.
2. S2 — 핵심 기능이 여러 사용자에게 막히지만 다른 길이 있는 경우입니다. 문서 공유가 특정 브라우저에서만 안 되고, 다른 브라우저로는 되는 상황입니다.
3. S3 — 불편하지만 하려던 일은 끝낼 수 있는 경우입니다. 목록 정렬이 최신순으로 안 잡히거나 알림이 몇 분 늦게 오는 정도입니다.
4. S4 — 기능에는 영향이 없고 눈에 거슬리는 경우입니다. 글자가 한 칸 어긋나거나 문구에 오타가 있는 상태입니다.

판정에서 실제로 어려운 것은 영향 범위라서 짐작 대신 숫자를 봅니다. 특정 브라우저에서만 생기는 문제라면 그 브라우저를 쓰는 사용자가 2퍼센트인지 40퍼센트인지에 따라 같은 결함이 S3 과 S2 로 갈립니다.

등급은 재현 절차, 즉 그 결함을 다시 일으키는 순서와 함께 적어 둡니다. 순서가 없으면 고치는 사람이 상황을 되살리는 데 먼저 한 시간을 쓰고, 영향 범위도 확인할 수 없어서 등급 자체가 흔들립니다.

갈라 두어야 할 것이 하나 더 있습니다. 심각도는 피해의 크기이고 우선순위는 언제 고칠지 정한 순서입니다. 이미 벌어진 인시던트, 즉 서비스에 영향을 준 사고에서는 심각도가 곧 대응 순서가 되지만, 아직 나가지 않은 기능의 결함은 사업 사정이 순서를 바꿉니다.

같은 값이 네 자리에서 다르게 쓰입니다.

1. 대응 속도 결정 — 장애 대응에서 등급이 곧 절차입니다. S1 이면 온콜 당번을 새벽에도 즉시 호출하고 핫픽스로 그날 배포합니다. S3 이면 다음 주기 작업 목록에 넣습니다.
2. 출시 판정 — 품질 보증 단계에서 내보낼지 말지의 기준으로 씁니다. S1 과 S2 가 0건이면 내보내고 S3 이하는 남겨 둔 채 낸다는 식으로 정해 두면, 출시 직전마다 "이 정도면 나가도 되나" 를 다시 다투지 않습니다.
3. 고객 약속 — 기업 고객과 맺는 계약서에는 등급별 응답 시간이 들어갑니다. 1등급은 1시간 안에 연락하고 4시간 안에 상황을 알린다는 조항이 흔해서, 등급을 어떻게 매기느냐가 계약 이행에 직접 걸립니다.
4. 품질 추세 확인 — 등급별 건수를 달마다 세어 봅니다. 전체 건수가 줄었는데 S1 이 늘었다면 품질이 나빠진 것이고, 반대면 나아진 것입니다. 전체 건수만 세면 오타 스무 개가 결제 장애 하나를 가립니다.

"이건 S1 입니다. 지금 가입하는 사용자 전원이 로그인을 못 해요."

영향 범위가 전체이고 우회 수단이 없으니 즉시 대응 절차로 넘기자는 말입니다.

"심각도는 S3 인데 우선순위는 올릴게요. 다음 주 기업 고객 시연에 나오는 화면이라서요."

피해 크기는 작지만 사업 사정 때문에 순서를 앞당긴다는 뜻입니다.

"영향 범위를 모르니 일단 S2 로 두고 확인되면 내립시다."

판단 근거가 아직 없을 때 높은 쪽에 두고 시작하는 관행입니다.

페이지덱은 결함을 올릴 때 등급 칸을 반드시 채우게 해 두었습니다. 태오가 아침에 보는 것은 전체 목록이 아니라 S1 과 S2 만 걸러 낸 화면입니다. 지난달에는 특정 조직 계정에서만 문서 목록이 비어 보이는 결함이 올라왔는데, 처음에는 한 고객사 이야기라 S3 으로 적혔습니다. 확인해 보니 같은 설정을 쓰는 조직이 전체 유료 팀의 18퍼센트였고, 그 숫자를 보고 S2 로 올려 그날 오후에 고쳤습니다.

수아는 등급을 다른 쪽으로 씁니다. 고객사 문의가 오면 그 문제가 어느 등급으로 등록됐는지를 보고 언제까지 답을 주겠다고 말합니다.

심각도와 우선순위를 같은 값으로 쓰는 경우가 가장 많습니다. 심각한 것을 먼저 고치는 게 당연해 보이니 두 칸을 따로 둘 이유가 없어 보입니다. 하지만 두 값이 답하는 질문이 다릅니다. 심각도는 지금 무슨 일이 벌어지고 있는지에 대한 사실이고, 우선순위는 그래서 무엇부터 할지에 대한 결정입니다. 하나로 합치면 결정이 사실을 덮습니다. 다음 주 시연에 나올 화면의 오타를 급히 고치려고 등급을 S1 으로 올려 적으면, 몇 달 뒤 등급별 건수를 세어 볼 때 그달에 치명적 장애가 세 건 있었던 것처럼 남습니다.

등급을 높게 적으면 빨리 고쳐진다고 생각하는 것도 같은 문제로 이어집니다. 실제로 한동안은 통합니다. 그러다 모두가 같은 방법을 쓰면 목록의 절반이 S1 이 되고, 그 시점에 등급은 순서를 정하는 기능을 잃습니다. 남는 것은 등급이 없던 시절과 같은 상태이고, 이번에는 칸이 채워져 있어서 문제를 알아채기까지 더 오래 걸립니다. 그래서 등급은 신고자가 아니라 합의된 기준표가 정하게 두고, 판정이 어긋나 보이면 기준표의 어느 줄에 해당하는지를 따집니다.