Cycle Time(사이클 타임)이란 무엇인가요?

Cycle Time(사이클 타임) 은 작업 항목이 실제 작업이 시작된 시점부터 완료될 때까지 걸리는 시간입니다. 칸반과 린 방법론에서 가장 중요한 흐름 메트릭(Flow Metric) 중 하나입니다.

간단히 말해, "이 작업을 하는 데 실제로 며칠이 걸렸는가?"에 대한 답이 Cycle Time입니다.

Cycle Time = 완료 날짜 - 작업 시작 날짜 + 1

(같은 날 시작하고 완료한 항목의 Cycle Time은 1일입니다.)

Cycle Time과 Lead Time은 자주 혼동되는 개념이지만, 측정 범위가 다릅니다:

측정 범위 비교

고객 요청 ──────────────────────────────── 고객 전달 | | |←──────────── Lead Time ─────────────────────→| | | | 대기 |←── Cycle Time ──→| 배포 | | | | | | 백로그 대기 | 작업 시작 → 완료 | 릴리스 대기 |

실무 예시

네이버 쇼핑의 기능 개발을 예로 들면:

• Lead Time: 제품 백로그에 등록(1월 5일) → 프로덕션 배포(1월 25일) = 20일
• Cycle Time: 개발 시작(1월 12일) → 개발 완료(1월 20일) = 9일
• 차이(11일): 백로그 대기(7일) + 배포 대기(4일)

칸반 보드에서 측정

칸반 보드의 각 항목에 대해:

1. "진행 중(In Progress)" 열에 들어간 날짜 기록
2. "완료(Done)" 열에 도달한 날짜 기록
3. 두 날짜의 차이를 계산

Cycle Time 산점도 (Scatter Plot)

각 완료 항목의 Cycle Time을 산점도로 시각화합니다:

• X축: 완료 날짜
• Y축: Cycle Time (일)
• 백분위선: 50%, 70%, 85%, 95% 백분위

Cycle Time (일) 20 | ● 15 | ● ● 10 | ───────────────────── 85% (12일) 8 | ● ● ● ● 5 | ──●──●────●───────── 50% (5일) 3 | ● ● ● ● ● 1 | ● ● └─────────────────────── 날짜

이 차트는 다음을 알려줍니다:

• 50% 백분위 = 5일: 절반의 항목이 5일 이내 완료
• 85% 백분위 = 12일: 85%의 항목이 12일 이내 완료
• 이상치: 15일, 20일 걸린 항목은 조사가 필요

히스토그램

완료 항목의 Cycle Time 분포를 히스토그램으로 보여줍니다:

빈도 8 | ████ 6 | ████████ 4 | ████████████ 2 | ████████████████ └────────────────── 1-3 4-6 7-10 11+ (일)

정규 분포에 가까울수록 프로세스가 안정적입니다.

긍정적 요소 (Cycle Time 감소)

• WIP 제한: 동시 작업 수 제한으로 집중력 향상
• 작은 배치 크기: 작업 항목을 작게 분할
• 자동화: CI/CD, 자동 테스트, 자동 배포
• 블로커 빠른 해결: 장애물의 신속한 제거
• 페어 프로그래밍: 리뷰 대기 시간 제거
• 명확한 요구사항: DoR 충족

부정적 요소 (Cycle Time 증가)

• 과도한 WIP: 컨텍스트 스위칭 증가
• 코드 리뷰 지연: PR 대기 시간
• 불명확한 요구사항: 개발 중 반복적 확인 필요
• 기술 부채: 기술 부채 누적으로 개발 속도 저하
• 외부 의존성: 다른 팀이나 외부 서비스 대기

1. WIP 제한 적용

리틀의 법칙(Little's Law)에 따르면:

Cycle Time = WIP / Throughput

WIP를 줄이면 Cycle Time이 비례적으로 감소합니다. 이는 가장 효과적인 Cycle Time 개선 전략입니다.

2. 배치 크기 줄이기

큰 기능을 작은 사용자 스토리로 분할하면:

• 작업 하나하나가 빨리 완료됨
• 조기 피드백 가능
• 리스크 조기 발견

3. 병목 현상 해결

CFD(누적 흐름 다이어그램)로 병목을 식별하고 해결합니다:

• 작업이 쌓이는 단계를 찾아냄
• 해당 단계의 용량 확대 또는 프로세스 개선
• 스워밍으로 병목 구간에 인력 집중

4. 대기 시간 제거

작업 간 대기 시간은 Cycle Time의 가장 큰 원인입니다:

• 코드 리뷰 SLA 설정 (예: 24시간 이내)
• 자동화된 테스트와 검증
• 이해관계자 피드백 루프 단축

5. 자동화 강화

• CI/CD 파이프라인으로 빌드, 테스트, 배포 자동화
• TDD로 테스트 커버리지 확보
• 인프라 자동화(IaC)

처리량(Throughput)과의 관계

처리량과 Cycle Time은 역의 관계에 있습니다:

• Cycle Time 감소 → 같은 기간에 더 많은 항목 완료 → Throughput 증가
• 리틀의 법칙: Throughput = WIP / Cycle Time

벨로시티(Velocity)와의 차이

DORA 메트릭과의 관계

DORA(DevOps Research and Assessment)의 4가지 핵심 메트릭 중 "변경 리드 타임(Lead Time for Changes)"은 Cycle Time의 확장 개념입니다. 엘리트 팀은 변경 리드 타임이 1시간 미만입니다.

카카오

카카오의 한 개발 팀은 Cycle Time을 주요 지표로 채택한 후, WIP 제한과 코드 리뷰 SLA를 도입하여 평균 Cycle Time을 12일에서 5일로 58% 단축했습니다.

네이버

네이버 쇼핑 팀은 CFD 분석을 통해 "QA 대기" 단계가 주요 병목임을 식별하고, QA 자동화를 강화하여 Cycle Time을 40% 개선했습니다.

삼성 SDS

삼성 SDS는 대규모 엔터프라이즈 프로젝트에서 Cycle Time 데이터를 활용하여 포캐스트의 정확도를 높이고, 고객에게 더 신뢰성 있는 납기 예측을 제공합니다.

Cycle Time을 어떤 단위로 측정해야 하나요?

일반적으로 일(day) 단위로 측정합니다. 짧은 Cycle Time의 팀은 시간(hour) 단위를, DevOps 팀은 분(minute) 단위로 측정하기도 합니다.

이상적인 Cycle Time은 얼마인가요?

정해진 기준은 없지만, 사용자 스토리 수준에서 3-5일이 일반적인 목표입니다. 중요한 것은 절대적 수치보다 추세(지속적으로 감소하는지)와 예측 가능성(분산이 작은지)입니다.

Cycle Time이 0일인 항목이 있을 수 있나요?

계산 방식에 따라 다릅니다. 완료일 - 시작일 + 1 방식에서는 같은 날 시작하고 완료하면 1일입니다. 시간 단위로 측정하면 몇 시간이 됩니다.

스크럼 팀에서도 Cycle Time을 측정해야 하나요?

강력히 권장합니다. 벨로시티만으로는 흐름의 건강도를 파악하기 어렵습니다. Cycle Time은 스프린트 내에서도 작업 흐름을 최적화하는 데 귀중한 데이터를 제공합니다.

• Lead Time - 리드 타임
• WIP - 진행 중 작업
• 처리량 - Throughput
• CFD - 누적 흐름 다이어그램
• 칸반 - 칸반 방법론
• Forecast - 예측