Draft Mode 계속 수정중입니다.
Waterfall은 나쁜 개발방법이다. 한국내 굴지의 대기업 SI업체들이 아직도 이 방법에 매달려 있는것은 한국 IT 후진성의 중요한 요인이기도 하다. 이미 이 방법론의 높은 실패율은 이미 상식이어서 이전부터 고전적인 iterative 방법론과 Agile 방법론등이 이미 소개되어 있다. 연구에 의하면 30%에 가까운 초기 요구사항들이 후반부에서는 없어지거나 변경된다고 한다. 이렇게 어차피 변경될 요구사항의 분석을 위해서 많은 시간을 낭비한 꼴이 되버리는 것이다.
하지만 관료적인 습성을 가진 조직은 이 방법론에 묘한 매력을 느끼게 된다. 그 이유는 초기에 수집되는 정보의 문서화와 각종 초기 산출물들은 이 방법론이 잘 정돈된 학문적인 활동으로 보이게 하기 때문이다. 그리고 게으르고 무능한 관리자들에게는 그 순차적인 스케쥴관리의 용이성이 매력적일 수 밖에 없다.
예를들어, 한국 IT 관리자들중에는 일단 수립된 스케쥴은 맹목적으로 지켜져야 한다고 생각하는 사람들이 있다. 이는 프로젝트가 지연되는 느낌을 주어 상부 관리자들에게 질책을 받지 않기 위한 생존을 위한 차원낮은 행태일 수도 있을 것이다. 하지만 스케쥴이 정확한 일정에 맞추어 진행되리라는 그 근거없는 믿음은 오히려 종교적이다. 오히려 매순간 벌어지는 예기치 못한 상황들의 적절한 위기 관리가 더 중요시 되어야 한다. 부장이나 상무라는 작자들이 그저 잘 돌아가고 있다는 하부 관리자의 거짓말에 속아야만 하는 상황을 자초한 것이고, 이러한 어리석음이 한국 IT의 후진성의 본질이다. 이 죽일놈의 관료적 작태가 결국 agile등과 같은 iteration과 eveolution을 중요시 여기는 방법론의 수용을 막고 있다.
처음부터 waterfall에 대한 공격을 시작한 이유는 이 방법론에 매달려서는 객체지향개발능력이 결코 향상될 수 없기때문이다. 즉, 개발자의 개인 능력에 악영향을 미쳐서 고급스런 코딩을 막고 진보적인 비지니스 로직을 탑재한 시스템에 대한 비젼마저 앗아가버리기 때문이다.
한국에서는 framework라는 상용 tool들을 개발의 한 부분으로서 많이 쓰고 있는 것을 본다. 하지만 이런 대부분의 tool이 해결해주는 부분은 design layer간의 protocol이나 domain model들의 template화등 시스템내의 infrastructure에 대한 tool인경우가 많다. 하지만 아직도 그 business layer안에서 여러 프로젝트를 아우를만한 business logic의 framework를 구현하려는 노력을 보는 모습은 드물었다. 그리고 framework란 말을 하나의 design layer내에서 사용할 때 제대로 이해하지 못하는 경우도 있었다. 즉, 같은 산업의 다른 고객들의 프로젝트를 할 때마다 business logic은 항상 처음부터 새롭게 제작된다. 어느누구도 이전에 tool의 재사용에 대한 성찰로 인해서 쉽게 변경하여 쓸 수 있는 base system개발에 대한 노력이 부족하였다. 이 모든 것이 개발자의 역량부족이 아니라 구조적인 문제에 의한 것이고 이는 잘못된 waterfall방법론 때문이라고 생각한다.
이 waterfall의 또하나의 병폐는 대형 프로젝트의 관리중 웃기지도 않는 인해전술이다. 즉, 처음에 잘 투자된 요구사항 분석과 디자인 (제대로 하는 것도 보지 못했지만)의 의해서 소위 framework라는 tool안에서 공장에서 찍어내는 듯한 모듈들을 수많은 개발자들이 집중적으로 코딩하면 될 것이라는 그 근거없는 믿음을 욕하고 싶다. 이는 요구사항 변경이 있을 때마다 노는 개발자들은 늘 놀고 힘든 개발자들은 늘 힘든 load balance 실패로 더 나아가 노동력의 낭비로 남게된다. 그리고 결국 개발자라는 직업에서 자부심을 없애게 만든 가장 중요한 요인이기도 하다. 개떼처럼 덤벼서 아무나 해낼 수 있는 3D 직종으로 전락하게끔 만든 악질적인 전략인 것이다. 그리고 얼마나 실패를 거듭했는지...
이제 Agile 개발과정에 대해서 실무위주의 설명을 해나가고자 한다. 여기에는 객체지향개발에 대한 새로운 접근법을 소개하고 이를 통해서 개발자들에게 객체지향에 쉽게 접근할 수 있는 하나의 길을 제시하고 싶다. 앞으로 계속 waterfall 방법론의 폐해를 말할텐데 이는 그 습관이 잘 없어지지 않기 때문이고 이제껏 자기를 가로막고 있던 잘못을 더 두드러지게 느끼게 하기 위함이다.
여기에 나온 방법은 Agile일반으로서 받아들이기를 바란다. XP나 UP , SCRUM등과 같은 구체적인 방법론은 이후에 각자가 응용하는데 어려움이 없을 것이다.