원문: How Kanban Works by Amr Noaman Abdel-Hamid

최근들어 소프트웨어 개발과 지속적 개선을 관리하는 단순하고 효과적인 방법으로 “칸반”이 점점 인기를 얻고 있다. 하지만 칸반이 작동하는 원리(또는 이유)는 도대체 무엇일까? 보이지 않던 시스템을 겉으로 드러내어, 전달받은 요청을 시각적으로 추적할 수 있기 때문일까? 아니면 진행 중 업무(WIP, work-in-progress)를 제한하고 낭비가 되는 효과 또는 작업 전환을 줄이기 때문일까? 그것도 아니라면 사이클 타임(Cycle Time)이나 처리량(Throughput) 같은 단순한 측정치를 통해 관리자에게 주기적 피드백을 주기 때문일까? 이 글에서 우리는 대기행열이론(Queuing Theory)과 리틀의 법칙(Little’s Law)의 관점에서 칸반을 자세히 파헤쳐 볼 것이다. 또한, 몇 가지 사례를 살펴보고 칸반 개발 시스템에서 관리자가 만나게 될 세 가지 전형적 문제 및 그 해결 방법을 설명하려 한다. 이를 통해 칸반의 작동 원리에 대한 기본적 개념과 통찰력 있는 아이디어를 얻을 수 있다.

소프트웨어 시스템에서 리틀의 법칙

리틀의 법칙(존 리틀(John Little)의 이름을 딴 것이다)은 칸반의 기초가 되는 아이디어다. 소프트웨어 개발에서는 리틀의 법칙을 다음과 같이 설명할 수 있다.

WIP = Th * CT

  • WIP(진행 중 업무) = 개발 시스템에서 완료되지 않은 항목(버그, 사용자 스토리, 변경 요청 등)의 평균량
  • Th(처리량) = 단위 시간 동안 팀의 출력
  • CT(사이클 타임) = 팀이 한 항목을 마치는 데 걸리는 평균 시간

리틀의 법칙이 보여주는 역동은 놀랍다. 리틀의 법칙은 소프트웨어 개발과 관련한 많은 문제를 설명해주며 해결책을 제시한다. 다음 사례 연구들에서 볼 수 있는 역동을 분석하기 위해, “효과도(Diagrams of Effects)”를 사용할 것이다. 효과도는 비선형 시스템 분석에 훌륭한 도구다. 또한 복수의 효과가 시스템의 행동에 영향을 미치는 경우를 분석할 때에도 유용하게 사용할 수 있다.

사례 1: 팀 처리량 증가

애덤은 회사 내 여러 제품의 유지 보수를 담당하는 팀의 코치다. 그 팀에는 두 명의 개발자와 한 명의 테스터가 있다. 2013년, 그 회사는 제품 마케팅에 많은 돈을 투자했고, 그 결과 관리해야 할 고객이 두 배로 늘어난 상태였다. 애덤의 팀이 전달받는 고객 지원 요청 건수가 점점 늘어나기 시작했다. 그러나 CEO는 팀에 추가 인원을 투입할 마음이 없었다.

이 사례에서, 점점 늘어나는 고객 요청 건수에 전부 대응하려면, 팀은 처리량을 증가시켜야 한다. 리틀의 법칙(Th = WIP / CT)에 의하면, 팀 처리량이 증가시키려면 사이클 타임을 줄이거나 WIP를 늘려야한다. 팀의 수용량(Capacity)은 고정된 상태이기 때문에 사이클 타임을 줄이기는 어렵다. 따라서 WIP를 늘리는 것이 쉬운 해결책이다.

질문: WIP를 증가시키면 처리량이 늘어나게 될까? 정답은 “아니오”다. WIP가 더 커지면 한계점까지는 처리량이 증가하다가, 그 후 다음 그래프처럼 감소하기 시작한다.

아래 그래프가 보여주는 것처럼, WIP가 늘어나면 팀이 최대 가용 처리량(초록색 영역)에 도달하기 전까지 업무를 최적화하고 출시 프로세스의 낭비를 제거하게 만들 수 있다.(노란색 영역) 그 이후에도 WIP가 계속 늘어난다면 더 이상의 개선이 이루어지긴 어렵다. 오히려 스트레스와 작업 전환으로 인해 팀의 처리량이 감소할 것이다.(빨간색 영역)

빨간색 영역에서 팀은 외부 요소에 의해 극도로 억눌리게 되고, 내부 문제로 인해 생산성이 감소한다. 다음 효과도는 빨간색 영역에서 나타나는 팀의 역동을 분석한 것이다.

이 그림은 팀 수용량 이상으로 WIP가 증가했을 때 발생하는 효과를 보여주고 있다. 이렇게 되면 고객과의 의사소통, 작업 전환, 스트레스가 늘어날 것이다. 스트레스를 받고 있는 상태에서 업무를 진행하고 작업 전환이 빈번하게 발생하면, 더 많은 버그가 발생하게 되고, 처리량이 줄어들며, 결국 생산성이 감소한다.

이러한 과정이 미치는 영향을 완전히 이해하기 위해, 다음 그림은 강화 효과를 보여준다. WIP 증가는 생산성 감소로 이어지는데, WIP가 늘어나면 처리하지 못한 채 쌓여가는 요청이 늘어가고 그것이 다시 WIP를 증가시킨다. 이 시스템에서는 팀이 완전히 망할 때까지 계속 반복해서 처리량을 감소한다!

(두 가지 음성 효과가 잇달아 나타나면 그것은 양성 효과다.)

요약하자면, 수용량이 고정되어 있고 처리량을 증가시키길 원한다면 팀의 크기를 늘릴 수도 있고 WIP를 늘릴 수도 있다. 이것이 불가능하다면 단 한 가지 선택만 남아있다. 그것은 바로 사이클 타임을 줄이는 것이다. 사이클 타임을 줄이면 모든 낭비를 발견하고 제거할 수 있다.

사례 2: 사이클 타임 안정화

이스마일은 고객의 변경 요청 처리를 담당하고 있는 개발 관리자다. 변경 요청은 서비스 수준 협약서(SLA, Service Level Agreement)에서 정해 놓은 시간 내에 처리해야 한다. 이스마일과 팀이 전달받는 고객 요청의 입력율은 예측할 수 없다. 사이클 타임이 SLA을 벗어날 정도로 그 변동이 평상시보다 더 심한 경우도 있으며, 입력율이 낮아서 팀의 모든 수용량을 소모하지 못하는 경우도 있다. 다음 그림은 입력율이 높아지면 사이클 타임이 증가하는 이유를 설명한다.

사이클 타임 안정화에 대해, 리틀의 법칙은 사이클 타임이 WIP에 정비례하며 처리량에 반비례한다는 의미를 담고 있다. 따라서 이스마일이 이 두 가지 변수를 안정화시킬 수 있다면, 사이클 타임도 안정화될 것이다.

그렇게 하려면, 이스마일은 입력율 변동에 맞추어 WIP와 팀 수용량(팀원 수 또는 팀이 고객 요청 처리에 사용하는 시간)을 모두 제어할 수 있어야 한다. 이 두 가지 변수는 사이클 타임에 이중으로 영향을 미치며, 팀 수용량이 증가하면 사이클 타임이 감소할 것이다. 그래서 두 가지 효과가 상쇄된다.

따라서 요약하자면, 팀이 입력율 변동을 겪고 있다면 두 가지 변수를 제어할 수 있어야 한다. 그것은 바로 WIP 제한과 팀 수용량이다. 이 두 변수를 제어함으로써 팀은 사이클 타임을 안정화시키고 팀 활용도를 최적화할 수 있다.

사례 3: 과도한 긴급 처리

긴급 업무(칸반 보드에서 우선 처리 레인을 사용한다)는 반복되는 장애 보고와 불량 서비스 요청(특히, 불만 고객)을 처리하는 손쉬운 해결책일 수 있다. 특별한 경우 또는 심하게 항의하는 고객을 대응할 때, 아무런 규칙도 없이 긴급 처리를 진행하는 경우가 많다.

긴급 처리 레인을 사용하면 팀의 시간과 노력을 소모하게 되고, 개발 속도가 늦어지며 평균 사이클 타임이 증가할 것이다. 이런 상황에서는 리틀의 법칙에 따라 팀의 처리량이 실질적으로 줄어들게 된다.

그러나, 사이클 타임과 처리량의 선형 관계가 실제로는 다음과 같이 바뀐다.

더욱 심한 경우라면, 팀은 긴급 처리 레인에 있는 작업 간 전환이 이루어지며, 진행 중인 작업을 그냥 두고 다른 요청을 즉시 처리하기 시작한다. 그렇게 즉석에서 변환이 일어나면 처리량은 더욱 심한 또 다른 부정적 영향을 받게 된다. 다음 그림은 이러한 상황을 설명한다.

세 번째 사례를 요약하자면, 긴급 처리 레인의 함정을 깨달아야 한다. 긴급 항목은 팀 생산성에 전반적으로 부정적 영향을 미치며, 평균 사이클 타임을 증가시킨다. 긴급 항목이 일부 비상 사태에는 유용할 수도 있지만, 의도치 못한 다른 부정적 역동도 함께 발생할 수 있다.

결론

이 세 가지 사례를 통해 대기행열이론의 관점에서 칸반이 작동하는 원리를 살펴보았다. 칸반은 아주 단순하고 매우 효과적인 관리 도구다. 관리자나 팀 리더에게는 WIP나 팀 수용량처럼 제어할 수 있는 여러 변수가 있다. 또한 사이클 타임이나 처리량과 같이 쉽게 측정할 수 있으며 프로세스의 효율성이 어떠한지 주기적으로 피드백을 얻을 수 있는 프로세스 측정치가 있다. 우리는 세 가지 사례에서 칸반을 사용할 때 생길 수 있는 기본적인 세 가지 문제를 다루어 보았다.

  1. 팀 수용량을 살펴보고 팀이 그 수용량을 넘어선 과도한 업무에 시달리지 않도록 한다. WIP와 처리량을 그래프로 그려보면 팀이 견뎌낼 수 있는 최대 WIP를 알 수 있다.
  2. 개발 프로세스를 안정화시키려면 한 가지 이상의 변수를 제어해야 할 수도 있다. 두 번째 사례에서는 WIP와 팀 수용량을 제어해서 안정적 사이클 타임을 얻을 수 있었다.
  3. 긴급 처리 레인의 함정을 인식해야 한다. 본질적으로 긴급 처리 레인은 프로세스 위반의 백도어(back door)다. 신중하게 사용하지 않으면 팀 생산성이 악화될 수 있다.