“이 답변의 신뢰도는 92%입니다”라는 문장은 그럴듯하다. 제품 화면에 이 숫자를 표시하면 사용자는 AI가 자기 한계를 잘 아는 것처럼 받아들이기 쉽고, 운영팀은 일정 점수 이상을 자동 처리하는 규칙을 만들고 싶어진다.
하지만 LLM이 문장으로 말한 신뢰도와, 해당 답변이 맞을 확률은 같은 값이 아니다. 언어 모델은 답변을 생성하듯 숫자도 텍스트로 생성한다. 따라서 자기보고식 신뢰도는 승인 여부를 결정하는 품질 보증 수치로 바로 쓰기 어렵다.
요구사항 단계에서 먼저 정할 질문은 하나다. 우리 서비스에서 이 점수는 사용자에게 불확실성을 알리는 보조 정보인가, 아니면 돈·권한·건강·계약처럼 되돌리기 어려운 결과를 자동으로 승인하는 기준인가. 두 용도에는 다른 검증이 필요하다.
자기보고식 신뢰도는 왜 승인 기준이 되기 어려운가
신뢰도 점수가 쓸모 있으려면, 같은 점수를 받은 업무 묶음에서 실제 정답률도 그 수준에 가까워야 한다. 예를 들어 어떤 유형의 요청에 80%라는 점수가 붙었다면, 충분히 많은 과거 사례에서 그 답변이 약 80% 수준으로 맞았는지 확인할 수 있어야 한다. 이를 보정 또는 캘리브레이션이라고 부른다.
점수가 맞았는지는 개별 답변 하나로 판단할 수 없다. 답변 결과와 이후의 실제 정답, 담당자 수정, 고객 이의, 처리 완료 여부 같은 결과를 누적해 비교해야 한다. 이 기록이 없으면 “90%”가 얼마나 믿을 만한지 측정할 방법도 없다.
또한 보정만으로는 충분하지 않다. 모든 요청에 비슷한 점수만 내는 시스템은 평균 정답률과 숫자가 맞아도, 쉬운 업무와 어려운 업무를 구별하지 못한다. 자동화 기준에는 다음 두 능력이 함께 필요하다.
- 보정: 80점이라고 한 답변이 장기적으로도 80% 안팎의 정확도를 보이는가
- 구별력: 맞을 가능성이 높은 요청과 낮은 요청을 점수로 분리하는가
의료 진단과 치료 선택 과제를 다룬 연구에서도 LLM이 말로 표현한 신뢰도는 모델의 실제 확신을 일관되게 과대평가하는 경향을 보였다. 여러 번 생성한 답변의 일관성을 보는 방식이 일부 불확실성 측정에서는 더 나은 구별력을 보였지만, 그 방식도 별도의 보정 없이는 점수 자체를 그대로 신뢰하기 어려웠다. 의료 외 업무에 같은 결과를 그대로 적용할 수는 없지만, 자기보고 숫자를 자동 승인 규칙으로 곧장 연결하면 안 된다는 기술적 경고로는 충분하다.
세 종류의 점수를 같은 이름으로 부르지 말아야 한다
제품 명세서에서 “confidence”라는 필드 하나로 모든 판단을 처리하면 논의가 흐려진다. 최소한 아래 세 값을 분리해 정의하는 편이 낫다.
| 구분 | 무엇을 나타내나 | 자동 승인에 단독 사용 가능한가 |
|---|---|---|
| 자기보고식 신뢰도 | LLM이 답변과 함께 서술한 확신 | 아니다 |
| 모델 출력 기반 지표 | 토큰 확률, 복수 응답의 일관성 등 생성 과정에서 얻은 대리 지표 | 검증 전에는 아니다 |
| 업무 보정 점수 | 특정 업무·데이터·모델 버전에서 실제 결과로 보정한 예측값 | 다른 통제 조건과 결합할 때 검토 가능 |
첫 번째 값은 대화 경험에 도움이 될 수 있다. 예를 들어 AI가 추가 자료를 요청하거나 “확인이 필요하다”고 안내할 때, 내부적으로 참고 신호로 쓸 수 있다. 다만 숫자를 그대로 고객이나 담당자에게 보여주면, 근거가 검증된 확률처럼 오해하게 만들 수 있다.
두 번째 값은 자기보고보다 나은 후보가 될 수 있지만, 그 자체로 정답률을 뜻하지는 않는다. 복수 답변이 서로 비슷하다고 해서 답이 맞는 것은 아니다. 같은 잘못된 전제나 누락된 자료를 바탕으로 일관된 답을 낼 수도 있다.
세 번째 값은 제품이 승인 기준으로 삼을 수 있는 출발점이다. 단, “업무 보정”이라는 조건이 중요하다. 문의 요약 업무에서 검증한 점수를 환불 승인, 채용 추천, 보험 심사 같은 다른 업무에 옮겨 쓸 근거는 별도로 확보해야 한다. 모델, 프롬프트, 검색 자료, 입력 양식이 달라져도 이전 보정값은 달라질 수 있다.
자동 승인 여부는 점수 하나가 아니라 네 개의 문으로 결정한다
자동화를 설계할 때는 신뢰도 임계값 하나보다 승인 경로를 먼저 정하는 편이 안전하다. 다음 네 조건을 모두 통과한 요청만 자동 승인 후보로 두는 방식이다.
-
정답을 정의할 수 있는가
결과가 맞았는지 사후에 확인할 기준이 있어야 한다. 예를 들어 정해진 문서에서 항목을 추출하는 업무는 대조가 가능하지만, 자유형 조언의 품질은 합의된 정답을 만들기 어렵다. -
근거가 연결되는가
답변이 어떤 문서, 데이터 필드, 규정 조항을 근거로 삼았는지 확인할 수 있어야 한다. 근거가 없거나 서로 충돌하면 높은 보정 점수라도 승인 대신 검토 큐로 보내는 편이 낫다. -
결정 규칙으로 걸러낼 수 있는가
금액 한도, 대상 조건, 필수 입력값, 권한 범위처럼 시스템이 판정할 규칙을 별도로 둬야 한다. LLM은 규칙을 설명하거나 후보를 제안할 수 있지만, 규칙 충족 여부까지 말로 판단하게 맡기면 오류 원인을 추적하기 어렵다. -
되돌릴 수 있는가
오답이 나와도 쉽게 취소·수정할 수 있는 처리와, 손해가 발생한 뒤 복구하기 어려운 처리는 나눠야 한다. 후자라면 점수가 높아도 담당자 확인을 남기는 쪽이 요구사항에 맞을 가능성이 크다.
이 구조에서 LLM의 자기보고 점수는 첫 단계의 탐색 신호 정도로 남는다. 실제 승인에는 보정 점수, 근거 존재 여부, 규칙 통과, 영향도 기준이 함께 작동한다.
어떤 업무는 자동화하고, 어떤 업무는 사람에게 넘길까
자동 승인 후보는 대체로 입력과 정답 형식이 좁고, 근거 문서가 정해져 있으며, 사후 결과를 기록할 수 있는 업무다. 예를 들어 정형화된 신청서에서 누락 항목을 찾거나, 명시된 정책에 따라 안내 문구 초안을 분류하는 작업이 여기에 가깝다. 이 경우에도 AI가 내놓은 답을 기준 데이터와 비교해 성능을 측정하고, 업무별 보정값을 다시 계산해야 한다.
반대로 사람 검토를 기본값으로 두어야 하는 업무도 있다. 근거가 부족한데 결론을 내려야 하는 요청, 여러 정책이 충돌하는 요청, 예외 승인, 개인에게 불리한 결정, 외부에 확정 답변을 보내는 업무가 대표적이다. 이런 경우 AI는 결론 승인자가 아니라 자료를 정리하고 누락을 표시하며 검토할 쟁점을 제시하는 역할이 더 적절하다.
초기 운영에서 특히 경계할 신호도 있다. 같은 입력에 점수가 크게 흔들리거나, 높은 점수의 답변에서 담당자 수정이 반복되거나, 특정 문서 버전이 바뀐 뒤 오류가 늘어나면 자동 승인 범위를 넓힐 시점이 아니다. 점수 계산 방식, 모델 버전, 검색 대상 문서가 변할 때마다 기존 평가가 여전히 유효한지도 다시 확인해야 한다.
요구사항 문서에 넣을 검증 질문
제품 관리자와 AI 담당자는 “신뢰도 점수를 제공할 수 있는가”보다 아래 질문에 답할 수 있어야 한다.
- 이 업무에서 정답 또는 승인 결과는 누가, 언제, 어떤 기록으로 확정하는가?
- 점수 구간별 실제 정답률과 처리 건수는 어떻게 저장하고 비교할 것인가?
- 모델이 제시한 근거가 없거나 근거끼리 충돌할 때 어떤 경로로 보낼 것인가?
- 프롬프트, 모델, 검색 문서, 업무 규칙이 바뀌면 어떤 평가를 다시 해야 하는가?
- 자동 처리 오류가 발생했을 때 취소, 수정, 통지, 재검토는 누가 담당하는가?
- 사람 검토자는 AI의 결론만 보는가, 아니면 근거와 적용 규칙까지 확인할 수 있는가?
업체나 개발팀이 신뢰도 기능을 제안한다면, “점수를 출력한다”는 설명만으로 충분하지 않다. 업무별 과거 결과로 점수를 보정했는지, 보정 데이터가 어떤 입력 범위를 포함하는지, 모델 변경 후 재평가 절차가 있는지까지 확인해야 한다.
자동 승인 임계값부터 정하지 말고, 우선 한 업무 유형을 골라 정답 기록과 검토 결과를 쌓는 방식으로 시작하는 편이 낫다. 그 기록이 있어야 높은 점수가 승인 신호가 될 수 있는지, 아니면 사람에게 넘겨야 할 경고 신호인지 구분할 수 있다.
