흔히 프로그램을 개발할 때 가장 겪는 딜레마라 본다. 어떤 이들은 좀더 완벽하게 가다듬고 출시해야 한다는 사람도 있고, 어떤 이들은 먼저 출발하고 서서히 가다듬는 것이 좋다는 의견도 있다.

사내에서 회의를 정하면 전자로 기울여지는 경우가 많다. 대부분의 개발자, 기획자들은 좀더 완벽하게 개발된 제품을 출시하고 싶어한다. 그래서 완벽을 더 기하기위해서 마감일을 미루는 것이 더 올바른 판단이라고 생각한다.


힘내세요! 우린 더 완벽한 상태에서 시작해야 한다구요!

그러나 개발자나 사내에서 이정도면 완벽하다고 해서 제품이 출시되어도 역시 예상치 못한 문제가 발생하는 경우가 있고, 정작 사용자가 자주 사용하는 기능에 보강보다는 잘 안쓰는 기능에 완벽을 가해서 시간과 노력을 낭비하는 경우가 많이 생긴다. 이것이 가장 큰 문제이다. 엉뚱한 곳에 에너지를 쏟아붇는 것이다.

이것을 피하기 위해서는 먼저 기본 핵심기능을 구현하고 출시후에 사용자의 빠른 피드백을 받아서 제품을 개선하는 것이다. 코딩 호러의 이펙티브 프로그래밍에서도 다음과 같이 충고한다!

버전 1은 엉망이야, 하지만 어쨌든 출시하라구! 어떤 사람은 당신이 버전 1.0을 출시하고 나서 당혹스러운 경험을 하지 않는다면 그것을 충분히 일찍 출시한 것이 아니라고 말하기까지 한다. 중요한 것은 소프트웨어가 얼마나 완벽한 것인가가 아니라, 소프트웨어를 출시한 다음에 당신이 어떻게 하느냐이다.

당신의 팀이 사용자의 피드백에 반응하는 속도와 태도는 하나의 완벽한 버전이 그렇게 할 수 있는 것에 비해 훨씬 더 강력하게 사용자들이 소프트웨어에 대해 품는 느낌을 결정한다. 그래서 당신이 진짜 잘해야 하는 것은 바로 피드백에 대한 반응이다. 신화적이고 완벽한 소프트웨어를 출시해야 한다는 이상적인 관념에 사로잡히는 것이 아니라, 사용자나 고객의 피드백에 제대로 응답하고 그들의 피드백을 활용해서 소프트웨어를 지속적으로 개선하고 가다듬는 모습을 보여주는 것이 진짜 중요하다. 따라서 당신이 지금 거의 완벽한 모습을 갖춘 소프트웨어를 붙들고 추가적인 최적화를 수행하고 있다면 잘못된 대상을 최적화하고 있는 셈이다.

주어진 비용의 한도내에서 소프트웨어를 최대한 일찍 출시하고, 나머지 시간을 실제 세상의 피드백에 기초해서 빠르고 반복적인 개선을 수행하는데 보내는 것은 의심의 여지없이 좋은 소프트웨어를 개발하는 최선의 방향이다.

내말을 믿기 바란다. 비록 버전 1이 다소 엉망이라고 해도, 그것을 일단 출시하라.

팔자좋은 외국사람이 한 말이라구???
국내 스타트업 기업인 배달의 앱, 윤현준 CTO도 같은 말을 하였다

크게 그림을 그리고, 작고 빠르게 시작하라.

한번에 모든 것을 구현하려고 하지 말고, 핵심을 먼저 구현하고 사용자의 피드백을 통해 지속적으로 개선하는 것이 중요하다. 인력도 자본도 없는 스타트업이 모든 것을 완벽하게 갖추고 시작하기란 사실상 불가능하다.

세계적인 소셜커머스 기업인 그루폰도 그 시작은 워드프레스로 구현한 초라한 웹사이트였다. 이 회사는 빨간색 티셔츠를 처음 판매했는데 PDF로 쿠폰을 만들고 주문도 이메일로 받았다. 그루폰에 있어 서비스의 핵심은 제품 판매였고, 이것에만 집중한 것이다.

물론, 장단점이 있겠지만, 깊이 새겨들을 말이다. 가장 두려운 것은 사용자는 별로 중요하지 않은 것에 완벽을 가하느라 선점의 기회를 놓치는 것이다! 핵심기능에 최선을 다하고 나머지의 완벽한 디테일은 사용자의 피드백을 받고 아주 빨리, 자주 개선하는 것이다. 포인트는 아주 빨리, 자주 개선! 이것이 생명이다.


자. 이제 처음부터 완벽해야 하다고 주장하는 당신의 선량한 팀원들을 설득하자!