P7-1.2 baseline과 첫 비교¶

Section ID: P7-1.2 Version: v2026.07.22

운영 로그를 읽고 평균, 최대값, 비율을 계산했다고 해서 바로 좋다, 나쁘다를 말할 수는 없습니다. baseline과 첫 비교는 숫자를 다시 적는 절이 아니라, 무엇이 기준선보다 실제로 달라졌는가, 그 차이 가운데 무엇이 먼저 볼 만한가를 가르는 자리입니다.

기준선 위에 놓을 첫 비교¶

• baseline은 왜 계산 결과 앞에 먼저 놓아야 하는가?
• 기준선과 현재 값을 어떻게 나란히 비교해야 하는가?
• 첫 비교에서 확인한 사실과 아직 가설인 해석을 어떻게 구분해 적어야 하는가?

핵심은 baseline -> 현재 값 -> 비교 결과 -> 다음 질문으로 이어지는 첫 비교 구조를 세우는 데 있습니다. 계산 기록은 혼자 놓일 때보다 어떤 기준선 위에 올려 두었는지가 더 중요하며, 그 기준이 있어야 다음 반복 판단으로 이어집니다.

Part 7의 공통 비교 기록 형식은 이 절에서 처음 고정됩니다. 이후 프로젝트의 실패 기록과 개선 계획도 모두 여기서 세운 사실, 해석, 다음 질문 구조를 다시 사용하지만, 그 앞에는 언제나 무엇을 기준선으로 두었는가가 먼저 와야 합니다.

Part 7에서 회고(retrospective)와 검토(review)의 구분이 다시 흔들리면, 먼저 회고는 다음 반복을 준비하는 정리, 검토는 아직 확정하지 않은 항목을 다시 보는 확인으로 읽고 이 절과 개념사전으로 돌아오면 됩니다.

판단 기준¶

• baseline이 어떤 비교 기준을 만들고, 현재 값이 그 기준과 어떻게 달라지는지 설명할 수 있습니다.
• 프로젝트 문서에서 사실, 해석, 다음 질문을 구분해 적을 수 있습니다.
• 비교 기준을 바꾸면 어떤 항목이 첫 비교 문서의 앞줄로 올라오는지 설명할 수 있습니다.
• 결과 요약만으로 끝나지 않고 한계와 보완점을 함께 남길 수 있습니다.

왜 baseline을 먼저 세워야 하나¶

프로젝트를 끝내면 종종 다음 두 문장으로 끝내려 합니다.

• 평균 방문자 수는 150.7명이었다.
• 2026-06-05가 가장 좋았다.

하지만 이런 문장만으로는 지금 값이 평소보다 나쁜 것인지, 원래 변동 범위 안에 있는 것인지 알 수 없습니다. 프로젝트 문서는 계산 결과를 옮겨 적는 곳이 아니라, 무엇을 기준선으로 보았고, 그 기준선에서 어디가 실제로 벗어났는지를 남기는 곳입니다.

baseline과 첫 비교가 계산 기록과 어떻게 다른지 판단 기준을 표로 고정하면 다음과 같습니다.

특히 데이터 분석 프로젝트에서는 얼마였는가보다 기준선에서 얼마나 벗어났는가가 다음 단계로 이어지는 질문을 더 잘 만듭니다.

예를 들어 오류가 가장 많았던 날을 찾는 것만으로는 충분하지 않습니다. 실제로는 다음이 더 중요합니다.

• 그 오류가 배포와 연결되었는가?
• 오류 증가가 가입 감소와 함께 나타났는가?
• 다음 실험이나 로그 추가가 필요한가?

baseline과 첫 비교를 읽는 기본 구조¶

첫 비교 문서도 다음 다섯 칸으로 나누면 훨씬 읽기 쉬워집니다.

이 구분이 중요한 이유는, 현재 값은 혼자서는 의미가 약하고 차이는 baseline 위에서만 읽히며, 해석은 그 뒤에도 여전히 가설 수준일 수 있기 때문입니다.

이 구조는 Part 7 전체에서 반복해서 쓰이는 공통 형식입니다. 이후 예측 모델, 딥러닝, RAG 프로젝트에서도 같은 세 칸을 다시 쓰게 됩니다.

여기에 한 가지를 더 붙이면 이 절이 Part 7 전체 비교 구조의 진짜 출발점이 됩니다. baseline, 현재 값, 사실, 해석, 다음 질문 다섯 칸을 단순 문장 형식으로만 보지 말고, 추가 검토가 필요한 항목, 아직 확정되지 않은 해석, 다음 반복에서 바로 확인할 질문을 함께 적는 공통 구조로 읽는 것입니다.

방금 같은 운영 로그의 출력과 결과 해석 표를 다시 읽으면, 이 세 칸이 어디에서 나오는지도 자연스럽게 보입니다.

• 코드 출력의 전체 전환율 차이, 채널별 비교는 사실(fact) 후보입니다.
• 본문 해설에서 붙인 ads 채널이 가장 크게 무너졌다 같은 문장은 해석(interpretation) 후보입니다.
• 그 아래에 이어진 landing page나 추적 스크립트를 먼저 볼 것인가 같은 문장은 다음 질문(next question) 후보입니다.

즉, P7-1.1의 출력은 여기서 회고 문서로 바로 다시 정리되어야 합니다.

같은 비교표를 예시로 다시 정리하기¶

P7-1.1의 결과를 이 구조에 맞추면 다음처럼 적을 수 있습니다.

이 표에서 중요한 점은 가능성과 사실을 섞지 않는 것입니다. 기준선과 비교한 차이가 보여도, 먼저 추가 확인이 필요한가를 적는 수준에 머무르는 편이 안전합니다.

오류 때문에 가입이 떨어졌다고 단정하는 것은 아직 이릅니다. 지금 단계에서 안전한 표현은 다음과 같습니다.

오류 증가와 가입 감소가 함께 보였으므로, 관련 가능성을 추가로 확인할 필요가 있다.

이 문장 차이를 꼭 익혀 두는 편이 좋습니다.

• 위험한 문장: 오류 때문에 가입이 떨어졌다.
• 안전한 문장: 오류와 가입 감소가 함께 보여 추가 확인이 필요하다.

예를 들어 ads 채널 전환율이 내려갔다는 한 줄만 보면, 빠르게는 ads 캠페인이 실패했다고 적고 싶어집니다. 하지만 더 안전한 다음 판단은 그렇게 단정하는 것이 아니라, 기준선 대비 하락, 오류율 동반 상승, 다른 채널은 같은 패턴이 아닌가를 먼저 나눠 적는 것입니다. 그래야 첫 비교 문서가 감상문이 아니라, 실제로 어디부터 다시 볼지를 정하는 기록이 됩니다. 이 장면에서 baseline은 숫자를 예쁘게 정리하는 장치가 아니라, 성급한 원인 단정을 한 번 멈추게 하는 장치입니다.

flowchart TD
  A["ads 채널 전환율 하락을 발견"]
  B["빠른 판단: 캠페인이 실패했다"]
  C["기준선 대비 하락 폭과 오류율을 함께 확인"]
  D["다른 채널은 같은 패턴이 아님"]
  E["안전한 기록: ads 채널 집중 이상 신호"]
  F["다음 질문: landing page, 추적 스크립트, 캠페인 설정을 순서대로 확인"]

  A --> B
  A --> C
  C --> D
  D --> E
  E --> F

비교 기준을 바꾸면 첫 비교도 달라진다¶

실제 프로젝트에서는 회고 문장을 예쁘게 쓰는 일보다 무엇이 baseline 대비 의미 있는 차이인가를 먼저 정해야 합니다. 같은 데이터라도 기준을 엄격하게 잡으면 한두 건만 첫 비교 문서의 앞줄에 올라오고, 탐색적으로 잡으면 더 많은 후보가 올라옵니다.

같은 운영 로그를 이어 받아, 예제에서는 어떤 날짜와 채널을 회고 후보로 올릴 것인가를 기준에 따라 나눠 보겠습니다.

• 문제 상황:
• 최근 7일 로그를 다시 읽으며 어떤 항목을 즉시 검토, 추가 관찰로 남길지 정해야 한다.
• 하지만 전환율 하락과 오류율 상승을 어느 수준부터 심각 신호로 볼지는 팀이나 단계마다 다를 수 있다.
• 입력:
• p7-1-traffic-log.csv
• 두 가지 검토 기준: 엄격 모드, 탐색 모드
• 기대 출력:
• 기준별 검토 후보 목록
• 어떤 날짜가 두 기준 모두에서 올라오는지
• 회고 문서에 바로 옮길 사실, 해석, 다음 질문
• 확인할 개념:
• 회고는 계산 결과를 옮겨 적는 문서가 아니라 검토 우선순위를 고정하는 문서다
• 기준을 바꾸면 회고 후보도 달라진다
• 그래도 두 기준에서 공통으로 올라오는 항목은 더 강한 검토 신호로 읽을 수 있다

실행 기록 기준¶

• 기준선을 먼저 적고, 현재 값과 차이를 그 옆에 둡니다.
• 엄격 모드와 탐색 모드에서 각각 올라오는 검토 후보를 따로 표시합니다.
• 두 기준에서 공통으로 남는 후보를 회고 앞줄 후보로 고릅니다.
• 사실, 해석, 다음 질문을 한 문장 안에 섞지 않고 분리해 씁니다.

Python 예제¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

# 트래픽 로그에서 전환율 하락과 오류율 상승 조건을 엄격 모드와 탐색 모드 기준으로 비교해 검토 후보를 고르는 예제입니다.
import csv
from collections import defaultdict
from datetime import datetime
from pathlib import Path

review_rules = [
    {
        "name": "엄격 모드",
        # 즉시 검토 후보만 남기고 싶을 때 쓰는 강한 기준입니다.
        "conversion_drop_max": -0.035,
        "error_rise_min": 0.011,
    },
    {
        "name": "탐색 모드",
        # 관찰 후보를 넓게 잡고 싶을 때 쓰는 완화 기준입니다.
        "conversion_drop_max": -0.025,
        "error_rise_min": 0.009,
    },
]

def conversion_rate(row):
    if row["visitors"] == 0:
        raise ValueError(f"visitors가 0인 행은 비율을 계산할 수 없습니다: {row}")
    return row["signups"] / row["visitors"]

def error_rate(row):
    return row["errors"] / row["visitors"]

data_path = Path("docs/assets/part-07/chapter-01/p7-1-traffic-log.csv")
rows = list(csv.DictReader(data_path.open(encoding="utf-8")))
for row in rows:
    row["date"] = datetime.strptime(row["date"], "%Y-%m-%d").date()
    row["visitors"] = int(row["visitors"])
    row["signups"] = int(row["signups"])
    row["errors"] = int(row["errors"])

# 조작 변수: 이 날짜를 바꾸면 기준선과 최근 구간이 달라집니다.
cutoff = datetime.strptime("2026-06-08", "%Y-%m-%d").date()
baseline_rows = [row for row in rows if row["date"] < cutoff]
recent_rows = [row for row in rows if row["date"] >= cutoff]

baseline_by_channel = defaultdict(lambda: {"visitors": 0, "signups": 0, "errors": 0})
for row in baseline_rows:
    baseline_by_channel[row["channel"]]["visitors"] += row["visitors"]
    baseline_by_channel[row["channel"]]["signups"] += row["signups"]
    baseline_by_channel[row["channel"]]["errors"] += row["errors"]

for channel, totals in baseline_by_channel.items():
    totals["conversion_rate"] = totals["signups"] / totals["visitors"]
    totals["error_rate"] = totals["errors"] / totals["visitors"]

candidate_rows = []
for row in recent_rows:
    baseline = baseline_by_channel[row["channel"]]
    current_conversion = conversion_rate(row)
    current_error = error_rate(row)
    candidate_rows.append({
        "date": row["date"],
        "channel": row["channel"],
        "conversion_rate": round(current_conversion, 4),
        "error_rate": round(current_error, 4),
        "conversion_delta": round(current_conversion - baseline["conversion_rate"], 4),
        "error_delta": round(current_error - baseline["error_rate"], 4),
    })

review_results = {}
for rule in review_rules:
    selected = []
    for row in candidate_rows:
        if (
            row["conversion_delta"] <= rule["conversion_drop_max"]
            and row["error_delta"] >= rule["error_rise_min"]
        ):
            selected.append({
                "date": row["date"].isoformat(),
                "channel": row["channel"],
                "conversion_delta": row["conversion_delta"],
                "error_delta": row["error_delta"],
            })
    review_results[rule["name"]] = selected

strict_keys = {
    (row["date"], row["channel"]) for row in review_results["엄격 모드"]
}
explore_keys = {
    (row["date"], row["channel"]) for row in review_results["탐색 모드"]
}
common_keys = sorted(strict_keys & explore_keys)

print("기준별 검토 후보 =")
print("읽은 파일 =", str(data_path))
for rule_name, rows in review_results.items():
    print(rule_name, rows)
print("공통 검토 후보 =", common_keys)

실행 결과 예시는 다음처럼 읽을 수 있습니다.

1
2
3
4
5

기준별 검토 후보 =
읽은 파일 = docs/assets/part-07/chapter-01/p7-1-traffic-log.csv
엄격 모드 [{'date': '2026-06-10', 'channel': 'ads', 'conversion_delta': -0.0354, 'error_delta': 0.011}, {'date': '2026-06-11', 'channel': 'ads', 'conversion_delta': -0.0388, 'error_delta': 0.0134}, {'date': '2026-06-12', 'channel': 'ads', 'conversion_delta': -0.0378, 'error_delta': 0.0129}, {'date': '2026-06-14', 'channel': 'ads', 'conversion_delta': -0.0385, 'error_delta': 0.0126}]
탐색 모드 [{'date': '2026-06-08', 'channel': 'ads', 'conversion_delta': -0.0283, 'error_delta': 0.0095}, {'date': '2026-06-09', 'channel': 'ads', 'conversion_delta': -0.0329, 'error_delta': 0.0091}, {'date': '2026-06-10', 'channel': 'ads', 'conversion_delta': -0.0354, 'error_delta': 0.011}, {'date': '2026-06-11', 'channel': 'ads', 'conversion_delta': -0.0388, 'error_delta': 0.0134}, {'date': '2026-06-12', 'channel': 'ads', 'conversion_delta': -0.0378, 'error_delta': 0.0129}, {'date': '2026-06-13', 'channel': 'ads', 'conversion_delta': -0.0395, 'error_delta': 0.0106}, {'date': '2026-06-14', 'channel': 'ads', 'conversion_delta': -0.0385, 'error_delta': 0.0126}]
공통 검토 후보 = [('2026-06-10', 'ads'), ('2026-06-11', 'ads'), ('2026-06-12', 'ads'), ('2026-06-14', 'ads')]

결과를 어떻게 읽는가¶

이 예제에서 확인해야 할 결과는 문장을 잘 썼는가가 아니라, 검토 기준을 바꾸었을 때도 계속 남는 신호가 무엇인가입니다. 그래야 회고 문서가 단순 감상문이 아니라 다음 행동의 우선순위 표가 됩니다.

결과 해석 기준¶

프로젝트 기록 예시¶

1
2
3
4
5
6
7
8

baseline:
현재 값:
엄격 모드 후보:
탐색 모드 후보:
공통 후보:
사실:
해석:
다음 질문:

이 결과를 어떻게 회고로 옮길까¶

위 출력은 회고 문서 안에서 다음처럼 바로 읽을 수 있습니다.

이 표에서 중요한 점은 후보가 많다보다 어떤 후보가 기준을 바꿔도 살아남는가입니다. 실제 프로젝트에서는 바로 그 항목이 먼저 회고 문서의 앞줄로 올라옵니다.

첫 비교 문서는 곧 다음 회고의 뼈대가 된다¶

비교 문서를 먼저 쓰면 회고는 그 뒤에 자연스럽게 따라옵니다. 독자가 흔히 놓치는 지점은 회고를 따로 쓰는 문서로 보고, baseline 비교는 숫자 표로만 남겨 두는 일입니다. 하지만 실제 프로젝트에서는 첫 비교 문서가 곧 회고의 뼈대가 됩니다.

데이터 분석 프로젝트의 회고에는 보통 다음이 들어갑니다.

• 무엇이 잘 보였는가
• 무엇이 아직 불분명한가
• 어떤 데이터가 더 필요했는가
• 어떤 비교를 못 했는가
• 다음 프로젝트에서 무엇을 먼저 보완할 것인가

즉, 첫 비교는 프로젝트의 중간 표가 아니라 다음 반복(iteration)을 준비하는 기준 기록입니다.

이 점 때문에 회고는 프로젝트의 맨 뒤 부록이 아니라, 다음 프로젝트의 첫 입력으로도 읽을 수 있어야 합니다.

프로젝트 회고 예시¶

프로젝트라면 다음 정도의 회고가 적절합니다.

잘 보인 점¶

• 전체 합계와 채널별 비교를 분리하니 서비스 전체 하락과 ads 채널 이상을 구분할 수 있었다.
• 검토 기준을 두 가지로 나눠 보니 공통으로 남는 날짜를 우선순위 1 후보로 고정할 수 있었다.

아직 모르는 점¶

• ads 채널 하락이 landing page 오류인지, 추적 스크립트 문제인지, 캠페인 품질 저하인지는 아직 확정할 수 없다.
• 엄격 모드에서 빠지고 탐색 모드에서만 잡힌 날짜를 실제 문제로 볼지 관찰 신호로만 둘지는 더 정해야 한다.

다음 반복에서 보완할 점¶

• campaign, release_version, error_type, browser 열을 추가한다.
• 채널 단위뿐 아니라 캠페인 단위 비교도 같이 본다.
• 검토 기준을 즉시 대응, 탐색 관찰 두 층으로 분리해 운영 문서에 남긴다.

바로 쓰는 회고 템플릿¶

읽은 뒤 바로 문서에 붙여 넣어 쓸 수 있는 최소 템플릿은 다음처럼 정리할 수 있습니다.

템플릿의 세 칸은 서로 다른 역할을 맡습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

### 사실
- 확인한 값:
- 비교 기준:

### 해석
- 이 값이 시사하는 가능성:
- 아직 단정할 수 없는 점:

### 다음 질문
- 다음에 추가로 확인할 데이터:
- 다음 반복에서 바꿀 점:

이 템플릿에서 중요한 점은 문장을 길게 잘 쓰는 일이 아닙니다. 먼저 확인한 값, 가능성, 다음 확인 항목이 각각 따로 적혀 있는지가 더 중요합니다.

예를 들어 이 예시를 이 빈칸에 바로 넣으면 다음처럼 됩니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

### 사실
- 확인한 값: 엄격 모드와 탐색 모드 모두에서 ads 채널의 2026-06-10, 06-11, 06-12, 06-14가 검토 후보로 남았다.
- 비교 기준: 채널별 기준선 전환율과 오류율 대비 최근 7일 변화를 비교했다.

### 해석
- 이 값이 시사하는 가능성: ads 채널에는 기준을 엄격하게 잡아도 사라지지 않는 구조적 이상 신호가 있을 수 있다.
- 아직 단정할 수 없는 점: landing page 오류인지, 추적 스크립트 문제인지, 캠페인 품질 변화인지는 아직 모른다.

### 다음 질문
- 다음에 추가로 확인할 데이터: campaign, release_version, error_type, browser
- 다음 반복에서 바꿀 점: 즉시 대응 기준과 탐색 관찰 기준을 분리해 운영 문서에 남긴다.

직접 바꿔 보며 확인할 것¶

기준을 어떻게 쓰는가에 따라 회고 문장이 달라지는 구조이므로, 실행 뒤에는 검토 기준을 직접 흔들어 보는 편이 좋습니다.

1. 엄격 모드 기준을 조금 더 높이거나 낮춰 봅니다. 관찰할 점: 공통으로 살아남는 날짜는 그대로인가, 아니면 회고 앞줄에 올라올 후보가 달라지는가?

2. organic이나 search에 ads와 비슷한 하락 행을 CSV에 한두 건 추가해 봅니다. 관찰할 점: 회고 문장이 특정 채널 이상에서 여러 채널 동시 이상으로 바뀌는가?

핵심 확인 기준은 문장을 예쁘게 쓰는가보다 검토 기준을 바꾸면 회고 우선순위가 어떻게 달라지는가입니다.

나쁜 회고와 좋은 회고¶

회고를 쓸 때는 결과 요약과 해석을 한 줄에 섞기 쉽습니다. 아래처럼 대비해서 보면 차이가 더 분명합니다.

나쁜 회고는 감상은 남지만 다음 행동이 남지 않습니다. 좋은 회고는 무엇을 봤는가, 무엇을 아직 모르는가, 무엇을 더 넣을 것인가가 같이 남습니다. 즉, 회고의 경고 문장도 자동 진단이 아니라 검토 필요 항목을 남기는 기록으로 읽혀야 합니다.

실무에서 왜 이 방식이 중요한가¶

실무에서는 분석 결과보다 분석 결과를 조직이 어떻게 다시 쓸 수 있느냐가 더 중요합니다.

예를 들어:

• 운영 팀은 오류가 많은 날짜를 보고 장애 기록과 연결합니다.
• 제품 팀은 가입이 높은 날을 보고 UI 변경과 연결합니다.
• 데이터 팀은 다음 주 실험 설계에 필요한 로그 열을 추가합니다.

즉, 프로젝트 문서가 좋다는 뜻은 계산이 복잡하다가 아니라 다른 사람이 다음 행동을 결정할 수 있다는 뜻에 더 가깝습니다.

체크리스트¶

이 체크리스트의 핵심은 회고를 길게 쓰는 일이 아닙니다. 숫자, 가능성, 다음 행동이 서로 다른 칸에 있어야 다음 사람이 같은 기록을 보고 이어서 실행할 수 있습니다.

출처와 참고 자료¶

이 절의 예시 데이터와 회고 구조는 이 책의 프로젝트 실습을 위해 구성한 자체 예시입니다. 외부 자료를 직접 인용하지 않았습니다.