얼마 전에 트위터에서 우연히 이런 트윗을 보았다.
애자일에서 말하는 칸반 보드는 역전 앞 같은 말이 아닌가… (…
워낙 자주 듣던 이야기이다. 사람들은 소프트웨어 개발 진행 상황을 시각화한 보드를 가리켜 흔히 ‘칸반’이라고 말한다. 나도 급할 때는 무의식 중에 보드를 가리켜 ‘칸반’이라고 이야기하기도 하는데, 그렇게 해도 의사 소통에 별로 문제가 없기 때문이다. “칸반 == 보드”라는 오해는 그 만큼 널리 퍼져있고 뿌리 깊게 자리잡고 있어 벗어나기 쉽지 않다.
곰곰이 생각해보았는데, 그 원인은 크게 두 가지로 볼 수 있을 것 같다.
- 데이비드 J. 앤더슨이 도요타 생산 시스템TPS, Toyota Production System과 제약 이론TOC, Theory Of Constraints의 당김 방식pulling system에서 영감을 얻어 새로운 소프트웨어 개발 방법을 만들면서 거기에 ‘칸반’이라는 이름을 붙였는데, 이는 일종의 메타포로써 사람들에게 쉽게 다가가기 위한 전략이었다고 할 수 있다. 마케팅 측면에서는 성공적이었지만, 그 이름이 지금에 와서는 오히려 사람들에게 혼란을 주고 있다.
- 칸반에서는 보드가 매우 중요한 역할을 수행한다. 그러나 워낙 시각적인 측면이 강렬하기 때문에 보드 이외의 다른 중요한 요소들을 보기가 쉽지 않다. 낮에는 태양의 밝기 때문에 달과 별이 보이지 않는 것과 마찬가지라고나 할까.
많은 사람들이 알고 있는 것처럼 칸반Kanban‘은 看板간판을 일본식으로 발음한 것이다. 간판의 사전적 의미는 ‘기관, 상점, 영업소 따위에서 이름이나 판매 상품, 업종 따위를 써서 사람들의 눈에 잘 뜨이게 걸거나 붙이는 표지’이지만 여기에서는 그런 의미가 아니다. 칸반이라는 단어에는 (연관성은 있으나) 서로 다른 세 가지 정의가 있다.
1. 도요타 생산 시스템에서의 칸반
위는 도요타에서 실제로 사용하던 칸반의 모습인데, 생산 도중 추가로 부품이 필요할 때 이 카드를 작성하여 프로세스의 전 단계로 보내면, 카드를 받은 곳에서는 카드를 보내온 곳에서 필요한 부품을 생산한다. 즉, 도요타 생산 시스템(린 제조 프로세스)에서 프로세스 전 단계로 보내는 물리적 주문서가 칸반의 첫 번째 정의다.
2. 당김 방식의 신호로써의 칸반
도요타에서 이런 방식으로 생산 프로세스를 운영했던 가장 큰 목적은 적시 생산JIT, Just-In-Time을 위해서다. 프로세스의 전 단계에서 미리 예측한 양만큼 생산한 부품을 다음 단계로 밀어내는push 것보다, 프로세스 이전 단계에서 필요한 부품을 당겨와pull 생산하면 필요한 때에 필요한 만큼만 제품을 생산해낼 수 있고 그 재고량은 최소화할 수 있다. 여기에서 칸반은 작업 시작을 알려주는 역할을 한다. 즉, 당김 방식에서 사용하는 새로운 작업을 시작할 수 있다는 신호가 칸반의 두 번째 정의다.
그렇다면 소프트웨어 개발의 칸반에서는 무엇이 ‘새로운 작업을 시작할 수 있다는 신호’의 역할을 할까? 바로 진행 중 업무(WIP)의 양을 제한한 값에서 현재 진행 중인 업무 항목 수를 뺀 값이 0보다 크다면 그것이 바로 새로운 작업 시작의 신호가 된다. 이것을 논리적으로 표현하면 다음과 같다.
if ( 0 < ('WIP Limit' - 'WIP') ) {
pull();
}
도요타 생산 시스템에서의 칸반과 비교해보았을 때 가장 두드러지는 차이점은 바로 물리적 실체가 없다는 점이다. 그래서 소프트웨어 개발에서 이야기하는 칸반을 가상 칸반 시스템virtual kanban system이라고 말한다.
3. 소프트웨어 개발 방법으로써의 칸반
칸반의 마지막 정의는 데이비드 J. 앤더슨이 만든 소프트웨어 개발 방법으로써의 칸반이다. 이런 혼란을 막기 위해서인지는 모르겠으나, 요즘 해외 커뮤니티에서는 소프트웨어 개발 방법인 칸반을 Kanban Method라고 부른다. 모두 여섯 가지 핵심 요소가 모두 포함되어 있어야 칸반 메소드라고 할 수 있다. 시각화만이 전부가 아니다.
- 시각화한다.
- 진행 중 업무(WIP)를 제한한다.
- 흐름을 관리한다.
- 정책을 명시화한다.
- 피드백 루프를 실행한다.
- 함께 개선하고 실험을 통해 발전시킨다.
요약하자면, 원래 칸반은 ‘도요타 생산 시스템에서 프로세스 이전 단계에서 새로운 업무를 당겨오는 신호 역할을 하는 카드’라고 할 수 있다. 우리는 이 단어를 소프트웨어 분야의 개발 방법 중 하나인 칸반의 이름으로 사용하고 있는 것이다. 따라서, 따라서 칸반 메소드에서는 보드를 칸반이라고 볼 수 없으며, 포스트잇을 칸반이라고 할 수도 없다. 칸반(소프트웨어 개발에서의 칸반 메소드)에는 칸반(즉, 당김 신호 역할을 하는 카드)이 없다.
물론 보드를 가리켜 칸반이라고 불러도 의사 소통이 안되는 것은 아니며, 무슨 큰 일이 나는 것은 더더욱 아니다. 하지만 칸반을 단순히 업무 시각화 방식으로 인식하는 오해가 여기에서 비롯된 것이라 생각하면 가볍게 생각할만한 것은 아니라고 생각한다.
다시 한 번 더 강조하지만, 칸반에는 칸반이 없다.