12장. 병든 학습 고치기
이 장의 질문: 학습이 안 될 때, 무엇을 어떤 순서로 의심해야 하는가? 증상별 진단 절차 — 이론이 아니라 임상이다. 이 장은 딥러닝을 하는 내내 다시 펼치게 될 것이다.
전제: 4장(과적합/과소적합), 10~11장(역전파, 학습 레시피).
의사의 마음가짐
학습이 안 되는 데는 언제나 이유가 있다. 신경망은 변덕스러워 보이지만 초자연적이지는 않다 — 손실이 NaN이 되는 것도, 정확도가 찍기 수준에서 안 움직이는 것도, 전부 추적 가능한 원인의 결과다. 필요한 것은 영감이 아니라 절차다. 원칙 두 개를 먼저 새긴다.
원칙 1: 한 번에 하나만 바꾼다. 학습률과 모델 구조와 데이터 전처리를 동시에 바꾸면, 나아져도 왜 나아졌는지 모른다. 디버깅은 통제된 실험의 연속이다.
원칙 2: 버그의 서식지는 확률 순으로 뒤진다. 경험적 서식지 분포는 대략 이렇다 — 데이터·전처리 > 학습률 등 기본 설정 > 손실/출력의 결선 > 모델 구조. 초심자는 정반대 순서로(모델부터) 뒤지며 시간을 태운다. 화려한 용의자보다 지루한 용의자가 범인이다.
0단계: 학습을 시작하기 전의 건강검진
병이 나기 전에 막는 세 가지 확인. 새 프로젝트마다 의식처럼 수행하라.
첫 손실값 검산. 학습 전, 무작위 초기화 상태의 손실은 예측 가능하다.
한 배치 암기 테스트. 데이터 단 한 배치(수십 개)만 반복 학습시켜 보라. 정상 모델이라면 손실이 0 근처까지 처박혀야 한다 — 4장에서 배웠듯 큰 모델이 소량 데이터를 못 외우는 것이 오히려 이상하다. 못 외우면 데이터 파이프라인이나 기울기 흐름에 구조적 버그가 있다는 뜻이며, 전체 데이터로 몇 시간 태우기 전에 잡을 수 있다. 가장 가성비 좋은 테스트다.
데이터 눈검사. 모델에 들어가기 직전의 배치를 꺼내 사람 눈으로 보라. 이미지라면 그려 보고, 텍스트라면 디코딩해 보라. 뒤집힌 이미지, 밀린 레이블, 전부 0인 텐서, 정규화 두 번 적용 — 놀랄 만큼 흔하고, 눈으로 보면 3초 만에 잡힌다.
증상별 진단
증상 A: 손실이 폭발한다 (inf/NaN, 또는 널뛰기)
- 학습률부터 10분의 1로. 발산의 첫 용의자는 언제나 학습률이다(2장에서 직접 체험했다). 줄여서 멎으면 그 사이 어딘가가 적정선이다.
- 손실 안의 수치 지뢰 확인 —
, , 직접 짠 손실의 오버플로. 소프트맥스+교차 엔트로피를 손수 조합하지 말고 프레임워크의 결합 구현(내부적으로 안정화됨)을 쓰는 것도 이 때문이다. - 기울기 클리핑(11장)을 걸고, 기울기 노름을 로깅해 실제로 폭발하는지 눈으로 확인.
- 데이터에 극단값·NaN이 섞여 있는지 확인(특징 하나가 수백만 단위면 그 방향의 기울기도 수백만 단위다 — 표준화).
증상 B: 손실이 내려가긴 하는데 찍기 수준에서 정체
가장 정보가 적은 증상이라 절차가 중요하다.
- 결선 버그 수색이 최우선. 정체의 흔한 진범들: 레이블과 입력의 순서가 어긋남(셔플을 따로 함), 손실에 로짓 대신 확률을 넣음(소프트맥스 이중 적용), 마지막 층 출력 개수가 클래스 수와 다름,
zero_grad누락(10장). 한 배치 암기 테스트가 이 부류를 대부분 걸러낸다. - 학습률 탐색 — 3e-4에서 시작해 10배 간격으로 위아래를 훑는다. 너무 작으면 정체처럼 보인다.
- 입력 표준화 여부 확인. 크기가 관리 안 되는 입력은 학습을 죽인다(11장).
- 이 모두가 정상인데도 정체라면 그때서야 모델 용량과 표현(구조)을 의심한다.
증상 C: 훈련 손실은 좋은데 검증이 나쁘다
4장의 과적합이다 — 처방전도 4장 그대로: 데이터 증강 → 정규화 강화(weight decay, 드롭아웃) → 조기 종료 → 모델 축소, 이 순서로. 단, 그 전에 반드시 확인할 것: 훈련·검증의 전처리가 동일한가? 훈련에만 적용해야 할 증강이 검증에 들어갔거나, 정규화 통계가 다르게 적용된 경우 — 과적합처럼 보이는 파이프라인 버그가 정말 많다. 그리고 검증 성적이 수상하게 너무 좋을 때도 의심하라 — 십중팔구 데이터 누수(4장)다.
증상 D: 어느 순간부터 성적이 무너진다 (잘 되다가 역주행)
학습률 스케줄이 없어 후반에 골짜기 바닥을 큰 걸음으로 짓밟고 있거나(감쇠 스케줄 추가), 학습률이 커서 안정 영역을 이탈한 것. 드물게는 데이터의 특정 구간(손상된 샤드)이 원인이니, 무너진 스텝 근처의 배치를 열어 보라.
증상 E: 재현이 안 된다 (어제는 됐는데)
시드 고정 여부, 라이브러리 버전, 데이터 버전, 하이퍼파라미터 — 8장의 기록 규율이 없으면 원인 추적 자체가 불가능하다. "돌 때마다 성적이 몇 %씩 다르다"는 것 자체는 정상 범위일 수 있다(초기화·셔플의 무작위성). 그래서 중요한 비교는 시드 여러 개의 평균으로 한다(8장).
관찰 없이는 진단도 없다
의사에게 청진기가 필요하듯, 다음 넷은 항상 로깅하라. 이 네 곡선이 있으면 위 증상들 대부분이 그래프에서 먼저 보인다.
- 훈련 손실과 검증 손실 (같은 그래프에) — 간격이 과적합, 동반 정체가 과소적합/버그.
- 기울기 노름 — 폭발·소실의 직접 증거.
- 학습률 — 스케줄이 의도대로 도는지.
- 표본 예측 — 몇 에포크마다 실제 예측 결과 몇 개를 눈으로. 숫자 지표가 못 잡는 이상함(같은 답만 내놓음 등)을 잡는다.
마지막으로 태도에 관한 조언 하나. 학습이 안 될 때 "모델이 이상하다"고 말하고 싶은 유혹을 견뎌라. 12장 전체를 한 문장으로 줄이면 이렇다 — 모델을 의심하는 것은 데이터, 설정, 결선을 모두 무죄 방면한 다음의 일이다. 이 순서를 지키는 사람이 하루 만에 잡는 버그를, 안 지키는 사람은 일주일 걸려 잡는다.
핵심 요약
- 디버깅은 절차다: 한 번에 하나만 바꾸고, 데이터 → 설정 → 결선 → 모델 순으로 의심한다.
- 시작 전 3종 검진: 첫 손실 =
검산, 한 배치 암기 테스트, 배치 눈검사. 이 셋이 버그의 태반을 조기에 잡는다. - 폭발 → 학습률↓·클리핑·수치 지뢰. 정체 → 결선 버그 수색이 먼저. 과적합 모양 → 전처리 일치 확인 후 4장 처방. 너무 좋은 성적 → 누수 의심.
- 상시 로깅 4종: 훈련/검증 손실, 기울기 노름, 학습률, 표본 예측.
스스로 점검
- 10클래스 분류의 첫 손실이 6.2로 찍혔다. 무엇을 의심하겠는가? (힌트:
과 비교, 그리고 어떤 결선 실수가 손실을 부풀리는가) - 한 배치 암기 테스트에 실패하는 모델과 성공하는 모델 — 각각에서 용의선상이 어떻게 달라지는가?
- 검증 정확도가 훈련 정확도보다 높게 나왔다. 가능한 원인을 두 가지 들어 보라. (하나는 무해하고 하나는 치명적이다.)
- 지금 진행 중인(또는 코드랩 02의) 학습에 로깅 4종 세트를 실제로 붙여 보라.
다음 장에서
3부가 끝났다 — 3부 복습 퀴즈로 점검하라. 이제 기계에게 감각을 주러 간다. 4부의 첫 관문은 시각이다. 픽셀 100만 개짜리 벡터를 9장의 MLP에 그대로 넣으면 왜 안 되는지, 그리고 "본다"는 행위의 구조를 신경망에 새겨 넣은 발명 — 합성곱 — 이 어떻게 그 문제를 푸는지 본다.