지난이야기. 1화부터 7화까지의 지난 이야기는 아이템을 기획하고, 방향을 수정해나가는 전략적인 부분을 주로 이야기했다. 남은 이야기는 서비스기획, 시스템기획 등… 아주 중요한 실수들을 이야기하려고 한다. 짤은 꼭 쓰고싶었다. 스타트업이 빠지기 쉬운 함정들이니까.
Scalability
우리 팀은 모바일 클라이언트 개발자와 기획자, 2명으로 구성된 팀이다. 서버개발은 배우면 하겠지만, 상용서비스를 개발해본 적은 없었기 때문에 서버개발은 주위의 손을 빌려야만 했다.
도움을 주셨던 분들은 현재 회사에 다니고 있는 지인분들. 퇴근 후, 주말에 짬짬이 개발하기 때문에 가능하면 기능을 축소하려 노력했다. 하루 8시간 넘게 일하고 온 사람을 붙잡고 일을 부탁한 거니 개발만 하기에도 벅찬 일정이었기 때문에 시스템기획은 내부적으로 준비되어 있어야 했다. 더군다나 회사 일이 최우선순위에 있다보니 우리의 프로젝트는 우선순위가 낮을 수밖에 없었다.
개발자의 일이라는 것이… 원하지 않는 타이밍에 일이 몰아칠 때도 있기 마련이니까… 그래서 최대한 일정을 외부인력에 맞추고, 내부인력은 시스템 설계에 공을 들였다.
문제는 너무 공들였다는 것이다. 서버 구조에 대해 잘 모르지만, 이 바닥에서 구른 것도 어느덧 4~5년이 넘다 보니 보고 들은 것들은 또 많아서 많은 경우의 수를 고려하게 되는 것이 자연스러운. 많은 사용자가 동시접속하면 어떡하지? 수만 개 데이터를 한 번에 통신하는 방법은? 보안은? 뭐 이런 것들.
특히, Scalability(확장성)를 고려하다 보면 개발언어부터도 고려대상에 들어가게 되는데, 어떤 언어가 개발하기 빠른 언어인지, 수백만 사용자들이 접속했을 때 안정적인지 까지도 말이다. 주위에 이제 시작하는 스타트업들 중에서는 개발자도 없는 상태에서 Scalability를 고려해 개발언어를 고르고 있는 팀을 본 적도 있다.
기획에서 설계로 넘어가면서 비교적 빠른 시기에 이 부분을 깨닫고, 확장성과 안정성은 고려대상에서 제외하게 되었는데, 이때 소모된 시간만 하더라도 한 달이 넘는 것 같다. 틈틈이 서버 개발자분들과 회의하고, 논의하고, 정책을 정해나가며 다듬는 동안 시간은 그렇게 흘러가버렸다.
한참의 시간이 흘러서야 깨닫게 된 설계의 기본원칙 중에 하나는 ‘1부터 시작한다’는 것이다. 1명의 사용자가 접속했을 때부터 안정시켜 나가는 것. 1명일 때 안정적이더라도, 여러 명의 사용자가 접속하면 문제가 생길 테니 다시 안정화 작업을 하고. 그렇게 조금씩 그릇을 키워가면 되는 것이다. 처음부터 100만 사용자를 담을 수 있는 서비스 설계는 스타트업에 어울리지 않는다. (최초의 페이스북도 같은 강의를 듣는 친구들만 가입할 수 있던 서비스였다.)
또 하나는 ‘굳이 내가 하지 않아도 된다’는 것. 수십만, 수백만의 동시접속이 될 정도로 서비스가 커지면 그에 맞는 개발을 새로 해야 될 수도 있고, 10년 차 이상의 고급개발자를 모셔와 개발해도 된다. 스타트업은 작은 규모인 만큼 내가 할 수 있는 만큼, 작은 그릇으로 빨리 만들고, 그릇을 키우거나 바꾸거나 여러개를 만드는 것은 그 때 가서 생각할 문제라는 것. 그렇게 서비스가 커지면 돈이 벌려야 정상이고, 그 돈으로 개발할 사람을 뽑으면 된다는 진실.지금 당장은 알게 뭐야, 누군가가 치우겠지. 뿌직=3
Multi-Platform
대부분의 서비스 방식을 크게 나누면 컨텐츠 제공형과 컨텐츠 생성형으로 나뉜다. 사업자가 컨텐츠를 제공하면 사용자들이 소비하는 방식이 있고(영화, 음악, 만화, 도서 등 미디어 분야가 많다.), 반대로 사용자가 컨텐츠를 생산해가면서 쓰는 방식이 있다.(대표적으로 SNS, 유틸리티들이 있다.)
유닛이 특이한 점은 사용자가 가지고 있던 컨텐츠인 전화번호부를 활용한다는 점이다. 더군다나 개인정보라 예민하고, 없어지면 안되는 중요한 정보다. 중요한 정보가 하나라도 지워지면 서비스가 소생할 수 없을 정도의 리스크도 있다. 쓰던 글이 사라진 것과는 다른 문제인건 확실하고. 그것을 아이폰 – 안드로이드 – 웹 세군데에서 핸들링하려고 하니 사소한 것 하나하나가 허들이었다.
안드로이드에서의 연락처 포맷이 다르고(심지어 제조사별로), 아이폰의 포맷이 달랐다. 더군다나 외부에서 꽂는 연락처들… iCloud, Gmail, Facebook, Linkedin 연락처등 이미 꽂혀있는 빨대도 엄청나게 많다.
여러 플랫폼 연동으로 이미 만신창이가 되어있는 전화번호부를 손실없이 고스란히 앱내로 가져와 웹으로 업로드하고, 안드로이드-아이폰 양쪽에 호환될 수 있도록 공통된 설계를 하는 것. 멀티플랫폼 대응이 간단한 경우가 절대 아니었다.
안드로이드 개발자와 아이폰 개발자는 연락처와 관련된 모든 API를 테스트해야했고, 그 두 사이의 차이점을 발견해내야 했고, 공통 설계를 위해 회의가 계속됐다. 뭔가 어긋나면 뺐다가 다시 끼울 수 있는 코트의 단추가 아니고, 이제까지의 뜨개질을 전부 풀어서 다시 뜨개질을 해야하는 니트같았다.
우리 서비스에 맞는 플랫폼이 무엇인지 판단하고, 그것부터 하는 것이 린개발의 방법일 수 있다. 해당 파트의 개발자가 있다고 무조건 개발을 시작하는건 아니라는 이야기다. 아이폰2명, 안드로이드 1명, 서버 3명. 목표를 달성하려고 동시에 투입된 개발자는 6명이나 됐지만 시간과 돈은 우리를 기다려주지 않았다. 프로젝트가 시작된지 7개월(당시 9월 말)이 지났지만, 초기설계대로 모든 플랫폼의 개발을 마무리하려면 족히 1년은 더 걸릴 것 같았다.
기획부터 구현까지 전부 갈아엎은 것만 총 네 번. 큰 결단을 내렸고(지난 6개월간의 설계와 구현을 무용지물로 만든거나 다름없는.. 진짜 큰 결단이다…) 서버연동을 뺀 순수한 아이폰 버전만 먼저 개발하기로 했다.(10월 중순)
1년도 모자랄 것 같던 개발은 지금은 어떻게 됐을까?
MVP
한참 설계를 하고 UI/UX 설계를 할 땐 기획서가 150장이 넘어갔다. 수많은 경우의 수와 다양한 스펙은 아무리 정리해도 이해도 힘들고.. 기획서 쓰기를 중단하고, 모든 기능을 제거하기 시작했다.
‘최소한에 집중하라.’ 늘 이야기 듣는 건데, 얼만큼이 최소한인지 알 수 없었다. 처음 설계가 100%이었다면, MVP라고 생각해 여러 번 쳐낸 수준은 20%이었다. 우린 앱개발 하던 사람인데, ‘기능 없으면 이거 쪽팔려서 어떻게 내보내지’ 했다. 쓸데없는 자존심이 우릴 좀 먹고 있었다.
하지만 자존심을 내려놓고, 결단을 내렸다.(9월) 더 빠르게, 더 최소한으로 줄이기 위해 이런 거 있다고 내세울 수 있는 기능들은 모두 빼버렸고, ‘차별성’하나만 남겨두고 전부 제거했다. 지금은 원래 기획의 1% 수준. 이런저런 기능들 원한다는 것 알고 있고, 구현해야 할 것도 알고 있지만, 완전무결한 프로젝트는 원래 없다고 마음을 다잡은 뒤로는 모두 To do list에 넣어버렸다. ‘그만하면 됐다’는 반응을 볼 수도 있다. 아무 기능도 없어도 괜찮다고 생각했다.
다시 기획서를 처음부터 쓴다면, 아마 5장 정도로 정리할 수 있지 않을까. 이 상태로 거의 완성된 프로토타입을 주위의 다른 기획자들에게 보여줬을 때, “너무 줄인 거 아니야?”라거나 “이게 다야? 실망인데”라거나 “명색이 기획자인데, 다 못해서 속상하지 않아?”라는 소리를 듣고야 말았다.
그제야 안심이 되는 것이다. ‘이제 더 쪼갤 수 없을 때까지 쪼개는 데 성공했구나.’
글 : 강미경
출처 : http://goo.gl/2Fd5Pw
You must be logged in to post a comment.