2.6 사이클 타임과 그 구성 요소

개요 및 동기

사이클 타임은 변경의 플로우 타임(주제 2.4)을 그 구성 엔지니어링 단계, 즉 코딩 시간, 리뷰 시간, 테스트 시간, 배포 시간으로 내부적으로 분해한 것이며, 때로는 픽업 시간(누군가 작업을 시작하기 전에 변경이 얼마나 오래 기다리는지)과 활성 시간(누군가 그렇게 할 때 얼마나 걸리는지)으로 더 나뉜다. 플로우 타임이 전체 가치 흐름을 통해 변경이 처음부터 끝까지 얼마나 걸리는지에 대한 단일한 수치를 주는 반면, 사이클 타임은 그것이 엔지니어링에 도달한 후 그 시간이 실제로 어디로 가는지 말해 주며, 이는 주제 2.4가 그 자체의 요약 수치 아래에 자리한다고 약속한 진단 계층이다.

이 구분이 중요한 이유는 “리드 타임이 너무 길다”는 그 자체로는 실행 가능하지 않기 때문이다. 리드 타임이 코딩 시간에 지배되는 팀은 리드 타임이 사흘짜리 리뷰 대기열에 지배되는 팀과 다른 개입이 필요하며, 그 팀은 또한 불안정하고 느린 테스트 스위트에 대부분의 시간을 잃는 팀과 다른 개입이 필요하다. 사이클 타임 분해 없이는 팀은 병목을 추측하는 경향이 있으며, 그 추측은 충분히 자주 틀려서 잘못된 단계를 고치는 것이 실제 노력을 낭비하는 동안 진짜 제약은 손대지 않은 채 남는다.

대규모 팀에게 사이클 타임 분해는 조직 전체의 리드 타임 퇴보를 미스터리에서 구체적이고 다룰 수 있는 문제로 바꾸는 것이다. 수십 개의 팀이 공통 인프라를 공유할 때, 공유된 리뷰 병목이나 공유된 느린 CI 파이프라인이 모든 팀의 리드 타임을 동일하게 끌어내리고 있을 수 있으며, 각 팀이 독립적으로 자신만의 지역적 설명을 추측하는 대신 오직 팀 간 사이클 타임 비교만이 그 공유된 근본 원인을 드러낸다.

핵심 원칙

사이클 타임은 리드 타임을 설명하며, 그것을 대체하지 않는다. 사이클 타임을 진단으로, 리드 타임을 요약으로 삼아 둘 다 함께 보고하라.
대기 시간은 보통 활성 시간을 지배한다. 소프트웨어 전달에서 대부분의 지연은 활성 노력이 아니라 대기열에서 유휴 상태로 있는 작업에서 온다(주제 2.5가 플로우 효율을 통해 이를 직접 다룬다).
해결책을 제안하기 전에 단계별로 분해하라. 잘못된 단계를 겨냥한 해결책은 노력을 낭비하고, 진짜 병목이 다른 곳에 있었을 때 “더 빠르게 일하라”는 요청을 받은 팀의 사기를 떨어뜨릴 수 있다.
여러 팀에 걸친 공유된 병목은 플랫폼 투자 기회다, 단지 일련의 개별 팀 문제가 아니라.
사이클 타임 데이터는 플로우 타임과 동일한 게임 위험에 노출된다(주제 2.4): 수치를 치장하기 위해 조용히 이동하는 단계 경계를 경계하라.

권장 사항

모든 단계 경계를 명시적으로 계측하라

변경의 여정을 명확하고 계측 가능한 경계를 가진 이름 붙여진 단계로 나누어라: 코딩(첫 커밋부터 풀 리퀘스트 열림까지), 픽업(풀 리퀘스트 열림부터 첫 리뷰까지), 리뷰(첫 리뷰부터 승인까지), 그리고 배포(승인부터 프로덕션까지). 자가 보고된 단계 추적이 아니라 버전 관리와 CI/CD 사건으로부터 자동으로 모든 전환에 대한 타임스탬프를 포착하며, 주제 1.5의 자가 보고보다 계측을 우선하는 것과 동일한 원칙을 적용하라.

각 단계 안에서 대기 시간을 활성 시간으로부터 분리하라

예를 들어 리뷰 안에서, 풀 리퀘스트가 리뷰어가 시작하기를 기다리며 손대지 않은 채 앉아 있는 시간(대기 시간)을 활성 리뷰 대화가 일단 시작되면 걸리는 시간(활성 시간)으로부터 구별하라. 이 구분은 보통 지배적인 비용이 노력이 아니라 대기열이라는 것을 드러내며, 이는 리뷰 대화 자체를 더 빠르게 만드는 것을 겨냥한 해결책과는 매우 다른 해결책(더 많은 리뷰어 역량, 더 나은 알림, 리뷰할 더 작은 풀 리퀘스트)을 가리킨다.

팀별로 진단하기 전에 공유된 병목을 찾아보라

여러 팀이 같은 단계를 지배적인 지연으로 보여 줄 때, 즉 느린 공유 CI 파이프라인, 과부하된 공유 리뷰 풀, 드문 공유 릴리스 트레인은, 그 공유된 원인은 일련의 무관한 지역적 문제가 아니라 플랫폼 수준의 투자 기회다. 각 팀의 병목이 그 팀에 고유하다고 가정하기 전에 특별히 이 패턴을 찾기 위해 팀 전반에 걸쳐 사이클 타임 데이터를 집계하라.

사이클 타임을 사용해 현실적이고 단계별로 구체적인 개선 목표를 설정하라

팀에게 어디에 집중해야 할지에 대한 아무런 지침도 주지 않는 단일한 “리드 타임을 20% 줄여라”는 목표 대신, 사이클 타임 분해를 사용해 단계별로 구체적인 목표를 설정하라: “중앙값 리뷰 대기 시간을 이틀에서 네 시간으로 줄여라.” 구체적이고 단계를 겨냥한 목표는 팀이 행동에 옮기기 더 쉬우면서 다른 곳의 무관한 변화가 아니라 실제 프로세스 변화를 통해 실제로 달성되었는지 검증하기도 더 쉽다.

단계 경계 게임을 경계하라

플로우 타임의 시작과 끝 지점이 드리프트할 수 있는 것처럼(주제 2.4), 개별 사이클 타임 단계 경계도 아무런 실제 개선 없이 특정 단계의 수치를 치장하는 방식으로 이동할 수 있다. 예를 들어, 리뷰어가 실제로 변경을 읽기 시작할 때가 아니라 리뷰어가 할당되는 순간 리뷰가 “시작됨”으로 표시하는 것이다. 문서화된 정의에 비추어 단계 경계 계측을 주기적으로 감사하라.

트레이드오프: 장단점

접근법	장점	단점
거친 사이클 타임 (두세 단계)	계측하고 설명하기 단순함	행동에 옮길 만큼 정밀하게 실제 병목을 짚어 내지 못할 수 있음
세밀한 사이클 타임 (많은 단계, 대기 대 활성 분할)	정밀한 진단, 실행 가능한 단계별 목표	더 많은 계측 노력; 유지하고 설명해야 할 더 많은 수치
팀별 사이클 타임 검토	각 팀의 실제 워크플로에 맞춤	비슷한 지역적 수치 뒤에 숨어 있는 공유된 팀 간 병목을 놓칠 수 있음
팀 간 집계된 사이클 타임 검토	공유된 플랫폼 수준의 병목을 드러냄	의미 있으려면 팀 전반에 걸쳐 표준화된 단계 정의가 필요함

핵심 긴장은 진단 정밀도 대 계측 비용이다. 더 세밀한 사이클 타임 추적은 더 실행 가능한 진단을 주지만 구축하고 유지하는 데 더 많은 비용이 들고, 팀이 이해하고 신뢰해야 할 더 많은 수치를 더한다. 거칠게(코딩, 리뷰, 배포) 시작하고, 특정 단계가 추가적인 계측 투자를 할 가치가 있는 진정하고 반복되는 병목으로 확인된 후에만 더 미세한 분할, 특정 단계 내 대기 대 활성 시간을 추가함으로써 이 긴장을 해결하라.

팀과 논의할 질문

오늘 리드 타임이 퇴보했다면, 우리는 추측이 아니라 데이터를 사용해 한 시간 안에 어떤 특정 단계가 책임이 있었는지 말할 수 있을까? 이것은 당신의 사이클 타임 계측이 실제로 그 진단적 목적에 봉사하고 있는지에 대한 핵심 시험이다. 정직한 답이 아니오라면, 그 간극은 다음 퇴보가 일어나기 전에 메울 가치가 있다.
우리의 지배적인 병목 단계 안에서, 지연 중 얼마나 많은 부분이 대기 시간이고 얼마나 많은 부분이 활성 시간인가? 대부분의 팀은 확인하기 전에 활성 노력이 제약이라고 가정하지만, 보통 대기열이 더 큰 비용이다. 가장 느린 단계에 대한 실제 분할을 가져와 그 가정이 성립하는지 확인하라.
여러 팀이 같은 지배적인 병목 단계를 공유하며, 이는 팀 수준이 아니라 플랫폼 수준의 해결책을 시사하는가? 팀 전반에 걸쳐 사이클 타임 데이터를 집계하고, 모든 팀의 느림이 지역적으로 야기되었다고 가정하기 전에 명시적으로 이 패턴을 찾아보라.
우리는 단계별로 구체적인 개선 목표를 설정했는가, 아니면 어디에 집중할지에 대한 아무런 지침도 없는 단일한 전체 리드 타임 목표만 있는가? 막연한 목표는 팀이 어디에 노력을 투자할지 추측하게 만들고, 단계별로 구체적인 목표는 그렇지 않다. 당신의 현재 목표를 이 구분에 비추어 확인하라.
우리의 계측에서 어떤 사이클 타임 단계 경계라도 시간이 지나며 문서화된 정의로부터 드리프트한 적이 있는가? 단계 경계는 플로우 타임 자체와 동일한 정의상의 드리프트에 노출된다(주제 2.4). 서면 정의에 비추어 최근 단계 전환 사건의 표본을 감사하라.
리뷰가 무거운 문화와 신뢰가 무거운 문화는 우리의 사이클 타임 데이터에서 어떻게 다르게 나타나는가? 매우 철저하고 다단계인 리뷰를 가진 팀은 단일 승인 병합을 신뢰하는 팀보다 더 긴 리뷰 단계 시간을 보일 것이다. 당신의 현재 균형이 의도적인 선택을 반영하는지 검토되지 않은 기본값을 반영하는지 논의하라.

분야별 관점

스타트업. 절차가 최소한이기 때문에 사이클 타임은 보통 리뷰나 배포 단계가 아니라 코딩 시간에 지배된다. 팀이 소수의 엔지니어를 넘어 성장함에 따라, 특별히 리뷰 대기 시간을 지켜보기 시작하라. 더 많은 사람들의 작업이 더 적은 이용 가능한 리뷰어를 거쳐야 함에 따라 이것이 보통 느려지는 첫 번째 단계이기 때문이다.

중소기업. 기본적인 버전 관리 플랫폼 분석은 보통 맞춤형 계측 없이도 충분한 단계 수준 타이밍(첫 리뷰까지의 시간, 병합까지의 시간)을 노출한다. 리뷰 단계에 먼저 집중하라. 그것이 가장 흔한 초기 병목이며 리뷰어 순환 같은 작은 프로세스 변화로 고치기 가장 쉽기 때문이다.

엔터프라이즈. 수십 개 팀에 걸친 공유된 병목은 흔하며 찾기에 레버리지가 높다: 단일한 과부하된 공유 CI 대기열이나 의무적인 중앙 리뷰 단계가 조직 전체의 리드 타임을 조용히 축내고 있을 수 있다. 각 팀이 독립적으로 진단하게 두는 대신 이러한 공유된 제약을 드러내기 위해 특별히 팀 간 사이클 타임 집계에 투자하라.

정부. 사이클 타임 데이터는 회의적인 이해관계자에게 프로세스 현대화를 정당화하기 위한 강력하고 구체적인 도구인데, “단일한 병목 승인 역할 때문에 리뷰 대기 시간이 평균 나흘이다”는 추상적인 “우리 프로세스는 느리다”는 주장보다 투자에 대해 훨씬 더 설득력 있고 구체적인 사례이기 때문이다.

사례

엔터프라이즈. 한 클라우드 인프라 회사의 엔지니어링 리더십은 거의 모든 팀에 걸쳐 동시에 리드 타임이 기어오르고 있다는 것을 알아챘다. 팀 간 사이클 타임 집계는 활성 리뷰 시간이 아니라 리뷰 대기 시간이 지배적이고 공유된 원인이라는 것을 드러냈다: 작고 중앙화된 보안 리뷰 팀이 그들의 승인을 필요로 하는 팀의 수가 그 팀 자체보다 더 빠르게 성장하면서 병목이 되어 버렸다. 개별 팀에게 어떻게든 더 빠르게 코딩하거나 테스트하도록 요청하는 대신 더 넓은 보안 인증 리뷰어 풀을 확장하고 훈련시키는 것이 공유된 병목을 해결했고 한 분기 안에 전반적으로 리드 타임을 다시 낮췄다.

정부. 한 주 정부의 디지털 서비스 팀은 리드 타임을 줄이라는 압박을 받았고, 처음에는 엔지니어에게 더 빠르게 일하라고 요청함으로써 대응했는데, 이는 자연스럽지만 결국 도움이 되지 않는 본능이었다. 사이클 타임 분해는 활성 코딩 시간이 연도별로 거의 바뀌지 않았다는 것을 보여 주었다. 퇴보의 거의 전부는 18개월 전 준수 조치로 도입된 의무적인 아키텍처 리뷰 단계에서 자라나는 대기열에서 왔다. 팀은 그 리뷰를 낮은 위험 변경에 대해 더 가볍고 위험 등급별로 나뉜 프로세스로 재설계하여, 진정으로 높은 위험의 변경에 대해서는 완전한 리뷰 엄격함을 유지하면서 리뷰 대기 시간을 상당히 줄였다.

비즈니스 사례: 동기, ROI, TCO

사이클 타임 분해의 수익은 목표를 겨냥한 효과적인 투자다: 정확히 어떤 단계가 병목인지 아는 조직은 무언가 도움이 되기를 바라며 전체 프로세스에 걸쳐 노력을 얇게 펼치는 대신 그 특정 단계를 고칠 수 있다. 위의 보안 리뷰 사례가 전형적이다: 정밀하게 목표를 겨냥한 해결책, 즉 하나의 특정 병목 자원을 확장하는 것은 광범위하고 초점이 없는 “전달을 가속화하라”는 이니셔티브보다 훨씬 더 저렴하게 조직 전체의 문제를 해결했다.

총 소유 비용은 단계 수준 타임스탬프를 신뢰성 있게 포착하는 계측 노력과 드리프트에 대해 단계 경계를 주기적으로 감사하는 지속적인 규율이다. 그 비용은 그만한 가치가 있는데, 대안, 즉 병목을 추측하고 잘못된 단계를 고치는 것은 계측 자체가 드는 비용보다 시간이 지남에 따라 훨씬 더 많은 엔지니어링 노력을 낭비하기 때문이다.

안티패턴과 함정

사이클 타임 진단 없이 리드 타임 퇴보에 반응하기: 흔히 잘못된 단계를 고치는 것으로 이어진다.
활성 노력이 아니라 대기 시간이 지배적인 비용이라고 가정하기: 보통 틀렸다. 대부분의 실제 전달 파이프라인에서는 대기열이 지배적이다(주제 2.5).
팀별로만 사이클 타임을 검토하여 공유된 팀 간 병목을 놓치기: 레버리지가 높은 플랫폼 해결책을 발견하지 못한 채 남긴다.
단계별 지침 없이 막연한 전체 리드 타임 목표를 설정하기: 팀이 어디에 노력을 집중할지 추측하게 만든다.
단계 경계의 정의상 드리프트: 실제 개선 없이 특정 단계의 수치를 치장한다.
그중 어느 것도 진정한 병목인지 확인하기 전에 가능한 모든 세밀한 단계를 계측하기: 아직 결정을 알려주지 않는 세부 사항에 계측 노력을 낭비한다.

성숙도 모델

1단계, 시작: 사이클 타임이 전혀 분해되지 않는다. 팀은 리드 타임이 퇴보할 때 병목을 추측한다.
2단계, 개발: 일부 팀이 비공식적으로 거친 단계 타이밍을 추적하지만, 일관된 계측이나 팀 간 비교가 없다.
3단계, 표준화: 단계 경계가 조직 전체에서 일관되게 계측되며, 지배적인 병목 단계에서 대기 시간이 활성 시간으로부터 분리된다.
4단계, 관리: 팀 간 사이클 타임 집계가 능동적으로 공유된 병목을 드러낸다. 단계별로 구체적인 개선 목표가 막연한 전체 리드 타임 목표를 대체한다.
5단계, 조율: 사이클 타임 데이터가 플랫폼 투자 우선순위를 직접 이끌며, 조직은 한 번에 많은 팀에 걸쳐 측정 가능하게 리드 타임을 개선한 확장된 리뷰 풀이나 더 빠른 공유 파이프라인 같은 구체적이고 목표를 겨냥한 해결책을 제시할 수 있다.

논의를 위한 아이디어

우리의 현재 지배적인 병목 단계는 무엇이며, 우리는 그 답에 얼마나 확신하는가?
그 병목 단계 시간 중 얼마나 많은 부분이 대기 시간이고 얼마나 많은 부분이 활성 시간인가?
우리의 어떤 팀이라도 같은 병목을 공유하여 플랫폼 수준의 해결책을 시사하는가?
우리는 마지막으로 언제 전체가 아니라 단계별로 구체적인 전달 개선 목표를 설정했는가?
우리 도구의 단계 경계 정의가 문서화 없이 바뀐 적이 있는가?

핵심 요약

사이클 타임은 플로우 타임을 코딩, 리뷰, 테스트, 배포라는 엔지니어링 단계로 분해하며, 그 요약 수치 아래에 있는 진단 계층이다.
각 단계 안에서 대기 시간을 활성 시간으로부터 분리하라. 대기열이 보통 활성 노력을 지배한다(주제 2.5).
느려짐이 팀에 특유한 것이라고 가정하기 전에 팀 간 공유된 병목을 찾아보라. 공유된 원인은 흔히 플랫폼 투자 기회다.
막연한 전체 목표가 아니라 단계별로 구체적인 개선 목표를 설정하여 팀이 정확히 어디에 집중해야 할지 알게 하라.
단계 경계는 플로우 타임 자체와 동일한 정의상 드리프트 위험에 노출된다. 주기적으로 그것들을 감사하라.
주제 2.7은 진행 중 작업과 사이클 타임이 왜 함께 움직이는지에 대한 근본적인 수학인 리틀의 법칙을 제공한다.

참고 문헌 및 추가 자료

Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Vacanti, Daniel S. Actionable Agile Metrics for Predictability. Actionable Agile Press, 2015.
Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Goldratt, Eliyahu M. The Goal: A Process of Ongoing Improvement. North River Press, 1984.