스타트업에서 제품 개발하기

이재원·2020년 10월 4일
1
post-thumbnail

"배포하기 직전에 코드에서 문제를 발견했습니다. 이 문제는 배포 후 6개월 이후에 반드시 발생하며, 6개우러 전까지 정상적으로 동작할 것으로 예상됩니다. 문제를 수정한다면 얼마나 시간이 걸릴지 모르겠지만, 오래 걸릴 것 같습니다. 배포를 한다고하면 지금 당장 배포할 수 있고요. 어떻게 하시겠어요?"

우리 조직의 개발 면접에서 반드시 나오는 질문이다. 질문의 요지는, '당신은 얼마나 요령있는 개발자인가요?'이다. 이 질문에서 우리 조직이 원하는 답변은 정해져 있다.

"일단 마무리하고, 다른 일을 진행하겠습니다."이다.

하지만, 대부분의 면접자는 시간이 더 오래 걸리더라도 완벽을 추구하고 싶다고 말한다. 슬픈 일이지만, 대다수의 초기 스타트업은 이러한 성향의 '완벽주의자' 개발자에게 좋은 경험을 주지 못할 확률이 높다.

스타트업에서 제품을 개발하려면 어떻게 할까요?

얼리슬로스는 2018년 3월 설립 된 기술 기반 스타트업이다. 우리 조직은 현재 다섯 명의 개발자가 함께 일을 하고 있다. 개발자가 처음 입사하면, 우리는 코드 리뷰보다는 우리의 개발 방법론에 대해서 이야기하는 시간을 갖는다. 우리 조직의 개발 방법론은 2018년부터 2020년까지 오는 과정에서 우리 조직이 쌓아온 삽질 경험치가 고스란히 포함하고 있다. 그리고 나는 우리 조직의 방법론이, 우리와 비슷한 규모의 스타트업에 꽤 적절하다고 생각한다.

  1. 우리는 처음부터 완전품을 만들 수 없다. 돈이 없으니까.
  2. 최대한 단순한 작업 단위로 잘라서 일한다.
  3. 기획이 중간에 크게 변경될 수 있다. 하지만 괜찮은 일이고, 개발자 입장에서도 괜찮아야한다.
  4. 지금 코드는 나중에 안 쓸 수도 있다. 처음부터 기획이 완벽한게 아니었으니까.
  5. 현재 우리의 목표는 매력적인 제품의 완성이 아닌, 기업의 존속이다.

스타트업의 개발 방법론: 린

당신은 얼마나 린에 대해서 잘 알고 있나요?

스타트업이 자동차를 만드는 나쁜 방법의 예시

자동차를 만든다고 가정해보자.
위 이미지는 린스타트업을 검색해보면 볼 수 있는 자동차 개발 방법의 잘못된 예시다. 바퀴를 만들고, 바퀴를 프레임으로 연결하고, 차체를 씌우고, 최종적으로 자동차를 만든다. 얼핏 보면 이 과정은 자동차를 만들기 위해서 군더더기 없는 효율적인 방식이지만, 스타트업에게 있어서 좋은 방법은 아니다.
이 방법은 최종 형태로 개발하기 전까지 제품의 시장성을 검증할 수 있는 방법이 전혀 없어서, 처음 시장을 잘못 읽어 계획이 잘못된 것이었을 경우, 알아채기 전까지 손해가 누적되는 구조를 갖는다.


"

포커에선 불리한 상황이라 판단될 때, 많은 경우 폴드를 하고 빠져나올 수 있다.
그러면 큰 손해는 입지 않는다.

그럼 가장 크게 잃는 상황은 언제일까?

틀린 계산을 한 다음 이길 수 있다는 확신을 가질 때이다.

웹툰 <텍사스 홀덤>중, '가장 크게 잃는 상황은 언제일까?'

포커에서 수를 읽는 것과 스타트업에서 개발하는 것은 일정 부분 동일하다.
자동차를 만들고자 했다면, 만드는 과정에서 끊임없이 내 상황이 불리한 상황인지 아닌지 판단해야 한다. 시장에서 좋은 성과를 낼 수 없다고 판단이 들었으면, 빠르게 선회해야 한다. 그래야 큰 손해를 입지 않는다. 우리가 개발 중인 제품이 무조건 성공할 것이라고 확신을 갖고 회사의 모든 역량을 다 투입하고나면, 나중에 그 확신이 잘못되었다고 깨닳았을 때 뒤가 없다. 기반이 탄탄한 기업들은 손해를 견딜 수 있지만, 금전적, 인력적으로 여유가 없는 스타트업은 한 번의 큰 손해로 회사가 와해될 수 있다.

스타트업이 처음부터 완벽한 자동차 개발을 목표로하고 만들어나가는 과정은 여러가지 문제가 있다.

  • 제품이 잘될 것이라고 확신을 갖고 비용과 시간을 들여서 시장에 선보였으나 반응이 좋지 않은 경우, 회사는 존폐의 기로에 놓이게 된다.
    이 경우는 어떻게 회사가 살아남더라도, 경영진이 조직원들의 신뢰를 회복하는데 많은 노력이 필요하다.

  • 자동차를 만드는 과정에서 시장 환경이 크게 변화하여, 개발 중에 우리 제품을 출시하는 게 의미가 없다고 판단되어 프로젝트를 폐기했을 때도 마찬가지다. 누적된 손해를 회복할 방법을 찾기는 매우 어렵다.

  • 이 제품을 우리만 만들고 있을 것이라는 보장이 없다. 2년을 준비해온 제품 출시가 한 달 남았는데, 우리보다 자금이 훨씬 많은 기업에서 우리 것과 유사한 제품을 만들어서 발표한다면?


자동차를 만드는 좋은 방법 예? 아니, 이것 역시 나쁜 예라고 생각한다.
이번에도 역시 자동차를 만든다고 가정해보자. 자동차를 만들기 위해서, 가장 먼저 스케이트 보드를 만들고, 그다음 킥보드를 만들고, 자전거를 만들고, 오토바이를 만들고, 자동차를 만든다. 많은 린스타트업 강의 자료를 보면 위와 같은 형태가 스타트업이 추구해야 할 개발 방법론이라고 이야기한다.

하지만, 나는 그렇게 생각하지 않는다.

질문을 해보자. 스케이트보드를 만들어본 경험치가 자동차를 만드는데 도움을 주는가? 혹은 킥보드를 만든 경험치가 오토바이를 만드는데 도움을 주는가? 나는 별 도움이 되지 않는다고 생각한다. 스케이트보드와 자동차는 '①사람이 탈 수 있다, ②바퀴가 달려있다, ③앞으로 갈 수 있다' 정도를 제외하면 별다른 공통점이 없다. 정말 린한 개발이라면, 각 과정이 유기적으로 연결되어서 각 단계에서 얻은 경험치가 내가 바라는 최종적인 결과물에 반영될 수 있어야 한다.

시장성에 대해서도 이야기를 빼놓을 수 없다. '자동차를 구입하는 사람이 스케이트 보드를 필요로 하는가?' 혹은 '킥보드를 구입하는 사람이 돈을 더 벌면 오토바이를 구입하는가?'의 관점에서 보면 이러한 다양한 형태와 시장을 걸쳐가는 개발 방법론이 얼마나 위험한지 알 수 있다. 물론 이 그림은 린스타트업의 예시일 뿐이지 정말 이렇게 하위 제품을 정의하라는 것은 아니지만, 내가 목표로 하는 제품을 개발하는 과정 중 제작하는 MVP, 프로토타입, 프로토타입 II... 는 최종 형태에 반영되어야 한다. 그래야 비용적으로 손해를 최소화할 수 있다.

번외로 onesound 작가의 <텍사스 홀덤>은 포커에 관심이 없는 사람에게도 삶을 대하는 태도에 대해서 좋은 화두를 던져주는 만화다. 네이버 시리즈에서 구입해서 볼 수 있으니, 창업가라면 한 번쯤 읽어보는 걸 추천하고 싶다. 일단 재밌다.
https://series.naver.com/comic/volumeDetail.nhn?productNo=4042199

그렇다면 스타트업에서 린하게 제품을 개발할 때는 어떻게 해야 할까?

그러면 어떻게 제품을 만들어야 하는가

위기에 처한 지구를 구하기 위해 응원을 할 것인가?
자동차 예시는 너무 흔하고 밋밋하니 지구를 지키기 위한 이족보행 로봇을 만든다고 가정해보자. 우리는 지금 위기에 처한 지구를 구할 두 가지 로봇 계획을 갖고 있다: 에반게리온을 만들 것인지, 볼트론을 만들 것인지.
  • 에반게리온은 생체 기반 로봇이다. 단독 유닛으로 활약이 가능하며, 별도 파츠를 제작하여 장비할 수 있다.
  • 볼트론은 변신합체 로봇이다. 다섯 개의 사족보행 로봇이 합체하여, 하나의 이족보행 로봇이 되는 구성이다.

예산이 한정된 스타트업에서 로봇을 만든다고 했을 때, 어느 쪽을 선택하는 것이 정답에 가까울까?

변신합체 로봇을 만드는 것이 정답입니다. 그러니 볼트론을 만듭시다.
만약 당신이 에반게리온 덕후이기 전에, 혹은 볼트론 덕후이기 전에 한 명의 개발자라면 '볼트론'을 만드는 것이 정답에 가깝다. 왜 우리는 '에반게리온'이 아니라, '볼트론'을 만드는 게 좋을까? 그 이유는 변신합체 로봇인 볼트론을 제작하는 과정이 아까 스케이트 보드, 킥보드를 걸쳐서 자동차를 만드는 방법과 비슷해 보이지만 근본적으로 다르기 때문이다. '에반게리온'을 제작하는 것은 맨 처음 잘못된 방법으로 소개한 한 번에 자동차를 만드는 것과 동일하기 때문에 오답이다.

사족보행 로봇 다섯 기가 합체하면 하나의 이족보행 로봇 형태로 구성된다.
볼트론의 특징은 사족보행 형태의 사자 로봇 다섯 기가 하나의 이족보행 로봇으로 합체 가능하며, 각 사족보행 형태 로봇 역시 독립적으로 기능을 수행할 수 있다는 것이다. 다시 말해, 사족보행 로봇 하나는 최종 형태의 일부이자, 각 형태가 분리되어 독립적으로 동작하는, 작전을 수행할 수 있는 개별 로봇이라는 것이다. 스타트업 제품이 변신합체 로봇 형태로 구성되어야 하는 이유는 여기에 있다.

당연한 이야기지만, 최종적으로 개발하고자 하는 서비스를 한 번에 만들기 위해서는 많은 시간과 비용이 필요하다. 또다시 당연한 이야기지만, 최종적으로 개발하고자 하는 제품을 만들다가 자본이 다 떨어지면, 내가 만들고자 한 것을 시장에 보여줄 수 없다. 그리고 시장이 최종적으로 만들고자 하는 제품을 원하지 않을 가능성, 팔리지 않을 가능성 또한 항상 염두에 두어야 한다.
나는 최종적으로 시장에 선보이고자 하는 제품을, 제품이 성립되는 최소 단위로 쪼개서 개발해야 한다고 이야기한다. 합체로봇 볼트론을 만들고자 하면, 유닛을 하나씩 만들어서 유용하게 쓰다가 나중에 다 만들어지면 합체하는 것이 여러모로 유리하다.

이런 형태로 개발해서 얻을 수 있는 장점은 다양하다:

  • 제품 개발 비용 회수 시기를 앞당길 수 있다.
  • 마이크로 서비스가 전체 서비스의 구성임으로 최종 제품 개발 완료까지 경험을 전부 활용할 수 있다.
  • 완성하고자하는 제품의 일부 기능들에 대한 시장 평가를 린하게 확인하고 최종 목표를 수정해가면서 개발할 수 있다.
  • 프로젝트의 성패를 빠르게 파악할 수 있어서, 조직의 사기를 유지하는데 유리하다.

만화영화에 나오는 로봇이 아닌 얼리슬로스에서 서비스하는 설문조사 서비스, '포켓서베이'를 예를 들면 조금더 구체적으로 설명할 수 있다.

포켓서베이 소개 이미지. 서비스 소개글은 아니었으나, 개발 방법론 설명에 필요할 것 같아서...
포켓서베이 주요 기능 중 하나는 모바일 메신저 '카카오톡' 환경에서 바로 설문조사 참여가 가능하다는 것이다. 우리는 처음에 이 서비스를 준비하기 전에, '카카오톡 챗봇'을 이용한 설문 참여 환경의 사용성과 시장성에 대해서 빠르게 확인하고 싶었다.

초기 포켓서베이 구성 최소 기능 단위. 지금은 당시보다 훨씬 복잡한 형태를 갖고 있다.

설문조사 도구를 처음부터 만든다고 했을 때, 필요한 것은 무엇일까?
설문 참여 도구가 가장 중요하겠지만, 설문을 만드는 설문지 빌더와 응답 확인 도구가 갖춰져야 한다. 처음 이 서비스를 기획하고 있을 때 내 선택은 '설문조사 챗봇만 구축해서 사용성을 확인한다',였다. 그것이 당시 서비스의 핵심가치라고 생각했으니까. '설문조사 빌더 없이 어떻게 설문조사 챗봇을 만들 수 있지?' 라는 질문에는 당시 우리 서비스 이용 흐름으로 답변할 수 있다.

포켓서베이 MVP 모델 서비스 이용 흐름:

  1. 구글 설문도구에서 설문지를 작성한다.
  2. 설문지 링크를 복사해서 포켓서베이 챗봇에 붙여 넣는다.
  3. 챗봇이 구글폼 설문지를 설문조사 챗봇에 사용할 수 있는 형태로 가공하여 저장하고, 설문 참여 번호를 생성한다.
  4. 챗봇에 번호를 입력하면 설문에 참여할 수 있다.
  5. 짜잔, 설문 빌더는 따로 개발하지 않아도 된다!

우리는 위와 같은 형태로 빠르게 포켓서베이의 시장성을 확인할 수 있었고, 시장 반응이 좋아서 개발을 계속해왔다. 시장성 확인까지 걸린 기간은 2주일이 채 소요되지 않았다. 웹페이지도 없었고, 소개서도 없었다. 하지만, 이것만으로도 서비스의 가능성을 검토하기에는 충분했다. 만약 설문지 빌더와 서비스 소개 페이지도 먼저 만들었다면, 포켓서베이의 시장성 확인은 이보다 조금 늦어졌을 거다. 그리고 장담컨데, 그 당시 만든 빌더와 서비스 소개 페이지는 완전히 업데이트되어 금방 존재하지 않게 되었을 것이다.


당시 작성했던 서비스 기획서 일부. 가끔 당시 작성했던 코드들의 잔재가 발견될 때마다 반갑고 그리운 기분이 든다... 그리고 다 부숴버리고 새로 만들고 싶다.

똑똑하게 실패를 경험할 수 있는 준비

기업이, 특히 많은 것이 부족한 스타트업이 실패 경험 없이 사업을 성장시키는 것은 매우 어렵다. 이 일을 시작한 이후로, 많은 창업가 동료들과 초기 스타트업에 합류한 개발자들을 만나며 이야기를 나누어 봤지만, 지금까지 내가 만나온 사람들 중 단 한 명도 크던 작던 실패를 경험하지 않은 사람은 없었다.

대기업은 한 가지 프로젝트를 진행하기 위해서, 경력자들로 이루어진 팀이 적지 않은 시간을 투입하여 시장을 조사하고, 계획을 세우고, 그 계획을 실행한다. 그리고 그 프로젝트의 끝이 실패로 끝난다고 하여도, 기업이 존폐의 기로에 놓이지 않는다. 하지만, 스타트업은 조사도, 계획도, 실행도 부족한데 한 프로젝트의 실패가 곧 기업의 몰락으로 이어질 수 있다.

스타트업의 제품을 개발하는 사람들, 그리고 제품 개발에 관여하는 사람들은 반드시 머릿속에 지금 진행하는 일들이 실패할 수 있음을 염두에 두어야 한다. 불리한 상황이라고 판단되었을 때, 빠르게 '폴드'할 수 있도록 준비해야 한다. 아무리 불리한 상황이라도, 판이 이미 커져있으면 심리적으로 '폴드' 선언하기가, 실패를 받아들이기가, 처음으로 돌아가기가 어려울 수 있다. '내가 지금 하는 일의 실패를 감당할 수 있는가', 질문하는 습관이 중요하다.

받아들일 수 있을 정도의 범위에서 실패를 경험하는 것이 중요하다.
나는 스타트업의 개발 프로젝트 중, 단독 기능 개발로 1개월이 넘게 소요되는 일이 있다면 더 쪼갤 것을 권장하고 싶다. 경험상 1개월까지는 실패 경험을 (토 나오지만) 비용으로 구입할 수 있더라고.

스타트업에서 개발하기

스타트업 취직을 준비하고 있는 신입 개발자라면, 스타트업은 대기업과 달라 개발자의 완벽 추구를 여유롭게 기다릴 수 없다는 것을 인지하는 것이 좋다. 모든 것이 완벽할 필요가 없다. 지금쓰고 있는 코드를 3개월 후에 다시 봐야할 일이 생길 수도 있다. 하지만 그건 내가 완벽하게 일을 하지못했기 때문이 아니라, 우리가 잘되고 있다는 반증일 수 있다. 어쨌든 3개월 후에도 살아있다는 거니까.

스타트업에서 시작하고 싶은 당신이 알아야 할 것들

  • 초기 스타트업(3년 미만)인 경우, 제대로 된 기획이 나오기를 기대하면 힘들다. 제대로 된 기획이 안 나온다면, 기획자를 탓하는 것이 아니라 같이 기획을 만들어가야한다.
  • 업무를 길게 가져가지 않는 것이 좋다. 초기 스타트업의 개발자들은 빠르게 성장한다. 초기에 작성 된 코드는 어차피 나중에 다시 쓴다. 일단 빠르게 만드는 것이 중요하다.
  • 다니던 스타트업이 꼬이면 대표만 망하는 것이 아니라, 개발자의 커리어도 같이 꼬인다. 취업 시장을 돌아보면, 좋은 레퍼런스를 갖고 있는 사람들이 얼마나 잘 취직하는지 볼 수 있을 것이다.

글쓴이 소개

이재원 | jay.yi@earlysloth.com
우리 조직 얼리슬로스의 개발 문화를 소개하고, 우리 조직의 문화에 공감할 수 있는 성장 가능성 높은 개발자를 찾아서 velog까지 찾아왔습니다. 제가 관심을 갖더라도 놀라지 마세요. 물지 않아요.

profile
누구나 쉽게 이해할 수 있는 사용자 경험을 만들고 싶습니다.

0개의 댓글