김진
디에스랩컴퍼니 · 부사장
글쓰는창업가
대표님, 제발 개발만 하지 말고 사업합시다
초기 스타트업의 IT 개발을 위한 잔소리

필자는 2008년부터 파운더와 코파운더의 역할을 맡아 다수의 서비스 개발을 진행하였고, 2017년 이후에는 다수의 초기 스타트업들의 IT 서비스 개발에 직간접적으로 참여하여 도움을 제공하였다. 이렇게 여러 스타트업과 일하면서 IT 개발과 관련하여 아래 2가지 유형을 발견할 수 있었다.
 

사례1

“홈페이지 얼마예요?”
“일반적으로 앱 개발 얼마나 해요?”
“괜찮은 IoT 서비스 개발하는 데 기간과 비용은 얼마나 들까요?”

개발을 잘 모르는 대표님들은 이렇게 견적을 요청한다. 이런 고객을 만나는 개발사들은 미소를 띄우며 친절히 상담에 임한다. 속으로 ‘이런 호구!’라고 외치면서.
 

사례2

“개발자가 프로젝트 중에 그만두겠다고 해요.”
“CTO가 개발팀을 더 충원해달래요.”
“개발팀에서 프로젝트 기간을 또 연장해달래요.”
“프리랜서 개발자들이 너무 책임감이 없어요.”

위와 같이 말하는 대부분의 대표님들은 마치 땅이 꺼지는 것과 같은 당혹감을 느낄 것이고, 넉넉치 않은 통장 잔고를 보며 무척 심난할 것이다. 정부 지원 사업을 받아 개발하는 경우라면, 실패 낙인이라도 받을까 걱정할 것이다. 

하지만 이 문제의 꼬리를 따라가 보면, 개발에 대한 경험이 부족한 대표이사의 능력 부족이 아니라 개발팀과의 협업이 제대로 이뤄지지 않아 생긴 경우가 더 많다. 기술에 대한 이해 부족이 문제가 아니라 협업과 관리의 기술이 필요했다는 의미이다. 
 

 

초기 스타트업을 위한 IT 개발 체크리스트

 

개발이 정말 필요할까?

개발을 논하기에 앞서, 실제로 개발하려는 아이템이 기존 서비스와 다르지 않거나 차별성이 없는 경우가 많다(개발 전 면밀한 선행 조사 분석은 절대 필수!). 

개발보다 중요한 것은 풀려는 문제가 어떤 문제인지 명확하고 구체적으로 정의하고, 해당 문제와 관련한 가설을 수립하는 것이다. 문제 정의가 개발보다 당연히 앞선 일인데, 안타깝게도 문제 정의보다 대표님이 만들고 싶은 솔루션 기획을 후딱 대충 하고 개발자 먼저 뽑는(혹은 외주개발사와 계약을 진행하는) 경우가 즐비하다.
 

무조건 고객부터

문제가 정의됐다면, 해당 문제를 겪는 고객이 실제로 존재하는지 확인해야 한다. 고객이 누구인지 소상히 정리하고 가급적 빨리 만나라. 실제로 우리가 생각하는 고객인지 여러 번 묻고 확인하고, 혹시 말과 생각이 다른 것은 아닌 지 꼼꼼하게 관찰한다(대부분의 사용자는 본인의 니즈를 구체적이고 정확하게 말하지 않는다). 

여전히 우리의 고객인 것을 확인하였다면, 어떤 흐름에서 해당 문제를 접하고 해결 혹은 회피하는지 고객의 여정을 확인해야 한다. 해당 문제의 선후 프로세스에 대해 명료하게 이해하고 정리한다.
 

인터뷰를 통해 모은 고객 요구사항(출처: 필자 제공)

 

솔루션 정의와 기능 기획

문제 정의를 잘 수행했고 고객에 대해 명확하게 이해했다면, 이제 솔루션을 정의한다. 솔루션은 해당 문제를 해결할 수 있는 기능 한두 개로 정리하는 것이 좋다. 기능이 많아지면, 가설이 제대로 작동하는 지 파악하기도 복잡하고, 자연스럽게 개발도 복잡해진다. 핵심 기능에 집중해서 설계하고, 다시 고객을 만나서 테스트해야 한다. 제발 불필요한 기능을 열심히 기획하지 말자. 

 

스파게티 면을 이용한 탑 쌓기(출처: 필자 제공)

 

가설 검증

앞서 솔루션을 기획했다면, 이제 가설 검증을 위한 솔루션을 구현한다. 꼭 개발이 아니어도 된다. 최근에는 편히 사용할 수 있는 온라인 서비스가 워낙 많아서, 잘 구성만 하면 웬만한 기능들은 어렵지 않게 만들 수 있다. 이를 위해 카카오톡 단톡방, 포털 카페, 밴드, 인스타그램 등을 쉽게 이용할 수 있으며 아임웹, 카페24, 스마트스토어 등을 이용하면 물건 판매도 가능하다.
 

 

그래도 개발을 해야 한다면

먼저, MVP(Minimal Viable Product)를 설계한다. MVP는 최소한의 노력으로 완성할 수 있는 최소 기능의 제품을 뜻한다(Eric Ries, 2011). 참고로, 경쟁사 서비스를 벤치마킹 하면, 설계 시간을 많이 줄일 수 있다. 

솔루션은 고객에 따른 핵심 기능, 부가 기능 등에 대해 상세하게 정리한다. 마치 집 건축 시, 방, 거실, 주방, 화장실, 마루 등으로 구성요소들을 하나씩 쪼개는 작업을 하는 것과 유사하다. 웹서비스라면 로그인 페이지, 메인화면, 사용자 화면 등으로 나눌 수 있고, 프로세스별, 화면별 기능에 대해 정리하고 더 세세하게 나눈다. 이후 이 업무(task)들을 기반으로 개발 일정을 설계하게 된다.

외주로 개발을 고려하고 있다면, 완성된 설계서를 가지고 5곳 이상의 개발사를 만나는 것을 추천한다. 미팅 수가 부족하면, 부족한 정보를 기반으로 결정을 할 수 밖에 없다. 더 많은 개발자를 만나 조언을 구하고, 우리 스타트업의 설계서를 업데이트하도록 한다. 

더불어 개발 기간은 2~3개월을 넘지 않도록 하고, 최대 6개월을 넘지 않도록 한다. 그렇게 하기 위해서는, 오픈소스를 이용한 개발 방향이 적합하고, 경험이 많은 개발사의 기존 개발물을 재활용하는 것도 좋은 방법이다. 우리는 MVP 혹은 Prototype을 개발하려는 것이지, 앞으로 계속 사용할 완성도 높은 거의 영구적인 제품을 개발하려는 것이 아니라는 것을 명심하자.

스타트업 대표가 기술 개발에 대해 잘 모른다고 생각하여, 서둘러 CTO(Chief Technology Officer)를 뽑거나 개발팀을 꾸리는 것은 대단히 위험할 수 있다. 글 서두에서 말했던 개발자 관련 불만은 차고 넘친다. 초기 기업에 능력있는 사람이 필요한 것은 사실이지만, 우리의 아이디어가 좋은 직원만 들어오면 된다고 생각할 수도 없는 노릇이다. 아이디어의 가설 검증을 위한 개발이라면, 외주 개발을 통해 6개월 내 개발과 시장 검증을 마치는 것을 적극 추천한다.

 

칸반을 이용한 업무 관리(출처: 필자 제공)

 

개발자들과의 협업

소통은 무조건 웃으면서 한다. 항상 양 손에 커피를 대동하고 밥을 밥 먹듯이 산다. (인하우스 개발자가 아닌 경우) 개발 비용까지 냈는데, 굳이 그렇게까지 해야 할까 싶을 수 있지만, 우리의 빠른 개발 종료를 위해, 비굴하고 겸손하게 미소로 소통한다. “메인 화면 작업 많이 되었나요? 혹시 안되셨다면, 언제까지 가능할까요?” 웃으면서 쪼아야 한다.

개발 중에 기획은 계속 변경될 수 밖에 없다. 개발자가 안된다고 말하는 것은 작업하기 싫어서일 수도 있고 정말 개발이 어려워서 그럴 수도 있다. 핵심 기능을 제외하고는 지금은 다 버려도 된다 생각하고, 우리의 목표인 빠른 개발 종료에만 집중해야 한다. 

그렇게 개발이 얼추 정리되면, 테스트 시나리오에 따라 모든 기능들에 대해 한땀 한땀 모든 프로세스를 여러 번 반복하여 테스트를 수행한다. 그리고 버그 혹은 누락된 내용들에 대해 개발자에게 요청하여 개발 종료까지 냉큼 달려간다.
 

두 손은 무겁게(출처: Packaging of the world)

 

개발 말고 사업

이제 프로토타입 개발을 마쳤다. 우리는 아주 미흡하지만, 이 개발물을 가지고 고객을 만나러 가야 한다. 디자인이 좀 세련되지 못하고 성능이 조금 미흡할 수 있어도, 개발에 미련을 두지 말고 1.0 Beta의 상태로 개발이 아닌 진짜 사업을 하러 갈 시간이다.

모든 스타트업 대표님들이 대단한 꿈을 따라가고 싶은 마음은 이해하지만, 스타트업 초기 너무 바람만 가득 찬 분들도 많다. 위대한 회사를 만들기에 앞서, 바늘귀부터 먼저 꿰어야 하고, 성실하고 똑똑하게 일을 해야 기대하는 이상에 가까워질 수 있다. 

디테일을 채우는 것은 오롯이 스타트업 대표의 몫이다. 멀리 있는 위대한 회사의 깃발만 보지 말고, 오늘과 내일을 살아야 하는 현실 속에 우리 회사가 지속 가능한 회사인지 계속 고민하며 성공을 염원하는 꼼꼼함을 잊지 않기를 진심으로 바란다.

Tags

Editor / Contributor
김진

기술을 이용한 새로운 세상의 변화를 더하는 코디네이터

댓글 2
웃으면서 쪼아야 한다.
전적으로 동의하는 생각이다. 
비용 지불하여 업무를 하고 있지만, 현재 진행 상황에 대해 명확히 인지 할 수 있으며, 
늘어질 수 일정 또는 중요성이 낮은 기능 구현을 위한 시간을 절약할 수 있도록 가이드도 될 수 있다고 생각한다. 
Reply   ·   12일 전
공감해주셔서 감사합니다!
Reply   ·   10일 전
2