워터폴 2006: 방법론과 프로세스에 대한 패러디

경고: 이 글은 개발자가 아니라면 재미없을 것임을 미리 알린다. 단 개발자라면 몹시 재미있을 지도. ^^

아마 소프트웨어 개발업에 종사하고 있는 사람이라면, 워터폴(Waterfall) 개발 방식에 대해 알고 있을 것이다. 워터폴 방식은 분석, 설계, 구현, 시험, 배치의 단계별 프로젝트 생명주기를 따르는 것인데, 단계별로 흘러간다는 점에서 워터폴이라고 부른다.

하지만 이와 같은 전통적인 워터폴 방식은 단계별 관리가 명확한 반면, 최종 산출물을 초기 단계에서 정확히 예측하기 어렵다는 한계로 인해 비판을 받게 되었다. 실제 상황에서는 요구사항이 구현 중간에도 도출되는 경우가 흔하고, 단계별 구분이 명확하지 않은 경우도 많기 때문이다.

그에 따라 반복(Iteration) 개발 방식이 등장하였는데, 여러 번의 반복을 통해 요구사항을 더 잘 이해하고 점차 완전한 소프트웨어로 발전시킨다는 개념이다. 최근에는 워터폴 방식으로 마일스톤과 일정을 관리하면서, 반복 개발 방식을 혼합하여 사용하는 것이 일반적인 추세이다. 개발 방식에 따라 각각의 장단점이 분명한데, 어쨌든 개발자들 사이에 워터폴 방식은 구식이라는 공감대가 있는 것이 사실이다.

서설이 길었다. 이제 본론이다. ^^

MS Architect MVP들간에는 활발한 메일링이 이루어지고 있는데, 어제 밤에는 엔터프라이즈 애플리케이션의 배포에 대한 심각한 주제로 많은 메일들이 오갔다. 마틴 파울러(Martin Fowler)는 자신의 배포 팀에게 가상화를 추천하고 있다는 메일을 남기기도 했다.

어쨌든 딱딱한 메일링 중에 보잉사에서 근무하는 아키텍트인 제프가 재미있는 사이트를 하나 소개했다.

워터폴 2006 사이트

소프트웨어 업계에 만연한 방법론과 프로세스를 패러디한 사이트이다. 하하~

이 업계에서 최소한 10년 이상을 일한 사람들만이 만들어 낼 수 있는 재미있는 글들이 많이 올라와 있다. 예를 들면, 리팩토링(Refactoring)을 패러디한 리퍽토링(Refuctoring) 글을 보면 리퍽토링을 잘 하기 위해서는 Unique Modeling Language(원래는 Unified임을 알 것이다!)를 통해 자신만의 비주얼 노테이션을 고안해서 사용하고 아무에게도 그것을 설명하지 않는 것이라고 되어 있다. 또한 Rainy Day Module이란 사용하지 않는 쓸데없는 코드를 삽입해 놓는 것인데, 그 이유는 누군가 나중에 그것을 필요로 할 수도 있기 때문이란다.

또한 프로젝트에서 개발 자체보다 문서가 너무 강조된 현실을 패러디한 wordUnit: A Document Testing Framework란 글도 있다. 지금까지 프로그램 검증 기술이 비해 문서 검증 기술이 너무 없었다고 주장하며, Document-Driven Documentation을 제안하고 있다. 하하~

영어의 압박이 있지만 개발자라면 한번 읽어보기 바란다. 해당 글들은 단순히 웃자고 만든 것만은 아니라고 생각하며, 고도의 풍자가 있는 것이다. 우리 업계에도 이러한 유머가 많이 있었으면 좋겠다. ^^