변경 리드 타임

변경 리드 타임은 고친 코드가 실제 서비스에 올라가기까지 걸린 시간입니다. 재는 구간이 정해져 있습니다. 변경이 버전 관리에 커밋된 순간이 시작입니다. 프로덕션에 배포된 순간이 끝입니다.

상세

택배를 부치면 접수창구에 상자를 넘긴 순간부터 받는 사람 문 앞에 놓이는 순간까지 며칠이 걸렸는지를 셉니다. 무엇을 보낼지 고르고 상자에 담은 시간은 그 셈에 안 들어갑니다.

변경 리드 타임은 변경 하나가 버전 관리에 커밋된 상태에서 프로덕션에 배포된 상태로 가기까지 걸리는 시간입니다. 시작점과 끝점이 이 값의 전부입니다. 무엇을 고쳤는지, 몇 줄을 고쳤는지, 누가 고쳤는지는 이 값이 보지 않습니다.

이 값은 DORA(DevOps Research and Assessment)가 소프트웨어 배달 성능을 재는 데 쓰는 지표 가운데 하나입니다. DORA 는 지표를 두 갈래로 묶습니다. 변경 리드 타임은 처리량 쪽에 있습니다. 처리량은 일정한 기간 동안 얼마나 많은 변경이 시스템을 통과할 수 있는지를 재는 값입니다. 처리량이 높다는 것은 그 시스템이 더 많은 변경을 프로덕션 환경까지 밀어낼 수 있다는 뜻입니다. DORA 는 처리량을 재는 데 세 가지를 씁니다. 변경 리드 타임, 배포 빈도, 그리고 즉각 개입이 필요한 배포 실패에서 복구하는 데 걸리는 시간입니다.

배경

DORA 는 2014년 첫 연구에서 IT 성과가 조직의 성과와 이어지는지를 과학적으로 밝히려 했습니다. 그러려면 "IT 성과" 라는 것이 실제로 무엇을 뜻하는지부터 수치로 정의해야 했습니다. 재는 값이 없으면 이어지는지를 물을 수도 없기 때문입니다.

연구진은 네 변수로 시작했습니다. 배포 빈도, 변경 리드 타임, 평균 복구 시간(MTTR, Mean Time To Recover), 변경 실패율입니다. 그런데 그 첫해의 통계 분석에서 변경 실패율은 나머지 변수들과 유의한 상관을 보이지 않았습니다. IT 성과라는 하나의 잠재 구성개념을 이루지 못한 것입니다. 그래서 그해의 IT 성과 정의는 세 지표에 기댔습니다. 변경 리드 타임은 그 셋 안에 남았습니다.

뒤에 지표 구성이 한 번 크게 바뀝니다. DORA 연구진은 변경 실패율이 팀이 해야 하는 재작업의 양을 대신 나타내는 값 노릇을 한다고 봤습니다. 그것을 확인하려고 다섯 번째 지표인 배포 재작업률을 들였습니다. 이 재편이 2024년의 일입니다. 변경 리드 타임은 2014년의 세 지표에도, 지금의 다섯에도 남아 있습니다.

예시

GitLab

GitLab 은 이 값을 lead_time_for_changes 라는 이름으로 내놓습니다. DORA 지표 API(Application Programming Interface, 응용 프로그램 인터페이스)에서 metric 파라미터에 넣을 수 있는 값은 deployment_frequency, lead_time_for_changes, time_to_restore_service, change_failure_rate 넷이고 그중 하나입니다.

GitLab 문서가 적은 lead_time_for_changes 의 정의는 이렇습니다. 그 기간 동안 배포된 모든 머지 리퀘스트에 대해, 머지 리퀘스트가 병합된 시각과 그 커밋들이 배포된 시각 사이의 초를 잰 중앙값입니다. 값 하나가 변경 하나를 가리키는 것이 아닙니다. 여러 건을 늘어놓고 가운데 것을 집은 값입니다.

계산 구간도 문서가 못 박습니다. 머지 리퀘스트를 프로덕션까지 성공적으로 내보내는 데 걸린 초를 세되, 병합 버튼을 누른 시각부터 코드가 프로덕션에서 성공적으로 도는 시각까지입니다. 코딩 시간은 계산에 넣지 않습니다.

Four Keys

Google Cloud 의 fourkeys 는 이 지표들을 모아 보여주는 프로젝트입니다. fourkeys 문서는 변경 리드 타임을 커밋 하나가 프로덕션에 배포되기까지 걸린 시간의 중앙값이라고 적습니다.

값의 크기에 따라 색을 다르게 칠합니다.

색	변경 리드 타임
보라	하루 미만
초록	일주일 미만
노랑	일주일에서 한 달 사이
빨강	한 달에서 6개월 사이
빨강	6개월을 넘는 것 전부. "일 년" 으로 표시합니다

이 색 구간은 2019 State of DevOps Report 가 적은 엘리트·상위·중위·하위 수행자 구간을 대략 따른 것입니다.

경계

코드를 쓰기 시작한 순간부터 잰 시간도 변경 리드 타임인가. 아닙니다. 시작점은 변경이 버전 관리에 커밋된 순간입니다. 그 앞에 코드를 쓰며 보낸 시간은 이 값에 안 들어갑니다.

이름이 비슷한 값과도 갈립니다. 밸류 스트림 애널리틱스의 리드 타임은 이슈가 만들어진 때부터 이슈가 닫힌 때까지를 잽니다. GitLab 문서는 변경 리드 타임이 그것과 같지 않다고 못 박습니다.

다만 시작점은 재는 쪽에 따라 갈립니다. DORA 가 세운 계약은 커밋에서 프로덕션 배포까지입니다. GitLab 이 실제로 계산하는 구간은 병합 버튼을 누른 시각부터입니다. 코딩 시간은 계산에 넣지 않습니다. 커밋은 병합보다 앞에 놓이므로 두 구간의 시작점은 같은 자리가 아닙니다.

flowchart TD
    A["코드 작성"] --> B["커밋"] --> C["병합"] --> D["프로덕션 배포"]
    B -. "DORA 의 계약" .-> D
    C -. "GitLab 의 구현" .-> D

같은 경로 위에서 두 선이 다른 자리에서 시작해 같은 자리에서 끝납니다. DORA 의 정의는 커밋에서 셉니다. GitLab 의 구현은 병합에서 셉니다. 어느 쪽을 쓰든 코드를 쓰던 시간은 이 값 밖에 있습니다.

변경 리드 타임

상세

배경

예시

GitLab

Four Keys

경계

관련 항목

함께 소프트웨어 배달 성능을 재는 지표

값이 거치는 처리 단계

값을 실제로 계산해 내놓는 구현

값이 오르는 관측 도구

헷갈리는 이웃

값이 속하는 상위 분류