BLUEBERRY

RAG 재순위(re-ranking) — cross-encoder로 검색 정밀도를 한 단계 올리기

Aramir — Sun, 17 May 2026 09:17:55 +0900

벡터 검색이 가져온 Top 50을 LLM에 그대로 넘기면 정밀도가 깨집니다. cross-encoder 재순위가 그 50개를 다시 정렬해 Top 5만 LLM에 넘기면 답변 품질이 한 단계 올라갑니다.

RAG 챗봇 답변이 자주 빗나간다면, 모델·프롬프트보다 검색 단계가 약할 가능성이 큽니다. 벡터 검색은 빠르지만 의미 매칭의 정밀도가 부족합니다. cross-encoder 재순위(re-ranking)는 1단계 검색의 Top 50을 다시 정렬해 정말 관련 있는 Top 5를 LLM에 넘깁니다. 한 단계 추가로 답변 품질이 눈에 띄게 올라갑니다.

마케터가 이 글을 읽어야 하는 이유: RAG 챗봇이 운영에 들어가 있다면, 답변 품질의 절반이 검색 단계에서 결정됩니다. 모델 교체보다 비용 효율적인 개선이 재순위 단계 추가입니다. 비용 약간 증가에 정밀도 큰 폭 상승. 사내 챗봇 신뢰도가 흔들리는 자리라면 가장 먼저 시도할 카드입니다.

빠른 1차 검색 + 정밀한 2차 재순위. 비용은 작게, 품질은 크게.

1. 왜 1차 검색만으로 부족한가

벡터 검색(bi-encoder 기반)은 사용자 질문과 문서를 각각 독립적으로 임베딩한 뒤 코사인 유사도로 비교합니다. 이 구조는 빠르지만 한 가지 약점이 있습니다.

질문과 문서가 서로 직접 비교되지 않고, 미리 만든 임베딩으로만 비교된다.

같은 단어라도 문맥이 다르면 의미가 다릅니다. "Meta 캠페인 ROAS"가 페이스북 광고를 의미하는지 메타분석을 의미하는지의 구분이 1차 검색에서는 약합니다. 그래서 Top 5가 깨끗하지 않고 무관한 문서가 자주 섞입니다.

검색 단계	입력	비교 방식	정밀도	속도
1차 (벡터)	질문 임베딩	미리 만든 문서 임베딩과 코사인	중간	매우 빠름
2차 (cross-encoder)	질문 + 문서 쌍	매번 함께 입력해 점수 출력	매우 높음	느림

cross-encoder는 정밀하지만 모든 문서에 적용하면 너무 느립니다. 그래서 1차 검색으로 Top 50을 빠르게 가져온 뒤 그 50개에만 cross-encoder를 적용하는 2단계 흐름이 표준이 되었습니다.

2. Cross-encoder의 한 줄 직관

cross-encoder는 질문과 문서를 한 번에 모델에 넣어 "얼마나 관련 있는가"의 점수를 직접 출력합니다.

입력: [질문] [SEP] [문서] → 출력: 관련도 점수 (0~1)

bi-encoder처럼 임베딩을 미리 만들어 둘 수 없습니다. 매 쿼리마다 50개 문서 각각에 대해 모델 forward를 돌려야 합니다. 그래서 느림. 대신 두 텍스트의 모든 토큰이 attention으로 직접 연결되니 의미 매칭의 정밀도가 폭발적입니다.

수식 직관:

score (q, d) = CrossEncoder ([q; d])

bi-encoder는 $cos (embed (q), embed (d))$ 로 두 임베딩의 코사인을 계산하지만, cross-encoder는 두 텍스트를 함께 모델에 넣어 단일 점수를 출력합니다. 토큰끼리 직접 attention하니 미묘한 문맥 차이를 잡아냅니다.

3. 2단계 검색의 표준 흐름

사용자 질문
    │
    ▼
1차 검색 (bi-encoder + vector DB)
  → Top 50 문서를 매우 빠르게 (수십 ms)
    │
    ▼
2차 재순위 (cross-encoder)
  → Top 50을 정밀 점수로 정렬
  → 상위 Top 5만 살림 (수백 ms)
    │
    ▼
Top 5를 LLM 프롬프트에 컨텍스트로 삽입
    │
    ▼
LLM이 답변 생성

각 단계의 책임이 분명해지고, 시스템 전체의 정밀도가 올라갑니다. 비용은 cross-encoder 50번 호출 = 수백 ms 지연 + 약간의 GPU/API 비용. 품질 개선이 비용을 항상 정당화한다는 게 RAG 운영 표준이 되어가는 이유입니다.

4. 코드 한 묶음 — sentence-transformers cross-encoder

이게 글에 박는 유일한 코드입니다.

from sentence_transformers import CrossEncoder

# 1. cross-encoder 모델 로드 (한 번만)
reranker = CrossEncoder("BAAI/bge-reranker-base")

# 2. 1차 검색 결과 (벡터 DB가 빠르게 가져온 Top 50)
query = "Meta 광고 ROAS 분기별 평균은?"
candidates = [
    "2024 Q3 Meta 광고 ROAS 평균은 4.2였습니다...",
    "메타분석에서 평균 효과크기는 0.35로...",
    "TikTok ROAS는 평균 3.1, Meta는 4.2...",
    # ... 47개 더
]

# 3. cross-encoder로 (질문, 문서) 쌍을 점수화
pairs = [(query, doc) for doc in candidates]
scores = reranker.predict(pairs)
# scores: [0.92, 0.18, 0.85, ...]

# 4. 점수 기준 정렬 후 Top 5만 살림
ranked = sorted(zip(scores, candidates), reverse=True)[:5]
top_5 = [doc for _, doc in ranked]
print(top_5)
# 1차 검색에서 메타분석 문서가 섞여 있었지만 cross-encoder가 점수 0.18로 떨궈냄.

50개 문서에 대해 각각 점수를 계산하니 수백 ms 지연이 추가됩니다. 그러나 잘못 섞여 들어왔던 메타분석 문서가 0.18 점수로 떨어져 Top 5에서 빠지고, 정확한 광고 ROAS 문서들이 살아 LLM 컨텍스트로 들어갑니다.

5. 모델 선택 — 어떤 cross-encoder를 쓸까

모델	크기	한국어 지원	추론 속도
`cross-encoder/ms-marco-MiniLM-L-6-v2`	작음 (22M)	약함	가장 빠름
`cross-encoder/ms-marco-MiniLM-L-12-v2`	중간 (33M)	약함	빠름
`BAAI/bge-reranker-base`	중간 (278M)	강함 (multilingual)	중간
`BAAI/bge-reranker-large`	큼 (560M)	매우 강함	느림
Cohere Rerank API	매니지드	강함	빠름 (클라우드)

한국어 RAG에는 BAAI/bge-reranker-base 이상을 권장합니다. 영어 전용 모델은 한국어 매칭이 약함. 매니지드 솔루션이 필요하면 Cohere Rerank API.

5-1. Cohere Rerank API의 자리

API 호출 한 번으로 100개 문서 재순위. 자체 호스팅 부담 없음. 비용은 1000번 검색당 약 $1-2. 챗봇 검색 트래픽이 일일 수만 건 이하면 합리적.

6. 1차 검색의 K값 — Top 몇 개를 재순위에 넘기나

K (1차 결과 수)	효과	비용
10	정밀도 한도 (재순위가 살릴 수 있는 게 적음)	매우 낮음
50	표준 — 대부분 자리에 적합	적당
100	높은 recall, cross-encoder 100번 호출	높음
200+	거의 모든 후보 검토, 비용 폭발	매우 높음

K=50이 표준이 되어가고 있습니다. 정밀도와 비용의 균형이 가장 좋은 자리. 매우 큰 코퍼스(수백만 문서)에서는 K=100이 안전.

7. 평가 — 재순위가 정말 도움이 됐나

재순위 단계 추가가 의미 있는지 측정하려면 RAG 평가 지표를 함께 봐야 합니다.

7-1. Context Relevance와 Recall

RAG 평가에서 다룬 4가지 지표 중 Context Relevance와 Context Recall이 재순위 효과를 직접 반영합니다. 재순위 ON/OFF를 토글해 같은 골든셋에서 두 지표를 비교.

시나리오	Context Relevance	Context Recall	Faithfulness
재순위 OFF (Top 5 직접)	0.78	0.85	0.81
재순위 ON (Top 50 → Top 5)	0.91	0.88	0.93

Context Relevance가 0.78 → 0.91로 큰 폭 상승. Faithfulness도 0.81 → 0.93. 재순위 단계가 답변 품질 전반에 영향을 미친다는 게 정량적으로 확인됩니다.

7-2. 응답 시간의 트레이드오프

재순위 단계 추가는 약 200-500ms 지연을 만듭니다. 사용자가 인식할 만한 지연이 아니지만 챗봇 응답이 이미 느린 자리(p95 5초+)에서는 추가 부담이 됩니다.

8. 운영 흐름의 안정화

8-1. 캐싱

같은 (질문, 문서) 쌍에 대해 점수를 캐시해두면 반복 질문 시 cross-encoder 호출이 줄어듭니다. 챗봇 트래픽의 20-40%가 같은 질문 패턴이라 캐시 히트율이 높음.

8-2. 배치 처리

cross-encoder는 배치 처리가 강합니다. 50개 쌍을 한 배치로 묶어 한 번에 forward하면 개별 호출보다 5-10배 빠름. PyTorch DataLoader 같은 표준 패턴 활용.

8-3. 모니터링 알림

재순위 점수의 분포를 매주 추적합니다. 갑자기 모든 점수가 낮아지면(예: 평균 0.3 이하) 임베딩 모델·코퍼스 변화 의심.

9. 마치며 — RAG 품질 개선의 가장 비용 효율적인 자리

RAG 챗봇 품질 개선에 큰 비용을 쓰기 전에 cross-encoder 재순위 단계를 한 번 시도해보는 게 가장 비용 효율적인 카드입니다. 모델 교체·프롬프트 튜닝보다 적은 비용으로 Context Relevance·Faithfulness가 큰 폭 상승하는 케이스가 흔합니다. 운영 중인 챗봇이 자주 빗나간다면 이 단계 추가를 분기 로드맵에 박아두세요.

다음 분기에 한 번만 시도해 볼 만한 것은 골든셋 50개에 대해 재순위 ON/OFF 비교를 한 번 돌려 정밀도 차이를 정량화하는 흐름입니다. 차이가 크면 즉시 운영 도입, 작으면 다른 단계로.

다음에 읽을 글

RAG 평가 — 재순위 효과를 측정하는 4가지 지표
임베딩 운영 — 1차 검색 임베딩 모델 관리
RAG 비용·latency — 재순위 추가 시 latency 트레이드오프

참고

"Sentence-BERT" (Reimers & Gurevych, 2019): https://arxiv.org/abs/1908.10084
BAAI BGE Reranker: https://huggingface.co/BAAI/bge-reranker-base
Cohere, "Rerank API": https://docs.cohere.com/docs/rerank
"MS MARCO passage ranking benchmark": https://microsoft.github.io/msmarco/
"Pretrained Transformers for Text Ranking" (Lin et al., 2021): https://arxiv.org/abs/2010.06467

Prophet과 CausalImpact — 시계열 예측과 캠페인 인과 효과

Aramir — Sun, 17 May 2026 09:17:05 +0900

Prophet은 시즌·트렌드를 자동 분리해 예측을 단순화하고, CausalImpact는 그 예측을 baseline으로 캠페인 효과를 추정합니다. 마케팅 자리의 두 도구 결합 사용 패턴.

캠페인 시작 후 매출이 +20% 올랐다면 그게 캠페인 효과인지 시즌·트렌드 효과인지 구분이 어렵습니다. CausalImpact는 캠페인이 없었을 때의 매출 예측(counterfactual)을 baseline으로 잡고, 실제 매출과의 차이를 캠페인 효과로 추정합니다. baseline 예측에 Prophet 같은 state-space 모델이 자주 들어갑니다. 두 도구의 결합이 마케팅 인과 분석의 표준 패턴 중 하나입니다.

마케터가 이 글을 읽어야 하는 이유: 분기 캠페인의 효과를 보고할 때 "전년 동기 대비 +20%"는 시즌·트렌드 효과가 섞여 있어 정직하지 않습니다. CausalImpact가 시즌·트렌드를 분리한 baseline을 만들어주면, 캠페인의 진짜 효과를 회의에서 데이터로 답할 수 있습니다.

baseline = 캠페인이 없었을 때의 예측. 실제와의 차이가 캠페인 효과의 정직한 추정.

1. Prophet의 한 줄 직관

Facebook이 만든 시계열 예측 라이브러리. 매끄러운 트렌드 + 주기적 시즌 + 휴일 효과로 시계열을 분해.

y (t) = g (t) + s (t) + h (t) + ε_{t}

$g (t)$ : 트렌드 (선형 또는 logistic)
$s (t)$ : 시즌 (주기적 푸리에 항)
$h (t)$ : 휴일 효과
$ε_{t}$ : 잔차 노이즈

자동으로 트렌드·시즌·휴일을 분리해 예측. 마케팅 시계열(매출·전환·CTR) 자리에 자연스럽게 적용.

2. CausalImpact의 한 줄 직관

Google이 만든 인과 분석 라이브러리. Bayesian state-space 모델로 처리 전 데이터를 학습한 뒤 처리 후 시점의 baseline을 예측. 실제값과 baseline의 차이가 인과 효과.

처리 후 시점의 "캠페인이 없었다면 어땠을까"를 데이터로 추정.

단계	작업
1. 학습	처리 전 데이터로 baseline 모델 학습
2. 예측	처리 후 baseline 예측 (counterfactual)
3. 차이	실제값 - baseline = 인과 효과
4. 신뢰구간	Bayesian posterior에서 직접

처리 전 충분한 데이터(보통 6주+)가 있으면 정직한 baseline 가능.

3. 두 도구의 결합 — Prophet → CausalImpact 백엔드

CausalImpact의 기본 baseline 모델은 BSTS(Bayesian Structural Time Series). Prophet으로 baseline 예측한 뒤 CausalImpact 식으로 처리 효과 추정하는 패턴이 유연.

처리 전 시계열
     │
     ▼
Prophet (트렌드 + 시즌 분리)
     │
     ▼
처리 후 baseline 예측 (Prophet의 yhat)
     │
     ▼
실제 처리 후 - baseline = 캠페인 효과
     │
     ▼
Bootstrap 95% CI

Prophet의 강점(트렌드·시즌 자동 분리) + CausalImpact의 강점(인과 효과 추정 + 신뢰구간)을 결합.

4. 마케팅 자리의 적용

4-1. 분기 캠페인 효과

분기 시작에 큰 캠페인 시작. 그 시점 이후 매출의 캠페인 기여를 baseline 차이로 추정.

4-2. 신규 광고 채널 도입

새 채널 광고 시작한 시점부터의 매출 lift 추정. 채널 도입이 무작위 배정이 아니라 RDD·DiD 적용 어려움. CausalImpact가 표준.

4-3. 가격 변경의 영향

상품 가격 인상·할인 시작 후 판매량 변화. 자연 실험으로 효과 추정.

4-4. 이벤트·시즌 이상치 탐지

블랙프라이데이 같은 이벤트의 매출 lift를 baseline 대비로 측정.

자리	처리 시점	baseline 데이터
분기 캠페인	캠페인 시작일	처리 전 8-12주
신규 채널	채널 도입일	처리 전 6주+
가격 변경	변경일	처리 전 8주+
이벤트 lift	이벤트일	작년 동기간

5. 코드 한 묶음 — Prophet + CausalImpact

이게 글에 박는 유일한 코드입니다.

Propensity score matching — 무작위 배정이 안 되는 자리에서 인과 효과 추정

Aramir — Sun, 17 May 2026 09:16:15 +0900

광고를 본 사람과 안 본 사람을 그냥 비교하면 자가 선택 편향이 큽니다. PSM은 두 그룹을 비슷한 특성으로 매칭해 비교가 가능한 짝을 만듭니다. 마케팅 자리에 적용하는 PSM 워크플로.

"광고 본 사람들의 구매율 8%, 안 본 사람들 구매율 3% — 광고가 5%p 끌어올렸다." 이 단순 비교의 함정은 분명합니다. 광고를 본 사람들이 원래 더 관심 있었던 사람일 가능성이 큽니다(자가 선택 편향). 무작위 배정 lift 실험을 못 돌리는 자리에서 자주 마주칩니다. propensity score matching(PSM)은 이 편향을 줄여 인과 효과를 추정하는 표준 도구입니다.

마케터가 이 글을 읽어야 하는 이유: 광고 노출과 전환의 단순 비교는 ROAS 보고에 자주 들어가지만 인과 효과는 거의 항상 과대 추정됩니다. PSM의 직관과 한계를 알면, 회의에서 "이 숫자가 인과인가 상관인가"를 정직하게 분리할 수 있습니다.

비슷한 특성을 가진 사람끼리 짝짓고 그 짝의 행동 차이로 인과 효과를 본다.

1. 자가 선택 편향과 PSM의 직관

광고 노출은 무작위가 아닙니다. 플랫폼이 "광고에 반응할 가능성이 높은 사람"에 더 많이 노출시킵니다. 그래서 노출 그룹은 비노출 그룹보다 원래 구매 의향이 높은 사람들로 구성됩니다.

노출 그룹의 구매율 - 비노출 그룹의 구매율 = 광고 효과 + 자가 선택 편향

PSM은 이 편향을 줄이는 한 가지 도구입니다.

노출 그룹의 각 사람마다 "비슷한 특성을 가진" 비노출 그룹 사람을 짝지어, 그 짝끼리만 비교한다.

비슷하다는 기준이 propensity score — "이 사람이 노출될 확률"의 추정치. 같은 propensity score를 가진 두 사람은 노출에 대한 사전 성향이 같으니 비교가 정직합니다.

2. Propensity score의 정의

특정 사람이 노출 그룹에 들어갈 확률을 그 사람의 특성으로 예측한 값.

p (X) = Pr (노출 = 1 ∣ X)

$X$ 는 사용자 특성(연령, 성별, 과거 구매, 페이지 방문 등). 로지스틱 회귀가 표준 추정 모델.

p (X) = \frac{1}{1 + exp ( - β _{0} - β _{1} X _{1} - ... - β _{k} X _{k} )}

이 모델로 모든 사람의 propensity score를 계산. 그 값이 비슷한 노출·비노출 사람을 짝지어 비교.

3. PSM 워크플로 — 5단계

3-1. 1단계: 특성 변수 선택

노출과 결과(전환) 둘 다에 영향을 주는 변수들을 모음. 흔한 자리:

인구통계 — 연령, 성별, 지역
과거 행동 — 방문 빈도, 마지막 구매일, 평균 구매액
사용자 세그먼트 — 신규 vs 기존, 카테고리 선호
디바이스·매체 — 모바일 vs 데스크톱, 유입 채널

이 단계가 가장 중요합니다. 빠뜨린 confounder가 있으면 매칭의 효력이 약해집니다.

3-2. 2단계: propensity score 추정

로지스틱 회귀 또는 GBM으로 노출 여부를 예측하는 모델 학습. 모든 사람의 propensity score 계산.

3-3. 3단계: 매칭

각 노출 그룹 사람마다 propensity score가 비슷한 비노출 사람을 1명(또는 N명) 짝지음. 매칭 알고리즘:

Nearest neighbor — 가장 가까운 1명 매칭
Caliper — score 차이가 임계값 이내인 경우만 매칭
Stratification — score 구간으로 나눠 구간별 비교
Kernel matching — 가중치로 여러 사람을 결합

3-4. 4단계: balance 점검

매칭 후 두 그룹의 특성 분포가 정말 비슷해졌는지 확인. 표준화된 평균 차이(SMD) < 0.1이면 균형 OK.

3-5. 5단계: 효과 추정

매칭된 짝의 결과 차이의 평균이 추정 인과 효과(ATT, Average Treatment effect on the Treated).

ATT = \frac{1}{N _{T}} i : T_{i} = 1 \sum [Y_{i} - Y_{matched (i)}]

단계	도구
1. 변수 선택	도메인 지식 + EDA
2. propensity 추정	로지스틱 회귀
3. 매칭	Nearest neighbor (1:1)
4. balance	SMD, KS 검정
5. 효과	ATT

4. 코드 한 묶음 — Python으로 PSM

이게 글에 박는 유일한 코드입니다.

Prompt caching 운영 경제학 — 같은 프롬프트를 1000번 보낼 때 비용을 90% 줄이는 법

Aramir — Sun, 17 May 2026 09:15:22 +0900

시스템 프롬프트·페르소나·문서가 호출마다 동일하다면 그 부분을 캐시할 수 있습니다. Anthropic·OpenAI의 prompt caching 작동 원리와 마케팅 자동화의 비용을 90% 깎는 운영 패턴.

광고 카피 양산을 LLM에 자동화한 뒤 첫 달 청구서를 받으면 자주 놀랍니다. 같은 페르소나·같은 브랜드 가이드를 매번 보내는데 그 부분이 매번 입력 토큰으로 잡혀 비용을 만듭니다. prompt caching은 이 반복되는 부분을 캐시 영역으로 표시해, 두 번째 호출부터는 그 부분을 캐시 토큰(가격 1/10)으로 처리합니다. 마케팅 자동화의 운영 비용을 90% 가까이 깎을 수 있는 단순하고 강력한 도구입니다.

마케터가 이 글을 읽어야 하는 이유: LLM을 자동화에 끼워 넣을수록 비용은 호출 수 × 입력 토큰으로 빠르게 커집니다. 같은 페르소나를 1000번 보내고 있다면, 그게 1000번의 입력 토큰 비용입니다. caching 한 줄로 999번을 캐시 토큰으로 돌리면 비용이 거의 1/10. 작은 변경 하나로 LLM 자동화의 ROI가 완전히 달라집니다.

반복되는 부분을 캐시로 표시하면 그 부분의 비용이 1/10. 자동화의 운영 경제학이 완전히 달라진다.

1. 왜 비용 90% 절감이 가능한가

LLM API 비용은 일반적으로 입력 토큰 + 출력 토큰의 합으로 청구됩니다. 마케팅 자동화에서는 입력 토큰이 비용의 80% 이상을 차지하는 경우가 흔합니다. 그 입력 토큰의 대부분은 매번 동일한 시스템 프롬프트·페르소나·브랜드 가이드·예시(few-shot)입니다.

호출 영역	토큰 수	매 호출마다 동일?	캐시 가능?
시스템 프롬프트	500	동일	가능
브랜드 페르소나	300	동일	가능
제품 정보	200	동일	가능
Few-shot 예시	1500	동일	가능
사용자 입력	50	매번 다름	불가
출력	200	매번 다름	—

총 입력 2550 토큰 중 캐시 가능 영역이 2500 (98%). 사용자 입력은 50 토큰뿐. caching이 적용되면 첫 호출은 그대로 비용이 들지만, 두 번째 호출부터 2500 토큰 영역이 캐시 히트로 처리되어 1/10 가격이 됩니다.

2. Anthropic·OpenAI의 caching 작동 원리

두 주요 제공사가 caching을 구현하는 방식은 비슷하지만 디테일이 다릅니다.

2-1. Anthropic Claude — 명시적 cache_control

Claude는 messages 안에 cache_control: {"type": "ephemeral"}을 명시적으로 박아 표시합니다. 캐시 경계를 직접 지정합니다.

캐시 영역 표시: 메시지 또는 도구 정의 안에 cache_control 추가
캐시 TTL: 5분(기본) 또는 1시간(프리미엄)
캐시 히트 비용: 입력 토큰의 약 10%
캐시 쓰기 비용: 입력 토큰의 약 125% (첫 호출에서 쓰는 비용)

직관: 첫 호출에서 약간 더 비싸게 캐시를 쓰고, 그 다음부터 1/10 가격으로 읽음. 5분 안에 5번만 같은 캐시를 써도 본전 회수.

2-2. OpenAI — 자동 prefix caching

OpenAI는 명시적 표시 없이 자동으로 prefix를 캐시합니다. 같은 시작 부분을 가진 요청이 들어오면 자동으로 hit.

캐시 표시 불필요
캐시 TTL: 5-10분
캐시 히트 비용: 입력 토큰의 약 50%
캐시 쓰기 비용: 추가 비용 없음

직관: 자동이라 편하지만 캐시 효율은 Claude보다 낮음(50% vs 10%). 대량 자동화에서는 Claude의 명시적 caching이 비용 측면 우위.

항목	Anthropic	OpenAI
표시 방법	명시적 cache_control	자동 prefix
캐시 히트 가격	입력의 10%	입력의 50%
캐시 쓰기 추가 비용	125% (첫 호출)	없음
캐시 TTL	5분 / 1시간	5-10분

3. 캐시 히트율을 높이는 프롬프트 구조 룰

caching은 prefix 매칭이라 프롬프트 구조가 중요합니다.

3-1. 변하지 않는 부분을 앞으로

시스템 프롬프트·페르소나·문서는 messages의 앞쪽에 고정. 사용자 입력은 항상 끝쪽. 같은 시작 부분을 공유하는 호출들이 캐시를 효율적으로 공유합니다.

좋은 구조	나쁜 구조
[시스템] [페르소나] [문서] [사용자 입력]	[사용자 입력] [페르소나] [문서] [시스템]
[시스템] [예시1] [예시2] [사용자 입력]	[사용자 입력] [동적 컨텍스트] [예시]

prefix 한 토큰이 다르면 그 뒤로 캐시 미스. 변하지 않는 부분 앞쪽 배치는 단순하지만 가장 강력한 룰.

3-2. 동적 부분을 한 곳에 모으기

타임스탬프·세션 ID 같은 동적 값을 시스템 프롬프트에 흩뿌리지 마세요. 그 값들 때문에 시스템 프롬프트의 prefix 매칭이 깨집니다. 동적 값은 사용자 메시지 끝쪽으로 모으거나 별도 메타 헤더로 분리.

3-3. Few-shot 예시 순서 고정

같은 작업을 위한 few-shot 예시를 매번 다른 순서로 섞지 마세요. 같은 순서로 고정하면 그 부분이 캐시됩니다. 다양성을 위해 예시를 무작위로 섞고 싶으면 batch 단위로 같은 순서를 유지하고 batch가 끝날 때 새 순서로 갱신하는 패턴.

4. 마케팅 자동화의 캐시 ROI 계산

캐시가 비용에 어떻게 영향을 미치는지 구체적으로 보겠습니다.

4-1. 캐시 없을 때

호출 1회: 입력 2500 토큰 × $3/1 M =$ 0.0075
1000회/일: $7.5/일
한 달: $225

4-2. 캐시 있을 때 (Anthropic 기준)

첫 호출: 2500 × $3/1 M \times 1.25 =$ 0.0094 (캐시 쓰기)
두 번째 호출부터: 2500 × $3/1 M \times 0.10 =$ 0.00075 (캐시 히트)
1000회/일: $0.0094 + (999 \times$ 0.00075) = $0.76/일
한 달: $22.8

월 $225 \to$ 22.8, 약 90% 절감. 자동화 호출 수가 많을수록 절감 효과는 더 큼.

4-3. 손익분기 — 몇 번 호출하면 본전?

첫 호출의 추가 비용( $0.0094 -$ 0.0075 = $0.0019) 이두번째부터의절감 ($ 0.0075 - $0.00075 =$ 0.00675)을 회수하려면 호출 0.3회면 충분. 사실상 즉시 본전. 5분 안에 두 번째 호출이 일어나기만 하면 무조건 이득.

일일 호출 수	월 비용 (캐시 없음)	월 비용 (캐시 있음)	절감
100	$22.5	$2.6	88%
1000	$225	$22.8	90%
10000	$2,250	$228	90%
100000	$22,500	$2,280	90%

자동화 규모가 클수록 절감액이 크고 캐시 ROI가 폭발합니다.

5. 코드 한 묶음 — Anthropic cache_control

이게 글에 박는 유일한 코드입니다. Claude의 명시적 caching 패턴.

Power analysis와 MDE — 실험 시작 전에 표본·기간을 정직하게 잡는 법

Aramir — Sun, 17 May 2026 09:14:39 +0900

A/B 시작 전 "표본 얼마나 모아야?"의 답이 power analysis. 검출력 80%로 검출 가능한 최소 효과(MDE)를 미리 계산해 실험 기간·해석 한도를 명확히 잡는 흐름.

A/B 실험을 시작하기 전 "표본 얼마나 모으면 돼?"라는 질문에 답하지 못하면, 결과 단계에서 "p-value 0.07이라 결론 못 냄"이 흔히 나옵니다. Power analysis는 그 질문에 답하는 표준 도구이고, MDE(Minimum Detectable Effect) 개념이 결정의 핵심입니다. 실험 시작 전 한 번의 계산이 실험 운영의 절반을 정직하게 만듭니다.

마케터가 이 글을 읽어야 하는 이유: 실험 결과 회의에서 "결론 보류"가 자주 나오는 자리는 사실 실험 시작 전의 power analysis 부족이 원인입니다. 검출력·MDE를 미리 계산하면 "이 실험은 +3%p 이상 효과만 검출 가능하다"는 한도를 알고 시작할 수 있습니다.

N이 커질수록 MDE가 작아진다. 그 곡선 위에서 실험 디자인이 결정된다.

1. 4개 변수의 관계

A/B 실험의 통계적 결정은 4개 변수가 서로 묶여 있습니다.

변수	의미
$N$	표본 크기 (그룹당)
$δ$	효과 크기 (MDE)
$α$	양측 유의수준 (보통 0.05)
$1 - β$	검출력 (보통 0.80)

이 4개 중 3개를 정하면 나머지 1개가 결정됩니다.

N과 $α$ , $1 - β$ 를 정하면 → MDE가 결정 (이만큼 작은 효과까지 검출 가능) $δ$ , $α$ , $1 - β$ 를 정하면 → 필요한 N이 결정

마케팅 자리에서 가장 자주 마주치는 건 두 번째 — "이만큼 효과면 의미 있을 것 같으니 표본 얼마나 모을까?".

2. 표본 크기 공식

이항 비율(전환율) 비교의 표준 공식.

N = \frac{( z _{α /2} + z _{β} ) ^{2} \cdot 2 p ( 1 - p )}{δ ^{2}}

$p$ : baseline 전환율
$δ$ : 검출하고자 하는 절대 효과 크기
$z_{α /2} = 1.96$ (양측 5%)
$z_{β} = 0.84$ (검출력 80%)

예시: baseline 전환율 5%, 효과 1%p (5% → 6%) 검출.

$p = 0.055$ , $δ = 0.01$
$N = \frac{( 1.96 + 0.84 ) ^{2} \cdot 2 \cdot 0.055 \cdot 0.945}{0.0 1 ^{2}} \approx 8136$

각 그룹 8,136명, 총 16,272명. 효과 크기를 절반(0.5%p)으로 잡으면 표본은 4배(32,500+).

3. MDE — 표본 거꾸로 풀기

표본이 정해져 있을 때 거꾸로 검출 가능한 최소 효과를 풉니다.

MDE = (z_{α /2} + z_{β}) \cdot \frac{2 p ( 1 - p )}{N}

예시: 그룹당 5,000명, baseline 5%.

MDE $\approx 2.8 \cdot 2 \cdot 0.05 \cdot 0.95/5000 \approx 0.0122$
약 1.22%p

이 실험은 +1.22%p 이상의 효과만 통계적으로 검출. +1%p 효과는 결과 보류 위험.

그룹당 N	MDE (baseline 5%)
1,000	2.7%p
5,000	1.2%p
10,000	0.85%p
50,000	0.38%p

작은 효과를 잡으려면 표본 폭증. 보통 +1%p 이하 효과를 잡으려면 그룹당 1만+ 필수.

4. 코드 한 묶음 — 표본·MDE 계산기

이게 글에 박는 유일한 코드입니다.

Multi-agent orchestration — supervisor·swarm·planner-executor 패턴 비교

Aramir — Sat, 16 May 2026 18:22:40 +0900

한 LLM이 모든 일을 다 하면 결과가 흔들립니다. 여러 에이전트가 역할을 나눠 협업하는 multi-agent orchestration의 3가지 표준 패턴과 마케팅 자동화에 적용하는 자리.

"이 캠페인 분석해서 슬랙으로 공유해줘"라고 한 LLM에 시키면 데이터 조회·분석·작성·전송을 모두 하나의 모델이 합니다. 그런데 작업이 길어질수록 모델이 헷갈리고, 한 단계 실패가 전체를 멈춥니다. multi-agent orchestration은 여러 에이전트가 역할을 나눠 협업하는 구조입니다. 3가지 표준 패턴과 마케팅 자동화에 적용하는 자리를 정리합니다.

마케터가 이 글을 읽어야 하는 이유: LLM 자동화가 한 단계 작업(요약·분류)을 넘어 여러 단계 작업(분석 + 보고 + 전송)으로 가면 단일 모델로는 안정적이지 않습니다. orchestration 패턴을 알면 자동화 설계의 전체 그림이 잡히고, 어느 자리에 어느 패턴이 맞는지가 분명해집니다.

중앙 통제냐 자율 협력이냐, 계획-실행 분리냐 — 자리에 따라 답이 다르다.

1. 단일 에이전트의 한계

단일 LLM에 복잡한 작업을 맡기면 다음 자리에서 깨집니다.

문제	증상
컨텍스트 누적	단계가 길어질수록 토큰 제곱 비용 증가
역할 혼동	분석 중인지 보고 작성 중인지 흐려짐
도구 선택 헷갈림	같은 도구를 반복 호출하거나 잘못된 도구 호출
한 단계 실패가 전체 멈춤	중간에 한 도구가 실패하면 복구 어려움

multi-agent는 이 문제를 "역할 분할"로 풉니다. 데이터 조회 에이전트, 분석 에이전트, 작성 에이전트가 각자 역할만 책임지고 다른 에이전트가 결과를 받아 다음 단계.

2. 패턴 1 — Supervisor (중앙 통제)

가장 직관적인 패턴. 중앙에 supervisor 에이전트가 있고, 그 supervisor가 여러 worker 에이전트에게 작업을 분배합니다.

사용자 요청
     │
     ▼
┌─ Supervisor 에이전트 ─┐
│ "이 작업을 어느 워커에│
│  맡길지 결정"        │
└────┬─────┬─────┬────┘
     │     │     │
     ▼     ▼     ▼
  워커1  워커2  워커3
 (조회) (분석) (작성)
     │     │     │
     └─────┴─────┘
           │
           ▼
      Supervisor에게 결과 반환
           │
           ▼
      사용자에게 답변

2-1. 적합한 자리

작업 단계가 명확히 나뉨 (조회 → 분석 → 작성)
워커들이 서로 독립 (한 워커의 결과가 다른 워커에 강하게 의존하지 않음)
디버깅·모니터링 중요

2-2. 한계

supervisor가 병목이 됨 (모든 결정이 한 곳을 거침)
워커 간 직접 협업 어려움
supervisor 한 번 호출이 비싸 비용 증가

대부분의 실무 자리에서 첫 번째로 시도할 패턴. LangGraph의 supervisor architecture가 이 패턴의 표준 구현.

3. 패턴 2 — Swarm (자율 협력)

supervisor 없이 에이전트들이 서로에게 작업을 직접 패스합니다. handoff 기반 구조.

사용자 → 에이전트 A (분류 담당)
              │
              "이건 데이터 조회야" handoff
              │
              ▼
         에이전트 B (조회 담당)
              │
              "분석이 필요해" handoff
              │
              ▼
         에이전트 C (분석 담당)
              │
              ▼
            사용자

3-1. 적합한 자리

작업 흐름이 동적이고 미리 정해두기 어려움
에이전트들이 자기 영역을 명확히 알고 자율 결정
빠른 반응이 중요

3-2. 한계

디버깅 어려움 (handoff 흐름이 복잡)
무한 loop 위험 (A → B → A → B...)
비용 예측 어려움

OpenAI의 Swarm framework, AutoGen의 GroupChat이 이 패턴의 구현. 마케팅 운영보다는 연구·실험적 자리에 더 자주 등장.

4. 패턴 3 — Planner-Executor

큰 LLM이 계획을 세우고, 작은 LLM이 단계별로 실행합니다. 비용·정확도 둘 다 잡는 하이브리드 패턴.

사용자 요청
     │
     ▼
┌─ Planner (대형 모델, 한 번 호출) ─┐
│ "다음 4단계로 진행:                │
│  1. ROAS 데이터 조회               │
│  2. 변화 추세 분석                 │
│  3. 보고서 초안 작성              │
│  4. 슬랙 전송"                     │
└────────────┬────────────────────┘
             │
             ▼
┌─ Executor (소형 모델, 단계별 호출) ─┐
│ 단계 1 실행 → 결과 저장             │
│ 단계 2 실행 → 결과 저장             │
│ 단계 3 실행 → 결과 저장             │
│ 단계 4 실행 → 완료                  │
└────────────┬────────────────────┘
             │
             ▼
        사용자에게 답변

4-1. 적합한 자리

작업이 중장기적이고 계획이 명확히 잡힘
비용 통제 중요 (큰 모델은 한 번만 호출)
단계별 결과를 사용자에게 점진적 보여주는 UX

4-2. 한계

planner의 잘못된 계획이 전체에 영향
동적 변화(예: 중간에 데이터 부족 발견)에 약함
두 모델 통합 운영 부담

LangChain의 Plan-and-Execute, OpenAI Assistants API의 일부 패턴이 이 구조. 보고서 자동화·다단계 분석 자리에 적합.

5. 코드 한 묶음 — Supervisor 패턴 의사코드

이게 글에 박는 유일한 코드입니다. 마케팅 보고 자동화의 supervisor 흐름.

# 의사코드 — 핵심 흐름만
SUPERVISOR_PROMPT = """다음 워커 중 하나를 선택해 작업을 패스하라:
- data_worker: BigQuery·광고 API 조회
- analysis_worker: 추세·비교 분석
- writer_worker: 보고서 작성
- slack_worker: 슬랙 전송
- finish: 작업 완료"""

def supervisor_step(messages):
    resp = call_llm("gpt-5", messages=messages,
                    system=SUPERVISOR_PROMPT,
                    response_format={"next": str, "task": str})
    return resp["next"], resp["task"]

WORKERS = {
    "data_worker": call_data_worker,
    "analysis_worker": call_analysis_worker,
    "writer_worker": call_writer_worker,
    "slack_worker": call_slack_worker,
}

def run_workflow(user_request, max_steps=10):
    messages = [{"role": "user", "content": user_request}]
    for step in range(max_steps):
        next_worker, task = supervisor_step(messages)
        if next_worker == "finish":
            break
        result = WORKERS[next_worker](task)
        messages.append({"role": "tool", "name": next_worker,
                         "content": result})
    return messages

supervisor가 매 단계마다 다음 워커를 결정하고, 워커가 작업을 실행해 결과를 messages에 추가. 무한 loop 방지 위한 max_steps 필수.

6. 패턴 선택 결정 트리

자리	작업 단계	흐름	패턴
FAQ 챗봇	1-2단계	단순	단일 에이전트
데이터 조회+답변	2-4단계	정해짐	Supervisor
일일 보고 자동화	4-6단계	정해짐	Planner-Executor
사용자 의도에 따라 분기	동적	가변	Supervisor 또는 Swarm
연구·실험	매우 동적	예측 어려움	Swarm

대부분의 마케팅 자동화는 Supervisor 또는 Planner-Executor가 적합. Swarm은 운영 안정성이 약해 일반 자리에 부적합.

7. 운영 안정성 — multi-agent의 함정

7-1. 무한 loop

에이전트 간 handoff가 순환할 위험. max_steps·max_handoffs 상한 필수. 보통 10-15 단계 이내로 제한.

7-2. 컨텍스트 누적

각 에이전트가 이전 단계의 모든 컨텍스트를 받으면 토큰이 폭발. 결과 요약·관련 정보만 다음 에이전트에 전달하는 컨텍스트 다이어트.

7-3. 비용 폭주

각 에이전트 호출이 별도 LLM 호출이라 단일 에이전트보다 비용이 5-10배. caching·작은 모델 활용으로 보완. LLM token economics 참고.

7-4. 디버깅 어려움

어느 에이전트에서 깨졌는지 추적이 어려움. 단계별 로그·trace ID 필수. LangSmith·Langfuse 같은 도구 활용.

8. 마케팅 자동화의 적용 자리 4가지

8-1. 일일 캠페인 보고 자동화

조회(BigQuery) → 분석(이상치 탐지) → 작성(자유 산문) → 전송(Slack). Planner-Executor 패턴이 자연스럽게 맞음.

8-2. 사용자 의도 라우팅 챗봇

분류(FAQ vs 데이터 조회 vs 액션) → 적합한 워커로 라우팅. Supervisor 패턴.

8-3. 콘텐츠 작성 + 검수

작성 에이전트 → 검수 에이전트 → 수정 에이전트의 파이프라인. Planner가 큰 흐름 잡고 Executor들이 실행.

8-4. 실시간 알림 분석

이상치 감지 → 원인 분석 → 알림 전송. Supervisor가 단계 결정.

9. 마치며 — 자동화 설계의 한 단계 위

LLM 자동화가 단순 작업을 넘어 운영의 표준 도구로 자리 잡을수록 multi-agent orchestration이 자연스럽게 들어옵니다. supervisor·swarm·planner-executor 3가지 패턴 중 자리에 맞는 한 가지를 골라 도입하면 단일 에이전트의 한계를 넘어설 수 있습니다. 다만 비용·디버깅·loop 방지 같은 운영 안정성 항목을 미리 챙겨야 합니다.

다음 분기에 한 번만 시도해 볼 만한 것은 가장 자주 돌리는 단일 에이전트 자동화 한 자리에 supervisor 패턴을 도입해 단계별 디버깅이 쉬워지는지 비교하는 흐름입니다. 작은 자리부터 도입해 운영 감각을 쌓는 게 표준 경로입니다.

다음에 읽을 글

Function calling 설계 패턴 — multi-agent의 기반 도구 호출
LLM 에이전트 평가 — multi-agent 시스템 평가 프레임워크
LLM token economics — multi-agent의 단위 경제학

참고

LangGraph, "Multi-agent supervisor": https://langchain-ai.github.io/langgraph/tutorials/multi_agent/agent_supervisor/
OpenAI, "Swarm framework": https://github.com/openai/swarm
Microsoft AutoGen: https://microsoft.github.io/autogen/
"Plan-and-Execute" (LangChain): https://blog.langchain.dev/planning-agents/
"ReAct" (Yao et al., 2022): https://arxiv.org/abs/2210.03629

Marketing analytics maturity model — last-click부터 triangulation까지 5단계

Aramir — Sat, 16 May 2026 18:21:49 +0900

마케팅 측정의 성숙도는 5단계로 나뉩니다. last-click → multi-touch → MMM → lift study → triangulation. 우리 팀이 어디 있는지 진단하고 다음 단계 로드맵을 잡는 한 가지 모델.

"우리는 어떤 측정을 쓰고 있는가?" 라는 질문에 답하는 5단계 모델이 있습니다. 1단계 last-click부터 5단계 triangulation까지. 우리 팀이 어디 있는지 진단하면 다음 분기 로드맵이 자연스럽게 나옵니다. 단계를 건너뛸 수 없고, 한 단계 위로 올라가는 데 보통 1-2분기가 걸립니다.

마케터가 이 글을 읽어야 하는 이유: 측정 도구를 한 번 도입하기는 쉬워도 운영 표준으로 정착시키는 게 어렵습니다. 5단계 모델로 우리 팀의 현재 위치를 객관화하면 다음 단계 투자 우선순위가 명확해지고, 분기 보고에서 "우리는 지금 3단계, 다음 분기 4단계 진입"이라는 구체적 답을 할 수 있습니다.

단계는 누적된다. 위 단계는 아래 단계를 대체하지 않고 보완한다.

1. 1단계 — Last-click 어트리뷰션

가장 단순한 출발점. 전환 직전 마지막 클릭에 100% 공을 줌.

항목	설명
측정 단위	채널·캠페인
데이터	광고 플랫폼 보고서
운영 부담	거의 없음
함정	검색에 과대 평가, 디스플레이·브랜드 광고 과소

대부분의 회사 출발점. 광고 플랫폼이 자동으로 제공하는 보고서가 그대로 last-click. 분기 ROAS 보고가 이 단계에 머물면 채널 간 의사결정이 왜곡.

2. 2단계 — Multi-touch attribution (MTA)

여러 터치포인트에 공을 분배. 데이터 기반(linear, time-decay) 또는 모델 기반(Shapley, Markov).

항목	설명
측정 단위	채널·캠페인·터치포인트 시퀀스
데이터	1st-party 사용자 시퀀스
운영 부담	중간 (CDP·cross-device 연결 필요)
함정	쿠키·ATT 한계로 정확도 저하

last-click의 단순성을 넘지만 사용자 시퀀스 데이터가 정확해야 함. iOS ATT·쿠키 종료로 MTA의 정확도가 점점 어려워지는 자리. Shapley value, Bayesian attribution 같은 도구가 표준.

3. 3단계 — MMM (Marketing Mix Model)

채널별 시계열 회귀로 광고비와 매출의 관계 모델링. 채널 기여도 추정.

항목	설명
측정 단위	채널·시기
데이터	주 단위 광고비·매출, 외생 변수
운영 부담	큼 (분석가·인프라 필요)
강점	cookieless, 장기 효과

MMM 입문, adstock 심화, saturation, 예산 재배분에서 다룬 도구들. PyMC-Marketing·Robyn 같은 오픈소스로 진입 장벽이 내려가고 있음.

4. 4단계 — Lift study (incrementality)

무작위 배정 + holdout으로 광고의 인과 효과 측정.

항목	설명
측정 단위	캠페인·채널
데이터	노출/비노출 그룹 비교
운영 부담	중간 (lift study 도구 사용)
강점	인과 효과 직접 측정

Brand lift study, Geo-lift, Incrementality 테스트에서 다룬 도구들. Meta·Google이 자체 lift 도구 제공하지만 외부 검증도 가능.

5. 5단계 — Triangulation

last-click + MTA + MMM + lift study를 모두 운영하면서 결과를 교차 검증. 한 도구의 한계를 다른 도구로 보완.

도구	강점	약점
Last-click	빠름·간단	채널 왜곡
MTA	사용자 시퀀스	privacy 한계
MMM	cookieless·장기	단기 캠페인 약함
Lift	인과 직접 측정	비용·기간

triangulation의 핵심 룰: 세 도구의 결과가 서로 일관되어야 신뢰. MMM이 채널 X의 ROAS 4.0이라 하고 lift study가 ROAS 2.5라면 둘 중 하나(또는 둘 다)가 틀림. 그 차이를 분석하는 게 triangulation의 실무.

MTA·MMM·Lift 비교에서 더 깊이 다룹니다.

6. 단계 진단 — 우리 팀은 어디?

다음 5질문에 답하면 현재 단계가 거의 정해집니다.

ROAS 보고서가 광고 플랫폼 자체 ROAS만으로 채워지는가?
사용자 시퀀스 데이터(노출 → 클릭 → 구매)가 1st-party로 통합되어 있는가?
MMM 분기 결과가 예산 재배분 회의에 들어가는가?
lift study가 분기 1회 이상 돌아가는가?
세 도구의 결과를 한 슬라이드에 두고 비교하는가?

질문	답
1만 yes	1단계
1+2 yes	2단계
1+2+3 yes	3단계
1+2+3+4 yes	4단계
1+2+3+4+5 yes	5단계

대부분의 팀이 2-3단계. 4단계 이상은 큰 회사·인프라 갖춘 자리. 단계 건너뛰기 어려움.

7. 단계 이동의 운영 부담

각 단계 진입에 드는 분기 단위 부담.

단계 →	인력	도구·인프라	시간
1 → 2	분석가 0.5명	CDP, GA4	1-2분기
2 → 3	분석가 1명	PyMC-Marketing, BigQuery	2-3분기
3 → 4	분석가·운영 1명	Lift study 도구	1-2분기
4 → 5	분석가 2명+	통합 대시보드	2-4분기

5단계 진입은 인력·인프라 모두 큰 투자. 회사 규모·마케팅 예산이 어느 정도 임계 이상일 때 의미 있음.

8. 코드 한 묶음 — triangulation 한 슬라이드 표

이게 글에 박는 유일한 코드입니다. 5단계 triangulation 표를 자동으로 생성.

Lookalike audience 운영 — 시드 품질·확장 비율·평가 사이클

Aramir — Sat, 16 May 2026 18:21:02 +0900

Lookalike audience(LAL)는 고가치 시드 사용자와 비슷한 잠재 고객을 광고 플랫폼이 찾아주는 기능입니다. 시드 한 줄로 효율이 두 배 차이 나는 LAL 운영의 표준 룰.

"고가치 고객 1만 명 명단을 Meta에 업로드하면 비슷한 사람을 1000만 명까지 찾아준다." Lookalike audience(LAL)의 마케팅 마법입니다. 그런데 시드 명단 한 줄을 잘못 잡으면 같은 1000만 명이라도 효율이 두 배 차이 납니다. 시드 품질·확장 비율·평가 사이클의 표준 룰을 정리합니다.

마케터가 이 글을 읽어야 하는 이유: LAL은 1st-party 데이터를 광고 플랫폼에 활용하는 표준 도구이고, ROAS 개선에 강력한 카드입니다. 하지만 시드 잘못 잡거나 확장 비율 잘못 정하면 효율이 무너집니다. 시드 5가지·확장 룰·평가 표가 분기 운영의 기준이 됩니다.

시드와 가까울수록 정밀, 멀어질수록 reach 큼 — 그 균형이 LAL 운영의 핵심.

1. LAL의 한 줄 직관

시드(고가치 고객) 사용자의 행동 패턴을 광고 플랫폼이 학습해, 그와 비슷한 잠재 고객을 찾아준다.

플랫폼별 부르는 이름:

플랫폼	명칭
Meta	Lookalike Audience
Google	Similar Audience (deprecated) → Optimized Targeting
TikTok	Lookalike
Naver	유사타겟
Kakao	유사타겟

작동 원리는 비슷합니다. 시드 사용자의 행동·인구통계·관심사 패턴 → 비슷한 사용자 풀 추정 → 광고 노출.

2. 시드 품질이 결정하는 5가지 요소

같은 1000만 명 LAL이라도 시드 한 줄로 효율이 결정됩니다.

2-1. 시드 크기

1,000명 미만: 패턴 추출 어려움, LAL 효율 낮음
1,000-5,000명: 마지노선
5,000-50,000명: 표준
50,000+: 상위 효율, 확장 가능 사용자 풀 큼

플랫폼별 권장 최소: Meta 100, Google 1,000, TikTok 1,000. 권장 최소 미달 시 LAL 비활성화.

2-2. 시드 동질성

시드가 한 가지 행동·세그먼트로 깨끗할수록 LAL 정밀도 상승. "전체 구매자" 시드보다 "Q1 카테고리 A 구매자" 시드가 더 정밀.

2-3. 시드 가치

시드 사용자의 평균 가치가 높을수록 LAL이 찾는 잠재 고객 가치도 높음. LTV 상위 10% 시드 vs 전체 구매자 시드의 효율 차이가 큼.

2-4. 시드 최신성

오래된 시드(2년 전 구매자)는 행동 패턴이 시장과 어긋남. 최근 90일 내 구매자가 표준.

2-5. 시드 매칭률

플랫폼이 시드를 자기 사용자와 매칭한 비율. Meta EMQ·Google match rate가 60%+ 권장. 매칭률 낮으면 시드 패턴 추출 한계.

시드 품질 변수	추천
크기	5,000+
동질성	단일 세그먼트
가치	LTV 상위 10-20%
최신성	90일 내
매칭률	60%+

3. 확장 비율의 트레이드오프

LAL 확장 비율(plataform별 1-10%)이 정밀도와 reach의 트레이드오프를 만듭니다.

3-1. 1% LAL — 시드와 가장 비슷

EU 4억 인구 중 1% = 400만. 시드와 행동 패턴이 가장 비슷, ROAS 가장 높음. reach 작아 광고 빈도가 빠르게 올라감(피로 위험).

3-2. 5% LAL — 표준

시드와 어느 정도 비슷, reach 충분. 대부분의 캠페인에 적합.

3-3. 10% LAL — 가장 넓음

시드와 가까운 정도가 약함, reach 가장 큼. 브랜드 인지·신규 도달 캠페인에 적합.

확장 비율	reach	정밀도	적합 캠페인
1%	작음	매우 높음	직접 반응, ROAS 우선
3-5%	중간	높음	표준
7-10%	큼	중간	브랜드 인지, 신규 도달

3-4. 다중 확장 비율 동시 운영

1%, 3%, 7% LAL을 모두 만들고 광고 그룹 분리. 1%에 우선 노출, 소진되면 3%, 그 다음 7%. ROAS 우선순위 자동화.

4. 평가 사이클 — 분기 1회 LAL 효율 점검

4-1. LAL vs control 효과 비교

LAL 노출 vs 일반 타겟팅 노출의 ROAS·CPA 비교. 분기에 한 번 lift study로 검증.

4-2. 시드 갱신 주기

시드는 살아있는 데이터. 분기마다 갱신해 최신 90일 구매자로 업데이트. 갱신 안 하면 시드가 노화.

4-3. 확장 비율별 효율

1% vs 5% vs 10% LAL의 ROAS·CPA·CTR을 표로. 어느 비율이 가장 효율 좋은지 분기마다 확인.

4-4. 시드 카테고리별 효율

여러 시드(VIP·구매자·신규)별 LAL 효율 비교. 어느 시드가 가장 효율 좋은지.

평가 항목	점검 빈도
LAL vs control	분기 1회 (lift study)
시드 갱신	분기 1회 (자동화)
확장 비율별	분기 1회
시드별 효율	분기 1회

5. 코드 한 묶음 — Python 시드 생성 자동화

이게 글에 박는 유일한 코드입니다.

LLM token economics — 자동화의 단위 경제학을 분기 보고로 끌고 가기

Aramir — Sat, 16 May 2026 18:20:07 +0900

LLM 자동화의 비용은 호출 수 × 입력 토큰 × 단가로 빠르게 커집니다. 호출별 비용·일일 합계·모델별 단위 경제학을 분기 보고에 박는 한 가지 표 양식.

LLM 자동화 한 자리에 비용이 매월 얼마나 드는지 즉답할 수 있나요? 첫 청구서를 받기 전까지는 의외로 어렵습니다. 호출 수 × 입력 토큰 × 단가가 각각 어떻게 움직이는지 모르고 자동화를 운영하면, 분기 마감일에 "이번 분기 LLM 비용이 예상보다 3배"라는 숫자만 받게 됩니다. 이 글은 그 숫자를 분기 보고로 끌고 가는 단위 경제학 한 묶음을 정리합니다.

마케터가 이 글을 읽어야 하는 이유: LLM 자동화는 ROI가 큰 만큼 비용도 빠르게 커집니다. 호출당 비용·일일 합계·모델별 단가 차이를 미리 알면 분기 예산 결정이 정확해지고, 어느 자동화에 어느 모델을 쓸지 결정할 때 데이터가 따라옵니다. 비용 청구서가 통제 안에 들어와야 LLM 자동화가 운영의 표준 도구가 됩니다.

자동화 한 자리의 비용은 입력·출력·캐시·모델 4가지 변수로 거의 결정된다.

1. LLM 비용의 4개 변수

LLM API 비용은 단순한 공식으로 계산됩니다.

Cost = calls \sum (T_{in} \cdot p_{in} + T_{out} \cdot p_{out} - T_{cache} \cdot p_{cache discount})

$T_{in}$ : 호출당 입력 토큰
$T_{out}$ : 호출당 출력 토큰
$T_{cache}$ : 호출당 캐시 히트 토큰
$p$ : 토큰당 단가 (모델·종류별 다름)

이 4개 변수가 자동화 한 자리의 매월 비용을 거의 결정합니다.

2. 모델별 단가 — 자릿수 차이

2026년 기준 주요 모델 단가(1M 토큰당, USD).

모델	입력	출력	캐시 히트	추론(thinking)
GPT-5	$5	$15	$2.5	$15
GPT-5-mini	$0.50	$1.50	$0.25	—
Claude Opus 4.7	$15	$75	$1.5	—
Claude Sonnet 4.6	$3	$15	$0.30	—
Claude Haiku 4.5	$0.80	$4	$0.08	—
Gemini 2.5 Pro	$1.25	$5	$0.31	—
Gemini 2.5 Flash	$0.30	$2.50	$0.075	—

같은 작업이라도 모델 선택만으로 비용이 10-30배 차이. 입력 토큰이 많은 자리(긴 컨텍스트)는 입력 단가, 출력이 긴 자리(보고서 생성)는 출력 단가가 핵심.

3. 호출당 비용 계산 — 한 자동화의 단위 경제학

캠페인 분류 자동화를 예로 들겠습니다.

항목	값
시스템 프롬프트	500 토큰
Few-shot 예시	1500 토큰
사용자 입력	100 토큰
출력	200 토큰
일일 호출	1000회

3-1. GPT-5 사용 시

호출당 비용:

입력: $(500 + 1500 + 100) / 1\text{M} \times \$ 5 = $0.0105$
출력: $200 / 1\text{M} \times \$ 15 = $0.003$
호출당: $\$ 0.0135$

일일 1000회: $\$ 13.5 $. 한달 :$ $405$.

3-2. GPT-5-mini 사용 시

호출당:

입력: $2100 / 1\text{M} \times \$ 0.50 = $0.00105$
출력: $200 / 1\text{M} \times \$ 1.50 = $0.0003$
호출당: $\$ 0.00135$

일일 1000회: $\$ 1.35 $. 한달 :$ $40.5$. GPT-5의 1/10.

3-3. Caching 적용 GPT-5

Prompt caching을 적용하면 시스템 프롬프트·few-shot이 캐시 히트:

입력 (캐시 안 됨): $100 / 1\text{M} \times \$ 5 = $0.0005$
입력 (캐시 히트): $2000 / 1\text{M} \times \$ 2.5 = $0.005$
출력: $\$ 0.003$
호출당: $\$ 0.0085$ (37% 절감)

옵션	호출당	일일 1000회	월 비용
GPT-5 (no cache)	$0.0135	$13.5	$405
GPT-5 + caching	$0.0085	$8.5	$255
GPT-5-mini	$0.00135	$1.35	$40.5
GPT-5-mini + caching	$0.001	$1.0	$30

같은 작업에 모델·캐싱 조합으로 월 $30-405. 13배 차이.

4. 코드 한 묶음 — 호출별 비용 추적

이게 글에 박는 유일한 코드입니다.

Heterogeneous treatment effects — 평균 효과 너머의 개인별 효과

Aramir — Sat, 16 May 2026 18:19:27 +0900

A/B 평균 효과 +5%p가 모든 사람에게 같지 않습니다. 일부에게는 +20%p, 일부에게는 -3%p. CATE·uplift forest로 효과의 이질성을 추정해 타겟 마케팅을 정밀화하는 흐름.

A/B 결과 "B안이 평균 +5%p 효과"라는 한 줄은 사실 평균값입니다. 어떤 사용자에게는 +20%p, 어떤 사용자에게는 -3%p일 수 있습니다. 평균만으로 결정하면 효과 큰 사용자에 못 집중하고, 효과 음수인 사용자도 똑같이 처리합니다. CATE(Conditional Average Treatment Effect)·uplift forest는 이 이질성을 추정해 정밀한 타겟팅을 가능하게 합니다.

마케터가 이 글을 읽어야 하는 이유: 같은 캠페인을 모든 사용자에게 동일하게 노출하는 시대는 지나갑니다. 효과가 큰 세그먼트에 집중하고 효과 없는 세그먼트는 제외하는 정밀 타겟팅이 ROAS의 다음 도약 자리. CATE 추정은 그 결정의 데이터 기반.

평균은 한 숫자, 실제는 분포. 그 분포를 보면 타겟팅이 달라진다.

1. ATE에서 CATE로

평균 처리 효과(ATE):

τ_{ATE} = E [Y (1) - Y (0)]

전체 사용자에 평균한 효과. A/B 결과 "+5%p"가 이 값.

조건부 평균 처리 효과(CATE):

τ_{CATE} (x) = E [Y (1) - Y (0) ∣ X = x]

특정 특성 $X$ 를 가진 사용자에게의 효과. 사용자별·세그먼트별로 다른 값.

사용자 X	CATE
신규, 모바일, 20대	+20%p
기존, 데스크톱, 40대	+2%p
VIP, 카테고리 A 선호	+12%p
비활성, 마지막 구매 90일+	-3%p

ATE 평균 +5%p는 이 분포의 평균에 불과. 분포를 보면 타겟팅 결정이 완전히 달라집니다.

2. Uplift modeling — CATE의 마케팅 언어

마케팅 자리에서 CATE를 부르는 더 흔한 단어가 uplift입니다.

처리 받았을 때의 결과 - 처리 안 받았을 때의 결과 = uplift

사용자 유형	uplift	마케팅 의미
Persuadables	+	광고로 설득 가능 — 타겟 1순위
Sure things	0	어차피 살 사람 — 광고 낭비
Lost causes	0	어차피 안 살 사람 — 광고 낭비
Sleeping dogs	-	광고가 오히려 역효과 — 광고 제외

마케팅 ROI의 핵심은 Persuadables를 찾고 Sleeping dogs를 제외하는 것. 평균 효과만 보면 둘이 섞여 결과가 흐려집니다.

3. CATE 추정 방법 3가지

3-1. Meta-learners (S/T/X-learner)

처리·비처리 별도 모델 학습 후 조합.

S-learner: 처리 인디케이터를 feature로 단일 모델
T-learner: 처리·비처리 두 모델 별도 학습
X-learner: T-learner + 매칭으로 보정

가장 단순. sklearn 모델로 직접 구현 가능.

3-2. Causal Forest

Random Forest의 인과 추론 버전. 트리 분할 기준이 "효과가 가장 다른 자리"가 되도록 학습. CATE를 노드 단위로 추정.

3-3. Uplift Tree (Klassifier)

Two-step: (1) outcome 예측 (2) 그 예측 차이로 uplift 정렬. 단순하고 해석 가능.

방법	강점	약점
Meta-learner	단순, sklearn 호환	큰 모델 비용
Causal Forest	비선형 자동 잡음	학습 느림
Uplift Tree	해석 쉬움	정밀도 낮음

4. 코드 한 묶음 — EconML CausalForest

이게 글에 박는 유일한 코드입니다.

Function calling 설계 패턴 — LLM이 도구를 부를 때 마케터가 점검할 것

Aramir — Sat, 16 May 2026 18:17:33 +0900

LLM이 광고 API·BigQuery·Slack을 직접 부르기 시작하면, 답변 품질보다 "어느 도구를 언제 부를지"가 운영 사고의 진앙이 됩니다. function calling의 한 줄 직관과 마케터가 점검할 5가지.

"이 캠페인 ROAS 보여줘"라고 묻자 챗봇이 BigQuery에 SQL을 던져 결과를 돌려줍니다. 마케터 입장에서는 마법 같은 일인데, 그 "마법"의 정체가 function calling입니다. 모델이 직접 데이터를 가져오는 게 아니라, 어느 도구를 어떤 인수로 부를지를 결정해 시스템에 넘기는 한 가지 능력입니다. 이 글은 function calling이 어떻게 동작하고, 운영에서 깨지는 자리, 그리고 마케터가 직접 점검할 5가지 체크포인트를 정리합니다.

마케터가 이 글을 읽어야 하는 이유: LLM 챗봇·에이전트가 사내 데이터에 직접 접근하기 시작하면, "답변이 맞다"보다 "어느 도구를 언제 불렀나"가 운영 사고의 1순위가 됩니다. 잘못된 도구를 부르면 잘못된 데이터로 답하고, 잘못된 인수를 넘기면 다른 캠페인의 데이터가 나옵니다. function calling의 작동 원리를 이해하면 이 사고들을 사전에 막을 수 있습니다.

모델이 답을 만드는 게 아니라, 어느 도구를 어떤 인수로 부를지를 결정한다 — 이게 function calling의 본질.

1. Function calling의 한 줄 직관

전통적 LLM은 한 가지만 합니다 — 토큰 시퀀스 받아 다음 토큰 예측. 이 모델에 외부 도구를 붙이는 표준 방식이 function calling입니다.

모델이 답을 만드는 대신, "어느 도구를 어떤 인수로 부르라"는 구조화된 지시를 출력한다. 실제 실행은 호스트 시스템이 한다.

작동 흐름을 4단계로 쪼개면:

의도 파악 — 사용자 질문 의미 해석 ("이 캠페인 ROAS 알려줘" → 데이터 조회 의도)
도구 선택 — 등록된 도구 목록 중 적합한 것 결정 (get_campaign_roas)
인수 추출 — 함수 시그니처에 맞춰 JSON 인수 생성 ({"campaign_id": "M2026Q2-display"})
응답 통합 — 호스트가 실행한 결과를 받아 자연어로 답변 합성

각 단계가 모두 모델 출력에서 나옵니다. 의도 파악과 인수 추출은 attention이 텍스트를 풀어가는 과정이고, 도구 선택은 등록된 함수 schema와의 매칭입니다. 잘 이해하면 LLM이 마케팅 데이터·SaaS API·내부 시스템을 자연어로 조작할 수 있는 인터페이스가 됩니다.

2. 마케팅 자리에 흔한 5가지 도구

function calling은 추상적 기술이 아니라 마케팅 운영의 구체적 자리에 들어옵니다. 자주 등장하는 도구 패턴은 다음 5가지입니다.

도구 카테고리	예시	위험 자리
데이터 조회	`get_campaign_roas`, `query_bigquery`	잘못된 캠페인 ID·기간 추출
보고 생성	`generate_weekly_report`, `export_to_pdf`	형식 일관성·접근권한
액션 실행	`pause_campaign`, `update_budget`	의도 오해석으로 운영 중 캠페인 정지
외부 검색	`search_competitor`, `lookup_creative_db`	외부 API rate limit·환각
사내 알림	`send_slack`, `notify_oncall`	잘못된 채널·잘못된 사람 멘션

위험 자리에 공통으로 들어가는 단어가 "잘못된"입니다. 모델이 의도를 잘못 해석하거나 인수를 잘못 추출하면, 자연어 인터페이스의 편의가 그대로 운영 사고로 연결됩니다.

3. 도구 schema 설계의 작은 디테일

모델이 도구를 잘 부르려면 함수 schema가 잘 쓰여 있어야 합니다. 같은 도구라도 schema 한 줄 차이로 호출 정확도가 크게 달라집니다.

3-1. 이름이 의도를 담아야 한다

get_data 같은 모호한 이름은 모델이 어느 자리에 부를지 헷갈립니다. get_campaign_roas_by_id처럼 입력·출력·범위가 한 번에 보이는 이름이 호출 정확도가 높습니다.

3-2. description은 "언제 부르는가"를 명시

좋은 description은 함수가 무엇을 하는지가 아니라 언제 부르고 언제 안 부르는지를 적습니다. "분기·월·주 단위 캠페인 ROAS를 조회. campaign_id가 명확할 때만 사용. 캠페인 이름으로 조회해야 한다면 lookup_campaign_by_name을 먼저 부를 것"처럼 호출 조건과 선후 관계가 들어가야 모델이 도구 선택에서 헤매지 않습니다.

3-3. 인수에 enum과 default를 적극 사용

enum이 있으면 모델은 그 값들 중 하나만 선택하므로 임의 문자열로 인한 오류가 사라집니다. 예를 들어 기간 인수가 ["last_week", "last_month", "last_quarter", "ytd"] 네 값 중 하나로 제한되면, 사용자가 "지난 분기"라고 말했을 때 모델이 last_quarter로 정확히 매핑합니다. 자유 문자열로 두면 Q1 2025Q1 1분기 같은 다양한 표기로 깨집니다. default까지 있으면 사용자가 기간을 명시하지 않을 때 모델이 추측하지 않고 안전한 기본값을 씁니다.

4. 의도 오해석이 일어나는 자리

function calling의 사고 대부분은 모델이 도구를 "부른다 vs 안 부른다"의 경계에서 일어납니다.

4-1. 부를 도구가 없는데 억지로 부르는 케이스

사용자가 "지난 분기 분위기 어땠어?"처럼 모호한 질문을 하면, 모델이 적절한 도구가 없는데도 get_campaign_roas 같은 가까운 도구를 일단 호출합니다. 결과는 잘못된 컨텍스트를 깔고 환각이 시작됩니다. 방어책은 시스템 프롬프트에 "확신이 없으면 도구를 부르지 말고 사용자에게 명확화 질문을 하라"는 룰 명시입니다.

4-2. 도구는 맞는데 인수가 틀린 케이스

"이번 분기 ROAS"라고 했을 때 모델이 period: "last_quarter"로 부를지 period: "ytd"로 부를지 헷갈립니다. enum 값에 대한 description("이번 분기는 last_quarter 아님, 현재 진행 중 분기는 별도 도구 사용")을 붙이면 줄어듭니다.

4-3. 도구를 안 불러야 하는데 부르는 케이스

"우리 캠페인 ROAS는 보통 어느 정도가 좋아?"는 일반론 질문입니다. 도구를 부르지 않고 일반 답변을 해야 하는데, 모델이 "이 회사 데이터를 봐야 한다"고 오해하고 도구를 호출합니다. 시스템 프롬프트에 "일반론 질문은 도구 호출 없이 답한다" 명시 + few-shot 예시로 분리합니다.

5. 모델 출력 한 묶음 — 코드 예시 한 개

모델이 어떻게 도구 호출을 출력하는지 한 번만 보여드립니다. 이게 글에 박는 유일한 코드입니다.

Doubly robust estimation — IPW와 outcome 모델의 결합으로 인과 추정 안정화

Aramir — Sat, 16 May 2026 18:16:48 +0900

PSM·IPW는 propensity 모델이 틀리면 무너지고, 회귀는 outcome 모델이 틀리면 무너집니다. doubly robust는 두 모델을 결합해 둘 중 하나만 맞으면 정직한 효과 추정. 마케팅 인과 분석의 안전판.

무작위 배정이 안 되는 자리에 인과 효과를 추정하려면 두 가지 길이 있습니다 — propensity 모델 기반(PSM·IPW) 또는 outcome 모델 기반(회귀). 두 길은 각각 서로 다른 자리에서 깨집니다. doubly robust(이중 안전) 추정은 두 모델을 결합해, 둘 중 하나만 맞으면 정직한 효과 추정을 보장합니다. 마케팅 인과 분석의 안전판.

마케터가 이 글을 읽어야 하는 이유: 인과 분석 결과를 회의에서 신뢰성 있게 보고하려면 "이 추정의 모델 가정 중 어느 게 깨져도 결과가 무너지는가"를 먼저 답해야 합니다. doubly robust는 그 답이 "둘 다 깨져야 무너진다"라 회의 신뢰도가 한 단계 올라갑니다.

둘 중 하나만 맞으면 정직 — 인과 추정의 안전 마진.

1. PSM·IPW가 흔들리는 자리

PSM이나 IPW(역확률 가중)는 propensity score $p (X) = Pr (노출 ∣ X)$ 를 정확히 추정한다는 가정에 의존합니다.

propensity 모델이 틀리면 매칭·가중이 잘못되고 효과 추정이 편향됩니다.

흔한 자리:

비선형 관계 (로지스틱이 아닌 GBM 필요)
변수가 너무 많음 (overfitting)
관측 변수 부족 (unmeasured confounder)

2. Outcome 회귀가 흔들리는 자리

다른 길은 outcome을 직접 모델링하는 것. $E [Y ∣ X, T]$ 를 회귀로 추정하고, $T = 1$ 과 $T = 0$ 의 차이를 효과로.

outcome 모델이 틀리면 회귀 계수가 편향되고 효과 추정도 무너집니다.

흔한 자리:

비선형 outcome (회귀 가정 위반)
interaction 효과 미포함
결과 변수의 분포 가정 위반

3. Doubly robust의 한 줄 직관

두 모델을 결합해 어느 하나만 맞으면 정직한 추정을 보장.

둘 다 잘 추정하면 효율 최고, 하나만 맞아도 unbias, 둘 다 틀리면 무너짐.

수식으로(AIPW = Augmented IPW):

\overset{τ}{^}_{D R} = \frac{1}{N} i \sum [\frac{T _{i} ( Y _{i} - μ _{1} ( X _{i} ))}{p ( X _{i} )} - \frac{( 1 - T _{i} ) ( Y _{i} - μ _{0} ( X _{i} ))}{1 - p ( X _{i} )} + μ_{1} (X_{i}) - μ_{0} (X_{i})]

첫 두 항: IPW 보정 (residual에 가중)
세 번째 항: outcome 모델의 직접 추정

핵심: propensity 모델이 정확하면 첫 두 항이 정직. outcome 모델이 정확하면 세 번째 항이 정직. 둘 다 틀려야 무너짐.

4. AIPW vs 단순 IPW·회귀 비교

같은 데이터에 세 추정량을 적용하면 어떻게 다른지.

추정량	propensity 정확	outcome 정확	결과
IPW	✓	✗	정직
회귀	✗	✓	정직
IPW	✗	✗	편향
회귀	✗	✗	편향
AIPW	✓	✗	정직
AIPW	✗	✓	정직
AIPW	✗	✗	편향

AIPW가 IPW와 회귀의 위험 분산. 한 모델이 흔들려도 다른 모델이 받쳐주는 구조.

5. 코드 한 묶음 — Python AIPW 구현

이게 글에 박는 유일한 코드입니다.

EU DMA가 walled garden을 어떻게 흔드나 — 마케터 영향 정리

Aramir — Sat, 16 May 2026 18:16:00 +0900

EU의 Digital Markets Act(DMA)가 Meta·Google·Apple의 walled garden을 강제 개방시키고 있습니다. 광고주 데이터·측정·광고 제품 관점에서 마케터가 알아야 할 변화 정리.

Meta·Google·Apple은 자기 플랫폼 안의 사용자 데이터·광고 제품을 닫힌 환경(walled garden)에서 운영해 왔습니다. 광고주는 그 안의 데이터를 부분만 보고, 측정·타겟팅 능력도 플랫폼에 의존했습니다. EU의 Digital Markets Act(DMA)가 2024년 본격 시행되면서 이 walled garden이 강제 개방되고 있고, 그 변화가 광고주의 데이터·측정·운영에 영향을 미칩니다.

마케터가 이 글을 읽어야 하는 이유: 한국 광고주에게도 DMA가 직접 영향을 줄 수 있습니다. 글로벌 캠페인 운영, 글로벌 분석 표준 변화, EU 사용자 타겟팅 룰 변경. 미리 흐름을 알면 분기 운영에서 헤매지 않습니다.

walled garden 일부가 열리는 중 — 광고주에게 새 가능성과 새 책임이 동시에.

1. DMA의 핵심 — gatekeeper 의무

EU DMA는 시장 지배적 디지털 플랫폼(gatekeeper) 7개를 지정해 의무를 부과합니다.

Gatekeeper	주요 서비스
Alphabet (Google)	Search, YouTube, Maps, Play, Chrome
Apple	App Store, Safari, iOS
Meta	Facebook, Instagram, WhatsApp, Messenger
Amazon	Marketplace, Ads
Microsoft	Windows, LinkedIn
ByteDance	TikTok
Booking	(2024 추가)

이들에게 부과된 의무:

데이터 이식성 — 광고주에게 자기 데이터를 가져갈 권리 보장
결합 제한 — gatekeeper 서비스끼리 사용자 데이터 결합에 사용자 동의 요구
자사 우대 금지 — 검색 결과·광고 노출에 자사 제품 부당 우대 금지
인터스토어 — 앱 내 결제 외 결제 수단 허용 (Apple 영향)
인터오퍼러빌리티 — 메신저 등 호환 가능 (Meta 영향)

2. 광고주 영향 — 데이터 측면

2-1. 데이터 이식성 (Data portability)

광고주가 Meta·Google에 쌓아둔 광고 데이터(노출·클릭·전환·오디언스)를 포터블 형식으로 추출 가능. CDP·BigQuery 같은 자체 시스템에 결합하기 쉬워짐.

2-2. Cross-service 데이터 결합 제한

Google이 검색·YouTube·Maps의 사용자 데이터를 결합해 광고 타겟팅에 쓰던 자리가 사용자 명시 동의 필요. 동의 안 한 사용자에 대한 cross-service 타겟팅 정밀도 저하.

2-3. 1st-party 데이터의 가치 상승

walled garden 안 매칭 정밀도가 떨어지면 광고주의 1st-party 데이터(이메일·전화번호 해시) 매칭이 더 중요. Server-side tagging·CAPI 운영 가치 상승.

영역	변화	광고주 대응
데이터 이식성	+	1st-party 결합 강화
Cross-service 타겟팅	- (동의 필요)	직접 동의 받는 페이지 운영
1st-party 매칭	+	CRM·CDP 정비

3. 광고주 영향 — 측정 측면

3-1. lift study의 표준화

DMA에 따라 gatekeeper가 광고주 자체 lift study를 더 자주 허용. Google·Meta의 자체 lift 도구 외 외부 툴(Nielsen·Comscore)과 통합도 증가.

3-2. Conversion lift API 개방

Meta의 Conversion Lift, Google의 Brand/Search lift 같은 도구가 더 표준화된 API 제공. 광고주 자체 분석 시스템과 통합 용이.

3-3. Attribution 멀티터치 가능성

지금까지 walled garden의 last-click 어트리뷰션 의존이 컸음. DMA가 광고주에게 자기 데이터를 외부 MTA·MMM 도구로 분석할 수 있게 하면서 멀티터치 어트리뷰션이 다시 살아남.

4. 광고주 영향 — 광고 제품 측면

4-1. 검색 광고의 자사 우대 금지

Google Search에서 자사 제품(Shopping·Travel)이 부당하게 상단 노출되는 자리 제한. 광고주의 검색 키워드 가치가 재조정.

4-2. App Store 결제 우회 (Apple)

iOS 앱이 외부 결제 수단으로 우회 가능해지면서 Apple 30% 수수료 회피 자리 발생. 광고주의 in-app 광고 ROI 변화.

4-3. 메신저 인터오퍼러빌리티 (Meta)

WhatsApp이 다른 메신저와 호환 가능. 글로벌 CRM 캠페인 채널 확장.

광고 제품	DMA 영향	광고주 액션
Google Search	자사 우대 금지	키워드 가치 재평가
YouTube Ads	Cross-service 타겟팅 약화	1st-party seed 강화
Meta Ads	API 표준화	외부 분석 도구 통합
App Store	외부 결제 허용	결제 비용 재계산

5. 한국 광고주에게의 영향 — 직간접

5-1. 직접 영향 (글로벌 캠페인)

EU 사용자 대상 캠페인 운영 시 DMA 룰 적용. Cross-service 동의 게이트 추가, 데이터 결합 제한 등.

5-2. 간접 영향 (글로벌 표준 변화)

Meta·Google의 글로벌 정책이 EU 룰에 맞춰 통일되는 경향. 한국 시장 광고 운영도 영향.

5-3. 한국 자체 규제 (PIPA)

한국 개인정보보호법(PIPA)이 cross-service 동의·1st-party 데이터 가치 측면에서 비슷한 방향. DMA의 흐름이 PIPA·KISA 기준에도 반영되는 추세.

6. 마케터가 미리 점검할 5가지

6-1. 1st-party 데이터 정비

서버측 태깅·CAPI 운영이 표준 인프라가 되어가고 있습니다. server-side-tagging-capi에서 다룬 매칭 키 정규화·EMQ 점수 관리가 더 중요해짐.

6-2. 동의 관리 시스템 (CMP)

OneTrust·TrustArc 같은 CMP 도입. EU 사용자 cross-service 동의를 받는 표준 플로우 운영.

6-3. 측정의 다층화

walled garden 자체 측정 + 외부 lift study + MMM 결합. 한 도구의 한계를 다른 도구로 보완.

6-4. 글로벌 캠페인 분리 운영

EU·미국·아시아 캠페인을 분리해 각 지역 룰 적용. 글로벌 단일 캠페인은 DMA 위반 위험.

6-5. 분기 정책 변화 점검

DMA·Apple ATT·Google Privacy Sandbox 등 정책 변화가 빠름. 분기에 한 번씩 정리하는 자리 필요.

점검 항목	분기 1회 점검
1st-party 데이터 EMQ 점수	7+ 유지
CMP 동의율	60%+
외부 lift study	분기 1회
글로벌 캠페인 분리	자동화 검토
정책 변화 요약	30분 회의

7. 코드 한 묶음 — 지역 분리 운영 인디케이터

이게 글에 박는 유일한 코드입니다. EU 사용자 분리 추적의 간단한 패턴.

# 광고 노출 로그 처리 시 EU 사용자 인디케이터

Customer journey orchestration — 채널을 시간 축에서 묶는 법

Aramir — Sat, 16 May 2026 18:15:11 +0900

같은 사용자가 광고·이메일·푸시·SMS를 받는 순서가 ROAS를 좌우합니다. customer journey orchestration이 cross-channel 시퀀싱을 자동화해 마찰을 줄이는 흐름. 도구·룰·평가 정리.

같은 사용자에게 광고가 뜨고 5분 뒤 이메일이 오고 1시간 뒤 푸시가 오고 다음 날 SMS가 오면 그건 마케팅이 아니라 폭격입니다. 사용자가 떠나면 ROAS가 무너집니다. customer journey orchestration은 채널을 시간 축에서 묶어 사용자 한 명의 경험을 디자인합니다. 마케팅의 다음 도약 자리.

마케터가 이 글을 읽어야 하는 이유: 채널별 ROAS 보고는 채널 안의 효율만 보여주고, cross-channel 마찰은 안 보여줍니다. journey orchestration이 그 마찰을 줄여 같은 예산으로 ROAS·LTV를 끌어올립니다. 도구·룰·평가의 표준 워크플로를 알면 분기 운영의 다음 단계 로드맵이 잡힙니다.

채널 단위가 아니라 사용자 한 명의 시간 축에서 마케팅을 디자인.

1. Cross-channel 마찰의 한 줄 직관

채널별로 분리된 운영의 함정.

광고팀은 광고 노출 최대화, 이메일팀은 발송 빈도 최대화, 푸시팀은 클릭률 최대화 — 각자 자기 지표를 최적화하면 사용자 한 명에게 동시에 폭격.

마케팅이 채널별 ROAS만 보고 의사결정하면 사용자 경험이 깨집니다. 사용자 단위 frequency·시간 간격이 운영의 새 단위가 되어야 합니다.

채널	단독 KPI	단독 최적화	Cross-channel 마찰
광고	노출·CTR	빈도 늘림	사용자 피로
이메일	오픈률	발송 늘림	스팸 신고
푸시	클릭률	알림 늘림	앱 알림 끔
SMS	응답률	발송 늘림	unsubscribe

cross-channel orchestration의 한 줄: "사용자 한 명에게 노출되는 모든 채널의 합을 한 곳에서 통제."

2. Journey orchestration의 4가지 핵심 능력

2-1. 사용자 단위 통합 ID

광고 노출·이메일 발송·푸시 알림이 모두 한 사용자에 매핑되어야 함. CDP·ID graph가 기반. CDP ID 그래프 참고.

2-2. 채널 간 시간 간격 룰

"광고 노출 후 24시간은 이메일 보내지 않음" 같은 룰을 자동 적용. 채널별 운영팀이 모르는 글로벌 룰을 orchestration이 보장.

2-3. 트리거 기반 시퀀스

사용자 행동(장바구니 담기, 페이지 방문)이 일어나면 다음 단계 채널 자동 발동. 정적 발송이 아닌 동적 흐름.

2-4. A/B 테스트 시퀀스 자체

journey 시퀀스 한 가지가 아니라 여러 변형을 동시 테스트. "광고 → 이메일" vs "광고 → 푸시" 효율 비교.

능력	도구
통합 ID	CDP (Segment, Tealium, Hightouch)
시간 룰	journey 도구 (Braze, Iterable, Customer.io)
트리거	event-based campaign
A/B	journey-level experiment

3. 표준 journey 패턴 5가지

마케팅 자리에 자주 등장하는 시퀀스 패턴.

3-1. Welcome series

가입 후 7일간 단계적 메시지. 1일차 환영 → 3일차 첫 액션 가이드 → 7일차 첫 구매 인센티브.

3-2. Cart abandonment

장바구니 담은 뒤 1시간 푸시 → 24시간 이메일 → 72시간 광고 retargeting. 단계마다 메시지 톤 다르게.

3-3. Post-purchase

구매 후 즉시 확인 메일 → 3일차 사용 가이드 → 30일차 재구매 인센티브 → 60일차 cross-sell.

3-4. Win-back

비활성 사용자(30일+ 미접속)에게 단계적 회복. 1주차 푸시 → 2주차 이메일 → 4주차 SMS + 인센티브.

3-5. Loyalty progression

포인트·등급 변화 시 축하 메시지. 등급 상승 즉시 → 다음 등급 도달 진행률 안내 → 등급 만료 임박 알림.

패턴	트리거	채널 시퀀스	기간
Welcome	가입	이메일 → 푸시 → 광고	7일
Cart abandon	장바구니	푸시 → 이메일 → 광고	72시간
Post-purchase	구매	이메일 → 이메일 → 광고	60일
Win-back	비활성 30일+	푸시 → 이메일 → SMS	4주
Loyalty	등급 변화	푸시 → 이메일	즉시

4. 코드 한 묶음 — journey 룰 평가 의사코드

이게 글에 박는 유일한 코드입니다. journey orchestration의 핵심 룰 평가 흐름.

from datetime import datetime, timedelta

def can_send(user_id: str, channel: str, history: list) -> bool:
    """
    사용자에게 이 채널을 지금 보낼 수 있나?
    history: 최근 7일 [{ts, channel}]
    """
    now = datetime.utcnow()

    # 룰 1: 채널별 일일 한도
    DAILY_LIMITS = {"email": 2, "push": 5, "sms": 1, "ads": 20}
    today_count = sum(1 for h in history
                      if h["channel"] == channel
                      and (now - h["ts"]).days == 0)
    if today_count >= DAILY_LIMITS.get(channel, 10):
        return False

    # 룰 2: 채널 간 최소 간격 (광고 후 1시간 내 이메일 금지)
    MIN_GAP = {"ads_to_email": timedelta(hours=1),
               "ads_to_push": timedelta(minutes=30),
               "email_to_push": timedelta(hours=2)}
    for h in history:
        gap_key = f"{h['channel']}_to_{channel}"
        if gap_key in MIN_GAP and (now - h["ts"]) < MIN_GAP[gap_key]:
            return False

    # 룰 3: 사용자 글로벌 frequency cap (모든 채널 합)
    week_count = sum(1 for h in history
                     if (now - h["ts"]).days <= 7)
    if week_count >= 30:  # 주 30번 이상이면 모든 채널 차단
        return False

    return True

# 사용 예
history = [{"ts": datetime.utcnow() - timedelta(minutes=15), "channel": "ads"}]
print(can_send("u123", "email", history))  # False (광고 후 1시간 내)
print(can_send("u123", "push", history))   # True (광고 후 30분 + 1초)

이 한 묶음이 cross-channel 폭격을 막는 글로벌 룰의 단순한 구현. 실제 운영은 Braze·Customer.io 같은 도구의 visual builder로 룰 관리.

5. 도구 비교 — 마케팅 자리에 적합한 자리

도구	강점	적합 자리
Braze	모바일 푸시 강함, journey UI	앱 중심 비즈니스
Iterable	이메일·SMS 통합, 가성비	이커머스
Customer.io	트리거·이벤트 기반 강함	SaaS, 구독
Salesforce Marketing Cloud	enterprise 표준	대형 B2B/B2C
Klaviyo	이커머스 전용, Shopify 연동	DTC 브랜드

도구 선택보다 운영 룰 설계가 더 중요. 어느 도구를 써도 룰이 없으면 폭격이 됩니다.

6. Journey orchestration의 ROI 측정

orchestration 도입의 효과를 측정하려면 journey-level lift study가 필요.

6-1. holdout group

사용자 일부를 holdout으로 두고 journey 적용 안 함. 두 그룹의 LTV·재구매율 비교.

6-2. journey 시퀀스 A/B

같은 트리거에 대해 두 가지 시퀀스 변형. 어느 시퀀스가 효율 좋은지 분기마다 검증.

6-3. 지표

사용자 단위 conversion rate
사용자 단위 unsubscribe·앱 알림 끔 비율
사용자 단위 LTV
channel별 marginal ROI (한 채널 추가했을 때의 lift)

지표	journey 도입 전	도입 후	변화
사용자 unsubscribe 비율	8%	3%	-5%p
앱 알림 끔 비율	12%	5%	-7%p
90일 재구매율	22%	28%	+6%p
LTV	$180	$215	+19%

이 표가 journey orchestration의 운영 가치를 정량적으로 보여주는 표준 양식.

7. 운영 시작의 첫 30일 로드맵

orchestration 도입의 표준 첫 분기.

7-1. 1주차 — 통합 ID 정비

CDP에 광고·이메일·푸시·구매 이벤트가 같은 사용자 ID로 들어오는지 점검. ID graph 정비.

7-2. 2-3주차 — 글로벌 frequency cap

가장 단순하고 강력한 첫 룰. 사용자별 7일 합계 노출 30+ 차단. 채널별 일일 한도 설정.

7-3. 4-6주차 — 채널 간 최소 간격

광고 → 이메일 1시간, 이메일 → 푸시 2시간 등의 룰 자동 적용.

7-4. 7-12주차 — 첫 journey 패턴 운영

cart abandonment 또는 welcome series 한 가지부터 운영. holdout group 두고 효과 측정.

주차	작업
1	통합 ID 정비
2-3	글로벌 frequency cap
4-6	채널 간 최소 간격
7-12	첫 journey 패턴 (cart abandon)
분기 후	journey 확대 + A/B 테스트

8. 마치며 — 마케팅의 다음 도약

채널별 ROAS 보고가 마케팅 운영의 표준이지만, 사용자 단위 경험 디자인이 다음 도약 자리입니다. journey orchestration이 cross-channel 마찰을 줄이고 사용자 LTV를 올려, 같은 예산으로 더 많은 결과를 만듭니다. 도구 도입보다 룰 설계가 중요하고, 단순한 룰부터 시작해 점진적 확장하는 게 표준 로드맵.

다음 분기에 한 번만 시도해 볼 만한 것은 사용자 단위 글로벌 frequency cap 한 가지를 도입해 unsubscribe·앱 알림 끔 비율 변화를 측정하는 흐름입니다. 한 가지 룰만으로 사용자 경험이 눈에 띄게 개선됩니다.

다음에 읽을 글

CDP ID 그래프 — 통합 ID의 인프라
Frequency capping — 채널별 frequency cap의 깊이
Marketing analytics maturity — 측정 성숙도와의 결합

참고

Braze, "Customer engagement platform": https://www.braze.com/
Iterable, "Cross-channel marketing": https://iterable.com/
Customer.io, "Behavioral messaging": https://customer.io/
"Customer journey orchestration" (Forrester): https://www.forrester.com/
"Lifecycle marketing playbook" (Reforge): https://www.reforge.com/

Context engineering — 200k 토큰 컨텍스트의 설계 원칙 5가지

Aramir — Sat, 16 May 2026 18:14:19 +0900

컨텍스트 창이 200k 토큰까지 커졌지만 단순히 다 넣으면 lost-in-the-middle·비용 폭발·정확도 하락이 옵니다. 마케팅 자동화에 적용하는 5가지 컨텍스트 설계 원칙.

Claude Sonnet은 200k 토큰, GPT-5는 1M 토큰까지 컨텍스트를 받습니다. 보고서 한 권을 통째로 넣고 질문할 수 있다는 뜻입니다. 그런데 실제 운영해보면 함정이 보입니다 — 중간 부분의 정보를 모델이 자주 놓치고, 비용은 길이 제곱으로 늘고, 정작 답변 정확도가 컨텍스트 짧을 때보다 떨어집니다. 긴 컨텍스트를 잘 쓰는 건 따로 설계 원칙이 필요합니다.

마케터가 이 글을 읽어야 하는 이유: RAG 챗봇·보고서 자동화·캠페인 분석 등 LLM 자동화의 거의 모든 자리에서 컨텍스트가 길어지는 압력이 있습니다. 단순히 "다 넣자"가 아니라 어떤 정보를 어디에 배치할지의 설계 한 줄이 답변 품질·비용 둘 다 결정합니다.

긴 컨텍스트는 새 차원의 문제를 만든다. 처음·끝·중간의 attention 분포가 다르다.

1. Lost-in-the-middle — 가장 큰 함정

긴 컨텍스트를 처음 써보면 가장 빨리 마주치는 현상입니다.

모델이 컨텍스트 처음·끝의 정보를 잘 보고, 중간 정보는 약하게 본다.

트랜스포머 직관에서 다룬 것처럼 attention이 모든 토큰을 같은 강도로 보지 않습니다. 학습 데이터에서 처음·끝 토큰이 정답에 자주 등장한 패턴이 모델에 박혀 있어, 100k 토큰의 중간에 핵심 정보를 두면 잘 못 찾습니다.

정보 위치	회수 정확도 (평균)
처음 10%	90%+
처음 30%	70-80%
중간 50%	50-60%
끝 30%	70-80%
끝 10%	85%+

NIAH (Needle In A Haystack) 벤치마크에서 일관되게 관찰되는 패턴. 모델·버전마다 차이가 있지만 큰 흐름은 비슷.

2. 원칙 1 — 핵심 정보는 처음과 끝에

가장 단순하고 강력한 원칙. 사용자 질문·핵심 지시는 시스템 프롬프트의 시작 또는 사용자 메시지의 끝에 배치합니다.

좋은 구조	나쁜 구조
[시스템 핵심 지시] [컨텍스트 문서들] [사용자 질문]	[컨텍스트 문서들] [시스템 지시 중간] [사용자 질문]

배경 컨텍스트(few-shot 예시·참고 문서)는 중간으로. 핵심 정보가 처음과 끝에 자리잡으면 lost-in-the-middle 영향을 줄입니다.

3. 원칙 2 — 컨텍스트 다이어트

200k가 가능하다고 200k를 다 쓸 이유는 없습니다. 컨텍스트 길이는 비용·latency·정확도 셋 다에 영향을 줍니다.

Cost \propto T_{in}, Latency \propto T_{in}, Attention compute \propto T_{in}^{2}

비용: 입력 토큰 단가 × 토큰 수 (선형)
Latency: 토큰 수에 거의 비례 (선형)
Attention 연산: 토큰 수 제곱 (KV cache 적용해도 인상)

8k → 4k 절반으로 줄이면 비용 절반, latency 절반, attention 연산 1/4. 동시에 lost-in-the-middle 감소. 모든 차원에서 이득.

4. 원칙 3 — RAG로 동적 선택

코퍼스가 크면 벡터 검색으로 관련 문서를 동적 선택해 컨텍스트에 넣는 RAG가 표준 패턴입니다.

사용자 질문
    │
    ▼
벡터 검색 → Top 5 문서 선택
    │
    ▼
선택된 5개만 컨텍스트로 LLM에 전달

전체 코퍼스를 통째로 넣지 않고 관련 5개만 동적 선택. 컨텍스트 다이어트가 자동으로 일어남. RAG 품질 개선은 RAG 평가와 RAG 재순위에서 다룹니다.

5. 원칙 4 — 구조화된 형식 활용

긴 컨텍스트라도 구조화된 형식이면 모델이 정보를 더 잘 회수합니다.

형식	효과
자유 산문	가장 약함
Markdown 헤딩	중간
YAML/JSON 구조	강함
XML 태그	가장 강함 (Anthropic 권장)

XML 태그로 컨텍스트의 각 영역을 명시적으로 구분하면 모델이 "이 부분은 회사 정책, 저 부분은 사용자 데이터"를 분명히 인식합니다. Claude는 XML 형식에 특히 강하게 학습되어 있어 컨텍스트 회수 정확도가 한 단계 올라갑니다.

6. 원칙 5 — 위치별 역할 분담

긴 컨텍스트의 위치별 역할을 명확히 잡으면 효율이 올라갑니다.

위치	역할
시스템 프롬프트 시작	핵심 지시·역할·톤
시스템 프롬프트 중간	제약·스타일 가이드
시스템 프롬프트 끝	출력 형식 명시
사용자 메시지 시작	컨텍스트 문서
사용자 메시지 중간	Few-shot 예시
사용자 메시지 끝	핵심 질문·요청

이 구조를 표준 템플릿으로 박아두면 새 자동화에 적용할 때 헷갈리지 않습니다. 각 자리의 역할이 분명하니 lost-in-the-middle도 줄어듭니다.

7. 코드 한 묶음 — 컨텍스트 구조 템플릿

이게 글에 박는 유일한 코드입니다. Anthropic XML 태그 활용 패턴.

Brand lift study 설계 — 광고가 인지·호감도를 끌어올렸나

Aramir — Sat, 16 May 2026 18:13:29 +0900

브랜드 광고는 ROAS로 잡히지 않고 인지·호감도·구매의향으로만 측정됩니다. 노출 그룹과 비노출 그룹을 비교하는 brand lift study의 설계, 표본 계산, 실무 함정을 마케터 시선에서 정리.

"이 브랜드 캠페인 효과 있었어?"라는 질문은 ROAS로 답하기 어렵습니다. 브랜드 광고의 진짜 결과는 며칠 또는 몇 주 뒤에 인지·호감도·구매의향으로 나타나기 때문입니다. brand lift study는 그 변화를 노출 그룹과 비노출 그룹의 설문 응답 차이로 측정합니다. Meta·Google·YouTube가 자체 도구로 제공하지만, 설계 한 줄을 잘못 잡으면 결과 해석이 통째로 깨집니다.

마케터가 이 글을 읽어야 하는 이유: 브랜드 캠페인 예산 의사결정에서 "효과 있었다 vs 없었다"의 답을 데이터로 정리하지 않으면, 다음 분기 브랜드 예산이 늘 위협받습니다. brand lift study가 그 답을 정직하게 만드는 표준 도구이고, 마케터가 직접 점검할 5가지 디자인 결정이 있습니다. 그 결정 한 줄이 결과의 신뢰도 절반을 만듭니다.

ROAS가 못 잡는 자리를 잡는 표준 — 노출과 비노출의 설문 응답 차이가 곧 brand lift.

1. Brand lift의 한 줄 직관

광고에 노출된 사람들과 노출되지 않은 사람들이 같은 설문에 어떻게 답하는가의 차이.

같은 사용자 풀에서 무작위로 두 그룹 추출 → 한 그룹은 광고 노출, 다른 그룹은 비노출(holdout) → 며칠 뒤 두 그룹 모두에게 같은 설문 → 응답 차이가 brand lift.

전형적 4개 KPI 문항:

KPI	질문
인지 (Awareness)	"다음 브랜드 중 들어본 적 있는 것은?"
회상 (Ad recall)	"최근 1주일 안에 X 브랜드 광고를 본 적 있나요?"
호감도 (Favorability)	"X 브랜드에 대한 호감도는?"
구매의향 (Purchase intent)	"다음 구매 시 X 브랜드를 고려하시겠습니까?"

노출 그룹 응답률이 비노출 그룹보다 +5%p 높다면, 그 5%p가 brand lift. 이게 광고 노출이 일으킨 인과 효과의 추정치입니다.

2. ROAS가 못 잡는 자리

브랜드 캠페인의 결과는 ROAS 보고서에서 거의 안 잡힙니다. 이유는 세 가지.

2-1. 시간 격차

브랜드 광고를 본 사용자가 며칠~몇 주 뒤에 검색·구매로 이어지는데, 그 사이에 다른 채널·이벤트가 끼어듭니다. 마지막 클릭 어트리뷰션에서는 검색 광고에 100% 공이 가고 브랜드 광고는 0.

2-2. 측정 한도

ROAS는 클릭과 직접 전환만 잡습니다. 인지도·호감도 변화는 ROAS에 안 들어옵니다. 측정 도구의 한계.

2-3. 자가 선택 편향

관심 있는 사람이 광고를 더 보고 더 구매합니다. 광고가 일으킨 효과가 아니라 원래 관심 있던 사람의 행동.

이 세 가지를 동시에 해결하는 설계가 brand lift study의 무작위 배정 + holdout. 인과 효과 추정의 표준 구조입니다.

3. 무작위 배정과 holdout

brand lift의 핵심은 무작위 배정입니다. 같은 사용자 풀에서 광고 노출 자격을 무작위로 결정. 노출 그룹과 holdout 그룹이 통계적으로 동일한 분포를 갖도록.

Meta·Google·YouTube의 brand lift 도구는 광고 자격을 가진 사용자 중 일정 비율(보통 10-20%)을 holdout으로 떼어두고, 그 그룹에는 광고를 노출하지 않습니다. 캠페인 종료 후 양 그룹에 같은 설문이 노출됩니다.

항목	노출 그룹 (Exposed)	Holdout
배정	무작위 80-90%	무작위 10-20%
광고 노출	가능	차단
설문 노출	캠페인 후	캠페인 후
응답 비교	brand lift 측정	기준선

이 구조 안에서만 "광고가 일으킨 효과"가 정직하게 추정됩니다. holdout 없이 노출 그룹의 사전·사후만 비교하는 건 자연 변화·계절성을 잡지 못해 결과가 부풀려집니다.

4. 표본 크기 — 검출 가능 lift는 얼마?

brand lift는 표본이 충분해야 검출 가능합니다. 작은 캠페인에서는 lift가 있어도 검출 못 함.

표준 lift 검출 표본 크기 공식 (이항 비율 차이):

n \approx \frac{( z _{α} + z _{β} ) ^{2} \cdot 2 p ˉ ( 1 - p ˉ )}{δ ^{2}}

$\overset{p}{ˉ}$ 는 평균 응답률, $δ$ 는 검출하고 싶은 lift, $z_{α} = 1.96$ , $z_{β} = 0.84$ (검출력 80%, 양측 5%).

예시: 인지 baseline 30%, 5%p lift 검출 (검출력 80%, 양측 5%).

$\overset{p}{ˉ} = 0.325$ , $δ = 0.05$
$n \approx \frac{( 1.96 + 0.84 ) ^{2} \cdot 2 \cdot 0.325 \cdot 0.675}{0.0 5 ^{2}} \approx 1376$

각 그룹 1376명, 총 약 2750명 응답 필요. 응답률 5% 가정 시 노출 약 5만 명, holdout 1.4만 명 = 캠페인 노출 6.4만 명+.

baseline	검출 lift	그룹당 표본
30%	5%p	약 1300
30%	3%p	약 3700
30%	1%p	약 33,000
50%	5%p	약 1500

작은 lift를 검출하려면 표본이 폭증합니다. 1%p lift를 잡으려면 그룹당 3.3만 명.

5. 코드 한 묶음 — lift 검출 표본 계산

이게 글에 박는 유일한 코드입니다.

Bayesian A/B 테스트 심화 — prior 잡는 법과 HDI 해석

Aramir — Sat, 16 May 2026 18:12:43 +0900

베이지안 A/B는 "p-value < 0.05"가 아니라 "B가 A보다 좋을 확률 0.92"를 줍니다. 그 확률이 정직하려면 prior를 잘 잡아야 하고, HDI를 잘못 읽으면 함정이 옵니다. 마케터 시선에서 prior·posterior·HDI 정리.

"B안이 A보다 좋을 확률 92%"라는 한 줄이 회의를 한 번에 정리합니다. 베이지안 A/B의 매력입니다. 그런데 그 92%라는 숫자가 정직하려면 prior를 어떻게 잡았는지, HDI를 어떻게 해석했는지가 함께 따라와야 합니다. 이 글은 마케터 시선에서 베이지안 A/B의 prior 설계, posterior 해석, HDI의 함정을 정리합니다.

마케터가 이 글을 읽어야 하는 이유: 빈도주의 A/B의 "p-value < 0.05"는 실무에서 늘 어색합니다. "그래서 B가 더 좋다는 거야 아니야?" 베이지안은 그 질문에 직접 답합니다. 다만 prior를 무심코 잡으면 답이 흔들리고, HDI를 단순 신뢰구간처럼 읽으면 의미가 깨집니다. 두 가지만 잘 잡으면 회의에서 의사결정 속도가 한 단계 올라갑니다.

prior가 출발점, 데이터가 갱신, posterior가 결론. HDI는 그 결론을 한 줄로 요약하는 구간.

1. 빈도주의 A/B와 베이지안 A/B의 한 줄 차이

항목	빈도주의	베이지안
답하는 질문	"이 차이가 우연일 확률은?"	"B가 A보다 좋을 확률은?"
출력	p-value, 신뢰구간	posterior 분포, HDI
해석	"기각/채택" 이분법	"어느 정도 더 좋은가" 연속적
표본 부족 자리	검출력 부족	prior가 정보 보강
회의 친화도	낮음 (해석 어려움)	높음 (확률로 직접 답)

베이지안의 직관: 사전 믿음(prior)을 데이터로 갱신해 사후 믿음(posterior)을 만든다. posterior가 의사결정의 입력이 됩니다.

2. Prior 잡는 법 — 세 가지 표준 패턴

prior는 "데이터를 보기 전에 우리가 알고 있던 것"입니다. 마케팅 자리에 자주 등장하는 세 패턴을 보겠습니다.

2-1. 무정보 prior — 정보 없을 때

Beta(1, 1) (= 균등분포)는 "0과 1 사이 어디든 가능성 동일"을 의미합니다. 정보가 전혀 없을 때 안전한 출발점.

θ \sim Beta (1, 1)

장점: 사전 편향 없음. 단점: 표본 작을 때 posterior가 흔들리기 쉬움.

2-2. 약한 정보 prior — 일반 상식 반영

Beta(2, 8)은 "전환율이 낮은 자리(평균 약 20%)에 약한 사전 정보". 마케터가 "이 캠페인은 전환율이 보통 15-25% 사이"라는 상식이 있을 때 그 상식을 prior에 반영.

θ \sim Beta (2, 8)

이런 prior는 데이터가 적을 때도 합리적인 posterior를 만들고, 데이터가 많아지면 prior 영향이 사라져 데이터가 답을 결정합니다.

2-3. 강한 정보 prior — 과거 데이터 활용

같은 캠페인의 작년 분기 데이터가 있으면, 그 데이터를 prior로 사용. 작년 분기에 1000명 중 250명 전환이라면 Beta(250, 750)을 prior로 잡습니다. 이게 베이지안 A/B의 가장 강력한 자리 — 과거 데이터가 사전 정보로 그대로 들어옵니다.

θ \sim Beta (250, 750)

이번 분기 작은 표본만으로도 posterior가 안정적으로 추정됩니다.

Prior 종류	$α, β$	표현
무정보	1, 1	"아는 게 없음"
약한 정보	2, 8	"전환율 약 20% 가정"
강한 정보	250, 750	"작년 데이터로 신뢰"

3. Posterior — 데이터로 갱신된 사후 분포

prior에 데이터가 들어가 posterior가 됩니다. Beta-Binomial 결합의 표준 결과:

Posterior = Beta (α + s, β + f)

$s$ 는 성공 수(전환), $f$ 는 실패 수(비전환). 1000명 노출 250명 전환이라면 $s = 250, f = 750$ . prior가 Beta(2, 8)이라면 posterior는 Beta(252, 758). 마케터 직관: 사전에 가정한 알파·베타에 실제 관측치를 더한다. 데이터가 많을수록 prior 영향은 사라지고 posterior가 데이터에 수렴.

A/B 두 변형 모두에 같은 절차를 적용해 두 posterior $θ_{A} \sim Beta (α_{A}, β_{A})$ , $θ_{B} \sim Beta (α_{B}, β_{B})$ 를 얻습니다. 비교는 두 분포의 비교입니다.

4. "B가 A보다 좋을 확률" 계산

두 posterior에서 직접 샘플링해 비교합니다.

P(B > A) = posterior 샘플 중 B 샘플이 A 샘플보다 큰 비율

10000개 샘플을 두 분포에서 각각 뽑아 짝지어 비교한 비율이 그 확률. 92%면 "B가 A보다 좋을 확률 92%"라고 회의에서 한 줄로 답할 수 있음.

이게 빈도주의 p-value가 못 답하는 자리입니다. p-value는 "차이가 우연일 확률"이지 "B가 A보다 좋을 확률"이 아닙니다. 둘은 다른 질문입니다.

5. 코드 한 묶음 — Beta-Binomial Bayesian A/B

이게 글에 박는 유일한 코드입니다.

CAC Payback period — 광고비를 몇 개월 만에 회수하는가

Aramir — Sat, 16 May 2026 18:11:50 +0900

CAC 한 번 쓰고 끝이 아닙니다. 그 광고비를 매출로 회수하는 데 몇 개월 걸리는지가 현금흐름·재투자 속도를 결정합니다. payback period 계산·운영 룰·SaaS vs 이커머스 차이.

광고비 $50 써서새고객한명데려왔다고끝이아닙니다 . 그$ 50을 매출로 회수하는 데 한 달 걸리는 채널과 1년 걸리는 채널은 현금흐름이 완전히 다릅니다. payback period는 LTV/CAC 비율이 못 잡는 시간 차원을 보여주는 핵심 지표이고, 마케팅 성장의 속도 한도를 결정합니다.

마케터가 이 글을 읽어야 하는 이유: LTV/CAC 5.0이라도 회수가 18개월 걸리면 그 캠페인을 매월 늘릴수록 현금이 마이너스로 갑니다. 회수 6개월 캠페인은 같은 비율 5.0이라도 빠르게 재투자 가능. payback period가 광고 예산 투입 속도의 한도를 데이터로 답합니다.

LTV/CAC만 보면 못 보는 시간 차원 — 회수 속도가 성장 한도를 결정한다.

1. Payback period의 한 줄 정의

신규 고객 한 명에게서 누적 매출이 그 고객을 획득한 CAC를 넘는 시점까지 걸린 시간.

수식으로:

Payback (t) = min {t : i = 1 \sum t revenue_{i} \geq CAC}

매출이 시간이 지나면서 누적되니, payback period는 그 누적 매출이 CAC를 넘는 첫 달.

CAC	월매출	Payback
$50	$25	2개월
$50	$10	5개월
$50	$5	10개월
$50	$4	13개월

월매출이 절반이면 payback이 두 배. 시간 대비 회수 속도가 단순한 비례 관계.

2. LTV/CAC와 payback의 차이

LTV/CAC와 payback은 둘 다 단위 경제학 지표지만 답하는 질문이 다릅니다.

지표	답하는 질문	시간 단위
LTV/CAC	"이 고객이 가치 있나?"	12-24개월 누적
Payback	"광고비 회수까지 얼마나?"	1-24개월

LTV/CAC 5.0인 채널 두 개:

채널 A: payback 4개월 → 매월 재투자 가능
채널 B: payback 18개월 → 같은 자본으로 매월 늘리면 현금 마이너스

같은 비율인데 운영 속도가 완전히 다름. payback이 그 차이를 잡습니다.

3. 산업별 표준 — SaaS vs 이커머스

3-1. SaaS

월간 구독 모델은 매출이 매월 나옵니다. payback은 보통 12-18개월이 표준.

LTV/CAC	Payback	등급
3.0+	< 12개월	매우 우수
3.0+	12-18개월	표준
3.0+	18-24개월	한계
3.0+	24+	자본 큰 회사만

3-2. 이커머스

이커머스는 첫 구매가 큰 비중. payback이 짧으면 좋고, 길면 재구매 LTV에 의존.

첫 구매 매출	재구매율	Payback
$50 (CAC와 동일)	0%	1개월 (첫 구매로 회수)
$30	30%	약 4개월
$20	50%	약 6개월
$15	60%	약 10개월

3-3. DTC 브랜드

평균 payback 6-12개월. 12개월 이상이면 광고 자본이 빠르게 묶여 성장 속도 한계.

산업	표준 payback
SaaS B2B	12-18개월
SaaS B2C	6-12개월
이커머스	6-12개월
DTC	6-12개월
게임	3-6개월
구독 박스	3-9개월

4. 코드 한 묶음 — Python으로 payback 계산

이게 글에 박는 유일한 코드입니다.

ROAS·CAC·LTV — 세 숫자 서로 다른 질문에 답하는 이유

Aramir — Sat, 16 May 2026 18:10:55 +0900

회의에서 ROAS만 들고 가면 장기·LTV가 빠지고, CAC만 보면 광고 효율이 빠집니다. 세 숫자를 한 슬라이드에 입체적으로 두는 표준 양식과 의사결정 프레임.

분기 회의에서 마케터가 ROAS만 들고 가면 임원이 "장기 매출은?" 묻고, CAC만 들고 가면 "획득 품질은?" 묻고, LTV만 들고 가면 "광고 효율 어떄?" 묻습니다. 세 숫자가 서로 다른 질문에 답하는 도구이고, 한 숫자만 보면 의사결정의 60%가 빠집니다. 이 글은 세 숫자를 한 슬라이드에 입체적으로 두는 표준 양식과 의사결정 프레임을 정리합니다.

마케터가 이 글을 읽어야 하는 이유: 분기마다 같은 질문이 회의에서 반복됩니다. 세 숫자를 한 번에 묶어 보고 양식으로 두면 그 반복이 사라지고, 의사결정 속도가 한 단계 올라갑니다. 신규 채널 도입·예산 재배분·캠페인 종료 같은 결정이 모두 세 숫자의 균형으로 답합니다.

세 숫자는 같은 결과의 다른 측면. 한 숫자만 보면 60%가 빠진다.

1. 세 숫자의 한 줄 정의

숫자	한 줄 정의	답하는 질문
ROAS	광고비 1원당 매출 (Return on Ad Spend)	"광고가 단기적으로 얼마나 효율적인가?"
CAC	신규 고객 1명 획득에 든 비용	"고객 한 명 데려오는 데 얼마?"
LTV	고객 1명이 평생 만들 매출 (Lifetime Value)	"데려온 고객이 얼마짜리?"

세 숫자는 서로 다른 시간 단위·서로 다른 분모에서 계산됩니다.

ROAS = 매출 / 광고비 (캠페인 단위, 단기)
CAC = 광고비 / 신규 고객 수 (코호트 단위, 단기)
LTV = 매출 / 고객 수 (코호트 단위, 장기)

이 차이가 회의에서 의사결정자가 묻는 질문의 차이를 만듭니다.

2. 세 숫자가 서로 다른 답을 하는 자리

2-1. ROAS 4.0인데 LTV가 망가지는 자리

ROAS는 단기 매출 효율만 봅니다. 첫 구매가 일어났으면 ROAS는 좋아 보이지만, 그 고객이 재구매 안 하고 떠나면 LTV는 낮습니다.

ROAS 4.0: 광고비 1원당 첫 구매 4원
LTV: 그 고객의 12개월 누적 매출이 4원에서 끝
결론: 단기 효율 좋지만 장기 가치 없음. 같은 ROAS 4.0의 다른 채널보다 가치 낮음.

2-2. CAC 낮은데 LTV가 부족한 자리

CAC만 낮추는 데 집중하면 획득 품질이 떨어집니다.

CAC $20 : 신규 1 명에$ 20만 씀
LTV $25 : 평생매출이$ 25
LTV/CAC 비율 1.25 (운영 한계, 보통 3.0+ 권장)

같은 자리에서 CAC $40 인데 L T V$ 200이면 비율 5.0으로 훨씬 좋음. CAC만 보면 첫 자리가 좋아 보이지만 LTV/CAC가 진실.

2-3. LTV 높은데 CAC도 폭주하는 자리

VIP 채널은 LTV가 높지만 CAC도 폭주할 수 있음.

LTV $500: 평균 매출 좋음
CAC $300: 획득에 너무 비쌈
LTV/CAC 1.7 (한계 영역)

3. 세 숫자의 관계 — LTV/CAC 비율

세 숫자를 묶는 표준 지표가 LTV/CAC 비율입니다.

LTV/CAC = \frac{LTV}{CAC}

LTV/CAC	진단
< 1.0	손실. 획득할수록 손해
1.0-2.0	한계. 광고 효율 또는 LTV 개선 필수
3.0+	표준 (SaaS·이커머스의 권장)
5.0+	매우 우수. 추가 투자 가치

LTV/CAC 3.0+가 권장되는 이유: 운영비·고정비를 제외한 마진을 확보하고 재투자할 여지를 만들기 위해서. 이커머스의 경우 마진 30%, SaaS는 70%+ 가정하에 산정.

3-1. ROAS와 LTV/CAC의 관계

단기 ROAS와 장기 LTV/CAC는 다른 도구입니다.

시나리오	ROAS	LTV/CAC
첫 구매만 ROAS	4.0	1.5 (LTV 부족)
재구매 풍부	2.5	5.0 (LTV 우위)
신규 시즌	1.5	3.0 (확장 단계)

ROAS만 좋고 LTV/CAC 부족이면 short-termist 함정. ROAS 낮은데 LTV/CAC 좋으면 장기 투자 자리.

4. 채널별 세 숫자 비교 — 표준 양식

분기 회의에 가져갈 표준 표.

채널	ROAS	CAC	LTV	LTV/CAC	판단
Meta 검색 (브랜드)	6.5	$25	$180	7.2	투자 확대
Meta retargeting	4.2	$35	$140	4.0	유지
TikTok prospecting	1.8	$55	$95	1.7	한계 — 검증
Naver 검색	5.1	$40	$220	5.5	투자 확대
Display	0.9	$80	$110	1.4	축소 또는 incrementality 검증

각 채널이 세 숫자에서 다르게 평가됩니다. 한 숫자만 보면 결정을 잘못 내림.

5. 코드 한 묶음 — Python으로 세 숫자 계산

이게 글에 박는 유일한 코드입니다.

마케팅 실험 플랫폼 설계 — 사내 A/B 시스템의 5가지 원칙

Aramir — Sat, 16 May 2026 18:10:03 +0900

광고 플랫폼 자체 A/B로는 부족하고 외부 SaaS는 비쌉니다. 사내 마케팅 실험 플랫폼을 설계할 때 깔아야 할 split assignment·exposure log·SRM 검정·sequential safe·메타 표준 5가지 원칙.

Meta·Google의 자체 A/B 도구는 광고 자체 효과만 보고, Optimizely·VWO는 비싸고 마케팅 데이터와 안 맞습니다. 사내 마케팅 실험 플랫폼을 직접 만들 때 깔아야 할 5가지 원칙이 있습니다. 한 가지라도 빠지면 결과가 흔들리고, 다섯 가지가 함께 깔리면 분기 실험이 정직한 의사결정의 기반이 됩니다.

마케터가 이 글을 읽어야 하는 이유: 사내 실험 플랫폼은 분석가·엔지니어가 만들지만, 마케터가 그 5가지 원칙을 모르면 결과 보고를 제대로 해석 못 합니다. 어떤 자리에서 어떤 보정이 필요한지, SRM 알림이 뜨면 무엇을 의심해야 하는지 — 이걸 알면 회의에서 결정 속도가 한 단계 올라갑니다.

실험 플랫폼의 골격은 단순하지만 각 단계의 디테일이 결과 신뢰도를 결정한다.

1. 원칙 1 — 결정론적 split assignment

1-1. 직관

같은 사용자가 실험에 여러 번 진입해도 항상 같은 그룹에 배정되어야 함. 매번 다른 그룹에 들어가면 결과가 흩어짐.

1-2. 표준 구현

사용자 ID와 실험 ID를 결합한 해시로 그룹 결정.

group (u, e) = hash (u \oplus e) mod N

$u$ 는 사용자 ID, $e$ 는 실험 ID, $N$ 은 그룹 수. SHA-256·MurmurHash3 등 빠른 해시 사용. 결정론적이라 같은 입력에는 항상 같은 출력.

1-3. 흔한 실수

시간 기반 ID 사용 → 매번 다른 그룹
실험 ID 빠뜨림 → 한 사용자가 모든 실험에서 같은 그룹 (의도된 균등 배정 깨짐)
캠페인 단위 실험인데 사용자 단위 split → 노출 빈도 차이로 편향

2. 원칙 2 — exposure log

2-1. 직관

사용자가 실험 그룹에 배정된 시점·맥락을 모두 기록. 결과 분석에 그 로그가 진실의 기반.

2-2. 필수 필드

필드	의미
user_id	사용자 식별자
experiment_id	실험 ID
variant	배정된 그룹 (A/B/C...)
timestamp	노출 시점
context	디바이스·페이지·세그먼트 등

이 5개 필드만 정확하면 후속 분석의 80%가 가능.

2-3. 노출 vs 의도 (intent-to-treat)

A/B 결과 분석의 표준은 ITT(Intent-to-Treat) — 그룹에 배정된 사용자가 실제로 처리를 받았는지와 무관하게 그룹 단위로 분석. 이 원칙을 지키려면 exposure log가 "어느 그룹에 속해야 했는가"를 기록해야 함. 실제 처리를 받았는지는 별도 컬럼.

3. 원칙 3 — SRM(Sample Ratio Mismatch) 자동 검정

3-1. 직관

50:50 그룹이 51:49로 깨졌으면 그룹 자체가 다른 분포일 수 있음. 카이제곱 검정으로 자동 점검.

χ^{2} = i \sum \frac{( O _{i} - E _{i} ) ^{2}}{E _{i}}

$O$ 는 관측 빈도, $E$ 는 기대 빈도(균등 분배 가정). p-value 0.001 이하면 SRM 의심.

3-2. SRM이 뜨면 의심할 것

bot·크롤러가 한쪽에 몰림
캐시 정책이 그룹별 다르게 작동
라우팅 로직 오류
트래픽 폭주로 한쪽 서버 과부하

3-3. 자동화

실험 시작 후 1시간·1일·1주 단위로 SRM 자동 체크. 알림 시 즉시 실험 일시 중지·원인 추적.

Simpson's Paradox에서 다룬 거의 모든 함정의 시작이 SRM이라 가장 먼저 잡아야 함.

4. 원칙 4 — Sequential safe 분석

4-1. 직관

전통적 t-test는 한 번만 봐야 함. 여러 번 보면 false positive 폭증. Sequential testing이 여러 번 봐도 안전한 통계.

4-2. peeking 함정

매일 결과 보면서 "유의미하면 종료" 룰 → 실험 5번 반복하면 false positive가 5배.

4-3. 표준 도구

mSPRT (mixture Sequential Probability Ratio Test) — Optimizely·VWO 기본
always-valid p-value
Bayesian A/B (prior + posterior, 매번 봐도 정직)

Sequential testing에서 깊이 다룸.

4-4. 마케팅 자리

분기 회의에서 "지금까지 결과 어때?" 질문이 자주 옴. Sequential safe 통계가 깔려 있어야 그 자리에 정직한 답 가능.

질문 빈도	통계 도구
실험 끝 후 1번만	t-test, chi-square
분기 한 번 점검	Sequential test
매주 점검	mSPRT 또는 Bayesian
매일 점검	Bayesian A/B

5. 원칙 5 — 메타데이터·표준화

5-1. 직관

플랫폼이 받는 모든 실험에 표준 메타데이터를 강제. 후속 분석·보고가 자동화 가능.

5-2. 필수 메타

필드	의미
실험 가설	"B안이 A보다 CVR +2%p"
Primary KPI	CVR, ROAS, 매출 등
사전 등록 MDE	검출 가능한 최소 효과
사전 등록 표본	power analysis 결과
종료 조건	표본 도달 또는 기간
결과 책임자	의사결정 담당

5-3. 사전 등록(preregister)이 보장하는 것

결과 보고 임의 조정 방지
p-value hacking 방지
다중 비교 함정 회피
결과 신뢰도 유지

5-4. 코드 한 묶음 — 실험 메타 schema

이게 글에 박는 유일한 코드입니다.

from pydantic import BaseModel
from typing import Literal
from datetime import datetime

class ExperimentMeta(BaseModel):
    experiment_id: str
    hypothesis: str
    primary_kpi: Literal["cvr", "roas", "revenue", "ctr", "retention"]
    mde_absolute: float       # 검출 최소 효과
    sample_size_per_group: int
    expected_duration_days: int
    end_condition: Literal["sample_reached", "time_elapsed"]
    owner: str
    created_at: datetime
    status: Literal["draft", "running", "ended", "stopped"]

# 실험 시작 전 메타 등록
exp = ExperimentMeta(
    experiment_id="exp-2026-q2-cta-color",
    hypothesis="빨강 CTA가 파랑 CTA 대비 CVR +1.5%p",
    primary_kpi="cvr",
    mde_absolute=0.015,
    sample_size_per_group=8136,
    expected_duration_days=8,
    end_condition="sample_reached",
    owner="marketing-team",
    created_at=datetime.utcnow(),
    status="draft",
)
print(exp.model_dump_json(indent=2))

이 스키마를 BigQuery·실험 테이블에 박아두면 모든 실험이 같은 양식으로 등록되고, 분기 보고 자동화가 가능.

6. 분석 단계 — 결과 보고의 표준 양식

실험 종료 후 결과 보고에 들어가야 할 항목.

항목	값 (예시)
실험 ID	exp-2026-q2-cta-color
가설	빨강 CTA +1.5%p
표본 (그룹당)	8,200 / 8,150
SRM 검정 p-value	0.42 (균형 OK)
Primary KPI 효과	+1.8%p (95% CI: +0.9%p - +2.7%p)
Sequential test 결과	유의 (p = 0.018)
운영 의미	ROPE ±1%p 밖, 의미 있음
결정	B안 채택, 전체 노출 전환

이 양식이 실험 플랫폼의 출력으로 자동 생성되면 의사결정 속도가 크게 빨라짐.

7. 외부 SaaS vs 사내 플랫폼 트레이드오프

항목	외부 SaaS (Optimizely, VWO)	사내 플랫폼
도입 속도	빠름	6-12개월
비용	월 $1K-10K+	인건비·인프라
마케팅 데이터 통합	약함	강함 (CDP·BQ 직결)
통계 도구	표준 (Sequential, Bayesian 내장)	직접 구현
커스터마이징	제한적	자유
운영 부담	거의 없음	큼

소규모 팀: 외부 SaaS. 대규모 팀(분기 100+ 실험): 사내 플랫폼이 비용·통합 우위.

8. 마치며 — 실험 플랫폼은 마케팅의 인프라

마케팅 의사결정의 신뢰도가 분기마다 올라가려면 실험 플랫폼이 5가지 원칙 위에 깔려 있어야 합니다. split assignment, exposure log, SRM 자동 검정, sequential safe 분석, 메타 표준화 — 한 가지라도 빠지면 결과가 흔들리고 의사결정자가 데이터를 안 믿게 됩니다. 마케터가 그 5가지를 알면 분석 결과 회의에서 정직한 질문을 던지고 정직한 답을 받을 수 있습니다.

다음 분기에 한 번만 시도해 볼 만한 것은 사내 실험 플랫폼의 메타데이터 등록·SRM 자동 검정 두 가지를 표준화하는 흐름입니다. 두 가지만 깔려도 분기 실험의 신뢰도가 한 단계 올라갑니다.

다음에 읽을 글

Sequential testing — 매번 봐도 정직한 통계
Power analysis · MDE — 사전 등록의 표본 계산
Simpson's Paradox — SRM 안 잡았을 때의 함정

참고

Kohavi, Tang, Xu (2020), "Trustworthy Online Controlled Experiments": https://www.amazon.com/Trustworthy-Online-Controlled-Experiments-Practical/dp/1108724264
"ExP platform" (Microsoft): https://www.exp-platform.com/
"Statistical methods in online controlled experiments" (Microsoft): https://www.microsoft.com/en-us/research/group/experimentation-platform-exp/
"Always Valid Inference" (Optimizely): https://research.optimizely.com/
"Stats engine" (VWO): https://vwo.com/downloads/VWO_SmartStats_technical_whitepaper.pdf

LLM evaluation harness — 분기마다 챗봇 품질을 자동 평가하는 공장

Aramir — Sat, 16 May 2026 18:09:14 +0900

챗봇·에이전트가 운영에 들어가면 한 번 평가가 아니라 분기 자동 평가가 필요합니다. 골든셋·regression·hyperparameter A/B를 묶는 evaluation harness 설계와 마케팅 자리에서의 적용.

RAG 챗봇·LLM 에이전트가 운영에 들어가면 한 번 평가하고 끝이 아닙니다. 모델 버전이 바뀌고, 프롬프트가 다듬어지고, 새 컨텍스트가 추가될 때마다 품질이 흔들립니다. evaluation harness는 분기마다 자동으로 모든 변화를 점검하는 공장이고, 사내 챗봇 품질의 운영 안정성을 결정합니다.

마케터가 이 글을 읽어야 하는 이유: 사내 RAG 챗봇·자동화 에이전트가 점점 늘어나는데, 그 품질이 분기마다 어떻게 변하는지 추적이 안 되면 사고가 사용자 보고로만 발견됩니다. evaluation harness는 그 사고를 사전 알림으로 잡는 표준 도구이고, 마케터·운영자가 도구의 골격을 알면 어떤 자리에 도입해야 할지 결정 가능.

모델·프롬프트가 바뀔 때마다 자동으로 50개 골든셋이 돌아간다 — 사고를 사용자보다 먼저 잡는 공장.

1. Evaluation harness의 한 줄 직관

골든셋(질문·기대 답변 묶음)을 입력으로, 여러 LLM 설정(모델·프롬프트·컨텍스트)을 자동 실행하고, 결과 점수를 비교 가능한 형태로 저장하는 시스템.

수동 평가의 한계:

사람이 매번 50개 답변을 읽어 점수 매기기 → 분기 1회도 어려움
모델·프롬프트 변경마다 처음부터 다시 → 비교 불가능
결과가 한 번 보고 사라짐 → 추세 추적 불가

harness는 이 세 가지를 자동화합니다.

2. 4가지 핵심 컴포넌트

2-1. 골든셋(golden set)

질문·기대 답변·컨텍스트의 묶음. 50-200개가 표준. 분기마다 갱신.

필드	의미
question	사용자 질문
expected_answer	기대 답변 또는 핵심 fact
context_docs	답변에 필요한 문서 ID
difficulty	easy/medium/hard
category	도메인 분류 (FAQ, 데이터 조회, 액션 등)

2-2. 실행 엔진(runner)

여러 LLM 설정을 병렬로 실행. 같은 골든셋을 GPT-5 vs Claude Sonnet에 동시 투입해 비교.

2-3. 점수 매기기(scorer)

Ragas 같은 라이브러리로 4개 지표 자동 계산:

Context relevance
Context recall
Faithfulness
Answer relevance

2-4. 결과 저장·비교(tracker)

각 실행의 결과를 SQL·JSON·MLflow에 저장. 분기 추세·configuration 비교가 자동.

3. 데이터 플로우 표준 흐름

골든셋 (50-200개 질문)
        │
        ▼
실행 엔진 — N개 configuration 병렬
   ├ GPT-5 + 프롬프트 v1
   ├ GPT-5 + 프롬프트 v2
   ├ Claude Sonnet + 프롬프트 v1
   └ Claude Sonnet + 프롬프트 v2
        │
        ▼
점수 매기기 — 4지표 × N config
        │
        ▼
결과 비교 표
   config × 지표 매트릭스
        │
        ▼
회귀 비교 — 지난 분기 결과 vs 이번 분기
        │
        ▼
보고 생성 (자동)

이 한 흐름이 마케팅 챗봇의 분기 품질 보고를 자동화.

4. 코드 한 묶음 — Pytest 스타일 harness

이게 글에 박는 유일한 코드입니다.

코호트 LTV 곡선 — 누적 매출 그래프 그리고 해석하기

Aramir — Sat, 16 May 2026 18:08:22 +0900

평균 LTV 한 숫자로는 채널·시즌·세그먼트 차이가 안 보입니다. 코호트별 누적 매출 곡선을 그려 그 차이를 시각적으로 잡고, 곡선 모양으로 운영 결정을 내리는 표준 워크플로.

"이 채널 LTV $180 입니다 ." 한숫자가회의에던져집니다 . 그런데그 L T V 가평균이라면, 어느코호트는$ 400이고 어느 코호트는 $80일 수 있습니다. 코호트 LTV 곡선은 그 차이를 한 그래프로 보여주고, 곡선 모양 자체가 운영 결정의 근거가 됩니다.

마케터가 이 글을 읽어야 하는 이유: 분기 회의에서 LTV 평균만 들고 가면 의사결정자가 "그래서 어느 자리에서 그 평균이 나왔어?"를 묻습니다. 코호트 곡선이 그 자리를 시각적으로 답합니다. 곡선이 빠르게 평탄화되면 churn 문제, 천천히 우상향이면 재구매 강함, 한 번 떨어지고 회복 안 되면 이슈 발생 시점 — 곡선 모양 한 번 보면 운영 진단이 즉답.

평균 한 숫자가 못 보여주는 입체. 곡선 모양 자체가 진단.

1. LTV 곡선의 한 줄 직관

한 코호트(같은 시점에 획득한 사용자 묶음)의 누적 평균 매출을 시간 축에 그린 그래프.

X축이 코호트 시작 후 경과 시간(월), Y축이 그 시점까지 누적된 사용자 1인당 매출.

경과 월	A코호트 누적 LTV	B코호트 누적 LTV
1	$30	$25
3	$55	$40
6	$85	$55
12	$145	$75
24	$220	$90

평균 LTV (12개월 = $110) 가같아도 A 는 24 개월에$ 220, B는 $90으로 곡선 모양이 완전 다름. 의사결정에 이 차이가 결정적.

2. 코호트 정의 — 어떻게 묶을까

코호트는 같은 시점에 획득한 사용자 묶음. 자주 등장하는 묶음 기준.

2-1. 획득 월

가장 흔한 기준. 2026-Q1·Q2·Q3 등 분기 단위 또는 월 단위.

2-2. 획득 채널

Meta·Google·Naver 등 채널별로 코호트 분리. 채널별 LTV 곡선 비교가 분기 의사결정의 핵심 자리.

2-3. 캠페인·크리에이티브

특정 캠페인이나 크리에이티브로 들어온 사용자만 묶기. 캠페인 단위 평가에 적합.

2-4. 첫 구매 카테고리

첫 구매 카테고리(전자기기·의류·식품 등)별로 묶어 LTV 차이 측정.

코호트 기준	자주 쓰는 자리
획득 월	분기 트렌드·시즌 효과
채널	채널 간 LTV 비교
캠페인	캠페인 평가
첫 카테고리	카테고리 전략
첫 구매 가격대	가격 정책

3. 4가지 표준 곡선 모양

LTV 곡선의 모양이 곧 운영 진단입니다.

3-1. 가파른 우상향 — 우수

처음 1-3개월에 빠르게 누적, 그 이후 안정적 추가 매출. 재구매·구독 강한 자리.

  $250 |              ___------
  $200 |          __--
  $150 |       _-/
  $100 |    _-/
   $50 | _-/
       +-----+-----+-----+-----+
         3m   6m   12m  18m

진단: 이 채널·세그먼트에 예산 추가 투입.

3-2. 빠른 평탄화 — Churn 문제

처음 한두 달은 매출 좋고, 그 이후 거의 평평. 첫 구매 후 떠나는 사용자 많음.

  $100 |     ____________________
   $80 |    /
   $40 |   /
   $20 |  /
       +-----+-----+-----+-----+
         3m   6m   12m  18m

진단: post-purchase journey, retention 캠페인 도입 검토.

3-3. S-curve — 늦게 활성화

초반은 약하고 6-9개월쯤부터 매출 급증. 학습·신뢰 형성 후 사용 본격화 패턴.

  $200 |                ____------
  $150 |             __-/
  $100 |          __-/
   $50 |    _____/
       +-----+-----+-----+-----+
         3m   6m   12m  18m

진단: 회수 시간이 길지만 LTV는 큼. 자본 여유 시 가치 큰 자리.

3-4. 톱니형 — 시즌·이벤트 의존

특정 시기(연말·세일)마다 급증, 다른 시기엔 평탄. 일정 의존도 높음.

  $150 |          __-/-_____-/
  $100 |       __/
   $60 |    __/
   $30 |  _/
       +-----+-----+-----+-----+
         3m   6m   12m  18m

진단: 시즌 외 retention 약점. 평상시 캠페인 강화.

4. 코드 한 묶음 — 코호트 곡선 그리기

이게 글에 박는 유일한 코드입니다.


ax.legend(); ax.grid(alpha=0.3)
plt.tight_layout(); plt.savefig("ltv_curve.png", dpi=150)

이 한 묶음이 코호트 LTV 곡선의 표준 시각화. 채널별 비교가 한 그래프에.

5. 곡선에서 읽는 의사결정 신호 5가지

5-1. 12개월 LTV 절대치

각 채널·세그먼트의 12개월 누적 LTV가 LTV/CAC 비율의 기반. 절대치 비교가 첫 단계.

5-2. 곡선 기울기

기울기가 가파른 자리는 재구매 강함. 평평한 자리는 첫 구매 의존.

5-3. 손익분기 시점 (CAC 회수)

곡선이 CAC 라인 넘는 시점이 payback period. 짧을수록 좋음.

5-4. 코호트 간 변동성

같은 채널 다른 월 코호트의 곡선이 비슷한 모양인지. 변동성 크면 운영 안정성 약함.

5-5. 시즌·이벤트 영향

특정 코호트가 다른 모양이면 그 시기에 시즌·이벤트·정책 변화 의심.

6. LTV 곡선의 한계와 보완

6-1. 미래 추정의 한계

12개월 코호트 곡선이 24개월 LTV를 정확히 예측 못 함. BG/NBD 같은 확률 모델(bgnbd-ltv-prediction)이 미래 LTV 추정의 표준.

6-2. 자가 선택 편향

ROAS 좋은 채널은 광고 자체가 더 자주 좋은 사용자에게 노출됨. LTV 곡선이 채널 효과인지 사용자 차이인지 분리 어려움.

6-3. 외부 요인

경기·경쟁·브랜드 인지도 변화가 LTV에 영향. 같은 채널의 분기 코호트가 다른 모양이면 외부 요인 의심.

6-4. Right-truncation

가장 최근 코호트는 데이터가 짧아 12개월 LTV 알 수 없음. 6개월 LTV로 12개월 LTV 추정하는 모델 필요.

7. 분기 보고에 박을 표 양식

채널	12mo LTV	곡선 기울기	Payback	변동성	판단
Meta retargeting	$185	가파름	1개월	낮음	적극 확장
Naver 검색	$220	표준	5개월	낮음	표준
TikTok prospecting	$110	평평	9개월	높음	retention 캠페인 도입
Display	$130	톱니	14개월	매우 높음	시즌 의존 — 분기별 분석

LTV 절대치만 보면 Naver가 1위지만, 곡선 기울기·payback·변동성을 함께 보면 Meta retargeting이 운영 안정성 우위.

8. 마치며 — 평균 한 숫자가 가린 진실

평균 LTV 한 숫자는 코호트 간 차이·곡선 모양·시간 변동성을 모두 가립니다. 코호트별 LTV 곡선을 한 그래프에 두는 것만으로 분기 회의의 의사결정 입력이 입체적이 되고, "왜 이 채널?"의 답이 데이터로 따라옵니다.

다음 분기에 한 번만 시도해 볼 만한 것은 채널별 코호트 LTV 곡선을 한 슬라이드에 두고 4가지 모양(가파른·평탄·S·톱니)으로 분류하는 흐름입니다. 분류 자체가 다음 분기 액션을 정해줍니다.

다음에 읽을 글

BG/NBD LTV 예측 — 미래 LTV 확률 모델링
CAC payback period — 곡선의 손익분기 시점
Retention curve cohort — LTV 곡선의 형제 도구

참고

"Cohort analysis 101" (Mode): https://mode.com/blog/cohort-analysis/
"LTV cohort curves in DTC" (Common Thread): https://commonthreadco.com/
"Cohort retention" (Reforge): https://www.reforge.com/
"Customer LTV" (HBR, 2014): https://hbr.org/
"Right-truncation in LTV estimation" (Fader & Hardie): https://www.brucehardie.com/papers/

웹 CRO 입문 — 랜딩 페이지 최적화의 핵심 6원칙과 실험 운영 표준

Aramir — Sat, 16 May 2026 18:07:34 +0900

같은 트래픽에서 매출만 1.5배 만드는 게 CRO입니다. 랜딩 페이지의 6원칙(clarity·urgency·friction·social proof·value prop·trust)부터 실험 운영·도구·KPI까지 한 글로.

광고비를 늘리지 않고 매출을 1.5배 만드는 가장 빠른 길은 CRO(Conversion Rate Optimization)예요. 들어오는 트래픽은 그대로, 그 트래픽이 더 자주 사는 사이트로 바꾸는 일. 그런데 CRO를 처음 시작하면 "버튼 색을 빨강으로 vs 초록으로" 같은 표면적인 실험에 빠지기 쉽습니다. 진짜 CRO는 사이트의 6가지 원칙을 점검하는 일이에요. 이 글은 랜딩 페이지 CRO의 6원칙과 실험 운영 표준을 한 글로 정리합니다.

CRO가 왜 광고보다 효율 높은가

같은 자리에서 매출을 늘리는 두 갈래.

광고비를 늘려 트래픽을 늘리기 (스케일링)
트래픽 그대로 두고 conversion을 늘리기 (CRO)

CRO의 한 가지 강점은 한 번 만들면 영구적이라는 점. 한 분기 CRO로 conversion이 1.2배가 되면 그 다음 분기에도 자동으로 1.2배예요. 광고비는 매달 지출이지만 CRO는 자산입니다.

다만 CRO에도 한계가 있어요. 자기 매체의 baseline conversion이 ceiling에 가까우면 추가 개선 어려워집니다. 보통 첫 사이트 audit으로 3-5개 큰 문제를 찾고, 그것만 잡아도 conversion이 1.2-1.5배 늘어요.

clarity·urgency·friction·social proof·value prop·trust — 6원칙을 점검하면 사이트의 conversion이 자연스럽게 올라간다.

6원칙 한 표 — 사이트 audit 체크리스트

원칙	한 줄 정의	점검 질문
Clarity (명확성)	"이 사이트가 뭘 파는지 5초 안에 보이나"	첫 화면 H1·sub가 가치를 명확히 말하나
Urgency (긴급성)	"지금 사야 할 이유가 있나"	시간 한정·재고 표시·early bird 같은 신호
Friction (마찰)	"사는 게 얼마나 쉽나"	form 필드 수·결제 단계 수·sign up 필수 여부
Social proof (사회적 증거)	"남들도 쓰나"	사용자 수·리뷰·logos·case study
Value prop (가치 제안)	"왜 경쟁사 말고 우리인가"	차별점 한 줄·benefit 3개·price
Trust (신뢰)	"이 사이트 안전한가"	보안·환불·고객 응대·법적 정보

audit은 이 6가지 질문을 자기 사이트에 던지는 일이에요. 한 원칙이라도 약하면 conversion이 그만큼 깎입니다.

원칙 1 — Clarity (명확성)

사용자는 사이트 도착 후 5초 안에 "이 사이트가 뭘 파는가"를 판단합니다. 첫 화면의 H1·sub·hero 이미지가 그 답을 명확하게 전달해야 해요.

흔한 실수:

H1이 슬로건 (의미 모호) — "더 나은 삶, 더 가까운 미래"
사용자 가치가 아닌 회사 자랑 — "업계 1위, 100만 고객"
너무 많은 정보로 첫 화면 가득 채우기
가치 제안과 무관한 hero 이미지

좋은 H1 패턴:

"[누구]가 [무엇]을 [어떻게] 한다" — "마케터가 매체 데이터를 BI에서 본다"
"[목표]를 [방법]으로" — "ROAS를 베이지안 신뢰구간으로"

H1을 사용자 가치로 바꾸면 conversion이 10-30% 늘어나는 일이 흔해요. 가장 cost-efficient한 CRO 첫 작업.

원칙 2 — Urgency (긴급성)

사람은 손해를 회피하기 위해 빠르게 결정합니다. "지금 안 사면 손해"라는 신호가 있으면 결정이 빨라져요.

표준 urgency 패턴:

시간 한정 (24시간 할인·이번 주말까지)
재고 한정 (이 사이즈 3개 남음·매진 임박)
early bird (사전 예약 -30%)
countdown timer
limited edition·시즌 한정

윤리적 경계가 있어요. 거짓 재고·가짜 카운트다운은 단기 conversion은 올려도 장기 trust와 reputation을 깨요. 진짜 urgency를 만들거나, urgency 없이 다른 원칙으로 가는 게 낫습니다.

원칙 3 — Friction (마찰)

마찰은 사용자가 conversion에 도달하기까지의 모든 장애물. 줄이면 줄일수록 conversion이 올라요.

흔한 마찰 자리:

form 필드가 너무 많음 (요청 정보 줄이기)
sign up 필수 (guest checkout 옵션)
결제 단계가 너무 많음 (1-page checkout)
이메일 인증 필수 (소셜 로그인)
모바일에서 폼 입력 어려움 (autofill·numeric keyboard)
페이지 로딩 느림 (LCP 3초 넘으면 conversion 절반)

form optimization 1개로 conversion이 25%까지 늘어난 사례가 흔해요. 필수가 아닌 필드를 다 빼고, 필요하면 결제 후에 받는 progressive disclosure.

원칙 4 — Social Proof

남들이 쓴다는 신호는 사용자가 망설이지 않게 만들어요. 특히 처음 방문 사이트에서 결정적입니다.

활용 자리:

사용자 수 ("100,000명이 이용 중")
리뷰 별점·실제 인용 ("이 제품 진짜 좋아요" - 김ㅇㅇ)
신뢰 로고 (B2B의 client logo wall)
미디어 언급 (TechCrunch·매체 언급)
case study·success story
live activity ("방금 ㅇㅇ님이 구매했어요")

원칙 — 진짜 데이터로만, 인용은 실명·사진 같이. 가짜 리뷰는 발각되면 trust가 무너집니다.

원칙 5 — Value Proposition

"왜 경쟁사 말고 우리인가"의 답이 첫 화면에 있어야 해요. 사용자는 다른 옵션을 두고 비교하기 때문에 차별점이 명확해야 합니다.

좋은 value prop 구조:

한 줄로 핵심 차별점
3개의 benefit 묘사
가격 또는 가격 모델 명시
(선택) 경쟁사 직접 비교 표

가격을 숨기는 사이트는 보통 conversion이 낮아요. enterprise B2B는 "contact for pricing"이 맞지만 SaaS·이커머스는 가격 명시가 표준입니다.

원칙 6 — Trust

사용자가 결제 직전 가장 자주 이탈하는 자리가 trust 신호 부족이에요. 결제 직전에 다음이 보여야 합니다.

환불·교환 정책
보안 인증 (SSL·PG·보안 logo)
고객 응대 채널 (전화·채팅·FAQ)
회사 정보 (법인 정보·주소·사업자 등록)
리뷰·평점 (정직한 평균치)

iOS App Store에서 트래픽 들어오는 경우 ATT 동의·privacy label 같은 신호도 trust 요소예요.

실험 운영 표준 — CRO를 A/B로

CRO는 가설을 A/B로 검증하는 일이에요. 매주 가설 1-2개를 검증하면 1년에 50-100개 학습이 쌓입니다.

실험 운영 표준:

가설 backlog 우선순위 (ICE: Impact·Confidence·Ease)
MDE(Minimum Detectable Effect)와 표본 수 계산
한 번에 1 페이지·1 변수만 (multi-variate는 후순위)
통계적 유의 + 실용적 유의 (5% lift가 의미 있는가)
종료 후 결과 문서화 (배운 것·다음 가설)

도구: Google Optimize는 종료됐고 지금은 VWO·Optimizely·Convert·자체 framework 사용. 무료로 시작하려면 GA4 audience + URL 분기 + custom segment로도 일정 수준 가능해요.

mab-vs-ab-testing·cuped-variance-reduction·ab-test-pitfalls에서 실험 통계의 깊은 자리를 다뤘습니다.

CRO 측정 — Funnel KPI

CRO의 KPI는 단순 conversion rate가 아니라 funnel 전체. 어느 단계가 약한지 알아야 어디를 고칠지 결정합니다.

표준 funnel 예시 (이커머스):

단계	이상적 conversion
방문 → 상품 페이지	30-50%
상품 페이지 → 장바구니	5-15%
장바구니 → 결제	60-80%
결제 → 완료	70-90%

이 표 자기 회사 숫자와 비교해서 가장 낮은 단계를 우선 개선. 한 단계 5% 올리면 매출 5% 늘어요.

heatmap·session replay (Hotjar·Microsoft Clarity·FullStory)로 어느 자리에서 사람이 멈추는지 보고, A/B로 가설 검증.

마치며

CRO는 거창한 일이 아니라 6원칙 체크리스트를 자기 사이트에 던지는 일에서 시작해요. 첫 1주는 audit, 그 다음부터 매주 가설 1개 실험. 1년 50개 실험이 누적되면 자기 사이트가 다른 사이트가 됩니다.

다음 글로는 Meta·Google·TikTok 픽셀 + CAPI 설치에서 측정 정합성, 웹 퍼널 세그먼트 설계에서 트래픽 분해를 다룹니다.

참고

Baymard Institute — UX research for ecommerce
Conversion Sciences blog
Speed matters: Google research on page speed
Cialdini's principles of influence (책)
사내 글: A/B 테스트 흔히 빠뜨리는 5가지
사내 글: MAB vs A/B
사내 글: CUPED 분산 축소
사내 글: Power analysis·MDE

스타트업 데이터팀 채용 — 1번 데이터 사람 뽑기와 첫 90일 온보딩

Aramir — Sat, 16 May 2026 18:06:42 +0900

스타트업이 처음 데이터 사람을 뽑을 때 가장 자주 깨지는 자리는 역할 정의·면접 기준·온보딩 90일. ICP·면접 셋·90일 마일스톤·흔한 실수를 한 글로 정리합니다.

스타트업이 처음 데이터 사람을 뽑을 때 가장 자주 깨지는 자리는 "어떤 사람을 뽑아야 하는지"부터 모호한 채로 채용 공고를 올리는 거예요. data scientist vs analytics engineer vs analyst의 차이도 모호하고, 면접에서 무엇을 보고 합격 시킬지도 흩어지고, 채용 후 첫 90일에 무엇을 시킬지 정리가 안 됩니다. 이 글은 스타트업의 1번 데이터 채용을 디자인하는 가이드. ICP·면접 셋·90일 마일스톤·자주 실패하는 패턴까지.

왜 1번 데이터 채용이 어려운가

스타트업이 데이터팀을 처음 만들 때 어려운 이유 5가지.

회사가 뭐가 필요한지 모름 (analyst·engineer·scientist 다 다름)
면접관이 데이터 직무를 깊게 모름
senior 1명이 모든 걸 해줄 거라 기대 (현실은 갭이 큼)
채용 후 시키는 일이 broad ("뭐든 다 봐주세요")
첫 6개월 결과가 안 보이면 채용 자체가 실패로 보임

이 5가지가 동시에 깨지면 6개월 후 채용한 사람이 떠나거나 회사가 데이터 효용을 못 느껴 추가 채용을 미뤄요.

ICP 정의 → 면접 셋 → 첫 90일 마일스톤. 1번 데이터 채용 성공 패턴은 3단계의 명확함.

데이터 직무 3가지 — 어느 ICP인가

스타트업 1번 채용에서 가장 먼저 풀어야 할 질문이 "어떤 직무인가". 세 가지가 본질적으로 달라요.

직무	주력	산출물	도구
Analyst	SQL·BI·domain	보고서·대시보드·ad-hoc 분석	SQL, Looker, Tableau
Analytics Engineer	데이터 모델링·파이프라인	dbt 모델·신뢰할 fact table	dbt, BigQuery, Airflow
Data Scientist	ML·실험·통계	모델·실험·예측	Python, ML libraries

회사 단계별 1번 채용 추천.

시드-시리즈 A (직원 1-30명): Analyst. 비즈니스 질문에 빠르게 답하고 SQL·BI를 직접 만들어야 함
시리즈 A-B (직원 30-100명): Analytics Engineer. 데이터 모델·파이프라인을 정비해야 다음 분석이 굴러감
시리즈 B+ (직원 100+명): Data Scientist. 모델·실험·예측이 회사 의사결정에 들어감

대부분 스타트업의 1번 채용은 Analyst가 맞아요. ML·deep learning 사람을 너무 일찍 뽑으면 데이터 인프라가 약해서 모델을 못 굽니다.

ICP가 명확해진 다음 — 채용 공고

좋은 채용 공고의 5가지 요소.

회사 단계·맥락 (어디까지 와있고 어디 가는지)
이 직무가 해결할 진짜 문제 (3-5개 구체 예시)
첫 90일 성공 기준
필요 스킬 vs 좋으면 좋은 스킬 분리
같이 일할 사람·보고 라인·자율성 수준

흔한 안티패턴 — "데이터에 관심 있는 분", "SQL·Python·R·Tableau·dbt·Airflow·SQL·BigQuery·Snowflake 다 가능한 분". 둘 다 지원자가 무엇을 기대받는지 모릅니다.

면접 셋 4단계

표준 채용 면접 구조.

단계	시간	평가
1. 전화·줌 스크리닝	30분	동기·기본 fit·연봉 범위
2. 기술 면접	60-90분	SQL·통계·도구 깊이
3. 케이스 인터뷰	60분	비즈니스 문제 푸는 사고
4. 컬처 fit·임원 면접	45분	회사 가치·장기 fit

각 단계에서 명확한 합격·불합격 기준이 있어야 면접관 별로 흩어지지 않아요.

기술 면접의 SQL 질문 예시:

"한 user의 N번째 구매 추출" (window function)
"30일 rolling retention rate 계산"
"두 table을 outer join 후 NULL 처리"
"PII 노출 없이 cohort size 보고"

지원자가 답하면서 가정·trade-off를 같이 설명하는지가 진짜 평가 자리.

케이스 인터뷰의 핵심

기술이 강해도 케이스 인터뷰에서 깨지는 사람이 많아요. 케이스는 "비즈니스 문제 → 데이터 가설 → 분석 설계 → 결론"의 전 흐름을 보는 자리.

좋은 케이스 예시.

"마케팅 채널 5개 중 어디를 줄일지 어떻게 판단할까?"
"신규 user의 첫 7일 retention이 갑자기 떨어졌다. 어떻게 디버깅?"
"A/B 테스트 결과가 통계적으로 유의했는데 매출이 늘지 않았다. 무엇을 확인?"

지원자가 가정·데이터 점검·여러 가설 비교·우선순위·결론까지 가는 흐름을 보여줘야 합니다. 단답이 아니라 사고 과정.

채용 후 90일 마일스톤

채용했다고 끝이 아니에요. 첫 90일이 회사·사람 둘 다의 fit을 결정합니다.

표준 90일 마일스톤 (Analyst 기준).

시기	목표
Week 1-2	도구·데이터·codebase 온보딩, 1:1 stakeholder 소개
Week 3-4	첫 ad-hoc 분석 1개 (작은 비즈니스 질문)
Week 5-8	핵심 대시보드 audit·1개 새 dashboard 출시
Week 9-12	1개 자기 주도 분석 프로젝트 + 사내 발표

90일 후 다음 분기 우선순위를 같이 정하고 본격 운영. 90일 안에 첫 성과 1개를 같이 만드는 게 사람과 회사 모두에게 큰 모멘텀이에요.

첫 90일 온보딩의 안티패턴

첫 주에 너무 많은 도구·문서를 한 번에 던지기
첫 한 달 동안 의미 있는 산출물 없이 read-only 상태
1:1을 안 잡거나 너무 적게 잡기
ad-hoc 요청을 무한정으로 받음 (포커스 깨짐)
"데이터 인프라부터 다시 정리해주세요" 같은 6개월 짜리 큰 일

90일 안에는 작지만 visible한 성공을 만드는 게 우선. 큰 인프라 작업은 90일 이후로 미뤄야 운영 fit을 보여줄 수 있어요.

데이터팀 1명에서 3명으로 가는 길

1번 채용이 성공하면 다음은 누구를 뽑을까. 패턴.

1명: Analyst (broad coverage)
3명: + Analytics Engineer (인프라 정비) + Junior Analyst
10명: + Data Scientist + Data Engineer + manager
30명: 도메인별 분리 (marketing·product·finance data팀)

1→3은 보통 18-24개월 차에 옴. 너무 일찍 ML·data engineering hire 하면 첫 사람이 외로워져요 (협업할 사람 없음).

한국 시장 특수성

영문 SQL·툴 익숙도와 한국어 비즈니스 컨텍스트 둘 다 필요
한국 직무 시장에서 "데이터 분석가"는 BA·DA·DS가 다 섞여있어 ICP 정의 더 중요
외부 채용 비용이 글로벌 대비 합리적이지만 좋은 사람의 retention이 어려움
신입·주니어 풀에 부트캠프 출신이 많아져서 코드·통계 기본기 점검 필수
LinkedIn보다 wanted·remember·잡코리아·원티드 인사이트가 1차 채용 채널

마치며

스타트업 1번 데이터 채용은 "어떤 사람을 뽑을까"보다 "그 사람이 어떤 환경에서 6개월 동안 첫 성과를 만들지"를 먼저 디자인하는 일이에요. 그 디자인이 명확하면 채용 자체가 쉬워지고 retention도 따라옵니다.

다음 글로는 스타트업 마케팅 조직 설계·stakeholder 커뮤니케이션 표준으로 이어집니다.

참고

Locally Optimistic — Data team blogs
dbt — analytics engineering 정의
Brittany Bennett — building a data team
Erik Bernhardsson — building analytics teams
Reforge — Data Strategy course
사내 글: CRM 라이프사이클 메시징
사내 글: AARRR 진짜 운영
사내 글: LLM cost guardrails

광고 SQL·BI 안티패턴 7가지 — ROAS 보고서를 거짓말로 만드는 SQL 함정

Aramir — Sat, 16 May 2026 18:05:53 +0900

광고 데이터를 SQL로 집계할 때 반복적으로 깨지는 7가지 패턴 — 중복 조인·attribution window 누락·시간대 미스·conversion lag·환율·채널 매핑·dedup. 마케터·BI팀이 실무에서 만나는 함정을 실제 SQL 반례와 함께 정리합니다.

"Meta는 ROAS 5.2라는데, GA4는 3.8이고, BI팀이 BigQuery로 다시 뽑은 건 9.6이에요." 어느 회의에서나 흔한 풍경입니다. 셋 다 다른 데이터를 봤다면 차이가 나는 게 당연한데, 진짜 무서운 건 같은 raw event를 두 사람이 SQL로 집계했는데 ROAS가 30% 차이 나는 경우입니다. 거의 모든 경우 원인은 데이터가 아니라 SQL 한 줄이에요. 이 글은 광고 데이터를 SQL로 집계할 때 마케터·BI팀이 반복적으로 빠지는 7가지 안티패턴을 정리합니다. 각각 어떻게 ROAS를 왜곡하는지, 어떻게 잡는지까지.

왜 SQL 한 줄이 ROAS 30%를 바꾸나

광고 데이터는 다른 도메인 데이터와 결이 다릅니다. 한 유저가 같은 캠페인을 4번 보고, 그 사이에 3번 사이트를 들렀다가, 마지막에 다른 디바이스로 구매하는 일이 일상입니다. 이걸 표 한 장으로 만들 때 SQL은 마법을 부려야 합니다.

impression·click·event 테이블이 따로
attribution window가 채널마다 다름
같은 user가 cookie·gaid·email_hash로 흩어져 있음
광고비는 매체 통화, 매출은 자사 통화
보고 시점마다 conversion lag로 어제 수치가 바뀜

이 다섯 가지가 동시에 들어오면 SQL은 굉장히 미묘해집니다. 운이 나쁘면 한 줄 잘못 짜서 ROAS가 두 배로 나오기도 하고, 운이 좋으면 한 분기 동안 모르고 지나가기도 합니다. 그래서 광고 SQL은 "맞다/틀리다"가 아니라 "어떤 안티패턴을 피했나"의 게임이에요.

JOIN·timezone·lag·환율·UTM·dedup — 각각 한 줄 잘못 짜면 ROAS가 30%씩 흔들리는 7가지 함정.

이 글은 BigQuery 기준으로 예시를 들지만 Snowflake·Redshift·Postgres 어디서나 동일한 함정이에요. 한 번에 다 외울 필요는 없고, BI팀과 마케팅팀의 숫자가 안 맞을 때 위에서부터 체크리스트로 쓰면 됩니다.

함정 1 — Fan-out 중복 조인

가장 흔하고, 가장 큰 폭의 오류를 만드는 패턴입니다. 광고비 테이블과 전환 테이블을 단순 JOIN으로 붙이면 한 행이 N행으로 부풀어 매출이 N배가 됩니다.

상황을 그려볼게요. 광고비 테이블 ad_spend는 캠페인·날짜 단위로 한 행씩 있습니다. 전환 테이블 conversions는 한 user의 한 구매가 한 행입니다. 한 캠페인의 하루에 구매가 50건 있다면 단순 JOIN의 결과는 어떻게 될까요.

-- ❌ 안티패턴: spend가 50번 복제되어 매출이 정상이지만 spend가 50배가 된다
SELECT
  s.campaign_id,
  s.date,
  SUM(s.spend) AS spend,        -- 50배 부풀려진다
  SUM(c.revenue) AS revenue
FROM ad_spend s
JOIN conversions c
  ON s.campaign_id = c.campaign_id
 AND s.date = DATE(c.event_time)
GROUP BY 1, 2

이 쿼리는 ad_spend의 한 행을 conversions의 50행과 카르테시안 조인합니다. SUM(s.spend)가 50배가 되어 ROAS가 1/50로 찍히죠. 운 좋게 매출 쪽이 부풀려지는 케이스라면 반대로 ROAS가 N배가 됩니다.

해결은 두 갈래입니다.

먼저 dedup·집계 → 그 다음 JOIN. 전환 테이블을 먼저 GROUP BY campaign_id, date로 합쳐서 한 행으로 만든 뒤 광고비와 1:1로 붙입니다.
full-outer + COALESCE 패턴. 전환이 없는 캠페인도 살려야 하니 INNER가 아니라 FULL OUTER로 붙이고 NULL은 0으로.

이 안티패턴이 무서운 이유는 결과가 그럴듯하게 보인다는 점이에요. ROAS 0.04 같은 명백히 이상한 숫자라면 다들 알아차리지만, 1.8쯤 나오면 "광고가 좀 약한가" 하고 넘어갑니다. 한 분기를 그렇게 보내고 나서야 누가 발견하는 일이 흔합니다.

함정 2 — Attribution window 누락

광고는 오늘 클릭하고 내일 구매합니다. 어떤 카테고리는 일주일 뒤에 구매하기도 하죠. SQL을 짤 때 click과 purchase를 같은 날짜로 묶으면 이 lag가 다 빠집니다.

흔한 잘못된 패턴은 click과 purchase를 user_id로 묶을 때 click.date = purchase.date 같은 등치 조건을 같이 넣는 것입니다. 이렇게 짜면 클릭한 당일에 구매한 케이스만 매칭되고 D+1 이후는 전부 attribution에서 빠져요. 단순 등치가 아니라 BETWEEN click.timestamp AND TIMESTAMP_ADD(click.timestamp, INTERVAL N DAY) 같은 윈도우 매칭이 표준입니다.

광고 채널별로 표준이 다른 attribution window가 있습니다.

채널	기본 window	비고
Meta	click 7d / view 1d	캠페인 옵션으로 28d까지
Google Ads	30d	data-driven은 더 유연
TikTok	click 7d / view 1d
Naver SA	14d	캠페인 설정
MMP (Appsflyer·Adjust)	click 7d / install 30d	앱 기준

이 window를 채널마다 다르게 적용해야 같은 보고서가 됩니다. 한 SQL에 모두 7일로 통일하면 Google Ads의 D+10 전환이 다 빠지고, 모두 30일로 통일하면 Meta·TikTok에서 view-through가 7배쯤 부풀려집니다.

해결 패턴:

채널별 window를 설정 테이블로 분리합니다. channel_attribution_config(channel, click_window_days, view_window_days) 같은 lookup.
매칭 조건은 BETWEEN click_time AND TIMESTAMP_ADD(click_time, INTERVAL window DAY)로 씁니다.
view-through는 별도 컬럼으로 분리해 두고, 보고서에서 켜고 끄게 합니다.

함정 3 — Timezone 미스매치

Meta API는 광고주 시간대를 기본으로 주지만 일부 endpoint는 UTC, GA4 BigQuery export는 이벤트 시점 UTC, 사내 주문 DB는 KST. 이 네 개를 같은 "5월 16일"로 집계하면 광고비와 매출이 각각 다른 24시간을 보고 있게 됩니다.

흔한 증상.

매일 9시에 도는 잡이 어제 ROAS를 뽑는데, KST 자정 직후 1시간의 전환이 사라진다
월요일 ROAS가 항상 낮고 일요일 ROAS가 높다 (광고비는 토~~일, 매출은 일~~월 카운팅)
광고 매체와 BI의 ROAS 차이가 정확히 "하루 정도의 비율"로 일정하다

해결은 단순합니다. 모든 timestamp를 한 timezone(보통 KST)으로 정규화한 다음 그 위에서 날짜를 만들어요. BigQuery라면 DATE(TIMESTAMP(event_timestamp), 'Asia/Seoul') 한 줄, Snowflake라면 CONVERT_TIMEZONE('UTC', 'Asia/Seoul', event_ts)::DATE처럼 표준 함수 한 줄로 처리합니다. 핵심은 raw layer가 항상 UTC라는 약속을 깨지 않는 거예요.

매체 API는 time_increment=1 옵션을 쓸 때 광고주 timezone으로 쪼개주지만, 통화·환율 변환과 섞이면 다시 깨집니다. 정책은 항상 같은 것이 좋아요. raw layer는 UTC로 통일해서 저장, 보고 layer에서 KST로 변환. dbt 같은 변환 도구를 쓴다면 timezone 변환 매크로를 만들어두면 안전합니다.

함정 4 — Conversion lag와 진행 중 데이터

어제 ROAS를 오늘 봤더니 2.3이었는데, 다음 주에 다시 보니 3.1이 됐습니다. 데이터가 바뀐 게 아니라 conversion lag로 늦게 잡힌 전환이 추가된 거예요. 마케터에게는 굉장히 혼란스러운 경험입니다.

이 함정은 SQL 자체보다 운영 정책의 문제입니다. SQL은 "지금 시점의 최선의 추정치"를 매번 다시 계산하니까요. 정책 없이 매일 ROAS를 뽑으면 어제 본 숫자와 오늘 본 숫자가 다를 수밖에 없습니다.

표준 운영 정책 3가지.

T+3 freeze. 발생 후 3일 지난 데이터만 KPI로 확정. 어제·그제·오늘은 "진행 중"으로 표시.
D+7 ROAS와 D+30 ROAS를 분리해 본다. 단기 의사결정은 D+7, 분기 회고는 D+30.
스냅샷 테이블. 매일 아침 같은 시점의 ROAS를 별도 테이블에 적재해서 시점별 비교 가능하게.

dbt를 쓰면 snapshots나 incremental + invalidation 패턴으로 이걸 처리합니다. SQL만 짠다면 적어도 report_run_date 컬럼을 항상 같이 박아두는 게 안전해요.

ROAS가 시점에 따라 바뀐다는 점을 회의에서 명확히 공유하지 않으면 마케터가 매일 다른 숫자를 보고 부담을 느낍니다. "월요일에 본 지난주 ROAS는 진행 중이고, 이번주 금요일 freeze 이후가 확정"이라는 식의 룰을 팀에 박아둬야 합니다.

함정 5 — 환율과 통화 단위

다국가 캠페인을 운영하면 Meta 광고비는 USD, GA 매출은 KRW, TikTok 광고비는 USD, 일부 매체는 EUR이 섞입니다. 이걸 단순히 한 컬럼으로 합치면 1달러와 1원이 같은 무게로 더해집니다. 그러면 환율 1300배짜리 ROAS 폭탄이 만들어져요.

흔한 잘못된 패턴:

환율을 적용 안 한 채 SUM하기 (한 통화로 보면 ROAS가 1300배)
환율을 적용할 때 보고서 출력 시점 환율로 일괄 적용하기
환율을 적용할 때 transaction 시점이 아니라 batch가 도는 시점으로 적용하기

권장 패턴:

raw layer에 항상 source currency 컬럼을 같이 적재. spend_amount + spend_currency.
환율 테이블은 일별 + 통화별로 별도. fx_rate(date, from_currency, to_currency, rate).
보고 layer에서 spend_amount * fx_rate 형태로 일자별 환율을 매칭해서 KRW 변환.

이렇게 짜놓으면 분기 회고에 "당시 환율 기준"과 "기준일 환율 기준" 두 가지 ROAS를 다 볼 수 있어요. 광고비는 당시 환율로 본 값이 의사결정에 더 맞고, 회계 정산은 기준일 환율로 보는 게 맞아서 두 뷰 모두 의미가 있습니다.

함정 6 — 채널 매핑과 UTM 일관성

같은 채널이 raw data에서 네 가지 이름으로 나타납니다.

utm_source=facebook
utm_source=Facebook
utm_source=fb
utm_source=meta

GA4 UI에서는 자동으로 일부 통합되지만 BigQuery export는 raw 그대로 들어옵니다. 채널 정규화 lookup이 없으면 같은 Meta가 4개 행으로 쪼개지고, 채널별 ROAS는 다 1/4 수준으로 찍힙니다.

문제는 여기서 끝나지 않아요. 더 깊은 함정은 utm을 잘못 박은 캠페인, 마케터가 자율적으로 만든 utm 표기, 매체가 자동으로 추가하는 파라미터(gclid, fbclid)와의 우선순위입니다.

권장 정책:

채널 정규화 테이블을 1번 소스로 만들고 SQL은 항상 LEFT JOIN으로 정규화 후 사용.
utm 표기 규칙(소문자, 하이픈, 캠페인 코드 prefix)을 마케팅팀과 합의해 거버넌스 문서로.
gclid·fbclid가 있을 때 utm보다 우선하는 fallback 룰 정의.
정규화 실패 케이스(매핑에 없는 새 utm)는 매주 모니터링 쿼리로 점검.

이 함정은 한 번 정리하면 한 분기는 평화롭다가, 마케터가 새 매체를 추가하면 다시 깨집니다. 거버넌스가 SQL보다 더 중요해요. 매주 도는 모니터링 쿼리 하나만 두면 안전합니다 — 채널 매핑 테이블에 없는 신규 utm_source TOP 10을 매주 슬랙으로 알려주는 잡 하나. 새 매체가 들어오면 자동으로 잡혀요.

함정 7 — Dedup과 동일 user의 다중 식별자

한 user가 brand search로 한 번 들어왔다가, 7일 뒤 retargeting으로 다시 와서 구매했다고 칩시다. raw data에는 cookie_id 두 개, email_hash 한 개, gaid 한 개로 나타날 수 있어요. SQL에서 user 단위 집계를 할 때 이 식별자들을 어떻게 묶느냐가 결과를 완전히 바꿉니다.

흔한 잘못된 패턴:

COUNT(DISTINCT cookie_id)로 unique user를 셈 → 한 user가 N명으로 카운팅
email_hash가 NULL인 비로그인 행을 user 집계에서 누락 → 신규 user가 사라짐
attribution을 user_id 매칭으로만 처리 → 로그인 전 클릭이 attribution에서 빠짐

해결 패턴은 ID resolution입니다. 사내에 CDP가 있다면 unified user_id를 쓰면 되고, 없다면 다음 우선순위로 식별자를 통합합니다.

로그인된 email_hash (가장 강함)
gaid / idfv (모바일 디바이스)
cookie_id (가장 약함, 짧은 수명)

window function을 써서 한 cookie_id가 어느 시점에 어느 email_hash로 매칭됐는지 추적합니다. 그 매칭이 잡힌 순간부터 그 cookie_id의 과거 이벤트도 같은 user로 묶어요. SQL로는 FIRST_VALUE(email_hash) OVER (PARTITION BY cookie_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) 같은 윈도우 함수 한 줄로 unified_email_hash를 만든 뒤, 그 매핑 테이블을 raw events에 LEFT JOIN으로 붙이는 식이 표준입니다.

이 함정은 SQL 한 줄이 아니라 데이터 모델 자체의 문제라 가장 어렵습니다. 사내 ID 거버넌스가 아직 약하다면 cdp-id-graph와 server-side-tagging-capi를 먼저 보시면 도움이 됩니다.

마치며 — 안티패턴 체크리스트

함정	증상	1차 점검
1. Fan-out 중복 조인	일부 캠페인의 spend·revenue가 비현실적으로 큼	JOIN 전 키 카디널리티 확인
2. Attribution window 누락	채널별 ROAS가 일관되게 낮음	window 설정 테이블, BETWEEN timestamp
3. Timezone 미스매치	요일별로 ROAS가 비정상 패턴	raw=UTC, 보고=KST 통일
4. Conversion lag	어제 수치가 매일 바뀜	T+3 freeze + 스냅샷
5. 환율·통화	ROAS 단위가 비현실적 (1300배 또는 1/1300)	currency 컬럼 + 일자별 fx_rate
6. 채널 매핑	같은 채널이 여러 행으로 쪼개짐	정규화 lookup + 모니터링
7. Dedup·식별자	unique user 수가 부풀려짐	ID resolution + window function

7가지를 한 번에 다 해결하려고 하지 마세요. 1·2·3은 SQL 표준 정착으로, 4는 운영 정책으로, 5·6은 데이터 거버넌스로, 7은 데이터 모델로 풀어야 합니다. 각각 다른 사람이 책임자라는 뜻이에요.

BI팀과 마케팅팀의 ROAS가 안 맞을 때, 회의에서 "데이터가 틀린 것 같아요"보다 "이 7가지 함정 중 어디서 깨졌을까요"로 시작하면 훨씬 건강한 대화가 됩니다. 데이터는 거의 안 틀려요. 거의 항상 SQL 한 줄이 틀려있습니다.

참고

매체 raw data 컬럼 가이드 — Meta, Google, TikTok, Naver의 진짜 컬럼들

Aramir — Sat, 16 May 2026 18:05:00 +0900

Meta·Google·TikTok·Naver 각 매체가 주는 raw export 컬럼을 한 표로 매핑합니다. spend·impression·click·conversion·video view·viewability까지, 같은 의미가 매체마다 어떻게 다른 이름으로 들어오는지 정리합니다.

Meta API의 actions, Google Ads의 conversions, TikTok의 result, Naver SA의 conversion_count. 셋 다 다른 이름이지만 비슷한 의미예요. 그런데 미묘하게 다릅니다. 마케터·BI팀이 매체 raw data를 다룰 때 가장 자주 깨지는 자리는 이 "비슷하지만 다른" 컬럼들을 잘못 매핑하는 자리예요. 이 글은 네 매체의 raw export 컬럼을 한 표로 매핑하고, 각 컬럼이 진짜로 무엇을 뜻하는지를 풀어둡니다. 매일 raw data 다루는 분 옆에 두는 사전 한 권.

왜 매체별 raw data를 알아야 하나

매체 UI 대시보드는 잘 그려졌지만 다음 분석을 하려면 raw data가 필요합니다.

매체 간 통합 대시보드 (한 BI에 4개 매체 ROAS를 동시에)
MMM 입력 (일자별·채널별 spend·impression·click·conversion)
자체 attribution (last-click·data-driven 대신 자사 룰)
매체 default와 다른 lookback window로 재계산
클릭별·소재별 deep dive

매체 raw를 직접 다룰 때 가장 큰 함정은 컬럼 이름이 매체마다 다르고, 같은 이름의 컬럼도 정의가 다를 수 있다는 점입니다. "conversion"이라는 같은 단어가 매체마다 다른 걸 가리켜요.

네 매체의 컬럼은 이름이 달라도 spend·impression·click·conversion·video 5개 그룹으로 매핑하면 한 번에 보인다.

5초 매핑 — 4개 매체 컬럼 한 표

의미	Meta (Marketing API)	Google Ads (Ads API)	TikTok (Marketing API)	Naver SA
캠페인 ID	`campaign_id`	`campaign.id`	`campaign_id`	`nccCampaignId`
광고 그룹	`adset_id`	`ad_group.id`	`adgroup_id`	`nccAdgroupId`
소재	`ad_id`	`ad.id`	`ad_id`	`nccCreativeId`
노출	`impressions`	`metrics.impressions`	`impressions`	`impCnt`
클릭	`clicks`	`metrics.clicks`	`clicks`	`clkCnt`
비용	`spend`	`metrics.cost_micros`	`spend`	`salesAmt`
전환 수	`actions` (nested)	`metrics.conversions`	`result` / `conversion`	`convCnt`
전환 가치	`action_values` (nested)	`metrics.conversions_value`	`total_purchase_value`	`convAmt`
비디오 25% 시청	`video_p25_watched_actions`	`video_quartile_p25_rate`	`video_play_25_rate`	(없음)
Viewability	`video_avg_time_watched_actions`	`metrics.active_view_viewable_impressions`	`viewable_impressions`	(별도)
Reach	`reach`	`metrics.unique_users`	`reach`	(별도)
Frequency	`frequency`	`metrics.avg_impression_frequency_per_user`	`frequency`	(별도)

이 표 하나를 옆에 두면 매체 raw data SQL을 짤 때 막힐 일이 거의 없습니다.

Meta Marketing API 핵심 컬럼

Meta의 raw 데이터는 actions라는 nested array가 가장 큰 함정입니다. 한 row 안에 여러 종류의 전환이 array로 들어있고, 각각의 attribution window별 값이 또 따로예요.

자주 쓰는 액션 타입:

purchase — 구매
add_to_cart
initiate_checkout
complete_registration
lead
app_install
mobile_app_install

각 액션의 attribution 값은 1d_click, 7d_click, 28d_click, 1d_view, 7d_view 같은 sub-field로 들어옵니다. 그래서 같은 purchase 액션도 윈도우별로 다른 값이 동시에 들어있어요.

Meta 액션 컬럼	의미
`actions[action_type=purchase].value`	기본 attribution 윈도우의 전환 수
`actions[action_type=purchase]._1d_click`	1일 click attribution 윈도우
`actions[action_type=purchase]._7d_click`	7일 click attribution 윈도우
`actions[action_type=purchase]._1d_view`	1일 view attribution 윈도우
`action_values[action_type=purchase].value`	전환 가치 (매출)

raw export를 BigQuery로 적재할 때 actions array를 풀어서 store하는 게 표준입니다. UNNEST + 액션 타입 필터로 분석하세요.

Google Ads API 핵심 컬럼

Google Ads API는 cost_micros 같은 단위가 특이합니다. 비용이 1원이면 1,000,000 micros로 들어와요. 1000000 나눠야 일반 단위가 됩니다.

자주 쓰는 컬럼:

metrics.cost_micros — 1,000,000 나누면 원
metrics.impressions — 노출 수
metrics.clicks — 클릭 수
metrics.conversions — 전환 수 (float, 부분 attribution 가능)
metrics.conversions_value — 전환 가치
metrics.all_conversions — 모든 전환 액션 합산 (multi action conversion)
metrics.view_through_conversions — view-through 전환만
metrics.search_impression_share — 검색 인벤토리 점유율

Google Ads는 conversion이 float인 게 인상적입니다. data-driven attribution에서 한 클릭이 부분 전환을 만들 수 있어 0.4 같은 값이 나옵니다. 이걸 INT로 변환하면 안 됩니다.

전환 액션을 따로 보려면 conversion_action 리소스를 따로 쿼리해서 액션 ID별로 metrics를 분해해야 합니다. 예를 들어 매출 전환과 lead 전환을 분리해서 ROAS·CPL을 따로 계산하려면 그 단계가 필요해요.

TikTok Marketing API 핵심 컬럼

TikTok은 비교적 최근 회사라 API가 깔끔합니다. RESTful + JSON, 단위가 직관적.

자주 쓰는 컬럼:

spend — 비용 (광고주 통화)
impressions / clicks
result — TikTok이 정의한 최적화 목표(설치·구매 등)에 따른 결과
conversion — 픽셀·이벤트로 측정한 전환
total_purchase — 구매 수
total_purchase_value — 매출
video_play_actions — 비디오 재생 시작 수
video_play_25_rate — 25% 시청 비율
video_play_100_rate — 100% 시청 비율
engagements — 좋아요·댓글·공유 합

TikTok의 result 컬럼은 캠페인 최적화 목표에 따라 의미가 바뀝니다. 설치 목표 캠페인의 result는 설치 수, 구매 목표 캠페인의 result는 구매 수. 그래서 캠페인 타입 메타데이터와 함께 봐야 의미가 잡힙니다.

비디오 광고가 많은 TikTok 특성상 video_play_* 시리즈가 굉장히 중요해요. 25%·50%·75%·100% 시청률은 크리에이티브 평가의 핵심 KPI입니다.

Naver SA·DA 핵심 컬럼

Naver는 국내 마케터에게는 빠질 수 없는 매체. 컬럼 이름이 국문 도메인이라 살짝 헷갈리지만 매핑은 단순해요.

자주 쓰는 컬럼:

nccCampaignId / nccAdgroupId / nccKeywordId / nccCreativeId — 4단계 계층
impCnt — 노출 수
clkCnt — 클릭 수
salesAmt — 비용 (원)
convCnt — 전환 수
convAmt — 전환 가치
ctr — CTR (Naver가 직접 계산해서 줌)
cpc — CPC
avgRnk — 평균 노출 순위 (검색 광고)

Naver는 검색(SA)과 디스플레이(DA) API가 분리되어 있어요. 같은 컬럼 이름도 SA와 DA에서 미묘하게 의미가 다를 수 있어 SA·DA를 다른 raw 테이블로 적재하는 게 표준입니다.

매체별 같은 의미·다른 정의

같은 단어인데 매체마다 정의가 다른 컬럼들:

단어	Meta	Google	TikTok	Naver
Impression	광고가 사용자 viewport에 로드	광고가 검색결과/페이지에 표시	광고가 피드에 표시	광고가 검색결과에 노출
Click	link/post click	검색 결과 클릭	광고 영역 모든 클릭 (link·profile·video)	광고 클릭
Reach	광고를 본 unique user	광고를 본 unique user (cookie 기반)	광고를 본 unique device	(별도 컬럼)
Frequency	reach 평균 노출 횟수	impressions / reach	impressions / reach	(별도)
Viewability	MRC 기준 (50%·1초)	active view	MRC 기준	(별도)

특히 click의 정의가 큽니다. TikTok의 click에는 video play, profile click 같은 비-link click이 다 포함됩니다. CTR을 매체 간 비교할 때 그대로 비교하면 TikTok이 항상 높아 보여요. link click만 분리해서 봐야 공평한 비교가 됩니다.

통합 BI 테이블 설계 권장

매체 raw를 한 BI 테이블로 합칠 때 표준 스키마는 이렇습니다.

컬럼	타입	의미
`date`	DATE	데이터 기준 일자 (KST)
`media_source`	STRING	meta / google / tiktok / naver
`campaign_id`	STRING	매체 캠페인 ID
`campaign_name`	STRING	캠페인 이름
`adset_id` / `adset_name`	STRING	광고 그룹
`ad_id` / `ad_name`	STRING	소재
`impressions`	INT	노출
`clicks`	INT	link click 기준
`spend_krw`	NUMERIC	환율 변환된 비용
`conversions`	NUMERIC	전환 수 (float 허용)
`conversion_value_krw`	NUMERIC	전환 가치
`attribution_window`	STRING	"click_7d_view_1d" 같은 라벨
`currency_original`	STRING	원본 통화
`spend_original`	NUMERIC	원본 통화 비용

이 스키마를 정의해두면 새 매체를 추가할 때도 매핑만 작성하면 됩니다.

마치며

매체 raw data는 컬럼이 많지만 그룹 매핑 한 번 해두면 통합 BI가 빠르게 굴러갑니다. 매체가 추가될 때마다 위 스키마에 맞춰 ETL을 짜면 새 매체 추가 비용이 1-2주에서 1-2일로 줄어요.

다음 글은 raw data에서 마케터가 가장 헷갈리는 트래픽 소스 — Organic·Direct·Referral의 4가지 정의를 organicdirectreferral-ga4-mmp-amplitude-organic-4에서 다룹니다.

참고

Organic·Direct·Referral의 진실 — GA4, MMP, Amplitude가 organic을 부르는 4가지 방식

Aramir — Sat, 16 May 2026 18:04:08 +0900

GA4의 organic search, MMP의 Organic, Amplitude의 Direct, GA4의 (direct)/(none). 같은 단어가 도구마다 다른 의미예요. 4가지 정의를 한 글로 정리하고 dark traffic·attribution 누락을 어떻게 분리하는지를 풉니다.

"지난주 organic 트래픽이 갑자기 30% 늘었어요. SEO 효과인가요?" 이 질문 하나에 답하려고 BI팀과 마케팅팀이 한 시간씩 회의를 합니다. 그런데 자세히 보면 GA4 organic, MMP Organic, Amplitude Direct, 자사 BI의 unknown이 다 다른 걸 뜻하고 있어요. 같은 organic이라는 단어가 도구마다 의미가 다릅니다. 이 글은 organic·direct·referral의 4가지 정의를 한 표로 매핑하고, "진짜 SEO 트래픽"과 "attribution 누락 dark traffic"을 어떻게 분리하는지 정리합니다.

왜 organic의 정의가 도구마다 다른가

organic이라는 단어는 직관적으로 "광고비를 안 쓴 트래픽"으로 들립니다. 그런데 실제로는 도구마다 측정 방식이 달라서 정의가 갈립니다.

GA4는 utm·referrer·landing 정보로 organic·direct·referral·paid를 판단
MMP는 attribution이 실패한 install을 Organic으로 부름
Amplitude는 첫 세션의 referrer로 acquisition channel을 판단
자사 BI는 자체 규칙으로 분류

같은 사용자, 같은 방문이라도 도구마다 다른 채널로 분류돼요. 이 차이를 모르고 비교하면 답이 안 나오는 회의가 됩니다.

organic이라는 단어 한 개로 네 가지 다른 트래픽이 묶인다. SEO·dark traffic·attribution 실패·진짜 직접 방문을 분리해야 의사결정이 가능해진다.

4가지 정의 — 한 표

도구	"Organic" / 유사 라벨	진짜 의미
GA4	`organic search`	검색 엔진 referrer가 잡힌 자연 검색
GA4	`(direct) / (none)`	utm·referrer 모두 없음 (북마크·앱·dark traffic)
MMP (Appsflyer 등)	`Organic`	attribution이 어느 매체에도 안 잡힘
Amplitude	`Direct`	첫 세션의 referrer가 비어있음
자사 BI	`unknown` / `untagged`	채널 매핑 lookup이 실패한 경우

이 5가지가 다 다른 트래픽을 뜻해요. 같은 단어로 부르지만 마케터가 의사결정할 때는 분리해서 보는 게 정확합니다.

GA4의 organic search vs (direct)/(none)

GA4의 acquisition channel은 한 마디로 referrer + utm 분석입니다. 사용자가 방문할 때 가져오는 정보로 채널을 추론해요.

utm_source/medium이 박혀있으면 → 해당 매체로 분류
referrer가 검색 엔진(google.com/search 등)이면 → organic search
referrer가 일반 사이트면 → referral
utm도 없고 referrer도 없으면 → (direct) / (none)

(direct) / (none) 버킷이 가장 큰 함정이에요. 이 안에는 진짜 직접 방문(북마크·URL 직접 입력) 외에 다음이 다 섞여 있어요.

HTTPS → HTTP 전환으로 referrer가 떨어진 트래픽
모바일 앱 deeplink (referrer 없음)
이메일·메신저 내장 브라우저 (referrer 정책 제한)
utm 빠뜨린 광고 클릭
도메인 직접 입력 (진짜 direct)

흔히 (direct)/(none)이 전체 트래픽의 20~40%인 사이트가 많은데, 이 안에서 진짜 direct는 절반도 안 되는 경우가 흔해요. 나머지가 다 dark traffic입니다.

MMP의 Organic은 attribution 실패다

앱 마케팅에서 MMP raw data의 media_source = Organic은 "SEO로 들어왔다"가 아닙니다. "attribution이 어느 매체에도 매칭되지 않았다"는 뜻이에요.

여기 들어가는 트래픽:

App Store / Google Play의 검색 트래픽 (진짜 organic)
친구 추천으로 검색 후 설치
이전 사용자 재설치 (window 지난 reattribution)
iOS ATT 거부로 attribution 못 잡은 광고 트래픽
click_id가 누락된 광고 트래픽
광고 SDK가 늦게 초기화되어 매칭 못 한 경우

iOS 14.5 ATT 이후 MMP Organic 비율이 갑자기 40%로 늘어난 게 마지막 3개 항목 때문이에요. 진짜 organic이 늘어난 게 아니라 attribution 실패가 늘어난 거예요.

Organic 분해 분석:

App Store / Play Store referrer가 잡힌 트래픽 → 진짜 organic
IDFA가 NULL이고 click_id 없는 트래픽 → ATT 실패 의심
같은 user의 reinstall 흔적이 있는 트래픽 → reattribution 누락

이런 식으로 Organic 안을 다시 분류해야 진짜 SEO·ASO 효과와 attribution 실패를 분리할 수 있어요.

Amplitude의 Direct는 첫 세션 기준

Amplitude·Mixpanel 같은 product analytics는 user-level의 첫 세션 referrer를 acquisition channel로 잡습니다. GA4가 매 세션 기준이라면 product analytics는 사용자 기준이에요.

이 차이가 만드는 함정:

같은 사용자의 모든 후속 세션도 첫 채널로 attribution
첫 방문이 (direct)면 그 사용자는 평생 Direct user
광고로 처음 들어왔다가 나중에 organic으로 재방문해도 acquisition은 광고
광고 첫 방문 후 attribution이 30일 지나 만료되면 Direct로 잡힘

product analytics의 acquisition은 "이 user를 누가 데려왔나"의 답이라 광고 ROAS 계산에는 적합하지 않아요. 광고 ROAS는 매체 raw 또는 MMP를 봐야 하고, product analytics는 코호트·retention·funnel 분석에 씁니다.

자사 BI의 unknown은 채널 매핑 실패다

자사 BI에서 별도 unknown/untagged 버킷이 있는 회사가 많습니다. 이건 보통 채널 매핑 lookup 테이블이 실패한 경우예요.

새 매체가 추가됐는데 매핑이 아직 없음
utm_source 표기가 lookup에 없는 값
마케터가 새 캠페인에 자체 utm을 박았는데 표준화 안 됨

이 unknown은 직접 잡을 수 있는 자리예요. 매주 unknown TOP 10을 모니터링하고 매핑에 추가하면 보통 사라집니다. SQL 안티패턴 글의 함정 6에서 다뤘던 채널 매핑 거버넌스가 이걸 다룹니다.

Dark traffic을 줄이는 운영 표준

진짜 direct(북마크·URL 입력)와 dark traffic을 분리하지 않으면 의사결정이 흐려집니다. dark traffic을 줄이는 운영 표준을 정리해볼게요.

모든 광고 링크에 utm 5종 박기 (source, medium, campaign, content, term)
사내 표준 utm 형식 (소문자·하이픈·캠페인 코드 prefix)
HTTPS → HTTPS만 referrer 살아남으니 외부 링크는 HTTPS 강제
이메일·메신저 deeplink에는 별도 source 라벨 (예: utm_source=newsletter)
모바일 앱에 들어가는 deeplink는 별도 utm 박기
광고 매체별 click_id 자동 파라미터를 사이트가 인식해 저장 (gclid, fbclid, ttclid 등)
referrer 떨어지는 케이스를 GA4 referrer override로 보정

이 7가지를 다 해도 (direct)/(none)이 0이 되지는 않습니다. 진짜 direct는 어느 정도 남아요. 다만 dark traffic 비중이 20%에서 5% 수준으로 줄어듭니다.

진짜 SEO 효과를 측정하는 법

"organic이 늘었다"가 SEO 효과인지 확인하려면 다음 분리가 필요합니다.

검색 엔진별 트래픽 (Google·Naver·Bing·DuckDuckGo) — Search Console·Naver Search Advisor 연결
검색 키워드별 트래픽 — 키워드 클러스터링
랜딩 페이지별 organic 트래픽 — 콘텐츠 단위 SEO 효과
신규 vs 재방문 organic 분리
(direct)/(none) 안의 진짜 direct 추정 (북마크·URL 입력)

이 모든 분리를 GA4 UI에서만 하기는 어려워서 BigQuery export 기반 자체 SEO 대시보드를 만드는 게 표준입니다. Google Search Console API와 GA4 raw event를 매칭해서 키워드 → 랜딩 페이지 → 전환의 흐름을 보는 거예요.

organic 분류 의사결정 체크리스트

"organic이 늘었다" → 어느 도구의 organic인지 먼저 확인
GA4 organic search 늘었다 → 검색 엔진별·키워드별 분해
GA4 (direct)/(none) 늘었다 → dark traffic 의심부터, utm 누락·referrer 떨어짐 점검
MMP Organic 늘었다 → attribution 실패 분해, ATT 거부율·매체별 SDK 체크
Amplitude Direct 늘었다 → 신규 user의 referrer가 떨어지는 경로 점검
자사 BI unknown 늘었다 → 채널 매핑 lookup에 새 utm 추가

마치며

organic은 한 단어인데 도구마다 다른 4가지 의미가 들어가 있다는 사실 하나만 알아도 보고서 회의 시간이 절반으로 줄어듭니다. 모든 분석의 시작은 "어느 도구의 organic이에요?" 한 질문이에요.

다음 글은 SEO의 다음 진화 — LLM 답변에 우리 브랜드를 노출시키는 Generative Engine Optimization으로 이어집니다.

참고

MMP raw export 컬럼 사전 — Appsflyer, Adjust, Branch가 주는 진짜 데이터

Aramir — Sat, 16 May 2026 18:03:18 +0900

Appsflyer·Adjust·Branch raw export에는 어떤 컬럼이 있고 각 컬럼이 진짜로 무엇을 뜻하는지. media_source·campaign·af_status·reattribution·SKAdNetwork postback 컬럼까지 마케터·데이터팀이 매일 만나는 raw export를 한 글로 정리합니다.

앱 광고 운영자라면 MMP raw export는 매일 만나는 데이터입니다. 그런데 정작 컬럼이 100개가 넘어가는 그 CSV에서 무엇이 진짜 신뢰할 컬럼이고, 무엇이 보조 정보이고, 무엇이 NULL이 많은지를 한 곳에서 정리한 글은 의외로 드물어요. 이 글은 Appsflyer·Adjust·Branch 세 MMP의 raw export 컬럼을 한 표로 정리하고, 각 컬럼이 마케터의 의사결정에서 어떤 의미를 갖는지를 함께 풉니다. 이 글 하나 옆에 두고 raw 데이터 보면 80%의 질문이 끝납니다.

왜 raw export를 직접 봐야 하나

MMP UI 대시보드는 굉장히 잘 만들어졌습니다. 캠페인별 install·revenue·ROAS가 알아서 그려져요. 그런데 운영자가 다음 단계로 가려면 raw export를 직접 만져야 하는 순간이 옵니다.

"UI ROAS와 BI ROAS가 다르다, 어디서 깨졌나"
"MMM에 넣을 채널별 install·revenue 일자별 데이터"
"사내 CDP와 MMP 데이터를 user-level로 매칭"
"incrementality 분석을 위한 raw event 추출"
"View-through와 click-through를 분리해서 보고"

이 모든 분석의 1번 입력이 MMP raw export입니다. UI는 가공된 요약이라서 원하는 단위·정의로 못 자릅니다.

세 MMP의 컬럼은 이름이 다르지만 같은 의미. media_source·campaign·attribution flag·reinstall·postback 5개 그룹으로 매핑하면 한 번에 보인다.

5초 요약 — 세 MMP의 컬럼 매핑 표

의미	Appsflyer	Adjust	Branch
매체 이름	`media_source`	`network_name`	`last_attributed_touch_data_tilde_channel`
캠페인	`campaign`	`campaign_name`	`..._tilde_campaign`
광고 그룹	`adset` / `af_adset`	`adgroup_name`	`..._tilde_ad_set_name`
소재	`af_ad`	`creative_name`	`..._tilde_ad_name`
install 시각	`install_time`	`installed_at`	`last_attributed_touch_data_plus_timestamp`
클릭 시각	`click_time`	`click_time`	`last_attributed_touch_data_plus_click_timestamp`
사용자 ID	`appsflyer_id` + `customer_user_id`	`adid` + `user_id`	`branch_id` + `developer_identity`
디바이스 ID	`idfa`/`idfv`/`gaid`	`idfa`/`gps_adid`	`idfa`/`google_advertising_id`
매출	`revenue`	`revenue_usd`	`last_attributed_touch_data_plus_revenue`
attribution 종류	`af_status`(Organic/Non-Organic)	`tracker`	`last_attributed_touch_type`
Reattribution	`is_retargeting` + `reattribution_status`	`is_reattributed`	`last_cta_view_timestamp`
첫 설치인가	`is_first_session`	`is_first_session`	(이벤트 type)

이 표 한 장으로 MMP 간 데이터 매핑 SQL의 90%가 결정됩니다.

Appsflyer 핵심 컬럼

Appsflyer가 글로벌 1위 MMP인 만큼 raw export 컬럼이 가장 풍부하고, 또 많아서 헷갈립니다. 자주 쓰는 컬럼 그룹을 분류해볼게요.

매체·캠페인 식별

media_source — 매체 (예: facebook_int, googleadwords_int, organic)
campaign / campaign_id — 캠페인
adset / adset_id — 광고 그룹
af_ad / af_ad_id — 소재
af_channel — 매체가 지정한 채널
af_keywords — 검색 광고의 키워드

Attribution 결과

af_status — Organic / Non-Organic. 가장 중요한 분류 컬럼
attribution_type — click_through / view_through / impression
match_type — referrer / probabilistic / id_matching
is_primary_attribution — 같은 install의 multiple touch 중 1차 attribution 여부

시간

install_time — 첫 설치 시각 (가장 중요)
event_time — 이 이벤트 시각
attributed_touch_time — 마지막 어트리뷰션 터치 시각
click_time — 마지막 클릭 시각

식별자

appsflyer_id — MMP가 만드는 device-level ID
customer_user_id — 광고주가 박는 사용자 ID (CDP 매칭용)
idfa / idfv / gaid — 디바이스 광고 ID
idfv — iOS는 ATT 동의 안 받으면 idfa는 NULL, idfv만 채워짐

매출과 이벤트

event_name — purchase, level_up, tutorial_complete 등 SDK가 보낸 이벤트
event_value — 이벤트 페이로드 JSON
revenue — 매출 (자사 통화)
revenue_in_selected_currency — 보고서 환산 통화의 매출

Adjust 핵심 컬럼

Adjust는 Appsflyer 대비 컬럼이 좀 더 깔끔하고 표준 OpenAPI 친화적입니다. 자주 쓰는 컬럼:

tracker — Adjust가 만든 deeplink 트래커 ID
network_name / campaign_name / adgroup_name / creative_name — 매체 계층
installed_at — 첫 설치 시각
click_time — 마지막 클릭 시각
impression_time — 마지막 view 시각 (view-through 시)
adid — Adjust device ID
idfa / idfv / gps_adid
user_id — 광고주가 박는 사용자 ID
revenue_usd — USD 변환된 매출
currency — 원본 통화
is_first_session — 첫 설치/재설치 여부
is_reattributed — reattribution 여부
engagement_type — click / impression / install

Adjust의 강점은 tracker 한 컬럼만 봐도 캠페인 전체 계층(매체·캠페인·광고그룹·소재)을 다 풀어낼 수 있다는 점입니다. 단일 키로 모든 매핑을 할 수 있어 SQL이 깔끔해요.

Branch 핵심 컬럼

Branch는 deeplink·attribution을 한 번에 다루는 회사라 컬럼 이름이 길고 nested합니다. 그런데 그만큼 한 이벤트의 attribution 맥락 전체가 한 row에 들어있어요.

last_attributed_touch_data_tilde_channel — 매체
last_attributed_touch_data_tilde_campaign — 캠페인
last_attributed_touch_data_tilde_ad_set_name — 광고 그룹
last_attributed_touch_data_tilde_ad_name — 소재
last_attributed_touch_data_plus_timestamp — 마지막 touch 시각
last_attributed_touch_data_plus_click_timestamp — 마지막 클릭 시각
last_attributed_touch_type — click / impression / referrer
last_attributed_touch_data_plus_revenue — 매출
branch_id — Branch device ID
developer_identity — 광고주 박은 사용자 ID
last_cta_view_timestamp — 마지막 CTA view 시각

Branch는 단일 row 안에 first touch / last touch 정보가 다 들어있어 multi-touch attribution을 한 SQL로 짤 수 있다는 게 강점입니다.

SKAdNetwork postback 컬럼

iOS 14.5 이후 attribution은 SKAdNetwork(SKAN) 기반 conversion value postback이 표준이 됐습니다. MMP raw에 추가로 들어오는 컬럼들이에요.

컬럼 의미	Appsflyer	Adjust	Branch
Conversion value	`conversion_value` (0~63)	`conversion_value`	`conversion_value`
Redownload	`redownload`	`redownload`	`redownload`
App version	`source_app_id` 등	`source_app`	`app_version`
Postback 시각	`event_time` (postback 도착 시각)	`postback_at`	`postback_received_at`

SKAN 데이터는 다음 두 가지 특성이 있어 raw 처리할 때 주의가 필요해요.

24~48시간 지연 후 도착 (lag)
일정 수 이하의 install은 privacy threshold로 NULL (k-anonymity)
conversion value 6비트(0~63)에 자사 정의한 의미 매핑이 필요 (compressed value)

깊은 SKAN 다루는 skan-postback-decoding·ios-att-skadnetwork-aem에서 더 자세히 정리했으니 SKAN 운영하시면 같이 보시면 좋습니다.

Reinstall·Reattribution 컬럼이 가장 헷갈리는 자리

같은 user가 앱을 지웠다가 다시 설치하면 그건 새 install인가, 재설치인가. 이걸 어떻게 카운팅하느냐에 따라 ROAS가 달라집니다.

MMP의 룰:

첫 설치 후 24시간 이내 재설치 → reinstall (is_first_session=true, is_reattributed=false)
첫 설치 후 24시간 이상 후 재설치 → reattribution (is_first_session=false, is_reattributed=true)
둘 다 새 install로 매체에 attribution은 됨

마케터 시선에서는 이걸 분리해서 봐야 해요.

is_first_session=true AND is_reattributed=false → 진짜 신규
is_reattributed=true → 재유입 (재마케팅 효과)

이걸 안 나누면 reattribution이 신규로 잡혀 ROAS가 부풀려져 보입니다.

환경 노이즈를 거르는 필터

raw export에는 자주 보이는 노이즈가 몇 가지 있습니다. 다음 필터를 기본으로 적용하고 분석을 시작하면 시간이 절약돼요.

attribution_type IS NOT NULL — attribution 실패 row 제외
media_source <> 'organic' — 광고 분석 시 organic 제외
is_first_session = true — 신규 설치만 본다면
app_version >= '최신 버전' — 구버전 데이터의 가짜 attribution 제외
event_time BETWEEN install_time AND install_time + INTERVAL '30 days' — 이상치 제외

사내 CDP와 매칭하는 키 우선순위

MMP 데이터를 사내 CDP·DW와 매칭할 때 어느 키를 쓸지 표준화가 필요합니다.

customer_user_id (Appsflyer) / user_id (Adjust) / developer_identity (Branch) — 광고주가 박은 사내 ID. 가장 강함.
idfa / gaid — 디바이스 ID. ATT 거부면 NULL.
appsflyer_id / adid / branch_id — MMP device ID. 약하지만 유일.
idfv — iOS 앱별 ID. 한 앱 안에서만 유효.

CDP를 운영한다면 사내 user_id를 MMP SDK 초기화 때 즉시 박는 게 표준입니다. 이걸 빠뜨리면 attribution은 잡혀도 CDP 매칭이 안 돼서 한 단계 더 분석을 할 수 없어요.

마치며

MMP raw export는 컬럼이 많지만 분류 매핑 한 번 해두면 SQL 짜는 게 단순해집니다. 위 표를 옆에 두고 새 분석을 시작할 때마다 컬럼 매핑 먼저 정리하시면 됩니다.

다음 글에서는 매체 자체 raw data — Meta·Google·TikTok·Naver export의 진짜 컬럼들 raw-data-meta-google-tiktok-naver로 이어집니다.

참고

마케팅 트렌드 위클리 — 매주 모니터링하는 글로벌·국내 소스 30곳 정리

Aramir — Sat, 16 May 2026 18:02:32 +0900

마케팅·adtech·AI·privacy 트렌드를 매주 따라잡는 표준 모니터링 소스 30곳. 글로벌·국내·매체 changelog·연구·뉴스레터·서브스택을 카테고리별로 묶고 활용법을 정리합니다.

마케터·운영자가 트렌드를 따라잡지 못하는 가장 큰 이유는 시간이 아니라 소스가 정리 안 됐기 때문이에요. 어디를 봐야 할지 모르면 매주 30분도 길게 느껴집니다. 반대로 잘 정리된 30곳을 매주 30분 훑어두면 사내 누구보다 빨리 매체 정책·AI 도구·privacy 변화를 알 수 있어요. 이 글은 글로벌·국내 마케팅·adtech·AI 트렌드를 따라잡는 표준 모니터링 소스 30곳을 카테고리별로 정리합니다. RSS·이메일·X 알림 셋업 가이드까지 함께.

왜 트렌드 모니터링이 마케팅의 한 축인가

광고·attribution·AI 도구·privacy 모두 분기마다 표준이 바뀝니다. 1년 전 표준이 지금 안 맞는 게 흔해요.

Meta·Google·TikTok이 새 캠페인 타입·attribution 옵션 출시 (매분기)
iOS·Android·Chrome이 privacy 정책 변경 (매년 큰 변화)
LLM 도구가 새 기능·새 모델 출시 (매월 1회 이상)
한국 PIPA·해외 GDPR 갱신
마케팅 자동화·CDP·BI 도구의 새 기능

이 변화를 따라잡지 못한 마케터는 6개월 후에 알게 되고, 그 사이 경쟁사는 활용하고 있어요. 트렌드 따라잡기는 학습이 아니라 운영 KPI입니다.

6개 카테고리 × 30곳 소스 = 매주 30분 모니터링으로 매분기 트렌드를 다 잡는 표준 레이더.

6개 카테고리 — 무엇을 따라잡는가

카테고리	모니터링 대상
글로벌 marketing strategy	큰 그림·case study·growth pattern
Adtech·매체 changelog	Meta·Google·TikTok·MMP 정책·기능 변경
AI·dev tool	LLM 모델·도구·workflow·하네스
Privacy·정책	ATT·GDPR·PIPA·Chrome 정책
국내 마케팅	국내 시장 동향·매체·콘텐츠
데이터·analytics	dbt·BigQuery·Snowflake·BI

각 카테고리별로 핵심 5곳 = 총 30곳을 매주 훑어요.

글로벌 marketing strategy 5곳

Stratechery (Ben Thompson) — tech·플랫폼 전략 깊은 분석, 주 2-3회 무료 일부
Lenny's Newsletter — growth·product 깊은 인터뷰, 주 2회
Marketing Brew — 마케팅 daily news, 5분 짜리
HBR — Marketing & Sales — 학술·전략적 관점
Andrew Chen blog — growth·acquisition·viral mechanics

이 5곳이면 글로벌 마케팅·growth의 큰 흐름은 다 잡혀요. Stratechery는 유료지만 다른 4곳은 무료.

Adtech·매체 changelog 5곳

AdExchanger — 글로벌 adtech 뉴스·attribution·programmatic
Meta for Business — Updates — Meta 공식 매체 정책·기능 changelog
Google Marketing Live & blog — Google Ads·GA4·Tag·attribution 업데이트
TikTok for Business blog — TikTok 광고 신기능·case study
Appsflyer·Adjust·Branch blog — MMP 측정·iOS·SKAN 변화

매체 정책은 한 분기 안에 ROAS를 흔들 정도로 큰 변화가 잦아요. RSS·이메일 구독으로 놓치지 말 것.

AI·dev tool 5곳

Anthropic — News & Engineering blog — Claude·Claude Code·API 신기능
OpenAI blog — GPT·ChatGPT·Codex·Sora·DALL-E
Hacker News — 매일 dev tool·AI 뉴스 가장 빠른 흐름
GeekNews — 한국어 dev·AI 큐레이션
Latent Space (서브스택) — AI engineering·practical deep dive

AI 도구는 거의 매주 큰 출시가 있어서 이 5곳 매주 한 번 훑는 게 표준. 특히 GeekNews는 한국어로 정리되어 시간 효율이 좋아요.

Privacy·정책 5곳

IAPP — Daily Dashboard — privacy 글로벌 뉴스
Apple Developer News — iOS·ATT·SKAN 업데이트
Google Chrome — Privacy Sandbox blog — Chrome cookie·sandbox 변화
개인정보보호위원회 — 공지·과징금 사례 — 국내 PIPA 단속·해석
모비인사이드·전자신문 IT — 국내 IT·광고 정책

Privacy는 마케팅 효율보다 매출 위험 관리. 큰 변화가 한 번 있으면 분기 운영 전체가 바뀌어요.

국내 마케팅·콘텐츠 5곳

모비인사이드 — 국내 모바일·앱 마케팅
디지털 인사이트 — 디지털 마케팅·트렌드
MAD Times — 광고 산업 뉴스
AB180 블로그 — 국내 MMP·attribution 운영 깊이
오픈서베이 트렌드 — 국내 소비자 트렌드 리포트

국내 시장 특수성을 잡는 데 필수. 글로벌 자료만 보면 한국 시장과 갭이 큽니다.

데이터·analytics 5곳

dbt blog — analytics engineering·modern data stack
BigQuery release notes — Google 데이터 웨어하우스
Snowflake blog — 경쟁 DW 업데이트
Locally Optimistic — data team 운영·culture
Substack: Benn Stancil's Notes — analytics 비판적 시각

이 5곳이면 데이터 stack의 현재 트렌드는 잡혀요.

운영 워크플로우 — 매주 30분 표준

소스 30곳을 매주 훑는 워크플로우.

월요일 아침 30분
RSS reader(Feedly·Inoreader)에 30곳 등록
카테고리별 폴더 분류
제목·요약만 빠르게 (Stratechery·Lenny's만 본문)
사내에 가치 있는 1-3개를 슬랙·노션에 공유 (요약 + 자체 코멘트)
매분기 1회 backlog 재정비 (안 보던 소스 제거·신규 추가)

매주 30분 모니터링이 사내 1번 트렌드 큐레이터로 만들어요. 매니저·팀원·외부 stakeholder가 트렌드를 물을 때 답하는 사람이 곧 회사의 의사결정에 영향 주는 자리.

모니터링을 콘텐츠로 — Weekly digest 발행

매주 모니터링한 결과를 자체 콘텐츠로 발행하면 회사·개인 브랜드가 같이 자라요. huny.log 같은 곳에 다음 형식으로.

주간 5-10개 카드 (소스 링크 + 한 줄 요약)
자체 코멘트 (마케터 영향도·실무 액션)
카테고리별 분류
매주 같은 요일·같은 시간 발행 (월요일 오전 같은 cadence)

marketing-trends-2026-q2-recap·marketing-trends-platform-policy-changelog 같은 분기 정기 발행으로 더 큰 cycle도 운영합니다.

트렌드 따라잡기의 안티패턴

30곳을 등록만 하고 매주 안 봄 (RSS 12000개 안 읽음)
모든 글을 처음부터 끝까지 정독 (시간 폭주)
카테고리 분류 안 함 (피로 가중)
가치 없는 글에도 자체 코멘트 시도 (퀄리티 하락)
글로벌 자료만 보고 국내 시장 갭 무시

10곳부터 시작해서 익숙해지면 30곳으로 확장하는 게 표준 onboarding이에요.

마치며

트렌드 모니터링은 학습이 아니라 운영입니다. 매주 30분 표준이 잡혀있으면 분기 의사결정에서 동료보다 늘 한 발 앞에 서요. 30곳을 한 번에 다 등록하기보다 5곳부터 시작해서 매월 확장하는 게 지속 가능한 패턴.

다음 글로는 2026 Q2 마케팅 트렌드 분기 정리·광고 매체 정책 changelog 분기 정리로 이어집니다.