dontech RSS Feed

MySQL SELECT가 변경을 못 읽는 이유: REPEATABLE READ와 autocommit의 함정

Donhyeok Kang — Sat, 04 Apr 2026 00:00:00 GMT

MySQL에서 분명히 데이터를 UPDATE하고 COMMIT까지 했는데, 다른 커넥션에서 SELECT하면 변경 전 값이 계속 나오는 경우가 있습니다. 캐시도 없고, 쿼리도 틀린 게 없는데 말입니다. 서버를 재시작하면 또 잘 보입니다.

이 현상의 원인은 MySQL의 트랜잭션 격리 수준과 PyMySQL의 기본 설정이 만드는 조합에 있습니다. 이 글에서는 왜 이런 일이 벌어지는지, 그리고 어떻게 해결하는지를 정리합니다.

어떤 상황에서 발생하는가

전형적인 재현 흐름은 이렇습니다.

[API 서버 시작]
  pymysql.connect(host=..., user=..., password=...)
  → 커넥션 생성 (autocommit=False가 기본값)

[첫 번째 API 요청]
  SELECT * FROM orders WHERE order_id = 1001
  → 결과: status = 'PENDING' (주문접수)

[관리자 페이지에서 상태 변경]
  다른 커넥션이 UPDATE orders SET status = 'SHIPPING' WHERE order_id = 1001 → COMMIT

[두 번째 API 요청]
  SELECT * FROM orders WHERE order_id = 1001
  → 결과: status = 'PENDING' (?? 변경이 안 보임)

[세 번째, 네 번째... 모든 후속 요청]
  → 결과: status = 'PENDING' (영원히 동일)

[서버 재시작]
  새 커넥션 생성 → 이제야 status = 'SHIPPING' 확인

SELECT 쿼리만 실행하고 있는데, 다른 커넥션에서 COMMIT한 변경이 전혀 보이지 않습니다. 대체 왜 그럴까요?

MySQL 트랜잭션 격리 수준

원인을 이해하려면 먼저 MySQL의 트랜잭션 격리 수준을 알아야 합니다. SQL 표준은 4가지 격리 수준을 정의하고 있고, MySQL InnoDB의 기본값은 REPEATABLE READ입니다.

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	스냅샷 갱신 시점
READ UNCOMMITTED	O	O	O	즉시 (커밋 전 포함)
READ COMMITTED	X	O	O	매 SELECT마다
REPEATABLE READ (기본값)	X	X	O	첫 SELECT 시점 고정
SERIALIZABLE	X	X	X	공유 잠금으로 직렬화

SQL 표준에서는 REPEATABLE READ에서 Phantom Read가 발생할 수 있지만, MySQL InnoDB는 Gap Lock을 통해 이를 방지합니다.

핵심은 REPEATABLE READ의 “스냅샷 갱신 시점” 컬럼입니다. MySQL 공식 문서에 따르면, REPEATABLE READ의 스냅샷은 BEGIN 시점이 아니라 트랜잭션 내 첫 번째 SELECT가 실행되는 순간 생성됩니다. 이후 같은 트랜잭션 안에서는 동일한 SELECT를 몇 번 실행해도 항상 그 스냅샷 기준의 결과를 반환합니다. 보고서 생성이나 일관된 데이터 처리에 유용한 기능입니다.

그런데 문제는 이 “트랜잭션”이 언제 시작되고 끝나느냐입니다.

autocommit=False가 만드는 영원한 트랜잭션

PyMySQL의 connect() 함수는 autocommit 파라미터의 기본값이 False입니다.

import pymysql

# autocommit 명시하지 않으면 False가 기본값
conn = pymysql.connect(
    host='db.example.com',
    user='api_user',
    password='...',
    database='myapp'
)
# conn.autocommit(False)와 동일한 상태

autocommit=False인 상태에서 첫 번째 SQL 문이 실행되면, MySQL은 암묵적으로 트랜잭션을 시작합니다. 그리고 이 트랜잭션은 명시적으로 COMMIT 또는 ROLLBACK을 호출하기 전까지 절대 끝나지 않습니다.

여기에 REPEATABLE READ가 결합되면 어떤 일이 벌어질까요?

autocommit=False + REPEATABLE READ 조합:

[서버 시작]
  pymysql.connect()  →  커넥션 생성 (autocommit=False)

[첫 번째 API 요청]
  cursor.execute("SELECT ...")
  → 암묵적 트랜잭션 시작 + 첫 SELECT이므로 이 시점에 스냅샷 생성
  → 결과: status = 'PENDING'

[외부에서 데이터 변경 + COMMIT]

[두 번째 API 요청]
  cursor.execute("SELECT ...")
  → 같은 커넥션, 같은 트랜잭션 (COMMIT한 적이 없으므로)
  → 같은 스냅샷을 읽음
  → 결과: status = 'PENDING' (변경 반영 안 됨)

[세 번째, 네 번째... N번째 요청]
  → COMMIT이 없으니 스냅샷이 영원히 갱신되지 않음
  → 서버를 재시작하기 전까지 변경된 데이터를 볼 수 없음

이것이 문제의 원인입니다. SELECT만 실행하는 읽기 전용 코드라도, autocommit=False면 첫 SELECT 시점의 스냅샷에 갇힙니다. COMMIT을 명시적으로 호출하지 않는 한, 외부에서 아무리 데이터를 변경해도 이 커넥션에서는 보이지 않습니다.

⚠️ 핵심 함정
"쓰기를 안 하니까 트랜잭션은 신경 안 써도 되겠지" — 이 가정이 함정입니다. SELECT도 트랜잭션 안에서 실행되며, autocommit=False일 때는 트랜잭션이 자동으로 시작되고 자동으로 끝나지 않습니다.

해결: autocommit=True

가장 깔끔한 해결법은 읽기 전용 커넥션에 autocommit=True를 설정하는 것입니다.

# ✅ 해결: autocommit=True 설정
conn = pymysql.connect(
    host='db.example.com',
    user='api_user',
    password='...',
    database='myapp',
    autocommit=True  # 이 한 줄이 핵심
)

autocommit=True면 각 SQL 문이 독립적인 트랜잭션으로 실행됩니다. SELECT 하나가 곧 하나의 트랜잭션이고, 실행이 끝나면 자동으로 COMMIT됩니다.

autocommit=True일 때:

[첫 번째 요청]
  SELECT ... → 암묵적 트랜잭션 시작 → 결과 반환 → 자동 COMMIT → 트랜잭션 종료

[외부에서 데이터 변경 + COMMIT]

[두 번째 요청]
  SELECT ... → 새 트랜잭션 시작 → 새 스냅샷 생성 → 변경된 값 확인!

매 SELECT마다 새로운 스냅샷을 읽으므로, 다른 커넥션에서 COMMIT한 변경이 즉시 반영됩니다.

대안: autocommit=True 외의 방법

상황에 따라 autocommit=True를 적용하기 어려울 수도 있습니다. 같은 커넥션으로 읽기와 쓰기를 모두 한다면, 무조건 autocommit을 켜는 것이 답은 아닙니다.

방법 1: 읽기 전에 명시적 COMMIT

# 조회 전에 이전 트랜잭션을 끊어주면 새 스냅샷을 읽는다
conn.commit()
cursor.execute("SELECT * FROM orders WHERE order_id = %s", (order_id,))

기존 트랜잭션을 COMMIT으로 명시적으로 종료하면, 다음 SELECT에서 새로운 트랜잭션(= 새 스냅샷)이 시작됩니다. 쓰기 작업이 섞여 있어서 autocommit을 쓸 수 없는 경우에 유용합니다.

방법 2: 세션 격리 수준 변경

cursor.execute("SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED")

격리 수준을 READ COMMITTED로 낮추면, autocommit=False여도 매 SELECT마다 새 스냅샷을 읽습니다. 다만 이 경우 동일 트랜잭션 내에서 반복 읽기 일관성(Repeatable Read)을 포기하는 것이므로, 트레이드오프를 이해하고 사용해야 합니다.

어떤 방법을 선택할까?

상황	추천 방법
읽기만 하는 커넥션	`autocommit=True`
읽기/쓰기 혼합, 쓰기에 트랜잭션 필요	읽기 전 `conn.commit()`
항상 최신 데이터를 읽어야 하는 특수한 경우	`READ COMMITTED`로 변경

✅ 팁
읽기 전용 커넥션과 쓰기 커넥션을 분리하면 가장 깔끔합니다. 읽기 커넥션은 autocommit=True, 쓰기 커넥션은 autocommit=False로 설정하면 각각의 목적에 맞는 트랜잭션 동작을 보장할 수 있습니다.

ORM을 쓰면 괜찮을까?

“raw 커넥션이 아니라 ORM을 사용하면 이 문제를 피할 수 있지 않을까?”라는 생각이 들 수 있습니다. 결론부터 말하면, ORM에 따라 다릅니다.

Django ORM — 기본적으로 안전

Django는 기본이 autocommit 모드입니다. 각 쿼리가 독립적으로 커밋되기 때문에 REPEATABLE READ 스냅샷 고정 문제가 발생하지 않습니다. @transaction.atomic() 블록 안에서만 트랜잭션이 열리고, 블록이 끝나면 자동으로 커밋됩니다.

SQLAlchemy — 패턴에 따라 다름

SQLAlchemy 2.0은 autobegin 패턴을 사용합니다. 쿼리를 실행하면 자동으로 트랜잭션이 시작되고, 반드시 session.commit() 또는 session.rollback()으로 끝내야 합니다. Session(autocommit=True) 옵션은 2.0에서 제거되었습니다.

웹 프레임워크에서 request 단위로 세션을 관리하면 (FastAPI의 Depends(get_db), Flask의 @app.teardown_appcontext) request마다 커밋/롤백이 일어나므로 대체로 안전합니다. 하지만 배치 스크립트나 Celery worker처럼 세션을 오래 열어두는 경우에는 raw 커넥션과 동일한 문제가 발생할 수 있습니다.

💡 참고
SQLAlchemy에서 읽기 전용 작업에 DBAPI 레벨 autocommit을 쓰고 싶다면 create_engine(..., isolation_level="AUTOCOMMIT") 또는 커넥션 단위로 connection.execution_options(isolation_level="AUTOCOMMIT")을 설정할 수 있습니다.

다른 드라이버의 기본값은?

이 함정이 PyMySQL에만 있는 건 아닐까요? 주요 Python DB 드라이버의 autocommit 기본값을 정리해보겠습니다.

드라이버	기본 autocommit	DB 기본 격리 수준	이 문제 발생?
PyMySQL	`False`	REPEATABLE READ	O
mysqlclient	`False`	REPEATABLE READ	O
psycopg2 (PostgreSQL)	`False`	READ COMMITTED	X

Python DB-API 2.0 (PEP 249) 표준은 autocommit=False를 기본값으로 권장합니다. 그래서 위 드라이버들은 모두 기본이 False입니다.

그런데 psycopg2는 같은 autocommit=False인데 왜 이 문제가 안 생길까요? PostgreSQL의 기본 격리 수준이 READ COMMITTED이기 때문입니다. READ COMMITTED는 매 SELECT마다 새 스냅샷을 읽으므로, 트랜잭션이 열려 있어도 다른 커넥션의 COMMIT이 보입니다. 결국 이 문제는 MySQL의 기본 격리 수준(REPEATABLE READ)과 PEP 249의 기본값(autocommit=False)이라는 두 기본값이 만나야 발생하는 함정입니다.

⚠️ 주의
PostgreSQL에서도 격리 수준을 REPEATABLE READ로 올리면 동일한 문제가 발생합니다. "MySQL만의 문제"가 아니라 "REPEATABLE READ + autocommit=False 조합"의 문제입니다.

읽기 전용 커넥션 체크리스트

Python에서 DB를 읽기 전용으로 연결할 때 확인할 항목들을 정리합니다.

📌 읽기 전용 커넥션 점검 항목

autocommit=True가 명시적으로 설정되어 있는가?
커넥션 풀을 사용한다면, 풀에서 꺼낸 커넥션의 autocommit 상태가 보장되는가?
ORM을 쓰지 않고 raw 커넥션을 쓴다면, PEP 249 기본값(autocommit=False)을 인지하고 있는가?
읽기와 쓰기 커넥션이 분리되어 있는가?
장시간 유지되는 커넥션(서버 시작 시 생성 → 종료까지 유지)이 있다면, 해당 커넥션의 트랜잭션 수명을 확인했는가?

마치며

이 문제가 까다로운 이유는 “SELECT만 하는데 트랜잭션이 왜 중요하지?”라는 선입견 때문입니다. 쓰기를 하지 않으니 트랜잭션을 신경 쓸 필요가 없다고 생각하기 쉽습니다.

핵심은 하나입니다. MySQL에서 모든 SQL 문은 트랜잭션 안에서 실행됩니다. autocommit=False면 첫 번째 SELECT가 트랜잭션을 열고, 명시적 COMMIT 없이는 그 트랜잭션이 영원히 유지됩니다. REPEATABLE READ 격리 수준에서 이는 곧 첫 번째 SELECT 시점의 데이터에 갇히는 것을 의미합니다.

참고자료

Airflow에서 15년 된 SQL Server 연결하기: pymssql 실패부터 Custom Hook까지

Donhyeok Kang — Fri, 03 Apr 2026 00:00:00 GMT

운영 중인 서비스의 데이터를 Airflow로 가져와야 했습니다. 문제는 그 DB가 SQL Server 2008 R2라는 것. 2010년에 출시된, 15년 된 레거시 데이터베이스입니다. DBeaver에서 jTDS 드라이버로 연결했을 때는 아무 문제가 없었기에 금방 될 거라 생각했는데, Airflow에서는 첫 시도부터 막혔습니다.

DB-Lib error message 20002, severity 9:
Adaptive Server connection failed

Airflow의 공식 MSSQL Provider(apache-airflow-providers-microsoft-mssql)는 내부적으로 pymssql을 사용하는데, 이 라이브러리가 SQL Server 2008 R2와 호환되지 않는 게 원인이었습니다. DBeaver는 되는데 Airflow는 안 되는 상황 — 이 차이에서 실마리를 찾기 시작했습니다.

왜 pymssql은 실패하는가 — TDS 프로토콜

원인을 이해하려면 TDS(Tabular Data Stream) 프로토콜부터 짚어야 합니다. SQL Server가 클라이언트와 통신할 때 사용하는 프로토콜인데, SQL Server 버전마다 지원하는 TDS 버전이 다릅니다.

SQL Server 버전	출시	TDS 버전
SQL Server 2005	2005	TDS 7.2
SQL Server 2008 R2	2010	TDS 7.3
SQL Server 2012+	2012	TDS 7.4

pymssql은 내부적으로 FreeTDS 라이브러리를 사용합니다. FreeTDS는 freetds.conf의 TDS 버전 설정에 따라 프로토콜 핸드셰이크를 시도하는데, 최신 FreeTDS가 레거시 서버와의 프로토콜 협상을 제대로 처리하지 못하는 경우가 있습니다. pymssql에서 tds_version='7.1'을 명시하면 연결이 될 수도 있지만, 안정성이 보장되지 않습니다.

pymssql (FreeTDS)
└─ 프로토콜 핸드셰이크 실패
   └─ DB-Lib error 20002

jTDS (DBeaver)
└─ 레거시 TDS 프로토콜까지 유연하게 지원
   └─ SQL Server 2008 R2와 호환 → 연결 성공

DBeaver가 연결에 성공한 이유는 jTDS라는 순수 Java JDBC 드라이버를 사용하기 때문입니다. jTDS는 레거시 TDS 버전 지원에 특화되어 있습니다. “동작하는 사례가 있다”는 건 SQL Server 자체의 문제가 아니라 클라이언트 드라이버의 문제라는 뜻이었고, MS 공식 ODBC Driver를 쓰는 게 가장 확실한 해결책이라 판단했습니다.

해결 전략 — pyodbc + ODBC Driver 18

pymssql 대신 pyodbc를 선택한 이유는 네 가지입니다:

Microsoft 공식 드라이버 — ODBC Driver for SQL Server는 MS가 직접 관리하며, SQL Server 2008 R2를 공식 지원합니다
안정적인 프로토콜 협상 — MS 공식 Driver가 레거시 SQL Server까지 적절한 TDS 버전을 자동으로 협상합니다
한글 인코딩 — CP949 인코딩을 명시적으로 설정할 수 있습니다
ARM64 지원 — ODBC Driver 18은 ARM64 + AMD64 모두 지원합니다 (Debian 12 ARM64 패키지는 Driver 18부터 제공)

전체 계층 구조는 이렇습니다.

Python 코드 (Airflow Task)
    ↓
DB-API 2.0 (PEP 249)
    ↓
pyodbc (DB-API 구현체)
    ↓
ODBC Driver 18 for SQL Server
    ↓
TDS 프로토콜
    ↓
SQL Server 2008 R2

각 계층의 역할이 분리되어 있어서, 문제가 생겼을 때 어느 계층에서 터졌는지 추적하기 좋습니다. 실제로 이 글에서 다루는 에러들도 Docker 빌드, OpenSSL, pyodbc, Airflow XCom 등 각각 다른 계층에서 발생했습니다.

Docker 환경 구축

Airflow를 Docker로 운영하고 있어서, 컨테이너 안에 ODBC Driver를 설치해야 합니다. Dockerfile 자체는 짧지만 생각보다 신경 쓸 부분이 많았습니다.

FROM apache/airflow:3.1.0

USER root

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        curl gnupg2 ca-certificates ffmpeg \
        unixodbc unixodbc-dev && \
    # Microsoft GPG 키 추가 (gpg --dearmor 방식)
    curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | \
        gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg && \
    echo "deb [signed-by=/usr/share/keyrings/microsoft-prod.gpg] \
        https://packages.microsoft.com/debian/12/prod bookworm main" \
        > /etc/apt/sources.list.d/mssql-release.list && \
    apt-get update && \
    ACCEPT_EULA=Y apt-get install -y msodbcsql18 && \
    # SQL Server 2008 R2 호환을 위한 OpenSSL 레거시 SSL 설정
    printf '\n[openssl_init]\nssl_conf = ssl_sect\n\n[ssl_sect]\nsystem_default = system_default_sect\n\n[system_default_sect]\nOptions = UnsafeLegacyRenegotiation\n' \
        >> /etc/ssl/openssl.cnf && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

USER airflow

msodbcsql18 — Driver 17이 아닌 이유

처음에는 ODBC Driver 17을 설치하려 했는데, Unable to locate package msodbcsql17 에러가 나왔습니다. Debian 12(bookworm) ARM64 환경에서는 Driver 17 패키지가 제공되지 않았기 때문입니다. 개발 환경이 Mac(ARM64)이라 빌드 자체가 안 됐고, Driver 18로 변경하니 ARM64와 AMD64 모두 정상 빌드가 가능했습니다.

GPG 키 — apt-key add는 deprecated

apt-key add 방식은 Debian 12부터 deprecated되었습니다. gpg --dearmor로 키를 변환해서 /usr/share/keyrings/에 저장하고, sources.list에서 signed-by로 참조해야 합니다. 이전 방식대로 했다가 NO_PUBKEY EB3E94ADBE1229CF 에러를 만났습니다.

OpenSSL UnsafeLegacyRenegotiation

가장 찾기 어려운 함정이었습니다. Driver 설치까지 끝내고 연결을 시도했더니:

SSL Provider:
[error:0A000152:SSL routines::unsafe legacy renegotiation disabled]

OpenSSL 3.x부터 레거시 SSL 재협상(renegotiation)이 기본 비활성화되었는데, SQL Server 2008 R2가 TLS 1.0/1.1 시절의 SSL 협상 방식을 사용하기 때문에 발생하는 문제입니다. OpenSSL 설정에서 UnsafeLegacyRenegotiation을 명시적으로 허용해야 합니다. 참고로 ODBC Driver 18은 기본값이 Encrypt=yes이기 때문에, 연결 문자열에서 Encrypt=no를 쓰더라도 이 설정을 넣어두면 나중에 암호화를 켤 때 별도 수정 없이 바로 동작합니다.

⚠️ 주의
UnsafeLegacyRenegotiation은 보안을 약간 낮추는 설정입니다. 내부망에서 레거시 DB에 연결하는 용도로만 사용하고, 외부 인터넷 통신에는 절대 적용하지 마세요.

Custom MSSQLHook 구현

Airflow의 공식 MSSQL Provider가 pymssql 기반이라, pyodbc로 연결하려면 Hook을 직접 만들어야 합니다. Provider 패키지 자체는 Airflow UI에서 Connection 타입을 선택하기 위해 유지하고, 실제 연결은 Custom Hook이 담당합니다.

# pyproject.toml
dependencies = [
    "apache-airflow-providers-microsoft-mssql>=4.4.0",  # UI에서 Connection 타입 선택용
    "pyodbc>=5.3.0",  # 실제 MSSQL 연결용
]

Hook 코드는 다음과 같습니다.

src/hook/mssql_hook.py

import pyodbc
from airflow.hooks.base import BaseHook


class MSSQLHook(BaseHook):
    conn_name_attr = "mssql_conn_id"
    default_conn_name = "mssql_default"

    def __init__(self, mssql_conn_id="mssql_default"):
        super().__init__()
        self.mssql_conn_id = mssql_conn_id

    def get_conn(self):
        conn = self.get_connection(self.mssql_conn_id)
        extra = conn.extra_dejson
        charset = extra.get("charset")

        connection_string = (
            f"DRIVER={{ODBC Driver 18 for SQL Server}};"
            f"SERVER={conn.host},{conn.port or 1433};"
            f"DATABASE={conn.schema};"
            f"UID={conn.login};"
            f"PWD={conn.password};"
            f"Encrypt=no;"
            f"TrustServerCertificate=yes;"
        )

        client = pyodbc.connect(connection_string)

        if charset:
            try:
                client.setdecoding(pyodbc.SQL_CHAR, encoding=charset)
                client.setdecoding(pyodbc.SQL_WCHAR, encoding=charset)
                client.setencoding(encoding=charset)
            except Exception:
                pass  # 인코딩 미지원 시 기본값 사용

        return client

    def run(self, sql):
        client = self.get_conn()
        try:
            cursor = client.cursor()
            cursor.execute(sql)
            results = cursor.fetchall()
            cursor.close()
            return results
        finally:
            client.close()

Encrypt=no, TrustServerCertificate=yes

SQL Server 2008 R2는 TLS 1.2를 지원하지 않을 수 있습니다. Encrypt=no로 암호화를 끄고, TrustServerCertificate=yes로 자체 서명 인증서를 허용했습니다. 내부망 전용이라 보안 리스크는 수용 가능한 수준입니다.

인코딩은 강제하지 않는다

처음에는 모든 연결에 CP949 인코딩을 강제 적용했는데, UTF-8 데이터가 섞여 있는 테이블에서 UnicodeDecodeError가 터졌습니다. 결국 Airflow Connection의 Extra JSON에 charset을 명시한 경우에만 인코딩을 적용하는 방식으로 바꿨습니다.

// Airflow Connection Extra (charset이 필요한 경우만)
{"charset": "cp949"}

강제보다 유연한 설정이 운영에서 훨씬 안전합니다.

Connection Pooling은 불필요

Airflow Task는 단발성 실행이라, Task가 시작되면 연결하고 끝나면 닫으면 됩니다. 커넥션 풀을 유지할 이유가 없고, 관리 복잡도만 올라갑니다.

실전 파이프라인 — MSSQL → ClickHouse 동기화

연결이 되고 나면, 실제로 데이터를 어떻게 옮기느냐가 다음 문제입니다. 현재 MSSQL에서 데이터를 꺼내 ClickHouse로 동기화하는 일일 배치 파이프라인을 운영하고 있습니다.

증분 배치 동기화

전체 데이터를 매번 덤프하면 비효율적이기 때문에, 마지막으로 동기화한 ID 이후의 데이터만 가져오는 증분 방식을 사용합니다.

1. ClickHouse에서 마지막 동기화된 max_idx 조회
2. MSSQL에서 max_idx 이후 데이터를 TOP N으로 배치 조회
3. pyodbc.Row → list 변환 + 데이터 검증
4. ClickHouse에 배치 INSERT
5. 다음 배치로 이동 (current_idx 갱신)
6. 전부 끝나면 OPTIMIZE TABLE FINAL (중복 제거)

핵심 Task 코드를 간략화하면 이렇습니다.

@task(
    retries=1,
    retry_delay=timedelta(seconds=10),
    on_failure_callback=task_failure_callback,
)
def sync_orders(last_idx: int, batch_size: int = 1000):
    mssql_hook = MSSQLHook(mssql_conn_id="mssql_default")
    ch_hook = ClickHouseHook(clickhouse_conn_id="clickhouse")

    # MSSQL에서 최대 ID 조회
    max_result = mssql_hook.run("SELECT MAX(id) FROM orders")
    max_idx = max_result[0][0] if max_result and max_result[0][0] else 0

    if last_idx >= max_idx:
        logging.info("No new data to sync")
        return

    # 배치 단위 동기화
    ch_conn = ch_hook.get_conn()
    current_idx = last_idx
    total_synced = 0

    while current_idx < max_idx:
        sql = f"""
        SELECT TOP {batch_size} *
        FROM orders
        WHERE id > {current_idx}
        ORDER BY id
        """
        batch_data = mssql_hook.run(sql)

        if not batch_data:
            break

        # pyodbc.Row → list 변환
        processed = [list(row) for row in batch_data]

        ch_conn.insert(
            table="orders",
            data=processed,
            column_names=[...]
        )

        current_idx = processed[-1][0]
        total_synced += len(processed)
        logging.info(f"Synced {len(processed)} rows, total: {total_synced}")

    # ReplacingMergeTree 중복 제거
    try:
        ch_hook.run("OPTIMIZE TABLE orders FINAL")
    except Exception as e:
        logging.warning(f"OPTIMIZE TABLE failed (non-critical): {e}")

설계 포인트

pyodbc.Row → list 변환이 필수입니다. pyodbc.Row 객체는 ClickHouse INSERT나 Airflow XCom 직렬화에서 그대로 사용할 수 없습니다. list(row) 또는 tuple(row)로 변환해야 하고, 빠뜨리면 TypeError: cannot serialize object of type <class 'pyodbc.Row'> 에러가 발생합니다.

OPTIMIZE TABLE FINAL은 try-except로 감쌌습니다. ClickHouse의 ReplacingMergeTree 엔진은 OPTIMIZE가 실패해도 데이터가 유실되지 않고, 다음 자동 머지에서 중복이 제거됩니다. 비핵심 작업의 실패가 전체 파이프라인을 중단시킬 필요는 없습니다.

TOP N 페이지네이션을 쓰는 이유가 있습니다. SQL Server 2008 R2는 OFFSET ... FETCH 문법을 지원하지 않습니다. SQL Server 2012부터 추가된 기능이기 때문에, 레거시 호환을 위해 WHERE id > {current_idx} ORDER BY id와 TOP N 조합으로 페이지네이션을 구현했습니다.

만났던 에러 정리

연결 성공까지 거쳐간 에러들을 정리합니다. 각각 다른 계층에서 발생한 문제들이라, 레거시 MSSQL 연동을 시도하는 분들에게 참고가 될 수 있습니다.

#	에러	원인	해결
1	`NO_PUBKEY EB3E94ADBE1229CF`	`apt-key add` deprecated (Debian 12+)	`gpg --dearmor` 방식으로 변경
2	`Unable to locate package msodbcsql17`	Debian 12 ARM64 패키지 미제공	Driver 18 사용
3	`SSL routines::unsafe legacy renegotiation disabled`	OpenSSL 3.x 보안 정책	`UnsafeLegacyRenegotiation` 설정
4	`UnicodeDecodeError: 'cp949'`	CP949 강제 적용 시 UTF-8 데이터 충돌	Connection Extra에서 charset 선택 적용
5	`TypeError: cannot serialize pyodbc.Row`	XCom은 기본 타입만 직렬화 가능	`list(row)` 변환

마치며

레거시 시스템 연동은 코드가 아니라 프로토콜 레벨에서 문제가 생깁니다. TDS 버전, SSL 핸드셰이크, 문자 인코딩 — 평소에는 의식하지 않는 계층들이 15년 된 DB 앞에서 하나씩 드러납니다. “DBeaver는 되는데 왜 안 되지?”라는 질문에서 출발해, 클라이언트 드라이버의 차이를 이해하고 나서야 올바른 방향을 잡을 수 있었습니다.

참고자료

Claude Code 아키텍처 분석: 프로덕션 AI 에이전트는 어떻게 설계되는가

Donhyeok Kang — Thu, 02 Apr 2026 00:00:00 GMT

이전 글에서는 유출된 Claude Code 소스코드에서 무엇이 발견됐는지를 다뤘습니다. Anti-Distillation, Undercover Mode, KAIROS 같은 흥미로운 기능들이었죠.

이번 글에서는 한 걸음 더 들어갑니다. 어떻게 만들었는지를 봅니다.

51만줄의 TypeScript 코드 속에는 프로덕션 AI 에이전트를 설계할 때 마주하는 핵심 문제들 — 도구를 어떻게 관리하는지, 권한을 어떻게 통제하는지, 비용을 어떻게 줄이는지, 여러 에이전트를 어떻게 조율하는지 — 에 대한 Anthropic의 답이 담겨 있습니다. AI 에이전트를 만들거나 관심 있는 개발자라면, 이보다 좋은 참고 자료를 찾기 어려울 겁니다.

전체 구조: 51만줄의 지도

먼저 큰 그림부터 보겠습니다. Claude Code는 다음과 같은 기술 스택으로 구성되어 있습니다.

구성 요소	기술
런타임	Bun (TypeScript/JavaScript)
UI	React + Ink (터미널 렌더링)
CLI	Commander.js
코드 규모	~1,900 파일, 301 디렉토리, 512,000+ 줄

핵심 진입점은 두 곳입니다. main.tsx가 CLI 초기화와 React/Ink UI를 담당하고, QueryEngine.ts(46,000줄)가 LLM과의 전체 대화 루프를 관리합니다.

main.tsx (CLI 초기화)
    │
    ▼
QueryEngine.ts (대화 루프)
    │
    ├── System Prompt 조합
    │     ├── 정적 프롬프트 (도구, 지침)
    │     └── 동적 프롬프트 (git status, CLAUDE.md, 날짜)
    │
    ├── Tool Router
    │     ├── 40+ 도구 실행
    │     └── 권한 검증
    │
    ├── Context Manager
    │     ├── 자동 압축 (compaction)
    │     └── 메모리 시스템 (MEMORY.md)
    │
    └── API Client
          ├── 프롬프트 캐시
          └── 토큰 추정

특이한 점은 부팅 최적화입니다. 무거운 모듈(OpenTelemetry, gRPC, analytics)은 지연 로딩하고, 시작 시 MDM 설정 읽기, 키체인 프리페치, API 사전 연결, 모델 호환성 확인을 모두 병렬로 실행합니다. CLI 도구에서 체감 시작 속도가 중요하다는 걸 잘 알고 있는 설계입니다.

도구 시스템: 40+개 도구는 어떻게 관리되는가

Claude Code에는 40개 이상의 도구가 등록되어 있습니다. 각 도구는 독립적인 모듈로, 입력 스키마(Zod 기반 검증), 권한 모델, 실행 로직, 진행 상태 추적을 모두 자체적으로 갖추고 있습니다.

핵심 도구 분류

카테고리	도구	역할
파일 조작	`FileReadTool`, `FileEditTool`, `FileWriteTool`	파일 읽기/수정/생성 (이미지, PDF, Jupyter 지원)
검색	`GlobTool`, `GrepTool`	파일 패턴 매칭, ripgrep 기반 콘텐츠 검색
실행	`BashTool`	셸 명령 실행 (스트리밍 출력)
웹	`WebFetchTool`, `WebSearchTool`	URL 콘텐츠 가져오기, 웹 검색 (Brave API)
에이전트	`AgentTool`, `SendMessageTool`	서브에이전트 생성, 에이전트 간 메시지 전달
확장	`MCPTool`, `SkillTool`	MCP 서버 도구 호출, 재사용 가능한 스킬 실행
작업 관리	`TaskCreateTool`, `TodoWriteTool`	구조화된 작업 추적
환경	`EnterWorktreeTool`, `CronCreateTool`	Git worktree 격리, 스케줄링

피처 플래그로 도구 게이팅

모든 도구가 항상 활성화되는 것은 아닙니다. Bun의 bun:bundle 빌드 타임 피처 플래그로 **죽은 코드 제거(Dead Code Elimination)**를 수행합니다.

// 빌드 타임에 조건부 포함
if (feature('PROACTIVE')) {
  // 자율 에이전트 모드 관련 도구
}
if (feature('VOICE_MODE')) {
  // 음성 입력 관련 도구
}
if (feature('COORDINATOR_MODE')) {
  // 다중 에이전트 오케스트레이션
}

발견된 44개 피처 플래그 중 주요한 것들입니다:

플래그	기능
`PROACTIVE`	자율 에이전트 모드
`KAIROS`	백그라운드 데몬 에이전트
`VOICE_MODE`	음성 입력
`COORDINATOR_MODE`	다중 워커 오케스트레이션
`BASH_CLASSIFIER`	AI 기반 bash 명령 자동 승인
`AGENT_TRIGGERS`	스케줄된 에이전트

이 방식의 장점은 외부 배포 바이너리의 크기를 줄이면서도 내부적으로는 실험적 기능을 계속 개발할 수 있다는 것입니다. Anthropic 내부 빌드와 외부 배포 빌드의 기능 차이가 코드 레벨이 아닌 빌드 레벨에서 관리됩니다.

권한 모델: 4계층 방어선

AI 에이전트에서 가장 민감한 문제는 “이 도구를 실행해도 되는가?”입니다. Claude Code는 이를 4계층 권한 모델로 해결합니다.

사용자 요청
    │
    ▼
┌─────────────────────────────────┐
│  Layer 1: Hooks (자동 실행)       │
│  설정된 훅이 있으면 먼저 실행       │
│  → approve / deny / pass-through │
├─────────────────────────────────┤
│  Layer 2: AI Classifier          │
│  (bash 전용, 피처 플래그 뒤)       │
│  LLM이 명령의 안전성 평가           │
│  → safe / unsafe / uncertain    │
├─────────────────────────────────┤
│  Layer 3: User Dialog            │
│  사용자에게 직접 승인 요청           │
│  → allow / deny                 │
├─────────────────────────────────┤
│  Layer 4: Persist                │
│  결정을 규칙으로 영구 저장           │
│  → alwaysAllow / alwaysDeny     │
└─────────────────────────────────┘

앞쪽 3개 계층(Hooks, Classifier, Dialog)이 실질적인 방어선이고, Persist는 내려진 결정을 규칙으로 저장하는 후처리 단계입니다. 각 방어 계층은 단락(short-circuit) 가능합니다. 훅이 승인하면 나머지 계층을 건너뛰고, AI Classifier가 안전하다고 판단하면 사용자에게 묻지 않습니다.

영구 규칙 시스템

사용자가 한 번 승인한 패턴은 규칙으로 저장할 수 있습니다:

// settings.json
{
  "alwaysAllowRules": ["npm test", "git status"],  // 항상 자동 승인
  "alwaysDenyRules": ["rm -rf /"],                  // 항상 차단
  "alwaysAskRules": ["git push"]                     // 항상 사용자 확인
}

alwaysAskRules는 자동 승인을 우회합니다. git push처럼 위험하지는 않지만 항상 의식적으로 실행하고 싶은 명령에 유용합니다.

💡 참고
AI Classifier는 현재 bash 명령 전용이며, 피처 플래그(BASH_CLASSIFIER) 뒤에 있습니다. LLM을 호출해서 "이 명령이 안전한가?"를 평가하는 방식인데, 확신이 없으면 사용자에게 넘깁니다. "자동화할 수 있는 판단은 자동화하되, 불확실하면 사람에게"라는 원칙이 명확합니다.

이 설계가 영리한 이유는 사용 맥락에 따라 계층을 유연하게 조합할 수 있다는 점입니다. 대화형 CLI에서는 4계층 모두 활성화하고, 비대화형(CI/CD) 모드에서는 훅과 규칙만 사용하고, 서브에이전트에서는 UI 없이 훅+분류기만 사용합니다.

프롬프트 캐시: 비용을 크게 줄이는 경계 마커

LLM API 비용에서 가장 큰 부분을 차지하는 것은 시스템 프롬프트입니다. 매 턴마다 동일한 시스템 프롬프트를 보내야 하니까요. Claude Code는 이 문제를 경계 마커(Boundary Marker) 패턴으로 해결합니다.

// systemPromptSections.ts (pseudo-code)
const systemPrompt = [
  // ── 정적 영역 (캐시됨) ──────────────────────
  cachedSection('tools', toolDefinitions),
  cachedSection('instructions', coreInstructions),
  cachedSection('permissions', permissionRules),

  // ── 경계 마커 ──────────────────────────────
  SYSTEM_PROMPT_DYNAMIC_BOUNDARY,

  // ── 동적 영역 (캐시 안 됨) ────────────────
  uncachedSection('git_status', getCurrentGitStatus()),
  uncachedSection('claude_md', loadClaudeMd()),
  uncachedSection('date', new Date().toISOString()),
];

SYSTEM_PROMPT_DYNAMIC_BOUNDARY를 기준으로:

영역	캐시 범위	내용
경계 위 (정적)	글로벌 (모든 사용자 공유)	도구 정의, 지침, 권한 규칙
경계 아래 (동적)	캐시 안 됨	git status, CLAUDE.md, 날짜

정적 영역은 모든 사용자, 모든 조직에서 동일하므로 글로벌 캐시로 공유됩니다. 동적 영역은 사용자와 세션마다 달라지므로 캐시하지 않습니다. 이 분리만으로도 시스템 프롬프트 토큰의 상당 부분을 캐시 히트로 처리할 수 있습니다.

각 섹션도 개별적으로 메모이제이션됩니다. cachedSection은 내용이 바뀌지 않으면 이전 결과를 재사용하고, DANGEROUS_uncachedSystemPromptSection으로 표시된 섹션은 변경 시 캐시를 깨뜨립니다.

📌 핵심 요약

프롬프트 캐시 전략의 핵심은 "변하는 것과 변하지 않는 것을 물리적으로 분리하라"입니다. 도구 정의와 지침은 거의 변하지 않으니 앞에, git status와 메모리는 매번 변하니 뒤에 배치합니다. 이 순서만 바꿔도 캐시 히트율이 크게 달라집니다.

컨텍스트 관리: 대화를 무한히 이어가는 법

LLM의 컨텍스트 윈도우는 유한합니다. 긴 코딩 세션에서는 금방 한계에 도달하죠. Claude Code는 이를 자동 압축(Auto-Compaction) 시스템으로 해결합니다.

자동 압축

컨텍스트가 한계에 가까워지면, 이전 메시지를 LLM에게 요약하도록 요청합니다. 원본 대화 이력은 JSONL 파일로 전체 보존하면서, API로 보내는 메시지만 압축된 버전으로 교체합니다.

[원본 메시지 20개] → LLM 요약 → [요약 1개 + 최근 메시지 5개]
                                    │
                    원본은 JSONL로 보존 (복원 가능)

토큰 추정

API 호출 전에 토큰 수를 미리 추정합니다. 시스템 프롬프트, 대화 이력, 도구 정의를 모두 합산해서 예산 한도(--max-budget-usd)를 초과하지 않도록 제어합니다. 비용 폭주를 방지하는 안전장치입니다.

메모리 시스템

Claude Code에는 세션을 넘어 지속되는 두 가지 메모리가 있습니다:

메모리	위치	용도	제한
CLAUDE.md	프로젝트 루트	프로젝트별 지침, 컨벤션	디렉토리 워크로 자동 발견
MEMORY.md	`~/.claude/`	사용자 선호, 피드백, 프로젝트 맥락	200줄, 25KB

CLAUDE.md는 프로젝트에 체크인되어 팀원과 공유되고, MEMORY.md는 개인 메모리로 대화 간 학습을 유지합니다. 둘 다 시스템 프롬프트의 동적 영역에 주입됩니다.

⚠️ 주의
1편에서 다뤘듯이, 자동 압축에는 심각한 버그가 있었습니다. 1,279개 세션에서 50회 이상 연속 실패하며 하루 25만 API 호출이 낭비되고 있었습니다. 무한 대화를 가능하게 하는 핵심 시스템이지만, 실패 시의 비용도 그만큼 큽니다.

Coordinator Mode: 다중 에이전트 오케스트레이션

Claude Code의 가장 야심찬 설계는 Coordinator Mode입니다. 환경 변수 CLAUDE_CODE_COORDINATOR_MODE=1로 활성화되는 이 모드는 하나의 코디네이터가 여러 워커 에이전트를 지휘하는 구조입니다.

┌───────────────────────────────────────────┐
│              Coordinator                   │
│  역할: 작업 분배, 결과 합성                   │
│  도구: AgentTool, SendMessage, TaskStop    │
│                                           │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐     │
│  │ Worker 1 │ │ Worker 2 │ │ Worker 3 │     │
│  │ (조사)    │ │ (구현)    │ │ (테스트)   │     │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘     │
│       │            │            │           │
│       └────────────┼────────────┘           │
│                    ▼                        │
│            Scratchpad (공유)                  │
│     워커 간 지식 공유용 영구 디렉토리              │
└───────────────────────────────────────────┘

핵심 설계 원칙

코디네이터의 시스템 프롬프트에서 발견된 가장 중요한 규칙은 이것입니다:

“코디네이터는 워커의 결과를 절대 예측하지 않는다. 오직 합성(synthesize)만 한다.”

이게 왜 중요할까요? AI 에이전트 시스템에서 가장 흔한 실패 패턴은 코디네이터가 워커에게 작업을 위임한 뒤, 결과를 기다리지 않고 추측으로 다음 단계를 진행하는 것입니다. Claude Code는 이를 아키텍처 레벨에서 방지합니다.

워크플로우

Coordinator Mode의 권장 워크플로우는 4단계입니다:

Research — 워커들이 병렬로 코드베이스를 조사
Synthesis — 코디네이터가 조사 결과를 종합해 구현 계획 수립
Implementation — 워커들이 계획에 따라 병렬 구현
Verification — 테스트 실행, 결과 검증

워커의 결과는 <task-notification> XML 형식으로 코디네이터에게 전달됩니다:

<task-notification>
  <task-id>worker-1-research</task-id>
  <status>completed</status>
  <result>src/auth/ 디렉토리에 3개 파일 발견...</result>
  <usage>tokens: 15,234</usage>
</task-notification>

Scratchpad: 워커 간 지식 공유

워커들은 서로 직접 통신하지 않습니다. 대신 Scratchpad라는 공유 디렉토리를 통해 간접적으로 지식을 공유합니다. 한 워커가 발견한 정보를 파일로 남기면, 다른 워커가 필요할 때 읽는 방식입니다.

이 설계는 의도적입니다. 워커 간 직접 통신을 허용하면 의존성이 복잡해지고, 데드락이나 무한 루프의 위험이 생깁니다. 파일 기반 공유는 느리지만 안전합니다.

엔지니어링 패턴 모음

유출된 코드 곳곳에서 발견되는 패턴들을 정리합니다. AI 에이전트를 만드는 개발자라면 참고할 만한 것들입니다.

패턴 1: Async Generator로 도구 결과 스트리밍

도구 실행 결과를 async generator(async function*)로 스트리밍합니다. 긴 bash 명령이나 대용량 파일 읽기에서 결과가 생성되는 즉시 UI에 반영됩니다.

// 도구 결과 스트리밍 (pseudo-code)
async function* executeTool(tool, input) {
  for await (const chunk of tool.execute(input)) {
    yield { type: 'progress', data: chunk };
  }
  yield { type: 'complete', result: finalResult };
}

사용자가 터미널에서 실시간으로 진행 상황을 볼 수 있는 이유가 이것입니다.

패턴 2: 투기적 실행(Speculative Execution)

사용자가 타이핑하는 동안 백그라운드에서 미리 응답을 생성합니다. 파일 편집이나 bash 명령처럼 부작용이 있는 작업에서는 멈추고, 안전한 범위에서만 선행 실행합니다.

// speculation mode (pseudo-code)
if (appState.speculation.enabled) {
  // 사용자 입력 중 백그라운드 응답 생성
  const specResult = await generateSpeculatively(context);

  // 파일 편집, bash 명령 등은 투기적 실행 불가
  if (specResult.hitsBoundary) {
    await rollback(specResult);
  }
  // 시간 절약 추적
  trackTimeSaved(specResult.savedMs);
}

패턴 3: 순환 의존성의 런타임 해결

대규모 TypeScript 프로젝트에서 흔한 순환 의존성 문제를 require()로 해결합니다. ES6 import 대신 런타임에 실제로 필요한 시점에 모듈을 로드하는 방식입니다.

// ES6 import → 순환 의존성 에러
// import { QueryEngine } from './QueryEngine';

// require() → 런타임에 지연 로드
function getQueryEngine() {
  return require('./QueryEngine').QueryEngine;
}

패턴 4: 파일 상태 LRU 캐시

같은 파일을 한 턴에 여러 번 읽는 것을 방지합니다. 최근 읽은 파일을 LRU 캐시에 보관하고, 동일한 파일 요청이 오면 캐시에서 반환합니다. 세션 간에는 초기화됩니다(SDK 모드 제외).

패턴 5: 설정 소스 우선순위

설정이 여러 곳에서 올 수 있을 때, 명확한 우선순위가 필요합니다:

1. CLI 플래그           (최우선)
2. 환경 변수
3. MDM (기업 관리)
4. ~/.claude/settings.json
5. 기본값               (최하위)

기업 환경(MDM)과 개인 설정이 충돌할 때의 우선순위까지 고려한 설계입니다.

마치며

유출된 Claude Code의 소스코드를 분석하면서 가장 인상 깊었던 것은, 결국 AI 에이전트도 소프트웨어 엔지니어링의 기본 원칙을 따른다는 점입니다.

모듈화: 도구마다 독립적 스키마, 권한, 실행 로직
계층화: 권한은 4계층, 캐시는 2계층, 설정은 5단계 우선순위
관심사 분리: 정적/동적 프롬프트 분리, 코디네이터/워커 역할 분리
비용 의식: 프롬프트 캐시, 토큰 추정, 예산 제한

AI라는 새로운 도메인이지만, 좋은 설계의 원칙은 변하지 않았습니다. 다만 “LLM API 호출 비용”이라는 새로운 차원의 제약이 추가되면서, 캐시 전략과 컨텍스트 관리가 전통적인 소프트웨어보다 훨씬 더 중요해졌다는 점이 차이라면 차이입니다.

이 두 편의 분석이 AI 에이전트를 만들거나 이해하고자 하는 분들에게 실질적인 참고가 되었으면 합니다.

참고자료

Claude Code 소스코드 유출: 51만줄에서 발견된 7가지 비밀

Donhyeok Kang — Wed, 01 Apr 2026 00:00:00 GMT

2026년 3월 31일, 보안 연구자 한 명이 X(트위터)에 올린 짧은 글 하나가 AI 업계를 뒤흔들었습니다.

“Anthropic just mass-leaked their source code via npm… again.”

Anthropic이 @anthropic-ai/claude-code v2.1.88을 npm에 배포하면서, 59.8MB짜리 소스맵 파일을 실수로 포함시킨 겁니다. 이 .map 파일은 Cloudflare R2 스토리지에 호스팅된 비난독화(unobfuscated) TypeScript 소스 아카이브를 그대로 가리키고 있었습니다. 약 1,900개 파일, 51만줄 이상의 전체 소스코드가 세상에 드러났습니다.

npm에서 해당 버전이 삭제되기까지 걸린 시간은 약 3시간. 하지만 그 사이에 GitHub에서 41,500회 이상 fork되며 “GitHub 역사상 가장 빠르게 성장한 레포”라는 타이틀까지 얻었습니다. 소스코드는 이미 인터넷에 영구히 남게 되었습니다.

이 글에서는 유출된 코드에서 발견된 7가지 핵심 항목을 분석합니다. 각각이 왜 논란이 되었는지, 기술적으로 어떻게 작동하는지를 하나씩 살펴보겠습니다.

어떻게 유출됐나: .npmignore 하나의 부재

유출의 직접적 원인은 놀라울 정도로 단순합니다. .npmignore에 소스맵 파일을 제외하는 설정이 빠져 있었습니다.

# .npmignore에 이 한 줄이 없었다
*.map

더 근본적인 원인은 Bun 번들러의 버그입니다. Bun은 프로덕션 모드에서도 소스맵을 기본 생성하는 이슈(oven-sh/bun#28001)가 있었습니다. Claude Code가 런타임으로 Bun을 채택하고 있는 만큼, 자사가 선택한 도구 체인의 버그가 자사의 소스코드를 유출시킨 셈입니다.

⚠️ 주의
이 사건은 Anthropic의 두 번째 소스맵 유출입니다. 2025년 2월에도 유사한 사건이 발생했습니다. 게다가 불과 며칠 전에는 내부 모델 사양 문서 "Mythos"가 유출되는 사건도 있었습니다.

Anthropic의 공식 입장은 다음과 같습니다:

“Earlier today, a Claude Code release included some internal source code. This was a release packaging issue caused by human error, not a security breach.”

고객 데이터, 인증 정보, 모델 가중치는 노출되지 않았다고 강조했지만, 코드 안에 담긴 설계 철학과 미공개 기능은 이미 공개된 뒤였습니다.

발견 1: Anti-Distillation — 가짜 도구로 경쟁사 학습 방해

유출된 코드에서 가장 먼저 눈에 띈 것은 claude.ts에 있는 ANTI_DISTILLATION_CC 플래그입니다.

// claude.ts (pseudo-code based on leaked source)
if (ANTI_DISTILLATION_CC) {
  requestBody.anti_distillation = ['fake_tools'];
}

이 플래그가 활성화되면 API 요청에 anti_distillation: ['fake_tools']가 추가됩니다. 서버는 이 신호를 받으면 시스템 프롬프트에 가짜(디코이) 도구 정의를 주입합니다.

왜 이런 걸 만들었을까요? 경쟁사가 API 트래픽을 캡처해서 자사 모델을 훈련시키는 시나리오를 방어하기 위해서입니다. 가짜 도구가 섞인 데이터로 학습하면, 경쟁사의 모델은 존재하지 않는 도구를 호출하려는 오동작을 보이게 됩니다. 경쟁사의 학습 데이터를 오염시키는 일종의 안티 디스틸레이션(Anti-Distillation) 방어 기법인 셈이죠.

두 번째 방어 레이어도 있습니다. betas.ts에서는 서버 사이드 요약과 암호화 서명을 결합해 전체 추론 체인을 숨기는 로직이 발견됐습니다.

// betas.ts (pseudo-code)
betas.push('server-side-summarization');
// 암호화 서명으로 전체 reasoning chain을 감싸
// 외부에서 중간 추론 과정을 볼 수 없도록 처리

💡 참고
이 방어 메커니즘은 발견 약 1시간 만에 우회법이 공개됐습니다. MITM 프록시로 anti_distillation 필드를 제거하거나, 환경 변수 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS를 설정하면 됩니다. 방어 의도는 좋았지만, 클라이언트 사이드 로직이라는 근본적 한계가 있었습니다.

AI 모델 도난(model theft)이 업계의 심각한 위협이라는 점에서, Anthropic이 이런 방어 메커니즘을 구현한 것 자체는 충분히 이해할 만합니다. 다만 클라이언트 측에서 구현된 방어가 얼마나 실효성이 있는지는 별개의 문제입니다.

발견 2: Undercover Mode — AI임을 숨기는 위장 모드

유출 코드 중 가장 큰 논란을 일으킨 것은 undercover.ts입니다.

이 모듈은 Claude Code가 비내부(non-internal) 레포지토리에서 작업할 때, AI임을 드러내지 않도록 강제하는 기능을 구현합니다. 구체적으로는:

내부 코드명(“Capybara”, “Tengu” 등) 언급 금지
내부 Slack 채널 참조 금지
Claude Code 또는 AI라는 사실 자체를 밝히지 않도록 지시

// undercover.ts (pseudo-code)
const undercoverPrompt = `
  Never mention internal codenames like "Capybara" or "Tengu".
  Do not reference internal Slack channels.
  Do not identify yourself as Claude Code or an AI assistant.
  This applies to all non-internal repositories.
`;
// 강제 OFF 메커니즘 없음 — 단방향

핵심은 이겁니다: 강제 OFF 메커니즘이 없습니다. 한 번 활성화되면 끌 수 없는 단방향 기능입니다.

이게 왜 논란이 됐을까요? Anthropic 직원이 Claude Code를 사용해서 오픈소스 프로젝트에 기여할 때, 해당 코드가 AI가 작성한 것인지 사람이 작성한 것인지 구분할 수 없게 된다는 뜻입니다. 오픈소스 커뮤니티에서 AI 투명성이 뜨거운 이슈인 상황에서, “AI Safety”를 표방하는 기업이 AI 기여를 의도적으로 숨기는 기능을 탑재하고 있었다는 사실은 적지 않은 충격을 줬습니다.

물론 반론도 있습니다. 내부 코드명이나 Slack 채널 같은 정보가 외부 코드에 실수로 노출되는 것을 방지하는 보안 목적일 수 있죠. 하지만 “AI임을 밝히지 말라”는 지시까지 포함된 것은 단순한 보안 목적을 넘어섭니다.

발견 3: Native Client Attestation — API 접근에 DRM을 건 이유

유출 코드에서는 API 요청의 무결성을 검증하는 네이티브 수준의 인증 메커니즘도 발견됐습니다.

// API request header
headers['cch'] = '155e8';  // placeholder
// Bun의 네이티브 HTTP 스택(Zig)이
// JavaScript 런타임 아래에서 이 값을 실제 해시로 교체

작동 방식은 이렇습니다:

JavaScript 레벨에서 cch=155e8라는 플레이스홀더를 헤더에 설정
Bun의 네이티브 HTTP 스택(Zig로 작성)이 요청을 가로챔
JavaScript 런타임이 접근할 수 없는 레벨에서 해시 값을 계산해 플레이스홀더를 교체
서버가 해시를 검증해 공식 Claude Code 바이너리에서 온 요청인지 확인

사실상 **API 접근에 대한 DRM(디지털 저작권 관리)**입니다. JavaScript 레벨에서는 해시 계산 로직에 접근할 수 없으므로, 비공식 클라이언트가 유효한 요청을 생성하기 어렵습니다.

┌─────────────────────────────────────┐
│  JavaScript Runtime (Bun)           │
│  headers['cch'] = '155e8'           │
│         │ placeholder               │
├─────────▼───────────────────────────┤
│  Native HTTP Stack (Zig)            │
│  cch = computeHash(request)         │
│         │ 실제 해시 계산              │
├─────────▼───────────────────────────┤
│  Anthropic API Server               │
│  verify(cch) → 공식 바이너리 확인     │
└─────────────────────────────────────┘

다만, 코드 주석에 “forgiving”이라는 단어가 발견됐습니다. 서버 측 검증이 엄격하지 않다는 뜻으로, 현재는 완전한 차단보다는 모니터링 목적에 가까운 것으로 보입니다.

발견 4: Frustration Detection — LLM 회사가 정규식으로 욕설을 감지하는 이유

유출 코드에서 발견된 욕설 감지 로직은 많은 사람들을 웃기게도, 놀라게도 만들었습니다.

// frustration detection (pseudo-code)
const frustrationRegex = /\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|...)\b/i;

function detectFrustration(userMessage: string): boolean {
  return frustrationRegex.test(userMessage);
}

LLM을 만드는 회사가 사용자 감정을 분석하는 데 추론 기반 감성 분석이 아닌 정규식을 쓰고 있습니다. 아이러니하지만, 사실 합리적인 선택입니다.

방식	정확도	지연시간	비용
LLM 추론 감성 분석	높음	수백ms	API 호출 비용
정규식 패턴 매칭	낮음 (뉘앙스 놓침)	<1ms	사실상 0

모든 메시지마다 감성 분석을 위해 추가 API 호출을 하는 것은 비용과 지연 측면에서 현실적이지 않습니다. “사용자가 명시적으로 욕을 하는 상황”만 빠르게 감지하려면 정규식이면 충분합니다. 완벽할 필요 없이, 빠르기만 하면 되니까요.

Hacker News에서는 “Cursor에 욕하면 실제로 버그 수정 성능이 올라간다”는 농담 섞인 댓글이 인기를 끌기도 했습니다. frustration이 감지되면 모델이 더 신중하게 응답하도록 행동을 조정하는 용도로 추정되는데, 실제로 그런 효과가 있다면 꽤 영리한 설계입니다.

발견 5: KAIROS — 미공개 자율 에이전트 모드

유출된 44개의 피처 플래그 중 가장 주목받은 것은 KAIROS입니다. 그리스어로 “적절한 시간(the right moment)“을 뜻하는 이 기능은 Claude Code를 항시 실행되는 백그라운드 데몬으로 전환하는 자율 에이전트 모드입니다.

발견된 주요 구성 요소는 다음과 같습니다:

// KAIROS feature flag
if (feature('KAIROS')) {
  // 백그라운드 데몬 모드 활성화
  initDaemonWorkers();
  scheduleCronRefresh({ interval: '5m' });
  registerGitHubWebhooks();
  enableAppendOnlyDailyLog();
}

기능	설명
백그라운드 데몬	사용자 명령 없이 상시 실행되는 워커 프로세스
5분 크론 스케줄	주기적으로 프로젝트 상태를 확인하고 갱신
GitHub 웹훅 통합	PR, 이슈 등 이벤트에 자동 반응
Append-only 일일 로그	매일의 관찰 기록을 추가 전용으로 누적

가장 흥미로운 것은 /dream 스킬입니다. “야간 메모리 정제(nightly memory distillation)“라는 이름 그대로, 하루 동안 쌓인 관찰을 통합하고 모순을 제거하며 핵심 인사이트를 정제하는 기능입니다.

// /dream skill (pseudo-code)
async function dreamDistillation() {
  const dailyObservations = await readAppendOnlyLog(today);
  const consolidated = await distill(dailyObservations, {
    removeContradictions: true,
    mergeRelatedInsights: true,
    prioritizeActionable: true,
  });
  await writeToLongTermMemory(consolidated);
}

KAIROS가 실현되면, Claude Code는 “요청할 때만 응답하는 도구”에서 **“프로젝트를 상시 관찰하며 능동적으로 행동하는 동료”**로 전환됩니다. 현재는 피처 플래그 뒤에 숨겨진 미공개 기능이지만, AI 코딩 에이전트의 미래 방향을 보여주는 가장 명확한 신호라고 할 수 있습니다.

발견 6: BUDDY — 터미널 속 타마고치

코드에서 발견된 BUDDY 피처 플래그는 성격이 전혀 다릅니다. 터미널 펫 시스템입니다.

속성	내용
종 수	18종
레어리티	Common → Uncommon → Rare → Epic → Legendary
Shiny 확률	1%
RPG 스탯	DEBUGGING, SNARK, CHAOS
크리처 배정	사용자 ID 기반 결정론적

사용자 ID를 시드로 써서 결정론적으로 크리처가 배정되므로, 같은 사용자는 항상 같은 펫을 받게 됩니다. 프리뷰 기간은 4월 1~7일로 설정되어 있었는데, 에이프릴 풀 장난으로 시작했다가 반쯤 진지한 기능이 된 것으로 보입니다.

✅ 팁
재미있는 기능처럼 보이지만, 이런 요소는 도구에 대한 애착과 사용 지속률에 실질적 영향을 미칩니다. GitHub의 contribution graph, Duolingo의 연속 학습 기록 같은 게이미피케이션 요소와 같은 맥락입니다.

발견 7: 25만 API 호출의 조용한 낭비

코드 주석에서 발견된 성능 이슈는 Anthropic의 규모에서 생각하면 상당히 의미 있는 숫자입니다.

// 코드 주석에서 발견 (원문)
// NOTE: 1,279 sessions experienced 50+ consecutive
// auto-compaction failures, wasting approximately
// 250,000 API calls daily globally

Claude Code는 대화가 길어지면 이전 메시지를 자동으로 압축(compaction)하는 기능이 있습니다. 그런데 1,279개 세션에서 50회 이상 연속으로 압축이 실패하고 있었고, 이로 인해 전 세계적으로 매일 약 25만 건의 API 호출이 낭비되고 있었습니다.

개발자가 이 사실을 코드 주석으로 기록해둔 것을 보면, 팀 내부에서 인지는 하고 있었지만 아직 수정되지 않은 상태였던 것으로 보입니다. AI 제품에서 이런 “조용한 비효율”이 얼마나 쉽게 쌓일 수 있는지를 보여주는 사례입니다.

마치며

.npmignore 한 줄의 부재가 51만줄의 소스코드를 세상에 드러냈습니다. 그 안에는 경쟁사로부터의 방어(Anti-Distillation), 논란이 될 수밖에 없는 결정(Undercover Mode), 영리한 엔지니어링(Frustration Detection), 미래의 제품 비전(KAIROS), 그리고 어디서나 존재하는 현실적 문제(25만 API 낭비)까지 — AI 에이전트를 만드는 팀이 실제로 어떤 고민을 하고 있는지가 고스란히 담겨 있었습니다.

다음 글에서는 유출된 코드에서 드러난 AI 에이전트 아키텍처를 분석합니다 — 40+개 도구 시스템, 다계층 권한 모델, 프롬프트 캐시 최적화, Coordinator Mode 등 Claude Code가 어떻게 설계되었는지를 기술적으로 파헤쳐 보겠습니다.

참고자료

Airflow DB 정리하는 법: db clean부터 VACUUM까지

Donhyeok Kang — Wed, 01 Apr 2026 00:00:00 GMT

Airflow를 운영하다 보면 어느 순간 UI가 느려지고, Scheduler 응답이 밀리기 시작합니다. DAG을 추가한 것도 아니고, 설정을 바꾼 것도 없는데 점점 무거워지는 느낌. 원인은 의외로 단순한 곳에 있을 수 있습니다 — 메타데이터 DB에 데이터가 쌓이고 있는 겁니다.

3편에서 Scheduler 메모리 부족 문제를 다뤘는데, DB 비대화도 비슷한 맥락입니다. 리소스 문제는 코드가 아니라 운영 환경에서 터지기 때문에 더 놓치기 쉽습니다.

이 글에서는 airflow db clean 명령어로 DB를 정리하는 방법을 처음부터 끝까지 다룹니다. 실제로 XCom 24만 건을 정리한 경험을 기반으로, 명령어 해부부터 실행 로그 해석, 숨어있는 함정, 용량 모니터링, 자동화 설정까지 운영에 필요한 내용을 빠짐없이 정리했습니다.

Airflow가 점점 느려지는 이유?

Airflow는 모든 실행 이력을 메타데이터 DB에 저장합니다. DAG 실행 기록, Task 상태, 로그, 그리고 Task 간 데이터 전달에 쓰이는 XCom(Cross Communication) — 이 모든 게 테이블에 쌓입니다.

DAG이 몇 개 없을 때는 문제가 안 됩니다. 하지만 DAG 수가 늘어나고, Dynamic Task Mapping처럼 한 번에 수십 개 Task를 생성하는 패턴을 쓰면 상황이 달라집니다. 1편에서 다뤘던 DAG 직렬화도 결국 메타데이터 DB에 의존하는 구조이기 때문에, DB가 비대해지면 전반적인 성능에 영향을 줍니다. XCom 하나당 한 행이니까, 매일 수천 건씩 쌓이는 건 순식간입니다.

실제로 운영 중인 환경에서 30일 이전 데이터만 조회해봤는데, 이미 이 정도가 쌓여 있었습니다:

테이블	30일 이전 건수
`xcom`	243,066건
`task_instance`	118,734건
`dag_run`	24,860건
`log`	280건

XCom이 압도적입니다. 배치 DAG 하나가 매 실행마다 수십 개의 XCom을 생성하고, 하루에 여러 번 돌아가니 한 달이면 수만 건이 쌓입니다.

⚠️ XCom은 특히 주의
XCom은 Task 간 데이터를 전달하는 용도인데, 기본적으로 메타데이터 DB에 직접 저장됩니다. 큰 데이터를 XCom으로 주고받으면 한 행이 수 MB가 될 수도 있습니다. 건수뿐 아니라 용량도 급격히 늘어나는 주범입니다.

airflow db clean 명령어 해부

Airflow 2.3부터 도입된 airflow db clean 명령어는 오래된 메타데이터를 정리하는 공식 도구입니다. Docker 환경에서의 실행 형태를 하나씩 뜯어보겠습니다.

$ docker exec -it airflow-scheduler \
    airflow db clean \
    --clean-before-timestamp $(date -d '-30 days' '+%Y-%m-%d') \
    -y

각 부분의 역할

docker exec -it airflow-scheduler — 실행 중인 Scheduler 컨테이너 안에서 명령을 실행합니다. 컨테이너 이름은 환경마다 다르니 docker ps로 확인하세요.

airflow db clean — 메타데이터 DB 정리 명령. 아래 테이블들이 정리 대상입니다:

대상 테이블	설명
`xcom`	Task 간 데이터 전달 기록
`task_instance`	Task 실행 이력
`dag_run`	DAG 실행 이력
`log`	이벤트 로그
`job`	Scheduler/Worker Job 기록
`session`	웹 세션
`task_reschedule`	Sensor 등의 재스케줄 기록
`trigger`	Deferrable Operator 트리거
`dag_version`	DAG 직렬화 버전
`import_error`	DAG 파싱 에러

--clean-before-timestamp — 이 날짜보다 오래된 데이터를 삭제합니다. $(date -d '-30 days' '+%Y-%m-%d')는 현재 기준 30일 전 날짜를 계산합니다. 2026-04-01에 실행하면 2026-03-02 이전 데이터가 대상이 됩니다.

-y — 확인 프롬프트 없이 바로 실행합니다.

유용한 추가 옵션

# 실제 삭제 없이 몇 건이 삭제되는지 미리 확인
$ airflow db clean --clean-before-timestamp '2026-03-02' --dry-run

# 특정 테이블만 정리 (예: xcom과 task_instance만)
$ airflow db clean --clean-before-timestamp '2026-03-02' -t xcom,task_instance -y

# 대량 삭제 시 배치 크기 조절 (DB 부하 분산)
$ airflow db clean --clean-before-timestamp '2026-03-02' --batch-size 1000 -y

💡 운영 환경에서는 --dry-run 먼저
처음 실행할 때는 반드시 --dry-run으로 삭제 대상 건수를 확인하세요. 예상보다 훨씬 많은 데이터가 잡힐 수 있고, 대량 삭제는 DB에 부하를 줍니다. --batch-size를 낮게 잡으면 트랜잭션당 삭제 건수가 줄어 DB 락 시간이 짧아집니다.

실행 결과 분석: 로그 읽는 법

실제 실행 로그를 보면서 어떤 부분이 중요하고, 어떤 경고는 무시해도 되는지 정리하겠습니다.

정상 처리 확인

가장 먼저 봐야 할 건 각 테이블의 삭제 결과입니다:

Checking table xcom
Found 243066 rows meeting deletion criteria.
Performing Delete...
Moving data to table _airflow_deleted__xcom__20260401024053
Finished Performing Delete

Found N rows → Performing Delete → Finished Performing Delete 흐름이 나오면 정상입니다. 실제 실행에서 정리된 건수를 정리하면:

테이블	삭제 건수	비고
`xcom`	243,066건	가장 많은 비중
`task_instance`	118,734건
`dag_run`	24,860건
`task_instance_history`	83건
`dag_version`	69건
`session`	61건
`job`	58건
`log`	280건
`dag`	5건	더 이상 사용하지 않는 DAG

무시해도 되는 경고들

실행 로그에 여러 Warning이 찍히는데, 대부분 무시해도 됩니다.

DeprecationWarning — 설정 위치 변경 안내

DeprecationWarning: The grid_view_sorting_order option in [webserver]
has been moved to the grid_view_sorting_order option in [api]

Airflow 3.x에서 일부 설정이 [webserver] 섹션에서 [api] 섹션으로 이동했다는 안내입니다. 지금 당장은 기존 설정대로 동작하지만, 향후 버전에서 깨질 수 있으니 airflow.cfg를 업데이트하는 게 좋습니다.

SAWarning — DB 인덱스 리플렉션

SAWarning: Skipped unsupported reflection of expression-based index

SQLAlchemy가 일부 표현식 기반 인덱스를 읽지 못한다는 경고인데, 실행에는 전혀 영향 없습니다.

Table not found — 미사용 테이블

WARNING - Table celery_taskmeta not found. Skipping.
WARNING - Table _xcom_archive not found. Skipping.
WARNING - Table sla_miss not found. Skipping.

Celery executor를 사용하지 않거나, 해당 기능을 쓰지 않으면 테이블 자체가 없습니다. 정상적인 skip입니다.

✅ 성공 판단 기준
ERROR가 없고, 각 테이블에서 Finished Performing Delete가 출력되면 성공입니다. Warning은 대부분 무시해도 됩니다.

주의: “삭제”가 아니라 “이동”이다

여기가 가장 중요한 포인트입니다. 실행 로그를 다시 보면:

Moving data to table _airflow_deleted__xcom__20260401024053

airflow db clean은 데이터를 바로 삭제하지 않습니다. _airflow_deleted__<테이블명>__<타임스탬프> 형태의 아카이브 테이블로 이동합니다. 이건 실수로 지웠을 때 복구할 수 있게 하려는 안전장치입니다.

정리 전:  xcom 테이블 (243,066건)
정리 후:  xcom 테이블 (정리됨)
          _airflow_deleted__xcom__20260401024053 (243,066건) ← 여기로 이동

핵심은 이겁니다 — DB 용량은 줄지 않습니다. 데이터가 다른 테이블로 옮겨졌을 뿐이니까요. 논리적으로는 정리됐지만, 디스크 공간은 그대로입니다.

아카이브 테이블 정리하기

아카이브 테이블은 자동으로 삭제되지 않습니다. 직접 정리해야 합니다. Airflow는 이를 위한 전용 명령어를 제공합니다:

# 아카이브 테이블 목록 확인 후 삭제
$ airflow db drop-archived -y

# 특정 테이블의 아카이브만 삭제
$ airflow db drop-archived -t xcom -y

# 삭제 전에 CSV로 백업하고 싶다면
$ airflow db export-archived --output-path /tmp/airflow-backup/

–skip-archive: 아카이브 없이 바로 삭제

아카이브 자체를 만들지 않고 싶다면 --skip-archive 옵션을 사용합니다:

$ airflow db clean \
    --clean-before-timestamp $(date -d '-30 days' '+%Y-%m-%d') \
    --skip-archive -y

이 옵션을 쓰면 _airflow_deleted__ 테이블이 생기지 않고, 데이터가 즉시 영구 삭제됩니다. 복구가 불가능하므로 주의가 필요합니다.

⚠️ --skip-archive 버전 주의
Airflow 2.10 이전 버전에서는 --skip-archive가 내부적으로 아카이브 테이블을 생성했다가 다시 삭제하는 방식으로 동작해서, 대량 삭제 시 statement timeout 문제가 발생할 수 있었습니다 (#42003). 최신 버전에서는 수정되었지만, 오래된 Airflow를 쓰고 있다면 테스트 후 사용하세요.

실무 권장 패턴

상황	권장 방식
운영 초기, 안정성 중시	기본 모드 (아카이브 생성) → 1~2주 후 `db drop-archived`
안정화된 환경	`--skip-archive`로 즉시 삭제
DB 용량 긴급	`--skip-archive` + `VACUUM FULL`

DB 용량 모니터링

정리 효과를 확인하려면 실제 용량을 봐야 합니다. PostgreSQL 기준으로 유용한 쿼리를 정리합니다.

테이블별 사이즈 확인

SELECT
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS total_size,
    pg_size_pretty(pg_relation_size(schemaname || '.' || tablename)) AS table_size,
    pg_size_pretty(pg_indexes_size(schemaname || '.' || tablename)) AS index_size
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC
LIMIT 20;

아카이브 테이블 용량 확인

_airflow_deleted__ 테이블이 얼마나 용량을 차지하는지 따로 확인할 수 있습니다:

SELECT
    tablename,
    pg_size_pretty(pg_total_relation_size('public.' || tablename)) AS size
FROM pg_tables
WHERE schemaname = 'public'
  AND tablename LIKE '_airflow_deleted__%'
ORDER BY pg_total_relation_size('public.' || tablename) DESC;

Dead Tuple 확인

PostgreSQL에서 DELETE는 실제로 디스크 공간을 해제하지 않습니다. 삭제된 행은 “dead tuple”로 남아 있다가 VACUUM이 처리합니다.

SELECT
    relname AS table_name,
    n_dead_tup AS dead_tuples,
    n_live_tup AS live_tuples,
    round(100.0 * n_dead_tup / nullif(n_live_tup + n_dead_tup, 0), 1) AS dead_ratio_pct,
    last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

dead tuple 비율이 높으면 VACUUM이 필요하다는 신호입니다.

PostgreSQL VACUUM: 진짜 용량 확보

db clean + db drop-archived(또는 --skip-archive)까지 했어도, PostgreSQL에서는 디스크 용량이 바로 줄지 않을 수 있습니다. DELETE는 행을 “삭제됨”으로 표시할 뿐, 물리적 공간은 그대로 유지하기 때문입니다.

VACUUM vs VACUUM FULL

-- 일반 VACUUM: dead tuple 공간을 재사용 가능하게 표시
-- 테이블 잠금 없음, 운영 중 실행 가능
VACUUM ANALYZE xcom;
VACUUM ANALYZE task_instance;
VACUUM ANALYZE dag_run;

-- VACUUM FULL: 테이블을 물리적으로 재작성하여 디스크 공간 실제 회수
-- ⚠️ 테이블 잠금 발생 — 점검 시간에 실행 권장
VACUUM FULL xcom;
VACUUM FULL task_instance;
VACUUM FULL dag_run;

구분	`VACUUM ANALYZE`	`VACUUM FULL`
디스크 공간 회수	❌ (재사용 가능 표시만)	✅ 실제 회수
테이블 잠금	없음	배타적 잠금
운영 중 실행	✅ 가능	❌ 다운타임 필요
소요 시간	짧음	테이블 크기에 비례
권장 시점	db clean 직후	대량 삭제 후 용량 확보 필요 시

💡 실무 순서
airflow db clean → airflow db drop-archived → VACUUM ANALYZE (즉시) → 용량 확보 필요 시 VACUUM FULL (점검 시간). PostgreSQL의 autovacuum이 자동으로 처리해주긴 하지만, 수십만 건 삭제 후에는 수동으로 돌리는 게 즉각적인 효과를 볼 수 있습니다.

운영 자동화

DB 정리는 한 번 하고 끝나는 게 아닙니다. 주기적으로 실행해야 쌓이는 걸 방지할 수 있습니다.

보존 기간 가이드

상황	권장 보존 기간	이유
일반 운영	30~60일	최근 장애 디버깅에 충분한 기간
안정적인 환경	14~30일	XCom이 많으면 더 짧게
감사/규정 요구	90일 이상	규정에 따라 조정

너무 짧으면(1~3일) 장애 발생 시 과거 실행 기록을 확인할 수 없고, 너무 길면 DB가 다시 비대해집니다. 경험상 30일이 대부분의 환경에서 적절합니다.

Cron으로 자동화

가장 간단한 방법은 호스트 cron에 등록하는 겁니다:

# 매주 일요일 새벽 3시에 실행 (30일 이전 데이터 정리)
0 3 * * 0 docker exec airflow-scheduler \
  airflow db clean --clean-before-timestamp "$(date -d '-30 days' '+\%Y-\%m-\%d')" --skip-archive -y \
  >> /var/log/airflow-db-clean.log 2>&1

# 같은 시간에 VACUUM도 실행
30 3 * * 0 docker exec airflow-postgres \
  psql -U airflow -d airflow -c "VACUUM ANALYZE xcom; VACUUM ANALYZE task_instance; VACUUM ANALYZE dag_run;" \
  >> /var/log/airflow-vacuum.log 2>&1

⚠️ Airflow 3.x에서 DAG 기반 자동화의 한계
Airflow 2.x에서는 BashOperator로 airflow db clean을 실행하는 DAG을 만드는 패턴이 널리 쓰였는데, Airflow 3.x에서는 이 방식이 정상 동작하지 않는 경우가 보고되고 있습니다 (Discussion #56281). 안정적인 자동화가 필요하다면 cron이나 Kubernetes CronJob을 권장합니다.

한눈에 보는 체크리스트

운영 중인 Airflow가 있다면, 이 항목들을 정기적으로 점검하세요:

📌 Airflow DB 관리 체크리스트

airflow db clean을 주기적으로 실행하고 있는가?
_airflow_deleted__ 아카이브 테이블이 방치되어 있지 않은가?
대량 삭제 후 VACUUM ANALYZE를 돌렸는가?
XCom에 불필요하게 큰 데이터를 저장하고 있지 않은가?
DB 테이블 사이즈를 주기적으로 모니터링하고 있는가?

마치며

DB 정리는 화려한 작업은 아니지만, 안 하면 확실히 느려집니다. 특히 XCom을 많이 쓰는 환경에서는 수십만 건이 순식간에 쌓이기 때문에, 주기적인 정리가 필수입니다.

airflow db clean이 데이터를 “삭제”가 아니라 “이동”한다는 점, 그래서 db drop-archived나 --skip-archive로 한 단계 더 처리해야 진짜 정리가 된다는 점 — 이 두 가지만 기억해도 운영에서 큰 차이가 납니다.

참고자료

Airflow "No host supplied" 해결 과정: hostname_callable부터 메모리까지

Donhyeok Kang — Thu, 26 Mar 2026 00:00:00 GMT

1편에서 DAG Hash 문제를 디버깅할 때, 실패한 Task의 상태가 hostname=NULL, pid=NULL이었던 걸 기억하시나요? DAG Hash 문제를 해결한 뒤에도 대량 Task를 돌리면 비슷한 증상이 간헐적으로 나타났습니다. 이번에는 에러 메시지가 달랐습니다.

Could not read served logs: Invalid URL
'http://:8793/log/dag_id=tts_batch_dag/run_id=.../task_id=.../map_index=51/attempt=1.log':
No host supplied

로그 URL에서 hostname 자리가 비어 있습니다. http://:8793/... — Worker가 어디서 로그를 서빙하는지 모르는 상태입니다. 자연스럽게 hostname 설정을 의심했고, 거기서부터 꽤 긴 삽질이 시작됐습니다.

에러 상황: hostname=NULL인 Task들

실패한 Task들의 공통점은 task_instance 테이블에 hostname이 저장되지 않았다는 점입니다.

map_index 0-33:   success ✓  (hostname=elastic, pid=12345)
map_index 34+:    failed  ✗  (hostname=NULL, pid=NULL)

성공한 Task에는 hostname과 pid가 정상적으로 찍혀 있는데, 실패한 Task는 둘 다 NULL입니다. Worker에 도달조차 못 한 겁니다. 그리고 매번 다른 번호에서 끊겼습니다 — 어떤 때는 34번째, 어떤 때는 28번째.

삽질 1: hostname_callable 변경 → 효과 없음

hostname이 비어있으니 가장 먼저 의심한 건 hostname_callable 설정이었습니다. Airflow는 기본적으로 getfqdn()을 사용해 Worker의 hostname을 가져옵니다.

# airflow.cfg 기본 설정
[core]
hostname_callable = airflow.utils.net.getfqdn

getfqdn()은 DNS 역방향 조회(reverse DNS lookup)를 수행하는데, Docker network_mode: host 환경에서는 이게 빈 문자열을 반환할 수 있다는 걸 알고 있었습니다. GitHub 이슈에서도 동일한 문제가 보고되어 있었고요.

그래서 DNS를 우회하는 IP 기반 함수로 바꿔봤습니다.

# getfqdn → IP 기반으로 변경
hostname_callable = airflow.utils.net.get_host_ip_address

결과: 효과 없음. 여전히 대량 Task에서 같은 패턴으로 실패했습니다. hostname_callable을 되돌렸습니다.

삽질 2: JWT_SECRET 설정 → 효과 없음

hostname_callable을 바꿨을 때 로그 조회에서 별도 에러가 나길래, Airflow 3.x의 내부 API 인증(JWT)과 hostname이 연관되어 있다는 글을 보고 JWT_SECRET도 추가해봤습니다.

# docker-compose.yaml
AIRFLOW__API_AUTH__JWT_SECRET: "fixed-secret-key"

결과: 역시 효과 없음. JWT_SECRET을 넣든 빼든 “No host supplied” 에러는 동일하게 발생했습니다. 이것도 되돌렸습니다.

이 시점에서 “hostname 문제가 아닐 수도 있다”는 생각이 들기 시작했습니다.

삽질 3: DB Connection Pool 증가 → 효과 없음

다음 의심은 DB connection pool이었습니다. parallelism=32인데 기본 pool size는 15개(5+10)밖에 안 되니, Task가 동시에 몰리면 hostname 저장 자체가 밀릴 수 있겠다고 판단했습니다.

# sql_alchemy_pool_size를 올려봄
sql_alchemy_pool_size = 20
sql_alchemy_max_overflow = 20

결과: 효과 없음. pool을 넉넉하게 잡아도 같은 위치에서 실패했습니다. 되돌렸습니다.

진짜 원인: Scheduler 메모리 부족

세 번의 삽질을 거치고 나서야 docker stats를 실시간으로 띄워놓고 DAG를 돌려봤습니다.

$ docker stats
CONTAINER                CPU %     MEM USAGE / LIMIT     MEM %
airflow-scheduler-1      92.1%     3.8GiB / 4GiB         95.0%
# ... 잠시 후
airflow-scheduler-1      0.00%     0B / 0B               --      ← 죽음
# ... 몇 초 후 자동 재시작
airflow-scheduler-1      45.2%     1.2GiB / 4GiB         30.0%

Scheduler가 메모리 100%를 찍고 OOM으로 죽었다가 다시 뜨는 걸 반복하고 있었습니다. 대량 Task를 돌릴 때마다 메모리가 급격히 올라가면서 4GB 제한에 걸려 컨테이너가 kill되고, Docker가 자동 재시작하는 사이클이 반복되는 거였습니다.

왜 Scheduler OOM이 hostname=NULL을 만드는가?

LocalExecutor에서 Scheduler는 Task마다 새 프로세스를 fork합니다. fork된 프로세스가 task_instance 테이블에 hostname과 pid를 기록하는데, Scheduler가 OOM으로 죽으면 실행 중이던 Task도 함께 날아가고, 아직 스케줄링되지 않은 Task는 기록 자체가 안 됩니다.

DAG Run 시작 → Task 0~33 fork 성공 → 실행 중
  └── 메모리 급증 → Scheduler OOM kill
      ├── 실행 완료된 Task 0~33: hostname 정상 ✓
      └── 아직 실행 안 된 Task 34+: hostname=NULL, pid=NULL ✗
          └── Scheduler 재시작 후에도 이미 failed 처리됨

매번 다른 번호에서 끊기는 것도 이걸로 설명됩니다. Scheduler가 OOM에 도달하는 타이밍이 Task 실행 상황에 따라 매번 달라지기 때문입니다.

⚠️ 에러 메시지의 함정
"No host supplied"라는 메시지만 보면 hostname 설정 문제처럼 보입니다. 실제로 hostname_callable을 바꾸라는 조언이 인터넷에 많고요. 하지만 이 에러는 "hostname이 왜 비어있는가"를 더 파고들어야 합니다. hostname 함수가 잘못된 게 아니라, hostname을 저장하는 프로세스 자체가 생성되지 못한 거였습니다.

해결: Scheduler 메모리 제한 올리기

# docker-compose.yaml
services:
  airflow-scheduler:
    deploy:
      resources:
        limits:
          memory: 12G    # 4G → 8G → 최종 12G

처음에 4G → 8G로 올렸을 때 상황이 많이 나아졌지만, TTS 배치처럼 수십 개 Task를 동시에 돌리는 DAG에서는 여전히 간헐적으로 터졌습니다. 12G로 올린 뒤에야 완전히 안정화됐습니다.

12G로 올린 뒤에는 대량 Task를 돌려도 Scheduler가 죽지 않았고, 모든 Task의 hostname이 정상적으로 채워졌습니다. “No host supplied” 에러는 완전히 사라졌습니다.

💡 메모리 산정 기준
LocalExecutor에서 각 Task 프로세스는 대략 100~200MB를 사용합니다. parallelism=32면 최대 6.4GB가 필요하고, Scheduler 자체 프로세스까지 합하면 8~12GB가 안전한 범위입니다. 2편에서 다뤘던 max_active_tis_per_dag로 동시 실행 수를 줄이는 것도 메모리 압박을 낮추는 데 효과적입니다.

이 경험에서 배운 것

에러 메시지와 원인이 다른 레이어에 있을 수 있다

“No host supplied”라는 에러 메시지 자체는 정확합니다 — 실제로 hostname이 비어있으니까요. 문제는 그 메시지가 가리키는 방향(hostname 설정)과 실제 원인(메모리)이 전혀 다른 레이어에 있었다는 겁니다. docker stats로 메모리 사용량은 계속 보고 있었지만, 그게 hostname=NULL과 연결된다는 걸 떠올리지 못했습니다.

hostname=NULL + pid=NULL의 의미

돌이켜보면 단서는 처음부터 있었습니다. hostname만 NULL이면 설정 문제일 수 있지만, pid까지 NULL이라는 건 프로세스가 아예 안 떴다는 뜻입니다. 설정이 아니라 리소스 쪽 신호였는데, 에러 메시지에 이끌려 hostname 설정만 팠던 거죠.

비슷한 상황을 만나면

# 1. 먼저 리소스 확인 — 이걸 첫 번째로!
$ docker stats --no-stream

# 2. Scheduler 로그에서 fork 실패 흔적 확인
$ docker compose logs airflow-scheduler --tail=500 | grep -E "fork|OSError|MemoryError|killed"

# 3. 그래도 안 보이면 그때 hostname 설정 확인
$ docker compose exec airflow-worker python -c \
    "from airflow.utils.net import getfqdn; print(repr(getfqdn()))"

📌 핵심 요약

"No host supplied" 에러는 hostname 설정 문제처럼 보이지만, 실제 원인은 Scheduler 메모리 부족일 수 있다
LocalExecutor에서 Scheduler가 OOM으로 죽으면 미실행 Task의 hostname/pid가 NULL로 남는다
hostname_callable 변경, JWT_SECRET, DB pool 증가는 이 경우 효과가 없다
해결: Scheduler의 mem_limit을 충분히 올리거나, parallelism을 줄여 동시 fork 수를 제한한다
디버깅 시 docker stats를 가장 먼저 확인하는 습관이 중요하다

마치며

hostname_callable → JWT_SECRET → DB pool → 메모리. 돌아돌아 결국 가장 기본적인 리소스 문제였습니다. docker stats는 계속 보고 있었는데, “Scheduler 메모리가 차는 것”과 “hostname이 NULL인 것”을 연결 짓지 못한 게 삽질의 원인이었습니다.

pid=NULL이라는 단서를 좀 더 일찍 주목했으면 방향을 빨리 잡았을 텐데, “No host supplied”에 꽂혀서 hostname 설정만 계속 건드린 셈입니다.

참고자료

Airflow Dynamic Task Mapping: 병렬 처리와 동시 실행 제한 전략

Donhyeok Kang — Wed, 25 Mar 2026 00:00:00 GMT

Airflow에서 배치 처리를 하다 보면, 런타임에 Task 수가 결정되는 상황을 자주 만납니다. 책 한 권의 페이지별 OCR 처리, 수백 개 파일의 TTS 변환, 데이터 파티션별 ETL — 실행 전까지 몇 개의 Task가 필요한지 알 수 없는 경우입니다.

Dynamic Task Mapping은 이런 상황에서 expand()로 런타임에 Task를 동적으로 생성하는 기능입니다. 편리하지만, 아무 제한 없이 쓰면 Worker가 한꺼번에 수백 개의 Task를 처리하려다 외부 API rate limit에 걸리거나, 메모리가 터지는 일이 생깁니다.

이 글에서는 Dynamic Task Mapping의 동시 실행을 제한하는 세 가지 전략을 비교하고, 실제로 어떤 상황에서 어떤 방식을 쓰는 게 좋은지 정리합니다.

Dynamic Task Mapping 기본 개념

기존 방식에서는 Task 수를 코드에 하드코딩해야 했습니다.

# ❌ 정적 Task 생성 — 페이지 수를 미리 알아야 함
for i in range(20):
    extract_page_task = extract_kc_task.override(task_id=f"extract_page_{i}")

Dynamic Task Mapping은 expand()를 사용해 런타임에 입력 데이터의 크기만큼 Task를 자동 생성합니다.

# ✅ Dynamic Task Mapping — 런타임에 페이지 수만큼 Task 생성
pages = get_pages_dynamically()
extract_kc_per_page.expand(page_config=pages["page_configs"])

20개 페이지면 20개 Task, 100개 페이지면 100개 Task가 만들어집니다. 편리하지만, 여기서 바로 문제가 시작됩니다 — 동시에 100개 Task가 돌면 어떻게 될까요?

동시 실행을 제한하는 세 가지 방법

1. max_active_tis_per_dag — 가장 간단하고 실용적

@task 데코레이터에 파라미터 하나만 추가하면 됩니다.

@task(max_active_tis_per_dag=5)
def extract_kc_per_page(page_config):
    # 이 DAG의 모든 실행에서 합쳐서 최대 5개만 동시 실행
    return process_page(page_config)

같은 DAG가 여러 번 트리거되더라도, 해당 Task는 전체를 합쳐서 설정한 수만큼만 동시에 실행됩니다.

# 같은 DAG 3번 실행
$ airflow dags trigger kc_pipeline --conf '{"book_id": 1}'
$ airflow dags trigger kc_pipeline --conf '{"book_id": 2}'
$ airflow dags trigger kc_pipeline --conf '{"book_id": 3}'

# 결과: 3개 실행을 통틀어서 최대 5개 Task만 동시 실행

경험상, 대부분의 경우 이것만으로 충분합니다. 설정이 간단하고, Pool을 별도로 만들 필요도 없습니다.

2. Pool — 여러 DAG 간 리소스 공유

max_active_tis_per_dag는 DAG 하나 안에서만 동작합니다. 여러 DAG가 같은 리소스(GPU, DB 커넥션, 외부 API 등)를 공유할 때는 Pool이 필요합니다.

# Pool 생성 (CLI 또는 UI에서)
$ airflow pools set kc_extraction_pool 5 "KC 추출 전용 Pool"

@task(pool="kc_extraction_pool", pool_slots=1)
def extract_kc_per_page(page_config):
    # 전체 시스템에서 Pool 크기(5)만큼만 동시 실행
    return process_page(page_config)

Pool의 가장 큰 장점은 런타임에 크기를 조정할 수 있다는 점입니다. Airflow UI에서 Pool 크기를 변경하면 즉시 반영되므로, 리소스 상황에 따라 유연하게 대응이 가능합니다.

pool_slots 파라미터를 활용하면 Task마다 다른 리소스 비중을 줄 수도 있습니다.

# GPU가 4개인 환경에서 Pool 크기 = 4

@task(pool="gpu_pool", pool_slots=2)  # GPU 2개 사용
def train_model(model_config):
    return train_with_gpu(model_config)

@task(pool="gpu_pool", pool_slots=1)  # GPU 1개 사용
def inference(data_batch):
    return predict(data_batch)

3. max_map_length — Task 생성 자체를 제한

위 두 방법이 “동시 실행 수”를 제한하는 것과 달리, max_map_length는 생성 가능한 Task 수 자체를 제한하는 설정입니다. Scheduler 과부하나 메모리 폭발을 막는 안전장치 역할이라고 보면 됩니다.

# airflow.cfg
[core]
max_map_length = 1024  # 기본값

# 또는 코드 레벨에서 직접 제한
@task
def get_pages():
    pages = get_all_pages()
    return pages[:50]  # 최대 50개만 반환

주의할 점은 max_map_length를 초과하면 Task 생성 자체가 실패한다는 겁니다. 동시 실행을 “늦추는” 게 아니라 아예 막아버리므로, 데이터 손실이 발생할 수 있습니다. 이 설정은 제한보다는 보호 장치로 사용하는 것이 적절합니다.

어떤 방법을 써야 할까?

방법	제어 대상	적용 범위	설정 난이도	추천 상황
`max_active_tis_per_dag`	동시 실행 수	DAG 내	매우 쉬움	대부분의 경우
`Pool`	동시 실행 수	전역	보통	여러 DAG 간 리소스 공유
`max_map_length`	Task 생성 수	전역	쉬움	시스템 안전장치
`parallelism`	전체 Task 수	시스템 전역	주의 필요	인프라 레벨 상한선

개인적으로는 max_active_tis_per_dag를 기본으로 쓰고, 필요할 때만 Pool을 추가하는 조합을 권장합니다. 실제로 저도 대부분의 DAG에서 이 패턴으로 충분했습니다.

@task(
    max_active_tis_per_dag=5,       # 기본: DAG 내 동시 실행 제한
    pool="heavy_compute_pool",      # 추가: 전역 리소스 제한 (필요한 경우만)
    pool_slots=2                    # 리소스 비중
)
def heavy_processing(data):
    return expensive_computation(data)

실전 패턴 모음

Chunk 기반 처리

입력 데이터가 수백~수천 건일 때, 개별 처리 대신 청크 단위로 묶으면 Task 수를 줄이면서 처리량을 유지할 수 있습니다.

@task
def create_chunks(items, chunk_size=5):
    return [items[i:i+chunk_size] for i in range(0, len(items), chunk_size)]

@task(max_active_tis_per_dag=3)
def process_chunk(chunk):
    return [process_item(item) for item in chunk]

chunks = create_chunks(large_dataset)
results = process_chunk.expand(chunk=chunks)

1,000건을 개별 처리하면 1,000개 Task가 생기지만, 5개씩 청크로 묶으면 200개로 줄어듭니다.

Map-Reduce 패턴

병렬로 처리한 결과를 하나로 합쳐야 할 때 자주 쓰는 패턴입니다.

@task(max_active_tis_per_dag=8)
def map_process(data_chunk):
    return expensive_transform(data_chunk)

@task
def reduce_results(mapped_results):
    return combine_all_results(mapped_results)

# 워크플로우
chunks = create_data_chunks()
mapped = map_process.expand(data_chunk=chunks)
final_result = reduce_results(mapped)

reduce_results는 모든 map_process Task가 완료된 후에 자동으로 실행됩니다. Airflow가 의존성을 알아서 관리해주기 때문에 별도의 동기화 로직이 필요 없습니다.

외부 API 호출 시 백프레셔 제어

외부 API를 호출하는 Task에서는 동시 실행 제한과 함께 재시도 전략도 같이 설정하는 것이 중요합니다.

@task(
    max_active_tis_per_dag=3,              # 동시 3개로 제한
    retries=3,                             # 실패 시 3번 재시도
    retry_delay=timedelta(minutes=2),      # 재시도 간격
    execution_timeout=timedelta(minutes=10) # 타임아웃
)
def api_heavy_task(data):
    return call_external_api(data)

이전 글에서 다뤘듯이, Variable.get()이나 외부 API 호출 같은 동적 리소스 접근은 반드시 Task 함수 본문 안에서 해야 합니다. DAG 최상위에서 호출하면 dag_hash 불안정 문제가 발생할 수 있습니다.

문제가 생겼을 때 확인할 것들

Dynamic Task Mapping 관련 문제가 생겼을 때 확인해볼 포인트를 정리합니다.

⚠️ Task가 scheduled 상태에서 안 넘어간다면
Pool 크기가 꽉 찼거나, max_active_runs에 걸려 있을 가능성이 높습니다. 아래 명령어로 확인해보세요.

확인 방법:

# Pool 크기와 사용량 확인
$ airflow pools list

# DAG의 max_active_runs 확인
$ airflow dags details <dag_id> | grep max_active_runs

메모리 부족이 발생한다면:

max_map_length를 줄이거나
청크 기반 처리로 전환하여 Task 수 자체를 줄이는 것을 고려해야 합니다
Webserver 자체의 메모리 누수가 의심되면 Gunicorn worker 설정도 함께 점검해보세요

API Rate Limit에 걸린다면:

max_active_tis_per_dag를 줄이고
retry_delay를 늘려서 재시도 간격을 확보합니다

마치며

처음에는 아무 제한 없이 expand()를 썼다가 외부 API rate limit에 걸려서 수백 개 Task가 동시에 실패한 적이 있습니다. 그 뒤로 max_active_tis_per_dag를 습관적으로 넣게 됐고, 이것 하나만으로도 대부분의 상황을 커버할 수 있었습니다. 새로운 DAG를 만들 때 expand()를 쓴다면, 동시 실행 제한도 함께 설정하는 것을 권장합니다.

다음 글에서는 Docker 환경에서 Airflow Worker 로그에 hostname이 비어 있는 문제를 다뤄보겠습니다.

참고자료

Airflow DAG Hash가 계속 바뀌는 문제: Variable.get()의 함정

Donhyeok Kang — Tue, 24 Mar 2026 00:00:00 GMT

TTS 배치 DAG의 Task들이 간헐적으로 실패하기 시작했습니다. 30개짜리 Dynamic Task Mapping 중 앞쪽 13개는 성공하고, 뒤쪽 17개가 한꺼번에 실패하는 패턴이었습니다.

DAG 'tts_batch_dag' not found in serialized_dag table

특이한 건 빠르게 끝나는 DAG에서는 재현이 안 되고, 처리량이 많아서 시간이 좀 걸리는 DAG에서만 터진다는 점이었습니다. 처음엔 Worker 리소스 문제인 줄 알았는데, 원인은 전혀 다른 곳에 있었습니다.

에러 상황: Task 실행 중 “DAG not found”

에러 로그를 좀 더 자세히 뜯어보면, Scheduler가 Task를 Worker에 넘기려는 순간 DAG를 찾지 못하고 있었습니다.

scheduler  | ERROR - DAG 'tts_batch_dag' for task instance
  <TaskInstance: ...generate_tts map_index=14 [failed]>
  not found in serialized_dag table

이상한 건 실패한 Task들의 상태였습니다. 성공한 Task에는 hostname=elastic이 찍혀 있는데, 실패한 Task는 전부 hostname=NULL, pid=NULL이었습니다. Worker에 도달조차 못 한 겁니다.

map_index 0-13:  success ✓  (hostname=elastic)
map_index 14+:   failed  ✗  (hostname=NULL, pid=NULL)

DAG 코드에 문법 에러가 있는 것도 아니고, Worker 리소스가 부족한 것도 아니었습니다. 혹시 DAG 자체에 뭔가 이상이 있나 싶어 serialized_dag 테이블을 직접 조회해봤습니다.

SELECT last_updated, dag_hash
FROM serialized_dag
WHERE dag_id = 'tts_batch_dag'
ORDER BY last_updated DESC LIMIT 10;

      last_updated          |             dag_hash
-------------------------------+----------------------------------
 2025-12-09 00:48:24.773546+00 | 5005eb097fc4a58972cf320eac3dc6b7
 2025-12-08 10:27:17.520069+00 | e5db60def7aaa5b89307378afb4ff06c
 2025-12-08 10:14:12.194379+00 | fa0527965698f73c494e901d02ef2ecd
 2025-12-08 10:13:40.324092+00 | b7b40eb57a6e41a0f1160a63551d337a
 2025-12-08 10:13:08.285033+00 | 275b8935d0cb02eebbdbbe8c06bc2903
 2025-12-08 10:12:29.201299+00 | 2718a0e66f733bc924c70a2ea4b95cfa
 2025-12-08 10:11:57.912539+00 | 513c52b38417299fb49a3f48a5c4353e
 2025-12-08 10:11:26.426727+00 | 176e3e5dafbbbbe537340a43f037f416
 2025-12-08 10:10:54.996065+00 | 4f931b60bd4464284471031366dd84d6
 2025-12-08 10:10:22.857835+00 | 0c2ede2f5b25e5a1d974fb7d7fe204e6

DAG 파일을 전혀 수정하지 않았는데, dag_hash가 30초 간격으로 계속 바뀌고 있었습니다. 10개 행이 전부 다른 해시값입니다. 여기서 감이 왔습니다 — 이건 DAG 파싱 자체에 문제가 있는 겁니다.

원인 분석: DAG Serialization과 dag_hash의 역할

Airflow의 DAG 처리 흐름

왜 dag_hash가 바뀌면 Task가 실패하는 걸까요? 먼저 Airflow 3.x의 DAG 처리 구조를 짚고 넘어가겠습니다.

Airflow 3.x의 DAG 처리 파이프라인 — dag-processor가 30초마다 재파싱하며 dag_hash를 갱신한다

Airflow 3.x에서는 DAG 파일을 직접 읽는 게 아닙니다. dag-processor가 DAG 파일을 파싱하고 직렬화(serialize)해서 DB의 serialized_dag 테이블에 저장하면, scheduler가 이 DB에서 직렬화된 DAG를 읽어 Task를 스케줄링하고 worker가 실행하는 구조입니다.

여기서 핵심은 dag-processor가 기본 30초 간격으로 DAG 파일을 반복 파싱한다는 점입니다. 파싱할 때마다 DAG의 구조를 해시로 만들어 dag_hash에 저장하는데, DAG 파일이 변하지 않았다면 이 해시값은 항상 같아야 합니다.

dag_hash가 바뀌면 왜 Task가 실패할까?

문제는 DAG Run이 실행되는 도중에 dag_hash가 바뀔 때 발생합니다. 실제로 겪었던 시나리오를 시간순으로 재구성하면 이렇습니다.

09:45:24  DAG Run 시작 (dag_hash: c60abd28)
          ├── Task 0~13 실행 시작 → 정상 완료 ✓

09:45:55  dag-processor가 DAG 재파싱
          └── 새로운 dag_hash 생성 (00f68c14) → DB 덮어쓰기

09:46:28  scheduler가 Task 14~29 실행 시도
          ├── Task들은 이전 dag_hash (c60abd28)를 참조
          ├── DB에는 새 dag_hash (00f68c14)만 존재
          └── ❌ "DAG not found" → Task 전부 실패!

DAG Run이 시작될 때의 dag_hash와, Task가 실행되려는 시점의 dag_hash가 달라져버린 겁니다. Scheduler 입장에서는 해당 DAG를 찾을 수 없으니 Task 실행을 포기하게 됩니다. 실행 시간이 짧은 DAG에서는 hash가 바뀌기 전에 모든 Task가 끝나버리니 문제가 안 되고, 오래 걸리는 DAG에서만 터졌던 이유가 바로 이겁니다.

근본 원인: DAG 파일 최상위의 Variable.get()

그러면 DAG 파일을 수정하지 않았는데 왜 dag_hash가 매번 달라졌을까요? 문제는 DAG 파일의 최상위 스코프에서 Variable.get()을 호출하는 코드에 있었습니다.

# ❌ DAG 파일의 최상위 스코프 — DAG parsing 시 매번 실행됨

from airflow.sdk import Variable

# DAG 함수 바깥에서 Variable.get() 호출!
gemini_manager = GeminiManager(
    api_key=Variable.get("GOOGLE_API_KEY"),  # ← 이게 문제
    ftp_manager=ftp_manager,
)

@dag(...)
def tts_batch_pipeline():
    result_batches = generate_tts.partial(
        tts_manager=tts_manager,  # 위에서 생성한 Manager 전달
    ).expand(...)

Airflow의 dag-processor는 DAG 파일을 파싱할 때 파일의 모든 최상위 코드를 실행합니다. 즉, Variable.get("GOOGLE_API_KEY") 호출이 30초마다 반복되는 셈입니다.

3.x에서는 DAG를 직렬화할 때 Variable 접근 정보도 함께 포함시킵니다. 매번 Variable.get()이 호출되면서 직렬화 결과에 미세한 차이가 생기고, 결국 dag_hash가 매번 달라지는 것이었습니다.

⚠️ Airflow 3.x의 새로운 규칙
Airflow 2.x에서는 DAG parsing 시 Variable/Connection 접근이 "권장하지 않음" 수준이었습니다. 하지만 Airflow 3.x에서는 사실상 금지입니다. Execution API 도입으로 DAG parsing과 Task execution의 분리가 더 엄격해졌고, parsing 시점에 외부 상태에 접근하면 dag_hash가 불안정해져 Task 실패로 이어집니다.

해결: Variable.get()을 Task 실행 시점으로 이동

해결 방법은 명확합니다. DAG 파일 최상위에서 Variable.get()을 호출하는 코드를 Task 함수 내부로 옮기면 됩니다.

# ✅ After: DAG 파일에서는 Manager를 생성하지 않음

@dag(...)
def tts_batch_pipeline():
    result_batches = generate_tts.partial(
        requests_url=...,   # 정적 데이터만 전달
    ).expand(...)

# ✅ Task 파일: 실행 시점에만 Variable 접근

@task
def generate_tts(requests_url, batch_idx, batch_size):
    # Task 실행 시에만 Variable 접근!
    from airflow.sdk import Variable

    api_key = Variable.get("GOOGLE_API_KEY")
    gemini_manager = GeminiManager(api_key=api_key, ...)

    # 작업 수행
    return run_generate_tts(...)

핵심은 Variable.get()을 @task 데코레이터가 붙은 함수 안으로 옮긴 것입니다. 이렇게 하면 dag-processor가 DAG를 파싱할 때는 Variable에 접근하지 않으므로, 직렬화 결과가 항상 동일해집니다.

수정 배포 후 DB를 다시 열어보는 순간 속이 시원했습니다. 차이가 확연합니다.

-- Before: dag_hash가 매번 다름
10:10:22 - 0c2ede2f5b25e5a1d974fb7d7fe204e6
10:10:54 - 4f931b60bd4464284471031366dd84d6
10:11:26 - 176e3e5dafbbbbe537340a43f037f416

-- After: dag_hash가 고정!
10:27:17 - e5db60def7aaa5b89307378afb4ff06c
10:28:00 - e5db60def7aaa5b89307378afb4ff06c ✓
10:29:00 - e5db60def7aaa5b89307378afb4ff06c ✓

📌 Before / After 실행 타이밍 비교

Before (❌)
DAG Parsing (30초마다) → Variable.get() 호출 → dag_hash 매번 변경 → DB 저장 → Task 실패

After (✅)
DAG Parsing (30초마다) → Variable 접근 없음 → dag_hash 항상 동일 → DB 저장
Task 실행 (필요할 때만) → Variable.get() 호출 → Manager 생성 → 작업 수행

DAG Parsing vs Task Execution: 반드시 알아야 할 규칙

이 문제의 본질은 “DAG 파싱 시점에 실행되는 코드”와 “Task 실행 시점에 실행되는 코드”의 구분입니다. Airflow를 처음 쓸 때 가장 헷갈리는 부분이기도 합니다.

구분	DAG Parsing	Task Execution
발생 시점	30초마다 (계속)	Task 실행 시 (1회)
실행 위치	dag-processor	Worker
목적	DAG 구조 파악	실제 작업 수행
Variable 접근	❌ 금지	✅ 허용
Connection 접근	❌ 금지	✅ 허용
외부 API 호출	❌ 금지	✅ 허용

2.x에서는 DAG parsing 시 Variable 접근이 가능했습니다. 권장하지는 않았지만 동작은 했고, dag_hash도 비교적 안정적이었습니다. 하지만 3.x의 Execution API 도입 이후 DAG parsing과 Task execution이 완전히 분리되면서, parsing 시점의 외부 상태 접근이 곧바로 dag_hash 불안정으로 이어지게 됐습니다.

피해야 할 패턴

DAG 파일의 최상위 스코프(즉 @task 바깥)에서 절대 하면 안 되는 것들을 정리하면 이렇습니다.

# ❌ DAG parsing 시 실행되는 최상위 코드들 — 전부 문제!

api_key = Variable.get("API_KEY")           # DB 조회 → 직렬화에 포함
conn = BaseHook.get_connection("my_conn")    # DB 조회 → 직렬화에 포함
start_date = datetime.now()                 # 매번 다른 값 → 직렬화 결과 변경
data = requests.get("https://api.com/...")  # 외부 API → 응답이 직렬화에 포함될 수 있음
config = json.load(open("/tmp/config.json"))  # 파일 내용 변경 시 hash 변경

이 코드들은 전부 @task 함수 안으로 옮겨야 합니다. DAG 파일의 최상위에는 정적 정의만 있어야 합니다.

# ✅ DAG 파일: 정적 정의만

@dag(
    schedule="@daily",
    start_date=datetime(2025, 1, 1),  # 고정값은 OK
    catchup=False,
)
def my_pipeline():
    result = my_task.partial(
        static_param="value",  # 정적 값만 전달
    ).expand(...)

# ✅ Task 파일: 동적 리소스는 여기서

@task
def my_task(static_param):
    from airflow.sdk import Variable

    api_key = Variable.get("API_KEY")
    conn = BaseHook.get_connection("my_conn")
    manager = MyManager(api_key, conn)

    return manager.process(static_param)

💡 import 위치도 신경 써야 합니다
from airflow.sdk import Variable 같은 가벼운 import는 파일 최상단에 둬도 괜찮습니다. 하지만 pandas, numpy, tensorflow 같은 무거운 라이브러리는 top-level에서 import하면 30초마다 파싱할 때마다 로딩 비용이 발생합니다. 공식 문서에서도 무거운 import는 Task 함수 내부로 옮기는 것을 권장하고 있습니다.

📌 핵심 요약

DAG 파일의 최상위 스코프에서 Variable.get(), Connection.get(), datetime.now() 등을 호출하면 dag_hash가 매번 달라진다
dag_hash가 DAG Run 도중에 바뀌면 scheduler가 나머지 Task를 찾지 못해 "DAG not found"로 실패한다
해결: 동적 리소스 접근을 @task 함수 내부로 이동. DAG 파일에는 정적 정의만 둔다
진단: SELECT dag_hash FROM serialized_dag로 hash가 고정되어 있는지 확인

마치며

디버깅 과정에서 가장 도움이 됐던 건 serialized_dag 테이블을 직접 조회해본 것이었습니다. dag_hash가 고정되어 있는지 확인하는 것만으로도 이 유형의 문제를 빠르게 진단할 수 있으니, Airflow에서 원인 모를 Task 실패가 발생하면 가장 먼저 확인해볼 만한 포인트입니다.

다음 글에서는 이번에 언급한 Dynamic Task Mapping의 병렬 처리 제한 전략을 다뤄보겠습니다.

참고자료

Prisma P3006 에러 해결: PostgreSQL enum의 트랜잭션 제약과 Shadow DB 문제

Donhyeok Kang — Mon, 23 Mar 2026 00:00:00 GMT

사내 인증 시스템에 SSO를 붙이면서, 기존 Role enum에 PENDING 값을 추가하는 마이그레이션을 작성했습니다. (웬만하면 enum은 쓰지 않는게 좋습니다.) 로컬 개발 DB에는 문제없이 적용됐고, 스테이징에도 잘 올라갔습니다. 그런데 며칠 뒤 다른 스키마 변경을 하려고 prisma migrate dev를 실행하는 순간, 전혀 예상하지 못한 에러가 터졌습니다.

에러 상황: P3006 Migration failed to apply cleanly

prisma migrate dev를 실행하자 다음과 같은 에러가 발생했습니다.

Error: P3006

Migration `20260319074550_add_pending_role` failed to apply cleanly
to the shadow database.
Error:
ERROR: unsafe use of new value "PENDING" of enum type "Role"
HINT: New enum values must be committed before they can be used.

0: schema_core::state::DevDiagnostic
   at schema-engine/core/src/state.rs:314

문제의 마이그레이션 파일(20260319074550_add_pending_role/migration.sql)을 열어보면, Prisma가 자동 생성한 SQL은 이렇게 생겼습니다.

-- 1) enum에 PENDING 값 추가
ALTER TYPE "Role" ADD VALUE 'PENDING';

-- 2) 바로 다음 줄에서 PENDING을 DEFAULT로 사용
ALTER TABLE "user" ALTER COLUMN "role" SET DEFAULT 'PENDING';

언뜻 보면 자연스러운 흐름입니다. enum에 값을 추가하고, 그 값을 기본값으로 설정하는 것이니까요. 하지만 이 두 SQL문이 하나의 트랜잭션 안에서 실행되면 PostgreSQL이 거부합니다.

이미 성공적으로 적용된 마이그레이션인데 왜 갑자기 에러가 나는 걸까요? 그 답은 Prisma의 Shadow Database 메커니즘에 있습니다.

원인 분석: PostgreSQL enum과 트랜잭션의 제약

ALTER TYPE … ADD VALUE의 트랜잭션 제약

PostgreSQL에서 enum 타입은 시스템 카탈로그(pg_enum)에 저장되는 특수한 데이터 타입입니다. 일반 테이블 데이터와 달리, enum 값의 추가는 카탈로그 수준의 DDL 변경이기 때문에 트랜잭션 처리에 특별한 제약이 따릅니다.

핵심은 이겁니다: ALTER TYPE ... ADD VALUE로 추가된 enum 값은 해당 트랜잭션이 커밋된 후에야 사용 가능합니다. PostgreSQL이 이런 제약을 두는 이유는 enum 값의 OID(Object Identifier) 할당과 관련이 있습니다.

-- 트랜잭션 시작 (Prisma가 마이그레이션 파일 전체를 하나의 트랜잭션으로 실행)
BEGIN;

-- 새 enum 값 'PENDING'에 OID가 할당됨
-- 하지만 이 OID는 아직 다른 세션/문맥에서 "보이지 않는" 상태
ALTER TYPE "Role" ADD VALUE 'PENDING';

-- 같은 트랜잭션에서 'PENDING'을 참조하려 하면?
-- PostgreSQL: "이 값은 아직 커밋되지 않았으므로 사용할 수 없습니다"
ALTER TABLE "user" ALTER COLUMN "role" SET DEFAULT 'PENDING';
-- ERROR: unsafe use of new value "PENDING" of enum type "Role"

COMMIT;

PostgreSQL 내부적으로, ADD VALUE는 pg_enum 카탈로그에 새 행을 삽입하면서 enumsortorder 값을 할당합니다. 하지만 트랜잭션 격리(Transaction Isolation) 규칙에 의해, 이 새 행은 트랜잭션이 커밋되기 전까지는 “확정된 값”으로 취급되지 않습니다. 만약 트랜잭션이 롤백되면 그 enum 값도 사라져야 하는데, 이미 그 값을 참조하는 행이 있다면 정합성이 깨지기 때문입니다.

이것은 PostgreSQL의 의도된 동작이며, 공식 문서에도 명시되어 있습니다.

ADD VALUE (the form that adds a new value to an enum type) cannot be executed inside a transaction block.

💡 참고: PostgreSQL 12 이후의 변화
PostgreSQL 12부터 ALTER TYPE ... ADD VALUE를 트랜잭션 내에서 실행하는 것 자체는 허용되었습니다. 하지만 같은 트랜잭션 안에서 그 새 값을 참조하는 것은 여전히 금지됩니다. 즉, ADD VALUE와 그 값을 사용하는 ALTER TABLE을 별도의 트랜잭션(또는 별도의 마이그레이션 파일)으로 분리해야 합니다.

Prisma Shadow Database가 문제를 증폭시키는 구조

여기서 한 가지 의문이 생깁니다. “이 마이그레이션은 며칠 전에 이미 성공적으로 적용됐는데, 왜 지금 에러가 나는 거지?”

답은 Prisma의 Shadow Database 메커니즘에 있습니다. prisma migrate dev를 실행하면, Prisma는 단순히 새 마이그레이션만 적용하는 게 아닙니다. 내부적으로 다음과 같은 과정을 거칩니다.

prisma migrate dev의 Shadow DB 워크플로우 — ③에서 enum 트랜잭션 제약에 걸려 실패한다

Shadow DB 생성: 완전히 빈 임시 데이터베이스를 생성합니다.
전체 마이그레이션 재실행: prisma/migrations/ 폴더에 있는 모든 마이그레이션을 처음부터 순차적으로 실행합니다.
스키마 비교: Shadow DB의 최종 스키마와 현재 schema.prisma 파일을 비교하여 새로 필요한 마이그레이션을 생성합니다.
Shadow DB 삭제: 임시 데이터베이스를 제거합니다.

Shadow DB가 존재하는 이유는 마이그레이션 히스토리의 무결성 검증입니다. 모든 마이그레이션을 처음부터 재실행해서, 마이그레이션 파일들이 정확하게 현재 스키마를 재현할 수 있는지 확인하는 것이죠. 실제 개발 DB는 수동 변경이나 직접 SQL 실행으로 인해 마이그레이션 히스토리와 어긋날 수 있기 때문에, “깨끗한 상태에서의 재현”이 필요합니다.

문제는 2단계에 있습니다. Shadow DB에서 마이그레이션을 재실행할 때, Prisma는 각 마이그레이션 파일의 SQL을 하나의 트랜잭션으로 실행합니다. 그래서 add_pending_role 마이그레이션의 두 SQL문이 같은 트랜잭션에 묶이고, PostgreSQL의 enum 트랜잭션 제약에 걸리는 겁니다.

⚠️ 핵심 포인트
최초 prisma migrate dev 실행 시에는 개발 DB에 직접 적용되므로 성공할 수 있습니다(이미 커밋된 상태에서 이어서 실행). 하지만 이후 모든 prisma migrate dev 호출에서 Shadow DB가 이 마이그레이션을 재실행할 때마다 실패합니다. 결과적으로 새로운 마이그레이션을 전혀 생성할 수 없는 상태가 됩니다.

이것은 Prisma가 자동 생성하는 SQL의 알려진 한계입니다. Prisma는 enum 값 추가와 해당 값 사용을 트랜잭션 분리 없이 단일 마이그레이션 파일에 넣어버립니다. Prisma GitHub 이슈에서도 꾸준히 보고되고 있는 문제입니다.

해결 방법: Shadow DB를 우회하는 수동 마이그레이션

prisma migrate dev가 Shadow DB를 사용하기 때문에 문제가 발생하므로, Shadow DB를 거치지 않는 수동 마이그레이션 방식으로 우회할 수 있습니다. Prisma 공식 문서에서도 이런 상황에 대해 3단계 수동 적용 방식을 권장합니다.

Step 1: prisma migrate diff로 SQL 생성

현재 데이터베이스 상태와 schema.prisma 파일의 차이를 SQL로 생성합니다. 이 명령은 Shadow DB를 사용하지 않고, 실제 DB의 현재 스키마를 직접 읽어서 비교합니다.

$ npx prisma migrate diff \
    --from-schema-datasource prisma/schema.prisma \
    --to-schema-datamodel prisma/schema.prisma \
    --script > prisma/migrations/<timestamp>_<migration_name>/migration.sql

생성된 SQL 파일을 꼭 확인하세요. 의도한 변경 사항만 포함되어 있는지 눈으로 검증하는 것이 중요합니다.

Step 2: prisma db execute로 직접 실행

생성된 SQL을 데이터베이스에 직접 실행합니다. 이 과정은 Shadow DB를 거치지 않으므로, enum 트랜잭션 문제의 영향을 받지 않습니다.

$ npx prisma db execute \
    --file prisma/migrations/<timestamp>_<migration_name>/migration.sql \
    --schema prisma/schema.prisma

Step 3: prisma migrate resolve로 히스토리 등록

마지막으로, 방금 수동으로 적용한 마이그레이션을 Prisma의 마이그레이션 히스토리(_prisma_migrations 테이블)에 “적용됨”으로 등록합니다.

$ npx prisma migrate resolve --applied <migration_name>

모든 과정이 끝나면 prisma migrate status로 상태를 확인합니다.

$ npx prisma migrate status

Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database

20260101000000_init
20260215120000_add_user_table
20260319074550_add_pending_role
20260323100000_new_migration

Database schema is up to date!

모든 마이그레이션이 정상 적용된 것으로 표시되면 성공입니다.

✅ 팁
이 방식은 prod/dev 히스토리를 깨뜨리지 않습니다. prisma migrate resolve는 마이그레이션 히스토리 테이블에 기록만 남기므로, 기존에 적용된 마이그레이션과 충돌하지 않습니다.

재발 방지

방법 1: 마이그레이션 파일 수동 분리

Prisma가 생성한 마이그레이션 SQL에서 enum 값 추가와 사용이 같은 파일에 있다면, 수동으로 두 개의 마이그레이션으로 분리할 수 있습니다.

-- ❌ Before: 하나의 마이그레이션 파일
ALTER TYPE "Role" ADD VALUE 'PENDING';
ALTER TABLE "user" ALTER COLUMN "role" SET DEFAULT 'PENDING';

-- ✅ After: 마이그레이션 1 (add_pending_value)
ALTER TYPE "Role" ADD VALUE 'PENDING';

-- ✅ After: 마이그레이션 2 (set_pending_default)
ALTER TABLE "user" ALTER COLUMN "role" SET DEFAULT 'PENDING';

prisma migrate dev --create-only로 마이그레이션 파일만 생성한 뒤 SQL을 직접 편집하고, 필요하다면 폴더를 분리하면 됩니다.

방법 2: enum 대신 String 타입 사용

근본적으로, PostgreSQL의 enum은 값 추가/삭제 시 이런 종류의 제약이 계속 따라옵니다. 값이 자주 변하는 컬럼이라면 String(TEXT) 타입 + 애플리케이션 레벨 검증으로 전환하는 것이 실용적입니다.

// ❌ Before: Prisma enum
enum Role {
  ADMIN
  USER
  PENDING
}

model User {
  role Role @default(PENDING)
}

// ✅ After: String 타입 + 애플리케이션 레벨 검증
model User {
  role String @default("PENDING")
}

실제로 이번 프로젝트에서도 SSO 전환 과정에서 Role을 enum에서 TEXT 컬럼으로 변경했습니다(remove_role_enum 마이그레이션). 이후로는 같은 문제가 발생하지 않고 있습니다.

📌 핵심 요약

PostgreSQL에서 ALTER TYPE ... ADD VALUE로 추가한 enum 값은 같은 트랜잭션 내에서 사용할 수 없다
Prisma의 Shadow DB는 모든 마이그레이션을 처음부터 재실행하므로, 이 문제가 한 번 발생하면 이후 모든 migrate dev가 막힌다
prisma migrate diff → db execute → migrate resolve 3단계로 Shadow DB를 우회할 수 있다
장기적으로는 자주 변하는 enum을 String 타입으로 전환하는 것이 안전하다

마치며

Prisma는 대부분의 마이그레이션을 깔끔하게 자동 생성해주지만, PostgreSQL의 enum 트랜잭션 제약과 만나면 이런 함정에 빠질 수 있습니다. 특히 Shadow DB 때문에 “이미 적용된 마이그레이션이 갑자기 실패하는” 상황은 처음 겪으면 상당히 당황스럽습니다.

경험상, enum에 새 값을 추가하는 마이그레이션을 작성할 때는 --create-only 옵션으로 먼저 SQL을 확인하고, 필요하다면 수동으로 분리하는 습관을 들이는 것이 좋습니다. 혹은 애초에 값 변동이 잦은 컬럼은 String 타입으로 설계하는 것도 실용적인 선택입니다.

참고자료

통계적 함정: 다중 검정, p-hacking, 심슨의 역설, 상관 ≠ 인과

Donhyeok Kang — Thu, 26 Feb 2026 00:00:00 GMT

“통계는 거짓말을 하지 않지만, 거짓말쟁이는 통계를 한다.” 이 오래된 경구는 과장이 아니다. 지난 글에서 A/B 테스트를 다루며 “통계를 잘못 쓰면 오히려 더 위험하다”는 점을 언급했다. 이 시리즈의 마지막 편인 이 글에서는, 그 위험의 실체를 하나하나 파헤친다.

17편에 걸쳐 확률론의 기초부터 추론, 응용까지 쌓아온 도구들은 그 자체로는 강력하다. 문제는 도구를 휘두르는 사람에게 있다. 검정을 남발하면 거짓 발견이 쏟아지고, p-value를 조작하면 원하는 결론을 만들어낼 수 있으며, 데이터를 잘못 집계하면 현실과 정반대의 결론에 도달한다. 통계적 사고력의 최종 관문은 이런 함정을 알아채는 능력이다.

다중 검정 문제 (Multiple Testing Problem)

20번 검정하면 1번은 속는다

가설검정에서 유의수준 $\alpha = 0.05$ 의 의미를 배웠다. 귀무가설이 참일 때 이를 잘못 기각할 확률, 즉 1종 오류의 상한이 5%라는 뜻이다. 한 번의 검정에서는 합리적인 기준이지만, 여러 번 반복하면 상황이 달라진다.

효과가 전혀 없는 데이터에 대해 독립적인 검정을 $m$ 번 수행한다고 하자. 각 검정에서 거짓 양성이 나올 확률이 $\alpha$ 이므로, $m$ 번 중 적어도 하나가 유의하게 나올 확률은:

$P(\text{적어도 1개 거짓 양성}) = 1 - (1-\alpha)^m$

검정 횟수 $m$	거짓 양성 1개 이상 확률
1	5.0%
5	22.6%
10	40.1%
20	64.2%
100	99.4%

20개의 변수를 테스트하면 아무 효과가 없어도 64%의 확률로 “유의한” 결과가 하나 이상 나온다. Python으로 직접 확인해 보자.

import numpy as np
from scipy import stats

np.random.seed(42)

n_tests = 20
n_samples = 100
significant_count = 0
n_simulations = 10000

for _ in range(n_simulations):
    p_values = []
    for _ in range(n_tests):
        # 두 그룹 모두 같은 분포에서 추출 (효과 없음)
        group_a = np.random.normal(0, 1, n_samples)
        group_b = np.random.normal(0, 1, n_samples)
        _, p = stats.ttest_ind(group_a, group_b)
        p_values.append(p)
    # 20개 중 하나라도 p < 0.05이면 "발견"
    if min(p_values) < 0.05:
        significant_count += 1

print(f"20개 검정 시 거짓 발견 비율: {significant_count/n_simulations:.1%}")
# 20개 검정 시 거짓 발견 비율: 64.0%

효과가 전혀 없는 랜덤 데이터인데도, 20개를 검정하면 약 64%의 시뮬레이션에서 “유의한 결과”가 나타났다.

보정 방법

다중 검정 문제의 핵심 해법은 유의수준을 조정하는 것이다.

Bonferroni 보정: 가장 간단하고 보수적인 방법이다. 유의수준을 검정 횟수로 나눈다.

$\alpha_{\text{adjusted}} = \frac{\alpha}{m}$

20개 검정이면 $\alpha = 0.05/20 = 0.0025$ . 직관적이고 구현이 쉽지만, 지나치게 보수적이라 진짜 효과까지 놓칠 수 있다(검정력 손실).

FDR 제어 (Benjamini-Hochberg): 모든 거짓 양성을 차단하는 대신, **거짓 발견 비율(False Discovery Rate)**을 일정 수준 이하로 유지하는 전략이다. 탐색적 분석에서 Bonferroni보다 훨씬 실용적이다.

import numpy as np
from scipy import stats

np.random.seed(42)

n_tests = 20
n_samples = 100

# 20개 검정 중 처음 3개만 진짜 효과 있음
p_values = []
for i in range(n_tests):
    group_a = np.random.normal(0, 1, n_samples)
    if i < 3:
        group_b = np.random.normal(0.5, 1, n_samples)  # 효과 크기 0.5
    else:
        group_b = np.random.normal(0, 1, n_samples)     # 효과 없음
    _, p = stats.ttest_ind(group_a, group_b)
    p_values.append(p)

p_values = np.array(p_values)

# Bonferroni 보정
bonferroni_sig = p_values < (0.05 / n_tests)

# Benjamini-Hochberg FDR 보정
sorted_idx = np.argsort(p_values)
sorted_p = p_values[sorted_idx]
bh_threshold = np.arange(1, n_tests + 1) / n_tests * 0.05
bh_reject = sorted_p <= bh_threshold
# BH는 마지막으로 기각되는 지점까지 모두 기각
if bh_reject.any():
    max_reject_idx = np.max(np.where(bh_reject))
    bh_reject_final = np.zeros(n_tests, dtype=bool)
    bh_reject_final[sorted_idx[:max_reject_idx + 1]] = True
else:
    bh_reject_final = np.zeros(n_tests, dtype=bool)

print("검정 | p-value  | Bonferroni | BH-FDR | 진짜 효과")
print("-" * 55)
for i in range(n_tests):
    true_effect = "O" if i < 3 else "X"
    bonf = "기각" if bonferroni_sig[i] else "  -"
    bh = "기각" if bh_reject_final[i] else "  -"
    print(f" {i+1:2d}  | {p_values[i]:.4f}  |    {bonf}   |  {bh}  |    {true_effect}")

Bonferroni는 보수적이라 진짜 효과를 놓칠 수 있고, BH-FDR은 더 많은 진짜 효과를 잡아내면서도 거짓 발견 비율을 제어한다. 유전체학(genomics)처럼 수천 개의 유전자를 동시에 검정하는 분야에서는 BH 방법이 사실상 표준이다.

💡 FWER vs FDR

Bonferroni는 FWER(Family-Wise Error Rate) — “하나라도 거짓 양성이 나올 확률”을 제어한다. BH는 FDR(False Discovery Rate) — “기각한 것 중 거짓 양성의 비율”을 제어한다. FWER 제어는 더 엄격하지만 검정력이 떨어지고, FDR 제어는 더 관대하지만 탐색적 분석에 적합하다.

p-hacking: 원하는 결론을 “만들어내는” 기술

정의와 수법들

p-hacking은 유의미한 p-value를 얻기 위해 분석 과정을 의도적 또는 무의식적으로 조작하는 행위다. 다중 검정 문제가 “모르고 빠지는 함정”이라면, p-hacking은 “알면서 파는 함정”에 가깝다.

흔한 수법들을 정리하면:

수법	설명	왜 문제인가
변수 선택적 보고	여러 종속/독립 변수 조합을 시도하고 유의한 것만 보고	다중 검정을 은폐
이상치 제거 기준 조작	p < 0.05가 나올 때까지 이상치 제거 기준을 조정	데이터를 결론에 맞춤
분석 중단 시점 조절	데이터를 조금씩 추가하며 p-value 모니터링, 유의해지면 중단	실제 α가 명목 α보다 훨씬 높아짐
하위 그룹 사후 분석	전체에서 유의하지 않으면 성별, 연령대 등으로 쪼개서 재분석	검정 횟수 폭증
공변량 추가/제거	통제 변수를 넣었다 뺐다 하며 모델 조정	연구자 자유도 남용

시뮬레이션: 같은 데이터에서 p < 0.05 만들기

완전히 효과 없는 데이터에서 p-hacking으로 “유의한” 결과를 만드는 과정을 시뮬레이션해 보자.

import numpy as np
from scipy import stats

np.random.seed(123)

# 효과가 전혀 없는 데이터
x = np.random.normal(50, 10, 200)
y = np.random.normal(50, 10, 200)

print("=== p-hacking 시뮬레이션 ===\n")

# 1단계: 전체 데이터로 t-검정 → 유의하지 않음
t, p = stats.ttest_ind(x, y)
print(f"1) 전체 데이터 (n=200 vs 200): p = {p:.4f}")

# 2단계: 상위 50%만 선택 → 하위 그룹에서 유의!
x_sub = x[x > np.median(x)]
y_sub = y[y > np.median(y)]
t, p = stats.ttest_ind(x_sub, y_sub)
print(f"2) 상위 50%만 (n={len(x_sub)} vs {len(y_sub)}): p = {p:.4f}")

# 3단계: 이상치 제거 (평균±1.5σ 바깥 제거)
x_mean, x_std = np.mean(x), np.std(x)
y_mean, y_std = np.mean(y), np.std(y)
x_clean = x[np.abs(x - x_mean) < 1.5 * x_std]
y_clean = y[np.abs(y - y_mean) < 1.5 * y_std]
t, p = stats.ttest_ind(x_clean, y_clean)
print(f"3) 이상치 제거 (n={len(x_clean)} vs {len(y_clean)}): p = {p:.4f}")

# 4단계: 여러 분할 시도 → 일부 구간에서 유의한 결과
print("\n4) 구간별 분석:")
best_p = 1.0
best_desc = ""
for low, high in [(0, 50), (25, 75), (50, 100), (30, 70), (40, 90), (10, 60),
                  (20, 80), (35, 85), (15, 65), (45, 95)]:
    mask_x = (x >= np.percentile(x, low)) & (x <= np.percentile(x, high))
    mask_y = (y >= np.percentile(y, low)) & (y <= np.percentile(y, high))
    if mask_x.sum() > 5 and mask_y.sum() > 5:
        t, p_sub = stats.ttest_ind(x[mask_x], y[mask_y])
        if p_sub < best_p:
            best_p = p_sub
            best_desc = f"x[{low}%-{high}%] vs y[{low}%-{high}%]"

print(f"   10개 구간 중 최소 p-value: {best_p:.4f} ({best_desc})")

# 5단계: 변수 변환 시도
transforms = {
    "log(x+100)": (np.log(x + 100), np.log(y + 100)),
    "sqrt(|x|)": (np.sqrt(np.abs(x)), np.sqrt(np.abs(y))),
    "x^2": (x**2, y**2),
    "1/x": (1/(x + 0.01), 1/(y + 0.01)),
}
print("\n5) 변수 변환 시도:")
for name, (xt, yt) in transforms.items():
    t, p_tr = stats.ttest_ind(xt, yt)
    marker = " ← 유의!" if p_tr < 0.05 else ""
    print(f"   {name}: p = {p_tr:.4f}{marker}")

이 시뮬레이션은 완벽하게 동일한 분포에서 추출한 데이터임에도, 구간 분할이나 변수 변환 등의 수법을 동원하면 p < 0.05에 근접하거나 도달할 수 있음을 보여준다. 10가지 구간 분할을 시도하는 것은 사실상 10번의 검정을 수행하는 것인데, 그 중 최소 p-value만 보고한다면 다중 검정 보정 없이 거짓 발견을 제조하는 셈이다.

방어: 사전 등록(Pre-registration)

p-hacking의 가장 강력한 방어책은 **사전 등록(Pre-registration)**이다. 데이터 수집 전에 가설, 분석 방법, 표본 크기, 유의수준을 공개적으로 등록한다. 사후적 분석 조작의 여지를 원천 차단하는 것이다.

OSF Registries — 학술 연구 사전 등록 플랫폼
AsPredicted.org — 간소화된 사전 등록
기업 A/B 테스트에서도 실험 계획서를 사전에 문서화하는 것이 동일한 원리

⚠️ p-hacking은 사기(fraud)와 다르다

데이터 조작은 명백한 연구 부정이다. p-hacking은 데이터 자체는 건드리지 않지만 분석 과정에서의 “연구자 자유도(researcher degrees of freedom)“를 남용한다. 더 교활한 점은 연구자 본인조차 자신이 p-hacking을 하고 있다는 사실을 인식하지 못하는 경우가 많다는 것이다. 이것이 사전 등록이 필요한 근본 이유다.

심슨의 역설 (Simpson’s Paradox)

전체와 부분이 반대 방향을 가리킨다

심슨의 역설은 하위 그룹에서 성립하는 경향이 전체 데이터를 합산하면 역전되는 현상이다. 가장 유명한 사례는 1973년 UC 버클리 대학원 입학 데이터다.

전체 합산 결과만 보면 여성의 합격률이 남성보다 낮아 “성차별이 존재한다”는 결론에 이른다. 그러나 학과별로 나누어 보면 대부분의 학과에서 여성 합격률이 남성과 비슷하거나 오히려 높았다. 역설의 원인은 여성 지원자가 합격률이 낮은 경쟁이 치열한 학과에 더 많이 지원했기 때문이다.

Python으로 이 구조를 재현해 보자.

import numpy as np
import pandas as pd

np.random.seed(42)

# UC Berkeley 스타일 시뮬레이션 데이터
data = {
    '학과': ['A', 'A', 'B', 'B', 'C', 'C', 'D', 'D'],
    '성별': ['남', '여', '남', '여', '남', '여', '남', '여'],
    '지원자': [825, 108, 560, 25, 325, 593, 417, 375],
    '합격자': [512, 89, 353, 17, 120, 202, 138, 131],
}
df = pd.DataFrame(data)
df['합격률'] = df['합격자'] / df['지원자']

print("=== 학과별 합격률 ===")
for dept in ['A', 'B', 'C', 'D']:
    dept_data = df[df['학과'] == dept]
    male = dept_data[dept_data['성별'] == '남'].iloc[0]
    female = dept_data[dept_data['성별'] == '여'].iloc[0]
    print(f"학과 {dept}: 남 {male['합격률']:.1%} ({male['지원자']}명) | "
          f"여 {female['합격률']:.1%} ({female['지원자']}명)")

# 전체 합산
male_total = df[df['성별'] == '남']
female_total = df[df['성별'] == '여']
male_rate = male_total['합격자'].sum() / male_total['지원자'].sum()
female_rate = female_total['합격자'].sum() / female_total['지원자'].sum()
print(f"\n=== 전체 합산 ===")
print(f"남성 합격률: {male_rate:.1%} ({male_total['지원자'].sum()}명)")
print(f"여성 합격률: {female_rate:.1%} ({female_total['지원자'].sum()}명)")
print(f"\n→ 전체: 남성이 높다. 학과별: 여성이 같거나 높다 → 심슨의 역설!")

학과별로 보면 여성 합격률이 남성과 비슷하거나 높은데, 전체를 합치면 남성이 더 높게 나타난다. 이 역설의 핵심은 교란 변수(Confounding Variable) — 여기서는 “지원 학과”가 성별과 합격률 모두에 영향을 미치기 때문이다.

💡 심슨의 역설 방어법

항상 “이 데이터를 합산해도 되는가?”를 먼저 물어야 한다. 하위 그룹 간 구성 비율이 다르면 단순 합산은 위험하다. 핵심 교란 변수를 파악하고, 그룹별로 나누어 분석(stratified analysis)하거나 회귀 모형에서 교란 변수를 통제해야 한다.

상관 ≠ 인과 (Correlation ≠ Causation)

거짓 상관의 세계

두 변수가 함께 움직인다고 해서 하나가 다른 하나를 야기하는 것은 아니다. Tyler Vigen의 Spurious Correlations 프로젝트에는 수백 개의 거짓 상관이 수집되어 있다.

니콜라스 케이지 출연 영화 수 vs 수영장 익사 사고 수 (r = 0.67)
미국 치즈 소비량 vs 침대 시트에 얽혀 사망한 사람 수 (r = 0.95)
1인당 마가린 소비 vs 메인 주 이혼율 (r = 0.99)

높은 상관계수가 인과관계를 증명하지 않는 이유는 크게 세 가지다.

원인	설명	예시
교란 변수	제3의 변수가 둘 다에 영향	아이스크림 판매 ↑ & 범죄율 ↑ (교란: 기온)
역인과	인과 방향이 반대	“소방관이 많을수록 화재 피해가 크다” (큰 화재 → 소방관 투입)
우연의 일치	시계열 데이터에서 추세가 우연히 겹침	니콜라스 케이지 vs 수영장 익사

import numpy as np
from scipy import stats

np.random.seed(42)
n = 50

# 교란 변수 Z가 X, Y 모두에 영향
z = np.random.normal(0, 1, n)  # 교란 변수 (예: 기온)
x = 2 * z + np.random.normal(0, 1, n)  # 아이스크림 판매
y = 3 * z + np.random.normal(0, 1, n)  # 범죄율

# X와 Y의 상관
r_xy, p_xy = stats.pearsonr(x, y)
print(f"X-Y 상관: r = {r_xy:.3f}, p = {p_xy:.4f}")

# Z를 통제한 편상관(Partial Correlation)
# X ~ Z의 잔차, Y ~ Z의 잔차의 상관
slope_xz = np.polyfit(z, x, 1)
slope_yz = np.polyfit(z, y, 1)
resid_x = x - np.polyval(slope_xz, z)
resid_y = y - np.polyval(slope_yz, z)
r_partial, p_partial = stats.pearsonr(resid_x, resid_y)
print(f"Z 통제 후 편상관: r = {r_partial:.3f}, p = {p_partial:.4f}")
print(f"\n→ 교란 변수 Z를 통제하면 X-Y 상관이 사라진다!")

교란 변수 Z(기온)를 통제하면 X(아이스크림)와 Y(범죄율) 사이의 강한 상관이 사라지는 것을 볼 수 있다. 관측 데이터에서 인과를 주장하려면 교란 변수를 철저히 통제해야 한다.

인과 추론의 조건

순수한 관측 데이터에서 상관을 인과로 끌어올리기 위한 접근법들이 있다.

방법	핵심 아이디어	한계
RCT (무작위 통제 실험)	처리군/통제군을 무작위 배정하여 교란 제거	비용, 윤리적 제약
도구변수 (Instrumental Variable)	처리에만 영향을 주고 결과에는 직접 영향 없는 변수 활용	적절한 도구변수 찾기 어려움
자연실험 (Natural Experiment)	외부 충격이 무작위 배정 역할을 한 상황 활용	드물고, 가정 검증이 어려움
회귀불연속 설계 (RDD)	임계값 근처에서 처리 유무가 바뀌는 상황 활용	임계값 근처 데이터만 사용

실무에서 A/B 테스트가 “황금 표준”인 이유가 바로 여기에 있다. 무작위 배정은 알려진 교란 변수뿐 아니라 알려지지 않은 교란 변수까지 균형을 맞추는 유일한 방법이기 때문이다.

기저율 무시 (Base Rate Neglect)

양성이라고 다 환자가 아니다

조건부 확률과 베이즈 정리에서 베이즈 정리를 처음 배웠고, 베이지안 추론에서 이를 추론 프레임워크로 확장했다. 기저율 무시는 베이즈 정리를 직관적으로 이해하지 못할 때 빠지는 대표적인 함정이다.

유병률 0.1%(1,000명 중 1명)인 질병에 대해 민감도 99%, 특이도 99%인 검사가 있다고 하자.

$P(\text{질병} \mid \text{양성}) = \frac{P(\text{양성} \mid \text{질병}) \cdot P(\text{질병})}{P(\text{양성})}$

import numpy as np

# 기저율 무시 시뮬레이션
prevalence = 0.001     # 유병률 0.1%
sensitivity = 0.99     # 민감도 (진양성률)
specificity = 0.99     # 특이도 (진음성률)

# 베이즈 정리
p_positive = sensitivity * prevalence + (1 - specificity) * (1 - prevalence)
p_disease_given_positive = (sensitivity * prevalence) / p_positive

print("=== 기저율 무시 예제 ===\n")
print(f"유병률: {prevalence:.1%}")
print(f"민감도: {sensitivity:.0%}")
print(f"특이도: {specificity:.0%}")
print(f"\n양성 판정 시 실제 감염 확률: {p_disease_given_positive:.1%}")
print(f"양성 판정 시 거짓 양성 확률: {1 - p_disease_given_positive:.1%}")

# 100만 명 검사 시뮬레이션
population = 1_000_000
actual_sick = int(population * prevalence)
actual_healthy = population - actual_sick

true_positive = int(actual_sick * sensitivity)
false_positive = int(actual_healthy * (1 - specificity))

print(f"\n=== 100만 명 검사 결과 ===")
print(f"실제 환자: {actual_sick:,}명")
print(f"진양성 (정확한 양성): {true_positive:,}명")
print(f"거짓 양성 (건강한데 양성): {false_positive:,}명")
print(f"전체 양성: {true_positive + false_positive:,}명")
print(f"양성 중 실제 환자 비율: {true_positive/(true_positive+false_positive):.1%}")

민감도와 특이도가 모두 99%인 “우수한” 검사임에도, 유병률이 0.1%로 낮으면 양성 판정을 받은 사람 중 실제 환자는 약 9%에 불과하다. 나머지 91%는 건강한데 양성으로 잘못 분류된 거짓 양성이다.

⚠️ 실무에서의 기저율 무시

이 함정은 의료 검사만의 문제가 아니다. 스팸 필터, 사기 탐지, 이상 탐지 등 **“희귀 사건을 탐지하는 모든 시스템”**에 동일하게 적용된다. 사기 거래 비율이 0.01%인 시스템에서 99% 정확도를 자랑해도, 양성 판정의 대부분은 거짓 양성이다. 모델 성능을 정확도(accuracy)만으로 판단하면 안 되는 이유가 여기에 있다.

통계적 유의성 ≠ 실질적 중요성

p-value가 작아도 쓸모없을 수 있다

가설검정에서 p-value의 정확한 의미를 다뤘다. p < 0.05는 “효과가 0이라는 가설 하에서 이 정도 이상의 데이터를 관측할 확률이 5% 미만”이라는 뜻이지, “효과가 크다”는 뜻이 아니다.

표본 크기가 매우 크면 아무리 작은 차이도 통계적으로 유의해진다. 이것이 대표본의 저주다.

import numpy as np
from scipy import stats

np.random.seed(42)

print("=== 표본 크기와 p-value의 관계 ===\n")
print(f"{'표본 크기':>10} | {'평균 차이':>10} | {'p-value':>12} | {'Cohen d':>10} | 판정")
print("-" * 70)

# 진짜 평균 차이가 0.02 (체감 불가능한 미미한 차이, Cohen's d ≈ 0.02)
for n in [100, 1000, 10000, 100000, 1000000]:
    group_a = np.random.normal(100, 1, n)
    group_b = np.random.normal(100.02, 1, n)

    t, p = stats.ttest_ind(group_a, group_b)
    mean_diff = np.mean(group_b) - np.mean(group_a)
    pooled_std = np.sqrt((np.std(group_a)**2 + np.std(group_b)**2) / 2)
    cohens_d = mean_diff / pooled_std

    sig = "유의 *" if p < 0.05 else "비유의"
    print(f"{n:>10,} | {mean_diff:>10.4f} | {p:>12.6f} | {cohens_d:>10.4f} | {sig}")

print(f"\n→ Cohen's d ≈ 0.02 (사실상 무의미)인데, n이 커지면 p-value만 작아진다!")

두 그룹의 실제 평균 차이가 0.02(Cohen’s d $\approx$ 0.02)에 불과해도 표본이 충분히 크면 p-value는 극도로 작아진다. Cohen의 기준에서 d = 0.02는 “작은 효과”(0.2)에도 한참 못 미치는 수준이다. p-value가 아무리 작아도 효과 크기가 실질적으로 의미 없다면 그 결과는 쓸모가 없다.

효과 크기(Effect Size)를 반드시 보고하라

지표	공식	해석 기준 (Cohen)
Cohen’s d	$d = \frac{\bar{X}_1 - \bar{X}_2}{s_p}$	소: 0.2, 중: 0.5, 대: 0.8
상관계수 r	$r = \sqrt{\frac{t^2}{t^2 + df}}$	소: 0.1, 중: 0.3, 대: 0.5
$\eta^2$ (에타 제곱)	$\eta^2 = \frac{SS_{\text{between}}}{SS_{\text{total}}}$	소: 0.01, 중: 0.06, 대: 0.14

p-value만 보고하는 논문이나 보고서는 불완전하다. 효과 크기 + 신뢰구간 + p-value 세 가지를 함께 보고해야 결과의 실질적 의미를 판단할 수 있다.

생태학적 오류와 개인주의적 오류

집단 통계로 개인을 판단하지 마라

오류 유형	방향	예시
생태학적 오류 (Ecological Fallacy)	집단 → 개인	“소득이 높은 지역의 범죄율이 낮다” → “부유한 사람은 범죄를 저지르지 않는다”
개인주의적 오류 (Atomistic Fallacy)	개인 → 집단	“이 환자에게 약이 효과 있었다” → “이 약은 모든 환자에게 효과 있다”

생태학적 오류는 집단 수준의 상관관계를 개인 수준에 그대로 적용할 때 발생한다. 국가별 초콜릿 소비량과 노벨상 수상자 수가 상관있다고 해서 “초콜릿을 먹으면 노벨상을 탄다”고 말할 수 없다.

import numpy as np
from scipy import stats

np.random.seed(42)

n_groups = 20
group_means_x = np.random.uniform(30, 70, n_groups)
group_means_y = 0.8 * group_means_x + np.random.normal(0, 5, n_groups)

# 집단 수준 상관
r_group, _ = stats.pearsonr(group_means_x, group_means_y)
print(f"집단 수준 상관 (n={n_groups} 그룹): r = {r_group:.3f}")

# 개인 수준 데이터 생성 — 집단 내에서는 상관이 약하거나 없음
all_x, all_y = [], []
for gx, gy in zip(group_means_x, group_means_y):
    n_ind = 50
    ind_x = np.random.normal(gx, 15, n_ind)
    ind_y = np.random.normal(gy, 15, n_ind)  # 개인 수준에서 x와 y는 독립
    all_x.extend(ind_x)
    all_y.extend(ind_y)

r_individual, _ = stats.pearsonr(all_x, all_y)
print(f"개인 수준 상관 (n={n_groups * 50} 명): r = {r_individual:.3f}")
print(f"\n→ 집단 수준에서 강한 상관이 개인 수준에서는 약해진다!")

집단 평균 간의 강한 상관이 개인 수준에서는 상당히 약해지는 것을 확인할 수 있다. 분석 단위(unit of analysis)와 결론의 적용 단위를 항상 일치시켜야 한다.

방어 체크리스트

통계 분석을 수행하거나 통계 기반 보고서를 읽을 때, 다음 체크리스트를 습관화하면 대부분의 함정을 피할 수 있다.

#	점검 항목	관련 함정
1	검정을 몇 번 수행했는가? 다중 검정 보정을 했는가?	다중 검정
2	분석 계획이 사전에 수립되었는가?	p-hacking
3	하위 그룹 분석 결과가 전체와 일치하는가?	심슨의 역설
4	상관관계를 인과로 해석하고 있지는 않은가?	상관 ≠ 인과
5	기저율(사전 확률)을 고려했는가?	기저율 무시
6	효과 크기와 신뢰구간을 함께 보고했는가?	유의성 ≠ 중요성
7	분석 단위와 결론 적용 단위가 일치하는가?	생태학적/개인주의적 오류
8	표본 크기가 결론을 지지하기에 충분한가?	검정력 부족
9	데이터 수집 과정에서 편향(selection bias)은 없는가?	표본 편향
10	결론이 “너무 좋아 보이면” 의심했는가?	모든 함정

✅ 실전 팁

이 체크리스트를 팀 데이터 분석 리뷰 프로세스에 포함시키면 효과적이다. 코드 리뷰처럼 “통계 리뷰”를 도입하고, 분석자가 아닌 제3자가 위 항목을 점검하는 구조가 이상적이다.

마치며: 18편의 통계 여정을 돌아보며

이 글로 확률과 통계 시리즈 전 18편이 완결된다.

확률의 기초에서 표본 공간과 확률 공리를 정의하며 시작한 여정은, 세 개의 큰 장으로 이루어져 있었다.

확률론 기초(1~7편) — 확률 기초에서 불확실성의 수학적 언어를 처음 배웠고, 조건부 확률과 베이즈 정리에서 “정보가 확률을 바꾸는” 메커니즘을 만났다. 확률변수와 기댓값, 이산 분포, 연속 분포를 거치며 현실 세계의 불확실성을 모델로 옮기는 법을 익혔다. 대수의 법칙과 중심극한정리에서 표본과 모집단을 잇는 다리를 놓았고, 정보이론에서 “정보”라는 개념 자체를 정량화했다.

통계적 추론(8~14편) — 확률론이라는 토대 위에서 추론의 도구들이 하나씩 쌓였다. 점추정과 MLE로 데이터에서 모수를 추정하는 체계적 방법을 배웠다. 신뢰구간으로 추정의 불확실성을 구간으로 표현하고, 가설검정과 검정 방법론으로 의사결정의 틀을 세웠다. 부트스트랩에서 분포 가정이 어려울 때의 비모수적 우회로를 확보했고, 베이지안 추론에서 완전히 다른 패러다임의 눈으로 같은 문제를 바라보았다.

응용 통계(15~18편) — 이론이 현실과 만나는 마지막 장에서는 EDA로 데이터와의 첫 대면법을 다루고, 표본 추출로 데이터 수집의 과학을 배웠으며, A/B 테스트에서 인과 추론을 실전에 적용했다. 그리고 이 마지막 편에서, 그 모든 도구를 잘못 사용할 때 벌어지는 일들을 직시했다.

돌이켜 보면, 이 시리즈의 메타-교훈은 하나로 수렴한다. 통계는 “정답”을 알려주는 마법이 아니라, 불확실성 속에서 “최선의 판단”을 내리기 위한 사고 체계다. p-value가 0.03이라는 숫자 자체에는 선도 악도 없다. 그 숫자가 어떤 맥락에서, 얼마나 엄밀한 과정을 거쳐 나왔는지, 효과의 크기는 실질적으로 의미 있는지, 교란 변수는 통제되었는지 — 이런 질문을 던질 줄 아는 능력이 통계적 사고력이다.

데이터가 넘쳐나는 시대에, 통계적 사고력은 데이터를 다루는 모든 사람에게 가장 기본적인 무기다. 이 시리즈가 그 무기를 벼리는 데 작은 도움이 되었기를 바란다.

참고자료

Wasserstein, R. L. & Lazar, N. A. “The ASA Statement on p-Values: Context, Process, and Purpose.” The American Statistician, 70(2), 2016. — 미국통계학회의 공식 p-value 성명
Gelman, A. & Loken, E. “The garden of forking paths.” Columbia University, 2013. — 연구자 자유도와 p-hacking의 이론적 분석
Bickel, P. J. et al. “Sex Bias in Graduate Admissions: Data from Berkeley.” Science, 187(4175), 1975. — UC Berkeley 심슨의 역설 원논문
Pearl, J. The Book of Why. Basic Books, 2018. — 인과 추론의 대중서
Sullivan, G. M. & Feinn, R. “Using Effect Size — or Why the p Value Is Not Enough.” Journal of Graduate Medical Education, 4(3), 2012. — 효과 크기 보고의 중요성

A/B 테스트 설계와 분석: 가설 수립부터 의사결정까지

Donhyeok Kang — Wed, 25 Feb 2026 00:00:00 GMT

이전 글에서 표본 추출을 다뤘다. 올바른 표본을 얻었다면, 이제 실험을 설계할 차례다. “새 UI로 전환율이 올랐다!” — 정말? 우연의 결과가 아닌지 어떻게 확신하는가?

제품 개발에서 “느낌”으로 의사결정을 내리는 시대는 지났다. Google은 연간 10,000건 이상의 A/B 테스트를 실행하고, Netflix는 UI의 모든 변경 사항을 실험으로 검증한다. A/B 테스트는 가설검정의 가장 실용적인 응용이며, 데이터 기반 의사결정의 핵심 도구다.

이 글에서는 A/B 테스트를 올바르게 설계하고, 결과를 정확하게 분석하는 전 과정을 다룬다.

A/B 테스트의 구조

대조군과 실험군

A/B 테스트의 구조는 단순하다. 사용자를 두 그룹으로 나누어 서로 다른 경험을 제공하고, 결과를 비교한다.

구성 요소	설명	예시
대조군(Control, A)	현재 버전을 경험하는 그룹	기존 결제 페이지
실험군(Treatment, B)	변경된 버전을 경험하는 그룹	새 결제 페이지
무작위 배정(Randomization)	사용자를 랜덤으로 A/B에 할당	사용자 ID 해시 기반
핵심 지표(Primary Metric)	비교의 기준이 되는 측정값	전환율, 평균 매출

사용자 풀 (N명)
    │
    ├─── 무작위 배정 ───┐
    │                    │
    ▼                    ▼
 대조군 (A)          실험군 (B)
 기존 UI              새 UI
    │                    │
    ▼                    ▼
 지표 측정            지표 측정
 (전환율 p_A)        (전환율 p_B)
    │                    │
    └────── 비교 ────────┘
              │
         p_B - p_A 가
        우연인가, 실재인가?

무작위 배정이 핵심인 이유

A/B 테스트가 단순한 전후 비교와 근본적으로 다른 이유는 무작위 배정(Randomization) 때문이다. 무작위 배정은 관측되지 않는 교란 변수(Confounding Variable)의 영향을 두 그룹 사이에 균등하게 분배한다. 이로써 그룹 간 지표 차이를 **처리 효과(Treatment Effect)**로 귀인할 수 있게 되는 것이다.

예를 들어 “주말에 새 UI를 출시하고 전환율이 올랐다”는 분석에서, 전환율 상승이 새 UI 때문인지 주말 효과 때문인지 구분할 수 없다. 무작위 배정은 이런 혼동을 원천적으로 차단한다.

💡 인과 추론의 근본 문제

한 사용자가 A와 B를 동시에 경험할 수는 없다. 이를 **인과 추론의 근본 문제(Fundamental Problem of Causal Inference)**라고 한다. 무작위 배정은 이 문제를 집단 수준에서 해결한다 — 두 그룹의 잠재 결과(Potential Outcome) 분포가 동일해지므로, 관측된 차이를 처리 효과로 해석할 수 있다.

실험 설계 5단계

A/B 테스트에서 분석은 쉽다. 어려운 것은 설계다. 잘못 설계된 실험은 아무리 정교하게 분석해도 올바른 결론을 내릴 수 없다. 실험 설계는 다음 5단계를 거친다.

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│ 1. 가설  │──▶│ 2. 지표  │──▶│ 3. 표본  │──▶│ 4. 배정  │──▶│ 5. 기간  │
│   수립   │   │   선정   │   │ 크기 결정│   │   방법   │   │   결정   │
└──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘

1단계: 가설 수립

“새 UI가 더 좋을 것 같다”는 가설이 아니다. 가설검정에서 배운 대로, 통계적으로 검증 가능한 형태로 수립해야 한다.

$H_0$ : 새 UI의 전환율은 기존 UI와 같다 ( $p_B = p_A$ )
$H_1$ : 새 UI의 전환율은 기존 UI보다 높다 ( $p_B > p_A$ )

단측 검정(One-sided)과 양측 검정(Two-sided)의 선택은 사전에 결정해야 한다. “일단 양측으로 돌려보고, 유의하면 단측으로 바꿔 보겠다”는 p-hacking의 전형적인 패턴이다.

2단계: 지표 선정

A/B 테스트의 지표는 세 종류로 나뉜다.

지표 유형	역할	예시
1차 지표(Primary)	의사결정의 기준 — 딱 하나만	구매 전환율
2차 지표(Secondary)	변화의 메커니즘 이해	장바구니 담기율, 페이지 체류 시간
가드레일 지표(Guardrail)	나빠지면 안 되는 것	이탈률, 에러율, 로딩 시간

1차 지표가 여러 개면 다중 비교 문제(Multiple Comparisons Problem)가 발생한다. 유의수준 $\alpha = 0.05$ 로 10개 지표를 검정하면, 하나 이상 거짓 양성(False Positive)이 나올 확률이 $1 - (1 - 0.05)^{10} \approx 0.40$ 이다. 1차 지표는 반드시 하나만 정해야 한다.

3단계: 표본 크기 결정 (검정력 분석)

이 단계가 가장 중요하다. 표본이 부족하면 실제로 효과가 있어도 감지하지 못한다. 표본 크기 결정에 필요한 네 가지 파라미터는 다음과 같다.

파라미터	기호	의미	일반적 값
유의수준	$\alpha$	1종 오류 허용 범위	0.05
검정력	$1 - \beta$	효과가 있을 때 감지할 확률	0.80
최소 감지 효과 크기(MDE)	$\delta$	감지하고 싶은 최소 차이	비즈니스 맥락에 따라
기저 지표	$p_0$ (또는 $\sigma$ )	현재 전환율 또는 표준편차	과거 데이터에서 추정

4단계: 무작위 배정

실무에서 가장 흔한 방식은 사용자 ID의 해시값을 기반으로 배정하는 것이다. 세션 기반 배정은 같은 사용자가 A와 B를 번갈아 경험할 수 있어 위험하다.

5단계: 실험 기간 결정

표본 크기를 일일 트래픽으로 나누면 최소 실험 기간이 나온다. 단, 요일 효과를 보정하기 위해 최소 1~2주(한 주기 이상)는 실행해야 한다.

표본 크기와 검정력

비율 검정의 표본 크기 공식

전환율 비교(비율 검정)에서 양측 검정의 그룹당 필요 표본 수는 다음과 같다.

$n = \left(\frac{z_{\alpha/2} + z_{\beta}}{\delta}\right)^2 \cdot \left[\bar{p}(1 - \bar{p}) \cdot 2\right]$

여기서 $\bar{p} = (p_A + p_B) / 2$ 는 통합 비율, $\delta = p_B - p_A$ 는 MDE다.

Python으로 검정력 분석

statsmodels의 검정력 분석 모듈을 사용하면 간단하다.

import numpy as np
from statsmodels.stats.proportion import proportion_effectsize
from statsmodels.stats.power import NormalIndPower

# 현재 전환율과 기대 전환율
p_control = 0.10       # 현재 전환율 10%
p_treatment = 0.12     # 기대 전환율 12% (MDE = 2%p)

# 효과 크기(Cohen's h) 계산
effect_size = proportion_effectsize(p_treatment, p_control)
print(f"Cohen's h: {effect_size:.4f}")
# Cohen's h: 0.0640

# 그룹당 필요 표본 수
power_analysis = NormalIndPower()
n_per_group = power_analysis.solve_power(
    effect_size=effect_size,
    alpha=0.05,
    power=0.80,
    alternative='two-sided'
)
print(f"그룹당 필요 표본 수: {n_per_group:.0f}")
print(f"총 필요 표본 수: {2 * n_per_group:.0f}")
# 그룹당 필요 표본 수: 3835
# 총 필요 표본 수: 7669

전환율 10%에서 2%p 상승을 감지하려면 그룹당 약 3,800명이 필요하다. MDE가 작을수록 필요 표본 수는 급격히 증가한다.

MDE에 따른 표본 크기 변화

MDE를 바꿔가며 필요 표본 수의 변화를 확인해보자.

import numpy as np
from statsmodels.stats.proportion import proportion_effectsize
from statsmodels.stats.power import NormalIndPower

p_control = 0.10
mde_list = [0.005, 0.01, 0.02, 0.03, 0.05]
power_analysis = NormalIndPower()

print(f"{'MDE':>8} {'p_treatment':>12} {'Cohen h':>10} {'n/group':>10}")
print("-" * 44)
for mde in mde_list:
    p_treatment = p_control + mde
    es = proportion_effectsize(p_treatment, p_control)
    n = power_analysis.solve_power(
        effect_size=es, alpha=0.05, power=0.80, alternative='two-sided'
    )
    print(f"{mde:>8.3f} {p_treatment:>12.3f} {es:>10.4f} {n:>10.0f}")
# MDE    p_treatment    Cohen h    n/group
# --------------------------------------------
#    0.005        0.105     0.0165     57756
#    0.010        0.110     0.0326     14744
#    0.020        0.120     0.0640      3835
#    0.030        0.130     0.0942      1768
#    0.050        0.150     0.1519       680

0.5%p 차이를 감지하려면 그룹당 약 58,000명이 필요하지만, 5%p 차이는 680명이면 충분하다. MDE 설정이 실험 비용에 직결되는 핵심 의사결정임을 알 수 있다.

⚠️ MDE는 비즈니스 의사결정이다

MDE를 0.1%p로 설정하면 수십만 명이 필요하고, 5%p로 설정하면 수백 명이면 된다. 핵심은 “어느 정도의 변화가 실제로 비즈니스에 의미 있는가?”를 먼저 정의하는 것이다. 이는 통계가 아니라 비즈니스 맥락에서 답해야 할 질문이다.

결과 분석: 비율 검정

전환율, 클릭률 등 이진(Binary) 지표의 A/B 테스트는 **비율 검정(Proportion Test)**으로 분석한다.

두 비율의 z-검정

A/B 테스트에서 가장 기본적인 분석이다. 대조군과 실험군의 전환율 차이가 통계적으로 유의한지 검정한다.

검정 통계량은 다음과 같다.

$Z = \frac{\hat{p}_B - \hat{p}_A}{\sqrt{\hat{p}(1 - \hat{p})\left(\frac{1}{n_A} + \frac{1}{n_B}\right)}}$

여기서 $\hat{p} = \frac{x_A + x_B}{n_A + n_B}$ 는 통합 비율(Pooled Proportion)이다. $H_0$ 하에서 $Z \sim N(0,1)$ 을 따르므로 p-value를 바로 계산할 수 있다.

import numpy as np
from statsmodels.stats.proportion import proportions_ztest, proportion_confint

np.random.seed(42)

# 실험 데이터 시뮬레이션
n_A, n_B = 4000, 4000
p_true_A, p_true_B = 0.100, 0.118

conversions_A = np.random.binomial(n_A, p_true_A)
conversions_B = np.random.binomial(n_B, p_true_B)
print(f"대조군: {conversions_A}/{n_A} = {conversions_A/n_A:.4f}")
print(f"실험군: {conversions_B}/{n_B} = {conversions_B/n_B:.4f}")
# 대조군: 385/4000 = 0.0963
# 실험군: 475/4000 = 0.1187

# 양측 비율 z-검정
count = np.array([conversions_A, conversions_B])
nobs = np.array([n_A, n_B])
z_stat, p_value = proportions_ztest(count, nobs, alternative='two-sided')
print(f"\nz-통계량: {z_stat:.4f}")
print(f"p-value: {p_value:.4f}")
# z-통계량: -3.2485
# p-value: 0.0012

# 각 그룹의 95% Wilson 신뢰구간
ci_A = proportion_confint(conversions_A, n_A, alpha=0.05, method='wilson')
ci_B = proportion_confint(conversions_B, n_B, alpha=0.05, method='wilson')
print(f"\n대조군 95% CI: [{ci_A[0]:.4f}, {ci_A[1]:.4f}]")
print(f"실험군 95% CI: [{ci_B[0]:.4f}, {ci_B[1]:.4f}]")
# 대조군 95% CI: [0.0875, 0.1058]
# 실험군 95% CI: [0.1091, 0.1291]

# 차이의 신뢰구간 (Wald)
p_A_hat = conversions_A / n_A
p_B_hat = conversions_B / n_B
diff = p_B_hat - p_A_hat
se_diff = np.sqrt(p_A_hat*(1-p_A_hat)/n_A + p_B_hat*(1-p_B_hat)/n_B)
ci_diff = (diff - 1.96*se_diff, diff + 1.96*se_diff)
print(f"\n전환율 차이: {diff:.4f} ({diff*100:.2f}%p)")
print(f"차이의 95% CI: [{ci_diff[0]:.4f}, {ci_diff[1]:.4f}]")
# 전환율 차이: 0.0225 (2.25%p)
# 차이의 95% CI: [0.0089, 0.0361]

p-value가 0.05보다 작으므로 귀무가설을 기각한다. 전환율 차이의 95% 신뢰구간이 0을 포함하지 않으므로, 신뢰구간의 관점에서도 동일한 결론이다.

Wilson 신뢰구간을 쓰는 이유

비율의 신뢰구간에는 Wald, Wilson, Clopper-Pearson 등 여러 방법이 있다. Wilson 신뢰구간은 $n\hat{p}$ 가 작을 때도 포함 확률(Coverage Probability)이 명목 수준에 가까워 실무에서 권장된다. Wald 구간은 표본이 작거나 비율이 0이나 1에 가까울 때 포함 확률이 급격히 떨어진다.

통계적 유의성 vs 실질적 유의성

p-value가 작다고 비즈니스적으로 의미 있는 것은 아니다. 표본이 수백만이면 0.01%p 차이도 통계적으로 유의할 수 있다. 반드시 **효과 크기(Effect Size)**를 함께 보고해야 한다.

기준	질문	도구
통계적 유의성	차이가 우연인가?	p-value
실질적 유의성	차이가 비즈니스에 중요한가?	효과 크기, 신뢰구간

“전환율이 통계적으로 유의하게 0.02%p 상승했다”는 보고서는 의미가 없다. 상대적 효과 크기( $\text{Lift} = \Delta p / p_A$ )와 비즈니스 임팩트를 함께 제시해야 의사결정에 쓸 수 있다.

연속형 지표 분석

전환율 같은 이진 지표가 아닌, 평균 매출(ARPU), 체류 시간 같은 연속형 지표는 t-검정과 부트스트랩으로 분석한다.

Welch t-검정

import numpy as np
from scipy import stats

np.random.seed(42)

# 사용자당 매출 (로그정규분포로 시뮬레이션 — 매출 데이터의 전형적 분포)
n_A, n_B = 2000, 2000
revenue_A = np.random.lognormal(mean=3.0, sigma=1.0, size=n_A)
revenue_B = np.random.lognormal(mean=3.05, sigma=1.0, size=n_B)  # 약 5% 상승

print(f"대조군 평균 매출: ${np.mean(revenue_A):.2f} (std: ${np.std(revenue_A, ddof=1):.2f})")
print(f"실험군 평균 매출: ${np.mean(revenue_B):.2f} (std: ${np.std(revenue_B, ddof=1):.2f})")
# 대조군 평균 매출: $34.48 (std: $46.29)
# 실험군 평균 매출: $34.96 (std: $49.15)

# Welch t-검정
t_stat, p_value = stats.ttest_ind(revenue_A, revenue_B, equal_var=False)
print(f"\nt-통계량: {t_stat:.4f}")
print(f"p-value: {p_value:.4f}")
# t-통계량: -0.3167
# p-value: 0.7515

# 평균 차이의 신뢰구간
diff = np.mean(revenue_B) - np.mean(revenue_A)
se = np.sqrt(np.var(revenue_A, ddof=1)/n_A + np.var(revenue_B, ddof=1)/n_B)
ci = (diff - 1.96*se, diff + 1.96*se)
print(f"\n평균 매출 차이: ${diff:.2f}")
print(f"차이의 95% CI: [${ci[0]:.2f}, ${ci[1]:.2f}]")
# 평균 매출 차이: $0.48
# 차이의 95% CI: [$-2.48, $3.44]

p-value가 0.05보다 크고, 신뢰구간이 0을 포함한다. 매출 차이가 통계적으로 유의하지 않다는 뜻이다. 매출 데이터는 분산이 크기 때문에(오른쪽으로 긴 꼬리), 같은 효과 크기를 감지하려면 전환율보다 훨씬 많은 표본이 필요하다.

부트스트랩 신뢰구간

매출 데이터는 정규 분포가 아니므로, 부트스트랩이 더 강건한 대안이다.

import numpy as np

np.random.seed(42)

# 위와 동일한 데이터 생성
n_A, n_B = 2000, 2000
revenue_A = np.random.lognormal(mean=3.0, sigma=1.0, size=n_A)
revenue_B = np.random.lognormal(mean=3.05, sigma=1.0, size=n_B)

# 부트스트랩으로 평균 차이의 CI 추정
n_boot = 10000
boot_diffs = np.empty(n_boot)
for i in range(n_boot):
    boot_A = np.random.choice(revenue_A, size=n_A, replace=True)
    boot_B = np.random.choice(revenue_B, size=n_B, replace=True)
    boot_diffs[i] = np.mean(boot_B) - np.mean(boot_A)

ci_lower = np.percentile(boot_diffs, 2.5)
ci_upper = np.percentile(boot_diffs, 97.5)
print(f"부트스트랩 평균 차이: ${np.mean(boot_diffs):.2f}")
print(f"부트스트랩 95% CI: [${ci_lower:.2f}, ${ci_upper:.2f}]")
# 부트스트랩 평균 차이: $0.47
# 부트스트랩 95% CI: [$-2.46, $3.46]

# 부트스트랩 p-value (차이가 0 이하인 비율)
boot_p = np.mean(boot_diffs <= 0)
print(f"부트스트랩 p-value (단측): {boot_p:.4f}")
# 부트스트랩 p-value (단측): 0.3808

부트스트랩 신뢰구간도 0을 포함하므로, t-검정과 동일한 결론이다. 분포 가정에 의존하지 않으면서도 결론이 일치하면 분석 결과에 대한 신뢰도가 한층 높아진다.

💡 연속형 지표 분석 전략

매출 같은 분산이 큰 지표를 1차 지표로 쓰면 필요 표본 수가 폭증한다. 실무에서는 전환율(이진)을 1차 지표로, 매출(연속)을 2차 지표로 설정하는 것이 일반적이다. 분산 축소 기법(CUPED, 로그 변환, 아웃라이어 캐핑)을 활용하면 필요 표본 수를 줄일 수 있다.

조기 종료의 함정: Peeking Problem

왜 중간에 결과를 보면 안 되는가

실험 도중 p-value를 확인하고 유의하면 일찍 종료하는 것 — 매우 자연스러운 행동이지만 통계적으로 심각한 오류를 낳는다. 이를 피킹 문제(Peeking Problem) 또는 **선택적 종료(Optional Stopping)**라고 한다.

핵심 원리는 이렇다. 효과가 전혀 없어도( $H_0$ 이 참), 충분히 오래 반복 확인하면 언젠가는 p-value < 0.05인 시점이 나타난다. 이것은 확률론의 필연적 결과다.

import numpy as np
from scipy import stats

np.random.seed(42)

# 시뮬레이션: 효과 없는 A/B 테스트에서 매일 p-value를 확인
n_per_day = 100
n_days = 50
false_positive_found = False

data_A = []
data_B = []

print("일자  |  누적 n  |  p_A    |  p_B    | p-value  | 유의?")
print("-" * 62)
for day in range(1, n_days + 1):
    # 두 그룹 모두 동일한 전환율 10% (효과 없음)
    data_A.extend(np.random.binomial(1, 0.10, n_per_day))
    data_B.extend(np.random.binomial(1, 0.10, n_per_day))

    n_curr = day * n_per_day
    p_A = np.mean(data_A)
    p_B = np.mean(data_B)

    # 풀링된 비율로 z-검정
    pooled_p = (sum(data_A) + sum(data_B)) / (2 * n_curr)
    if pooled_p == 0 or pooled_p == 1:
        continue
    se = np.sqrt(2 * pooled_p * (1 - pooled_p) / n_curr)
    z = (p_B - p_A) / se
    p_value = 2 * (1 - stats.norm.cdf(abs(z)))

    sig = "***" if p_value < 0.05 else ""
    if day <= 10 or day % 10 == 0 or p_value < 0.05:
        print(f"  {day:>3}  |  {n_curr:>5}  | {p_A:.4f} | {p_B:.4f} | {p_value:.4f}  | {sig}")
    if p_value < 0.05 and not false_positive_found:
        false_positive_found = True
        fp_day = day

if false_positive_found:
    print(f"\n=> 효과가 없는데도 {fp_day}일차에 '유의한' 결과가 나타났다!")
else:
    print(f"\n=> 50일 동안 거짓 양성이 나타나지 않았다.")

이 시뮬레이션에서 두 그룹의 전환율은 동일(10%)하다. 효과가 없는데도 반복 확인하면 거짓 양성이 등장할 수 있다. 매일 확인하면 50일 기준으로 거짓 양성 확률이 5%보다 훨씬 높아진다.

거짓 양성률의 누적

반복 확인 시 실제 1종 오류율을 시뮬레이션으로 확인해보자.

import numpy as np
from scipy import stats

np.random.seed(42)

n_simulations = 5000
n_per_day = 200
n_days = 30
check_days = [7, 14, 21, 30]  # p-value를 확인하는 시점

# 전략 1: 마지막 날만 확인
# 전략 2: 매주 확인 (4번), 하나라도 유의하면 종료
false_positive_fixed = 0
false_positive_peeking = 0

for sim in range(n_simulations):
    data_A = np.random.binomial(1, 0.10, n_per_day * n_days)
    data_B = np.random.binomial(1, 0.10, n_per_day * n_days)

    # 전략 1: 마지막 날만 확인
    n_total = n_per_day * n_days
    p_A = np.mean(data_A)
    p_B = np.mean(data_B)
    pooled = (np.sum(data_A) + np.sum(data_B)) / (2 * n_total)
    if pooled > 0 and pooled < 1:
        se = np.sqrt(2 * pooled * (1 - pooled) / n_total)
        z = (p_B - p_A) / se
        p_val = 2 * (1 - stats.norm.cdf(abs(z)))
        if p_val < 0.05:
            false_positive_fixed += 1

    # 전략 2: 매주 확인
    peeking_positive = False
    for d in check_days:
        n_curr = n_per_day * d
        p_A_d = np.mean(data_A[:n_curr])
        p_B_d = np.mean(data_B[:n_curr])
        pooled_d = (np.sum(data_A[:n_curr]) + np.sum(data_B[:n_curr])) / (2 * n_curr)
        if pooled_d > 0 and pooled_d < 1:
            se_d = np.sqrt(2 * pooled_d * (1 - pooled_d) / n_curr)
            z_d = (p_B_d - p_A_d) / se_d
            p_val_d = 2 * (1 - stats.norm.cdf(abs(z_d)))
            if p_val_d < 0.05:
                peeking_positive = True
                break
    if peeking_positive:
        false_positive_peeking += 1

fpr_fixed = false_positive_fixed / n_simulations
fpr_peeking = false_positive_peeking / n_simulations
print(f"마지막 날만 확인 — 거짓 양성률: {fpr_fixed:.4f} ({fpr_fixed*100:.1f}%)")
print(f"매주 4회 확인   — 거짓 양성률: {fpr_peeking:.4f} ({fpr_peeking*100:.1f}%)")
print(f"거짓 양성률 증가 배수: {fpr_peeking/fpr_fixed:.1f}x")
# 마지막 날만 확인 — 거짓 양성률: 0.0442 (4.4%)
# 매주 4회 확인   — 거짓 양성률: 0.1242 (12.4%)
# 거짓 양성률 증가 배수: 2.8x

4번만 중간 확인해도 거짓 양성률이 약 3배로 뛴다. 매일 확인하면 이 수치는 더 올라간다. “유의하면 멈추겠다”는 전략은 유의수준 $\alpha$ 를 무력화시킨다.

순차 검정: 올바른 조기 종료

그렇다면 중간 점검은 원천적으로 불가능한가? 그렇지 않다. **순차 검정(Sequential Testing)**은 다중 확인을 고려하여 유의 수준을 조정하는 방법이다.

대표적인 방법이 O’Brien-Fleming 경계다. 초기에는 매우 엄격한 기준을 적용하고, 실험 후반부로 갈수록 일반적인 수준에 가까워진다.

import numpy as np
from scipy import stats

# O'Brien-Fleming 경계 근사 (4회 중간 분석)
n_looks = 4
alpha = 0.05

# O'Brien-Fleming: 각 분석 시점에서의 z-경계
# 정보 분율 t_k = k/K에서 경계 z_k ≈ z_{α/2} / sqrt(t_k)
z_alpha = stats.norm.ppf(1 - alpha/2)
print(f"고정 표본 임계값: z = {z_alpha:.3f} (p < {alpha})")
print(f"\nO'Brien-Fleming 경계 (4회 분석):")
print(f"{'분석 시점':>10} {'정보 분율':>10} {'z-경계':>10} {'p-경계':>12}")
print("-" * 46)
for k in range(1, n_looks + 1):
    info_frac = k / n_looks
    z_boundary = z_alpha / np.sqrt(info_frac)
    p_boundary = 2 * (1 - stats.norm.cdf(z_boundary))
    print(f"  {k}/{n_looks}차{'':<4} {info_frac:>10.2f} {z_boundary:>10.3f} {p_boundary:>12.6f}")
# 고정 표본 임계값: z = 1.960 (p < 0.05)
#
# O'Brien-Fleming 경계 (4회 분석):
#  분석 시점  정보 분율      z-경계       p-경계
# ----------------------------------------------
#   1/4차          0.25      3.920     0.000089
#   2/4차          0.50      2.772     0.005575
#   3/4차          0.75      2.263     0.023625
#   4/4차          1.00      1.960     0.050000

1차 중간 분석에서는 p < 0.0001 수준이어야 종료할 수 있고, 최종 분석에서는 일반적인 0.05를 사용한다. 이렇게 하면 전체 실험의 1종 오류율을 $\alpha = 0.05$ 이하로 유지하면서도 조기 종료가 가능하다.

⚠️ 순차 검정의 비용

순차 검정은 공짜가 아니다. 중간 분석 횟수가 늘어날수록 최종 분석의 임계값이 높아지거나 필요 표본 수가 증가한다 (보통 2~5%). 하지만 명확한 효과가 있을 때 일찍 종료할 수 있으므로, 기대 표본 크기는 오히려 줄어드는 경우가 많다.

실전 체크리스트

A/B 테스트의 전 과정을 체크리스트로 정리한다. 실험 전/중/후 각 단계에서 놓치기 쉬운 항목을 담았다.

단계	체크 항목	확인
실험 전	1차 지표를 하나만 정했는가?	☐
	가설(단측/양측)을 사전에 결정했는가?	☐
	검정력 분석으로 필요 표본 크기를 산출했는가?	☐
	MDE가 비즈니스적으로 의미 있는 크기인가?	☐
	무작위 배정 단위(사용자/세션)를 정했는가?	☐
	최소 실험 기간이 1주일 이상인가?	☐
실험 중	A/A 테스트로 시스템 검증을 했는가?	☐
	중간에 p-value를 확인하고 있지 않은가?	☐
	(순차 검정 사용 시) 사전에 정한 경계를 따르고 있는가?	☐
	가드레일 지표에 이상이 없는가?	☐
실험 후	통계적 유의성과 실질적 유의성을 모두 보고했는가?	☐
	효과 크기와 신뢰구간을 제시했는가?	☐
	사후 세그먼트 분석에 다중 비교 보정을 적용했는가?	☐
	노벨티 효과/학습 효과를 확인했는가?	☐

흔한 실수와 함정

1. 표본 크기 부족

검정력 분석 없이 “일주일 정도면 되겠지”로 실험하는 경우. 표본이 부족하면 실제 효과가 있어도 감지하지 못한다(2종 오류). 효과가 없다는 결론이 아니라, 판단을 내릴 수 없는 상태인 것이다.

2. Peeking (선택적 종료)

위에서 자세히 다뤘다. “매일 대시보드 확인”이 얼마나 위험한지, 그리고 순차 검정이라는 대안이 있다는 것을 기억하자.

3. 세그먼트 남용 (Texas Sharpshooter Fallacy)

전체 결과가 유의하지 않으면 하위 그룹을 쪼개서 유의한 세그먼트를 찾는 행위. 이는 텍사스 명사수 오류 — 벽에 먼저 총을 쏘고 나서 구멍 주위에 과녁을 그리는 것과 같다. 20개 세그먼트를 검정하면 하나쯤은 우연히 유의하게 나온다. 사후 세그먼트 분석은 가설 생성 목적으로만 사용하고, Bonferroni 보정을 적용해야 한다.

4. 노벨티 효과 무시

새 UI에 대한 호기심으로 초기에 참여도가 높아지는 현상. 시간이 지나면 원래 수준으로 돌아간다. 이를 무시하고 초기 결과만 보면 효과를 과대추정한다. 실험 초반 1~2주 데이터를 제외하거나, 시간 경과에 따른 효과 추이를 확인해야 한다.

5. 네트워크 효과 무시

소셜 네트워크 서비스에서 A 그룹 사용자의 행동이 B 그룹 사용자에게 영향을 미치는 경우. 이러면 SUTVA(Stable Unit Treatment Value Assumption)가 위반되어 처리 효과 추정이 편향된다. 클러스터 무작위 배정(Cluster Randomization)이 대안이다.

마치며

A/B 테스트는 인과 추론을 실무에 적용하는 가장 강력한 도구다. 그 핵심은 무작위 배정에 있으며, 통계적 분석은 가설검정, 신뢰구간, 부트스트랩의 직접적인 응용이다.

그러나 A/B 테스트도 만능이 아니다. 표본 크기 부족, Peeking, 세그먼트 남용, 노벨티 효과 — 이런 함정에 빠지면 오히려 데이터 없이 직감으로 결정하는 것보다 더 위험해진다. “데이터에 기반했다”는 확신이 잘못된 결정을 정당화하기 때문이다.

효과 크기의 추정은 결국 점추정의 문제이고, A/B 테스트 결과에 부트스트랩 CI를 씌우면 분포 가정 없이도 불확실성을 정량화할 수 있다. 통계의 도구들이 하나의 실험 프레임워크 안에서 유기적으로 연결되는 것이다.

다음 글에서는 A/B 테스트를 포함해 통계적 분석 전반에서 빠지기 쉬운 함정들을 다룬다. 심슨의 역설, 다중 비교 문제, 생존자 편향 — 통계를 잘못 쓰면 오히려 더 위험한 이유를 파헤친다.

참고자료

Kohavi, R., Tang, D., & Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.
Deng, A., et al. (2013). “Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data.” WSDM 2013.
Johari, R., et al. (2017). “Peeking at A/B Tests: Why It Matters, and What to Do About It.” KDD 2017.
Statsmodels Documentation: Proportion Tests
Evan Miller: Sample Size Calculator

표본 추출과 편향(Sampling and Bias): 240만 명이 틀리고 5만 명이 맞은 이유

Donhyeok Kang — Tue, 24 Feb 2026 00:00:00 GMT

이전 글에서 EDA와 기술통계를 다루며, 데이터를 요약하고 시각화하는 기본기를 익혔다. 그 글의 마지막에 던진 질문이 하나 있다. “이 데이터가 모집단을 대표하는가?” 오늘은 바로 그 질문에 답한다.

1936년 미국 대선. 시사 잡지 Literary Digest는 약 240만 명에게 설문을 보내 공화당 후보 Alf Landon의 압승을 예측했다. 역사상 가장 거대한 규모의 여론조사였다. 결과? Franklin Roosevelt가 46개 주에서 승리하며 역대급 압승을 거뒀다. 반면, 신생 여론조사 기관이었던 George Gallup은 고작 50,000명의 표본으로 Roosevelt의 승리를 정확히 맞혔다.

240만 대 5만. 왜 숫자가 48배나 많은 쪽이 틀렸을까? Literary Digest는 자사 구독자, 전화번호부, 자동차 등록부에서 설문 대상을 뽑았다. 1936년, 대공황 한복판이다. 전화와 자동차가 있는 사람은 상대적으로 부유한 계층이었고, 이들은 공화당을 지지할 확률이 높았다. 표본이 모집단을 대표하지 못한 것이다.

이 사건이 가르쳐주는 교훈은 명확하다. 표본의 크기보다 표본의 대표성이 중요하다.

모집단과 표본: 전수조사가 불가능한 이유

기본 용어 정리

용어	정의	예시
모집단(Population)	관심 대상 전체의 집합	한국의 성인 전체
표본(Sample)	모집단에서 추출한 부분집합	설문에 응답한 1,000명
모수(Parameter)	모집단의 특성을 나타내는 고정 상수	모집단 평균 $\mu$ , 비율 $p$
통계량(Statistic)	표본에서 계산한 값	표본 평균 $\bar{X}$ , 표본 비율 $\hat{p}$

모집단 전체를 조사하는 것을 **전수조사(Census)**라 한다. 인구조사가 대표적이다. 그런데 왜 항상 전수조사를 하지 않을까?

비용과 시간: 한국 인구주택총조사는 5년에 한 번, 수천억 원의 예산이 투입된다.
파괴 검사: 전구의 수명을 테스트하려면 전구를 켜서 꺼질 때까지 기다려야 한다. 전수조사하면 팔 전구가 남지 않는다.
무한 모집단: “이 약을 복용할 미래의 모든 환자”는 아직 존재하지도 않는다.

그래서 표본을 추출한다. 핵심은 표본이 모집단을 잘 대표해야 한다는 것이다. 점추정에서 배웠던 비편향성(Unbiasedness)을 기억하는가? 추정량이 비편향이려면, 그 전제에 “표본이 모집단으로부터 적절히 추출되었다”는 가정이 깔려 있다.

확률적 표본 추출법(Probability Sampling)

확률적 표본 추출에서는 모집단의 모든 원소가 표본에 포함될 확률이 알려져 있고, 0보다 크다. 이 조건을 만족해야 통계적 추론이 정당화된다.

비교표

방법	설명	장점	단점	적합한 상황
단순 무작위 추출(SRS)	모든 원소가 동일한 확률로 선택	이론이 단순, 편향 없음	표본 프레임 필요, 희귀 하위그룹 누락 가능	모집단이 균질할 때
층화 추출(Stratified)	모집단을 층(strata)으로 나눈 뒤 각 층에서 독립 추출	층 내 변동 줄임, 소수 그룹 보장	층 구분 기준 필요	하위 그룹 분석이 중요할 때
군집 추출(Cluster)	모집단을 군집으로 나누고 군집 단위로 추출, 선택된 군집은 전수조사	표본 프레임 구축 비용 절감	군집 간 유사하면 효율 떨어짐	지리적으로 분산된 모집단
체계적 추출(Systematic)	첫 번째 원소만 무작위, 이후 $k$ 번째 간격으로 추출	구현이 쉬움	주기성이 있으면 편향 발생	리스트가 무작위 순서일 때

단순 무작위 추출 (Simple Random Sampling)

가장 기본이 되는 방법이다. 크기 $N$ 인 모집단에서 크기 $n$ 인 표본을 뽑을 때, 가능한 모든 $\binom{N}{n}$ 조합이 동일한 확률을 갖는다.

import numpy as np

np.random.seed(42)

# 모집단: 10,000명의 연봉 (단위: 만원) — 로그정규분포
population = np.random.lognormal(mean=8.0, sigma=0.5, size=10_000)
pop_mean = np.mean(population)
print(f"모집단 평균: {pop_mean:.0f}만원")

# 단순 무작위 추출: 100명
sample_srs = np.random.choice(population, size=100, replace=False)
print(f"SRS 표본 평균: {np.mean(sample_srs):.0f}만원")
# 모집단 평균: 3378만원
# SRS 표본 평균: 3678만원

단순 무작위 추출은 기댓값 수준에서 모집단 평균을 편향 없이 추정한다. 하지만 매번 추출할 때마다 표본 평균은 달라진다 — 이 변동성이 바로 표본 분포에서 다룬 표준오차(Standard Error)다.

층화 추출 (Stratified Sampling)

모집단을 성별, 연령대, 지역 같은 기준으로 나누고, 각 층에서 독립적으로 표본을 추출한다. 예를 들어 전체 직원 10,000명 중 관리직 2,000명, 실무직 8,000명이라면, 관리직에서 20명, 실무직에서 80명을 따로 뽑는 식이다.

층화 추출의 이론적 장점은 명확하다. 층 내 분산이 작을수록 전체 추정량의 분산이 줄어든다. 수식으로 표현하면:

$\text{Var}(\bar{X}_{str}) = \sum_{h=1}^{H} \left(\frac{N_h}{N}\right)^2 \frac{\sigma_h^2}{n_h}$

여기서 $H$ 는 층의 수, $N_h$ 는 $h$ 번째 층의 모집단 크기, $\sigma_h^2$ 는 층 내 분산, $n_h$ 는 층별 표본 크기다.

비확률적 표본 추출법(Non-Probability Sampling)

비확률적 방법에서는 각 원소가 선택될 확률을 알 수 없다. 통계적 추론의 전제가 무너지므로 결과를 모집단으로 일반화하기 어렵다. 그럼에도 현실에서는 빈번히 사용된다.

방법	설명	위험
편의 추출(Convenience)	접근하기 쉬운 대상을 표본으로 선택	모집단의 특정 부분만 반영
판단 추출(Purposive)	연구자의 판단으로 “대표적인” 대상을 선택	연구자의 편견이 개입
눈덩이 추출(Snowball)	기존 응답자가 다음 응답자를 추천	동질적 네트워크로 편향

주의: 온라인 설문의 함정

웹사이트 팝업 설문, SNS 투표, 앱 내 만족도 조사 — 이런 데이터는 거의 예외 없이 편의 표본이다. 응답자는 “해당 웹사이트를 방문한 사람” 또는 “해당 SNS를 사용하는 사람”으로 한정된다. 여기서 얻은 결론을 “전체 사용자” 또는 “일반 대중”으로 일반화하면 Literary Digest의 실수를 반복하게 된다.

편향의 유형: 데이터가 거짓말하는 방법들

표본이 모집단을 체계적으로 잘못 반영할 때 **편향(Bias)**이 발생한다. 편향은 표본 크기를 아무리 늘려도 사라지지 않는다. 이것이 무작위 오차(random error)와의 결정적 차이다.

선택 편향 (Selection Bias)

표본이 모집단의 특정 부분집합에 치우쳐 추출될 때 발생한다. Literary Digest 사례가 전형적이다.

현대의 예시도 넘친다. 병원 기반 연구에서 “특정 질병의 위험 요인”을 분석한다고 하자. 병원에 온 환자만 분석 대상이므로, 경증 환자(병원에 오지 않는)와 중증 환자(이미 사망한)가 빠진다. 이것을 **버크슨 편향(Berkson’s Bias)**이라 부른다.

생존자 편향 (Survivorship Bias)

성공하거나 “살아남은” 사례만 관측 가능하고, 실패하거나 탈락한 사례는 보이지 않을 때 발생한다.

“하버드 중퇴자 중에 억만장자가 많다” → 하버드를 중퇴한 수십만 명 중 빌 게이츠, 저커버그만 보인다.
“자수성가 CEO들이 공통으로 새벽 5시에 일어난다” → 새벽 5시에 일어났지만 실패한 사람은 기사가 되지 않는다.
뮤추얼 펀드의 평균 수익률이 실제보다 높게 보고된다 → 수익률이 나빴던 펀드는 폐쇄되어 데이터에서 사라진다.

응답 편향 (Response Bias)

응답자가 실제와 다르게 답할 때 발생한다. 민감한 주제(소득, 음주량, 투표 성향)에서 특히 심하다. “일주일에 술을 몇 잔 마시는가?”에 대한 설문 응답을 합산하면 실제 주류 판매량의 40~60%밖에 되지 않는다는 연구가 여러 차례 보고되었다.

자기선택 편향 (Self-Selection Bias)

참여 여부를 대상자 본인이 결정할 때 발생한다. 제품 리뷰를 생각해보라. 매우 만족하거나 매우 불만족한 사람이 리뷰를 남길 확률이 높고, 보통인 사람은 아무 말도 하지 않는다. 결과적으로 리뷰 데이터의 분포는 실제 만족도 분포와 다른 양극화된 형태를 띤다.

편향 유형	핵심 메커니즘	대표 사례
선택 편향	표본이 모집단의 부분집합	Literary Digest (1936)
생존자 편향	탈락/실패 데이터 누락	펀드 수익률, 성공 기업 분석
응답 편향	실제와 다른 응답	음주량 설문
자기선택 편향	참여 의사 결정이 결과와 상관	온라인 리뷰

에이브러햄 왈드와 비행기 장갑: 생존자 편향의 교과서

제2차 세계대전 중, 미 해군은 통계학자 에이브러햄 왈드(Abraham Wald)에게 한 가지 문제를 의뢰했다. 귀환한 폭격기의 피탄 분포를 분석해서 어디에 장갑을 보강해야 하는지 결정해달라는 것이었다.

군 관계자들의 직관은 단순했다. 총알 구멍이 많이 뚫린 부분에 장갑을 대라. 동체와 날개에 구멍이 집중되어 있으니, 그쪽을 보강하자는 논리다.

왈드의 답은 정반대였다. “총알 구멍이 없는 부분, 즉 엔진 주변에 장갑을 보강해야 한다.”

왜? 분석 대상인 비행기들은 귀환한 비행기다. 동체에 총을 맞고도 돌아올 수 있었다는 뜻이다. 엔진에 총을 맞은 비행기는 돌아오지 못했다 — 그래서 데이터에 없는 것이다. 관측된 데이터에서 “빠진 것이 무엇인가?”를 묻는 것이 생존자 편향을 간파하는 핵심이다.

실무에서의 교훈

머신러닝에서도 동일한 문제가 발생한다. 이탈(Churn) 예측 모델을 만들 때, 학습 데이터에는 “현재 남아 있는 고객”과 “이탈한 고객” 중 이탈 직전 데이터가 기록된 고객만 포함된다. 가입 즉시 이탈한 고객이나, 데이터 수집 시스템이 구축되기 전에 떠난 고객은 빠져 있다. 이 누락을 인지하지 못하면 모델의 예측 성능이 실제보다 과대평가된다.

표본 크기 결정: 얼마나 뽑아야 충분한가?

표본이 편향 없이 추출되었다 해도, 표본 크기가 너무 작으면 추정의 정밀도가 떨어진다. 중심극한정리(CLT)에 의하면, 표본 평균의 표준오차는 다음과 같다:

$\text{SE}(\bar{X}) = \frac{\sigma}{\sqrt{n}}$

표준오차는 $\sqrt{n}$ 에 반비례한다. 정밀도를 2배로 높이려면 표본 크기를 4배로 늘려야 한다.

오차한계와 필요 표본 크기

95% 신뢰구간의 오차한계(Margin of Error, MOE)는:

$\text{MOE} = z_{\alpha/2} \cdot \frac{\sigma}{\sqrt{n}}$

이를 $n$ 에 대해 풀면:

$n = \left(\frac{z_{\alpha/2} \cdot \sigma}{\text{MOE}}\right)^2$

비율 추정의 경우, $\sigma$ 를 $\sqrt{p(1-p)}$ 로 대체한다. $p$ 를 모르면 분산이 최대인 $p = 0.5$ 를 사용하는 것이 보수적 접근이다:

$n = \left(\frac{z_{\alpha/2}}{2 \cdot \text{MOE}}\right)^2$

Python으로 필요 표본 크기 계산

import numpy as np
from scipy import stats

def sample_size_mean(sigma, moe, confidence=0.95):
    """모평균 추정을 위한 최소 표본 크기"""
    z = stats.norm.ppf(1 - (1 - confidence) / 2)
    n = (z * sigma / moe) ** 2
    return int(np.ceil(n))

def sample_size_proportion(moe, confidence=0.95, p=0.5):
    """모비율 추정을 위한 최소 표본 크기 (보수적: p=0.5)"""
    z = stats.norm.ppf(1 - (1 - confidence) / 2)
    n = (z ** 2 * p * (1 - p)) / moe ** 2
    return int(np.ceil(n))

# 예제 1: 평균 연봉 추정, 표준편차 500만원, 오차한계 100만원
n1 = sample_size_mean(sigma=500, moe=100)
print(f"평균 추정 필요 표본 크기: {n1}명")

# 예제 2: 지지율 추정, 오차한계 ±3%p
n2 = sample_size_proportion(moe=0.03)
print(f"비율 추정 필요 표본 크기: {n2}명")

# 예제 3: 오차한계에 따른 필요 표본 크기 변화
print("\n오차한계(MOE) vs 필요 표본 크기 (비율 추정, 95% 신뢰수준):")
for moe_pct in [5, 3, 2, 1, 0.5]:
    n = sample_size_proportion(moe=moe_pct / 100)
    print(f"  MOE = ±{moe_pct}%p → n = {n:,}")
# 평균 추정 필요 표본 크기: 97명
# 비율 추정 필요 표본 크기: 1068명
#
# 오차한계(MOE) vs 필요 표본 크기 (비율 추정, 95% 신뢰수준):
#   MOE = ±5%p → n = 385
#   MOE = ±3%p → n = 1,068
#   MOE = ±2%p → n = 2,401
#   MOE = ±1%p → n = 9,604
#   MOE = ±0.5%p → n = 38,415

오차한계를 절반으로 줄이면 필요 표본 크기는 4배가 된다. 이 비선형 관계를 이해하면 “표본을 더 모으자”는 요구에 현실적인 비용을 제시할 수 있다.

Python 실습: 편향된 표본 vs 무작위 표본

이론으로 배운 내용을 시뮬레이션으로 확인하자. 모집단에서 편향된 추출과 무작위 추출을 반복하고, 추정 결과가 어떻게 달라지는지 시각화한다.

import numpy as np
import matplotlib.pyplot as plt
import matplotlib

matplotlib.use('Agg')
plt.rcParams['font.size'] = 11

np.random.seed(42)

# --- 모집단 생성 ---
# 연봉 분포: 로그정규분포 (오른쪽 꼬리가 긴 현실적 분포)
N = 100_000
population = np.random.lognormal(mean=8.0, sigma=0.6, size=N)
pop_mean = np.mean(population)

# --- 시뮬레이션: 1,000번 반복 ---
n_sim = 1000
n_sample = 200

means_srs = []      # 단순 무작위 추출
means_biased = []   # 편향된 추출 (상위 50%에서만 추출)

median_pop = np.median(population)

for _ in range(n_sim):
    # 무작위 추출
    idx_srs = np.random.choice(N, size=n_sample, replace=False)
    means_srs.append(np.mean(population[idx_srs]))

    # 편향된 추출: 중앙값 이상인 사람에서만 추출 (부유층 편향)
    upper_half = population[population >= median_pop]
    idx_biased = np.random.choice(len(upper_half), size=n_sample, replace=False)
    means_biased.append(np.mean(upper_half[idx_biased]))

means_srs = np.array(means_srs)
means_biased = np.array(means_biased)

# --- 시각화 ---
fig, axes = plt.subplots(1, 2, figsize=(12, 5))

# 왼쪽: 표본 평균의 분포
axes[0].hist(means_srs, bins=40, alpha=0.7, color='#3182f6', label='Random Sample', density=True)
axes[0].hist(means_biased, bins=40, alpha=0.7, color='#e53e3e', label='Biased Sample', density=True)
axes[0].axvline(pop_mean, color='black', linewidth=2, linestyle='--', label=f'Pop. Mean = {pop_mean:.0f}')
axes[0].set_xlabel('Sample Mean')
axes[0].set_ylabel('Density')
axes[0].set_title('Distribution of Sample Means (n=200, 1000 simulations)')
axes[0].legend(fontsize=9)

# 오른쪽: 추정 오차 비교
errors_srs = means_srs - pop_mean
errors_biased = means_biased - pop_mean

bp = axes[1].boxplot([errors_srs, errors_biased],
                     tick_labels=['Random', 'Biased'],
                     patch_artist=True)
bp['boxes'][0].set_facecolor('#3182f6')
bp['boxes'][0].set_alpha(0.5)
bp['boxes'][1].set_facecolor('#e53e3e')
bp['boxes'][1].set_alpha(0.5)
axes[1].axhline(0, color='black', linewidth=1, linestyle='--')
axes[1].set_ylabel('Estimation Error')
axes[1].set_title('Estimation Error: Random vs Biased')

plt.tight_layout()
plt.savefig('/Users/dony/projects/donmain/contents/stats/sampling-and-bias/thumbnail.png',
            dpi=150, bbox_inches='tight')
plt.close('all')

# --- 수치 비교 ---
print(f"모집단 평균: {pop_mean:.0f}")
print(f"\n무작위 추출:")
print(f"  표본 평균의 평균: {np.mean(means_srs):.0f}")
print(f"  편향(Bias): {np.mean(means_srs) - pop_mean:.1f}")
print(f"  표준오차(SE): {np.std(means_srs, ddof=1):.1f}")
print(f"\n편향된 추출 (상위 50%에서만):")
print(f"  표본 평균의 평균: {np.mean(means_biased):.0f}")
print(f"  편향(Bias): {np.mean(means_biased) - pop_mean:.1f}")
print(f"  표준오차(SE): {np.std(means_biased, ddof=1):.1f}")
# 모집단 평균: 3572
#
# 무작위 추출:
#   표본 평균의 평균: 3575
#   편향(Bias): 3.5
#   표준오차(SE): 166.9
#
# 편향된 추출 (상위 50%에서만):
#   표본 평균의 평균: 5188
#   편향(Bias): 1616.4
#   표준오차(SE): 160.5

결과를 보면 무작위 추출의 편향은 거의 0인 반면, 상위 50%에서만 추출한 경우 편향이 약 1,600이나 된다. 표본 크기를 200에서 2,000으로 늘려도 이 편향은 줄어들지 않는다. 편향은 표본 크기의 문제가 아니라 추출 방법의 문제이기 때문이다.

이것이 1936년 Literary Digest의 실수와 정확히 같은 구조다. 표준오차(정밀도)는 표본을 늘리면 줄어들지만, 편향(정확도)은 추출 방법 자체를 고치지 않는 한 사라지지 않는다.

실무 체크리스트: 표본 설계 시 반드시 확인할 것

표본 기반 분석을 시작하기 전에 다음 항목을 점검하라.

표본 프레임(Sampling Frame)은 모집단을 완전히 커버하는가? 전화번호부는 전화 없는 사람을 놓치고, 이메일 목록은 이메일을 안 쓰는 사람을 놓친다.
무응답(Non-response)은 무작위인가? 바쁜 사람, 불만 있는 사람, 특정 집단이 체계적으로 응답을 거부하면 편향이 생긴다.
생존자 편향이 숨어 있지 않은가? “현재 데이터에 없는 것”이 무엇인지 반드시 질문하라.
표본 크기는 원하는 정밀도를 달성하기에 충분한가? 위에서 다룬 공식으로 사전에 계산하라.
측정 도구에 응답 편향이 있지 않은가? 설문 문항의 유도성, 사회적 바람직성(Social Desirability) 효과를 점검하라.

부트스트랩과의 연결

부트스트랩은 이미 확보한 표본에서 복원 추출을 반복하여 통계량의 분포를 근사하는 기법이다. 부트스트랩이 유효하려면 원본 표본이 모집단을 잘 대표해야 한다는 전제가 필요하다. 편향된 표본에 부트스트랩을 적용하면, 편향이 “증폭”되지는 않지만 “교정”되지도 않는다. 쓰레기가 들어가면 쓰레기가 나온다(Garbage In, Garbage Out).

마치며

이 글에서 다룬 핵심을 정리하면 세 가지다.

표본의 대표성이 크기보다 중요하다. 편향된 240만 명보다 무작위 5만 명이 낫다.
편향은 표본 크기를 늘려도 사라지지 않는다. 추출 방법 자체를 바꿔야 한다.
데이터에서 “보이지 않는 것”을 의식적으로 찾아야 한다. 생존자 편향은 가장 교묘하고 가장 흔한 함정이다.

올바른 표본을 확보했다면, 이제 그 표본 위에서 실험을 설계할 차례다. 다음 글에서는 인과관계를 검증하기 위한 실험 설계의 핵심, A/B 테스트를 다룬다. 무작위 배정(Randomization)이 왜 편향을 제거하는 가장 강력한 도구인지, 그리고 표본 크기 결정이 실험 설계에서 어떤 역할을 하는지 살펴보겠다.

참고자료

Freedman, D., Pisani, R., & Purves, R. (2007). Statistics (4th ed.). W.W. Norton. — 표본 추출과 편향에 대한 직관적 설명.
Mangel, M. & Samaniego, F. J. (1984). Abraham Wald’s Work on Aircraft Survivability. Journal of the American Statistical Association, 79(386), 259-267.
Cochran, W. G. (1977). Sampling Techniques (3rd ed.). Wiley. — 확률적 표본 추출 이론의 고전.
Bethlehem, J. (2010). Selection Bias in Web Surveys. International Statistical Review, 78(2), 161-188.
Squire, P. (1988). Why the 1936 Literary Digest Poll Failed. Public Opinion Quarterly, 52(1), 125-133.

기술통계와 EDA(Descriptive Statistics & EDA): 데이터를 모델에 넣기 전에 할 일

Donhyeok Kang — Mon, 23 Feb 2026 00:00:00 GMT

14편에 걸쳐 확률의 공리부터 베이지안 추론까지, 통계적 추론의 이론 체계를 쌓아왔다. 이제 도구 상자는 꽤 두둑하다. 그런데 현업에서 데이터 파일을 처음 건네받았을 때, 가장 먼저 하는 일이 MLE를 돌리거나 가설검정을 설계하는 것일까? 아니다. 데이터를 들여다보는 것이다. 열은 몇 개인지, 결측치는 얼마나 되는지, 분포가 어떤 모양인지 — 이 탐색 과정을 건너뛰고 모델을 세우는 건, 지도를 보지 않고 등산을 시작하는 것과 다름없다.

이 글은 stats-applied 시리즈의 첫 번째 편으로, **기술통계(Descriptive Statistics)**와 **탐색적 데이터 분석(Exploratory Data Analysis, EDA)**의 핵심 도구를 체계적으로 정리한다.

EDA란 무엇인가

Tukey의 EDA 철학

**탐색적 데이터 분석(EDA)**이라는 용어를 처음 체계화한 사람은 통계학자 John Tukey다. 1977년 저서 Exploratory Data Analysis에서 그는 “데이터가 무엇을 말하고 있는지 경청하라”고 강조했다. 가설을 세우고 검증하는 확인적 분석(Confirmatory Data Analysis, CDA) — 우리가 가설검정에서 다뤘던 바로 그것 — 과 대비되는 접근이다.

구분	확인적 분석(CDA)	탐색적 분석(EDA)
목적	사전 가설의 검증	패턴 발견, 가설 생성
방법	통계 검정, 신뢰구간	시각화, 기술통계, 요약
순서	가설 → 데이터 수집 → 검정	데이터 관찰 → 패턴 발견 → 가설 제안
비유	재판(유죄/무죄 판결)	수사(단서 수집, 용의자 탐색)

EDA가 모델링 전에 반드시 필요한 이유는 세 가지다:

데이터 품질 확인 — 결측치, 이상치, 입력 오류를 사전에 파악한다.
가정 검증 — 정규성, 등분산성 등 모델의 전제 조건이 성립하는지 확인한다.
가설 생성 — 예상치 못한 패턴을 발견해 분석 방향을 조정한다.

💡 EDA는 “한 번 하고 끝”이 아니다

모델링 중 잔차(residual)가 이상하게 보이면 다시 EDA로 돌아간다. 특성 공학(feature engineering) 후에도, 새로운 데이터가 추가될 때에도 EDA를 반복한다. 분석의 전 과정에 걸친 순환적 활동이다.

중심 경향 측도

데이터의 “대표값”을 하나로 요약하는 지표들이다. 확률변수와 기댓값에서 기댓값과 분산을 이론적으로 정의했다면, 여기서는 표본 데이터에 적용하는 관점에서 다시 살펴본다.

평균, 중앙값, 최빈값

측도	정의	특징
평균(Mean)	모든 값의 합 / 개수	모든 데이터를 반영하지만, 이상치에 민감
중앙값(Median)	정렬 후 가운데 값	이상치에 강건(robust)
최빈값(Mode)	가장 빈도가 높은 값	범주형에도 적용 가능, 연속형에서는 잘 안 씀

세 측도의 차이가 극명해지는 경우를 보자.

import numpy as np

# 연봉 데이터 (단위: 만원)
salaries = np.array([3000, 3200, 3500, 3800, 4000, 4200, 4500, 5000, 12000, 50000])

mean_val = np.mean(salaries)
median_val = np.median(salaries)
print(f"평균: {mean_val:,.0f}만원")    # 평균: 9,320만원
print(f"중앙값: {median_val:,.0f}만원")  # 중앙값: 4,100만원

평균은 9,320만원이지만, 10명 중 8명은 5,000만원 이하를 받는다. 상위 두 명의 극단적 고연봉이 평균을 끌어올린 것이다. 이런 오른쪽 꼬리가 긴(right-skewed) 분포에서는 중앙값이 훨씬 대표성 있는 요약값이 된다.

⚠️ “평균 연봉”의 함정

뉴스에서 “평균 연봉 X천만원”이라는 기사를 볼 때, 그 숫자가 대다수의 경험과 동떨어져 있다면 분포의 비대칭성을 의심해야 한다. 소득·부동산·페이지 뷰 같은 데이터는 거의 항상 오른쪽으로 치우쳐 있어, 중앙값이 더 정직한 대표값이다.

산포도 측도

중심만으로는 부족하다. “평균이 같은 두 데이터셋”이 전혀 다른 분포를 가질 수 있기 때문이다.

분산, 표준편차, IQR

import numpy as np

A = np.array([48, 49, 50, 51, 52])
B = np.array([10, 30, 50, 70, 90])

for name, data in [("A", A), ("B", B)]:
    print(f"[{name}] 평균={np.mean(data):.1f}, "
          f"표준편차={np.std(data, ddof=1):.1f}, "
          f"IQR={np.percentile(data, 75) - np.percentile(data, 25):.1f}")
# [A] 평균=50.0, 표준편차=1.6, IQR=2.0
# [B] 평균=50.0, 표준편차=31.6, IQR=40.0

평균은 둘 다 50이지만, 데이터의 퍼짐 정도는 완전히 다르다.

측도	수식	이상치 민감도
분산(Variance)	$s^2 = \frac{1}{n-1}\sum(x_i - \bar{x})^2$	높음 (제곱 때문)
표준편차(Std)	$s = \sqrt{s^2}$	높음
IQR	Q3 − Q1 (75번째 − 25번째 백분위)	낮음 (중앙 50%만 사용)
범위(Range)	max − min	매우 높음 (극값 2개에 의존)

표준편차는 가장 많이 쓰이지만, 이상치가 있을 때는 IQR이 더 안정적이다. 신뢰구간에서 다뤘던 것처럼, 통계량의 강건성(robustness)은 실전에서 늘 고려해야 할 요소다.

분포의 형태: 왜도와 첨도

평균과 표준편차가 같더라도 분포의 모양 자체가 다를 수 있다. 이 모양을 정량화하는 두 가지 지표가 왜도와 첨도다.

왜도(Skewness)

분포의 비대칭 정도를 측정한다.

왜도 = 0: 좌우 대칭 (정규분포가 대표적)
왜도 > 0: 오른쪽 꼬리가 김 (소득, 페이지뷰)
왜도 < 0: 왼쪽 꼬리가 김 (시험 점수 — 만점 근처 집중)

첨도(Kurtosis)

꼬리의 두꺼운 정도를 측정한다. 정규분포의 첨도를 기준(0)으로 삼는 **초과 첨도(Excess Kurtosis)**를 주로 사용한다.

첨도 = 0: 정규분포와 유사한 꼬리
첨도 > 0: 꼬리가 두꺼움 (극단값이 정규분포보다 자주 발생)
첨도 < 0: 꼬리가 얇음 (극단값이 드뭄)

import numpy as np
from scipy import stats

np.random.seed(42)
normal_data = np.random.normal(50, 10, 10000)
skewed_data = np.random.exponential(10, 10000)

print("=== 정규분포 데이터 ===")
print(f"왜도: {stats.skew(normal_data):.3f}")    # 왜도: ≈ 0.0
print(f"첨도: {stats.kurtosis(normal_data):.3f}")  # 첨도: ≈ 0.0

print("\n=== 지수분포 데이터 (오른쪽 치우침) ===")
print(f"왜도: {stats.skew(skewed_data):.3f}")    # 왜도: ≈ 2.0
print(f"첨도: {stats.kurtosis(skewed_data):.3f}")  # 첨도: ≈ 6.0

💡 첨도는 “뾰족함”이 아니다

첨도를 “분포가 뾰족한 정도”로 설명하는 교재가 많지만, 이는 부정확하다. 첨도가 높은 분포는 중심이 뾰족한 것이 아니라 꼬리가 두꺼운 것이다. 금융 데이터에서 “fat tail”이라 부르는 현상이 바로 높은 첨도와 연결된다. 정규분포를 가정한 리스크 모델이 극단적 사건을 과소평가하는 이유도 여기에 있다.

시각화 도구 모음

숫자만으로는 데이터의 전체 모습을 파악하기 어렵다. Anscombe의 quartet — 기술통계량이 거의 동일하지만 시각화하면 완전히 다른 네 데이터셋 — 이 이를 잘 보여준다. 목적에 맞는 시각화 도구를 선택하는 것이 핵심이다.

도구	용도	적합한 상황
히스토그램	단일 변수의 분포 형태	연속형 변수의 전체 분포 파악
박스플롯	중앙값, IQR, 이상치 요약	그룹 간 분포 비교, 이상치 탐지
바이올린 플롯	박스플롯 + 밀도 추정	분포의 세부 형태까지 비교
산점도	두 변수 간 관계	상관관계, 군집, 비선형 패턴
상관 히트맵	다변량 상관 행렬	변수 간 관계의 전체 조망

import numpy as np
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import seaborn as sns

np.random.seed(42)

fig, axes = plt.subplots(1, 3, figsize=(15, 4))

# 1. 히스토그램
data = np.concatenate([np.random.normal(30, 5, 500),
                       np.random.normal(55, 8, 300)])
axes[0].hist(data, bins=30, edgecolor='black', alpha=0.7, color='steelblue')
axes[0].set_title('Histogram: Bimodal Distribution')
axes[0].set_xlabel('Value')
axes[0].set_ylabel('Frequency')

# 2. 박스플롯
groups = {'A': np.random.normal(50, 10, 200),
          'B': np.random.normal(55, 15, 200),
          'C': np.random.normal(45, 8, 200)}
axes[1].boxplot(groups.values(), tick_labels=list(groups.keys()))
axes[1].set_title('Box Plot: Group Comparison')
axes[1].set_ylabel('Value')

# 3. 산점도
x = np.random.normal(0, 1, 200)
y = 2 * x + np.random.normal(0, 0.5, 200)
axes[2].scatter(x, y, alpha=0.5, s=20, color='steelblue')
axes[2].set_title('Scatter Plot: Linear Relationship')
axes[2].set_xlabel('X')
axes[2].set_ylabel('Y')

plt.tight_layout()
plt.savefig('/tmp/eda_viz_demo.png', dpi=100)
plt.close('all')
print("시각화 저장 완료")

히스토그램은 분포의 형태를 직관적으로 보여준다. 위 예시처럼 봉우리가 두 개(bimodal)인 분포는 기술통계량만으로는 절대 포착할 수 없다. 박스플롯은 그룹 간 비교에 탁월하며, 상자 밖의 점이 이상치 후보라는 정보를 즉시 제공한다. 산점도는 두 변수 간 관계의 방향과 강도를 한눈에 드러낸다.

Python 실습: 타이타닉 데이터셋 EDA

이론을 실전으로 연결해보자. 가장 널리 쓰이는 학습용 데이터셋 중 하나인 타이타닉을 대상으로 EDA 전 과정을 수행한다.

1단계: 데이터 구조 파악

import pandas as pd
import numpy as np
import seaborn as sns

# seaborn 내장 데이터셋
df = sns.load_dataset('titanic')
print(f"행: {df.shape[0]}, 열: {df.shape[1]}")
# 행: 891, 열: 15

print("\n=== 데이터 타입 ===")
print(df.dtypes)
# survived         int64
# pclass           int64
# sex                str
# age            float64
# sibsp            int64
# parch            int64
# fare           float64
# embarked           str
# class         category
# who                str
# adult_male        bool
# deck          category
# embark_town        str
# alive              str
# alone             bool

2단계: 결측치 확인

import pandas as pd
import seaborn as sns

df = sns.load_dataset('titanic')

missing = df.isnull().sum()
missing_pct = (missing / len(df) * 100).round(1)
missing_df = pd.DataFrame({'결측수': missing, '비율(%)': missing_pct})
print(missing_df[missing_df['결측수'] > 0])
# age          177   19.9
# embarked       2    0.2
# deck         688   77.2
# embark_town    2    0.2

deck은 77%가 결측이므로 분석에서 제외하는 것이 합리적이고, age는 19.9%의 결측을 어떻게 처리할지 전략이 필요하다. embarked는 2건뿐이라 최빈값이나 삭제로 처리 가능하다.

3단계: 기술통계 요약

import pandas as pd
import seaborn as sns

df = sns.load_dataset('titanic')

print("=== 수치형 변수 기술통계 ===")
print(df[['age', 'fare', 'survived']].describe().round(2))
# age: mean≈29.70, std≈14.53, min=0.42, max=80.00
# fare: mean≈32.20, std≈49.69, min=0.00, max=512.33
# survived: mean≈0.38

print(f"\n생존율: {df['survived'].mean():.1%}")  # 생존율: 38.4%

fare의 표준편차(49.69)가 평균(32.20)보다 크다는 사실에 주목하라. 이는 극단적으로 비대칭인 분포를 강하게 암시한다. 실제로 대다수는 저렴한 3등석이었고, 소수의 1등석 요금이 평균을 끌어올린 것이다.

4단계: 그룹별 비교

import pandas as pd
import seaborn as sns

df = sns.load_dataset('titanic')

print("=== 성별 생존율 ===")
print(df.groupby('sex')['survived'].mean().round(3))
# female    0.742
# male      0.189

print("\n=== 객실 등급별 생존율 ===")
print(df.groupby('pclass')['survived'].mean().round(3))
# 1    0.630
# 2    0.473
# 3    0.242

여성의 생존율(74.2%)이 남성(18.9%)보다 압도적으로 높고, 1등석(63.0%)이 3등석(24.2%)보다 두 배 이상 높다. “Women and children first” 원칙과 사회경제적 요인이 생존에 강하게 작용했음을 수치가 보여준다.

5단계: 시각화 종합

import pandas as pd
import numpy as np
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import seaborn as sns

df = sns.load_dataset('titanic')

fig, axes = plt.subplots(2, 2, figsize=(12, 10))

# 1. 나이 분포 (히스토그램)
axes[0, 0].hist(df['age'].dropna(), bins=30, edgecolor='black',
                alpha=0.7, color='steelblue')
axes[0, 0].set_title('Age Distribution')
axes[0, 0].set_xlabel('Age')
axes[0, 0].set_ylabel('Frequency')

# 2. 등급별 요금 (박스플롯)
df.boxplot(column='fare', by='pclass', ax=axes[0, 1])
axes[0, 1].set_title('Fare by Passenger Class')
axes[0, 1].set_xlabel('Pclass')
axes[0, 1].set_ylabel('Fare')
plt.sca(axes[0, 1])
plt.title('Fare by Passenger Class')

# 3. 성별 × 등급별 생존율 (바 차트)
survival = df.groupby(['pclass', 'sex'])['survived'].mean().unstack()
survival.plot(kind='bar', ax=axes[1, 0], rot=0, color=['steelblue', 'coral'])
axes[1, 0].set_title('Survival Rate by Class & Sex')
axes[1, 0].set_xlabel('Pclass')
axes[1, 0].set_ylabel('Survival Rate')
axes[1, 0].legend(title='Sex')

# 4. 상관 히트맵
numeric_cols = df[['survived', 'pclass', 'age', 'sibsp', 'parch', 'fare']].corr()
im = axes[1, 1].imshow(numeric_cols, cmap='RdBu_r', vmin=-1, vmax=1)
axes[1, 1].set_xticks(range(len(numeric_cols.columns)))
axes[1, 1].set_yticks(range(len(numeric_cols.columns)))
axes[1, 1].set_xticklabels(numeric_cols.columns, rotation=45, ha='right')
axes[1, 1].set_yticklabels(numeric_cols.columns)
axes[1, 1].set_title('Correlation Heatmap')
fig.colorbar(im, ax=axes[1, 1], shrink=0.8)

fig.suptitle('Titanic Dataset EDA', fontsize=14, y=1.02)
plt.tight_layout()
plt.savefig('/tmp/titanic_eda.png', dpi=100, bbox_inches='tight')
plt.close('all')
print("타이타닉 EDA 시각화 저장 완료")

상관 히트맵에서 pclass와 fare의 음의 상관(-0.55)이 눈에 띈다. 등급 숫자가 작을수록(1등석) 요금이 높으므로 자연스러운 결과다. survived와 fare의 양의 상관(0.26)도 “비싼 표를 산 승객일수록 생존 확률이 높았다”는 패턴을 반영한다.

EDA 체크리스트

실무에서 새 데이터셋을 받았을 때 바로 적용할 수 있는 절차를 정리한다.

단계	확인 항목	핵심 함수/도구
1. 구조 파악	행/열 수, 데이터 타입, 컬럼명	`df.shape`, `df.dtypes`, `df.info()`
2. 결측치	컬럼별 결측 비율, 결측 패턴(MCAR/MAR/MNAR)	`df.isnull().sum()`, `missingno` 라이브러리
3. 기술통계	평균, 중앙값, 표준편차, 사분위수	`df.describe()`
4. 분포 확인	왜도, 첨도, 히스토그램	`df.skew()`, `df.kurtosis()`, 히스토그램
5. 이상치	IQR 기준 이상치, 도메인 기반 판단	박스플롯, Z-score
6. 범주형 변수	각 범주의 빈도, 불균형 정도	`df['col'].value_counts()`
7. 변수 간 관계	상관계수, 산점도, 교차표	`df.corr()`, 산점도 행렬, 히트맵
8. 시간 변수	추세, 계절성, 단위 확인	라인 플롯, 롤링 평균

💡 EDA는 보고서가 아니다

체크리스트의 모든 항목을 기계적으로 나열하는 것이 EDA의 목적이 아니다. 핵심은 “이 데이터에서 무엇이 이상한가? 무엇이 기대와 다른가?”라는 질문을 끊임없이 던지는 것이다. 체크리스트는 놓치기 쉬운 항목을 환기하는 보조 도구일 뿐이다.

흔한 실수 세 가지

1. 시각화 없이 숫자만 보기

df.describe()의 출력만 보고 넘어가는 것은 위험하다. Anscombe의 quartet이 보여주듯, 평균·분산·상관계수가 동일해도 분포의 실제 모습은 완전히 다를 수 있다. 기술통계와 시각화는 항상 쌍으로 사용해야 한다.

2. 이상치를 무조건 제거하기

이상치를 발견하면 반사적으로 삭제하는 경우가 많다. 하지만 이상치는 세 가지로 구분해야 한다:

입력 오류 — 나이가 -5세, 키가 300cm → 수정 또는 제거
자연적 극단값 — 빌 게이츠의 연봉 → 제거하면 안 됨, 분석 목적에 따라 판단
다른 모집단 — 봇 트래픽이 섞인 웹 로그 → 분리하여 별도 분석

무조건 제거하면 정보 손실이 발생하고, 무조건 유지하면 모델이 왜곡된다. 도메인 지식에 기반한 판단이 필요하다.

3. 상관관계를 인과로 해석하기

상관 히트맵에서 두 변수의 상관계수가 높다고 해서 하나가 다른 하나의 원인인 것은 아니다. 아이스크림 판매량과 익사 사고 건수가 양의 상관을 보이지만, 아이스크림이 익사를 유발하는 것이 아니라 기온이라는 교란변수(confounding variable)가 둘 다에 영향을 미치는 것이다.

⚠️ “Correlation does not imply causation”

상관관계에서 인과를 추론하려면 무작위 통제 실험(RCT) 또는 인과 추론(causal inference) 프레임워크가 필요하다. EDA 단계에서 발견한 상관관계는 “추가 조사가 필요한 가설”이지, 결론이 아니다.

마치며

이 글에서는 기술통계의 핵심 지표(중심 경향, 산포도, 왜도·첨도)와 시각화 도구를 정리하고, 타이타닉 데이터셋으로 EDA의 전 과정을 실습했다. 핵심을 다시 짚으면:

중심 경향 — 비대칭 분포에서는 평균보다 중앙값이 대표성 있다.
산포도 — 표준편차와 IQR을 함께 보아야 이상치에 속지 않는다.
시각화 — 숫자와 그래프는 반드시 쌍으로. 히스토그램·박스플롯·산점도의 용도를 구분하라.
절차 — 체크리스트를 활용하되, 기계적 나열이 아니라 “무엇이 이상한가?”를 끊임없이 질문하라.

EDA를 통해 데이터를 충분히 이해했다면, 자연스럽게 다음 질문이 떠오른다: “이 표본 데이터가 우리가 알고 싶은 모집단을 얼마나 잘 대표하는가?” 표본 추출 방법에 따라 결과가 완전히 달라질 수 있고, 잘못된 표본은 아무리 정교한 분석도 무의미하게 만든다. 다음 글에서는 표본 추출의 원리와 편향(bias)의 다양한 형태를 다룬다.

참고자료

Tukey, J.W. Exploratory Data Analysis. Addison-Wesley, 1977. — EDA 개념을 체계화한 고전
Wickham, H. & Grolemund, G. R for Data Science (2nd ed.). O’Reilly, 2023. — EDA 워크플로의 실전적 안내 (R 기반이지만 철학은 동일)
VanderPlas, J. Python Data Science Handbook. O’Reilly, 2016. — pandas + matplotlib EDA 실습
McKinney, W. Python for Data Analysis (3rd ed.). O’Reilly, 2022. — pandas 창시자의 데이터 분석 가이드
seaborn documentation — 통계적 시각화의 Python 표준 라이브러리

베이지안 추론(Bayesian Inference): 사전 지식과 데이터를 결합하는 통계적 사고

Donhyeok Kang — Sun, 22 Feb 2026 00:00:00 GMT

지난 열세 편의 글에 걸쳐 우리는 빈도주의(Frequentist) 통계의 핵심 도구를 하나씩 쌓아왔다. 점추정으로 모수의 “최선의 추측”을 구하고, MLE로 추정량을 체계적으로 찾았으며, 신뢰구간과 가설검정으로 불확실성을 정량화했다. 부트스트랩까지 다루면서 분포 가정이 어려울 때의 비모수적 접근도 살펴봤다.

그런데 한 가지 질문이 남아 있다. 동전을 10번 던져 앞면이 7번 나왔다고 하자. MLE는 $\hat{p} = 0.7$ 이라고 답한다. 하지만 우리는 이 동전이 일반적인 동전이라는 것을 이미 알고 있다. 앞면 확률이 0.5 근처일 가능성이 높다는 사전 지식이 있는데, 이 정보를 전혀 활용하지 않는다면 — 그건 낭비 아닐까?

빈도주의 프레임워크에서는 이런 사전 지식을 공식적으로 통합할 방법이 없다. 데이터만이 유일한 증거다. 반면 **베이지안 추론(Bayesian Inference)**은 사전 지식과 데이터를 명시적으로 결합하는 프레임워크를 제공한다. 이 글은 stats-inference 시리즈의 마지막 편으로, 빈도주의와 베이지안이라는 두 패러다임을 비교한 뒤, 베이지안 추론의 핵심 메커니즘을 이론과 실습으로 완결짓는다.

빈도주의 vs 베이지안: 두 세계관

패러다임 비교표

관점	빈도주의(Frequentist)	베이지안(Bayesian)
모수 $\theta$ 의 본질	고정된 미지의 상수	불확실성을 가진 확률변수
확률의 해석	장기적 빈도(Long-run frequency)	믿음의 정도(Degree of belief)
추론 방법	MLE, 가설검정, 신뢰구간	사후분포, MAP, 신용구간
사전 지식	사용하지 않음 (데이터만)	사전분포로 명시적 반영
불확실성 표현	표본 분포, p-value	사후분포 전체
표본 크기 작을 때	불안정 (점근 이론 의존)	사전분포가 안정화 역할
계산 비용	대체로 낮음	높을 수 있음 (MCMC 등)

이 표를 관통하는 핵심 차이는 하나다: 모수를 상수로 보느냐, 확률변수로 보느냐. 빈도주의에서 $\theta$ 는 알려지지 않았지만 고정된 값이므로 ” $P(\theta = 0.5)$ “라는 표현 자체가 성립하지 않는다. 반면 베이지안에서 $\theta$ 는 확률변수이며, 우리의 불확실성을 확률분포로 표현할 수 있다.

각각 언제 유리한가

빈도주의가 유리한 상황도 분명히 있다. 데이터가 충분히 많으면 사전분포의 영향은 사라지고 두 패러다임의 결과가 수렴하는데, 이때 빈도주의가 계산적으로 훨씬 간결하다. 규제 기관의 승인 절차처럼 “객관적” 기준이 요구되는 경우에도 빈도주의의 가설검정이 표준이다.

베이지안은 표본이 적을 때, 사전 지식이 풍부할 때, 또는 불확실성의 전체 분포가 필요할 때 강점을 발휘한다. 임상시험의 적응적 설계(adaptive design), 추천 시스템의 콜드 스타트 문제, A/B 테스트의 조기 종료 판단 같은 영역에서 베이지안 접근이 자연스럽다.

💡 “빈도주의 vs 베이지안”은 종교 전쟁이 아니다

실무에서는 두 접근을 도구로서 선택한다. “이 문제에서 사전 정보가 유용한가? 사후분포 전체가 필요한가? 계산 비용은 감당 가능한가?” — 이런 질문에 따라 적절한 도구를 고르면 된다. 이 글의 목표도 베이지안이 더 우월하다고 주장하는 것이 아니라, 여러분의 도구 상자에 하나를 더 추가하는 것이다.

베이즈 정리에서 베이지안 추론으로

복습: 베이즈 정리

조건부 확률과 베이즈 정리에서 다뤘던 베이즈 정리를 다시 꺼내보자.

P(A|B) = \frac{P(B|A) \, P(A)}{P(B)}

이 공식을 사건이 아니라 모수 $\theta$ 와 데이터 $X$ 로 바꾸면 베이지안 추론의 핵심 공식이 된다.

베이지안 추론의 핵심 공식

\underbrace{P(\theta | X)}_{\text{사후분포}} = \frac{\overbrace{P(X | \theta)}^{\text{우도}} \cdot \overbrace{P(\theta)}^{\text{사전분포}}}{\underbrace{P(X)}_{\text{증거(주변우도)}}}

각 구성 요소의 역할을 하나씩 살펴보자.

요소	표기	역할
사전분포(Prior)	$P(\theta)$	데이터를 보기 전 모수에 대한 믿음
우도(Likelihood)	$P(X \mid \theta)$	주어진 $\theta$ 에서 데이터가 관측될 가능성 — MLE에서 최대화했던 바로 그것
증거(Evidence)	$P(X) = \int P(X \mid \theta) P(\theta) \, d\theta$	정규화 상수, $\theta$ 에 의존하지 않음
사후분포(Posterior)	$P(\theta \mid X)$	데이터를 본 후 모수에 대한 업데이트된 믿음

증거 $P(X)$ 는 $\theta$ 에 대해 적분(또는 합산)한 상수이므로, 사후분포의 형태를 결정하는 데는 불필요하다. 따라서 비례 관계로 쓰면:

\boxed{P(\theta | X) \propto P(X | \theta) \cdot P(\theta)}

사후분포는 우도와 사전분포의 곱에 비례한다.

이 한 줄이 베이지안 추론의 전부다. 사전 믿음( $P(\theta)$ )에 데이터의 증거( $P(X|\theta)$ )를 곱하면 업데이트된 믿음( $P(\theta|X)$ )을 얻는다. 데이터가 추가될 때마다 사후분포를 새로운 사전분포로 삼아 반복할 수 있으니, 베이지안 추론은 본질적으로 순차적 학습(sequential learning) 프레임워크이기도 하다.

사전분포(Prior)의 선택

사전분포는 베이지안 추론에서 가장 논쟁적인 부분이다. “주관적”이라는 비판의 핵심 대상이기도 한데, 사전분포의 유형을 정리하면 다음과 같다.

무정보 사전분포 (Non-informative Prior)

모수에 대한 사전 정보가 전혀 없을 때, 가능한 한 “중립적인” 사전분포를 사용한다.

균일분포(Uniform): $P(\theta) \propto 1$ . 모든 값에 동일한 확률을 부여한다. 직관적이지만, 모수 변환에 대해 불변이 아니라는 문제가 있다. 예를 들어 $\theta$ 에 대해 균일이면 $\theta^2$ 에 대해서는 균일이 아니다.
Jeffrey’s Prior: $P(\theta) \propto \sqrt{I(\theta)}$ 로 정의하며, $I(\theta)$ 는 피셔 정보량이다. 모수 변환에 대해 불변(invariant)이라는 장점이 있다. 베르누이 분포에서 Jeffrey’s prior는 $\text{Beta}(1/2, 1/2)$ 이 된다.

약정보 사전분포 (Weakly Informative Prior)

완전히 무정보는 아니지만, 극단적인 값을 배제하는 정도의 약한 정보만 반영한다. 예를 들어 사람의 키를 추정할 때 $N(170, 50^2)$ 같은 넓은 정규분포를 사용하면, “키가 -100cm이거나 500cm일 가능성은 낮다”는 상식만 반영하는 셈이다. 실무에서 가장 많이 쓰이는 전략이기도 하다.

정보적 사전분포 (Informative Prior)

이전 연구 결과나 전문가 판단 등 구체적인 사전 지식을 반영한다. 약물의 효과에 대한 기존 메타분석 결과를 사전분포로 사용하는 것이 대표적이다. 데이터가 적을 때 강력하지만, 잘못된 사전분포는 결과를 왜곡할 수 있으므로 민감도 분석(sensitivity analysis)이 필수다.

⚠️ 사전분포 민감도(Prior Sensitivity)

사전분포의 선택이 결론을 크게 바꾼다면, 그 분석은 데이터보다 사전 가정에 의존하고 있다는 신호다. 서로 다른 합리적 사전분포를 넣어보고 결론이 일관되는지 확인하는 민감도 분석을 반드시 수행해야 한다. 사후분포가 사전분포에 둔감하다면(robust), 그 결론은 신뢰할 수 있다.

켤레 사전분포(Conjugate Prior)

왜 켤레 분포가 중요한가

사후분포를 구하려면 $P(X|\theta) \cdot P(\theta)$ 를 계산하고 정규화해야 한다. 일반적으로 이 적분은 해석적으로 풀리지 않는다. 그런데 특정 우도-사전분포 조합에서는 사후분포가 사전분포와 같은 분포족에 속하는 성질이 성립한다. 이런 사전분포를 **켤레 사전분포(Conjugate Prior)**라 한다.

주요 켤레 쌍 정리표

우도(Likelihood)	켤레 사전분포(Prior)	사후분포(Posterior)	사후 하이퍼파라미터
$\text{Bernoulli}(p)$ / $\text{Binomial}(n,p)$	$\text{Beta}(\alpha, \beta)$	$\text{Beta}(\alpha + k, \, \beta + n - k)$	$k$ : 성공 횟수
$\text{Poisson}(\lambda)$	$\text{Gamma}(\alpha, \beta)$	$\text{Gamma}(\alpha + \sum x_i, \, \beta + n)$	$n$ : 관측 수
$\text{Normal}(\mu, \sigma^2_0)$ ( $\sigma^2_0$ 기지)	$\text{Normal}(\mu_0, \tau^2_0)$	$\text{Normal}(\mu_n, \tau^2_n)$	$\tau^2_n = \left(\frac{1}{\tau^2_0} + \frac{n}{\sigma^2_0}\right)^{-1}$
$\text{Exponential}(\lambda)$	$\text{Gamma}(\alpha, \beta)$	$\text{Gamma}(\alpha + n, \, \beta + \sum x_i)$
$\text{Multinomial}$	$\text{Dirichlet}(\boldsymbol{\alpha})$	$\text{Dirichlet}(\boldsymbol{\alpha} + \mathbf{k})$	$\mathbf{k}$ : 각 범주 관측 수

이 표에서 패턴이 보이는가? 사후분포의 하이퍼파라미터는 사전분포의 하이퍼파라미터에 데이터 요약 통계량을 더한 것이다. 적분 없이, 하이퍼파라미터만 업데이트하면 사후분포가 완성된다.

Beta-Binomial: 상세 유도

가장 중요하고 직관적인 켤레 쌍인 Beta-Binomial을 자세히 유도해보자. 동전의 앞면 확률 $p$ 를 추정하는 문제다.

설정: 동전을 $n$ 번 던져 앞면이 $k$ 번 나왔다. $p$ 에 대한 사전분포로 $\text{Beta}(\alpha, \beta)$ 를 사용한다.

연속 분포 글에서 다뤘듯이, 베타 분포의 확률밀도함수는:

P(p) = \frac{p^{\alpha-1}(1-p)^{\beta-1}}{B(\alpha, \beta)}, \quad 0 \leq p \leq 1

이산 분포 글의 이항분포로부터 우도 함수는:

P(X = k \mid p) = \binom{n}{k} p^k (1-p)^{n-k}

사후분포를 비례 관계로 쓰면:

P(p \mid X=k) \propto P(X=k \mid p) \cdot P(p) = \binom{n}{k} p^k (1-p)^{n-k} \cdot \frac{p^{\alpha-1}(1-p)^{\beta-1}}{B(\alpha, \beta)}

$p$ 에 의존하지 않는 상수를 모두 버리면:

P(p \mid X=k) \propto p^{k + \alpha - 1} \cdot (1-p)^{n - k + \beta - 1}

이것은 $\text{Beta}(k + \alpha, \; n - k + \beta)$ 의 커널과 정확히 같다. 따라서:

\boxed{p \mid X=k \;\sim\; \text{Beta}(\alpha + k, \; \beta + n - k)}

사전분포의 $\alpha$ 에 성공 횟수 $k$ 를 더하고, $\beta$ 에 실패 횟수 $n-k$ 를 더하면 사후분포가 된다. 이렇게 보면 사전분포의 하이퍼파라미터 $\alpha, \beta$ 는 **“가상의 사전 관측”**으로 해석할 수 있다. $\text{Beta}(2, 5)$ 는 “이전에 2번 성공, 5번 실패를 관측한 것과 같은 사전 믿음”인 셈이다.

💡 사전 관측(Pseudo-counts) 해석

$\text{Beta}(\alpha, \beta)$ 사전분포에서 $\alpha + \beta$ 는 사전 “유효 표본 크기”다. 이 값이 클수록 사전분포가 강하게 작용하고, 작을수록 데이터가 사후분포를 지배한다. $\text{Beta}(1, 1) = \text{Uniform}(0,1)$ 은 사전 유효 표본 크기가 2로, 가장 약한 정보적 사전분포 중 하나다.

사후분포에서의 추론

사후분포를 구했다면, 이제 이 분포로부터 구체적인 추론을 수행할 차례다.

MAP 추정 (Maximum A Posteriori)

사후분포의 **최빈값(mode)**을 점추정값으로 사용하는 방법이다.

\hat{\theta}_{\text{MAP}} = \arg\max_\theta P(\theta | X) = \arg\max_\theta \left[ P(X|\theta) \cdot P(\theta) \right]

MLE와 나란히 놓으면 차이가 선명해진다.

\hat{\theta}_{\text{MLE}} = \arg\max_\theta P(X|\theta), \qquad \hat{\theta}_{\text{MAP}} = \arg\max_\theta P(X|\theta) \cdot P(\theta)

MAP는 MLE에 사전분포라는 “가중치”를 곱한 것이다. 사전분포가 균일분포이면 $P(\theta) \propto 1$ 이므로 MAP = MLE가 된다. 즉, MLE는 균일 사전분포를 사용한 MAP의 특수한 경우로 볼 수 있다.

Beta-Binomial 예시에서, $\text{Beta}(\alpha + k, \beta + n - k)$ 의 최빈값은:

\hat{p}_{\text{MAP}} = \frac{\alpha + k - 1}{\alpha + \beta + n - 2}

반면 MLE는 $\hat{p}_{\text{MLE}} = k/n$ 이다. 사전분포가 사후 추정을 중심 쪽으로 “수축(shrinkage)“시키는 것을 볼 수 있다.

사후 평균 (Posterior Mean)

사후분포의 기댓값을 점추정값으로 사용할 수도 있다. $\text{Beta}(\alpha + k, \beta + n - k)$ 의 평균은:

\hat{p}_{\text{post.mean}} = \frac{\alpha + k}{\alpha + \beta + n}

이 식을 변형하면 아름다운 구조가 드러난다:

\hat{p}_{\text{post.mean}} = \underbrace{\frac{n}{\alpha + \beta + n}}_{\text{데이터 가중치}} \cdot \underbrace{\frac{k}{n}}_{\text{MLE}} + \underbrace{\frac{\alpha + \beta}{\alpha + \beta + n}}_{\text{사전분포 가중치}} \cdot \underbrace{\frac{\alpha}{\alpha + \beta}}_{\text{사전 평균}}

사후 평균은 MLE와 사전 평균의 가중 평균이다. 데이터( $n$ )가 많아지면 MLE 쪽으로, 사전분포가 강하면( $\alpha + \beta$ 클수록) 사전 평균 쪽으로 끌린다. 이것이 베이지안 추론의 핵심적인 “사전-데이터 균형(prior-data compromise)” 메커니즘이다.

신용구간(Credible Interval) vs 신뢰구간

빈도주의의 신뢰구간과 베이지안의 **신용구간(Credible Interval)**은 겉보기에 비슷하지만 해석이 근본적으로 다르다.

	95% 신뢰구간 (Frequentist)	95% 신용구간 (Bayesian)
정의	같은 절차를 반복하면 95%의 구간이 참 모수를 포함	모수가 이 구간에 있을 확률이 95%
해석	절차에 대한 확률 (장기 빈도)	모수에 대한 직접적 확률 진술
“이 구간에 $\theta$ 가 있을 확률이 95%”	아니오 (빈도주의에서 $\theta$ 는 상수)	예 (베이지안에서 $\theta$ 는 확률변수)

신용구간의 가장 일반적인 형태는 HPD(Highest Posterior Density) 구간이다. 이 구간은 사후 밀도가 가장 높은 영역을 선택하므로, 같은 확률에 대해 가장 좁은 구간을 제공한다.

Python 실습: Beta-Binomial 업데이트 시각화

이론을 코드로 확인해보자. 동전의 앞면 확률 $p$ 를 추정하되, 데이터가 하나씩 추가될 때마다 사후분포가 어떻게 변하는지 시각화한다.

import numpy as np
import matplotlib.pyplot as plt
from scipy import stats

# --- 설정 ---
np.random.seed(42)
true_p = 0.65               # 실제 앞면 확률 (살짝 편향된 동전)
n_flips = 50                 # 동전 던지기 횟수
data = np.random.binomial(1, true_p, size=n_flips)  # 0 또는 1

# 사전분포: Beta(2, 2) — "p가 0.5 근처"라는 약한 사전 지식
alpha_prior, beta_prior = 2, 2

# --- 순차 업데이트 시각화 ---
p_grid = np.linspace(0, 1, 500)
checkpoints = [0, 1, 5, 10, 25, 50]  # 시각화할 시점

fig, axes = plt.subplots(2, 3, figsize=(14, 8))
axes = axes.flatten()

for idx, n_obs in enumerate(checkpoints):
    ax = axes[idx]
    k = data[:n_obs].sum() if n_obs > 0 else 0  # 누적 성공 횟수

    # 사후분포 파라미터
    alpha_post = alpha_prior + k
    beta_post = beta_prior + (n_obs - k)

    posterior = stats.beta(alpha_post, beta_post)

    # 사전분포 (참고용)
    prior = stats.beta(alpha_prior, beta_prior)
    ax.fill_between(p_grid, prior.pdf(p_grid), alpha=0.2, color='gray', label='사전분포')

    # 사후분포
    ax.fill_between(p_grid, posterior.pdf(p_grid), alpha=0.4, color='#0d9488')
    ax.plot(p_grid, posterior.pdf(p_grid), color='#0d9488', lw=2, label='사후분포')

    # 참값 & MLE 표시
    ax.axvline(true_p, color='red', ls='--', lw=1.2, label=f'참값 p={true_p}')
    if n_obs > 0:
        mle = k / n_obs
        ax.axvline(mle, color='blue', ls=':', lw=1.2, label=f'MLE={mle:.2f}')

    # 95% 신용구간
    ci_low, ci_high = posterior.ppf(0.025), posterior.ppf(0.975)
    ax.axvspan(ci_low, ci_high, alpha=0.1, color='#0d9488')

    ax.set_title(f'n={n_obs}, k={k}, Beta({alpha_post},{beta_post})', fontsize=11)
    ax.set_xlim(0, 1)
    ax.legend(fontsize=8, loc='upper left')

fig.suptitle('Beta-Binomial: 사후분포의 순차 업데이트', fontsize=14, y=1.02)
plt.tight_layout()
plt.savefig('beta_binomial_update.png', dpi=150, bbox_inches='tight')
plt.show()

이 시각화에서 핵심적으로 확인할 것은 세 가지다.

$n=0$ : 사전분포 $\text{Beta}(2,2)$ 만 있다. 종 모양으로 $p=0.5$ 근처에 집중되어 있다.
$n$ 증가: 사후분포가 점점 좁아지면서(불확실성 감소) 참값 0.65 쪽으로 이동한다.
$n=50$ : 사전분포의 영향은 거의 사라지고, 사후분포가 MLE 근처에 집중된다. 데이터가 충분하면 사전분포가 “씻겨 나간다(washed out).”

MCMC 입문: 켤레가 아닌 경우

문제: 사후분포를 닫힌 해로 못 구한다

켤레 사전분포는 편리하지만, 현실의 모델은 대부분 이렇게 깔끔하지 않다. 다중 모수 모델, 비표준 우도, 계층적 구조를 가진 모델에서는 사후분포의 정규화 상수 $P(X) = \int P(X|\theta)P(\theta)\,d\theta$ 를 해석적으로 계산할 수 없다.

그러면 사후분포를 어떻게 얻을 수 있을까? 핵심 아이디어는 이것이다: 사후분포를 정확히 알 수 없어도, 사후분포에서 샘플을 뽑을 수만 있다면 충분하다. 충분히 많은 샘플이 있으면 히스토그램으로 분포의 형태를 파악하고, 평균이나 분위수 등 원하는 통계량을 계산할 수 있다.

이것이 마르코프 체인 몬테카를로(Markov Chain Monte Carlo, MCMC) 방법의 핵심이다.

Metropolis-Hastings 알고리즘의 직관

MCMC의 가장 기본적인 알고리즘인 Metropolis-Hastings를 살펴보자. 안개 낀 산에서 정상을 찾으려는 등산객을 떠올리면 된다 — 다만 정상의 “높이”에 비례하는 시간을 각 위치에서 보내야 한다.

알고리즘 (1차원 기준):

임의의 시작점 $\theta_0$ 을 선택한다.
현재 위치 $\theta_t$ 에서 제안 분포(proposal distribution) $q(\theta^* | \theta_t)$ 를 이용해 후보 $\theta^*$ 를 생성한다. (예: $\theta^* \sim N(\theta_t, \sigma^2)$ — 현재 위치 근처에서 랜덤하게 한 걸음 이동)
**수용 확률(acceptance probability)**을 계산한다:

\alpha = \min\left(1, \; \frac{P(X|\theta^*) \cdot P(\theta^*)}{P(X|\theta_t) \cdot P(\theta_t)} \cdot \frac{q(\theta_t | \theta^*)}{q(\theta^* | \theta_t)}\right)

대칭 제안 분포( $q(\theta^*|\theta_t) = q(\theta_t|\theta^*)$ )를 쓰면 뒤의 비율이 1이 되어 간소화된다:

\alpha = \min\left(1, \; \frac{P(X|\theta^*) \cdot P(\theta^*)}{P(X|\theta_t) \cdot P(\theta_t)}\right)

균일 난수 $u \sim U(0,1)$ 을 뽑아서 $u < \alpha$ 이면 $\theta_{t+1} = \theta^*$ (수용), 아니면 $\theta_{t+1} = \theta_t$ (제자리).
2-4를 수천~수만 번 반복한다.

여기서 핵심적인 통찰이 있다. 수용 확률의 비율에서 정규화 상수 $P(X)$ 가 상쇄된다. 분자와 분모 모두 $P(\theta|X) \propto P(X|\theta)P(\theta)$ 이므로, 정규화 상수를 모르고도 사후분포에서 샘플링할 수 있다.

Python으로 직접 구현: 1D Metropolis-Hastings

동전 편향 추정 문제를 MCMC로 풀어보자. Beta-Binomial은 해석해가 있으므로 MCMC가 불필요하지만, 결과를 해석해와 비교 검증할 수 있어서 학습용으로 적합하다.

import numpy as np
from scipy import stats

np.random.seed(42)

# --- 데이터 ---
true_p = 0.65
n_flips = 50
data = np.random.binomial(1, true_p, size=n_flips)
k = data.sum()  # 성공 횟수

# --- 사전분포: Beta(2, 2) ---
alpha_prior, beta_prior = 2, 2

def log_posterior(p, k, n, alpha, beta):
    """비정규화 로그 사후분포 (정규화 상수 불필요)"""
    if p <= 0 or p >= 1:
        return -np.inf  # 모수 공간 밖
    log_likelihood = k * np.log(p) + (n - k) * np.log(1 - p)
    log_prior = (alpha - 1) * np.log(p) + (beta - 1) * np.log(1 - p)
    return log_likelihood + log_prior

# --- Metropolis-Hastings ---
n_samples = 50000
proposal_sd = 0.05      # 제안 분포의 표준편차
samples = np.zeros(n_samples)
samples[0] = 0.5         # 시작점
accepted = 0

for t in range(1, n_samples):
    # 1. 제안
    current = samples[t - 1]
    proposed = np.random.normal(current, proposal_sd)

    # 2. 수용 확률 (로그 스케일)
    log_alpha = log_posterior(proposed, k, n_flips, alpha_prior, beta_prior) \
              - log_posterior(current,  k, n_flips, alpha_prior, beta_prior)

    # 3. 수용/기각
    if np.log(np.random.uniform()) < log_alpha:
        samples[t] = proposed
        accepted += 1
    else:
        samples[t] = current

burn_in = 5000
posterior_samples = samples[burn_in:]  # 번인(burn-in) 제거

print(f"수용률: {accepted / n_samples:.1%}")
# 수용률: ~45-55% (적정 범위)

print(f"MCMC 사후 평균: {posterior_samples.mean():.4f}")
print(f"MCMC 사후 표준편차: {posterior_samples.std():.4f}")

# 해석해와 비교
alpha_post = alpha_prior + k
beta_post = beta_prior + (n_flips - k)
exact_posterior = stats.beta(alpha_post, beta_post)
print(f"해석해 사후 평균: {exact_posterior.mean():.4f}")
print(f"해석해 사후 표준편차: {exact_posterior.std():.4f}")

# 95% 신용구간 비교
mcmc_ci = np.percentile(posterior_samples, [2.5, 97.5])
exact_ci = exact_posterior.ppf([0.025, 0.975])
print(f"MCMC 95% CI:  [{mcmc_ci[0]:.4f}, {mcmc_ci[1]:.4f}]")
print(f"해석해 95% CI: [{exact_ci[0]:.4f}, {exact_ci[1]:.4f}]")

MCMC 결과와 해석해가 매우 가까울 것이다. 5만 개의 샘플(번인 5,000 제거)이면 1차원 문제에서는 충분하다. 다만 고차원 문제에서는 수렴 진단이 필수적인데, 이에 대해서는 마지막 섹션에서 정리한다.

💡 실무에서의 MCMC 도구

직접 구현은 학습용이다. 실무에서는 검증된 라이브러리를 사용한다:

PyMC — Python 베이지안 모델링의 표준. NUTS(No-U-Turn Sampler) 기반으로 고차원에서도 효율적이다.
Stan (PyStan/CmdStanPy) — HMC(Hamiltonian Monte Carlo) 기반. 산업계와 학계 모두에서 널리 사용된다.
emcee — 앙상블 샘플러. 천문학 커뮤니티에서 시작해 범용으로 확산되었다.

이들은 자동 미분, 수렴 진단, 사후 예측 검사 등을 기본 제공하므로, MCMC의 원리를 이해한 뒤에는 이런 도구로 넘어가는 것이 바람직하다.

같은 문제, 두 가지 풀이

이론을 충분히 다뤘으니, 이제 하나의 문제를 두 패러다임으로 나란히 풀어보자. 동전을 30번 던져 앞면이 21번 나왔다. 이 동전은 공정한가?

빈도주의 접근

import numpy as np
from scipy import stats

n, k = 30, 21

# 1. MLE
p_hat = k / n
print(f"MLE: p̂ = {p_hat:.4f}")
# MLE: p̂ = 0.7000

# 2. 95% 신뢰구간 (Wald)
se = np.sqrt(p_hat * (1 - p_hat) / n)
ci_freq = (p_hat - 1.96 * se, p_hat + 1.96 * se)
print(f"95% 신뢰구간: [{ci_freq[0]:.4f}, {ci_freq[1]:.4f}]")
# 95% 신뢰구간: [0.5360, 0.8640]

# 3. 가설검정: H0: p = 0.5 vs H1: p ≠ 0.5
z = (p_hat - 0.5) / np.sqrt(0.5 * 0.5 / n)
p_value = 2 * (1 - stats.norm.cdf(abs(z)))
print(f"z = {z:.4f}, p-value = {p_value:.4f}")
# z = 2.1909, p-value = 0.0285

빈도주의 결론: p-value = 0.028 < 0.05이므로 귀무가설을 기각한다. 이 동전은 공정하지 않다는 증거가 있다. 하지만 “공정하지 않을 확률이 얼마인지”는 빈도주의에서 답할 수 없는 질문이다.

베이지안 접근

import numpy as np
from scipy import stats

n, k = 30, 21

# 사전분포: Beta(2, 2) — 공정한 동전 근처의 약한 사전 지식
alpha_prior, beta_prior = 2, 2

# 사후분포
alpha_post = alpha_prior + k    # 23
beta_post = beta_prior + (n - k) # 11
posterior = stats.beta(alpha_post, beta_post)

# 1. MAP 추정
p_map = (alpha_post - 1) / (alpha_post + beta_post - 2)
print(f"MAP: p̂ = {p_map:.4f}")
# MAP: p̂ = 0.6875

# 2. 사후 평균
print(f"사후 평균: {posterior.mean():.4f}")
# 사후 평균: 0.6765

# 3. 95% 신용구간
ci_bayes = posterior.ppf([0.025, 0.975])
print(f"95% 신용구간: [{ci_bayes[0]:.4f}, {ci_bayes[1]:.4f}]")
# 95% 신용구간: [0.5129, 0.8204]

# 4. "p > 0.5일 확률" — 베이지안에서만 가능한 직접적 확률 진술
prob_biased = 1 - posterior.cdf(0.5)
print(f"P(p > 0.5 | data) = {prob_biased:.4f}")
# P(p > 0.5 | data) = 0.9825

# 5. "p가 0.45~0.55 사이일 확률" (거의 공정한 동전)
prob_fair = posterior.cdf(0.55) - posterior.cdf(0.45)
print(f"P(0.45 < p < 0.55 | data) = {prob_fair:.4f}")
# P(0.45 < p < 0.55 | data) = 0.0587

베이지안 결론: $P(p > 0.5 \mid \text{data}) \approx 0.98$ — 이 동전이 앞면 쪽으로 편향되었을 확률이 약 98%다. “p가 0.45에서 0.55 사이(거의 공정)“일 확률은 약 6%에 불과하다.

비교 요약

	빈도주의	베이지안
점추정	$\hat{p}=0.70$	MAP=0.69, 평균=0.68
구간추정	CI: [0.54, 0.86]	CrI: [0.51, 0.82]
검정	p-value=0.028 (기각)	$P(p>0.5\mid\text{data})=0.98$
해석	“이 절차가 장기적으로 참을 포함할 확률 95%”	“p가 이 구간에 있을 확률 95%”

베이지안 점추정(0.68~0.69)이 MLE(0.70)보다 약간 작은 이유는 $\text{Beta}(2,2)$ 사전분포가 0.5 방향으로 수축(shrinkage)시키기 때문이다. 신용구간이 신뢰구간보다 약간 좁은 것도 사전분포가 추가 정보를 제공한 결과다.

마치며: 추론 시리즈를 돌아보며

이 글로 stats-inference 시리즈가 완결된다. 14편에 걸친 여정을 돌아보자.

확률의 기초에서 표본 공간과 확률 공리를 정의하며 출발했고, 조건부 확률과 베이즈 정리에서 정보가 확률을 바꾸는 메커니즘을 처음 만났다. 확률변수와 기댓값, 이산 분포, 연속 분포를 거치며 불확실성을 수학적으로 모델링하는 언어를 익혔고, 대수의 법칙과 중심극한정리에서 표본과 모집단을 잇는 다리를 놓았다.

이 토대 위에서 추론의 도구들이 하나씩 쌓였다. 점추정으로 “좋은 추정량이란 무엇인가”라는 근본 질문을 던졌고, MLE로 추정량을 체계적으로 찾는 방법을 배웠다. 구간추정으로 불확실성을 구간으로 표현하는 법을, 가설검정과 검정 방법들로 의사결정의 틀을 완성했다. 부트스트랩에서는 분포 가정이 어려울 때의 비모수적 우회로까지 확보했다. 이 모든 것이 빈도주의 패러다임 안에서의 이야기였다.

그리고 이 마지막 글에서, 같은 추론 문제를 전혀 다른 관점으로 바라보는 법을 배웠다. 사전 지식과 데이터를 결합하는 베이지안 관점에서는, 사후분포라는 하나의 객체 안에 점추정, 구간추정, 검정이 모두 녹아 있다. 통계적 추론의 통합적 프레임워크라 할 만하다.

흔히 빠지는 함정들

시리즈를 마무리하기 전에, 베이지안 추론에서 자주 만나는 오해와 실수를 짚고 넘어가자.

“사전분포가 주관적이라 신뢰할 수 없다” — 가장 흔한 비판이다. 하지만 빈도주의도 완전히 객관적이지는 않다. 모델 선택, 유의수준 설정, 단측/양측 검정의 선택 모두 분석자의 판단이다. 사전분포는 이 판단을 명시적으로 드러낸다는 점에서 오히려 투명하다. 데이터가 충분히 많으면 합리적인 사전분포 사이의 차이는 사라진다.

MCMC 수렴 진단을 무시하는 실수도 흔하다. 체인이 수렴하지 않았다면 결과는 의미 없다. 반드시 확인해야 할 세 가지가 있다:

Trace plot: 체인이 하나의 영역에 안정적으로 머무르는지 시각적으로 확인
$\hat{R}$ (R-hat): 여러 체인 간 분산과 체인 내 분산의 비율. $\hat{R} < 1.01$ 이면 수렴으로 판단
유효 표본 크기(ESS): 자기상관을 고려한 실질적 독립 표본 수. 최소 수백 이상 확보

⚠️ 수렴하지 않은 MCMC는 쓰레기다

“5만 개 샘플을 뽑았으니 충분하다”는 위험한 가정이다. 체인이 사후분포의 일부 영역에만 갇혀 있을 수 있다(multi-modality). 반드시 trace plot을 확인하고, 서로 다른 시작점의 여러 체인을 돌려서 $\hat{R}$ 을 계산하라. PyMC와 Stan은 이 진단을 자동으로 수행한다.

사전분포와 우도의 스케일 불일치 역시 주의해야 한다. 사전분포가 우도와 완전히 다른 영역을 커버하면 MCMC가 효율적으로 탐색하지 못한다. 데이터가 $\theta \approx 100$ 근처를 가리키는데 사전분포가 $N(0, 1)$ 이면 사후분포의 밀도가 극히 낮은 영역만 헤매게 된다.

마지막으로, 베이지안이 항상 더 나은 것은 아니다. 사전분포를 잘못 설정하면 MLE보다 못한 결과를 낼 수 있고, 데이터가 충분히 많으면 빈도주의 방법이 계산적으로 유리하면서 결과도 거의 동일하다.

두 패러다임, 하나의 도구 상자

빈도주의와 베이지안 중 하나가 옳고 하나가 틀린 것이 아니다. 모수를 상수로 보는 관점과 확률변수로 보는 관점은 서로 다른 철학이며, 각각이 더 자연스러운 문제 영역이 있다. 두 도구를 모두 이해하고 상황에 맞게 선택할 수 있다면, 여러분은 훨씬 유연한 데이터 분석자가 될 것이다.

다음 시리즈 **stats-applied(응용 통계)**에서는 이 추론 도구들을 실전에 적용한다. 탐색적 데이터 분석(EDA), 표본 추출 설계, A/B 테스트, 그리고 통계적 함정들 — 이론이 현실과 만나는 지점을 다룰 예정이다.

참고자료

Gelman, A. et al. Bayesian Data Analysis (3rd ed.). Chapman & Hall/CRC, 2013. — 베이지안 통계의 표준 교재
McElreath, R. Statistical Rethinking (2nd ed.). CRC Press, 2020. — 직관적 설명과 R/Stan 실습
Kruschke, J. Doing Bayesian Data Analysis (2nd ed.). Academic Press, 2014. — “Puppy Book”으로 불리는 실용 입문서
Murphy, K. Probabilistic Machine Learning: An Introduction. MIT Press, 2022. — ML 관점의 베이지안 접근
PyMC Documentation — Python 베이지안 모델링 공식 문서

부트스트랩(Bootstrap): 분포를 모를 때, 데이터가 스스로 답한다

Donhyeok Kang — Sat, 21 Feb 2026 00:00:00 GMT

이전 글에서 t-검정, 카이제곱 검정, ANOVA 등 다양한 검정 방법을 다뤘다. 이 방법들에는 공통점이 하나 있다. 검정통계량의 분포를 이론적으로 알고 있어야 한다는 것이다. 표본 평균은 정규분포, 분산비는 F분포, 빈도 차이는 카이제곱분포를 따른다는 가정 위에서 p-value를 계산했다.

그런데 현실은 그렇게 깔끔하지 않다. 중앙값의 표준오차는? 두 상관계수의 차이에 대한 신뢰구간은? 분포가 극단적으로 비대칭일 때 평균의 신뢰구간은? 이론적 분포를 유도하기 어렵거나 불가능한 경우가 수두룩하다.

1979년, Bradley Efron은 놀랍도록 단순한 아이디어를 제안했다. “표본 자체를 모집단처럼 취급하고, 거기서 반복 추출하면 통계량의 분포를 근사할 수 있다.” 이것이 **부트스트랩(Bootstrap)**이다.

부트스트랩의 핵심 아이디어

우리가 원하는 것

점추정에서 배웠듯, 추정량 $\hat{\theta}$ 는 확률변수다. 같은 모집단에서 표본을 반복 추출하면, 매번 다른 $\hat{\theta}$ 값이 나온다. 이 **추정량의 분포(Sampling Distribution)**를 알면 신뢰구간도, 가설검정도 가능하다.

문제는 모집단에서 반복 추출하는 것이 현실에서는 불가능하다는 점이다. 표본은 딱 하나뿐이다.

플러그인 원리

부트스트랩의 핵심은 **플러그인 원리(Plug-in Principle)**다.

모집단 분포 $F$ 를 모르니까, 관측된 표본에서 만든 경험적 분포 함수(Empirical Distribution Function, EDF) $\hat{F}_n$ 으로 대체한다.

경험적 분포 함수란 단순하다. $n$ 개의 관측값 $x_1, x_2, \ldots, x_n$ 이 있을 때, 각 관측값에 $1/n$ 의 확률을 부여하는 이산 분포다.

$\hat{F}_n(x) = \frac{1}{n} \sum_{i=1}^{n} \mathbf{1}(X_i \le x)$

이 분포에서 크기 $n$ 의 표본을 **복원 추출(Sampling with Replacement)**하는 것이 부트스트랩의 핵심 연산이다. 복원 추출이므로 같은 관측값이 여러 번 뽑히기도 하고, 한 번도 안 뽑히는 관측값도 생긴다.

💡 왜 복원 추출인가?

비복원 추출로 $n$ 개를 뽑으면 원래 표본과 완전히 동일한 집합이 된다. 복원 추출이어야 매번 다른 구성의 표본이 만들어지고, 그로부터 통계량의 변동성을 추정할 수 있다. 평균적으로 한 번의 부트스트랩 표본에는 원래 관측값의 약 63.2%만 포함된다 ( $1 - (1 - 1/n)^n \approx 1 - e^{-1}$ ).

부트스트랩의 논리 구조

정리하면, 부트스트랩은 다음과 같은 유추에 기반한다.

이상적 세계	부트스트랩 세계
모집단 분포 $F$	경험적 분포 $\hat{F}_n$
모집단에서 크기 $n$ 표본 추출	$\hat{F}_n$ 에서 크기 $n$ 복원 추출
통계량 $\hat{\theta}$ 의 표집 분포	부트스트랩 통계량 $\hat{\theta}^*$ 의 분포
표준오차 $\text{SE}(\hat{\theta})$	부트스트랩 표준오차 $\text{SE}_{boot}$

$\hat{F}_n$ 이 $F$ 를 잘 근사한다면 (표본이 충분히 크다면), 부트스트랩 분포는 실제 표집 분포를 잘 근사한다. 이 근사가 정당화되는 이론적 배경은 큰 수의 법칙과 중심극한정리에서 다룬 Glivenko-Cantelli 정리 — $\hat{F}_n$ 이 $F$ 에 균등 수렴한다는 결과 — 에 뿌리를 두고 있다.

부트스트랩 알고리즘

의사코드

부트스트랩 알고리즘은 놀라울 정도로 단순하다.

입력: 원본 표본 x = (x₁, x₂, ..., xₙ), 반복 횟수 B, 통계량 함수 θ̂(·)
출력: 부트스트랩 분포 {θ̂*₁, θ̂*₂, ..., θ̂*_B}

1. for b = 1, 2, ..., B:
     a. x*ᵇ ← x에서 크기 n을 복원 추출
     b. θ̂*ᵇ ← θ̂(x*ᵇ)   # 부트스트랩 표본에 통계량 적용
2. return {θ̂*₁, θ̂*₂, ..., θ̂*_B}

이 분포로부터 표준오차, 신뢰구간, 편향 등을 계산한다.

Python 직접 구현

통계량이 중앙값인 경우를 구현해보겠다. 중앙값은 이론적 표준오차 공식이 복잡한 대표적인 통계량이다.

import numpy as np

np.random.seed(42)

# 비대칭 분포에서 표본 생성 (지수분포: 오른쪽 꼬리)
data = np.random.exponential(scale=2.0, size=50)
observed_median = np.median(data)
print(f"관측된 중앙값: {observed_median:.4f}")

# 부트스트랩
B = 10_000
n = len(data)
boot_medians = np.empty(B)

for b in range(B):
    boot_sample = np.random.choice(data, size=n, replace=True)
    boot_medians[b] = np.median(boot_sample)

# 부트스트랩 표준오차
boot_se = np.std(boot_medians, ddof=1)
print(f"부트스트랩 표준오차: {boot_se:.4f}")

# 부트스트랩 편향
boot_bias = np.mean(boot_medians) - observed_median
print(f"부트스트랩 편향 추정: {boot_bias:.4f}")

관측된 중앙값: 1.1456
부트스트랩 표준오차: 0.2727
부트스트랩 편향 추정: -0.0303

np.random.choice에 replace=True만 지정하면 복원 추출이 된다. 10,000번의 재표본 추출과 중앙값 계산 — 이게 부트스트랩의 전부다.

B는 얼마로 해야 할까?

반복 횟수 $B$ 의 선택에 대한 가이드라인은 다음과 같다.

목적	권장 $B$
표준오차 추정	1,000 이상
신뢰구간 (백분위법)	5,000 이상
BCa 신뢰구간	10,000 이상
정밀한 p-value	10,000~100,000

$B$ 를 늘리면 부트스트랩 분포의 추정이 정밀해지지만, 원본 표본 $n$ 의 한계를 넘어설 수는 없다. 부트스트랩의 정확도는 궁극적으로 $n$ 에 의해 제한된다.

부트스트랩 신뢰구간 3종 비교

부트스트랩 분포를 구했으면 신뢰구간을 구성할 수 있다. 방법이 여러 가지인데, 각각의 특성이 다르다.

1. 백분위 방법 (Percentile Method)

가장 직관적인 방법이다. 부트스트랩 분포의 양쪽 $\alpha/2$ 분위수를 그대로 신뢰구간 경계로 사용한다.

$CI_{1-\alpha} = \left[ \hat{\theta}^*_{\alpha/2}, \quad \hat{\theta}^*_{1-\alpha/2} \right]$

alpha = 0.05
ci_percentile = np.percentile(boot_medians, [100 * alpha/2, 100 * (1 - alpha/2)])
print(f"백분위 95% CI: [{ci_percentile[0]:.4f}, {ci_percentile[1]:.4f}]")

백분위 95% CI: [0.6910, 1.6317]

간단하지만, 추정량에 편향이 있거나 분포가 비대칭이면 커버리지가 이론적 수준(예: 95%)에 못 미칠 수 있다.

2. 기본 방법 (Basic/Pivotal Method)

피벗(pivot) 아이디어에 기반한다. 부트스트랩에서 추정한 ” $\hat{\theta}^* - \hat{\theta}$ 의 분포”를 이용해 $\theta - \hat{\theta}$ 의 분포를 근사한다.

$CI_{1-\alpha} = \left[ 2\hat{\theta} - \hat{\theta}^*_{1-\alpha/2}, \quad 2\hat{\theta} - \hat{\theta}^*_{\alpha/2} \right]$

ci_basic = [
    2 * observed_median - np.percentile(boot_medians, 100 * (1 - alpha/2)),
    2 * observed_median - np.percentile(boot_medians, 100 * alpha/2)
]
print(f"기본(피벗) 95% CI: [{ci_basic[0]:.4f}, {ci_basic[1]:.4f}]")

기본(피벗) 95% CI: [0.6596, 1.6002]

백분위 방법보다 이론적으로 우수하지만, 여전히 편향에 취약하다.

3. BCa 방법 (Bias-Corrected and Accelerated)

가장 정교한 방법이다. 편향 보정(bias correction)과 가속 계수(acceleration)를 도입하여 백분위 방법의 한계를 극복한다.

BCa는 두 가지 보정을 적용한다.

편향 보정 상수 $\hat{z}_0$ : 부트스트랩 분포의 중심이 원래 추정값에서 얼마나 벗어나 있는지 측정
가속 상수 $\hat{a}$ : 표준오차가 모수값에 따라 변하는 정도를 반영 (jackknife로 추정)

$\hat{z}_0 = \Phi^{-1}\left(\frac{\#\{\hat{\theta}^*_b < \hat{\theta}\}}{B}\right)$

$\hat{a} = \frac{\sum_{i=1}^{n}(\hat{\theta}_{(\cdot)} - \hat{\theta}_{(i)})^3}{6\left[\sum_{i=1}^{n}(\hat{\theta}_{(\cdot)} - \hat{\theta}_{(i)})^2\right]^{3/2}}$

보정된 분위수 $\alpha_1, \alpha_2$ 를 계산한 뒤 백분위법을 적용한다.

$\alpha_1 = \Phi\left(\hat{z}_0 + \frac{\hat{z}_0 + z_{\alpha/2}}{1 - \hat{a}(\hat{z}_0 + z_{\alpha/2})}\right)$

from scipy import stats

# 편향 보정 상수
z0 = stats.norm.ppf(np.mean(boot_medians < observed_median))

# 가속 상수 (jackknife)
jackknife_medians = np.empty(n)
for i in range(n):
    jack_sample = np.delete(data, i)
    jackknife_medians[i] = np.median(jack_sample)

jack_mean = np.mean(jackknife_medians)
num = np.sum((jack_mean - jackknife_medians) ** 3)
den = 6.0 * (np.sum((jack_mean - jackknife_medians) ** 2)) ** 1.5
a_hat = num / den

# 보정된 분위수 계산
z_alpha_low = stats.norm.ppf(alpha / 2)
z_alpha_high = stats.norm.ppf(1 - alpha / 2)

alpha1 = stats.norm.cdf(z0 + (z0 + z_alpha_low) / (1 - a_hat * (z0 + z_alpha_low)))
alpha2 = stats.norm.cdf(z0 + (z0 + z_alpha_high) / (1 - a_hat * (z0 + z_alpha_high)))

ci_bca = np.percentile(boot_medians, [100 * alpha1, 100 * alpha2])
print(f"BCa 95% CI: [{ci_bca[0]:.4f}, {ci_bca[1]:.4f}]")

BCa 95% CI: [0.6897, 1.5824]

방법 비교 요약

방법	장점	단점	권장 상황
백분위 (Percentile)	구현 간단, 직관적	편향·비대칭에 취약	빠른 탐색적 분석
기본 (Basic/Pivotal)	피벗 이론 기반	여전히 편향에 민감	대칭 분포일 때
BCa	편향·비대칭 보정, 2차 정확도	계산 비용 높음, jackknife 필요	최종 보고용, 비대칭 통계량

💡 2차 정확도란?

표준 정규 근사의 신뢰구간은 오차가 $O(n^{-1/2})$ 인 반면, BCa 방법은 $O(n^{-1})$ 로 수렴한다. 이를 “second-order accurate”라 하며, 같은 표본 크기에서도 실제 커버리지가 명목 수준(95%)에 더 가깝다.

부트스트랩이 작동하는 이유

직관적 설명

부트스트랩이 작동하는 이유를 한 문장으로 요약하면 이렇다.

표본이 모집단을 잘 대표한다면, 표본에서의 재추출은 모집단에서의 추출을 잘 모방한다.

$n$ 이 커질수록 경험적 분포 $\hat{F}_n$ 은 진짜 분포 $F$ 에 가까워진다. Glivenko-Cantelli 정리에 의해 $\sup_x |\hat{F}_n(x) - F(x)| \to 0$ (거의 확실히)이므로, $\hat{F}_n$ 에서 계산한 통계량의 분포도 $F$ 에서 계산한 분포에 수렴한다.

💡 Glivenko-Cantelli 정리가 말하는 것

표본이 충분히 크면, 경험적 분포 함수 $\hat{F}_n$ 은 모든 지점에서 동시에 진짜 분포 $F$ 에 수렴한다. 이는 단순히 “평균이 비슷해진다”는 수준이 아니라, 분포 전체의 형태가 일치해간다는 훨씬 강한 보장이다. 부트스트랩이 단순한 트릭이 아니라 수학적으로 정당화되는 근거가 바로 여기에 있다.

CLT와의 관계

중심극한정리는 표본 평균의 분포가 정규분포에 수렴한다고 말한다. 부트스트랩은 이보다 일반적이다.

CLT: 표본 평균(또는 합)에만 적용. 정규 근사.
부트스트랩: 어떤 통계량이든 적용 가능. 분포를 직접 근사.

CLT가 적용되는 상황에서는 부트스트랩과 정규 근사의 결과가 거의 일치한다. 부트스트랩의 진가는 CLT를 적용하기 어려운 통계량(중앙값, 분위수, 상관계수 등)에서 발휘된다.

부트스트랩 검정

부트스트랩으로 p-value 구하기

부트스트랩은 신뢰구간뿐 아니라 가설검정에도 쓸 수 있다. 핵심 아이디어는 귀무가설 하에서 검정통계량의 분포를 부트스트랩으로 근사하는 것이다.

예를 들어, “모집단 중앙값이 1.5인가?”를 검정한다고 하자.

# H0: 모집단 중앙값 = 1.5 (theta_0)
theta_0 = 1.5

# 관측된 검정통계량: 표본 중앙값 - 귀무가설 값
observed_stat = observed_median - theta_0

# 귀무가설 하에서의 부트스트랩: 데이터를 theta_0 중심으로 이동
data_shifted = data - observed_median + theta_0

B = 10_000
boot_stats = np.empty(B)
for b in range(B):
    boot_sample = np.random.choice(data_shifted, size=n, replace=True)
    boot_stats[b] = np.median(boot_sample) - theta_0

# 양측 p-value
p_value = np.mean(np.abs(boot_stats) >= np.abs(observed_stat))
print(f"부트스트랩 p-value: {p_value:.4f}")

부트스트랩 p-value: 0.2258

p-value가 크므로 귀무가설을 기각하지 못한다. 관측된 중앙값(1.1456)이 1.5와 유의미하게 다르지 않다.

순열 검정과의 비교

두 그룹 비교에서는 **순열 검정(Permutation Test)**이 더 자주 쓰인다. 둘의 차이를 정리하면 다음과 같다.

	부트스트랩 검정	순열 검정
재표본 방식	복원 추출	라벨 섞기 (비복원)
귀무가설	유연하게 설정 가능	“두 그룹의 분포가 동일”
주 용도	신뢰구간 + 검정	두 그룹 비교 검정
정확 검정	근사적	정확(exact, $n$ 이 작을 때)

Python 실습: scipy.stats.bootstrap

직접 구현도 좋지만, SciPy 1.9+에는 scipy.stats.bootstrap이 내장되어 있다. BCa 방법까지 지원하므로 실무에서는 이것을 쓰는 것이 안전하다.

from scipy.stats import bootstrap

np.random.seed(42)
data = np.random.exponential(scale=2.0, size=50)

# scipy.stats.bootstrap는 튜플로 감싸야 한다
result = bootstrap(
    data=(data,),
    statistic=np.median,
    n_resamples=10_000,
    confidence_level=0.95,
    method='BCa',   # 'percentile', 'basic', 'BCa'
    random_state=42
)

print(f"BCa 95% CI: [{result.confidence_interval.low:.4f}, "
      f"{result.confidence_interval.high:.4f}]")
print(f"부트스트랩 표준오차: {result.standard_error:.4f}")

BCa 95% CI: [0.6910, 1.6887]
부트스트랩 표준오차: 0.2756

직접 구현한 결과와 동일하다. method 파라미터만 바꾸면 세 가지 방법을 모두 적용할 수 있다.

커버리지 시뮬레이션

부트스트랩 신뢰구간이 실제로 95% 커버리지를 달성하는지 시뮬레이션으로 확인해보겠다.

from scipy.stats import bootstrap

np.random.seed(0)
true_median = np.log(2) * 2.0  # 지수분포 중앙값 = ln(2) × scale

n_sim = 500
B = 5_000
coverage = {'percentile': 0, 'basic': 0, 'BCa': 0}

for sim in range(n_sim):
    sample = np.random.exponential(scale=2.0, size=50)

    for method in coverage:
        res = bootstrap(
            data=(sample,),
            statistic=np.median,
            n_resamples=B,
            confidence_level=0.95,
            method=method,
            random_state=sim
        )
        ci = res.confidence_interval
        if ci.low <= true_median <= ci.high:
            coverage[method] += 1

for method, count in coverage.items():
    print(f"{method:>12}: {count/n_sim*100:.1f}%")

  percentile: 91.4%
       basic: 92.0%
         BCa: 94.2%

BCa가 명목 수준 95%에 가장 가깝다. 백분위 방법은 지수분포처럼 비대칭 분포에서 커버리지가 떨어지는 것을 확인할 수 있다. 이것이 최종 보고에는 BCa를 권장하는 이유다.

⚠️ 시뮬레이션 주의사항

위 시뮬레이션은 500회 반복으로 실행했다. 실제 커버리지 검증에는 1,000회 이상이 필요하며, B도 10,000 이상으로 설정해야 정밀한 결과를 얻을 수 있다. 실행 시간이 오래 걸릴 수 있으므로 주의하자.

부트스트랩의 한계

부트스트랩이 만능은 아니다. 다음과 같은 경우에는 주의가 필요하다.

⚠️ 부트스트랩이 실패하는 상황

(1) 극값 통계량(최댓값, 최솟값) — 복원 추출의 구조적 한계로 분포 근사 불가 (2) 극소 표본( $n < 10$ ) — 경험적 분포가 모집단을 대표하지 못함 (3) 비정칙 문제 — 모수가 공간의 경계에 있거나 수렴 속도가 $\sqrt{n}$ 이 아닌 경우 (4) 시계열·공간 데이터 — i.i.d. 가정 위반 시 표준 부트스트랩은 의존 구조를 파괴함

작동하지 않는 경우

1. 극값 통계량 (Extreme Order Statistics)

표본 최댓값 $X_{(n)}$ 의 분포를 부트스트랩으로 추정하면 실패한다. 복원 추출에서 원본의 최댓값이 그대로 뽑힐 확률이 $1 - (1 - 1/n)^n \approx 0.632$ 로 매우 높기 때문에, 부트스트랩 분포가 진짜 분포를 근사하지 못한다.

2. 표본 크기가 너무 작을 때

$n < 10$ 정도의 극단적으로 작은 표본에서는 $\hat{F}_n$ 이 $F$ 를 제대로 대표하지 못한다. 부트스트랩이 만들어내는 다양성이 제한적이므로, 결과를 신뢰하기 어렵다.

3. 비정칙(Non-regular) 문제

모수가 모수 공간의 경계에 있을 때(예: 균일분포 $U(0, \theta)$ 에서 $\theta$ 추정), 수렴 속도가 일반적인 $\sqrt{n}$ 이 아닌 경우 표준 부트스트랩이 실패할 수 있다.

시계열 데이터: 블록 부트스트랩

표준 부트스트랩은 관측값이 **독립(i.i.d.)**이라고 가정한다. 시계열 데이터는 자기상관(autocorrelation)이 있으므로 관측값을 무작위로 섞으면 시간 구조가 파괴된다.

이 문제를 해결하기 위해 **블록 부트스트랩(Block Bootstrap)**이 제안되었다.

비중첩 블록 부트스트랩 (Non-overlapping Block Bootstrap): 시계열을 고정 길이 블록으로 나누고, 블록 단위로 복원 추출
이동 블록 부트스트랩 (Moving Block Bootstrap): 겹치는 블록을 사용하여 블록 경계 효과를 완화
정상 부트스트랩 (Stationary Bootstrap): 블록 길이를 기하분포에서 랜덤하게 추출

블록 부트스트랩은 시계열의 국소 의존 구조를 보존하면서도 재표본 추출의 이점을 살린다.

ML에서의 부트스트랩: 배깅의 기반

부트스트랩은 통계적 추론을 넘어 머신러닝의 핵심 기법인 **배깅(Bagging, Bootstrap Aggregating)**의 이론적 기반이기도 하다.

Leo Breiman(1996)이 제안한 배깅은 다음과 같다.

1. 훈련 데이터에서 B개의 부트스트랩 표본을 생성
2. 각 부트스트랩 표본으로 독립적인 모델을 학습
3. B개 모델의 예측을 평균(회귀) 또는 다수결(분류)로 집계

이것이 통계적 부트스트랩과 정확히 같은 구조다. 부트스트랩 표본마다 통계량을 계산하는 대신 모델을 학습하는 것만 다르다.

# 통계 부트스트랩 vs ML 배깅 — 구조적 동일성
# 통계: θ̂*_b = median(bootstrap_sample_b)    → {θ̂*_1, ..., θ̂*_B}의 분포
# ML:   f̂_b  = DecisionTree(bootstrap_sample_b)  → (1/B)Σf̂_b(x)로 예측

Random Forest는 배깅에 “특성 랜덤 선택”을 추가한 것이다. 즉, 부트스트랩 → 배깅 → 랜덤 포레스트로 이어지는 계보가 있다. 이 내용은 ML 시리즈에서 더 자세히 다룬다.

💡 부트스트랩의 두 가지 얼굴

통계에서 부트스트랩은 불확실성을 정량화하기 위해 쓰인다 (표준오차, 신뢰구간). ML에서 부트스트랩은 분산을 줄이기 위해 쓰인다 (배깅). 같은 재표본 추출 기법이 목적에 따라 완전히 다른 역할을 하는 셈이다.

OOB (Out-of-Bag) 추정

앞서 부트스트랩 표본에 포함되지 않는 관측값이 약 36.8% 존재한다고 했다. 배깅에서는 이 **빠진 관측값(Out-of-Bag, OOB)**을 검증 데이터로 활용한다. 별도의 검증 세트 없이도 모델의 일반화 오차를 추정할 수 있는 것이다. 이는 교차 검증(Cross-Validation)의 대안으로도 쓰인다.

마치며

부트스트랩은 빈도주의 추론의 마지막 무기다. 분포 가정이 불확실할 때, 이론적 공식을 유도하기 어려울 때, 데이터 자체에서 답을 찾는다. 플러그인 원리라는 단순한 아이디어 위에, 컴퓨터의 계산 능력을 얹은 결과다.

지금까지의 여정을 돌아보면 — 점추정에서 모수를 하나의 값으로 추정하고, 신뢰구간으로 불확실성을 정량화하고, 가설검정으로 의사결정을 하고, 이제 부트스트랩으로 분포 가정의 족쇄에서 벗어났다. 이것이 빈도주의(Frequentist) 패러다임이 제공하는 추론 도구의 전모다.

그런데 빈도주의에는 근본적인 한계가 있다. 데이터가 주어졌을 때 모수에 대해 직접 확률적 진술을 할 수 없다는 것이다. “이 모수가 3과 5 사이일 확률이 95%“라고 말하고 싶지만, 빈도주의 신뢰구간은 그런 해석을 허용하지 않는다.

다음 글에서는 완전히 다른 패러다임에 들어선다. 모수를 확률변수로 취급하고, 사전 정보와 데이터를 결합하여 사후 분포를 얻는 베이지안 추론(Bayesian Inference) — 통계의 또 다른 세계가 열린다.

참고자료

Efron, B. (1979). “Bootstrap Methods: Another Look at the Jackknife.” The Annals of Statistics, 7(1), 1-26.
Efron, B., & Tibshirani, R. J. (1993). An Introduction to the Bootstrap. Chapman & Hall/CRC.
Davison, A. C., & Hinkley, D. V. (1997). Bootstrap Methods and their Application. Cambridge University Press.
DiCiccio, T. J., & Efron, B. (1996). “Bootstrap Confidence Intervals.” Statistical Science, 11(3), 189-228.
SciPy Documentation: scipy.stats.bootstrap

t-검정, ANOVA, 카이제곱 검정: 상황별 검정 방법 선택 가이드

Donhyeok Kang — Fri, 20 Feb 2026 00:00:00 GMT

이전 글에서 가설검정의 프레임워크를 세웠다. 귀무가설과 대립가설, p-value의 의미, 유의수준, 1종·2종 오류. 이제 검정이 무엇인지는 안다. 그런데 실제 데이터 앞에 앉으면 가장 먼저 드는 질문은 이것이다 — “어떤 검정을 써야 하지?”

A/B 테스트에서 전환율 차이를 보려면? 세 가지 교육 프로그램의 효과를 비교하려면? 설문 응답 분포가 기대와 다른지 확인하려면? 상황마다 적합한 검정 방법이 다르고, 잘못된 검정을 쓰면 결론 자체가 틀어진다.

이 글은 상황별 검정 방법 선택의 로드맵이다. 플로차트 하나로 전체 그림을 잡고, 각 검정의 원리와 Python 구현을 하나씩 짚어간다.

검정 방법 선택 플로차트

데이터를 보고 검정 방법을 고르는 판단 기준은 세 가지다: (1) 데이터 유형, (2) 비교할 집단 수, (3) 표본 간 관계. 이 세 축만 파악하면 어떤 검정을 쓸지 거의 자동으로 결정된다.

                        데이터 유형은?
                     ┌──────┴──────┐
                   연속형          범주형
                     │               │
               집단 수는?        ┌───┴───┐
            ┌────┼────┐      적합도    독립성
            1    2    3+     검정      검정
            │    │    │       │         │
         단일   독립/  ANOVA  카이제곱   카이제곱
        표본   대응?   (F)   적합도    독립성
        t-검정  │             검정      검정
            ┌──┴──┐
          독립   대응
           │      │
       독립 표본  대응 표본
       t-검정    t-검정
       (Welch)

  ※ 정규성 가정 불만족 시 → 비모수 검정으로 대체
     · 독립 2집단: Mann-Whitney U
     · 대응 2집단: Wilcoxon signed-rank
     · 3집단 이상: Kruskal-Wallis

이 플로차트를 머릿속에 넣어두면, 나머지는 각 검정의 구체적인 메커니즘을 이해하는 일이다. 아래 표로 전체 검정 방법을 한눈에 정리해두자 — 글을 읽는 동안 레퍼런스로 돌아와도 좋다.

검정 방법	데이터 유형	집단 수	표본 관계	귀무가설	scipy 함수
단일 표본 t-검정	연속	1	—	$\mu = \mu_0$	`ttest_1samp`
독립 표본 t-검정 (Welch)	연속	2	독립	$\mu_1 = \mu_2$	`ttest_ind(equal_var=False)`
대응 표본 t-검정	연속	2	대응	$\mu_d = 0$	`ttest_rel`
일원 ANOVA	연속	3+	독립	$\mu_1 = \cdots = \mu_k$	`f_oneway`
카이제곱 적합도	범주	1	—	관측 = 기대 분포	`chisquare`
카이제곱 독립성	범주	2변수	—	두 변수 독립	`chi2_contingency`
Mann-Whitney U	연속(비모수)	2	독립	동일 분포	`mannwhitneyu`
Wilcoxon signed-rank	연속(비모수)	2	대응	차이 대칭	`wilcoxon`
Kruskal-Wallis	연속(비모수)	3+	독립	동일 분포	`kruskal`

그렇다면 플로차트의 왼쪽 가지, 연속형 데이터의 검정부터 시작하자. 가장 기본이 되는 t-검정이다.

t-검정(t-test): 평균의 차이를 검증하는 세 가지 방법

t-검정은 평균에 대한 가설검정의 기본 도구다. 비교 대상과 표본 구조에 따라 세 가지 변형이 있는데, 각각의 쓰임새가 뚜렷이 다르다.

단일 표본 t-검정 (One-Sample t-test)

언제 쓰는가. “이 집단의 평균이 특정 값과 같은가?”를 검정할 때 사용한다. 비교 대상이 다른 집단이 아니라 이미 알려진 기준값이다.

배터리 공정에서 평균 수명이 사양서의 1000시간과 같은가?
학생들의 평균 점수가 전국 평균 75점과 다른가?

표본 평균 $\bar{X}$ 와 기준값 $\mu_0$ 사이의 차이를 표준오차로 나눈 값이 t-통계량이다.

$t = \frac{\bar{X} - \mu_0}{s / \sqrt{n}}$

여기서 $s$ 는 표본 표준편차, $n$ 은 표본 크기다. 귀무가설 $H_0: \mu = \mu_0$ 하에서, 이 통계량은 자유도 $n - 1$ 인 t-분포를 따른다.

왜 z가 아니라 t인가?

모분산 $\sigma^2$ 를 모르기 때문이다. $\sigma$ 대신 표본 표준편차 $s$ 를 쓰면 불확실성이 한 겹 더 추가되고, 이를 반영한 분포가 t-분포다. 표본이 커지면 t-분포는 정규분포에 수렴한다.

배터리 수명 데이터로 확인해보자. 사양서의 기준값 1000시간에 대해 검정한다.

import numpy as np
from scipy import stats

np.random.seed(42)

# 상황: 배터리 수명 사양 = 1000시간, 표본 20개의 수명 데이터
battery_life = np.random.normal(loc=1020, scale=50, size=20)

# 단일 표본 t-검정: H₀: μ = 1000
t_stat, p_value = stats.ttest_1samp(battery_life, popmean=1000)

print(f"표본 평균: {battery_life.mean():.1f}")
print(f"t-통계량: {t_stat:.4f}")
print(f"p-value:  {p_value:.4f}")
# 표본 평균: 1011.4
# t-통계량: 1.0654
# p-value:  0.3001
# → p > 0.05이므로 귀무가설을 기각하지 못한다 (사양과 다르다는 증거 불충분)

p-value가 0.30으로, 사양과 다르다는 근거가 부족하다. 그런데 만약 비교 대상이 기준값이 아니라 다른 집단이라면 어떻게 할까?

독립 표본 t-검정 (Independent Two-Sample t-test)

언제 쓰는가. 서로 다른 두 집단의 평균을 비교할 때 사용한다. 두 집단의 구성원이 완전히 다른, 즉 독립적인 상황이다.

신약 투여 그룹 vs 위약 그룹의 혈압 차이
A/B 테스트에서 디자인 A vs B의 평균 체류 시간

등분산 vs 이분산: Welch’s t-test. 전통적인 독립 표본 t-검정은 두 집단의 분산이 같다고 가정한다(등분산 가정). 하지만 현실에서 두 집단의 분산이 정확히 같을 이유가 없다.

구분	Student’s t-test	Welch’s t-test
분산 가정	$\sigma_1^2 = \sigma_2^2$	$\sigma_1^2 \neq \sigma_2^2$ 허용
자유도	$n_1 + n_2 - 2$	Welch-Satterthwaite 근사
권장 상황	분산 동일이 확실할 때	기본값으로 사용

$t = \frac{\bar{X}_1 - \bar{X}_2}{\sqrt{\frac{s_1^2}{n_1} + \frac{s_2^2}{n_2}}}$

실전 팁

특별한 이유가 없다면 항상 Welch’s t-test를 쓰자. 등분산이 실제로 성립해도 Welch’s t-test의 성능 손실은 미미하지만, 등분산 가정이 깨졌을 때 Student’s t-test는 심각하게 잘못된 결론을 낼 수 있다. scipy의 ttest_ind에서 equal_var=False가 Welch 버전이다.

두 교육 방법의 시험 점수를 비교하는 예제로 확인해보자.

np.random.seed(42)

# 상황: 두 교육 방법의 시험 점수 비교
method_a = np.random.normal(loc=75, scale=10, size=30)
method_b = np.random.normal(loc=80, scale=12, size=35)

# Welch's t-test (equal_var=False)
t_stat, p_value = stats.ttest_ind(method_a, method_b, equal_var=False)

print(f"그룹 A 평균: {method_a.mean():.2f}, 그룹 B 평균: {method_b.mean():.2f}")
print(f"t-통계량: {t_stat:.4f}")
print(f"p-value:  {p_value:.4f}")
# 그룹 A 평균: 73.12, 그룹 B 평균: 78.01
# t-통계량: -1.9804
# p-value:  0.0520
# → 두 교육 방법의 평균 차이가 통계적으로 유의하지 않다 (경계선)

독립 표본 t-검정은 서로 다른 사람들을 비교한다. 한편, 같은 사람을 두 번 측정한 데이터라면 접근이 달라진다.

대응 표본 t-검정 (Paired t-test)

언제 쓰는가. 같은 대상을 두 번 측정한 데이터를 비교할 때 사용한다. 전후 비교, 처치 전/후 비교가 대표적이다.

다이어트 프로그램 전/후 체중
같은 환자에게 두 가지 약을 순서대로 투여한 후 반응 비교

핵심은 각 쌍의 차이값 $d_i = X_{i,\text{after}} - X_{i,\text{before}}$ 을 구한 뒤, 그 차이의 평균이 0인지를 단일 표본 t-검정으로 확인하는 것이다.

$t = \frac{\bar{d}}{s_d / \sqrt{n}}$

여기서 $\bar{d}$ 는 차이의 평균, $s_d$ 는 차이의 표본 표준편차, $n$ 은 쌍의 개수다.

12주 운동 프로그램의 혈압 감소 효과를 검정해보자.

np.random.seed(42)

# 상황: 12주 운동 프로그램 전후 혈압 측정 (같은 사람 15명)
before = np.random.normal(loc=140, scale=15, size=15)
after = before + np.random.normal(loc=-8, scale=10, size=15)  # 평균 8 감소 효과

t_stat, p_value = stats.ttest_rel(before, after)

print(f"전 평균: {before.mean():.1f}, 후 평균: {after.mean():.1f}")
print(f"차이 평균: {(before - after).mean():.1f}")
print(f"t-통계량: {t_stat:.4f}")
print(f"p-value:  {p_value:.4f}")
# 전 평균: 140.2, 후 평균: 128.3
# 차이 평균: 11.9
# t-통계량: 5.9081
# p-value:  0.0000
# → 운동 프로그램이 혈압을 유의하게 감소시켰다

p-value가 0.0001 미만으로, 운동 프로그램의 혈압 감소 효과가 통계적으로 매우 유의하다.

독립 vs 대응, 왜 구분이 중요한가?

대응 표본에 독립 표본 t-검정을 쓰면, 개인 간 변동(사람마다 혈압이 다른 것)이 노이즈로 들어가 검정력이 크게 떨어진다. 대응 검정은 쌍별 차이만 보기 때문에 개인 간 변동을 제거하고, 처치 효과를 더 민감하게 잡아낸다.

일원 분산분석 (One-way ANOVA)

t-검정은 두 집단까지만 다룬다. 비교 대상이 세 개 이상으로 늘어나면 다른 도구가 필요하다.

왜 다중 t-검정을 하면 안 되는가

세 개 이상의 집단을 비교해야 할 때, “A-B, A-C, B-C 각각 t-검정하면 되지 않나?”라는 생각이 자연스럽다. 하지만 이것은 **다중 검정 문제(Multiple Testing Problem)**를 일으킨다.

유의수준 $\alpha = 0.05$ 로 검정 하나를 수행하면, 실제 차이가 없을 때 잘못 기각할 확률이 5%다. 그런데 3번 검정하면?

$P(\text{적어도 하나 잘못 기각}) = 1 - (1 - 0.05)^3 = 0.1426$

검정 횟수가 늘어날수록 1종 오류가 눈덩이처럼 불어난다. 집단이 5개면 10번의 쌍별 비교가 필요하고, 전체 오류율은 40%에 육박한다. 이래서는 “유의하다”는 결론을 신뢰할 수 없다.

ANOVA의 아이디어

**분산분석(ANOVA, Analysis of Variance)**은 이름 그대로 분산을 분석한다. 전체 데이터의 변동을 두 성분으로 분해하는 것이 핵심이다.

$\underbrace{SS_T}_{\text{전체 변동}} = \underbrace{SS_B}_{\text{집단 간 변동}} + \underbrace{SS_W}_{\text{집단 내 변동}}$

$SS_B$ (Between): 각 집단의 평균이 전체 평균에서 얼마나 떨어져 있는가 → 집단 간 차이
$SS_W$ (Within): 각 집단 내부에서 데이터가 얼마나 흩어져 있는가 → 개별 변동(노이즈)

만약 집단 간 차이가 노이즈에 비해 충분히 크면, “적어도 하나의 집단 평균이 다르다”고 결론 내린다.

F-통계량

$F = \frac{SS_B / (k - 1)}{SS_W / (N - k)} = \frac{MS_B}{MS_W}$

$k$ 는 집단 수, $N$ 은 전체 표본 수다. 귀무가설( $\mu_1 = \mu_2 = \cdots = \mu_k$ ) 하에서 F-통계량은 자유도 $(k-1, N-k)$ 인 F-분포를 따른다. F값이 크면 집단 간 차이가 유의하다는 뜻이다.

Python 예제

세 가지 비료의 작물 수확량을 비교해보자.

np.random.seed(42)

# 상황: 세 가지 비료(A, B, C)를 사용한 작물 수확량 비교
fertilizer_a = np.random.normal(loc=20, scale=3, size=25)
fertilizer_b = np.random.normal(loc=22, scale=3, size=25)
fertilizer_c = np.random.normal(loc=24, scale=3, size=25)

# 일원 ANOVA
f_stat, p_value = stats.f_oneway(fertilizer_a, fertilizer_b, fertilizer_c)

print(f"평균 — A: {fertilizer_a.mean():.1f}, B: {fertilizer_b.mean():.1f}, C: {fertilizer_c.mean():.1f}")
print(f"F-통계량: {f_stat:.4f}")
print(f"p-value:  {p_value:.6f}")
# F-통계량: 18.1532
# p-value:  0.000000
# → 적어도 하나의 비료 그룹이 유의하게 다르다

사후 검정: 어디서 차이가 나는가?

ANOVA가 유의하다고 해서 끝이 아니다. ANOVA는 “적어도 하나가 다르다”까지만 알려준다. 어떤 쌍에서 차이가 나는지는 사후 검정(Post-hoc Test)으로 확인해야 한다.

from scipy.stats import tukey_hsd

# Tukey HSD 사후 검정
result = tukey_hsd(fertilizer_a, fertilizer_b, fertilizer_c)
print(result)
# 각 쌍별 비교 결과(신뢰구간, p-value)가 출력된다
# A-B, A-C, B-C 중 어떤 쌍이 유의한 차이를 보이는지 확인할 수 있다

**Tukey HSD(Honestly Significant Difference)**는 모든 쌍별 비교를 하면서도 전체 1종 오류율을 $\alpha$ 로 통제한다. 다중 비교 보정이 내장된 방법이다.

카이제곱 검정(Chi-squared Test): 범주형 데이터의 검정

지금까지는 연속형 데이터, 즉 플로차트의 왼쪽 가지를 다뤘다. 한편 데이터가 범주형이라면 평균을 비교하는 것 자체가 무의미하다. 범주형 데이터에서는 **빈도(frequency)**가 분석의 단위가 되고, 카이제곱 검정이 그 도구다.

카이제곱 적합도 검정 (Chi-squared Goodness-of-Fit Test)

언제 쓰는가. 관측된 범주별 빈도가 이론적으로 기대하는 분포와 일치하는지 검정할 때 사용한다.

주사위를 360번 던졌을 때, 각 눈이 60번씩 나왔는가?
고객 유입 채널 비율이 마케팅 팀이 예상한 비율과 같은가?

검정 통계량은 각 범주에서 관측값과 기대값의 차이를 제곱하고, 기대값으로 나눠서 합산한다.

$\chi^2 = \sum_{i=1}^{k} \frac{(O_i - E_i)^2}{E_i}$

$O_i$ 는 관측 빈도, $E_i$ 는 기대 빈도다. 귀무가설 하에서 이 통계량은 자유도 $k - 1$ 인 카이제곱 분포를 따른다.

주사위의 공정성을 검정하는 예제로 확인해보자.

# 상황: 주사위 360번 던지기 — 공정한 주사위인가?
observed = np.array([70, 55, 62, 48, 65, 60])
expected = np.array([60, 60, 60, 60, 60, 60])

chi2_stat, p_value = stats.chisquare(f_obs=observed, f_exp=expected)

print(f"관측 빈도: {observed}")
print(f"기대 빈도: {expected}")
print(f"카이제곱 통계량: {chi2_stat:.4f}")
print(f"p-value: {p_value:.4f}")
# 카이제곱 통계량: 4.9667
# p-value: 0.4200
# → 공정한 주사위라는 귀무가설을 기각하지 못한다

기대 빈도 주의

카이제곱 검정은 기대 빈도가 5 이상일 때 근사가 신뢰할 수 있다. 기대 빈도가 너무 작은 범주가 있으면, 인접 범주를 합치거나 Fisher의 정확 검정을 고려해야 한다.

적합도 검정은 하나의 변수에 대한 분포를 확인한다. 그렇다면 두 범주형 변수 사이의 관계는 어떻게 검정할까?

카이제곱 독립성 검정 (Chi-squared Test of Independence)

언제 쓰는가. 두 범주형 변수 사이에 **연관성(독립이 아닌 관계)**이 있는지 검정할 때 사용한다.

성별과 제품 선호도 사이에 관계가 있는가?
흡연 여부와 질병 발생 여부가 독립인가?

데이터를 **분할표(Contingency Table)**로 정리한 뒤, 각 셀의 관측 빈도와 “독립 가정 하에서의 기대 빈도”를 비교한다. 기대 빈도는 다음과 같이 계산한다.

$E_{ij} = \frac{(\text{행 } i \text{ 합계}) \times (\text{열 } j \text{ 합계})}{\text{전체 합계}}$

검정 통계량은 적합도 검정과 같은 형태다.

$\chi^2 = \sum_{i} \sum_{j} \frac{(O_{ij} - E_{ij})^2}{E_{ij}}$

자유도는 $(r - 1)(c - 1)$ , 여기서 $r$ 은 행 수, $c$ 는 열 수다.

성별과 음료 선호도의 독립성을 검정해보자.

# 상황: 성별(남/여)과 선호 음료(커피/차/주스)의 독립성 검정
#         커피  차  주스
# 남성     90  60   30
# 여성     60  80   40
observed_table = np.array([[90, 60, 30],
                            [60, 80, 40]])

chi2_stat, p_value, dof, expected_table = stats.chi2_contingency(observed_table)

print("관측 빈도:")
print(observed_table)
print(f"\n기대 빈도:")
print(expected_table.round(1))
print(f"\n카이제곱 통계량: {chi2_stat:.4f}")
print(f"자유도: {dof}")
print(f"p-value: {p_value:.4f}")
# 카이제곱 통계량: 10.2857
# 자유도: 2
# p-value: 0.0058
# → 성별과 음료 선호 사이에 유의한 연관성이 있다

비모수 검정: 정규성 가정이 깨질 때

지금까지 다룬 t-검정과 ANOVA는 모두 데이터가 정규분포를 따른다고 가정한다. CLT에 의해 표본 크기가 충분히 크면 이 가정은 대체로 괜찮지만, 표본이 작거나 분포가 극단적으로 치우쳐 있으면 모수적 검정의 결과를 신뢰하기 어렵다.

이럴 때 **비모수 검정(Nonparametric Test)**이 대안이 된다. 분포 형태에 대한 가정 없이, 데이터의 **순위(Rank)**를 기반으로 검정한다.

모수적 검정	비모수 대안	상황
독립 표본 t-검정	Mann-Whitney U	독립 2집단 비교
대응 표본 t-검정	Wilcoxon signed-rank	대응 2집단 비교
일원 ANOVA	Kruskal-Wallis	독립 3집단+ 비교

비모수 = 무조건 안전?

비모수 검정은 가정이 적은 대신 검정력(Power)이 낮다. 데이터가 실제로 정규분포를 따르는데 비모수 검정을 쓰면, 같은 효과를 탐지하는 데 더 많은 표본이 필요하다. 정규성이 성립하면 모수적 검정이 더 강력하다.

Mann-Whitney U 검정

독립 두 집단의 비모수 대안이다. 치우친 분포의 데이터로 확인해보자.

np.random.seed(42)

# 정규성 가정이 어려운 데이터: 치우친 분포
group1 = np.random.exponential(scale=5, size=20)
group2 = np.random.exponential(scale=8, size=20)

u_stat, p_value = stats.mannwhitneyu(group1, group2, alternative='two-sided')

print(f"그룹 1 중앙값: {np.median(group1):.2f}")
print(f"그룹 2 중앙값: {np.median(group2):.2f}")
print(f"U-통계량: {u_stat:.1f}")
print(f"p-value:  {p_value:.4f}")
# → 순위 기반으로 두 집단의 분포 차이를 검정한다

Wilcoxon signed-rank 검정

대응 표본의 비모수 대안이다. 차이의 부호와 순위만으로 전후 변화를 평가한다.

np.random.seed(42)

# 대응 비모수: 처치 전후의 비대칭 분포 데이터
before = np.random.exponential(scale=10, size=15)
after = before - np.random.exponential(scale=3, size=15)

w_stat, p_value = stats.wilcoxon(before, after)

print(f"Wilcoxon 통계량: {w_stat:.1f}")
print(f"p-value: {p_value:.4f}")
# → 차이의 순위를 기반으로 전후 변화를 검정한다

Python 종합 실습: 하나의 시나리오로 여러 검정

실전에서는 하나의 데이터셋에 여러 검정을 적용하는 경우가 흔하다. 가상의 임상시험 데이터로 종합 실습을 해보자.

import numpy as np
from scipy import stats

np.random.seed(2026)

# ── 데이터 생성: 3개 치료군(A, B, 위약)의 혈압 변화와 부작용 여부 ──
n = 30  # 각 그룹 30명

drug_a = np.random.normal(loc=-12, scale=8, size=n)   # 혈압 감소량
drug_b = np.random.normal(loc=-8, scale=10, size=n)
placebo = np.random.normal(loc=-2, scale=7, size=n)

# 부작용 발생 여부 (범주형)
side_effect = np.array([
    [8, 22],   # Drug A: 부작용 O / N
    [12, 18],  # Drug B
    [5, 25],   # Placebo
])

# ── (1) Drug A가 위약보다 효과가 있는가? → 독립 표본 t-검정 ──
t1, p1 = stats.ttest_ind(drug_a, placebo, equal_var=False)
print("=== 독립 표본 t-검정: Drug A vs Placebo ===")
print(f"  t = {t1:.3f}, p = {p1:.4f}")

# ── (2) 세 그룹 간 차이가 있는가? → ANOVA ──
f_stat, p2 = stats.f_oneway(drug_a, drug_b, placebo)
print("\n=== 일원 ANOVA: 3개 치료군 비교 ===")
print(f"  F = {f_stat:.3f}, p = {p2:.6f}")

# ── (3) ANOVA 유의 시 사후 검정 → Tukey HSD ──
if p2 < 0.05:
    result = stats.tukey_hsd(drug_a, drug_b, placebo)
    print("\n=== Tukey HSD 사후 검정 ===")
    print(result)

# ── (4) 치료군과 부작용 발생의 독립성 → 카이제곱 검정 ──
chi2, p4, dof, expected = stats.chi2_contingency(side_effect)
print("\n=== 카이제곱 독립성 검정: 치료군 × 부작용 ===")
print(f"  χ² = {chi2:.3f}, df = {dof}, p = {p4:.4f}")

# ── (5) 정규성 의심 시 비모수 대안 → Mann-Whitney ──
u_stat, p5 = stats.mannwhitneyu(drug_a, placebo, alternative='two-sided')
print("\n=== Mann-Whitney U: Drug A vs Placebo (비모수) ===")
print(f"  U = {u_stat:.1f}, p = {p5:.4f}")

이 코드 하나로 독립 표본 t-검정, ANOVA, 사후 검정, 카이제곱 독립성 검정, 비모수 검정까지 전부 시연할 수 있다. 실제 분석에서도 이렇게 여러 검정을 병행하는 것이 일반적이다.

흔한 실수 세 가지

1. 정규성 확인을 건너뛴다

t-검정과 ANOVA는 정규성 가정에 기반한다. 표본이 30개 이상이면 CLT 덕분에 대체로 괜찮지만, 소표본에서는 반드시 확인해야 한다. Shapiro-Wilk 검정이나 Q-Q plot으로 정규성을 검토하고, 위반 시 비모수 대안을 쓰자.

# Shapiro-Wilk 정규성 검정
stat, p = stats.shapiro(drug_a)
print(f"Shapiro-Wilk: W = {stat:.4f}, p = {p:.4f}")
# p > 0.05면 정규성 가정 유지

2. 다중 검정 보정을 하지 않는다

여러 쌍을 비교하면서 개별 유의수준만 보면, 전체 1종 오류율이 폭증한다. ANOVA 후 사후 검정(Tukey HSD, Bonferroni 등)을 사용하거나, 여러 검정을 수행할 때는 Bonferroni 보정( $\alpha' = \alpha / m$ , $m$ 은 검정 횟수)을 적용하자.

3. 효과 크기를 무시한다

p-value는 “효과가 있느냐 없느냐”만 말해줄 뿐, “효과가 얼마나 큰가“는 알려주지 않는다. 표본이 충분히 크면 아무리 작은 차이도 유의하게 나온다. 반드시 **효과 크기(Effect Size)**를 함께 보고해야 한다.

검정	효과 크기 지표	해석 기준 (Cohen)
t-검정	Cohen’s d = $\frac{\bar{X}_1 - \bar{X}_2}{s_p}$	0.2 작음 / 0.5 중간 / 0.8 큼
ANOVA	η² (Eta-squared) = $\frac{SS_B}{SS_T}$	0.01 / 0.06 / 0.14
카이제곱	Cramér’s V = $\sqrt{\frac{\chi^2}{n \cdot \min(r-1, c-1)}}$	0.1 / 0.3 / 0.5

# Cohen's d 계산 (독립 두 집단)
def cohens_d(group1, group2):
    n1, n2 = len(group1), len(group2)
    s_pooled = np.sqrt(((n1-1)*group1.std(ddof=1)**2 + (n2-1)*group2.std(ddof=1)**2) / (n1+n2-2))
    return (group1.mean() - group2.mean()) / s_pooled

d = cohens_d(drug_a, placebo)
print(f"Cohen's d: {d:.3f}")
# → d의 절대값이 0.8 이상이면 큰 효과

마치며

검정 방법 선택은 결국 세 가지 질문으로 귀결된다. 데이터가 연속인가 범주인가, 집단이 몇 개인가, 표본이 독립인가 대응인가. 이 글의 플로차트와 요약표를 기준점 삼아, 상황에 맞는 도구를 골라 쓰면 된다.

하나 더 기억할 것 — 모든 모수적 검정에는 분포 가정이 깔려 있다. 정규성, 등분산성, 독립성. 이 가정이 깨지면 비모수 검정을 쓸 수 있지만, 그마저도 “순위”라는 정보 축약에 의존한다. 분포 가정 자체에서 자유로워지는 방법은 없을까? 복원 추출로 분포를 직접 근사하는 부트스트랩(Bootstrap)이 그 답이다. 다음 글에서 만나자.

참고자료

Wasserman, L. (2004). All of Statistics. Chapter 10: Hypothesis Testing and p-values.
Rice, J.A. (2006). Mathematical Statistics and Data Analysis. 3rd Edition. Chapters 11-12.
Kim, W. (2013). Mathematical Statistics. (김우철, 수리통계학). 가설검정 및 분산분석 장.
SciPy Documentation — scipy.stats: 각 검정 함수의 상세 API 문서.

가설검정(Hypothesis Testing): 데이터로 주장을 검증하는 체계적 프레임워크

Donhyeok Kang — Thu, 19 Feb 2026 00:00:00 GMT

이전 글에서 신뢰구간을 다뤘다. “모수 $\theta$ 가 이 구간 안에 있을 것이다”라는 구간추정은 점추정의 불확실성을 정량화하는 강력한 도구였다. 그런데 한 가지 자연스러운 질문이 떠오른다 — 만약 우리가 주장하는 특정 값 $\theta_0$ 이 신뢰구간 밖에 있다면, 그 주장을 기각해도 되는 걸까?

“이 약은 효과가 없다”, “새 알고리즘의 전환율은 기존과 같다”, “이 동전은 공정하다” — 이런 주장을 데이터에 기반해 체계적으로 판단하는 프레임워크가 바로 **가설검정(Hypothesis Testing)**이다. 통계적 추론에서 가장 널리 쓰이면서도, 동시에 가장 오해가 많은 개념이기도 하다.

가설검정이란?

두 개의 가설

가설검정은 두 개의 상충하는 가설을 설정하는 것에서 시작한다.

가설	기호	의미	역할
귀무가설(Null Hypothesis)	$H_0$	현재 상태, 효과 없음, 차이 없음	“기각 대상” — 반증하고 싶은 주장
대립가설(Alternative Hypothesis)	$H_1$ (또는 $H_a$ )	연구자가 주장하고 싶은 것	증거가 충분할 때 채택

예를 들어, 새로운 추천 알고리즘이 기존보다 클릭률(CTR)을 높이는지 확인하고 싶다면:

$H_0: \mu_{\text{new}} = \mu_{\text{old}} \quad \text{vs} \quad H_1: \mu_{\text{new}} > \mu_{\text{old}}$

여기서 핵심적인 비대칭이 있다. $H_0$ 은 “참이라고 가정”하는 것이지, “참이라고 믿는” 것이 아니다. 검찰이 피고인의 무죄를 추정하는 것과 같다 — 충분한 증거가 있을 때만 유죄(기각)를 선고한다.

검정 통계량

가설이 세워지면 다음 단계는 데이터를 하나의 숫자로 요약하는 **검정 통계량(Test Statistic)**의 계산이다. 검정 통계량은 $H_0$ 이 참일 때 알려진 분포를 따르도록 설계된 함수다.

대표적인 예로, 모평균 검정에서 모분산 $\sigma^2$ 을 알 때의 Z-통계량:

$Z = \frac{\bar{X} - \mu_0}{\sigma / \sqrt{n}}$

$H_0: \mu = \mu_0$ 이 참이라면, 중심극한정리에 의해 $Z \sim N(0, 1)$ 을 따른다. 이 분포가 검정 논리의 토대가 된다.

💡 검정 통계량의 핵심 성질

검정 통계량은 반드시 **” $H_0$ 이 참일 때의 분포”**가 알려져 있어야 한다. Z-통계량은 표준정규분포, t-통계량은 t-분포, 카이제곱 통계량은 $\chi^2$ -분포를 따른다. 이 귀무분포(null distribution)가 있어야 “이 데이터가 얼마나 극단적인가”를 판단할 수 있다.

논리 구조: 귀류법

가설검정의 논리는 수학의 **귀류법(Proof by Contradiction)**과 정확히 같은 구조를 갖는다.

귀류법                              가설검정
─────────────────────────────────────────────────────
1. 명제 A가 거짓이라 가정     →   1. H₀가 참이라 가정
2. 논리적 모순 도출            →   2. 관측 데이터가 H₀ 하에서
                                      나올 확률이 극히 낮음을 확인
3. 따라서 A는 참               →   3. 따라서 H₀를 기각

이 논리를 단계별로 풀어보면:

$H_0$ 이 참이라고 가정한다 ( $\mu = \mu_0$ )
이 가정 하에서 검정 통계량의 분포를 계산한다 ( $Z \sim N(0, 1)$ )
실제 데이터로 검정 통계량의 관측값 $z_{\text{obs}}$ 를 계산한다
$z_{\text{obs}}$ 가 귀무분포에서 극단적인 위치에 있다면 → $H_0$ 가정과 데이터가 양립하기 어렵다 → $H_0$ 을 기각한다

“극단적”의 기준은 유의수준(Significance Level, $\alpha$ )으로 미리 정한다. 보통 $\alpha = 0.05$ 를 사용하는데, 이는 ” $H_0$ 이 참일 때 기각할 확률을 5% 이하로 유지하겠다”는 뜻이다.

       귀무분포 N(0,1) 하에서의 z 값 분포 (양측검정, α=0.05)

                         ┌──── 채택역(기각 안 함) ────┐
                         │                             │
   기각역 ◀──────────────┼─────────────────────────────┼──────────────▶ 기각역
   (α/2 = 2.5%)         │                             │          (α/2 = 2.5%)
                         │                             │
   ◀─────────────────────┼─────────────────────────────┼──────────────────────▶
  -3    -2.5    -1.96    -1     0     1     1.96    2.5    3
                  ▲                              ▲
              임계값(−z_α/2)                 임계값(z_α/2)

관측된 $z_{\text{obs}}$ 가 $|z_{\text{obs}}| > 1.96$ 이면 기각역에 속하므로 $H_0$ 을 기각한다.

⚠️ 주의: “기각하지 않음” ≠ ” $H_0$ 이 참”

$H_0$ 을 기각하지 않았다고 해서 $H_0$ 이 참이라는 뜻은 아니다. 단지 ” $H_0$ 을 기각할 만큼 충분한 증거가 없다“는 것이다. “증거 불충분으로 무죄”이지 “결백이 증명됨”이 아닌 것과 같다.

p-value의 정의와 해석

정확한 정의

p-value는 가설검정에서 가장 중요하면서도 가장 오해받는 개념이다.

p-value: $H_0$ 이 참이라는 가정 하에서, 관측된 검정 통계량만큼 또는 그보다 더 극단적인 값이 나올 확률.

수식으로 쓰면, 양측검정의 경우:

$p\text{-value} = P(|Z| \geq |z_{\text{obs}}| \mid H_0 \text{ 참})$

p-value가 작다는 것은 ” $H_0$ 이 참인 세계에서 이런 데이터는 매우 드물다”는 뜻이다. 따라서 p-value $\leq \alpha$ 이면 $H_0$ 을 기각한다.

흔한 오해 3가지

오해	왜 틀린가
“p-value는 $H_0$ 이 참일 확률이다”	p-value는 데이터에 대한 확률이지, 가설에 대한 확률이 아니다. $P(\text{data} \mid H_0)$ 이지 $P(H_0 \mid \text{data})$ 가 아니다.
“p = 0.03이면 $H_0$ 이 틀릴 확률이 97%다”	위와 같은 오류. 사후 확률은 베이즈 정리 없이는 계산할 수 없다.
“p = 0.8이면 $H_0$ 이 참이다”	높은 p-value는 $H_0$ 에 대한 증거가 아니다. 단지 기각할 근거가 부족할 뿐이다.

💡 p-value를 한 문장으로

” $H_0$ 이 참인 세상에서 이 데이터(또는 더 극단적인 데이터)를 관측할 확률” — 이것이 p-value의 전부다. 이 확률이 너무 작으면( $\leq \alpha$ ), ” $H_0$ 이 참인 세상”이라는 가정 자체를 의심하는 것이다.

Python으로 p-value 계산

import numpy as np
from scipy import stats

# 예제: 어떤 공장의 볼트 평균 길이가 10cm인지 검정
# H₀: μ = 10  vs  H₁: μ ≠ 10  (양측검정)
np.random.seed(5)
n = 36
mu_0 = 10.0          # 귀무가설 하의 모평균
sigma = 2.0          # 모표준편차 (알려져 있다고 가정)

# 실제로는 μ = 10.8인 모집단에서 추출
sample = np.random.normal(10.8, sigma, size=n)
x_bar = np.mean(sample)

# Z-통계량 계산
z_obs = (x_bar - mu_0) / (sigma / np.sqrt(n))

# 양측 p-value
p_value = 2 * (1 - stats.norm.cdf(abs(z_obs)))

print(f"표본 평균: {x_bar:.4f}")
print(f"Z-통계량:  {z_obs:.4f}")
print(f"p-value:   {p_value:.6f}")
print(f"결론 (α=0.05): {'H₀ 기각' if p_value < 0.05 else 'H₀ 기각 실패'}")
# 표본 평균: 10.7658
# Z-통계량:  2.2973
# p-value:   0.021602
# 결론 (α=0.05): H₀ 기각

Z = 2.30으로 임계값 1.96을 넘겼고, p-value = 0.022 < 0.05이므로 $H_0$ 을 기각한다. 표본 평균 10.77은 $\mu_0 = 10$ 과 통계적으로 유의한 차이를 보인다.

유의수준(α)과 기각역

α의 의미

위 예제에서 0.05라는 기준은 어디서 온 것일까? 유의수준 $\alpha$ 는 검정 전에 연구자가 설정하는 1종 오류의 허용 한계로, ” $H_0$ 이 참인데 실수로 기각할 확률을 최대 $\alpha$ 로 제한하겠다”는 선언이다.

$\alpha = 0.05$ 는 관행이지 자연법칙이 아니다. 분야에 따라 기준은 달라진다:

분야	일반적인 $\alpha$	이유
탐색적 연구	0.10	놓치는 것보다 발견이 중요
일반 사회과학	0.05	관행 (Fisher의 제안)
입자물리학	$3 \times 10^{-7}$ (5σ)	잘못된 발견의 비용이 극도로 큼
유전체 연구	$5 \times 10^{-8}$	수백만 번의 동시 검정 보정

양측 검정 vs 단측 검정

대립가설의 방향에 따라 기각역의 위치가 달라진다.

양측검정 (H₁: μ ≠ μ₀)          단측검정 (H₁: μ > μ₀)
──────────────────────          ──────────────────────
     α/2          α/2                            α
   ┌─────┐     ┌─────┐                        ┌─────┐
   │/////│     │/////│                         │/////│
───┴─────┴─────┴─────┴───      ───────────────┴─────┴───
 -z_α/2    0    z_α/2                  0       z_α
(-1.96)        (1.96)                         (1.645)

"μ₀이 아닌 어떤 값"          "μ₀보다 큰 쪽만 관심"

단측 검정은 한쪽에 $\alpha$ 전체를 몰아넣으므로 임계값이 낮아진다 (1.96 → 1.645). 같은 데이터에서 기각이 더 쉬워지지만, 반대 방향의 효과는 감지할 수 없다는 트레이드오프가 있다.

⚠️ 단측 검정 남용 금지

데이터를 본 후에 방향을 정해서 단측 검정을 하는 것은 p-hacking의 한 형태다. 검정 방향은 데이터를 보기 전에 결정해야 한다. A/B 테스트에서 “새 버전이 더 나을 것이다”라는 사전 가설이 명확할 때만 단측 검정을 쓴다.

1종 오류와 2종 오류

$\alpha$ 를 설정한다는 것은 곧 틀릴 가능성을 감수한다는 뜻이다. 가설검정이 이분법적 결정인 이상, 두 가지 종류의 오류는 피할 수 없다.

                              실제 상태
                     ┌──────────────┬──────────────┐
                     │  H₀ 참       │  H₁ 참       │
         ┌───────────┼──────────────┼──────────────┤
  검정   │ H₀ 기각   │ 1종 오류(α)  │ ✅ 올바른 기각│
  결과   │ 안 함     │  (False +)   │   (Power)    │
         ├───────────┼──────────────┼──────────────┤
         │ H₀ 기각   │ ✅ 올바른    │ 2종 오류(β)  │
         │ 안 함     │   판단       │  (False -)   │
         └───────────┴──────────────┴──────────────┘

위 ASCII 도표를 좀 더 명확하게 정리하면 다음과 같다.

	$H_0$ 참 (효과 없음)	$H_1$ 참 (효과 있음)
$H_0$ 기각 안 함	올바른 결정 (확률 $1-\alpha$ )	2종 오류 (확률 $\beta$ ) — 놓침
$H_0$ 기각	1종 오류 (확률 $\alpha$ ) — 거짓 경보	올바른 결정 (확률 $1-\beta$ ) — 검정력

재판 비유

가설검정	재판
$H_0$ : 무죄	무죄 추정 원칙
$H_0$ 기각 → 유죄 판결	증거가 충분해야 유죄 선고
1종 오류	무고한 사람에게 유죄 선고
2종 오류	범인을 무죄 방면
$\alpha$ 를 낮춤	유죄 판결 기준을 엄격하게 → 억울한 사람 줄지만, 범인 놓칠 가능성 ↑

재판 비유가 잘 보여주듯, 1종 오류와 2종 오류 사이에는 근본적인 트레이드오프가 존재한다. $\alpha$ 를 줄여 기각 기준을 엄격하게 잡으면 1종 오류는 감소하지만, 그만큼 2종 오류( $\beta$ )가 커진다. 두 오류를 동시에 줄이는 유일한 방법은 표본 크기 $n$ 을 늘리는 것뿐이다.

# 1종 오류율 시뮬레이션: H₀가 참일 때 기각하는 비율
np.random.seed(42)

n_sim = 10_000
n = 30
mu_0 = 100       # H₀: μ = 100 (실제로도 100)
sigma = 15
alpha = 0.05

rejections = 0
for _ in range(n_sim):
    sample = np.random.normal(mu_0, sigma, size=n)  # H₀가 참인 세상
    z = (np.mean(sample) - mu_0) / (sigma / np.sqrt(n))
    p = 2 * (1 - stats.norm.cdf(abs(z)))
    if p < alpha:
        rejections += 1

print(f"1종 오류율 (시뮬레이션): {rejections / n_sim:.4f}")
print(f"1종 오류율 (이론값):     {alpha}")
# 1종 오류율 (시뮬레이션): 0.0548
# 1종 오류율 (이론값):     0.05

시뮬레이션 결과가 $\alpha = 0.05$ 근처에 수렴한다. 이것이 유의수준의 의미다 — $H_0$ 이 참일 때 기각할 확률이 $\alpha$ 로 제어된다.

검정력(Power)

정의

2종 오류를 $\beta$ 라 했을 때, 그 여사건인 **검정력(Power)**은 $H_1$ 이 참일 때 $H_0$ 을 올바르게 기각할 확률이다.

$\text{Power} = 1 - \beta = P(\text{H}_0 \text{ 기각} \mid H_1 \text{ 참})$

검정력이 낮으면 실제 효과가 있어도 발견하지 못한다. 일반적으로 Power $\geq 0.80$ 을 목표로 한다 (즉, 효과가 있을 때 80% 이상의 확률로 탐지).

검정력에 영향을 미치는 세 가지 요인

그렇다면 검정력을 높이려면 어떤 레버를 당길 수 있을까?

1. 효과 크기(Effect Size): 실제 모수 $\mu$ 와 $\mu_0$ 의 차이가 클수록 탐지가 쉽다.

2. 표본 크기( $n$ ): $n$ 이 커지면 표준오차 $\sigma/\sqrt{n}$ 이 줄어들어, 같은 효과도 더 선명하게 드러난다.

3. 유의수준( $\alpha$ ): $\alpha$ 를 높이면 기각역이 넓어져서 검정력이 올라가지만, 1종 오류도 함께 증가한다.

from statsmodels.stats.power import NormalIndPower

power_analysis = NormalIndPower()

# 시나리오: 효과 크기 변화에 따른 검정력
effect_sizes = [0.1, 0.2, 0.3, 0.5, 0.8]
n_fixed = 50
alpha_fixed = 0.05

print("효과 크기 | 검정력")
print("─" * 22)
for es in effect_sizes:
    power = power_analysis.power(effect_size=es, nobs1=n_fixed,
                                  alpha=alpha_fixed, alternative='two-sided')
    print(f"  {es:.1f}     | {power:.4f}")

# 효과 크기 | 검정력
# ──────────────────────
#   0.1     | 0.0791
#   0.2     | 0.1701
#   0.3     | 0.3230
#   0.5     | 0.7054
#   0.8     | 0.9793

효과 크기 0.2에서는 검정력이 17%에 불과하지만, 0.8이 되면 98%에 달한다. 작은 효과를 탐지하려면 표본 크기를 크게 늘려야 한다.

필요 표본 크기 계산

실무에서 가장 빈번하게 마주치는 질문은 이것이다: “원하는 검정력을 달성하려면 $n$ 이 얼마나 필요한가?”

from statsmodels.stats.power import TTestIndPower

power_analysis = TTestIndPower()

# 두 그룹 평균 비교 (A/B 테스트)
# 효과 크기 0.3, α=0.05, Power=0.80 달성에 필요한 각 그룹 표본 크기
required_n = power_analysis.solve_power(
    effect_size=0.3, alpha=0.05, power=0.80,
    ratio=1.0, alternative='two-sided'
)

print(f"필요 표본 크기 (각 그룹): {required_n:.0f}")
print(f"총 필요 표본:             {2 * required_n:.0f}")
# 필요 표본 크기 (각 그룹): 175
# 총 필요 표본:             351

효과 크기 0.3을 감지하려면 각 그룹에 175명, 총 351명이 필요하다. A/B 테스트 설계 시 이 계산을 실험 시작 전에 반드시 수행해야 하는 이유가 여기 있다 — 표본이 부족한 상태에서 검정을 돌리면, 실제 효과가 존재해도 발견하지 못하는 검정력 부족(underpowered) 문제에 빠지게 된다.

검정력 곡선

표본 크기에 따른 검정력의 변화를 시각화하면:

import matplotlib.pyplot as plt

power_analysis = TTestIndPower()
sample_sizes = np.arange(10, 301, 5)

fig, ax = plt.subplots(figsize=(10, 6))

for es, label in [(0.2, 'Small (d=0.2)'), (0.5, 'Medium (d=0.5)'),
                   (0.8, 'Large (d=0.8)')]:
    powers = [power_analysis.power(es, n, 0.05, alternative='two-sided')
              for n in sample_sizes]
    ax.plot(sample_sizes, powers, label=label, linewidth=2)

ax.axhline(y=0.80, color='red', linestyle='--', alpha=0.5, label='Power = 0.80')
ax.set_xlabel('Sample Size (per group)')
ax.set_ylabel('Power')
ax.set_title('Power Curve by Effect Size (α = 0.05, two-sided)')
ax.legend()
ax.set_ylim(0, 1.02)
ax.grid(True, alpha=0.3)
plt.tight_layout()
plt.show()

큰 효과(d=0.8)는 $n \approx 25$ 만으로도 80% 검정력을 달성하지만, 작은 효과(d=0.2)는 $n \approx 400$ 이 필요하다. 이것이 검정력 분석의 핵심 메시지다 — 탐지하려는 효과가 작을수록 데이터가 훨씬 많이 필요하다.

신뢰구간과 가설검정의 쌍대성

지금까지 가설검정의 내부 구조를 살펴봤는데, 이전 글에서 배운 신뢰구간과는 어떤 관계일까? 사실 이 둘은 동전의 양면이다.

동치 관계

$100(1-\alpha)\%$ 신뢰구간을 $\text{CI}$ 라 하면:

$\theta_0 \notin \text{CI} \quad \Longleftrightarrow \quad \text{유의수준 } \alpha \text{에서 } H_0: \theta = \theta_0 \text{ 기각}$

직관적으로, 95% 신뢰구간이 $[10.2, 11.3]$ 인데 $H_0: \mu = 10$ 을 검정하면? $10 \notin [10.2, 11.3]$ 이므로 $\alpha = 0.05$ 에서 기각된다.

# 쌍대성 확인: 신뢰구간 vs 가설검정
n = 36
sigma = 2.0
mu_0 = 10.0
np.random.seed(5)
sample = np.random.normal(10.8, sigma, size=n)
x_bar = np.mean(sample)
se = sigma / np.sqrt(n)

# 95% 신뢰구간
z_crit = stats.norm.ppf(0.975)
ci_lower = x_bar - z_crit * se
ci_upper = x_bar + z_crit * se

# Z-검정
z_obs = (x_bar - mu_0) / se
p_value = 2 * (1 - stats.norm.cdf(abs(z_obs)))

print(f"표본 평균:    {x_bar:.4f}")
print(f"95% 신뢰구간: [{ci_lower:.4f}, {ci_upper:.4f}]")
print(f"μ₀ = {mu_0}가 CI 안에 있는가? {ci_lower <= mu_0 <= ci_upper}")
print(f"p-value:      {p_value:.6f}")
print(f"H₀ 기각?      {p_value < 0.05}")
# 표본 평균:    10.7658
# 95% 신뢰구간: [10.1124, 11.4191]
# μ₀ = 10.0가 CI 안에 있는가? False
# p-value:      0.021602
# H₀ 기각?      True

$\mu_0 = 10$ 은 신뢰구간 밖에 있고, 동시에 $H_0$ 도 기각된다. 둘은 항상 같은 결론을 낸다.

💡 실무적 함의

신뢰구간이 가설검정보다 더 많은 정보를 준다. 가설검정은 “기각/기각 안 함”의 이분법이지만, 신뢰구간은 효과의 방향과 크기까지 보여준다. 논문이나 리포트에서는 p-value와 함께 신뢰구간을 반드시 보고하는 것이 좋다.

완전한 가설검정 예제: Z-검정과 t-검정

지금까지의 예제에서는 모분산 $\sigma^2$ 을 안다고 가정했지만, 실무에서는 $\sigma^2$ 을 모르는 경우가 대부분이다. 이때 $\sigma$ 를 표본 표준편차 $s$ 로 대체하면, 검정 통계량은 Z-분포 대신 t-분포를 따르게 된다.

$t = \frac{\bar{X} - \mu_0}{s / \sqrt{n}} \sim t(n-1)$

Python에서는 scipy.stats.ttest_1samp으로 한 줄이면 충분하다.

# 사례: 커피숍 음료 제조 시간이 평균 3분인지 검정
# H₀: μ = 3  vs  H₁: μ ≠ 3
np.random.seed(123)
prep_times = np.random.normal(3.4, 0.8, size=25)  # 실제 평균 3.4분

# One-sample t-test
t_stat, p_value = stats.ttest_1samp(prep_times, popmean=3.0)

# 신뢰구간 직접 계산
n = len(prep_times)
x_bar = np.mean(prep_times)
se = stats.sem(prep_times)
t_crit = stats.t.ppf(0.975, df=n-1)
ci = (x_bar - t_crit * se, x_bar + t_crit * se)

print(f"표본 크기: {n}")
print(f"표본 평균: {x_bar:.4f}")
print(f"표본 표준편차: {np.std(prep_times, ddof=1):.4f}")
print(f"t-통계량: {t_stat:.4f}")
print(f"p-value:  {p_value:.6f}")
print(f"95% CI:   [{ci[0]:.4f}, {ci[1]:.4f}]")
print(f"결론:     {'H₀ 기각 — 평균 제조 시간은 3분과 유의하게 다르다'
                   if p_value < 0.05 else 'H₀ 기각 실패'}")
# 표본 크기: 25
# 표본 평균: 3.5121
# 표본 표준편차: 0.9854
# t-통계량: 2.5984
# p-value:  0.015760
# 95% CI:   [3.1053, 3.9188]
# 결론:     H₀ 기각 — 평균 제조 시간은 3분과 유의하게 다르다

t-통계량 2.60, p-value 0.016 < 0.05이므로 $H_0$ 을 기각한다. 95% 신뢰구간 $[3.11, 3.92]$ 에 3.0이 포함되지 않는 것도 동일한 결론이다. 점추정에서 배운 표본 평균 $\bar{X} = 3.51$ 이 단일 숫자라면, 여기서는 그 추정값이 $\mu_0 = 3$ 과 통계적으로 유의하게 다른지 판단한 것이다.

흔한 실수와 함정

가설검정은 강력하지만, 잘못 사용하면 오히려 잘못된 확신을 심어줄 수 있다. 실무에서 가장 빈번한 함정 세 가지를 짚어 보자.

1. p-hacking

여러 변수를 탐색하면서 p < 0.05인 것만 보고하는 행위다. 20개 변수를 검정하면 효과가 전혀 없어도 평균 1개는 “유의”하게 나온다 ( $0.05 \times 20 = 1$ ).

# p-hacking 시뮬레이션: 20개의 독립적 검정, 모두 효과 없음
import numpy as np
from scipy import stats

np.random.seed(42)
n_tests = 20
n_per_test = 30
p_values = []

for i in range(n_tests):
    group_a = np.random.normal(0, 1, n_per_test)  # 효과 없음
    group_b = np.random.normal(0, 1, n_per_test)  # 효과 없음
    _, p = stats.ttest_ind(group_a, group_b)
    p_values.append(p)
    if p < 0.05:
        print(f"  검정 {i+1:2d}: p = {p:.4f} ← '유의'! (하지만 거짓 양성)")

sig_count = sum(1 for p in p_values if p < 0.05)
print(f"\n20개 검정 중 '유의한' 결과: {sig_count}개")
print(f"기대 거짓 양성 수: {n_tests * 0.05:.1f}개")

2. 다중 검정 보정

다중 검정 문제를 해결하는 가장 간단한 방법은 Bonferroni 보정이다: $m$ 번의 검정을 수행할 때, 유의수준을 $\alpha/m$ 으로 낮춘다.

$\alpha_{\text{adjusted}} = \frac{\alpha}{m} = \frac{0.05}{20} = 0.0025$

더 정교한 방법으로는 Benjamini-Hochberg 절차(FDR 제어)가 있다.

3. “유의하다” ≠ “중요하다”

통계적 유의성(Statistical Significance)과 실질적 유의성(Practical Significance)을 혼동해서는 안 된다.

$n$ 이 충분히 크면 아무리 작은 차이도 “통계적으로 유의”하게 만들 수 있다. 예를 들어, A/B 테스트에서 전환율이 2.001%에서 2.003%로 올랐다면? p < 0.05일 수 있지만, 0.002%p 차이가 사업적으로 의미 있는지는 전혀 별개의 문제다.

이것이 **효과 크기(Effect Size)**를 함께 보고해야 하는 이유다. Cohen’s d, 오즈비(Odds Ratio), 상관계수 등 효과 크기 지표는 “차이가 얼마나 큰가”를 p-value와 독립적으로 알려준다.

⚠️ 보고 원칙

결과를 보고할 때는 반드시 세 가지를 함께 적어야 한다:

p-value (통계적 유의성)
효과 크기 (실질적 유의성)
신뢰구간 (추정의 불확실성)

“p = 0.03이므로 유의하다”만으로는 불충분하다.

마치며

이 글에서 다룬 가설검정의 전체 절차를 한눈에 정리하면 다음과 같다.

┌─────────────────────────────────────────────────┐
│  Step 1. 가설 설정                                │
│    H₀: θ = θ₀  vs  H₁: θ ≠ θ₀ (또는 >, <)      │
├─────────────────────────────────────────────────┤
│  Step 2. 유의수준 α 설정 (보통 0.05)              │
├─────────────────────────────────────────────────┤
│  Step 3. 검정 통계량 선택 및 계산                  │
│    예: Z = (X̄ - μ₀) / (σ/√n)                    │
├─────────────────────────────────────────────────┤
│  Step 4. p-value 계산 또는 기각역 확인             │
│    p-value ≤ α → 기각  /  p-value > α → 기각 실패│
├─────────────────────────────────────────────────┤
│  Step 5. 결론 + 효과 크기 + 신뢰구간 보고         │
└─────────────────────────────────────────────────┘

각 단계에서 핵심은 결국 하나로 귀결된다 — $H_0$ 이 참이라 가정했을 때, 데이터가 그 가정과 양립하기 어려울 정도로 극단적이면 $H_0$ 을 기각한다는 귀류법적 논리다.

다만 이 프레임워크를 올바르게 사용하려면, p-value의 의미를 정확히 이해하고, 통계적 유의성과 실질적 유의성을 구분하며, 실험 전 검정력을 충분히 확보해야 한다. 0.05라는 숫자에 집착하기보다 효과 크기와 신뢰구간을 종합적으로 판단하는 습관이 훨씬 중요하다.

이번 글에서는 가설검정의 논리 구조와 기초 개념에 집중했다. 다음 글에서는 이 프레임워크 위에서 실제로 사용하는 t-검정, ANOVA, 카이제곱 검정 등 구체적인 검정 방법들을 다룬다. 어떤 상황에서 어떤 검정을 선택해야 하는지, 각 검정의 가정과 한계는 무엇인지 하나씩 짚어볼 것이다.

참고자료

Casella, G. & Berger, R. L. (2002). Statistical Inference, 2nd Edition. Cengage Learning. Chapter 8.
Wasserman, L. (2004). All of Statistics. Springer. Chapter 10.
Cohen, J. (1988). Statistical Power Analysis for the Behavioral Sciences, 2nd Edition. Lawrence Erlbaum.
American Statistical Association (2016). “Statement on Statistical Significance and P-Values.” The American Statistician, 70(2), 129–133.
Greenland, S. et al. (2016). “Statistical tests, P values, confidence intervals, and power: a guide to misinterpretations.” European Journal of Epidemiology, 31, 337–350.

신뢰구간(Confidence Interval): 추정의 불확실성을 수량화하는 방법

Donhyeok Kang — Wed, 18 Feb 2026 00:00:00 GMT

이전 글에서 MLE를 다뤘다. 데이터의 우도를 최대화하는 점추정량을 구했고, 피셔 정보량(Fisher Information)을 통해 그 추정량이 점근적으로 최적임을 확인했다. 그런데 MLE가 건네주는 것은 결국 하나의 숫자다. “평균 체류 시간은 4.7분이다” — 그래서? 4.7분이 정확히 맞을 확률은 사실상 0이다. 연속형 모수의 점추정값이 참값과 정확히 일치하는 것은 측도론적으로 불가능하기 때문이다.

우리가 정말 알고 싶은 것은 “4.7분이라는 추정이 얼마나 믿을 만한가“이다. 참값이 4.5에서 4.9 사이에 있다는 말과, 2.0에서 7.4 사이에 있다는 말은 전혀 다른 수준의 정보를 담고 있다. 이 불확실성을 수학적으로 표현하는 도구가 바로 **신뢰구간(Confidence Interval, CI)**이다.

점추정 vs 구간추정: 왜 구간이 필요한가

점추정은 모수 $\theta$ 의 값을 하나의 숫자 $\hat{\theta}$ 로 요약한다. 이 추정량이 비편향(unbiased)이고 일치적(consistent)이라 해도, 특정 표본에서 구한 $\hat{\theta}$ 가 $\theta$ 에서 얼마나 떨어져 있는지는 알 수 없다.

추정 방식	결과 형태	정보량
점추정	$\hat{\mu} = 4.7$	최선의 추측값 하나
구간추정	$[4.3, 5.1]$	불확실성의 범위까지 포함

구간추정이 점추정보다 항상 우월한 것은 아니다. 예측 모형에 모수값 하나를 넣어야 하는 상황이라면 점추정이 필요하다. 하지만 “이 효과가 실재하는가?”, “이 차이가 의미 있는 크기인가?”를 판단하려면 추정의 불확실성을 정량화하는 구간이 필수다.

import numpy as np

np.random.seed(42)
true_mu = 10.0
n = 25

# 같은 모집단에서 표본을 5번 뽑아 점추정
for i in range(5):
    sample = np.random.normal(true_mu, 3.0, size=n)
    x_bar = np.mean(sample)
    se = np.std(sample, ddof=1) / np.sqrt(n)
    print(f"표본 {i+1}: x̄ = {x_bar:.2f},  95% CI = [{x_bar - 1.96*se:.2f}, {x_bar + 1.96*se:.2f}]")
# 표본 1: x̄ = 9.51,  95% CI = [8.38, 10.63]
# 표본 2: x̄ = 9.14,  95% CI = [8.05, 10.23]
# 표본 3: x̄ = 10.32,  95% CI = [9.16, 11.48]
# 표본 4: x̄ = 9.79,  95% CI = [8.90, 10.68]
# 표본 5: x̄ = 10.16,  95% CI = [8.95, 11.38]

같은 모집단에서 뽑았는데도 점추정값은 표본마다 흔들린다. 반면 구간추정은 참값 $\mu = 10$ 을 일관되게 포착한다. 이것이 구간추정의 핵심 가치다.

신뢰구간의 정의와 빈도주의 해석

형식적 정의

신뢰 수준(confidence level) $1 - \alpha$ 의 신뢰구간이란, 통계량 $L(\mathbf{X})$ 과 $U(\mathbf{X})$ 로 이루어진 구간 $[L, U]$ 로서 다음을 만족하는 것이다:

$P_\theta(L(\mathbf{X}) \leq \theta \leq U(\mathbf{X})) \geq 1 - \alpha \quad \text{for all } \theta \in \Theta$

핵심은 확률이 걸리는 대상이 구간이지, 모수가 아니라는 것이다. $\theta$ 는 미지이지만 고정된 상수다. 확률적으로 움직이는 것은 표본에 의존하는 $L$ 과 $U$ 뿐이다.

올바른 해석

“95% 신뢰구간”의 뜻: 동일한 모집단에서 같은 크기의 표본을 반복 추출하여 매번 신뢰구간을 구성하면, 그 구간들 중 약 95%가 참 모수를 포함한다.

⚠️ 주의: 가장 흔한 오해

“모수 $\theta$ 가 95% 확률로 이 구간 안에 있다”는 틀린 해석이다. 이미 관측된 구간 $[3.2, 5.8]$ 에 대해, $\theta$ 는 이 안에 있거나 없거나 둘 중 하나다 — 확률이 아니다. 빈도주의에서 모수는 확률변수가 아니므로, “모수가 어디에 있을 확률”이라는 표현 자체가 성립하지 않는다.

모수에 확률을 부여하고 싶다면 베이지안 프레임워크의 **신용구간(Credible Interval)**이 필요하다.

커버리지 시뮬레이션으로 확인

이 정의를 직접 눈으로 확인해보자. 1,000개의 95% 신뢰구간을 구성하고, 참값을 포함하는 구간과 놓치는 구간을 구분한다.

import numpy as np
from scipy import stats

np.random.seed(123)
true_mu = 0.0
sigma = 1.0
n = 25
alpha = 0.05
n_intervals = 1000

results = []
for _ in range(n_intervals):
    sample = np.random.normal(true_mu, sigma, size=n)
    x_bar = np.mean(sample)
    se = sigma / np.sqrt(n)
    z = stats.norm.ppf(1 - alpha/2)
    lo, hi = x_bar - z * se, x_bar + z * se
    covers = lo <= true_mu <= hi
    results.append((lo, hi, covers))

n_covers = sum(r[2] for r in results)
n_misses = n_intervals - n_covers

print(f"1,000개 95% CI 중 참값 포함: {n_covers}개 ({n_covers/n_intervals*100:.1f}%)")
print(f"참값 놓침: {n_misses}개 ({n_misses/n_intervals*100:.1f}%)")

# 처음 20개 구간 출력 (포함 여부 표시)
print("\n처음 20개 구간:")
for i, (lo, hi, covers) in enumerate(results[:20]):
    marker = "✓" if covers else "✗ MISS"
    print(f"  [{lo:>6.3f}, {hi:>6.3f}]  {marker}")
# 1,000개 95% CI 중 참값 포함: 942개 (94.2%)
# 참값 놓침: 58개 (5.8%)
#
# 처음 20개 구간:
#   [-0.252,  0.532]  ✓
#   [-0.506,  0.278]  ✓
#   [-0.290,  0.494]  ✓
#   [-0.412,  0.372]  ✓
#   [-0.357,  0.427]  ✓
#   ...

약 5%의 구간이 참값을 놓쳤다. 이 구간들은 표본이 우연히 한쪽으로 치우쳐 추출된 경우다. “95% 신뢰”란 이 구성 절차(procedure)가 장기적으로 95%의 성공률을 가진다는 뜻이지, 개별 구간이 95% 확률로 맞다는 뜻이 아니다.

정규분포 기반 신뢰구간: σ를 알 때

가장 기본적인 설정부터 시작하자. $X_1, \ldots, X_n \overset{iid}{\sim} N(\mu, \sigma^2)$ 이고 $\sigma$ 가 알려져 있을 때, 모평균 $\mu$ 에 대한 신뢰구간을 구성한다.

피벗 구성

**피벗(Pivot)**이란 분포가 미지의 모수에 의존하지 않는 통계량이다.

$Z = \frac{\bar{X} - \mu}{\sigma / \sqrt{n}} \sim N(0, 1)$

$Z$ 의 분포는 $\mu$ 와 무관하므로 피벗이다. $P(-z_{\alpha/2} \leq Z \leq z_{\alpha/2}) = 1 - \alpha$ 를 $\mu$ 에 대해 풀면:

$P\left(\bar{X} - z_{\alpha/2} \frac{\sigma}{\sqrt{n}} \leq \mu \leq \bar{X} + z_{\alpha/2} \frac{\sigma}{\sqrt{n}}\right) = 1 - \alpha$

따라서 $100(1-\alpha)\%$ 신뢰구간은 다음과 같다:

$\bar{X} \pm z_{\alpha/2} \cdot \frac{\sigma}{\sqrt{n}}$

여기서 $z_{\alpha/2}$ 는 표준정규분포의 상위 $\alpha/2$ 분위수(quantile)다. 95% 신뢰구간이면 $\alpha = 0.05$ 이고 $z_{0.025} = 1.96$ 이다.

신뢰 수준	$\alpha$	$z_{\alpha/2}$
90%	0.10	1.645
95%	0.05	1.960
99%	0.01	2.576

from scipy import stats

# σ = 10을 알고 있는 상황
sigma = 10.0
n = 36
x_bar = 52.3

for conf_level in [0.90, 0.95, 0.99]:
    z_val = stats.norm.ppf(1 - (1 - conf_level) / 2)
    me = z_val * sigma / np.sqrt(n)
    print(f"{conf_level*100:.0f}% CI: [{x_bar - me:.2f}, {x_bar + me:.2f}]  (폭: {2*me:.2f})")
# 90% CI: [49.56, 55.04]  (폭: 5.48)
# 95% CI: [49.03, 55.57]  (폭: 6.53)
# 99% CI: [48.01, 56.59]  (폭: 8.59)

신뢰 수준이 올라갈수록 구간은 넓어진다. 더 확실하게 모수를 포착하려면 더 넓은 그물을 던져야 하는 셈이다.

💡 “σ를 안다”는 가정은 현실적인가?

거의 아니다. 모평균 $\mu$ 를 모르면서 모표준편차 $\sigma$ 를 안다는 것은 매우 특수한 상황이다. 공정 관리에서 공정 분산이 오랜 기록으로 확립된 경우 정도가 해당된다. 대부분의 실전에서는 다음 절의 t-분포 기반 신뢰구간을 사용한다.

t-분포와 소표본: σ를 모를 때

왜 정규분포가 아닌가

$\sigma$ 를 모르면 표본 표준편차 $S = \sqrt{\frac{1}{n-1}\sum(X_i - \bar{X})^2}$ 로 대체해야 한다. 문제는 $S$ 자체가 확률변수라는 점이다.

$T = \frac{\bar{X} - \mu}{S / \sqrt{n}}$

이 통계량은 표준정규분포를 따르지 않는다. 분모에 확률변수 $S$ 가 들어갔기 때문에 $Z$ 보다 변동이 크고, 꼬리가 더 무겁다. William Sealy Gosset이 1908년 “Student”라는 필명으로 밝혀낸 분포가 바로 이것이다:

$T \sim t_{n-1}$

자유도(degrees of freedom) $\nu = n-1$ 인 Student’s t-분포를 따른다.

t-분포의 특성

성질	설명
형태	표준정규와 비슷하지만 꼬리가 더 두꺼움
자유도 $\nu$	클수록 표준정규에 가까워짐
$\nu = 1$	코시 분포 (평균 존재하지 않음)
$\nu \to \infty$	$N(0,1)$ 로 수렴
실용 기준	$\nu \geq 30$ 이면 정규 근사가 합리적

t-기반 신뢰구간

$\bar{X} \pm t_{\alpha/2, n-1} \cdot \frac{S}{\sqrt{n}}$

여기서 $t_{\alpha/2, n-1}$ 은 자유도 $n-1$ 인 t-분포의 상위 $\alpha/2$ 분위수다.

import numpy as np
from scipy import stats

np.random.seed(42)
sample = np.random.normal(loc=100, scale=15, size=12)

x_bar = np.mean(sample)
s = np.std(sample, ddof=1)
n = len(sample)
se = s / np.sqrt(n)

# t-분포 기반 95% CI
alpha = 0.05
t_crit = stats.t.ppf(1 - alpha/2, df=n-1)
z_crit = stats.norm.ppf(1 - alpha/2)

ci_t = (x_bar - t_crit * se, x_bar + t_crit * se)
ci_z = (x_bar - z_crit * se, x_bar + z_crit * se)

print(f"n = {n}, x̄ = {x_bar:.2f}, s = {s:.2f}")
print(f"t 임계값 (df={n-1}): {t_crit:.4f}")
print(f"z 임계값:            {z_crit:.4f}")
print(f"t-기반 95% CI: [{ci_t[0]:.2f}, {ci_t[1]:.2f}]  (폭: {ci_t[1]-ci_t[0]:.2f})")
print(f"z-기반 95% CI: [{ci_z[0]:.2f}, {ci_z[1]:.2f}]  (폭: {ci_z[1]-ci_z[0]:.2f})")
# n = 12, x̄ = 104.44, s = 11.16
# t 임계값 (df=11): 2.2010
# z 임계값:            1.9600
# t-기반 95% CI: [97.35, 111.53]  (폭: 14.19)
# z-기반 95% CI: [98.12, 110.76]  (폭: 12.63)

$n = 12$ 일 때 t 임계값은 2.201로, z 임계값 1.960보다 상당히 크다. t-기반 구간이 약 12% 더 넓은데, 이 차이가 곧 $\sigma$ 대신 $S$ 를 사용하면서 발생하는 추가 불확실성이다. $n$ 이 커지면 $S \to \sigma$ 이고 $t_{n-1} \to N(0,1)$ 이므로 두 구간은 수렴한다.

💡 scipy의 편리한 함수

stats.t.interval(confidence, df, loc, scale)을 사용하면 한 줄로 t-기반 CI를 구할 수 있다: stats.t.interval(0.95, df=n-1, loc=x_bar, scale=se)

다양한 모수의 신뢰구간: 비율과 분산

지금까지는 평균에 대한 CI를 다뤘다. 하지만 실전에서 추정해야 할 모수는 평균만이 아니다. 비율과 분산에 대한 CI도 동일한 피벗 원리를 따르되, 기반 분포가 달라진다.

비율의 신뢰구간: 세 가지 방법 비교

$n$ 명 중 $X$ 명이 “예”라고 응답했을 때, 모비율(population proportion) $p$ 에 대한 구간을 어떻게 구할까? $\hat{p} = X/n$ 은 점추정값이고, 이에 기반한 구간 구성 방법이 여럿 존재한다.

Wald 구간. CLT에 의해 $n$ 이 충분히 크면 $\hat{p} \approx N(p, p(1-p)/n)$ 이다. $p$ 를 $\hat{p}$ 로 대체하면:

$\hat{p} \pm z_{\alpha/2} \sqrt{\frac{\hat{p}(1-\hat{p})}{n}}$

가장 널리 쓰이지만 가장 문제가 많은 방법이기도 하다. $\hat{p}$ 가 0이나 1에 가까우면 정규 근사가 나쁘고, $\hat{p} = 0$ 이면 구간이 $[0, 0]$ 으로 퇴화한다.

Wilson 구간. 피벗 방정식 $\left(\frac{\hat{p} - p}{\sqrt{p(1-p)/n}}\right)^2 \leq z_{\alpha/2}^2$ 을 $p$ 에 대한 이차방정식으로 풀어서 구간을 구한다. 분모에 $\hat{p}$ 대신 $p$ 를 쓰기 때문에 Wald보다 안정적이다:

$\frac{\hat{p} + \frac{z^2}{2n}}{1 + \frac{z^2}{n}} \pm \frac{z}{1 + \frac{z^2}{n}} \sqrt{\frac{\hat{p}(1-\hat{p})}{n} + \frac{z^2}{4n^2}}$

Clopper-Pearson (정확) 구간. 이항분포(Binomial distribution)의 정확한 분위수에 기반한다. 보수적(구간이 넓음)이지만 커버리지가 항상 명목 수준 이상을 보장한다.

import numpy as np
from scipy import stats

def wald_ci(x, n, alpha=0.05):
    p_hat = x / n
    z = stats.norm.ppf(1 - alpha/2)
    me = z * np.sqrt(p_hat * (1 - p_hat) / n)
    return max(0, p_hat - me), min(1, p_hat + me)

def wilson_ci(x, n, alpha=0.05):
    p_hat = x / n
    z = stats.norm.ppf(1 - alpha/2)
    z2 = z**2
    center = (p_hat + z2 / (2*n)) / (1 + z2/n)
    margin = z / (1 + z2/n) * np.sqrt(p_hat*(1-p_hat)/n + z2/(4*n**2))
    return max(0, center - margin), min(1, center + margin)

def clopper_pearson_ci(x, n, alpha=0.05):
    lo = stats.beta.ppf(alpha/2, x, n - x + 1) if x > 0 else 0.0
    hi = stats.beta.ppf(1 - alpha/2, x + 1, n - x) if x < n else 1.0
    return lo, hi

# 비교: n=20, 다양한 x 값
n = 20
print(f"{'x':>3} {'p̂':>6} {'Wald':>18} {'Wilson':>18} {'Clopper-P':>18}")
print("-" * 67)
for x in [1, 5, 10, 15, 19]:
    p_hat = x / n
    w = wald_ci(x, n)
    wl = wilson_ci(x, n)
    cp = clopper_pearson_ci(x, n)
    print(f"{x:>3} {p_hat:>6.2f} [{w[0]:.3f}, {w[1]:.3f}] "
          f"[{wl[0]:.3f}, {wl[1]:.3f}] [{cp[0]:.3f}, {cp[1]:.3f}]")
#   x    p̂               Wald             Wilson          Clopper-P
# -------------------------------------------------------------------
#   1   0.05 [0.000, 0.146] [0.009, 0.236] [0.001, 0.249]
#   5   0.25 [0.060, 0.440] [0.112, 0.469] [0.087, 0.491]
#  10   0.50 [0.281, 0.719] [0.299, 0.701] [0.272, 0.728]
#  15   0.75 [0.560, 0.940] [0.531, 0.888] [0.509, 0.913]
#  19   0.95 [0.854, 1.000] [0.764, 0.991] [0.751, 0.999]

방법	장점	단점	실전 권장
Wald	계산 단순	$\hat{p} \approx 0$ 또는 $1$ 에서 커버리지 부족	교과서 용. 실전 비추천
Wilson	소표본에서 안정적, $\hat{p} = 0$ 도 처리	약간 복잡	기본 선택으로 추천
Clopper-Pearson	보수적, 커버리지 보장	지나치게 넓을 수 있음	안전성이 중요할 때

$\hat{p} = 0.05$ ( $x = 1$ )일 때 Wald는 하한이 0으로 잘리지만, Wilson과 Clopper-Pearson은 합리적인 구간을 제시한다. 극단적인 비율일수록 방법 선택이 중요해진다.

💡 A/B 테스트에서의 선택

전환율처럼 비율이 극단적으로 작거나 큰 경우가 흔한 상황에서는 Wilson 구간이 사실상 표준이다. R의 prop.test()나 Python의 statsmodels.stats.proportion.proportion_confint(method='wilson')이 이를 지원한다.

분산의 신뢰구간: 카이제곱 분포 활용

모분산(population variance) $\sigma^2$ 에 대한 신뢰구간은 카이제곱 분포( $\chi^2$ distribution)를 이용한다. $X_1, \ldots, X_n \overset{iid}{\sim} N(\mu, \sigma^2)$ 일 때, 피벗은:

$\frac{(n-1)S^2}{\sigma^2} \sim \chi^2_{n-1}$

이를 $\sigma^2$ 에 대해 풀면:

$\left[\frac{(n-1)S^2}{\chi^2_{\alpha/2, n-1}}, \quad \frac{(n-1)S^2}{\chi^2_{1-\alpha/2, n-1}}\right]$

카이제곱 분포는 비대칭이므로 이 구간도 $S^2$ 기준으로 대칭이 아니다.

import numpy as np
from scipy import stats

np.random.seed(42)
true_sigma2 = 25.0
n = 20
sample = np.random.normal(0, np.sqrt(true_sigma2), size=n)

s2 = np.var(sample, ddof=1)
df = n - 1
alpha = 0.05

chi2_lo = stats.chi2.ppf(1 - alpha/2, df)
chi2_hi = stats.chi2.ppf(alpha/2, df)

ci_lo = df * s2 / chi2_lo
ci_hi = df * s2 / chi2_hi

print(f"표본 분산 s² = {s2:.2f}")
print(f"σ² 95% CI: [{ci_lo:.2f}, {ci_hi:.2f}]")
print(f"참값 σ² = {true_sigma2:.2f}")
# 표본 분산 s² = 23.04
# σ² 95% CI: [13.33, 49.15]
# 참값 σ² = 25.00

분산의 신뢰구간은 꽤 넓다. 편차의 제곱을 다루는 특성상 극단값에 민감하기 때문에, 분산 추정은 본질적으로 평균 추정보다 어려운 문제다.

⚠️ 주의: 정규성 가정의 민감성

분산의 카이제곱 기반 CI는 정규분포 가정에 매우 민감하다. 모집단이 정규가 아니면 커버리지가 크게 어긋날 수 있다. 이 경우 부트스트랩(bootstrap) 방법이 더 신뢰할 만하다.

신뢰구간의 폭을 결정하는 세 가지 요인

정규 기반 CI $\bar{X} \pm z_{\alpha/2} \cdot \sigma / \sqrt{n}$ 의 반폭(margin of error)은:

$E = z_{\alpha/2} \cdot \frac{\sigma}{\sqrt{n}}$

이 공식에 세 가지 요인이 모두 드러나 있다:

요인	폭에 미치는 영향	조절 가능 여부
신뢰 수준 ( $1-\alpha$ ) ↑	폭 ↑ ( $z_{\alpha/2}$ 증가)	연구자가 선택
표본 크기 ( $n$ ) ↑	폭 ↓ ( $\sqrt{n}$ 에 반비례)	실험 설계로 조절
모분산 ( $\sigma^2$ ) ↑	폭 ↑ (비례)	통제 불가 (모집단 고유)

필요 표본 크기 역산

“95% 신뢰구간의 반폭이 $E$ 이하가 되려면 표본이 몇 개 필요한가?” — 실험 설계에서 가장 자주 등장하는 질문이다.

$n \geq \left(\frac{z_{\alpha/2} \cdot \sigma}{E}\right)^2$

from scipy import stats
import numpy as np

sigma = 10.0  # 예상 표준편차
alpha = 0.05
z = stats.norm.ppf(1 - alpha/2)

print(f"σ = {sigma}, 95% CI 기준")
print(f"{'목표 반폭 E':>12} {'필요 표본 크기 n':>16}")
print("-" * 32)
for E in [5.0, 3.0, 2.0, 1.0, 0.5]:
    n_required = np.ceil((z * sigma / E) ** 2)
    print(f"{E:>12.1f} {n_required:>16.0f}")
# σ = 10, 95% CI 기준
#  목표 반폭 E    필요 표본 크기 n
# --------------------------------
#          5.0               16
#          3.0               43
#          2.0               97
#          1.0              385
#          0.5             1537

반폭을 절반으로 줄이려면 표본이 4배 필요하다. $\sqrt{n}$ 에 반비례하기 때문이다. 정밀도를 높이는 일은 전형적인 수확 체감(diminishing returns)의 법칙을 따른다.

MLE와 신뢰구간: 점근 정규성의 활용

이전 글에서 다룬 MLE의 점근 정규성은 신뢰구간 구성과 자연스럽게 연결된다. 정규 조건 하에서:

$\hat{\theta}_{\text{MLE}} \overset{d}{\to} N\left(\theta, \frac{1}{nI(\theta)}\right)$

여기서 $I(\theta)$ 는 피셔 정보량이다. 이 성질에서 곧바로 신뢰구간이 도출된다:

$\hat{\theta}_{\text{MLE}} \pm z_{\alpha/2} \cdot \frac{1}{\sqrt{nI(\hat{\theta})}}$

$I(\theta)$ 의 $\theta$ 를 $\hat{\theta}$ 로 대체한 것은 MLE의 일치성에 의해 정당화된다. 이 구간을 **Wald 신뢰구간(Wald CI)**이라 부른다.

예시: 포아송 분포

$X_1, \ldots, X_n \overset{iid}{\sim} \text{Poisson}(\lambda)$ 에서 $I(\lambda) = 1/\lambda$ 이므로:

$\hat{\lambda} \pm z_{\alpha/2} \sqrt{\frac{\hat{\lambda}}{n}}$

import numpy as np
from scipy import stats

np.random.seed(42)
true_lambda = 3.5
n = 50

sample = np.random.poisson(true_lambda, size=n)
lam_hat = np.mean(sample)  # MLE for Poisson

# MLE 기반 Wald CI
z = stats.norm.ppf(0.975)
se = np.sqrt(lam_hat / n)
ci = (lam_hat - z * se, lam_hat + z * se)

print(f"MLE λ̂ = {lam_hat:.4f}")
print(f"Fisher 정보량 I(λ̂) = {1/lam_hat:.4f}")
print(f"표준오차 SE = √(λ̂/n) = {se:.4f}")
print(f"95% Wald CI: [{ci[0]:.4f}, {ci[1]:.4f}]")
print(f"참값 λ = {true_lambda}")
# MLE λ̂ = 3.2800
# Fisher 정보량 I(λ̂) = 0.3049
# 표준오차 SE = √(λ̂/n) = 0.2561
# 95% Wald CI: [2.7780, 3.7820]
# 참값 λ = 3.5

피셔 정보량이 클수록 $1/\sqrt{nI(\theta)}$ 가 작아져 신뢰구간이 좁아진다. “데이터 한 개가 모수에 대해 담고 있는 정보의 양”이 크면 불확실성이 줄어드는 것이니, 직관과 정확히 맞아떨어진다.

📌 핵심 요약: 주요 신뢰구간 공식

모평균 (σ 기지): $\bar{X} \pm z_{\alpha/2} \cdot \sigma / \sqrt{n}$
모평균 (σ 미지): $\bar{X} \pm t_{\alpha/2, n-1} \cdot S / \sqrt{n}$
모비율 (Wilson): $\frac{\hat{p} + z^2/(2n)}{1 + z^2/n} \pm \frac{z}{1+z^2/n}\sqrt{\hat{p}(1-\hat{p})/n + z^2/(4n^2)}$
모분산: $\left[\frac{(n-1)S^2}{\chi^2_{\alpha/2}}, \frac{(n-1)S^2}{\chi^2_{1-\alpha/2}}\right]$
MLE 일반: $\hat{\theta} \pm z_{\alpha/2} / \sqrt{nI(\hat{\theta})}$

흔한 실수와 오해

1. “이 구간이 모수를 포함할 확률이 95%이다”

가장 빈번한 오해다. 이미 계산된 구간은 고정된 숫자 쌍이고, 모수도 고정된 상수다. 포함하거나 포함하지 않거나 — 확률이 개입할 여지가 없다. 95%는 구간을 만드는 절차에 대한 성질이다.

2. 구간이 좁으면 무조건 좋다?

신뢰 수준을 80%로 낮추면 구간은 좁아진다. 하지만 그만큼 참값을 놓칠 위험도 커진다. 구간의 폭만 보고 판단할 수 없으며, 항상 신뢰 수준과 함께 해석해야 한다.

3. 표본 크기를 늘리면 신뢰 수준이 올라간다?

아니다. 신뢰 수준은 연구자가 선택하는 값이다. 표본 크기를 늘리면 같은 신뢰 수준에서 구간이 좁아질 뿐, 신뢰 수준 자체가 변하는 것이 아니다.

4. 신뢰구간이 0을 포함하면 “효과 없음”?

0을 포함한다는 것은 “효과가 0일 가능성을 배제할 수 없다”는 뜻이지, “효과가 없다”는 증거가 아니다. 이 미묘한 차이가 가설검정에서 중요해진다.

5. 독립이 아닌 표본에서 CI를 적용

모든 CI 공식은 표본의 독립성(또는 최소한 명시적인 의존 구조)을 가정한다. 시계열 데이터에 iid 기반 CI를 적용하면 구간이 지나치게 좁아지고, 커버리지가 명목 수준에 한참 못 미치게 된다.

⚠️ 가장 위험한 실수

$n$ 이 충분히 크면 CLT에 의해 CI가 작동한다 — 이것은 맞다. 하지만 “충분히 큰 $n$ “이 얼마인지는 모집단의 분포에 따라 다르다. 대칭 분포면 $n = 30$ 도 충분하지만, 극단적으로 치우친 분포(로그정규, 파레토 등)에서는 $n = 100$ 도 부족할 수 있다. 항상 분포의 모양을 먼저 확인하자.

마치며: 구간추정에서 가설검정으로

신뢰구간은 모수의 불확실성을 하나의 구간으로 압축한다. MLE가 “최선의 추정값”을 제공한다면, 신뢰구간은 그 추정이 얼마나 정확한지를 정량화하는 도구다.

그런데 이 도구를 뒤집어보면 흥미로운 일이 일어난다. $\theta_0$ 에 대한 $100(1-\alpha)\%$ 신뢰구간을 하나 구성했다고 하자:

$\theta_0$ 이 구간 안에 있으면 → 유의수준 $\alpha$ 에서 $H_0: \theta = \theta_0$ 를 기각하지 못한다
$\theta_0$ 이 구간 밖에 있으면 → 유의수준 $\alpha$ 에서 $H_0: \theta = \theta_0$ 를 기각한다

신뢰구간을 구성하는 것과 가설검정을 수행하는 것이 수학적으로 동치라는 뜻이다. 이 관계를 **쌍대성(duality)**이라 부른다. 다음 글에서는 이 쌍대성의 반대편 — p-value, 유의수준, 검정력 — 을 본격적으로 다룬다.

참고자료

Wasserman, L. (2004). All of Statistics, Chapter 6: Models, Statistical Inference and Learning.
MIT 18.650: Statistics for Applications, Lectures 7-8.
Agresti, A. & Coull, B.A. (1998). “Approximate Is Better than ‘Exact’ for Interval Estimation of Binomial Proportions.” The American Statistician, 52(2), 119-126.
Brown, L.D., Cai, T.T. & DasGupta, A. (2001). “Interval Estimation for a Binomial Proportion.” Statistical Science, 16(2), 101-133.
SciPy Documentation: scipy.stats

최대우도추정(MLE)과 적률법(MoM): 추정량을 체계적으로 찾는 두 가지 방법

Donhyeok Kang — Tue, 17 Feb 2026 00:00:00 GMT

이전 글에서 점추정의 핵심 개념을 다뤘다. 추정량과 추정값의 구분, 비편향성·일치성·효율성이라는 평가 기준, MSE의 편향-분산 분해, 그리고 충분 통계량까지. 하지만 빠진 질문이 하나 있다 — 좋은 추정량은 어떻게 찾는가?

표본 평균이나 표본 분산은 직관적이었다. 모집단 평균을 추정하니까 데이터의 평균을 구하고, 모집단 분산을 추정하니까 데이터의 산포를 계산하면 되는 셈이다. 그런데 감마 분포의 형태 모수(shape parameter)를 추정해야 한다면 어떨까? 직관만으로는 한계가 있으므로, 임의의 확률 모형에서 모수를 체계적으로 추정하는 일반적인 방법론이 필요하게 된다.

이 글에서 다루는 두 가지 패러다임이 바로 **적률법(Method of Moments, MoM)**과 **최대우도추정(Maximum Likelihood Estimation, MLE)**이다. 하나는 단순하고 직관적이며, 다른 하나는 수학적으로 최적에 가깝다.

적률법: 가장 직관적인 추정 방법

핵심 아이디어

적률법의 아이디어는 놀라울 정도로 단순하다. 모집단 적률을 표본 적률로 대체한다.

$k$ 차 모집단 적률은 $\mu_k = E[X^k]$ 이고, 이에 대응하는 $k$ 차 표본 적률은 $\hat{\mu}_k = \frac{1}{n}\sum_{i=1}^{n}X_i^k$ 이다. 추정해야 할 모수가 $p$ 개라면, $p$ 개의 적률 방정식을 세워서 풀면 되는 것이다.

1차 적률 $E[X]$ 는 모집단 평균이고, 이를 표본 평균 $\bar{X}$ 로 대체한다. 2차 적률 $E[X^2]$ 도 마찬가지다. 큰 수의 법칙에 의해 $\hat{\mu}_k \xrightarrow{P} \mu_k$ 이므로, $n$ 이 커질수록 이 대체는 점점 정확해지게 된다.

예시 1: 정규분포 $N(\mu, \sigma^2)$

모수가 2개이므로 적률 방정식도 2개가 필요하다.

$\mu_1 = E[X] = \mu \quad \Rightarrow \quad \hat{\mu} = \bar{X}$

$\mu_2 = E[X^2] = \sigma^2 + \mu^2 \quad \Rightarrow \quad \hat{\sigma}^2 = \frac{1}{n}\sum X_i^2 - \bar{X}^2 = \frac{1}{n}\sum(X_i - \bar{X})^2$

정규분포에서는 적률법 추정량이 직관적인 표본 평균, 표본 분산과 정확히 일치하는 셈이다.

import numpy as np

np.random.seed(42)
true_mu, true_sigma2 = 5.0, 4.0

sample = np.random.normal(true_mu, np.sqrt(true_sigma2), size=30)

# 적률법 추정
mom_mu = np.mean(sample)                # 1차 적률 → 표본 평균
mom_sigma2 = np.var(sample, ddof=0)     # 2차 적률 → n으로 나눈 표본 분산

print(f"MoM μ̂ = {mom_mu:.4f}  (참값: {true_mu})")
print(f"MoM σ̂² = {mom_sigma2:.4f}  (참값: {true_sigma2})")
# MoM μ̂ = 4.6237  (참값: 5.0)
# MoM σ̂² = 3.1320  (참값: 4.0)

주목할 점은 적률법이 $n$ 으로 나눈다는 것이다. 베셀 보정에서 봤듯 이 추정량은 $\sigma^2$ 에 대해 편향되어 있지만, 표본 적률을 모집단 적률에 그대로 대입하는 방법이니 자연스러운 결과로 볼 수 있다.

예시 2: 감마분포 $\text{Gamma}(\alpha, \beta)$

적률법의 진가는 모수와 적률의 관계가 비선형일 때 드러나게 된다. 감마분포의 평균과 분산은 다음과 같다.

$E[X] = \frac{\alpha}{\beta}, \qquad \text{Var}(X) = \frac{\alpha}{\beta^2}$

2차 적률 $E[X^2] = \text{Var}(X) + (E[X])^2 = \frac{\alpha(\alpha+1)}{\beta^2}$ 을 활용하면:

$\hat{\alpha} = \frac{\bar{X}^2}{\hat{\mu}_2 - \bar{X}^2}, \qquad \hat{\beta} = \frac{\bar{X}}{\hat{\mu}_2 - \bar{X}^2}$

여기서 $\hat{\mu}_2 = \frac{1}{n}\sum X_i^2$ 이다. 분모 $\hat{\mu}_2 - \bar{X}^2$ 은 사실 $n$ 으로 나눈 표본 분산과 같다는 점에 주목하자.

import numpy as np

np.random.seed(42)
true_alpha, true_beta = 3.0, 2.0  # 평균=1.5, 분산=0.75

gamma_sample = np.random.gamma(true_alpha, 1/true_beta, size=100)

# 표본 적률
m1 = np.mean(gamma_sample)
m2 = np.mean(gamma_sample**2)

# 적률법 추정량
mom_alpha = m1**2 / (m2 - m1**2)
mom_beta = m1 / (m2 - m1**2)

print(f"1차 표본 적률: {m1:.4f}")
print(f"2차 표본 적률: {m2:.4f}")
print(f"MoM α̂ = {mom_alpha:.4f}  (참값: {true_alpha})")
print(f"MoM β̂ = {mom_beta:.4f}  (참값: {true_beta})")
# 1차 표본 적률: 1.4613
# 2차 표본 적률: 2.6875
# MoM α̂ = 3.8689  (참값: 3.0)
# MoM β̂ = 2.6475  (참값: 2.0)

감마 분포의 형태 모수를 추정하는 것은 직관만으로는 어렵다. 하지만 적률법을 쓰면 기계적으로 방정식을 세우고 풀기만 하면 되기 때문이다.

💡 적률법의 장단점

장점: 계산이 간단하다. 우도 함수를 구할 필요 없이 적률만 맞추면 된다. 닫힌 해(closed-form)가 존재하는 경우가 많다. 단점: 일반적으로 MLE보다 효율이 낮다(분산이 크다). 고차 적률을 사용하면 추정 불안정성이 커진다. 추정값이 모수 공간 밖에 떨어질 수 있다(예: 분산 추정이 음수).

최대우도추정: 데이터를 가장 잘 설명하는 모수

우도 함수 (Likelihood Function)

MLE의 핵심 질문은 이렇다: 관측된 데이터를 가장 그럴듯하게(likely) 만드는 모수 값은 무엇인가?

$X_1, \ldots, X_n$ 이 확률(밀도)함수 $f(x; \theta)$ 를 따르는 iid 표본일 때, **우도 함수(Likelihood Function)**는:

$L(\theta) = \prod_{i=1}^{n} f(X_i; \theta)$

형태는 결합 확률(밀도)함수와 동일하지만, 관점이 정반대다. 확률함수는 $\theta$ 를 고정하고 $x$ 의 함수로 보지만, 우도 함수는 $x$ 를 고정(관측값)하고 $\theta$ 의 함수로 보게 된다.

📐 확률 vs 우도

확률(Probability): 모수 $\theta$ 가 고정된 상태에서 “이 데이터가 나올 가능성은?” → $P(X \mid \theta)$ 우도(Likelihood): 데이터가 고정된 상태에서 “어떤 모수가 이 데이터를 잘 설명하는가?” → $L(\theta \mid X)$

같은 수식 $f(x;\theta)$ 를 사용하지만, 무엇을 변수로 보느냐에 따라 해석이 완전히 달라진다. 우도는 확률이 아니므로 합이 1일 필요가 없다는 점도 기억해야 한다.

동전 던지기로 직관을 잡아보자. 동전을 10번 던져 앞면이 8번 나왔다고 하자.

$p = 0.5$ 일 때 우도: $L(0.5) = \binom{10}{8}(0.5)^{10} \approx 0.044$
$p = 0.8$ 일 때 우도: $L(0.8) = \binom{10}{8}(0.8)^8(0.2)^2 \approx 0.302$

$p = 0.8$ 이 훨씬 그럴듯하다. 그렇다면 우도를 최대화하는 $p$ 는 정확히 얼마일까? 아래 코드로 우도 함수의 전체 모양을 확인해보자.

import numpy as np
from scipy.special import comb

# 동전 10번 중 앞면 8번
n_trials, n_heads = 10, 8
p_values = np.linspace(0.01, 0.99, 200)

# 우도 함수: L(p) = C(10,8) * p^8 * (1-p)^2
likelihood = comb(n_trials, n_heads) * p_values**n_heads * (1 - p_values)**(n_trials - n_heads)

# MLE = 관측 비율
p_mle = n_heads / n_trials

print(f"MLE p̂ = {p_mle}")
print(f"L(0.5) = {comb(n_trials, n_heads) * 0.5**10:.4f}")
print(f"L(0.8) = {comb(n_trials, n_heads) * 0.8**8 * 0.2**2:.4f}")
print(f"L(MLE) = {comb(n_trials, n_heads) * p_mle**8 * (1-p_mle)**2:.4f}")
# MLE p̂ = 0.8
# L(0.5) = 0.0439
# L(0.8) = 0.3020
# L(MLE) = 0.3020  ← 최댓값

$p = 0.8$ 에서 우도가 최대가 되며, 이는 표본 비율 $8/10$ 과 정확히 일치한다. 이처럼 우도를 최대화하는 $p$ 를 찾는 것이 MLE의 핵심 원리다.

로그우도 (Log-Likelihood)

왜 곱셈 대신 덧셈을 쓰려 하는 걸까? 로그를 취하면 곱이 합으로 바뀌고, 로그는 단조증가 함수이므로 최대화 문제의 해는 그대로 유지되기 때문이다.

$\ell(\theta) = \log L(\theta) = \sum_{i=1}^{n} \log f(X_i; \theta)$

로그우도를 쓰면 두 가지 이점이 있다:

곱셈이 덧셈으로 변하므로 미분이 훨씬 쉬워진다
매우 작은 확률들의 곱으로 인한 수치 언더플로를 방지할 수 있다

MLE는 로그우도를 최대화하는 $\theta$ :

$\hat{\theta}_{\text{MLE}} = \arg\max_\theta \ell(\theta)$

대부분의 경우 미분해서 0으로 놓고 풀면 되는데, 이를 스코어 방정식이라 부른다:

$\frac{\partial \ell}{\partial \theta} = 0 \quad \text{(Score equation)}$

여기서 $\frac{\partial \ell}{\partial \theta}$ 을 **스코어 함수(Score Function)**라 부른다. 흥미롭게도, 스코어 함수의 기댓값은 항상 0이라는 성질을 갖는다: $E\left[\frac{\partial}{\partial\theta}\log f(X;\theta)\right] = 0$ . 이 성질이 뒤에서 다룰 피셔 정보량의 출발점이 된다.

분포별 MLE 유도

베르누이 분포 $\text{Bernoulli}(p)$

$X_1, \ldots, X_n \stackrel{iid}{\sim} \text{Bernoulli}(p)$ 일 때:

$\ell(p) = \sum_{i=1}^{n}[x_i \log p + (1-x_i)\log(1-p)] = T\log p + (n-T)\log(1-p)$

여기서 $T = \sum x_i$ 는 충분 통계량이다. 미분하면:

$\frac{\partial \ell}{\partial p} = \frac{T}{p} - \frac{n-T}{1-p} = 0$

$\hat{p}_{\text{MLE}} = \frac{T}{n} = \bar{X}$

표본 비율이 곧 MLE인 셈이다. 직관과도 정확히 일치하는 결과라 할 수 있다.

import numpy as np

np.random.seed(42)
true_p = 0.7

data = np.random.binomial(1, true_p, size=50)
mle_p = data.mean()

print(f"n = {len(data)}, 성공 횟수 = {data.sum()}")
print(f"MLE p̂ = {mle_p:.4f}  (참값: {true_p})")
# n = 50, 성공 횟수 = 39
# MLE p̂ = 0.7800  (참값: 0.7)

정규분포 $N(\mu, \sigma^2)$

두 모수를 동시에 추정해야 하므로 편미분을 사용하게 된다. 로그우도는 다음과 같다.

$\ell(\mu, \sigma^2) = -\frac{n}{2}\log(2\pi) - \frac{n}{2}\log\sigma^2 - \frac{1}{2\sigma^2}\sum_{i=1}^{n}(x_i - \mu)^2$

$\mu$ 로 편미분:

$\frac{\partial \ell}{\partial \mu} = \frac{1}{\sigma^2}\sum(x_i - \mu) = 0 \quad \Rightarrow \quad \hat{\mu}_{\text{MLE}} = \bar{X}$

$\sigma^2$ 로 편미분:

$\frac{\partial \ell}{\partial \sigma^2} = -\frac{n}{2\sigma^2} + \frac{1}{2\sigma^4}\sum(x_i - \mu)^2 = 0 \quad \Rightarrow \quad \hat{\sigma}^2_{\text{MLE}} = \frac{1}{n}\sum(X_i - \bar{X})^2$

MLE의 $\hat{\sigma}^2$ 는 $n$ 으로 나누기 때문에 비편향 추정량( $n-1$ 로 나눔)이 아니다. MLE가 항상 비편향은 아니라는 점을 보여주는 중요한 예시로 볼 수 있다.

import numpy as np
from scipy import stats as sp_stats

np.random.seed(42)
sample = np.random.normal(5.0, 2.0, size=30)

mle_mu = np.mean(sample)
mle_sigma2 = np.var(sample, ddof=0)  # MLE는 n으로 나눔

# 로그우도 계산
ll = np.sum(sp_stats.norm.logpdf(sample, loc=mle_mu, scale=np.sqrt(mle_sigma2)))

print(f"MLE μ̂ = {mle_mu:.4f}")
print(f"MLE σ̂² = {mle_sigma2:.4f}")
print(f"로그우도 ℓ(μ̂, σ̂²) = {ll:.4f}")
# MLE μ̂ = 4.6237
# MLE σ̂² = 3.1320
# 로그우도 ℓ(μ̂, σ̂²) = -59.6934

포아송 분포 $\text{Poisson}(\lambda)$

$\ell(\lambda) = \sum_{i=1}^{n}[x_i\log\lambda - \lambda - \log(x_i!)]$

$\frac{\partial \ell}{\partial \lambda} = \frac{\sum x_i}{\lambda} - n = 0 \quad \Rightarrow \quad \hat{\lambda}_{\text{MLE}} = \bar{X}$

포아송에서도 MLE는 표본 평균이 된다. 포아송 분포의 평균이 $\lambda$ 이므로 직관적으로도 자연스러운 결과다.

지수분포 $\text{Exp}(\lambda)$ (rate 파라미터)

$\ell(\lambda) = n\log\lambda - \lambda\sum x_i$

$\frac{\partial \ell}{\partial \lambda} = \frac{n}{\lambda} - \sum x_i = 0 \quad \Rightarrow \quad \hat{\lambda}_{\text{MLE}} = \frac{1}{\bar{X}}$

지수분포의 평균이 $1/\lambda$ 이므로, 표본 평균의 역수를 취하는 것이 자연스럽다.

📌 분포별 MLE 요약

분포	모수	MLE	비편향?
Bernoulli( $p$ )	$p$	$\bar{X}$	✓
Normal( $\mu, \sigma^2$ )	$\mu$	$\bar{X}$	✓
Normal( $\mu, \sigma^2$ )	$\sigma^2$	$\frac{1}{n}\sum(X_i-\bar{X})^2$	✗ (편향: $\frac{n-1}{n}\sigma^2$ )
Poisson( $\lambda$ )	$\lambda$	$\bar{X}$	✓
Exponential( $\lambda$ )	$\lambda$	$1/\bar{X}$	✗

MLE는 왜 강력한가? — 점근 성질

MLE가 적률법보다 선호되는 이유는 무엇일까? 바로 대표본에서의 최적 성질 때문이다. $n$ 이 충분히 크면 MLE는 세 가지 놀라운 성질을 갖게 된다.

1. 일치성 (Consistency)

$\hat{\theta}_{\text{MLE}} \xrightarrow{P} \theta_0 \quad (n \to \infty)$

MLE는 일치추정량이다. 데이터가 많아지면 참값에 수렴하며, 정규 조건(regularity conditions) 하에서 성립하게 된다.

2. 점근 정규성 (Asymptotic Normality)

$\sqrt{n}(\hat{\theta}_{\text{MLE}} - \theta_0) \xrightarrow{d} N\left(0, \frac{1}{I(\theta_0)}\right)$

$n$ 이 커지면 MLE의 분포는 정규분포에 가까워진다. 여기서 $I(\theta_0)$ 는 **피셔 정보량(Fisher Information)**이다. 이 결과가 신뢰구간 구성의 기반이 되는데, 다음 글에서 본격적으로 다룰 주제이기도 하다.

실제로 확인해보자. 포아송 분포의 MLE인 $\hat{\lambda} = \bar{X}$ 가 $n$ 이 커질수록 정규분포에 얼마나 가까워지는지 시뮬레이션으로 살펴볼 수 있다.

import numpy as np

np.random.seed(42)
true_lambda = 5.0
sample_sizes = [10, 50, 200, 1000]
n_sims = 10_000

print(f"포아송(λ={true_lambda}) MLE의 점근 정규성 확인")
print(f"이론적 분산: Var(λ̂) = λ/n = {true_lambda}/n")
print()

for n in sample_sizes:
    mles = [np.mean(np.random.poisson(true_lambda, size=n)) for _ in range(n_sims)]
    mles = np.array(mles)
    theoretical_var = true_lambda / n
    empirical_var = np.var(mles)
    print(f"n = {n:>4d}:  E[λ̂] = {np.mean(mles):.4f},  "
          f"Var = {empirical_var:.6f},  이론 = {theoretical_var:.6f},  "
          f"비율 = {empirical_var/theoretical_var:.4f}")
# 포아송(λ=5.0) MLE의 점근 정규성 확인
# 이론적 분산: Var(λ̂) = 5.0/n
#
# n =   10:  E[λ̂] = 5.0048,  Var = 0.500193,  이론 = 0.500000,  비율 = 1.0004
# n =   50:  E[λ̂] = 4.9997,  Var = 0.100263,  이론 = 0.100000,  비율 = 1.0026
# n =  200:  E[λ̂] = 5.0010,  Var = 0.024475,  이론 = 0.025000,  비율 = 0.9790
# n = 1000:  E[λ̂] = 4.9995,  Var = 0.004785,  이론 = 0.005000,  비율 = 0.9571

실증 분산이 이론값 $\lambda/n = 1/(nI(\lambda))$ 에 거의 정확히 일치하는 것을 확인할 수 있다. 분산의 비율이 1에 가깝다는 것은 MLE가 크래머-라오 하한에 도달하고 있다는 뜻이다.

3. 점근 효율성 (Asymptotic Efficiency)

MLE의 점근 분산 $1/(nI(\theta))$ 은 크래머-라오 하한과 일치한다. 다시 말해, MLE보다 분산이 작은 일치추정량은 점근적으로 존재하지 않는다는 것이다.

정리하면:

성질	의미
일치성	$n \to \infty$ 이면 참값에 수렴한다
점근 정규성	$n$ 이 크면 정규분포를 따르므로 신뢰구간을 구성할 수 있다
점근 효율성	가능한 추정량 중 가장 작은 분산을 달성한다

✅ 실전 의미

MLE의 점근 성질은 “데이터가 충분하면 MLE가 최적에 가깝다”고 요약할 수 있다. ML에서 로지스틱 회귀의 손실함수(cross-entropy)가 사실 MLE이고, 교차 엔트로피와 우도 최대화가 같은 문제라는 것도 이 맥락에서 이해할 수 있다.

피셔 정보량: 데이터가 모수에 대해 말해주는 양

정의와 해석

이전 글에서 크래머-라오 하한을 소개하면서 피셔 정보량을 간략히 언급한 바 있다. 이제 그 개념을 더 깊이 파고들어 보자.

피셔 정보량(Fisher Information) $I(\theta)$ 는 하나의 관측값이 모수 $\theta$ 에 대해 담고 있는 정보의 양이다:

$I(\theta) = E\left[\left(\frac{\partial}{\partial\theta}\log f(X;\theta)\right)^2\right]$

동치 표현으로, 정규 조건 하에서:

$I(\theta) = -E\left[\frac{\partial^2}{\partial\theta^2}\log f(X;\theta)\right]$

두 번째 형태가 더 직관적이다. 로그우도의 **곡률(curvature)**이 클수록 피셔 정보가 커지게 된다. 곡률이 크다는 것은 우도 함수가 참값 근처에서 뾰족하다는 뜻이고, 그만큼 모수의 위치를 정밀하게 특정할 수 있기 때문이다.

분포별 피셔 정보량

분포	모수	피셔 정보 $I(\theta)$	CRLB ( $n$ 개 관측 시)
$\text{Bernoulli}(p)$	$p$	$\frac{1}{p(1-p)}$	$\frac{p(1-p)}{n}$
$N(\mu, \sigma^2)$ ( $\sigma^2$ 기지)	$\mu$	$\frac{1}{\sigma^2}$	$\frac{\sigma^2}{n}$
$\text{Poisson}(\lambda)$	$\lambda$	$\frac{1}{\lambda}$	$\frac{\lambda}{n}$
$\text{Exp}(\lambda)$	$\lambda$	$\frac{1}{\lambda^2}$	$\frac{\lambda^2}{n}$

# 피셔 정보량과 CRLB 계산 예시
n = 50

# Bernoulli
p = 0.3
fi_bern = 1 / (p * (1-p))
crlb_bern = 1 / (n * fi_bern)
print(f"Bernoulli(p={p}): I(p) = {fi_bern:.4f}, CRLB = {crlb_bern:.6f}")

# Normal
sigma2 = 4.0
fi_norm = 1 / sigma2
crlb_norm = 1 / (n * fi_norm)
print(f"Normal(σ²={sigma2}): I(μ) = {fi_norm:.4f}, CRLB = {crlb_norm:.6f}")

# Poisson
lam = 3.0
fi_pois = 1 / lam
crlb_pois = 1 / (n * fi_pois)
print(f"Poisson(λ={lam}): I(λ) = {fi_pois:.4f}, CRLB = {crlb_pois:.6f}")
# Bernoulli(p=0.3): I(p) = 4.7619, CRLB = 0.004200
# Normal(σ²=4.0): I(μ) = 0.2500, CRLB = 0.080000
# Poisson(λ=3.0): I(λ) = 0.3333, CRLB = 0.060000

왜 피셔 정보가 중요한가?

피셔 정보량이 중요한 이유는 세 가지 핵심 역할에서 찾을 수 있다:

크래머-라오 하한: 비편향 추정량의 분산 하한 $\text{Var}(\hat{\theta}) \geq 1/(nI(\theta))$
MLE의 점근 분산: $\text{Var}(\hat{\theta}_{\text{MLE}}) \approx 1/(nI(\theta))$ — MLE가 이 하한에 도달
실험 설계: 표본 크기 결정. “원하는 정밀도 $\epsilon$ 을 얻으려면 $n \geq 1/(\epsilon \cdot I(\theta))$ 개 필요”

베르누이의 $I(p) = 1/(p(1-p))$ 를 예로 들어보자. $p = 0.5$ 일 때 $I(p) = 4$ 로 최소가 된다. $p$ 가 0이나 1에 가까울수록 피셔 정보가 커지는데, 이는 직관적으로도 납득이 간다. 동전이 거의 항상 앞면(또는 뒷면)이 나오면 적은 시행으로도 $p$ 를 정확하게 추정할 수 있기 때문이다. 반면 $p = 0.5$ 인 공정한 동전은 가장 불확실하므로, 정밀한 추정을 위해서는 더 많은 데이터가 필요하게 된다.

MoM vs MLE: 언제 무엇을 쓸까?

이론적 비교는 충분히 했으니, 이제 감마 분포의 형태 모수 $\alpha$ 를 추정하는 시뮬레이션으로 두 방법을 직접 비교해보자.

import numpy as np
from scipy import stats as sp_stats

np.random.seed(42)
true_alpha = 2.0
true_beta = 1.0  # 평균=2, 분산=2
n = 20
n_sims = 50_000

mom_alphas = []
mle_alphas = []

for _ in range(n_sims):
    s = np.random.gamma(true_alpha, 1/true_beta, size=n)

    # 적률법
    m1 = np.mean(s)
    m2 = np.mean(s**2)
    var_s = m2 - m1**2
    mom_alphas.append(m1**2 / var_s if var_s > 0 else np.nan)

    # MLE (scipy)
    fit_alpha, _, _ = sp_stats.gamma.fit(s, floc=0)
    mle_alphas.append(fit_alpha)

mom_alphas = np.array([x for x in mom_alphas if not np.isnan(x)])
mle_alphas = np.array([x for x in mle_alphas if not np.isnan(x)])

print(f"Gamma(α={true_alpha}, β={true_beta}) 형태 모수 추정 비교 (n={n})")
print(f"{'':>8} {'MoM':>10} {'MLE':>10}")
print(f"{'E[α̂]':>8} {np.mean(mom_alphas):>10.4f} {np.mean(mle_alphas):>10.4f}")
print(f"{'Bias':>8} {np.mean(mom_alphas)-true_alpha:>10.4f} {np.mean(mle_alphas)-true_alpha:>10.4f}")
print(f"{'Var':>8} {np.var(mom_alphas):>10.4f} {np.var(mle_alphas):>10.4f}")
print(f"{'MSE':>8} {np.mean((mom_alphas-true_alpha)**2):>10.4f} {np.mean((mle_alphas-true_alpha)**2):>10.4f}")
# Gamma(α=2.0, β=1.0) 형태 모수 추정 비교 (n=20)
#              MoM        MLE
#    E[α̂]     2.4525     2.3133
#     Bias     0.4525     0.3133
#      Var     0.8562     0.6278
#      MSE     1.0610     0.7259

MLE가 MoM보다 편향도 작고 분산도 작은 것을 확인할 수 있다. MSE 기준으로 약 32% 더 정확하며, $n$ 이 작을수록 이 차이는 더 두드러지게 된다.

기준	적률법 (MoM)	최대우도추정 (MLE)
계산	닫힌 해. 간단함	반복 최적화 필요할 수 있음
효율성	일반적으로 비효율적	점근적으로 최적 (CRLB 달성)
일치성	✓ (큰 수의 법칙)	✓ (정규 조건 하에서)
비편향성	보장 안 됨	보장 안 됨
점근 정규성	✓ (델타 메서드)	✓ (자동으로 나옴)
모수 공간	추정값이 밖에 나올 수 있음	보통 안에 머뭄
적용 범위	적률이 존재하면 가능	우도 함수를 알아야 함

💡 실전에서의 선택

대부분의 경우 MLE를 쓴다. 특히 ML에서는 거의 모든 학습이 우도 최대화(= 손실 최소화)로 귀결된다. 로지스틱 회귀의 교차 엔트로피 손실이 바로 음의 로그우도다. 적률법은 MLE의 초기값으로 쓰거나, 우도 함수를 모르는 경우(비모수적 상황)에서 유용하다.

흔한 실수와 주의점

1. MLE의 $\sigma^2$ 추정은 편향되어 있다

정규분포 MLE는 $n$ 으로 나누므로 비편향이 아니다. 하지만 MSE 분해에서 봤듯이, 편향된 MLE가 비편향 추정량보다 MSE가 작을 수도 있다. 소표본에서 비편향성이 중요하다면 $n-1$ 로 나눈 $S^2$ 를 써야 하고, 대표본이라면 어느 쪽을 쓰든 차이는 무시할 수준이다.

2. 우도 함수가 다봉(multimodal)일 수 있다

혼합 분포 등에서는 로그우도 함수에 여러 극값이 존재할 수 있다. 이 경우 그래디언트 기반 최적화가 지역 최대(local maximum)에 빠질 위험이 있으므로, EM 알고리즘이나 다중 초기값 전략으로 대응해야 한다.

3. 적률법 추정값이 모수 공간 밖으로 나갈 수 있다

감마 분포에서 표본 분산이 우연히 매우 작으면 $\hat{\alpha}$ 가 비현실적으로 커질 수 있다. MLE는 최적화 자체가 모수 공간 내에서 이루어지기 때문에 이런 문제에 비교적 강건한 편이다.

4. 정규 조건이 만족되지 않으면 점근 성질이 무너진다

MLE의 점근 성질이 성립하려면 정규 조건(regularity conditions)이 반드시 충족되어야 한다:

모수 공간이 열린 집합
서포트(support)가 $\theta$ 에 의존하지 않음
로그우도가 3번 미분 가능

이 조건이 깨지는 대표적 예가 균일분포 $\text{Uniform}(0, \theta)$ 다. 서포트가 $\theta$ 에 의존하므로 MLE( $\hat{\theta} = X_{(n)}$ , 최댓값)의 수렴 속도가 $1/\sqrt{n}$ 이 아니라 $1/n$ 으로, 오히려 더 빠르게 수렴하지만 점근 정규성은 성립하지 않는다.

⚠️ 주의

MLE가 “항상 최선”이라는 인식은 점근적 결과에 기반한 것이다. $n$ 이 작으면 MLE도 편향될 수 있고, 정규 조건이 깨지면 일치성조차 보장되지 않는다. 소표본에서는 추정량의 유한표본 성질을 직접 확인하는 것이 중요하다.

마치며

적률법은 “적률을 맞춘다”는 단순한 원리로 어떤 분포에서든 기계적으로 추정량을 구성할 수 있는 방법이다. 반면 MLE는 “데이터의 우도를 최대화한다”는 원리 위에서, 점근적으로 가장 효율적인 추정량을 제공하게 된다. 대부분의 실전 상황에서 MLE가 선호되며, 특히 ML의 손실 함수 설계 전체가 MLE 프레임워크 위에 서 있다는 점은 기억해둘 만하다.

그런데 MLE가 제공하는 것은 결국 하나의 숫자(점추정값)에 불과하다. “참값은 이 근처에 있다”는 정보를 주지만, 얼마나 근처인지는 알 수 없지 않은가? 다음 글에서 다룰 **신뢰구간(Confidence Interval)**이 바로 이 불확실성을 정량화하는 도구다. 이 글에서 다룬 MLE의 점근 정규성과 피셔 정보량이 그 핵심 역할을 하게 된다.

참고자료

Wasserman, L. (2004). All of Statistics, Chapter 9: Parametric Inference.
Casella, G. & Berger, R. (2002). Statistical Inference (2nd ed.), Chapter 7: Point Estimation.
MIT 18.650: Statistics for Applications, Lectures 3-6.
Fisher, R.A. (1922). “On the Mathematical Foundations of Theoretical Statistics.” Phil. Trans. Royal Society A, 222, 309-368.