최소 처리 시간(MTT)을 측정하는 과정은 다음과 같습니다.
소규모 변경 배포 과정
아주 작은 텍스트 변경이라도 프로덕션에 배포하기까지는 여러 단계가 필요합니다.
-
최신 코드 풀다운
-
브랜치 생성 및 요청 파악
-
코드 내 변경 지점 식별 및 실제 코드 수정
-
관련 자동화 테스트 업데이트 및 실행, 수정 반복
-
린팅 등 추가 검사 수행
-
브랜치 푸시 및 풀 리퀘스트(PR) 준비
-
CI/CD 액션 실행 대기 (실패 시 반복)
-
PR 검토 대기
UAT(사용자 인수 테스트)나 스테이징 배포가 필요한 경우, 메인 브랜치 병합, 프로덕션 CI/CD 배포, 최종 프로덕션 검토 등의 추가 단계가 발생합니다. 각 단계는 개별적으로 빠를 수 있지만, 전체적으로는 상당한 시간이 소요되며 품질 저하 없이 건너뛸 수 없는 필수 과정입니다.
MTT의 중요성 및 다른 지표와의 비교
MTT는 팀이 얼마나 빠르게 작은 작업을 처리하고 배포할 수 있는지를 보여주는 가장 빠른 지표입니다. 이는 개발자들이 PR 검토 등을 기다리는 동안 발생하는 대기 시간이나 컨텍스트 전환 비용을 명확히 드러냅니다.
-
DORA 지표: DORA의 ‘변경 리드 타임(Lead Time for Changes)’은 커밋부터 프로덕션까지의 시간을 측정합니다. 그러나 ‘커밋’의 정의에 따라 MTT와 차이가 발생할 수 있습니다. 일반적으로 DevOps에서는 최종 PR 병합 시점부터 측정하는 경우가 많아, 코드 작성 및 초기 검토 시간을 제외하여 MTT보다 짧게 보일 수 있습니다.
-
SPACE 모델: ‘효율성 및 흐름(Efficiency and Flow)’ 차원이 MTT와 유사하지만, SPACE는 개발자 만족도, 성과 등 더 광범위한 영역을 다룹니다.
-
린(Lean) 생산: ‘사이클 타임(Cycle Time)’은 작업 시작부터 한 단위 완료까지의 평균 시간을 의미하며, ‘리드 타임(Lead Time)’은 요청부터 인도까지의 전체 시간을 포함합니다. 이들은 MTT와 달리 평균 시간이거나 계획 및 우선순위 지정까지 포함하는 더 넓은 개념입니다.
MTT는 다른 복잡한 지표들과 달리 측정하기 쉽고, 비개발자에게도 팀의 효율성을 명확하게 설명할 수 있는 강력한 피드백 지표입니다. 매달 또는 분기별로 MTT를 재측정하여 프로세스 개선 노력을 평가하고 팀의 민첩성을 지속적으로 향상시킬 수 있습니다.