변경 실패율

배포를 무서워하는 팀에는 대개 규칙이 하나씩 있습니다. 금요일에는 내보내지 않는다, 밤 10시 이후에 올린다, 올리는 날은 두 명이 남아 있는다. 규칙 자체는 합리적입니다. 다만 그 규칙이 어느 정도의 위험에 대한 대비인지는 아무도 모릅니다.

페이지덱에서도 그랬습니다. 새 기능을 빨리 내보내자는 요구에 개발팀은 그러다 장애가 난다고 답했고, 요구한 쪽은 지난번에도 괜찮지 않았냐고 되물었습니다. 양쪽 다 기억에 기댄 주장이었습니다. 한쪽은 크게 터졌던 한 번을 기억하고 다른 쪽은 조용히 지나간 수십 번을 기억하니, 같은 분기를 두고도 결론이 반대로 났습니다.

변경 실패율은 그 논쟁에 분모를 붙인 숫자입니다. 장애가 몇 번 났는지가 아니라 몇 번 중 몇 번이었는지를 묻습니다. 한 분기에 장애가 세 번 났다는 사실만 놓으면 많아 보이지만, 그 분기에 배포가 200번이었다면 이야기가 달라집니다. 무섭다는 느낌을 비율로 바꾼 덕분에, 속도를 올리자는 요구와 안전하게 가자는 요구가 같은 표 위에서 만나게 됐습니다.

정해진 기간에 실패로 끝난 배포 수를 그 기간의 전체 배포 수로 나누고 100을 곱합니다. 4주 동안 80번 내보냈고 그중 6번이 문제를 일으켰다면 7.5퍼센트입니다.

계산은 세 단계입니다.

1. 분모를 정합니다. 운영 환경에 실제로 반영된 배포만 셉니다. 개발용 서버에 올린 것이나 코드만 넣고 기능은 꺼 둔 것은 사용자에게 닿지 않았으므로 빼고 셉니다.
2. 무엇을 실패로 볼지 정합니다. 여기가 가장 자주 흔들리는 자리입니다. 이전 버전으로 되돌리는 롤백만 셀지, 급한 문제만 고쳐 즉시 내보내는 핫픽스까지 셀지, 기능 스위치를 꺼서 막은 경우도 넣을지를 미리 적어 둡니다.
3. 나눕니다. 6을 80으로 나누면 0.075이고 7.5퍼센트입니다.

2번을 팀이 합의해 두지 않으면 분기마다 다른 잣대로 잰 값이 한 표에 섞입니다. 이번 분기는 롤백만 세서 4퍼센트, 다음 분기는 핫픽스까지 세서 11퍼센트가 나오면 세 배 가까이 나빠진 것처럼 보이지만 달라진 것은 세는 방법뿐입니다. 그래서 기준은 지표 옆에 한 줄로 적어 두고, 바꿀 때는 지난 분기 값까지 같은 기준으로 다시 계산합니다.

사용자 영향을 기준에 넣을지도 정해야 합니다. 새벽에 5분 동안 로그인이 안 됐는데 아무도 눈치채지 못했다면 실패인지가 갈립니다. 대개는 되돌리는 조치가 있었는지로 판정하는 편이 흔들림이 적습니다.

조사에서 잘하는 조직은 한 자릿수에서 15퍼센트 사이에 들어옵니다. 다만 이 값은 혼자 놓고 읽으면 거의 언제나 잘못 읽힙니다. 아무것도 내보내지 않는 팀의 변경 실패율은 0퍼센트이기 때문입니다.

그래서 이 지표는 나머지 셋과 한 묶음으로 놓입니다. 얼마나 자주 내보내는지를 보는 배포 빈도, 코드를 다 쓴 뒤 운영에 반영되기까지 걸린 시간인 변경 리드 타임, 그리고 장애가 난 뒤 서비스가 돌아오기까지 걸린 복구 시간입니다. 앞의 둘이 속도를, 변경 실패율과 복구 시간이 안정성을 맡습니다. 배포 빈도가 주 8회이면서 실패율이 6퍼센트인 팀과, 월 1회에 실패율이 0퍼센트인 팀 가운데 앞쪽이 낫습니다.

이 값을 실제로 내리는 장치는 대개 하나입니다. 코드 변경을 자동으로 검증하고 배포까지 잇는 CI/CD입니다. 나가기 전에 검사가 자동으로 돌면 사람이 놓치던 것이 걸러지고, 한 번에 나가는 변경의 덩치가 작아지면 터졌을 때 원인을 찾기도 쉬워집니다.

허용치를 미리 정해 두는 방법도 있습니다. 목표를 지키면서 써도 되는 실패의 여유분인 에러 버짓을 잡아 두고, 그 여유가 남아 있으면 새 기능을 계속 내보내고 다 쓰면 안정화에 시간을 돌리는 식입니다. 몇 퍼센트가 좋으냐는 질문을 이번 분기에 우리가 감당하기로 한 값이 얼마냐로 바꿔 놓는 장치입니다.

"이번 분기 변경 실패율 9퍼센트인데 절반이 결제 쪽입니다."

전체 값보다 그 값이 한곳에 몰려 있다는 사실이 중요하다는 말이고, 손볼 곳이 배포 과정이 아니라 특정 영역이라는 뜻입니다.

"지난달부터 핫픽스도 실패로 세기로 했어요. 그래서 숫자가 올라갔습니다."

지표가 나빠진 것이 아니라 세는 기준이 넓어진 것이라는 설명입니다.

"실패율은 괜찮은데 복구 시간이 두 시간이에요. 되돌리기가 안 되는 거죠."

터지는 빈도보다 터졌을 때 되돌릴 수단이 없는 쪽이 지금 문제라는 진단입니다.

페이지덱이 이 값을 처음 재 봤을 때는 12퍼센트였습니다. 태오가 3개월 치 배포 기록을 열어 실패로 분류한 건들을 하나씩 살펴보니, 여덟 건 중 다섯 건이 같은 모양이었습니다. 금요일 오후에 한 주 치 변경을 모아 한 번에 내보낸 배포였습니다.

그래서 고친 것은 지표가 아니라 순서였습니다. 변경이 준비되는 대로 그날그날 내보내도록 바꿨고, 검사를 통과하지 못하면 자동으로 막히게 했습니다. 두 분기 뒤 배포 빈도는 주 2회에서 주 8회로 올랐고 변경 실패율은 5퍼센트로 내려갔습니다. 한 번에 나가는 변경이 작아지니 터질 거리도 작아진 것입니다.

0에 가까울수록 좋다고 읽는 경우가 가장 많습니다. 실패라는 이름이 붙어 있으니 낮을수록 좋아 보입니다. 하지만 이 값은 분모가 있는 비율이고 분모를 줄이면 얼마든지 내려갑니다. 팀에 0을 요구하면 사람들은 배포를 미루고 변경을 모으기 시작하는데, 그러면 한 번에 나가는 덩치가 커져 실제 위험은 오히려 올라갑니다. 분기 내내 0퍼센트였다는 보고는 잘했다는 신호가 아니라 무엇을 내보내지 못하고 있는지 물어볼 신호입니다.

개인의 성적으로 읽는 것도 흔합니다. 누구의 배포가 터졌는지는 기록에 남아 있어서 세기도 쉽습니다. 그런데 배포가 실패하는 이유는 대개 사람이 아니라 그 사람이 지나온 과정에 있습니다. 검사가 자동으로 돌지 않았거나, 되돌릴 수단이 없었거나, 한 번에 나가는 변경이 너무 컸던 쪽입니다. 이 값을 개인에게 붙이면 사람들은 실패를 보고하지 않는 방향으로 움직이고, 작은 문제를 조용히 고친 뒤 기록에 남기지 않게 됩니다. 그때부터 숫자는 좋아지고 팀이 실제로 겪는 장애는 그대로입니다.