웹 개발 프로젝트는 왜 실패하나, 두 번째 글

이 글은 회사 블로그에 등록한 글입니다. 개발 일기는 계속... 참고로 이 글은 별도의 CCL을 적용합니다.

지난 글에 이어.

지난 글에서 기존의 웹 개발 방식이 포드식 대량생산방식과 일맥상통하는 면이 있으며, 포드식 대량생산방식이 완전해지기 위해서는 어떤 조건이 필요한지를 얘기했습니다. 웹 개발 프로젝트에서 기존의 방식을 유지하기 위해서는 설계 단계에서의 완벽성이 보장되어야 합니다. 그러나 이 점이 큰 함정입니다.

웹 개발 프로젝트에서 그 사이트의 최종 결과물을 그려내는 사람은 기획자입니다. 고객(내부고객이든 외부고객이든)의 요구사항을 받아 그것을 (흔히 스토리보드라고 부르는)화면설계로 구체화합니다. 그 다음 이걸 기준으로 고객의 승인을 받죠. 고객 승인이 끝났다는 말은 이 화면설계대로 개발하기만 하면 모든 사람이 행복해진다는 뜻입니다. 여기엔 결정적인 전제가 있습니다. 바로 ‘화면설계가 완벽해야 한다’는 것이죠. 그러나 안타깝게도 완벽한 화면설계란 우리의 현실에는 존재하지 않습니다. 제 여자친구처럼요.

왜 완벽한 화면설계가 존재하지 않느냐. 답은 간단합니다. 화면설계는 종이쪼가리에 불과하기 때문입니다. 웹 개발 프로젝트의 결과물은 실제로 작동하는 제품입니다. 사용자가 글을 읽고, 무언가를 입력하고, 버튼을 누르고, 결과를 받아봅니다. 화면설계는 이 모든 과정을 단지 기획자의 머리 속 시뮬레이션에 의해, 다른 말로 하면 추측에 기반해 제작됩니다. 현명한 기획자는 이 과정에서 개발자에게 조언을 구하고, 피드백을 받아 수정하기도 합니다. 다만 이 조언 역시 개발자의 머리 속 시뮬레이션에 지나지 않는다는 것이 문제지만요.

많은 계획이 실패하는 이유는 계획을 한 사람들이 계획을 세우고는 모든 일이 끝난 것처럼 생각하기 때문입니다. 무능한 관리자는 고작 업무 분담을 한 것을 가지고 마치 그 업무가 끝난 것처럼 좋아합니다. 사실은 그렇지 않습니다. 계획은 일의 종료가 아니라, 시작에 불과합니다. 그것도 실천 과정에서 무수히 많은 장애물을 만나는. 웹 개발 프로젝트의 화면설계 역시 마찬가집니다. 화면설계는 고작해야 ‘지금 이 순간, 고객의 요구사항을 받아 기획자가 적당히 만들어낸’ 가상의 결과물에 불과합니다. 이 사실을 있는 그대로 인정하고, 거기서부터 실제 구현을 출발하면 그나마 덜할테지만, 안타깝게도 많은 경우 이 화면설계를 마치 ‘알파이자 오메가이며, 모든 것’인냥 절대화한다는 겁니다. 고작 종이 뭉텅이를 만들어놓고는 말이죠.

더 큰 문제는 화면설계가 나온 이후에야 비로소 고객의 요구사항이나 개발 스펙이 구체화된다는 데 있습니다. 스티브 잡스가 그랬지요. 고객은 자신이 뭘 원하는지 모른다고. 화면설계대로 개발이 한창 진행된 다음에야 고객은 자신이 승인해준 종이쪼가리가 실제로 눈 앞에서 작동하는 걸 확인합니다. 웹 개발 프로젝트의 재앙은 대개 이 순간 시작합니다. 기획 단계에서 정의한 기능 열 가지 중 세 가지는 쓸모 없는 것이라 판정이 나지만 그대로 구현합니다. 왜? 고객의 도장이 찍혀있으니까요. 그리고 기획 단계에서 생각하지 못한 문제점 다섯 가지와 새로운 -사실은 고객이 스스로도 알지 못했던, 그러나 지금 와서 생각해보니 그 때 알고 있었고, 얘기도 했지만 기획자가 제대로 이해하지 못했거나, 고객 외에는 아무도 기억하지 못하는- 요구사항 다섯 가지가 등장합니다. 문제점은 왜 생길까요? 누누히 말하지만 화면설계는 종이쪼가리에 불과하기 때문입니다. 막상 개발을 시작해보니 동네 뒷산 약수터가 호수공원이 되는 경우가 허다합니다.

자동차를 만드는 것과 비교해서 정리를 하자면 이렇습니다. 새로운 자동차를 개발한다고 칩시다. 처음부터 설계도를 그려서 그걸 바로 공장에 던지고 조립라인을 구성하는 경우는 없습니다. 새로운 자동차를 만들 때도 컨셉 스케치부터 프로토타입 제작까지 무수히 많은 단계를 거칩니다. 생산라인에 올리기 전까지 많은 사람들이 여러가지 방법으로 설계를 검토합니다. 그러고나서야 대량 생산에 돌입합니다. 웹 개발 프로젝트는 어떤가요? 설계와 구현이 바로 연결됩니다. 이 사이에 있는 중요한 단계가 하나 생략됩니다. 바로 프로토타입입니다. 프로토타이핑을 통해 우리가 설계한 것이 정말로 구현 가능한 것인지, 과연 우리에게 필요한 것인지를 판단하고 다듬는 과정을 거쳐야 하는데, 그것을 과감히 생략합니다.

기획 단계에서 모든 화면의 설계와 기능을 예측한다는 실현 불가능한 허상을 믿고 프로젝트에 돌입한다면 이후에 확인하는 것은 그것이 허상임을 깨닫는 일 뿐입니다. 안타깝게도 매 프로젝트에서 그것을 경험하면서도 다음 프로젝트에서는 지난 일은 모두 잊은 것처럼 그대로 반복합니다. 이번에는 그런 일이 생기지 않을 것처럼 계획을 하고 일을 진행하죠. 이건 스스로를 기만하는 겁니다.

10개월 예정의 프로젝트에서 2개월을 기획, 2개월을 디자인, 4개월을 개발, 2개월을 테스트에 할당한다고 가정합시다. 모든 일이 계획대로 진행될 경우 기획자는 자신이 만든 화면설계가 실제로 작동하는 것을 최소한 두 달이 지난 뒤부터 확인할 수 있다는 뜻입니다. (물론 현실에선 두 달 뒤에 확인할 수 있는 것은 아무것도 없습니다. 아직 개발자는 한 줄도 코딩을 시작하지 못했을테니까요) 두 달이면 기획자 본인도 화면설계에 대한 질문을 받으면 문서를 다시 열어봐야 하는 시점입니다. 석 달 쯤 지나면 개발자로부터 ‘이 기능은 이런 뜻인가요?’ 질문을 받으면 ‘그게 무슨 기능이었는지’를 기억해내야하는 일도 생깁니다. 애초에 그렇게 기획을 한 의도를 조금씩 잊어버리기도 합니다.

웹 개발 프로젝트의 결과물은 형체가 없습니다. 수 천 페이지나 되는 웹 사이트를 기획하면서 만들어낸 수 천 페이지짜리 화면설계는 실제로는 아무것도 보장해주지 못합니다. 그 기능들이 실제로 구현이 가능한지, 구현하면 어떻게 작동할 것인지 아무것도 테스트해보지 않았습니다. 그런 종이뭉텅이를 만들기 위해 여러 명이 몇 달을 씁니다. 모든 팝업창 하나, 에러 메시지 하나까지 포함된 완벽한 계획이 나올 것을 기대하면서 말이지요. 다시 말하지만 완벽한 계획은 우리의 현실에선 존재하지 않습니다. 제 여자친구처럼요.

다음 글에서는 그래서 우리는 어떻게 했는지, 그 과정에서 어떤 문제점을 발견했는지를 얘기하도록 하죠.