AI 답변이 맞는지 확인하는 5가지 방법: 출처·재질문·검산·교차 확인·미확인 표시

AI는 왜 그럴듯하게 틀릴까?

거래처에 보낼 안내문을 AI에게 맡겼는데, 결과물이 너무 매끈합니다.
날짜도 숫자도 척척 들어 있고 어색한 구석이 하나도 없어요.
보내기 직전에 '이거 진짜 맞나?' 하는 생각이 스치면서 손이 멈춥니다.
한 번쯤 겪어 보셨을 법한 순간이죠.

그 불안은 근거가 있습니다.
대화형 AI는 질문을 받으면 '그럴듯하게 이어질 문장'을 만들어 냅니다.
사실이 저장된 사전을 찾아 읽는 방식이 아니라서, 아는 내용과 모르는 내용이 같은 말투로 나옵니다.
모르는 부분을 그럴듯하게 채우는 현상을 흔히 '환각'이라고 부르는데, 서비스마다 정도는 달라도 틀리지 않는다고 보장해 주는 곳은 없습니다.

그렇다고 AI를 믿지 말자는 얘기는 아닙니다.
맞는지 가려내는 데 드는 시간을 줄이자는 쪽입니다.
방법 1부터 보겠습니다.

방법 1: 출처를 묻고 직접 열어 볼 수 있나?

AI에게 "이 내용의 출처를 알려 줘"라고 물으면 주소나 문서 이름을 줍니다.
문제는 그 주소가 실제로 있는지 모른다는 점입니다.
없는 주소를 만들어 낼 수도 있어서, 받은 출처는 직접 열어 봐야 의미가 있습니다.

저희는 먼저 이렇게 물어 봤습니다.
"HTTP 상태 코드 418은 무엇을 뜻하나요?" AI는 확인 전에 이렇게 답했고, 저희는 그 답을 먼저 적어 두었습니다.
"나는 찻주전자입니다"라는 뜻이고, 1998년 4월 1일에 나온 만우절 문서 RFC 2324에서 왔으며, 지금 표준 표에는 '사용 안 함'으로 올라 있다는 내용이었어요.

이 답에서 따져 볼 곳은 '표준 표'였습니다.
인터넷 번호 관리 기관(IANA)의 상태 코드 표를 열어 418 행을 찾으니 "(Unused)"라고 적혀 있었습니다.
답의 뒷부분이 맞다는 근거를 눈으로 본 셈입니다.
다만 '1998년 4월 1일'은 처음 쓸 때 열어 보지 못했습니다.
그 날짜는 원문을 보기 전까지 사실로 쓰지 않았는데, 이 이야기는 방법 5에서 이어집니다.

출처가 없는 답이라면 질문을 바꿔 봅니다.

방법 2: 같은 질문을 다르게 두 번 물으면?

같은 질문을 말만 바꿔 다시 물었을 때 답이 달라지면, 어느 한쪽은 지어낸 것일 수 있습니다.
새 대화창에서 물으면 앞 대화의 영향을 덜 받아서 더 좋고요.

저희는 파이썬 질문으로 해 봤습니다.
처음엔 "파이썬에서 round(2.5)의 결과는?"이라고 묻고, 이어서 "파이썬은 .5로 끝나는 수를 올림하나요, 짝수 쪽으로 맞추나요?"라고 다시 물었습니다.
두 답은 같은 결론, 그러니까 2이고 짝수 쪽이라는 쪽으로 모였어요.

여기서 안심이 조금 늘 뿐이라는 점은 짚어 두고 싶습니다.
같은 AI는 같은 착각을 되풀이할 수 있기 때문에, 이 방법은 틀림을 발견하는 데는 좋아도 맞다는 증명은 못 합니다. 답이 갈릴 때만 큰 신호로 보시면 됩니다.

방법 3: 숫자·날짜·이름만 따로 검산하려면?

답 전체를 의심하기 시작하면 금방 지칩니다.
그래서 숫자, 날짜, 고유명사만 골라 따로 확인하는 편이 훨씬 빠릅니다.
틀렸을 때 피해가 큰 부분이 대개 거기 몰려 있거든요.

파이썬 질문은 계산을 직접 돌려 볼 수 있어서 좋은 재료였습니다.
AI는 round(2.5)=2, round(0.5)=0, round(1.5)=2, round(2.675, 2)=2.67이라고 답했고, 저희가 실제로 실행하니 똑같이 2 0 2 2.67이 나왔습니다.
마지막 값은 흔히 2.68로 착각하는 자리입니다.
2.675가 컴퓨터 안에서 2.67499999…로 저장되기 때문인데, AI가 이 이유까지 짚은 게 인상적이었습니다.

계산이 아닌 숫자는 원문에서 같은 숫자를 찾아 눈으로 맞춰 봅니다.
표로 옮길 때는 숫자 칸만 따로 대조하면 시간이 꽤 줄어듭니다.

방법 4: 다른 AI나 검색으로 교차 확인하려면?

서로 다른 길로 확인한다는 뜻입니다.
다른 AI에게 같은 질문을 하거나, 검색해서 공식 자료와 맞춰 봅니다.
같은 회사의 AI끼리는 같은 자료로 배웠을 수 있으니, 가능하면 AI 한 번, 사람이 쓴 원문 한 번으로 나누는 쪽을 권합니다.

저희 실험에서는 "HTTP 상태 코드를 정의한 최신 문서와 발행 시기"를 물었고, "RFC 9110, 2022년 6월"이라는 답을 얻었습니다.
RFC 편집부 페이지에서는 제목이 'HTTP Semantics', 발행이 2022년 6월, 지위가 인터넷 표준(Internet Standard)으로 나와 있었어요.
다만 이번에는 다른 AI를 쓰지 않고 공식 원문 대조만 했다는 점은 밝혀 둡니다.

방법 5: 확인할 수 없는 답은 어떻게 표시하나?

끝내 확인하지 못한 내용은 지우기보다 '미확인'으로 표시해 두는 편이 안전합니다.
나중에 같은 내용을 다시 쓸 때 사실처럼 굳어지는 걸 막아 주니까요.

앞서 말한 418 예시의 '1998년 4월 1일'이 딱 그랬습니다.
초안에서는 미확인으로 남겨 두었고, 검수 때 RFC 편집부의 RFC 2324 원문 머리글에서 '1 April 1998'을 직접 확인한 뒤에야 사실로 바꿨습니다.
표시를 해 둔 덕분에 무엇을 더 열어 봐야 하는지 바로 보이더라고요.
이 사이트의 다른 글에서 쓰는 정보 등급 표시와 같은 생각입니다.

질문에 따라 몇 가지를 쓸까?

솔직히 모든 답을 다섯 가지로 확인하면 AI를 쓰는 의미가 없어집니다.
기준은 틀렸을 때 얼마나 아픈가입니다.
아이디어를 나열하거나 문장을 다듬는 정도라면 방법 2 하나로 충분하고, 업무 메모나 개념 설명이면 방법 2와 3을 함께 씁니다.
돈이나 계약, 제출 서류가 걸렸다면 다섯 가지를 전부 씁니다.

시간 감각은 재 본 값이 아니라 추정입니다.
확인할 시간조차 없다면, 그 답은 '미확인'으로 두고 쓰지 않는 것이 가장 싼 방법입니다.

우리가 직접 해 본 것

이 글을 쓰면서 공개 정보로 질문 3개를 만들었습니다.
Claude(Sonnet 5.5)에게 먼저 답을 적게 하고, 그 뒤에 위 방법들로 하나씩 대조했어요.
결과는 3개 모두 맞았습니다. 틀린 답을 일부러 끌어내려 하지는 않았고, 틀린 사례를 재현하지도 못했습니다.
그래서 이 글에는 AI가 틀린 장면이 없습니다.

오히려 기록의 핵심은 다른 데 있었습니다.
맞았다는 사실조차 열어 보고 돌려 봐야 알 수 있었다는 점입니다.
한계도 있습니다.
방법 2는 새 대화창이 아니라 같은 대화창에서 다시 묻는 형태라 효과가 약했을 수 있습니다.
질문이 3개뿐이라는 점도 함께 밝혀 둡니다.

우리가 보는 점

• 확인은 의심이 아니라 분업입니다. AI가 초안을 빨리 만들고, 사람은 틀리면 아픈 곳만 봅니다.
• 방법을 늘리기보다 위험도에 맞게 줄이는 기준이 더 쓸모 있다고 봅니다.
• AI가 맞은 날에도 확인 기록을 남기면, 어떤 종류의 질문에서 틀리는지 쌓입니다.

자주 묻는 질문

Q. 새 AI 모델은 덜 틀리니 확인이 필요 없지 않나요?

덜 틀릴 수는 있어도 보장하지는 않습니다.
이 글의 실험도 3개가 맞았을 뿐, 다른 질문에서도 그렇다는 뜻은 아닙니다.

Q. AI가 준 출처 주소가 열리지 않으면요?

그 출처는 쓰지 않습니다.
같은 내용을 공식 사이트에서 직접 검색해 보고, 못 찾으면 미확인으로 둡니다.

Q. 다른 AI에게 "위 답이 맞아?"라고 물어도 되나요?

참고는 되지만 증명은 아닙니다.
마지막 확인은 사람이 쓴 원문이나 직접 계산으로 하세요.

Q. 의료·법률 질문도 이 방법으로 확인하면 되나요?

이 글은 일반적인 확인 방법 안내입니다.
건강, 법률, 세금, 투자처럼 결과가 큰 문제는 해당 분야 전문가나 공식 기관에 확인하세요.

Q. 확인할 시간이 없을 때 최소한 무엇을 하나요?

숫자·날짜·이름 세 가지만 따로 확인하세요.
그것도 못 하면 미확인으로 표시합니다.

이 글은 AI 도구의 도움을 받아 작성했고, 운영자가 내용을 검토한 뒤 게시했습니다. AI 사용 안내

출처