PG 북 개발 스토리 ⑦ — 자신 있게 틀린 답을 다루는 법
2026-09-07
저는 PG 북스튜디오를 개발하면서 AI가 자신 있게 틀린 답을 내어 놓은 경우를 자주 접합니다. 한 번은 이벤트 참여자들에게 보내는 메일 내용 중 내려받기 링크 주소가 있었는데, 클로드 코드가 매우 분명하고 자신 있게 그 주소가 맞다고 대답했습니다.
답변 형식과 내용을 신뢰가 가서, 저는 링크 주소가 맞는지 확인하지 않고 그대로 활용했는데, 그것은 나흘 전 체험판의 링크 주소였고 이미 폐기되어 있었습니다. 저는 그 폐기된 링크 주소를 활용하여 다운로드 받으라고 말을 하고 있었습니다.
그때 저는 그것을 "AI가 없는 것을 지어낸다"라고 판단했고, 그래서 없는 것을 지어내지 말라고 지시문에 적었습니다.
그런데 그 지시는 아무것도 바꾸지 못했는데, 사람과 달리 틀린 답이 자신 없는 말투나 형식으로 오지 않았기 때문입니다.
제가 그 대답을 의심 없이 받아들인 이유는 내용이 아니라 말투와 형식이었습니다. 주소가 끝까지 적혀 있고 문장이 단정하면 저는 가끔씩 귀찮아서 확인 작업을 건너뛰었습니다. 사람이 해야 할 가장 중요한 작업이 확인하고 판단하는 것이었는데 너무 쉽게 믿었던 것입니다.
나중에 확인해 보니 링크의 주소는 두 곳에 적혀 있었는데, AI는 한쪽만 수정했던 것이었습니다. 새 주소는 그날 저녁 문서에 제대로 적혔는데, 어제 남긴 메모는 옛 주소를 그대로 들고 있었고 AI는 메모만을 확인했습니다. 문제는 AI의 확신이 아니라 제가 확신을 근거로 읽고 있었다는 것이었습니다.
저는 답을 받을 때 세 가지로 나눠 놓고 각각 다르게 다루기로 했는데, 나누는 기준은 "이 값이 어디서 왔는가"입니다.
```
🟢 원문 확인 내가 원본 파일이나 원문을 열어서 그 문장을 눈으로 봤다 → 그대로 쓴다
🟡 서지 확인 출처 이름과 자리만 안다. 본문은 아직 안 봤다 → 아직 원고에 못 넣는다
🔴 미확인 기억이나 요약에서 왔다 → 원고에 안 넣고 후보로만 둔다
```
그리고 규칙을 하나 더 두었는데, "주소와 숫자와 날짜는 인용하기 전에 살아 있는지 한 번 열어 본다"입니다. 주소 하나를 여는 데는 1초면 됩니다. 저는 이런 값에서만 사고가 났고, 이런 값은 검색하면 그럴듯하게 맞아 보이기 때문에 지어낸 값보다 고치기가 어려웠습니다. 그래서 틀린 것이 나오면 "실패 로그"에 그날 바로 한 줄을 적어 두는데, 같은 종류로 다섯 건이 모이면 규칙 자체를 고칩니다.
나중에 알았는데 이 습관에는 근거가 있었습니다. Xiong 등의 연구(ICLR 2024)는 모델에게 "이 답을 얼마나 확신하는가"를 말로 물어 그 답을 모아 봤는데, 확신도가 80퍼센트에서 100퍼센트 사이에 몰렸고 대개 5의 배수로 나왔습니다. 연구진은 모델이 사람의 말버릇을 흉내 내고 있는 것일 수 있다고 적었습니다.
읽고 나서 저는 확신도를 물어보는 것을 그만두었는데, 말로 하는 확신은 근거가 아니라 말투와 형식이기 때문입니다.
AI가 준 답에서 숫자·날짜·이름에만 밑줄을 그어 보십시오. 이 세 가지만 확인하면 확인해야 할 양이 크게 줄고, 저는 이렇게 되묻습니다.
```
🔴 안 묻는 것 "확실한가요?" → 거의 언제나 "확실합니다"가 돌아옵니다
🟢 묻는 것 "이 값이 적힌 파일 이름과 그 줄을 그대로 보여 주십시오"
🟢 묻는 것 "그 주소를 지금 한 번 열어 보고 살아 있는지 알려 주십시오"
🟢 묻는 것 "원문에서 이 문장을 그대로 옮겨 주십시오. 없으면 없다고 적어 주십시오"
```
말투를 묻는 대신 자리를 물으면 답이 달라집니다. 없는 것은 그때 "없습니다"로 돌아오고, 저는 그 한 번만 되물었어도 하루를 아꼈을 것입니다.
PG 북스튜디오를 개발하면서 제가 마지막 단계에서 가장 자주 하는 확인 질문은 세 가지를 말씀드렸습니다.
다음 편에서는 "했습니다"라는 답과 실제로 된 것 사이를 어떻게 확인하는지 적겠습니다.
출처 — Xiong 외, Can LLMs Express Their Uncertainty? (ICLR 2024) · https://arxiv.org/abs/2306.13063