변경 리드 타임

개발이 끝났다는 말과 사용자가 쓸 수 있다는 말 사이에는 아무도 세지 않던 구간이 있었습니다. 기능이 완성됐다는 보고를 받고 몇 주가 지나도 화면에는 아무 변화가 없는 일이 예사였습니다. 그 사이에 무슨 일이 있었는지 물으면 답은 늘 비슷했습니다. 리뷰어가 바빴고, 테스트 환경이 막혀 있었고, 정기 배포일이 다음 주였습니다.

지현이 "그 기능 지난주에 끝났다면서요" 하고 물으면 태오는 "코드는요. 배포는 월말 정기 배포에 들어갑니다" 하고 답했습니다. 둘 다 맞는 말이었습니다. 개발 일정은 지켰는데 고객은 한 달을 더 기다렸고, 무엇이 잘못됐는지 짚을 숫자가 없었습니다.

변경 리드 타임은 그 구간에 이름과 숫자를 붙인 것입니다. 코드를 쓰는 속도는 이미 여러 방식으로 관리되고 있었지만, 다 쓴 코드가 사용자에게 닿기까지 어디에서 며칠을 보냈는지는 아무도 기록하지 않았습니다. 이 값을 재기 시작하면 대개 기다린 시간이 대부분이라는 사실이 먼저 드러납니다.

한 변경이 코드 저장소에 들어간 시각과 그 변경이 운영 환경에 반영된 시각의 차이를 건마다 재고, 모아서 중앙값을 읽습니다.

시작점을 어디로 잡을지는 팀이 정합니다. 흔히 쓰는 기준은 변경을 본류에 합쳐 달라고 올린 요청, 즉 풀 리퀘스트가 합쳐진 시각입니다. 첫 커밋 시각을 시작점으로 잡는 팀도 있는데, 그러면 코드를 쓰는 시간까지 값에 들어가 배포 과정만 보려던 목적이 흐려집니다. 끝점은 운영 환경 반영 시각 하나로 고정합니다. 테스트 서버에 올라간 것이나 기능을 꺼 둔 채 코드만 들어간 것은 사용자에게 닿지 않았으므로 아직 끝나지 않은 겁니다.

계산은 세 단계입니다.

1. 최근 배포들에 실제로 포함된 변경 목록을 뽑습니다. 배포 도구나 저장소 기록에서 어떤 변경이 어느 배포에 실렸는지를 확인할 수 있습니다.
2. 변경마다 합쳐진 시각과 그 변경이 실린 배포의 완료 시각의 차를 구합니다.
3. 최근 서른 건 정도를 모아 중앙값을 읽습니다. 평균을 쓰면 담당자 휴가로 3주를 끈 한 건이 전체를 끌어올려 실제 상태와 먼 숫자가 나옵니다.

값 하나만 보면 어디를 고쳐야 할지 알 수 없으니 구간을 잘라 봅니다. 합침에서 리뷰 통과까지, 리뷰 통과에서 테스트 완료까지, 테스트 완료에서 배포까지를 따로 재는 식입니다. 페이지덱이 이 값을 처음 쟀을 때 중앙값은 6일이었고, 그중 4일이 코드 리뷰를 기다린 시간이었습니다. 개발자를 더 뽑아도 줄지 않는 종류의 6일이었던 셈입니다.

조사에서 상위권 조직은 하루를 넘기지 않고, 아래쪽은 같은 값이 몇 주에서 몇 달 단위로 나옵니다. 다만 구간 기준은 조사 회차마다 바뀌므로 특정 숫자를 외우기보다 우리 팀의 지난 분기와 이번 분기를 견주는 쪽이 쓸모 있습니다. 6일이 4일이 됐는지가 하루라는 기준선보다 먼저 볼 값입니다.

무엇을 고칠지는 구간별 분해가 알려 줍니다. 가장 긴 구간은 대개 사람이 손으로 하는 단계에 붙어 있습니다. 리뷰어가 한 명뿐이라 그 사람의 일정이 전체 속도를 정하고 있거나, 배포하려면 회의에서 승인을 받아야 하거나, 정기 배포일이 주에 한 번이라 화요일에 끝난 변경이 다음 월요일까지 기다리는 식입니다. 이런 단계를 하나씩 없애면 값이 따라 내려옵니다. CI/CD, 즉 코드 변경을 자동으로 검사하고 문제가 없으면 서버까지 올리는 체계를 두는 것이 가장 크게 듣는 조치입니다.

한 번에 내보내는 변경의 크기도 값을 좌우합니다. 3주치를 모아 한 번에 내보내면 먼저 끝난 변경은 나머지가 완성될 때까지 기다리고, 문제가 생겼을 때 어느 변경 탓인지 가려내는 데 또 며칠이 듭니다. 작게 자주 내보내면 두 시간이 함께 줄어듭니다.

이 값만 목표로 걸면 검증 단계를 건너뛰는 쪽으로 움직이기 쉽습니다. 그래서 변경 실패율, 곧 내보낸 배포 중 장애로 이어진 비율을 짝으로 놓고 함께 봅니다. 한쪽이 내려갈 때 다른 쪽이 올라가면 시간을 줄인 게 아니라 위험을 옮긴 것입니다.

"변경 리드 타임 중앙값이 엿새인데 그중 나흘이 리뷰 대기예요."

고칠 곳이 개발 속도가 아니라 리뷰가 밀리는 구간이라는 뜻입니다.

"이번 분기 목표는 이 값을 하루 안으로 줄이는 겁니다. 월말 정기 배포부터 없애죠."

정해진 날짜에 모아 내보내는 방식이 값을 끌어올리는 가장 큰 원인이라는 진단입니다.

"그건 개발 기간이에요. 코드 다 쓴 다음부터 세야 맞습니다."

시작점을 잘못 잡아 다른 구간을 재고 있다는 지적입니다.

페이지덱에서는 태오가 분기마다 이 값을 구간별로 잘라 정리합니다. 처음 쟀을 때는 리뷰 대기가 나흘이라 리뷰어를 두 명으로 늘리고 하루가 지나면 알림이 가게 했더니 중앙값이 엿새에서 사흘로 내려갔습니다. 다음 분기에는 월말 정기 배포를 없애고 준비된 변경을 그때그때 내보내는 쪽으로 바꿔 하루 반까지 줄였습니다.

지현은 이 숫자를 일정 대화에 씁니다. 기능이 언제 사용자에게 닿느냐는 질문에 개발이 끝나는 날짜만으로는 답할 수 없기 때문입니다. 개발 완료 예정일에 이 값을 더해 전하는 쪽이 실제와 가깝습니다.

시간을 줄이면 품질이 나빠진다고 보는 경우가 가장 많습니다. 급하게 내보내면 사고가 난다는 경험이 있으니 그렇게 읽기 쉽습니다. 하지만 이 값이 긴 팀에서 줄어드는 대상은 검증이 아니라 기다림입니다. 리뷰를 기다린 나흘을 하루로 줄이는 것은 리뷰를 생략하는 것과 다릅니다. 오히려 3주치를 모아 내보내던 팀이 매일 조금씩 내보내기 시작하면 한 번에 나가는 변경이 작아져 문제가 생겼을 때 원인을 찾기 쉬워집니다. 이 오해를 그대로 두면 팀은 안전을 이유로 정기 배포일을 지키고, 그 결과 한 번에 나가는 덩어리가 계속 커집니다.

도구를 들이면 저절로 줄어든다고 보는 것도 흔합니다. 자동화로 푸는 문제처럼 보이기 때문입니다. 그런데 자동 배포 체계를 갖춘 뒤에도 값이 그대로인 팀이 있습니다. 배포 자체는 5분 만에 끝나는데 그 앞에 승인 회의가 주 1회로 남아 있으면 기다리는 날짜는 바뀌지 않습니다. 구간을 잘라 보지 않고 도구부터 들이면 이런 단계가 그대로 남습니다.