JOHAWK_DATABASE

AI로 실무형 SQL 쿼리 테스트 준비하기

JOHAWK — Tue, 10 Mar 2026 18:15:35 +0900

쿼리 테스트, 왜 이렇게 어렵게 느껴졌을까?
연습은 했는데, 왜 결과가 안 좋았을까?
ChatGPT에게 실무형 문제를 요청하는 법
실제로 받은 문제들: 이런 수준이 나왔다
MySQL에서 바로 실행 가능한 샘플 데이터
AI에게 내 쿼리를 피드백 받는 방법
결과는 어땠을까?
마무리: AI는 SQL 공부의 좋은 파트너다

1. 쿼리 테스트, 왜 이렇게 어렵게 느껴졌을까?

데이터 직군을 준비하거나 이직을 고민하는 분들이라면, SQL 쿼리 테스트가 얼마나 긴장되는 관문인지 잘 아실 겁니다.

SQL 문법 자체는 어렵지 않다고 느꼈는데, 막상 테스트를 앞두고 나니 '실제로 어떤 유형의 문제가 나올까?', '어느 정도 수준까지 준비해야 할까?' 하는 질문들이 머릿속을 가득 채웠습니다.

결국 다들 하는 방법대로, 잘 알려진 SQL 연습 사이트부터 시작했습니다.

2. 연습은 했는데, 왜 결과가 안 좋았을까?

HackerRank, LeetCode, 프로그래머스, solvesql을 돌아가며 꾸준히 문제를 풀었습니다. GROUP BY, JOIN, 서브쿼리, 윈도우 함수까지 주요 개념을 골고루 다뤘고, 나름 자신감도 붙었습니다.

그런데 실제 쿼리 테스트 당일, 문제를 보자마자 멈칫했습니다.

데이터 구조가 낯설었습니다. 테이블이 여러 개였고, 어떤 테이블을 어떻게 조합해야 하는지 바로 감이 잡히지 않았습니다. 연습 때는 테이블 구조가 명확하고 문제 설명도 친절했는데, 실무형 테스트는 달랐습니다. 요구사항을 스스로 해석하고 데이터 간의 관계를 파악해서 쿼리를 짜야 했습니다.

결과는 기대보다 낮은 점수였습니다. 문법이 문제는 아니었습니다. 원인은 실무와 가까운 데이터와 심화 SQL 문제에 대한 경험 부족이었습니다.

3. ChatGPT에게 실무형 문제를 요청하는 법

다음 테스트를 준비하면서 방향을 바꿨습니다. ChatGPT에게 직접 실무형 데이터셋과 문제를 만들어달라고 요청했습니다.

던진 프롬프트는 이겁니다.

"리텐션, DAU & MAU, 퍼널 분석 등 실무와 관련된 SQL 문제를 만들어줄 수 있어?"

ChatGPT는 MySQL 8.0 기준으로 테이블 구조까지 설계해서 응답했습니다. 테이블은 세 개였습니다.

테이블	주요 컬럼
`users`	user_id, signup_date, channel, country
`events`	event_id, user_id, event_time, event_name, session_id
`orders`	order_id, user_id, order_time, amount

event_name은 app_open, view_product, add_to_cart, begin_checkout, purchase로 구성됐습니다. 실제 커머스 앱의 유저 행동 로그를 그대로 재현한 구조였습니다.

4. 실제로 받은 문제들: 이런 수준이 나왔다

총 25개의 문제를 받았습니다. 초급부터 고급까지 난이도별로 구성되어 있었습니다.

초급 ~ 중급 문제 예시

DAU 구하기

2026년 2월 한 달 동안의 일별 활성 유저 수(DAU)를 구하세요. 활성 유저는 하루에 events 테이블에 1번 이상 기록된 유저로 정의합니다.
출력 컬럼: dt, dau / 정렬: dt 오름차순

DAU / MAU Stickiness

2026년 2월의 각 일자별로 DAU, MAU, stickiness(= dau / mau)를 구하세요. stickiness는 소수점 둘째 자리까지 반올림하여 표시

신규 유저 D1 리텐션

가입한 다음 날 다시 접속한 비율(D1 retention)을 가입일 기준으로 구하세요.
출력 컬럼: signup_date, new_users, retained_users_d1, d1_retention_rate

고급 문제 예시

순차 퍼널 분석

app_open → view_product → add_to_cart → purchase 순서를 시간 순서대로 만족한 유저 수를 구하세요. 각 단계의 최초 시각만 사용합니다.

매출 포함 코호트 분석

가입 월 코호트별로 코호트 유저 수, 가입 월 매출(Month 0), 가입 다음 달 매출(Month 1), ARPU를 구하세요.

채널별 종합 리포트

채널별 가입자 수, DAU 평균, MAU, 구매 유저 수, 총 매출, D7 리텐션, 전환율을 한 번에 비교하는 리포트를 작성하세요.

처음 이 문제들을 봤을 때 솔직히 당황했습니다. 지표가 뭔지는 알겠는데, 어떤 테이블을 조합해야 하는지 바로 떠오르지 않는 그 느낌이 실제 테스트와 거의 똑같았습니다.

5. MySQL에서 바로 실행 가능한 샘플 데이터

ChatGPT에게 테이블 생성문과 샘플 데이터도 함께 만들어달라고 요청했습니다. 아래 SQL을 실행하면 바로 연습 환경이 만들어집니다.

테이블 생성 (DDL)

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    signup_date DATE NOT NULL,
    channel VARCHAR(20) NOT NULL,
    country VARCHAR(20) NOT NULL
);

CREATE TABLE events (
    event_id INT PRIMARY KEY,
    user_id INT NOT NULL,
    event_time DATETIME NOT NULL,
    event_name VARCHAR(50) NOT NULL,
    session_id VARCHAR(50) NOT NULL
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    user_id INT NOT NULL,
    order_time DATETIME NOT NULL,
    amount INT NOT NULL
);

샘플 데이터 INSERT

-- users 데이터
INSERT INTO users (user_id, signup_date, channel, country) VALUES
(1, '2026-01-28', 'organic', 'KR'),
(2, '2026-01-28', 'ads', 'KR'),
(3, '2026-01-29', 'referral', 'KR'),
(4, '2026-02-01', 'organic', 'KR'),
(5, '2026-02-01', 'ads', 'KR'),
(6, '2026-02-03', 'organic', 'US'),
(7, '2026-02-05', 'referral', 'KR'),
(8, '2026-02-10', 'ads', 'JP'),
(9, '2026-02-15', 'organic', 'KR'),
(10, '2026-02-20', 'ads', 'KR');

-- events 데이터
INSERT INTO events (event_id, user_id, event_time, event_name, session_id) VALUES
-- user 1: 풀 퍼널 완주 (app_open → purchase)
(1,  1, '2026-02-01 09:00:00', 'app_open',       's1'),
(2,  1, '2026-02-01 09:02:00', 'view_product',   's1'),
(3,  1, '2026-02-01 09:05:00', 'add_to_cart',    's1'),
(4,  1, '2026-02-01 09:07:00', 'purchase',       's1'),
(5,  1, '2026-02-02 10:00:00', 'app_open',       's2'),
(6,  1, '2026-02-03 11:00:00', 'app_open',       's3'),
-- user 2
(7,  2, '2026-02-01 13:00:00', 'app_open',       's4'),
(8,  2, '2026-02-01 13:03:00', 'view_product',   's4'),
(9,  2, '2026-02-02 14:00:00', 'app_open',       's5'),
-- user 3
(10, 3, '2026-02-02 08:00:00', 'app_open',       's6'),
(11, 3, '2026-02-02 08:05:00', 'view_product',   's6'),
(12, 3, '2026-02-04 08:00:00', 'app_open',       's7'),
(13, 3, '2026-02-04 08:10:00', 'begin_checkout', 's7'),
-- user 4
(14, 4, '2026-02-01 07:00:00', 'app_open',       's8'),
(15, 4, '2026-02-01 07:05:00', 'view_product',   's8'),
(16, 4, '2026-02-01 07:07:00', 'add_to_cart',    's8'),
(17, 4, '2026-02-03 12:00:00', 'app_open',       's9'),
-- user 5: 풀 퍼널 완주
(18, 5, '2026-02-01 21:00:00', 'app_open',       's10'),
(19, 5, '2026-02-08 21:00:00', 'app_open',       's11'),
(20, 5, '2026-02-08 21:05:00', 'view_product',   's11'),
(21, 5, '2026-02-08 21:06:00', 'add_to_cart',    's11'),
(22, 5, '2026-02-08 21:08:00', 'purchase',       's11'),
-- user 6
(23, 6, '2026-02-03 15:00:00', 'app_open',       's12'),
(24, 6, '2026-02-03 15:10:00', 'view_product',   's12'),
(25, 6, '2026-02-10 16:00:00', 'app_open',       's13'),
-- user 7
(26, 7, '2026-02-05 09:00:00', 'app_open',       's14'),
(27, 7, '2026-02-05 09:01:00', 'view_product',   's14'),
(28, 7, '2026-02-05 09:02:00', 'add_to_cart',    's14'),
(29, 7, '2026-02-05 09:04:00', 'begin_checkout', 's14'),
(30, 7, '2026-02-06 10:00:00', 'app_open',       's15'),
-- user 8
(31, 8, '2026-02-10 20:00:00', 'app_open',       's16'),
(32, 8, '2026-02-10 20:03:00', 'view_product',   's16'),
(33, 8, '2026-02-11 20:00:00', 'app_open',       's17'),
(34, 8, '2026-02-11 20:05:00', 'purchase',       's17'),  -- add_to_cart 없이 purchase → 순차퍼널 탈락
-- user 9
(35, 9, '2026-02-15 18:00:00', 'app_open',       's18'),
(36, 9, '2026-02-15 18:05:00', 'view_product',   's18'),
(37, 9, '2026-02-16 18:00:00', 'app_open',       's19'),
-- user 10
(38, 10, '2026-02-20 10:00:00', 'app_open',       's20'),
(39, 10, '2026-02-20 10:03:00', 'view_product',   's20'),
(40, 10, '2026-02-20 10:05:00', 'add_to_cart',    's20'),
(41, 10, '2026-02-20 10:06:00', 'begin_checkout', 's20'),
(42, 10, '2026-02-21 10:00:00', 'app_open',       's21');

-- orders 데이터
INSERT INTO orders (order_id, user_id, order_time, amount) VALUES
(1, 1, '2026-02-01 09:07:00', 32000),
(2, 5, '2026-02-08 21:08:00', 54000),
(3, 8, '2026-02-11 20:05:00', 21000),
(4, 1, '2026-02-15 12:00:00', 18000),
(5, 5, '2026-02-20 22:00:00', 47000);

한 가지 포인트를 짚자면, user 8은 purchase 이벤트는 있지만 add_to_cart가 없습니다. 단순 집계에서는 구매자로 카운트되지만, 순차 퍼널 분석에서는 앞 단계를 거치지 않았으므로 탈락합니다. 이런 디테일이 실무형 문제를 까다롭게 만드는 부분입니다.

6. AI에게 내 쿼리를 피드백 받는 방법

처음에는 하나의 채팅창에서 모든 문제의 피드백을 이어받았습니다. 대화가 길어질수록 이전에 받은 피드백을 다시 찾기가 어려웠고, 문항마다 맥락이 달라 정리도 잘 되지 않았습니다.

그래서 ChatGPT에서 "SQL 실무 쿼리"라는 프로젝트를 만들고, 소스에 샘플 데이터 파일을 업로드했습니다. 프로젝트 내 모든 채팅에서 테이블 구조를 공통으로 참고하기 때문에, 매번 구조를 다시 설명할 필요가 없었습니다.

그리고 문항마다 새로운 채팅을 열어 피드백을 받았습니다. 나중에 다시 찾아보기도 쉽고, 문제별 질문과 답변이 한 곳에 모여 깔끔하게 정리됐습니다.

실제로 받은 피드백은 이런 식이었습니다.

"서브쿼리 대신 CTE(WITH 절)를 사용하면 가독성이 좋아집니다"
"LEFT JOIN보다 INNER JOIN이 의도에 더 맞는 표현입니다"
"윈도우 함수의 PARTITION BY 기준을 확인해보세요. 현재 쿼리는 전체 기간 기준으로 순위를 매기고 있습니다"

"이 쿼리 맞아?"보다 "왜 이 방법이 더 나은지 설명해줘"라고 물으면 훨씬 깊이 있는 피드백을 받을 수 있습니다. SQL 실력은 '왜 이렇게 쓰는가'를 이해하는 데서 빠르게 늘기 때문입니다.

7. 결과는 어땠을까?

두 번째 테스트 결과는 만족스러웠습니다.

테이블 구조를 봤을 때 당황하지 않았습니다. "이전에 연습했던 커머스 이벤트 로그 구조와 비슷하다"는 느낌이 들었고, 접근 방향이 빠르게 잡혔습니다. 리텐션과 퍼널 쿼리도 여러 번 직접 써봤던 유형이라 침착하게 풀 수 있었습니다.

AI가 모든 걸 해결해 주지는 않습니다. 쿼리를 직접 짜는 건 결국 본인이고, 논리적 사고도 스스로 훈련해야 합니다. 하지만 실무에 가까운 환경을 만들고 즉각적인 피드백을 받는다는 점에서 AI는 효과적인 학습 파트너였습니다.

8. 마무리: AI는 SQL 공부의 좋은 파트너다

HackerRank나 LeetCode는 여전히 유효한 도구입니다. SQL 기초와 문법 감각을 키우는 데는 충분합니다. 하지만 실무형 쿼리 테스트를 앞두고 있다면, 그것만으로는 부족할 수 있습니다.

생성형 AI를 활용해 리텐션, DAU/MAU, 퍼널 분석 같은 실무 지표 중심의 문제를 직접 만들고, 쿼리에 대해 즉각적인 피드백을 받고 개선하는 루프를 만들어보세요. 연습의 질이 달라집니다.

실무 SQL은 문법을 아는 것과 실제로 쓰는 것 사이에 생각보다 큰 간격이 있습니다. AI는 그 간격을 좁히는 데 쓸 만한 도구입니다.

다음 쿼리 테스트를 준비 중이신 분들께 도움이 됐으면 좋겠습니다.

무료 데이터셋으로 리텐션 분석 연습하기(SQL)

JOHAWK — Fri, 23 Jan 2026 16:47:50 +0900

안녕하세요, SQL로 리텐션 분석을 연습하고 싶은 분께 추천드리고 싶은 데이터셋이 있어서 소개드립니다.

바로 Iranian Cosmetics & Personal Care Sales Dataset 입니다. (클릭 시 kaggle 사이트로 이동)

실제 이란의 2025년 화장품 및 퍼스널 케어 구매 데이터(트랜잭션)를 참고한 합성 데이터셋으로 Kaggle에 공개되어있습니다. 다운로드를 받으면 csv 파일로 구할 수 있습니다.

1. 데이터셋 살펴보기

데이터는 아래와 같이 구성되어 있습니다.

select * from invoices limit 1

컬럼명	의미
InvoiceId	송장 고유번호(INT)
OrderDate	주문일자(YYYY-MM-DD)
ProductId	제품 고유번호(INT)
CustomerId	고객 고유번호(INT)
ShipMode	배송 방식(Standard, Second, First, SameDay)
Quantity	구매한 제품 수량
Sales	수량을 반영한 판매 금액(단가 * Quantity)
Profit	판매자 기준 예상 이익
Discount	할인율(0, 0.05, 0.1)
TotalAmount	할인까지 적용된 실제 판매 금액(Sales*(1-Discount))

총 14,586건의 거래(트랜잭션) 데이터가 있고, 2496명의 고객, 고유 제품 500개, 4가지의 배송 방식과 3가지 할인율이 있습니다.

select
  count(*) as total_transactions,
  count(CustomerId) as total_customers,
  count(distinct CustomerId) as unique_customers,
  count(distinct ProductId) as unique_products,
  count(distinct ShipMode) as cat_shipmode,
  count(distinct Discount) as cat_discount
from invoices

이 데이터가 합성데이터셋인 것을 어떻게 알 수 있을까요?
월간 활성 유저 수와 거래 수, 그리고 배송 방식별 트랜잭션의 특징을 보면 알 수 있습니다.

1. 월간 활성 유저 수(MAU)와 주문 수가 모두 비슷합니다. 실제 미용 관련 커머스에서 이뤄지기 어려운 형태입니다.

with add_month as (
    select
        *,
        date_format(OrderDate, '%Y-%m-01') as OrderMonth
    from invoices
)
select OrderMonth,
    count(distinct CustomerId) as "MAU",
    count(InvoiceId) as cnt_transactions
from add_month
group by OrderMonth

2. 배송 방식에 따라 주문 수, 평균 이익, 평균 양, 평균 금액 등을 비교했을 때 큰 차이가 없어 합성 데이터셋임을 알 수 있습니다.

select
    ShipMode,
    count(InvoiceId) as cnt_orders,
    avg(Sales) as avg_price,
    avg(Quantity) as avg_quantity,
    avg(TotalAmount) as avg_amount
from invoices
group by ShipMode
order by avg_amount desc

3. 하나의 송장에 여러 제품들이 동시에 들어있는 경우는 없었습니다.

select
    count(InvoiceId) as total_invoice,
    count(distinct InvoiceId) as unique_invoice
from invoices

2. 리텐션 분석 쿼리 연습

리텐션을 추출하기 위해 필요한 컬럼은 CustomerId, OrderDate 두 개입니다.

1) '첫 주문 월'을 기준으로 코호트 구성하기

첫 주문 월을 기준으로 코호트를 만들기 위해 각 주문마다 주문 월과 해당 고객의 첫 주문 월을 넣어줍니다.

with add_month as (
    select
        CustomerId,
        OrderDate,
        date_format(OrderDate, '%Y-%m-01') as OrderMonth
    from invoices
), -- date_format 함수로 구매 연월 컬럼 생성
first_order as (
    select
        CustomerId,
        min(OrderMonth) as first_order_month
    from add_month group by CustomerId
) -- 코호트 구별을 위해 고객별 첫 주문 월 추출

select a.CustomerId, a.OrderMonth, f.first_order_month
from add_month a
left join first_order f
    on a.CustomerId = f.CustomerId

2) 리텐션 계산

case when과 date_add 함수를 이용해 첫 주문 이후 n개월 차에도 구매를 했는 지 확인하는 것이 중요합니다.

with add_month as (
select CustomerId, OrderDate, date_format(OrderDate, '%Y-%m-01') as OrderMonth from invoices
), -- date_format 함수로 구매 연월 컬럼 생성
first_order as (
select CustomerId, min(OrderMonth) as first_order_month from add_month group by CustomerId
) -- 코호트 구별을 위해 고객별 첫 주문 월 추출

select
    f.first_order_month as months, -- 첫 주문 기준 코호트
    count(distinct a.CustomerId) as month0, -- 첫 주문을 한 고객 수(고유 고객 수를 추출해야하므로 distinct를 사용)
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 1 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month1, -- 첫 주문 고객 수 대비 1개월이 지난 후 주문을 한 고객의 비율(%)
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 2 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month2, -- 첫 주문 고객 수 대비 2개월이 지난 후 주문을 한 고객의 비율(%)
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 3 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month3,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 4 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month4,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 5 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month5,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 6 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month6,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 7 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month7,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 8 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month8,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 9 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month9,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 10 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month10,
    round((count(distinct case when OrderMonth = date_add(f.first_order_month, interval 11 month) then a.CustomerId end) / count(distinct a.CustomerId)*100), 2) as month11 -- 첫 주문 고객 수 대비 11개월이 지난 후 주문을 한 고객의 비율(%)
    from add_month a
        left join first_order f
        on a.CustomerId = f.CustomerId
    group by f.first_order_month -- 첫 주문 월을 기준으로 코호트를 나누기 위해 group by 사용

이렇게 각 월마다 첫 주문을 한 고객 수(명)와 n개월이 지날 때마다 결제를 한 고객의 비율(%)을 구할 수 있습니다.

mysql에서는 반복문이 없기 때문에 각 컬럼마다 반복해서 작성해야합니다 ㅠㅠ

3) 해석

sql로 추출한 리텐션 데이터를 보다 쉽게 해석하기 위해 엑셀(구글스프레드 시트)의 조건부 서식 기능을 이용해서 히트맵을 만들었습니다.

month0은 고객수를 기준으로 막대 그래프를 넣었습니다. 2025년 1월의 첫 주문 고객 수가 975명으로 가장 많고 12월에 첫 주문을 한 고객 수는 3명으로 가장 적습니다.
month1부터 month11까지 리텐션은 녹색이 진할수록 높습니다.

리텐션은 가로, 세로, 대각선(↗) 방향으로 볼 수 있습니다.

1) 가로: 첫 주문 코호트 별 리텐션의 변화
- 25년 1월 코호트(첫 주문 고객)는 11개월이 지나도 37% 이상의 리텐션을 꾸준히 기록하고 있습니다.
- 25년 8월 코호트의 리텐션은 3개월 후(11월) 34%로 높았으나 12월에 21%로 크게 감소했습니다.

2) 세로: 각 코호트의 n개월 차 리텐션 비교
- 25년 8월 코호트는 다른 코호트에 비해 리텐션이 낮습니다.

3) 대각선(↗): 특정 월의 리텐션
- 25년 12월 리텐션을 비교했을 때, 10월 및 11월 코호트가 60%로 가장 높았고 8월 코호트가 21.88%로 가장 낮았습니다.

만약 이 데이터가 실제 데이터였으면, 저는 8월에 첫 주문을 한 고객들의 리텐션이 낮다는 것에 주목해 리서치를 통해 그 원인을 찾아보고자 했을 것입니다.

하지만 여기서 가장 중요한 것은 시간이 지날수록 첫 주문을 하는 고객 수가 급격히 줄어드는 것이죠. 리텐션을 걱정하기보다 신규 고객이 감소하는 원인을 찾는 것이 더 중요합니다.

지금까지 Kaggle의 데이터셋을 활용해서 연습하는 예시를 만들어봤습니다.

SQL을 배웠는데 실제로 연습할 데이터셋이 부족한 분들께 도움이 되셨길 바랍니다.

감사합니다.

이 글은 데이터리안 ‘SQL 데이터 분석 캠프 실전반’을 수강하며 작성한 내용입니다.

리텐션에서 ‘스마일 커브’는 언제 나타나는가

JOHAWK — Thu, 8 Jan 2026 10:39:16 +0900

안녕하세요, 최근 리텐션을 공부하다가 '스마일 커브'라는 흥미로운 유형의 리텐션 커브를 알게 되었습니다. 쉽게 나타나지 않는 모양이기 때문에 스마일 커브가 발생한 사례를 모으고 스마일커브가 언제 발생하는지 정리했습니다.

ChatGPT로 생성한 이미지입니다.

리텐션에서 '스마일 커브'는 언제 나타나는가

목차
1. 스마일 커브

2. 사례

1) 에버노트

2) ChatGPT

3) Missbeez

4) 무니스

3. 스마일 커브는 언제 나타나는가?

1. 스마일 커브

스마일 커브는 리텐션 코호트 그래프에서 다음과 같은 형태를 의미합니다.

초기 사용 이후 리텐션이 감소
일정 시점 이후 리텐션이 다시 상승
장기 코호트에서 사용 비율이 회복되거나 더 높아짐

이는 두 가지 현상이 동시에 일어날 때 가능합니다.

한 번 이탈한 사용자가 다시 돌아온다 (Resurrection)
오래 남은 사용자들의 사용 강도나 가치가 더 커진다

즉, “버틴 유저”가 아니라 “되돌아올 이유가 있는 유저” 가 존재해야 합니다.

2. 스마일 커브 사례

1) 에버노트

출처: Should Your Startup Go Freemium?

Evernote는 스마일 커브 논의에서 가장 자주 인용되는 사례입니다.
TechCrunch에 공개된 글에서 Evernote는 일반적인 하향 곡선과 달리, 1년 이후 사용이 오히려 증가하는 ‘Smile Graph’ 를 직접 공개했습니다.

이 현상이 가능했던 이유는 Evernote의 제품 구조에 있습니다.

사용자가 저장한 노트, 문서, 클리핑은 시간이 지날수록 쌓인다
쌓인 데이터 자체가 개인 자산이 된다
한동안 사용하지 않더라도 “언젠가 다시 필요해질 것”이라는 기대가 생긴다

결과적으로 Evernote는
“매일 쓰는 앱”이 아니라 “필요해지면 반드시 돌아오는 앱” 이 되었고,
이 복귀 행동이 코호트 전체 리텐션을 다시 끌어올렸습니다.

이 사례는 스마일 커브가 마케팅이나 리마인드 알림이 아니라, ‘저장되는 가치’에서 비롯될 수 있음을 보여줍니다.

2) ChatGPT

ChatGPT 역시 최근 여러 VC와 분석가들이 스마일 커브 리텐션을 보인 사례로 언급하고 있습니다.
Menlo Ventures의 파트너 Deedy Das는 공개적으로 ChatGPT의 리텐션을 “rapidly rising smile curve”라고 표현했습니다.

이 사례가 흥미로운 이유는 Evernote와 정반대의 특성을 갖고 있기 때문입니다.

Evernote는 ‘저장형(Stored Value)’ 제품
ChatGPT는 ‘즉시 가치형(Instant Utility)’ 제품

그럼에도 스마일 커브가 나타난 이유는 다음과 같습니다.

초기 사용자는 단일 유스케이스로 유입
시간이 지나며 새로운 활용법을 발견
(업무 자동화, 학습 보조, 글쓰기, 코딩 등)
다시 돌아왔을 때 “이전보다 훨씬 쓸모 있는 도구”가 되어 있음

즉, ChatGPT의 스마일 커브는
‘데이터 축적’이 아니라 ‘유스케이스 확장’에 의해 만들어진 곡선이라고 볼 수 있습니다.

3) Missbeez

출처: Cohort analysis - 4 ways to analyze your product retention rate

이스라엘에서 시작한 라이프스타일 및 뷰티 서비스 예약/배달 서비스를 제공하는 Missbeez 사례는 조금 다릅니다.
이 사례에서 스마일 커브는 사용자 수 리텐션이 아니라, 코호트 기준 매출 리텐션에서 관측되었습니다.

공개된 코호트 분석에 따르면,

특정 월에 유입된 고객들의 매출은 초기에는 감소
이후 재구매, 업셀, 사용 빈도 증가로 인해
시간이 지나며 유입 시점의 매출을 다시 상회

이는 전형적인 Negative Churn(순확장 매출) 패턴입니다.

이 사례는 중요한 시사점을 줍니다.

사용자 수 리텐션은 평범해 보여도, 매출 리텐션에서는 스마일 커브가 나타날 수 있다.

특히 B2B SaaS, 마켓플레이스, 구독 서비스에서는
“남아 있는 소수의 고객이 점점 더 많은 가치를 만들어내는 구조”가
스마일 커브를 매출 기준으로 먼저 드러내는 경우가 많습니다.

4) 무니스

지금까지 해외 기업에서 발생한 스마일 커브를 살펴봤습니다. 국내에서는 스마일 커브를 보인 서비스가 있을까요? 국내 스타트업 Munice(무니스) 에서도 실제로 관측된 바 있습니다. 무니스는 AI 기반 수면 앱인 'Nightly(미라클나잇)'을 제공하고 있습니다.

출처: 리텐션이 웃다니

무니스의 초기 리텐션은 전형적으로 빠르게 하락 후 flat 형태를 유지하고 있었습니다.

무니스는 고객들이 자사 서비스를 충분히 사용할 수 있도록 두 가지 전략을 사용했고, 리텐션의 증가로 이어졌습니다.

푸시 알림 도입
- 데이터를 기반으 고객들이 잠들기 직전(오전 12시 이후)에 앱을 가장 많이 사용하는 것을 확인했고 그 전인 오후 11시에 푸시 알림을 보냈습니다.
콘텐츠 추가
- 자사 서비스의 과학적 배경, 기본 기능과 관련이 있는 아티클 업로드, 수면을 유도하는 명상 기능 추가 등을 추가했습니다.

무니스 사례는 스마일 커브가 저장형 서비스나 글로벌 SaaS에 국한되지 않고,
사용자 문제의 재발성과 서비스 가치의 타이밍이 맞물릴 때 국내 서비스에서도 충분히 발생할 수 있음을 보여줍니다.

3. 스마일 커브는 언제 나타나는가?

위 사례들을 종합했을 때, 서비스 유형에 따라 세부적인 방식은 다르겠지만, 서비스를 계속 이용하는 유저들이 늘어나거나, 혹은 복귀 유저가 늘어나 리텐션이 증가하는 스마일 커브는 다음과 같을 때 발생합니다.

시간이 지날수록 유저에게 서비스의 가치가 높아짐(축적된 고객 데이터로 개인화된 서비스 제공 등)
새로운 기능 추가 또는 활용법 발견
부담스럽지 않은 리텐션 유도

즉, 고객이 계속 사용하거나 돌아올 수 있도록 서비스의 가치를 올리는 것이 가장 중요합니다.그리고 데이터 분석을 통해 푸시 알림 시간 설정 등 리텐션을 높이는 최적의 방법을 탐색해야 합니다.그래서 스마일 커브를 이끌어내기 위해 다음과 같은 질문을 하는건 떨까요?

우리 제품에는 시간이 지날수록 쌓이는 가치가 있는가?
사용자가 떠났다가 돌아와야 할 이유를 명확히 설명할 수 있는가?
사용자 리텐션과 매출 리텐션을 분리해서 보고 있는가?
‘계속 쓰는 사람’과 ‘돌아오는 사람’을 구분해 분석하고 있는가?

참고

리텐션이 웃다니 | Disquiet*

우리 팀은 오늘 이론적으로만 존재하는 줄 알았던 스마일 리텐션을 목격했다. (탈춤을 췄다)사실 Retention이라는 지표를 목적으로 스프린트를 진행하지 않아 상당히 의아한 결과라고 생각한다.

disquiet.io

Should Your Startup Go Freemium? | TechCrunch

Editor's note: Jules Maltz is a general partner at IVP. Daniel Barney is a senior associate at IVP. For some, freemium is a business model that sacrifices revenues and forces startups to support freeloaders who will never become paying customers. For oth

techcrunch.com

ChatGPT's Retention Curves Resemble Past Winners - Brian Balfour

Brian cites Didi Doss’s retention curves showing ChatGPT’s engagement levelling much higher and shifting upward, echoing past winners like Slack.

lennysvault.com

https://www.mobilespoon.net/2019/07/cohort-analysis-retention-rate.html

Cohort analysis - 4 ways to analyze your product retention rate

4 practical methods to calculate your product's retention rate to analyze the unit economics and performance of each cohort across time.

www.mobilespoon.net

본 내용은 데이터리안 'SQL 데이터 분석 캠프 실전반' 을 수강하며 작성한 내용입니다.

생성형 AI를 이용한 워크플로우 개선

JOHAWK — Thu, 30 Oct 2025 15:43:23 +0900

ChatGPT와 Claude 등 생성형 AI를 이용해 수동으로 작업했던 과정을 개선한 경험을 공유드립니다.

생성형 AI를 이용한 워크플로우 개선

목차
1. 문제 및 현황

2. 워크플로우 개선

3. 결과

1. 문제 및 현황

저희 회사는 IT교육기관과 협력해 부트캠프 수강생들에게 노트북을 대여하는 사업도 하고 있습니다. 그리고 그 과정에서 노트북을 관리하는 것은 필수입니다.

오퍼레이션 팀은 수강생들이 대여한 노트북을 관리하기 위해 리툴에서 엔지니어팀이 만들어 준 앱을 이용해 회사 소프트웨어 DB에 수동으로 학생들을 등록하고 있었습니다.

문제는 수백 명을 등록해야 하는데 아래 사진처럼 모든 항목을 타이핑해서 등록하는 것은 너무 오래 걸리고, 엔지니어팀에 요청하기에는 당장 처리해야 할 일들이 산더미라는 것입니다.

그래서 저는 생성형 AI와 함께 수강생 DB 등록 워크플로우를 보다 쉽게 만들어보기로 했습니다.

2. 개선 방법

1) Retool과 구글 스프레드시트 연동

먼저, Retool 앱 내에서 바로 수강생 정보들을 확인할 수 있게 구글 스프레드 시트를 연동했습니다. 다행히 Retool에서 구글 스프레드시트 연동을 지원해서 쉽게 연결할 수 있었습니다.

2) Retool 앱 변경 with Claude

Retool은 로우코드를 지향하는 백오피스앱으로 기본적인 조작은 GUI로 가능하나 디테일한 설정을 하기 위해서는 자바스크립트를 사용해야 합니다. 하지만 저는 자바스크립트르 배웠던 적이 없었고, 기존에 있던 Retool 앱을 최대한 변경하지 않고 기능만 추가하기 위해 ChatGPT와 Claude를 사용해보고 응답의 정확성이 더 높았던 Claude를 메인으로 활용했습니다.

Claude와 ChatGPT가 가장 잘 했던 부분은 코드 해석 및 생성이었습니다. 기존 앱의 자바스크립트 내용을 해석하기 위해 물어봤을 때 가장 정확하게 만들어줬고, 기존 자바 스크립트를 기반으로 제가 반영하고자 하는 코드를 만들어주었습니다.

반면, 생성형 ai가 가지고 있는 retool에 대한 지식이 최근 retool과 일치하지 않았던 점이 어려웠습니다. GUI로 설정을 바꿔야 하는 과정에서 Claude의 답변이 실제 ui와 달랐습니다. 그랬을 때에는 현재 UI를 캡쳐한 다음 Claude에게 캡쳐한 UI를 기준으로 답변해달라고 했을 때 더 나은 답변을 받을 수 있었습니다.

최종적으로 Retool에서 구글 스프레드를 테이블 형태로 가져오고 추가하고자 하는 인원의 행을 클릭한 후 '바로 추가' 버튼을 누르면 DB에 등록되도록 했습니다.

실제로 완성된 retool 앱의 모습. 구글 스프레드시트에 잘못된 정보가 입력되었을 때를 대비해 기존의 타이핑 등록 방식도 남겨놨습니다.

3. 결과

약 1시간 동안 Claude와 작업을 해 Retool에서 구현을 완료했습니다. 기존에는 1명을 등록하기 위해 모든 정보를 타이핑하고 등록을 하기까지 최소 2초가 걸렸지만, 원하는 행을 클릭하고 등록을 하는 것으로 바꾸니 0.5초도 걸리지 않았습니다. 약 4배의 업무시간이 단축된 것이었죠. 거기에 여러 명을 하는 동안 타이핑하면서 누적되는 피로감도 사라졌으니 효율은 더 올라갔습니다.

그 결과, 오퍼레이션 팀은 밀렸던 수강생 등록을 빠르게 마무리했고, 주요 업무를 보면서 시간이 빌 때 간단하게 수강생을 등록하는 데일리 업무로 전환할 수 있었습니다.

인터넷을 찾아보면 생성형 AI를 무궁무진하게 활용하시는 분들도 많습니다. 처음부터 그 분들을 따라하려고 하면 막히는 부분이 있을 수도 있어요. 그렇게 어려움을 느낄 때 저처럼 간단하게라도 생성형 ai를 이용해서 생산성을 높여보는 것은 어떨까요?

가장 간단한 방법으로 문제 해결하기: 결제일 예측 프로세스 개선

JOHAWK — Wed, 29 Oct 2025 16:53:57 +0900

이번에는 제가 처음으로 맡았던 업무인 결제일 예측 프로세스 개선 사례에 대해 알려드리려고 합니다. 결제일 예측을 개선하기 위해 다양한 방법을 고민했다가 가장 간단한 방법인 결제일을 기반으로 예측해서 정확도를 높였습니다.

가장 간단한 방법으로 문제 해결하기: 결제일 예측 프로세스 개선

목차
1. 문제 및 현황

2. EDA

1) 결제일 간격

2) 결제일 빈도

3) 인사이트

3. 가설 검증

1) 가설

2) 결제일 빈도 기반 예측 로직

3) 가설 검증

4) 결과

1. 문제 및 현황

1) 문제

제가 다니는 회사에서는 주간 리포트를 통해 고객사의 지난 주 소프트웨어 결제 내역과 주요 포인트를 제공하고 이번 주에 발생할 결제를 예측해서 안내하고 있습니다. 그런데 이번 주 결제일 예측의 정확도가 낮다는 피드백을 받고 확인을 해보니 정확도가 낮았고 예측 자체도 많지 않았습니다.

2025년 6월 2주차 기준 결제일 예측

항목	건
실제 결제 내역 수	287
예측한 결제 수	85
맞춘 결제 예측 수	5

1) 현황

제가 들어오기 전까지 고객사의 각 소프트웨어의 결제일의 평균 간격을 계산해 예측하는 방식으로 다가오는 결제일을 예측했습니다. 하지만 이 방식은 크게 두 가지 문제점이 있습니다.

- 달마다 일 수가 다릅니다. 1년 중 7개월은 31일이 있으며, 4개월은 30일입니다. 그리고 2월은 28일이며, 윤달인 경우 29일입니다. 이 상황에서 결제일의 간격을 기반으로 하루, 이틀의 차이가 발생할 수 있습니다.

- 고객사의 결제 패턴이 매우 다양합니다. 고객사와 소프트웨어의 유형에 따라 결제하는 방식이 다릅니다. 예를 들어, 어떤 기업은 ChatGPT 팀 요금제를 사용해 매 월 1회만 결제합니다. 반면, 구성원 별로 ChatGPT를 결제해 매 월 n회 이상 결제가 발생합니다.

2. EDA

64개 고객사의 결제내역 55,210건을 수집했고, 모든 결제 내역에 반드시 포함되는 결제 승인 시각을 KST로 변환했습니다. 그리고 결제 금액도

1) 결제일 간격

고객사들의 평균 소프트웨어 결제일 간격은 38.7일이었습니다. 1개월 + 7일 정도의 차이였습니다.

결제일 간격의 범위는 0일 ~ 412.5일이었습니다. 0일인 경우는 같은 날에 다른 구성원들의 소프트웨어를 결제한 케이스입니다.

2) 결제일 빈도

전체 데이터를 비교해봤을 때, 각 기업에서 결제일이 같은 소프트웨어의 수는 2,377개였습니다. 총 소프트웨어 수가 2,879개인 것을 고려하면 대부분의 소프트웨어가 결제일이 같다는 것을 확인할 수 있습니다.

결제일이 달랐던 케이스를 살펴보면 매입만 기록되는 카드사에서 주말에 결제 승인이 되면 다음 영업일에 매입이 발생하는 경우, 매월 말일에 결제가 발생하는 경우가 있었습니다.

3) 인사이트

EDA를 통해 대부분의 소프트웨어가 지정된 날짜를 기준으로 결제가 발생한다는 것을 확인했습니다.

3. 가설 검증

1) 가설

EDA를 통해 대부분의 소프트웨어가 특정 날짜를 지정해서 결제가 발생한다는 것을 확인했고, 이에 기반해 다음과 같은 가설을 세웠습니다.

결제일 간격 기반 예측보다 결제일 빈도 기반 예측의 정확도가 더 높을 것이다.

2) 결제일 빈도 기반 예측 로직

결제일 빈도 기반 예측은 다음과 같은 전개를 통해 이루어집니다. 먼저, 신규 고객이 가져올 수 있는 최소 단위가 3개월이기 때문에 최근 3개월 결제 내역 데이터를 가져옵니다. 그 다음, 최근 2개월 내 같은 날짜에 트랜잭션이 발생한 경우와 3개월 동안 매 월 1회 결제가 발생하는데 결제일들의 범위(가장 빠른 날과 가장 느린 날)가 3일 이하면 결제일 목록에 추가했습니다.

3) 가설 검증

6월 2주차 데이터를 가지고 두 예측 방식 결과를 비교했습니다.

기존 결제일 간격 기반 예측은 85건을 예측한 반면, 결제일 빈도 기반 예측은 242건을 예측해 실제 결제 내역 수(287건)와 비슷해졌습니다.

정밀도, 재현율, F1 점수 모두 이전에 비해 10배 이상 상승했습니다.

4) 결과

위 분석 결과를 근거로 결제일 예측 프로세스를 결제일 빈도 기반으로 바꿨습니다. 그리고 고객으로부터 이전보다 결제일 예측 정확도가 높아졌다는 긍정적인 피드백을 받았습니다.

위 프로젝트를 하면서 처음에는 정확한 결제일 예측을 위해 머신러닝과 같은 고도화된 분석 방법들을 생각했으나 EDA를 통해 결제일 간격을 결제일 빈도로 바꾸는 가장 간단한 방법으로 결제일 예측의 정확도를 10배 이상 높일 수 있었습니다.

최신 분석 방법이 무조건적인 정답이 아니고 EDA를 통해 데이터가 가지는 특성을 확인하는 것이 중요하다는 것을 실제 데이터로 확인할 수 있던 좋은 기회였습니다.

데이터 분석에서 B2B와 B2C의 차이

JOHAWK — Wed, 29 Oct 2025 14:57:09 +0900

안녕하세요, 저는 올해 6월부터 SaaS를 비롯한 IT자산을 관리하는 스타트업의 데이터 분석가로 커리어를 시작했습니다. 지금까지 데이터 분석을 하면서 느꼈던 B2B와 B2C의 차이를 간단하게 적어보려고 합니다.

데이터 분석에서 B2B와 B2C의 차이

목차
1. 규모

2. 설득 대상

3. 피드백 방법

1. 규모

일반적인 B2C 사업은 수많은 개인 고객들을 상대하기 때문에 표본의 크기가 매우 큽니다. 그렇기 때문에 유저 행동 데이터를 기반으로 A/B 테스트, 리텐션 분석 등 다양한 정량적 분석 방법을 사용할 수 있습니다.

반면, B2B 사업은 고객 수가 상대적으로 적습니다. 물론, slack이나 notion처럼 글로벌 기업에서는 충분한 표본이 있겠으나 제가 근무하는 스타트업에서는 활성 고객사 수가 100곳 이하였습니다. 그렇기 때문에 사용자의 행동 데이터를 기반으로 분석을 진행하는 것이 어려웠습니다. 그래서 고객사 하나 하나의 패턴에 집중하고, 정량적 데이터로는 알 수 없는 고객사의 내부 상황 등을 고려해야 합니다.

2. 설득 대상

B2C 사업에서 설득의 대상은 타겟층으로 정한 사람입니다. 사람은 이성적 판단 뿐만 아니라 감정적 만족도 중요합니다. 그래서 고객에게 프로덕트 사용을 이끌어내기 위해 이성적인 판단 뿐만 아니라 감정도 어필해야 합니다. 즉, 프로덕트를 이용하는 과정에서 고객들의 생각과 심리를 파악하기 위해 데이터를 분석합니다.

B2B 사업에서는 설득 대상은 개인이 아닌 조직으로 크게 실무진과 경영진으로 나눌 수 있습니다. 실무진은 실제 프로덕트를 사용하는 입장으로 B2C의 개인과 유사한 입장에 있습니다. 하지만 경영진은 비용을 지불하면서 프로덕트를 사용할 만한 가치가 있는 지 그 효용성을 확인하고 싶어합니다. 그래서 실무진은 프로덕트에 대해 만족하지만 경영진의 반대로 인해 계약이 무산되는 경우도 있습니다. 즉, 보다 이성적인 판단이 필요한 기업의 경영진에게 설득을 위한 데이터를 보여줘야 합니다.

3. 피드백 방법

B2C 사업에서 회사측에서 변화를 주면 고객들의 반응이 빠르게 다가옵니다. 예를 들어, 프로덕트에 새로운 기능을 추가했을 때 유저들의 클릭율이나 이탈률을 통해 반응을 볼 수 있습니다. 그래서 발전 속도가

반면, B2B 사업은 표본도 적고, 때문에 행동 데이터만으로 프로덕트의 변화가 성공했는지 쉽사리 판단하기 어렵습니다. 대신, 실제 유저들이 작성한 VoC, 담당자와 회의 내역이 더 중요합니다.

이상으로 신입 데이터 분석가가 느낀 B2B 데이터 분석과 B2C 데이터 분석의 차이였습니다. 감사합니다.

[후기] 넛지헬스케어 데이터분석 코딩 테스트

JOHAWK — Tue, 22 Apr 2025 09:58:32 +0900

넛지헬스케어 데이터분석 직무 채용 과정 중 서류 전형 후 응시하는 코딩 테스트 후기입니다.

넛지헬스케어 데이터분석 코딩 테스트

목차
1. 지원 직무

2. 코딩테스트

1) 플랫폼: 코드시그널

2) 방식

3) 난이도

3. 소감

1. 지원 직무

캐시워크를 운영하는 넛지헬스케어에서 캐시워크의 데이터분석을 담당하는 채용전환형 인턴에 지원했습니다.

지원서 제출 후 다음 날에 코딩테스트 안내 메일이 왔습니다.

2. 코딩테스트

1) 플랫폼: 코드시그널

코드시그널이라는 해외 플랫폼에서 코딩테스트를 했습니다. 해외 플랫폼이기 때문에

영어로 코딩테스트가 진행되는데 쉽게 서술되어 있고 프로그래머스처럼 문제 제시 후 예시를 보여주기 때문에 이해하는데 큰 어려움은 없었습니다.준비를 한다면 리트코드에서 영어로 제공하는 문제들을 풀어보는 것이 좋을 것 같습니다

2) 방식

제가 예상한 방식과 많이 달랐습니다.

저는 이전에 코딩테스트를 본 적이 없으며, 프로그래머스에서 연습문제를 계속 풀어 웹에서 SQL문을 작성하는 것에 익숙했습니다.

그런데 예상치도 못한 객관식 위주의 코딩테스트로, 응시자에게 분석에 사용할 csv파일을 주고 자신의 IDE로 문제를 푼 다음, 웹사이트에서 정답을 고르는 방식이었습니다. 웹에서 SQL문을 작성하는 문제는 딱 1개였습니다.

그리고 하나의 시나리오에 6~7개의 문제들이 분포되어 있는 형태였기에 제공되는 csv파일도 많아 파일을 다운받고 MySQL에 업로드하는데 시간이 소요됩니다.

코딩테스트 방식을 정리하면 아래와 같습니다.

시험 시간: 70분
문제 수: 15문제
문제 유형: 객관식 14문제 + SQL문 작성 1문제

3) 난이도

문제 하나 하나 내용을 천천히 살펴보면 어려운 문제는 아니었습니다. 프로그래머스에서 레벨 2, 3 단계 문제들을 빠르게 풀 수 있다면 코딩테스트에서도 높은 점수를 받을 수 있을 것 같습니다. 저는 15문제 중 2문제를 풀지 못했습니다.

다만, 프로그래머스 문제와 다른 유형이 있어 당황할 수 있습니다. 예를 들어, 보기에서 제시된 문서 이름 중 가장 분량이 많은 것을 고르라는 문제에서는 단순히 MAX()를 쓴다고 정답이 나오지 않습니다. 직접 보기에 제시된 문서들을 서치해 비교해야 합니다.

그리고 후반부에 통계 분석 문제가 나와서 sql에서 python으로 옮겨야 하기 때문에 시간이 소요될 수 있습니다.

실무와 유사한 시나리오에서 1~2번 문제를 풀면 3번은 1~2번에 풀었던 내용에 기반한 문제가 나와 순서대로 푸는 것이 도움이 될 것 같습니다.

3. 소감

처음 진행한 코딩테스트인데 일반적으로 구글링을 했을 때 볼 수 있었던 코딩 테스트와 다른 유형이어서 약간 당황했습니다.

이번 기회를 통해 데이터 분석가가 겪는 코딩테스트에 대해 감을 잡을 수 있었고, 언제나 SQL과 Python을 자유롭게 넘나들 수 있게 준비를 해야겠습니다.

Fandom-K 데이터베이스 설계

JOHAWK — Fri, 3 Jan 2025 20:51:22 +0900

본 미션은 가상의 서비스 "Fandom-K"의 와이어프레임을 바탕으로 진행되었습니다.

Fandom-K은 K-pop 아티스트와 팬을 이어주는 글로벌 조공 플랫폼입니다. 아직 서비스의 와이어프레임만 있을 뿐, 아직 개발을 시작하진 않았다고 가정해볼게요. 여러분은 Fandom-K의 데이터 인프라를 담당하는 데이터 엔지니어로써 해당 서비스의 DB를 구축해야합니다.
하단의 서비스 소개를 참고하여 서비스 전체의 ERD 다이어그램을 그려봅시다. 어떤 테이블이 필요할까요? 테이블간의 관계(식별/비식별 관계, 카디널리티, 컬럼의 PK와 FK 등)와 테이블 정규화를 고려하면서 작성해주세요.작성한 ERD 다이어그램을 기반으로 직접 MySQL에 구현해봅시다. "FandomK"라는 데이터베이스를 하나 생성하고, DDL 문 작성을 통해 실제 DB 환경을 구현해보세요. (테이블 내 데이터는 따로 구현하지 않아도 좋습니다.)MySQL Workbench (혹은 사용하고 있는 DB Tool)에서 구현한 데이터베이스의 ERD를 확인할 수 있어요. 1번에서 그린 ERD와 비교하며 구현이 제대로 되었는지 확인해보세요.

1. ERD 그리기

1) user

Fandom-K에 가입한 유저들의 정보를 저장
primary key: user_id
포함된 정보: 가입일, 생일, 성별, 직업 등
관계
- 1:N 관계 >> credit_charge, favorite, jogong_log, chart_log

2) credit_charge

유저들의 크레딧 충전 정보를 저장
primary key: charge_id
포함된 정보: 충전일자, 충전금액, 충전방식, 상태(대기, 취소, 승인 등), user_id(foreign key)
관계
- N:1 관계 >> user

3) artist

Fandom-K에 등록된 아이돌 멤버에 대한 정보 저장
primary key: artist_id
포함된 정보: 이름, 그룹_id, 그룹명, 성별, 유형(솔로, 그룹 등), 사진
관계
- 1 :N 관계 >> favorite, jogong, chart
- 1:N 관계 >> jogong_log
- N:1 관계 >> artist

4) favorite

유저가 '관심 있는 아이돌'에 추가한 정보 저장
primary key: favor_id
포함된 정보: 등록일자, artist_id(foreing key), user_id(foreign key)
관계
- N:1 관계 >> user, artist

5) jogong

Fandom-K에 등록된 조공 서비스에 대한 정보 저장
primary key: j_id
포함된 정보: 생성일, 목표 금액, 마감일자, 조공이미지, artist_id(foreign key)
관계
- 1:N 관계 >> jogong_log
- N:1 관계 >> artist

6) jogong_log

유저들이 조공에 참여한 기록 저장
primary key: id
포함된 정보: 조공일, 조공금액, platform_id(foreign key), user_id (foreign key) , j_id(foreign key)
관계
- N:1 관계 >> jogong, user_id, platform_id

7) chart

Fandom-K에 등록된 '투표'에 대한 정보 저장
primary key: chart_id
포함된 정보: 시작일, 마감일, 득표수, 차트 유형(월간 투표, 일간 투표 등), artist_id(foreign key)
관계
- 1:N 관계 >> chart_log
- N:1 관계 >> artist_id

8) chart_log

유저들이 투표에 참여한 기록 저장
primary key: id
포함된 정보: 투표일, platform_id(foreign key), user_id (foreign key) , artist_id(foreign key), chart_id(foreign key)
관계
- N:1 관계 >> chart_id, user_id, artist_id, platform_id

9) platform

유저들이 접속한 기기에 대한 정보 저장
primary key: platform_id(PC, mobile, tablet 등)
관계
- 1:N 관계 >> jogong_log, chart_log

2. DDL 작성

-- 빅쿼리로 작성했습니다.
-- 데이터셋 생성
CREATE SCHEMA IF NOT EXISTS `da-first-445105.Fandom_K`
OPTIONS(
  location="US"  -- 지역 설정 (예: US, ASIA 등)
);

--테이블 생성
CREATE TABLE Fandom_K.user(
  user_id STRING NOT NULL,
  start_date DATETIME NOT NULL,
  birthday DATETIME,
  gender STRING NOT NULL,
  job STRING NOT NULL);

CREATE TABLE Fandom_K.artist(
  artist_id STRING NOT NULL,
  artist_name STRING NOT NULL,
  group_id STRING,
  group_name STRING,
  enroll_date DATETIME NOT NULL,
  artist_type STRING NOT NULL,
  gender STRING NOT NULL,
  photo STRING
);

CREATE TABLE Fandom_K.favorite(
  favor_id STRING NOT NULL,
  favor_date DATETIME,
  user_id STRING,
  artist_id STRING
);

CREATE TABLE Fandom_K.credit_charge(
  charge_id STRING NOT NULL,
  user_id STRING,
  charge_date DATETIME,
  charge_amount INT NOT NULL,
  charge_method STRING NOT NULL,
  status STRING NOT NULL
);

CREATE TABLE Fandom_K.platform(
  platform_id STRING NOT NULL
);

CREATE TABLE Fandom_K.jogong(
  j_id STRING NOT NULL,
  start_date DATETIME NOT NULL,
  end_date DATETIME NOT NULL,
  goal_amount INT NOT NULL,
  image STRING NOT NULL,
  artist_id STRING
);

CREATE TABLE Fandom_K.jogong_log(
  id STRING NOT NULL,
  donation_date DATETIME NOT NULL,
  credit_amount INT NOT NULL,
  j_id STRING,
  user_id STRING,
  platform_id STRING
);

CREATE TABLE Fandom_K.chart(
  chart_id STRING NOT NULL,
  start_date DATETIME NOT NULL,
  end_date DATETIME NOT NULL,
  chart_type STRING NOT NULL,
  artist_id STRING,
  vote_count INT NOT NULL
);

CREATE TABLE Fandom_K.chart_log(
  id STRING NOT NULL,
  chart_id STRING,
  artist_id STRING,
  platform_id STRING,
  user_id STRING,
  vote_date DATETIME NOT NULL
);

3. Bigquery에서 스키마 확인하기

베이커리 구매 패턴 분석을 통한 운영전략 구상

JOHAWK — Mon, 2 Dec 2024 22:32:30 +0900

안녕하세요, 이번에는 EDA와 연관 분석을 활용해 베이커리를 구매하는 사람들이 같이 구매하는 메뉴가 무엇인지 확인하고 이에 따른 운영 전략을 구상해보았습니다.

베이커리 구매 패턴 분석을 통한 운영전략 구상

목차
1. 데이터 전처리

2. EDA

1) 월별 거래 수

2) 판매 물품

3) 요일별 거래 수

4) 시간 및 품목별 거래 수

3. 연관분석

4. 종합

5. 후기

1. 데이터 전처리

이번 분석은 캐글에서 제공하는 Bakery Sales Dataset 데이터셋을 사용했습니다. 해당 데이터는 영국 에든버러의 한 베이커리에서 발생한 트랜잭션(transaction) 정보가 담겨있습니다.

변수명	설명
Transaction	거래 ID
Item	구매한 제품명
date_time	거래 날짜 및 시각
period_day	아침/오후/저녁/밤 중 언제 구매했는지 여부
weekday_weekend	주중/주말 중 언제 구매했는지 여부

데이터를 면밀히 살펴보기 위해 date_time을 세부적으로 나눴습니다.

# DateTime 컬럼의 데이터타입을 DateTime으로 변환 후 연월일 분리
bakery['DateTime'] = bakery['DateTime'].astype('datetime64[ns]')
bakery['year'] = bakery['DateTime'].dt.year
bakery['month'] = bakery['DateTime'].dt.month
bakery['day'] = bakery['DateTime'].dt.day
bakery['hour'] = bakery['DateTime'].dt.hour
bakery['dayofweek'] = bakery['DateTime'].dt.strftime("%A")
bakery.describe(include='all')

월별로 판매량을 살펴봤을 때, 다른 기간에 비해 2016년 11월 ~ 2017년 3월까지 기간에서 거래량이 매우 많았습니다. 그 이유에 대해 여러 방면으로 생각하고 리서치를 실행했습니다. 그리고 브렉시트로 인한 물가 상승이 크게 발생했으나 빵은 상승폭이 크지 않아 사람들이 많이 샀다는 결론을 내렸습니다. 그래서 2016년 11월 ~ 2017년 3월은 특수 시즌, 그 외 기간은 일반 시즌으로 정의했습니다. 그리고 추후 분석은 일반 시즌과 특수 시즌을 나누어서 진행했습니다.

(사실, 특수 시즌이 정상적으로 데이터가 남은 것이고 일반 시즌이 한 달 중 15일 미만의 데이터만 남은 것입니다. 캐글에서도 초창기에는 위 데이터와 같은 모습을 보였으나 중간부터 특수 시즌만 남긴 데이터셋으로 수정되었습니다.)

2. EDA

1) 월별 거래 수

특수 시즌과 일반 시즌의 월별 거래 수를 비교했습니다. 특수 시즌과 일반 시즌 간 차이는 존재하지만 같은 시즌에서는 유의한 월별 판매량 차이가 존재하지 않았습니다.

2) 판매 물품

판매한 품목들을 살펴보면 정말 다양한 물건들을 팔고 있었습니다. 일반적인 빵이나 음료부터 가방, 셔츠, 바우처 등 베이커리와 직접적인 연관이 없을 것 같은 물건들이 있습니다.

인기 품목을 살펴보면 모든 시즌에서 커피, 일반 빵, 차, 케이크, 페이스트리가 인기있었습니다. 인기 품목들을 봤을 때 카페처럼 운영되는 베이커리라는 것을 알 수 있었습니다.

비인기 품목은 빵집의 스키마와 관련이 없는 제품들이 다수를 차지했습니다. 치미추리 오일, 꿀, 베이컨, 살라미, 가방 등 종합 마트의 스키마와 가까운 물품들이 많았습니다.

3) 요일별 거래 수

요일별 거래 수는 특수 시즌과 일반 시즌에서 차이가 있었습니다.

특수 시즌에서는 토요일과 금요일에 거래량이 많았고, 일반 시즌에서는 월요일과 일요일에 거래량이 많았습니다.

즉, 특수 시즌은 주말을 준비 & 시작을 하면서 거래량이 많았고, 일반 시즌은 주중을 준비 & 시작하면서 거래량이 많아졌습니다.

이런 결과에 대한 해석을 아래 표에 작성했습니다.

시즌	거래량이 많은 요일	해석
일반	일요일, 월요일	주말 이후 몸과 마음이 모두 피곤해진 월요병... 간단하게 베이커리로 해결
특수	금요일, 토요일	물가가 상승한 특수 시즌은 비싼 외식을 자제하기 위해 주말에 베이커리의 거래량이 많아짐

4) 시간 및 품목별 거래 수

두 시즌 모두 오후 4시부터 거래 수가 급감하는 모습을 보여 영업 시간을 6시 전에 마무리하는 것을 조언할 수 있을 것 같습니다.

오전에는 페이스트리가 인기가 있지만, 오후에는 차와 케이크가 인기가 많았습니다.

오전과 오후에 인기 품목이 다른 이유는 크게 두 가지를 제시할 수 있을 것 같습니다.

인기가 많은 페이스트리는 오전에 다 팔려 재고가 떨어지고 대체품인 차와 케이크의 거래량이 증가할 수 있음
차와 케이크는 오후에 즐기는 디저트일 수 있음

하지만 영국은 early morning tea(기상 직후), breakfast tea(아침 식사), elevens tea(11시), afternoon tea(16시) 등 차문화가 발달했기 때문에 2번 해석은 설득력이 약합니다. 따라서 1번으로 가정을 하고 분석을 진행하겠습니다.

3. 연관분석

본격적인 연관 분석을 하기 전, 거래 1회 당 구매한 평균 품목 수가 2개라는 것을 확인해 사람들이 여러 품목들을 동시에 구매하는 것을 확인했습니다.

연관 분석은 Apriori 알고리즘을 적용해 최소 지지도 0.05, 향상도 최소 역치를 0으로 설정하고 실시했습니다.

최소 지지도 이상을 기록한 빈발항목집단을 탐색한 결과, 특수 시즌에서의 빈발항목의 수는 12개, 일반 시즌에서의 빈발항목 수는 11개로 그 수는 유사했습니다.

두 시즌 모두 일반빵과 커피의 향상도가 0.57로 둘 중 하나를 집으면 다른 하나도 같이 구매할 확률이 감소했습니다. 반면, 케이크 + 커피나 페이스트리 + 커피 등 이름이 있는 빵과 커피는 양의 상관관계를 가지고 있는 것을 확인했습니다.

4. 종합

지금까지 분석 결과를 종합하고 얻은 인사이트는 다음과 같습니다.

판매물품: 베이커리의 정체성에 맞지 않는 메뉴는 비인기 품목이었습니다. 그렇기 때문에 베이커리의 정체성에 맞는 메뉴만 판매해야 합니다.
생산량
- 특수 시즌에는 금~토요일에 집중적으로 생산량을 늘리고, 일반 시즌에는 일~월요일에 생산량을 늘려야 합니다.
- 그리고 인기가 많은 페이스트리의 생산량을 높일 필요가 있습니다.
영업시간
- 출근~점심시간에 판매가 집중되어 있습니다. 그러므로 오전 8시부터 영업을 싲가하고 거래량이 급감하는 16~18시 사이에는 영업을 종료해야 효율적인 영업을 할 수 있습니다.
세트메뉴
- 연관 분석 결과, 커피와 어울리는 베이커리 메뉴가 존재합니다. 그렇기 때문에 베이커리는 커피와 어울리는 디저트 메뉴를 발굴할 필요가 있습니다.
- 그리고 해당 디저트를 먹으러 오는 손님에게 '스페셜 & 커피' 세트를 판매하거나 해당 디저트를 구매하면 커피를 할인해주는 조건부 할인 프로모션을 적용할 수 있습니다.

분석을 진행하면서 느꼈던 한계점은 고객 ID, 가격과 같은 정보가 부족해 깊이 있는 분석을 하지 못했습니다. 이 문제를 해결하기 위해서는 해당 정보들을 포함해 데이터를 수집해야 합니다.

5. 후기

연관 분석이란 개념을 처음 배웠고, 실제로 적용해보면서 실제 데이터에서는 결과들이 깔끔하게 나오지 않는다는 것을 느꼈습니다. 그리고 지지도가 높으면 조건부 할인 프로모션이 유용하고, 향상도가 높으면 세트메뉴를 판매하는 것이 유용하다 등 지지도와 향상도의 수준에 따라 적용할 수 있는 전략이 다르다는 것도 알게 되었습니다.

결정 트리와 부스팅

JOHAWK — Fri, 29 Nov 2024 17:10:36 +0900

이번 시간에는 결정 트리와 부스팅에 대해 알아보겠습니다.

결정 트리와 부스팅

목차
1. 결정트리

2. 부스팅

1) AdaBoost

2) GBM

3) XGBoost

4) LightGBM

1. 결정트리

결정트리는 데이터를 반복적으로 분할하여 결과를 예측하거나 분류하는 트리 형태의 모델입니다.

위 그림은 Iris 데이터에 결정 트리를 적용한 예시이며, 결정 트리에서 자주 사용되는 용어는 아래 표에 작성했습니다.

용어	설명
뿌리 노드(root node)	전체 의사결정나무가 시작되는 마디로, 전체 자료를 포함
부모 노드(parent node)	주어진 마디의 상위에 있으며 자녀 노드를 가지고 있음
자녀 노드(child node)	부모 마디로부터 분리되어 나간 2개 이상의 마디. 자녀 노드는 또 다른 부모 노드가 될 수 있음
리프 노드(leaf node)	더 이상 분할되지 않는 노드. 예측 값을 가지며, 클래스 혹은 회귀값으로 반환
깊이(depth)	뿌리 노드부터 가장 먼 리프 노드까지의 경로에 있는 노드들의 수

결정 트리는 기준에 맞춰 데이터를 분할하기 위해 지니 계수와 엔트로피를 사용합니다. 지니 계수는 한 그룹 안에서 데이터가 얼마나 섞여 있는지를 나타내는 기준으로 아래 수식으로 정의할 수 있습니다. 값이 클수록 불순도(다른 클래스의 데이터가 들어가 있는 정도)가 높아지고 순수도는 낮아집니다. 클래스가 2개일 때 최대 지니 계수는 0.5입니다.

엔트로피도 지니 계수처럼 한 그룹 안에서 데이터가 얼마나 섞여 있는지를 나타내는 기준입니다. 다만, 계산 식에서 로그를 적용해 지니 계수보다 작은 차이를 더 민감하게 반영할 수 있어 데이터 불균형이 심할 때 사용하기 적합합니다. 클래스가 2개일 때 최대 엔트로피 지수는 1.0입니다.

결정트리의 장단점은 아래 표와 같습니다.

구분	설명
장점	- 해석의 용이성: 나무 구조(if-then)에 의해 표현되어 모델을 쉽게 이해할 수 있음 - 주요 변수 파악: 종속 변수를 잘 설명할 수 있는 독립변수 파악 가능 및 분리 기준 제시 - 비모수적 모형: 데이터의 통계적 가정이 필요 없음 - 유연성과 정확도: 수치형 및 범주형 데이터 모두 사용 가능하며, 분류 정확도가 높음
단점	- 많은 데이터, 많은 시간: 좋은 모형을 생성하는데 비교적 많은 데이터와 시간이 소요됨 - 비연속성: 분리 시 연속형 변수를 구간화 처리, 분리 경계점 근처에서 오류 발생 가능성 있음 - 선형 구조에 적합하지 않음

2. 부스팅

부스팅은 앙상블의 한 종류로, depth가 얕은 약학습기(weak learner)들을 순차적으로 결합해 강학습기(strong learner)를 만드는 방법입니다.

약학습기들을 여러 개 만들고 순차적으로 약학습기들을 결합하면서 이전 학습기에서 틀린 부분(개별 데이터 or 손실함수)에 대한 가중치를 크게 만들면서 학습을 유도합니다. 부스팅 기법은 적절히 설정된다면 높은 성능과 더불어 과적합을 방지할 수 있다는 장점이 있습니다.

부스팅의 종류는 매우 다양한데 여기서는 AdaBoost, GBM, XGBoost, LightGBM에 대해 알아보겠습니다.

1) AdaBoost

AdaBoost(Adaptive Boost)는 부스팅 기법의 원조로 약학습기에서 틀렸던 개별 데이터에 가중치를 부여하는 방식으로 부스팅을 진행합니다.

최종 결정을 내릴 때 성능이 좋은 학습기들의 비중을 높이고 그렇지 않은 학습기들의 비중을 낮게 반영해 성능이 가장 높은 예측값을 반환합니다.

AdaBoost의 장단점

구분	설명
장점	- 성능 향상: 약학습기를 결합해 강학습기를 생성 - 간단한 알고리즘: 구현이 쉽고 약학습기를 기반으로 간단하게 작동
단점	- 노이즈에 민감: 이상치나 노이즈에 지나치게 높은 가중치를 부여할 수 있음 - 클래스 불균형에 민감: 소수 클래스에 과도한 가중치가 부여되어 과적합이 발생할 수 있음 - 데이터 크기 제한: 대규모 데이터셋에서는 학습 속도가 느림

2) Gradient Boosting Machine(GBM)

GBM은 손실함수의 경사하강법을 사용해 약학습기를 순차적으로 학습합니다.

GBM은 유연성이 높기 때문에 다양한 손실함수(회귀, 분류 등)을 적용할 수 있습니다.

GBM의 장단점

구분	설명
장점	성능이 우수하며, 다양한 유형의 데이터에 적합
단점	계산 비용이 높고, 학습 시간이 오래 걸릴 수 있음 하이퍼파라미터 튜닝이 까다로움

3) XGBoost

Extreme Gradient Boosting은 GBM의 개선된 버전으로 병렬처리, 가중치 규제 등이 추가되었습니다.

XGB의 장점

구분	설명
장점	빠른 속도와 높은 예측 성능 결측치 자동 처리 및 다양한 커스터마이징 옵션
단점	복잡한 구조로 인해 학습 곡선이 높을 수 있음

4) LightGBM

XGB의 경량화된 버전으로 대용량의 데이터셋과 높은 차원의 데이터에 적합합니다.리프 중심 방식으로 트리를 생성해 효율성을 높였습니다.

LGB의 장단점

구분	설명
장점	매우 빠른 학습 속도와 낮은 메모리 사용량 대규모 데이터셋에 적합
단점	작은 데이터셋에서는 성능이 떨어질 수 있음

이번 시간에는 결정 트리와 부스팅에 대해 알아봤습니다.