배포 빈도

배포가 한 달에 한 번 있는 행사이던 시절이 있었습니다. 날짜를 잡고, 그날까지 만든 것을 전부 모으고, 밤에 서버를 내렸다가 올렸습니다. 한 번 내보내는 데 사람 손이 많이 드니 자연히 모아서 한꺼번에 내보내게 됐고, 모아서 내보내니 한 번이 더 커졌습니다.

이 방식의 문제는 사고가 났을 때 드러납니다. 금요일 밤에 변경 서른 개를 한꺼번에 올렸는데 토요일 아침에 결제가 안 된다는 문의가 들어옵니다. 서른 개 중 무엇이 원인인지 아무도 모릅니다. 하나씩 빼 보는 데 반나절이 가고, 그러는 동안 나머지 스물아홉 개의 멀쩡한 변경도 사용자에게 닿지 못한 채 묶여 있습니다.

그래서 팀들은 배포를 더 잘게 나누는 쪽으로 움직였습니다. 한 번에 변경 하나만 나가면 문제가 생겨도 범인이 하나라 5분 만에 롤백할 수 있습니다. 배포 빈도는 그 변화가 실제로 일어났는지를 밖에서 확인하려고 세는 숫자입니다. 배포를 잘게 나누자는 말은 누구나 하지만, 지난달에 몇 번 내보냈는지를 세어 보면 말과 실제가 얼마나 벌어져 있는지가 바로 보입니다.

기간을 하나 정하고 그 기간에 운영 환경으로 나간 배포 횟수를 셉니다. 4주 동안 32번 내보냈으면 주당 8회이고, 한 달에 한 번 올리는 팀은 월 1회입니다.

세는 규칙은 세 가지입니다.

1. 운영 환경에 실제로 반영된 것만 셉니다. 개발용 서버나 내부 확인용 환경에 올린 것은 사용자에게 닿지 않았으므로 뺍니다.
2. 코드가 나갔으면 한 번으로 셉니다. 피처 플래그로 기능을 꺼 둔 채 코드만 올린 경우가 애매한데, 그 코드가 운영 서버에서 돌기 시작했다면 배포로 셉니다. 기능이 켜지는 시점은 배포와 별개의 사건입니다.
3. 되돌린 것도 한 번으로 셉니다. 롤백은 운영 환경을 바꾼 행위이고, 되돌린 횟수는 변경 실패율이 따로 셉니다.

세는 방법 자체는 어렵지 않아서 배포 기록을 그대로 세면 나옵니다. 어려운 것은 무엇을 한 번으로 볼지 팀 안에서 같은 기준을 쓰는 일입니다. 서비스가 셋으로 나뉘어 있고 셋이 각각 배포되는 팀이라면, 세 번을 세 번으로 셀지 한 묶음으로 볼지에 따라 값이 세 배 차이 납니다. 기준을 적어 두지 않으면 분기마다 다른 잣대로 잰 값이 한 표에 섞입니다.

표기는 보통 주당 횟수나 하루 횟수로 합니다. 월 1회짜리 팀과 하루 다섯 번짜리 팀을 같은 단위로 놓으면 한쪽이 소수점 아래로 내려가 읽기 어려워지기 때문입니다.

절대값을 외우기보다 지난 분기의 우리 팀과 견주는 쪽이 쓸모 있습니다. 조사에서 상위권 조직은 하루에도 여러 번 내보내고 아래쪽은 몇 달에 한 번 내보내지만, 구간을 가르는 숫자는 조사 회차마다 조금씩 바뀝니다. 월 1회에서 주 1회가 된 팀은 상위권이 아니어도 분명히 나아진 팀입니다.

이 값만 따로 보면 안 된다는 조건이 붙습니다. 배포 빈도는 복구 시간과 변경 실패율이 나란히 있을 때만 뜻이 생깁니다. 빈도가 주 2회에서 주 20회로 올랐는데 실패율이 5퍼센트에서 30퍼센트가 됐다면 나아진 게 아니라 검증을 건너뛴 것입니다. 반대로 빈도가 그대로인데 실패율만 0에 가깝다면 아무것도 안 내보내는 쪽으로 몸을 사린 상태일 수 있습니다.

값이 낮을 때 손봐야 할 곳은 대체로 정해져 있습니다. 한 번 내보내는 데 사람 손이 몇 번 드는지를 세어 보면 됩니다. 배포에 수동 승인 세 단계와 한 시간짜리 수동 점검이 걸려 있으면 아무리 의지가 있어도 하루에 여러 번은 못 합니다. CI/CD는 코드 변경을 자동으로 검사하고 문제가 없으면 서버까지 올리는 체계인데, 이 체계에서 사람이 손으로 하던 단계를 하나씩 없앨 때마다 값이 따라 올라갑니다. 숫자를 목표로 걸지 않고 병목을 없애는 쪽이 이 지표를 쓰는 방법입니다.

"지난달 배포 빈도가 주 1회예요. 배포 절차에 수동 승인이 세 단계 있어서 그렇습니다."

숫자를 설명이 아니라 병목을 찾는 단서로 쓴 말입니다.

"배포 빈도를 올리자고 목표를 걸진 맙시다. 빈 배포로 숫자만 올릴 수 있어요."

지표를 목표로 바꾸면 재는 기능을 잃는다는 지적입니다.

"이번 분기에 빈도가 두 배가 됐는데 실패율은 그대로예요. 이건 제대로 올라간 겁니다."

짝이 되는 안정성 지표와 함께 읽고 판정했다는 뜻입니다.

페이지덱이 이 값을 처음 재 본 건 한 달에 한 번 배포하던 시절이었습니다. 월 1회, 그러니까 값이 1이었습니다. 태오가 배포 한 번에 드는 단계를 적어 보니 열한 개였고 그중 일곱 개가 사람이 손으로 하는 일이었습니다. 테스트를 직접 돌려 보고, 변경 목록을 문서로 정리하고, 승인을 받고, 서버에 접속해 명령을 치는 식이었습니다.

그 일곱 개를 두 분기에 걸쳐 하나씩 자동으로 바꿨습니다. 특별한 계획이 있었던 건 아니고 가장 손이 많이 가는 단계부터 없앴습니다. 지금 페이지덱의 배포 빈도는 주에 여덟 번쯤이고, 같은 기간에 변경 실패율은 오르지 않았습니다. 규원이 이사회 자료에 이 두 숫자를 나란히 넣은 것도 그래서였습니다. 하나만 넣으면 빨라졌다는 말이 되지만 둘을 같이 넣으면 빨라지면서도 덜 깨졌다는 말이 됩니다.

자주 내보낼수록 불안정해진다고 읽는 경우가 많습니다. 손대는 횟수가 늘면 사고 날 확률도 는다는 게 상식이니 자연스러운 생각입니다. 실제로는 반대에 가깝습니다. 한 번에 나가는 변경이 작아지니 문제가 생겨도 원인이 하나로 좁혀지고, 되돌리기도 쉬워집니다. 서른 개를 한꺼번에 올린 팀은 사고가 나면 반나절을 쓰고, 하나씩 올린 팀은 5분 만에 이전 상태로 돌아갑니다. 이 오해를 그대로 두면 팀은 배포를 더 모아서 내보내는 쪽으로 움직이고, 그러면 한 번의 사고가 더 커집니다.

숫자 자체를 목표로 삼는 것도 흔합니다. 올리기 쉬운 값처럼 보이니 분기 목표로 걸고 싶어집니다. 하지만 아무것도 바꾸지 않는 빈 배포를 하루에 열 번 올려도 값은 올라갑니다. 목표를 받은 팀은 대개 변경 하나를 셋으로 쪼개 세 번에 나눠 내보내는 쪽으로 움직이고, 반년 뒤에는 값만 세 배가 된 채 사용자가 받는 것은 그대로입니다. 올라가야 할 것은 숫자가 아니라 변경이 사용자에게 닿는 속도이고, 그건 네 지표를 함께 놓아야 보입니다.