스타트업, 서비스 개발자가 되자
소프트웨어 개발자 김수보님의 글을 모비인사이드에서 소개합니다.
이 글은 트위터나 페이스북같은 서비스를 만들거나, 그런 회사에서 처음 일하게 된 개발자들을 위한 글입니다. 이런 회사가 처음인 개발자는 다음과 같은 상황에 직면하면 크게 당황하게 됩니다. 즉, 만들어야 할 서비스 로직이 정해지지 않았고 돈을 어떻게 벌어야 할 지 모르는 경우입니다. 여기에 대해 정리를 해보았습니다.
DevOps를 논의하는 팀원들1. 변하지 않는 서비스/사업 모델은 없다.
100% 성공이 입증되어 앞으로 변하지 않아도 되는 사업모델이 있을까요? 예를 한 번 들어 보겠습니다.
(1) Fakebook을 만들면 됩니다. 입증된 성공 모델입니다. Facebook에 싫어요가 없으니 ‘싫어요’를 넣으면 대박을 칠 겁니다. 아마 네이버나 카카오를 뛰어넘는 훨씬 훌륭한 기업이 될 것입니다.
(2) 아니면, 구글을 만들면 됩니다. 이것도 입증된 성공 모델이지요. 구글은 2015년 2분기 매출만 20조원이 넘었습니다. 검색엔진을 만들고, 클라우드 갖다 붙이면 됩니다.
(3) 구글이 어렵다면 유튜브를 만들면 됩니다. 입증되었지요? 현재 유튜브보다 더 신기술을 쓰고, 한국형 컨텐츠를 많이 올립니다. 그러면 한류 열풍을 타고 금방 유튜브의 경쟁자가 될 것입니다.
세가지 모두 성공한 서비스들이고 적지 않은 사람들이 그 기능을 상세히 알고 있습니다. 따라서 기능을 그대로만 개발해도 서비스가 성공할 수 있지 않을까요? 아니, 적어도 2등은 하겠지요.
그래서 적지 않은 사장님들이 개발자를 채용할 때
'이거 이거만 개발해주면 돼.'
이렇게 이야기합니다. 하지만, 정말 그럴까요? 저렇게만 하면 2등을 할까요? '한국형 유튜브'를 만들면 대박이 나는걸까요? 위 세가지 사례에는 많은 사람들이 간과한 공통점이 있습니다.
지금 보이는 성과는 오랜 시간과 과정을 겪은 결과
라는 것 입니다. 그 과정의 결과로 비즈니스 로직과 사업 모델이 자리를 잡은 것입니다. 그 과정의 증거로 '아직 다 정리되지 못한' 회원 정보와 서비스 데이터가 남아 있습니다.
회원 정보와 서비스 데이터가 그동안 서비스와 사업 모델이 어떻게 변해 왔는지를 보여줍니다. 후발 주자가 기능은 카피해도 회원 정보와 데이터는 카피 할 수 없습니다. 기능이 비슷해도 회원과 데이터가 다르면 다른 사업입니다.
사업은 반드시 시행착오를 거칩니다. 시행착오 때 방향의 변화가 생기면 축적되는 정보와 데이터는 달라집니다. 그 데이터가 사업의 성격을 바꾸고 결정하게 됩니다. 인터넷 서비스는 절대 한 번의 개발로 끝나지 않습니다.
2. 서비스 모델과 사업모델의 차이
이걸 헷갈리는 사람들이 꽤 많이 있습니다. 케이스가 다양하지만, 이해를 돕기 위해 단순한 사례를 들어 보겠습니다.
동물원이 있습니다. 동물을 너무 사랑하는 사육사가 있습니다. 그 사람은 많은 사람들에게 코끼리, 사자 등을 보여주면 모두가 좋아할 것이라고 생각합니다. 그래서 투자가의 돈을 얻어 직원들을 고용하고 동물 우리를 만듭니다. 그리고는 코끼리 열차도 만듭니다. 매일 싱싱한 건초를 사서 동물 우리에 넣어 줍니다.
이렇게 모든 준비가 된 후 동물원을 열고 입장료를 받습니다. 그리고, 아이들에게 호랑이 인형을 팝니다. 매점에서 콜라와 초코파이도 팝니다.
여기서 동물원은 서비스 모델입니다. 입장료를 받고 솜사탕을 파는 것은 사업 모델입니다. 동물원을 상상한다면 두 개를 떼고 생각하기 힘듭니다. 그러나, 분리해서 생각할 수 없는 것도 아닙니다.
서비스 모델은 고객들에게 가치를 제공하는 일입니다. 굳이 돈과 연관 지어서 생각할 필요는 없습니다. 그러나 사업 모델은 돈을 벌어들이는 일입니다. 반드시 돈과 연관지어서 생각해야만 합니다. 서비스 모델은 서비스 제공자, 서비스, 그리고 서비스 이용자가 있어야 합니다. 사업 모델은 상품, 공급자, 유통업자, 소비자가 필요합니다.
3. 스타트업에게 사업 모델이란
어떤 스타트업들은 서비스 모델만 가지고 시작합니다. 서비스가 성공을 하면 그 때 사업 모델을 붙여도 되기 때문입니다. 그러나 현실적으로 이 경우는 사업 모델을 가진 회사와 제휴, 인수합병되는 것을 목표로 합니다.
반면 유통, 공급, 소비 구조는 생각보다 금방 만들어지지 않습니다. 사람의 인식과 습성이 변해야 하기 때문입니다. 사업 모델은 종종 기술보다는 사회적 시스템이 훨씬 더 중요합니다. 그래서 새로운 사업 모델을 개발하기 보다, 기존의 사업 모델을 활용하는 경우가 많습니다.
예를 들어 새로운 사업 모델을 기대했던 페이스북, 트위터, 인스타그램의 경우도 결국은 광고 모델을 선택했습니다.
4. 개발자에게 서비스/사업 모델이란?
개발자에게 서비스 모델과 사업 모델은 프로그램으로 구현해야 할 대상입니다. 즉, 어떤 부분을 프로그램으로 만들지 그것이 어떻게 작동해야 할 지 결정되지 않으면 절대 만들어 질 수 없습니다. 그래서 가능하면 개발 이전에 세부 사항들이 상세하게 결정되어 있어야 합니다.
그러나, 만일 '세상에 없는 것'을 만드는 것이라면 그렇게 하기 힘듭니다. 왜냐하면 사업 담당자도 어떻게 해야 할 지 모르기 때문입니다.
사람들이 곤충을 좋아하지 않거나, 입장료가 너무 비쌀 수도 있습니다. 그러면 빨리 사업 모델을 바꾸어야 합니다. 피봇팅이라고 합니다.
즉, 서비스 모델, 사업 모델이 언제나 바뀔 수 있고 사용자는 기대와 다르게 행동할 수 있습니다. 그래서, 세상에 없는 것을 만들 때는 깔끔한 아키텍쳐로 만들 수가 없습니다. 계속해서 흔들리는 사업 모델 때문에 룰은 흔들리고, 데이터는 금방 더러워지게 됩니다. 기술 부채가 급격히 늘어나서 시스템 투자 비용이 기하급수적으로 증가합니다.
개발자들에게 서비스나 사업 모델은 코드의 불확실성이자 데이터의 불일치, 그 자체입니다.
5. 적정기술의 선택과 단위별 재개발
적정기술은 문제 해결 자체에 집중한다.*** Level 1.
일반적으로 받게 되는 최초의 기획서는 완성된 사업 형태라기 보다 사업의 의지입니다. 하지만, 대부분의 사업은 의지대로 풀리지 않습니다. 그래서 최초의 기획서는 최종 형상이 아닙니다. 요구사항을 완벽하게 구현하더라도 얼마되지 않아 상당부분을 고치게 됩니다.
그래서 베테랑 개발자는 처음에 사업 담당자의 욕구를 듣습니다. 욕구는 사업이 망할 때까지 거의 변하지 않기 때문입니다.
데이터 모델은 Actor를 중심으로 느슨하게 모델링합니다. 기능을 최적화, 공통화시키기 보다 관리, 변경의 필요성을 중심으로 구축합니다.
그래서 처음에는 그냥 MySQL로 구축합니다. JOIN을 쉽게 할 수 있어서 서비스와 통계를 분리하지 않고 개발할 수 있기 때문입니다. 개발 기간이 짧아지지만, 급증하는 트래픽에 대응하기는 힘듭니다. 상황에 따라 다르지만 보통 100만 명 정도의 회원까지는 무난히 감당할 수 있습니다.
그런데 경험상 많은 업체가 이 단계에서 망합니다. 서비스 모델이 작동하지 않아서 회원이 모이지 않기 때문입니다.
따라서 복잡한 시스템을 구현하느라 시간과 자원을 낭비하는 것보다 간단히 구현해서 오픈해 보는 것이 훨씬 합리적인 선택입니다.
*** Level 2.
첫 단계에서 망하지 않았다면 회원이 늘어나고 데이터가 쌓이게 됩니다. 그러면 가장 먼저 통계 트래픽이 서비스에 영향을 주기 시작합니다. 이 때는 통계 DB와 서비스 DB를 분리합니다. 그러면 서비스 DB의 사용률이 떨어지면서 서비스 상태가 쾌적해집니다. 통계 DB는 사용률이 높아지면서 사업 운영도 탄력을 받게 됩니다.
비즈니스가 복잡해지면서 트랜잭션이 무거워집니다. 사용자수가 4~500만이 넘어가기 시작하면 IO 처리도 한계에 다다르고, API의 Call Flow도 복잡하게 얽히기 시작합니다. 그래서 이 때쯤 복잡한 시스템 구조와 데이터 모델을 고려해야 합니다. 과감하게 기존의 데이터 모델을 버리고 새로운 모델을 설계해야 합니다.
어플리케이션 모델도 Actor중심으로 분리합니다. 만일 Rule Base의 모듈 통합을 했다면 이 때쯤 낭패일 수 있습니다. 제휴 정책이 변하거나 영업 원칙이 변하면서 룰이 달라지는 경우가 적지 않기 때문입니다. 코드와 기능이 복잡하게 얽혀 손을 대기 힘든 경우도 많습니다.
사업 모델의 피봇팅이 발생되면 완벽했던 설계는 하루 아침에 부서져 버리기도 합니다. 성장하는 기업들은 거의 대부분 이 과정을 겪게 되는 것 같습니다. 현실적으로 모든 것을 예측해서 사업을 시작할 수 없기 때문입니다.
*** Level 3.
사업이 잘 되면 기능은 계속해서 복잡해지고, 데이터는 계속해서 늘어납니다. 사업 모델은 살아남기 위해 계속 변하고, 관리되지 않는 API들은 늘어납니다. 중요한 것은 이 모든 상황을 꿰뚫는 하나의 아키텍쳐는 없다는 것입니다.
그래서 세상에 없는 것을 만들 때는 반드시 내부 개발팀을 가지고 있어야 합니다. 그런데 내부 개발팀은 목표 기능이 복잡해지거나 서비스 모델이 커지면 함께 커지게 됩니다. 이 단계가 되면 인건비가 급격하게 늘어나 망하기도 합니다.
실리콘밸리는 이 단계의 투자 환경이 좋지만, 우리나라는 그렇지 않습니다. 그래서 이 때는 사업 속도의 조율과 협업 비용의 관리가 매우 중요하게 됩니다. 이것은 프로세스로 해결할 수 없고, 문화가 바탕이 되어야 합니다.
*** 교훈
즉, 사업 모델 및 서비스 모델을 잘 이해하고, 협업이 잘 되는 팀을 가지는 것은 회사의 성장에 매우 중요합니다. 왜냐하면 그런 팀은 회사의 상황에 맞는 적정기술을 선택하고, 성장 속도에 따라 시스템을 진화시키기 때문입니다. 그리고 이런 활동들이 회원정보와 서비스 데이터를 안정적인 회사의 자산으로 바꾸어 줍니다.
6. 개발자는 서비스 모델에 어떻게 참여하나?
대기업이라면 개발만 잘하면 됩니다. 그러나, 스타트업은 그렇지 않습니다. IT 사업에 있어서 기술은 제한된 자원입니다. 개발자의 수와 시스템의 품질 및 크기가 정비례하지 않습니다.
인터넷 서비스는 이 기술 자원을 효과적이면서 효율적으로 잘 사용해야 하는 게임입니다. 그런데 개발자가 서비스와 사업을 모르면 기술의 적정성을 결정할 수 없습니다. 그래서 엉뚱한 부분에서 시간을 낭비하게 됩니다. 이 포인트는 스타트업들이 대부분 아웃소싱에서 실패하는 이유이기도 합니다.
사업, 기획, 디자인, 개발의 엄격한 분업화는 악순환의 고리를 만들어 냅니다. 문제란 결코 나누어 일하기 좋게 끔 찢어져 있지 않습니다. 서로가 문제를 입체적으로 토론할 수 있어야만 어려움을 빠르게 극복할 수 있습니다.
7. SI 개발자들이 어려워하는 것들
인도의 아웃소싱 프로젝트룸
많은 서비스 회사들이 SI 개발자들을 채용하기 꺼려 합니다. 왜냐하면 많은 SI 개발자들이 아래와 같이 행동하기 때문입니다. 그러나, 이것은 업무 환경에 대한 인식의 차이에서 발생한 것입니다. 따라서 SI 개발자들에게만 해당되는 것은 아닙니다. 서비스 분야에서 처음 일하게 된다면 아래 사항들에 대해 진지하게 고민해 볼 필요가 있습니다.
첫째로. 요구사항이 없으면 일을 안합니다.
아웃소싱 프로젝트는 대부분 목표 시스템과 요구사항이 명확합니다. 그래서 요구사항없이 일을 하게 되면 사고로 이어지는 경우가 많습니다. 그렇게 일하도록 배웠고 그래야만 책임 분쟁에서 자유로울 수 있습니다.
둘째로. 서비스 및 사업모델의 문제점을 지적하기만 합니다.
기술 구현만 할 생각이기 때문에 요구 사항에 허점이 있으면 안됩니다. 데이터 오류를 피하기 위해 문제점을 미리 찾아서 보고해 줍니다. 그렇게 일하도록 배웠기 때문에 문제를 알아서 해결하려 하지 않습니다.
셋째로. 사업과 서비스 업무에 전혀 관여하지 않습니다.
제 경험상 사업 및 서비스 정책에 대해 가장 현실적으로 조언을 해 줄 수 있는 사람은 개발자들입니다. 왜냐하면 자기 손으로 직접 기능을 구현하기 때문에 부족한 점을 가장 먼저 보게 됩니다. 그리고 데이터가 잘못 쌓이는 걸 가장 먼저 알게 됩니다. 하지만, 운영 경험이 없는 개발자들은 그런 것에 대해 거의 신경쓰지 않습니다.
넷째로. 완벽하게 설계하고 변경을 고려하지 않습니다.
운영을 해보지 않은 개발자는 변경에 대해 극도로 보수적입니다. 왜 변경이 발생해야 하는지 이해하지 못합니다. 완벽한 설계 속에서 문제를 해결하려고 합니다. 예외를 인정하지 않습니다. 그래서 사업이 때를 놓치는 경우가 적지 않습니다.
다섯째로, 데이터 자산에 대해서 고려하지 않습니다.
일반적으로 SI 프로젝트는 기능을 구현해 주고는 철수합니다. 따라서 데이터를 어떻게 활용할 지에 대해서는 고민하지 않습니다. 그래서 SI 개발자들은 데이터 오류 검증이나 활용 방안에 대해서는 전혀 관심이 없습니다. 하지만, 서비스에서 데이터는 시장을 나타내는 지표이며, 사업의 목적이기도 합니다. 데이터에 관심이 없는 개발자를 만나게 되면, 반드시 어느 부분에서는 펑크가 나게 됩니다.
여섯째로. 유지 보수 업무를 단순 운영 업무로 이해합니다.
일반적인 IT 아웃소싱은 시스템을 구매하는 것입니다. 기능이 변경되면 별도의 예산을 통해 구매합니다. 따라서 유지 보수란 잘못된 기능을 보수하는 수준에 그칩니다.
그래서 개발하면서 운영하는 것에 대해 잘 이해하지 못합니다. 버전 관리나 형상 관리, 배포 관리의 중요성을 이해하지 못하는 경우가 많습니다.
서비스에 참여하게 되면 위 사항과 거의 반대로 생각하고 행동해야 합니다. 개발자도 사용자 가치를 만들어 내는 직접적인 주체이기 때문입니다.
SI 개발자라도 훈련을 통해 이런 주체성을 연습할 수 있습니다. 바로 자신만의 개인 프로젝트를 해보는 것입니다. 그러면 의사결정과 기술의 적정성 등에 대해 생각해볼 기회가 많아지게 됩니다. 태도라고 표현되는데 기술보다 생각과 마음을 바꿔야 한다는 것이 더 정확한 것 같습니다.
7. 요약
– 개인 프로젝트를 하자.
– 기술 외에 취미 하나씩 가지자. (기술을 공부하게 만드는 동기)
– 주도적이고 주체성 있는 개발자가 되자.
– 적정기술과 모듈별 재개발에 익숙해지자.
[IT의 중심에서] 시리즈
- (6) 페이스북은 어떻게 성장했을까
- (5) 유니콘 기업들의 핵심 경쟁력, 채용전략
- (4) 스타트업, 잘 헤어지기
