cleanUrl: /post/review/book/the-phoenix-project

http://www.yes24.com/Product/Goods/103210348

회사는 경쟁사에게 조금씩 지는 중이다. 시간이 지날수록 우하향 곡선은 가팔라진다. 이 위기를 반전시킬 수 있는 것은 "피닉스 프로젝트" 뿐이다. 리더십에선 "피닉스 프로젝트"가 회사의 생존을 위한 최우선순위 프로젝트라고 천명한다.

하지만 이상하게도 가장 유능한 인력들은 피닉스 프로젝트에 투입되지 못한다. 회사에는 계속해서 Highest급의 이슈가 터지고, 가장 유능한 인력들은 이 이슈를 해결하는데 대부분의 시간을 쓰고 있다. 프로젝트는 계속해서 늦어지고, 예산은 계속 샌다. 한 술 더 떠, 피닉스 프로젝트를 위한 변경사항은 기존 기능들을 고장내고 또다른 Highest이슈들을 만든다.

이런 어수선한 시점에 얼떨결에 IT 운영팀의 부사장이 된 주인공 빌. 이 사태를 수습하기 위해 빌은 다양한 시도를 하지만 획기적인 개선은 만들지 못한다. 우연한 기회에 만난 에릭은, 이런 빌을 데리고 공장으로 간다. 공장에서는 이미 비슷한 문제를 겪었고, 해결했다면서.

우리는 IT산업이 기존 산업과는 뭔가 다르다고 생각한다. 실제로 다른 점은 많다. 토지도 필요 없고, 원자재도 거의 필요 없다. IT산업에선 거의 모든 제약이 구성원의 지적 역량과 상상력에 달려있는 것처럼 보인다. 그래서 IT산업을 성공시키기 위한 방법도, 기존 산업의 성공 방정식과는 질적으로 다를 것이라 기대하기 쉽다. 하지만 『피닉스 프로젝트』는 그렇지 않다고 말한다.

책의 이런 주장은 직관적으로 받아들이기 어렵다. 그렇기 때문에 책이 택한 "소설"이라는 형식이 빛을 발한다. 소설 속 주인공이 겪는 수많은 문제들이 너무나 나의 이야기 같기 때문에, 그리고 그 문제를 해결해나가는 과정도 익숙하거나 설득력이 있기에, 독자는 주인공과 함께 가슴을 졸이다가 분노했다가 기뻐하면서, 자연스럽게 책의 주장에 공감하고 납득한다.

공장이던, 앱스토어의 앱이던, 사실 본질은 같다. 고객에게 가치를 전달해 회사에 돈을 벌어오는 가치흐름을 만드는 것이다. 이 때, 고객으로부터 회수하는 매출이, 가치를 만드는데 드는 비용보다 적으면 회사는 결국 망한다. 그런데 가치를 만드는 비용 중 대부분은 시간에 비례한다. 인건비도 시간에 따라 나가고, 도구 사용료도 시간에 따라 청구된다. 따라서 제품을 만들기로 한 시점부터, 그 제품이 고객으로부터 매출을 발생시킬 때 까지의 시간을 최소화 시켜야한다.

어떻게 하면 그렇게 할 수 있을까? 병목이론에 의하면, 이를 위해선 병목을 개선해야 한다. 해야 하는 정도가 아니라, 병목이 아닌 곳에 대한 개선은 오히려 문제를 악화시킨다! 왜냐하면 병목 앞을 개선해봤자, 병목에 더 많은 WIP가 쌓이는 일밖에 되지 않으며, 병목 뒤를 개선해봤자, 병목에서 나오는 가치는 여전히 변화가 없으므로, 최종 결과물에도 변화가 없기 때문이다.

그런 한 편, 병목에 쌓이는 WIP(Work In Progress)는 회사를 죽이는 주범이라고 할 수 있다. WIP는 병목을 더욱 옥죄기 때문이다. 예를 들어, 우리 PM 한 명이 제품의 모든 정책을 다 알고 있어서 모든 사람들이 이슈가 생길 때마다 이 PM에게 문의를 한다고 하자. 이 모든 문의는 PM에게 WIP로 쌓인다. 이 PM은 서로 다른 WIP를 처리할 때마다 문맥전환을 해야 하고, 그러면서 각 WIP 처리에 걸리는 시간은 더 늘어난다.

그런데 가장 큰 문제는, 그리고 직관에 반하는 점은, 이 WIP 처리에 걸리는 시간, 즉 대기시간 은 선형적으로 늘지 않고 기하급수적으로 는다는 점이다!

대기시간은 그 일을 하는 작업자의 "노는시간(idle)"에 반비례하고, "바쁜시간(busy)"에 비례한다. 즉, 더 바쁜 사람일수록 내 일을 맡게 되기까지 오래 걸리고, 한가한 사람일 수록 내 일을 빨리 맡아 처리 할 수 있다. 그런데 노는시간과 바쁜시간이 반대의 개념임을 생각하면, 다음과 같이 대기시간과 노는시간의 상관관계 그래프가 기하급수적 형태를 띄는 것은 매우 자연스럽게 다가온다.

그래프에 따르면, 하루 50%를 노는 사람의 대기시간은 1시간 (50/50)이지만, 하루 10%를 노는 사람의 대기시간은 9시간(90/10)이 된다. 노는 시간 차이는 5배지만, 대기시간 차이는 9배가 된다. (출처: understanding-wait-time-vs-utilization)

이로 인해 병목의 성능은 우리의 예상보다 훨씬 가파르게 나빠지고, 일정은 미뤄진다. 구성원들은 늦어진 일정을 만회하기 위해 꼼수를 쓰거나 기술부채를 지고, 이는 예측 불가능한 계획되지 않은 일로 이어진다. 계획되지 않은 일은, "계획된 일"을 비용으로 소모하는 한 편, 병목 앞에 WIP를 더욱 빠르게 만드는 악순환을 만든다.

공장에서는 이 처럼 WIP 와 계획되지 않은 일 이 어떻게 병목을 악화시켜 가치흐름을 마비시키는지 익히 알고 있었다. 그래서 그들은 어떻게 해서든 WIP를 최소화시키기 위해 안간힘을 썼다. 예컨대 병목 앞에 일감이 잔뜩 쌓여있다면, 그 앞의 파이프라인이 아무리 여유로워도, 공장에선 그 파이프라인을 가동시키지 않는다. 병목 앞에 쌓이는 WIP가 얼마나 무서운지 알고 있기 때문에.

IT산업에선 그러나 WIP를 가시적으로 인지하기 힘들다. 공장에서는 WIP가 상자나 재고라는 형태로 눈에 보이지만, 소프트웨어는 그렇지 않기 때문이다. 이런 문제를 해결하기 위해 등장한 것이 칸반보드이다. 모든 팀원들이 현재 하는 일들을 "ToDo", "In Progress", "Done" 등으로 분류하고, "In Progress"의 작업이 너무 많다면, 칸반보드에서는 이를 한 눈에 확인 할 수 있다.

칸반보드등을 활용해 WIP 를 가시적으로 확인할 수 있다. 이를 활용해 WIP의 개수를 조절하는 것은 중요하다 (출처: https://kanbanize.com/kanban-resources/getting-started/what-is-wip)