AI 품질 관리와 검증

AI는 틀릴 수 있다. 그래서 관리해야 한다

기업이 AI를 운영에 넣는 순간, 가장 먼저 받아들여야 할 문장이 있다. "AI는 틀릴 수 있다." 그러나 이 말은 "그러니 AI를 쓰면 안 된다"는 뜻이 아니다. 오히려 반대다. AI가 틀릴 수 있음을 전제로 업무를 설계해야 한다는 뜻이다.

사람도 틀린다. 신입 직원은 규정을 잘못 이해하고, 숙련된 직원도 피로가 쌓이면 숫자를 잘못 옮긴다. 그래서 기업은 결재선, 검토표, 감사 로그, 샘플링 검사, 내부 통제 절차를 만든다. AI도 마찬가지다. AI 결과물을 믿거나 불신하는 문제가 아니라, 어떤 조건에서 믿을 수 있고 어떤 조건에서 반드시 검토해야 하는지 정하는 문제가 핵심이다.

AI 품질 관리는 단순히 답변 하나를 보고 "맞다, 틀리다"를 판단하는 일이 아니다. 도입 전 준비도 평가, 프롬프트 설계, RAG 검색 구조, 워크플로우 통제, 테스트, 배포 후 모니터링, 오류 재발 방지까지 포함하는 운영 체계다. 최근 기업용 AI 보증 논의에서도 기존 소프트웨어 테스트만으로는 AI 시스템의 편향, 성능 저하, 설명 가능성 부족 같은 문제를 충분히 다루기 어렵다고 본다.¹ 다시 말해 AI 품질 관리는 마지막에 검사하는 QA가 아니라 처음부터 품질을 설계하는 Quality Engineering에 가깝다.

이 장의 핵심은 간단하다. AI는 틀릴 수 있기 때문에 못 쓰는 것이 아니다. 틀릴 수 있음을 전제로 평가하고, 기록하고, 개선하는 회사만이 AI를 운영 자산으로 만들 수 있다.

모든 오류를 '환각'이라고 부르면 개선할 수 없다

AI가 엉뚱한 답을 하면 많은 사람이 "환각이네"라고 말한다. 환각이라는 표현은 편리하지만, 기업 운영에서는 너무 거칠다. 마치 모든 병을 "몸이 안 좋다"라고 부르는 것과 같다. 원인을 나누지 않으면 처방도 나눌 수 없다.

AI 오류는 적어도 다음처럼 분류해야 한다.

예를 들어 고객지원 AI가 "환불 가능합니다"라고 잘못 답했다고 해보자. 이것을 단순히 환각이라고 부르면 다음 조치는 "모델을 바꾸자"가 되기 쉽다. 그러나 실제 원인은 다를 수 있다. 환불 규정 문서가 오래되었을 수도 있고, 최신 규정은 슬랙 공지에만 있고 지식베이스에는 없었을 수도 있다. 고객이 "개봉했다"는 말을 했는데 AI가 이를 놓쳤을 수도 있다. 또는 프롬프트에 "고객 만족을 최우선으로 답하라"는 문장과 "환불 규정을 엄격히 준수하라"는 문장이 충돌했을 수도 있다.

원인 분류가 중요한 이유는 재발 방지책이 달라지기 때문이다. 문서가 없으면 문서를 보강해야 하고, 검색이 안 되면 RAG 구조를 고쳐야 한다. 프롬프트가 애매하면 지시문을 바꿔야 하고, 승인 절차가 없으면 워크플로우를 바꿔야 한다. AI 품질 관리는 모델을 탓하는 일이 아니라 시스템 전체를 점검하는 일이다.

정확성, 일관성, 유용성을 따로 본다

AI 산출물은 하나의 점수로 평가하기 어렵다. 답이 사실상 맞아도 고객에게 불친절할 수 있고, 문장은 매끄러운데 근거가 없을 수 있다. 보고서 형식은 훌륭하지만 회사 내부 규정을 위반할 수도 있다. 그래서 기업은 최소한 세 가지 축을 나누어 봐야 한다.

정확성은 사실, 숫자, 규정, 코드, 계약 조항 등이 맞는지를 보는 기준이다. 재무 보고서의 숫자, 법무 검토의 조항, 고객지원 답변의 정책 안내처럼 틀리면 직접적인 피해가 발생하는 영역에서는 가장 중요한 기준이 된다.

일관성은 같은 상황에서 같은 기준으로 답하는지를 보는 기준이다. 월요일에는 환불 가능하다고 하고 화요일에는 불가능하다고 답한다면, 둘 중 하나가 맞더라도 운영 품질은 낮다. 기업 업무에서는 개별 답변의 멋짐보다 반복 가능한 기준이 더 중요하다.

유용성은 실제 업무에 도움이 되는지를 보는 기준이다. AI가 길고 그럴듯한 답변을 했지만 담당자가 다시 처음부터 고쳐야 한다면 유용성이 낮다. 반대로 80% 수준의 초안이라도 담당자가 10분 안에 완성할 수 있다면 업무 가치는 크다.

여기에 기업에서는 몇 가지 기준을 더 붙여야 한다. 근거 출처가 있는가, 개인정보를 노출하지 않았는가, 저작권 문제가 없는가, 내부 규정과 톤앤매너를 지켰는가, 금지 표현을 쓰지 않았는가, 승인 없이 약속이나 보장을 하지 않았는가. 고객지원 자동 품질관리 도구들이 대량의 상담을 같은 평가 기준으로 점검하고, 낮은 신뢰도나 예외 케이스를 사람 검토로 넘기는 방식도 이와 같은 문제의식에서 출발한다.²

부서별 검수 기준표를 만든다

AI 품질 기준은 전사 공통 기준과 부서별 기준으로 나눠야 한다. 전사 공통 기준은 개인정보 보호, 보안, 저작권, 금지 표현, 근거 표시, 내부 규정 준수처럼 모든 부서에 적용되는 원칙이다. 부서별 기준은 업무의 성격에 맞춰 달라진다.

검수 기준표는 복잡할 필요가 없다. 처음에는 5점 척도보다 "통과, 수정 필요, 사용 금지"처럼 단순하게 시작하는 편이 낫다. 중요한 것은 기준을 문서로 남기고, 여러 사람이 같은 산출물을 봤을 때 비슷한 판단을 내릴 수 있게 만드는 것이다.

예를 들어 고객지원 답변 검수표는 이렇게 만들 수 있다.

법무나 재무처럼 리스크가 큰 업무는 기준을 더 엄격하게 잡아야 한다. "AI가 작성한 결과물을 사람이 검토한다"는 말만으로는 부족하다. 누가, 무엇을, 어떤 기준으로, 어디까지 검토하는지가 정해져야 한다.

평가 데이터셋은 AI 품질의 시험지다

AI 시스템을 개선하려면 시험지가 있어야 한다. 사람에게 교육을 시킨 뒤 시험을 보듯이, AI 업무 시스템도 대표 질문과 예외 상황을 모아 반복해서 테스트해야 한다. 이를 평가 데이터셋이라고 한다.

평가 데이터셋은 AI 애플리케이션이나 에이전트를 체계적으로 테스트하기 위해 만든 입력 예시와 기대 결과의 묶음이다. MLflow 같은 LLMOps 도구에서도 평가 데이터셋을 "알려진 문제 사례를 다시 테스트하고, 회귀를 방지하며, 프롬프트나 모델 버전을 비교하기 위한 기준 세트"로 설명한다.³ 쉽게 말하면 우리 회사 AI가 반드시 맞혀야 하는 문제집이다.

좋은 평가 데이터셋에는 다음 요소가 들어간다.

• 대표 질문: 실제 업무에서 자주 들어오는 일반적인 요청

• 정상 사례: AI가 무리 없이 처리해야 하는 표준 케이스

• 예외 상황: 규정상 예외, 특수 고객, 비정상 입력

• 실패하기 쉬운 질문: 과거에 AI가 틀렸거나 사람이 자주 실수한 케이스

• 금지 답변: 절대 해서는 안 되는 약속, 표현, 조언

• 모범 답안: 가장 바람직한 응답 또는 산출물

• 허용 가능한 답변 범위: 표현은 달라도 통과로 인정할 수 있는 기준

예를 들어 고객지원 챗봇의 평가 데이터셋에는 "개봉한 제품을 환불할 수 있나요?", "배송이 7일째 지연됐는데 보상되나요?", "부모님 계정의 주문 내역을 알려주세요" 같은 질문이 들어간다. 각 질문에는 정답만 넣는 것이 아니라, 어떤 조건에서 답이 달라지는지도 적어야 한다. "본인 확인 전에는 주문 내역을 제공하면 안 됨", "개봉 여부와 상품군에 따라 환불 가능 여부가 달라짐"처럼 판단 기준을 함께 넣어야 한다.

Google Vertex AI의 생성형 AI 평가 데이터셋 문서도 평가 목적에 따라 prompt, response, reference, conversation_history, intermediate_events 같은 필드를 사용한다고 설명한다.⁴ 이것은 실무적으로 매우 중요하다. 단일 질문과 답변만 모아서는 멀티턴 상담, 에이전트 도구 호출, RAG 검색 품질을 제대로 평가하기 어렵기 때문이다.

기업에서는 다음과 같은 간단한 스키마로 시작할 수 있다.

처음부터 수천 개를 만들 필요는 없다. 중요한 업무별로 30~50개만 만들어도 AI 시스템의 약점이 보이기 시작한다. 이후 실제 운영 로그에서 실패 사례를 골라 데이터셋에 추가하면 된다. OpenAI가 실제 직업 업무를 평가하기 위해 직업별 과제를 구성한 GDPval에서도, 지식노동의 성과를 평가하려면 단순 퀴즈가 아니라 실제 산출물과 루브릭이 필요하다는 점을 보여준다.⁵

골든셋은 작지만 강해야 한다

평가 데이터셋 중에서도 반드시 통과해야 하는 핵심 세트를 골든셋이라고 부를 수 있다. 골든셋은 AI 시스템의 안전벨트다. 모델을 바꾸거나 프롬프트를 수정하거나 문서를 업데이트할 때마다 이 세트를 다시 돌려본다. 이전에는 잘 맞히던 문제를 갑자기 틀리면 배포를 멈춰야 한다.

골든셋을 만들 때 가장 흔한 실수는 너무 쉬운 문제만 넣는 것이다. "영업 이메일을 작성해줘", "회의록을 요약해줘" 같은 일반 요청만 넣으면 대부분의 모델이 그럴듯하게 통과한다. 하지만 운영에서 사고를 내는 것은 애매한 경계 사례다. 고객이 화가 나 있지만 환불 대상은 아닌 경우, 계약서에 불리한 조항이 숨어 있는 경우, 재무 데이터 일부가 누락된 경우, 개발 코드가 돌아가지만 보안상 위험한 경우가 실제 품질을 가른다.

좋은 골든셋은 작아도 날카롭다. 대표 업무, 고위험 업무, 과거 실패 사례, 규정상 예외, 악의적 요청을 균형 있게 담는다. 그리고 버전으로 관리한다. "고객지원 골든셋 v1.0", "계약 검토 골든셋 v1.3"처럼 이름을 붙이고, 어떤 정책 변경 때문에 어떤 문항을 바꿨는지 기록한다.

이때 데이터셋은 살아 있는 자산이어야 한다. 제품 정책이 바뀌고, 법규가 바뀌고, 고객 문의 유형이 바뀌면 평가 데이터셋도 바뀌어야 한다. 한 번 만든 시험지로 1년 내내 평가하면 AI는 현재 업무가 아니라 과거 업무에 최적화된다.

자동 평가와 사람 검토를 섞는다

모든 AI 결과물을 사람이 전수 검토하면 안전해 보이지만, 실제로는 운영이 막힌다. 반대로 모든 것을 자동화하면 작은 오류가 대량으로 퍼질 수 있다. 그래서 기업은 업무 위험도와 AI 신뢰도에 따라 검토 방식을 나눠야 한다.

자동 평가는 반복적이고 대량으로 발생하는 검수에 유용하다. 예를 들어 고객지원 답변 1만 건을 모두 사람이 읽기는 어렵지만, AI 평가기를 사용하면 금지 표현, 출처 누락, 과도한 보상 약속, 개인정보 포함 여부를 빠르게 걸러낼 수 있다. 자동화된 QA 플랫폼이 대량 상호작용을 일관된 기준으로 평가해 속도와 커버리지를 높인다는 점은 이미 고객지원과 소프트웨어 품질관리 영역에서 널리 활용되고 있다.²

하지만 자동 평가도 AI가 한다는 점을 잊으면 안 된다. 평가 AI 역시 틀릴 수 있다. 따라서 자동 평가 결과를 그대로 최종 판단으로 삼기보다, 고위험·저신뢰·예외 케이스는 사람에게 넘겨야 한다. 이것이 Human-in-the-loop 구조다.

실무에서는 다음과 같은 라우팅 규칙을 만들 수 있다.

• AI 신뢰도 점수가 90점 이상이고 위험도가 낮으면 자동 처리한다.

• 신뢰도 점수가 70~89점이면 결과를 사용하되 표본 감사 대상에 넣는다.

• 신뢰도 점수가 70점 미만이면 담당자 검토 후 사용한다.

• 개인정보, 금액, 계약, 법률, 의료, 인사 평가 키워드가 포함되면 신뢰도와 관계없이 검토한다.

• 고객 불만, 해지, 환불, 보상, 소송 같은 키워드가 있으면 사람 승인 없이는 외부 발송하지 않는다.

EY가 감사 업무에 에이전트형 AI를 대규모로 적용하면서도 인간의 판단, 회의적 검토, 통찰의 역할을 유지한다고 강조한 것도 같은 맥락이다.⁶ AI가 더 많은 일을 처리할수록 사람의 역할은 사라지는 것이 아니라, 더 중요한 검토 지점에 배치되어야 한다.

로그가 없으면 품질 관리도 없다

AI 품질 이슈가 발생했을 때 가장 곤란한 상황은 "왜 이런 답이 나왔는지 아무도 모르는 것"이다. 누가 어떤 질문을 했는지, AI가 어떤 문서를 검색했는지, 어떤 모델과 프롬프트를 썼는지, 사람이 어디를 수정했는지 기록이 없으면 개선도 감사도 어렵다.

기업 AI 시스템은 최소한 다음 로그를 남겨야 한다.

이 로그는 직원을 감시하기 위한 것이 아니라 품질을 개선하기 위한 운영 데이터다. 예를 들어 특정 정책 문서가 참조될 때 오류율이 높다면 문서 구조가 문제일 수 있다. 특정 프롬프트 버전에서 재작업률이 올라가면 프롬프트 변경을 되돌려야 한다. 특정 부서에서 금지 표현이 자주 나오면 교육이나 템플릿 보강이 필요하다.

AI 품질 관리는 설명 가능성과도 연결된다. 기업 품질관리 체계에 설명 가능한 AI를 결합하면 투명성, 책임성, 규제 대응, 디버깅 능력을 높일 수 있다는 논의가 확산되고 있다.⁷ AI가 왜 그런 결론에 도달했는지 완벽히 해부할 수는 없더라도, 최소한 어떤 입력과 근거와 절차를 거쳤는지는 추적할 수 있어야 한다.

품질 지표는 업무 지표와 연결해야 한다

AI 품질을 평가할 때 "답변이 좋아졌다"는 느낌만으로는 부족하다. 품질 지표는 숫자로 관리해야 하며, 가능하면 업무 성과와 연결해야 한다.

대표적인 지표는 다음과 같다.

여기서 중요한 것은 지표 하나만 보지 않는 것이다. 처리 시간이 줄었지만 오류율이 올랐다면 좋은 개선이 아니다. 정확도는 높지만 재작업률이 높다면 실무자가 쓰기 불편한 결과일 수 있다. 고객지원에서는 고객 만족과 재문의율을 함께 봐야 하고, 개발에서는 코드 통과율과 보안 취약점 검출률을 함께 봐야 한다.

품질 지표는 대시보드로 운영하는 것이 좋다. 부서별 AI 사용량, 통과율, 오류 유형, 재작업률, 검토 대기 시간을 주간 단위로 보면 AI가 실제로 업무를 개선하는지 확인할 수 있다. 품질 데이터가 쌓이면 "어떤 모델이 좋은가"보다 더 중요한 질문을 할 수 있다. "어떤 업무에서 어떤 조건일 때 AI가 안정적으로 성과를 내는가"라는 질문이다.

배포 전 테스트, 배포 후 모니터링

AI 시스템을 배포할 때는 소프트웨어 배포처럼 단계가 필요하다. 먼저 개발 환경에서 평가 데이터셋을 돌려보고, 그다음 제한된 사용자에게 파일럿을 열고, 이후 부서 단위로 확대한다. 중요한 업무라면 새 프롬프트나 새 모델을 바로 전체 적용하지 말고 A/B 테스트를 해야 한다.

배포 전에는 다음을 확인한다.

• 대표 평가 데이터셋 통과율이 기준 이상인가

• 고위험 골든셋에서 치명 오류가 없는가

• 금지 답변과 개인정보 노출 테스트를 통과했는가

• RAG 검색 결과가 최신 문서를 우선 참조하는가

• 사람 승인 단계가 정상 작동하는가

• 실패 시 자동 중단 또는 사람 전환이 되는가

배포 후에는 운영 로그를 통해 실제 사용 데이터를 본다. 평가 데이터셋에서 좋은 점수를 받은 AI도 실제 현장에서는 다른 질문을 받는다. 고객은 예상보다 더 모호하게 묻고, 직원은 내부 약어를 쓰고, 문서는 중간에 바뀐다. 그래서 모니터링은 선택이 아니라 필수다.

이때 품질 관리는 "문제가 생기면 고친다"가 아니라 "문제가 생길 가능성을 계속 줄인다"에 가까워야 한다. 오류 사례를 평가 데이터셋에 추가하고, 프롬프트를 수정하고, 문서를 정리하고, 자동 평가 기준을 보강하는 순환 구조를 만들어야 한다.

AI 결과물 책임 소재를 정한다

기업에서 AI를 쓸 때 가장 위험한 문장은 "AI가 그렇게 답했습니다"다. AI는 책임 주체가 아니다. 책임은 시스템을 도입하고 운영한 조직에 있다. 따라서 업무별로 책임 소재를 명확히 해야 한다.

내부 초안 생성처럼 위험이 낮은 업무는 작성자가 최종 책임을 진다. 고객에게 발송되는 답변은 승인자가 책임을 진다. 법무 의견이나 재무 자료처럼 전문 판단이 필요한 결과물은 해당 자격과 권한을 가진 사람이 검토해야 한다. AI 에이전트가 도구를 호출해 실제 시스템을 변경하는 경우에는 실행 권한자와 승인자를 분리하는 것이 좋다.

책임 소재를 정한다는 것은 AI 사용을 위축시키기 위한 것이 아니다. 오히려 사람들이 안심하고 AI를 쓰게 만드는 장치다. "어디까지 AI 초안을 써도 되는지", "어느 순간부터 사람 승인이 필요한지", "오류가 발견되면 누구에게 알려야 하는지"가 분명하면 조직은 더 빠르게 움직일 수 있다.

실무 적용: AI 품질 운영 회의 만들기

AI 품질 관리를 제도화하려면 정기적인 운영 회의가 필요하다. 거창한 위원회가 아니어도 된다. 처음에는 AI 담당자, 주요 부서 실무자, 보안·법무 담당자가 2주에 한 번 모여도 충분하다.

회의에서는 신규 유스케이스를 심사하고, 최근 오류 사례를 확인하고, 평가 데이터셋 변경 사항을 승인한다. 또한 자동 평가 점수와 사람 검토 결과가 얼마나 일치하는지 확인한다. 만약 자동 평가기는 통과라고 했는데 사람이 보기에는 위험한 결과가 많다면 평가 기준을 다시 조정해야 한다.

이 회의의 산출물은 세 가지면 충분하다. 첫째, 이번 주에 발견된 주요 오류와 원인. 둘째, 다음 배포 전 반드시 통과해야 할 평가 항목. 셋째, 문서·프롬프트·워크플로우 중 무엇을 고칠지에 대한 결정이다.

AI 품질 관리는 별도의 문서 작업이 아니라 AI를 운영 자산으로 만드는 가장 현실적인 방법이다. 품질 회의가 쌓이면 회사는 점점 더 똑똑해진다. 어떤 업무는 자동화해도 되는지, 어떤 업무는 사람 검토가 필요한지, 어떤 문서가 AI 성능을 떨어뜨리는지 알게 된다.

품질을 관리하는 회사만 AI를 확장할 수 있다

AI 도입 초기에는 속도가 중요해 보인다. 누가 더 빨리 챗봇을 만들고, 누가 더 많은 프롬프트를 공유하고, 누가 더 많은 자동화를 붙이는지가 성과처럼 보인다. 그러나 운영 단계로 넘어가면 품질이 속도를 결정한다.

검증되지 않은 AI는 결국 멈춘다. 한 번 큰 오류가 나면 조직은 겁을 먹고 사용을 줄인다. 반대로 품질 기준, 평가 데이터셋, 검토 절차, 로그, 지표가 있는 AI는 확장된다. 실수해도 원인을 찾을 수 있고, 원인을 찾으면 고칠 수 있기 때문이다.

AI 네이티브 기업은 AI를 맹신하는 회사가 아니다. AI를 불신해서 아무것도 맡기지 않는 회사도 아니다. AI가 잘하는 일과 약한 일을 구분하고, 틀릴 수 있는 지점에 검증 장치를 넣고, 사람의 판단을 가장 중요한 곳에 배치하는 회사다.

결국 AI 품질 관리의 목적은 완벽한 AI를 만드는 것이 아니다. 불완전한 AI를 안전하게, 반복 가능하게, 점점 더 나아지게 운영하는 것이다. 그 능력이 있는 회사만이 AI 파일럿을 넘어 실제 운영으로 나아갈 수 있다.

참고

¹Cognizant AI Quality Assurance

²Crescendo.ai Automated Quality Assurance

³MLflow Building Evaluation Datasets

⁴Google Vertex AI Evaluation Dataset

⁵OpenAI GDPval

⁶EY Agentic AI in Assurance

⁷KPMG Explainable AI and Enterprise Quality Management Systems