판정을 믿을 수 있나: 신뢰도 표시·근거·감사 추적과 평가

왜 '신뢰도: 중간'을 따져 봐야 하나

'판정하는 AI: Decision RAG의 허와 실' 시리즈의 3편이다. 2편에서는 LLM에 비정형 문서 읽기와 설명을, 결정표·정책 코드에 규칙 적용을 맡기는 분업을 다뤘고, 판정마다 규칙 버전을 남겨야 한다는 데서 마무리했다. 이번 편은 판정 결과 화면에 붙는 '신뢰도: 중간', '근거: 약관 제5조' 같은 항목을 실제로 믿어도 되는지 따진다.

판정 업무에서 신뢰도와 근거는 장식이 아니다. 신뢰도가 높으면 자동 확정하고 낮으면 사람에게 넘기는 식으로, 이 값이 업무 흐름이 어느 쪽으로 갈지 정한다. 근거와 기록은 고객이 이의를 제기하거나 내부 감사가 들어왔을 때 '왜 이렇게 판정했나'에 답할 수 있는 유일한 자료다. 신뢰도 값이 엉터리면 흐름이 엉뚱한 쪽으로 가고, 기록이 비어 있으면 설명 책임을 질 수 없다.

OECD AI 원칙글은 신뢰할 수 있는 AI의 가치로 투명성과 설명 가능성, 견고성·보안·안전, 책임성, 그리고 공정성과 프라이버시를 포함한 인권·민주적 가치를 꼽는다. 이 글은 이 원칙들을 판정 시스템의 구체적인 장치 네 가지로 옮긴다. 측정으로 보정한 신뢰도, 사람에게 넘기는 기준, 감사 기록, 평가 세트다.

말로 하는 확신도는 왜 높은 쪽으로 몰리나

먼저 용어부터 정리한다. LLM 신뢰도 추정·보정 서베이논문는 신뢰도를 두 가지로 나눈다. 상대적 신뢰도는 맞는 답과 틀린 답의 순서를 잘 가리는 능력이다. 절대적 신뢰도는 숫자 자체가 실제 정확도와 맞는 것이다. 모델이 70%라고 말한 사례들이 실제로 70% 정도 맞으면 그 모델은 '보정됐다(calibrated)'고 한다. 이 차이를 재는 대표 지표가 ECE(기대 보정 오차)다. 신뢰도 값을 구간별로 묶고, 각 구간의 평균 신뢰도와 실제 정확도가 얼마나 벌어지는지를 가중 평균한다. 같은 서베이는 ECE가 구간 폭 같은 설정에 민감하다는 점도 짚고, 이를 그래프로 보여 주는 신뢰도 다이어그램을 소개한다.

그렇다면 LLM에게 '확신도를 0~100으로 말해 줘'라고 물으면 어떻게 될까. 확신도 끌어내기 연구논문는 GPT-4, LLaMA 2 Chat을 포함한 다섯 개 LLM을 다섯 유형의 과제에서 시험했다. 모델이 말로 밝힌 확신도는 대체로 과신 쪽이었고, 값은 주로 80~100%에 몰렸으며 사람이 확신을 말할 때처럼 5의 배수로 나오는 경우가 많았다. 모델이 커질수록 나아졌지만 이상적인 수준과는 거리가 멀었다. 사람의 대화 방식을 본뜬 프롬프트로 보정 오차(ECE)는 크게 줄일 수 있었다. 하지만 어떤 답이 틀릴지 미리 가려내는 실패 예측은 여전히 어려웠고, 전문 지식이 필요한 과제에서는 어느 방법이든 고전했다. 과신 평가 연구논문도 GPT-4, GPT-3.5, LLaMA2, PaLM 2와 비전-언어 모델들이 대부분 과신하고 보정 오차가 크다고 보고했다. 이 연구는 오차가 과신 쪽인지 과소 신뢰 쪽인지를 가리는 지표로 NCE(Net Calibration Error)를 제안했고, 평균·표준편차나 95% 신뢰구간처럼 수치 범위를 내라고 해도 보정이 나빴다고 밝혔다.

이 결과는 판정 시스템 설계와 바로 이어진다. Claude 문서글에 따르면 구조화된 출력은 제한 디코딩(constrained decoding)으로 응답이 스키마를 따르도록 보장한다. 필드 타입과 필수 필드가 지켜지고, 문서의 분류 예시에도 confidence: float 칸이 들어 있다. 그러나 이 보장은 형식에 대한 것이다. confidence가 실수로 나온다는 것은 보장하지만, 0.8이 '이런 사례 열 개 중 여덟 개는 맞는다'는 뜻이라는 것까지 보장하지는 않는다. '높음·중간·낮음' 같은 단계 표시도 마찬가지다. '중간'이 실제로 몇 %의 정확도인지 재 보기 전까지는 그냥 이름표일 뿐이다.

서베이논문는 LLM에서 신뢰도 추정이 특히 어려운 이유도 정리한다. 가능한 출력이 너무 많고, 다른 표현이 같은 뜻일 수 있어 의미 단위로 따져야 하며, 예시나 예시의 순서 같은 프롬프트 변화에 결과가 크게 흔들린다. 확신도를 얻는 방법은 크게 셋이다. 말로 묻는 방법, 같은 질문에 여러 번 답하게 해서 답이 얼마나 일치하는지 보는 방법, 토큰 확률 같은 모델 내부 정보를 보는 방법이다.

불확실성을 행동 신호로 바꾸기

확신도 끌어내기 연구논문는 신뢰도 추정을 세 부품으로 나눴다. 확신도를 말하게 하는 프롬프트 전략, 답을 여러 개 받는 샘플링 전략, 그 답들의 일치 정도를 계산하는 집계 전략이다. 여러 답의 일관성을 쓰는 방법은 특히 실패 예측을 개선했다. 내부 정보를 쓰는 화이트박스 방법이 더 나았지만 차이는 크지 않아서, 실패 예측 지표인 AUROC가 0.522 대 0.605 수준이었다. 다만 연구진은 어느 방법도 늘 다른 방법보다 낫지는 않았다고 밝혔다. 실무에서 보면 닫힌 API만 쓸 수 있는 조직도 일관성 기반 방법으로 꽤 많은 것을 얻을 수 있다. 대신 판정 한 건당 호출 비용이 늘어난다.

능동 신호로서의 불확실성 서베이논문는 흐름이 바뀌고 있다고 정리한다. 불확실성이 '사후에 보는 진단 지표'에서 '모델의 행동을 실시간으로 바꾸는 제어 신호'로 옮겨 가고 있다는 것이다. 추론에서는 계산을 얼마나 더 쓸지 정하고 스스로 고칠지 판단하는 데, 에이전트에서는 도구를 부를지·정보를 더 찾을지 정하는 데, 강화학습에서는 보상 해킹을 줄이는 데 쓰인다. 이 서베이는 이런 흐름을 베이즈 방법과 Conformal Prediction 같은 이론 틀 위에서 설명한다.

판정 업무에 옮기면 신뢰도의 역할은 결과 화면에 숫자를 띄우는 것보다 길을 나누는 것이다. 서베이논문가 소개하는 구분을 빌리면, 불확실성에는 데이터 자체가 모호해서 생기는 것(aleatoric)과 모델의 지식이 부족해서 생기는 것(epistemic)이 있다. 뒤쪽은 정보를 더 모으면 줄일 수 있다. 그래서 '추가 서류 조회나 규칙 엔진 재질의로 줄일 수 있는 불확실성'은 도구 호출 쪽으로, '입력 자체가 애매하거나 위험이 큰 사례'는 사람 검토 쪽으로 보내는 설계가 자연스럽다. 이때 각 갈래의 문턱값은 모델이 말한 숫자로 정하지 않는다. 평가 세트에서 신뢰도 구간별 실제 정확도를 재고, 그 결과로 정한다.

판정이 여러 단계로 이어지는 에이전트라면 한 단계 더 어렵다. 에이전트 불확실성 정량화 연구논문는 대부분의 불확실성 연구가 아직 한 번 묻고 답하는 상황에 머물러 있다고 지적한다. 그리고 에이전트에 특유한 과제 네 가지를 든다. 어떤 추정 방법을 고를지, 성격이 서로 다른 대상(도구 결과, 사용자 응답 등)의 불확실성을 어떻게 다룰지, 상호작용 속에서 불확실성이 어떻게 변하는지를 어떻게 모델링할지, 세밀한 벤치마크가 부족하다는 점이다. 단계마다 신뢰도를 따로 재는 것만으로 전체 판정의 신뢰도를 안다고 여기면 안 된다는 뜻이다.

사람에게 넘길 때를 배우기: 위임 학습

'자신 없으면 사람에게 넘긴다'는 규칙은 단순해 보이지만 빠진 것이 있다. 넘겨받은 사람이 그 사례에서 실제로 더 잘하느냐는 질문이다. 위임 학습 연구논문는 이 질문을 학습 문제로 바꿨다. 직접 예측하는 분류기와, 이 사례를 하류의 전문가에게 넘길지 정하는 거절기(rejector)를 함께 학습한다. 학습에는 전문가가 과거에 내린 결정 샘플만 있으면 된다. 연구진은 이 문제를 비용 민감 학습으로 바꾸고, 교차 엔트로피 손실을 일반화한 일관된 대리 손실 함수를 제시했다. 여러 실험 과제에서 효과도 보였다.

비유하면 신입 심사역과 팀장의 관계다. 좋은 신입은 '내가 헷갈리는 건'만 올리지 않는다. '팀장님이 나보다 확실히 잘 보는 유형'을 올린다. 둘 다 헷갈리는 사례라면 올려도 정확도는 오르지 않고 팀장의 시간만 쓴다. 반대로 신입은 자신 있지만 자주 틀리는 유형이 있다면, 그런 사례는 신입의 자신감과 상관없이 올려야 한다. 위임 학습은 넘길지 말지를 모델의 불확실성 하나가 아니라 모델과 사람 각각의 정확도, 그리고 오류 비용을 함께 놓고 정하라고 말한다.

실무에서 거절기를 따로 학습시키지 않더라도 이 생각은 그대로 쓸 수 있다. 첫째, 사람에게 넘긴 사례마다 사람이 내린 최종 결정을 기록해 둔다. 이것이 쌓이면 사례 유형별로 모델과 사람의 정확도를 비교할 수 있다. 둘째, 위임 기준은 신뢰도 문턱값 하나로 두지 않는다. 사례 유형, 금액이나 위험 등급, 검토 인력이 감당할 수 있는 양을 함께 놓고 정한다. 셋째, 위임 기준을 바꿀 때도 2편에서 말한 규칙 변경처럼 버전을 매기고 회귀 테스트를 거친다. 사람이 AI 제안을 보고 판단할 때 생기는 문제와 자동화 수준을 정하는 방법은 4편에서 다룬다.

근거와 감사 추적: 판정마다 무엇을 남기나

판정 기록의 목적은 두 가지다. 하나는 나중에 '왜 이 판정이 나왔나'를 설명하는 것이고, 다른 하나는 같은 조건으로 다시 돌려 같은 결과가 나오는지 확인하는 것이다. 두 목적을 모두 채우려면 결과만이 아니라 결과를 만든 재료와 버전을 남겨야 한다. 판정 한 건마다 남길 항목은 다음과 같다.

입력 스냅숏은 판정 당시의 문서와 입력값 그대로다. 원본이 나중에 고쳐질 수 있으므로 사본이나 해시를 남긴다. 추출된 사실은 LLM이 문서에서 읽어 낸 구조화된 값이다. 적용 규칙 버전은 2편에서 다룬 결정표·정책 코드의 버전이다. 참조 문서는 검색해서 근거로 쓴 문서 조각의 식별자와 그 문서의 버전이다. 모델·프롬프트 버전에는 모델 식별자, 시스템 프롬프트와 예시의 버전, 샘플링 설정을 함께 적는다. 신뢰도 기록에는 값뿐 아니라 산출 방식(자기 보고인지, 몇 번 샘플링한 일관성인지)과 그때 쓴 보정 기준의 버전을 남긴다. 경로는 자동 확정·추가 조회·사람 검토 중 어디로 갔는지다. 사람 개입 기록에는 검토 여부, 검토자, 바꾼 내용과 사유를 남긴다. 마지막으로 고객에게 통보한 최종 결과를 남긴다.

근거 항목은 '있다'로 끝내지 말고 검증한다. 판정 설명이 인용한 조항이나 문서 조각이 실제로 참조 문서 목록에 있는지, 그 조각에 그런 내용이 실제로 들어 있는지를 자동 점검하는 단계를 둔다. 근거 칸도 confidence 칸처럼 형식만 보장될 뿐, 내용이 맞는지는 따로 확인해야 한다.

재현성 점검은 이 기록으로 한다. 저장한 입력 스냅숏을 같은 규칙·모델·프롬프트 버전으로 다시 돌려 판정이 같은지 본다. 규칙 엔진이 맡은 부분은 매번 같아야 한다. LLM이 맡은 추출·설명 부분은 같은 입력에도 출력이 달라질 수 있으므로, 최종 판정이 바뀌는 비율이 허용 범위 안인지를 본다. 서베이논문가 지적하듯 LLM은 예시와 그 순서 같은 프롬프트 변화에 민감하다. 그러니 프롬프트를 조금만 바꿔도 새 버전으로 기록하고 재현성 점검을 다시 해야 한다.

평가: 판정을 무엇으로 재나

출발점은 정답 판정이 있는 평가 세트(Evals)다. 전문가가 확정한 과거 사례를 모으되 쉬운 사례만 넣지 않는다. 확신도 끌어내기 연구논문에서 모든 방법이 전문 지식이 필요한 과제에서 고전했으므로, 업무상 판단이 까다로운 사례와 경계선 사례를 일부러 포함한다. 위임 기준을 평가하려면 그 사례에 대해 사람이 내린 결정도 함께 담는다.

이 세트로 재는 것은 정확도 하나가 아니다. 첫째는 보정이다. 신뢰도 구간별로 실제 정확도를 재서 ECE와 신뢰도 다이어그램으로 보고, NCE처럼 방향을 보는 지표로 과신 쪽인지 확인한다논문. 둘째는 실패 예측이다. AUROC처럼 맞는 판정과 틀린 판정을 신뢰도가 얼마나 잘 가르는지를 본다. 확신도 끌어내기 연구논문에서 보정 오차는 줄었는데 실패 예측은 그대로였듯, 이 두 가지는 따로 움직일 수 있다. 셋째는 일관성이다. 같은 사례를 표현만 바꾸거나 문서 순서만 바꿔 넣었을 때 판정이 유지되는지 본다. 넷째는 집단별 차이다. 고객 집단, 지역, 접수 채널처럼 의미 있는 구간마다 정확도, 자동 확정률, 사람 위임률을 따로 보고, 전체 평균에 가려진 차이를 찾는다. 다섯째는 시간에 따른 표류다. 입력 문서의 모양, 규칙, 모델 버전이 바뀌면 예전에 맞춰 둔 보정 기준이 깨질 수 있다. 운영 중 사람이 확정한 사례를 주기적으로 평가 세트에 더하고 보정을 다시 확인한다.

조직 차원의 틀로는 NIST AI RMF를 참고할 수 있다. NIST 페이지글에 따르면 AI RMF는 AI 제품·서비스·시스템의 설계, 개발, 사용, 평가에 신뢰성 고려 사항을 반영하도록 돕는 자율 적용 프레임워크다. 2023년 1월 26일 공개됐고, 실행 안내서인 Playbook이 함께 나왔다. 2024년 7월 26일에는 생성형 AI 프로파일(NIST-AI-600-1)이 나왔다. 2026년 4월 7일에는 핵심 기반시설용 프로파일의 개념 노트가 공개됐고, AI RMF 1.0은 백악관 AI 행동 계획에 따라 개정 중이다. 이 글이 참고한 페이지 발췌에는 측정·관리 기능의 세부 항목이 나오지 않는다. 그래서 여기서는 위의 평가 항목과 기능별 대응 관계를 단정하지 않는다. 보정·일관성·집단 차이·표류 측정, 위임 기준과 재보정 같은 관리 장치를 정리한 뒤 Playbook을 직접 읽고 사내 위험 관리 항목에 맞춰 보길 권한다.

흔한 실수 점검 목록

가장 흔한 실수는 JSON의 confidence 칸이나 '높음·중간·낮음' 표시를 측정 없이 확률처럼 쓰는 것이다. 여기서 이어지는 실수가 문턱값을 감으로 정하는 것이다. '0.8 이상이면 자동 확정' 같은 규칙은 평가 세트에서 그 구간의 실제 정확도를 확인한 뒤에야 의미가 있다. 연구에서 말로 밝힌 확신도가 80~100%에 몰렸다는 점을 떠올리면, 감으로 정한 문턱값은 거의 모든 사례를 통과시킬 수 있다.

두 번째 묶음은 해결됐다고 착각하는 경우다. 프롬프트로 모델을 겸손하게 만들어 보정 오차가 줄었어도 실패 예측은 그대로일 수 있다. 위임 기준이 모델의 자신감만 보고, 사람이 그 유형을 더 잘 보는지와 검토 인력이 감당할 수 있는 양을 보지 않는 것도 흔하다. 한 번 묻고 답하는 평가 결과를 여러 단계로 움직이는 에이전트의 판정에 그대로 옮기는 것도 같은 종류의 착각이다논문.

세 번째 묶음은 기록과 운영의 빈틈이다. 근거 칸이 있다는 이유로 인용 내용을 검증하지 않는다. 기록에 모델·프롬프트·규칙 버전이 빠져 재현이 안 된다. 평가 세트를 한 번 만들고 갱신하지 않아 표류를 놓친다. 전체 정확도만 보고 집단별 차이를 보지 않는다. 아래 목록을 배포 전과 정기 점검 때 함께 확인한다.

더 공부하려면, 그리고 4편으로

개념부터 잡으려면 LLM 신뢰도 추정·보정 서베이논문의 2장(기본 개념과 지표)을 먼저 읽는다. 상대적·절대적 신뢰도, ECE, 두 종류의 불확실성이 정리돼 있다. 다음으로 확신도 끌어내기 연구논문를 읽으면 닫힌 API만 쓰는 환경에서 무엇을 할 수 있는지 실험으로 볼 수 있다. 과신 평가 연구논문는 짧으니 NCE 지표와 수치 범위의 보정 문제만 확인해도 된다.

불확실성을 설계에 녹이는 법은 능동 신호로서의 불확실성 서베이논문의 설계 패턴 부분에서, 에이전트로 넓힐 때 생기는 어려움은 에이전트 불확실성 정량화 연구논문에서 이어 읽는다. 위임 학습 연구논문는 수학 비중이 크다. 문제 설정과 분류기·거절기 구조까지만 읽어도 이 글의 위임 기준을 이해하는 데 충분하다. 제도 쪽은 NIST AI RMF 페이지글에서 AI RMF 1.0과 Playbook을, OECD AI 원칙글에서 가치 기반 원칙을 확인한다. 구조화된 출력이 무엇을 보장하고 무엇을 보장하지 않는지는 Claude 문서글에서 직접 확인할 수 있다.

이번 편은 신뢰도와 근거를 측정할 수 있는 값으로 만드는 데 집중했다. 그런데 측정이 끝나도 '어떤 판정을 사람에게 남겨야 하나', '사람은 AI 제안을 얼마나 따라가나', '규제는 사람의 역할을 어떻게 요구하나'라는 질문은 남는다. 4편 '사람은 어디에 서나: 자동화 수준·규제·사례'에서 이 질문들을 다룬다.