폭포수 모델 실패 사례 - 클린 애자일

클린 애자일
- 로버트 C. 마틴 -

컴퓨터 없이 빈 시간이 있을 때 클린 애자일 이라는 책을 챙겨서 조금씩 읽어보고 있다.
읽으면서 공감이 가는 부분들이 있었어서 공유해보고 싶다는 생각이 들었다.

폭포수 모델 실패 사례 에 대한 부분이었다.

폭포수 모델 실패 사례

회의

5월의 첫날이다. 부문장이 큰 회의실에 모두를 불러 모았다.

“우리가 새로운 프로젝트를 수주했습니다.” 부문장이 말했다. “11월 1일에 끝날 예정입니다. 아직 요구 사항은 모릅니다. 아마 1, 2주 정도 안에 전달될 겁니다. 자, 분석하는 데 얼마나 걸릴까요?”

누군가 웅얼거렸다. “하지만 아직 요구 사항이 뭔지도 모르잖아요…”

“요구 사항이 있다 치고 하는 거죠!” 부문장이 고함친다.
“일이 어떻게 돌아가는지 다 알잖아요. 모두 전문가 아닙니까? 제가 지금 정확한 날짜를 말하라는 게 아니잖아요. 그래도 일정은 잡아야 하니깐 물어보는 겁니다. 참, 만약에 두 달이 넘게 걸린다면 이 프로젝트는 그냥 접는게 나을 겁니다.”

누군가의 입에서 “두 달?”하고 중얼대는 소리가 흘러나오자, 부문장은 의견을 낸 것으로 받아들인다.

“좋아요! 사실 제 생각에도 그렇습니다. 자, 그러면 설계에는 얼마나 걸릴까요?”

11월 1일까지는 여섯 달 밖에 남지 않았다는 걸 다들 알고 있을 것이다.

“두 달요?” 당신이 말한다.

“정확해!” 부문장이 활짝 웃는다.
“제가 생각한 것과 정말 똑같네요. 그러면 구현에 두 달을 쓰면 되겠군요. 모두 회의하느라 수고 많았습니다.”

많은 수가 이런 회의에 참석해 봤을 것이다. 이런 경험이 없다면 운이 좋았다고 생각하자.

분석 단계

모두가 회의실을 떠나 자리로 돌아왔다.

분석 단계는 프로젝트의 신혼 시기다. 모두가 행복하게 웹 서핑을 하고, 주식 투자도 조금 하고, 고객도 만난다. 사용자를 만나보기도 하고, 멋진 차트도 그리며 전반적으로 좋은 시간을 보낸다.

그리고 7월 1일이 되자 기적이 일어난다. 분석이 끝난 것이다.

왜 분석이 끝났을까? 7월 1일이 되었기 때문이다. 일정상 7월 1일에 분석이 끝난다고 되어 있으므로 끝낸 것이다.

관문을 한 단계 넘은 것을 기념하기 위해 작은 파티를 연다. 풍선과 치하의 말씀도 빼놓을 수 없다.

다음 단계는 설계 단계다.

설계 단계

자 이제는 설계를 해야 한다.

설계 단계에서는 프로젝트를 모듈별로 나누고, 각 모듈 간의 인터페이스를 설계하는 것이다.

물론 이 단계에서도 여러 가지가 예상치 못하게 바뀐다. 새로운 기능이 추가되고, 기존 기능은 빠지거나 변경된다.

앞 단계로 돌아가서 이 변경 사항을 재분석하고 싶지만 시간이 모자라다. 그러니 변경 사항을 설계 안에 땜질해 넣는다.

그리고 또 한 번 기적이 일어난다. 9월 1일이 되었고, 설계를 마친 것이다.

왜 설계가 끝났을까? 9월 1일이 되었기 때문이다. 일정상 끝나는 것으로 되어있는데 왜 늦어지겠는가?

다시 한번 풍선과 치하의 말씀을 곁들인 파티를 연다. 그러고는 다음 단계의 문을 열어젖히고 구현 단계로 들어간다.

분석이나 설계는 성공인지 실패인지가 명확한 결과물을 내놓지 않는다. 분명한 완성 기준이 없기 때문이다. 그러니 제시간에 된 것처럼 하는 편이 나을 것이다.
하지만 구현은 다르다. 실제로 완성해야 하는 것이기 때문이다.

구현 단계

구현은 명확한 완성 기준을 갖고 있다. 완성된 것처럼 꾸밀 수 있는 방법은 없다.

구현 단계 동안 우리가 하는 일은 하나도 모호하지 않다. 우리는 코딩을 한다. 그것도 엉덩이에 불이 난 것처럼. 이미 프로젝트의 넉 달을 날려 버렸기 때문이다.

그러는 동안, 요구 사항은 여전히 계속 바뀐다. 새로운 기능이 계속 추가 되고, 기존 기능은 계속 빠지거나 변경된다. 앞 단계로 돌아가서 이 변경 사항을 재분석하고 재설계하고 싶지만, 이제 몇 주밖에 남지 않았다. 그러니 변경 사항을 코드 속에 떔질, 또 땜질해 넣는다.

설계할 때 그린 근사하고 예쁜 그림에 코드가 전혀 들어맞지 않는다. 하지만 걱정할 시간 따위는 없다. 시간은 계속 흐르고, 야근 시간은 쌓여 간다.

그러다 10월 15일쯤, 누군가가 말한다. “마감시간이 언제죠? 언제까지 해야하죠?”

이제 2주밖에 남지 않았고, 11월 1일까지는 절대 끝낼 수 없다는 것을 알아차리게 되는 시점이 이때다.
이해관계자도 프로젝트에 자그만 문제가 있다는 것을 처음 알게되는 시점이기도 하다.

이해관계자의 불만은 다음과 같을 것이다.
“분석 단계에서 우리에게 알려줄 수는 없었습니까? 프로젝트 규모를 산정하고 일정을 맞출 수 있는지 가늠하는 것은 그때 아닙니까? 설꼐 단계에서 우리에게 말할 수는 없었습니까? 설계를 모듈별로 나눈 후, 모듈을 팀별로 할당하고, 인력 수요를 계산하는 것이 그때 하는 일 아닙니까? 왜 마감기한을 2주 남겨놓은 지금에서야 말하는 거죠?”

죽음의 행진

이제 우리는 죽음의 행진 단계에 들어간다. 고객은 화가 나 있다. 이해관계자도 화가 나 있다. 압박이 심해진다. 야근 시간은 급증한다. 사람들이 그만둔다. 지옥이 따로 없다.

3월의 어느 날, 고객이 원하던 것을 절반 정도만 그럭저럭 해내는 물건을 인도한다. 모두가 상심해 있다. 다시는 이렇게 프로젝트를 진행하지 않겠다고 스스로 다짐한다. 다음번에는 제대로 해야지! 다음번에는 더 분석하고 더 설계해야지!

이것을 따라잡을 수 없는 프로세스 인플레이션(Runaway Process Inflation, Runaway Inflation 이란 물가 상승이 너무 급격해서 도저히 제어할 수 없는 상태를 말한다.)이라고 부른다. 우리는 될 리가 없는 일을 계속하려고 한다. 그것도 아주 많이 하려고 한다.

과장?

과장된 이야기인 것은 명백하다. 프로젝트에서 일어난 거의 모든 나쁜 일을 한 곳에 모아 놓은 것이다. 늘 이렇게 극적으로 실패하지는 않는다. 다만 이 이야기는 과장일 수 있지만, 한편으로 사실이기도 하다. 폭포수가 무조건 나쁜 것은 아니다. 하지만 소프트웨어 프로젝트를 운영하기에는 재앙에 가까운 방법이었고, 지금도 그렇다.

추가적으로 이후 부분을 읽으면서 인상깊었던 문장을 정리해본다. 이후 부분에서는 애자일에 대한 이야기가 본격적으로 나오기 시작한다. 아직 많은 부분을 읽지는 못했다.

애자일

애자일은 희망을 없애는 것이 주요 목표다.

애자일이 빠르게 나아가는 것이라고 생각하는 사람도 있다. 그렇지 않다. 빠르게 나아가는 것이었던 적은 없다. 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다.

애자일은 데이터를 만든다. 애자일은 데이터를 많이 만든다. 관리자는 이 데이터를 사용하여 프로젝트를 가능한 한 최선의 결과로 이끈다.

관리자는 데이터를 모으고 그 데이터에 기반하여 최선의 결정을 내림으로써 소프트웨어 프로젝트를 관리한다.