블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'start up'에 해당되는 글 2

  1. 2015.05.07 린스타트업 - #3 성장 엔진 이론
  2. 2013.03.14 조직의 성숙도별 개발 모델 (Devops & CD) (1)
 

린스타트업 - #3 성장 엔진 이론

비지니스/스타트업 | 2015.05.07 01:28 | Posted by 조대협

성장엔진


린 스타트업에서는 성장 엔진이라는 개념을 사용하는데, 이 성장 엔진이란, 린 스타트업에 따르면 "회사가 지속적으로 성장을 달성하는데 쓰는 메커니즘이다. "

린스타트업에서 성장엔진을 다음과 같은 변수로 정의하고 있다.

기본적으로 스타트업의 성장은 사용자가 늘어남을 전재로 하되, 사용자가 늘어나는 것 뿐만 아닌 비지니스 모델에 따라서 다음과 같은 지표를 추가 지표로 사용한다.


1. 재방문율 : 복합 비율로 측정


대부분의 서비스들에 해당하는 지표로, 기존 사용자의 재 방문율이다.

일반적으로는 액티브 사용자를 사용하지만, 린스타트업 프레임웍에서는 "복합 비율"이라는 성장 변수를 사용한다. 

재방문율 성장 엔진의 기본 개념은 신규 고객 유치율 > 가입 해지율 이 넘는지를 살펴본다. 가입 해지율은 명시적으로 계약을 해지 않더라도 서비스를 더 이상 방문하지 않는 고객의 비율을 의미한다. (일주일 동안 한번도 로그인 하지 않은 사용자등)

즉, 매주 10%의 고객이 증가하는데, 매주 가입 해지율이 10% 이상이면 이 회사의 사용자 수는 늘어나고 있지만 실제로는 성장하지 않고 있는 것이다.

복합 비율의 계산은 

(자연 성장율) - (가입 해지율) 

이다. 즉 전체 사용자 증가율에서 해지율을 빼보면, 서비스가 성장하고 있는지 여부를 판단할 수 있다.


2. 바이럴 성장 엔진


입소문이 아닌 서비스를 사용하는 사용자가 신규 사용자를 유치하게 되는 방식

- 핫메일의 보내는 메일 끝에, 핫메일 링크를 달아서 가입을 유도 한다던가

- 페이팔을 써서 친구한테 돈을 보내면, 받는 친구가 페이팔을 가입해야 한다던가.


이렇게 기존 사용자층이 서비스 사용을 통해서 신규 사용자를 확보하는 메커니즘을 바이럴 성장 엔진이라고 한다.

바이럴 성장엔진은 "바이럴 계수" 라는 것으로 측정하는데, 계산식은 다음과 같다.

(기존 고객 1명당 신규 고객 유치율)

즉, 10명의 고객중 1명만 1명의 신규 고객을 유치했으면 바이럴 계수는 0.1이 된다.

10명의 고객이 100명의 신규 고객을 유치했으면 계수는 10이된다.


이 바이럴 계수가 1 이상이면 한명의 고객이 한명 이상의 신규 고객을 가지고 온다는 개념으로, 바이럴 성장엔진에 의존하는 회사는 이 바이럴 계수를 높이는데 초점을 둬야 한다.

이렇게 바이럴 계수를 높이는 전략으로는 친구를 추천하면 추가 용량을 주는 것과 같은 드롭 박스의 전략등을 들 수 있다.

 

3. 유료화 성장엔진


유료화 성장엔진은 , 계산 방법은 

(고객당 수익:LTV-Life time value 또는 고객당 잠재가치 ) - (고객당 신규 유치비용:CPA-Cost per aquisition )

유료 서비스가 아니더라도, 광고등을 통해서 수익을 창출하는 서비스의 경우에도, 고객당 발생 가능한 광고 수익이 "고객당 수익" 개념이 된다.

페이스북과 같은 SNS 서비스가 있다고 가정하자 이 서비스에 신규 고객을 유치하기 위해서  들어 10억의 돈으로 100만명의 사용자를 모집했다고 하자 , 인당 고객 유치 비용은 1000원이고, 이 한명의 고객이 평생 광고를 보면서 발생할 수 있는 수익은 8만원이라고 할 때, 수익률은 8만원 - 1000원 = 79000원이다.

유료화 성장엔진을 사용하는 기업은, 이 LTV-CPA의 차이를 꾸준히 늘려나가는 것이 필요하다. 

※ 주) 마치 ROI(Return of investment) 개념 같은데. 게임과 같은 서비스가 적절한 모델일듯.



선택과 집중


기술적으로는 두개 이상의 성장 엔진을 사용할 수 있기는 한데, 책의 저자의 말에 따르면 성공한 스타트업은 하나의 성장 엔진에 집중한 경우가 많다고 한다.

하나의 성장엔진에 집중하고 회사의 모든것을 그 성장엔진이 돌아가는데 필요한 방향으로 특화한다. 세 엔진을 모두 선택하게 되면 복잡해지고 집중하기 어렵기 때문에 운영이 어렵다.


성장 엔진 부분은 세번을 읽고 도저히 이해가 안되서 글로 재정리하면서 다시 이해중인데, 결론적으로 보면, 회사의 성장을 이끄는 지표가 무엇인지를 조금 더 구체적으로 정의해주고, 기존의 허수 지표를 피할 수 있는 조금 더 효과적인 지표를 3가지 성장엔진 모델을 통해서 제시해주고 있다. 특히 스타트업의 서비스를 DAU나 MAU 등과 같은 액티브 사용자 계수으로만 측정하는 경우가 많은데  이보다는 복합 비율과 같은 

오랜만의 포스팅입니다. 그간 많이 바뻤습니다.

요즘 시스템 운영쪽에 관심이 많아서 Devops (Development + Operation)쪽을 틈틈이 보고 있습니다. 오늘은 조직의 성숙도별 개발 모델과 함께, CD (Continuous Delivery)와 Devops에 대해서 설명해보고자 합니다.



회사의 규모나 성숙도에 따라서 개발 모델을 크게 다음과 같이 3단계로 나눠볼 수 있습니다.


1. 스타트업


소규모에 처음 서비스 개발을 시작한 스타트업 기업 같은 경우에는 일단 모든 의사 결정이 빠르다. 아이디어가 나오면 별도의 승인이나 분석 없이 바로 개발하고, 개발이 끝나면 바로 배포 한다. 규모가 작고 모든 의사 결정이 팀내에서 이루어지기 때문에 매우 빠르다. 그리고 인력이 적기 때문에, 분석/설계/개발 및 운영이 같은 그룹에서 이루어진다.


2. 성숙된 개발 조직

어느정도 조직이 성숙되고, 인원이 많아지고 이익에 대해서 고민을 하게 되면, 조금더 체계화된 개발 프로세스를 원하게 된다.

한정된 예산으로 서비스를 개발하게 되며, 인원이 많아짐으로써 품질 저하를 막기 위해서 역할이 세분화 되고 체계화 된다.




아마 대부분의 일반적인 서비스 개발 이나 시스템 개발 기업들은 이러한 프로세스를 따를 것이다. 아이디어가 나오면, 발표하고 경영진을 설득하여 예산을 정하고, 요구 사항 분석을 통해서 범위를 정한후, 개발/테스트/수정을 한후, 모든 테스트를 통과하면 릴리즈 일정을 결정하고 산출물을 정리한후, 운영팀으로 이행한다.


체계화 되어 있기는 하지만, 앞서 설명한,Start up에 비해서는 전체적인 프로세스가 느리고, 운영으로 이관후, 자잘한 Fix나 Enhancement가 어렵다. 그리고, 새로운 기능이나 컴포넌트를 개발하려면, 새로운 프로젝트를 시작해서 위와 같은 전과정을 다시금 거쳐야 한다.


3. CD와 Devops기반의 개발 모델

요즘 같이 새로운 서비스가 많이 나오는 시절에, 저런형태의 개발 프로세스는 빠른 기능 추가등이 불가능하고, 운영중의 피드백을 받기 어려워서 SNS와 같은 서비스에는 적절하지가 않다. 

그래서 CD (Continuous Delivery)와 Devops라는 개념을 사용하는데


CD

CD는 Continuous Delivery의 약어로

운영 시스템에 계속해서 Fix나 새로운 기능을 지속적으로 Release를 하는 개념이다.

쉽게 예를 들어보면, 프로젝트 기간이 끝나면 릴리즈를 하는게 아니라, 매일매일 새로운 FIX나 기능이 추가되면 거의 매일 릴리즈를 하는 개념으로 보면 된다.

Face Book의 경우 이런식으로 매일 개발자가 새로운 기능을 운영 환경에 반영 및 추가 하는 것으로 알고 있다.


Devops

Devops는 Netflix에서 주로 시작된 개념으로 개발팀과 운영팀을 하나로 묶어서, 커뮤니케이션에서 오는 장애를 해소하고 빠른 서비스 개발과 반영을 하고자 함에 있다.

보통 개발팀과 운영팀이 나눠져 있는 것이 전통적인 모델인데, 이 경우에는 운영중에 고객의 요구 사항등이 개발쪽에 잘 전달되지 않고, 매일 서비스를 운영하면서 개선 사항이 있더라도 개발팀에 전달되기가 어려운 경우가 많다. 반대로, 개발쪽에서 무엇인가를 수정하면 수정 내용이 운영쪽에 제대로 전달되지 않아서 배포 실수등을 유발하여 시스템 장애를 유발하는 경우가 많다

그래서 Devops는 두팀을 하나로 합침으로써, 서로간의 의사소통을 빠르게 하고, 개발자가 직접 운영환경을 컨트롤함으로써 빠른 피드백을 받고, 빠른 반영을 통해서 서비스의 신속성을 향상 시키는 모델이다.


보통 이런 개념을 채용한 개발 모델은 다음과 같다.


위의 그림은 TDD를 채용한 그림인데, 먼저 테스트 계획서를 작성한후, 개발 및 테스트를 수행한후, 운영환경에 배포하고, 모니터링을 한다. 그리고 바로 신규 기능에 대한 피드백이나 효과를 모니터링해서 다시금 요구 사항을 정의하는 형태를 따른다

이렇게 Devops와 CD를 적용하기 위해서 중요한것은 자동화된 툴셋이 매우 중요하다.

개발 반영시 자동으로 꼼꼼하게 테스트를 할 수 있어야, 운영시 발생하는 장애를 방지할 수 있으며, 위의 전체 프로세스의 주체는 개발자가 되기 때문에, 복잡한 인프라나 미들웨어에 대한 배포를 자동으로 할 수 있어야 한다.

물론 자동화 툴셋은 어디까지나 구현 관점이다. 더 중요한것은 문화적인 차이점을 이해해야 하고, 프로세스의 변화를 인지하고 바꿔야 한다.

기존의 조직처럼 운영과 개발이 나눠져 있는 경우 조직을 합친다는 것은 기존에 가지고 있는 프로세스,  조직 구조를 모두 바꿔야 하는 것을 의미하며, 아울러서 기술셋도 모두 바꿔야 한다.

아울러 예산 집행 방식에 있어서도 기존에는 개발비용과 운영 비용을 나눠서 미리 잡아놓고 집행했기 때문에 초기 투자비와 운영비용(Running Cost또는 Opex), Devops 방식은 있는 인원들이 쭈욱 업그레이드와 운영을 계속해서 나가는 방식이라서 초기 투자비용보다는 운영비용(Running Cost)에 대한 부분이 커진다.


Devops나 CD의 경우에는 분명히 서비스 관점에서 가지는 이득은 매우 많지만, 변화의 폭이 기존 개발 방식에 비해서 매우 크기 때문에, 함부로 달려들 것은 아니라고 본다. 

그러나 스타트 업에서 규모가 커질 경우 위에서 언급한 정형화된 프로세스보다는 CD/Devops기반의 개발 프로세스로 비교적 쉽게 이동할 수 있고 얻는 이득도 많다.

기존의 대기업이나 SI기업의 경우에는 Devops 모델을 도입하기에는 변경되어야 하는 부분이 매우 많기 때문에, 매우 신중한 접근이 요구 된다.