21. What — 소프트웨어 테스팅 vs ML 테스팅의 근본적 차이
3- 전통 소프트웨어: 입력 → 로직(코드) → 출력이 명세(spec)로 확정됨
4 - 예: add(2, 3) → 반드시 5 반환. 틀리면 버그
5- ML 모델: 입력 → 학습된 가중치 → 출력이 확률적이고 "정답"이 모호함
6 - 예: 흉부 X-ray → 폐렴 확률 0.73. 이것이 맞는 건가, 틀린 건가?
7- 핵심 구분표:
8 - 전통 SW — 결정적(deterministic), 유한한 경계 조건, 코드 리뷰로 검증 가능
9 - ML 시스템 — 확률적(stochastic), 무한한 입력 공간, 데이터+모델+코드 모두 검증 필요
102. Why — ML 테스팅이 본질적으로 더 어려운 3가지 이유
11이유 ①: 입력 공간이 사실상 무한차원
12- 224×224 RGB 이미지 하나의 입력 공간: 256^{224 \times 224 \times 3} \approx 10^{360000}
13- 전통 SW의 "테스트 커버리지 100%"라는 개념이 ML에는 적용 불가능
14- 비유: 전통 SW 테스팅은 "방 안의 스위치를 모두 눌러보기", ML 테스팅은 "우주의 모든 별을 방문하기" (Braiek & Khomh, 2020)
15이유 ②: 학습 데이터 \neq 실세계
16- 모델이 훈련셋에서 정확도 99%여도, 실세계 배포 시 처참히 실패하는 사례:
17 - 의료 진단: 특정 병원 장비로 찍은 X-ray에만 최적화 → 다른 병원에서 오진 (Zech et al., 2018)
18 - 추천 시스템: 인기 있는 콘텐츠만 추천 → 편향 증폭(filter bubble) → 다양성 파괴 (Beutel et al., 2019)
19 - 자율주행: 맑은 날 학습 → 비 오는 날 보행자 미인식
20- 이 문제를 분포 이동(distribution shift)이라 하며, 전통 SW에는 존재하지 않는 ML 고유 실패 모드
21이유 ③: 오라클 문제(Oracle Problem)
22- 전통 SW: 명세서가 곧 오라클 — 기대 출력이 정확히 정의됨
23- ML: "이 사진에 고양이가 있는가?"의 정답은 인간 라벨러마다 다를 수 있음
24- 테스트 자체의 정답을 만드는 것이 이미 비용이고 불확실성 (Barr et al., 2015)
253. How — 그래서 ML 테스팅은 무엇이 달라져야 하는가
26- 전통 단위 테스트(unit test)만으로는 부족 → 다층 테스팅 전략 필요:
27 - 데이터 검증: 입력 분포가 훈련 분포와 일치하는가?
28 - 모델 행동 테스트: 특정 속성 변경 시 예측이 합리적으로 변하는가? (invariance test)
29 - 슬라이스 테스트: 하위 그룹별(성별, 연령, 지역) 성능 편차가 수용 범위 내인가?
30 - 스트레스 테스트: 적대적 입력(adversarial examples)에 얼마나 견고한가?
31- 이 레슨의 핵심 질문: "배포 전 모델을 어떻게 체계적으로 믿을 수 있게 만드는가?"
32- 답은 단일 메트릭이 아닌, 테스트 체크리스트(verification gate)를 통과하는 프로세스
334. 실제 비유 — 자동차 검사 vs ML 검사
34- 전통 SW = 공장 출고 검사: 브레이크 작동? ✓ 엔진 정상? ✓ → 합격
35- ML 시스템 = "이 차가 모든 도로, 모든 날씨, 모든 운전자에게 안전한가?" → 완전한 검증 불가능
36- 따라서 ML 테스팅의 목표는 "버그 없음 증명"이 아니라 "위험을 수용 가능한 수준으로 낮추기" (Amershi et al., 2019)