DEEP LEARNING FUNDAMENTALS ③ · ML STRATEGY · ERROR ANALYSIS
모델 성능이 안 나온다.
그래서 무엇부터 고칠 것인가?
Course 1에서는 Neural Network가 어떻게 학습하는지 배웠다. Course 2에서는 그 Network를 어떻게 안정적이고 빠르게 학습시키는지 배웠다. 그런데 실제 프로젝트에 들어가면 훨씬 어려운 문제가 나타난다.
모델을 키워야 할까?
Label을 다시 검수해야 할까?
Dev Set을 바꿔야 할까?
Transfer Learning을 써야 할까?
아니면 지금 Metric부터 잘못된 걸까?
이 질문들은 Backpropagation 공식만 안다고 해결되지 않는다.
Structuring Machine Learning Projects는 바로 이런 상황에서 AI Engineer가 어떤 순서로 문제를 진단하고, 어디에 시간을 투자할지 결정하는 방법을 가르친다.
Orthogonalization · Single-number Metric · Satisficing / Optimizing Metric · Train/Dev/Test Distribution · Human-level Performance · Avoidable Bias
Week 2 · ML Strategy
Error Analysis · Incorrect Labels · Data Mismatch · Train-dev Set · Transfer Learning · Multi-task Learning · End-to-end Learning ```
Course 3의 핵심: 모델이 아니라 의사결정을 최적화한다
“성능을 높이려면 무엇을 할 수 있을까?”보다 “현재 성능을 제한하는 가장 큰 병목은 무엇인가?”를 먼저 묻는다.
WEEK 1
먼저 성공의 기준부터 하나로 맞춰라
프로젝트가 시작되면 팀마다 원하는 것이 다르다.
Data Scientist:
"Accuracy가 높은 모델이 좋습니다."
Platform Engineer:
"Latency가 너무 높습니다."
Product:
"사용자가 싫어하는 False Positive가 많아요."
Security:
"특정 Data는 절대 외부 Model로 나가면 안 됩니다."
Business:
"비용이 너무 비쌉니다."모두 맞는 말이다. 그런데 이것들을 동시에 개선하려 하면 무엇부터 해야 할지 알기 어렵다.
1. Orthogonalization: 다이얼 하나에는 목표 하나
Orthogonalization은 원래 서로 직교하는 축을 뜻하는 수학적 표현이다. ML Strategy에서는 서로 다른 목표를 가능한 한 독립적으로 조절할 수 있는 다이얼을 만들라는 의미로 이해하면 좋다.
예를 들어 Early Stopping은 Training Error를 줄이는 과정도 중단하고, 동시에 Overfitting을 줄이는 Regularization 역할도 한다.
하나의 Knob이 Optimization과 Regularization 두 목표에 동시에 영향을 준다. 그래서 진단 관점에서는 완전히 Orthogonal하지 않다.
좋은 ML Platform도 비슷하다. Model Quality, Latency, Cost, Safety, Authorization을 하나의 거대한 설정으로 묶기보다 각 Layer에서 독립적으로 측정하고 제어할 수 있어야 Debugging이 쉬워진다.
2. Single-number Evaluation Metric
두 모델이 있다고 해보자.
| Model | Precision | Recall |
|---|---|---|
| A | 95% | 90% |
| B | 91% | 94% |
어느 모델이 더 좋을까?
두 숫자를 매번 동시에 비교하면 실험 속도가 느려진다. 그래서 하나의 Evaluation Metric으로 압축할 수 있다.
핵심은 F1 자체가 아니다.
3. 모든 Metric을 하나로 합칠 필요는 없다
예를 들어 음성 인식 모델을 비교한다고 하자.
| Model | Accuracy | Latency |
|---|---|---|
| A | 97% | 80ms |
| B | 98% | 900ms |
서비스 요구사항이 Latency 100ms 이하라고 해보자.
그러면:
Latency ≤ 100ms
Optimizing Metric
그 조건을 만족하는 모델 중 Accuracy 최대화
즉 모든 Metric을 복잡한 가중합으로 만들 필요가 없다.
Optimizing → 승인된 평가 Metric 최대화
Satisficing → P95 Latency 500ms 이하
Satisficing → 필수 Audit Log 100% 기록
Satisficing → 권한 없는 고객 데이터 접근 0건 ```
특히 마지막 조건을 Accuracy와 가중합해서 “Accuracy가 높으니 데이터 접근 위반 몇 건은 허용한다”처럼 만들면 안 된다.
4. Dev/Test Distribution은 어디서 가져올까?
모델을 실제 서비스할 환경이 중요한 이유가 여기서 나온다.
예를 들어 고양이 사진 분류기를 만든다고 하자.
Training Data
= 인터넷에서 수집한 고품질 고양이 사진
실제 서비스
= 사용자가 스마트폰으로 찍은
어둡고 흔들린 사진Training Data를 인터넷 사진으로 많이 구할 수 있다고 해서 Dev/Test까지 인터넷 사진으로 만들면 안 된다.
“앞으로 잘하고 싶은 세계”를 반영해야 한다.
그리고 Dev와 Test는 가능한 한 같은 Target Distribution에서 뽑는 것이 중요하다.
5. Dev/Test Set의 크기는 몇 %가 맞을까?
예전에는 70/30, 60/20/20 같은 비율이 자주 등장했다.
하지만 데이터가 1천만 건이라면 Test 20%는 200만 건이다. 반드시 그렇게 많은 Test Data가 필요한 것은 아니다.
더 중요한 질문은 이것이다.
두 Algorithm의 성능 차이를 충분히 신뢰성 있게 구분할 수 있는가?
Test Set
최종 시스템 성능을 충분히 신뢰성 있게 추정할 수 있는가?
6. Metric이 현실과 충돌하면 Metric을 바꿔라
모델 A와 B가 있다.
Model A
Accuracy = 98%
Model B
Accuracy = 97%Metric만 보면 A가 더 좋다.
그런데 A가 사용자에게 매우 불쾌한 이미지를 가끔 보여준다고 하자. 실제 제품에서는 B가 훨씬 낫다.
그럼 문제는 Algorithm이 아니라 Metric이다.
우리가 원하는 제품 행동을 제대로 표현하지 못한다면 평가 기준을 수정해야 한다.
7. Human-level Performance는 왜 중요할까?
인간이 잘하는 Perception Task에서는 Human-level Performance가 Bayes Error에 대한 실용적인 Proxy 역할을 할 수 있다.
Bayes Error는 데이터 자체의 노이즈와 모호성 때문에 이론적으로 피하기 어려운 Error 수준을 의미한다고 생각하면 된다.
Human-level Error ≈ 1%
Train Error = 8%
Dev Error = 10%이 경우:
약 7% Gap
``` Train → Dev
약 2% Gap ```
상대적으로 큰 문제는 Variance보다 Bias 쪽에 있다고 판단할 수 있다.
8. Avoidable Bias
Training Error 자체만 보고 Bias가 크다고 말할 수는 없다.
예를 들어:
| Case | Human | Train | Dev |
|---|---|---|---|
| A | 1% | 8% | 10% |
| B | 7.5% | 8% | 10% |
두 경우 모두 Train Error는 8%지만 의미가 완전히 다르다.
Human 1% → Train 8%
개선 가능한 Bias가 크다.
Case B
Human 7.5% → Train 8%
Training Error는 이미 상당히 낮다. 오히려 Train → Dev Gap을 줄이는 것이 더 중요할 수 있다.
9. Human-level을 넘어가면 왜 어려워질까?
인간보다 성능이 낮을 때는 Expert Error를 기준으로 아직 줄일 수 있는 Bias를 비교적 쉽게 추정할 수 있다.
그런데 모델이 인간을 능가하면 Bayes Error가 정확히 어디인지 알기 어려워진다.
그래서 Bias와 Variance 중 무엇이 더 큰 병목인지 진단하는 것도 어려워질 수 있다.
10. 그래서 성능이 안 나오면 무엇부터 할까?
WEEK 2
숫자만 보지 말고 Error를 직접 들여다보자
Dev Error가 10%라고 하자.
이 숫자만 보면 무엇을 해야 할지 알 수 없다.
실제로 틀린 Example을 직접 열어봐야 한다.
1. Error Analysis
고양이 분류 모델이 100개의 Dev Example을 틀렸다고 하자.
사람이 직접 보고 원인을 분류한다.
| Error Category | 개수 | 비율 |
|---|---|---|
| Dog와 혼동 | 10 | 10% |
| 야간 사진 | 45 | 45% |
| Blur | 25 | 25% |
| Label Error | 5 | 5% |
이제 우선순위가 보인다.
Dog 분류 문제를 완벽히 해결해도 전체 Error를 최대 10%밖에 줄일 수 없다. 반면 야간 이미지 문제는 45%를 차지한다.
구현이 멋져 보이는 문제보다 실제 Error의 큰 비중을 차지하는 문제를 먼저 해결한다.
금융 AI에서는 이렇게 바꿔볼 수 있다
금융 문서 분류 모델의 Dev Error 200건을 직접 분석했다고 하자.
| 실패 유형 | 비중 | 후보 조치 |
|---|---|---|
| OCR 품질 | 32% | OCR Pipeline 개선 |
| 표 내부 정보 누락 | 27% | Table Parsing |
| 문서 유형 애매함 | 8% | Taxonomy 검토 |
| 잘못된 Label | 4% | Annotation 검수 |
이런 상황에서 더 큰 LLM을 붙이는 것이 첫 번째 답이 아닐 수 있다.
가장 큰 병목이 OCR과 Table Parsing이라면 Retrieval이나 Generation Model을 바꾸기 전에 Ingestion Layer를 고치는 편이 훨씬 큰 효과를 낼 수 있다.
2. Label이 틀렸다면 전부 고쳐야 할까?
Training Set에 잘못된 Label이 일부 있을 수 있다.
Deep Learning 모델은 충분한 데이터가 있고 Label Error가 비교적 Random하다면 어느 정도 Noise를 견딜 수 있다.
따라서 수백만 개 Training Example을 모두 사람이 다시 검수하는 것이 항상 최고의 투자라는 보장은 없다.
평가 Label이 잘못되어 있으면 모델의 실제 성능을 판단하는 기준 자체가 오염된다.
특히 잘못된 Label이 전체 Dev Error에서 큰 비중을 차지한다면 정리할 가치가 있다.
3. 첫 시스템을 빨리 만들어라
프로젝트를 시작하기 전에 가능한 모든 Error Case를 상상하려 하면 끝이 없다.
Andrew Ng의 중요한 조언 중 하나는 합리적인 Baseline System을 빨리 만든 뒤 실제 Error를 보고 Iteration하라는 것이다.
4. 그런데 Train과 Dev Distribution이 다르면?
현실에서는 Target Distribution의 데이터를 많이 구하기 어려운 경우가 많다.
Train
= 인터넷의 고품질 Speech 100만 건
Dev/Test
= 실제 콜센터 녹음 10,000건Train Error는 2%, Dev Error는 10%라고 하자.
이전 사고방식이라면 Variance가 8%라고 생각할 수 있다.
하지만 정말 Overfitting일까?
아니면 콜센터 음질과 인터넷 음질 차이 때문일까?
5. Train-dev Set이 등장한다
Training Distribution에서 데이터를 조금 떼어내되, 실제 Training에는 사용하지 않는 Set을 하나 만든다.
Training Distribution에서 왔지만 Training에는 쓰지 않은 데이터
이제 다음 결과가 나왔다고 하자.
| Dataset | Error |
|---|---|
| Human / Approx. Bayes | 1% |
| Train | 2% |
| Train-dev | 3% |
| Dev | 10% |
이제 원인을 분리할 수 있다.
Avoidable Bias ≈ 1%
``` Train → Train-dev
Variance ≈ 1%
Train-dev → Dev
Data Mismatch ≈ 7% ```
가장 큰 문제는 Regularization이 아니라 Data Distribution Mismatch다.
6. Data Mismatch는 어떻게 해결할까?
가장 먼저 할 일은 역시 Error Analysis다.
Train-dev와 Dev의 실패 Example을 비교해 Target Distribution에서만 나타나는 특징을 찾는다.
Train:
깨끗한 음성
Dev:
콜센터 배경 소음
전화망 Compression
여러 사람이 동시에 말함그러면:
1. Target Distribution Data를 더 수집하거나
2. Training Data에
실제 환경과 비슷한 Noise를 추가하거나
3. Synthetic Data / Augmentation으로
Distribution Gap을 줄이는 방법을 검토할 수 있다.
7. Transfer Learning
모든 것을 처음부터 학습할 필요는 없다.
Task A에서 많은 데이터로 학습한 Representation을 데이터가 적은 Task B에 재사용할 수 있다.
Transfer Learning이 특히 유리하려면:
Task A에는 훨씬 많은 데이터가 있으며,
Task A에서 학습한 Feature가 Task B에도 유용해야 한다.
8. Multi-task Learning
Transfer Learning이:
이라면 Multi-task Learning은 여러 Task를 동시에 학습한다.
자율주행 이미지 하나
→ 보행자 존재?
→ 자동차 존재?
→ 신호등 존재?
→ 표지판 존재?서로 관련된 Task가 같은 Representation을 공유하며 함께 학습될 수 있다.
| Transfer Learning | Multi-task Learning |
|---|---|
| A에서 학습 후 B로 이동 | A/B/C를 동시에 학습 |
| Task B 데이터가 적을 때 유용 | 관련 Task가 Representation을 공유할 때 유용 |
9. End-to-end Deep Learning
전통적인 시스템은 여러 단계로 나뉜다.
Audio
↓
Feature Extraction
↓
Phoneme
↓
Word
↓
TranscriptEnd-to-end Learning은 중간 단계를 사람이 명시적으로 설계하지 않고:
로 직접 학습하는 접근이다.
10. End-to-end가 항상 더 좋은가?
아니다.
데이터가 충분하면 모델이 더 적합한 Representation을 직접 학습할 수 있다.
중간 단계의 구조와 Domain Knowledge를 활용하기 어려울 수 있다.
그런데 Enterprise AI에서는 End-to-end가 더 복잡하다
예를 들어 금융 문서 QA를 하나의 거대한 Model에게 모두 맡긴다고 해보자.
↓
Giant Model
↓
Answer
기능적으로는 매력적일 수 있다. 하지만 Enterprise에서는 중간 단계를 없애면 안 되는 경우가 있다.
Authentication
↓
Authorization
↓
Eligibility Filter
↓
Retrieval
↓
Reranking
↓
Generation
↓
Audit특히 Authorization을 “End-to-end Model이 알아서 판단하도록” 없애는 것은 단순한 Architecture Simplification 문제가 아니다.
권한 없는 데이터가 LLM Context에 들어간 순간 이미 데이터 접근이 발생했다.
권한 없는 데이터는 Retrieval 또는 Tool Execution 이전 단계에서 제외되어야 한다.
Course 3를 2026년 AI Engineering으로 번역하면
| Course 3 개념 | 현대 AI Engineering |
|---|---|
| Single Metric | Evaluation Scorecard · Model Selection Gate |
| Satisficing Metric | Latency · Cost · Safety Threshold · Compliance Gate |
| Error Analysis | RAG Failure Taxonomy · LLM Eval Slice Analysis |
| Data Mismatch | PoC Dataset ↔ Production Query Distribution |
| Transfer Learning | Foundation Model → Domain Fine-tuning |
| Multi-task | Shared Model for Multiple Related Tasks |
| End-to-end | Monolithic Agent vs Explicit Workflow |
RAG 프로젝트에 Course 3를 그대로 적용해보자
RAG 정확도가 72점에서 더 이상 오르지 않는다고 하자.
많은 팀이 바로 이런 실험을 시작한다.
Embedding Model 바꾸기
Chunk Size 바꾸기
Top-K 바꾸기
LLM 바꾸기
Reranker 바꾸기
Prompt 바꾸기하지만 Course 3 방식은 먼저 Error를 분해한다.
| 실패 유형 | 비중 | 먼저 볼 Layer |
|---|---|---|
| 정답 문서 자체가 없음 | 22% | Ingestion / Coverage |
| 문서는 있지만 Retrieval 실패 | 31% | Search / Retrieval |
| Top-K 안에 있으나 순위 낮음 | 18% | Reranking |
| Context는 맞는데 답변 실패 | 15% | Generation / Prompt |
| Evaluation Label 오류 | 6% | Eval Dataset |
이제 “LLM을 GPT-X에서 Y로 바꾸자”가 첫 번째 실험이 아니라는 사실이 보인다.
Production AI 팀이 가져가면 좋은 운영 Loop
Course 3 핵심 치트시트
MODEL QUALITY가 부족하다
│
▼
무엇을 "좋다"고 정의했는가?
Metric / Dev Distribution 확인
│
▼
Avoidable Bias?
Human/Bayes ↔ Train
│
├─ 크다 → Model Capacity / Optimization
│
▼
Variance?
Train ↔ Train-dev
│
├─ 크다 → More Data / Regularization
│
▼
Data Mismatch?
Train-dev ↔ Dev
│
├─ 크다 → Target Data / Augmentation
│
▼
Error Analysis
│
▼
가장 큰 Failure Category부터 해결실무에서 자주 보이는 잘못된 접근
High Bias 문제라면 데이터 증가가 가장 효율적인 처방이 아닐 수 있다.
Latency, Safety, Cost 같은 Satisficing Constraint를 만족하지 못하면 Production 후보가 아니다.
8%라는 숫자는 조치를 알려주지 않는다. 어떤 Failure Category가 8%를 만들고 있는지 봐야 한다.
PoC와 Production Query/Data Distribution이 다르면 같은 모델도 전혀 다른 성능을 낼 수 있다.
14문제로 Course 3 이해도 체크
- Orthogonalization이 ML 프로젝트에서 중요한 이유는 무엇인가?
- 여러 Metric 대신 Single-number Metric을 만들면 어떤 장점이 있는가?
- Optimizing Metric과 Satisficing Metric은 어떻게 다른가?
- Dev/Test Distribution은 왜 실제 Target Environment를 반영해야 하는가?
- Human-level Performance를 Bias 진단에 사용할 수 있는 이유는?
- Avoidable Bias와 일반적인 Training Error는 어떻게 다른가?
- Error Analysis에서 Dev Error Example을 직접 보는 이유는?
- Label Error가 있다고 Training Data 전체를 무조건 다시 검수하면 안 되는 이유는?
- 왜 첫 Baseline System을 빠르게 만드는 것이 도움이 되는가?
- Train-dev Set은 무엇이고 왜 필요한가?
- Train → Train-dev Gap과 Train-dev → Dev Gap은 각각 무엇을 의미하는가?
- Transfer Learning과 Multi-task Learning의 차이는?
- End-to-end Learning이 유리하려면 보통 무엇이 많이 필요한가?
- Enterprise AI에서 End-to-end Architecture를 무조건 단순화하면 안 되는 이유는?
Course 3를 한 문장으로
Human / Train / Dev Gap으로 문제를 진단한다.
Error Analysis로 실제 Failure를 분류한다.
Train-dev로 Variance와 Data Mismatch를 분리한다.
Transfer / Multi-task / End-to-end를 데이터 조건에 맞게 선택한다.
그리고 가장 큰 Error Source에 Engineering Time을 먼저 투자한다.
Course 3에는 복잡한 미분식도, 새로운 Optimizer도 거의 등장하지 않는다.
그런데 실제 프로젝트에서는 오히려 이런 판단이 더 어렵다.
Model Architecture를 개선하는 데 한 달을 썼는데 실제 Error의 대부분이 Label Quality나 Data Mismatch에서 왔다면 그 한 달은 거의 낭비될 수 있다.
다음에 해야 할 가장 가치 있는 실험을 고를 수 있는 사람이다.
References
- DeepLearning.AI — Deep Learning Specialization
- Coursera — Structuring Machine Learning Projects
- Week 1 — ML Strategy
- Week 2 — ML Strategy
※ 현재 공식 Course 3의 2개 Module과 강의 주제를 기준으로 재구성한 학습용 Deep Dive다. 강의 Transcript를 옮긴 것이 아니라 주요 ML Strategy 개념을 직관, 숫자 예제, RAG 및 금융/Enterprise AI Engineering 사례와 연결해 설명했다.