업무 프로세스의 변화
이번 글에서는 합류 한 후 실제 구체적으로 어떤 변화가 있었는지 이야기 하고자 합니다.
제품의 기술, 운영, 마케팅과 관련한 많은 변화들이 있었지만, 가장 중요한 것은 이 모든 것을 아우르는 업무 프로세스의 변화입니다. 지난 글 마지막 부분에서 언급한 '솔루션 중심에서 문제 중심으로 생각하고 움직이는 팀'이 되기 위해서는 업무 프로세스는 반드시 변해야하는 것이라 생각합니다.
2016년 5월까지 PUBLY의 개발팀은 애자일(Agile) 기반의 개발 프로세스를 갖추고 있었습니다. 4주의 스프린트(Sprint) 기간을 시작하며 무엇을 구현할 지 정하고, 기간이 끝난 후 회고 미팅을 하는 방식이었습니다. 당시 개발팀은 엔지니어가 모두 팀 외부에 있었던 상황이라 4주라는 꽤 긴 기간의 스프린트를 채택한 것을 제외하고는 평범한 프로세스였습니다.
문제는 무엇을 구현할지 정하는 과정이 솔루션 중심이었다는 것입니다. 예를 들어 유저 보이스(User Voice)가 굉장히 중요하게 다뤄지고, 개발 피쳐(Feature)를 정할 때 큰 역할을 하고 있었습니다. 유저 보이스에 과도하게 의존하는 것은 고객 중심의 서비스를 지향하는 팀이 저지르는 가장 큰 실수입니다.
고객에게 무엇을 원하느냐고 물으면 고객은 '더 빠른 말'이라고 대답할 것이다.
- 헨리 포드
과연 모르는 사람이 있을까 싶을, 너무나 유명한 말입니다. 그런데 정말로 '더 빠른 말'을 만들려고 한적이 없느냐고 물었을 때 "없다"고 자신있게 대답할 수 있는지 생각해봐야 합니다. 고객은 문제를 말하기보다, 상상 가능한 형태의 솔루션으로 이야기하는 경향이 있습니다. 그리고 고객이 제안한 솔루션에서 거꾸로 문제를 파악해내는 것이 서비스를 만드는 사람들이 해야하는 일입니다. 저희 팀은 이 단순한 명제를 끊임 없이 되새기며 잊지 않으려 노력합니다.
유저 보이스는 솔루션 중심이 아니더라도 '소수 고객의 이야기'일 수 있다는 한계를 갖고 있습니다. 고객의 의견은 소중하지만 목소리가 큰 일부 고객의 이야기를 일반화 해서는 안됩니다. 이를 위해 많은 고객이 꾸준히 이야기하는 것과 아닌 것을 구분해야 하며, 유저 보이스의 트렌드(혹은 경향성)을 지속적으로 모니터링해야 합니다. 또한 일부 고객이 아닌 임의로 선택된 다수의 고객을 찾아가 직접 인터뷰(User Interview)를 할 수도 있습니다.
제가 재정비하고자 하는 업무 프로세스는 위에서 이야기 한 3가지 방법(User Voice, User Interview, Data Analysis)을 통해 '문제'를 밝혀내는 것으로 시작합니다.
어떤 문제가 있는지,
지금 해결해야 하는 문제인지,
다른 문제와의 우선순위는 어떻게 할지,
충분히 고민하고 나서 솔루션을 찾습니다.
이후 잘 정의된 문제를 가지고 솔루션을 찾는 과정에는 소프트웨어 엔지니어, UX 디자이너 등 개발 업무를 담당하는 사람들뿐만 아니라 운영, 마케팅(그로스 해킹) 담당자 등 제품에 관여하는 모든 사람이 참여합니다. 그리고 참여한 사람들은 각자의 전문성을 활용하여 솔루션을 내놓아야 합니다. 이처럼 크로스 펑셔널 팀(Cross functional Team)이 되어야만, 일부 분야의 전문성을 넘어서는 더욱 다양한 솔루션 후보를 내놓을 수 있습니다.
다수의 솔루션 후보가 정해지면, 최종적으로 어떤 솔루션을 채택할 지 정합니다. 그리고 채택한 솔루션이 실제로 문제를 해결하는지 실험을 합니다. 실험을 통해 해당 솔루션의 성과를 평가하고 현재 상태로 유지 할지, 더 발전시킬지, 또는 버리고 이전 상태로 되돌릴지 결정하게 됩니다.
위에 설명한 과정을 2주 정도의 간격으로 반복합니다. 저는 이것을 문제해결 스프린트라 부릅니다. 애자일 방법론에서 스프린트를 활용하는 이유는 주요 피쳐를 개발하는 과정에서 개발팀이 방해받지 않기 위해서입니다. 일반적인 개발 스프린트가 아닌 문제해결 스프린트를 두는 이유는 방해받지 않아야 할 기간의 단위가 피쳐가 아닌 문제-해결 중심이어야 하기 때문입니다.
기술적인 부분에서의 변화
PUBLY 서비스는 2016년 5월까지 PHP 5를 CodeIgniter Framework와 함께 쓰고 있었는데, 이를 PHP 7과 Laravel 5 Framework으로 교체했습니다. PHP는 엔지니어들 사이에서 여러면에서 부정적으로 평가받고 있지만, PHP 7에서의 성능 향상과 Laravel이라는 Modern Framework의 등장은 PHP를 재조명하고 있습니다. 아직도 PHP에 대해 부정적이거나 PHP의 Modern Framework 생태계에 대해 궁금한점이 있다면 아래 글을 참고해주시기 바랍니다.
- Taking PHP Seriously (by Keith Adams, Slack Engineering)
- Modern PHP (by 전창완, @wan2land)
그런데 라이브로 이미 서비스가 제공되고 있는 상태에서 새로운 기술 스택으로 모든 기능을 한번에 마이그레이션 하기가 매우 어려운 상황이었습니다. 저는 평소에 모든 피쳐 및 기반 시스템을 직접 개발하기보다 가능한한 외부의 서비스를 결합(Integration)하여 쓰는 것을 선호합니다. 이 경우 개발 비용의 효율화가 가능할 뿐만 아니라, 서비스의 다양한 기능들이 모듈화 되고 기술적으로 디커플링(Decoupling)되는 장점이 있습니다.
이에 착안하여 저희 서비스를 내부적으로도 각각의 분리된 서비스의 형태로 만들면 어떨까 생각했습니다. 그리고 나중에 이러한 구조가 흔히 Microservice Architecture(MSA) 라고 불리는 것을 알게되었습니다. 현재 publy.co의 벡엔드는 기존 단일한 API 서비스의 각 기능들이 분리되어 auth-service(로그인, 유저정보), content-service(프로젝트, 콘텐츠), payment-service(결제, 주문), notification-service(알림), maintenance-service(메인터넌스) 등으로 이루어져 있습니다.
운영에서의 변화
우선은 deploybot이라는 스크립트 기반의 단순한 배포 서비스를 도입했습니다. 그리고 rollbar와 new relic을 통해 애플리케이션 에러와 서버 상태를 모니터링 했습니다. 운영 담당자를 영입하여 배포 전(Staging)/후(Production) QA 단계를 두어 안정성을 높였습니다.
서비스 운영은 제품의 질에 대한 관리뿐만 아니라 사용자와의 접점으로써도 많은 역할을 해야 합니다.
사용자로부터 '문제'를 찾아내는 것은
서비스 운영 담당자의
가장 중요한 일이기도 합니다.
저희 팀은 아직 QA에 너무나 많은 시간을 써야 하는 상황입니다. 이를 해결하기 위해 가능한 테스트를 자동화할 수 있도록 노력하고 있습니다.
현재 백엔드의 결제 관련 주요 로직에 대해서는 배포시 자동으로 유닛 테스트(Unit Test)를 하고 있으며, 추후 개발 전반에 걸쳐 TDD(Test Driven Development)를 도입하여 운영 담당자의 QA 부담을 크게 줄일 수 있도록 할 예정입니다. QA 효율화를 위해서는 우선적으로 고객과의 커뮤니케이션을 돕는 티켓팅 서비스 Zendesk를 도입했으며, 정성적인 부분에서의 고객의 문제를 파악하고자 Hotjar라는 분석/조사 툴을 사용하고 있습니다.
마케팅 측면에서의 변화
이전 글에서 이야기 했듯 제품 측면에서 이루어지는 마케팅을 그로스 해킹(Growth Hacking)이라 합니다.
그로스 해킹의 핵심은
결국 불확실성을 최소화하면서
성장하는 것입니다.
이를 위해서는 사용자의 행동과 특성을 정밀하게 분석하는 것이 중요합니다. 그렇기 때문에 제가 합류했을 당시 팀에 가장 시급히 필요했던 것은 PUBLY 서비스에 적합한 분석 도구(Analytics Tool)를 도입하는 것이었습니다.
국내에서는 구글 애널리틱스(Google Analytics, 이하 GA)를 가장 많이 사용하고 있지만, 저는 개인적으로 GA를 추천하지 않습니다. 이유인즉슨, GA는 기본적으로 페이지뷰(Pageview)와 세션(Session) 중심의 분석을 제공하는데, 이벤트(Event)와 유저(User) 중심의 분석이 좀 더 유의미한 도움이 된다고 생각하기 때문입니다.
이벤트 중심의 분석 툴은 Mixpanel, Kissmetrics가 전통적으로 유명하지만 저희는 최근에 많은 성장을 하고 있는 Amplitude를 최종적으로 선택했습니다. 이러한 이벤트 중심의 툴과 GA의 차이점은 여러가지가 있으며, 저에게는 다음의 3가지의 단점이 GA를 쓰지 않는 가장 결정적인 이유입니다.
- 실시간(real time) 데이터를 제공하지 않습니다. 전환 최적화를 진행하다보면 빨리 결과를 보고 결정을 해야 하는 경우가 생길 수 있는데 이때 어려움이 있을 수 있습니다.
- 퍼널(Funnel)을 새로 정의했을 때 정의 시점 이전의 전환율을 볼 수 없습니다. 새로운 퍼널을 정의하고 분석하면서 이전의 전환율을 볼 수 없다는 것은 매우 큰 단점입니다.
- 세션/디바이스 단위의 데이터 수집을 하여 사용자 단위의 행동 분석을 하기 힘듭니다. 따라서 사용자가 여러 개의 디바이스를 통해 행동하는 것을 통합해서 추적하기 어렵습니다.
사실 위의 문제들은 약간의 번거로움만 극복하면, GA에서도 해결 가능합니다. 게다가 GA는 다른 툴들이 제공하지 않는 다른 강력한 기능들도 많기 때문에 '잘만 쓴다면' 훌륭한 툴입니다. 따라서 GA가 이미 손에 익은 상태라면 굳이 바꿀 필요는 없습니다.
하지만 데이터 분석 초보자라면 웬만하면 GA로 시작하지 말라고 조언하고 싶습니다. GA는 설치하자마자 너무나 많은 숫자를 보여줍니다. 그렇기 때문에 초보자의 경우, GA가 기본적으로 보여주는 다양한 숫자를 보며 본인이 '데이터를 잘 보고 있다고 착각'을 합니다.
하지만 대부분의 경우,
정작 중요한 데이터가 뭔지 모르고
GA에서 보여주는 많은 숫자를
'보고 있다는 것만으로'
만족하는 경우가 많습니다.
데이터를 분석할 때 '일단 봤으니 됐다'하는 마음은 가장 경계해야 할 생각 중 하나입니다.
데이터 분석은 가설에서 시작해야 합니다. 예를 들어, 고객이 유입 이후 구매를 하는 과정에서 문제가 있는가? 콘텐츠를 충분한 시간 동안 보지 않고 바운스(bounce) 되는것이 아닌가? 와 같은 가설을 먼저 세우고 그에 대한 답을 줄 수 있는 데이터가 무엇인지 고민해야 합니다. 단순히 GA가 보여주는 몇가지 전형적인 데이터만 가지고서는 데이터 분석을 한다고 할 수 없습니다.
2016년 여름 PUBLY 팀 내부 교육 세션으로 진행했던 자료 중 성장 엔진(Growth Engine) 관련 설명했던 슬라이드 ⓒ이승국
분석 기반을 갖춘 후 다음에 해야 하는 일은 제품의 성장 전략을 결정하는 것입니다. 그로스 해킹 측면에서 성장 전략은 크게 3가지로 나눌 수 있습니다.
단순 유입,
재방문,
그리고 바이럴을 통한 성장입니다.
물론 이 3가지는 복합적으로 작용하여 제품의 성장을 만들어내지만, 리소스가 제한적인 초기 스타트업의 경우 비즈니스 모델(Business Model) 또는 각 성장 단계에 따라 가장 중요한 한가지에 집중해서 성장하는 것을 추천합니다.
PUBLY는 처음에는 다른 미디어 콘텐츠 사업과 비슷하게 바이럴 중심의 성장 전략을 택했습니다. 주로 유료 콘텐츠를 홍보하기 위한 무료 글을 작성하여 PUBLY 플랫폼 내부와 다른 소셜 미디어를 통해 노출시키고 공유를 유도했습니다.
그러나 일반적으로 미디어 콘텐츠 사업자가 바이럴 중심의 성장 전략을 택하는 이유는 수익 모델이 트래픽을 통한 광고 매출이기 때문입니다. 이러한 모델에서는 1) 유입되는 트래픽이 모두 수익을 창출한다는 점, 그러나 2) 개별 트래픽의 수익성이 매우 낮다는 특징을 가지고 있습니다. 따라서 낮은 비용으로 많은 트래픽을 모아야 하는 것이 과제이며, 필수 불가결하게 바이럴 중심의 성장 전략을 택할 수 밖에 없습니다.
아시다시피 PUBLY는 이와 정반대인 서비스입니다. PUBLY 서비스에는 광고가 전혀 없고, 유료 콘텐츠 판매를 통해 매출을 발생시킵니다. 그렇기 때문에 홍보 글이 많이 공유되고 사용자가 유입된다 한들, 아무도 구매하지 않으면 수익을 창출하지 못합니다. 실제로 한 소셜 미디어에서 20만 뷰를 넘긴 한 무료 글은 단 한건의 구매도 유도하지 못했습니다. 반면에 유료 콘텐츠에 관심을 가질만한 사람들을 잘 타겟팅하여 단순히 상품 설명 페이지로 광고를 했을 때는 마진이 충분히 남는 수준에서 상당한 구매를 유도할 수 있었습니다.
이러한 시행착오를 겪으며, 지난 6개월 간 저희 PUBLY팀은 사용자를 단순한 방법으로 유입시킨 다음 구매를 잘 유도하는 것으로 성장의 방향을 정했습니다. 우리가 출판하고 있는 유료 콘텐츠에 관심 있어할만한 주 타겟층을 잘 발굴하고 쉽게 구매할 수 있도록 만들어 주는 것에 집중하는 것입니다. 그리고 플랫폼 내에서 공유를 유도하는 대부분의 기능은 서비스 단순화와 관리 비용을 고려하여 삭제하였습니다.
PUBLY 콘텐츠 팀에서 정성을 다해 발행하는 유료 콘텐츠의 미리보기(Preview) 글들
콘텐츠팀 역시 저의 문제 의식에 공감하여, 홍보 목적의 미리보기 글의 KPI를 페이지뷰가 아닌 유료 콘텐츠 판매 전환율로 재설정하였습니다. 기존에는 많은 사람들이 관심을 가지고 공유할만한 '다수의 글'을 작성하는데 많은 힘을 썼으나, 현재는 한 편의 무료 글을 발행하더라도 '유료 콘텐츠 구매를 결정하는 데에 있어 도움을 주는 글'을 쓰는데 집중하고 있습니다.
물론 미디어/콘텐츠 비즈니스를 하면서 바이럴 성장 전략을 완전히 배제하는 것에 대해서는 우려가 있을 수 있습니다. 콘텐츠를 소비하는 형태에 관계없이 콘텐츠를 소비하는 사람들과 신뢰를 형성하고 바이럴을 유도하는 것은 성장에 중요한 요소가 될 수 있기 때문입니다.
하지만 제가 앞서 이야기 했듯,
스타트업의 성장 전략은
스타트업의 단계에 따라
달라져야 한다고 생각합니다.
그렇기 때문에 저희 팀 또한 내년 상반기 중 재방문 또는 바이럴 중심의 성장 전략을 채택하는 시점이 오지 않을까 예상하며 준비하고 있습니다.
마치며
이상으로 PUBLY에 합류 후 6개월간 제가 해온 일을 정리하는 글을 마칩니다. 처음 글을 쓰기로 결정했을 때만 해도 3편의 글을 3주에 쓰는 것을 목표로 했습니다. 그런데 실제로 모든 글을 마무리 하는데에 2개월이 넘는 시간이 걸렸습니다. 머리 속으로 생각은 많이 해왔는데 글로 풀어내는 것은 또 다른 이야기인 것 같습니다.
평소 글을 통해 표현하는 것을 즐기지 않아 과연 읽어 주는 분들이 있을까 하는 두려움이 있었습니다. 두려움을 극복하고 글을 마칠 수 있었던 것은 개인적으로 호응을 보내주신 분들이 있었기 때문입니다. 감사드리며, 앞으로 저희 PUBLY의 제품이 진화해 나가는 과정을 계속 지켜봐주시기 바랍니다.
이전 글 바로가기: PUBLY가 개발자를 생각하는 방법