1-1. AI 품질의 개요¶
AI 품질은 기능 동작 여부만으로 판단할 수 없습니다. AI 시스템의 결과는 코드뿐 아니라 데이터 상태, 모델 출력, 운영 환경의 영향을 함께 받습니다.
1-1에서는 기존 Software QA와 AI Software QA의 차이를 먼저 이해합니다. 핵심은 API가 정상적으로 응답하더라도, 입력 데이터와 모델 출력이 품질 기준을 충족하는지는 별도로 검증해야 한다는 점입니다.
이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.
- 기존 Software QA: 정해진 입력과 기대 출력의 일치 여부 확인
- AI Software QA: 데이터 상태, 모델 출력, 운영 로그를 함께 보는 품질 확인
- Software 2.0: 판단 규칙의 일부가 코드 밖의 데이터와 모델 산출물(model artifact)에 위치
- 데이터/모델/운영 품질 연결: 데이터, 모델, API, 운영 로그가 같은 상태를 설명하는지 확인
1-1-1. 기능 정상과 AI 품질 판단의 차이¶
AI 시스템에서는 기능이 정상이어도 품질 판단이 끝나지 않습니다. 일반적인 웹 API라면 상태 코드(status code)가 200이고 응답 스키마(schema)가 맞을 때 기본 기능은 정상이라고 볼 수 있습니다. 그러나 AI API에서는 같은 응답 안에서도 모델 출력과 예측(prediction) 비율이 품질 기준 안에 있는지 확인해야 합니다. 예측은 모델 출력과 운영 기준을 거쳐 만들어지는 최종 분류 결과입니다.
이 운영 시나리오에서 중요한 점은 “정상 응답”과 “신뢰 가능한 AI 판단”이 서로 다른 판단이라는 것입니다. API 계약(API contract)이 맞는지 확인하는 일은 여전히 필요합니다. 다만 AI Software QA는 그 다음에 입력 특성(feature) 분포가 평소와 다른지, 라벨 기준이 일관되는지, 모델 출력이 달라졌는지를 이어서 확인합니다. 특성은 모델 입력으로 쓰는 값이고, 라벨은 평가에서 정답으로 보는 값입니다.
| 관측된 현상 | 기능 테스트에서 보기 쉬운 해석 | AI 품질에서 추가로 확인할 항목 |
|---|---|---|
| HTTP status 200 유지 | API 기능 정상 | 입력 데이터와 예측 비율이 기준 범위 안에 있는가 |
| 오류율(error rate) 증가 | 기능 테스트만으로는 놓치기 쉬움 | 값의 범위 오류나 입력 계약 실패가 있는가 |
| 코드 변경 없음 | 회귀 가능성 낮음 | 데이터 수집 방식, 라벨 기준, 모델 산출물이 바뀌지 않았는가 |
high_risk 비율 증가 |
기능 요구사항 밖의 현상 | 오탐 증가인지, 실제 입력 변화인지, 설정 변경인지 구분했는가 |
이 표는 기능 테스트가 불필요하다는 뜻이 아닙니다. 기능 테스트는 AI 서비스 품질 확인의 출발점입니다. 다만 AI 서비스에서는 기능 정상 이후에도 데이터, 모델 출력, 운영 신호를 확인해야 품질 판단이 완성됩니다.
공개 프레임워크 관점에서도 이 확장은 중요합니다. NIST AI RMF 1.0은 AI 시스템을 만드는 조직이 위험을 관리하고 신뢰 가능한 AI 사용을 촉진할 수 있도록 위험 관리 관점을 제시합니다. 이 자료는 AI 품질을 기능 테스트보다 넓은 위험 관리와 신뢰성 관점에서 바라보아야 하는 배경으로 연결됩니다.
이 절에서 가져갈 판단 기준은 명확합니다. “기능이 정상인가”와 “AI 품질을 신뢰할 수 있는가”는 같은 질문이 아닙니다. API가 정상 응답을 반환해도 입력 특성, 라벨, 모델 출력, 예측 변화가 함께 설명되지 않으면 AI 품질을 충분히 판단했다고 보기 어렵습니다.
1-1-2. AI Software QA에서 확인 범위가 넓어지는 이유¶
AI Software QA는 기존 Software QA를 버리는 것이 아니라, 확인 범위를 데이터 조건과 모델 출력과 운영 추적 정보까지 확장하는 활동입니다. 기존 Software QA에서는 요구사항과 구현 결과의 일치 여부를 중심으로 확인합니다. 입력값이 올바른지, 예외 처리가 동작하는지, 기존 기능이 깨지지 않았는지 확인하는 방식입니다.
AI 시스템에서도 이 기본 확인은 그대로 필요합니다. 요청 스키마가 깨졌거나, 필수값이 누락되었거나, API가 오류를 반환한다면 AI 품질 이전에 서비스 기능 문제가 됩니다. 그러나 AI API는 형식상 정상인 입력을 받아도 품질 문제가 발생할 수 있습니다. 예를 들어 심박수(heart rate)를 담는 heart_rate가 숫자로 들어왔더라도 값의 범위가 비정상적이거나, 특정 시간대에만 같은 값이 반복된다면 모델 출력이 왜곡될 수 있습니다.
출력 확인도 넓어집니다. 일반 API에서는 응답 코드와 응답 본문 스키마를 확인하면 기본 검증이 끝나는 경우가 많습니다. AI API에서는 여기에 모델 출력과 예측, 모델 버전(model_version)을 함께 확인해야 합니다. 모델 버전이 바뀌면 같은 요청이라도 다른 출력이 나올 수 있고, 운영 기준이 바뀌면 같은 출력도 다른 예측으로 이어질 수 있습니다.
AI Software QA의 확인 흐름은 다음처럼 확장됩니다. 이 표는 모든 장의 세부 내용을 한 번에 설명하려는 표가 아니라, 기존 Software QA에서 보던 항목이 AI Software QA에서 어디까지 넓어지는지 보여주는 지도입니다.
| 확인 흐름 | 기본 확인 (기존 SW QA) | 추가되는 확인 (AI SW QA) |
|---|---|---|
| 입력 확인 | 필수값, 형식, 권한, 입력 계약 위반 | 특성 범위, 결측치, 입력 분포 |
| 출력 확인 | 기대 출력, 응답 스키마, 상태 코드 | 점수, 임계값, 예측, 모델 버전 |
| 회귀 확인 | 기능 변경 후 기존 기능 유지, 배포 버전과 설정 변경 영향 | 데이터셋, 라벨 기준, 모델 버전과 임계값 영향 |
| 로그 확인 | 오류 원인, 예외 처리, 요청 ID, 응답 시간, 오류율 | 요청 ID별 모델 버전, 점수, 임계값, 예측 추적 |
| 운영 확인 | 서비스 실행 상태, 트래픽, 응답 시간, 오류율, 대시보드 | 입력 분포, 점수 분포, 예측 분포 |
이 표에서 중요한 점은 확인 항목이 늘어난다는 사실 자체가 아닙니다. 입력, 출력, 회귀, 로그, 운영 확인이 각각 데이터 조건과 모델 출력과 운영 추적 정보로 이어진다는 점입니다. 따라서 QA 담당자 및 AI 서비스 품질/운영에 관심 있는 실무자는 모델을 직접 개발하지 않더라도, 변화가 어느 기록에 남고 어떤 판단을 바꾸는지 읽을 수 있어야 합니다.
이 절의 판단 기준은 확인 범위의 확장입니다. 기능 동작 확인은 출발점이고, AI Software QA에서는 그 위에 데이터 조건, 모델 출력, 운영 추적 가능성을 함께 올려야 합니다. 다음 절에서는 왜 이 확인 범위가 코드 밖의 데이터와 모델 산출물까지 넓어지는지 살펴봅니다.
1-1-3. Software 1.0과 Software 2.0의 차이¶
Software 2.0에서는 판단 규칙의 일부가 코드가 아니라 데이터와 모델 산출물 안에 들어갑니다. 이 차이를 이해하면 AI Software QA가 왜 코드 실행 결과만 볼 수 없는지 더 분명해집니다. 먼저 사람이 직접 규칙을 작성하는 Software 1.0 방식부터 보겠습니다.
규칙 기반 시스템은 판단 기준이 코드 안에 직접 표현됩니다. 예를 들어 체온 값이 일정 기준보다 높으면 알림을 발생시키는 규칙은 코드 안에 직접 표현할 수 있습니다.
temperature: float = 38.5
if temperature > 38.0:
alert: bool = True
else:
alert = False
이 방식에서는 판단 기준이 코드에 명확히 들어 있습니다. QA는 경계값, 예외 입력, 기대 결과를 기준으로 기능이 맞게 동작하는지 확인할 수 있습니다. 규칙이 어디에 있는지 비교적 명확하기 때문에 테스트 케이스도 코드와 요구사항을 중심으로 설계할 수 있습니다.
AI 시스템에서는 사람이 모든 규칙을 직접 작성하지 않습니다. 심박수(heart rate), 산소포화도(oxygen saturation), 혈압(blood pressure) 같은 여러 특성과 라벨을 사용하여 모델이 Positive class와 Negative class를 구분하는 기준을 학습합니다. 특성은 모델 입력으로 쓰는 값이고, 라벨은 평가에서 정답으로 보는 값입니다. Positive class는 관심 있게 찾으려는 클래스(class)이고, Negative class는 그 비교 기준이 되는 클래스입니다. 이때 판단 기준의 일부는 모델 파라미터(parameter) 안에 압축되고, 그 파라미터(parameter)는 데이터로부터 만들어집니다.
Software 2.0은 신경망과 데이터 기반 학습을 새로운 소프트웨어 작성 방식으로 설명하는 관점입니다. 이 글은 QA가 확인해야 할 대상이 코드에서 데이터, 모델 산출물, 설정, 운영 신호로 확장되는 이유를 설명하는 배경으로 연결됩니다.
| 구분 | Software 1.0 | Software 2.0 |
|---|---|---|
| 판단 규칙의 위치 | 사람이 작성한 코드 | 데이터로 학습된 모델 산출물 |
| 주요 확인 대상 | 조건문, 예외 처리, API 계약(API contract) | 특성, 라벨, 모델 버전, 운영 기준 |
| 품질 이상 원인 | 코드 버그, 요구사항 오해, 회귀 | 데이터 품질 저하, 분포 변화, 설정 변경 |
| QA 관점 | 입력과 기대 출력 비교 | 데이터와 모델 출력과 운영 신호 연결 |
high_risk 예측 비율 증가 운영 시나리오는 코드 분기보다 데이터, 모델, 운영 조건을 함께 봐야 합니다. 앞에서 본 사건도 이 관점으로 다시 볼 수 있습니다. 원인 확인은 코드의 if 문을 찾는 데서 끝나지 않습니다. API 코드가 그대로여도 모델을 만든 라벨 기준, 모델 파라미터(parameter), 운영 입력 분포가 달라졌다면 결과도 달라질 수 있습니다.
Software 2.0 관점의 핵심은 모델을 특별하게 보는 것이 아니라, 품질 확인 위치가 코드 밖으로 넓어진다는 점입니다. 사람이 작성한 조건문은 코드 리뷰와 경계값 테스트로 확인할 수 있지만, 데이터로 학습된 판단 기준은 어떤 데이터에서 만들어졌고 운영 요청에 어떻게 적용되는지 함께 봐야 합니다.
이 절에서 가져갈 질문은 “판단 기준이 어디에 있는가”입니다. 규칙이 코드 안에 있으면 코드와 요구사항을 중심으로 확인합니다. 규칙이 모델 산출물 안에 있으면 모델을 만든 데이터, 운영에서 들어오는 특성, 모델 출력을 예측으로 바꾸는 기준을 함께 확인해야 합니다.
1-1-4. 데이터, 모델, 운영 품질을 함께 확인하기¶
데이터, 모델, 운영 신호를 함께 봐야 AI 서비스 품질을 판단할 수 있습니다. 공통 운영 시나리오의 high_risk_prediction_shift를 증거 관점에서 다시 보겠습니다. 여기서는 기능 정상 여부를 다시 판단하기보다, 같은 사건을 어떤 자료로 나누어 확인할지 정리합니다.
같은 사건이라도 API 응답, 데이터 품질 리포트, 모델 평가 결과, 운영 대시보드(dashboard)는 서로 다른 신호를 보여줄 수 있습니다. 이때 중요한 일은 어느 해석이 맞는지 바로 고르는 것이 아니라, 각 자료가 같은 상황을 설명하는지 가볍게 맞춰 보는 것입니다.
정상처럼 보이는 기능 신호와 품질 판단 증거는 분리해야 합니다. 아래 표는 high_risk 증가 사건에서 정상처럼 보이는 신호와 추가로 확인해야 할 증거를 정리한 것입니다.
| 관측 신호 | 처음 보이는 해석 | 놓치기 쉬운 가능성 | 이후 확인할 자료 |
|---|---|---|---|
| HTTP 200 유지 | API 기능 정상 | 응답은 정상이어도 예측 비율은 달라질 수 있음 | API 응답 필드, 로그 |
| 필수 컬럼 존재 | 입력 데이터 정상 | 컬럼은 있어도 값의 범위나 분포가 달라질 수 있음 | 데이터 품질 리포트 |
| 모델 평가 결과 개선 | 모델 품질 개선 | 평가 데이터 조건이 이전과 다를 수 있음 | 2장 모델 평가 리포트 |
high_risk 0.2167 → 0.4583 |
위험 알림 증가 | 현재 배치 입력 구성, 설정 변경, 모델 버전 변경이 섞였을 수 있음 | 운영 대시보드, 배포 기록 |
| 오류율 증가 | 운영 장애 가능성 | 검증 실패와 서비스 지연이 함께 변했을 수 있음 | 로그, 주요 운영 지표 |
이 표의 목적은 담당자별 책임을 나누는 것이 아닙니다. 품질 이상이 발생했을 때 한 가지 정상 신호에 기대지 않고, 여러 자료가 같은 설명을 만드는지 확인하는 데 목적이 있습니다. 예를 들어 API는 정상 응답을 반환하지만 high_risk 비율이 크게 늘었다면, API 기능만으로는 품질 판단이 끝나지 않습니다.
증거를 대조할 때는 데이터 품질 리포트, 모델 평가 리포트, API 응답, 배포 기록, 운영 대시보드를 같은 사건의 자료로 놓고 봅니다. 1장에서는 이 정도의 관점만 잡으면 충분합니다. 모델 지표와 운영 로그를 깊게 해석하는 방법은 2장과 4장에서 더 자세히 다룹니다.
ML 시스템의 이런 의존성은 잘 알려진 운영 리스크입니다. Hidden Technical Debt in Machine Learning Systems는 ML 시스템에서 빠른 성과 뒤에 데이터 의존성, 설정 의존성, 운영 피드백 같은 장기 품질 리스크가 쌓일 수 있음을 설명합니다. 이 논문은 AI 서비스 품질을 하나의 산출물이 아니라 여러 증거의 관계로 확인해야 한다는 배경으로 연결됩니다.
따라서 QA와 운영 관점의 역할은 모든 일을 직접 수행하는 것이 아닙니다. 핵심은 확인 기준을 명확히 만들고, 데이터 품질 리포트, 모델 평가 리포트, API 응답, 배포 기록, 운영 대시보드가 서로 모순되지 않는지 확인하는 것입니다. 서로 다른 문서처럼 보이는 산출물도 실제로는 하나의 품질 상태를 설명하는 증거입니다.
이 절의 판단 기준은 증거 대조입니다. AI 서비스 품질을 확인할 때는 “어느 한 신호가 정상인가”보다 “데이터, 모델, API, 운영 로그가 같은 품질 상태를 설명하는가”를 봐야 합니다. 1-1에서는 결론보다 관점이 중요합니다. AI 품질 이상은 한 화면이나 한 숫자로 끝나지 않고, 여러 자료를 함께 놓고 읽어야 합니다.