2.4 플로우 타임과 플로우 로드

개요 및 동기

플로우 타임은 플로우 아이템(주제 2.2)이 가치 흐름에 진입할 때부터 전달될 때까지의 총 경과 시간으로, 비즈니스 필요가 식별되는 것부터 고객이 가치를 받는 것까지 전체 경로에 걸친 반응성을 측정한다. 플로우 로드는 가치 흐름에서 현재 활성 상태이거나 대기 중인 플로우 아이템의 총 수로, 주제 2.5가 진행 중 작업이라고 부르는 것에 대한 플로우 프레임워크의 이름이다. 이 둘은 함께 대기 행렬의 수학에 가장 직접적으로 연결되는 두 가지 플로우 프레임워크 메트릭인데, 플로우 로드는 플로우 타임과 단지 상관관계만 있는 것이 아니라 수학적으로 그것을 결정하기 때문이다.

그 관계는 리틀의 법칙이며, 대기 행렬 이론(주제 2.7이 전체적으로 다룬다)에서 나온 증명으로, 안정적인 시스템에서 평균 아이템 수는 평균 도착률에 각 아이템이 시스템에서 보내는 평균 시간을 곱한 것과 같다고 말한다. 여기에 적용하면: 플로우 로드는 도착률 곱하기 플로우 타임과 같다. 이것이 이 주제에서 가장 유용한 단일 사실인데, 이는 과거에 정성적이었던 주장, “우리는 너무 과부하되어 있고, 일이 너무 오래 걸린다”를 비즈니스 리더가 쉽게 무시할 수 없는 증명 가능하고 정량적인 것으로 바꾸기 때문이다: 도착률이 일정하게 유지되는 동안 플로우 로드가 계속 상승한다면, 플로우 타임도 상승할 가능성이 있는 정도가 아니라 수학적으로 보장된다.

대규모 팀에게 이것은 흔히 전체 프레임워크에서 가장 설득력 있는 단일 수치다. 모든 요청이 개별적으로 정당화되어 보이기 때문에 새로운 작업을 거절하는 아이디어에 저항하는 비즈니스 리더는, 일단 플로우 로드가 추적되고 플로우 타임과의 관계가 추상적으로 주장되는 대신 직접 보여지면, 가치 흐름에 과부하를 주는 것이 이미 그 안에 있는 모든 아이템을 증명 가능하게 느리게 만든다는 것을 흔히 받아들인다. 많은 동시적인 전략적 이니셔티브를 저글링하는 엔터프라이즈 조직과 수십 개의 병렬 워크스트림을 운영하는 정부 프로그램 모두 한 번에 더 많은 작업을 시작하는 것을 거절하는 것을 정당화하기 위해 그 배후의 직관뿐 아니라 이 증명에 의존한다.

핵심 원칙

플로우 로드는 리틀의 법칙을 통해 플로우 타임을 수학적으로 결정한다. 이것은 상관관계가 아니다. 이것은 어떤 안정적인 가치 흐름에도 성립하는 증명이다.
플로우 타임은 엔지니어링뿐 아니라 전체 가치 흐름에 걸쳐 있다. 그것은 엔지니어링이 작업을 시작할 때가 아니라 비즈니스 필요가 식별될 때 시작하며, 주제 2.6의 사이클 타임은 그다음에 그것을 더 분해한다.
상승하는 플로우 로드는 상승하는 플로우 타임의 가장 이른 경고 신호다. 그 관계가 증명 가능하기 때문에, 플로우 로드는 플로우 타임이 이미 저하된 후에야 발견되는 것이 아니라 선행 지표로서 지켜볼 수 있다.
가치 흐름의 진입점은 고정되고 문서화되어야 한다. 플로우 타임 시계가 어디서 시작하는지는 이 책의 다른 어떤 메트릭 경계와도 같은 게임 위험에 노출되는 정의상의 선택이다.
비즈니스 리더는 플로우 로드에 직접 행동할 수 있다. 후행 측정치인 플로우 타임과 달리, 플로우 로드는 지렛대다: 새로운 작업 시작을 거절하는 것은 오늘 이용 가능한 행동이다.

권장 사항

플로우 타임을 측정하기 전에 가치 흐름의 진입점을 고정하고 문서화하라

플로우 타임이 비즈니스 필요가 처음 식별될 때, 공식적으로 승인될 때, 혹은 엔지니어링이 작업을 시작할 때 시작하는지 명시적으로 결정하고, 주제 1.4가 어떤 메트릭 헌장에 대해서도 권장하는 것과 동일한 방식으로 그 선택을 문서화하라. 이 단일한 결정은 플로우 타임이 진정한 종단간 반응성을 측정하는지 아니면 엔지니어링이 통제하는 더 좁은 부분만 측정하는지를 결정하며, 공개하지 않은 채 나중에 정의를 바꾸는 것이 이 주제의 핵심 게임 위험이다.

플로우 로드를 주기적으로가 아니라 지속적으로 추적하라

플로우 로드는 리틀의 법칙을 통해 아직 오지 않은 플로우 타임에 대한 선행 지표이기 때문에, 그것을 주기적인 스냅샷이 아니라 실시간의, 지속적으로 갱신되는 수치로 추적하라. 누군가 확인할 때쯤 이미 몇 주 동안 상승한 플로우 로드는 메트릭이 따라잡기 전까지 보이지 않게 그만큼 오래 플로우 타임을 조용히 연장해 온 것이다.

WIP 제한이나 역량 증가를 주장할 때 리틀의 법칙을 명시적으로 사용하라

동시 작업을 덜 시작하거나 역량을 추가하자는 주장을 할 때, 권고뿐 아니라 실제 방정식을 제시하라: 플로우 로드는 도착률 곱하기 플로우 타임과 같으므로, 도착률이 대략 고정되어 있다면 플로우 로드를 줄이는 것은 수학적으로 플로우 타임을 줄이는 것이 보장된다. 이것은 “우리는 너무 바쁘다”는 정량화되지 않은 주장보다 회의적인 이해관계자에게 훨씬 더 강력한 주장인데, 그것이 단언되는 것이 아니라 증명 가능하기 때문이다.

해결책을 제안하기 전에 플로우 타임을 플로우 로드의 근본 원인으로부터 분리하라

플로우 로드가 높을 때, 어떤 플로우 아이템 유형(주제 2.2)이 실제로 그것을 이끌고 있는지 조사하라: 한꺼번에 시작된 너무 많은 동시적인 기능, 다루어지지 않은 결함의 백로그, 혹은 공유된 승인을 기다리며 막혀 있는 위험 작업. 각 원인은 다른 해결책을 시사하며, “플로우 로드가 높다”를 단일하고 미분화된 문제로 취급하는 것은 일반적이고 비효과적인 대응을 만들어 내는 경향이 있다.

지연이 실제로 어디서 일어나는지 분리하기 위해 플로우 타임을 사이클 타임과 교차 검증하라

플로우 타임이 전체 가치 흐름에 걸쳐 있고 사이클 타임(주제 2.6)은 그중 엔지니어링 부분만 다루기 때문에, 둘을 직접 비교하라. 플로우 타임과 사이클 타임 사이의 큰 간극은 대부분의 지연이 엔지니어링이 그 작업을 보기도 전에, 승인 대기열, 우선순위 지정 백로그, 혹은 팀 간 핸드오프에서 일어난다는 것을 의미하며, 이는 엔지니어링 자체 안에 집중된 간극과는 매우 다른 해결책을 가리킨다.

트레이드오프: 장단점

접근법	장점	단점
엔지니어링 착수부터만 플로우 타임 측정	단순하고 기존 사이클 타임 계측과 일치함	엔지니어링 이전의 지연을 놓치고 진정한 반응성을 과소평가함
진정한 비즈니스 필요 식별부터 플로우 타임 측정	진정한 종단간 반응성을 포착함	엔지니어링의 직접 통제 밖에 있는 단계를 계측해야 함
주기적인 플로우 로드 스냅샷	이따금 계산하기 저렴함	선행 지표로서의 가치를 놓침; 상승하는 로드가 너무 오래 눈에 띄지 않음
지속적인 플로우 로드 추적	실시간의, 실행 가능한 선행 지표	이따금의 보고가 아니라 지속적인 도구 통합이 필요함

핵심 긴장은 범위 대 계측 도달 범위다. 엔지니어링 착수부터만 플로우 타임을 측정하는 것은 주제 2.6이 이미 수집하는 사이클 타임 데이터를 재사용하기 때문에 계측하기 훨씬 쉽지만, 엔지니어링이 그 작업을 보기 전에 일어나는 모든 것을 무시함으로써 진정한 반응성을 조용히 과소평가한다. 오늘 계측할 수 있는 것이 그것뿐이라면 더 좁은, 엔지니어링 범위의 측정부터 시작하되, 플로우 타임의 시작점을 상류로, 비즈니스 필요 식별과 우선순위 지정으로 확장하는 것을 영구적인 한계가 아니라 단기 우선순위로 취급하라.

팀과 논의할 질문

우리의 플로우 타임 시계는 오늘 실제로 어디서 시작하며, 조직의 모두가 그것이 올바른 시작점이라는 데 동의하는가? 이해관계자가 시계가 시작한다고 가정하는 곳과 실제로 시작하는 곳 사이의 불일치는 메트릭에 대한 흔하고 조용한 불신의 원천이다. 문서화된 정의가 공유된 이해와 일치하는지 확인하라.
우리가 측정한 플로우 로드, 도착률, 플로우 타임이 실제로 리틀의 법칙을 만족하는지 확인해 본 적이 있는가? 대략적으로도 균형이 맞지 않는다면, 세 수치 중 하나가 일관성 없이 측정되고 있는 것이다. 확인이 통과할 것이라고 가정하는 대신 실제 수치를 함께 살펴보라.
플로우 로드는 지속적으로 추적되는가, 아니면 누군가 확인하기 전에 꾸준한 상승이 몇 주 동안 눈에 띄지 않을 것인가? 선행 지표는 누군가 분기 보고서에서만이 아니라 실제로 거의 실시간으로 그것을 지켜보고 있을 때만 당신을 보호한다.
플로우 로드가 상승할 때, 우리는 어떤 플로우 아이템 유형이 실제로 그것을 이끌고 있는지 말할 수 있는가, 아니면 그것은 하나의 미분화된 수치로 읽히는가? 일반적인 “우리는 과부하되어 있다”는 진단은 일반적이고 흔히 비효과적인 대응을 만들어 낸다. 당신의 현재 계측이 실제로 상승하는 로드를 특정 원인에 귀속시킬 수 있는지 확인하라.
우리의 플로우 타임과 사이클 타임 사이의 간극은 얼마나 크며, 그 간극은 대부분의 지연이 엔지니어링이 그 작업을 보기 전에 일어나는지 후에 일어나는지를 시사하는가? 이 비교는 흔히 개선을 위한 가장 큰 기회가 엔지니어링 자체의 통제 밖 완전히 다른 곳에 있다는 것을 드러낸다.
누군가 그 변경이 문서화되거나 공개되지 않은 채 수치를 더 좋아 보이게 하려고 우리의 플로우 타임 시작점을 조용히 좁힌 적이 있는가? 이것이 이 주제의 핵심 게임 위험을 직접 서술한 것이다. 당신의 정의가 이런 식으로 드리프트한 적이 있는지 정직하게 물어보라.

분야별 관점

스타트업. 단순히 동시에 많은 작업을 시작할 만큼 충분한 사람이 없기 때문에 플로우 로드는 보통 낮지만, 창업자나 리드 엔지니어가 많은 동시적인 이니셔티브의 개인적인 병목이 되는 순간 동일한 수학적 관계가 여전히 적용된다. 전용 도구 없이도 비공식적으로 플로우 로드를 추적하라. 리틀의 법칙은 규모와 무관하게 성립하기 때문이다.

중소기업. 현재 활성 상태인 모든 것의 단순하고 공유된 목록이면 보통 전용 가치 흐름 관리 소프트웨어 없이도 플로우 로드를 계산하기에 충분하다. 유용한 습관은 상승하는 수치가 플로우 타임이 이미 눈에 띄게 저하된 후에야 발견되는 것이 아니라 일찍 잡히도록 충분히 정기적으로 확인하는 것이다.

엔터프라이즈. 이곳이 리틀의 법칙이 단순한 메트릭이 아니라 하나의 주장으로서 제 몫을 하는 곳이다: 수십 개의 동시적인 전략 이니셔티브를 저글링하는 대규모 조직은 플로우 로드와 플로우 타임 사이의 증명 가능한 관계를 사용해 작업 순서 지정에 대한 증거 기반 주장을 할 수 있으며, 이는 순전히 정성적인 “우리는 너무 바쁘다”는 주장이 단호한 이해관계자 압박에 맞서 좀처럼 달성하지 못하는 것이다.

정부. 다년간의 프로그램은 각각 개별적으로 정당화되지만 조직 전체에 걸친 총계에 대한 가시성이 없는 많은 워크스트림에 걸쳐 크고 암묵적인 플로우 로드를 일상적으로 축적한다. 프로그램 자체의 플로우 타임 성장이 그 자체의 상승하는 플로우 로드에 의해 수학적으로 설명된다는 것을 보여 주며 리틀의 법칙을 직접 제시하는 것은, 흔히 모든 워크스트림을 무기한 병렬로 실행하는 대신 순서를 지정하는 것에 대해 이용 가능한 가장 명확하고 가장 설득력 있는 증거다.

사례

엔터프라이즈. 한 미디어 기술 회사의 플랫폼 조직은 대략 열두 개에 현실적인 역량으로 스물두 개의 동시적인 전략 이니셔티브를 운영하고 있었으며, 새로운 엔지니어링 VP가 직접 플로우 로드를 요청할 때까지 아무도 이 불일치를 수량화하지 않았다. 중앙값 이니셔티브의 플로우 타임은 전년 대비 40% 증가했으며, 리더십은 이 추세를 “작업이 더 어려워지고 있다”는 탓으로 돌렸다. 실제 플로우 로드 및 도착률 수치와 함께 리틀의 법칙을 제시한 것은 그 성장이 그것을 설명하는 데 필요한 근본적인 작업 난이도의 변화 없이 오직 상승하는 플로우 로드만으로 완전히 설명된다는 것을 보여 주었다. 조직은 이니셔티브를 지속 가능한 플로우 로드까지 순서를 지정했고, 중앙값 플로우 타임은 두 분기 안에 거의 3분의 1 떨어졌다.

정부. 한 연방 보조금 관리 기관의 현대화 프로그램은 어떤 단일한 추적된 총계도 없이 수십 개의 병렬 워크스트림에 걸쳐 플로우 로드를 축적해 왔으며, 각 워크스트림 후원자는 자신의 이니셔티브가 고립된 상태에서 적절하게 자원이 배분되었다고 믿었다. 리틀의 법칙을 사용한 프로그램 사무소 분석은 프로그램의 총 플로우 타임, 즉 워크스트림의 승인부터 전달까지의 시간이 그 총 플로우 로드만으로부터 거의 정확하게 예측될 수 있다는 것을 보여 주었으며, 이는 1년 넘게 우선순위 하향 조정 주장에 저항해 온 후원자들을 설득한 발견이었다. 그 프로그램은 명시적인 플로우 로드 상한을 채택했고, 새로운 워크스트림은 이제 현재의 로드와 무관하게 즉시 시작하는 대신 대기열에 진입한다.

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

플로우 로드와 플로우 타임을 함께 추적하는 것의 수익은 모든 것을 병렬로 실행하는 대신 작업의 순서를 지정하는 것에 대한 단지 설득력 있는 것이 아니라 증명 가능한 사례다. 전체 플로우 타임 퇴보를 플로우 로드만으로 설명한 위의 미디어 기술 사례는 이 조합이 신뢰성 있게 만들어 내는 패턴이다: 구체적이고 정량적인 주장은 “너무 바쁘다”는 정성적인 호소가 더 많은 작업을 시작하라는 실제 조직적 압박에 맞서 이전에 실패했던 곳에서 성공한다.

총 소유 비용은 그 설득력에 비해 낮다: 플로우 로드는 활성 및 대기 중인 아이템의 실시간 개수만 필요로 하며, 플로우 타임은 가치 흐름의 진입점을 계측해야 하는데, 이는 조직이 실제 역량이 지원할 수 있는 것보다 더 많은 동시적인 이니셔티브에 헌신하는 것을 막는 첫 순간 그 자체 비용을 회수하는 작업이다.

안티패턴과 함정

수치를 치장하기 위해 플로우 타임 시작점을 조용히 좁히기: 이 주제의 핵심에 있는 게임 벡터다. 시계의 시작을 진정한 비즈니스 필요 식별에서 더 늦은 지점, 엔지니어링 착수나 공식 승인으로 옮기는 것은 진정한 반응성을 전혀 바꾸지 않으면서 플로우 타임을 축소하며, 어떤 단일한 변경도 의도적인 조작으로 보이지 않을 만큼 점진적으로 일어날 수 있다. 가드레일은 메트릭 헌장(주제 1.4)에 진입점을 명시적으로 문서화하고 문서화된 정의에 비추어 주기적으로 그것을 감사하는 것이며, 이는 이 책이 모든 메트릭 경계에 요구하는 것과 동일한 규율이다.
플로우 로드를 오직 주기적으로만 측정하기: 꾸준한 상승이 몇 주 동안 눈에 띄지 않을 수 있기 때문에 선행 지표로서의 가치를 포기한다.
플로우 로드를 단일한 미분화된 수치로 취급하기: 어떤 플로우 아이템 유형이 실제로 과부하를 이끌고 있는지 놓쳐 목표에 맞춘 대응이 아니라 일반적인 대응을 만들어 낸다.
플로우 타임과 사이클 타임 사이의 간극을 무시하기: 지연이 엔지니어링 이전에 집중되어 있는지 이후에 집중되어 있는지 놓치며, 이는 매우 다른 해결책을 시사한다.
리틀의 법칙을 명시적으로 제시하지 않고 동시 작업 감축을 주장하기: 정성적인 호소는 이해관계자가 정량적이고 증명 가능한 관계보다 훨씬 더 쉽게 무시할 수 있다.
리틀의 법칙이 대규모에서만 적용된다고 가정하기: 그것은 규모와 무관하게, 단 한 명의 과부하된 개인을 포함해 어떤 안정적인 시스템에도 성립한다.

성숙도 모델

1단계, 시작: 플로우 타임도 플로우 로드도 추적되지 않는다. 지연은 뒷받침하는 데이터 없이 일화적으로 논의된다.
2단계, 개발: 플로우 타임은 엔지니어링 착수부터만 추적되고, 플로우 로드는 지속적으로가 아니라 주기적으로 확인된다.
3단계, 표준화: 플로우 타임은 문서화된, 조직 전체의 가치 흐름 진입점으로부터 측정되고, 플로우 로드는 선행 지표로서 지속적으로 추적된다.
4단계, 관리: 리틀의 법칙이 역량 및 순서 지정 결정을 정당화하는 데 명시적으로 사용되며, 상승하는 플로우 로드는 해결책이 제안되기 전에 특정 플로우 아이템 유형에 귀속된다.
5단계, 조율: 조직은 그 가치 흐름 전반에 걸쳐 명시적인 플로우 로드 상한을 설정하며, 리틀의 법칙에 의해 뒷받침되어 측정 가능하게 플로우 타임을 개선한 구체적인 순서 지정 결정을 제시할 수 있다.

논의를 위한 아이디어

우리의 플로우 타임 시계는 실제로 어디서 시작하며, 그 정의가 문서화 없이 드리프트한 적이 있는가?
우리가 측정한 플로우 로드, 도착률, 플로우 타임은 대략 리틀의 법칙을 만족하는가?
플로우 로드는 꾸준한 상승이 몇 달이 아니라 며칠 안에 잡힐 만큼 충분히 지속적으로 추적되는가?
우리의 플로우 타임과 사이클 타임 사이의 간극은 얼마나 되며, 그 간극은 지연이 실제로 어디서 일어나는지에 대해 우리에게 무엇을 말해 주는가?

핵심 요약

플로우 로드는 리틀의 법칙을 통해 플로우 타임을 수학적으로 결정한다: 플로우 로드는 어떤 안정적인 가치 흐름에 대해서도 도착률 곱하기 플로우 타임과 같다.
플로우 타임은 전체 가치 흐름에 걸쳐 있다, 비즈니스 필요 식별에서 전달까지, 사이클 타임의 엔지니어링 전용 범위(주제 2.6)보다 더 넓다.
이 주제의 핵심 게임 벡터는 플로우 타임 시작점을 조용히 좁히는 것이다. 가드레일은 문서화되고 감사되는 진입점 정의다.
그것이 후행하는 발견이 아니라 진정한 선행 지표로 기능하도록 플로우 로드를 주기적으로가 아니라 지속적으로 추적하라.
WIP 제한, 역량 증가, 혹은 동시 작업의 순서 지정을 주장할 때 리틀의 법칙을 단지 직관으로서가 아니라 명시적으로 사용하라.

참고 문헌 및 추가 자료

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.