LLM은 오답일수록 자신 있게 답한다

대규모 언어 모델(LLM)을 사용하는 도구 개발 현장에서 간과되기 쉬운 문제가 드러났다. AI가 출력하는 문장이 "그럴듯하게 들린다"는 것과 "실제로 올바르다"는 것은 완전히 별개의 문제다. 한 엔지니어가 평가 프레임워크(출력을 기존의 정답과 비교하여 채점하는 체계)를 구축한 결과, LLM이 틀렸을 때일수록 확신에 찬 표현으로 답변하는 경향이 확인되었다.

많은 개발팀이 채택하고 있는 평가 기법은 "정성 검토"라고 불리는 것으로, 도메인 지식을 갖춘 담당자가 출력 샘플을 눈으로 확인하여 "좋아 보이는 답변인가"라는 직관으로 판단하는 방식이다. 이 기법은 명백히 틀린 내용, 형식이 이상한 내용, 주제가 벗어난 내용 등 뚜렷한 문제를 탐지하는 데는 효과적이다. 한편, 정답과 비교하지 않으면 알 수 없는 유형의 오류를 놓치기 쉬우며, 특히 "그럴듯하게 들리지만 실제로는 잘못된 근거를 제시하고 있다"는 출력은 정성 검토를 통과해버린다.

이 점이 실증된 것은 데이터 이동에서 "드리프트(의도하지 않은 데이터의 편차)"의 원인을 설명하는 도구를 개발하는 과정이었다. 개발자는 드리프트 감지 이벤트를 받아서 그 원인으로 가능성이 높은 것들을 순위 형식으로 제시하는 도구를 구축했다. 초기 프로토타입이 생성한 설명문은 유창하고 구체적으로 들렸으며, 정성 검토에서는 문제없는 것으로 판단되었다. 하지만 정답이 알려진 사례와 비교하는 평가 프레임워크를 사용하여 테스트한 결과, 출력의 정확도가 예상보다 훨씬 낮다는 것이 드러났다. 더욱 심각했던 것은 모델이 잘못된 답변을 제시할 때 높은 확신도의 표현을 사용하는 경향이 보였다는 점이다.

이 문제가 눈에 띄지 않는 이유는 LLM이 본래 "자연스럽고 읽기 쉬운 문장을 생성하는 것"에 최적화되어 있으며, 내용의 정확성과는 독립적으로 권위 있는 어조나 정연한 논리 구조를 출력할 수 있기 때문이다. 정성 검토를 수행하는 담당자가 "정답"을 별도로 확인할 수단을 갖지 않은 경우, 출력의 톤이나 문장의 흐름을 "정확성"과 혼동하기 쉽다. 이는 기업용 도구 전반에 공통적인 위험이라고 할 수 있다.

평가 프레임워크의 구축이란 정답이 알려진 사례 세트를 준비하고, 모델의 출력을 기계적으로 채점하는 체계를 정비하는 것을 의미한다. 시간과 노력이 들기 때문에 많은 팀이 이 단계를 생략하기 쉬우나, 이 과정 없이는 "출력이 얼마나 자주 정확한가"를 정량적으로 파악할 수단이 없다. 정성 검토에서는 통과해도 평가 프레임워크를 거치면 정확도 문제가 드러나는 사례가 확인되고 있다.

AI 도구가 단순한 작업 보조에서 분석가의 조사 방침, 컴플라이언스 담당자의 에스컬레이션 판단, 운영팀의 트리아주(우선순위 지정) 같은 실제 업무 판단에 영향을 미치는 경우가 늘어나고 있다. 이러한 용도에서는 "합리적으로 들린다"는 수준의 평가 기준으로는 불충분하며, 출력의 정확도를 객관적으로 측정하는 체계가 필요하다는 관점이 있다. 정성 검토에만 의존하는 개발 프로세스는 정확도상의 위험을 본번 환경에 갖고 들어오는 구조적 문제를 안고 있다고 할 수 있다.

앞으로 주목해야 할 점은 기업이 LLM 도구를 업무의 중핵에 통합하는 속도에 대해 평가 기법의 정비가 따라가고 있는가 하는 것이다. 평가 프레임워크의 구축은 최종 사용자에게 직접 보이지 않는 지루한 작업이지만, 도구의 신뢰성을 보장하기 위해 필수적인 단계로 자리매김된다. 특히 정확도가 비즈니스 결과에 직결되는 영역에서는, 이 단계를 개발 표준에 포함시키는 움직임이 확대될지 여부가 LLM 활용의 성숙도를 측정하는 하나의 지표가 될 수 있다는 관점이 있다.