24. Lead Time for Changes — 변경 리드 타임

핵심 인사이트 (3줄 요약)

1. 본질: LTC (Lead Time for Changes, 변경 리드 타임)는 DORA (DevOps Research and Assessment) 4대 지표 중 하나로, 코드가 커밋된 시점부터 프로덕션(Production)에 성공적으로 배포되기까지 걸리는 총 시간을 측정하는 소프트웨어 딜리버리 속도 지표다.
2. 가치: LTC는 개발 파이프라인의 병목(Bottleneck)을 가시화하며, Elite 수준 팀은 LTC < 1시간을 달성하는 반면 Low 팀은 6개월 이상이다. LTC 단축은 고객 피드백 → 코드 반영 → 배포까지의 피드백 루프를 압축하여 시장 대응력을 높인다.
3. 판단 포인트: LTC는 단순히 배포 자동화 속도가 아닌 PR 리뷰 대기·QA 병목·수동 승인 프로세스 등 모든 대기 시간을 포함한다. LTC 개선의 핵심은 자동화(CI/CD)보다 먼저 업무 흐름의 대기 시간(Queue Time) 제거이다.

Ⅰ. 개요 및 필요성

Lead Time for Changes는 "아이디어가 실제 사용자에게 전달되기까지 얼마나 걸리는가?"의 소프트웨어 버전이다.

┌──────────────────────────────────────────────────────────────┐
│           Lead Time for Changes 측정 구간                     │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  [코드 커밋] ──────────────────────────── [프로덕션 배포]       │
│      │                                         │            │
│      ▼                                         │            │
│  CI 빌드·테스트 (자동화, 수 분)                  │            │
│      │                                         │            │
│  PR 리뷰 대기 (수 시간~수 일) ← 주요 병목        │            │
│      │                                         │            │
│  통합 테스트·QA (수 시간~수 일) ← 병목           │            │
│      │                                         │            │
│  배포 승인 프로세스 (수 시간) ← 병목              │            │
│      │                                         │            │
│  CD 배포 (자동화, 수 분) ──────────────────────→            │
│                                                              │
│  LTC = 전체 구간의 합 (커밋 → 프로덕션)                        │
└──────────────────────────────────────────────────────────────┘

• 📢 섹션 요약 비유: LTC는 피자 주문에서 수령까지의 총 시간이다. 오븐 굽기(빌드·배포 자동화)보다 주문 대기(PR 리뷰)·배달 대기(QA 병목)가 더 긴 경우가 많아, 오븐 속도보다 줄 서는 시간 단축이 핵심이다.

Ⅱ. 아키텍처 및 핵심 원리

DORA 성과 등급별 LTC 기준

LTC 단축 5대 전략

• 📢 섹션 요약 비유: LTC 단축은 편의점 계산대 대기 시간 줄이기다. 계산대 속도(자동화)를 높이는 것도 중요하지만, 손님이 줄 서는 시간(PR 대기·QA 병목)이 더 긴 문제를 먼저 해결해야 한다.

Ⅲ. 비교 및 연결

LTC와 DF는 "속도" 지표, CFR과 MTTR은 "안정성" 지표로 서로 보완 관계를 이룬다.

• 📢 섹션 요약 비유: DF가 "얼마나 자주 배달하는가"이면, LTC는 "한 번 배달에 얼마나 걸리는가"다. 자주 배달하면서도 빠른 것이 Elite 팀의 특징이다.

Ⅳ. 실무 적용 및 기술사 판단

실무 시나리오: LTC 30일→4시간 개선

은행 핀테크 팀의 LTC를 30일(Low)에서 4시간(High→Elite 목표)으로 단축.

1. 측정: JIRA + GitHub 연계로 커밋 시각과 배포 시각 자동 측정.
2. 병목 분석: PR 리뷰 평균 대기 4일 → 핵심 병목 확인.
3. Trunk-based 전환: 장수 브랜치 제거, 매일 main 머지.
4. PR 규칙: PR당 200줄 이하 코드 변경 정책 도입.
5. 자동화 QA: Playwright E2E 테스트 CI 통합 → 수동 QA 80% 제거.
6. 결과: LTC 30일 → 4시간 (99% 단축).

안티패턴

• LTC 측정 없이 CI/CD 도구만 도입하는 안티패턴. 자동화 파이프라인 구축 후 "빨라졌겠지" 하고 LTC를 측정하지 않으면 실제 병목(PR 대기, QA)이 해소되지 않았음을 모른다. "측정하지 않는 것은 개선할 수 없다(If you can't measure it, you can't improve it)."

• 📢 섹션 요약 비유: LTC 측정 없이 CI/CD만 도입하는 건, 식당 주방 속도만 올리고 홀 서비스 대기 시간을 무시하는 것이다. 손님이 느린 이유는 주방이 아니라 홀 대기에 있을 수 있다.

Ⅴ. 기대효과 및 결론

LTC는 DORA의 SPACE 프레임워크(Satisfaction·Performance·Activity·Communication·Efficiency)로 확장되어 개발자 경험(Developer Experience, DX) 관점의 생산성 측정으로 발전하고 있다.

• 📢 섹션 요약 비유: LTC 단축은 가속 페달을 밟는 것이 아니라 신호등(병목)을 제거하는 것이다. 빠른 차(CI/CD 자동화)가 있어도 신호등이 많으면 목적지에 늦게 도착한다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

[수동 배포 — 릴리스 주기 수 개월, 높은 LTC]
    │
    ▼
[CI/CD 도입 — 자동화 빌드·테스트·배포, LTC 단축 시작]
    │
    ▼
[Trunk-based + 소규모 배치 — PR 병목 해소]
    │
    ▼
[DORA 측정 — LTC/DF/CFR/MTTR 데이터 기반 개선]
    │
    ▼
[Elite DevOps — LTC < 1시간, 지속 개선 문화]

👶 어린이를 위한 3줄 비유 설명

1. LTC는 피자 가게에서 주문을 받은 후 피자가 완성되어 배달되기까지의 총 시간이에요!
2. 오븐(코드 빌드) 시간보다 주문 받기(PR 리뷰)와 품질 확인(QA) 기다리는 시간이 더 길어서 전체가 느려지는 경우가 많아요.
3. 세계 최고 IT 기업들은 코드를 짜고 1시간 안에 수억 명의 사용자에게 배포할 수 있답니다!