그로스 해킹

- “열한 명의 뛰어난 선수들이 훈련에 최선을 다하고, 체중을 유지하고, 충분히 숙면을 취하고, 정확한 시간에 경기장에 나타나기만 한다면, 승리의 절반은 이미 이룬 셈이다. 그러나 놀랍게도 많은 구단들이 이 간단한 일을 해내지 못한다. " (리딩(알에이치코리아, 2016))
- 그로스 해킹이란?
* 크로스펑셔널한 직군의 멤버들이 모여서
* 핵심지표를 중심으로
* 실험을 통해 배움을 얻고, 이를 빠르게 반복하면서
* 제품이나 서비스를 성장시키는 것
- 생각해 보면 서비스 기획을 하는 입장에서 '이런저런 자료를 다각도로 검 토한 결과 내 논리에는 빈틈이 없어. 이렇게 하는 게 맞아.'라고 확신하는 것만큼 위험한 게 없다. 마찬가지로 기획 과정에서 내부 설득이나 보고를 위한 논리를 계속 덧칠하는 것만큼 부질없는 짓이 없다. 논리적인 기획자 가 나쁜 건 절대 아니지만 논리에 함몰되는 기획자는 분명 서비스에 나쁜 영향을 미친다. 제품을 만들 때는 부장님과 상무님을 바라보면서 기획서 를 쓰고 제품이 출시되고 나서야 사용자를 찾는다면 그 제품은 십중팔구 사용자에게 외면받게 될 것이다.
- 성장하고 있는 시점에도 기능을 추가하고, 성장세가 둔화되면 기능을 추가한다. 사실 많은 회사에서 서비스 개선'이라는 용어를 기능 추가와 동일한 의미로 사용한다. 사용자가 원하는 꼭 필요한 기능을 추가한다면 다행이지만 그렇다고 해서 서비스 개선이 기능 추가와 동일시되는 건 분명히 문제가 된다. 추가되는 기능만큼 서비스의 복잡도는 높아지고 자연스럽게 뒤따라오는 레거시(legacy)가 늘어나기 때문이다. 서비스에 특정 기능을 추가할 때는 관련된 운영 정책, 고객 커뮤니케이션, 로그 기록과 수집 등 기능이 추가되면서 발생하는 유지보수 리소스를 꼭 고려해야 한다. 이후에 더 자세히 설명하겠지만 제품이 기능의 조합이 되어서는 안 다. 제품은 가설의 조합으로 이뤄져야 하며, 그러한 가설을 테스트하기 위한 최소한의 기능으로 이뤄져야 한다. 기능이 많은 제품이 성공하는 게 아니라 최소한의 기능으로 사용자에게 가치를 전달할 수 있는 제품이 성공한다는 점을 꼭 기억할 필요가 있다.
- 만약 우리 서비스가 제품시장 적합성을 충분히 만족하지 못하는 것처럼 보인다면 이를 개선하기 위해 어떤 것들을 할 수 있을까? 이 시기에 해서는 안 되는 것과 해야 하는 것을 정리하면 다음과 같다.
해서는 안 되는 것
* 브레인스토밍
* 새로운 기능을 추가하는 것
* 잔존율이나 전환율을 개선하기 위한 실험
단순한 브레인스토밍은 이 시기에 거의 도움이 되지 않는다. 상상 속에서 만든 제품이 실제 시장의 요구사항을 담아내지 못했는데 여기에 또 다른 상상을 덧붙여 봐야 상황이 개선될 리 없기 때문이다. 앞서 언급한 것처럼 새로운 기능을 추가하는 것은 이 시점에서 할 수 있는 가장 나쁜 선택이라 는 점도 꼭 기억하자. 사실 이 시기에 머물러야 하는 곳은 책상 앞이나 회 의실이 아니라 제품을 사용하는 고객의 옆이어야 한다.
- 브레인스토밍을 하지 말라는 이야기는 그렇다고 해도 잔존율이나 전환율을 개선하기 위한 실험을 이 시기에 하면 안 된다는 이야기를 하면 많은 사람들이 의아해한다. 제품 시장 적합성을 판단하는 데 잔존율과 전환율이 중요하다고 강조했으면서 이걸 개선하는 실험을 하지말라는 것은 어떤 의미일까? 이 단계에서 리텐션과 전환율을 높이기 위한 실험을 해서는 안 된다는 의미는 자칫하면 리텐션과 전환율을 높이는 것 자체가 '목적'이될 수 있기 때문이다. 이 단계에서의 목적은 제품 시장 적합성을 찾는 것이고, 리텐션과 전환율은 이를 확인하기 위한 수단으로 활용해야 한다. 가 령 가입하는 모든 회원에게 매일 푸시 알림을 보낸다면 일시적으로 리텐 션 지표가 높아질 수는 있지만 그렇다고 해서 서비스가 푸시 알림 때문에 갑자기 제품 시장 적합성을 만족한다고 볼 수는 없다. 리텐션과 전환율은 제품-시장 적합성을 찾고 난 이후의 결과로 나타나는 지표이고, 이 지표 자체를 개선하는 것이 목적이 돼서는 안 된다는 점을 꼭 기억하자.
해야 하는 것 
* 사용자를 직접 만나서 이야기를 듣기
* 사용자 행동 데이터 분석
- 이 시기에 해야 하는 가장 중요한 일은 사용자에 대해 더 많이 연구하고, 사용자를 이해하려고 노력하는 것이다. 특히 사용자를 이해하려면 직접 만나서 이야기를 듣는 과정이 꼭 필요하다(물론 사용자 인터뷰는 이 시기뿐 아니라 서비스를 만들고 개선해 나가는 전 과정에서 꼭 필요한 일이 다). 사용자가 우리의 의도대로 서비스를 잘 쓰고 있는지, 우리가 포착하지 못한 숨겨진 니즈는 없는지, 실제로 제품을 사용하는 맥락이나 환경이 우리가 생각한 것과 동일한지에 대해 사용자의 생각을 직접 들어보고 그 행동을 꼼꼼하게 관찰해야 한다. 이 시기에 필요한 것은 1:1 사용자 인터뷰와 행동 관찰이다. 이 단계에서 포커스 그룹 인터뷰(Focus Group Interview)를 진행하는 경우도 있는데, 일반적으로 깊이 있는 인사이트를 찾기 위해서는 1:1로 진행하는 사용자 인터뷰(In-Depth Interview)가 더 효과적이다. 
- AARRR을 활용하는 방법
* 각 단계별로 풀어야 하는 문제를 확인한다.
* 각 단계의 핵심이 되는 주요 지표를 선정하고, 해당 지표의 현재 수준을 측정한다.
* 측정된 지표가 가지는 의미를 이해한다.
* 개선해야 하는 목표 수준을 정하고, 실험을 통해 단계적으로 개선한다.
- 페이팔(PayPal) 창업자이자 《제로 투 원(한국경제신문사, 2014)의 저자 로 알려진 피터 티엘(Peter Thiel)은 '사업이 실패하는 이유는 제대로 된 채널 하나를 확보하지 못하기 때문'이라고 이야기한 적이 있다. 많은 마케 팅팀에서 빠지기 쉬운 함정 중 하나가, 고객 유치 성과가 정체된 것처럼 느껴질 때 기존 채널에 대한 최적화를 고민하기보다는 새로운 채널을 찾 고 테스트하는 데 지나치게 많은 리소스를 쓰는 것이다. 물론 기존에 놓치 고 있던 채널 중 우리 서비스와 잘 맞는 곳이 있을 수도 있지만 무작정 새 로운 채널을 추가한다고 해서 고객 유치 성과가 개선되는 것은 아니다. 채 널을 계속 늘려가는 것은 관리해야 할 포인트도 함께 증가한다는 의미이고, 새로운 채널의 특성을 공부하고 테스트를 진행하고 결과를 분석하는 일련의 과정은 비교적 많은 시간과 노력을 필요로 하는 일이다. 무엇보다, 새로운 채널을 찾는 것보다 기존 채널을 효율화하는 것이 더 좋은 결과를 가져오는 경우가 많다. 특히 스타트업이라면 단순히 많은 채널을 찾으려고 하기보다는 영향력 있는 소수의 채널을 찾아서 해당 채널의 효과를 극대화하는 것을 목표로 삼는 편이 훨씬 바람직하다. 많은 마케터들이 '예산 규모가 늘어나면 새 로운 채널을 찾는다. 하지만 채널 확장은 예산이 아니라 채널의 포화도 (Saturation)를 바탕으로 결정해야 한다. 채널의 포화도를 판단하려면 우선 각 채널 운영이 충분히 최적화돼 있는지를 점검해야 한다.
- 리텐션이 가파르게 떨어지는 구간을 지난 후 안정화되는 단계에서는 사 용자와의 관계를 잘 유지하는 것이 중요하다. 정기적인 커뮤니케이션 플 랜이나 CRM 마케팅 활동, 주기적으로 진행하는 프로모션 등이 도움이 된 다. 특히 일정 기간 미사용 후 휴면 고객이 되는 사용자들을 대상으로 적 절한 복귀 명분을 만들어주는 리마케팅(Re-Marketing) 등을 꾸준히 진행할 필요가 있다. 한번 떨어진 리텐션을 끌어올리기는 쉽지 않다. 떨어진 리텐션을 끌어올 리는 것보다는 애초에 리텐션이 떨어지지 않도록 관리하는 편이 현명하다. 일반적으로 높은 리텐션을 유지하는 방법 중 하나는 서비스를 통해 '축적되는 가치를 만들고 이를 사용자에게 지속적으로 전달하는 것이다. 반대로 후발주자로 시작하는 서비스들은 경쟁 서비스의 사용자들을 데려 오기 위해 그동안 축적해 놓은 가치를 손실 없이 이전하는 기능을 제공하는 경우가 많다.
- 리텐션을 개선하기 위한 활동들을 할 때 주의해야 할 점은 단순히 리텐션 지표만 보지 말고 전반적인 사용자 경험을 고려해야 한다는 점이다. 사실 푸시, 이메일, SMS 등 커뮤니케이션 채널을 반복적으로 활용하면 일시적인 리텐 션 지표는 무조건 올라간다. 특히 한 달에 한 번만 접속해도 숫자가 집계 되는 MAU(Monthly Active User)의 경우 약간의 꼼수만으로도 크게 높 일 수 있다. 하지만 사용자 입장에서 커뮤니케이션 채널에 대한 피로 관리가 제대로 되지 않으면 단기적인 효과는 있을지 몰라도 장기적으로는 악영향이 누적된다는 점을 반드시 유의해야 한다. 특히 앱 푸시 등의 촉발제 (Trigger)를 반복적으로 사용하면 당연하게도 앱 삭제(uninstall)나 회원 탈퇴 같은 부작용이 증가할 수밖에 없다. 이 때문에 유저 커뮤니케이션 채널은 사내의 특정 부서에서 일원화해서 관리하는 편이 좋다. 이 과정에서 발송되는 메시지의 빈도나 총량이 너무 많아지지 않도록 유의해야 한다. 특히 전체 회원을 대상으로 하는 앱 푸시나 이메일을 발송한다면 해당 푸 시나 이메일에 대한 클릭율이나 반응율을 보는 것과 함께 해당 푸시나 이 메일로 인한 앱 삭제나 회원 탈퇴와 같은 부작용 지표들을 체크할 필요가 있다. 리텐션은 단기적인 이벤트보다는 장기적으로 꾸준히 진행하는 활동을 통 해 점진적으로 개선되는 지표다. 리텐션을 잘 관리하면 복리 효과로 돌아 오지만, 반대로 리텐션이 안 좋은 상태로 장기간 누적되면 그에 따른 마이너스 효과도 복리로 누적된다는 점을 기억하자.
- 고객 생애 매출 100원, 고객 획득 비용 50원(수익 50원)인 서비스
1. LTV 10% 증가 → 고객 생애 매출 110원, 고객 획득 비용 50원(수익 60원)
2. CAC 10% 감소 → 고객 생애 매출 100원, 고객 획득 비용 45원(수익 55원)
다만 현실적으로는 고객 생애 매출보다는 고객 획득 비용이 조금 더 변화 시키기 쉬운 지표이기 때문에 이쪽에 먼저 집중하는 경우가 많다. 비즈니스 모델이나 수익 구조를 단기간에 바꾸기는 쉽지 않지만 고객 획득을 위 한 마케팅 채널이나 소재는 비교적 쉽게 테스트할 수 있기 때문이다. 따라 서 현실에서는 이 두 지표를 다음과 같은 형태로 많이 사용한다.
1. 고객 생애 매출을 먼저 구한다. 앞서 설명한 대로 가입 코호트를 활용해 코호트별 비교를 하거나 고객 생애 매출의 기간별 변화 추이를 살펴보면 좋다.
2. 고객 생애 매출을 고려해서 목표로 하는 고객 획득 비용 수준을 정한다. 수익 구조나 마진을 고려해서 고객 생애 매출의 1/5 ~1/10 정도를 목표로 잡으면 좋다. 이 수치가 마케팅을 진행할 때의 의사결정 기준이 된다.
- 온보딩 프로세스 : 친구 초대 메시지를 전송하는 순간까지의 프로세스에 신경 쓰는 서비스는 많지만 막상 초대받은 친구가 메시지를 수신하고 앱을 설치하고 회원가입 을 하는 온보딩 프로세스에 관심을 두는 곳은 많지 않다. 물론 친구의 추 천이라는 강력한 명분이 있기 때문에 친구 초대 경로로 들어온 사람들은 일반적인 마케팅을 통해 데려온 사용자보다 가입 전환율이 높은 편이긴 하지만 온보딩 프로세스를 세심하게 설계하면 친구 초대의 효과를 크게 높일 수 있다.에어비앤비는 친구 초대를 굉장히 적극적으로 활용하고 관련 테스트도 활 발하게 진행하는 서비스로 알려져 있다. 에어비앤비는 초대받은 친구의 온보딩 프로세스 전환율이 매우 높은 것으로 알려져 있는데, 실제로 에어 비앤비는 초대받은 친구의 온보딩 화면을 주제로 굉장히 많은 실험을 진 행했다. 그림 3-50을 보면 첫 단계에서부터 전화번호를 입력받는 일반 가 입 화면과 달리 친구 초대를 통해 가입 화면에 진입한 사용자에게는 초대 한 친구의 프로필 사진과 이름, 가입 연도 등을 표시하고 할인 혜택에 대 한 내용을 상단에 크게 강조한 것을 볼 수 있다.
- 그로스 해킹을 돈을 쓰지 않고 하는 마케팅으로 잘못 이해하는 사람들 이 있는데, 이 경우 입소문을 이용한 논페이드(non-paid) 마케팅이 그 로스 해킹의 전부인 것처럼 오해하게 된다. 그로스 해킹은 앞서 언급한 AARRR에 해당하는 모든 활동들을 통합적으로 지칭하는 용어이지 단순 한 바이럴 마케팅 활동을 지칭하는 용어가 아니다. 추천을 통한 바이럴 루 프가 잘 동작하는 경우 서비스 규모를 키우는 데 큰 도움이 되는 것은 맞 지만 이를 위해 바이럴의 기능적 요소에만 지나치게 집중하는 것은 전후 가 뒤바뀐 것이다. 우선은 바이럴이 일어날 수 있을 정도로 좋은 제품을 먼저 만들고, 그다음으로 서비스를 주변에 추천할 수 있는 자연스러운 초대 맥락을 기획해야 한다.
- 추천과 관련된 사용 플로는 필수적으로 신규 사용자 경험 (NUX, New User Experience)과 연계된다는 점을 고려해야 한다. 그런 의미에서 추천 시스템이 잘 동작하려면 앞서 설명한 활성화(Activation) 단계가 잘 구축돼 있어야 한다. 가입과 온보딩은 유저가 우리 서비스에서 단 한 번 겪는 경험이고, 이 때문에 코호트를 나누거나 테스트를 진행하기 쉽지 않다. 그럼에도 불구하고 이 프로세스를 꼼꼼하게 잘 설계해두면 초 대받은 새 사용자의 이탈을 방지함으로써 추천의 효과를 극대화할 수 있다는 점을 꼭 기억하자.
- 좋은 지표가 가져야 할 조건 중 하나는 그 지표를 바탕으로 행동할 수 있 어야 한다(actionable)는 것이다. 지표가 주는 정보를 기반으로 다음 행동 을 계획할 수 있고, 계획에 따라 실험을 진행한 이후에 그 결과를 돌아보 며 배움을 얻을 수 있다면 굉장히 의미 있는 지표라고 할 수 있다. 반대로 행동을 이끌어내지 못하는 의미 없는 지표도 있다. 이런 유형의 지표를 허무 지표(Vanity metric) 혹은 허상 지표라고 한다. 단순히 시간이 흐르면서 자연스럽게 높아지는 지표, 실제로 중요한 수치와는 크게 상관 이 없는 지표, 단순히 많은 일을 했다는 것을 드러내기 위한 지표가 여기 에 속한다. 허무 지표는 서비스가 올바른 방향으로 가고 있는지에 대한 정보를 거의 주지 못한다. 앞서 지표의 속성을 스톡과 플로로 구분해서 설명했는데, 스톡 지표의 경우 특별한 맥락에서 사용되는 일부를 제외하면 허무 지표인 경우가 많다.
- 데이터와 지표가 있다고 해도 이를 정확하게 해석하고 의사결정을 내리는 것은 생각보다 간단하지 않다. 코호트 분석, A/B 테스트, 퍼널 분석 등 데 이터를 통해 유의미한 인사이트를 찾아내는 방법에는 공통점이 있다. 바 로 데이터를 쪼개서’ 살펴본다는 점이다. 전체 데이터를 놓고 보면 잘 드 러나지 않는 특성들이 쪼개진 상태에서는 명확하게 드러나는 경우가 많은 데, 이처럼 로 데이터를 분석 과정에서 어떤 식으로 가공하느냐에 따라 데이터에서 얻는 인사이트가 완전히 달라질 수 있다. 데이터를 쪼개서 보는 것과 관련해서 통계학에서 '심슨 패러독스'라고 부르는 재미있는 개념이 있다. 심슨 패러독스란 쪼개진 데이터에서 성립하는 관계가 합쳐진 데이터에서는 반대로 나타나는 현상을 말한다. 
- OMTM과 전혀 다른 맥락에서 사용되긴 하지만 비즈니스에서 강조하는 지표로 널리 알려진 KPI(Key Performance Index)라는 지표가 있다. OMTM과 KPI는 어떤 차이가 있을까? OMTM과 KPI의 가장 큰 차이는 각 지표를 정의하고 활용하는 목적이 다 르다는 점이다. OMTM은 성장을 목표로 하는 지표다. OMTM에 해당하 는 지표를 개선하는 것도 물론 중요하지만 사실 더 중요한 것은 OMTM을 바탕으로 어떤 의사결정을 하고 이에 따라 전사적인 리소스를 어떻게 배 분할 것인가를 결정하는 것이다. OMTM은 결과뿐 아니라 그 결과를 달성 하는 과정도 큰 의미를 갖는다. 반면 KPI는 일반적으로 평가를 위해 활용 하는 지표다. 이 때문에 KPI는 달성 여부 자체가 굉장히 중요하다. 성장을 위한 수단으로 활용하는 OMTM과 달리 KPI는 그 자체가 목표에 가까운 지표라고 할 수 있다. OMTM은 모두가 공유하는 하나의 목표인 데 반해 KPI는 팀이나 부서 별로 서로 다르게 설정된다는 점도 큰 차이점이다. 이러한 특성 때문에 OMTM은 공통의 목적을 달성하기 위한 부서 간 협력을 유도하지만 KPI 는 자칫하면 부서 간 경쟁을 유도할 수 있다. KPI를 기반으로 업무를 진행 하는 조직에서는 팀별 KPI가 서로 연관이 없는 경우가 많다. 더 나쁜 경우에는 서로 다른 팀의 KPI가 충돌하기도 한다. 한 팀의 KPI를 달성하려고하다 보면 다른 팀의 KPI에 부정적인 영향을 주기도 한다. 가령 개발팀의 KPI는 출시일을 최대한 앞당기는 것이고 QA팀의 KPI는 출시 시점의 버 그를 최소화하는 것이라면, 빠른 출시 일정을 잡는 것이 개발팀의 KPI 달 성에는 도움이 되지만 QA팀의 KPI 달성에는 부담으로 작용할 것이다. KPI는 성과 측정을 위한 지표이기 때문에 일단 한번 정해지면 평가할 때 까지는 거의 바뀌지 않는다. 특히 구성원들이 실적이나 평가에 민감한 경 우 KPI가 잘못 설정됐다는 사실을 알면서도 타 부서와의 공정성 문제 등 을 고려해서 수정하지 못하는 경우가 많다. 하지만 OMTM은 성장을 위 한 목표이므로 주변 환경이나 서비스 성장 속도에 따라 시기마다 변경될 수 있다는 것을 당연하다고 생각한다. 서비스 확산에 초점을 맞추는 시기에는 친구 초대 등 유입 채널과 관련된 목표를 OMTM으로 정하지만 일정 기간 후 수익화에 초점을 맞추는 시기에는 결제전환율 등 매출과 관련된 목표 지표를 OMTM으로 새롭게 정의하는 식이다. 변화에 따른 유연한 대응이 가능한 지표라고 할 수 있다.
- OKR은 구글이 도입한 목표 관리 체계로 널리 알려져 있다. OKR은 3~5 개의 목표(Objectives)와 목표당 3~5개 정도의 핵심 결과(Key Results) 로 구성된다.
목표(Objectives)
* 매우 도전적인 목표
* 주로 정성적인 언어로 표현되며, 구성원들의 가슴을 뛰게 할 수 있는 크고 담대한 목표를 설정해야 한다.
핵심 결과(Key Results)
* 목표를 달성하기 위한 구체적인 결과 지표
* 객관적으로 측정하고 모니터링할 수 있는 지표
하나의 목표에 연계된 핵심 결과는 3개 이하를 권장한다.
- OKR에 대한 소개를 읽으면서 느꼈겠지만 OKR과 OMTM은 비슷한 점이 많다. 우선순위를 명확하게 정하고 중요한 목표에 전사적인 자원을 집중 한다는 철학적인 배경이 유사하기 때문이다. 굳이 구분하자면 OMTM은 중요한 지표 그 자체를 강조하는 것에 조금 더 초점이 맞춰진 반면, OKR 은 그 지표를 개선하기 위한 구체적인 액션 플랜에 가깝다는 차이 정도일 것이다. OMTM과 OKR 모두 목표를 정하는 과정에서 측정 가능하고 도전 적인 소수의 목표에 집중할 것을 권장하며, 구성원들이 모두 같은 그림을 그리는 것의 중요성을 강조한다. 또한 목표를 달성해 나가는 과정 자체에 서도 경쟁이 아닌 협력의 필요성을 이야기하고 있고 구성원 개개인의 자 율성과 투명한 공유 환경을 중요하게 여긴다는 점도 굉장히 비슷하다.
- 클라우드 분석 환경 : 데이터를 잘 쌓고 활용하는 과정에서 만나는 가장 큰 난관은 데이터를 수집하고, 이를 분석할 수 있는 기본적인 환경을 구축하는 일이다. 하둡 (Hadoop), 스파크(Spark) 등 널리 알려진 분산처리 시스템이 있지만 막 상 분석 환경을 직접 구축하다 보면 여러 대의 서버와 오픈소스 스택을 관 리하는 과정에서 갖가지 난관과 장애를 만나게 된다. (무엇보다 일단 엔지 니어가 없으면 시작할 수가 없다!) 하지만 최근에는 클라우드 분석 환경이 눈부시게 발전하면서 인프라 구축을 위한 엔지니어링이 크게 간소화됐다. 아마존의 EMR(Elastic MapReduce), 구글의 GCP(Google Cloud Platform), 마이크로소프트의 Azure 등이 대표적인 클라우드 플랫폼으로 알려져 있다. 실제로 이러한 클라우드 분석 환경을 잘 이용하면 데이터 수집과 저장, 전처리에 이르는 많은 프로세스를 간단한 몇 가지 설정만으로 쉽게 구현할 수 있다. 아마존 의 레드시프트(Redshift), 구글 빅쿼리(BigQuery) 등 클라우드 데이터베 이스의 성능도 훌륭한 편이다. 그뿐만 아니라 최근에는 머신러닝과 관련 된 모델 생성과 서빙에 이르기까지 지원 범위가 점점 넓어지고 있다.
- ETL 자동화 서비스 : 데이터 분석을 하기 위해서는 ETL(Extract, Transform, Load)이라는 프로세스가 선행돼야 한다. ETL은 여기저기에 산재돼 있는 데이터를 수집하고, 분석하기 편한 형태로 변환하고, 원하는 데이터베이스에 최종적으 로 적재하는 일련의 과정을 의미한다. 실제로 데이터 분석을 위해 원천 데이터를 그대로 사용하는 경우는 많지 않다. 서비스를 운영하면서 발생하는 데이터와 분석을 위해 필요한 데이터는 그 형태나 요건이 다르기 때문 이다. 과거에는 이러한 데이터 전처리 과정을 위해 많은 데이터 엔지니어가 필요했고 경우에 따라서는 별도의 인프라 담당 개발자를 두는 경우도 흔했다. 하지만 최근에는 간단한 설정을 통해 ETL을 자동화하는 서비스가 다수 등장하고 있다. Fivetran, Stitch 등의 ETL 자동화 서비스는 수십 가 지의 광고플랫폼, 어트리뷰션, CRM, 기타 데이터 분석 서비스와의 연동 을 통해 필요한 형태로 데이터를 적재하고 전처리하는 과정을 굉장히 쉽고 편리하게 구축해 준다.
- BI(Business Intelligence) 서비스 : 클라우드 분석 환경과 분석용 데이터베이스가 잘 갖춰졌다고 하더라도 실 무자들이 당장 데이터를 쉽게 활용할 수 있는 것은 아니다. 기본적으로 아마존 EMR이나 구글 GCP의 주 사용자들은 데이터 분석가와 데이터 엔지니어이고, 클라우드 데이터베이스를 활용하려면 분석 언어에 대한 지식이 필요하기 때문이다. 원하는 데이터를 추출하는 것'과 '데이터에서 인사이 트를 찾아내고 이를 바탕으로 의사결정하는 것' 사이에는 여전히 큰 간극 이 존재한다. 데이터 분석가나 개발자뿐 아니라 다양한 직군의 실무자들의 데이터에 손쉽게 접근하고, 이를 통해 인사이트를 얻을 수 있는 환경을 만들려면 적절 한 시각화를 통해 지표를 한눈에 볼 수 있도록 대시보드를 만들고, 필요 한 경우 로 데이터를 쉽게 확인할 수 있는 시스템을 구축해야 한다. 과거 에는 이러한 대시보드 개발을 위해 디자이너, 프런트엔드 개발자, 백엔드 개발자가 모두 필요했고, 대시보드를 수정하거나 업데이트하는 데도 많은
- 시간과 노력이 필요했다. 하지만 최근에는 태블로(Tableau)나 구글 데이 터 스튜디오(Google Data Studio) 등의 데이터 시각화 및 대시보드 구축 서비스가 빠르게 발전하고 있고, 수퍼셋(Superset)이나 리대시(Redash) 등 오픈소스를 기반으로 한 BI(Business Intelligence) 서비스도 속속 등 장하고 있다. 이러한 BI 서비스는 기본적으로는 SQL(Structured Query Language) 쿼리 기반으로 동작하는 경우가 많지만 최근에는 드래그 앤드 드롭 등의 더욱 편리한 UX를 지원하는 사례도 늘어나고 있다. 실제로 많은 회사들에서는 데이터 분석가나 데이터 엔지니어가 아니더라 도 간단한 SQL 구분을 활용할 수 있으면 BI 툴을 통해 필요한 데이터를 스스로 찾아볼 수 있는 형태로 빠르게 업무 환경이 변화하고 있다.
- 구글 애널리틱스 등의 상용 서비스 대신 이벤트 로그를 자체적으로 관리 하는 데이터베이스에 쌓는 방법도 있다. 아마존 레드시프트나 구글 빅쿼 리 등의 클라우드 데이터베이스는 많은 데이터를 적재하고 처리하는 데 최적화돼 있어서 이벤트 로그를 쌓는 용도로 사용하기에 적합하다. 데이터 엔지니어와 데이터 분석가의 지원이 가능한 환경이라면 데이터 적재와 분석의 자유도가 높다는 점에서 추천할 만한 방법이다.