AI 품질관리와 평가

AI 품질은 배포 후에 더 중요해진다

기업이 AI 시스템을 구축하면 흔히 마지막 단계에서 테스트를 한다. 몇 가지 질문을 던져 보고, 그럴듯한 답이 나오면 배포한다. 그러나 AX 환경에서 AI 품질은 출시 시점의 성능만으로 결정되지 않는다. 실제 사용자가 어떤 질문을 하는지, 사내 문서가 어떻게 바뀌는지, 업무 규칙이 얼마나 자주 변경되는지, 모델과 프롬프트가 어떤 버전으로 운영되는지에 따라 품질은 계속 달라진다.

따라서 AI 품질관리는 일회성 검수가 아니라 운영 체계다. 사람이 쓰는 업무 시스템처럼 AI도 성능, 오류, 비용, 보안, 사용자 만족도를 계속 봐야 한다. 특히 고객 상담, 내부 지식 검색, 계약 검토, 재무 보고, 채용 지원처럼 업무 결과가 실제 의사결정에 영향을 주는 영역에서는 더 그렇다.

AI가 한 번 좋은 답을 했다고 해서 계속 좋은 답을 한다는 보장은 없다. 문서가 바뀌면 답이 틀릴 수 있고, 프롬프트를 조금 수정했는데 안전성이 떨어질 수 있다. 검색 로직을 바꿨더니 예전에는 찾던 근거 문서를 놓칠 수도 있다. 그래서 AI 운영의 핵심 질문은 '잘 만들었는가'가 아니라 '지금도 안전하고 유용하게 작동하는가'여야 한다.

AI 생성 이미지

업무 목적에 맞게 품질을 수치화한다

AI 품질을 관리하려면 먼저 좋은 답변이 무엇인지 정의해야 한다. 막연히 '자연스럽다', '똑똑하다', '빠르다'로는 부족하다. 업무별로 평가 기준을 나누고 가능한 한 수치화해야 한다.

기본적으로 기업 AI 답변은 다섯 가지 관점에서 평가할 수 있다.

• 정확성: 사실, 규정, 수치, 업무 기준과 일치하는가

• 일관성: 같은 조건에서 비슷한 품질의 답을 반복적으로 내는가

• 유용성: 사용자의 업무를 실제로 해결하는 데 도움이 되는가

• 안전성: 개인정보, 기밀, 차별, 금지 조언, 법적 위험을 만들지 않는가

• 근거성: 답변이 어떤 문서나 데이터에 기반했는지 확인할 수 있는가

정답이 있는 업무에서는 더 구체적인 지표를 쓸 수 있다. 예를 들어 요약문이나 번역 결과를 기준 답안과 비교할 때는 BLEU, ROUGE, 텍스트 유사도, 의미 유사도 같은 기준을 활용할 수 있다. BLEU와 ROUGE는 생성된 문장과 기준 문장의 단어 겹침을 보는 방식이고, 의미 유사도는 표현이 달라도 뜻이 얼마나 가까운지를 보는 방식이다. Microsoft는 생성형 AI 평가 지표를 기준 답안 기반 평가, 문맥 기반 평가, LLM 기반 평가 등으로 나누어 설명한다¹.

다만 이 지표들은 보조 수단이다. 단어가 많이 겹친다고 반드시 좋은 답은 아니다. 고객 상담에서는 공감과 정책 준수가 중요하고, 법무 검토에서는 누락된 위험 조항을 찾는 능력이 중요하다. 코드 생성에서는 문장이 자연스러운지보다 실행이 되는지, 테스트를 통과하는지가 더 중요하다. 그러므로 평가 지표는 업무 목적에 맞게 설계해야 한다.

RAG는 검색과 답변을 나누어 평가한다

사내 지식 AI나 규정 검색 AI처럼 RAG 기반 시스템은 답변만 평가하면 부족하다. RAG는 먼저 문서를 찾고, 그 문서를 바탕으로 답을 만든다. 따라서 품질 문제도 두 곳에서 생긴다. 하나는 필요한 문서를 못 찾는 문제이고, 다른 하나는 찾은 문서를 잘못 해석하는 문제다.

검색 단계에서는 다음 지표를 볼 수 있다.

• 검색 정확도: 가져온 문서 중 실제로 관련 있는 문서의 비율

• Recall@K: 상위 K개 검색 결과 안에 필요한 문서가 포함되는 비율

• 근거 문서 적합성: 검색된 문서가 질문 해결에 충분히 관련 있는지

• 최신성: 폐기된 문서나 과거 버전이 검색되지 않는지

답변 생성 단계에서는 다음을 본다.

• 근거 충실도: 답변이 검색된 문서에 충실한가

• 답변 관련성: 질문에 직접 답하고 있는가

• 불필요한 추론 여부: 문서에 없는 내용을 추가하지 않았는가

• 출처 표시 품질: 사용자가 근거를 확인할 수 있는가

NVIDIA는 RAG 시스템을 평가할 때 검색기와 생성기를 분리해 보고, 검색 정밀도·재현율, 충실도, 응답 관련성 등을 함께 봐야 한다고 설명한다². 기업 환경에서는 이 구분이 특히 중요하다. 답변이 틀렸을 때 모델이 문제인지, 검색 인덱스가 문제인지, 문서 자체가 오래된 것인지 알아야 고칠 수 있기 때문이다.

예를 들어 인사 규정 AI가 잘못된 연차 기준을 안내했다면 원인은 다양하다. 최신 규정 문서가 색인되지 않았을 수 있다. 검색은 됐지만 AI가 예외 조항을 놓쳤을 수 있다. 사용자의 질문 의도를 잘못 해석했을 수도 있다. 품질관리는 이 원인을 분리해 찾는 작업이다.

평가 데이터셋은 실제 업무에서 만들어야 한다

좋은 평가의 출발점은 좋은 테스트 데이터다. 공개 벤치마크는 모델의 일반 능력을 비교하는 데는 도움이 된다. 그러나 기업 업무 품질을 판단하기에는 부족하다. 고객이 실제로 묻는 질문, 직원이 자주 헷갈리는 규정, 법무팀이 반복해서 검토하는 조항, 상담원이 자주 수정하는 답변은 회사마다 다르다.

평가 데이터셋에는 다음 유형이 포함되어야 한다.

• 실제 현업 질문

• 자주 발생하는 예외 상황

• 과거 오류 답변과 실패 사례

• 답하면 안 되는 위험 질문

• 비슷하지만 다른 반대 사례

• 최신 문서와 과거 문서가 충돌하는 사례

• 짧은 질문, 모호한 질문, 여러 의도가 섞인 질문

Databricks는 LLM 평가가 하나의 방식으로 해결될 수 없으며, 애플리케이션 맥락에 맞는 평가 데이터와 기준을 설계해야 한다고 강조한다³. 고객 상담 AI와 법무 검토 AI는 같은 방식으로 평가할 수 없다. 고객 상담은 정확성뿐 아니라 표현의 친절함, 정책 준수, 고객 감정 대응이 중요하다. 법무 검토는 문장 자연스러움보다 위험 조항 탐지, 누락 방지, 근거 표시가 중요하다. 내부 지식 검색은 답변의 간결함보다 최신 문서 기반 답변과 출처 표시가 더 중요할 수 있다.

평가 데이터셋은 한 번 만들고 끝내지 않는다. 운영 중 새로 발생한 질문, 실패 사례, 사용자 불만, 상담원 수정 내역을 계속 추가해야 한다. 이렇게 해야 AI가 실제 업무 변화에 맞춰 개선된다.

자동 평가와 휴먼 리뷰를 결합한다

AI 평가를 모두 사람이 하면 비용이 크고 속도가 느리다. 반대로 모두 자동화하면 미묘한 위험을 놓칠 수 있다. 그래서 자동 평가와 휴먼 리뷰를 역할에 맞게 결합해야 한다.

자동 평가는 대량 테스트와 버전 비교에 강하다. 프롬프트를 바꿨을 때 정확성 점수가 얼마나 달라졌는지, 검색 로직을 바꿨을 때 Recall@K가 올라갔는지, 모델을 교체했을 때 금지 답변이 늘었는지 빠르게 확인할 수 있다. 규칙 기반 점검도 유용하다. 예를 들어 개인정보가 포함된 답변을 탐지하거나, 출처 없는 답변을 실패로 처리하거나, 특정 금지 표현을 감지할 수 있다.

LLM-as-a-judge도 활용할 수 있다. 이는 다른 LLM에게 평가자 역할을 맡기는 방식이다. 평가 기준, 사용자 질문, AI 답변, 근거 문서를 함께 제공하고 정확성, 명확성, 근거 충실도 등을 점수화하게 한다. 이 방식은 대량 평가에 유용하지만, 평가 모델도 편향과 한계를 가질 수 있다. 따라서 고위험 업무에서는 전문가 리뷰가 반드시 필요하다.

휴먼 리뷰는 맥락 판단에 강하다. 법무 담당자는 조항의 실제 위험을 판단할 수 있고, 상담 리더는 고객에게 적절한 표현인지 볼 수 있다. 보안 담당자는 답변이 정책상 허용되는지 판단한다. 특히 고객 권리, 금전, 법률, 인사, 의료, 개인정보에 영향을 주는 업무에서는 사람 검토를 생략해서는 안 된다.

실무적으로는 다음처럼 나누는 것이 좋다.

• 낮은 위험·대량 반복 업무: 자동 평가 중심, 일부 샘플 휴먼 리뷰

• 중간 위험 업무: 자동 평가와 정기 휴먼 리뷰 병행

• 높은 위험 업무: 전문가 리뷰와 승인 절차 필수

• 신규 배포·중요 변경: 자동 회귀 테스트 후 책임자 승인

회귀 테스트로 품질 하락을 막는다

AI 시스템은 작은 변경에도 품질이 달라진다. 모델 버전이 바뀌거나, 프롬프트 문장이 수정되거나, RAG 문서가 업데이트되거나, 검색 순위 알고리즘이 바뀌면 기존에 잘 되던 질문이 틀릴 수 있다. 이를 회귀라고 한다. 회귀 테스트는 변경 후에도 기존 핵심 기능과 안전성이 유지되는지 확인하는 절차다.

Braintrust는 LLM 평가를 출시 전 한 번의 점검이 아니라 지속적인 측정, 버전 비교, 회귀 탐지, 운영 모니터링의 과정으로 다룬다⁴. 기업도 같은 관점이 필요하다. AI 변경 사항이 생기면 최소한 다음을 비교해야 한다.

• 이전 버전 대비 정확성 점수

• 근거 문서 인용률

• 검색 Recall@K

• 금지 답변 발생률

• 사용자 질문 재시도율

• 낮은 만족도 응답 비율

• 비용과 응답 지연 시간

품질 기준을 통과하지 못하면 배포를 중단하거나 롤백할 수 있어야 한다. AI 시스템도 일반 소프트웨어처럼 품질 게이트가 필요하다. 예를 들어 법무 검토 AI의 근거 충실도가 기준 아래로 떨어지면 배포하지 않는다. 고객 상담 AI에서 개인정보 노출 위험이 감지되면 즉시 이전 버전으로 되돌린다. 운영 품질은 좋은 의도보다 명확한 중단 기준에서 나온다.

사용자 피드백은 개선 데이터다

운영 중 발생하는 사용자 행동은 중요한 품질 신호다. 사용자가 같은 질문을 다시 묻는다면 첫 답변이 충분하지 않았을 가능성이 있다. 상담원이 AI 답변을 자주 수정한다면 답변이 실무 표현과 맞지 않을 수 있다. 고객이 낮은 만족도를 남긴다면 정확성보다 태도나 맥락 대응에 문제가 있을 수 있다. 출처 없는 답변이 반복된다면 RAG 검색 또는 답변 생성 지침을 고쳐야 한다.

품질 개선에 활용할 운영 신호는 다음과 같다.

• 오류 답변 신고

• 사용자 불만과 낮은 만족도

• 재질문과 질문 재작성

• 상담원·직원의 수정 내역

• 답변 미사용 또는 복사 후 대폭 수정

• 근거 문서 미인용 사례

• 금지 정보 입력 시도

• 예외 처리 요청

이 데이터는 단순 CS 기록이 아니다. 평가 지표가 놓친 품질 저하와 새로운 리스크를 발견하는 신호다. 따라서 운영 로그는 품질 개선 회의에서 정기적으로 검토해야 한다. 낮은 점수 사례를 모아 원인을 분류하고, 필요한 경우 평가 데이터셋에 추가한다. 이렇게 해야 AI 시스템이 실제 업무에서 배우는 구조가 된다.

품질관리 체계를 운영 시스템으로 만든다

AI 품질관리는 담당자의 감각에 맡길 일이 아니다. 최소한 다음 요소가 체계로 관리되어야 한다.

• 평가 지표: 정확성, 일관성, 유용성, 안전성, 근거성 등

• 테스트 데이터셋: 실제 질문, 예외 사례, 실패 사례, 위험 질문

• 승인 기준: 배포 가능한 최소 점수와 금지 조건

• 로그 모니터링: 사용량, 오류, 재질문, 수정, 만족도, 비용

• 개선 이력: 모델, 프롬프트, 문서, 검색 로직 변경 기록

• 책임자: 현업 오너, 기술 오너, 품질 검토자, 보안·법무 담당자

작게 시작해도 된다. 처음부터 복잡한 평가 플랫폼을 만들 필요는 없다. 핵심 업무 하나를 정하고, 대표 질문 50개를 모으고, 좋은 답변 기준을 정하고, 매주 실패 사례를 검토하는 것만으로도 품질관리는 시작된다. 중요한 것은 AI를 '만들어 놓은 도구'로 보지 않는 것이다. AI는 계속 평가하고 개선해야 하는 운영 대상이다.

AX 전환이 깊어질수록 AI는 더 많은 업무 판단에 관여한다. 그만큼 품질관리의 수준이 조직 신뢰의 수준이 된다. 좋은 AI 시스템은 한 번에 완성되지 않는다. 실제 사용, 오류 발견, 평가, 수정, 재검증을 반복하면서 업무에 맞게 다듬어진다. 결국 AI 품질관리의 목적은 완벽한 답변을 약속하는 것이 아니라, 오류를 발견하고 고칠 수 있는 조직 능력을 만드는 데 있다.

참고

¹A list of metrics for evaluating LLM-generated content

²Mastering LLM Techniques: Evaluation

³Best Practices and Methods for LLM Evaluation

⁴LLM evaluation metrics: Full guide to LLM evals and key metrics