언어모델이 자기 답을 얼마나 믿어도 되는지 가늠하는 새로운 방법이 나왔다. 발상은 간단하다. 모델이 그동안 쌓아 온 과거 경험(일종의 성적표)을 함께 꺼내 보고 "이 답이 맞을 확률"을 매긴다. 저자들은 이 방법을 XConf(eXperiential Confidence, 경험적 확신도)라 부른다. 성과부터 말하면, 아홉 개 벤치마크 대부분에서 확신도를 기존 방식보다 더 잘 맞히면서도 비용은 훨씬 적게 들었다.
언어모델을 실제 서비스에 올릴 때 늘 부딪히는 질문이 있다. "이 답을 그냥 내보내도 되는가, 사람에게 넘겨야 하는가, 다시 시도해야 하는가." 이 판단의 근거가 바로 확신도(confidence) 추정이다. 모델이 "이 답은 90% 맞다"고 말했을 때 실제로 열 번 중 아홉 번은 맞아야, 그 숫자를 믿고 자동화를 맡길 수 있다. 말한 확률과 실제 정답률이 이렇게 들어맞는 성질을 보정(calibration, 캘리브레이션)이라고 한다.
보정이 왜 중요한지는 틀렸을 때를 떠올리면 분명해진다. 모델이 "90% 확신"이라던 답이 실제로는 절반밖에 안 맞는다면, 그 숫자를 믿고 돌린 자동화는 통째로 오작동하거나 막대한 비용 손실로 이어진다. 확신도는 단순한 참고 수치가 아니라 자동화의 안전장치인 셈이다.
그런데 기존 확신도 추정 기법들은 하나같이 같은 약점을 공유한다. 오직 지금 진행 중인 추론 한 번만 들여다본다는 점이다. 방식은 셋으로 나뉜다. 모델에게 "너 이거 얼마나 확신해?"라고 되묻거나, 생성된 글자들의 확률을 점수로 매기거나, 같은 질문을 여러 번 다시 풀게 해서 답이 얼마나 일치하는지 본다. 세 번째가 흔히 쓰이는 자기일관성(self-consistency)인데, 10번 다시 풀게 하면 생성 비용도 10배로 든다.
세 방식 모두에 빠진 것은 자기 이력이다. 시험장에서 한 문제를 풀며 "내가 이걸 맞혔을까?"를 그 문제만 노려보며 판단하는 학생을 떠올리면 된다. 정작 결정적인 정보 — "나는 이런 유형에서 자신 있다고 했다가 자주 틀렸다" — 는 완전히 빠져 있다. 사람은 경험이 쌓이면 "이 정도 확신할 때 나는 대체로 맞더라" 혹은 "이럴 때 꼭 방심하더라"를 안다. XConf는 바로 이 빈자리를 채운다.
XConf는 모델에게 개인 성적표를 쥐여주고, 새 문제를 만났을 때 그 성적표를 펼쳐 보게 한다. 먼저 어떻게 동작하는지 본 뒤, 왜 현실적인지를 짚자.
출발점은 경험을 저장하는 방식이다. 모델은 과거에 풀었던 문제 하나하나를 에피소드(episode)로 남긴다. 마치 학생이 오답 노트를 쓰듯, 어떤 문제였고(과제) 그때 무슨 생각을 했으며(성찰) 얼마나 자신했고(확신도) 결과는 어땠는지(정답 여부), 끝으로 채점 뒤 무엇을 배웠는지(교훈)를 하나의 '경험'으로 적어 두는 것이다. "이 유형, 80% 확신했는데 틀림, 원인은 조건 하나 놓침" 같은 한 줄이 쌓여 성적표가 된다.
새 과제가 들어오면 두 단계로 작동한다. 먼저 회상(Recall) 단계에서, 지금 과제와 비슷한 유형이면서 비슷한 확신도로 임했던 과거 에피소드들을 꺼내 와 그것들이 실제로 몇 퍼센트나 맞았는지(역사적 성공률)를 읽는다. "예전에 이만큼 자신 있다고 했을 때, 진짜로는 얼마나 맞았지?"를 데이터로 확인하는 것이다. 이어 성찰(Reflect) 단계에서, 모델은 그 기록을 보며 자신이 반복적으로 저지르는 실패 유형에 스스로 이름을 붙이고, 그 이력을 반영해 확신도를 다시 말한다. 방금 뽑은 답에 대한 순진한 자신감이 아니라, "나는 이런 상황에서 과대평가하는 버릇이 있으니 낮춰 말하겠다"처럼 자기 실적으로 교정된 확신도가 나온다.
이 구조는 낯익은 패러다임을 비튼 것이다. 검색증강생성(RAG, 외부 지식을 검색해 답에 끌어오는 기법)이 '지식'의 외부 기억장치라면, XConf는 '판단'의 외부 기억장치다. 끌어오는 대상이 바깥 지식에서 자기 이력으로 바뀌었을 뿐 검색해서 가져다 쓴다는 뼈대는 같은데, 이 한 끗 차이가 의미심장하다. AI가 단순히 더 똑똑해지는 것을 넘어, 자기 과거를 돌아보며 스스로를 점검하는 메타인지 단계로 들어서고 있다는 신호이기 때문이다.
작동 원리에서 세 가지 강점이 따라온다. 첫째, 형식을 가리지 않는다(format-general). 정답이 숫자든 코드든 자유 서술이든 그대로 적용된다. 둘째, 모델 내부를 열어 볼 필요가 없다. 글자 확률값(로짓)에 접근하거나 가중치를 다시 학습시키는 과정이 전혀 없어, API로만 붙여 쓰는 폐쇄형 상용 모델에도 그대로 얹을 수 있다. 셋째, 답을 한 번 생성한 뒤 짧은 성찰 호출을 한 번 더 하는 정도라, 같은 질문을 10번 다시 푸는 자기일관성과는 체급이 다르다.
평가는 추론·코딩·멀티모달 QA(이미지와 글을 함께 보고 답하는 문제)·상호작용 에이전트(여러 단계에 걸쳐 도구를 쓰며 과제를 풀어가는 AI)에 걸친 9개 벤치마크, 그리고 세 개 계열에서 뽑은 네 개 모델에서 이뤄졌다. 성과는 세 축으로 나뉜다.
먼저 판별력이다. 맞은 답과 틀린 답을 확신도로 얼마나 잘 갈라내는지를 재는 AUROC 지표를 보자. 한 번에 답하는 비에이전트 과제는 6개 벤치마크에 4개 모델, 곧 24개 조합에서 10-샘플 자기일관성과 맞붙였다. 결과는 21승 2무 1패로, 24개 중 23개에서 앞서거나 대등했다. 에이전트 과제 3개 벤치마크에서는 10회 재실행 대신 별도 기준선들과 비교했다.
다음은 보정 오차다. 말한 확률과 실제 정답률의 어긋남을 재는 ECE(Expected Calibration Error)가 훨씬 낮았다. "90% 확신"이 실제 90%에 더 가까워졌다는 뜻이다.
비용은 이 글의 처음과 끝을 잇는 대목이다. XConf는 위 성과를 자기일관성 대비 답변 생성 횟수 10분의 1로 해냈다. 다만 이 "10분의 1"은 답변 생성 횟수만 센 값이다. 과거를 회상하려면 임베딩(글을 숫자 벡터로 바꿔 유사한 것을 찾는 기술)과 검색이 필요하고 그 비용이 부록 L에 따로 명시돼 있어, 전체 API 비용이 정확히 10분의 1로 떨어지는 것은 아니다. 그럼에도 같은 질문을 10번 다시 푸는 방식보다는 전체적으로 훨씬 효율적이다.
가장 실전적으로 와닿는 결과는 선택적 예측에서 나온다. 여기서 주의할 것은 앞의 판별력·보정 성과가 '확신도를 잘 맞혔다'는 이야기이지 답 자체의 정답률이 올랐다는 뜻은 아니라는 점이다. 선택적 예측은 이 잘 맞힌 확신도를 어디에 쓰는지를 보여 준다. 확신도가 가장 낮은 하위 10% 에피소드에 대해 답을 내지 않고 보류(abstain)했더니, 실제로 전달된 답들의 성공률이 에이전트 과제에서 최대 8.7포인트까지 올랐다. 자신 없는 것만 골라 걸러 내는 것만으로 전달 품질이 눈에 띄게 좋아진 것이다. 무엇을 내보내고, 무엇을 상위 단계로 넘기고, 무엇을 다시 시도할지를 정하는 실무 판단에 바로 연결되는 숫자이며, 특히 다단계로 도구를 쓰는 에이전트 과제에서 효과가 두드러졌다.
더 적은 비용으로 확신도를 더 잘 맞혔다는 점, 이것이 경험적 확신도 추정을 범용 확신도 추정의 다음 후보로 올려놓는 핵심이다.
실제 제품에 얹기 전에 검토해야 할 구조적 한계가 몇 가지 있다. 아래는 초록에 수치로 적힌 내용이 아니라, 방법의 설계에서 따라오는 물음이다.
온틀은 고객 프로젝트마다 AI 프로젝트 매니저를 파견하는 서비스다. AI PM이 사람 대신 판단하고 일을 넘긴다면, 가장 위험한 순간은 "틀렸는데 자신 있게 밀어붙이는" 때다. 그렇다면 온틀의 AI PM이 XConf를 탑재하면 무슨 일이 벌어질까.
고객이 외부 시스템 연동을 요청하고, AI PM이 "이건 반나절이면 됩니다"라고 답하려는 순간을 그려 보자. 답을 내보내기 전에 모델은 자기 성적표를 펼친다. "비슷하게 간단해 보였던 연동 작업에서, 나는 실제로 몇 번이나 일정을 맞췄지?" 과거에 같은 호언을 했다가 자주 틀렸다면 확신도를 스스로 낮춰 잡고, 이 건을 자동 처리 대신 사람 담당자에게 올린다(에스컬레이션, 즉 현장에서 애매한 건을 상위 담당자에게 넘기는 것). 과거 기록 조회 → 확신도 수정 → 사람에게 인계로 이어지는 흐름이 그대로 보류·에스컬레이션 설계가 된다. 애매한 것만 사람에게, 확실한 것은 자동으로.
마침 온틀 같은 제품은 이미 프로젝트 이력과 작업 결과를 쌓는다. XConf는 이 이력을 확신도 교정용 '경험 저장소'로 재활용하자는 발상과 맞닿아 있고, 로짓 접근도 재학습도 필요 없이 짧은 성찰 호출만 더하면 된다는 점은 상용 모델을 API로 붙여 쓰는 제품 환경과 잘 맞는다.
다만 논문의 벤치마크 성과가 곧 이 워크플로우의 보증은 아니다. 하위 10% 보류를 실제 업무 자동화에 적용하려면 앞서 짚은 한계가 그대로 검증 과제가 된다. 성적표가 충분히 쌓였는지(콜드 스타트), 과제 분포가 안정적인지(분포 이동), "비슷한 과제"를 제대로 판정하는지(유사성 기준)를 먼저 맞춰야 보류 판단을 믿고 자동화를 맡길 수 있다. 그럼에도 "지금 한 번의 추론이 아니라 쌓인 경험으로 확신을 매긴다"는 방향은, 신뢰할 수 있는 자동화를 지향하는 제품에 분명한 참고점이다.
아니요. 가중치 업데이트나 로짓 접근 없이 동작하므로(원문 §5.1 기준), API로만 접근하는 폐쇄형 모델에도 추가 학습 없이 바로 적용할 수 있습니다.
답변 생성 횟수를 10분의 1로 줄입니다. 다만 과거를 회상하는 임베딩·검색 비용이 추가되므로(부록 L) 전체 API 비용이 정확히 10분의 1이 되지는 않습니다. 그래도 같은 질문을 10번 다시 푸는 방식보다는 효율적입니다.