💡 핵심 인사이트
애자일/칸반 환경에서 팀의 생산성을 측정하는 핵심 지표(Metrics)입니다.
**리드 타임(Lead Time)**은 '고객' 관점에서 요구사항을 요청한 날부터 내 손에 쥐어지기까지의 전체 대기 시간이며, **사이클 타임(Cycle Time)**은 '개발팀' 관점에서 코딩을 시작해서 기능을 완료하기까지 걸린 실제 작업 시간입니다.

Ⅰ. 칸반 보드와 시간의 흐름

어떤 고객이 "장바구니에 찜하기 버튼 만들어주세요"라고 티켓을 생성했습니다. 이 티켓은 칸반 보드의 각 열을 통과하며 상태가 변합니다.

[ 백로그(요청됨) ] ➔ [ To Do (대기 중) ] ➔ [ In Progress (개발 중) ] ➔ [ Review ] ➔ [ Done (완료) ]

이 흐름 속에서 스톱워치를 언제 누르고 언제 끄느냐에 따라 리드 타임과 사이클 타임이 나뉩니다.

Ⅱ. 리드 타임 (Lead Time) - 고객의 인내심 지표

• 측정 구간: 티켓이 [백로그]에 생성된 그 순간부터 ➔ 최종적으로 [Done(배포 완료)] 상태가 될 때까지의 전체 소요 시간입니다.
• 관점: 철저히 고객의 관점입니다.
• 특징: 내가 짜장면을 배달 앱으로 주문한(요청) 시간부터 내 집 문을 두드리는(배달 완료) 순간까지의 시간입니다. 주방장이 재료를 준비하느라 10분을 기다렸든, 배달통에 담겨 20분을 지연됐든 고객에겐 중요하지 않습니다. 총 40분이 걸렸으면 리드 타임은 40분입니다.

Ⅲ. 사이클 타임 (Cycle Time) - 개발팀의 코딩 속도 지표

• 측정 구간: 개발자가 백로그에서 굴러다니던 티켓을 집어 들어 실제 코딩(작업)을 시작한([In Progress]) 그 순간부터 ➔ [Done] 상태가 될 때까지의 시간입니다.
• 관점: 철저히 작업자(개발팀)의 관점입니다.
• 특징: 짜장면 주문이 들어왔어도 주문표에 30분 동안 꽂혀있던 대기 시간은 빼버립니다. 주방장이 웍을 잡고 불을 켠 순간부터 짜장면이 포장기에 담길 때까지 걸린 순수 조리 시간(예: 10분)만을 측정합니다.

Ⅳ. 왜 두 지표를 분리해서 봐야 하는가? (병목 탐지)

팀장(PM)은 이 두 지표의 격차를 보고 팀의 어느 파이프라인이 썩어 있는지(병목) 진단할 수 있습니다.

• 상황 A: 사이클 타임은 1일인데, 리드 타임이 20일인 경우

  • 개발자가 키보드를 잡으면 하루 만에 코드를 뚝딱 짭니다(사이클 타임 우수).
  • 하지만 기능 요청 티켓이 백로그나 대기열에 무려 19일 동안 방치되어 먼지만 쌓이고 있었다는 뜻입니다. 개발자의 실력이 부족한 게 아니라, 기획팀의 요구사항 분석이 느리거나 개발팀의 일감이 폭주해서 처리 못 하는 과부하 상태(Backlog 늪)임을 알 수 있습니다.

• 상황 B: 사이클 타임이 자꾸 길어지는 경우

  • 개발자가 티켓을 물었는데(In progress), Done으로 가기까지 10일이 걸립니다.
  • 이는 개발자가 코딩 실력이 부족하거나, 빌드/배포 환경(CI/CD)이 너무 느려 코딩은 다 했는데 테스터의 승인을 받느라 병목에 걸려있음을 시사합니다. (WIP 제한을 낮춰서 멀티태스킹을 줄여야 함을 의미합니다.)

📢 섹션 요약 비유: 맥도날드 햄버거집을 생각하세요. 손님이 키오스크에서 돈을 내고 번호표를 받아 햄버거를 건네받기까지의 총 15분의 지루한 기다림이 **'리드 타임(고객 관점)'**입니다. 반면, 주방 안에서 알바생이 빵을 굽기 시작해서 패티를 얹어 종이에 예쁘게 싸기까지 걸린 3분의 불꽃 튀는 요리 시간이 **'사이클 타임(작업자 관점)'**입니다. 애자일의 궁극적 목표는 이 두 시간을 최대한 일치시키고 줄여나가는 것입니다.