웹 개발 프로젝트는 왜 실패하나

아래 글은 재직중인 회사의 블로그에 올린 글을 옮겨온 것. 우리 팀이 왜 애자일 방법론을 택했는지, 왜 기존 개발 방식은 안된다고 판단했는지에 대해 적었다. 이 글의 얼개는 2008년에 당시 다니던 회사에 제출한 보고서에서 나왔고, 글만 다시 썼을 뿐 기본 내용은 동일하다. 참고로 이 글은 별도 라이센스를 적용한다.

애자일하게 일하기 첫 번째 이야기에서 일반적인 웹 개발 프로세스에 대해 언급했습니다. 이번 글에서는 기존의 웹 개발 프로세스에 대해 조금 더 이야기해보려 합니다. 앞서 말한 것과 같이 기존의 웹 개발 프로세스는 통상 ‘기획 -> 디자인(html퍼블리싱) -> 개발 -> QA(그러나 많은 경우 QA마저 고작 기능 테스트 혹은 오탈자를 찾아내는 데에 그침) -> 런칭’의 순서로 진행됩니다.

위와 같은 개발 프로세스는 흔히 폭포수 방식이라 불리는 개발 방식에서 나왔습니다. ‘폭포수’라는 이름에서 짐작할 수 있다시피 이 방식에는 한 가지 중요한 전제가 있습니다. 폭포 아래로 떨어진 물이 다시 시작점으로 거슬러올 수 없듯이, 이미 한 번 진행한 프로세스를 다시 되짚어 올라오는 일이 없어야 합니다. 그것을 전제로 할 때, 그야말로 ‘물 흐르듯이’ 개발이 진행될 수 있는 거지요.

그러나 정말로 한 번 흘러내려간 물이 다시 거슬러 올라오지 않는다면 왜 폐 절제 수술을 받는 개발자가 생기고, 코딩하다 막히면 회사 근처 치킨집으로 간다(치킨집 사장님이 개발자 출신)는 말이 생길까요. 이는 소프트웨어, 특히 웹 개발이 갖고 있는 태생적인 특성 때문이고, 이 특성이 폭포수 방식과 맞지 않기 때문입니다. 그렇다면 웹 개발은 어떤 특성이 있고 왜 그것이 폭포수 방식으로 구현이 어렵다는 것일까요?

폭포수 프로세스는 전형적인 ‘밀어내기’ 방식으로, 앞 단계의 업무가 완성된 이후 다음 단계의 업무로 진행됨을 가정합니다. 마치 자동차 공장에서 자동차를 조립/생산하는 생산라인의 방식을 떠올리게 하지요. 이러한 자동차 공장의 생산 방식은 포드식 대량생산방식이 그 출발점입니다. 포드식 대량생산방식은 조정 이론에 의해 그 의미를 설명할 수 있습니다. 조정 이론은 ‘활동들 사이에 어떤 종류의 의존성이 있는가’에 대한 이론입니다.

조정이론에 따르면, 두 가지 활동 사이에 가능한 의존성은 기본적으로 세 가지가 있습니다. 바로 유통, 공유, 적합입니다. 유통적 의존은 하나의 활동성과가 다른 활동의 자원이 되는 경우를 말합니다. 공유적 의존은 같은 자원을 여러 활동이 이용하는 것이고, 적합적 의존은 여러 활동이 합쳐져 하나의 자원을 산출하는 경우를 말합니다. 포드식 대량생산방식은 전형적인 유통적 의존성에 대응하는 생산방식입니다. 앞 단계의 작업자가 작업한 결과물을 기반으로 뒷 단계의 작업자가 작업을 진행합니다. MIT 슬론스쿨의 토머스 말론 교수는 저서 <노동의 미래>에서 ‘조립라인은 유통적 의존성을 중앙집중적으로 관리하는 극단적인 예다. 관리자들은 언제 어디서 일을 착수할 것인지, 매 단계별로 무엇이 성취될 것인지를 정확히 알고 있다’고 말합니다.

말론 교수에 따르면 포드식 대량생산방식은 앞 사람의 작업물을 이어받아 뒷 사람이 작업을 하는 유통적 의존성을 관리하는 극단적인 예입니다. 그리고 이것의 전제 조건이 바로 일종의 ‘신’과 같은 관리자의 존재죠. 어디에서 일을 시작하고, 어느 단계에선 어떤 결과물이 나오는지 정확하게 알고 있어야 합니다. 더불어 각 단계에서 실제로 조립 작업을 하는 노동자는 전체적인 그림을 그릴 수가 없고, 그럴 필요도 없죠. 여기에서 저는 한 가지 의문을 제시합니다. 웹 개발이 과연 유통적 의존에 해당할까요?

자동차 조립의 경우에는 각 단계별 생산 목표가 명확히 규정되며, 무엇을 얼마나 생산할 것인지도 분명합니다. 최종 완제품의 모습은 이미 결정된 상태이며, 이에 대해 조립 라인의 작업자가 할 수 있는 것은 전혀 없지요. 조립 라인에서 갑자기 자동차 시트의 디자인을 변경하는 법은 없습니다. 한 단계가 끝나면 다음 단계는 전 단계의 결과물을 받아 그대로 자신의 업무를 수행하기만 하면 됩니다. 또한, 자동차 조립라인의 노동자들은 다음 단계의 노동자로부터 결과물의 피드백을 받을 필요도 없지요. 조립이 잘못된 경우를 제외한다면, 다음 단계의 피드백을 받아 뭔가를 개선할 필요도 없습니다. 한 마디로, 각 단계의 작업자들은 자신의 작업에서 최적의 상태를 추구하기만 하면 전체 작업도 최적의 상태가 된다는 뜻입니다.

그렇다면 웹 개발 프로젝트도 그런가요? ‘그렇다’라고 말하고 싶지만, 사실은 그렇지 않습니다. ‘뭔 소리냐? 기획단계에서 전체 사이트의 화면설계까지 끝내고 개발을 시작하지 않느냐’고요? 그것도 맞는 말입니다. 금융권이나 이동통신사 웹사이트처럼 거대한 규모의 서비스도 전체 화면의 화면설계와 기능정의를 끝낸 뒤에 본격적인 디자인, 개발 단계에 착수합니다. 아이러니하게도 바로 이 점이 웹 개발 프로젝트가 무수히 실패로 끝나는, 혹은 프로젝트 참여자들을 야근과 철야의 구렁텅이로 몰아넣는 제일 큰 원흉입니다.

글이 길어질 듯 하니 왜 그런지 다음 글에서 계속 이야기를 이어가겠습니다. 글을 마치기 전에 폭포수 개발방식에 대한 변호를 할 필요를 느끼네요. 폭폭수 방식 자체가 헛점 투성이의 개발 방식인 것은 아닙니다. 다만 폭포수 방식을 제대로 실천하기 위해서는 세심한 검토를 통해 결과물에 대한 거의 완벽한 이해가 선행되어야 합니다. 그러기 위해서는 장기간의 설계 기간은 물론이고, 이를 수행하기 위한 탁월한 역량과 경험을 지닌 전문가가 반드시 필요합니다. 안타깝게도 현실에선 설계 기간을 보장해 주지도 않을 뿐더러, 탁월한 역량을 쌓기도 전에 개발자를 치킨집 사장으로 밀어냅니다. 우리는 어쩌면 단 한 번도 제대로 된 폭포수 개발방식을 경험조차 못한건지도 모릅니다.