폭포수 모델을 따르는 웹 제작 과정은 PPT - PSD - HTML - CSS - JavaScript - Java와 같이 일련의 과정을 거치게 된다. 만약, 버튼의 레이블이 하나 변경되더라도 PPT, PSD, HTML, CSS가 순차적으로 변경되어야 한다. 기능이 변경되는 것이라면 말할 것도 없다. 로드맵이 명확하고 각 단계에서 결과물을 확실하게 보증하는 검증과정이 들어간다면 폭포수 모델도 아주 나쁜 것은 아니라고 생각한다. 다만 웹이라는 변화 무쌍한 제작물의 특성에 적합하지 않을 뿐이다. 잦은 수정과 개선이 계속해서 반복되는 웹사이트 제작에서 폭포수 모델은 프로젝트의 피로도를 쌓이게 하는 좋지 않은 방법론이다.

왜 수정사항은 계속 생기는 것일까? 왜 프로젝트는 막판에 뒤집어 지는 것일까? 왜 개발자들은 불가항력적으로 과도한 업무 환경에 놓이는 것일까? 누구나 한번쯤은 생각해 봤을 것이다. 정말로 스토리 보드에 도장찍고 PSD 수정을 막고 프로젝트를 진행할 수 있을까? 웹쪽 일을 계속 하다가 내린 결론은 '그렇게 할 수 없다'였다.

그렇다면 어떤 방법이 필요할까? 최종 결과물을 수정함에 있어서 기민하게 반응할 수 있는 프로세스를 만들고 또한 개선안이 후반부에 나오지 않도록 시제품을 만들고 많은 테스트를 시행하는 것이다. 프로토타이핑은 이 시제품을 통해서 많은 테스트를 어떻게 해야하는지에 대해서 이야기 하고 있는 책이다.

프로토타이핑을 할 때에 가장 어려운 선택 과제는 프로토타이핑의 범위이다. 모든 기능이 다 작동되는 시제품을 만든다면 확실한 테스트와 코드 재사용성을 높일 수 있겠지만 개선안을 미리 뽑는다는 취지에서 벗어나게 된다. 반대로 최소한의 기능만이 작동되는 시제품을 만들고 테스트 하기에는 테스트 범위가 협소하고 코드 재사용성이 떨어질 수 있다. 이 책에서 이 범위의 산정은 어려운 문제로 다루고 있고 범위산정을 위해서는 프로토타이핑의 목적을 명확하게 할 필요가 있다고 한다. '시제품을 통한 UX 테스트'가 목적이 아니라 아주 구체적인 목적이 필요하고 그 목적이 정해진다면 범위도 명확하게 제한할 수 있게 된다.

기존 프로세스에 희망이 없었다면 프로토타이핑을 통해서 개선점을 찾을 수 있을 것 같다. 프로세스에 있어서의 창의성을 가장 쉽게 끌어올릴 수 있는 기법이 아닌가 싶다. 특히나 콘텐츠, 구조, 표현, 동작을 모두 다루는 웹 퍼블리셔들은 한번쯤 읽어보고 '중간자'로서의 자리매김보다는 '클라이언트 기술의 리더'로서 위치를 고민해봤으면 좋겠다.