지금까지 우리 서비스를 사랑해 주셔서 감사합니다
개발 비전공자 세 친구의 IT 창업 도전기 : 뜻 밖의 여정
'회사와 투자자는 본 계약에 의하여 협업사항을 이행하여야 한다. (중략)
회사에서 현재 운영중인 ○○○ 서비스 사용자 및
사용 데이터를 ○○○ 서비스로 이전한다. (후략)'
자사에서 처음으로 만든 IT 서비스를 투자 계약서에 의거, 다른 회사에 넘기게 되었다. (Exit이라고 할 수 있을까?)
이제 막 IT 업계에 발을 들인 3명의 비전공 멤버가 스타트업을 창업해서 3년이라는 시간동안 서비스를 만들어내고, 투자를 받아 새로운 기회를 창출하고, 서비스를 공식 종료하기까지 정말 많은 일들이 있었다. 수없이 넘어지고, 몇 번이고 다시 일어나며 많은 것을 경험했다.
서비스의 아이디어 단계부터 종료까지 모든 과정을 지켜본 우리는 감회가 새로웠고, 서비스를 개발했던 모든 과정, 모든 여정에서 배우고, 느낀 것을 글에 담아보고자 한다. 부디 우리의 경험을 통해 비슷한 길을 걸어가는 모든 분들이 우리보다는 조금 덜 넘어지기를 바라며 글을 시작한다.
글의 항목은 창업 멤버 3인방이 총 세 개의 파트(제품 기획, 초기 기업 마케팅, 초기 경영)로 분류된다. 구체적인 내용은 아이디어 현실화 과정, 서비스 기획 및 운영(마케팅 포함), 투자 유치 과정, 서비스 공식 종료 순서로 이어진다.
글 내에서 계약서 상 합법적인 범위 내에서 서술할 수 있는 부분은 모두 다루고자 한다.
투자 계약서 중 일부. 게약서 상 구체적인 내용은 현재 협업 중인 사항이라 마스킹한 점, 양해를 구합니다.PART 1. 프로덕트 총괄 창업 멤버 L의 이야기
회사의 창업 멤버는 현재 대표직을 맡고 있는 S, 프로덕트 기획을 담당한 나(이하 "L"), 사업 개발과 마케팅을 담당한 J까지 총 3명이다.
서비스에 대해 서술 하기 전에 내가 이 회사에 어떻게 들어왔는지 설명해야할 것 같다.
지금 다니는 회사에 들어오기 전, 나는 다른 스타트업에서 사업 개발을 담당했었다.
한마디로 IT 서비스 기획에는 무지했다. (지금은 IT 기획을 담당하고 있으니 인생은 역시 한치 앞을 모른다)
내가 몸을 담았던 스타트업 A의 대표님은 박사 학위를 딴 후 오랜 시간 대기업에서 일하시다가 창업을 하신 분이었다. 따라서 회사는 자연스레 대기업 방식으로 운영되었다.
실질적인 직원은 나 하나였지만 직급과 명령 체계가 굉장히 중요했다. 창업 멤버로 들어갔지만 업무는 논의 없이 명령으로 주어졌고, 내 의견은 말 그대로 왼쪽 귀에서 오른쪽 귀로 통과했다.
내가 경험하고 싶었던 스타트업의 분위기가 아니었다.
'그냥 스카웃 제의를 받은 N사로 도망갈까? 여긴 뭐지?'
스카웃 제의를 받은 대기업으로 이직을 고려하던 차에 현재 회사의 대표 S에게 연락이 왔다. 대표는 같이 일해보자고 했다. 그의 목소리에서 자신감과 열정이 넘치는 것이 느껴졌다.
‘진짜 스타트업을 겪어볼 수 있는 기회가 아닐까?’
고민은 길지 않았다. 나는 20대의 마지막을 배팅하기로 했다.
"해보죠"
여정은 이렇게 시작되었다.
회사에 합류하기로 결정하고, 부푼 마음으로 처음 사무실에 도착했다. 그런데 이게 뭘까, 기대와 달리 회사에는 아무도 없었다. 다들 자금을 끌어오기 위해 외주사에 출근하거나 다른 회사의 프로젝트를 도와주고 있었다. 이게 초기 스타트업의 현실인가?
당시 입주 공간은 공유 오피스로 출입에 카드키가 필요했기에 조금 일찍 도착한 나는 다른 회사의 직원이 들어가는 것을 기다릴 수 밖에 없었다.
잠시 후 대표가 잠깐 사무실에 들렀다.
대표는 IR자료를 보여주며 서비스에 대한 전반적인 아이디어를 설명해줬다.
“우리는 요양 시설에서 이용할 BSS 서비스를 만들거에요” (BSS란 조직이 모든 고객과 접점이 있는 모든 운영 요소를 관리할 수 있는 시스템을 말한다) IR 자료에 쓰일 몇 개의 목업 디자인을 제외하고는 사실상 진행된 것이 없었다. 앞서 말한 것과 같이 다른 팀원들은 자금 확보에 집중하고 있었기에 서비스 개발을 진행할 수 있는 인력은 나 뿐이었다.
뭐라도 해보려고 노트북을 켰다. 우선 IT 서비스 개발을 어떻게 하는지 찾아보기 시작했다. 가장 기본 컨셉은 기획, 디자인, 개발이었다. 회사에는 개발자는 커녕 기획자도 없었기에 일단 전부 내가 해보기로 하고, 일주일 간 IT 서비스 기획에 대해 공부했다.
일주일 후에 adobe XD를 이용해 서비스 화면을 그리고, 간단한 기획 문서를 만들기 시작했다. 2시간 정도 기획 문서를 만들다 보니 대략적인 서비스의 윤곽이 보였다. 우리가 만들려고 했던 BSS의 범위는 너무나도 컸다. 아직 IT에 대해 잘 모르는 나였지만 이건 안되겠다 싶었다. 그날 저녁 집에 가는 길에 나는 대표에게 전화했다.
“BSS에 있는 기능 중 하나만 떼어내서 따로 런칭하는게 어때요?"
대표는 잠시 고민 하더니 일단 알았다고 했다.
지금와서 돌아보면 이는 굉장히 잘한 일이었다. 뒤에서 자세히 설명하겠지만 결국 우리는 원하는 서비스를 앱으로 만드는 것에만 몇 백만원이 들었고, 그 마저도 이용하지 못했다.
스타트업의 구루 Paul Graham은 이렇게 말하기도 했다.
"Doing things that don't scale", 크게 일 벌리지마라!
기획은 제품을 처음 만드는 것에 그치지 않고, 운영하는 것까지 포함한다. 파트 1에서는 최초 기획 시 고려할 사항, 기획을 통한 제품 개발, 운영 기획을 통해 서비스를 개선하는 과정을 분리해서 이야기하고자 한다.
처음 서비스를 개발하는 경우 서비스의 범위를 결정하는 것이 어려울 수 있는데, 가능한 한 작게 생각하는 것이 현명하다. 작게 생각하는 것은 최소 기능 리스트를 작성한다는 의미이고, 이는 곧 MVP를 만든다는 뜻이기도 하다(Minimum Viable Product, 최소기능 제품). 따라서 일단 최소 기능 리스트를 작성 후 개발 환경 플랫폼을 선정하자. 개발을 잘 모른다면 주변의 개발자에게 적극적으로 물어보자. 기능 범위가 줄어들 수록 개발자가 불필요한 기능 개발을 하지 않아도 되기 때문에 제품을 신속하게 개발할 수 있다. 이후 고객의 피드백을 받으며 제품을 개선하면 된다.
최소 기능 리스트를 작성한 이후에는 개발 진행을 위한 플랫폼을 선정해야 한다.
웹 서비스
웹 서비스를 개발할 때에는 모바일 이용 유저를 고려해야 한다. 반응형 웹, 모바일 웹을 따로 개발할 수 있으며, 반응형 웹은 유저가 이용하는 화면의 해상도와 크기에 따라 저절로 반응해서 변한다. 웹 사이트가 하나이기 때문에 관리하기가 편리하다는 장점이 있다. PC에서 에어비앤비 사이트(https://www.airbnb.co.kr/)에 접속하고, 브라우저의 크기를 조절하면 화면이 바뀌는 것을 볼 수 있다.
하지만 네이버 같은 포털 사이트 등은 기능이 너무 많기 때문에 반응형으로 개발하는 것이 쉽지 않고, 로딩 속도가 느려질 수 있다. 그럴 때에는 모바일 웹을 따로 개발하는 것이 좋다. 네이버(https://www.naver.com/)는 브라우저의 크기를 조절해도 화면이 바뀌지 않는다. 모바일 웹을 이용하려면 네이버 모바일 웹(https://m.naver.com/)으로 접근해야 한다. 네이버에서는 다양한 모바일 기기에 대응하기 위해 모바일 웹을 반응형 웹으로 제공한다.
또는 PC 웹을 개발하지 않고, 모바일 웹만 개발하는 방법도 있다. 링크트리나 리틀리(https://litt.ly/start_now)의 경우 프로필을 모바일 웹으로만 제공한다. PC에서도 약간의 불편함을 감수하면 모바일 사이즈의 웹을 이용하는 것에 무리가 없기 때문에 PC 웹이 불필요하거나 리소스를 줄일 때 추천하는 방법이다.
앱 서비스
다들 알다시피 모바일에는 AOS(안드로이드)와 IOS(애플) 두 가지의 운영체제가 있다. 두 운영체제를 따로 개발하는 것을 네이티브 방식이라고 한다. 각 운영체제에 최적화된 개발을 할 수 있어 휴대폰의 기본 기능과 성능을 최대로 끌어낼 수 있다. 하지만 AOS 개발자와 IOS 개발자를 채용해야 하기에 비용과 시간이 많이 든다. 하나의 모바일 앱을 두 번 개발하는 리소스를 줄이기 위해 만들어진 프레임워크가 크로스 플랫폼이다. 같은 소스 코드로 AOS, IOS 버전에서 모두 작동하며, 대표적으로 구글에서 출시한 Flutter, 페이스북의 React Native가 있다. 크로스 플랫폼은 성능에 한계가 분명하며, 아직까지는 이용자가 네이티브에 비해 적기에 공부하는 것이 조금 더 어렵다. 또한 프레임워크 제공자가 업데이트를 하지 않으면 이용이 불편할 수 있다는 단점이 있다.
이와 별개로 모바일에는 하이브리드 앱이라는 방식이 있다. 모바일 웹을 “웹뷰”라는 방식으로 앱에서 보여주는 기능이다. 신규 기능을 웹으로 만들고, 빠르게 테스트해볼 수 있다는 장점이 있다. 다만 브라우저에서의 기능에 한정되어 있고, 웹을 불러와야 하기 때문에 속도가 조금 느리다는 단점이 있다.
그렇다면 우리는?
우리 역시 앞서 설명한 내용을 고려하여 개발 환경 플랫폼을 선택했다. 유저가 주기적으로 사용하는 본 서비스는 원할 때마다 쉽게 접근할 수 있도록 모바일 앱으로 개발되었으며, 초기 자본과 인력이 부족한 점과 개발하는 기능이 복잡하지 않았기에 플러터라는 크로스 플랫폼 프레임워크를 이용했다. 또한 서비스 소개를 위한 정적 랜딩페이지는 반응형 웹으로 개발했다.나중에 관리자 기능을 원하는 유저가 많아졌고, 대부분이 PC로 작업을 하는 것을 고려하여 PC 웹으로만 관리자 서비스를 제공하였다. (계속)
