by
Mar 22. 2020
스타트업에서 제품 개발하기 (1)
생존을 염두에 둔 제품 개발: 최소 단위로 개발할 것
"코드를 짜다가 기능 기획의 문제를 발견했습니다. 이 문제는 배포 후 6개월 이후에 반드시 발생하며, 6개월 전까지는 정상적으로 동작할 것으로 예상됩니다. 지금 배포를 한다고 하면, 지금 당장 배포할 수 있고, 문제를 수정한다고 하면 얼마나 시간이 더 걸릴지 모르지만, 오래 걸릴 것 같습니다. 어떻게 하시겠어요?"
우리 회사 개발 면접 시 면접을 보러 오신 분에게 반드시 묻는 질문이다. 질문의 요지는, '당신은 요령 있는 개발자인가요?'이다. 이 질문에서 내가 원하는 답변은 정해져 있다. '일단 마무리하고, 다른 일을 진행하겠습니다.'이다. 하지만, 대부분의 면접자는 시간이 더 오래 걸리더라도 완벽을 추구하고 싶다고 답변했다. 슬픈 일이지만, 대다수의 초기 스타트업은 완벽주의자 개발자에게 좋은 경험을 주지 못할 확률이 높다.
제목으로 강렬할 자신이 없어서, 타이포그래픽으로 강렬함을 전함이런 사람들이 읽어볼 만합니다:
· IT 제품을 개발해야 하는 비개발자 출신 스타트업 대표자
· 스타트업에서 일하는 신입 개발자
· 대기업에서 일하다가 스타트업으로 넘어온 중견 개발자
· IT 스타트업을 창업하고 싶은 예비 지옥 탐험가
매년 이 시기가 되면 '개발 외주'와 개발자 구인에 대해서 많은 문의를 받는다. 올해도 지난해와 다르지 않았는데, 이 시기가 많은 스타트업들이 본격적으로 창업하는 시기이며, 많은 초기 스타트업들이 제품 개발에 대해서 막연하게 생각하고 있기 때문이기도 하겠다.
며칠 전에도 예비대표님이 자신의 사업 제품을 외주 줘도 괜찮은지 질문해서, 답변을 해주다가 이 내용을 글로 정리해두는 것이 편하겠다는 생각이 들었다. 요즘 말을 너무 많이해서 그런지 목이 아프거든….
스타트업에서 제품을 개발하려면 어떻게 할까요?
개발자가 처음 입사했을 때, 우리는 코드 리뷰보다는 우리의 개발 방법론에 대해서 이야기하는 시간을 갖는다. 이 일을 해오면서 우리가 지금까지 쌓아온 삽질 경험치가 고스란히 포함된 이야기다. 그리고 나는 우리의 방법론이 우리, 그리고 우리와 같은 규모의 스타트업에 꽤 적절하다고 생각한다.
1. 우리는 처음부터 완전품을 만들 수 없다. 돈이 없으니까.
2. 최대한 단순한 작업 단위로 잘라서 일한다.
3. 기획이 중간에 크게 변경될 수 있다. 하지만 괜찮은 일이고, 개발자 입장에서도 괜찮아야한다.
4. 지금 코드는 나중에 안 쓸 수도 있다. 처음부터 기획이 완벽한게 아니었으니까.
5. 현재 우리의 목표는 매력적인 제품 완성이 아니라, 기업의 존속이다.
스타트업 모임 REGO 모임 중. 가끔 이렇게 외부에서 강연을 하기도 한다. 어쩌면 체질인지도.
총 36 페이지의 짧은 강의 내용스타트업의 개발 방법론: 린
스타트업이 자동차를 만드는 나쁜 방법 예자동차를 만든다고 가정해보자.
위 이미지는 린스타트업을 검색해보면 볼 수 있는 자동차 개발 방법의 잘못된 예시다. 바퀴를 만들고, 바퀴를 프레임으로 연결하고, 차체를 씌우고, 최종적으로 자동차를 만든다. 얼핏 보면 이 과정은 자동차를 만들기 위해서 군더더기 없는 효율적인 방식이지만, 스타트업에게 있어서 좋은 방법은 아니다.
이 방법은 최종 형태로 개발하기 전까지 제품의 시장성을 검증할 수 있는 방법이 전혀 없어서, 처음 시장을 잘못 읽어 계획이 잘못된 것이었을 경우, 알아채기 전까지 손해가 누적되는 구조를 갖는다.
포커에선 불리한 상황이라 판단될 때, 많은 경우 폴드를 하고 빠져나올 수 있다. 그러면 큰 손해는 입지 않는다.
그럼 가장 크게 잃는 상황은 언제일까?
틀린 계산을 한 다음 이길 수 있다는 확신을 가질 때이다.
웹툰 <텍사스 홀덤> 중, '가장 크게 잃는 상황은 언제일까?', 창업도 똑같다고 생각한다.포커에서 수를 읽는 것과 스타트업에서 개발하는 것은 일정 부분 동일하다.
자동차를 만들고자 했다면, 만드는 과정에서 끊임없이 내 상황이 불리한 상황인지 아닌지 판단해야 한다. 시장에서 좋은 성과를 낼 수 없다고 판단이 들었으면, 빠르게 선회해야 한다. 그래야 큰 손해를 입지 않는다. 우리가 개발 중인 제품이 무조건 성공할 것이라고 확신을 갖고 회사의 모든 역량을 다 투입하고나면, 나중에 그 확신이 잘못되었다고 깨닳았을 때 뒤가 없다. 기반이 탄탄한 기업들은 손해를 견딜 수 있지만, 금전적, 인력적으로 여유가 없는 스타트업은 한 번의 큰 손해로 회사가 와해될 수 있다.
스타트업이 처음부터 완벽한 자동차 개발을 목표로하고 만들어나가는 과정은 여러가지 문제가 있다.
제품이 잘될 것이라고 확신을 갖고 비용과 시간을 들여서 시장에 선보였으나 반응이 좋지 않은 경우, 회사는 존폐의 기로에 놓이게 된다.
이 경우는 어떻게 회사가 살아남더라도, 경영진이 조직원들의 신뢰를 회복하는데 많은 노력이 필요하다.
자동차를 만드는 과정에서 시장 환경이 크게 변화하여, 개발 중에 우리 제품을 출시하는 게 의미가 없다고 판단되어 프로젝트를 폐기했을 때도 마찬가지다. 누적된 손해를 회복할 방법을 찾기는 매우 어렵다.
이 제품을 우리만 만들고 있을 것이라는 보장이 없다. 2년을 준비해온 제품 출시가 한 달 남았는데, 우리보다 자금이 훨씬 많은 기업에서 우리 것과 유사한 제품을 만들어서 발표한다면?
자동차를 만드는 좋은 방법 예? 아니, 이것 역시 나쁜 예라고 생각한다.이번에도 역시 자동차를 만든다고 가정해보자.
자동차를 만들기 위해서, 가장 먼저 스케이트 보드를 만들고, 그다음 킥보드를 만들고, 자전거를 만들고, 오토바이를 만들고, 자동차를 만든다. 많은 린스타트업 강의 자료를 보면 위와 같은 형태가 스타트업이 추구해야 할 개발 방법론이라고 이야기한다.
하지만, 나는 그렇게 생각하지 않는다.
질문을 해보자. 스케이트보드를 만들어본 경험치가 자동차를 만드는데 도움을 주는가? 혹은 킥보드를 만든 경험치가 오토바이를 만드는데 도움을 주는가? 나는 별 도움이 되지 않는다고 생각한다. 스케이트보드와 자동차는 '①사람이 탈 수 있다, ②바퀴가 달려있다, ③앞으로 갈 수 있다' 정도를 제외하면 별다른 공통점이 없다. 정말 린한 개발이라면, 각 과정이 유기적으로 연결되어서 각 단계에서 얻은 경험치가 내가 바라는 최종적인 결과물에 반영될 수 있어야 한다.
시장성에 대해서도 이야기를 빼놓을 수 없다. '자동차를 구입하는 사람이 스케이트 보드를 필요로 하는가?' 혹은 '킥보드를 구입하는 사람이 돈을 더 벌면 오토바이를 구입하는가?'의 관점에서 보면 이러한 다양한 형태와 시장을 걸쳐가는 개발 방법론이 얼마나 위험한지 알 수 있다. 물론 이 그림은 린스타트업의 예시일 뿐이지 정말 이렇게 하위 제품을 정의하라는 것은 아니지만, 내가 목표로 하는 제품을 개발하는 과정 중 제작하는 MVP, 프로토타입, 프로토타입 II... 는 최종 형태에 반영되어야 한다. 그래야 비용적으로 손해를 최소화할 수 있다.
번외로 onesound 작가의 <텍사스 홀덤>은 포커에 관심이 없는 사람에게도 삶을 대하는 태도에 대해서 좋은 화두를 던져주는 만화다. 네이버 시리즈에서 구입해서 볼 수 있으니, 창업가라면 한 번쯤 읽어보는 걸 추천하고 싶다. 일단 재밌다.
그럼 스타트업에서 린하게 제품을 개발할 때는 어떻게 해야 할까?
그러면 어떻게 제품을 만들어야 하는가
자동차 예시는 너무 흔하고 밋밋하니 지구를 지키기 위한 이족보행 로봇을 만든다고 생각해보자.
우리는 지금 지구를 구할 두 가지 로봇 계획을 갖고 있다: 에반게리온을 만들 것인지, 볼트론을 만들 것인지.
· 에반게리온은 생체 기반의 로봇이다. 단독 유닛으로 활약이 가능하며, 별도 파츠를 별도 제작하여 장비할 수 있다.
· 볼트론은 변신합체 로봇이다. 다섯 개의 사족보행 로봇이 합체하여, 하나의 이족보행 로봇이 되는 구성이다.
예산이 한정된 스타트업에서 로봇을 만든다고 했을 때, 어느 쪽을 선택하는 것이 정답에 가까울까?
변신합체 로봇을 만드는 것이 정답이다. 그러니 볼트론을 만들자!문제 출제자의 의도에 따른 정답은 변신합체로봇인 '볼트론'을 만든다이다.
왜 우리는 '에반게리온'이 아니라, '볼트론'을 만드는 게 좋을까? 그 이유는 변신합체 로봇인 볼트론을 제작하는 과정이 아까 스케이트 보드, 킥보드를 걸쳐서 자동차를 만드는 방법과 비슷해 보이지만 근본적으로 다르기 때문이다. '에반게리온'을 제작하는 것은 맨 처음 잘못된 방법으로 소개한 한 번에 자동차를 만드는 것과 동일하기 때문에 오답이다.
볼트론. 하나의 이족보행 로봇 형태는 다섯 개의 사족보행 로봇으로 분리할 수 있다.볼트론의 특징은 사족보행 형태의 사자 로봇 다섯 기가 하나의 이족보행 로봇으로 합체 가능하며, 각 사족보행 형태 로봇 역시 독립적으로 기능을 수행할 수 있다는 것이다. 다시 말해, 사족보행 로봇 하나는 최종 형태의 일부이자, 각 형태가 분리되어 독립적으로 동작하는, 작전을 수행할 수 있는 개별 로봇이라는 것이다. 스타트업 제품이 변신합체 로봇 형태로 구성되어야 하는 이유는 여기에 있다.
당연한 이야기지만, 최종적으로 개발하고자 하는 서비스를 한 번에 만들기 위해서는 많은 시간과 비용이 필요하다. 또다시 당연한 이야기지만, 최종적으로 개발하고자 하는 제품을 만들다가 자본이 다 떨어지면, 내가 만들고자 한 것을 시장에 보여줄 수 없다. 그리고 시장이 최종적으로 만들고자 하는 제품을 원하지 않을 가능성, 팔리지 않을 가능성 또한 항상 염두에 두어야 한다.
나는 최종적으로 시장에 선보이고자 하는 제품을, 제품이 성립되는 최소 단위로 쪼개서 개발해야 한다고 이야기한다. 합체로봇 볼트론을 만들고자 하면, 유닛을 하나씩 만들어서 유용하게 쓰다가 나중에 다 만들어지면 합체하는 것이 여러모로 유리하다.
이런 형태로 개발해서 얻을 수 있는 장점은 다양하다:
제품 개발 비용 회수 시기를 앞당길 수 있다.
마이크로 서비스가 전체 서비스의 구성임으로 최종 제품 개발 완료까지 경험을 전부 활용할 수 있다.
완성하고자하는 제품의 일부 기능들에 대한 시장 평가를 린하게 확인하고 최종 목표를 수정해가면서 개발할 수 있다.
프로젝트의 성패를 빠르게 파악할 수 있어서, 조직의 사기를 유지하는데 유리하다.
만화영화에 나오는 로봇이 아닌 얼리슬로스에서 서비스하는 설문조사 서비스, '포켓서베이'를 예를 들면 조금더 구체적으로 설명할 수 있다.
포켓서베이 소개 이미지. 서비스 소개글은 아니었으나 개발 방법론 설명에 필요할 것 같아서...포켓서베이 주요 기능 중 하나는 모바일 메신저 '카카오톡' 환경에서 바로 설문조사 참여가 가능하다는 것이다. 우리는 처음에 이 서비스를 준비하기 전에, '카카오톡 챗봇'을 이용한 설문 참여 환경의 사용성과 시장성에 대해서 빠르게 확인하고 싶었다.
초기 포켓서베이 구성 최소 기능 단위. 지금은 당시보다 훨씬 복잡한 형태를 갖고 있다.설문조사 도구를 처음부터 만든다고 했을 때, 필요한 것은 무엇일까?
설문 참여 도구가 가장 중요하겠지만, 설문을 만드는 설문지 빌더와 응답 확인 도구가 갖춰져야 한다. 처음 이 서비스를 기획하고 있을 때 내 선택은 '설문조사 챗봇만 구축해서 사용성을 확인한다',였다. 그것이 당시 서비스의 핵심가치라고 생각했으니까. '설문조사 빌더 없이 어떻게 설문조사 챗봇을 만들 수 있지?' 라는 질문에는 당시 우리 서비스 이용 흐름으로 답변할 수 있다.
포켓서베이 MVP 모델 서비스 이용 흐름:
1. 구글 설문도구에서 설문지를 작성한다.
2. 설문지 링크를 복사해서 포켓서베이 챗봇에 붙여 넣는다.
3. 챗봇이 구글폼 설문지를 설문조사 챗봇에 사용할 수 있는 형태로 가공하여 저장하고, 설문 참여 번호를 생성한다.
4. 챗봇에 번호를 입력하면 설문에 참여할 수 있다.
5. 짜잔, 설문 빌더는 따로 개발하지 않아도 된다!
우리는 위와 같은 형태로 빠르게 포켓서베이의 시장성을 확인할 수 있었고, 시장 반응이 좋아서 개발을 계속해왔다. 시장성 확인까지 걸린 기간은 2주일이 채 소요되지 않았다. 웹페이지도 없었고, 소개서도 없었다. 하지만, 이것만으로도 서비스의 가능성을 검토하기에는 충분했다. 만약 설문지 빌더와 서비스 소개 페이지도 먼저 만들었다면, 포켓서베이의 시장성 확인은 이보다 조금 늦어졌을 거다. 그리고 장담컨데, 그 당시 만든 빌더와 서비스 소개 페이지는 완전히 업데이트되어 금방 존재하지 않게 되었을 것이다.
