정성 평가가 놓친 '확신에 찬 오답'의 실체

데이터 마이그레이션 드리프트(Data Migration Drift, 데이터 이전 중 발생하는 값의 차이)의 원인을 설명하는 LLM 도구를 개발하며, 정답 데이터(Ground Truth)를 기반으로 한 평가 하네스(Eval Harness)가 구축됐다. 엔터프라이즈 아키텍트 아룬 미슈라(Arun Mishra)가 설계한 이 체계는 모델이 내놓은 답변이 단순히 '그럴듯한지'가 아니라, 실제 정답과 일치하는지를 수치로 측정한다.

이번에 구축된 평가 하네스는 세 가지 단계로 작동한다. 먼저 스키마 변경, 변환 로직 버그, 소스 시스템의 행동 변화 등 통제된 원인을 직접 주입해 정답을 미리 알고 있는 '합성 정답 데이터셋'을 만들었다. 이어 모델이 제시한 원인들의 순위(Rank)와 정답 포함 여부(Presence)를 결합해 점수를 매기는 스코어링 함수를 적용했다. 마지막으로 일부 사례만 확인하는 스팟 체크 대신 전체 데이터셋을 대상으로 체계적인 평가를 수행했다.

검증 결과에서 가장 눈은 띄는 점은 모델의 확신도와 정확도가 반비례하는 구간이 존재한다는 사실이다. 스키마 변경 시나리오에서는 높은 신뢰도를 보였으나, 두 가지 이상의 원인이 동시에 발생한 '중첩 신호(Overlapping-signal)' 시나리오에서는 가장 높은 확신을 가지고 틀린 답을 내놓았다. 이는 사람이 눈으로 읽고 판단하는 정성적 리뷰로는 절대 발견할 수 없는 패턴이다.

'그럴듯함'에서 '정확성'으로 옮겨가는 채택 기준

기업용 AI 도구의 역할이 단순 생산성 보조에서 비즈니스 의사결정의 핵심 구성 요소로 확장되면서, 채택 기준이 '유창함'에서 '정확성'으로 빠르게 이동하고 있다. 분석가가 데이터 품질 문제를 조사하거나 컴플라이언스 검토자가 기록의 에스컬레이션 여부를 결정하는 도구의 경우, '합리적으로 보인다'는 수준의 평가는 실제 운영 환경에서 심각한 리스크가 된다.

기존의 정성적 평가(Qualitative Review)는 도메인 전문가가 자신의 직관을 바탕으로 답변을 검토하고 프롬프트를 수정하는 방식이다. 이 방식은 형식이 잘못되었거나 주제에서 벗어난 답변을 잡아내는 데는 유용하지만, 권위 있는 말투와 그럴싸한 논리로 무장한 '정교한 오답'을 걸러내지 못한다. 결과적으로 내부 리뷰에서는 통과하지만, 실제 현장에서 정답과 대조하는 순간 실패하는 '조용한 실패(Fail quietly)' 현상이 발생한다.

시장의 흐름은 이제 모델의 유창함(Fluency)과 일관성(Coherence)을 측정하는 단계를 넘어, 외부의 객관적 기준과 대조하는 정량적 검증 체계를 구축하는 방향으로 흐르고 있다. 특히 비즈니스 결정에 영향을 주는 도구일수록, 모델이 내놓은 답변의 순위가 실제 원인의 중요도와 얼마나 일치하는지를 측정하는 랭킹 기반 평가가 중요해지고 있다.

실무자가 구축해야 할 '정답 데이터셋'의 기준

한국의 AI 실무자와 개발자가 주목해야 할 지점은 '정확성(Correctness)'을 측정하기 위한 합성 데이터셋의 설계 방식이다. 단순히 깨끗한 데이터를 넣는 것이 아니라, 실제 운영 환경에서 발생하는 노이즈와 중첩된 신호를 의도적으로 추가해야만 예측 가능한 성능 지표를 얻을 수 있다. 초기 버전의 데이터셋이 너무 깨끗했을 때 실제 성능을 예측하지 못했다는 점은 시사하는 바가 크다.

실무적으로 가장 먼저 실행해야 할 과제는 우리 서비스에서 '정답'이란 무엇인지 정밀하게 정의하는 것이다. 정답의 정의가 내려지면 스코어링 함수나 하네스 인프라를 구축하는 것은 상대적으로 간단하다. 하지만 이 정의 과정 자체가 해당 유즈케이스의 핵심 로직을 명확히 하는 작업이 되므로, 개발 초기 단계부터 투자할 가치가 있다.

결국 LLM 도구를 프로덕션에 배포하기 전, '답변이 합리적인가'라는 질문을 '정답을 알고 있는 사례에서 정확하게 작동하는가'로 바꿔야 한다. 모델이 가장 확신에 차 있을 때 가장 크게 틀릴 수 있다는 가능성을 전제하고, 정답 데이터셋을 통한 강제 검증 단계를 파이프라인에 포함하는 것이 실질적인 리스크 관리 방안이다.