개념
LLM만 AI가 아니다
이 모듈의 앞선 레슨들은 대부분 LLM을 다뤘다. 환각, RAG, 프롬프트, 비결정성. 그런데 실무에서 QA가 만나는 AI 기능은 그것만이 아니다.
- 이상 거래를 잡아내는 분류 모델
- 배송 시간을 예측하는 회귀 모델
- 상품을 골라주는 추천 시스템
- 사진에서 문서를 읽는 OCR·비전 모델
- 이탈할 고객을 예측하는 이탈 예측 모델
이런 시스템에는 프롬프트가 없다. 대신 학습 데이터와 지표 가 있다. 그리고 "이 모델이 잘 동작하는가"를 판단하려면 LLM 평가와는 다른 언어가 필요하다.
국제 자격증 체계도 이 둘을 나눈다 — 생성형 AI를 다루는 CT-GenAI와 별개로, ISTQB CT-AI(AI Testing) 가 머신러닝 시스템 전반의 테스팅을 다룬다. 이 레슨은 그 핵심을 QA 관점으로 옮긴 것이다.
AI 시스템의 품질 특성 — 전통 소프트웨어에 없던 것들
모듈 25(레슨 2)에서 ISO/IEC 25010의 여덟 가지 품질 특성을 배웠다. AI 기반 시스템에는 거기에 없는 특성이 더해진다.
| 특성 | 무엇인가 | 테스트 관점의 질문 |
|---|---|---|
| 유연성·적응성 | 환경이 바뀌어도 동작하는가 | 학습 때와 다른 분포의 입력이 오면? |
| 자율성 | 사람 개입 없이 얼마나 오래 도는가 | 어디서 사람에게 넘겨야 하는가 |
| 진화(evolution) | 재학습으로 계속 바뀐다 | 어제 통과한 케이스가 오늘도 통과하는가 |
| 편향 | 특정 집단에 불리하지 않은가 | 레슨 4에서 다룬 그것 |
| 윤리 | 사회적 규범에 맞는가 | 허용 가능한 실패는 무엇인가 |
| 부작용·보상 해킹 | 목표는 달성하는데 엉뚱한 방식으로 | 지표를 만족시키려 편법을 쓰지 않는가 |
| 투명성·해석가능성·설명가능성 | 왜 그렇게 판단했는지 알 수 있는가 | 거절 사유를 사용자에게 설명할 수 있는가 |
| 비결정성 | 같은 입력에 다른 출력 | 레슨 5에서 다룬 그것 |
'진화'가 QA에게 가장 실무적인 항목이다. 전통 소프트웨어는 우리가 코드를 바꾸지 않으면 그대로다. 그런데 모델은 재학습될 때마다 동작이 바뀐다. 코드 변경 없이 회귀가 발생하는 셈이라, "배포 전 테스트"만으로는 부족하고 모델 버전마다 회귀 세트를 다시 돌려야 한다.
'보상 해킹'도 흥미롭다. 추천 시스템의 목표를 클릭률로 잡으면, 모델은 자극적인 썸네일을 추천하는 방향으로 최적화된다. 지표는 올라가는데 서비스 품질은 나빠진다. 지표를 목표로 삼으면 그 지표만 최적화된다 는 문제의 AI 버전이고, 모듈 25(레슨 3)에서 인증에 대해 한 이야기와 구조가 같다.
데이터가 먼저다 — 그리고 함정 세 개
모듈 18b(레슨 7·8)에서 학습데이터 품질을 다뤘다. 여기서는 테스트 관점에서 반드시 확인할 세 가지 만 짚는다.
1) 데이터 분할 — 학습(train) / 검증(validation) / 테스트(test)
전체 데이터
├─ 학습셋 모델이 배우는 데이터
├─ 검증셋 학습 중 하이퍼파라미터를 고르는 데 쓰는 데이터
└─ 테스트셋 최종 성능을 재는 데이터 — 학습에 절대 쓰이면 안 된다2) 데이터 누출(leakage) — 테스트셋 정보가 학습에 새어 들어간 상태다. 그러면 성능 지표가 실제보다 좋게 나오고, 배포 후에 무너진다.
흔한 누출 경로들이다.
| 경로 | 예 |
|---|---|
| 중복 레코드 | 같은 데이터가 학습셋과 테스트셋에 모두 있음 |
| 시간 누출 | 미래 데이터로 학습해 과거를 예측 |
| 파생 변수 | 정답에서 계산된 컬럼이 입력에 포함 |
| 전처리 순서 | 분할 전에 전체 데이터로 정규화 |
QA가 물어야 할 질문은 하나다 — "테스트셋은 학습 과정 어디에도 쓰이지 않았습니까?" 이 질문에 명확히 답하지 못하면 지표는 신뢰할 수 없다.
3) 과적합(overfitting)과 과소적합(underfitting)
| 학습셋 성능 | 테스트셋 성능 | 의미 | |
|---|---|---|---|
| 과적합 | 매우 높음 | 낮음 | 외웠다. 새 데이터에 못 쓴다 |
| 과소적합 | 낮음 | 낮음 | 아직 못 배웠다 |
| 적절 | 높음 | 높음 |
두 숫자의 격차 를 보는 것이 요령이다. 학습 99%, 테스트 71%라면 과적합 신호다. 이건 "모델 잘 나왔습니다"라는 보고를 받았을 때 QA가 던질 첫 질문이 된다 — "학습셋과 테스트셋 성능이 각각 얼마입니까?"
혼동 행렬 — 모든 분류 지표의 출발점
분류 모델의 평가는 전부 여기서 나온다.
실제 정답
양성(P) 음성(N)
┌──────────────┬──────────────┐
예측 양성 │ TP │ FP │
│ 진짜 양성 │ 거짓 양성 │ ← 오탐
├──────────────┼──────────────┤
음성 │ FN │ TN │
│ 거짓 음성 │ 진짜 음성 │
│ ← 놓침 │ │
└──────────────┴──────────────┘QA에게 익숙한 언어로 옮기면 이렇다.
- FP(거짓 양성) = 오탐. 아닌 것을 맞다고 함
- FN(거짓 음성) = 놓침. 맞는 것을 아니라고 함
모듈 14(레슨 5)에서 다룬 false alarm 이 FP이고, 결함 탈출이 FN이다. 개념이 그대로 대응한다.
정확도가 함정인 이유
가장 먼저 배우는 지표가 정확도(Accuracy) 다.
정확도 = (TP + TN) / 전체직관적이고, 그래서 위험하다. 예를 들어보자.
이상 거래 탐지 모델. 전체 거래 100만 건 중 실제 이상 거래는 1,000건 (0.1%). "전부 정상"이라고만 답하는 모델의 정확도는 99.9%다.
이 모델은 이상 거래를 하나도 못 잡는데 정확도가 거의 만점이다. 불균형 데이터에서 정확도는 아무것도 말해주지 않는다.
QA가 정확도 숫자를 받으면 반드시 물어야 할 것 — "양성 클래스의 비율이 얼마입니까?" 5% 아래면 정확도는 무시하고 다른 지표를 봐야 한다.
정밀도와 재현율 — 무엇을 지킬 것인가
정밀도(Precision) = TP / (TP + FP)
"양성이라고 한 것 중 진짜는 몇 %인가" → 오탐을 줄이는 지표
재현율(Recall) = TP / (TP + FN)
"진짜 양성 중 몇 %를 찾아냈나" → 놓침을 줄이는 지표
F1 = 2 × (정밀도 × 재현율) / (정밀도 + 재현율)
두 지표의 조화평균 — 한쪽만 높으면 F1도 낮다이 둘은 대개 서로를 밀어낸다. 판정 임계값을 낮추면 더 많이 양성으로 분류하니 재현율이 오르고 정밀도가 떨어진다. 높이면 반대다.
그래서 진짜 질문은 "어느 쪽이 더 높은가"가 아니라 "우리 도메인에서 무엇이 더 비싼 실수인가" 다.
| 도메인 | 더 비싼 실수 | 우선할 지표 |
|---|---|---|
| 암 진단 보조 | 놓침(FN) — 환자가 치료를 못 받는다 | 재현율 |
| 스팸 필터 | 오탐(FP) — 중요한 메일이 사라진다 | 정밀도 |
| 이상 거래 탐지 | 상황에 따라 — 놓치면 손실, 오탐하면 정상 거래 차단 | 균형(F1) + 운영 부담 고려 |
| 채용 서류 1차 선별 | 놓침 — 좋은 지원자를 거른다 | 재현율 + 편향 검증 필수 |
| 콘텐츠 유해성 필터 | 도메인 정책이 결정 | 정책과 함께 정의 |
이 판단은 데이터 과학자가 아니라 제품·도메인이 해야 한다. 그리고 그 논의를 회의 테이블에 올리는 것이 QA의 일이다. 지표를 고르는 것은 기술 결정이 아니라 제품 결정 이기 때문이다.
지표 하나만 더 짚자. ROC 곡선과 AUC 는 임계값을 바꿔가며 성능을 본 것이다. AUC가 높다는 것은 "임계값을 잘 고르면 좋은 성능을 낼 수 있다"는 뜻이지, 지금 설정으로 잘 동작한다는 뜻이 아니다. 실제 운영 임계값에서의 정밀도·재현율을 따로 확인해야 한다.
회귀 모델의 지표
값을 예측하는 모델(배송 시간, 가격, 수요)에는 다른 지표를 쓴다.
| 지표 | 성격 | 특징 |
|---|---|---|
| MAE (평균 절대 오차) | 평균적으로 얼마나 틀리나 | 해석이 쉽다 |
| RMSE (제곱근 평균 제곱 오차) | 큰 오차에 더 민감 | 큰 실수를 잡아낸다 |
| MAPE (평균 절대 백분율 오차) | 비율로 본다 | 실제값이 0에 가까우면 폭발 |
| R² | 설명력 | 단독으로 보면 오해하기 쉽다 |
QA 관점의 요령: 평균 지표만 보지 말고 오차 분포와 최악의 경우 를 본다. MAE가 5분이어도 특정 조건에서 3시간씩 틀린다면 그게 사용자 불만의 원인이다. 모듈 14(레슨 7)에서 평균 대신 p95를 보라고 한 것과 같은 논리다.
신경망과 테스팅
딥러닝 모델은 내부가 사실상 블랙박스다. 그래도 테스트 관점에서 알아둘 개념이 둘 있다.
1) 뉴런 커버리지 계열
전통 소프트웨어의 구문·분기 커버리지(모듈 3 레슨 7)를 신경망에 옮긴 개념이다. "테스트 입력이 신경망의 뉴런을 얼마나 활성화시켰는가"를 잰다.
다만 한계가 분명하다. 커버리지가 높다고 모델이 옳다는 보장이 없고, 연구 단계의 논쟁도 있다. 실무에서는 참고 지표 정도로 다루는 것이 안전하다.
2) 적대적 예제(adversarial example)
사람 눈에는 거의 차이가 없는데 모델이 완전히 다르게 판단하는 입력이다. 이미지에 미세한 잡음을 더하면 판다를 긴팔원숭이로 분류하는 식이다.
QA에게 이건 보안 테스트의 AI 버전 이다. 모듈 16(레슨 5)의 입력 검증 사고를 확장해서 — "악의적으로 조작된 입력에 이 모델이 어떻게 반응하는가" 를 묻는다. 얼굴 인식, 문서 위변조 판별, 유해 콘텐츠 필터처럼 속이려는 동기가 있는 영역에서 필수다.
AI 특유의 테스트 기법
기대 결과를 정확히 알 수 없는 시스템을 어떻게 테스트하는가. 모듈 18b (레슨 1)에서 던진 문제다. ML 영역에서 쓰이는 기법 네 가지를 정리한다.
1) 메타모픽 테스팅(Metamorphic Testing)
정답을 모르더라도 입력을 바꿨을 때 출력이 어떻게 변해야 하는지 는 알 수 있다는 발상이다.
검색 모델: "노트북" → 결과 A
"노트북 " (공백 추가) → 결과가 A와 같아야 한다
이미지 분류: 원본 사진 → "고양이"
좌우 반전한 사진 → 여전히 "고양이"여야 한다
가격 예측: 면적 30평 → 예측가 X
면적 40평 (다른 조건 동일) → X보다 높아야 한다이게 강력한 이유는 정답 레이블 없이도 결함을 잡아내기 때문이다. 그리고 QA가 도메인 지식으로 관계를 정의할 수 있다 — 데이터 과학자보다 QA가 더 잘하는 일일 수 있다.
2) 백투백(Back-to-Back) 테스팅
같은 입력을 기존 모델과 새 모델 에 넣어 결과를 비교한다. 모듈 4 (레슨 6)에서 배운 이중 실행 비교와 완전히 같은 구조다. 모델 교체 시 어떤 케이스에서 판단이 뒤집혔는지 를 목록으로 만들 수 있다.
3) 적대적 테스팅
앞에서 본 적대적 예제를 의도적으로 만들어 넣는다.
4) A/B 테스트
실제 트래픽을 나눠 두 모델의 성능을 비교한다. 오프라인 지표와 실제 사용자 행동이 다를 수 있으므로, 최종 검증은 여기서 이뤄지는 경우가 많다.
테스트 환경이 다르다
ML 시스템의 테스트 환경에는 전통 소프트웨어에 없는 요소가 있다.
- 데이터 파이프라인 — 모델만이 아니라 데이터 수집·전처리 과정도 테스트 대상이다. 모듈 18b(레슨 8)의 검증 파이프라인이 여기에 붙는다
- 하드웨어 의존성 — GPU 유무, 버전에 따라 결과가 미세하게 달라질 수 있다
- 모델 버전 관리 — 어떤 데이터로 언제 학습한 모델인지 추적 가능해야 한다
- 재현성 — 같은 데이터·같은 설정으로 다시 학습하면 같은 모델이 나오는가 (난수 시드 고정 여부)
마지막 항목이 QA에게 중요하다. 재현이 안 되면 "이 결함이 모델 때문인지 학습 과정의 우연 때문인지"를 가릴 수 없다.
그래서 QA가 물어야 할 질문 목록
이 레슨의 내용을 실무 질문으로 압축하면 이렇다. AI 기능의 검증을 맡았을 때 이 순서로 물으면 된다.
- 이 모델이 하는 일은 분류인가 회귀인가 생성인가?
- 양성 클래스의 비율 은? (정확도를 믿어도 되는가)
- 학습셋과 테스트셋 성능 이 각각 얼마인가? (과적합 여부)
- 테스트셋이 학습에 쓰이지 않았음 을 어떻게 보장하는가?
- 우리 도메인에서 더 비싼 실수 는 FP인가 FN인가?
- 지금 운영 임계값 에서의 정밀도·재현율은?
- 이 모델이 재학습되면 무엇을 다시 테스트하는가?
- 실패했을 때 사람에게 넘기는 경로 가 있는가?
- 조작된 입력에 대한 대응은?
- 오프라인 지표와 실사용 지표 를 어떻게 대조하는가?
실무에서 왜 필요한가
AI 기능을 만드는 팀에서 QA가 지표 언어를 모르면 대화에 참여할 수 없다. "F1이 0.87 나왔습니다"라는 보고에 고개만 끄덕이게 되고, 그 숫자가 우리 서비스에 충분한지 판단할 수 없다.
반대로 이 레슨의 질문 목록을 던질 수 있으면 위치가 달라진다. 특히 5번(무엇이 더 비싼 실수인가) 은 데이터 과학자가 혼자 정할 수 없는 질문이고, 제품·도메인 관점에서 답해야 한다. 그 논의를 여는 사람이 QA인 경우가 많다.
그리고 '진화' 특성 때문에 QA의 일이 구조적으로 늘어난다. 모델은 재학습될 때마다 바뀌므로, 회귀 세트를 만들고 모델 버전마다 돌리는 체계가 필요하다. 이건 모듈 11에서 배운 회귀 자동화의 대상이 코드에서 모델로 확장되는 것이다.