2.5 플로우 효율과 진행 중 작업
개요 및 동기
플로우 효율은 작업의 한 조각에 대한 활성 시간 대 총 시간의 비율이다: 만약 어떤 변경이 열 시간 동안 활발하게 코딩되고, 검토되고, 테스트되지만, 전체 여정에 걸쳐 총 아흔 시간 동안 대기열에서 유휴 상태로 앉아 있다면, 플로우 효율은 10%다. 대부분의 소프트웨어 전달 파이프라인은 정직하게 측정하면 10%에서 25% 사이의 플로우 효율에 놓이며, 이는 노력이 지배적일 것이라고 기대하는 사람들을 놀라게 한다. 대부분의 전달 시스템에서 지배적인 비용은 작업을 하는 데 얼마나 걸리는지가 아니라, 작업이 시작되기를 기다리는 데 얼마나 걸리는지다.
진행 중 작업(WIP)은 팀이나 시스템 전반에 걸쳐 어느 한 시점에 활발하게 작업 중인 아이템의 수로, 주제 2.4가 “플로우 로드”라고 부르는 것과 같은 양이다. 이 주제의 배후에 있는 반직관적인 발견, 즉 운영 관리에서 수십 년의 연구로 뒷받침되고 칸반과 대기 행렬 이론을 통해 소프트웨어 전달에 공식화된 발견은, WIP를 제한하는 것이 처리량을 감소시키는 것이 아니라 증가시키는 경향이 있다는 것인데, 한 번에 진행 중인 작업이 적을수록 더 적은 맥락 전환, 더 짧은 대기열, 그리고 아이템당 더 빠른 완료를 의미하기 때문이다. 동시에 더 적게 작업하는 것이 전체적으로 더 적은 산출물을 만들어 낼 것 같은 느낌에도 불구하고 그렇다.
대규모 팀에게 플로우 효율을 이해하는 것은 거의 모든 전달 문제를 “사람들이 더 빠르게 일해야 한다”에서 “작업이 덜 기다려야 한다”로 재구성한다. 그 재구성은 중요한데, 첫 번째 프레이밍은 개인에 대한 압박을 초래하며, 이는 정확히 주제 2.6이 경고하는 함정인 반면, 두 번째 프레이밍은 대기열 구조, 검토 역량, 그리고 얼마나 많은 작업이 동시에 시작되는지에 대한 조사를 초래하는데, 이곳이야말로 실제적이고 지속 가능한 개선이 보통 자리하는 곳이기 때문이다. 공유 팀에 걸쳐 많은 동시적인 이니셔티브를 저글링하는 엔터프라이즈 조직은 특히 높은 WIP와 낮은 플로우 효율에 취약한데, 새로운 작업을 시작하는 것은 이미 진행 중인 모든 것을 조용히 느리게 만들고 있을 때조차 항상 진전처럼 느껴지기 때문이다.
핵심 원칙
- 대부분의 전달 파이프라인에서는 활성 노력이 아니라 대기 시간이 지배적이다. 25% 미만의 플로우 효율은 전형적이며, 망가진 팀의 신호가 아니다.
- 진행 중 작업을 제한하는 것은 처리량을 감소시키는 것이 아니라 증가시키는 경향이 있다, 맥락 전환을 줄이고 대기열을 짧게 만듦으로써.
- 새로운 작업을 시작하는 것은 진전처럼 느껴지지만, 실제로 가치를 전달하는 것은 작업을 끝내는 것이다. 이것들은 같은 것이 아니며, 조직은 일상적으로 그것들을 혼동한다.
- 높은 WIP는 측정되기 전까지는 흔히 보이지 않는다. 팀은 어느 개인이 개별적으로 깨닫는 것보다 훨씬 더 많은 동시적인 작업을 저글링하고 있을 수 있다.
- 이것은 개인 수준이 아니라 시스템 수준의 메트릭이다. WIP 제한을 개인을 벌하는 데 적용하는 것은 이 기법 전체의 취지를 잘못 읽는 것이다.
권장 사항
노력이 병목이라고 가정하기 전에 플로우 효율을 측정하라
주제 2.6의 사이클 타임 단계 데이터를 사용해, 최근 변경의 대표적인 표본에 대해 활성 시간 대 총 경과 시간의 비율을 계산하라. 이것을 처음 측정하는 대부분의 팀은 그 수치가 얼마나 낮은지에 놀라며, 그 놀라움 자체가 가치 있다: 그것은 관심을 “더 열심히 일하라”에서 “대기를 줄여라”로 재조정하며, 이는 거의 항상 더 생산적인 지렛대다.
명시적인 진행 중 작업 제한을 설정하고 눈에 보이게 그것을 강제하라
공유된 보드(물리적이거나 디지털 칸반 보드가 고전적인 구현이다)에서 눈에 보이게, 팀이나 개인이 한 번에 활발하게 진행 중일 수 있는 아이템의 수에 상한을 두라. 제한에 도달하면, 팀의 다음 행동은 새로운 것을 시작하는 것이 아니라 이미 진행 중인 무언가를 끝내는 것을 돕는 것이다. 린 제조업에서 빌려와 칸반에서 공식화된 이 단일한 관행은 소프트웨어 팀에 이용 가능한 가장 일관되게 효과적인 플로우 개선 중 하나이며, 구현하는 데 거의 비용이 들지 않는다.
WIP 제한을 개인 할당량이 아니라 시스템 제약으로 취급하라
WIP 제한은 어느 한 사람이 건드릴 수 있는 양이 아니라 시스템(팀, 공유된 검토 대기열, 공유된 환경)이 한 번에 얼마나 많은 작업을 진행하는지를 관장한다. “당신은 오직 두 개의 티켓만 열어 둘 수 있다”처럼 제한을 개인 성과 할당량으로 적용하는 것은 이 기법을 잘못 적용하는 것이며 이 책 전체가 경고하는 바로 그런 종류의 개인 수준 게임의 위험을 무릅쓴다. 그 제한은 전체 시스템을 통한 흐름을 보호하기 위해 존재하며, 그 시행은 개인적인 상한이 아니라 팀의 규범이어야 한다.
얼마나 오래인지뿐 아니라 왜 작업이 유휴 상태로 있는지 조사하라
플로우 효율 분석이 긴 대기 시간을 드러낼 때, 구체적으로 왜인지 물어보라: 검토자가 이용 불가능해서인가, 공유된 테스트 환경이 예약되어 있어서인가, 다른 팀에 대한 의존성이 아직 도착하지 않아서인가. 이것들 각각은 다른 해결책을 가진다. 이 구체적인 조사 없는 일반적인 “대기 시간을 줄여라”는 지시는 일반적이고 비효과적인 대응을 만들어 내는 경향이 있다.
초기 개선 후 WIP가 다시 기어오르는지 경계하라
WIP 제한을 성공적으로 채택한 팀은 흔히 새로운 이니셔티브를 시작하라는 압박이 돌아오면서 시간이 지남에 따라 그것이 침식되는 것을 본다. “이번만, 우리는 이 긴급한 것도 시작해야 한다.” 모든 WIP 제한 예외를 조용하고 일상적인 무시가 아니라 명시된 이유를 가진 의도적이고 눈에 보이는 결정으로 취급하여, 그 제한의 규율이 조용히 원래 상태로 쇠퇴하지 않게 하라.
트레이드오프: 장단점
| 접근법 | 장점 | 단점 |
|---|---|---|
| WIP 제한 없음 | 유연하게 느껴짐; 새 작업 시작에 마찰이 없음 | 맥락 전환과 대기열이 조용히 모든 것을 느리게 만듦 |
| 팀 수준 WIP 제한 | 처리량과 플로우 효율을 측정 가능하게 개선함 | 특히 마감 압박 아래서 시행하려면 규율이 필요함 |
| 개인 수준 WIP 할당량 | 명시하기 단순함 | 기법을 잘못 적용함; 개인 게임의 위험 |
| 엄격하고 굽히지 않는 WIP 제한 | 최대의 플로우 효율 이점 | 진정으로 긴급하고 예외적인 상황에서 경직되게 느껴질 수 있음 |
핵심 긴장은 유연성 대 플로우다. 긴급해 보일 때마다 새로운 작업을 시작하는 것은 반응적으로 느껴지지만, 플로우 효율과 WIP 연구는 일관되게 이 유연성이 무언가를 빠르게 끝내는 것의 대가로 온다는 것을 보여 주는데, 더 많은 동시 작업은 이미 진행 중인 모든 것에 대해 더 긴 대기열과 더 많은 맥락 전환을 의미하기 때문이다. 엄격하고 예외 없는 규칙이나 무제한적이고 유연한 자유방임 둘 다 대신, 진정한 비상사태를 위한 의도적이고 눈에 보이며 드문 예외 절차와 함께 팀 수준 WIP 제한을 기본값으로 채택함으로써 이 긴장을 해결하라.
팀과 논의할 질문
실제 사이클 타임 데이터로부터 측정한 우리의 실제 플로우 효율은 무엇이며, 그 수치는 우리를 놀라게 하는가? 대부분의 팀은 이것을 계산해 본 적이 없으며 그것이 밝혀지는 것보다 훨씬 더 높다고 가정한다. 이 주제의 다른 무엇이든 논의하기 전에 최근 변경의 표본을 가져와 정직하게 그 비율을 계산하라.
우리는 전체 팀에 걸쳐 실제로 지금 얼마나 많은 진행 중 작업을 가지고 있으며, 세어 보기 전에 누군가 그 수치를 알았는가? 높은 WIP는 각 개인이 오직 자신의 몫만 보기 때문에 명시적으로 측정되기 전까지는 흔히 보이지 않는다. 오늘 아무도 활발하게 손대고 있지 않은 작업을 포함해 현재 진행 중인 모든 것을 세어 보라.
우리가 WIP 제한을 채택한다면, 새로운 긴급한 요청에 대응하는 방식에서 무엇이 바뀌어야 할까? 이 질문은 WIP 제한이 중단시키도록 설계된 실제 조직적 습관, 즉 반사적으로 새로운 작업을 시작하는 것을 드러내며, 제한을 시행하려고 하기 전에 논의할 가치가 있다.
작업이 우리 파이프라인에서 유휴 상태로 있을 때, 구체적인 이유는 무엇이며, 그것은 매번 같은 이유인가? “일들이 대기한다”는 일반적인 감각은 이용 불가능한 검토자, 예약된 공유 환경, 팀 간 의존성 같은 구체적이고 반복되는 원인보다 덜 유용하다. 최근의 실제 사례로부터 실제 패턴의 이름을 대라.
우리가 WIP 제한을 채택했다가 예외를 통해 그것이 조용히 침식되는 것을 본 적이 있는가? 이것은 매우 흔하며 정직하게 논의할 가치가 있다: 무엇이 첫 번째 예외를 초래했으며, 아무도 그것을 명시적으로 결정하지 않은 채 예외가 새로운 정상이 되었는가.
우리 맥락에서 WIP 제한은 개인, 팀, 혹은 공유 자원(검토 대기열이나 테스트 환경 같은) 수준에서 적용되어야 할까? 서로 다른 병목은 다른 수준의 제한을 요구하며, 잘못된 수준에서 제한을 적용하는 것, 즉 공유 대기열 상한 대신 개인 할당량은 기법 전체를 잘못 적용할 수 있다.
분야별 관점
스타트업. 사람이 적으면 WIP는 단순히 동시에 많은 작업을 시작할 만큼 충분한 엔지니어가 없기 때문에 흔히 자연스럽게 낮다. 위험은 정반대다: 창업자나 리드 엔지니어가 자신이 깨닫는 것보다 훨씬 더 많은 동시적인 이니셔티브를 개인적으로 저글링하는 것이며, 이는 공식적인 칸반 도구 없이도 측정할 가치가 있다.
중소기업. 명시적인 열 제한을 가진 단순하고 눈에 보이는 보드, 물리적이든 기본적인 디지털 도구든, 정교한 플로우 메트릭 도구에 투자하지 않고도 대부분의 이점을 얻기에 충분하다. 관대한 제한으로 시작해 팀이 그 규율에 익숙해짐에 따라 점차 조여라.
엔터프라이즈. 높은 WIP는 여기서 특히 흔하고 특히 비싼데, 많은 동시적인 전략 이니셔티브가 같은 공유 엔지니어링 역량을 두고 경쟁하며, 새로운 것을 시작하는 것은 그것을 후원한 사람에게 항상 진전처럼 보이기 때문이다. WIP를 팀 수준뿐 아니라 포트폴리오 수준에서도 눈에 보이게 만들어, 리더십이 현재의 것들을 끝내기 전에 또 다른 이니셔티브를 시작하는 비용을 볼 수 있게 하라.
정부. 다년간의 프로그램은 흔히 각각 개별적으로 정당화되지만 조직 전체에 걸친 총계에 대한 가시성이 없는 많은 워크스트림에 걸쳐 거대한 암묵적인 WIP를 축적한다. 포트폴리오 수준의 WIP 가시성을 비공식적으로라도 도입하는 것은 흔히 모든 것을 병렬로 실행하는 대신 작업의 순서를 지정하는 것에 대한 단 하나의 가장 설득력 있는 주장인데, 높은 WIP의 플로우 효율 비용은 일단 측정되면 눈에 보이게 복합적으로 커지기 때문이다.
사례
엔터프라이즈. 한 금융 서비스 회사의 플랫폼 팀은 단 열두 명의 엔지니어로 열여덟 개의 동시적인 이니셔티브를 저글링하고 있었으며, 이 WIP 대 역량 비율은 새로운 엔지니어링 이사가 그것을 직접 요청할 때까지 아무도 실제로 계산하지 않았다. 팀의 작업 전체에 걸친 플로우 효율은 12% 미만으로 측정되었다. 팀은 두 명의 엔지니어당 하나의 활성 이니셔티브라는 명시적인 WIP 제한을 채택하여, 역량을 계속 얇게 펼치는 대신 여러 낮은 우선순위의 이니셔티브를 의도적으로 중단했다. 분기당 진정으로 완료된 이니셔티브로 측정된 처리량은 팀이 어느 주어진 순간에도 눈에 띄게 “더 적게 하고” 있었음에도 불구하고 두 분기 안에 두 배 이상이 되었다.
정부. 한 국가 인프라 기관의 디지털 전환 프로그램은 각각 자신의 후원자와 자신의 정당화를 가진, 진행 중인 총 작업에 대한 단일한 관점 없이 그 포트폴리오에 걸쳐 마흔 개 넘는 동시적인 워크스트림을 축적해 왔다. 프로그램 수준의 플로우 효율 검토는 중앙값 워크스트림이 그 경과 시간의 15% 미만을 활발한 개발에 썼으며, 나머지는 공유 자원을 기다렸다는 것을 발견했다: 작은 중앙 아키텍처 검토 팀, 공유된 테스트 환경, 그리고 기관 간 승인. 그 프로그램은 마흔 개 모두를 병렬로 실행하는 대신 워크스트림의 순서를 지정하는 명시적인 포트폴리오 수준 WIP 제한을 도입했고, 기관 자체의 추적은 한 번에 실행되는 총 수가 급격히 떨어졌음에도 활성 상태로 남은 워크스트림에 대해 측정 가능하게 더 빠른 완료를 보여 주었다.
비즈니스 사례: 동기, ROI, TCO
플로우 효율과 WIP를 의도적으로 관리하는 것의 수익은 반직관적이지만 잘 문서화되어 있다: 조직이 한 번에 덜 할 때 처리량은 떨어지는 것이 아니라 오르는 경향이 있는데, 더 적은 맥락 전환과 더 짧은 대기열은 각 개별 작업 조각이 더 빠르게 끝난다는 것을 의미하기 때문이다. 위의 금융 서비스 사례, 즉 동시 작업을 의도적으로 줄임으로써 처리량이 두 배가 된 것은 조직이 더 많은 병렬 작업이 항상 더 많은 진전을 의미한다고 가정하는 대신 실제로 플로우 효율을 측정하고 그에 따라 행동할 때의 흔한 패턴이다.
이 규율을 채택하는 총비용은 대체로 기술적인 것이 아니라 조직적이다: 눈에 보이는 보드, 합의된 WIP 제한, 그리고 제한에 도달했을 때 새로운 작업 시작을 거절하는 규율. 그 규율은 채택하는 것보다 유지하는 것이 더 어려우며, 이것이 위의 “WIP가 다시 기어오르는지 경계하라”는 권장 사항이 초기 채택 자체만큼이나 중요한 이유다.
안티패턴과 함정
- 플로우 효율을 측정하지 않고 활성 노력이 전달 시간을 지배한다고 가정하기: 보통 틀렸으며, 개선 노력을 잘못된 지렛대로 오도한다.
- WIP 제한을 시스템 제약이 아니라 개인 할당량으로 적용하기: 기법을 잘못 적용하고 개인 게임의 위험을 무릅쓴다.
- 진전처럼 느껴지기 때문에 반사적으로 새로운 작업을 시작하기: 플로우 효율과 WIP 제한이 중단시키도록 설계된 핵심 습관.
- WIP 제한 예외가 일상적이고 보이지 않게 되도록 두기: 아무도 의도적으로 그렇게 결정하지 않은 채 규율을 원래 상태로 되돌려 침식시킨다.
- 팀 수준에서만 WIP를 측정하고 포트폴리오 수준의 과부하를 놓치기: 많은 동시적인 전략 이니셔티브를 운영하는 대규모 조직에서 흔하다.
- 낮은 플로우 효율 수치를 나쁜 팀의 신호로 취급하기: 이는 대부분의 전달 파이프라인에서 전형적이며 판결이 아니라 조사의 시작점이다.
성숙도 모델
- 1단계, 시작: 진행 중 작업이 추적되지 않는다. 팀은 총 동시 부하에 대한 가시성 없이 반사적으로 새로운 작업을 시작한다.
- 2단계, 개발: 일부 팀이 비공식적인 보드를 사용하지만, WIP 제한이 일관되게 시행되지 않으며 플로우 효율은 결코 계산되지 않는다.
- 3단계, 표준화: 팀은 시스템 수준에서 명시적이고 눈에 보이는 WIP 제한을 가지고 있으며, 플로우 효율은 실제 사이클 타임 데이터로부터 주기적으로 측정된다.
- 4단계, 관리: WIP 제한 예외는 의도적이고 눈에 보이는 결정으로 추적된다. 플로우 효율은 시간에 따른 침식을 위해 모니터링되고 떨어질 때 조사된다.
- 5단계, 조율: WIP는 팀 수준뿐 아니라 포트폴리오 수준에서도 눈에 보이고 관리되며, 조직은 동시 작업을 의도적으로 줄인 결과로 나타난 구체적인 처리량 개선을 제시할 수 있다.
논의를 위한 아이디어
- 실제 데이터로부터 정직하게 계산한 우리의 실제 플로우 효율은 무엇인가?
- 이 논의 전에 아무도 세어 보지 않았던, 우리가 현재 가지고 있는 진행 중 작업의 양은 얼마인가?
- 실제 WIP 제한을 시행하기 위해 우리는 무엇에 거절해야 할까?
- 우리 파이프라인에서 작업이 유휴 상태로 있는 단 하나의 가장 흔한 이유는 무엇인가?
- 우리 조직에서 포트폴리오 수준의 WIP가 보이지 않으며 아마도 너무 높은 곳은 어디인가?
핵심 요약
- 활성 시간 대 총 시간의 비율인 플로우 효율은 실제 전달 파이프라인에서 전형적으로 25% 미만이다. 노력이 아니라 대기 시간이 지배적이다.
- 진행 중 작업을 제한하는 것은 처리량을 감소시키는 것이 아니라 증가시키는 경향이 있다, 맥락 전환을 줄이고 대기열을 짧게 만듦으로써.
- WIP 제한을 시스템 제약으로 적용하고, 결코 개인 할당량으로 적용하지 마라.
- 일반적인 “대기 시간을 줄여라”는 지시 대신 작업이 유휴 상태로 있는 구체적인 이유를 조사하라.
- WIP 제한이 일상적인 예외를 통해 침식되는지 경계하라. 모든 예외를 의도적이고 눈에 보이는 결정으로 취급하라.
- 주제 2.4는 이 양을 플로우 로드라고 부르며 주제 2.7은 그 관계를 리틀의 법칙으로 공식화한다: 어떤 안정적인 대기열에 대해서도 진행 중 작업은 도착률 곱하기 사이클 타임과 같다.
참고 문헌 및 추가 자료
- Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
- Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
- Vacanti, Daniel S. Actionable Agile Metrics for Predictability. Actionable Agile Press, 2015.
- Goldratt, Eliyahu M. The Goal: A Process of Ongoing Improvement. North River Press, 1984.