[Software Enginnering] 애자일(Agile) 칸반(Kanban): WIP 제한과 병목현상

 

이전 포스팅에서 스크럼의 2주짜리 타임박싱(스프린트)과 핵심 이벤트들을 다루었다.

https://hsunnystory.tistory.com/265

[Software Enginnering] 애자일(Agile) 스크럼 실전: 이벤트와 산출물

 

하지만 실무를 하다 보면 완벽한 플래닝에도 불구하고 문제가 생긴다. API 개발은 일찌감치 끝났는데 프론트엔드 연동을 기다리느라, 혹은 기획팀의 QA대기로 인해 지라(Jira) 보드의 In Progress 컬럼에 티켓이 수십 개씩 쌓여있는 경험을 해본 적이 있을 것이다. 결국 배포일이 다가오면 막혀있던 병목이 한꺼번에 터지며 야근이로 이어진다.

 

이러한 막힘 현상을 해결하고 작업의 흐름을 극대화하기 위해 도입하는 것이 바로 칸반(Kanban)이다. 이번 포스팅에서는 칸반의 핵심 원리인 WIP 제한을 다루면서, 이것이 서버의 트래픽 제어 아키텍처와 얼마나 닮아있는지 엔지니어링 관점에서 비교해 본다.

 

1. 스크럼(Scrum)과 칸반(Kanban)의 차이점

현대의 많은 애자일 팀은 스크럼과 칸반을 섞은 스크럼반(Scrumban)형태를 띠지만, 두 가지의 근본적인 포커스는 다르다.

 

 - 스크럼(Scrum) : 시간을 제어한다. 2주라는 고정된 타임박스 안에 얼마나 많은 작업을 약속하고 끝낼 수 있는지에 집중한다.

 - 칸반(Kanban) : 흐름을 제어한다. 타임박스보다 중요한 것은 티켓이 생성되어 배포되기까지의 리드 타임(Lead Time)을 줄이는 것이다. 이를 위해 각 작업 단계(컬럼)에 머물 수 있는 티켓의 수를 엄격하게 제한한다.

 

2. 칸반 WIP(Work In Progress) 제한

칸반 보드를 단순히 할 일, 진행 중, 완료로 나누어 놓은 화이트보드라고 생각하면 오산이다. 칸반의 진짜 가치는 WIP 제한에서 나온다.

개발팀의 In Progress 컬럼의 WIP 제한이 3이라고 가정해보자. 현재 개발자 3명이 각자 1개씩 티켓을 잡고 개발 중이라면, 누군가 새로운 급한 요청을 가져오더라도 기존 티켓 중 하나를 완료(Done)로 넘기기전까지는 절대 새로운 작업을 시작할 수 없다.

 

 - 멀티태스킹의 환상 파괴 : 인간의 뇌는 컨텍스트 스위칭(Context Switching)에 막대한 에너지를 소모한다. 작업 5개를 동시에 20%씩 진행하는 것보다, 1개를 100% 끝내고 다음으로 넘어가는 것이 압도적으로 빠르다.

 - 슬로건 : Stop Starting, Start Finishing

 

3. [Bad vs Good] 팀의 WIP 제한과 서버의 스레드 풀(Thread Pool)

흥미롭게도, 칸반의 WIP 제한 원리는 서버가 대규모 트래픽을 처리할 때 시스템의 병목을 막고 장애를 예방하는 아키텍처적 원리와 정확히 일치한다.

무제한의 작업을 동시에 수용하려는 팀(WIP 제한 없음)과, 동시 처리량을 엄격히 통제하는 팀(WIP 제한 있음)의 차이를 시스템에 비유해보자.

 

[Bad] WIP 제한이 없는 무한대 대기열 (장애 유발)

기획팀이 요청하는대로 모든 작업을 다 진행중으로 끌고 오는 팀이다. 서버 아키텍처로 치면 제한 없는 스레드 풀을 사용하는 것과 같다. 요청이 들어오는 족족 스레드를 생성하여 처리하려고 시도한다.

결과는 뻔하다. 컨텍스트 스위칭 비용이 폭발하여 CPU가 멈추고, DB 커넥션 풀이 고갈되며, 결국 Out Of Memory으로 시스템 전체가 뻗어버린다. 팀원들은 번아웃에 빠지고, 배포되는 기능은 하나도 없다.

[Good] WIP 제한(Backpressure)을 적용한 견고한 시스템

건강한 애자일 팀은 본인들이 감당할 수 있는 한계치를 명확히 설정한다. 시스템에서는 이를 세마포어(Semaphore)나 제한된 스레드 풀을 통한 백프려셔(Backpressure)라고 부른다. 팀이 동시에 처리할 수 있는 작업의 수를 5로 제한하고, 꽉 찼다면 더 이상 새로운 요청을 받지 않고 백로그(Backlog)에 대기시킨다. 당장 눈앞의 테스크를 쳐내는 속도는 느려 보일지 몰라도, 컨텍스트 스위칭이 최소화 되어 전체적인 처리량은 훨씬 높아지고 팀은 지치지 않는다.

 

4. 병목의 가시화와 리드 타임(Lead Time)의 단축

칸반 보드를 운영하다 보면 신기한 현상을 발견할 수 있다. 개발팀의 WIP는 여유가 생겼는데, 그 다음 단계인 QA대기 컬럼에 티켓이 잔뜩 쌓여 병목이 발생하는 경우다.

이때 개발자의 올바른 대처는 무엇일까? "내 코딩은 끝났으니 새 기능 개발이나 해야지"라며 새로운 티켓을 In Progress로 당겨오는 것은 최악의 선택이다. 이는 꽉 막힌 병목 앞단에 트래픽을 더 쏟아붓는 격이다.

진정한 칸반의 팀플레이는 새로운 코드 작성을 멈추고, 다 같이 병목 지점으로 달려가 문제를 뚫어내는 것이다. 테스트 코드를 보강해 주거나, QA 시나리오 작성을 돕거나, 심지어 직접 메뉴얼 테스트에 참여하여 앞단에서 완성된 코드가 실제 배포로 빠져나갈 수 있도록 돕는 것이 리드타임을 단축하는 유일한 길이다.

 

5. 결론

개발자는 DB 커넥션 풀 사이즈를 튜닝하고, 카프카 파티션 갯수를 고민하며 시스템의 병목을 해결하는 데 도가 튼 전문가들이다.

우리가 일하는 방식도 시스템 구조와 똑같다. 팀의 인지적 리소스와 체력은 무한하지 않다. 지라 보드에 무의미하게 쌓여가는 In Progress 티켓들을 보며 무력감을 느끼고 있다면, 당장 이번 회고 시간에 "우리 팀의 적정 WIP는 몇 개 인가?" 를 화두로 던져보라. 새로운 것을 끝없이 시작하는 짜릿함보다, 지루하더라도 하나의 작업을 완전히 끝마치고 배포하는 것. 그것이 애자일 팀이 폭발적인 퍼포먼스를 내는 진짜 비결이다.