SkyWith628

모델 선택과 평가 제대로 이해하기 — NFL부터 교차검증·Selection Bias까지

harang Lee — Thu, 3 Sep 2026 14:15:29 +0900

이번 강의자료는 "모델을 만드는 법"이 아니라 "만든 모델을 어떻게 고르고 믿을 수 있게 평가하느냐"에 관한 파트였습니다. 슬라이드가 목적 함수·가설 같은 용어 정리에서 시작해서 No Free Lunch, 오컴의 면도날 같은 철학적 전제를 깔고, 거기서 Bias-Variance 분해로 오차의 정체를 파고든 다음, 홀드아웃·교차검증·하이퍼파라미터 탐색까지 쭉 이어지더라고요. 중간중간 Wolpert, Domingos, Kohavi, Bergstra·Bengio, Cawley·Talbot 같은 원논문 인용이 계속 튀어나오는 게 인상적이었습니다.

개념이 워낙 많아서, 이 글에서는 자료의 뼈대를 이루는 네 개의 질문으로 압축해 정리하려고 합니다. "완벽한 모델이 왜 없는가 → 오차는 어디서 오는가 → 성능을 어떻게 공정하게 재는가 → 튜닝은 어떻게 하고 어떤 함정이 있는가". 각 주장은 scikit-learn 공식 문서와 원논문으로 근거를 붙였고, 공식 문서가 그 개념을 실제로 어떤 예제 코드로 보여주는지도 같이 담았습니다.

큰 그림 — 네 개의 질문
완벽한 모델은 없다 — No Free Lunch & 오컴의 면도날
오차의 정체 — Bias · Variance · Noise
공정하게 평가하기 — 재치환에서 교차검증까지
튜닝과 그 함정 — Train/Val/Test, Grid vs Random, Selection Bias
치트시트 & 핵심 5가지

1. 큰 그림 — 네 개의 질문

세부 개념으로 들어가기 전에, 이 조각들이 어떻게 맞물리는지 한 장으로 보겠습니다. 아래 네 칸이 이 글의 나머지 섹션과 그대로 대응합니다.

모델 선택·평가 를 이렇게 쪼갠다

▼

완벽한 모델?애초에 없다NFL · Occam

오차는 어디서?세 갈래로 분해Bias+Var+Noise

어떻게 재나?데이터를 아껴 쓴다Holdout→CV

튜닝·함정?선택도 과적합된다Search · Selection Bias

왼쪽에서 오른쪽으로 갈수록 "이론적 전제 → 실전 절차"로 내려옵니다.

핵심을 관통하는 한 문장은 강의자료 표현처럼 "우리가 가진 일부 데이터로 특정 문제를 풀 최적의 모델을 만들고 고른다" 입니다. 문제는 이 최적과 고른다가 생각보다 위험하다는 거죠. 왜 위험한지 첫 칸부터 봅시다.

2. 완벽한 모델은 없다 — No Free Lunch & 오컴의 면도날

모델 선택 이야기를 왜 "완벽한 모델은 없다"로 시작할까요? 만약 모든 문제에서 항상 이기는 만능 알고리즘이 있다면, 애초에 선택이라는 고민 자체가 필요 없을 테니까요. 그런 게 없다는 걸 못 박는 정리가 바로 No Free Lunch입니다.

No Free Lunch (공짜 점심은 없다): 가능한 모든 문제에 대해 성능을 평균 내면, 어떤 알고리즘도 다른 알고리즘보다 낫지 않다는 정리 / 예: 한 데이터셋에서 이긴 모델은 다른 데이터셋에서 반드시 그만큼 진다.

직관적으로 말하면, 특정 문제에서 잘 통하는 건 그 문제의 구조에 맞는 가정을 심어놨기 때문입니다. 그 가정이 안 맞는 다른 문제로 가면 그대로 손해로 돌아옵니다. 강의자료의 막대그래프(Algorithm A vs B)가 딱 이걸 보여줬죠 — 한쪽이 튀어나온 만큼 다른 쪽이 꺼져 있고, 평균선은 결국 같습니다.

원논문은 이렇게 말합니다. Wolpert와 Macready는 어떤 알고리즘이 한 부류의 문제에서 얻은 성능 이득은 다른 부류의 문제에서의 손해로 상쇄된다고 증명했습니다. 한 줄로 요약된 유명한 문장이 "두 알고리즘은 모든 문제에 걸쳐 평균 내면 동등하다" 입니다. (출처: Wolpert & Macready, "No Free Lunch Theorems for Optimization", IEEE TEC, 1997)

그럼 실무 지침은 "정답 알고리즘을 외우지 말고, 문제마다 여러 개를 비교하라"가 됩니다. 그런데 후보가 여럿이면 어느 걸 고를지 기준이 필요하고, 여기서 두 번째 원리인 오컴의 면도날이 등장합니다.

Occam's Razor (오컴의 면도날): 성능이 비슷하게 경쟁하는 가설이 있으면 가정이 가장 적은(가장 단순한) 쪽을 고르라는 원칙 / 모델링에선 보통 파라미터 수가 더 적은 모델.

⚠️ 흔한 오해 — "단순한 모델이 항상 더 정확하다"는 아닙니다. 강의자료가 인용한 Domingos는 오컴의 면도날을 실용적 휴리스틱으로는 인정하되, "단순함이 곧 높은 정확도"라는 해석은 이론적으로 반증됐다고 지적합니다. 그래서 슬라이드가 곧바로 c.f) ensemble(여러 모델 결합 — 오히려 복잡한데 잘 되는 사례)을 붙여둔 거고요. (출처: Domingos, "A Few Useful Things to Know about Machine Learning", CACM, 2012)

어디에 쓰나 — 새 문제를 받으면 "이 도메인엔 이 모델이 국룰"이라고 단정하지 말고, 선형모델 같은 단순 후보부터 트리·부스팅·신경망까지 여러 개를 같은 조건에서 비교하는 습관. 그게 NFL의 실전 번역입니다.

→ 여러 모델을 비교하려면 "성능"을 숫자로 재야 합니다. 그런데 그 숫자, 즉 오차가 대체 무엇으로 이루어져 있는지부터 봐야 합니다.

3. 오차의 정체 — Bias · Variance · Noise

모델을 고른다는 건 결국 "오차가 가장 작은 걸 고른다"는 뜻인데, 그 오차는 한 덩어리가 아니라 성질이 다른 세 조각의 합입니다. 이 분해를 알아야 "지금 내 모델이 덜 배운 건지, 너무 외운 건지"를 진단할 수 있어요.

Bias (편향): 복잡한 현실을 너무 단순한 모델로 근사해서 체계적으로 빗나가는 오차 / 예: 곡선 데이터를 직선으로 억지로 맞출 때.
Variance (분산): 훈련 데이터가 조금만 바뀌어도 모델이 크게 출렁이는 정도 / 예: 데이터의 노이즈까지 통째로 외운 고차 다항식.
Noise (irreducible error, 줄일 수 없는 오차): 데이터 자체에 낀 잡음이라 어떤 모델로도 제거 불가능한 하한.

강의자료의 과녁 그림이 이 셋을 직관적으로 보여줬습니다. 화살이 과녁 중심에서 한쪽으로 쏠려 몰리면 높은 편향(계속 같은 방향으로 틀림), 사방으로 흩어지면 높은 분산(쏠 때마다 제멋대로)이죠. Domingos의 표현을 빌리면 편향은 "계속 같은 걸 틀리는 경향", 분산은 "진짜 신호와 무관하게 랜덤한 걸 학습하는 경향"입니다.

수식으로는 기대 예측 오차가 이렇게 세 조각으로 깔끔하게 나뉩니다(슬라이드 p.84의 유도).

# 기대 예측 오차의 Bias-Variance 분해
E[(y - f̂)²] = Bias[f̂]²  +  Var[f̂]  +  σ²
              (편향²)       (분산)     (노이즈, 줄일 수 없음)

공식 문서는 이렇게 설명합니다. scikit-learn의 underfitting/overfitting 예제는 편향과 분산을 모델 복잡도(다항식 차수)로 직접 보여줍니다. 차수 1은 데이터를 못 따라가는 과소적합(underfitting), 차수가 너무 높으면 "훈련 데이터의 노이즈를 학습한다"는 과대적합(overfitting)이라고 짚죠. 중요한 건 이걸 눈대중이 아니라 교차검증으로 정량화한다는 점입니다. (출처: scikit-learn, "Underfitting vs. Overfitting" 예제)

# scikit-learn 공식 예제 — 복잡도(차수)별 일반화 오차를 CV로 측정
from sklearn.model_selection import cross_val_score
scores = cross_val_score(
    pipeline, X[:, np.newaxis], y,
    scoring="neg_mean_squared_error", cv=10)
# degree 1  → MSE 4.08e-01  (underfit, 높은 편향)
# degree 4  → MSE 4.32e-02  (딱 좋음)
# degree 15 → MSE 2.20e-01  (overfit, 높은 분산)

여기서 자연스럽게 Bias-Variance Trade-off가 나옵니다. 모델을 복잡하게 만들면 편향은 줄지만 분산이 커지고, 단순하게 만들면 반대가 됩니다. 그래서 총 오차는 U자를 그리고, 그 최저점이 최적 복잡도예요. 학습 곡선(train/validation accuracy)의 간격으로도 진단할 수 있는데, 두 곡선이 낮은 데서 붙어 수렴하면 높은 편향, 간격이 크게 벌어지면 높은 분산입니다.

핵심 — 훈련 데이터로 잰 정확도는 진짜보다 낙관적으로 부풀려집니다(편향된 추정). 다만 강의자료의 통찰처럼, 이 낙관적 편향이 모든 후보 모델에 똑같이 작용한다면 모델을 서로 비교하는 데는 문제가 없습니다. 우리가 알고 싶은 건 절대 성능이 아니라 상대 순위니까요. 문제는 이 "똑같이"가 깨질 때 생깁니다 — 그게 뒤의 Selection Bias죠.

어디에 쓰나 — 검증 성능이 낮을 때 처방이 갈립니다. 높은 편향(과소적합)이면 feature를 늘리거나 더 복잡한 모델로, 높은 분산(과대적합)이면 데이터를 더 모으거나 규제(L2·Dropout)·조기 종료로. 어느 쪽인지 모르면 엉뚱한 처방을 하게 됩니다.

→ 그런데 이 "일반화 오차"를 대체 어떤 데이터로 재야 부풀려지지 않을까요? 평가 방법의 발전사를 따라가 봅니다.

4. 공정하게 평가하기 — 재치환에서 교차검증까지

오차를 세 조각으로 나눴으니, 이제 그걸 믿을 수 있게 측정할 차례입니다. 평가 방법은 "왜 이전 방법이 위험한가"를 하나씩 메우며 발전해 왔어요.

① 하면 안 되는 것 — 재치환 평가. Resubstitution evaluation (재치환 평가): 훈련에 쓴 바로 그 데이터로 성능을 재는 것. 공식 문서도 이걸 대놓고 경고합니다 — 방금 본 라벨을 그대로 되뇌는 모델은 "완벽한 점수"를 받지만 새 데이터엔 쓸모가 없고, 이게 바로 과대적합이라고요. (출처: scikit-learn, "Cross-validation" 개요)

② 기본 — 홀드아웃. Holdout (홀드아웃): 데이터를 훈련용과 테스트용으로 나눠, 테스트셋은 학습에 쓰지 않고 "처음 보는 데이터" 역할로 남겨두는 것. scikit-learn의 기본 예제가 딱 이겁니다.

# 공식 예제 — 홀드아웃: iris를 train 60% / test 40%로 분리
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.4, random_state=0)

clf = svm.SVC(kernel='linear', C=1).fit(X_train, y_train)
clf.score(X_test, y_test)   # → 0.96

홀드아웃엔 피할 수 없는 trade-off가 있습니다. 테스트셋을 크게 떼면 모델이 학습에 쓸 데이터가 줄어 성능이 실제보다 낮게 나오고(비관적 편향), 작게 떼면 성능 추정이 운에 크게 흔들립니다(분산 증가). 게다가 한 번의 분할은 어쩌다 쉬운/어려운 테스트셋이 걸리는 우연을 통제하지 못하죠.

여기서 두 가지 보강이 나옵니다. 하나는 분할할 때 클래스 비율을 유지하는 Stratified sampling (계층 샘플링)인데, 공식 문서는 StratifiedKFold가 각 fold에 원본과 거의 같은 클래스 비율을 담아준다고 설명합니다 — 불균형 데이터에서 필수죠. 이게 추정치의 분산·편향에 좋다는 건 Kohavi(1995)가 실증했습니다. 다른 하나는 시드를 바꿔 홀드아웃을 여러 번 반복해 평균 내는 반복 홀드아웃 = Monte Carlo CV고요.

③ 표준 — K-Fold 교차검증. K-Fold Cross-Validation (K-겹 교차검증): 데이터를 k조각으로 나눠, 번갈아 한 조각을 검증용으로 쓰고 나머지 k-1조각으로 학습하기를 k번 반복한 뒤 평균 내는 방법. 모든 데이터를 검증에 한 번씩 써서 홀드아웃의 "운" 문제를 눌러줍니다.

# 공식 예제 — 5-fold CV로 정확도의 평균과 표준편차를 함께 본다
from sklearn.model_selection import cross_val_score
scores = cross_val_score(clf, X, y, cv=5)
# scores → [0.96, 1. , 0.96, 0.96, 1. ]
# 0.98 accuracy with a standard deviation of 0.02

공식 문서가 콕 집어 말하는 포인트: "최종 평가용 테스트셋은 여전히 따로 떼어둬야 하고, CV를 하면 별도의 검증셋은 더 필요 없다". 즉 CV는 훈련셋 안에서 검증을 돌리는 것이고, 테스트셋은 건드리지 않습니다. 그리고 강의자료가 강조했듯 CV로 얻은 모델은 최종 모델이 아닙니다 — CV는 "이 설정이 좋다"를 알아내는 절차일 뿐, 최종 모델은 전체 데이터로 다시 학습합니다.

⚠️ Data Leakage (데이터 누수) — 테스트/검증 정보가 학습에 새어드는 것. 강의자료의 Kaggle 암 예측 사례처럼, "전립선 수술 여부" 필드가 사실상 "이미 암 진단을 받았다"를 의미하면 정답이 새어듭니다. 시계열 데이터를 무작위 분할하면 미래가 과거 학습에 섞이는 것도 같은 함정이고요. 스케일링을 전체 데이터에 fit한 뒤 나누는 것도 흔한 누수입니다 — 분할을 먼저, 전처리는 훈련셋에만 fit이 원칙입니다.

어디에 쓰나 — 데이터가 넉넉하면 홀드아웃으로 빠르게, 데이터가 적거나 성능 추정을 안정적으로 보고해야 하면 (Stratified) K-Fold. 불균형 분류는 거의 항상 StratifiedKFold. 시계열은 무작위 CV 대신 TimeSeriesSplit으로 시간 순서를 지켜야 합니다.

→ 여기까지가 "성능을 재는 법"이었습니다. 이제 그 측정을 반복해서 최적 설정을 고르는 튜닝 단계로 넘어가는데, 바로 여기에 가장 미묘한 함정이 숨어 있습니다.

5. 튜닝과 그 함정 — Train/Val/Test, Grid vs Random, Selection Bias

하이퍼파라미터를 바꾸면 매번 다른 모델이 나옵니다. 그중 가장 좋은 걸 고르는 게 Model Selection (모델 선택)인데, 이 "고르는" 행위 자체가 데이터에 과적합될 수 있다는 게 이 섹션의 핵심입니다.

① 역할을 셋으로 나눈다. 강의자료가 반복 강조한 3분할입니다.

세트	역할	쓰는 곳
Training	모델 파라미터 학습	`fit()`
Validation	모델·하이퍼파라미터 선택	Grid / Random Search
Test	최종 성능 평가 (딱 1회)	배포 직전 확인

가장 성능 좋은 모델만 고르면 되고 편향 없는 일반화 성능 추정엔 관심이 없다면 2분할(train/test)만으로도 됩니다. 하지만 튜닝까지 하려면 validation이 필요해요. 그리고 테스트셋으로 정확도만 높은 모델을 고르기보다, 목적에 맞는 지표(불균형이면 F1·Recall 등)로 골라야 한다는 점도 슬라이드가 짚었습니다.

② 탐색 방법 — Grid vs Random. Grid Search (격자 탐색): 지정한 값들의 모든 조합을 전수 평가. 공식 문서 표현으로는 fit할 때 가능한 조합을 다 평가하고 최고를 남깁니다.

# 공식 예제 — GridSearchCV용 파라미터 격자 (조합을 전수 탐색)
param_grid = [
  {'C': [1, 10, 100, 1000], 'kernel': ['linear']},
  {'C': [1, 10, 100, 1000], 'gamma': [0.001, 0.0001],
   'kernel': ['rbf']},
]

Randomized Search (랜덤 탐색): 분포에서 정해진 횟수(n_iter)만큼 조합을 샘플링. 공식 문서가 밝히는 두 가지 이점이 명확합니다 — "파라미터 개수·값 수와 무관하게 예산을 정할 수 있고", "성능에 영향 없는 파라미터를 추가해도 효율이 떨어지지 않는다".

# 공식 예제 — RandomizedSearchCV용 분포 (연속 구간에서 샘플링)
from sklearn.utils.fixes import loguniform
{'C': loguniform(1e0, 1e3),
 'gamma': loguniform(1e-4, 1e-3),
 'kernel': ['rbf'],
 'class_weight': ['balanced', None]}

원논문은 이렇게 말합니다. Bergstra와 Bengio는 랜덤 탐색이 격자 탐색보다 경험적으로도 이론적으로도 더 효율적이며, 같은 도메인에서 훨씬 적은 계산으로도 동등하거나 더 나은 모델을 찾는다고 보고했습니다. 강의자료의 그 유명한 그림 — 소수의 중요한 파라미터가 성능을 좌우할 때, 격자는 중요 축을 3개 값만 훑지만 랜덤은 같은 예산으로 9개 값을 훑는다 — 이 그게 핵심 직관입니다. (출처: Bergstra & Bengio, "Random Search for Hyper-Parameter Optimization", JMLR, 2012)

③ 가장 미묘한 함정 — Selection Bias. Selection Bias (선택 편향): 검증 성능만 보고 하이퍼파라미터를 고르다 보면, 모델이 검증셋에까지 과적합되어 최종 성능이 낙관적으로 부풀려지는 현상.

원논문은 이렇게 말합니다. Cawley와 Talbot은 모델 선택 기준의 불편성(unbiasedness)보다 낮은 분산이 최소한 그만큼 중요하다고 강조합니다. 검증 성능 추정에 무시 못 할 분산이 있으면, 그 노이즈에 맞춰 하이퍼파라미터를 고르는 순간 모델 선택 단계에서도 과적합이 일어나기 때문이죠. 처방은 Nested Cross-Validation (중첩 교차검증) — 안쪽 루프는 하이퍼파라미터 튜닝, 바깥쪽 루프는 성능 평가로 선택과 평가를 분리합니다. (출처: Cawley & Talbot, "On Over-fitting in Model Selection and Subsequent Selection Bias in Performance Evaluation", JMLR, 2010)

# 개념 — Nested CV: 선택(inner)과 평가(outer)를 분리
from sklearn.model_selection import GridSearchCV, cross_val_score, KFold

inner = KFold(n_splits=5, shuffle=True, random_state=0)
outer = KFold(n_splits=5, shuffle=True, random_state=1)

clf = GridSearchCV(estimator, param_grid, cv=inner)      # 안쪽: 하이퍼파라미터 선택
scores = cross_val_score(clf, X, y, cv=outer)            # 바깥: 편향 없는 성능 추정
# scores.mean() ← 튜닝까지 감안한 정직한 일반화 성능

핵심 — 3번 섹션에서 "낙관적 편향이 모든 모델에 똑같이 작용하면 비교엔 문제없다"고 했었죠. Selection Bias는 바로 그 "똑같이"가 깨지는 지점입니다. 후보를 많이 시도할수록, 그중 검증셋에 운 좋게 잘 맞은 하나가 뽑힐 확률이 커지거든요. 그래서 시도 횟수가 많을수록 Nested CV의 가치가 커집니다.

어디에 쓰나 — 논문·경진대회처럼 정직한 최종 성능 숫자를 보고해야 할 때는 Nested CV. 반대로 데이터가 크고 시도가 적어 선택 편향이 작을 땐 단순 train/val/test 3분할로도 충분합니다(비용이 큰 만큼 상황을 보고 결정).

6. 치트시트 & 핵심 5가지

상황	패턴
기본 홀드아웃	`train_test_split(X, y, test_size=0.2, stratify=y, random_state=0)`
안정적 성능 추정	`cross_val_score(clf, X, y, cv=5)` → 평균 ± 표준편차
불균형 분류	`StratifiedKFold(n_splits=5)`
시계열	`TimeSeriesSplit` (무작위 CV 금지 — 누수)
파라미터 적음·전수	`GridSearchCV(estimator, param_grid, cv=5)`
파라미터 많음·예산 제한	`RandomizedSearchCV(estimator, dist, n_iter=50, cv=5)`
정직한 최종 성능	Nested CV: `cross_val_score(GridSearchCV(...), X, y, cv=outer)`
최종 배포 모델	고른 설정으로 전체 데이터 재학습

딱 5가지만 기억하면 됩니다.
1. 만능 모델은 없다 — 문제마다 여러 후보를 같은 조건에서 비교(NFL).
2. 오차 = 편향² + 분산 + 노이즈 — 진단이 처방을 가른다.
3. 같은 데이터로 학습·평가 금지 — 재치환은 낙관적 거짓말, 테스트셋은 최종 1회.
4. 데이터를 아껴 쓰려면 CV — 불균형은 Stratified, 시계열은 시간 순서 유지.
5. 선택도 과적합된다 — 튜닝까지 정직하게 재려면 Nested CV(Selection Bias).

참고 자료

scikit-learn — Cross-validation: evaluating estimator performance
scikit-learn — Tuning the hyper-parameters of an estimator
scikit-learn — Underfitting vs. Overfitting
Wolpert & Macready (1997) — No Free Lunch Theorems for Optimization, IEEE TEC
Domingos (2012) — A Few Useful Things to Know about Machine Learning, CACM
Bergstra & Bengio (2012) — Random Search for Hyper-Parameter Optimization, JMLR
Cawley & Talbot (2010) — On Over-fitting in Model Selection and Subsequent Selection Bias, JMLR
Kohavi (1995) — A Study of Cross-Validation and Bootstrap for Accuracy Estimation and Model Selection, IJCAI

LLM 에이전트의 Human-in-the-Loop — LangGraph interrupt로 멈추고 재개하기

harang Lee — Wed, 2 Sep 2026 13:56:52 +0900

부트캠프에서 LLM 에이전트를 만들다 보면 슬슬 무서워지는 순간이 옵니다. 에이전트가 스스로 판단해서 도구를 호출하는데, 그게 메일 발송이나 DB 삭제 같은 되돌릴 수 없는 행동이면요. "얘가 혼자 다 처리하게 두는 게 맞나?" 싶은 지점, 바로 여기서 Human-in-the-Loop가 등장합니다.

이 글은 HITL이 무엇이고 왜 필요한지, 그리고 실전에서 LangGraph의 interrupt()로 이걸 어떻게 구현하는지를 공식 문서를 근거로 정리합니다. 앞서 정리한 프레임워크 시리즈가 "모델을 학습시키는 법"이었다면, 이건 "학습된 모델(에이전트)을 안전하게 굴리는 법"에 가깝습니다.

1. 큰 그림 — 멈추고, 묻고, 재개한다

HITL의 뼈대는 단순합니다. 위험한 순간에 멈추고, 사람에게 묻고, 답을 받아 재개하는 것. LangGraph는 이 세 동작에 각각 도구를 하나씩 붙여놨습니다.

Human-in-the-Loop 를 네 조각으로

▼

왜 멈추나?위험·불확실 행동 전발송·삭제·결제

어떻게 멈추나?노드 안에서 정지interrupt()

어떻게 재개?사람 답으로 이어감Command(resume=)

무엇을 저장?멈춘 상태 보존checkpointer

2장 개념·이유, 3장 패턴, 4장 LangGraph 구현 순으로 채웁니다.

2. HITL이 뭐고, 왜 필요한가

Human-in-the-Loop (HITL, 휴먼 인 더 루프): 자동화 과정 중간에 사람의 승인·수정·검토를 끼워 넣는 설계 / AI가 제안하면 사람이 확인한 뒤 이어감.

비유하자면 수술 동의서 같은 겁니다. 의사(에이전트)가 판단은 내리되, 몸에 칼을 대기(되돌릴 수 없는 행동) 직전엔 환자(사람)의 서명을 받는 거죠. 판단은 자동으로, 결단은 사람이.

왜 필요할까요. LLM 에이전트의 핵심은 도구 호출(tool call: 에이전트가 외부 함수·API를 실행하는 것)인데, 이 도구가 실제 세계를 바꿉니다. 검색이야 몇 번 틀려도 되지만, "환불 메일 일괄 발송"이나 "테이블 DROP"은 한 번 나가면 끝입니다. 에이전트가 프롬프트 한 줄 오해로 이런 행동을 하면 사고가 되죠. 그래서 영향이 크고 되돌리기 어려운 지점 앞에 사람을 세웁니다.

사실 지금 여러분이 쓰는 AI 도구 상당수가 이미 HITL입니다. 코딩 에이전트가 파일을 지우기 전 확인을 받거나, 어시스턴트가 메일을 보내기 전 "이대로 보낼까요?"라고 묻는 것 전부 같은 패턴이에요.

어디에 쓰나 — 고객 응대 자동화(환불·계정 변경 전 상담사 승인), 코드 에이전트(배포·마이그레이션 전 개발자 확인), 데이터 파이프라인(삭제성 쿼리 전 검토). "자동화하되 사고는 막고 싶은" 모든 곳.

→ 그럼 사람을 어떤 방식으로 끼워 넣을까요? 대표 패턴 넷을 봅니다.

3. 대표 패턴 4가지

HITL이라고 다 "예/아니오"만 있는 게 아닙니다. LangGraph 공식 문서는 개입 방식을 크게 네 가지로 정리합니다. (참고: LangGraph — Human-in-the-loop concepts)

패턴	사람이 하는 일	예시
Approve / Reject (승인/거부)	위험 행동을 통과시키거나 막기	결제·발송·배포 직전 게이트
Edit state (상태 수정)	에이전트가 만든 결과를 고쳐서 진행	초안 메일 문구 다듬기
Review tool call (도구 호출 검토)	실행 전 인자·쿼리를 확인·교정	생성된 SQL 검토 후 실행
Validate input (입력 검증)	사람에게 필요한 정보를 되물어 받기	모자란 값 재확인

넷 다 근본은 같습니다 — "실행 흐름을 잠깐 멈추고 사람에게 제어권을 넘긴다." 다른 건 사람이 돌려주는 값이 승인 여부냐, 수정된 텍스트냐, 교정된 인자냐일 뿐이에요.

어디에 쓰나 — 위험도에 따라 패턴을 섞습니다. 저위험은 Review로 슬쩍 보여만 주고, 고위험(자금 이체 등)은 Approve/Reject로 명시적 승인을 강제하는 식으로요.

→ 이제 이걸 실제 코드로. LangGraph의 interrupt입니다.

4. LangGraph interrupt — 멈추고 재개하기

패턴이 다 "멈추고 → 사람 값 받고 → 재개"로 수렴한다고 했는데, LangGraph는 이걸 함수 하나로 제공합니다.

interrupt() (인터럽트): 노드 안에서 그래프 실행을 멈추고 사람에게 값을 넘긴 뒤, 답이 오면 그 자리부터 이어가는 함수.
Command(resume=값): 멈춘 그래프를 다시 굴리는 명령. 여기 넣은 값이 interrupt()의 반환값이 됨.
checkpointer (체크포인터): 멈춘 시점의 그래프 상태를 저장해 두는 저장소.

공식 문서는 이렇게 설명합니다. interrupt()는 노드 안에서 "a resumable exception", 즉 재개 가능한 예외를 던져 그래프를 멈추고, 넘긴 값을 클라이언트로 보냅니다. 그리고 사람이 답하면 Command(resume=...)으로 재개하죠. (출처: LangChain Reference — interrupt)

from langgraph.types import interrupt, Command

def node(state):
    answer = interrupt("what is your age?")   # 여기서 멈춤 → 사람에게 질문 전달
    return {"human_value": answer}         # answer = 사람이 준 값

# 1차 실행 — interrupt에서 정지
graph.stream({"foo": "abc"}, config)

# 사람 입력으로 재개
graph.stream(Command(resume="some input from a human!!!"), config)
# > human_value = "some input from a human!!!"

승인/거부 패턴이라면 이런 모습이 됩니다. 넘긴 값(초안)을 사람이 보고, 돌아온 값(decision)으로 분기하는 거죠.

def approval_node(state):
    decision = interrupt({"action": "send_email",
                          "draft": state["draft"]})   # 사람에게 초안 보여주고 대기
    if decision == "approve":
        return {"status": "sending"}
    return {"status": "cancelled"}

그런데 이게 동작하려면 전제가 하나 있습니다. 멈춘 상태를 어딘가 저장해 둬야 나중에 이어갈 수 있겠죠. 공식 문서도 "you must enable a checkpointer" — 체크포인터를 반드시 켜라고 못박습니다. (출처: LangChain Reference — interrupt)

from langgraph.checkpoint.memory import InMemorySaver

graph = builder.compile(checkpointer=InMemorySaver())   # 상태 저장소 필수
# 재개 때 어느 대화인지 찾도록 thread_id를 config로 넘긴다
config = {"configurable": {"thread_id": "user-42"}}

⚠️ ★ 최대 함정 · 노드가 통째로 재실행된다 — 공식 문서는 "The graph resumes from the start of the node, re-executing all logic."라고 합니다. 재개하면 그 노드가 interrupt() 지점부터가 아니라 맨 처음부터 다시 돕니다. 그래서 interrupt() 앞에 부작용 있는 코드(메일 발송, 카운터 증가, 랜덤 생성)를 두면 두 번 실행됩니다. 부작용은 반드시 interrupt 뒤로 빼거나 별도 노드로 분리하세요.

InMemorySaver는 프로세스가 죽으면 상태도 사라집니다. 실서비스에서 사람이 며칠 뒤 승인할 수도 있는 흐름이라면 DB 기반 체크포인터(예: Postgres saver)로 영속화해야 재개가 보장됩니다.

어디에 쓰나 — 챗봇이 "이 주문을 취소할까요?"라 묻고 사용자 클릭을 기다리는 흐름, 승인 대기 중 며칠이 지나도 되는 결재 워크플로. 멈춤과 재개 사이에 시간이 흐를 수 있는 모든 에이전트에 필수입니다.

5. 언제 걸어야 하나 — 과하지 않게

마지막으로 실무 감각 하나. 모든 스텝에 사람을 넣으면 자동화한 의미가 없습니다. 개입 지점은 두 축으로 고릅니다 — 영향의 크기(되돌릴 수 있나?)와 불확실성(에이전트가 확신하나?).

영향 크고 · 불확실 → 무조건 승인 게이트 (자금 이체, 대량 발송)
영향 크고 · 확실 → 요약만 보여주고 통과 (되돌릴 순 있게 로그 남김)
영향 작음 → 사람 개입 없이 자동 (검색, 조회)

신뢰도 임계값을 두어 "에이전트가 확신 못 하는 경우에만" 사람에게 넘기는 것도 흔한 설계입니다. 자동화율과 안전성 사이의 트레이드오프를 조절하는 손잡이인 셈이죠.

치트시트 & 핵심 4가지

하고 싶은 것	패턴
노드에서 멈추고 묻기	`answer = interrupt(payload)`
사람 답으로 재개	`graph.stream(Command(resume=값), config)`
상태 저장(필수)	`compile(checkpointer=InMemorySaver())`
대화 식별	`config={"configurable":{"thread_id":...}}`
부작용 코드 위치	반드시 `interrupt()` 뒤에

딱 4가지만 기억하면 됩니다.
1. HITL = 되돌릴 수 없는 행동 앞에 사람을 세우는 것.
2. 패턴은 승인/거부 · 수정 · 도구검토 · 입력검증 넷, 뿌리는 "멈추고 제어권 넘기기".
3. LangGraph는 interrupt()로 멈추고 Command(resume=)로 재개, checkpointer 필수.
4. 재개 시 노드가 통째로 재실행된다 — 부작용은 interrupt 뒤로!

참고 자료

LangChain Reference — interrupt (공식 문서) : "resumable exception", "resumes from the start of the node", "must enable a checkpointer"
LangGraph — Human-in-the-loop (공식 개념 문서) : approve/reject·edit·review·validate 패턴
LangGraph — Persistence & Checkpointers (공식 문서)

TensorFlow 전문가 학습 루프 — 서브클래싱·GradientTape·@tf.function

harang Lee — Tue, 1 Sep 2026 14:59:07 +0900

공식 TensorFlow 튜토리얼에는 "초보자용"과 "전문가용" 두 개의 quickstart가 나란히 있습니다. 초보자용은 model.fit() 한 줄로 학습이 끝나는데, 전문가용은 학습 루프를 손으로 다 씁니다. 처음엔 "왜 굳이 번거롭게?" 싶었는데, 뜯어보니 fit()이 안에서 대신 해주던 일이 전부 코드로 드러나더라고요.

이 글은 전문가용 quickstart(MNIST 분류기)를 근거로, 커스텀 학습 루프의 세 축 — 모델 서브클래싱, GradientTape, @tf.function — 을 공식 문서와 함께 정리합니다. GAN이나 강화학습처럼 fit()으로 안 되는 걸 만들려면 반드시 넘어야 하는 문턱이에요.

1. 큰 그림 — 학습 루프의 톱니바퀴

모델을 학습시킨다는 건 결국 "예측하고 → 틀린 만큼 재고 → 그만큼 고치기"의 반복입니다. 전문가판은 이 톱니바퀴를 직접 조립하는데, 조각은 이렇게 나뉩니다.

커스텀 학습 루프 를 네 조각으로

▼

어떻게 계산?모델 서브클래싱call()

어떻게 미분?기울기 기록GradientTape

어떻게 배우나?가중치 갱신apply_gradients

왜 빠른가?그래프 컴파일@tf.function

2장 모델, 3장 기울기(GradientTape), 4장 속도(@tf.function) 순으로 채웁니다.

2. 모델 서브클래싱 — call()에 순전파를 쓴다

먼저 "어떻게 계산하는가", 즉 모델부터. 전문가판은 Sequential로 쌓는 대신 Model을 상속받아 만듭니다.

subclassing (서브클래싱): 상위 클래스를 상속해 원하는 메서드를 직접 구현하는 것 / 여기선 Model을 상속해 call()을 채움.

레이어는 __init__에서 미리 만들어 두고, 데이터가 흐르는 순서(순전파)는 call()에 파이썬 코드로 씁니다. "부품을 사물함에 넣어두고(__init__), 조립 순서를 설명서에 적는(call)" 셈이죠. (참고: TensorFlow — Quickstart for experts)

class MyModel(Model):
  def __init__(self):
    super().__init__()
    self.conv1 = Conv2D(32, 3, activation='relu')
    self.flatten = Flatten()
    self.d1 = Dense(128, activation='relu')
    self.d2 = Dense(10)              # 출력 10클래스, softmax 없음(logits)

  def call(self, x):                  # 순전파 경로를 직접 기술
    x = self.conv1(x)
    x = self.flatten(x)
    x = self.d1(x)
    return self.d2(x)

출력층에 softmax가 없는 게 눈에 띕니다. 확률 대신 logits(로짓: 정규화 전 원점수)를 그대로 내보내고, 손실 함수에서 SparseCategoricalCrossentropy(from_logits=True)로 받습니다. 이렇게 하면 softmax와 로그를 한데 묶어 계산해 수치적으로 더 안정적입니다.

어디에 쓰나 — 레이어 사이에 조건 분기가 필요하거나(입력에 따라 경로가 갈리는 모델), 하나의 call에서 여러 출력을 내야 할 때. 연구용 커스텀 아키텍처는 대부분 이 서브클래싱 방식으로 짭니다.

→ 다음은 이 모델의 오차를 어떻게 미분하는가, GradientTape입니다.

3. GradientTape — 자동미분의 녹음기

모델이 예측을 내면 손실을 구하고, 그 손실을 가중치로 미분해야 "어느 방향으로 고칠지"를 압니다. 이 미분을 자동으로 해주는 게 GradientTape입니다.

tf.GradientTape (그래디언트 테이프): 연산 과정을 기록해 두었다가 자동으로 미분해주는 도구 / with 블록 안의 계산을 추적함.

이름 그대로 테이프(녹음기)가 직관입니다. with 블록 안에서 벌어지는 계산을 쭉 녹음해 두었다가, 나중에 거꾸로 재생하며 기울기를 뽑아냅니다.

공식 문서는 이렇게 설명합니다. 텐서플로가 테이프 안에서 실행된 연산을 "'records' relevant operations ... onto a 'tape'", 즉 테이프에 기록해 두고, 그 테이프로 역방향 미분(reverse mode)을 수행해 기울기를 계산한다고 합니다. (출처: TensorFlow — Introduction to gradients and automatic differentiation)

# 배치 하나에 대한 학습 스텝
with tf.GradientTape() as tape:     # ① 연산 녹음 시작
    predictions = model(images, training=True)  # 순전파
    loss = loss_object(labels, predictions)      # 손실
gradients = tape.gradient(loss, model.trainable_variables)   # ② 역재생 → 기울기
optimizer.apply_gradients(zip(gradients, model.trainable_variables))  # ③ 갱신

여기서 training=True는 Dropout·BatchNorm처럼 학습/추론 때 동작이 다른 레이어를 위한 스위치입니다. 평가할 땐 training=False로 두고, 그 스텝에는 GradientTape도 apply_gradients도 두지 않습니다(가중치를 안 바꾸니까요).

어디에 쓰나 — 기본 분류·회귀는 물론, 손실을 커스텀하는 모든 경우. GAN의 생성자/판별자 각각의 손실, 강화학습의 정책 경사, 적대적 예제 생성처럼 "표준 손실 하나로 안 끝나는" 학습이 전부 GradientTape 위에서 굴러갑니다.

→ 마지막은 이 루프를 수십 배 빠르게 만드는 @tf.function입니다.

4. @tf.function — 파이썬을 그래프로 컴파일

학습 스텝을 파이썬으로 한 줄씩 실행하면 느립니다. 여기에 데코레이터 하나를 붙이면 텐서플로가 그 함수를 정적 계산 그래프로 컴파일해 크게 가속합니다.

@tf.function (그래프 컴파일 데코레이터): 파이썬 함수를 텐서플로 그래프로 변환해 빠르게 실행하게 만드는 것.

@tf.function                       # 이 한 줄이 함수를 그래프로
def train_step(images, labels):
    with tf.GradientTape() as tape:
        predictions = model(images, training=True)
        loss = loss_object(labels, predictions)
    gradients = tape.gradient(loss, model.trainable_variables)
    optimizer.apply_gradients(zip(gradients, model.trainable_variables))

⚠️ 함정 · 그래프 모드의 부작용 — @tf.function 안에서는 파이썬 print나 리스트 append 같은 부작용이 기대와 다르게(추적 시점에 한 번만) 동작할 수 있습니다. 디버깅할 땐 데코레이터를 잠깐 떼고 eager 모드(즉시 실행)로 값을 확인한 뒤 다시 붙이는 게 안전합니다. (참고: TensorFlow — Better performance with tf.function)

어디에 쓰나 — 매 배치 수천 번 호출되는 train_step/test_step에 붙이면 체감 속도가 확 올라갑니다. 반대로 한 번만 실행하는 코드나 디버깅 중인 코드엔 굳이 붙이지 않습니다.

치트시트 & 핵심 4가지

단계	코드
모델 정의	`class M(Model): def call(self, x): ...`
손실(로짓)	`SparseCategoricalCrossentropy(from_logits=True)`
기울기 기록	`with tf.GradientTape() as tape: ...`
기울기 계산	`tape.gradient(loss, model.trainable_variables)`
가중치 갱신	`optimizer.apply_gradients(zip(grads, vars))`
가속	`@tf.function` (train_step 위에)

딱 4가지만 기억하면 됩니다.
1. 커스텀 모델은 Model 서브클래싱 + call(). 출력은 logits, 손실은 from_logits=True.
2. GradientTape는 with 블록을 녹음했다가 tape.gradient로 역재생해 미분한다.
3. 갱신은 apply_gradients, 평가 스텝엔 테이프·갱신을 두지 않는다.
4. @tf.function으로 스텝을 그래프 컴파일 → 빠름. 단 디버깅 땐 떼기.

참고 자료

TensorFlow — Quickstart for experts (공식 문서) : 서브클래싱·GradientTape 학습 루프 전체
TensorFlow — Introduction to gradients and automatic differentiation (공식 문서) : "records ... onto a tape", 역방향 미분
TensorFlow — Better performance with tf.function (공식 문서)
「PyTorch 학습 루프」 (다음 글) : 같은 루프를 loss.backward()로 — TF↔PyTorch 대응

PyTorch 학습 루프 — nn.Module·loss.backward()와 zero_grad 함정 (TF 대응)

harang Lee — Tue, 1 Sep 2026 14:58:45 +0900

바로 앞 글에서 TensorFlow 전문가 학습 루프(「TensorFlow 전문가 학습 루프」)를 정리했는데요. PyTorch 공식 quickstart를 열어보니 구조가 거의 판박이였습니다. 모델을 클래스로 정의하고, 배치마다 예측→손실→미분→갱신을 도는 흐름이요. 다만 문법이 다르고, PyTorch에만 있는 함정이 하나 있더라고요 — 바로 zero_grad()입니다.

이 글은 PyTorch quickstart(FashionMNIST 분류기)를 근거로 nn.Module 서브클래싱, autograd와 loss.backward(), train()/eval()를 정리하되, TF를 아는 사람이 바로 매핑할 수 있게 대응 관계를 먼저 깔고 갑니다.

1. 큰 그림 — TF와 같은 루프, 다른 문법

학습 루프의 네 조각(계산·미분·갱신·초기화)은 TF와 동일합니다. PyTorch식 답을 지도로 먼저 보겠습니다.

PyTorch 학습 루프 를 네 조각으로

▼

어떻게 계산?모듈 서브클래싱forward()

어떻게 미분?역전파loss.backward()

어떻게 배우나?가중치 갱신optimizer.step()

★ 초기화?기울기 리셋zero_grad()

TF엔 없던 네 번째 칸(zero_grad)이 PyTorch 초심자 1순위 함정입니다.

TF 전문가판을 이미 봤다면, 아래 대응표 하나로 문법이 거의 다 매핑됩니다.

하는 일	TensorFlow	PyTorch
모델 정의	`Model` → `call()`	`nn.Module` → `forward()`
기울기 계산	`tape.gradient(loss, vars)`	`loss.backward()`
가중치 갱신	`optimizer.apply_gradients(...)`	`optimizer.step()`
기울기 초기화	테이프가 매번 새로 시작	`optimizer.zero_grad()` 필수
추론 모드	`training=False`	`model.eval()` + `torch.no_grad()`

2. nn.Module 서브클래싱 — forward()에 순전파

계산 방식, 즉 모델부터. TF의 call()에 해당하는 게 PyTorch의 forward()입니다.

nn.Module (신경망 모듈): PyTorch 모든 모델·레이어의 기반 클래스 / 상속받아 forward()를 구현하면 모델이 됨.

구성은 TF와 판박이입니다. 레이어는 __init__에서 만들고, 순전파는 forward()에 씁니다.

class NeuralNetwork(nn.Module):
    def __init__(self):
        super().__init__()
        self.flatten = nn.Flatten()
        self.linear_relu_stack = nn.Sequential(
            nn.Linear(28*28, 512), nn.ReLU(),
            nn.Linear(512, 512), nn.ReLU(),
            nn.Linear(512, 10),                # logits (softmax 없음)
        )
    def forward(self, x):
        x = self.flatten(x)
        return self.linear_relu_stack(x)

model = NeuralNetwork().to(device)      # 모델을 GPU 등으로 명시적 이동

여기도 출력층에 softmax가 없습니다. PyTorch의 nn.CrossEntropyLoss가 내부에서 log_softmax와 음의 로그가능도를 함께 처리하기 때문인데요. TF의 from_logits=True와 정확히 같은 이유입니다. 앞 글에서 본 그 논리 그대로예요.

어디에 쓰나 — 사전학습 모델을 불러와 forward 일부만 바꿔 파인튜닝하거나, 커스텀 레이어를 끼워 넣을 때. 허깅페이스 Transformers 모델도 전부 nn.Module이라 이 구조를 알면 그대로 응용됩니다.

→ 다음은 PyTorch의 심장, autograd와 backward입니다.

3. autograd와 backward — 그리고 zero_grad 함정

TF가 GradientTape로 연산을 녹음했다면, PyTorch는 텐서에 연산 이력을 자동으로 붙여 둡니다. 이걸 autograd라 부르고, 미분은 loss.backward() 한 줄로 촉발됩니다.

autograd (자동 미분 엔진): 텐서 연산을 그래프로 추적해 backward() 때 기울기를 자동 계산 / TF GradientTape에 대응.
optimizer.zero_grad(): 파라미터에 쌓인 기울기를 0으로 비우는 것.

학습 스텝의 뼈대는 이렇습니다.

pred = model(X)              # ① 순전파
loss = loss_fn(pred, y)      # ② 손실

loss.backward()              # ③ 역전파: 기울기 계산 & 누적(+=)
optimizer.step()             # ④ 가중치 갱신
optimizer.zero_grad()        # ⑤ 기울기 0으로 — 다음 배치 대비

공식 문서는 이렇게 못박습니다. PyTorch는 기울기를 덮어쓰지 않고 더합니다 — "Gradients by default add up; ... we explicitly zero them at each iteration." 기본적으로 기울기가 누적되니, 이중 계산을 막으려면 매 반복마다 명시적으로 0으로 비워야 한다는 뜻입니다. (출처: PyTorch — Optimizing Model Parameters)

⚠️ ★ 1순위 함정 · zero_grad를 잊으면 — zero_grad()를 빼먹으면 이전 배치의 기울기가 계속 더해집니다. 그러면 갱신 방향이 엉키고 손실이 요동치거나 발산하죠. TF의 GradientTape는 with 블록마다 새로 시작해 이 문제가 없었지만, PyTorch는 누적이 기본이라 내가 챙겨야 합니다. (이 누적 특성을 역이용하면 작은 GPU에서 여러 배치를 모아 큰 배치처럼 학습하는 gradient accumulation 기법이 됩니다.)

어디에 쓰나 — 모든 PyTorch 학습 코드의 심장부입니다. 특히 GPU 메모리가 부족할 때 zero_grad를 몇 스텝에 한 번만 호출해 기울기를 일부러 누적하는 기법은 대형 모델 파인튜닝의 단골 트릭이에요.

→ 마지막은 학습과 평가를 가르는 두 스위치, train/eval과 no_grad입니다.

4. train() / eval() 과 no_grad()

학습할 때와 평가할 때는 모델이 다르게 동작해야 합니다. PyTorch는 이걸 두 개의 서로 다른 스위치로 다룹니다 — 여기가 TF와 문법이 가장 갈리는 지점입니다.

model.train() / model.eval(): Dropout·BatchNorm 등 레이어의 동작 모드를 학습용/추론용으로 전환.
torch.no_grad(): autograd의 기울기 추적을 꺼서 메모리·속도를 아끼는 컨텍스트.

def test(dataloader, model, loss_fn):
    model.eval()                     # 추론 모드(Dropout 끔 등)
    with torch.no_grad():             # 기울기 추적 끔
        for X, y in dataloader:
            pred = model(X)
            # ... 손실·정확도 집계 (가중치 갱신 없음)

둘은 다른 일을 한다 — eval()은 레이어 동작을, no_grad()는 기울기 계산을 끕니다. 목적이 달라 평가 땐 둘 다 써야 합니다. TF의 training=False 하나가 사실상 이 둘을 합쳐 놓은 셈이라, TF만 하다 오면 하나를 빠뜨리기 쉽습니다.

⚠️ 함정 — 평가에서 model.eval()을 빼면 Dropout이 켜진 채라 결과가 매번 흔들리고, no_grad()를 빼면 불필요한 기울기 그래프가 쌓여 메모리가 터질 수 있습니다. 학습 루프 시작엔 model.train(), 평가엔 model.eval()을 짝으로 붙이는 습관을 들이세요.

어디에 쓰나 — 검증/테스트 루프, 그리고 배포 후 추론 서버. 추론만 하는 서비스 코드에선 eval() + no_grad()(또는 inference_mode())가 기본 세팅입니다.

치트시트 & 핵심 4가지

단계	코드
모델 정의	`class M(nn.Module): def forward(self, x): ...`
손실(로짓)	`nn.CrossEntropyLoss()`
학습 스텝	`backward()` → `step()` → `zero_grad()`
학습/추론 전환	`model.train()` / `model.eval()`
평가 컨텍스트	`with torch.no_grad():`

딱 4가지만 기억하면 됩니다.
1. 모델은 nn.Module 서브클래싱 + forward(). 출력은 logits, 손실은 CrossEntropyLoss.
2. 학습 스텝은 backward → step → zero_grad. 기울기는 기본이 누적이다.
3. zero_grad()를 잊으면 학습이 망가진다 (TF엔 없던 함정).
4. 평가엔 eval()과 no_grad()를 둘 다 — 각각 레이어·기울기를 끈다.

참고 자료

PyTorch — Quickstart (공식 문서) : nn.Module·학습/평가 루프 전체
PyTorch — Optimizing Model Parameters (공식 문서) : "Gradients by default add up ... zero them at each iteration"
PyTorch — Automatic Differentiation with torch.autograd (공식 문서)
「TensorFlow 전문가 학습 루프」 (이전 글) : 같은 루프를 GradientTape로 — 대응 관계의 반대편

pandas 선택과 집계 제대로 — .loc·iloc, SettingWithCopyWarning, groupby

harang Lee — Tue, 1 Sep 2026 14:58:16 +0900

넘파이 인덱싱을 정리하고 나니(「NumPy 인덱싱 5종」), 자연스럽게 판다스가 궁금해졌습니다. 표(表) 데이터를 다루다 보면 df["A"], df.loc[...], df.iloc[...]가 뒤섞여 나오는데, 어떤 땐 되고 어떤 땐 SettingWithCopyWarning이라는 노란 경고가 떠서 늘 찜찜했거든요.

공식 "10 minutes to pandas"와 인덱싱 가이드를 다시 읽어보니, 판다스 선택의 핵심은 딱 세 갈래([] · .loc · .iloc)였고, 그 경고도 "왜 뜨는지"를 알면 두 번 다시 안 볼 수 있더라고요. 이 글에선 그 세 갈래와 경고의 정체, 그리고 데이터 분석의 심장인 groupby까지 공식 문서를 근거로 짚습니다.

1. 큰 그림 — 고르고, 안전하게 고치고, 묶는다

판다스로 하는 일의 상당수는 이 세 동작으로 수렴합니다. 원하는 데이터를 고르고, 값을 안전하게 고치고, 그룹으로 묶어 요약하는 것.

DataFrame 다루기 를 세 동작으로

▼

라벨로 고르기이름으로 선택.loc['a':'c']

위치로 고르기번호로 선택.iloc[0:3]

안전하게 수정한 번의 .loc.loc[mask,col]=x

그룹별 요약쪼개고·집계.groupby().agg()

2장에서 선택 3축, 3장에서 수정의 함정, 4장에서 그룹 집계를 채웁니다.

2. 선택의 3축 — [], .loc, .iloc

먼저 "고르기"부터. 판다스에는 인덱싱 진입점이 세 개 있고, 각자 역할이 다릅니다.

.loc (라벨 기반): 인덱스·컬럼 이름으로 선택 / df.loc["2013-01-02", "A"].
.iloc (위치 기반): 0부터 세는 정수 위치로 선택 / df.iloc[1, 0].

직관적으로는 []는 "컬럼 꺼내기 전용 지름길", .loc는 "이름표로 찾기", .iloc는 "몇 번째냐로 찾기"입니다.

# [] — 주로 컬럼 선택 / 행 슬라이스
df["A"]            # 단일 컬럼(Series)
df[["B", "A"]]     # 여러 컬럼

# .loc — 라벨로 (행, 열)
df.loc[:, ["A", "B"]]
df.loc["2013-01-02":"2013-01-04", ["A", "B"]]

# .iloc — 위치로 (행, 열)
df.iloc[3:5, 0:2]
df.iloc[[1, 2, 4], [0, 2]]   # 위치 리스트(팬시와 같은 결)

공식 문서는 이렇게 설명합니다. 두 슬라이싱의 끝값 처리가 다른 게 핵심인데요. .loc는 라벨 슬라이스라 "both the start and the stop are included" — 시작·끝 라벨을 둘 다 포함합니다. 반면 .iloc는 파이썬 관례대로 끝을 제외합니다. (출처: pandas — Indexing and selecting data)

s = pd.Series([10, 20, 30, 40], index=["a", "b", "c", "d"])
s.loc["a":"c"]     # a, b, c  ← 'c' 포함!
s.iloc[0:2]       # a, b     ← 2번(=c) 제외

⚠️ 오프바이원 단골 — .loc["a":"c"]는 3개, .iloc[0:3]은 3개인데 .loc[0:3](정수 라벨)은 4개가 나올 수 있습니다. 끝값 포함/제외가 진입점마다 달라서 생기는 실수예요. "라벨 슬라이스는 끝 포함"을 못박아 두세요.

어디에 쓰나 — 시계열에서 df.loc["2024-01":"2024-03"]로 분기 데이터를 이름으로 자르거나, df.iloc[:1000]로 앞 1000행만 빠르게 떼어 실험할 때. 라벨이 의미를 담으면 .loc, 순수 위치면 .iloc가 정석입니다.

→ 다음은 이 선택으로 값을 "고칠 때" 터지는 SettingWithCopyWarning입니다.

3. 체인 인덱싱과 SettingWithCopyWarning

고르는 것까진 쉬운데, 고른 자리에 값을 대입할 때 판다스가 노란 경고를 냅니다. 이게 넘파이에서 본 view/copy 문제의 판다스 버전이에요.

chained indexing (체인 인덱싱): 대괄호를 연달아 쓰는 것 / df["A"][0], df[df.A>0]["B"].

왜 위험할까요. df[df.A>0]가 복사본일 수 있는데, 거기에 다시 ["B"] = 0을 하면 그 복사본만 바뀌고 원본 df는 그대로일 수 있습니다. 판다스는 이 애매함을 감지하면 경고를 띄웁니다.

공식 문서는 이렇게 권합니다. 값 대입 때 .loc는 축(axis)을 정렬해 한 번에 처리하지만, 체인 인덱싱은 정렬이 대입보다 먼저 일어나 "will not modify df"가 될 수 있다고 설명합니다. 그래서 대입은 하나의 .loc으로 하라는 게 정석입니다. (출처: pandas — Indexing and selecting data)

# ✗ 체인 인덱싱 — 경고 + 원본 안 바뀔 수 있음
df[df["A"] > 0]["B"] = 0

# ✓ 한 번의 .loc — 행·열을 동시에 지정해 안전하게 대입
df.loc[df["A"] > 0, "B"] = 0

규칙 — "고를 땐 []도 괜찮지만, 고치는(대입) 순간엔 무조건 .loc 한 방." 이 습관 하나로 SettingWithCopyWarning은 거의 사라집니다.

판다스 3.x부터 도입되는 Copy-on-Write(쓸 때 복사)로 이 경고의 동작 방식이 정리되고 있습니다. 다만 "체인 인덱싱으로 대입하지 말라"는 원칙 자체는 버전과 무관하게 그대로 유효합니다.

어디에 쓰나 — 이상치 클리핑(df.loc[df.x > cap, "x"] = cap), 조건부 라벨링(df.loc[df.score >= 60, "pass"] = True)처럼 "조건에 맞는 행의 특정 열만 수정"은 데이터 전처리에서 매일 나옵니다.

→ 마지막으로, 고른 데이터를 그룹으로 묶어 요약하는 groupby입니다.

4. groupby — 쪼개고, 적용하고, 합친다

선택이 "행/열 고르기"였다면, groupby는 "같은 부류끼리 묶어 통계 내기"입니다. 판다스 분석의 심장이라 할 만해요.

groupby (그룹 연산): 특정 컬럼 값으로 행을 묶어 그룹마다 집계하는 것 / SQL의 GROUP BY와 같은 개념.

공식 문서는 이 과정을 split-apply-combine(쪼개기–적용–합치기)이라는 세 단계로 설명합니다. 데이터를 그룹으로 쪼개고, 각 그룹에 함수를 적용하고, 결과를 하나로 합치는 흐름이죠. (출처: pandas — Group by: split-apply-combine)

df = pd.DataFrame({
    "팀":   ["A", "B", "A", "B", "A"],
    "득점": [10, 7, 3, 8, 5],
})
df.groupby("팀")["득점"].sum()
# 팀
# A    18
# B    15

여러 집계를 한 번에 낼 땐 이름을 붙이는 named aggregation이 깔끔합니다. 결과 컬럼명이 정돈되고, 파이썬 함수를 apply로 도는 것보다 내장 집계가 훨씬 빠릅니다.

df.groupby("팀").agg(
    총득점=("득점", "sum"),
    평균=("득점", "mean"),
    경기수=("득점", "count"),
)

⚠️ 함정 · agg vs transform — agg는 그룹을 하나의 값으로 축소(합·평균)하고, transform은 원래 행 수 그대로 돌려줍니다. "각 행에 그 그룹의 평균을 붙이고 싶다"면 groupby(...).transform("mean")이어야지 agg가 아닙니다. 둘을 헷갈리면 형태가 안 맞아 에러가 나거나 조용히 잘못된 결과가 됩니다.

어디에 쓰나 — "카테고리별 평균 구매액", "사용자별 세션 수"처럼 집계 리포트 전부가 groupby입니다. 머신러닝에선 그룹 통계를 피처로 만들 때(transform으로 그룹 평균을 각 행에 붙이기) 특히 유용해요.

치트시트 & 핵심 4가지

하고 싶은 것	패턴
컬럼 꺼내기	`df["A"]`, `df[["A","B"]]`
라벨로 (행, 열)	`df.loc[row_label, col]` (끝 포함)
위치로 (행, 열)	`df.iloc[i, j]` (끝 제외)
조건 행의 열 수정	`df.loc[mask, "col"] = 값`
그룹 집계	`df.groupby("k").agg(...)`
그룹 통계를 각 행에	`df.groupby("k")["v"].transform("mean")`

딱 4가지만 기억하면 됩니다.
1. 고르기 진입점은 [] · .loc · .iloc 셋, 역할이 다르다.
2. .loc 슬라이스는 끝 포함, .iloc는 끝 제외.
3. 대입은 체인 인덱싱 말고 한 번의 .loc — SettingWithCopyWarning의 해법.
4. groupby는 split-apply-combine. 축소는 agg, 형태 유지는 transform.

참고 자료

pandas — 10 minutes to pandas (공식 문서) : 선택·groupby 기본 예제
pandas — Indexing and selecting data (공식 문서) : .loc 끝값 포함, 체인 인덱싱 경고, 대입은 .loc
pandas — Group by: split-apply-combine (공식 문서)
「NumPy 인덱싱 5종」 (이전 글) : 판다스 불리언 선택의 뿌리인 넘파이 불리언 인덱싱

NumPy 인덱싱 5종 제대로 — Basic·Advanced와 View/Copy 함정

harang Lee — Tue, 1 Sep 2026 14:57:54 +0900

넘파이 공식 Quickstart를 다시 훑다가, "Indexing"이라는 짧은 절 하나에 발이 걸렸습니다. 인덱싱이 파이썬 리스트처럼 a[2], a[1:5] 정도인 줄 알았는데, 정수·슬라이스·불리언·정수배열까지 종류가 여러 갈래더라고요. 특히 fancy indexing(팬시 인덱싱)이라는 이름이 낯설어서 "이게 대체 뭔데 이름까지 붙었나" 싶었습니다.

파보니 인덱싱의 진짜 핵심은 "종류가 몇 개냐"가 아니라, 어떤 인덱싱은 원본을 공유(view)하고 어떤 인덱싱은 복사본(copy)을 만든다는 갈림길이었습니다. 이 글은 넘파이 인덱싱 5종을 정리하면서, 그 밑에 깔린 Basic/Advanced 구분과 view/copy 함정까지 공식 문서를 근거로 짚어봅니다. (배열이 메모리에 어떻게 놓이길래 view가 가능한지, 그 왜는 지난 글 「NumPy는 왜 빠른가 — ndarray 메모리 모델」에서 다뤘으니 여기선 인덱싱 사용법에 집중합니다.)

1. 큰 그림 — 무엇으로 고르느냐

인덱싱은 결국 "배열에서 원하는 원소를 골라내는 방법"입니다. 무엇을 기준으로 고르느냐에 따라 갈래가 나뉘는데, 이걸 한 장으로 정리하면 이렇게 됩니다.

배열에서 원소 고르기 를 4가지 기준으로

▼

정수 하나로위치 콕 집기a[2], a[1,3]

범위로연속 구간 슬라이스a[1:5]

위치 배열로흩어진 위치 한 번에a[[0,3,1]]

조건으로참인 것만 거르기a[a>0]

앞 두 칸은 Basic(뷰), 뒤 두 칸은 Advanced(복사본) — 이 경계가 이 글의 핵심입니다.

2장에서 5종을 빠르게 훑고, 3장에서 그 5종이 사실 Basic과 Advanced 두 무리로 갈린다는 것(그리고 그게 왜 중요한지)을 봅니다. 그다음 4·5장에서 Advanced에 속하는 팬시 인덱싱과 불리언 인덱싱을 하나씩 깊게 팝니다.

2. 인덱싱 5종 — 한눈에

먼저 종류부터 훑겠습니다. 넘파이 인덱싱은 보통 아래 5가지로 나눠 설명합니다. 예제 배열 하나로 전부 보여드릴게요.

indexing (인덱싱): 배열에서 특정 위치의 원소(들)를 지정해 읽거나 쓰는 것 / 예: a[0]은 첫 원소.

import numpy as np
a = np.array([[10, 20, 30],
              [40, 50, 60],
              [70, 80, 90]])

# ① 정수 인덱싱 — 위치 하나
a[0]          # array([10, 20, 30])  (0번 행)

# ② 슬라이싱 — 연속 범위
a[0:2]        # 0~1번 행

# ③ 다차원 인덱싱 — 콤마로 축마다
a[1, 2]       # 60  (1번 행, 2번 열)
a[0:2, 1]     # array([20, 50])

# ④ 팬시 인덱싱 — 정수 "배열"로 임의 선택
a[[2, 0]]     # 2번, 0번 행을 이 순서로

# ⑤ 불리언 인덱싱 — 조건 필터
a[a > 50]      # array([60, 70, 80, 90])

공식 문서도 인덱싱을 크게 두 부류로 나눠 설명하는데, 재미있는 건 위 다섯이 딱 5개의 독립된 기능이 아니라는 점입니다. (참고: NumPy Indexing on ndarrays) 종류를 외우기보다, 다음 장에서 볼 Basic이냐 Advanced냐의 경계를 잡는 게 훨씬 남는 장사입니다.

어디에 쓰나 — ①②③은 데이터의 특정 행/열을 꺼내 볼 때(예: 이미지 한 채널 img[:, :, 0]), ④⑤는 조건에 맞는 샘플만 골라 학습셋을 만들 때 일상적으로 씁니다.

→ 다음은 이 5종을 가르는 진짜 경계, Basic vs Advanced입니다.

3. 진짜 경계 — Basic이냐 Advanced냐 (View냐 Copy냐)

5종을 외우는 것보다 중요한 건, 넘파이가 인덱싱을 내부적으로 Basic indexing과 Advanced indexing 두 무리로 구분한다는 사실입니다. 그리고 이 구분이 곧 "결과가 원본과 메모리를 공유하는가"를 결정합니다.

view (뷰): 원본과 같은 데이터 버퍼를 공유하며 보는 방식만 다른 배열 / 뷰를 고치면 원본도 바뀜.
copy (복사본): 데이터까지 새로 복제한 독립 배열 / 고쳐도 원본은 그대로.

공식 문서는 이렇게 설명합니다. 기본 인덱싱(정수·슬라이스)은 오프셋과 스트라이드로 주소를 매길 수 있어서 언제나 뷰를 만들고, 고급 인덱싱은 언제나 복사본을 만든다고 못박습니다 — "basic indexing always creates views", "Advanced indexing ... always creates copies". (출처: NumPy — Copies and views)

# 공식 문서 예제 — 슬라이싱은 뷰
x = np.arange(10)
y = x[1:3]        # 뷰 생성
x[1:3] = [10, 11]
y                  # array([10, 11]) — x를 바꿨는데 y도 바뀐다

# 팬시(고급) 인덱싱은 복사본
z = x[[1, 2]]
z.base is None     # True — 원본을 참조하지 않는 독립 배열

여기서 .base가 판별기 역할을 합니다. 뷰라면 원본 배열을 가리키고, 복사본이라면 None입니다. 공식 문서 표현을 빌리면 base는 뷰에선 원본을, 복사본에선 None을 돌려줍니다. (출처: NumPy — Copies and views)

무리	어떤 인덱싱	결과	`arr[...] = 값` 하면
Basic	정수 · 슬라이스 · 다차원(콤마)	View (뷰)	원본이 바뀐다
Advanced	팬시(정수배열) · 불리언	Copy (복사본)	새 배열이라 원본 안 바뀔 수 있음

한 줄 판별법 — 대괄호 [ ] 안에 리스트/배열이 들어가면(팬시·불리언) Advanced → Copy. 정수와 슬라이스(:)만 있으면 Basic → View.

⚠️ 흔한 함정 — 큰 배열을 슬라이싱해서 조각만 남기면, 그건 뷰라 원본 전체가 메모리에 계속 붙잡혀 있습니다. 정말로 조각만 떼어 쓰려면 arr[1:100].copy()로 명시적 복사하세요. 반대로, 팬시 인덱싱 결과를 고쳐도 원본이 안 바뀌어서 "왜 안 되지?" 하는 경우도 여기서 옵니다.

어디에 쓰나 — 전처리에서 원본을 보존하며 정규화할 때 df.copy()/arr.copy()를 습관적으로 쓰는 이유가 바로 이 view/copy 경계입니다. 판다스의 SettingWithCopyWarning도 같은 뿌리예요.

→ 다음은 Advanced의 첫 주자, 팬시 인덱싱입니다.

4. 팬시 인덱싱 — 흩어진 위치를 한 번에

앞에서 Advanced 무리가 복사본을 만든다고 했는데, 그 대표가 팬시 인덱싱입니다. 슬라이싱이 "연속 범위"만 잘라내는 데 비해, 팬시 인덱싱은 흩어진 위치를 임의 순서로, 중복까지 허용해서 뽑아냅니다.

fancy indexing (팬시 인덱싱): 정수(또는 불리언) 배열을 인덱스로 넘겨 여러 원소를 한 번에 선택하는 것 / 예: a[[0, 2, 0]].

직관은 "번호표 뭉치를 건네는 것"에 가깝습니다. 슬라이싱이 "3번부터 7번까지"라면, 팬시는 "3번, 0번, 3번 다시, 5번 줘"처럼 순서와 중복을 마음대로 지정합니다.

공식 문서는 이렇게 설명합니다. 인덱스 배열의 모양(shape)이 곧 결과의 모양이 된다는 점을 예제로 보여줍니다. (출처: NumPy Quickstart — Indexing with arrays of indices)

# 공식 문서 예제
a = np.arange(12)**2              # [0,1,4,9,16,25,...,121]
i = np.array([1, 1, 3, 8, 5])
a[i]                          # array([ 1,  1,  9, 64, 25]) — 중복 OK

j = np.array([[3, 4], [9, 7]])   # 2차원 인덱스
a[j]                          # j와 같은 (2,2) 모양으로 반환

여러 축을 각각의 인덱스 배열로 넘기면, 두 배열이 짝지어져 원소를 뽑습니다. 이때 두 인덱스 배열은 브로드캐스팅 규칙으로 맞춰지는데, 그 자세한 규칙은 앞서 링크한 메모리 모델 글에서 다뤘습니다.

a = np.arange(12).reshape(3, 4)
i = np.array([[0, 1], [1, 2]])   # 행 인덱스
j = np.array([[2, 1], [3, 3]])   # 열 인덱스
a[i, j]                       # a[0,2],a[1,1],a[1,3],a[2,3] → [[2,5],[7,11]]

⚠️ 면접 단골 함정 — 같은 위치를 여러 번 넣고 += 하면 어떻게 될까요?

a = np.arange(5)
a[[0, 0, 2]] += 1
a                # array([1, 1, 3, 3, 4]) — 0번은 +1이 두 번 아니라 한 번!

0번이 두 번 나오니 2가 될 것 같지만 실제로는 한 번만 오릅니다. a[idx] += 1이 "뽑고 → 더하고 → 되쓰기"를 한 번에 처리(buffered)하기 때문인데요. 정말 누적하고 싶다면 np.add.at(a, [0,0,2], 1)을 써야 합니다. (출처: NumPy Quickstart)

어디에 쓰나 — 매 epoch마다 데이터를 섞을 때 idx = np.random.permutation(len(X)); X[idx], y[idx]로 입력·라벨을 짝 맞춰 셔플하는 게 팬시 인덱싱의 교과서적 활용입니다. 라벨→색 팔레트 매핑(palette[labels])도 같은 패턴이에요.

→ 다음은 조건으로 거르는 불리언 인덱싱입니다.

5. 불리언 인덱싱 — 조건으로 거르기

팬시가 "위치"로 골랐다면, 불리언 인덱싱은 "조건"으로 고릅니다. 역시 Advanced라 결과는 복사본입니다.

boolean indexing (불리언 인덱싱 / 마스킹): 원본과 같은 모양의 True/False 배열을 넘겨, True인 자리의 원소만 뽑는 것 / 예: a[a > 0].

비유하면 배열 위에 구멍 뚫린 마스크(mask)를 겹쳐, 구멍(True) 아래 값만 통과시키는 셈입니다.

# 공식 문서 예제
a = np.arange(12).reshape(3, 4)
b = a > 4              # a와 같은 모양의 True/False 배열
a[b]                    # array([5,6,7,8,9,10,11]) — 1D로 뽑힘
a[b] = 0               # 4보다 큰 값 전부 0으로 (조건부 대입)

조건을 여러 개 엮을 때가 진짜 함정입니다. 파이썬의 and/or는 배열에 쓸 수 없고, 원소별 논리연산자 &(AND) |(OR) ~(NOT)를 써야 합니다. 게다가 우선순위 때문에 각 조건을 괄호로 감싸야 하고요.

# 올바른 방법 — 괄호 필수
a[(a > 2) & (a < 9)]

# a > 2 and a < 9   → ValueError (truth value 모호)
# a > 2 & a < 9     → a > (2 & a) < 9 로 잘못 묶임

⚠️ 주의 — &/|는 비교연산자보다 우선순위가 높습니다. 괄호를 빼면 a > (2 & a) < 9처럼 엉뚱하게 묶여 조용히 틀린 결과가 나오거나 에러가 납니다. "불리언 조건엔 무조건 괄호"로 외우세요.

어디에 쓰나 — "결측 아닌 행만", "임계값 넘는 픽셀만" 같은 필터링 전부가 불리언 인덱싱입니다. 딥러닝에선 어텐션 패딩 마스크, 손실에서 특정 클래스 제외 등에서 매일 만나게 됩니다.

치트시트 & 핵심 4가지

하고 싶은 것	패턴	무리
위치 하나	`a[i]`, `a[r, c]`	Basic → View
연속 범위	`a[start:stop]`	Basic → View
흩어진 위치·재정렬·중복	`a[[0, 3, 1]]`	Advanced → Copy
조건 필터	`a[a > 0]`	Advanced → Copy
여러 조건	`a[(a>2) & (a<9)]`	괄호 필수
인덱스 누적 대입	`np.add.at(a, idx, 1)`	`+=` 대신
독립 조각 확보	`a[1:100].copy()`	뷰 → 복사

딱 4가지만 기억하면 됩니다.
1. 인덱싱은 Basic(정수·슬라이스)과 Advanced(배열·불리언)로 갈린다.
2. Basic은 View(원본 공유), Advanced는 Copy(독립) — .base로 확인.
3. 팬시 인덱싱의 a[[0,0,2]] += 1은 한 번만 오른다. 누적은 np.add.at.
4. 불리언 여러 조건은 and가 아니라 & | ~ + 괄호.

참고 자료

NumPy — Indexing on ndarrays (공식 문서) : 인덱싱 종류와 Basic/Advanced 구분
NumPy — Copies and views (공식 문서) : "basic indexing always creates views", "advanced ... always creates copies", .base
NumPy — Quickstart (공식 문서) : 팬시/불리언 인덱싱 예제, a[[0,0,2]] += 1 동작
「NumPy는 왜 빠른가 — ndarray 메모리 모델부터 einsum까지」 (이전 글) : strides로 view가 가능한 이유, 브로드캐스팅 규칙

데이터 전처리, 왜 모델보다 먼저인가 — sklearn으로 정리하는 ML 전처리 파이프라인

harang Lee — Tue, 1 Sep 2026 14:08:09 +0900

이번 강의자료는 「기계학습」 개론이었는데요, 앞부분에서 "기계가 데이터로부터 규칙을 학습한다"는 정의와 지도·비지도·강화 학습 분류를 훑고, 뒷부분(53쪽 이후)에서 2장. 전처리의 중요성으로 넘어갑니다. 저는 이 뒷부분에 꽂혔습니다. 모델 알고리즘은 한 줄이면 바꾸는데, 정작 성능을 좌우하는 건 그 앞단의 데이터 손질이더라고요.

강의는 인코딩·결측치 처리·스케일링·차원 축소·특성 선택을 쭉 나열하고 마지막에 scikit-learn 파이프라인으로 닫습니다. 그런데 슬라이드만 보면 "이런 도구들이 있다"는 카탈로그처럼 읽혀요. 이 글에서는 그 도구들을 실제 데이터가 모델에 들어가기까지의 순서로 다시 엮고, 강의가 개념 그림으로 보여준 것들을 sklearn 공식 API·예제와 하나씩 맞춰보겠습니다. 강의자료엔 실행 코드가 없어서, "강의는 이 개념을 이렇게 그림으로 설명했다 ↔ 공식 문서/실무에선 이 코드로 한다"로 대조합니다.

이 글의 순서

큰 그림 — 전처리가 왜 모델보다 먼저인가
Encoding — 글자를 숫자로
Impute — 빈칸 메우기
Feature Scaling — 눈금 맞추기
차원 축소 — 열이 너무 많을 때
Feature Selection — 쓸모없는 열 골라내기
Pipeline — 순서를 통째로 묶고 데이터 누수 막기
치트시트 & 핵심 6가지

1. 큰 그림 — 전처리가 왜 모델보다 먼저인가

강의 55쪽에 Raw data vs Featured Data 비교표가 나옵니다. 원본 데이터를 그대로 쓰면 "정보 손실이 없다"는 장점이 있지만, 차원의 저주·높은 계산비용·큰 저장공간이라는 엄지척 반대 방향의 대가가 따라붙죠. 반대로 전처리해서 특성을 다듬으면(Featured) 약간의 정보 손실을 감수하는 대신 차원이 줄고 학습이 빨라집니다. 전처리는 결국 이 트레이드오프(trade-off, 하나 얻으면 하나 잃는 관계)를 우리 문제에 맞게 조율하는 작업입니다.

Feature (특성/피처) (한국어 의미): 모델의 입력이 되는 하나의 열(변수) — 예: 붓꽃 데이터의 꽃잎 길이, 꽃잎 너비. 강의 41쪽 Iris 데이터로 치면 sepal_length, petal_width 같은 각 칸이 특성이고, class가 정답(레이블)입니다.

강의 56쪽은 한 발 더 나갑니다. 전통적인 머신러닝은 사람이 Feature extraction(특성 추출)을 손으로 해준 뒤 분류기에 넘기지만, 딥러닝은 특성 추출까지 신경망이 알아서 합니다. 그래서 "전처리를 얼마나 사람이 하느냐"는 곧 "머신러닝이냐 딥러닝이냐"를 가르는 축이기도 해요. 이 글에서 다루는 건 앞쪽, 즉 사람이 명시적으로 하는 전처리입니다.

아래는 원본 표(raw table) 한 장이 모델에 들어갈 수 있는 행렬이 되기까지 거치는 관문들입니다. 이후 섹션이 각 칸을 하나씩 채웁니다.

원본 데이터 를 모델이 먹을 수 있게 손질하기

▼ 데이터가 흐르는 순서

글자를 숫자로?EncodingOneHotEncoder

빈칸은?ImputeSimpleImputer

눈금이 제각각?ScalingStandardScaler

열이 너무 많다차원 축소PCA

쓸모없는 열?Feature SelectionSelectKBest / RFE

매번 반복?Pipelinemake_pipeline

마지막 Pipeline이 앞의 다섯 단계를 하나로 묶고, 동시에 "데이터 누수"를 막아줍니다.

어디에 쓰나 — 실무에서 캐글이든 회사 프로젝트든, 새 데이터셋을 받으면 제일 먼저 하는 게 이 관문 점검입니다. "이 열은 범주형인가 수치형인가, 결측치는 몇 %인가, 스케일 차이가 큰가"를 훑는 것만으로 모델 선택과 전처리 계획의 절반이 정해져요.

→ 먼저 가장 앞 관문, 글자를 숫자로 바꾸는 Encoding부터 봅니다.

2. Encoding — 글자를 숫자로

모델은 "green"이나 "XL" 같은 문자열을 곧바로 계산하지 못합니다. 그래서 범주형 값을 숫자로 바꿔야 하는데, 이때 "순서가 있는 범주냐 없는 범주냐"에 따라 방법이 갈립니다. 강의 57쪽이 정확히 이 두 갈래를 보여줍니다.

One-Hot Encoding (원핫 인코딩) (한국어 의미): 순서 없는 범주(nominal)를 값의 개수만큼의 0/1 열로 펼치는 방식 — 예: 색(green/red/blue) → 열 3개, 해당 색만 1. Ordinal Encoding (순서형 인코딩) (한국어 의미): 순서 있는 범주(ordinal)를 크기를 보존하는 정수로 매핑 — 예: 사이즈 M/L/XL → 1/2/3.

직관은 이렇습니다. 색깔에 "green=1, red=2, blue=3"처럼 번호를 매기면 모델은 "blue가 green의 3배"라는 없던 순서를 학습해버립니다. 그래서 순서가 없는 건 원핫으로 펼쳐 서로 대등하게 두고, 진짜 순서가 있는 사이즈는 정수로 눌러도 됩니다.

공식 문서는 이렇게 설명합니다. scikit-learn은 원핫을 "각 범주형 특성을 n_categories개의 이진 특성으로 변환하되 그중 하나만 1"이라고 정의합니다 (출처: sklearn User Guide 6.3). 순서형은 OrdinalEncoder로 "각 범주형 특성을 0~(n_categories-1)의 정수 하나로" 바꿉니다.

# 공식 예제 — OneHotEncoder (순서 없는 범주)
from sklearn import preprocessing
enc = preprocessing.OneHotEncoder()
X = [['male', 'from US', 'uses Safari'],
     ['female', 'from Europe', 'uses Firefox']]
enc.fit(X)
enc.transform([['female', 'from US', 'uses Safari']]).toarray()
# array([[1., 0., 0., 1., 0., 1.]])  ← 3개 특성이 6개 0/1 열로 펼쳐짐

# 공식 예제 — OrdinalEncoder (순서 있는 범주)
enc = preprocessing.OrdinalEncoder()
enc.fit(X)
enc.transform([['female', 'from US', 'uses Safari']])
# array([[0., 1., 1.]])  ← 범주마다 정수 하나

강의 슬라이드에서는 이렇게 봤습니다. color(green/red/blue)를 (1,0,0) (0,1,0) (0,0,1)로, size(M/L/XL)를 1/2/3으로 나눠 그렸죠. 개념은 위 공식 API와 정확히 같습니다. 다만 슬라이드 제목이 "Label Encoding"으로 붙어 있는데, 여기에 함정이 하나 있습니다.

구분	강의 슬라이드(57쪽)	sklearn 공식	차이 · 이유
순서 없는 범주	color → (1,0,0)…	`OneHotEncoder`	동일 개념. 공식은 희소행렬(sparse)로 반환해 메모리 절약
순서 있는 범주	size M/L/XL → 1/2/3	`OrdinalEncoder`	동일 개념. 강의는 "Label Encoding"이라 불렀지만 실제로는 순서형 인코딩
정답(y) 인코딩	(명시 안 함)	`LabelEncoder`	공식은 이건 타깃 y 전용이라 못 박음

⚠️ 흔한 실수 — "Label Encoding"이라는 이름 때문에 입력 특성 X에 LabelEncoder를 쓰는 경우가 많은데요, 공식 문서는 딱 잘라 말합니다. "This transformer should be used to encode target values, i.e. y, and not the input X." (LabelEncoder 문서) 특성에 순서를 넣고 싶으면 OrdinalEncoder, 정답 라벨(예: setosa/versicolor/virginica)을 정수로 바꿀 때만 LabelEncoder입니다.

어디에 쓰나 — 성별·지역·상품카테고리처럼 순서 없는 범주는 원핫, 학점(A/B/C)·설문 만족도(하/중/상)·옷 사이즈처럼 순서 있는 범주는 순서형 인코딩. 트리 기반 모델(랜덤포레스트·XGBoost)은 순서형만으로도 잘 도는 반면, 선형·거리 기반 모델은 순서 없는 범주에 반드시 원핫이 필요합니다.

→ 인코딩으로 글자를 숫자로 바꿨으면, 이제 그 표의 빈칸을 메울 차례입니다.

3. Impute — 빈칸 메우기

현실 데이터엔 빈칸이 널려 있습니다. 강의 58쪽은 결측치(missing value) 처리를 삭제와 대체(Imputation) 둘로 나누고, 대체 방식으로 더미·평균·빈도·회귀 대체를 나열합니다.

Imputation (대체/보간) (한국어 의미): 누락된 값을 통계량이나 예측값으로 채워 넣는 것 — 예: 나이 열의 빈칸을 나머지 나이의 평균으로 채우기. 삭제는 간단하지만 행이 통째로 날아가면 소중한 데이터가 줄어드니, 결측이 적당할 땐 대체가 기본 선택입니다.

공식 문서는 이렇게 설명합니다. SimpleImputer를 "평균·중앙값·최빈값 같은 기술통계량으로, 또는 상수로 열마다 결측을 채우는 단변량 대체기"로 정의합니다 (출처: SimpleImputer 문서). strategy 인자로 mean(수치 평균)·median(중앙값)·most_frequent(최빈값, 문자열도 가능)·constant(고정값)를 고릅니다.

# 공식 예제 — 평균 대체
import numpy as np
from sklearn.impute import SimpleImputer
imp = SimpleImputer(missing_values=np.nan, strategy='mean')
imp.fit([[7, 2, 3], [4, np.nan, 6], [10, 5, 9]])
X = [[np.nan, 2, 3], [4, np.nan, 6], [10, np.nan, 9]]
print(imp.transform(X))
# [[ 7.   2.   3. ]   ← 1열 빈칸 = (7+4+10)/3 = 7
#  [ 4.   3.5  6. ]   ← 2열 빈칸 = (2+5)/2 = 3.5
#  [10.   3.5  9. ]]

강의 58쪽 용어	sklearn `strategy`	언제
평균 대체	`mean`	수치형, 이상치 적을 때
(중앙값)	`median`	수치형, 이상치 많을 때(더 안전)
빈도 대체	`most_frequent`	범주형/최빈값
더미 대체	`constant`	"없음"을 명시적 값(0, "Unknown")으로
회귀 대체	`IterativeImputer`*	다른 열로 예측해 채움(고급)

* 강의의 "회귀 대체"는 SimpleImputer가 아니라 sklearn의 IterativeImputer(다변량 대체)에 해당합니다.

⚠️ 핵심 함정 — 평균값을 전체 데이터로 계산하면 안 됩니다. 반드시 학습(train) 데이터의 평균으로만 채워야 해요. 테스트 데이터의 값이 평균 계산에 섞이면, 아직 보지 못했어야 할 정보가 새어 들어옵니다(데이터 누수). 이 문제는 7번 섹션에서 정면으로 다룹니다.

어디에 쓰나 — 설문·의료·센서 데이터처럼 결측이 흔한 도메인의 필수 단계. 실무 팁 하나: 결측 여부 자체가 신호일 때가 많아서, 채우기 전에 "이 값이 비어 있었다"는 이진 플래그 열(was_missing)을 하나 더 만들어두면 성능이 오르기도 합니다.

→ 빈칸까지 채웠으면, 이제 열마다 제각각인 눈금(스케일)을 맞춥니다.

4. Feature Scaling — 눈금 맞추기

키(150~190cm)와 연봉(3천만~1억)을 한 모델에 넣으면, 숫자가 큰 연봉이 거리 계산을 지배해버립니다. 강의 59쪽이 바로 이 Feature Scaling을 표준화 공식과 함께 제시하고, 60쪽에서 스케일러 4종을 산점도로 비교합니다.

Standardization (표준화) (한국어 의미): 각 특성을 평균 0, 분산 1로 맞추는 변환. 공식은 강의 59쪽 그대로 z = (x − μ) / σ입니다(μ는 평균, σ는 표준편차).

공식 문서는 이렇게 설명합니다. "표준화는 많은 추정기의 공통 요구사항이며, 특성들이 평균 0, 단위 분산의 표준정규분포처럼 보이지 않으면 모델이 나쁘게 동작할 수 있다"고 말합니다 (출처: sklearn User Guide 6.3).

# 공식 예제 — StandardScaler
from sklearn.preprocessing import StandardScaler
scaler = StandardScaler().fit(X_train)
scaler.mean_       # array([1., 0., 0.33])  ← 학습 데이터의 평균 μ
scaler.scale_      # array([0.81, 0.81, 1.24]) ← 표준편차 σ
X_scaled = scaler.transform(X_train)
X_scaled.mean(axis=0)  # array([0., 0., 0.]) → 평균 0
X_scaled.std(axis=0)   # array([1., 1., 1.]) → 분산 1

강의 슬라이드에서는 이렇게 봤습니다. 59쪽 공식 옆에 아주 중요한 붉은 메모가 달려 있습니다 — "use same parameters for the test/new data!" 즉 학습 데이터에서 구한 mean_·scale_를 테스트 데이터에도 그대로 써야 한다는 뜻이죠. 이게 fit은 train에만, transform은 양쪽에 적용하는 sklearn의 패턴과 정확히 일치합니다.

60쪽 산점도 4종은 스케일러의 성격 차이를 보여줍니다. 공식 문서의 정의로 정리하면:

스케일러	하는 일	공식 설명 요지	언제
`StandardScaler`	평균 0, 분산 1	표준정규분포 형태로	기본값. 대부분 여기서 시작
`MinMaxScaler`	[0, 1] 범위로	최소·최대로 눌러 담기	범위가 정해져야 할 때(이미지 픽셀 등)
`RobustScaler`	중앙값·IQR 기준	"이상치가 많으면 평균·분산은 잘 안 통한다"	이상치가 많을 때
`Normalizer`	샘플(행)을 단위 벡터로	"개별 샘플을 단위 노름으로"	행 방향 정규화(텍스트 TF-IDF 등)

Normalizer만 방향이 다릅니다. 나머지 셋은 열(특성) 단위로 스케일을 맞추지만, Normalizer는 행(샘플) 하나하나를 길이 1인 벡터로 만듭니다. 60쪽 산점도에서 Normalizer만 점들이 원호 위에 몰려 보이는 이유가 이겁니다.

어디에 쓰나 — k-NN·SVM·로지스틱 회귀·신경망처럼 거리나 경사하강법을 쓰는 모델엔 스케일링이 사실상 필수입니다(강의 59쪽도 "gradient descent 수렴이 빨라진다"고 언급). 반대로 트리 계열은 스케일에 둔감해서 생략해도 됩니다.

→ 여기까지가 "값을 다듬는" 전처리였다면, 이제부터는 "열의 개수를 줄이는" 전처리입니다.

5. 차원 축소 — 열이 너무 많을 때

강의 앞부분 49~50쪽에서 차원의 저주를 짚었던 게 여기서 회수됩니다. 차원(특성 수)이 늘수록 같은 공간을 채우는 데 필요한 데이터가 기하급수로 늘어나고, 데이터가 부족하면 과적합(overfitting)에 빠지죠. 해결책으로 강의가 든 게 차원 축소와 특성 선택인데, 먼저 차원 축소입니다.

PCA (주성분 분석) (한국어 의미): 데이터의 분산을 가장 많이 담는 새 축을 찾아 그 축으로 데이터를 투영해 차원을 줄이는 기법 — 예: 13개 열을 2개 축으로 압축해 산점도로 그리기. LDA (선형판별분석)는 클래스를 가장 잘 구분하는 축을 찾는다는 점이 다릅니다(강의 61쪽에 둘 다 등장).

공식 문서는 이렇게 설명합니다. PCA를 "특이값 분해(SVD)를 이용한 선형 차원 축소로, 데이터를 더 낮은 차원 공간으로 투영한다"고 정의합니다 (출처: PCA 문서). 각 축이 원본 분산의 몇 %를 설명하는지는 explained_variance_ratio_로 확인합니다.

# 공식 예제 — PCA
from sklearn.decomposition import PCA
pca = PCA(n_components=2)
X_transformed = pca.fit_transform(X)
print(pca.explained_variance_ratio_)
# [0.9924 0.0075] ← 첫 축이 분산의 99.24%를 설명 → 2차원으로 줄여도 정보 대부분 보존

강의 61쪽은 차원 축소를 "왜 하나"로 세 가지를 듭니다 — 시각화·해석 가능성(2·3차원으로 줄이면 눈으로 봄), 저장·속도, 예측 성능. 위 explained_variance_ratio_가 딱 첫 번째 이유를 뒷받침합니다. 99%가 한 축에 담기면 2D 그림 한 장으로 데이터 구조가 거의 다 보이니까요. 강의자료엔 실행 코드가 없어 이 예제가 곧 공식 기준이 됩니다.

⚠️ PCA도 스케일에 민감합니다. 분산이 큰 축을 찾는 방식이라, 스케일이 큰 열이 주성분을 독차지해버려요. 그래서 StandardScaler → PCA 순서가 정석입니다. (공식도 "입력을 센터링은 하지만 스케일링은 하지 않는다"고 명시 — 스케일링은 우리 몫)

어디에 쓰나 — 수백 차원 임베딩을 2D로 찍어 군집을 눈으로 확인하거나, 이미지·유전자처럼 특성이 수천 개인 데이터를 압축해 학습 속도를 올릴 때. 다만 PCA를 거치면 축이 원래 특성의 조합이라 "어느 특성이 중요한지" 해석은 어려워집니다 — 그게 필요하면 다음 섹션의 특성 선택이 답입니다.

→ PCA가 특성을 "합쳐서" 줄인다면, Feature Selection은 특성을 "골라서" 줄입니다.

6. Feature Selection — 쓸모없는 열 골라내기

강의 62쪽은 특성 선택을 Filter / Wrapper / Embedded 세 방법으로 나누고, sklearn feature_selection 모듈의 SelectKBest·RFE·VarianceThreshold를 소개합니다. 그리고 63·64쪽에서 순차 선택과 RFE의 동작을 그림으로 풀죠. PCA와 달리 원래 특성을 그대로 남기므로 해석이 유지되는 게 장점입니다.

세 방법의 직관부터 잡고 갑니다.

Filter(필터): 모델과 무관하게 통계로 먼저 거른다. 싸고 빠름.
Wrapper(래퍼): 실제 모델을 돌려보며 특성 조합을 넣었다 뺐다 한다. 정확하지만 느림.
Embedded(임베디드): 모델이 학습하면서 스스로 중요도를 매긴다(예: L1 규제, 트리 중요도).

공식 문서는 이렇게 설명합니다.

# ① Filter — VarianceThreshold: 분산 낮은(거의 안 변하는) 열 제거
#   "분산이 문턱을 못 넘는 특성을 모두 제거한다"
from sklearn.feature_selection import VarianceThreshold
sel = VarianceThreshold(threshold=(.8 * (1 - .8)))
sel.fit_transform(X)

# ① Filter — SelectKBest: 점수 높은 상위 k개만 남김
from sklearn.datasets import load_iris
from sklearn.feature_selection import SelectKBest, f_classif
X, y = load_iris(return_X_y=True)     # X.shape (150, 4)
X_new = SelectKBest(f_classif, k=2).fit_transform(X, y)
X_new.shape                          # (150, 2) ← 4개 중 2개로

강의 슬라이드 63·64쪽은 Wrapper 방법을 그림으로 보여줍니다. 63쪽 Sequential Feature Selection은 특성을 하나씩 추가하며 최적 조합을 찾고("fit model, pick best, repeat"), 64쪽 RFE는 반대로 전부 넣고 가중치 낮은 것부터 제거합니다("remove lowest weight, repeat"). 공식 정의와 나란히 두면 이렇게 맞물립니다.

강의 그림	방법 분류	sklearn	공식 정의 요지
63쪽: 하나씩 추가	Wrapper	`SequentialFeatureSelector`	0개에서 시작해 교차검증 점수를 최대화하는 특성을 탐욕적으로 추가
64쪽: 하나씩 제거	Wrapper	`RFE`	모델을 학습해 `coef_`/중요도가 낮은 특성을 재귀적으로 제거
62쪽: 통계 필터	Filter	`SelectKBest`	단변량 통계 검정 점수 상위 k개 선택
(강의 언급 없음)	Embedded	`SelectFromModel`	L1 규제·트리 중요도로 학습 중 자동 선택

공식 문서의 한 가지 포인트: SequentialFeatureSelector는 RFE·SelectFromModel과 달리 모델이 coef_나 feature_importances_를 내놓지 않아도 됩니다. k-NN처럼 중요도를 못 뽑는 모델에도 쓸 수 있다는 뜻이에요.

어디에 쓰나 — 특성이 수백 개인데 "어떤 게 예측에 중요한지" 보고서에 써야 할 때. RFE로 상위 특성을 추리면 모델은 가벼워지고, 남은 특성 목록 자체가 도메인 인사이트가 됩니다. 빠르게 훑을 땐 VarianceThreshold로 상수 열부터 날리는 게 첫 수입니다.

→ 지금까지 관문을 다섯 개 지났습니다. 문제는, 이걸 매번 순서대로 train·test에 따로 적용하다 보면 실수가 생긴다는 거예요. 마지막 관문이 이걸 해결합니다.

7. Pipeline — 순서를 통째로 묶고 데이터 누수 막기

강의의 마지막 슬라이드(66쪽) Scikit-learn Pipelines는 지금까지의 이야기를 한 장으로 요약합니다. Scaling → Dimensionality Reduction → Learning Algorithm이 하나의 상자(Pipeline) 안에 들어 있고, 학습 데이터엔 fit & transform, 테스트 데이터엔 transform만 적용되는 흐름이 화살표로 그려져 있죠. 이 그림이 왜 중요한지가 이 글의 진짜 결론입니다.

Data Leakage (데이터 누수) (한국어 의미): 예측 시점엔 알 수 없어야 할 정보가 모델 학습에 새어 들어가, 성능이 실제보다 부풀려지는 현상 — 예: 테스트 데이터까지 포함해 평균을 구한 뒤 스케일링하기.

공식 문서는 이렇게 설명합니다. "데이터 누수는 예측 시점에 사용할 수 없는 정보가 모델 구축에 쓰일 때 발생하며, 지나치게 낙관적인 성능 추정으로 이어져 실제 신규 데이터에서 성능이 나빠진다"고 정의합니다 (출처: sklearn Common Pitfalls). 그리고 못 박습니다 — "전처리 변환은 오직 학습 데이터로부터만 학습되어야 한다."

왜 이게 4번 섹션의 붉은 메모("use same parameters for test data!")와 같은 말인지 코드로 보면 명확합니다.

# ❌ 잘못된 방법 — 전체 데이터로 먼저 변환한 뒤 나눔 (누수 발생)
X_selected = SelectKBest(k=25).fit_transform(X, y)   # X 전체를 봄!
X_train, X_test, y_train, y_test = train_test_split(X_selected, y, random_state=42)
# → 정확도 0.76 (부풀려진 값)

# ✅ 올바른 방법 — 먼저 나누고, 학습 데이터로만 fit
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42)
select = SelectKBest(k=25)
X_train_sel = select.fit_transform(X_train, y_train)  # train에만 fit
X_test_sel  = select.transform(X_test)             # test는 transform만
# → 정확도 0.50 (무작위 데이터의 정직한 실력)

0.76과 0.50. 같은 데이터·같은 모델인데 단지 전처리를 언제 fit 했느냐로 결과가 이만큼 갈립니다. 강의 59쪽이 스케일링에서 "테스트엔 같은 파라미터를 써라"라고 한 것과, 같은 쪽 Sampling 항목의 "검증셋은 맨 마지막까지 쓰지 마라(overfitting)"가 전부 이 하나의 원칙을 가리키고 있었던 거죠.

그래서 Pipeline입니다. 공식 문서는 파이프라인의 세 번째 이점을 "안전성"으로 꼽으며, "같은 샘플로만 변환기와 예측기를 학습시켜, 테스트 데이터의 통계가 새어 드는 걸 막는다"고 설명합니다 (출처: sklearn Pipelines).

# 강의 66쪽 그림을 코드로 — 전처리+모델을 하나로 묶기
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.decomposition import PCA
from sklearn.linear_model import LogisticRegression

pipe = make_pipeline(StandardScaler(), PCA(n_components=2), LogisticRegression())
pipe.fit(X_train, y_train)   # 스케일·PCA·모델을 train에만 fit — 한 줄로
pipe.score(X_test, y_test)  # test엔 자동으로 transform만 적용 (누수 없음)

make_pipeline 한 줄이 스케일링·차원축소·학습을 순서대로 엮고, fit은 train에만·transform은 test에 자동으로 나눠 적용합니다. 실수할 여지 자체를 없애는 거죠. 강의 66쪽 그림에서 왼쪽(train)은 fit & transform, 오른쪽(test)은 transform이었던 이유가 바로 이겁니다. 참고로 범주형·수치형 열에 서로 다른 전처리를 적용하려면 ColumnTransformer를 파이프라인 안에 넣습니다.

어디에 쓰나 — 교차검증(cross-validation)이나 하이퍼파라미터 탐색(GridSearchCV)을 할 때는 파이프라인이 사실상 필수입니다. fold를 나눌 때마다 전처리가 그 fold의 train에만 다시 fit 되어야 누수가 없는데, 파이프라인이 이걸 자동으로 처리해주거든요. 손으로 하면 거의 틀립니다.

치트시트 & 핵심 6가지

상황	도구
순서 없는 범주 → 숫자	`OneHotEncoder`
순서 있는 범주 → 숫자	`OrdinalEncoder` (정답 y는 `LabelEncoder`)
결측치 채우기	`SimpleImputer(strategy='mean'\|'median'\|'most_frequent')`
스케일 맞추기(기본)	`StandardScaler` (이상치 많으면 `RobustScaler`)
차원 압축(합치기)	`PCA(n_components=k)` — 스케일링 먼저
특성 고르기(남기기)	`SelectKBest`(빠름) / `RFE`(정확)
전부 묶고 누수 방지	`make_pipeline(...)`

딱 6가지만 기억하면 됩니다.
1. 글자는 숫자로 — 순서 없으면 One-Hot, 있으면 Ordinal.
2. 빈칸은 채우거나 지우거나 — 기본은 평균/중앙값/최빈값 대체.
3. 눈금은 맞춘다 — 거리·경사하강 모델엔 표준화가 사실상 필수.
4. 차원은 줄인다 — 합치면 PCA, 고르면 Feature Selection.
5. fit은 train에만, transform은 양쪽에 — 이 한 줄이 데이터 누수를 막는다.
6. 순서는 Pipeline으로 — 실수할 여지를 코드에서 없앤다.

강의가 도구들의 카탈로그로 끝났다면, 다시 엮어본 결론은 하나였습니다. 전처리의 진짜 요점은 어떤 스케일러·인코더를 쓰느냐가 아니라, "테스트 데이터의 정보를 학습에 흘리지 않는 것"이고, scikit-learn Pipeline은 그 원칙을 강제하기 위해 존재한다는 것. 강의 59쪽의 붉은 메모 한 줄이 66쪽의 파이프라인 그림으로 이어지는 이 흐름이, 이 자료 뒷부분 전체를 관통하는 이야기였습니다.

참고 자료

scikit-learn User Guide — 6.3 Preprocessing data (표준화·인코딩·스케일러)
LabelEncoder 문서 ("타깃 y 전용" 명시)
SimpleImputer 문서 (결측치 대체 전략)
PCA 문서 (선형 차원 축소, explained_variance_ratio_)
scikit-learn User Guide — 1.13 Feature selection (VarianceThreshold·SelectKBest·RFE·SFS)
scikit-learn User Guide — 6.1 Pipelines and composite estimators
scikit-learn — Common Pitfalls (Data leakage)

Bad Data 제대로 다루기 — 데이터 클리닝·랭글링부터 ML 데이터 누수까지

harang Lee — Mon, 31 Aug 2026 16:58:12 +0900

이번 강의자료는 제목부터 bad_data였습니다. 67장 내내 "데이터는 원래 지저분하다"는 한 문장을 여러 각도에서 못 박는 덱이었는데요. 슬라이드를 넘기다 보면 217과 2.17이 뒤섞인 CSV, 전화번호 형식이 제각각인 표, "Isreal"처럼 오타 난 국가명, 심지어 성이 "Null"이라서 시스템에서 사라져 버린 사람 이야기까지 나옵니다. 그러다 후반부에서 갑자기 결이 바뀌어서 데이터 누수(data leakage)·데이터셋 시프트(dataset shift) 같은 머신러닝 전용 함정으로 넘어가더라고요.

즉 이 자료의 진짜 메시지는 "지저분한 데이터를 어떻게 청소하느냐"가 아니라, "에러를 원인부터 이해하고 → 탐지하고 → 예방하고 → 고치는" 하나의 사이클이고, 그 사이클이 ML 파이프라인에서는 특유의 함정을 하나 더 품는다는 겁니다. 이 글에서는 넓게 흩어진 67장을 그 사이클 순서로 다시 꿰어 정리하려 합니다. 실습 코드 파일은 따로 없었기 때문에, 개념마다 공식 문서가 그걸 어떻게 설명하는지를 근거로 붙였습니다.

이 글의 순서

큰 그림 — 에러의 생애주기
실무 데이터는 지저분하다 (GIGO)
전처리 vs 랭글링 vs 클리닝 — 헷갈리는 3형제
에러의 원인과 탐지 — 스키마로 걸러내기
에러 예방 — 애초에 안 새게 만들기
에러 수정 — 결측·이상치·중복 다루기
⭐ ML 특화 함정 — 데이터 누수와 데이터셋 시프트
치트시트 & 핵심 7가지

1. 큰 그림 — 에러의 생애주기

세부로 들어가기 전에 조각들이 어떻게 맞물리는지부터 잡고 가겠습니다. 강의자료는 순서가 뒤죽박죽처럼 보이지만, 사실 에러 하나가 태어나서 죽을 때까지의 생애주기를 따라갑니다. 이 지도를 머릿속에 두면 나머지가 "따로 노는 목록"이 아니라 "각 칸을 채우는 이야기"로 읽힙니다.

Bad Data 는 이 흐름으로 다룬다

▼

왜 생기나?사람·기계의 실수오타 · 센서 · 직렬화

어떻게 찾나?도메인 지식 + 스키마JSON Schema · Pydantic

어떻게 막나?포맷·서명·파이프라인Parquet · 해시 · ETL

어떻게 고치나?결측·이상치·중복 처리impute · cap · dedup

그리고 ML에선 함정이 하나 더 — 데이터 누수 · 데이터셋 시프트 (7장)

2~3장은 이 문제가 왜 중요한지(GIGO)와 용어 정리, 4~6장은 지도의 "찾기·막기·고치기" 세 칸, 마지막 7장은 AI 엔지니어라면 반드시 짚어야 하는 ML 전용 함정입니다.

→ 먼저 "왜 데이터는 늘 지저분한가"부터 봅니다.

2. 실무 데이터는 지저분하다 (GIGO)

강의자료가 가장 먼저 던진 문장은 "Real world data is messy"였습니다. 교과서 예제 데이터는 깨끗하지만, 실무에서 마주치는 데이터는 예외 없이 어딘가 망가져 있다는 거죠.

Dirty data (더티 데이터): 값이 틀렸거나 빠졌거나 형식이 어긋난, 그대로 쓰면 분석·학습을 망치는 데이터. 강의에서 정리한 유형을 표로 다시 묶으면 이렇습니다.

유형	무슨 뜻	강의 속 예시
bad / invalid	값 자체가 틀림 (오타)	나이 "25"를 "225"로 입력
missing	값이 비어 있음	결혼 여부·월급 무응답
obsolete	낡아서 현재와 안 맞음	갱신 안 된 주소·전화번호
non-standard	표기 규칙이 제각각	"홍길동"을 "홍동", "홍*"으로
incomplete	일부만 채워짐	"성남시 수정구 복정동"을 "성남시"로만
redundant / duplicated	같은 레코드 중복	동일 거래가 두 번 기록
inconsistent	서로 모순되는 값	생일은 1990인데 나이는 50
noisy / outlier	튀는 값	가격 2.17을 217로 (소수점 유실)

왜 이걸 이렇게까지 강조할까요. 슬라이드 중간에 빨간 글씨로 GIGO가 등장합니다. GIGO (Garbage In, Garbage Out): 쓰레기를 넣으면 쓰레기가 나온다 — 입력 데이터가 엉망이면 아무리 좋은 모델·알고리즘도 엉망인 결과만 낸다는 컴퓨팅의 오래된 격언입니다. 모델을 아무리 튜닝해도, 학습에 들어간 데이터가 틀렸으면 결과는 틀립니다.

그래서 강의는 데이터 정제 분야의 유명한 문장을 인용합니다 — 탐색적 데이터 마이닝과 클리닝이 "전체 노력의 80%"를 차지한다는(T. Dasu & T. Johnson). 좋은 데이터 과학자는 시간 대부분을 데이터를 청소하고 형식 맞추는 데 쓰고, 나머지는 "쓸 데이터가 없다"고 불평하는 데 쓴다는 슬라이드의 뼈 있는 농담도 같은 얘기고요.

어디에 쓰나 — 캐글 노트북과 실무의 결정적 차이가 여기입니다. 실무 프로젝트는 모델링 코드보다 "이 컬럼은 왜 이렇게 더럽지?"를 파헤치는 데이터 이해(EDA) 시간이 훨씬 깁니다. 포트폴리오에 "데이터 X% 정제 → 성능 Y% 개선"을 적을 수 있으면 모델 자랑보다 강력합니다.

→ 그런데 "청소"라고 뭉뚱그렸지만, 사실 비슷해 보이는 용어가 세 개나 섞여 있습니다.

3. 전처리 vs 랭글링 vs 클리닝 — 헷갈리는 3형제

강의자료가 유독 여러 장을 할애한 지점이 이 용어 정리였습니다. 실무에서 자주 섞어 쓰지만 뉘앙스가 다릅니다.

Data Cleaning (데이터 클리닝): 손상되거나 부정확한 레코드를 탐지하고 제거·수정하는 과정 — 위 3형제 중 가장 좁고 구체적인 작업입니다. (data cleansing, data scrubbing과 거의 같은 말)

Data Wrangling (데이터 랭글링, = munging): 원시 데이터를 분석하기 좋은 형태로 변환·매핑하는 기술. 클리닝을 포함하는 더 넓은 "데이터를 요리하는" 전 과정입니다.

Data Preprocessing (데이터 전처리): 데이터 소스에서 막 꺼낸 직후 하는 준비 작업.

이 셋의 핵심 구분선은 강의의 "Data preprocessing vs wrangling" 슬라이드에 있었습니다. 제 언어로 다시 쓰면:

항목	전처리(Preprocessing)	랭글링(Wrangling)
시점	분석 시작 전, 소스에서 꺼낸 직후	분석·모델링 도중
실행 횟수	보통 한 번 (once)	반복적 (iteratively)
주체	개발자·데이터 과학자	데이터 과학자·비즈니스 분석가
목적	초기 변환·집계·클리닝	인사이트 찾을 때까지 데이터 모양 바꾸기

비유하자면 전처리는 장 보고 재료를 다듬는 단계(한 번 하면 끝), 랭글링은 요리하면서 간을 보고 계속 고치는 단계(맛있어질 때까지 반복)입니다. 그리고 강의는 전체를 이렇게 요약했죠 — Data Preparation = Data Cleansing + Feature Engineering. 즉 데이터 준비란 "청소"와 "특징 만들기"를 합친 것이고, 그 안에 샘플링·데이터 분할·정규화·비닝·결측 대치(imputation) 같은 세부 작업이 다 들어갑니다.

Imputation (대치): 통계적 알고리즘으로 빠진 값을 채워 넣는 것 — 뒤 6장에서 다시 나옵니다.

헷갈릴 때 — "좁다→넓다" 순서로 기억하세요. Cleaning(오류 수정) ⊂ Wrangling(요리 전 과정) 이고, Preprocessing은 "언제/몇 번 하느냐"로 랭글링과 갈립니다. 전처리=한 번, 랭글링=반복.

→ 용어를 정리했으니, 이제 지도의 첫 칸 "에러를 어떻게 찾나"로 갑니다.

4. 에러의 원인과 탐지 — 스키마로 걸러내기

고치려면 먼저 찾아야 하고, 잘 찾으려면 어디서 생기는지를 알아야 합니다. 강의는 에러의 원인을 딱 둘로 나눴습니다.

사람(Human): 오타, 형식 착오("Isreal"), 잘못 고른 드롭다운, 규칙 없는 입력. 이메일·성별처럼 "정답 형식"을 딱 정하기 어려운 필드에서 특히 많습니다. (성이 "Null"이라 DB에서 실종된 Mr. Null 사례가 압권이었죠.)
기계(Machine): 계산 코드의 버그(예: BMI 산출식 오류 → 그래서 원본 raw 데이터를 꼭 저장하라), 고장 난 센서, 부정확한 시계, 그리고 직렬화(serialization) 에러 — 데이터를 빅엔디안으로 보냈는데 받는 쪽이 리틀엔디안으로 읽는 식의 바이트 순서 불일치.

탐지 전략도 둘로 제시됐습니다. 하나는 도메인 지식(domain knowledge) — 예를 들어 위도는 −90~90, 경도는 −180~180을 벗어날 수 없다는 걸 알면 범위 밖 값을 바로 오류로 잡습니다. 다른 하나는 스키마(scheme) + 검증(validation)입니다. 이쪽이 엔지니어가 자동화하기 좋은 방향이라 강의도 여기에 지면을 많이 썼습니다.

Schema (스키마): 데이터가 "어떤 필드를, 어떤 타입으로, 어떤 제약 아래" 가져야 하는지를 미리 선언한 청사진. 실제 데이터가 아니라 데이터의 설계도입니다.

공식 문서는 이렇게 설명합니다. JSON Schema는 스스로를 "JSON 문서에 주석을 달고 검증하게 해주는 선언적 언어"라고 정의합니다. 기존 데이터 포맷을 기술하고, 사람·기계가 모두 읽을 수 있는 문서를 제공하며, 자동화된 테스트와 제출 데이터의 품질 보증에 쓰인다고 하고요. (출처: json-schema.org)

파이썬 진영에서 이 "스키마로 검증" 아이디어를 가장 널리 구현한 게 Pydantic입니다. 공식 문서 표현으로는 "파이썬 타입 애너테이션을 이용한 데이터 검증" 라이브러리로, 타입 힌트를 런타임에 강제하고 데이터가 유효하지 않으면 친절한 에러를 낸다고 소개합니다. 검증 코어가 Rust로 작성돼 파이썬에서 가장 빠른 축에 든다는 점도 강조하고요. (출처: docs.pydantic.dev)

# Pydantic 스타일: 타입 힌트가 곧 검증 규칙이 된다
from pydantic import BaseModel, EmailStr, field_validator

class Donation(BaseModel):
    name: str
    country: str
    card_number: str
    amount: int                       # "2O"(알파벳 O) 넣으면 여기서 에러

    # amount는 양수여야 한다 — 도메인 지식을 코드로
    @field_validator("amount")
    def positive(cls, v):
        if v <= 0:
            raise ValueError("amount must be positive")
        return v

# 잘못된 데이터가 들어오면 조용히 통과하지 않고 즉시 막힌다
Donation(name="Miki", country="Israel",
         card_number="1234", amount="2O")  # ValidationError!

강의는 여기에 더해 데이터프레임 전용 검증 도구 pandera("dataframe을 위한 통계적 데이터 테스팅 툴킷", 공식 문서상 pandas·dask·pyspark 스키마를 정의해 런타임 검증), 설정·데이터 검증 언어 CUE, 직렬화+검증 라이브러리 marshmallow, 그리고 구조화 데이터 스키마로 Protocol Buffers·관계형 DB schema까지 소개했습니다. 공통 아이디어는 하나예요 — "데이터가 파이프라인에 들어오는 입구에서 규칙 위반을 막아라."

어디에 쓰나 — FastAPI로 추론 서버를 만들면 요청 바디를 Pydantic 모델로 받는 순간 입력 검증이 공짜로 됩니다. LLM이 뱉은 JSON을 파싱할 때도 Pydantic 모델로 검증하면 "형식 안 맞는 응답"을 애플리케이션 로직 전에 걸러낼 수 있고요(구조화 출력의 핵심). 학습 데이터 적재 단계엔 pandera로 컬럼 타입·범위를 못 박아 둡니다.

→ 찾는 것도 좋지만, 애초에 에러가 안 생기게 막는 게 더 낫겠죠.

5. 에러 예방 — 애초에 안 새게 만들기

강의의 "Preventing Errors" 슬라이드는 예방 수단을 한 줄로 나열했습니다 — 직렬화 포맷 · 디지털 서명 · ETL/ELT·파이프라인 · 자동화 · 트랜잭션 · tidy data · 품질 지표. 하나씩 짚습니다.

① 직렬화 포맷. Serialization (직렬화): 메모리 속 자료구조·객체를, 저장하거나 전송할 수 있는 형태(파일·바이트 스트림)로 바꾸고 나중에 복원하는 과정. 포맷 선택이 곧 에러 예방입니다. 강의의 비교를 정리하면:

포맷	특징	스키마
CSV	텍스트뿐, 타입 정보 없음 → `217`/`2.17` 혼동 취약	없음
JSON	사람이 읽기 좋음, 숫자 타입 단순	데이터에 내장 안 됨(외부 스키마 필요)
Parquet	컬럼 지향, 압축·분석 쿼리에 강함	파일에 타입·스키마 내장

공식 문서는 Parquet를 이렇게 설명합니다. "효율적 데이터 저장·조회를 위해 설계된 오픈소스 컬럼 지향 데이터 파일 포맷"으로, 강력한 압축·인코딩과 향상된 성능으로 대량의 복잡한 데이터를 다룬다고 합니다. (출처: parquet.apache.org) 강의도 짚었듯 판다스에서 Parquet를 쓰려면 Apache Arrow(PyArrow)가 필요합니다 — Arrow는 언어 독립적인 인메모리 컬럼 포맷이라 직렬화 오버헤드 없이 데이터를 주고받게 해줍니다.

# CSV는 타입을 잃지만, Parquet는 스키마를 데이터와 함께 저장한다
import pandas as pd
df.to_parquet("sales.parquet")      # dtype(int/float/datetime) 보존
df2 = pd.read_parquet("sales.parquet")  # 다시 읽어도 price는 float 그대로

② 디지털 서명 / 체크섬. 강의는 MD5·SHA1·SHA256·CRC32를 나열했습니다. 전송 중 데이터가 깨졌는지 해시값 대조로 확인하는 거죠. 여기서 실무 주의점 하나 — MD5·SHA1은 무결성 확인용 체크섬으론 여전히 쓰이지만, 보안(비밀번호 해싱·서명)에는 이미 깨진 알고리즘이라 절대 쓰면 안 됩니다. 비밀번호는 bcrypt·argon2가 정답입니다.

③ ETL / ELT 와 데이터 파이프라인. ETL (Extract-Transform-Load): 여러 소스에서 추출→변환→적재. 변환을 먼저 하고 데이터 웨어하우스에 넣습니다. ELT는 순서를 바꿔 원본을 먼저 데이터 레이크에 적재하고 나중에 변환합니다. 강의의 비교표에서 핵심만 뽑으면:

기준	ETL	ELT
소스 데이터	주로 정형	정형+반정형+비정형
데이터 규모	비교적 소량	대량에 적합
지연(Latency)	높음(먼저 다 변환)	낮음(최소 처리 후 적재)
유연성	낮음(초반에 변환 정의)	높음(새 소스 붙이기 쉬움)
저장 요구	변환분만 저장, 적음	원본까지 저장, 큼

강의는 랭글링과 ETL의 차이도 구분했는데요 — 랭글링은 비즈니스 분석가가 새로 생긴 다양한 데이터를 분석용으로 다루는 쪽이고, ETL은 IT 전문가가 정형 데이터를 중앙 웨어하우스로 옮기는 쪽입니다. 파이프라인 도구로는 Apache Airflow(워크플로를 코드로 작성·스케줄·모니터링)를 소개했고요.

④ 자동화. 반복되는 정제·빌드 작업을 손으로 하면 사람이 실수합니다. 강의는 파이썬 태스크 실행 도구 Invoke를 예로 들었습니다. @task로 셸 작업을 함수처럼 정의해 재현 가능하게 만드는 거죠 — make/rake의 파이썬판입니다.

⑤ Tidy Data. 예방의 마지막 축은 데이터의 "모양"을 표준화하는 겁니다. 강의는 Tidy Data = Narrow Data = long form이라고만 적어 뒀는데, 이건 통계학자 Hadley Wickham의 유명한 논문에서 온 개념입니다.

원 논문은 이렇게 정의합니다. tidy data란 "각 변수는 하나의 열, 각 관측치는 하나의 행, 각 관측 단위 종류는 하나의 표"인 구조를 말합니다. 이렇게 정리해 두면 조작·모델링·시각화가 쉬워지고, 적은 도구로 다양한 지저분한 데이터를 다룰 수 있다는 것이 핵심 주장입니다. (출처: Wickham, H. "Tidy Data", J. Statistical Software, 2014)

강의 후반의 Row/Column Compression 슬라이드가 이 "모양 바꾸기"의 실전 예입니다. 여러 동물 행을 "Carnivore" 하나로 묶거나(행 압축), 8개의 상품 컬럼을 Health Food·Apparel·Digital 3개 카테고리로 합치는(열 압축) 식으로, 목적에 맞게 wide↔long을 오가는 거죠.

⑥ 품질 지표. "관리하려면 측정하라." 강의는 시계열 모니터링 스택 Prometheus·InfluxDB를 소개하며, 데이터 에러 건수·정확도·완전성·일관성 같은 지표를 지속 추적하라고 했습니다. 이건 다음 장의 "Process" 질문과 연결됩니다 — 불량 레코드가 10%를 넘으면 어떻게 할 것인가? 언제 전체를 멈추고 경보를 울릴 것인가?

어디에 쓰나 — 학습 데이터는 CSV보다 Parquet로 관리하면 재현성·용량·속도가 다 좋아집니다. 데이터 적재 파이프라인은 Airflow로 스케줄링하고, 매 실행마다 "결측률·이상치 비율" 같은 데이터 품질 지표를 Prometheus에 남겨 임계치 초과 시 알람을 겁니다. MLOps 면접에서 "데이터 드리프트를 어떻게 모니터링하나?"의 답이 여기서 시작됩니다.

→ 예방을 뚫고 들어온 에러는 결국 손으로 고쳐야 합니다.

6. 에러 수정 — 결측·이상치·중복 다루기

강의의 "Fixing Errors"는 작업 목록을 나열했습니다 — 필드 이름 바꾸기, 타입 고치기, 데이터 조인·분리, 불량 삭제, 결측 채우기, 모양 바꾸기(reshaping). 그리고 이걸 문제 유형별 대응 전략으로 다시 묶어 줬는데, 이게 실무에서 제일 자주 쓰는 의사결정 트리입니다.

문제	대응 전략
결측(Missing)	무시(ignore) / 행 삭제(listwise deletion) / 수동 채움 / 계산값으로 채움(imputation)
이상치·노이즈(Noisy)	비닝(binning) / 군집화(clustering) / ML 알고리즘 / 수동 제거 / 상·하한 자르기(cap/floor)
불일치(Inconsistent)	외부 레퍼런스 참조 / 지식 엔지니어링 도구
중복(Duplicated)	충돌 처리 전략 — 무시 / 회피(avoidance) / 해결(resolution)

두 개념만 용어를 풀고 가겠습니다. Listwise Deletion (목록 삭제): 값이 하나라도 빠진 행 전체를 버리는 방법 — 간단하지만 데이터가 줄고 편향(bias)이 생길 수 있음. Imputation (대치): 삭제 대신 평균·중앙값·모델 예측 등 계산값으로 빈 칸을 메우는 방법.

이상치(outlier) 탐지는 강의가 세 갈래로 나눴습니다 — 통계 기반(가설검정, 분포 적합), 거리 기반(전역/지역), 모델 기반. 어느 쪽이든 "정상 범위를 정의하고 그 밖을 튀는 값으로 본다"는 뼈대는 같습니다.

⚠️ 결측 처리의 함정 — 결측을 무심코 평균으로 채우면 분산이 줄고 상관관계가 왜곡됩니다. 또 "결측이라는 사실 자체"가 신호일 때가 많습니다(예: 소득 무응답 ↔ 고소득). 그래서 강의의 Data Preparation 트리도 결측을 "자기만의 그룹으로 처리(handling as its own group)"하는 비닝을 따로 언급합니다. 무조건 채우지 말고 "왜 비었나"를 먼저 보세요.

→ 여기까지가 일반적인 데이터 이야기입니다. 이제 ML만의 함정으로 넘어갑니다.

7. ⭐ ML 특화 함정 — 데이터 누수와 데이터셋 시프트

강의 마지막 "One More Things"부터 결이 확 바뀝니다. 앞까지가 "데이터를 깨끗하게"였다면, 여기부터는 "깨끗한 데이터로도 조용히 망하는 법"입니다. AI 엔지니어라면 이 두 개가 이 자료의 진짜 하이라이트예요.

데이터 누수 (Data Leakage)

Data Leakage (데이터 누수): 예측 시점에는 알 수 없는 정보가 모델 학습에 새어 들어가는 것. 검증 점수는 비현실적으로 높은데 실제 운영에서는 성능이 폭락하는 원인입니다.

직관적으로는 "시험 문제를 미리 보고 공부한 학생"입니다. 모의고사 점수는 만점인데 실전에서 무너지죠. 강의는 누수의 원인을 전처리를 전체 데이터에 적용, 테스트·검증 데이터 공유, 중복, 시간 데이터의 암묵적 누수(미래 정보가 과거로 새는 것)로 정리했습니다.

공식 문서는 이렇게 설명합니다. scikit-learn은 데이터 누수를 "예측 시점에 사용할 수 없는 정보가 모델 구축에 쓰이는 것"이라 정의하고, 가장 흔한 원인으로 전처리기를 훈련·테스트 분리 전에 전체 데이터에 학습시키는 것을 듭니다. 규칙은 단순합니다 — "테스트 데이터에는 절대 fit을 호출하지 마라." (출처: scikit-learn — Common pitfalls)

공식 문서의 예제가 이걸 극적으로 보여줍니다. 같은 데이터·같은 모델인데 특징 선택을 언제 하느냐만 다릅니다.

# ❌ 잘못 — 전체 데이터로 특징 선택 후 분리 (테스트가 선택에 관여)
X_selected = SelectKBest(k=25).fit_transform(X, y)
X_train, X_test, y_train, y_test = train_test_split(X_selected, y, random_state=42)
gbc = HistGradientBoostingClassifier(random_state=1).fit(X_train, y_train)
accuracy_score(y_test, gbc.predict(X_test))
# → 0.76  (누수로 부풀려진 가짜 점수)

# ✅ 올바름 — 먼저 분리하고, 훈련 데이터로만 fit
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42)
select = SelectKBest(k=25).fit(X_train, y_train)   # fit은 훈련에만
X_train_s, X_test_s = select.transform(X_train), select.transform(X_test)
gbc = HistGradientBoostingClassifier(random_state=1).fit(X_train_s, y_train)
accuracy_score(y_test, gbc.predict(X_test_s))
# → 0.50  (진짜 성능. 이 데이터엔 신호가 없었던 것)

0.76과 0.50입니다. 누수 하나로 "쓸 만한 모델"이 "동전 던지기"로 바뀝니다. scikit-learn이 권하는 근본 해법은 Pipeline이에요 — 전처리와 모델을 하나로 묶으면 교차검증·하이퍼파라미터 탐색에서 각 폴드마다 전처리가 훈련분에만 적용되도록 자동 보장됩니다.

# 권장 — Pipeline이 누수를 구조적으로 막는다
from sklearn.pipeline import make_pipeline
pipe = make_pipeline(SelectKBest(k=25), HistGradientBoostingClassifier(random_state=1))
pipe.fit(X_train, y_train)                # fit이 훈련분에만 닿는다
accuracy_score(y_test, pipe.predict(X_test))  # → 0.50

⚠️ 가장 흔한 실수 — StandardScaler·정규화를 분리 전에 전체 데이터에 걸면 테스트셋의 평균·분산이 훈련에 새어 들어갑니다. 강의도 "정규화는 훈련/테스트 분리 후에 하라"고 못 박았죠. EDA조차 훈련셋에만 하는 게 원칙입니다 — 테스트셋을 눈으로 보는 순간 그것도 누수입니다.

데이터셋 시프트 (Dataset Shift)

누수가 "학습 중 미래를 훔쳐보는" 문제라면, 시프트는 "배포 후 세상이 바뀌는" 문제입니다. Dataset Shift (데이터셋 시프트): 학습 때와 운영 때 데이터의 결합 확률분포 P(X, Y)가 달라지는 현상. 학습 분포와 실제 분포가 어긋나면 모델은 서서히(혹은 갑자기) 틀리기 시작합니다.

강의는 세 종류로 나눴는데, 이건 Moreno-Torres 등의 정리를 따른 표준 분류입니다. (출처: Moreno-Torres et al., "A unifying view on dataset shift in classification", Pattern Recognition, 2012)

종류	무엇이 변하나	예시
공변량 시프트 (Covariate shift)	입력 분포 `P(X)`는 변하지만 `P(Y\|X)`는 그대로	학습은 낮 사진, 운영은 밤 사진
사전확률 시프트 (Prior probability shift)	레이블 분포 `P(Y)`가 변함 (label shift)	사기 거래 비율이 학습 때보다 급증
개념 시프트 (Concept shift / drift)	입력↔출력 관계 `P(Y\|X)` 자체가 변함	스팸의 정의·패턴이 시간이 지나며 변함

여기서 강의가 슬쩍 끼워 넣은 소분류 하나가 내부 공변량 시프트(internal covariate shift)입니다. 이건 딥러닝에서 특히 중요한데, 원 논문은 이를 "학습 도중 앞 층의 파라미터가 바뀌면서 각 층의 입력 분포가 계속 변하는 현상"으로 정의하고, 이 때문에 학습이 느려진다고 진단합니다. 그 해법으로 나온 게 바로 Batch Normalization이고요 — 층 입력을 정규화해 같은 정확도를 14배 적은 스텝으로 달성했다는 논문입니다. (출처: Ioffe & Szegedy, "Batch Normalization…", arXiv:1502.03167, 2015) BatchNorm을 "왜 쓰나"의 원류가 이 시프트 개념이라는 걸 알면 면접에서 한 단계 깊게 답할 수 있습니다.

어디에 쓰나 — 운영 중인 모델의 성능이 이유 없이 떨어지면 1순위 용의자가 데이터셋 시프트입니다. 그래서 MLOps에선 입력 분포를 지속 모니터링하다가(5장의 품질 지표와 연결) 드리프트가 감지되면 재학습을 트리거합니다. "왜 재학습이 필요한가"의 이론적 근거가 바로 이 세 가지 시프트예요.

강의는 데이터 누수 방지법(교차검증 전 올바른 정규화, 훈련/검증/테스트 3분할, 중복 제거)을 한 번 더 강조하며 "바퀴를 다시 발명하지 마라(You don't have to reinvent the wheel)"는 슬라이드로 끝맺습니다. 검증엔 Pydantic·pandera, 파이프라인엔 Airflow, 누수 방지엔 sklearn Pipeline — 이미 잘 만들어진 도구를 쓰라는 거죠.

치트시트 & 핵심 7가지

상황	도구 · 패턴
입력 데이터 검증	`Pydantic` / `pandera` — 입구에서 규칙 위반 차단
학습 데이터 저장	`Parquet` + `PyArrow` — 타입·스키마 보존
전송 무결성	`SHA256` 체크섬 (비밀번호엔 절대 X → bcrypt/argon2)
파이프라인 자동화	`Airflow` (스케줄) · `Invoke` (태스크)
결측 처리	삭제(listwise) vs 대치(impute) — "왜 비었나" 먼저
누수 방지	`train_test_split` 먼저 → `Pipeline`으로 fit 격리
드리프트 감시	입력 분포 모니터링 → 시프트 감지 시 재학습

딱 7가지만 기억하면 됩니다.
1. GIGO — 데이터가 틀리면 모델도 틀린다. 준비가 일의 80%.
2. Cleaning ⊂ Wrangling, Preprocessing은 "한 번", Wrangling은 "반복".
3. 에러는 사람·기계에서 나고, 스키마 검증으로 입구에서 막는다.
4. 예방 = 포맷(Parquet)·서명(해시)·파이프라인(ETL)·tidy data·품질 지표.
5. 수정은 결측·이상치·중복별로 다르게 — 무조건 채우거나 지우지 말 것.
6. 데이터 누수: 테스트에 fit 금지. 전처리는 분리 후, Pipeline으로.
7. 데이터셋 시프트: 공변량·사전확률·개념 3종. BatchNorm의 뿌리이자 재학습의 이유.

참고 자료

Tidy Data 제대로 이해하기 — 지저분한 표를 pandas로 정돈하기

harang Lee — Mon, 31 Aug 2026 14:03:02 +0900

이번 강의는 "Bad Data"라는 넓은 주제였습니다. 실무 데이터가 왜 지저분한지(오타·결측·중복·비표준·이상치…), 그걸 어떻게 청소하고(cleaning) 주무르는지(wrangling), 에러를 어떻게 탐지·예방하는지까지 훑고, 마지막에 Tidy Data로 마무리하더라고요. 그리고 강의와 함께 받은 tidy-data-master 폴더에는 이 Tidy Data 개념의 원전 — Hadley Wickham(해들리 위컴)의 논문과 실제 지저분한 데이터 파일들(종교·소득 조사, 빌보드 차트, 결핵 통계, 기상 관측)이 들어 있었습니다.

강의 전체를 다 옮기면 물타지니까, 이 글은 "지저분한 표를 어떻게 분석 가능한 표로 바꾸는가" 한 갈래에 집중합니다. Tidy Data가 뭔지 정의부터 잡고, 위컴이 정리한 지저분한 데이터 5대 유형 중 자주 만나는 3가지를 실제 강의 데이터에 pandas로 직접 손봐가며 볼게요. 참고로 폴더의 README는 R 코드 파일(tidy-data.R)을 언급하지만 실제 파일은 빠져 있어서, 논문의 R 예제를 제가 pandas로 재현했습니다.

큰 그림 — 조각들이 어떻게 맞물리나
Tidy Data란 무엇인가 (3원칙)
지저분한 데이터 5대 유형
melt — 열 이름이 값일 때 (종교·소득 데이터)
split — 한 열에 변수가 두 개일 때 (결핵 데이터)
pivot — 값이 행·열 양쪽에 흩어졌을 때 (기상 데이터)
치트시트 & 핵심 4가지

1. 큰 그림 — 조각들이 어떻게 맞물리나

Tidy Data는 결국 "표 하나에 딱 세 가지 질문을 던지고, 어긋나면 정해진 도구로 고친다"는 이야기입니다. 세 가지 질문이 tidy의 3원칙이고, 어긋나는 방식이 지저분한 유형이며, 고치는 도구가 melt·split·pivot입니다. 아래 지도가 이 글의 뼈대예요. 이후 각 섹션이 이 칸을 하나씩 채웁니다.

지저분한 표 에 이 질문들을 던진다

▼

변수 = 열?tidy 3원칙§2

열 이름이 값?→ meltwide→long

한 열에 변수 2개?→ splitstr.split

값이 행·열 양쪽?→ pivotlong→wide

세 도구는 서로 반대·보완 관계 — melt는 펴고(long), pivot은 접고(wide), split은 쪼갠다

핵심 한 줄 — Tidy Data는 "예쁜 데이터"가 아니라, 분석 도구가 바로 먹을 수 있게 구조(structure)와 의미(semantics)를 일치시킨 데이터입니다. 사람이 보기 좋은 표와 기계가 다루기 좋은 표는 다릅니다.

2. Tidy Data란 무엇인가 (3원칙)

먼저 용어부터 정확히 잡고 갑시다. 강의 슬라이드에도 한 줄로 "Tidy Data = Narrow Data = long form"이라고만 적혀 있어서, 이게 정확히 뭘 뜻하는지 원전에서 확인하는 게 중요합니다.

Tidy Data (정돈된 데이터): 데이터의 의미를 구조에 규칙적으로 대응시킨 표 — 변수는 열, 관측치는 행에 오도록 맞춘 형태.

variable (변수): 같은 속성을 여러 대상에 걸쳐 잰 값들의 묶음 (예: 키, 온도, 소득구간). observation (관측치): 한 대상에 대해 잰 값들의 묶음 (예: 사람 한 명, 하루, 경기 하나).

비유하자면, 엑셀에서 사람이 보기 좋으라고 만든 "요약표"는 셀 하나에 정보가 응축돼 있어 눈으로 읽기엔 좋지만, 컴퓨터가 groupby·집계·시각화를 하려면 매번 다른 방식으로 값을 뜯어내야 합니다. Tidy Data는 그 뜯어내기를 단 한 가지 방식으로 통일해 줍니다.

원전은 이렇게 정의합니다. 위컴은 Tidy Data를 세 가지 원칙으로 못박습니다 — 각 변수는 하나의 열을, 각 관측치는 하나의 행을, 각 관측 단위 유형은 하나의 표를 이룬다. 그리고 이건 관계형 데이터베이스의 제3정규형(3rd normal form)을 통계 언어로 바꿔 쓴 것이라고 밝힙니다. (출처: Hadley Wickham, Tidy Data, Journal of Statistical Software, §2.3)

# Tidy Data 3원칙 (Wickham, 2014)
# 1. Each variable forms a column.        각 변수 = 하나의 열
# 2. Each observation forms a row.         각 관측치 = 하나의 행
# 3. Each observational unit forms a table. 각 관측 단위 = 하나의 표

여기서 강의의 "long form"이 연결됩니다. 같은 데이터를 담아도 wide form(넓은 형태: 변수를 옆으로 펼쳐 열을 늘림)과 long form(긴 형태: 변수를 아래로 쌓아 행을 늘림)이 있는데, tidy는 보통 long form 쪽입니다. 아래 표가 같은 정보의 두 얼굴입니다.

구분	wide form (넓은/지저분하기 쉬움)	long form (긴/tidy)
모양	열이 옆으로 많음	행이 아래로 많음
예	`religion, <$10k, $10-20k, …`	`religion, income, frequency`
사람 눈	읽기 좋음(요약표)	장황해 보임
기계 처리	매번 다른 방식으로 뜯어야 함	groupby·집계·플롯 한 방에

어디에 쓰나 — seaborn·plotly 같은 시각화 라이브러리, groupby().agg() 집계, 그리고 ML 모델의 입력 X 만들기 전 단계가 전부 tidy(long) 형태를 전제로 돌아갑니다. "데이터가 왜 이렇게 플롯이 안 그려지지?" 태반은 형태가 wide라서입니다.

→ 그럼 실무 데이터는 이 3원칙을 어떻게 어길까요? 위컴이 정리한 5대 유형을 봅니다.

3. 지저분한 데이터 5대 유형

위컴은 "행복한 가정은 다 비슷하지만 불행한 가정은 저마다의 방식으로 불행하다"는 톨스토이를 빌려, 지저분한 데이터도 저마다의 방식으로 지저분하다고 말합니다. 그런데 실제로 겪어보면 대부분 아래 다섯 가지로 수렴하더라는 게 논문의 관찰입니다. (출처: Tidy Data, §3)

지저분한 데이터 5대 유형

▼

① 열이름=값변수가 헤더에→ melt

② 한 열 = 여러 변수성별+나이 뭉침→ split

③ 행·열 양쪽변수가 흩어짐→ pivot

④⑤ 표 문제여러 단위 한 표 /
한 단위 여러 표→ 정규화

이 글은 실무 빈도가 높은 ①②③을 실제 데이터로 다룹니다

④(한 표에 여러 종류의 관측 단위가 섞임)와 ⑤(한 관측 단위가 여러 표에 쪼개짐)는 데이터베이스 정규화·조인의 영역이라 별도 글로 미루고, 여기서는 표 하나를 재구조화하는 ①②③에 집중하겠습니다.

→ 첫 번째, 가장 흔한 "열 이름이 사실은 값"인 경우입니다.

4. melt — 열 이름이 값일 때 (종교·소득 데이터)

앞의 지도에서 ①번 칸입니다. 발표용으로 예쁘게 만든 표는 대개 이 함정에 빠져 있습니다. 강의 데이터 중 pew.txt(미국 Pew Research Center의 종교별 소득 조사)가 딱 그렇습니다.

melt (녹이다): 옆으로 펼쳐진 여러 열을 두 개의 열(이름 열 + 값 열)로 녹여 아래로 쌓는 변형 — wide를 long으로 바꾸는 대표 도구.

직관적으로는 얼음 틀(각 칸=열)을 녹여서 한 줄기 물(이름·값 두 열)로 흘려보내는 그림입니다. 그래서 이름이 "melt"예요.

공식 문서는 이렇게 설명합니다. pandas 공식 레퍼런스는 melt를 "id_vars로 지정한 식별 열은 그대로 두고, 나머지 열들을 variable/value 두 열로 unpivot한다"고 정의합니다. 아래가 공식 문서에 실린 예제 그대로입니다. (출처: pandas.melt)

# pandas 공식 문서 예제 — 대조 기준
df = pd.DataFrame({"A":["a","b","c"], "B":[1,3,5], "C":[2,4,6]})
pd.melt(df, id_vars=["A"], value_vars=["B","C"])
#    A variable  value
# 0  a        B      1     ← B,C 열 이름이 'variable' 열의 값으로 내려오고
# 1  b        B      3        원래 셀 값은 'value' 열로 쌓인다
# ...
# 3  a        C      2

강의 데이터에 적용하면 이렇게 됩니다. pew.txt는 religion 한 열을 빼면 나머지 열 이름(<$10k, $10-20k…)이 전부 "소득 구간"이라는 변수의 값입니다. 즉 열 이름 자리에 데이터가 앉아 있는 거죠. religion만 식별 열로 고정하고 melt하면 tidy해집니다.

pew = pd.read_csv("pew.txt", sep="\t")
print(pew.shape)              # (18, 11)  ← 18개 종교 × 10개 소득열 + religion

tidy = pew.melt(id_vars="religion",
                # 나머지 소득 열 전부를 녹인다
                var_name="income", value_name="frequency")
print(tidy.shape)             # (180, 3)  ← 18 × 10 = 180 행으로 길어짐
print(tidy.head(4))
#            religion income  frequency
# 0          Agnostic  <$10k         27
# 1           Atheist  <$10k         12
# 2          Buddhist  <$10k         27
# 3          Catholic  <$10k        418

재밌는 지점 하나. 위컴은 R 사람이라 논문에서는 reshape2::melt를 썼고, 지금 그의 후속 도구 tidyr에서는 pivot_longer()가 이 역할을 합니다. 그런데 tidyr 공식 문서의 대표 예제가 바로 이 Pew 데이터(relig_income)예요. 강의 데이터와 공식 문서 예제가 같은 데이터인 셈입니다. (출처: tidyr::pivot_longer)

# R tidyr 공식 예제 — 완전히 같은 데이터, 같은 결과 (18×11 → 180×3)
relig_income |> pivot_longer(!religion, names_to = "income", values_to = "count")

항목	pandas 공식 예제	강의 데이터(pew) 적용	차이 · 이유
식별 열	`id_vars=["A"]`	`id_vars="religion"`	고정할 변수 지정 — 개념 동일
녹일 열	`value_vars=["B","C"]` 명시	생략(나머지 전부 자동)	열이 10개라 일일이 안 씀 — 생략 시 id 외 전부
결과 열 이름	`variable`/`value` 기본값	`income`/`frequency`	의미가 드러나게 개명 — 실무 권장
모양 변화	3행 → 6행	18행 → 180행	둘 다 wide→long, 원리 동일

var_name·value_name을 "variable"/"value" 기본값으로 두지 말고 꼭 의미 있는 이름으로 바꾸세요. 6개월 뒤의 내가 value가 빈도인지 금액인지 몰라 헤맵니다.

어디에 쓰나 — 설문·통계청·엑셀에서 받은 "가로로 긴 요약표"를 분석용으로 바꿀 때 1순위 도구입니다. 연도별·월별 열이 옆으로 쭉 늘어선 매출표를 시계열 분석용으로 펴는 것도 정확히 이 패턴입니다.

→ melt로 폈더니 이번엔 열 이름 하나에 변수가 두 개 뭉쳐 있는 경우가 나옵니다.

5. split — 한 열에 변수가 두 개일 때 (결핵 데이터)

지도의 ②번 칸입니다. melt를 하고 나면 variable 열의 값이 사실은 여러 정보를 합쳐 놓은 코드인 경우가 잦습니다. 강의의 tb.csv(WHO 결핵 통계)가 전형적이에요. 열 이름이 new_sp_m1524 같은데, 여기엔 성별(m)과 나이대(15–24세)가 한 덩어리로 붙어 있습니다.

split (쪼개다): 한 문자열을 구분 규칙에 따라 여러 조각으로 나누는 것 — 여기서는 뭉친 열 이름을 성별·나이대 두 변수로 분리.

tidy 원칙 1번("한 변수 = 한 열")을 정면으로 어긴 상태라, 붙어 있는 걸 떼어 각자 열을 주는 게 목표입니다.

공식 문서는 이렇게 설명합니다. pandas Series.str.split은 expand=True를 주면 쪼갠 조각들이 여러 개의 열로 펼쳐진다고 명시합니다(부족한 칸은 NaN으로 채움). (출처: pandas.Series.str.split)

# pandas 공식 문서 예제 — expand=True 는 조각을 '열'로 펼친다
s = pd.Series(["this is a regular sentence", ...])
s.str.split(expand=True)
#        0    1    2        3         4
# 0   this   is    a  regular  sentence   ← 공백 기준으로 5개 열 생성

강의 데이터에 적용하면 이렇게 됩니다. tb.csv는 구분자가 없이 m1524처럼 딱 붙어 있어서, 공식 예제처럼 구분자 split이 아니라 위치 기반 슬라이싱이 더 깔끔합니다(첫 글자=성별, 나머지=나이대). 도구는 .str[...]로 살짝 바꾸되, "한 열의 뭉친 정보를 두 변수로 떼어낸다"는 목적은 공식 예제와 완전히 같습니다.

tb = pd.read_csv("tb.csv")
m  = tb.melt(id_vars=["iso2","year"],
             var_name="column", value_name="cases").dropna()

# "new_sp_m1524" → 접두어 떼고 → 첫 글자=성별, 나머지=나이대
demo    = m["column"].str.replace("new_sp_", "", regex=False)
m["sex"] = demo.str[0]      # 'm' 또는 'f'
m["age"] = demo.str[1:]     # '1524', '014' …

print(m[["iso2","year","sex","age","cases"]].head(3))
# iso2  year sex  age  cases
#   AE  1999   m  014    4.0     ← 성별·나이대가 각자의 열로 분리됨
#   AE  2000   m  014    2.0
#   AE  2002   m  014    1.0

R 쪽에서는 위컴이 이걸 아예 한 함수로 흡수했습니다. pivot_longer(names_to = c("sex","age"), names_sep = ...)처럼 펴면서 동시에 쪼개기가 됩니다 — melt와 split이 한 스텝으로 합쳐진 셈입니다. (출처: tidyr::pivot_longer, names_sep/names_to)

항목	pandas 공식 예제	강의 데이터(tb) 적용	차이 · 이유
도구	`str.split(expand=True)`	`str[0]` / `str[1:]` 슬라이싱	구분자가 없어 위치로 자름 — 목적은 동일
결과	공백마다 N개 열	`sex`, `age` 2개 열	쪼갠 뒤 각자 열이 되는 원리 같음
선행 단계	없음	먼저 `melt` 필요	열 이름이 값이자 뭉친 변수 — ①+② 복합

⚠️ 결핵 데이터에는 값이 0인 칸과 결측(NaN)인 칸이 섞여 있습니다. 논문도 짚듯 이 둘은 의미가 달라요("0건 확인"과 "조사 안 함"). dropna()로 결측만 걸러내되, 0을 결측과 뭉뚱그려 지우지 않도록 주의하세요.

어디에 쓰나 — 로그·센서·설문 필드에서 2026-08-31_seoul_temp처럼 날짜·지역·측정값이 한 컬럼명/문자열에 뭉쳐 오는 경우가 흔합니다. 이걸 각 변수 열로 떼어야 필터·집계가 됩니다.

→ 마지막, 변수가 행에도 있고 열에도 있어 melt만으로는 안 되는 가장 까다로운 경우입니다.

6. pivot — 값이 행·열 양쪽에 흩어졌을 때 (기상 데이터)

지도의 ③번, 논문이 "가장 복잡한 형태"라고 부른 유형입니다. 강의의 weather.txt(멕시코 기상관측소 일별 기온)가 그렇습니다. 날짜는 d1~d31 열로 가로로 흩어져 있고, 동시에 최고기온·최저기온이 element 열 안에서 TMAX/TMIN 행으로 흩어져 있어요. 한 방향은 melt로 펴야 하고, 다른 방향은 다시 접어야 합니다.

pivot (돌려 세우다 / cast): 한 열에 쌓여 있던 값을 여러 열로 펼쳐 세우는 변형 — melt의 반대. 논문 용어로는 cast.

melt가 열을 녹여 아래로 쌓았다면, pivot은 그 쌓인 걸 다시 옆으로 세웁니다. 여기서는 TMAX/TMIN이 서로 다른 변수인데 한 열에 값으로 눌려 있으니, 각자의 열로 세워 올려야 tidy해집니다.

공식 문서는 이렇게 설명합니다. pandas pivot_table은 index(행이 될 키), columns(열로 펼칠 키), values(칸을 채울 값)로 long 데이터를 wide로 재구성한다고 정의합니다. (출처: pandas.pivot_table)

# pandas 공식 문서 예제 — long을 index/columns/values로 세운다
pd.pivot_table(df, values=["D","E"], index=["A","C"], aggfunc="mean")
# A,C 조합이 행이 되고, D·E가 열이 되어 값이 채워짐

강의 데이터에 적용하면 이렇게 됩니다. 2단계예요. ① 먼저 d1~d31을 melt로 펴서 day 열을 만들고(가로 흩어짐 해결), ② 그다음 element(TMAX/TMIN)를 pivot으로 세워 두 개의 열로 올립니다(세로 흩어짐 해결).

w = pd.read_csv("weather.txt", sep="\t")

# ① melt: 날짜 열 d1~d31 을 'day' 한 열로 편다
long = w.melt(id_vars=["id","year","month","element"],
             var_name="day", value_name="value").dropna()
long["day"] = long["day"].str.replace("d","",regex=False).astype(int)
# 이 시점: element(TMAX/TMIN)가 아직 '값'으로 한 열에 눌려 있음 → 아직 안 tidy

# ② pivot: element 를 열로 세운다 (TMAX, TMIN 각자 열로)
wide = long.pivot_table(index=["id","year","month","day"],
                        columns="element", values="value").reset_index()
print(wide.head(3))
#            id  year  month  day   TMAX   TMIN
# MX000017004  2010      1   30  278.0  145.0   ← 하루 = 한 행, 기온 = 각 열
# MX000017004  2010      2    2  273.0  144.0   (값은 0.1℃ 단위: 278 = 27.8℃)
# MX000017004  2010      2    3  241.0  144.0

포인트는 element 열이 변수가 아니라 변수 이름을 담은 열이었다는 겁니다. TMAX와 TMIN은 서로 다른 측정량이니 각자 열이어야 맞습니다. pivot으로 세우고 나면 "하루 = 한 행, 최고·최저기온 = 각 열"이라는 tidy 형태가 완성됩니다. R에서는 이 반대 방향을 pivot_wider()가 맡습니다.

항목	pandas 공식 예제	강의 데이터(weather) 적용	차이 · 이유
행 키	`index=["A","C"]`	`index=[id,year,month,day]`	관측치를 식별하는 키 — 개념 동일
펼칠 키	`columns` 미사용(예제)	`columns="element"`	TMAX/TMIN을 열로 세우는 게 핵심
선행 단계	없음	`melt` 먼저	가로·세로 양쪽 흩어짐이라 melt+pivot 2단
방향	long → wide	long → wide	melt의 역연산 — 원리 동일

pivot vs pivot_table: 같은 (행,열) 조합에 값이 하나뿐이면 pivot, 여러 개라 집계(mean·sum 등)가 필요하면 pivot_table을 씁니다. 중복 키에서 pivot은 에러, pivot_table은 aggfunc로 뭉갭니다.

어디에 쓰나 — "long으로 저장, wide로 표현"이 실무 공식입니다. DB·수집은 tidy(long)로 쌓아두고, 리포트 피벗테이블이나 상관행렬·히트맵을 그릴 때만 pivot으로 잠깐 wide로 세웁니다.

→ 세 도구를 한 장으로 정리하고 닫겠습니다.

치트시트 & 핵심 4가지

증상 (지저분한 유형)	도구	pandas 패턴
열 이름이 사실은 값 (wide)	melt	`df.melt(id_vars=..., var_name=..., value_name=...)`
한 열에 변수가 여러 개	split	`s.str.split(sep, expand=True)` / `s.str[a:b]`
값이 행·열 양쪽에 흩어짐	pivot	`df.pivot_table(index=..., columns=..., values=...)`
(참고) long→wide 되돌리기	pivot	melt의 역연산 — R은 `pivot_wider()`

핵심 4가지
1. Tidy = 변수는 열, 관측치는 행, 관측단위는 표 (Wickham 3원칙 = DB 제3정규형).
2. 사람이 보기 좋은 표(wide)와 기계가 다루기 좋은 표(long)는 다르다 — 분석은 long이 기본.
3. 지저분함은 대부분 열이름=값 / 한 열에 여러 변수 / 행·열 양쪽 흩어짐으로 수렴한다.
4. 고치는 도구는 melt(펴기) · split(쪼개기) · pivot(세우기) 셋이면 충분하다.

강의의 다른 명언도 같은 이야기입니다 — "데이터 분석의 80%는 데이터 청소와 준비에 쓰인다"(Dasu & Johnson, 위컴 논문 서두 인용). tidy 구조를 처음에 잡아두면 그 80%가 훨씬 가벼워집니다.

참고 자료

Hadley Wickham, Tidy Data — Journal of Statistical Software (tidy 3원칙 §2.3, 5대 유형 §3의 원전)
pandas 공식 문서 — melt · pivot_table · Series.str.split
tidyr(R, Wickham) 공식 문서 — pivot_longer (melt/split의 후속, relig_income 예제)
데이터 출처: 강의 첨부 tidy-data-master/data (pew·tb·weather — WHO·Pew·GHCN 원자료)

NumPy는 왜 빠른가 — ndarray 메모리 모델부터 einsum까지

harang Lee — Thu, 27 Aug 2026 14:35:59 +0900

이번 강의자료는 NumPy/SciPy 한 편인데, 분량이 124장이나 됩니다. "왜 파이썬은 느린가"에서 출발해서 ndarray 내부 구조, stride, broadcasting, ufunc, 그리고 마지막엔 einsum까지 훑는, 사실상 "NumPy를 어떻게 생각해야 하는가"를 다룬 자료더라고요. 슬라이드가 그림 위주라 개념 흐름은 좋은데, 정작 "그래서 왜?"를 묻는 대목마다 근거가 비어 있어서 이 글에서 공식 문서로 메꿔가며 다시 정리해 봤습니다.

강의 전체를 한 문장으로 압축하면 이렇습니다 — "파이썬 리스트가 아니라 ndarray로 생각하라. 메모리 레이아웃을 이해하면 뷰·브로드캐스팅·벡터화가 왜 거의 공짜인지 보인다." 그래서 이 글도 그 축을 따라, 메모리 모델을 바닥에 깔고 위로 쌓아 올리는 순서로 갑니다. 자료에 나온 axis·dtype·indexing 같은 조각들은 이 네 기둥 안에 녹여 넣었어요.

1. 큰 그림 — 조각들이 어떻게 맞물리나

NumPy 함수를 외우려 들면 끝이 없습니다. 대신 질문 네 개로 쪼개면, 강의에 나온 수십 개 개념이 각자 어느 칸에 들어가는지 보여요.

NumPy가 빠른 이유 를 이렇게 쪼갠다

▼

무엇을 저장?연속 메모리 + 타입data·dtype

어떻게 위치를?보폭으로 계산strides·view

루프 없이 계산?벡터화·확장ufunc·broadcast

짧게 표현?첨자로 지정einsum

아래 각 섹션이 이 네 칸을 왼쪽부터 하나씩 채웁니다.

맨 왼쪽 칸이 가장 밑바닥입니다. 여기서부터 시작하죠.

2. ndarray — 연속 메모리 한 덩어리 + 타입

"NumPy가 리스트보다 빠르다"는 말은 많이 듣지만, 그 이유는 결국 메모리에 값을 어떻게 놓느냐에서 갈립니다. 그래서 첫 칸이 ndarray의 정체예요.

ndarray (N차원 배열 객체): 같은 타입의 값들을 메모리에 빈틈없이 이어 붙인 한 덩어리 + 그걸 어떻게 읽을지 알려주는 설명서. 강의 슬라이드는 이걸 "block of memory + indexing scheme + data type descriptor"라는 세 조각으로 표현했습니다.

비유하면, 리스트는 "여기저기 흩어진 물건들의 주소록"이고 ndarray는 "번호표 붙여 한 줄로 세워둔 사물함"입니다. 파이썬 리스트는 각 원소가 사실 객체를 가리키는 포인터라, 값들이 메모리 곳곳에 흩어져 있어요(강의 11쪽의 그 화살표 그림이 이걸 말합니다). 흩어져 있으면 CPU 캐시가 무력해지죠. ndarray는 반대로 값 자체가 한 곳에 붙어 있어서, CPU가 "다음 것, 그다음 것"을 예측하며 훑을 수 있습니다.

공식 문서는 이렇게 설명합니다. ndarray는 "연속된 1차원 메모리 구간과, N개의 정수를 그 블록 안 원소 위치로 대응시키는 인덱싱 방식의 결합"이라고 정의합니다. 각 원소가 몇 바이트이고 그 바이트를 어떻게 해석할지는 dtype이 정한다고 못 박고요. (출처: NumPy — Internal memory layout of an ndarray)

# 공식 문서 예제 — ndarray의 세 조각을 눈으로 확인
import numpy as np
x = np.array([[1, 2, 3], [4, 5, 6]], np.int32)
x.shape     # (2, 3)  ← 인덱싱 방식(모양)
x.dtype     # dtype('int32')  ← 데이터 타입 descriptor
x.strides   # (12, 4)  ← 다음 원소까지 몇 바이트 점프?

dtype (data type, 자료형): 원소 하나가 차지하는 바이트 수와 해석 방식 — int32면 4바이트 정수, float64면 8바이트 실수. 강의가 "타입을 명시하여 원소의 배열로 데이터를 유지"한다고 한 게 이 부분입니다. 리스트처럼 아무 타입이나 섞을 수 없는(homogeneous, 동종) 제약이 오히려 속도의 대가예요.

강의 실습에서는 이렇게 짚었습니다. 슬라이드 50쪽이 float32 vs float64를 직접 재봤는데, 이게 dtype 선택이 왜 성능 문제인지 보여주는 좋은 예제라 가져왔습니다.

a = np.zeros((1e6,), dtype=np.float64)
b = np.zeros((1e6,), dtype=np.float32)
%timeit a*a   # 1.78 ms per loop
%timeit b*b   # 1.07 ms per loop  ← 절반 크기 = 더 빠름

항목	공식 문서 예제	강의 실습	차이 · 이유
보려는 것	`shape/dtype/strides` 구조 확인	`float32/64` 속도 비교	같은 "dtype이 메모리를 정한다"를 각각 구조와 성능 관점으로
핵심 메시지	dtype이 바이트 해석을 결정	작은 dtype = 절반 메모리 = 빠름	강의는 결과로, 문서는 원리로 같은 곳을 가리킴

⚠️ 강의도 경고하듯, float32는 반올림 오차가 더 큽니다. "정말 필요할 때만" 쓰라고 하죠 — 딥러닝 추론처럼 메모리·대역폭이 병목일 때가 대표적인 "정말 필요한" 경우입니다.

어디에 쓰나 — 이미지·텐서를 다룰 때 uint8(0~255)로 읽어 메모리를 아끼고, 학습 직전에 astype(np.float32)로 올립니다. 강의 25~36쪽의 "이미지 = (H, W, 3) 텐서, RGB는 0~255" 이야기가 정확히 이 dtype 선택 문제로 이어져요.

→ 다음은 strides입니다. 방금 (12, 4)로 슬쩍 봤는데, 이 숫자 두 개가 NumPy의 마법 절반을 담당합니다.

3. strides와 view — 값을 복사하지 않고 다르게 보기

메모리에 값이 한 줄로 깔려 있다면, 2차원 배열의 a[1][2]는 그 한 줄에서 몇 번째 바이트일까요? 이 "몇 번째"를 계산하는 규칙이 stride입니다.

strides (보폭): 각 축에서 다음 원소로 가려면 메모리를 몇 바이트 건너뛰어야 하는지 적어둔 튜플. 앞의 (12, 4)는 "다음 행은 12바이트, 다음 열은 4바이트 점프"라는 뜻이에요(int32 = 4바이트니까, 한 행에 원소 3개 → 12바이트).

공식 문서는 이렇게 설명합니다. N차원 인덱스 (n₀, …, n_{N-1})가 가리키는 바이트 위치(offset)는 각 인덱스 × 그 축의 stride를 전부 더한 값이라고 정의합니다. 수식으로는 offset = Σ (sₖ × nₖ). (출처: NumPy — Internal memory layout of an ndarray)

# 공식 문서 예제 — 같은 데이터, 다른 stride = 다른 배열
x = np.array([[1,2,3],[4,5,6]], np.int32)
x.strides            # (12, 4)  → C-order(행 우선)
# a[1][2] 위치 = 1*12 + 2*4 = 20바이트째 = 값 6

여기서 강의의 핵심 통찰이 나옵니다. 모양(shape)을 바꾸거나 축을 뒤집는 일은 데이터를 옮기지 않고 stride만 고쳐 쓰면 된다는 거죠. 강의 57~58쪽의 C-order(행 우선, NumPy 기본) vs Fortran-order(열 우선) 그림이 이걸 말합니다 — 같은 메모리를 stride (12,4)로 읽으면 C, (4,12)로 읽으면 Fortran입니다.

강의 실습에서는 이렇게 짚었습니다. 슬라이드 66쪽이 "Not a copy, but a VIEW!!!"라고 강조하는데, 이게 stride의 실전 귀결입니다. 슬라이싱은 stride를 조정한 새 창문일 뿐, 데이터를 복사하지 않아요.

a = np.arange(10)
y = a[1:3]        # 기본 슬라이싱 → view(뷰)
a[1:3] = [10, 11]
y                  # array([10, 11])  ← 원본을 바꿨는데 y도 바뀜!

view (뷰): 같은 데이터 버퍼를 stride·dtype만 바꿔 다르게 바라보는 배열 — 복사가 아니라서 한쪽을 고치면 다른 쪽도 바뀝니다. 반대로 copy(복사)는 버퍼까지 통째로 복제해 서로 독립이고요.

공식 문서는 경계를 이렇게 긋습니다. "기본 인덱싱(슬라이싱)은 항상 뷰를 만들고, 고급 인덱싱(fancy indexing)은 항상 복사를 만든다"고요. 뷰인지 복사인지는 .base로 확인 — 뷰면 원본을, 복사면 None을 돌려줍니다. (출처: NumPy — Copies and views)

# 공식 문서 예제 — view와 copy를 .base로 구별
x = np.arange(9).reshape(3, 3)
y = x[1:3]        # 기본 슬라이싱
y.base is None    # False  → 뷰 (원본 공유)
z = x[[1, 2]]     # fancy indexing(정수 배열)
z.base is None    # True   → 복사 (독립)

인덱싱 방식	예시	결과	왜
기본 슬라이싱	`a[1:3]`, `a[::2]`	view	offset·stride 조정만으로 표현 가능
fancy indexing	`a[[0,2,4]]`	copy	불규칙한 위치 → stride로 못 그림, 새로 모아야 함
boolean mask	`a[a<0]`	copy	위와 같은 이유 (고급 인덱싱)

강의 63쪽이 던진 np.may_share_memory(a, b)가 바로 이 확인용 함수입니다. 두 배열이 메모리를 공유하는지(=뷰 관계인지) 알려줘요. 슬라이스를 수정했는데 엉뚱한 배열이 바뀐다면 십중팔구 뷰 문제입니다.

어디에 쓰나 — 대용량 이미지 배치를 슬라이싱으로 잘라 전처리할 때, 뷰라서 메모리가 안 늘어 좋지만 원본을 건드리면 원본이 오염됩니다. 안전하게 떼어내려면 .copy()를 명시하세요. "왜 원본 데이터가 학습 중에 바뀌었지?" 버그의 단골 원인이 이겁니다.

→ 지금까지가 "데이터를 어떻게 놓고 어떻게 짚나"였습니다. 이제 그 위에서 계산을 어떻게 루프 없이 하는지로 넘어갑니다.

4. vectorization · broadcasting · ufunc — 루프를 C로 내려보내기

연속 메모리에 값이 깔려 있으면, "전부 다 더해"라는 연산을 파이썬 for 없이 한 방에 내려보낼 수 있습니다. 이게 세 번째 칸이고, 서로 맞물린 세 단어로 이뤄져 있어요.

vectorization (벡터화): 원소마다 for를 도는 대신, 배열 전체에 연산을 한 번에 거는 방식. 강의 15쪽의 "5 operations → 2 operations" 그림이 이 아이디어입니다. 루프가 사라지는 게 아니라, 느린 파이썬 루프가 빠른 C 루프로 내려가는 거예요.

ufunc (universal function, 범용 함수): 배열을 원소별(element-wise)로 처리하는, 벡터화된 함수 — np.add, np.sqrt, np.sin 같은 것들. 강의 84쪽이 "이런 종류의 연산을 ufunc라 한다"고 한 그거요.

공식 문서는 이렇게 설명합니다. ufunc는 "ndarray를 원소 대 원소로 처리하며, 배열 브로드캐스팅과 타입 캐스팅 등을 지원하는 함수"이고, "고정된 입력을 받아 고정된 출력을 내는 함수의 '벡터화된' 래퍼"라고 정의합니다. (출처: NumPy — Universal functions (ufunc))

# 공식 문서 예제 — 원소별 처리 + 브로드캐스팅
a = np.array([1.0, 2.0, 3.0])
b = 2.0
a * b     # array([2., 4., 6.])  ← 스칼라가 전체에 퍼짐

그런데 위에서 a는 모양 (3,)이고 b는 스칼라입니다. 모양이 다른데 어떻게 곱해질까요? 여기서 세 번째 단어가 나옵니다.

broadcasting (브로드캐스팅): 모양이 다른 배열끼리 연산할 때, 작은 배열을 큰 배열 모양에 맞춰 자동으로 늘려주는 규칙. 강의 79~82쪽이 스칼라·1D·2D·3D로 단계별로 보여준 바로 그 그림입니다.

공식 문서는 규칙을 이렇게 못 박습니다. 두 배열의 모양을 맨 뒤(오른쪽) 차원부터 왼쪽으로 비교해서, 각 차원이 ①크기가 같거나 ②한쪽이 1이면 호환된다고요. 그리고 결정적으로 — 이 과정에서 "데이터를 불필요하게 복사하지 않고, 루프가 파이썬 대신 C에서 돈다"고 합니다. (출처: NumPy — Broadcasting)

강의 실습에서는 이렇게 짚었습니다. 슬라이드 80쪽의 (4,3) + (3,) 예제가 규칙을 정확히 따릅니다.

# 강의 실습 — (4,3) 행렬에 (3,) 벡터 더하기
A = np.arange(12).reshape(4, 3)   # shape (4,3)
v = np.array([0, 1, 2])            # shape (3,)
A + v
# 맨 뒤 차원: 3 == 3 ✓ / 그 앞: 4 vs (없음→1) ✓
# v가 4개 행에 각각 복사된 것처럼 동작 (실제 복사는 안 함)

왼쪽 shape	오른쪽 shape	맞춰본 결과	되나?
`(4, 3)`	`(3,)`	`(4, 3)`	✅ 뒤부터 3=3, 4=4(1로 채움)
`(4, 3)`	`(4, 1)`	`(4, 3)`	✅ 3 vs 1 → 1이 늘어남
`(4, 3)`	`(4,)`	—	❌ 뒤부터 3 vs 4, 둘 다 1 아님

연산 결과를 어느 축으로 뭉갤지는 axis가 정합니다. axis (축): 다차원 배열에서 연산이 진행되는 방향 — axis=0은 행 방향(세로로 훑음), axis=1은 열 방향(가로로 훑음). 강의 60쪽의 np.mean 예제가 헷갈리기 딱 좋은 대목이라 짚고 갑니다.

a = np.arange(30).reshape(10, 3)
a.mean(axis=0)   # shape (3,) → 각 '열'의 평균. 축 0이 사라짐
a.mean(axis=1)   # shape (10,) → 각 '행'의 평균. 축 1이 사라짐

axis=k는 "k번째 축을 없앤다"로 외우면 안 헷갈립니다. (10, 3)에서 axis=0을 주면 0번 축(크기 10)이 뭉개져 (3,)이 남죠. "0이니까 행별?"로 외우면 매번 헷갈립니다.

어디에 쓰나 — 데이터 정규화가 교과서적 사례입니다. (N, D) 특성 행렬에서 X - X.mean(axis=0)는 브로드캐스팅으로 각 특성의 평균을 빼주죠(평균 (D,)가 N개 행에 퍼짐). 이미지에서 채널별 평균을 빼는 전처리도 정확히 같은 패턴입니다.

→ 여기까지가 강의의 "기초 3기둥"입니다. 마지막으로, 이 모든 연산을 첨자 문자열 하나로 표현하는 einsum으로 마무리합니다.

5. einsum — 첨자로 텐서 연산을 받아쓰기

행렬곱, 전치, 대각합, 배치 연산… 강의 후반 20쪽이 통째로 einsum 하나에 할애돼 있습니다. 슬라이드 105쪽 제목이 "Einsum is All You Need"일 정도예요. 앞의 벡터화·브로드캐스팅을 선언적으로 적는 방법이라 마지막 칸에 놓았습니다.

einsum (Einstein summation, 아인슈타인 합 표기): 각 축에 알파벳 라벨을 붙이고, 그 라벨의 등장 패턴만으로 연산을 지정하는 방법. "ik,kj->ij" 한 줄이 행렬곱이 됩니다.

규칙은 딱 두 개예요(강의 122쪽 요약과 일치합니다):

반복되는 라벨은 합친다 — 곱하고 그 축으로 더함(summation index).
출력(-> 뒤)에 남긴 라벨은 유지한다 — 안 남기면 그 축은 사라짐(free index).

공식 문서는 이렇게 설명합니다. "라벨이 반복되면 그 축으로 합산되므로 np.einsum('i,i', a, b)는 np.inner(a,b)와 같고, 라벨이 한 번만 나오면 합산하지 않는다"고요. (출처: NumPy — numpy.einsum)

# 공식 문서 예제 — 라벨 패턴만으로 연산이 결정됨
a = np.arange(25).reshape(5, 5)
np.einsum('ii', a)        # 60      → 대각합(trace): i가 반복 → 합산
np.einsum('ii->i', a)     # [0,6,12,18,24] → 대각선: i를 남김 → 유지
np.einsum('ij->ji', a)    # 전치(transpose): 라벨 순서만 뒤집음
np.einsum('ij,jk->ik', a, b) # 행렬곱: j가 반복 → j축으로 합산

강의 실습에서는 이렇게 짚었습니다. 슬라이드 111쪽이 3중 for 루프 행렬곱을 einsum 한 줄로 접는 과정을 색 화살표로 보여줍니다. "이 장황한 루프가 결국 이 한 줄"이라는 대비가 einsum의 매력을 정확히 찌릅니다.

# 강의 실습 — 행렬곱을 루프로 vs einsum으로
# [기존] 3중 루프
C = np.empty((Ni, Nj))
for i in range(Ni):
    for j in range(Nj):
        total = 0
        for k in range(Nk):   # k: 합산 인덱스(반복 라벨)
            total += A[i, k] * B[k, j]
        C[i, j] = total          # i, j: 자유 인덱스(출력에 남음)

# [einsum] 한 줄 — k가 반복 → k로 합산, ij는 출력에 남김
C = np.einsum("ik,kj->ij", A, B)

연산	강의 표기	공식 표기	차이 · 이유
대각합(trace)	`"ii->"`	`"ii"`	같은 결과. 강의는 "출력 비움"을 `->`로 명시(explicit), 공식은 생략(implicit) — 명시형이 덜 헷갈려 실무 권장
전치	`"ij->ji"`	`"ij->ji"`	동일
행렬곱	`"ik,kj->ij"`	`"ij,jk->ik"`	라벨 이름만 다를 뿐 구조 동일(반복 라벨로 합산)

강의가 강조한 einsum의 진가는 배치(batch) 차원입니다. 슬라이드 117쪽의 배치 외적 "Bi,Bj->Bij"처럼, 앞에 B 라벨 하나만 붙이면 "배치마다 반복"이 공짜로 붙어요. 슬라이드 120쪽은 MLP 역전파(backprop) 전체를 einsum 몇 줄로 적는데, np.dot에서 매번 고민하던 전치·축 순서를 einsum이 알아서 처리한다는 게 핵심입니다.

⚠️ einsum은 만능처럼 보이지만, 라벨 규칙을 어기면 조용히 틀리는 게 아니라 에러를 냅니다(강의 198쪽 "Bad" 사례 모음). 대표적으로 — 입력 첨자 그룹 수 ≠ 인자 개수, 출력에 없는 입력 라벨을 출력에 넣기, 같은 라벨인데 축 크기가 다름. 라벨은 반드시 ASCII 알파벳이어야 하고요.

어디에 쓰나 — 어텐션(attention) 스코어 QKᵀ를 "bqd,bkd->bqk"로 적으면 배치·헤드 차원을 라벨로 관리하며 실수를 줄입니다. PyTorch torch.einsum, TensorFlow tf.einsum도 같은 문법이라, 한 번 익히면 프레임워크를 넘나들며 씁니다.

치트시트 & 핵심 4가지

하고 싶은 것	패턴
구조 확인	`x.shape`, `x.dtype`, `x.strides`
뷰/복사 판별	`y.base is None`, `np.may_share_memory(a, b)`
안전하게 떼어내기	`a[1:3].copy()`
축별 집계	`X.mean(axis=0)` (0번 축을 없앰)
모양 다른 연산	`X - X.mean(axis=0)` (broadcasting)
행렬곱	`np.einsum("ik,kj->ij", A, B)`
대각합 / 전치	`np.einsum("ii->", M)` / `np.einsum("ij->ji", M)`

딱 4가지만 기억하면 이 강의가 정리됩니다.
1. ndarray = 연속 메모리 + dtype + strides — 리스트보다 빠른 근본 이유.
2. 슬라이싱은 뷰, fancy/bool 인덱싱은 복사 — stride로 그릴 수 있으면 뷰.
3. broadcasting은 뒤 차원부터, 같거나 1이면 OK — 복사 없이 C 루프로.
4. einsum은 반복 라벨=합산, 남긴 라벨=유지 — 텐서 연산의 받아쓰기.

강의 123쪽의 "Zen of NumPy"가 이 네 가지를 한 줄씩 압축해 뒀더라고요 — "흩어진 것보다 보폭이 낫고(strided), 보폭보다 연속이 낫다(contiguous). 명령형보다 선언형이 낫다(데이터 타입을 써라). 벡터화가 명시적 루프보다 낫다." 결국 메모리를 이해하고, 루프를 NumPy에게 넘겨라로 수렴합니다.