수백가지의 프로토타입을 만드는 신차 개발과 SW 개발

어느 트위터의 글에 '자동차는 하나의 모델에 대해 수백가지의 프로토타입을 만든다고 하는데, 소프트웨어는 얼마나 많은 프로토타입을 만드느냐"라는 내용을 본 적이 있습니다. 신차를 만드는데 다양한 디자인과 내용물들을 구성하는데 있어서 얼마나 많은 시도를 하고, 실패를 하는지를 잘 보여주는 글이었습니다. 하지만, SW를 만드는 입장에서 우리는 하나의 프로젝트에서 얼마나 많은 프로토타입을 만들고, 시도하고 실패하는지를 물어보는 대목에서 많은 생각을 하게 만듭니다.

SW 개발에서 정말 우리는 신차를 개발하는 것과 같이 수백번의 프로토타입을 만들고 맘에 안들면 바꾸는 작업을 할 수는 없는 것일까요? 먼저 이러한 개발 방식이 SW 개발 방식과 유사하다는 것을 말해야 할 것 같습니다. SW 개발 방식은 100g의 철을 가지고 100g의 핀을 만드는 공정과 같이 언제나 누가 만드는지에 상관없이 동일한 입력과 출력이 나오는 공정이 아닙니다. 물론, 어느 정도의 편차는 인정할 수도 있겠지만, SW와 같이 개발 과정에 사람의 지식이 크게 좌우하는 경우에는 편차가 너무나도 큽니다. 따라서, SW 개발 방식은 제조업의 개발 방식보다는 신차와 같이 신제품을 만드는 방식과 유사하다고 보면 됩니다. 따라서, 신차를 만들 때에 수백개의 프로토타입을 통해 고객의 입맛에 맞는 제품을 만드는 과정이 SW 개발 방식에도 적용한다면 분명 고객의 가치를 실현하는 SW 만들 가능성이 더 높은 것입니다.

SW 제품 개발 방식은 대부분의 프로젝트에서 주로 분석/설계/구현/테스트 라는 일차원적인 시간 순으로 진행하고, 여기에 맞게 인력을 투입하는 형태입니다. 즉, 총 1년의 프로젝트 기간이라면, 이를 위의 단계로 나누어서 분석(2), 설계(3), 구현(6), 테스트(1)과 같이 일정을 계획합니다. 프로젝트 초반에 WBS라는 이러한 고정된 계획틀을 만드는 작업의 일환으로 수주를 보내기도 합니다. 한번 고객과 합의된 WBS는 프로젝트 끝까지 변경되지 못합니다. 혹, 변경하려고 하면 수많은 의사결정 프로세스를 만들고 그에 대한 합당한 이유를 만들어야만 가능합니다. 그리고, 이를 지키지 못하는 개발측에 칼을 들이대듯이 압력을 가합니다.

이러한 고정된 계획 하에서는 수백번의 프로토타입을 만든다는 것은 꿈을 꾸기 힘듭니다. 즉, WBS에 박혀있는 일정을 준수해서 해당 일자까지 아무도 그 내용을 이해하지 못하는(혹은 이후 아무도 신경을 쓰지도 않는) 산출물들을 만들어내는데 눈코 뜰새가 없습니다. 간혹 아키텍처를 결정하는 과정에서 한 두번의 자그마한 (그것도 대부분의 중요한 규칙을 제외한) 기능을 만드는데 아주 잠깐의 시간을 냅니다. 멋드러진 UI와 현란한 화면 기술을 사용해서 고객에게 보여주고 칭찬을 받는 것에 만족할 뿐입니다. 그 이후로는 이러한 프로토타입 결과에 대해서는 어느 누구도 신경쓰지 않으며, 최종 모습은 그 때 잠깐 보여주었던 것과는 전혀 다른 형태를 띠는 경우가 대부분입니다. 이 때 만들어진 아키텍처는 프로젝트 끝까지 전혀 변함없이 그 형태를 유지하며, 이후 다양한 비즈니스와 제약들을 수용하기에는 너무나도 힘든 아키텍처에 어떻게든 맞추려는 개발자의 현란한 기술만이 코드 안에 만들어집니다.

프로토타입을 만들려면 그 디자인과 내용물에 따라서 아키텍처 구조 역시 유동적일 수 밖에 없습니다. 아니, 유동적인 것이 아니라 확장성(extensibility)과 적응성(adaptability)이 보장되어야 합니다. 이러한 아키텍처는 결코 프로젝트 초반에 반짝 프로토타입을 통해서 완성되는 형태가 아니라, 프로젝트 내내 같이 진화하고 발전하는 형태여야 합니다. 떄로는 초반에 설계한 아키텍처가 잘못된 것일 수도 있으며, 설사 아무런 문제가 없다고 하더라도 이후에 다른 형태로 대체될 수도 있습니다. 프로토타입은 고객의 요구와 선호도를 맞추어가는 과정의 부산물들입니다. SW 개발 역시 한번에 딱 맞는 해결책을 내놓을 수는 없습니다. 다양한 설계 결정 중에서 고객의 요구에 맞는 것을 선택해야 하며, 이는 이후의 비즈니스 추가와 다양한 제약으로 인해서 다시 뒤바뀔 수도 있습니다. 하지만, 천편일률적인 SW 아키텍처를 고수하는 개발 문화에서는 이러한 여러차례의 프로토타입을 만들 수 있는 조건이 되지 못합니다.

또한, 많은 경우 개발자들의 잘못으로 인해서 SW가 문제가 발생된다는 논리로 개발자들을 강제하는 각종 표준을 근거로 개발자들의 자유와 권한을 뺏는 가이드들이 프로토타입을 만들려는 의지를 꺾어버립니다. 가이드는 하나에서 열까지 일일히 따라하는 문서로 채워지고 이대로 하지 않는 형태에 대해 무조건 개발자의 책임으로 몰아부치는 문화를 낳아버렸습니다. 그 안에는 어떠한 원칙과 원리가 없고, 오로지 개발자들을 문책하기 위한 법적 근거로 전락해버렸습니다.

SW 개발은 사람의 지식이 생동감있게 뿜어져 나와서 그 지식으로 한층 더 좋은 SW 제품이 만들어지는 과정이어야 합니다. 따라서, 실패하는 자그마한 프로토타입들이 결국 성공적인 SW 제품을 만드는 밑거름이 됩니다. 프로젝트 기간 동안 실패하지 않는다면 우리는 오픈 시점에 아주 커다란 실패를 맛볼 것입니다. 일정대로 되지 않는다고 주의를 받을 것을 염려하여 다양한 수치를 조작하여 99.5% 진척률이 몇달 간 계속되는 현실에서 이러한 실패를 위한 도전과 창의 정신은 SW 개발 어디에서도 찾아보기 힘들 것입니다. 프로젝트 기간 내내 실패하는 프로토타입을 만드십시오. 그리고, 이를 인정하고 그 안에서 성공의 해답을 찾으려고 하십시오. 그 외의 일정은 오로지 고객이 만족하는 동작하는 SW를 인도하는 것만이 남아 있을 것입니다.