답변의 범위를 제한하고 검증 절차를 프롬프트에 내장하는 것만으로도 신뢰도를 크게 높일 수 있습니다.
작성일: 2026년 8월 4일
목차
- 서론: 할루시네이션은 왜 발생하는가
- 프롬프트 설계의 다섯 가지 핵심 원칙
- 기법 1 — 그라운딩: 답변의 범위를 물리적으로 제한하기
- 기법 2 — 사고 사슬과 자기 일관성: 양날의 검
- 기법 3 — 사고 사슬 검증(Chain-of-Verification)
- 기법 4 — 구조화된 출력 요청
- 기법 5 — 명시적 제약과 부정 지시문
- 다층 방어 전략 종합
- 준비 및 검증 도구 안내
- 실전 프롬프트 템플릿 모음
- 산출물 점검 체크리스트
- 결론 및 향후 발전 방향
1. 서론: 할루시네이션은 왜 발생하는가
생성형 AI를 실무에 도입하는 과정에서 가장 빈번하게 제기되는 우려는 할루시네이션, 즉 모델이 실재하지 않는 정보를 마치 사실인 것처럼 그럴듯하게 생성해내는 현상입니다. 이는 단순한 결함이 아니라 다음 토큰의 확률 분포를 예측하여 텍스트를 순차적으로 생성하는 언어 모델의 근본적인 작동 원리에서 비롯되는 구조적 특성입니다. 모델은 “모른다”고 답하는 것보다 통계적으로 그럴듯한 답을 만들어내는 쪽으로 최적화되는 경향이 있기 때문입니다.
그러나 완전한 근절이 어렵다고 해서 대응이 무의미한 것은 아닙니다. 답변의 범위를 물리적으로 제한하는 프롬프트 구성이 할루시네이션 억제에 가장 효과적인 방법으로 꼽히고 있으며, 질문과 관련된 참고 자료를 직접 제공하고 해당 문서 내 정보만을 근거로 답변하도록 요청하는 방식이 현재까지 알려진 방법 중 가장 정확도가 높은 것으로 확인되고 있습니다.
이 기록에서는 코드 구현이 아닌 프롬프트 작성 그 자체에 초점을 맞추어, 할루시네이션을 실질적으로 줄이는 다섯 가지 핵심 기법을 이론적 근거와 함께 심층적으로 다루고, 실전에서 그대로 활용할 수 있는 완성형 프롬프트 템플릿을 박사 연구자의 관점에서 제시하도록 하겠습니다.
2. 프롬프트 설계의 다섯 가지 핵심 원칙
할루시네이션을 줄이는 프롬프트들이 공통적으로 따르는 다섯 가지 설계 원칙은 다음과 같습니다.
| 원칙 | 설명 |
|---|---|
| 1. 구조 분리 | 시스템 지침, 참고 자료, 질문을 명확히 구분된 섹션으로 분리하여 신뢰할 지침과 참고 데이터가 뒤섞이지 않도록 합니다. |
| 2. 범위 제한 | 참고 자료를 직접 제공하고 그 문서 내 정보만으로 답변하도록 명시적으로 요청합니다. |
| 3. 명시적 제약 | “정확하게 답하십시오”와 같은 모호한 지시 대신 “문서의 정보만 사용해 답하십시오”와 같은 구체적 제약을 사용합니다. |
| 4. 검증 절차 내장 | 답변 생성 후 스스로 근거를 재검토하도록 요청하는 자기 검증 단계를 프롬프트에 포함시킵니다. |
| 5. 기권 허용 | 확신할 수 없는 경우 “확인되지 않음”이라고 답하는 것을 명시적으로 허용하고 권장합니다. |
3. 기법 1 — 그라운딩: 답변의 범위를 물리적으로 제한하기
3.1 페르소나 부여와 데이터 소스 한정
그라운딩 기법에서 가장 먼저 적용할 수 있는 방법은 페르소나(역할) 부여와 데이터 소스를 명확히 한정하는 것입니다. 모델에게 “당신은 제공된 문서만을 근거로 답변하는 리서치 어시스턴트입니다”와 같이 역할과 정보 출처의 한계를 동시에 지정하면, 모델이 학습 데이터 전반에서 자유롭게 추측하려는 경향을 억제하는 효과가 있습니다.
3.2 근거 문장의 병기 요구
모든 사실 진술에 근거가 되는 원문 문장이나 출처를 함께 인용하도록 요구하는 것은 검증 가능성을 응답 구조 자체에 내재화하는 효과적인 방법입니다. 이는 사용자가 사후적으로 각 진술의 타당성을 손쉽게 확인할 수 있게 해줍니다.
그라운딩 프롬프트 예시입니다:
“당신은 제공된 자료만을 근거로 답변하는 리서치 어시스턴트입니다. 아래 [참고 자료]에 명시되지 않은 내용은 절대 추측하지 마시고, 답을 찾을 수 없는 경우 ‘제공된 자료에서 확인할 수 없습니다’라고 답하십시오. 모든 사실 진술 뒤에는 해당 근거가 되는 자료 내 문장을 괄호로 함께 표기하십시오. 확신이 낮은 내용은 단정하지 말고 ‘~일 가능성이 있습니다’와 같은 표현을 사용하십시오.”
4. 기법 2 — 사고 사슬과 자기 일관성: 양날의 검
4.1 사고 사슬 기법의 원리
사고 사슬(Chain-of-Thought) 기법은 관련된 사실 관계를 먼저 나열하고 논리적 추론 과정을 단계적으로 거친 뒤 최종 답안을 작성하도록 요청하는 방식입니다. 이렇게 하면 모델이 정보를 검증할 “시간”을 가지게 되어 응답의 정합성이 높아지는 효과가 있습니다.
4.2 주의할 점: 사고 사슬이 오히려 할루시네이션을 늘릴 수도 있다
다만 최근 연구에서는 이 기법을 무비판적으로 적용해서는 안 된다는 중요한 경고도 함께 제기되고 있습니다. 복잡한 과제에서는 사고 사슬 프롬프팅이 오히려 할루시네이션을 최대 12퍼센트까지 증가시킬 수 있다는 연구 결과가 발표된 바 있습니다. 이는 추론 단계가 길어질수록 중간 단계에서 발생한 사소한 오류가 이후 단계로 누적되어 증폭될 수 있기 때문으로 해석됩니다. 따라서 사고 사슬 기법은 단독으로 사용하기보다, 뒤에서 살펴볼 검증 절차와 반드시 함께 결합하여 사용하는 것이 안전합니다.
4.3 자기 일관성을 통한 교차 확인
자기 일관성 기법은 동일한 질의에 대해 여러 차례 독립적으로 답변을 생성하도록 요청하고, 그 결과들이 서로 일치하는 정도를 확인하는 방식입니다. 여러 응답이 일관되게 동일한 결론에 도달한다면 해당 정보에 대한 모델의 지식이 상대적으로 견고하다는 신호로 해석할 수 있는 반면, 응답마다 결론이 크게 요동친다면 이는 근거가 빈약한 추측성 답변일 가능성이 높다는 신호로 활용할 수 있습니다.
사고 사슬 + 자기 검증 결합 프롬프트 예시입니다:
“다음 질문에 답하기 전, 먼저 관련된 사실을 항목별로 나열하십시오. 그다음 각 사실 사이의 논리적 연결 관계를 단계적으로 설명하십시오. 마지막으로 이 추론 과정에 기반하여 최종 답변을 작성하십시오. 각 단계에서 확신이 서지 않는 부분이 있다면 다음 단계로 넘어가기 전에 반드시 명시하십시오.”
5. 기법 3 — 사고 사슬 검증(Chain-of-Verification)
5.1 CoVe의 작동 원리
사고 사슬 검증(Chain-of-Verification, CoVe)은 모델이 검증 질문을 스스로 생성하고, 최종 답변을 확정하기 전에 그 질문들에 먼저 답하도록 요구함으로써 할루시네이션을 줄이는 기법입니다. 이는 초안 답변을 곧바로 신뢰하지 않고, 그 안에 포함된 각 주장을 독립적으로 재확인하는 절차를 프롬프트 안에 내장하는 방식입니다.
5.2 4단계 검증 프로세스를 하나의 프롬프트로 압축하기
CoVe는 초안 생성, 검증 질문 계획, 검증 질문 답변, 최종 수정이라는 네 단계로 구성되며, 이 전체 과정을 별도의 프로그래밍 없이 하나의 정교한 프롬프트만으로 유도할 수 있습니다.
사고 사슬 검증(CoVe) 프롬프트 예시입니다:
“다음 절차를 순서대로 따라 답변을 작성하십시오. 1단계, 질문에 대한 초안 답변을 작성하십시오. 2단계, 초안에 포함된 사실 진술을 하나씩 분리하여, 각 진술이 참인지 확인하기 위한 독립적인 검증 질문을 만드십시오. 3단계, 만든 검증 질문 각각에 대해 제공된 자료만을 근거로 답하십시오(자료에 없으면 ‘확인 불가’라고 답하십시오). 4단계, 검증 결과 초안과 모순되거나 근거가 부족한 부분을 수정하여 최종 답변을 작성하고, 수정된 부분이 있다면 무엇이 왜 바뀌었는지 간단히 밝히십시오.”
6. 기법 4 — 구조화된 출력 요청
6.1 구조화된 출력이 신뢰도를 높이는 이유
자유 서술형 답변보다, 근거 문장과 확신도, 출처를 명확히 구분된 항목으로 요구하는 구조화된 출력 형식이 검증을 훨씬 용이하게 만듭니다. 구조화된 출력은 응답의 신뢰성과 이후 처리 과정의 정확성을 함께 높이며, 주요 AI 제공사들도 정해진 항목 체계에 맞춘 출력을 강제하는 기능을 지원하고 있습니다.
6.2 항목 구분을 프롬프트로 직접 지정하기
별도의 개발 없이도, 프롬프트 안에서 원하는 출력 항목을 명확히 나열하는 것만으로 구조화된 형태의 응답을 유도할 수 있습니다.
구조화된 출력 요청 프롬프트 예시입니다:
“답변을 다음 네 개의 항목으로 구분하여 작성하십시오. [핵심 답변] 항목에는 결론을 한두 문장으로 제시하십시오. [근거] 항목에는 결론을 뒷받침하는 자료 내 문장을 그대로 인용하십시오. [확신도] 항목에는 ‘확실함’, ‘가능성 있음’, ‘확인되지 않음’ 중 하나를 표기하십시오. [추가 확인 필요 사항] 항목에는 자료만으로는 판단할 수 없어 별도 확인이 필요한 부분을 나열하십시오. 각 항목은 반드시 위 순서와 명칭을 그대로 따르십시오.”
7. 기법 5 — 명시적 제약과 부정 지시문
7.1 모호한 지시와 구체적 제약의 차이
“정확하게 답하십시오”라는 지시는 제약이라 부르기 어려운 모호한 당부에 불과합니다. 반면 “문서에 있는 정보만 사용해서 답하십시오”라는 지시는 모델이 선택할 수 있는 답변의 폭 자체를 물리적으로 좁히는 명확한 제약입니다. 이러한 구체적 제약은 모델이 규칙을 지키는 것보다 지키지 않는 것이 더 어렵게 만드는 방식으로 작동합니다.
7.2 부정 지시문의 효과적 활용
“~하지 마십시오”라는 형태의 부정 지시문도 긍정 지시만으로는 통제하기 어려운 오류 유형을 차단하는 데 유용합니다. 예를 들어 “출처를 확인할 수 없는 통계나 인명은 언급하지 마십시오”, “제공된 자료에 없는 예시를 임의로 만들어내지 마십시오”와 같은 명시적 금지 조항은 모델의 자유로운 창작 경향을 직접적으로 억제합니다.
8. 다층 방어 전략 종합
단일 기법만으로는 할루시네이션을 충분히 억제하기 어렵기 때문에, 여러 방어 계층을 중첩하여 적용하는 것이 프로덕션 환경에서 권장되는 접근입니다. 다음 표는 앞서 살펴본 다섯 가지 기법을 적용 시점별로 정리한 것입니다.
| 적용 시점 | 기법 | 기대 효과 |
|---|---|---|
| 생성 이전 | 그라운딩, 명시적 제약 | 답변 범위 자체를 물리적으로 제한 |
| 생성 중 | 구조화된 출력, 사고 사슬(신중히) | 근거와 결론을 분리하여 추적 가능하게 함 |
| 생성 이후 | 사고 사슬 검증(CoVe), 자기 일관성 | 초안의 오류를 스스로 재확인하고 수정 |
| 사용자 검토 | 확신도 표기, 기권 허용 | 사용자가 후속 검증 우선순위를 판단 가능 |
9. 준비 및 검증 도구 안내
9.1 별도 설치 없이 시작하는 방법
본 글에서 소개한 프롬프트 기법들은 특별한 소프트웨어 설치 없이, ChatGPT나 Claude와 같은 웹 기반 AI 서비스에서 곧바로 적용할 수 있습니다. 자주 사용하는 원칙을 매번 새로 입력하는 대신, 각 서비스가 제공하는 프로젝트 맞춤 지침(커스텀 인스트럭션) 기능에 앞서 소개한 다섯 가지 원칙을 미리 등록해 두면 매 대화마다 반복 입력할 필요 없이 일관되게 적용할 수 있습니다.
9.2 자동화된 검증이 필요한 경우의 도구
조직 차원에서 대량의 응답을 자동으로 점검해야 하는 경우에는 별도의 오픈소스 검증 도구를 함께 활용할 수 있습니다. 대표적으로 자기 일관성 기반의 검증 방식을 자동화한 SelfCheckGPT와, 입력·출력 검열 및 사실 검증 기능을 통합적으로 제공하는 NVIDIA의 NeMo Guardrails가 있습니다. 이러한 도구는 다음과 같은 한 줄 명령으로 설치할 수 있습니다.
- SelfCheckGPT 설치: 파이썬 패키지 관리자를 통해
pip install selfcheckgpt명령 한 줄로 설치할 수 있으며, 이는 pip이 PyPI 저장소에서 최신 배포 버전을 내려받아 현재 환경에 등록하는 표준 절차입니다. - NeMo Guardrails 설치: 동일한 방식으로
pip install nemoguardrails명령을 실행하면 되며, 설치가 완료되면 기존 애플리케이션에 프로그래밍 가능한 검증 계층을 추가로 연결할 수 있습니다.
두 도구 모두 프롬프트 기법을 대체하는 것이 아니라 보완하는 역할을 합니다. 즉, 본 글에서 제시한 그라운딩과 검증 지향 프롬프트를 1차 방어선으로 삼고, 이러한 자동화 도구를 2차 점검 장치로 배치하는 이중 구조가 가장 안정적입니다.
10. 실전 프롬프트 템플릿 모음
10.1 요약 작업용 그라운딩 템플릿
“아래 [원문]만을 근거로 요약하십시오. 원문에 없는 내용을 추가하거나 추론으로 보충하지 마십시오. 요약된 각 문장 끝에는 원문의 해당 문단 번호를 괄호로 표기하십시오.”
10.2 수치·통계 검증용 템플릿
“응답에 포함되는 모든 숫자, 통계, 날짜에는 반드시 출처와 기준 시점을 함께 명시하십시오. 정확한 수치를 확인할 수 없는 경우, 임의로 추정치를 만들어내지 말고 ‘수치 확인 불가’라고 답하십시오.”
10.3 종합 검증(그라운딩 + CoVe + 구조화) 템플릿
“당신은 제공된 [참고 자료]만을 근거로 답변하는 검증 지향 어시스턴트입니다. 다음 절차를 따르십시오. 첫째, 자료 내 정보만으로 초안 답변을 작성하십시오. 둘째, 초안의 각 주장을 확인할 검증 질문을 만들고 자료를 근거로 답하십시오. 셋째, 검증 결과를 반영해 최종 답변을 수정하십시오. 최종 답변은 [핵심 답변], [근거], [확신도], [추가 확인 필요 사항]의 네 항목으로 구분하여 제시하고, 자료에 없는 내용은 절대 추측하지 마십시오.”
10.4 일상생활 실전 프롬프트 템플릿 20선
앞서 살펴본 다섯 가지 원칙은 업무용 리서치뿐 아니라 일상생활의 크고 작은 정보 확인에도 그대로 적용할 수 있습니다. 아래는 실생활에서 자주 마주치는 상황별로, 그라운딩과 확신도 표기 원칙을 이미 내장한 20가지 프롬프트 템플릿입니다. 대괄호 [ ] 부분은 각자의 상황에 맞게 채워 사용하시면 됩니다.
건강·의료 정보 확인입니다:
1. “[증상]에 대해 일반적으로 알려진 원인을 설명해 주십시오. 확진이나 처방에 해당하는 답은 하지 마시고, 각 원인 옆에 확신도를 표기하며, 반드시 마지막에 ‘정확한 진단은 의료진의 진료가 필요합니다’라는 문구를 포함해 주십시오.”
2. “[약물명]과 [약물명]을 함께 복용해도 되는지 일반적으로 알려진 상호작용 정보를 알려주십시오. 확실하지 않은 내용은 ‘확인되지 않음’으로 표기하고, 반드시 약사나 의사 상담을 권고하는 문구로 마무리해 주십시오.”
음식·영양 정보입니다:
3. “[식재료]의 일반적인 100g당 칼로리와 주요 영양성분을 알려주십시오. 정확한 수치를 확신할 수 없다면 ‘대략적인 추정치’라고 명시해 주십시오.”
4. “[재료 목록]으로 만들 수 있는 요리를 추천해 주십시오. 제시한 재료에 없는 재료가 반드시 필요한 경우, 그 재료를 ‘추가로 필요한 재료’로 명확히 구분해서 알려주십시오.”
쇼핑·제품 비교입니다:
5. “[제품 A]와 [제품 B]를 [비교 기준] 측면에서 비교해 주십시오. 확실한 사양 정보와 일반적인 사용자 평가를 구분해서 제시하고, 정확한 수치를 모르는 항목은 ‘확인 필요’로 남겨 주십시오.”
6. “[제품명]의 알려진 단점이나 소비자 불만 사항을 정리해 주십시오. 근거 없는 추측은 배제하고, 확인되지 않은 내용은 표기하지 마십시오.”
여행 계획입니다:
7. “[여행지]로 [기간] 동안 여행할 때 필요한 준비물과 주의사항을 알려주십시오. 최신 입국 규정이나 비자 요건처럼 자주 바뀌는 정보는 반드시 ‘최신 공식 정보를 재확인하십시오’라고 표기해 주십시오.”
8. “[여행지]의 대표 관광지 목록을 알려주시되, 확실히 알고 있는 곳과 불확실한 곳을 구분해 주십시오. 존재를 확신할 수 없는 장소는 절대 만들어내지 마십시오.”
재무·세금 정보입니다:
9. “[세금/공제 항목]에 대해 일반적으로 알려진 내용을 설명해 주십시오. 세율이나 한도액처럼 매년 바뀔 수 있는 수치는 반드시 기준 연도를 함께 표기하고, ‘정확한 금액은 국세청 등 공식 자료로 재확인하십시오’라고 안내해 주십시오.”
10. “[금융상품]의 일반적인 구조와 장단점을 설명해 주십시오. 투자 권유나 확정적인 수익 예측은 하지 마시고, 불확실한 부분은 ‘개인 상황에 따라 다를 수 있음’으로 명시해 주십시오.”
학습·자료 조사입니다:
11. “[주제]에 대해 설명해 주시되, 확실히 알고 있는 정설과 아직 논쟁 중인 견해를 구분해서 제시해 주십시오. 출처를 특정할 수 없는 통계나 일화는 포함하지 마십시오.”
12. “아래 [원문]을 근거로 [주제]를 요약해 주십시오. 원문에 없는 배경지식을 임의로 추가하지 마시고, 원문에서 다루지 않은 부분은 ‘원문에서 다루지 않음’이라고 표기해 주십시오.”
뉴스·사실 확인입니다:
13. “[뉴스/소문 내용]이 사실인지 알려진 정보를 바탕으로 검토해 주십시오. 확실하지 않다면 단정하지 말고 ‘확인되지 않음’ 또는 ‘추가 확인 필요’로 표기해 주십시오.”
14. “[인물]이 했다고 알려진 ‘[발언 내용]’이라는 말이 실제로 그 인물의 발언이 맞는지 확인해 주십시오. 확신이 없다면 사실이라고 단정하지 말고 ‘출처 불명’이라고 답해 주십시오.”
계약서·약관 확인입니다:
15. “아래 [약관/계약서 조항]에서 소비자에게 불리할 수 있는 조항을 찾아 표시해 주십시오. 제공된 조항에 없는 내용을 추가로 지어내지 마시고, 법적 판단이 필요한 부분은 ‘전문가 확인 권고’로 표기해 주십시오.”
16. “[보험 약관 조항]을 쉬운 말로 풀어서 설명해 주십시오. 원문에 명시되지 않은 보장 범위를 임의로 추측하지 말고, 애매한 부분은 ‘보험사에 직접 확인 필요’로 남겨 주십시오.”
업무 이메일·문서 작성입니다:
17. “아래 [메모/구두 지시 내용]을 바탕으로 이메일 초안을 작성해 주십시오. 제공된 내용에 없는 세부 일정이나 수치는 임의로 채우지 말고 ‘[확인 필요]’로 비워 두십시오.”
18. “아래 [회의록/자료]를 근거로 요약 보고서를 작성해 주십시오. 자료에서 명시적으로 언급되지 않은 결론이나 수치를 추가하지 마시고, 근거가 되는 발언이나 항목을 함께 표기해 주십시오.”
역사·문화 상식 확인입니다:
19. “[역사적 사건]의 발생 연도와 배경을 알려주십시오. 정확한 날짜를 확신할 수 없는 세부 사항은 ‘정확한 시점 확인 필요’로 표기해 주십시오.”
20. “[속담/고사성어]의 유래와 정확한 의미를 알려주십시오. 여러 가지 유래설이 있는 경우 하나로 단정하지 말고 알려진 설들을 모두 나열해 주십시오.”
11. 산출물 점검 체크리스트
프롬프트를 아무리 정교하게 설계하더라도, 최종 산출물은 다음 항목을 기준으로 사람이 직접 확인하는 절차를 반드시 거쳐야 합니다.
- 답변에 인용된 근거 문장이 실제 원문에 그대로 존재하는지 여부
- 확신도 표기가 실제 근거의 강도와 부합하는지 여부
- “확인되지 않음”으로 표기된 항목이 누락 없이 별도 정리되어 있는지 여부
- 동일 질의를 반복했을 때 핵심 결론이 크게 요동치지 않는지 여부(자기 일관성 확인)
- 부정 지시문으로 금지한 내용(예: 임의 통계 생성)이 실제로 포함되지 않았는지 여부
12. 결론 및 향후 발전 방향
이 기록에서는 할루시네이션이 언어 모델의 확률적 생성 구조에서 비롯되는 근본적 특성임을 짚어보고, 그라운딩, 사고 사슬과 자기 일관성, 사고 사슬 검증, 구조화된 출력, 명시적 제약이라는 다섯 가지 프롬프트 기법을 이론적 근거와 함께 심층적으로 분석하였습니다. 특히 사고 사슬 기법이 복잡한 과제에서는 오히려 할루시네이션을 늘릴 수 있다는 최근 연구 결과는, 어떤 기법도 맹목적으로 적용해서는 안 되며 반드시 검증 절차와 함께 결합해야 한다는 균형 잡힌 태도의 중요성을 보여줍니다.
향후 발전 방향으로는 다음을 전망할 수 있습니다. 첫째, 개별 사용자가 직접 다듬어온 검증 지향 프롬프트가 조직 차원의 표준 라이브러리로 정착해 나갈 것으로 예상됩니다. 둘째, 프롬프트 수준의 방어와 SelfCheckGPT, NeMo Guardrails와 같은 자동화 도구가 결합된 이중 방어 구조가 실무 표준으로 자리 잡을 것입니다. 셋째, 텍스트를 넘어 이미지와 코드 생성 영역까지 그라운딩과 검증 지향 프롬프트 설계 원칙이 확장 적용될 것으로 보입니다.
결국 할루시네이션 방지의 핵심은 특정 기법 하나에 의존하는 것이 아니라, 답변의 범위를 제한하고 근거를 요구하며 스스로 검증하도록 요청하는 여러 원칙을 프롬프트 안에 유기적으로 결합하는 태도에 있다는 점을 다시 한번 강조하고자 합니다.
Takeaway
- 할루시네이션은 도덕 문제가 아니라 다음 토큰 예측의 기본 성질입니다.
- 프롬프트로 할 수 있는 일은 범위 제한과 근거 강제입니다. 지식 갱신은 RAG나 도구 몫입니다.
- “모르면 모른다”를 허용하지 않는 프롬프트가 환각을 늘립니다.
- 템플릿을 복사한 뒤, 우리 도메인의 금지 항목과 필수 출처 형식을 덮어쓰십시오.