IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

스타트업, 서비스 개발자가 되자.

이 글은 트위터나 페이스북 같은 서비스를 만들거나, 그런 회사에서 처음 일하게 된 개발자들을 위한 글입니다.
이런 회사가 처음인 개발자는 다음과 같은 상황에 직면하면 크게 당황하게 됩니다.
즉, 만들어야 할 서비스 로직이 정해지지 않았고 돈을 어떻게 벌어야 할 지 모르는 경우입니다.
여기에 대해 정리를 해보았습니다.


DevOps를 논의하는 팀원들

DevOps를 논의하는 팀원들

1. 변하지 않는 서비스/사업 모델은 없다.

100% 성공이 입증되어서 앞으로 변하지 않는 사업모델이 있을까요?
예를 한 번 들어 보겠습니다.

Fakebook 을 만들면 됩니다.
Facebook에 싫어요가 없으니 ‘싫어요’를 넣으면 대박을 칠 겁니다.
아마 네이버나 카카오를 뛰어 넘는 훨씬 훌륭한 기업이 될 것입니다.

아니면, 구글을 만들면 됩니다.
구글은 2015년 2분기 매출만 20조원이 넘었습니다.
검색엔진을 만들고, 클라우드 갖다 붙이면 됩니다.

구글이 어렵다면 유튜브를 만들면 됩니다.
현재 유튜브보다 더 신기술을 쓰고, 한국형 컨텐츠를 많이 올립니다.
그러면 한류 열풍을 타고 금방 유튜브의 경쟁자가 될 것입니다.

세가지 모두 성공한 서비스들이고, 대부분의 사람들이 그 기능을 상세히 알고 있습니다.
따라서 기능을 그대로만 개발해도 서비스가 성공할 수 있다고 생각합니다.

“그래서 이거 이거만 개발해주면 되.” 이런 이야기를 듣습니다.
조금씩 내용이 달라도 개발자들이 합류 시점에 많이 듣는 이야기들입니다.
하지만, 정말 그럴까요?

위 세가지 사례는 모두 공통점이 있습니다.
지금 보이는 성과는 오랜 시간과 과정을 겪은 결과라는 것입니다.

그 과정의 결과로 비즈니스 로직과 사업 모델이 안정되어 있습니다.
그 과정의 증거로 수많은 회원정보와 서비스 데이터가 남아 있습니다.
회원정보와 서비스 데이터는 그동안 서비스와 사업모델이 어떻게 변했는지 보여줍니다.

후발주자가 기능은 카피를 해도 회원 정보와 데이터를 카피할 수는 없습니다.
그러나 회원과 데이터가 다르면 서비스와 사업은 다르게 변합니다.
따라서 정보와 데이터를 모으기 위해 반드시 시행착오를 거치게 됩니다.
“인터넷 서비스”는 절대 한 번의 개발로 끝나지 않습니다.

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. 요약
– 개인 프로젝트를 하자.
– 기술 외에 취미 하나씩 가지자. (기술을 공부하게 만드는 동기)
– 주도적이고 주체성 있는 개발자가 되자.
– 적정기술과 모듈별 재개발에 익숙해지자.

Advertisements

스타트업, 서비스 개발자가 되자.”에 대한 12개의 댓글

  1. Suri Kim
    2016년 6월 7일

    좋은 글 감사드려요! 저는 대학 졸업하고 early stage 스타트업에서 일하고 있는데, 많은 조언 얻고 갑니다 :)

    • subokim
      2016년 6월 7일

      감사합니다. 화이팅하세요~

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

정보

이 엔트리는 2016년 5월 24일에 님이 개발자의 삶, 스타트업에 게시하였으며 , , 태그가 지정되었습니다.

내비게이션

누적 조회수

  • 951,808 Visits

페이스북 페이지

%d 블로거가 이것을 좋아합니다: