Day 5 - Week 5 종합: 모델 개발 2 복습

한 장으로 보는 Week 5

이번 주는 "내 코드로 학습하고, 크게 학습하고, 학습을 들여다보고, 결과를 제대로 평가한다"는 모델 개발의 두 번째 절반이었다.

[커스텀 학습]      내 코드를 어디까지 가져오나
   스크립트 모드 → requirements 확장 → BYOC

[분산 학습]        무엇을 쪼개나
   데이터 병렬(느림) ↔ 모델 병렬(안 들어감)

[디버깅·프로파일링] 학습 안을 들여다본다
   Debugger(모델 텐서) ↔ Profiler(자원)

[모델 평가]        결과가 정말 좋은가
   지표 선택 + 과적합 진단 + 교차검증

• 커스텀 학습은 "최소 노력" 쪽(스크립트 모드)을 기본으로 두고 필요한 만큼만 아래로 내려간다.
• 분산은 증상(느림 vs OOM)으로, 관측은 관심사(모델 vs 자원)로, 평가는 문제 성격(불균형·이상치)으로 갈린다.

하나의 학습 작업 안에서 보면

이번 주 네 주제는 서로 다른 이야기가 아니라 같은 학습 작업의 다른 단면이다.

                       ┌── 커스텀 학습: 무엇으로 실행할 것인가 (컨테이너·코드)
                       │
   S3 데이터 ──► [ SageMaker 학습 작업 ] ──► model.tar.gz ──► (다음 주) 배포
                       │        │
                       │        └── 관측: Debugger(텐서) / Profiler(자원) / CloudWatch
                       │
                       └── 분산 학습: 몇 대에 어떻게 쪼갤 것인가
 
                            그리고 끝난 뒤 ──► 평가: 지표 선택 · 과적합 · 교차검증

커스텀 학습 복습

"내 코드를 어디까지 가져오느냐"의 스펙트럼이다.

기억할 규약: 데이터는 SM_CHANNEL_<채널명>, 모델 저장은 SM_MODEL_DIR(/opt/ml/model). BYOC는 /opt/ml/input/data/<채널명>/ 입력, train 실행 규약.

입력 모드도 함께 기억한다 — File(전부 복사 후 시작) / Pipe(스트리밍) / FastFile(필요할 때 지연 로딩). 시작 지연이 문제면 FastFile·Pipe를 검토한다.

💡 관련 이론: 이 계층은 관심사 분리다. 학습 로직과 실행 환경을 분리해, 환경이 표준이면 코드만 갈아끼우고(스크립트 모드) 환경이 특수할 때만 환경을 직접 만든다(BYOC). 시험이 "최소 노력"을 강조하면 위쪽을, "시스템 의존성/미지원 프레임워크"를 말하면 아래쪽을 고른다.

분산 학습 복습

"무엇을 쪼개느냐"로 갈린다.

• 데이터 병렬: 데이터를 GPU마다 나누고 모델 복제본으로 학습 후 그래디언트 all-reduce 평균. 해결하는 문제 = 속도(처리량). SMDDP. 주의: 유효 배치 증가 → 학습률 조정.
• 모델 병렬: 모델 자체를 GPU에 분할·샤딩. 해결하는 문제 = OOM(모델이 안 들어감). SMP.
• 인프라: 노드 간 통신 = EFA, 데이터 공급 = FSx for Lustre.

OOM이 "조금 모자란" 수준이면 병렬화 전에 혼합 정밀도 · 배치 축소 + 그래디언트 누적 · 활성값 체크포인팅부터 시도한다.

⚠️ 함정: OOM을 데이터 병렬(GPU 추가)로 풀려는 보기는 오답이다. 데이터 병렬은 각 GPU에 전체 복제본을 두므로 모델이 안 들어가면 GPU를 늘려도 똑같이 OOM이다. OOM은 모델 병렬/샤딩으로 푼다. 반대로 "느리다"는 데이터 병렬이다.

디버깅·프로파일링 복습

학습 내부를 두 관점으로 본다.

기억할 점: Debugger 규칙은 기본적으로 감지·보고만 하고, 자동 중단하려면 action(StopTraining)을 붙여야 한다. GPU 저활용은 데이터 파이프라인(worker 증가, FSx 캐시, 프리페치)으로 푼다.

증상에서 도구·조치까지 한 줄로 잇는 연습이 시험에 그대로 나온다.

Debugger는 모델이라는 수학적 프로세스의 내부 상태를, Profiler는 그 프로세스가 도는 물리 자원의 사용 패턴을 본다. 두 층위를 함께 봐야 "왜 학습이 안 되나"와 "왜 비싼가"를 동시에 푼다.

모델 평가 복습

"문제에 맞는 지표"로 "일반화"를 잰다.

• 분류: 혼동행렬 → 정밀도(거짓경보 억제)·재현율(놓침 방지)·F1·AUC. 불균형이면 정확도 금지, F1·재현율·AUC-PR.
• 회귀: RMSE(큰 오차 민감)·MAE(이상치 둔감)·R².
• 과적합: 학습-검증 격차로 진단 → 정규화·드롭아웃·증강·조기 종료.
• 교차검증: k-fold로 평가 분산↓. 불균형 = stratified, 시계열 = time-series split.
• 누수 점검: 전처리는 반드시 분할 이후 학습 세트 기준으로. 점수가 비현실적으로 높으면 과적합보다 누수를 먼저 의심한다.

한 팀이 "정확도 98%" 사기 탐지 모델을 자랑했지만 실제로는 사기를 거의 못 잡았다(불균형). 재현율을 보니 12%였다. 평가 지표를 F1·재현율로 바꾸고 stratified k-fold로 검증한 뒤, 임계값과 클래스 가중치를 조정해 재현율을 끌어올렸다. 교훈: 숫자 하나(정확도)에 속지 말고 문제 성격에 맞는 지표로 본다.

종합 의사결정 흐름

이번 주 전체를 하나의 판단 트리로 묶으면:

학습할 때
 ├─ 내 코드 종류?  표준 프레임워크 → 스크립트 모드
 │                 +파이썬 패키지 → requirements
 │                 +시스템 패키지 → BYOC
 ├─ 규모?          느림 → 데이터 병렬 / OOM → 모델 병렬
 └─ 문제 생기면    모델 이상 → Debugger / 자원 비효율 → Profiler

평가할 때
 ├─ 분류?  불균형 → F1·재현율·AUC / 균형 → 정확도 가능
 ├─ 회귀?  큰 오차 중요 → RMSE / 이상치 둔감 → MAE
 ├─ 일반화?  학습-검증 격차 크면 과적합 → 정규화·증강·조기종료
 └─ 데이터 적음?  k-fold 교차검증 (불균형=stratified, 시계열=time-split)

한 코드 안에서 다시 보기

이번 주에 나온 설정들이 실제로는 하나의 Estimator에 함께 붙는다. 각 인자가 어느 주제에서 왔는지 확인하며 읽는다.

from sagemaker.pytorch import PyTorch
from sagemaker.debugger import Rule, rule_configs
 
estimator = PyTorch(
    entry_point='train.py', source_dir='src', role=role,   # ← 커스텀 학습(스크립트 모드)
    framework_version='2.0', py_version='py310',
    instance_type='ml.p4d.24xlarge', instance_count=2,
    distribution={'torch_distributed': {'enabled': True}},  # ← 분산 학습
    rules=[Rule.sagemaker(                                  # ← 관측(Debugger)
        rule_configs.loss_not_decreasing(),
        actions=rule_configs.ActionList(rule_configs.StopTraining())
    )],
    metric_definitions=[                                    # ← 관측(CloudWatch 지표)
        {'Name': 'validation:f1', 'Regex': r'val_f1: ([0-9\.]+)'}
    ],
    enable_sagemaker_metrics=True,
    use_spot_instances=True, max_run=86400, max_wait=172800,
    checkpoint_s3_uri='s3://my-bucket/ckpt/',               # ← 비용·생존성
)
estimator.fit({'training': 's3://my-bucket/train/'})

• val_f1을 지표로 올려 두면, 평가에서 고른 지표가 그대로 모니터링·튜닝 목표가 된다.
• 스팟과 체크포인트는 한 세트, 규칙과 액션도 한 세트다. 한쪽만 켜면 효과가 없다.

키워드 → 정답 즉답 카드

자주 걸리는 오답 패턴

다음 주에는 학습한 모델을 실제로 서비스에 올리는 모델 배포와 추론을 다룬다.

📖 용어

• 스크립트 모드 : 학습 스크립트만 넘기고 실행 환경은 AWS 컨테이너에 맡기는 방식. 이번 주의 기본값.
• BYOC : Docker 이미지를 직접 만들어 ECR에 올려 쓰는 방식. 시스템 패키지·특수 런타임이 필요할 때만.
• SM_MODEL_DIR : 컨테이너 안 /opt/ml/model. 여기 저장한 것만 S3로 올라간다.
• 데이터 병렬 / 모델 병렬 : 데이터를 쪼개 빨라지는 방식 / 모델을 쪼개 메모리에 넣는 방식.
• 샤딩 : 파라미터·그래디언트·옵티마이저 상태를 GPU들에 나눠 보관해 메모리를 줄이는 기법.
• EFA / FSx for Lustre : 노드 간 저지연 네트워크 / 대용량 데이터를 빠르게 공급하는 병렬 파일시스템.
• Debugger 액션 / Profiler : Debugger 액션은 규칙 위반 시 실행할 조치로, StopTraining으로 비용이 새는 학습을 끊는다. Profiler는 GPU·CPU·I/O가 각각 얼마나 바쁜지 측정해 병목을 찾아 주는 도구다.
• metric_definitions : 학습 로그에서 정규식으로 숫자를 뽑아 CloudWatch 지표로 올리는 설정.
• AUC-PR : 정밀도-재현율 곡선의 면적. 양성이 매우 드문 데이터에서 ROC-AUC보다 정직한 지표.
• 데이터 누수 : 평가 시점에 알 수 없어야 할 정보가 학습에 섞여 점수가 부풀려지는 현상.