질문을 잘 쓰면 근거 없는 답변을 줄일 수 있지만, 어떤 문구도 사실성을 보장하지는 않습니다. 환각은 단순한 형식 오류가 아닙니다. 모델은 존재하지 않는 주장, 인용, 출처, 수치와 설명을 매우 자연스럽게 생성할 수 있습니다. 명확한 지시는 유용한 행동의 가능성을 높이지만 생성된 문장을 검증된 원자료로 바꾸지는 못합니다.

NIST는 confabulation을 생성형 AI의 핵심 위험 중 하나로 다룹니다. OWASP는 misinformation과 overreliance를 애플리케이션 위험으로 분류합니다. 주요 모델 공급자의 공식 지침도 명확한 지시, 관련 맥락, 출력 제약, grounding과 반복 평가를 공통적으로 권장합니다.

따라서 현실적인 목표는 “모델이 절대 환각하지 않게 만들기”가 아닙니다. 근거 없는 주장이 발생할 가능성을 낮추고, 발견하기 쉽게 만들고, 피해 범위를 줄이며, 검증 없이 실제 의사결정으로 넘어가지 못하게 하는 것이 목표입니다.

1. 질문 전에 사용할 근거의 경계 정하기

답변이 어떤 정보를 사용할 수 있는지 먼저 지정합니다. 근거 경계가 없으면 모델은 제공된 문서와 학습 과정에서 익힌 일반 패턴을 섞고도 하나의 확정된 답처럼 표현할 수 있습니다.

다음과 같은 경계를 사용할 수 있습니다.

  • 첨부 문서에 있는 내용만 사용
  • 제공한 context에 명시된 사실만 사용
  • 승인된 검색 도구로 확인한 최신 공식 출처만 사용
  • 일반 지식은 사용할 수 있지만 최신 확인이 필요한 사실은 별도로 표시
  • 빠진 날짜, 가격, 이름, 인용을 추측하지 않음

문서 기반 질문에서는 답이 없을 때의 행동도 정합니다. “정확하게 답해라”보다 “제공된 자료에 답이 없으면 근거가 부족하다고 말하고 필요한 추가 자료를 적어라”가 더 실질적인 통제입니다.

시간 범위도 명확히 하세요. 현재 요금제, 법률, 제품 기능, 공직자, 보안 권고처럼 변하는 정보는 기준일과 최신 정보를 가져올 도구 또는 출처가 필요합니다.

2. 모델이 따라갈 수 있는 구조로 맥락 제공하기

맥락이 많다고 항상 좋아지는 것은 아닙니다. 길고 중복되며 서로 충돌하는 자료는 오히려 신뢰도를 낮출 수 있습니다. 업무에 필요한 자료만 제공하고 지시와 증거를 분리하세요.

재사용 가능한 구조는 다음과 같습니다.

업무:
어떤 질문이나 의사결정을 해결해야 하는가?

허용 근거:
어떤 문서나 도구 결과만 사용할 수 있는가?

제약:
무엇을 추측하거나 생성해서는 안 되는가?

출력:
어떤 섹션, 필드, 표가 필요한가?

불확실성 규칙:
근거가 없거나 충돌할 때 어떻게 표현할 것인가?

긴 문서를 제공할 때는 자료를 먼저 두고 정확한 질문을 마지막에 배치하는 방식이 도움이 될 수 있습니다. 명확한 heading과 delimiter를 사용해 문서 안의 인용문, 웹페이지, 고객 메시지가 시스템 지시처럼 해석되지 않도록 합니다.

맥락을 풍부하게 만들겠다는 이유로 secret, 내부 기록, 승인되지 않은 개인정보를 붙이지 마세요. 실제 조직 자료를 넣기 전에는 AI 도구 도입 전 개인정보·보안 체크리스트를 사용합니다.

3. 사실·추론·추천·미확인을 분리하기

모든 내용을 하나의 설명으로 섞지 말고 문장의 성격을 구분하도록 요청하세요.

다음 네 필드를 요구할 수 있습니다.

필드의미
확인된 사실허용된 근거에 직접 명시되거나 측정된 내용
추론사실에서 도출한 결론과 필요한 가정
추천공개된 기준과 tradeoff에 따른 판단
미확인현재 근거로는 확정할 수 없는 내용

이 구조는 확신이 어디에서 나오는지 드러냅니다. 추천이 측정된 사실처럼 보이는 것도 막을 수 있습니다.

중요한 업무에서는 정확한 주장, 근거 출처, 적용 범위, 확인일, 검증 상태를 담은 주장 장부를 요구하세요. 모델이 장부 초안을 만드는 것은 가능하지만 중요한 항목은 사람이나 결정론적 절차가 다시 확인해야 합니다.

“문서에 명시되어 있다”, “이 자료는 다음을 시사한다”, “확인할 수 없다”는 서로 다른 표현입니다. 의미에 맞춰 구분하세요.

4. 인용과 출처를 검증 가능한 형태로 요청하기

출처를 요구하면 추적성이 좋아질 수 있지만 모델이 출처 자체를 잘못 만들 수도 있습니다. 검토자가 실제로 열어 보고 주장을 뒷받침하는지 확인할 수 있을 때만 유용한 인용입니다.

다음 정보를 요구하세요.

  • 문서 제목과 발행 기관
  • 직접 URL 또는 안정적인 식별자
  • 정확한 section, page, table, timestamp
  • 필요한 경우 짧은 원문 인용
  • 해당 출처가 뒷받침하는 주장
  • 변동 정보의 확인 날짜
  • 지역, 요금제, 버전, 표본 같은 적용 조건

답변을 먼저 쓰게 한 뒤 “출처 몇 개를 추가해라”라고 요청하지 마세요. 장식용 참고문헌이 붙을 가능성이 높습니다. 생성 과정에서 중요한 주장마다 근거를 연결하도록 요구합니다.

그다음 출처를 별도로 검증합니다. 실제 문서가 존재하는지, 제목·작성자·연도가 맞는지, 인용문이 있는지, 앞뒤 문맥이 결론을 지지하는지 확인합니다. 전체 과정은 AI 답변의 출처와 사실을 검증하는 8단계를 사용할 수 있습니다.

5. 출력 형식을 명시적인 schema로 제한하기

자유로운 긴 글에서는 빠진 항목과 근거 없는 연결을 발견하기 어렵습니다. 반복 업무에는 증거와 빈칸을 강제로 드러내는 schema를 사용하세요.

예를 들면 다음과 같습니다.

다음 열을 가진 표로 답하라.
주장 | 근거 | 적용 범위 | 상태 | 부족한 정보

상태는 다음 값만 허용한다.
확인됨 | 조건부 | 상충 | 미확인

근거와 상태를 비워 두지 않는다.
미확인 주장을 추천의 근거로 사용하지 않는다.

Schema 자체가 사실성을 보증하지는 않지만 검증을 쉽게 만듭니다. 소프트웨어는 누락 필드, 허용되지 않은 상태, 잘못된 날짜, 위험 URL과 예상하지 않은 구조를 차단할 수 있습니다.

금지 목록만 길게 적기보다 원하는 행동을 긍정적으로 설명하세요. “근거 있는 사실만 사용하고 빠진 근거를 표시하라”는 지시는 여러 종류의 실수를 동시에 줄일 수 있습니다.

6. 최신 사실과 계산에는 적절한 도구 사용하기

더 신뢰할 수 있는 도구가 있는데도 모델 기억만으로 현재 사실이나 정확한 계산을 만들게 하지 마세요.

검색 또는 grounding이 필요한 경우는 다음과 같습니다.

  • 현재 가격과 제품 기능
  • 최신 사건과 공직자
  • 변경되는 정책과 규정
  • release note와 보안 advisory
  • 문서의 정확한 인용

계산기나 code execution이 필요한 경우는 다음과 같습니다.

  • 산술과 단위 변환
  • 집계와 개수 계산
  • 날짜 계산
  • 재현 가능한 데이터 변환
  • 원입력과 공식으로 계산 재검증

도구 결과도 자동으로 정확한 것은 아닙니다. 검색이 오래된 페이지를 가져오거나, 코드가 잘못된 입력을 사용하거나, 모델이 결과를 잘못 읽을 수 있습니다. 검색어, 출처, 입력, 출력과 변환 과정을 기록해 다시 실행할 수 있게 하세요.

프롬프트에는 어떤 도구를 언제 사용할지와 도구를 사용할 수 없을 때의 행동을 적습니다. 검색에 실패했는데 기억으로 대체하고도 최신 결과처럼 쓰게 해서는 안 됩니다.

7. 답변을 채택하기 전에 반대 질문하기

그럴듯한 첫 답변으로 작업을 끝내지 마세요. 취약한 가정과 빠진 근거를 드러내는 후속 질문을 사용합니다.

예시는 다음과 같습니다.

  • 제공된 출처가 직접 뒷받침하지 않는 주장은 무엇인가?
  • 어떤 조건에서 이 결론이 틀릴 수 있는가?
  • 어떤 날짜, 가격, 이름, 인용을 다시 확인해야 하는가?
  • 여러 출처가 사실상 같은 원자료를 반복한 것은 아닌가?
  • 추천과 충돌하는 증거는 무엇인가?
  • 가장 큰 가정에 의존하는 부분은 어디인가?
  • 회의적인 도메인 전문가가 가장 먼저 문제 삼을 부분은 무엇인가?

모델의 자기 비판을 독립 검증으로 간주하지 마세요. 유용한 문제를 찾을 수는 있지만 같은 종류의 생성 시스템입니다. 중요한 주장은 원출처, 결정론적 검사, 재현 실험 또는 자격 있는 사람의 검토가 필요합니다.

실제 행동으로 이어지는 업무라면 사람이 승인해야 하는 AI 워크플로우 설계의 승인 경계를 적용합니다.

8. 반복 질문에는 평가 세트 만들기

한 번 잘 작동한 프롬프트는 운영 통제가 아닙니다. 대표 입력과 기대 속성을 저장하고 모델, 도구, 문서 형식이나 지시가 바뀔 때마다 다시 시험하세요.

평가 세트에는 다음을 포함합니다.

  • 일반적인 사례
  • 근거가 없는 사례
  • 서로 충돌하는 출처
  • 오래된 정보
  • 모호한 질문
  • 긴 context
  • 문서 안의 무관하거나 악의적인 지시
  • 거절하거나 전문가에게 넘겨야 하는 요청
  • 정답이 알려진 계산
  • “미확인”이 올바른 답인 사례

문장 품질만 평가하지 마세요. 근거 없는 주장 비율, citation 유효성, 누락률, 올바른 불확실성 표현, 형식 준수, 수정 시간과 사람 승인율을 측정합니다.

더 자연스러운 문장을 만들었지만 불확실성을 숨긴다면 regression입니다. 짧더라도 확인된 사실과 미확인을 정확히 나눈 답변이 더 유용할 수 있습니다.

근거 제한형 질문 템플릿

당신은 사실 조사 업무를 보조한다.

업무:
[정확한 질문과 필요한 의사결정을 적는다.]

허용 근거:
[사용할 문서 또는 승인된 검색 도구를 적는다.]

규칙:
- 사실 주장은 허용된 근거만 사용한다.
- 확인된 사실, 추론, 추천, 미확인을 분리한다.
- 중요한 주장마다 정확한 출처 section을 적는다.
- 날짜, 지역, 요금제, 버전 또는 표본을 표시한다.
- 근거가 없거나 충돌하면 명확히 말한다.
- 인용, 출처, 수치, 날짜, 제품 동작을 만들지 않는다.

출력:
1. 직접 답변
2. 주장·근거 표
3. 불확실성과 상충 근거
4. 아직 필요한 검증 행동

이 템플릿은 출발점입니다. 실제 업무, 모델, 도구와 위험 수준에 맞게 수정하고 대표 사례로 검증하세요.

거짓 확신을 만드는 질문 패턴

  • 근거가 부족한데도 “확정적인 답”을 요구한다.
  • “불확실하다고 말하지 마라” 또는 “절대 거절하지 마라”고 지시한다.
  • 결론을 작성한 뒤 출처를 추가하게 한다.
  • 날짜가 다른 여러 문서를 구분 없이 붙인다.
  • “너는 전문가다”라는 역할 설정을 전문성 증거로 취급한다.
  • 데이터나 계산 도구 없이 정확한 수치를 요구한다.
  • 원출처를 열지 않고 모델에게 자기 답을 검증하게 한다.
  • 필수 사실이 미확인인데도 추천을 강요한다.
  • 낮은 temperature가 정확성을 보증한다고 생각한다.

짧은 환각 감소 체크리스트

  • 허용된 근거와 기준일이 명확한가?
  • 맥락이 관련성 있게 구조화됐고 승인되지 않은 민감정보가 없는가?
  • 사실, 추론, 추천, 미확인을 분리하도록 했는가?
  • 출처가 특정 주장과 정확한 section에 연결되는가?
  • 출력 schema를 자동으로 검증할 수 있는가?
  • 최신 사실과 계산을 적절한 도구에 맡겼는가?
  • 반대 근거와 실패 조건을 질문했는가?
  • 반복 사용을 위한 평가 세트가 있는가?
  • 중요한 주장을 독립 검증하고 사람이 승인하는가?

확인한 기준 자료

자료 확인일: 2026-07-20