칸반

팀이 무엇을 하고 있느냐고 묻는 자리에서 가장 자주 나오던 답은 "진행 중입니다" 였습니다. 여덟 명이 각자 서너 건씩 붙들고 있으면 스물네 건이 전부 진행 중이고, 그중 이번 주에 끝나는 것이 몇 건인지는 아무도 답하지 못합니다. 일이 어디에 얼마나 쌓여 있는지 보이지 않으니 늦어지는 이유도 보이지 않았습니다.

그래서 월요일 회의는 늘 같은 모양으로 흘러갔습니다. 열두 개 항목을 하나씩 짚으면 담당자가 "거의 다 됐습니다" 라고 답하고, 다음 주 월요일에 같은 열두 개를 다시 짚으면 같은 답이 돌아옵니다. 실제로 막혀 있던 것은 그중 넷이었는데, 그 넷이 왜 막혔는지는 회의록 어디에도 남지 않았습니다. 모두가 바쁜데 끝나는 것은 없는 상태가 이어졌습니다.

동시에 많이 붙들고 있으면 더 많이 나갈 것 같지만 실제로는 반대로 움직입니다. 한 사람이 세 건을 번갈아 잡으면 건마다 다음에 손댈 때 어디까지 했는지를 다시 떠올려야 하고, 그 되짚는 시간이 건수만큼 늘어납니다. 게다가 세 건 모두 끝나기 전까지는 나간 것이 없으니 요청한 쪽이 기다리는 시간은 세 배가 됩니다. 한 건씩 끝내고 넘어가면 같은 시간에 같은 양을 하고도 첫 건은 사흘 만에 나갑니다. 전체 양이 아니라 기다리는 시간이 문제라는 점이 이 방식의 출발점입니다.

칸반은 공장에서 건너온 말입니다. 앞 공정이 부품을 계속 밀어내면 뒤 공정 앞에 상자가 쌓이니, 뒤 공정이 필요한 만큼만 카드를 보내 앞 공정에서 끌어가게 한 장치가 있었습니다. 그 카드의 이름이 칸반이었고 뜻은 눈에 보이는 간판입니다. 장치가 한 일은 두 가지입니다. 일감을 눈에 보이게 만든 것, 그리고 앞에서 미는 대신 뒤에서 당기게 만든 것입니다. 소프트웨어 개발로 옮겨 온 것은 2000년대 후반이고, 옮겨 오면서 부품 상자는 작업 한 건으로, 공정은 보드의 칸으로 바뀌었습니다.

일하는 방식의 프레임워크 갈래에서 첫 갈림길은 시간을 끊느냐 흐름을 관리하느냐입니다. 스크럼은 2주 같은 고정 길이로 시간을 끊고 그 안에 담을 것을 주기 앞에서 고릅니다. 칸반은 주기를 끊지 않습니다. 대신 일이 들어와서 나갈 때까지 지나는 칸을 그려 두고, 각 칸에 동시에 올려 둘 수 있는 개수를 정합니다. 개수가 찬 칸에는 새 일을 넣을 수 없으니 다음 일을 시작하려던 사람이 먼저 앞에서 막힌 건을 치우게 됩니다. 앞 문단의 "거의 다 됐습니다" 열두 개는 보드 위에서 개발 중 칸에 여덟 장, 검수 대기 칸에 넉 장으로 놓입니다. 어디가 막혔는지가 말이 아니라 배치로 드러납니다.

가치로 이어지지 않는 일을 낭비로 보고 걷어 내자는 린의 생각이 이 방식 아래에 그대로 깔려 있습니다. 반쯤 만들다 만 일이 쌓인 상태를 린은 재고로 읽고, 칸반은 그 재고를 눈에 보이게 만든 뒤 상한을 걸어 줄입니다.

칸반 아래 묶인 용어는 네 갈래입니다. 흐름을 무엇에 그리는지(도구), 그 위에서 무엇을 금지하는지(규칙), 흐름이 나아졌는지를 무엇으로 재는지(지표), 그리고 흐름이 어디서 멈추는지(문제)입니다.

도구는 흐름을 그려 두는 자리입니다. 칸반 보드는 작업 한 건을 카드 한 장으로 두고 상태별 칸에 늘어놓은 판입니다. 칸은 팀이 실제로 거치는 단계를 그대로 옮겨 세웁니다. 대기 · 개발 중 · 코드 리뷰 · 검수 대기 · 완료처럼 다섯 칸을 두는 식인데, 남의 보드를 베끼지 않고 자기 팀이 실제로 기다리는 지점을 칸으로 세우는 데서 출발합니다. 기다리는 구간을 칸으로 세워 두지 않으면 그 구간에서 며칠이 사라져도 보드에는 아무 변화가 없습니다. 스윔레인은 그 보드를 가로로 한 번 더 나눈 줄입니다. 장애 대응과 신규 기능이 같은 칸을 두고 경쟁하면 급한 쪽이 늘 이기니, 줄을 나눠 각각 몇 장까지 올릴 수 있는지를 따로 정합니다.

규칙은 보드 위에서 무엇을 금지할지를 정하는 갈래입니다. 두 가지가 있고 사실은 한 몸입니다.

1. WIP 제한 — 한 칸에 동시에 올려 둘 수 있는 카드 수의 상한입니다. 개발 중 칸을 세 장으로 정해 두면 네 번째 카드를 끌어오려던 사람은 손이 비어도 새 일을 열지 못합니다. 대신 이미 올라가 있는 세 장 가운데 하나를 다음 칸으로 넘기는 일을 돕게 됩니다. 이 규칙이 빠지면 보드는 카드가 붙은 할 일 목록에 그칩니다.
2. 풀 시스템 — 일을 배분받는 대신 여유가 생긴 사람이 다음 카드를 끌어갑니다. 위에서 미리 나눠 주면 누구 앞에 일이 쌓였는지가 보드에 드러나지 않고, 막힌 사람을 옆자리가 돕는 일도 생기지 않습니다.

두 규칙은 같은 곳을 겨냥합니다. 상한이 있어야 당길 수 있고, 당기는 방식이라야 상한이 뜻을 가집니다. 상한을 얼마로 잡을지는 처음에 맞히기 어려워서 대개 사람 수보다 적게 시작합니다. 개발자가 다섯이면 개발 중 칸을 셋이나 넷으로 두는 식인데, 사람 수와 같게 두면 각자 한 건씩 붙들고 아무도 남을 돕지 않는 상태가 그대로 허용되기 때문입니다. 걸어 놓고 몇 주 돌려 본 뒤 손이 자주 남으면 하나 올리고, 카드가 오래 머물면 하나 내립니다.

지표는 흐름이 나아졌는지를 재는 갈래입니다. 네 가지가 있고, 앞의 둘은 카드 한 장이 걸린 시간을, 뒤의 둘은 판 전체의 모양을 봅니다.

1. 리드 타임 — 요청이 들어온 순간부터 끝날 때까지입니다. 요청한 사람이 체감하는 시간이라 약속에 쓰는 숫자가 이쪽입니다.
2. 사이클 타임 — 실제로 손을 대기 시작한 순간부터 끝날 때까지입니다. 둘의 차이가 대기 시간입니다. 리드 타임이 9일인데 사이클 타임이 이틀이면 이레는 아무도 손대지 않은 채 줄에 서 있던 것이고, 그 팀이 고칠 곳은 개발 속도가 아니라 줄을 세우는 방식입니다.
3. 처리량 — 일정 기간에 끝낸 카드 수입니다. 주당 열 장이 나가는 팀이라면 앞에 스무 장이 밀려 있을 때 새 요청이 2주 뒤에 시작된다고 어림할 수 있습니다.
4. 누적 흐름도 — 상태별 카드 수를 시간축에 쌓아 그린 그래프입니다. 어느 칸의 띠가 갈수록 두꺼워지면 그 칸에 들어오는 양이 나가는 양보다 많다는 뜻이라 어디가 막혔는지가 한눈에 보입니다.

문제는 흐름이 멈추는 자리를 모아 둔 갈래입니다. 병목은 전체 속도를 혼자 결정해 버리는 가장 느린 구간입니다. 코드 리뷰를 한 사람이 도맡고 있으면 개발을 아무리 빨리 해도 주당 나가는 카드 수는 그 사람이 리뷰하는 속도에 맞춰집니다. 블로커는 다른 조건 때문에 진행할 수 없게 된 카드 한 장입니다. 외부 업체의 답을 기다리는 건처럼 우리 팀이 손쓸 수 없는 이유로 멈춘 것이라, 구간의 문제인 병목과 달리 한 장의 문제입니다. 둘을 나눠 두는 이유는 대응이 다르기 때문입니다. 병목은 그 구간에 사람을 더 붙이거나 앞 칸의 상한을 줄여 풀고, 블로커는 따로 표시해 두고 매일 누가 쫓을지를 정해 풉니다.

네 갈래는 한 방향으로 이어집니다. 보드에 흐름을 그려야 상한을 걸 수 있고, 상한이 있어야 대기가 줄어 지표가 움직이고, 지표가 움직이지 않으면 병목이 어디인지를 되짚게 됩니다. 보드만 들여오고 상한을 걸지 않은 팀에서 아무것도 달라지지 않는 이유가 여기 있습니다. 벽에 카드가 붙었을 뿐 동시에 붙들고 있는 일의 개수는 그대로이기 때문입니다.

"개발 중 칸이 꽉 찼으니 새로 시작하지 말고 리뷰 대기부터 같이 치웁시다."

상한에 걸렸으니 새 일을 여는 대신 앞에서 막힌 것을 끝내자는 말입니다.

"이 요청 리드 타임이 9일인데 실제 작업은 이틀이었어요. 이레는 그냥 줄 서 있었습니다."

늦어진 원인이 개발이 아니라 대기라는 뜻이고, 손볼 곳은 순서를 정하는 방식이라는 지적입니다.

"저희는 스프린트를 안 돌립니다. 보드로 관리하고 주당 처리량으로 일정 답드려요."

고정 주기 대신 흐름을 관리하는 방식을 쓰고 있고, 약속은 주기가 아니라 최근 실적으로 한다는 뜻입니다.

페이지덱에서 고객 문의를 받아 처리하는 일에 이 방식을 씁니다. 수아에게 들어온 문의 가운데 개발이 손대야 하는 것이 주당 열 건쯤 되는데, 언제 들어올지 정해져 있지 않아 2주 주기에 미리 담아 둘 수가 없었습니다. 태오가 보드를 세우고 개발 중 칸에 상한 셋을 걸었습니다.

첫 두 주는 불평이 나왔습니다. 손이 빈 사람이 새 건을 열지 못하는 상황이 어색했기 때문입니다. 그런데 셋째 주에 검수 대기 칸에 카드가 아홉 장 쌓인 것이 눈에 들어왔습니다. 개발이 느린 것이 아니라 지현이 검수를 몰아서 하던 것이 원인이었습니다. 지현이 매일 아침 30분을 검수에 쓰기로 하자 리드 타임 중앙값이 9일에서 4일로 내려갔습니다. 보드가 한 일은 답을 준 것이 아니라 아홉 장이 어디에 쌓여 있는지를 보여 준 것뿐입니다.

가장 흔한 오해는 보드를 쓰면 칸반을 하는 것이라는 생각입니다. 눈에 보이는 결과물이 보드뿐이고 도구를 깔면 바로 생기는 것도 보드라서 그렇게 여기기 쉽습니다. 실제로 흐름을 바꾸는 쪽은 상한입니다. 상한이 없는 보드는 카드가 붙은 할 일 목록이라, 전과 똑같이 스물네 건을 동시에 붙들고 있으면서 그 스물네 건이 벽에 보이기만 합니다. 그대로 두면 팀은 도구를 바꿨는데 리드 타임은 그대로인 상태를 석 달쯤 겪고, 칸반이 우리 팀에는 안 맞는다는 결론으로 갑니다. 맞지 않았던 것은 방식이 아니라 걸지 않은 상한입니다.

두 번째는 칸반에는 마감이 없어서 편하다는 생각입니다. 주기를 끊지 않으니 약속할 날짜도 없다고 읽히기 때문입니다. 실제로는 약속하는 방법이 다를 뿐입니다. 스크럼이 2주 안에 무엇을 넣을지로 약속한다면 칸반은 최근 리드 타임과 처리량으로 약속합니다. 최근 서른 건의 리드 타임이 대체로 나흘 안쪽이었다면 새 요청에 나흘을 부를 수 있습니다. 마감이 없다고 읽은 팀은 상한도 걸지 않고 지표도 재지 않게 되는데, 그러면 남는 것은 관리되지 않는 대기 줄입니다. 요청한 쪽은 언제 되는지 묻지 못하고, 받는 쪽은 급해 보이는 순서대로 끼워 넣게 됩니다.