고객 문의에 자동으로 답하는 에이전트를 만들었다고 해 보자. 모델이 엉뚱한 소리를 지어낼까 봐 걱정돼서 시스템 프롬프트 맨 끝에 지침을 한 줄 덧붙인다. “답변과 함께 네 확신도를 0에서 1 사이의 숫자로 적어라.” 그리고 이 숫자가 0.8보다 낮으면 상담원에게 넘기도록 분기문을 짠다. 얼핏 보면 꽤 그럴듯한 안전장치 같다.
그런데 몇 번 테스트를 돌려 보다 보면 이상한 풍경을 마주하게 된다. 방금 전까지 확신도 0.85를 찍어 주던 똑같은 질문을 다시 보냈더니 이번에는 난데없이 0.7을 내놓는다. 질문 내용도 그대로고 검색해서 붙여 준 참고 문서도 토씨 하나 안 바뀌었는데 말이다. 심지어 뒤에 “정말 확실해?”라는 한마디만 덧붙여도 숫자가 갈대처럼 흔들린다. 과연 이런 숫자를 믿고 사람 호출 여부를 결정해도 괜찮은 걸까.
엔지니어 Amrut Joshi는 2026년 10월에 쓴 글 “Asking LLM for confidence”에서 이 방식에 단호하게 선을 긋는다. 모델이 스스로 적어 내는 확신도 숫자는 믿을 근거가 전혀 없다는 것이다. 왜 그 숫자가 정교한 계산이 아니라 그저 그럴듯하게 이어 붙인 낱말에 불과한지, 그리고 모델 바깥에서 진짜로 믿을 수 있는 점수를 만들려면 어떻게 해야 하는지 차근차근 짚어 본다.
기상 예보관의 70%는 정보와 규칙에서 나온다
일기예보관이 뉴스에 나와 “내일 비가 올 확률은 70%입니다”라고 말할 때 그 숫자는 어디서 나왔을까. 바로 예보관이 손에 쥔 관측 정보에서 나온다. 현재 기압 배치와 구름의 이동 속도, 그리고 과거에 이와 비슷한 날씨 조건이었을 때 실제로 비가 얼마나 자주 내렸는지 기록해 둔 통계 자료다. 이 재료들을 정해진 계산 공식에 집어넣어 돌리면 70%라는 값이 떨어진다.
다시 말해 제대로 된 확신도는 계산의 산물이다. 똑같은 계산 규칙을 쓰는 두 예보관에게 똑같은 기상 데이터를 쥐여 준다면 둘은 반드시 같은 숫자를 내놓아야 한다. 만약 두 사람의 답이 갈렸다면 한쪽이 덜컥 다른 데이터를 봤거나 계산 규칙을 잘못 적용했다는 뜻이다. 그날 예보관 기분이 좋다고 해서 확률에 10%를 덤으로 얹어 주는 일은 일어나지 않는다.
당장 손에 쥔 정보가 하나도 없을 때를 떠올려 보면 이 원리가 더 또렷해진다. 지금 당장 2주 뒤의 날씨를 물어보면 예보관에게도 쓸 만한 관측 데이터가 없다. 이럴 때 예보관은 과거 이맘때의 계절 평균치로 돌아간다. 예컨대 예년 이 계절에 열흘 중 사흘꼴로 비가 왔다면 그냥 30%라고 답하는 식이다. 그러다 약속한 날짜가 가까워져 기압과 바람 데이터가 하나둘 들어오면 숫자는 비가 안 온다는 0% 쪽이나 꼭 온다는 100% 쪽으로 성큼성큼 움직인다. 결국 믿을 만한 확신도란 그 예측이 지금 얼마나 많은 정보 위에 서 있는지를 그대로 비추는 거울이다.
점수가 정확한지는 한 번의 결과로는 알 수 없다
내일 비 올 확률이 70%라는 예보가 맞았는지 틀렸는지는 내일 하루만 봐서는 판정할 수 없다. 내일 실제로 비가 내리든 맑게 개든 “70% 확률”이라는 말 자체와는 모순되지 않기 때문이다. 그래서 확신도 점수가 얼마나 믿을 만한지는 지난 예측들을 수백 개씩 모아 놓고 사후에 대조해 봐야 비로소 드러난다. 1년 치 일기예보를 모아서 성적표를 매겨 보면 아래와 같은 표가 나온다.
| 말한 확률 | 날 수 | 실제로 비 온 날 | 비율 |
|---|---|---|---|
| 10% | 120 | 13 | 11% |
| 30% | 90 | 26 | 29% |
| 70% | 80 | 57 | 71% |
| 90% | 75 | 67 | 89% |
예보관이 10%라고 예보했던 120일 가운데 실제로 비가 내린 날은 13일, 즉 11%다. 90%라고 장담했던 75일 중에는 67일 동안 비가 내려 실제 비율이 89%를 기록했다. 예보관이 입 밖으로 꺼낸 확률과 실제로 비가 내린 비율이 거의 정확하게 포개진다. 통계학에서는 이렇게 예측 확률과 실제 정답률이 잘 맞아떨어지는 상태를 두고 ‘보정(calibration)이 잘되었다’고 부른다. 반대로 70%라고 호언장담한 날들을 모았는데 정작 절반밖에 비가 안 왔다면 그 예보관은 자기 실력보다 자신감이 과한 셈이다. 이런 성적표가 눈앞에 있어야만 그 숫자를 믿고 우산을 챙길지 말지 결정할 수 있다.
물론 보정이 잘되었다는 것만으로는 충분하지 않다. 1년 내내 날씨도 안 보고 매일 앵무새처럼 “비 올 확률 30%”라고만 외치는 예보관을 상상해 보자. 계절 평균 강수 확률이 원래 30%라면 이 게으른 예보관도 연말에 표를 그려 보면 보정이 완벽하게 된 것처럼 나온다. 하지만 그날그날의 기상 정보를 하나도 반영하지 않았으니 예보로서는 아무런 가치가 없다. 진짜 실력 있는 예보관은 보정도 정확하면서 매일 들어오는 정보를 적극 활용하기 때문에 예측값이 애매한 중간 지대가 아니라 0%나 100% 같은 양 끝단에 많이 몰린다.
결국 우리가 어떤 확신도 숫자를 믿으려면 두 가지 조건이 동시에 만족되어야 한다. 지금 가진 정보의 양에 따라 숫자가 일관되게 움직여야 하고 같은 종류의 문제를 충분히 많이 풀어 본 뒤 실제 정답률과 대조해 검증을 마쳐야 한다. 이제 이 두 가지 잣대를 들고 LLM이 내놓는 숫자를 다시 들여다보자.
LLM이 내놓는 0.85는 다음 글자를 이어 붙인 결과다
대규모 언어 모델(LLM)은 본질적으로 글자(토큰)를 한 번에 하나씩 이어 붙여 문장을 완성하는 기계다. 앞쪽에 이미 적힌 단어들을 쭉 훑어본 뒤 그다음 자리에 오기에 가장 자연스러운 단어를 확률적으로 골라내는 작업을 끝없이 반복한다. 프롬프트로 “확신도를 적어라”고 시켰을 때 화면에 0.85가 찍혔다면 그건 모델 내부의 정밀한 계기판을 읽어서 출력한 값이 아니다. 그냥 그 문맥에서 다음에 이어질 가장 그럴듯한 문자열로 0, ., 8, 5를 골라냈을 뿐이다.
앞서 확인한 두 가지 조건에 이 숫자를 비춰 보면 두 항목 모두 낙제점이다. 이 0.85는 모델이 참고한 정보의 양을 정해진 공식으로 요약한 값도 아니고 우리 서비스의 실제 정답률 데이터와 맞춰 본 적도 없다. 언어 모델은 수조 개의 문장을 읽으며 “다음에 어떤 단어가 와야 자연스러운가”를 맞히도록 훈련받았을 뿐 자기가 말한 숫자가 실제 정답 비율과 일치하도록 훈련받지 않았다.
이 태생적 한계는 조금만 건드려 봐도 금세 탄로 난다. 똑같은 질문을 다시 던졌는데 0.85가 0.7로 바뀌는 건 매번 다음 글자를 뽑을 때 주사위를 굴리는 샘플링 과정이 들어가기 때문이다. 주어진 정보는 티끌만큼도 안 바뀌었는데 숫자만 혼자 널을 뛴다. 사용자가 “정말 확실해?”라고 한마디 되물으면 질문의 말투가 바뀌었으니 그에 맞춰 숫자도 덩달아 내려간다. 반대로 모델이 앞 문장에 “이 답변은 명백한 사실입니다”처럼 단정적인 표현을 먼저 써 버렸다면 그 문장 뒤에는 높은 숫자가 붙는 게 글의 흐름상 자연스럽기 때문에 아무 근거 없이 0.95 같은 높은 숫자를 적어 낸다. 정보가 숫자를 결정하는 게 아니라 앞선 문장의 분위기가 숫자를 끌고 가는 셈이다.
가장 고약한 문제는 이 가짜 숫자가 겉보기에는 너무나 정밀해 보인다는 점이다. 모델은 아무 근거가 없을 때도 주저 없이 소수점 둘째 자리까지 찍힌 숫자를 내밀고 완전히 틀린 답을 말할 때도 맞는 답을 말할 때와 똑같이 당당한 숫자를 붙인다. 이 숫자가 정말로 맞는지 확인하려면 결국 수백 개의 답변을 모아 일일이 정답지와 대조해 보는 수밖에 없는데 정작 프롬프트 한 줄로 확신도를 얻으려는 팀일수록 그런 검증 작업은 건너뛰기 일쑤다. 결국 모델이 스스로 적어 낸 0.85라는 숫자는 정밀한 척 연기하는 문장일 뿐 그 뒤에는 아무런 계산도 검증도 없다.
믿을 수 있는 점수는 모델 밖에서 계산한다
그렇다면 실무에서는 이 문제를 어떻게 풀어야 할까. 해법은 의외로 단순하다. 모델에게 자기 점수를 매기라고 묻는 일을 그만두고 모델 바깥의 코드에서 직접 점수를 계산하는 규칙을 만드는 것이다. 답변 문장을 작성하는 일은 기존처럼 LLM에게 맡기되 그 답변을 얼마나 믿을지 판단하는 점수판은 우리가 통제할 수 있는 바깥 시스템에 따로 세운다. 도움말 문서를 검색해 고객에게 답하는 지원 에이전트를 예로 들면 전체 과정은 다섯 단계로 굴러간다.
첫째는 점수 계산에 쓸 ‘관찰 가능한 신호’를 고르는 단계다. 모델의 주관적인 자기 평가는 철저히 배제하고 바깥 코드에서 객관적으로 측정할 수 있는 사실만 재료로 삼는다. 검색 엔진이 질문과 딱 맞는 도움말 문서를 찾아냈는지, 관련 문서가 몇 개나 걸렸는지, 과거에 이와 비슷한 질문을 성공적으로 처리한 적이 있는지, 혹은 같은 질문을 모델에 세 번 던졌을 때 세 번 모두 같은 취지의 답이 나오는지를 확인하는 식이다. 이어지는 둘째 단계에서는 과거의 전체 평균 성적에서 소박하게 출발한다. 아직 세세한 규칙을 만들 데이터가 없는 초기라면 일단 지난 답변 200개를 사람이 직접 채점해 본다. 그중 150개가 정답이었다면 당분간은 새로 나가는 모든 답변의 기본 확신도를 일괄 75%로 잡는다. 기상 예보관이 정보가 없을 때 계절 평균 30%를 부르는 것과 똑같은 이치다.
셋째 단계부터는 나가는 모든 답변의 발자취를 꼼꼼히 기록한다. 당시 검색에서 잡힌 신호들과 우리 규칙이 매긴 확신도 점수, 그리고 나중에 확인한 실제 정답 여부를 한 세트로 묶어 저장한다. 내부 검토자가 답변을 승인했거나 고객이 추가 항의 없이 상담을 끝냈다면 정답으로 기록하면 된다. 이렇게 데이터가 쌓이면 넷째 단계에서 그 기록을 바탕으로 점수 규칙을 세밀하게 쪼갠다. 과거 답변들을 신호 조합별로 묶어서 각 묶음의 실제 정답률을 다시 계산하는 것이다. 예컨대 “일치하는 문서가 있고 두 번 생성한 답이 똑같았던 경우”의 실제 정답률이 95%였다면 앞으로 똑같은 신호가 잡힌 답변에는 95%를 부여한다. 반대로 “검색된 문서가 하나도 없던 경우”의 정답률이 40%에 그쳤다면 그 조건에는 가차 없이 40%를 매긴다. 처음에는 분류가 거칠지만 기록이 쌓일수록 규칙은 점점 정교해진다.
마지막 다섯째 단계는 매주 일기예보 성적표 같은 보정표를 뽑아 보며 규칙을 점검하는 일이다. 우리 규칙이 90% 점수를 준 답변들을 모았는데 실제로는 70%만 맞았다면 규칙이 지나치게 낙관적이라는 신호다. 모든 입력 신호와 결과가 기록되어 있으니 어느 조건에서 점수가 부풀려졌는지 역추적해 고치기도 쉽다. 이렇게 모델 바깥에서 만든 점수는 입력 정보가 같으면 언제나 흔들림 없이 똑같은 값을 내놓는다. 질문 끝자락의 말투에 휘둘리지 않고 실제 우리 팀이 겪은 데이터로 검증된 진짜 확신도다.
정답을 채점해 쌓은 기록이 점수를 만든다
돌아보면 우리가 확신도라는 숫자에 기대하는 바는 처음부터 분명했다. 지금 손에 쥔 정보의 양을 정직하게 반영할 것, 그리고 과거의 실제 결과와 대조해 그 정확성이 입증되어 있을 것. LLM이 답변 끝에 덧붙이는 숫자는 이 두 가지 중 어느 쪽도 만족시키지 못한다. 그저 앞 문장의 말투에 어울리는 다음 글자를 뽑아낸 결과이기에 사용자가 살짝 되묻기만 해도 숫자가 바뀐다.
물론 모델 바깥에 점수 계산 규칙을 세운다고 해서 모든 게 마법처럼 자동화되는 건 아니다. 이 다섯 단계 순환 구조가 제대로 돌아가려면 가장 밑바닥에 반드시 한 가지 재료가 깔려 있어야 한다. 바로 나간 답변이 실제로 맞았는지 틀렸는지 사후에 확인해 적어 두는 기록이다. 정답 여부가 기록되지 않으면 초기 평균치를 계산할 수도 없고 신호별 정답률을 업데이트할 수도 없으며 주간 보정표를 그려 볼 수도 없다.
프롬프트 끝에 “확신도를 0에서 1 사이로 적어라”고 한 줄 치는 건 당장 돈도 시간도 안 드는 공짜 해법처럼 보인다. 하지만 세상에 공짜로 얻어지는 신뢰는 없다. 에이전트의 답변을 정말로 숫자에 기대어 걸러 내고 싶다면 모델에게 점수를 물어보는 대신 우리가 내보낸 답변들을 꾸준히 채점하고 기록하는 정직한 수고부터 시작해야 한다.
출처: Amrut Joshi, Asking LLM for confidence, 2026년 10월 20일. GeekNews 소개 글