낭비

모두 바쁜데 고객이 받는 것은 늘지 않는 상태가 있습니다. 야근이 늘고 회의는 꽉 차 있는데, 분기가 끝나고 보면 실제로 나간 것은 지난 분기와 비슷합니다. 이 상태를 사람의 태도에서 설명하려 하면 답이 나오지 않습니다. 아무도 놀지 않았기 때문입니다.

페이지덱에서 이런 일이 있었습니다. 팀마다 금요일 오후를 주간 보고서 쓰는 데 썼습니다. 여섯 팀이 각각 두 시간씩, 한 주에 열두 시간이 들어갔습니다. 지현이 문서 열람 기록을 확인해 보니 지난 두 달 동안 그 보고서를 연 사람은 넷이었고, 그중 셋은 쓴 사람 본인이었습니다. 일은 분명히 했는데 그 일이 만든 값이 없었습니다.

여기에 하나가 더 있습니다. 일하지 않은 시간도 셈에 넣는다는 발상입니다. 코드 리뷰를 기다리며 사흘 멈춰 있던 변경은 아무의 작업 시간에도 잡히지 않지만, 고객에게는 사흘 늦게 도착한 것과 같습니다. 낭비라는 말은 만든 것과 기다린 것을 한 덩어리로 묶어 보게 해서, 바쁜데 성과가 없는 상태의 원인을 사람이 아니라 구조에서 찾게 만듭니다.

무엇이 낭비인지 갈래로 나눠 두고 그 목록으로 현장을 훑는 방식으로 씁니다. 소프트웨어를 만드는 일에서 흔한 것은 일곱입니다.

1. 끝나지 않은 작업 — 만들었지만 고객에게 닿지 않은 것입니다. 세 달째 검토 중인 기능, 합치지 못한 채 쌓인 변경이 여기 듭니다. 쌓여 있는 동안 값을 내지 못하고, 오래 둘수록 합치는 비용만 커집니다.
2. 쓰이지 않는 기능 — 만들어 놓고 아무도 안 쓰는 것입니다. 사용률 2퍼센트인 화면도 유지보수와 테스트와 문서를 계속 요구합니다.
3. 다시 파악하기 — 기록이 없어 같은 것을 두 번 알아내는 일입니다. 반년 전에 왜 그렇게 정했는지 아무도 모르면 그 결정을 처음부터 다시 합니다.
4. 넘겨주기 — 담당이 바뀔 때 맥락이 빠지는 자리입니다. 한 번 넘길 때마다 설명하지 못한 부분이 남고, 받는 쪽이 그만큼을 다시 묻거나 추측합니다.
5. 작업 전환 — 여러 일을 오가며 생기는 손실입니다. 컨텍스트 스위칭이라고 부르는데, 세 가지 일을 동시에 들고 있으면 각각을 다시 붙잡는 데만 매번 시간이 듭니다.
6. 기다림 — 앞의 어느 구간이 끝나기를 기다리는 시간입니다. 대개 전체 시간의 가장 큰 몫을 차지합니다.
7. 결함 — 잘못 만들어 다시 하는 일입니다. 늦게 발견될수록 다시 하는 범위가 넓어집니다.

세는 방법은 그림을 그려 확인하는 쪽입니다. 가치 흐름은 요청 하나가 고객에게 닿기까지 지나는 구간을 시간과 함께 늘어놓은 경로인데, 구간마다 손댄 시간과 기다린 시간을 나눠 적으면 6번이 어디에 얼마나 있는지 드러납니다. 전체 시간 가운데 손댄 시간의 비율을 흐름 효율이라고 하고, 처음 재 보는 팀은 대개 15퍼센트 아래가 나옵니다. 나머지 85퍼센트가 걷어 낼 대상이 놓인 자리입니다.

회고에서 무엇을 없앨지 정할 때 가장 많이 씁니다. 회고는 대개 무엇을 더 할지로 채워지는데, 목록을 손에 들고 보면 없앨 것도 같이 나옵니다. 주간 보고서를 격주로 줄이거나 없애는 결정이 이 자리에서 나옵니다.

새 절차를 들이자는 요청을 판단할 때도 씁니다. 승인 단계를 하나 더 두자는 제안은 대개 사고를 막으려는 것인데, 그 단계가 더할 대기 시간과 막을 결함의 크기를 나란히 놓고 봅니다. 한 해에 두 번 나는 실수를 막으려고 모든 변경에 이틀을 더하는 제안이라면 계산이 맞지 않습니다.

구조로 줄이는 수단도 있습니다. WIP 제한은 동시에 진행할 수 있는 작업 수의 상한인데, 이 값을 낮추면 4번과 5번이 함께 줄어듭니다. 한 사람이 세 건을 들고 있을 때보다 한 건을 들고 끝낼 때 전환 손실이 적고, 끝나지 않은 작업도 적게 쌓입니다.

주의할 점이 둘 있습니다. 작업이 아닌 시간을 모두 낭비로 몰면 안 됩니다. 학습, 정리 작업, 쉬는 시간은 값을 나중에 내놓는 것들입니다. 코드 리뷰도 대기는 낭비지만 리뷰 자체는 7번을 줄이는 작업입니다. 다른 하나는 이 개념이 사람을 감시하는 도구로 바뀌는 경우입니다. 낭비 찾기가 누가 덜 일했는지 찾기로 변하면 팀은 바빠 보이는 쪽으로 움직이고, 정작 기다림은 그대로 남습니다.

"그 보고서 지난 두 달 동안 넷이 열었습니다. 없애죠."

산출물이 쓰이지 않는다는 근거를 들어 걷어 내자는 제안입니다.

"작업 시간은 사흘인데 전체가 12일이에요. 나머지 9일이 기다림입니다."

손볼 대상이 작업 속도가 아니라 대기 구간이라는 지적입니다.

"지금 동시에 다섯 건 들고 계신데 두 건으로 줄이시죠."

작업 전환 손실과 끝나지 않은 작업을 함께 줄이자는 말입니다.

지현은 분기마다 한 번 팀이 하는 정기 작업의 목록을 만들고, 각 항목이 누구에게 쓰이는지 적어 봅니다. 주간 보고서는 격주 회의 하나로 합쳤고, 두 팀이 따로 관리하던 같은 내용의 문서는 한쪽을 지웠습니다. 금요일 오후가 돌아왔습니다.

태오는 코드 리뷰 대기를 줄이려고 하루 두 번 리뷰 시간을 정했습니다. 리뷰에 쓰는 시간 자체는 그대로인데 변경이 멈춰 있는 시간은 사흘에서 반나절로 줄었습니다.

낭비를 게으름이나 일하는 속도의 문제로 읽는 경우가 가장 많습니다. 낭비라는 말이 아까운 시간을 떠올리게 하니 자연스러운 오해입니다. 하지만 실제로 재 보면 가장 큰 몫은 기다림이고, 기다리는 동안 사람들은 다른 일을 하느라 바쁩니다. 이 오해를 그대로 두면 개선안이 사람을 더 몰아붙이는 쪽으로 나오고, 전체 시간은 줄지 않습니다. 12일 가운데 9일이 대기인 흐름에서 작업하는 사흘을 이틀로 줄여도 전체는 11일입니다.

회의와 문서는 전부 낭비라고 읽는 오해도 흔합니다. 두 가지가 대표적인 예로 자주 쓰이기 때문입니다. 판단 기준은 종류가 아니라 그 산출물이 다음 단계에서 쓰이는지입니다. 아무도 열지 않는 보고서는 낭비고, 그 자리에 없던 사람이 반년 뒤에 읽고 따라잡는 문서는 3번을 줄이는 일입니다. 회의도 같습니다. 이 구분 없이 회의와 문서를 걷어 내면 다시 파악하기와 결함이 늘어나서, 걷어 낸 시간보다 더 큰 시간이 나중에 나갑니다.