칸반이 효과적인 이유, 그리고 우리 팀에 맞는지 확인하는 법

대부분의 팀은 누군가 블로그 글을 읽었다는 이유로 칸반을 도입합니다. 더 현명한 질문은 칸반이 해결해 주는 문제가 우리 팀이 실제로 겪고 있는 문제인가 하는 것입니다.

구성원이 여덟아홉 명을 넘길 즈음, 대부분의 팀이 공감하는 순간이 찾아옵니다. 일은 되고 있습니다. 이메일이 오가고, 기능이 출시되고, 고객 관리도 이루어집니다. 그런데 다른 사람들이 무엇을 하고 있는지는 아무도 명확히 알지 못합니다. 프로젝트는 쌓여 가고, 약속은 해 놓고 조용히 잊힙니다. 회의 전마다 어떤 업무가 지금 어디까지 왔는지 파악하느라 20분을 씁니다. 답은 대개 "어딘가에"입니다.

칸반이 해결하려고 만들어진 문제가 바로 이것입니다. 전략을 세우거나, 좋은 사람을 채용하거나, 문화를 만드는 문제가 아니라, 팀이 무엇을 하고 있고 무엇이 발목을 잡고 있는지 파악하는, 구체적이고 지겹도록 반복되는 운영상의 문제입니다.

이렇게 큰 관심을 받아 온 것에 비하면 놀랍도록 소박한 도구입니다. 칸반은 조직을 고쳐 주겠다고 주장하지 않습니다. 단지 일을 눈에 보이게 만들 뿐입니다. 그런데 이 가시성을 꾸준히 적용하면 그 이후의 놀랄 만큼 많은 것이 달라집니다.

칸반은 어디서 시작되었을까

칸반은 일본어로 "간판" 또는 "게시판"을 뜻하며, 1940년대 후반 도요타가 제조 공장의 재고를 관리하기 위해 개발한 방식입니다. 발상은 단순했습니다. 부품을 정해진 일정에 따라 생산하는 대신, 다음 공정이 필요하다는 신호를 보낼 때만 생산하는 것입니다. 칸반이라는 물리적 카드가 요청서로서 생산 라인을 거슬러 올라갔습니다. 예측에 따른 생산은 없었고, 불필요하게 쌓이는 것도 없었습니다.

도요타가 얻었고 이후 소프트웨어 팀이 빌려 온 통찰은, 시스템의 비효율 대부분이 사람이 너무 느리게 일해서가 아니라 잘못된 일을 잘못된 때에 하고 있어서 생긴다는 점입니다. 한꺼번에 너무 많은 일을 시작합니다. 아무도 눈치채지 못하다가 너무 늦게야 드러나는 병목이 있습니다. 끝난 일은 한쪽에 놓여 있는데 다음 단계는 다른 곳에서 일에 짓눌려 있습니다.

특히 2000년대 초 Microsoft 같은 기업의 소프트웨어 개발자들이 이 개념을 지식 노동에 맞게 응용하기 시작했습니다. 카드는 과제가 되었고, 공장의 공정은 워크플로의 단계가 되었으며, 간판은 보드가 되었습니다. 처음에는 물리적인 보드였다가 이후 디지털로 옮겨 갔고, 팀원 누구나 무엇이 진행 중이고, 무엇이 대기 중이며, 무엇이 끝났는지 한눈에 볼 수 있게 되었습니다.

칸반 보드가 실제로 보여 주는 것

기본 칸반 보드는 할 일, 진행 중, 완료의 세 열로 이루어집니다. 많은 소규모 팀에는 이것으로 충분하며 시작점으로도 좋습니다. 하지만 진짜 가치는 이 단계를 우리가 바라는 흐름이 아니라 실제 일이 흘러가는 방식에 맞게 바꾸기 시작할 때 나타납니다.

콘텐츠 팀이라면 아이디어, 브리프, 초안 작성 중, 검토 중, 발행 예약, 발행 완료로 나눌 수 있습니다. 소프트웨어 팀은 "진행 중"을 개발, 코드 리뷰, QA의 별도 열로 나눌 수 있습니다. 컨설팅 팀은 탐색, 제안, 진행, 고객 회신 대기, 종료를 관리할 수 있습니다. 단계는 일이 다른 사람에게 넘어가거나 다른 일이 일어나기까지 대기하는 지점, 즉 실제 인수인계와 실제 대기 시간을 반영해야 합니다.

가운데 열의 카드를 보세요. 8일째 진행 중이고 차단됨으로 표시된 창고 감사 보고서입니다. 보드가 없는 시스템이라면 이 과제는 아무도 움직이지 않는다는 사실을 알아차리지 못한 채 2주는 더 방치될 수 있습니다. 누군가가 외부 업체의 회신을 기다리고 있을 수도 있고, 자신이 병목인 줄 모르는 관리자의 결정이 필요한 상황일 수도 있습니다. 보드는 정체를 눈에 보이게 만듭니다. 그것이 일의 대부분입니다.

칸반을 작동하게 하는 규칙: WIP 제한

칸반을 제대로 쓰는 팀과 그저 더 예쁜 할 일 목록을 가진 팀을 가르는 개념을 하나만 꼽자면, 진행 중 작업 제한(WIP 제한)입니다. 각 열에 동시에 둘 수 있는 항목 수의 최대치를 정하는 것입니다. 열이 가득 차면 무언가가 빠져나가기 전에는 새 작업을 추가할 수 없습니다.

직관에 반하는 것처럼 느껴집니다. 진행 중인 과제를 더 많이 둘 수 있으면 더 많이 처리하는 것 아닐까요? 그렇지 않습니다. 사람들이 여러 일을 동시에 하면 실제로는 모든 일이 더 오래 걸립니다. 컨텍스트 전환에는 큰 비용이 듭니다. 반쯤 끝난 일은 조율 비용을 만들어 냅니다. 그리고 열 가지가 "진행 중"이면 어떤 일이 실제로 움직이고 있고 어떤 일이 표시도 없이 멈춰 있는지 구분하기가 매우 어렵습니다.

"진행 중" 열의 WIP 제한이 3이라면, 네 번째 일이 누군가의 책상에 도착했을 때 팀원 중 누군가는 결정해야 합니다. 기존 과제 중 무엇을 먼저 끝낼 것인가. 우선순위를 정하게 만들고, 대화를 하게 만듭니다. 그 결과 새 일을 시작하는 속도가 느려지더라도 개별 항목은 더 빨리 완료되는 경향이 있습니다.

칸반 vs. 스크럼: 팀들이 늘 묻는 질문

소프트웨어 팀이나 현대적인 운영 방식 주변에 조금이라도 있었다면 스크럼을 접했을 것입니다. 업무를 2주 단위의 고정된 스프린트로 나누고, 계획 회의와 회고, 스크럼 마스터와 프로덕트 오너 같은 정해진 역할을 두는 프레임워크입니다. 많은 팀이 스크럼과 칸반을 경쟁 관계의 방법론으로 보고 둘 중 하나를 골라야 한다고 느낍니다. 하지만 차이는 그보다 단순합니다.

많은 팀, 특히 순수한 소프트웨어 엔지니어링 팀이 아닌 팀은 스크럼의 의식이 무겁고 고정 스프린트 구조를 지속적인 운영 업무에 적용하기 어색하다고 느낍니다. 마케팅팀, 고객 성공팀, 운영팀, 모든 일을 한꺼번에 챙기는 창업자의 업무는 2주 주기에 깔끔하게 들어맞는 경우가 드뭅니다. 지속적인 흐름을 중시하는 칸반이 이들에게 더 잘 맞는 경향이 있습니다.

그렇다고 해도 많은 팀이 둘을 함께 씁니다. 제품 개발에는 스프린트 방식의 계획 주기를 쓰고, 어느 스프린트에 있든 상관없이 들어오는 운영·지원 업무에는 칸반 보드를 운영하는 것입니다. 충분히 합리적인 하이브리드 방식입니다.

보드가 30초 안에 답해 줘야 할 세 가지 질문

칸반 보드는 누구와 이야기하지 않고도 다음 세 가지 질문에 빠르게 답할 수 있을 때 가장 유용합니다. 지금 팀은 무엇을 하고 있는가? 일은 어디서 막히고 있는가? 해야 하는데 아직 시작하지 않은 일은 없는가?

보드를 보고 30초 안에 세 질문에 모두 답할 수 없다면, 아마 제대로 관리되고 있지 않은 것입니다. 가장 흔한 실패 유형은 과제는 만들어지는데 한 번도 옮겨지지 않는 보드입니다. 실제 업무를 보여 주는 살아 있는 지도가 아니라 좋은 의도의 무덤이 되어 버립니다. 최신 상태가 아닌 보드는 보드가 없는 것보다 나쁩니다. 가시성에 대한 잘못된 안도감을 주기 때문입니다.

보드를 유지하는 데 필요한 규율은 분명히 존재합니다. 일이 움직이면 과제도 옮겨야 합니다. 차단된 항목은 2주 뒤가 아니라 멈추는 즉시 표시해야 합니다. 카드에는 명확한 담당자가 있어야 하고, 담당자는 자기 카드를 갱신해야 합니다. 시간이 많이 드는 일은 아닙니다. 잘 운영되는 칸반이라면 한 사람이 하루 5~10분이면 충분합니다. 하지만 꾸준함이 필요합니다. 칸반의 혜택을 가장 많이 누리는 팀은 보드를 보조 기록이 아니라 단일 진실 공급원으로 대하는 팀입니다.

칸반이 해 주지 않는 것

칸반은 전략 도구가 아닙니다. 무엇을 해야 할지 정하는 데는 도움이 되지 않고, 이미 하기로 한 일을 관리하는 데만 도움이 됩니다. 조직에 우선순위 문제나 권한이 불분명한 문제, 혹은 프로세스가 아니라 리더십 행동에서 비롯된 "예전 프로젝트를 끝내기도 전에 너무 많은 프로젝트를 시작한다"는 문제가 있다면, 칸반 보드는 그 문제를 드러낼 뿐 해결해 주지는 못합니다.

좋은 관리를 대체하는 것도 아닙니다. 보드는 1:1 면담이나 신중한 업무 위임, 특정 업무가 왜 중요한지에 대한 명확한 소통을 대신하지 못합니다. 팀들은 때때로 프로세스 도구를 도입하면서, 실은 관리자의 몫인 관계와 조직 차원의 일을 프로세스가 대신해 주기를 기대합니다. 그렇게 되지 않습니다.

칸반이 해 주는 일은 대부분의 팀을 느리게 만드는 주변의 불확실성을 줄이는 것입니다. "누가 무엇을 하고 있는가", "이건 끝났는가", "다음엔 무엇을 맡아야 하는가" 같은 질문은 공유되고 눈에 보이는 시스템이 없는 조직에서 엄청난 양의 가치 낮은 커뮤니케이션을 낳습니다. 칸반은 그 소음 대부분을 없애 줍니다. 그 소음이 가장 큰 문제인 팀에게는 차이가 상당합니다.

사흘짜리 워크숍 없이 시작하는 법

제가 본 가장 좋은 칸반 도입 사례는 작게 시작해서 발전한 경우였습니다. 가장 나쁜 사례는 컨설턴트를 부르고 이틀간 오프사이트를 열어 아름답게 설계한 보드를 만들었지만 3주 차에는 아무도 쓰지 않던 경우였습니다.

있는 그대로의 팀과 실제로 가진 업무에서 출발하세요. 백로그, 진행 중, 완료의 세 열을 만드세요. 팀과 30분을 들여 현재 진행되는 모든 업무를 카드에 옮기세요. 규칙은 하나만 정합니다. 무언가를 시작하면 보드에 올리고, 일이 움직이면 카드를 옮깁니다. 2주 동안은 그 외에 아무것도 하지 마세요.

2주 뒤 팀원들과 함께 보드를 살펴보세요. 어디에 일이 쌓였나요? 모두가 우선순위라고 했는데 백로그에 그대로 남은 것은 무엇인가요? 예상보다 빨리 움직인 것은 무엇인가요? 무엇이 왜 막혔나요? 관찰한 내용을 바탕으로 열을 다듬고 구체성을 더하세요. "진행 중"을 "진행 중"과 "외부 회신 대기"로 나눠야 할 수도 있고, 계속 누락되는 단계라면 "검토 중"이라는 열이 필요할 수도 있습니다. 방법론 책이 말하는 모습이 아니라 실제 업무가 드러내는 것에 따라 보드가 발전하도록 하세요.

더 긴 안목으로: 플로우 지표

칸반 시스템이 돌아가기 시작하면 대부분의 팀이 활용하지 않는 데이터가 쌓입니다. 과제가 생성된 때부터 완료될 때까지의 총 시간인 리드 타임이 가장 중요합니다. 일반적인 과제의 평균 리드 타임이 12일인데 5일로 줄이고 싶다면, 목표로 삼을 숫자와 나머지 7일이 어디로 가는지 보여 줄 보드가 이미 있는 셈입니다.

사이클 타임은 과제가 백로그에 머문 시간을 제외하고 실제로 작업한 기간만 측정합니다. 처리량은 팀이 매주 완료하는 항목 수를 측정합니다. 카드가 생성되고 종료된 시점을 꾸준히 기록한다면 이 지표 중 어느 것도 특별한 소프트웨어가 필요하지 않습니다. 그리고 이 지표들을 함께 보면 추정 기반 계획 프로세스보다 훨씬 솔직하게 팀의 역량을 알 수 있습니다.

대부분의 중소 규모 팀은 여기까지 가지 않습니다. 칸반을 가시성 도구로 쓰는 것만으로도 충분히 가치 있으며, 더 나아가지 않습니다. 그래도 괜찮습니다. 하지만 이해관계자에게 언제 끝날지 약속해야 하거나, 어떤 일은 왜 예상보다 세 배나 오래 걸리는지 알고 싶어진다면 필요할 때 그 지표가 준비되어 있습니다.