20. 검증 가능한 출력 만들기

좋은 답 vs 검증 가능한 답

18장에서 환각은 0이 되지 않는다고 했습니다. 그렇다면 다음 방어선은, 틀렸을 때 그것을 알아챌 수 있게 만드는 것입니다. 검증 가능성이란, 답이 맞는지 사람이나 시스템이 쉽게 확인할 수 있는 정도입니다.

같은 정답이라도 검증 가능성은 천차만별입니다. "근거 없이 결론만 던지는 답"과 "근거를 함께 제시해 따라가며 확인할 수 있는 답"은, 정확도가 같아도 신뢰도가 다릅니다.

📌 핵심: 목표를 "정확한 답"에서 "정확하면서 검증 가능한 답"으로 한 단계 올리세요. 검증 가능성은 환각이라는 피할 수 없는 위험에 대한 보험입니다.

기법 1: 근거를 함께 내게 한다

16·18장에서 반복된 핵심입니다. 결론만이 아니라 근거를 함께 내게 하면, 그 근거를 따라가며 답을 검증할 수 있습니다.

검증 어려움 ❌            검증 쉬움 ✅
"이 계약은 위험합니다"  →  "이 계약은 위험합니다.
                          근거: 제3조가 일방적 해지권을 부여 → [원문 인용]
                          제7조에 배상 상한이 없음 → [원문 인용]"

아래는 각 주장의 출처를 짚을 수 있어, 사람이 "정말 그런가" 원문과 대조할 수 있습니다.

기법 2: 구조로 점검 지점을 만든다

8장의 출력 형식을 검증 목적으로 씁니다. 답을 점검 가능한 단위로 쪼개면, 어디가 틀렸는지 짚기 쉽습니다.

✅
"각 항목을 [주장 | 근거 | 확신도(상/중/하)] 표로 정리해줘."

여기서 확신도 열이 특히 유용합니다. 모델이 스스로 불확실하다고 표시한 부분을 우선 검증하면, 검토 노력을 효율적으로 배분할 수 있습니다.

⚠️ 흔한 실수·미신: 모델이 매긴 확신도가 실제 정확도와 항상 일치하지는 않습니다. 모델은 틀린 답에도 높은 확신을 보일 수 있습니다(18장). 확신도는 "검토 우선순위 힌트"이지 "정확도 보증"이 아닙니다.

기법 3: 검증 가능한 형태로 답을 요구한다

가능하면, 답 자체를 기계나 사람이 객관적으로 확인할 수 있는 형태로 끌어내세요.

• 계산이면 과정을 보여주게 해 재계산 가능하게(9장)
• 코드면 테스트 케이스나 실행 가능한 예제를 함께
• 사실 주장이면 출처·날짜·구체적 수치를 명시해 대조 가능하게
• 추천이면 기준을 밝히게 해 타당성 판단 가능하게

✅
"이 정규식을 만들고, 매칭되는 예 3개와 매칭 안 되는 예 3개를 함께 줘."

예제를 함께 받으면, 정규식이 맞는지 직접 돌려보지 않고도 어느 정도 가늠할 수 있고, 돌려보기도 쉽습니다.

기법 4: 자기 점검을 시킨다 (보조 수단)

답을 낸 뒤 모델에게 검토를 시키는 방법입니다(5부 자기 비판과 연결). 별도 단계로 분리하면 더 효과적입니다.

✅
"1단계: 답을 작성해.
 2단계: 작성한 답에서 사실 오류나 근거 약한 부분을 스스로 찾아 표시해."

⚠️ 흔한 실수·미신: 19·18장에서 반복했듯, 자기 점검은 자기 환각을 재확인할 수 있어 완전하지 않습니다. 같은 모델이 같은 맥락에서 점검하면 같은 실수를 놓치기 쉽습니다. 보조 수단으로 쓰되 최종 보증으로 믿지 마세요. 더 독립적인 검증은 다른 맥락·다른 도구·사람에서 옵니다.

검증 노력은 위험에 비례해 배분한다

모든 출력을 똑같이 엄격히 검증할 필요는 없습니다. 틀렸을 때의 손해에 비례해 검증을 배분하세요.

🧪 직접 검증법: 출력을 받으면 "이 중 틀리면 가장 손해 큰 주장은?"을 먼저 찾아 거기부터 검증하세요. 모든 걸 똑같이 보면 정작 중요한 곳을 놓칩니다. 검증도 13장의 "최소집합" 사고 — 가장 중요한 지점에 노력을 집중 — 가 통합니다.

🔧 개발자 노트: 자동 검증 가능한 형태가 가장 이상적입니다. 구조화 출력(8장)으로 받으면 스키마 검증·값 범위 체크를 코드로 돌릴 수 있고, 인용을 강제하면 인용이 원문에 실제 존재하는지 자동 대조할 수 있습니다. 코드 생성이면 생성된 코드를 실제로 실행·테스트해 검증합니다. "검증을 사람 눈에만 의존하지 말고, 가능한 부분은 자동 게이트로"가 프로덕션 원칙입니다. 이는 다음 22장의 일관성·재현성, 23장의 평가와 직접 이어집니다.

이 장에서 배운 것

• 환각이 불가피한 만큼, 다음 방어선은 틀렸을 때 알아챌 수 있게 만드는 "검증 가능성"이다.
• 검증 가능성을 높이는 법: 근거 함께 내기, 점검 단위로 구조화(확신도 열 포함), 객관적으로 확인 가능한 형태(과정·테스트·출처)로 요구, 자기 점검(보조).
• 모델의 확신도는 검토 우선순위 힌트이지 정확도 보증이 아니다.
• 자기 점검은 자기 환각을 재확인할 수 있어 불완전하다. 독립적 검증(다른 도구·사람)이 더 강하다.
• 검증 노력은 틀렸을 때의 손해에 비례해 배분한다. 가장 위험한 지점부터 본다.

✍️ 확인 문제

1. "정확한 답"과 "검증 가능한 답"의 차이를 예를 들어 설명하고, 왜 후자가 추가로 중요한지 적어보세요.

1. 모델이 표에 "확신도: 상"이라고 표시한 항목을 그대로 믿어도 되는지, 이 장과 18장의 내용으로 판단해보세요.

1. (실습) 모델에게 "최근 3년 시장 규모 추이"를 요청할 때, 답을 검증 가능하게 만드는 프롬프트를 작성해보세요. (근거·구조·확인 가능 형태를 모두 고려)

다음 → 21. 거절과 실패 다루기
이전 ← 19. 모호함과 과잉생성 다루기 · 목차