서브 쿼리Subquery란 메인 쿼리Main query를 실행하는 데 필요한 데이터를 추가로 조회하기 위해 사용되는 부가적인 SELECT문을 말한다. 어떤 메인 쿼리에 포함되어 있다는 의미에서 내부 쿼리Inner query라고 부르기도 한다. 이때, 메인 쿼리는 외부 쿼리Outer query로 지칭될 수 있다. 

서브 쿼리의 형태 / 실행 조건

SELECT 열
FROM 테이블
WHERE 조건식 ( SELECT 열
                             FROM 테이블
                             WHERE 조건식 )

(1) 반드시 괄호에 감싸진 형태로 쓰인다.

(2) SELECT문의 형태로만 작성이 가능하다.

(3) 쿼리의 끝에서 ;세미 콜론을 사용할 수 없다.

(4) ORDER BY절을 삽입할 수 없다.

서브 쿼리의 특징

(1) 비교 혹은 조회의 대상이 될 때 조회 대상의 오른쪽에 놓인다.

(2) 메인 쿼리와의 비교를 위해 존재하는 쿼리이기 때문에 서브 쿼리의 SELECT 절은 메인 쿼리의 비교 대상과 같은 자료형과 같은 개수로 지정돼야 한다.

(3) 결과값 역시 메인 쿼리의 연산자 종류와 동일해야 한다.

(4) 메인 쿼리와의 관계는 단방향이다. 이는 Java 객체지향의 상속과도 유사한 형태인데, 상속당한 자식 객체는 부모 객체의 인스턴스를 사용할 수 있지만 부모는 자식 객체의 인스턴스를 사용할 수 없는 특징이 있다.

(5) 구조화를 통해 쿼리의 각 부분을 가독성 있고 명확하게 볼 수 있게 해 준다.

(6) 위의 특징 때문에, 복잡한 JOIN과 UNION을 명료하게 정리할 수 있는 대체재로 기능할 수 있다. 

서브 쿼리의 사용처

(1) SELECT 절에서 사용 / 스칼라 서브 쿼리Scalar Subquery

(2) FROM 절에서 사용 / 인라인 뷰Inline View

(3) WHERE 절에서 사용 / 중첩 서브 쿼리Nested Subquery

(4) HAVING 절에서 사용

(5) ORDER BY 절에서 사용

(6) INSERT문의 VALUES 값 대체재로써 사용

(7) UPDATE문의 SET 값 대체재로써 사용

서브쿼리의 사용

이번 포스트에서는 서브 쿼리의 사용처 중 SELECT, FROM, WHERE절에서 쓰이는 경우, 즉 스칼라 서브 쿼리, 인라인 뷰, 중첩 서브 쿼리에 대해 알아본다.

SELECT절, 스칼라 서브 쿼리Scalar Subquery

ㅡ스칼라 서브쿼리(Scalar Subquery)
  정대리 급여와 테이블 전체 평균 급여를 구하시오.

SELECT name
	, salary
   	, (SELECT ROUND(AVG(salary), -1) FROM employee) AS 평균급여
FROM employee
WHERE name = '정대리';

스칼라 서브 쿼리는 SELECT절에서 나타나는 서브 쿼리다. 다른 테이블에서 어떠한 값을 불러올 때 주로 쓰이며, '스칼라'라는 이름에서 보여지듯 단일 값만을 가져올 수 있다. 해당 서브 쿼리는 일치하는 값이 없다면 NULL을 리턴한다(해당 부분은 그룹 함수의 특징이기도 하다.).

FROM절, 인라인 뷰Inline View

ㅡ인라인 뷰(Inline View)
  직급이 사원인 사람들의 이름과 급여를 구하시오.

SELECT ex1.name
	, ex1.salary
FROM (SELECT * FROM employee li
WHERE li.office_worker= '사원') ex1;

인라인 뷰는 FROM 절에서 나타나는 서브 쿼리다. 특정 테이블에서 전체 데이터가 아니라 일부 데이터만 추출해 연결하고자 할 때 쓴다. 타 서브 쿼리와 달리 꼭 별칭alias을 지정해 줘야지만 사용이 가능하다. 참고로, WITH 문을 사용해도 결과물은 동일하기 때문에 손에 맞는 것을 취사선택해 쓰면 된다.

WITH
[별칭1] AS (SELECT문 1),
[별칭2] AS (SELECT문 2),
...,
[별칭N] AS (SELECT문 N)
SELECT 
FROM 별칭1, 별칭2, ..., 별칭N

WHERE절, 중첩 서브 쿼리Nested Subquery

ㅡNested Subquery - 단일 행 
  정대리라는 사람의 직급을 구하시오.

SELECT office_worker
FROM employee
WHERE office_worker = (SELECT office_worker FROM employee WHERE name = '정대리')

ㅡNested Subquery - 복수(다중) 행 
  정대리보다 급여가 높은 사람들을 구하시오.

SELECT *
FROM employee
WHERE salary > (SELECT salary FROM employee WHERE name = '정대리')

  직급이 사원인 사람들을 구하시오.

SELECT *
FROM employee
WHERE office_worker IN (SELECT office_worker FROM employee WHERE office_worker = '사원')

WHERE절에서 나타나는 서브 쿼리는 중첩 서브 쿼리라 부른다. 실행 결과의 행 수, 열 수에 따라 단일 행 서브 쿼리, 다중 행 서브 쿼리, 다중 열 서브 쿼리로 나누며 이번 포스트에서는 실무에서 주로 사용되는 단일 행/ 다중 행 서브 쿼리만 다룬다. 

단일 행 서브 쿼리는 >, >=, =, <=, <, <>, ^=, != 등의 연산자와 함께 쓰이며, 다중 행 서브 쿼리는 IN, ANY, SOME, ALL, EXISTS 등의 연산자와 함께 쓰인다. 출력하는 행 수와 연결지어서, 전자를 단일 행 연산자, 후자를 다중 행 연산자라 부르기도 한다. 

IN : 하나라도 일치한 데이터가 있다면 TRUE
ANY, SOME : 만족하는 결과가 하나 이상이면 TRUE
ALL : 결과가 모두 만족하면 TRUE
EXISTS : 결과가 존재하면 TRUE (행이 1개 이상이면 TRUE)

 <IN> 부서별 최고 급여와 동일한 급여를 받는 사원 정보

SELECT *
FROM emp
WHERE sal IN (SELECT MAX(sal) FROM emp GROUP BY deptno);

 <SOME> 등가 비교 연산자(=)와 ANY, SOME을 함께 사용하면 IN 연산자와 같은 기능 수행

SELECT *
FROM emp
WHERE sal = SOME (SELECT MAX(sal) FROM emp GROUP BY deptno);

 <ANY> 등가 비교 연산자가 아닌 대소 비교 연산자와 ANY를 함께 사용하면?
 < ANY : 부서 30 중 최대값보다 적은 급여를 가진 사원을 찾게 됨
 > ANY : 부서 30 중 최소값보다 높은 급여를 가진 사원을 찾게 됨

SELECT *
FROM emp
WHERE sal < ANY (SELECT sal FROM emp WHERE deptno = 30);

 <ALL> 부서 30 중 최대 급여보다 더 많은 급여를 받는 사원 출력

SELECT *
FROM emp
WHERE sal > ALL (SELECT sal FROM emp WHERE deptno = 30);

 <EXISTS> 부서50이 있으면 EMP 전체 출력

SELECT *
FROM emp
WHERE EXISTS (SELECT dname FROM dept WHERE deptno = 50);

출처

양디로그 블로그

Inpa Dev 블로그

java의 개발일기 블로그

이번 년은 내 생의 이전 해를 전부 합친 만큼 요리를 자주 했다. 물론 밀키트로. 이 글은 내가 약 세 달동안 육십여 개의 밀키트를 먹고 구매해 본 경험을 바탕으로 밀키트 얘길 하는 글이다.

밀키트는 꽤 흥미로운 구성을 갖고 있다. 일단 완제품이 아니라 어떤 요리를 구성할 수 있는 재료를 소분해 포장하고 레시피를 동봉한 형태로 판다. 즉 '요리해야 한다'. 노동력과 시간을 필요로 하고 요리를 조리할 수 있는 장소도 필요하다. 요리를 하고 나면 설거지도 해야 한다. 거기다 더 주목할 점은 요리를 할 재료는 전부 들어 있긴 하지만 재료가 요리의 완전한 성공을 담보해 주진 않는다는 점이다. 물 양, 불 세기, 재료의 손질 형태 등 아주 미묘하고 오랜 기간의 시행착오로만 손에 익혀야 하는 몇몇 암묵지가 없다면 요리는 온전한 성공을 거두기 어렵다. 

신기한 것은 그럼에도 밀키트의 시장가는 동일 용량의 원물보다는 훨씬 비싸게, 시장에 가서 사거나 배달로 주문할 수 있는 완제품과 비슷하게 유지되고 심지어 시장의 투 톱인 쿠팡프레시와 마켓컬리의 매출을 견인할 정도의 수요를 가지고 있다는 점이다. (어떤 일부 제품은) 배달해서 먹는 완제품보다는 싸다, 할 수도 있겠지만 이런 밀키트의 폭발적인 수요를 설명할 수는 없다. 쿠팡프레시를 조금만 둘러보면 같은 브랜드의 요리를 원물 그대로 냉동한 것보다 동일한 요리를 밀키트화 한 것이 판매량이 더 잘 나온다는 점을 몇 분 안 돼 파악할 수 있다. 밀키트가 완성된 요리 이상의 편익을 고객에게 제공한다는 것은 분명해 보인다. 그럼 냉동 요리, 배달 음식점과 밀키트의 다른 점은 뭘까. 

나는 프레시지, 곰곰, 마이셰프, 애슐리 등의 온갖 밀키트를 조리해 보며 내가 얻는 편익의 플러스 알파에 대해 추측해 봤다. 그 내용은 아래와 같다.

(1) 재료의 신선함:

밀키트는 재료나 소스가 원물 상태로 오고 그것들의 유통기한이나 선도, 재료의 원산지 등을 바로 체크할 수 있고 원물의 맛을 200% 살릴 수 있는 요리를 할 수 있다. 완제품의 경우는 이리 조리되어 소스에 절어 있기 때문에 상대적으로 이를 파악하기 힘들다.

(2) 요리를 개인화할 수 있음:

나는 짜게 먹는 편이지만, A는 싱겁게 먹는다. 배달 음식이나 냉동 음식의 경우 음식이 짜게 오는 경우가 많아서 얘가 잘 못 먹는 경향이 컸다. 밀키트는 이렇게 개인 취향에 맞춰 염도를 조절할 수 있을 뿐 아니라 식재료를 가감해서 요리를 먹는 사람에게 최적화된 형태로 맞출 수 있다.

(3) 요리에 대한 진입장벽 최소화/ 경험 구매:

밀키트는 '성공하는 레시피'와 '소분화된 재료'를 제공함으로써 요리에 대한 진입장벽을 낮추고 사용자가 쉽게 요리에 접근하게 도와 준다. 요즘은 요리 레시피를 공개하는 여러 채널이 많지만, 그걸 찾는 것도 사실 일이다. 밀키트를 통하면 검증된 레시피와 요리할 수 있는 재료가 한 번에 온다. 요리라는 취미를 적당히 경험해 보고 싶은 나 같은 사람에겐 밀키트가 종합선물세트다.

이 글을 쓰게 된 원인이 있다. 어제 소곱창이 너무 먹고 싶어서 로켓프레시를 둘러 보다가 아무 생각 없이 소곱창을 샀다. 밀키트 말고 원물만 냉동된 것. 그냥 이거랑 부추랑 사서 구워 먹으면 되겠거니 생각했는데 막상 요리하려고 보니 아니었다.

부추는 무쳐야 하고 간장도 만들어야 했다. 그런데 부추를 무치려면 고춧가루가 필요했고 간장을 만드려면 거기에 더해 다진 마늘, 까나리액젓, 빙초산이, 구울 땐 다시다가 필요했다. 그렇다. 요리를 할 때 들어가는 부차적인 재료는 한두 개가 아니다. 그리고 일단 그 모든 것들을 하나의 요리를 위해 사기엔 너무 대용량이고 지출이 컸다. 그래도 뭔가 만들어 보려고 급하게 편의점에 갔는데 나머지는 다 없었고 다시다 100g을 4,300원에 사서 털레털레 집에 왔다. 밀키트가 그리웠다.

아는가. 요리는 꽤 돈이 들어가는 취미란 것을. (나는 뒤늦게 알았다.) 요리에는 기본적으로 일정 수준의 투자가 요구된다. 위에서 언급한 식재료 외에도 갖춰줘야 할 것이 많은 비싼 취미다. 하지만 밀키트는 이 모든 것 없이 요리의 좋은 부분만 경험할 수 있게 해 준다. 그런 부분에서 어쩌면 밀키트의 아하 모멘트는 완성된 요리를 먹는 부분이 아니라 요리하는 그 순간에 있는지도 모르겠다. 여튼간에, 나는 내일도 밀키트로 두 끼를 해결할 예정이다. 밀키트 사랑해, 덧붙이며 글을 마친다.

<

AARRR 퍼널 분석 시리즈 몰아보기

AARRR (1): Acquisition 획득

AARRR (2): Activation 활성화

AARRR (3): Revenue 수익화

AARRR (4): Retention 리텐션

AARRR (5): Referral 추천

>

이번 포스트에서는 퍼널 분석 중 가장 보편적으로 사용되는 AARRR의 Activation활성화 단계에 대해 다룬다. Activation 단계는 유저가 유입 또는 회원가입 이후, 서비스의 핵심 단계를 발견하는 단계, 로 정의할 수 있다. 서비스의 매력을 발견하는 단계여서 Aha moment 단계라고도 불린다. <이 포스트의 내용 대다수는 패스트캠퍼스의 세계 3등에게 배우는 13개 데이터 분석 프로젝트 강의 기반으로 작성됐다.>

Activation 퍼널을 분석하면 고객이 얼마나 활발하게 우리 서비스를 이용하는지, 또 고객들이 우리 서비스의 어떤 기능을 이해해야 구매 유저로 전환될 수 있는지 확인할 수 있다. 예를 하나 들어 보겠다. 상품 찜하기는 일반적으로 구매와 상관도가 높은 고객 행동이다. 유저 행동 데이터를 분석해 보니 해당 행동을 한 유저의 구매 전환과 리텐션은 하지 않은 유저 대비 20% 이상 차이가 나는 것이 밝혀졌다면, 우리는 상품 찜하기를 우리 서비스의 Aha moment로 삼아 찜하기를 유도하는 이벤트와 제품을 기획해볼 수 있을 것이다.

Activation의 주요 지표는 아래와 같다.

   1) 집계 기준: 가입 수, 체류시간Duration time, 페이지뷰 빈도Page view Frequency

   2) 비용 기준: CPACost Per Action

   3) 전환 기준: DAU/MAUStickiness, CVRConversion Rate

'집계 기준'에서는 일반적인 기준인 가입 수로 잡았지만, Activation은 상위 첨부 이미지, <글로벌 기업들의 아하 모멘트>에서 보이듯이 조금 더 구체적인 기준으로 집계하는 게 좋다. 단순 가입 수가 아니라 유저가 프로덕트에서 가치를 얻는 순간(이벤트)을 기준으로 집계하는 것이다. 유저가 프로덕트에서 가치를 얻는 명확한 행동 기준으로 Activation을 집계해야지만 리텐션, 결제, 추천 등 비즈니스의 주요 목표를 개선할 수 있는 퍼널을 구축할 수 있다.

이를 위한 접근법은 두 가지다.

   (1) 퍼널 최적화: 핵심 가치를 더 많은 유저들이 더 빨리 경험할 수 있는 방법 찾기

   (2) 지표/ 고객 세분화: 우리 서비스의 핵심 가치 찾기

 아래부터는 이 두 가지 접근법에 근거해서 Activation 퍼널을 최적화하는 방법을 살펴본다

(1) 퍼널 최적화: 핵심 가치를 더 많은 유저들이 더 빨리 경험할 수 있는 방법 찾기

퍼널 간 전환율 늘리기

Activation 퍼널을 최적화하기 위해 우리는 핵심 가치를 더 많은 유저들이 더 빨리 경험할 수 있는 방법에 대해 고민해야 한다. 서비스에서 알려주고 싶은 기능은 너무나 많다. 우리가 '가장 중요한 하나의 기능에 초점을 두지 않으면' 유저는 우리 서비스의 목적을 이해하지 못 하고 지쳐서 이탈한다. 우리는 우리가 말하고 싶은 핵심 기능까지 유저가 자연스럽게 도달할 수 있는 경로를 의도적으로 설계해야 한다. 

도메인의 평균적인 전환율과 대비해 나쁜 방향으로 편차가 있는 유저 동선을 개선하자. 위 표를 보면 이 서비스에서는 상세페이지에서 찜하기에 이어지는 전환율이 타 단계에 비해 크게 낮다. 서비스의 문제일 수도 있지만 버튼이 작다거나 다른 오브젝트에 묻혀 잘 안 보인다거나 하는 UI 문제일 가능성도 있다. 

퍼널 자체를 줄이기

유저가 핵심 기능을 '더 많이' 그리고 '더 빠르게' 경험하게 만드는 방향이 전환율을 높이는 데에만 있는 것은 아니다. 퍼널을 아예 줄여 버려도 된다. 요새 브랜드 웹사이트에 자주 도입되는 소셜 로그인이나 커머스 사이트의 바로구매 기능은 퍼널을 효과적으로 축소한 사례다. 각 단계 간에 얼마나 전환율을 끌어올리든간에, 단계가 존재하는 이상 이탈은 발생한다. 반대로 고객이 기능이나 서비스를 충분히 인지하게 만든 상황에서 가능한 퍼널을 줄이면 전환율은 개선될 것이다.

(2) 지표/ 고객 세분화: 우리 서비스의 핵심 가치 찾기

Stickiness유저 고착도 활용하기

(기간 평균) DAU일 활성 이용자를 MAU월 활성 이용자로 나눈 지표인 Stickiness를 관리하는 것도 Activation 퍼널을 최적화하는 하나의 방법일 수 있다. Stickiness는 유저 고착도 내지는 잔존율로 번역되는 용어로, '서비스를 유저들이 얼마나 자주 사용하는가'를 정의할 수 있는 지표다.

DAU와 MAU의 차이를 놓고 보면 조금 더 이해가 쉽다. DAU는 하루동안 우리 서비스의 핵심 기능을 이용한 유니크 유저 수를 집계하는 지표고, MAU는 한 달동안 우리 서비스의 핵심 기능을 이용한 유니크 유저 수를 집계하는 지표다. 어떤 유저가 열흘 동안 하루 한 번씩 우리 서비스에 접속한다면 DAU는 열 번이 잡히지만 MAU는 단 한 번 잡힌다. 즉, 우리 서비스를 기간 동안 자주 이용하는 유저가 많을 수록 (기간 평균) DAU와 MAU 값의 차이는 적을 거고 그럴 수록 Stickiness 값은 1에 가까워진다. 우리 서비스의 Stickiness 값이 높다면, 우리 유저들의 리텐션, 혹은 핵심 기능 사용 빈도가 높다고 볼 수 있는 것이다.

다만 서비스의 사용 주기에 따라 Stickiness는 유효하지 않은 측정기준이 될 수 있다. 카카오톡, 메타, 유튜브 같은 sns 서비스의 경우 매일 서비스를 방문해 사용하는 비중이 크지만 알라딘, 29cm 같은 커머스나 토스 같은 금융 서비스는 그렇지 않다. 이런 서비스의 경우 DAU와 MAU의 비율로 측정하는 Stickiness가 비교적 낮게 측정될 수밖에 없고 지표의 중요도가 전자에 비해 떨어질 수밖에 없다.

Aha moment 찾기: XaY 공식

글의 초반부에서도 언급했지만, Activation 단계는 유저에게 서비스의 매력을 발견하게 만드는 단계이기도 하다. Activation 단계의 성공은 '우리 서비스가 얼마나 많은 유저에게 얼마나 빠르게 핵심 기능을 제공했는가'로 요약될 수 있다. 그러면 이 퍼널의 성공은 다음과 같은 XaY 공식으로 집계된 유저의 비율을 세는 것으로도 표현될 수 있을 것이다.

정해진 기간(Y) 동안 서비스의 핵심 행동(a)을 일정 횟수(X) 이상 하는 유저

a: 핵심 행동 / X: 유저의 행동 빈도 / Y: 기간

줌과 메타의 Aha moment도 이런 공식을 따른다. 줌의 경우는 28일(Y) 동안 4회 이상(X) 미팅(a)을 잡은 유저를, 메타는 10일(Y) 동안 7회 이상(X) 친구 추가(a)한 유저를 각각 활성 유저로 정의하고 있다.

선형대수학은 말 그대로 '선형' '대수'에 관한 학문이다. 이때의 대수는 x나 y 등의 변수를 뜻하고 선형은 직선을 뜻한다. 직선을 떠올려 보자. 이것은 점과 점 사이를 이은 것이다. 연속적인 값의 모음. 그래서 직선은 단일 값이 아니라 여러 값을 가지는 행렬matrix 형태다. 선형대수학은 쉽게 말하자면 다차원과 다차원 사이의 연산에 관한 학문인 셈이다. 우리가 머신러닝에서 다루게 될 자료는 이미지나 음성 등의 다차원 형태기 때문에 머신러닝에 대한 이해를 위해 필연적으로 학습할 내용이기도 하다. 아래로는 선형대수학에 관해 정리된 포스트들을 개인 학습 차 정리한 내용이다. 

머신러닝을 위한 선형대수학(1):  사전 지식 익히기

머신러닝을 위한 선형대수학(2):  벡터와 벡터 연산

머신러닝을 위한 선형대수학(3): 행렬과 행렬 연산

인공지능을 위한 선형대수(1)

인공지능을 위한 선형대수(2)

선형대수학(1): 주요용어 및 기본공식

선형대수학(2): 역행렬과 행렬식(determinant)

선형대수학(3): 고유값과 고유벡터 (eigenvalue & eigenvector)

선형대수학(4): 특이값 분해(Singular Value Decomposition, SVD)의 활용

선형대수학(5): 선형연립방정식 풀이

선형대수학(6): 주성분분석(PCA)의 이해와 활용

매거진이란 종의 특수성을 좋아한다. 정확히는 여럿이 모여 그들이 모은 진주들을 품평하고 체에 거르고 닦아서 내놓은, 반짝이는 것들의 아주 밀도 높은 어떤 시절의 집약체라는 일면을 좋아한다. 개중에서도 당장 나온 따끈따끈한 것 말고, 적어도 이삼 년, 길면 십여 년쯤 전에 나온 낡고 먼지 쌓인 호수를 좋아한다. 시각과 후각을 동시에 자극하는 그것들을 읽어 내려가면서 나는 다시 돌아갈 수 없는 시절의 나이테를 더듬으며 내 밑바닥의 지문과 맞춰 보고 즐거워한다. 어쩌면 시대에 뒤처진 취미다.

컨셉진 오십오 호의 소재는 '애장품'이다. 생각해 보면 시간이 표면에 남긴 흔적이 늘어날 수록, 본인의 물성보다는 장소의 물성을, 생산될 당시의 효용보다는 과거 어디쯤의 기억을 대표하게 될 때 더 깊은 가치를 갖는 애장품의 향유 방식은 내가 매거진을 감각하는 방식과 닮아 있다. 그런 문맥 탓인지 아니면 그냥 이번 호 자체가 취향이었던 건지 모르겠지만 이번 호는 조금 더 감정 섞여 읽혔네.

가장 좋았던 페이지는 '빵지순례'다. 첫단부터 끝단까지 몇 페이지에 걸쳐 이 빵집의 식빵 맛과 저 빵집의 식빵 맛을 비교하는 데 일관된 지면을 할당하고 있는 글인데, 각 빵집을 소개하는 앞단에는 무슨 증명사진처럼 잘린 식빵의 단면이 들어가 있다. 식빵이 다 식빵이지 않나 싶었는데 막상 맨얼굴을 마주하고 보니 비슷한 부분을 찾기가 더 어려워 낯설게 보였다. 개념을 해체하고 재조립하는, 하지만 오만한 데가 없이 쉽게 읽히는, 잘 쓴 글이었다.

마음 편하게 읽을 수 있는 실무 서적이다. 프레임워크를 서비스 적용 관점에서 쉽게 풀어 썼고 어쩌면 난해할 데이터 분석 용어 관련해서도 자세하다. '안 물어 봐서 안 알려 주는' 암묵지, 솔루션 툴이나 실무 팁도 참고가 많이 됐다. 다만 전반적으로 비슷한 주제를 다루고 있어선지 내게는 린 분석의 순한맛 버전 같다 느껴졌다. (린 분석을 이미 읽은 입장에서는) 기대하던 내용보다는 이론의 깊이가 얇아서 일 할 아쉬웠지만, 여전히 입문자 또 실무자에게 좋은 책임은 확실하다. 요새 스타트업 기술 블로그에서 자주 언급되는 '데이터 드리븐', '목적 조직', '스프린트' 기반의 구조를 이해해보고 싶은 분들께 이 책을 권하고 싶다. 이 책을 한 줄로 설명해 주는 문장을 덧붙이며 글을 마친다. "그로스 해킹은 존재하지만 그로스 해커는 없다." (p.208)

<

AARRR 퍼널 분석 시리즈 몰아보기

AARRR (1): Acquisition 획득

AARRR (2): Activation 활성화

AARRR (3): Revenue 수익화

AARRR (4): Retention 리텐션

AARRR (5): Referral 추천

>

이번 포스트에서는 퍼널 분석 중 가장 보편적으로 사용되는 AARRR의 Acquisition획득 단계에 대해서 다룬다. Acquisition은 단어 뜻대로 고객이 유입되었을 때, 혹은 회원가입을 했을 때와 같이 유저의 서비스 인입 시점에서 측정할 수 있는 지표다. 때문에, 이 지표를 기준으로 우리는 몇 가지 비즈니스에 유의미한 질문을 얻을 수 있다. 이번 포스트에서는 수많은 질문 중 아래 두 가지 질문에 집중하고자 한다. <이 포스트는 패스트캠퍼스의 세계 3등에게 배우는 13개 데이터 분석 프로젝트 강의를 개인 공부 차 정리한 것이다.>

1) 우리 서비스의 MAU월간 활성 사용자 수는 건전하게 성장하고 있는가?

2) 우리 서비스의 LTV유저 평생 가치 / CAC유저 획득 단가 ratio는 과도하지 않게 유지되고 있는가?

1) 우리 서비스의 MAU는 건전하게 성장하고 있는가?

Acquisiton의 지표는 집계, 비용, 전환 중 어디에 초점을 맞추는지에 따라 다양하게 세분화될 수 있다.

집계 기준: DAU일별 활성 사용자 수, MAU월별 활성 사용자 수, 방문 수, 가입 수, 설치 수

비용 기준: CPC유입 단가, CAC회원가입, CPI앱 설치

전환 기준: CTR노출 대비 클릭율, CVR회원가입/ 설치 전환율

이 중 MAU는 '월간 활성 사용자 수'로 우리 서비스를 사용하는 유니크 유저의 수를 측정함으로써 서비스의 성장을 가늠해볼 수 있는 지표다. 일반적으로 MAU가 증가하면 서비스 자체가 성장하고 있다고 추측할 순 있지만, 이런 뭉텅이 지표만으로 우리 MAU가 왜 성장한 건지를 알기는 어렵다. "월 평균 MAU가 22.5% 가량 성장하고 있으니 다음 달에도 이 정도 오를 걸로 기대돼." 할 수는 있지만 "우리 MAU가 지금 이 부분에서 성장하고 있어서 다음 달엔 이정도 성장이 기대돼." 할 수는 없다는 소리다. 이때 MAU를 세부적으로 나눠 보면 우리의 목적을 달성할 수 있다. 

MAU를 조금 더 쪼개 보자면 이번 달의 신규 유저와 지난 달부터 유지되는 사용자+ 지난달 이전 기간에 비활성되어 있다가 부활한 유저의 합으로 볼 수 있다.

이번 달 MAU

-> MAU(25.4) = new(25.4) + retained(25.4) + resurrected(25.4)

-> MAU(t) = new(t) + retained(t) + resurrected(t)

이렇게 보면 MAU를 이루는 구성 요소가 다 나왔다. 신규 유저와 부활 유저는 MAU에 긍정 기여를 하고, 이탈 유저는 부정 기여를 한다. 이 셋이 합쳐져 MAU를 이룬다. 이 지표를 뜯어 보면 우리 서비스가 왜 성장했는지(신규 유저가 늘었는지, 부활(복귀) 유저가 늘었는지, 혹은 이탈 유저가 줄었는지)도 알 수 있을 것이다. 이를 식으로 정리해 보면 다음과 같다.

MAU(t) - MAU(t-1) = new(t) + resurrect(t) - churned(t)

해당 식의 값이 0보다 크면 MAU가 전 달 대비 성장한 것이고 0보다 작다면 감소한 것이다. 즉 MAU 성장을 위해서는 신규 유저와 부활 유저의 합이 이탈 유저의 합보다 커야 하고 아래와 같이 이 식을 성장 지표로 치환할 수도 있을 것이다.

(new + resurrected) / churned > 1

2) 우리 서비스의 LTV / CAC ratio는 과도하지 않게 유지되고 있는가?

우리 서비스가 '얼마나 유저를 많이 획득했어'도 중요하지만 '얼마나 유저를 비용 효율적으로 획득했'도 우리가 초점을 맞춰야 할 요소다. 우리 서비스가 광고, 운영 등을 통해 지불하는 비용이 우리 서비스를 이용해 회수할 수 있는 매출보다 크다면 그 서비스는 장기적으로 존속하기 어려울 것이다. 이를 위해 우리가 유심히 봐야 할 지표는 CAC유저 획득 단가와 LTV유저 평생 가치다. 

CACCustomer Acquisition Cost, 유저 획득 단가

CAC는 우리가 유저를 '데려오는 데' 투여된 비용을 의미한다. 이때 획득이란 단어는 모호하다. 서비스에 따라서, '어디까지 데려오는지'(회원가입? 첫 구매?)와 비용 기준(매체비만 볼지? 제작비와 인건비까지 넣을지?), 유저 기준(전체 유저 다? 페이드 유저만?)는 달라질 수 있기 때문에 명확하게 정의하고 들어갈 필요성이 있다. 일단 정의하고 나면 아래와 같이 간단하게 CPC를 뽑을 수 있고, 이 지표를 통해 각 채널별간 효율 비교, 유입 채널을 최적화할 수 있다.

CAC = 들어간 비용 / 획득 유저 수

다만, (마케팅에 등장하는 거의 모든 지표가 그렇듯이) CAC를 비교할 때는 CAC에 대한 기준부터 확실하게 설정해야 효율적으로 의사결정할 수 있다. 예를 들어, 해당 도메인의 평균 CAC가 5,000원이라면 네이버 광고를 끄는 것만이 아니라 세 개 채널의 캠페인을 전부 점검했어야 했다. 만약 평균 CAC가 50,000원이었다고 해도 전체 광고비를 증량하는 것이 훨씬 효과적일 테고 말이다.

LTVLifetime Value, 유저 평생 가치

LTV는 반대로 우리 유저가 우리 서비스에 지불하는 가치의 총합을 의미한다. 우리가 모객한 유저는 우리 서비스를 한 번 사용하고 이탈할 수도 있지만 계속 잔존하며 꾸준히 제품을 구매할 수도 있다. LTV는 이렇게 우리 서비스를 지속적으로 사용하고 있는 유저의 가치를 측정할 때 쓰인다.

여기서 한 번 정의해 두고 들어가자면, 나는 '금액'과 '가치'를 다르게 쓰고 있다. 아래 표에서 김패캠의 예시에서 볼 때, 김패캠은 생애 동안 우리 서비스에서 50만원을 사용했기 때문에 이 사람의 LTRLifetime Revenue 금액은 50만원이 된다. 하지만 그에게 재구매를 유도하기 위해 우리는 월마다 10,000원씩, 총 50,000원의 CRM 쿠폰을 제공했기 때문에 이 사람의 LTV 가치는 45만원이다. 이 포스트에서 다루는 것은 유저의 'LTV 가치'에 대해서다.

LTV / CAC ratio

다시 정리하자면, CAC는 고객을 데리고 오는 데 든 비용이고 LTV는 데려온 고객이 우리 서비스에 지불한 가치다. 그렇다. '비용 효율적; 측면에서 Acquisition에서의 성공이란 CAC보다 LTV가 높아지는 것으로 정의해볼 수 있겠다. 아래 표를 다시 보자. 

김패캠의 LTV에서 CAC를 빼면 35만원이 된다. 반면 이데타의 LTV에서 CAC를 빼면 0원이다. 이렇게 유저들을 LTV와 CAC의 차액 혹은 비율로 세분화하게 되면 우리가 어떤 유저에게 집중해야 할 지가 명확해진다.

LTV / CAC ratio의 값이 높을 수록 서비스의 비용 구조는 '건전해진다'. 그럼 이 지표는 어디까지 올려 잡는 게 건전할까. 서비스마다 차이가 있겠지만 전문가들은 3~4 정도의 수치를 가지고 있으면 서비스가 건강하게 성장한다고 볼 수 있다고 말한다. 

내 것이었으나 이제 더는 내 것이 아닌 기억들이 있다. 소년을 연명시키는 기억이 있다. 이를 테면, 쓰레기봉투를 찢는 고양이의 자세에 각인된 몇천 년 전 사바나의 기억(간밤에 추하다는 말을 들었다, p11), 제 집도 못 찾는 눈 먼 개의 삶을 지탱하고 있을 눈 뜬 시절의 기억(어느 날, p36), 끈이 풀어진 일리야 레핀의 구두 끈(세상 속으로, p33)따위. 두려운 것 없고 등푸르던 시절의 관성으로 우리는 살아간다. 파편 같은 푸른 유리 조각을 주워 담으며 무슨 법처럼, 나쁜 소년이 서 있는 것을 본다(나쁜 소년이 서 있다, p17).

<데이터 체크>

<

문제 출처: 프로그래머스, 이름에 el이 들어가는 동물 찾기

테이블명: animal_ins동물 보호소에 들어온 동물의 정보를 담은 테이블

컬럼명: animal_id동물 아이디, animal_type동물 종, datetime보호시작일, intake_condition보호 시작 시 상태, name이름, sex_upon_intake성별 및 중성화 여부

데이터베이스 구성: 1개 테이블, 6개 컬럼, 100개 로우

>

<시나리오>

보호소에 돌아가신 할머니가 기르던 개를 찾는 사람이 찾아왔다. 이 사람이 말하길 할머니가 기르던 개는 이름에 'el'이 들어간다고. 동물 보호소에 들어온 동물 중 이름이 'el'이 들어가는 개의 리스트를 뽑으려면 어떻게 쿼리를 작성해야 할까.

<풀이> 

문제는, 개의 이름을 특정할 수 없으니 대소문자 역시 확답할 수 없다는 거다. 모든 경우의 수를 WHERE절에 넣어 주는 방향도 있겠지만, 문자열을 전부 대문자나 소문자로 바꿔 버리는 UPPER나 LOWER를 사용해도 동일한 결과물을 구현할 수 있다.

WHERE name LIKE LOWER('%EL%')

나머지는 쉽다. 조건을 채워서 쿼리를 마저 짜면 아래와 같을 것이다.

SELECT animal_id
        , name
FROM animal_ins
WHERE name LIKE LOWER('%EL%')
    AND animal_type = 'Dog'
ORDER BY name

<데이터 체크>

<

문제 출처: 프로그래머스, 자동차 평균 대여 기간 구하기

테이블명: car_rental_company_rental_history어느 자동차 대여점의 대여 기록 테이블 견본 

컬럼명: history_id대여 기록 아이디, car_id자동차 아이디, start_date대여시작일, end_date대여종료일

데이터베이스 구성: 1개 테이블, 4개 컬럼, 160개 로우

>

>

<시나리오>

여기 어떤 자동차 대여점이 있다. 이 자동차 대여점에서는 기존 고객들을 확실히 잡아두기 위해 주 고객층에 최대한의 가격 메리트를 부여하는 방향으로 가격 정책을 개편하려고 한다. 이번 EDA탐색적 데이터 분석는 이를 위한 고객 세분화 과정이다. 평균 대여 기간이 7일 이상인 자동차들의 평균 대여 기간(컬럼명: average_duration) 리스트를 출력하는 SQL문을 작성하려면 어떻게 해야 할까?

<풀이>

먼저 문제를 해소하기 위해서는 전체 리스트의 평균 대여 기간을 리스트화해야 한다. 파편화되어 있는 데이터를 그룹으로 묶어 주고,

GROUP BY car_id

이 데이터의 기준으로 평균 대여 기간을 뽑는다. 대여 기간은 대여종료일과 대여시작일의 차로 계산될 수 있는데, 이 때 대여시작일 역시 하루로 계산되기 때문에 꼭 1을 더해 줘야 한다. 이 값에 평균을 적용해 주고 가독성을 위해 소수점 첫째 자리까지 반올림하는 쿼리를 다음과 같이 짤 수 있다.

SELECT car_id
	, ROUND(AVG(DATEDIFF(end_date, start_date) + 1), 1) average_duration

이 중에서 평균 대여 기간이 7일 이상인 값을 뽑으려면 HAVING에 조건을 추가해주면 된다. WHERE가 아닌 HAVING에 넣는 이유는 그룹의 집계값(AVG) 기준으로 연산해야 하기 때문이다.

HAVING average_duration >= 7

마무리하면, 완성된 식은 아래와 같을 것이다.

SELECT car_id
        , ROUND(AVG(DATEDIFF(end_date, start_date) + 1), 1) average_duration
FROM car_rental_company_rental_history
GROUP BY car_id
HAVING average_duration >= 7
ORDER BY average_duration DESC, car_id DESC

찰스 다윈은 종의 기원에서 원시적 단계에서의 자연도태와 적자생존에 대해 다뤘다. 그 시대에서는 강한 자가 살아남는 게 아니라 살아남는 자가 강한 것이었다. 요새는 다르다. 먹을 것은 차고 넘칠 정도로 많아서 도태의 형질을 가진 사람조차 쉽사리 연명한다. 이 책은 연명하는 자들의 얘기다. 살다 보니 어쩌다가 사회의 명확한 흐름에서 도태된, 그러나 여전히 주워먹을 것은 있고 그 모든 것이 일어난 이후에도 여전히 살아 남아 있는 사람들의 이야기. 발 뒷쪽에 불쑥 튀어나온 흉터, 아랫배에 물렁하게 자리 잡은 지방을 보는 것처럼 그들을 본다. 어쩌면 그들은 우리 자신의 가장 추한 모습이다. 쉽사리 미워할 수가 없다. 

태블로에서 각 계산과 필터는 내부 지정된 쿼리 파이프라인에 따라 순차적으로 작동한다. 계산과 필터가 맞물린 형태로 진행되며 세부적인 순서는 아래와 같다.

01) 데이터 추출 필터> 02) 데이터 원본 필터> 03) 컨텍스트 필터> 04) FIXED > 05) 차원 필터> 06) INCLUDE/ EXCLUDE/ 블렌딩> 07) 측정값 필터> 08) 테이블 계산/ Clusters/ Totals/ Forecasts> 09) 테이블 계산 필터> 10) 추세선/ 참조선

어떤 순서로 계산과 필터가 실행되는지에 따라 때때로 결과값마저 바뀌기도 하므로 작동 순서는 꼭 숙지해 둘 필요가 있다.

예를 들어 보자. 당신은 Furniture 카테고리 내에서 매출 상위 3개의 서브 카테고리를 보고 싶다. 문제는 여기서 발생한다. 상위 필터가 차원 필터보다 먼저 실행되기 때문에, 전체 중에서 매출 상위 3개의 서브 카테고리가 먼저 걸러지고 잔여물 중에서 Furniture 카테고리인 것이 조회된다. 이건 당신이 원하던 답이 아닐 것이다. 어떻게 해야 당신이 원하는 답을 태블로로 걸러낼 수 있을까?

이에 대한 훌륭한 솔루션이 컨텍스트 필터다. 컨텍스트 필터는 워크시트에서 생성되는 다른 어떤 필터보다 앞서서 실행된다.

위 경우로 보면, 카테고리 필터를 눌러서 컨텍스트 필터로 전환('컨텍스트에 추가' 클릭)해 주면 순위 집계보다 카테고리 데이터가 먼저 읽히게 된다. 이렇게 되면 태블로가 서브 카테고리의 순위 집계하는 타이밍에 카테고리 데이터를 보유하게 되니 Furniture 카테고리 중에서 상위 3개 서브 카테고리를 뽑는 것도 가능해진다. 

바꿔준 건 컨텍스트 필터 지정밖에 없는데도 잘 뽑히는 것 볼 수 있다. 머릿속의 결과물과 실제 결과물의 간극은 대부분 작동 순서를 다르게 파악하는 데서 발생한단다. 여튼 앞서 간 선배들의 눈물에 젖은 시행착오를 밟고 우리는, 두 결과물의 간극을 최대한 좁힐 거인의 어깨 위에 탄 셈이다. 잘 배워 활용해 보자.