1. 할루시네이션, 그럴듯한 거짓말

할루시네이션(Hallucination)은 AI가 사실이 아닌 정보를 사실처럼 자신감 있게 말하는 현상입니다. 단순 버그가 아니라 LLM의 구조적 특성입니다. 모델은 "다음에 올 가장 그럴듯한 단어"를 끝없이 고르는 기계라서, 그럴듯하기만 하면 사실이 아닌 단어도 이어붙입니다.

1.1 실제 사고로 이어진 두 사례

이 현상이 단순 기술 흠집이 아니라 실제 법정·금전 분쟁으로 이어진 사건이 있습니다.

Mata v. Avianca, 2023년 5월. 뉴욕의 한 변호사가 ChatGPT에게 비슷한 판례를 찾아달라고 했습니다. ChatGPT는 "Varghese v. China Southern Airlines"를 비롯해 여섯 건의 판례를 그럴듯한 인용문과 사건 번호까지 붙여 제시했습니다. 변호사는 그 결과를 법원 서면에 그대로 인용했고, 그 판례는 단 하나도 존재하지 않았습니다. 판사는 5,000달러의 벌금을 부과했고, 이 사건은 Mata v. Avianca, Inc.로 정리되어 이후 미국 변호사 윤리 교육에서 가장 자주 인용되는 AI 사고 사례가 됐습니다.

Moffatt v. Air Canada, 2024년 2월. Air Canada 웹사이트의 챗봇이 "유가족 할인은 일단 정상가로 사고 90일 안에 환급 신청하면 된다"고 잘못 안내했고, 실제 정책은 출발 전 사전 신청만 가능했습니다. Air Canada는 "챗봇은 별개 개체"라고 변호했지만, BC 민사 트리뷰널은 "회사 웹사이트의 일부이므로 회사가 책임진다"고 판단해 환급금을 지급하라고 판결했습니다(BC Tribunal 판결 해설, ABA).

두 사건이 같이 던지는 메시지는 분명합니다. AI의 거짓 답을 외부에 그대로 쓴 책임은 사람·회사가 진다. "AI가 그렇게 말했다"는 면책 사유가 되지 않습니다.

1.2 왜 발생하나

1. 확률 기반 생성. 가장 그럴듯한 다음 단어를 고를 뿐, 그 단어가 사실인지 검증하는 별도 단계가 없습니다.
2. 학습 데이터의 한계. 그 분야 정보가 적으면 모델은 자기 패턴 안에서 "있을 법한 답"을 만들어냅니다.
3. 최신 정보 부재. 학습 시점 이후 사건은 모르는데, 모른다고 답하는 대신 "있을 법한 시나리오"를 채워 넣습니다.
4. 자신감 과잉. "모르겠다"는 응답이 학습 과정에서 별로 강화되지 않아, 모르는 영역에서도 단정적인 어투로 답하는 경향이 있습니다.

2. 프롬프트로 할루시네이션 줄이기

완전히 막을 수는 없지만, 프롬프트 설계만으로 빈도를 상당히 줄일 수 있습니다. 세 가지 패턴이 핵심입니다.

2.1 사실과 의견을 분리해서 받기

답을 한 덩어리로 받지 말고, 강제로 칸을 나눠서 받습니다.

다음 형식으로 답해줘.

[사실] 검증 가능한 객관적 정보만, 가능하면 출처 같이
[의견·분석] 위 사실에서 끌어낸 해석
[불확실] 검증이 필요한 부분, 사용자가 직접 확인하는 게 좋은 부분

비즈니스 보고서, 시장 조사, 법률·의료처럼 사실과 의견이 섞이면 안 되는 영역에서 특히 잘 통합니다. "[불확실]" 칸에 적힌 항목만 사람이 검증하면 되니까 검증 시간도 짧아집니다.

2.2 자기 검증 시키기

답을 한 번 받은 뒤, 같은 모델에게 그 답을 다시 점검하게 시키는 패턴입니다. 2023년 Meta AI의 Chain-of-Verification 논문이 이걸 4단계로 정리했는데, 일상 사용에서는 짧게 후속 질문 한 번이면 충분합니다.

방금 답에서 사실 주장으로 볼 수 있는 부분만 따로 뽑아줘.
각 주장에 대해 다음을 표시해줘.

- 출처가 학습 데이터에 명확히 있다고 확신하는 정도 (높음/중간/낮음)
- 검증이 필요하다면 어떤 자료를 찾아봐야 하는지

원본 답에 들어 있던 그럴듯한 거짓이 이 단계에서 자주 걸러집니다. 모델은 "이 주장은 출처를 정확히 못 댄다"고 분리해주는 경우가 많습니다.

같은 발상의 변형으로, 처음부터 반대 시각을 같이 요구하는 방법도 있습니다. 한쪽 결론으로 휩쓸리는 걸 막아 줍니다.

이 주장에 대해 셋 다 정리해줘.
1 - 지지 근거 3가지
2 - 반대 근거 3가지
3 - 위 둘을 종합한 중립적 평가

2.3 웹 검색으로 직접 확인하게 시키기

요즘 ChatGPT, Claude, Gemini는 모두 웹 검색이 기본으로 들어가 있습니다. 그래서 답을 받기 전에 "검색해서 확인하는 절차를 한 번 거쳐달라"고 한 줄만 추가하면 됩니다. 모델 머릿속의 흐릿한 기억에 맡기지 말고, 검색을 거쳐 확인된 정보만 답에 넣게 시키는 패턴입니다.

답하기 전에 웹 검색으로 충분히 확인해줘.

- 모든 사실 주장에 출처 링크를 같이 달아줘.
- 검색해도 신뢰할 만한 출처를 못 찾으면 답에 포함하지 말고 "확인 불가"로 표시해줘.
- 가능하면 서로 다른 출처 두 곳 이상에서 교차 확인된 정보만 사실로 다뤄줘.
- 통계나 인용문처럼 원본이 중요한 항목은 1차 출처(원 보고서, 논문, 공식 발표)까지 거슬러 올라가서 인용해줘.

핵심은 "교차 확인"과 "1차 출처"입니다. 검색을 시켜도 모델은 첫 번째 결과 한 곳을 그대로 옮겨오는 경우가 많은데, 두 곳 이상에서 같은 사실이 잡히는지 확인하라고 요구하면 출처를 한 번 더 찾아봅니다. 어느 블로그 한 곳에 잘못 적힌 수치가 그대로 굳어 답에 들어오는 일을 막을 수 있습니다.

조사 범위가 큰 작업이라면 ChatGPT나 Gemini의 Deep Research처럼 여러 페이지를 훑은 뒤 보고서 형태로 정리해주는 모드를 쓰는 게 더 안전합니다. 단발 검색보다 출처 수가 많고, 어떤 출처에서 어떤 문장이 나왔는지 매핑이 잘 되어 있어서 사람이 검증하기 편합니다.

다만 검색을 거친 답이라고 다 맞는 건 아닙니다. 모델이 검색 결과를 잘못 요약하기도 하고, 신뢰성이 떨어지는 글을 그대로 인용하기도 합니다. 그래서 출처 링크를 사람이 직접 클릭해 보는 단계는 여전히 필요합니다. 다만 출처 자체를 통째로 지어내는 비율은 검색 기능을 켰을 때 눈에 띄게 줄어듭니다.

2.4 모르면 모른다고 답하라고 못 박기

가장 단순하지만 효과적인 방법입니다.

- 모르는 내용은 "모른다"고 답해줘. 추측해서 채우지 마.
- 출처가 학습 데이터에 명확히 있는 정보가 아니면 "출처 불명"이라고 표시해줘.
- 숫자·날짜·고유명사는 확신이 없으면 사용자가 확인하라고 명시해줘.

이 세 줄을 시스템 프롬프트나 첫 메시지에 넣어 두면 모델의 자신감 과잉이 눈에 띄게 줄어듭니다. 다만 모델은 출처 자체를 지어내기도 하기 때문에, 정말 중요한 출처는 사람이 직접 클릭해서 실존하는지 확인해야 합니다. 이게 마지막 안전장치입니다.

3. 프롬프트 디버깅, 결과가 마음에 안 들 때

프롬프트는 한 번에 완벽하게 안 나옵니다. 결과를 보고 조금씩 고치는 게 본 작업의 거의 전부입니다.

3.1 먼저 점검할 8가지

원하는 답이 안 나올 때, 프롬프트 자체에서 흔히 빠뜨리는 점들입니다.

[ ] 역할이 명확한가, 아니면 모호한 "전문가" 정도로만 되어 있는가
[ ] 우리 회사·우리 상황 같은 맥락을 충분히 줬는가
[ ] 작업 지시가 "분석해줘" 수준으로 막연하지 않은가
[ ] 결과 형식을 명시했는가 (표, JSON, 글머리표 등)
[ ] 제약 조건끼리 서로 모순되지 않는가
[ ] 예시가 한 개라도 도움이 될 상황인가
[ ] 프롬프트가 너무 길어서 핵심이 묻혀 있지 않은가
[ ] 한 프롬프트에 작업을 너무 많이 욱여넣지 않았는가

여덟 가지 중 한두 개만 고쳐도 결과가 크게 달라지는 경우가 많습니다.

3.2 A/B로 비교해 보기

같은 목적의 프롬프트를 두 버전 만들어서 같은 입력을 넣어 보면, 어떤 요소가 결과에 진짜 영향을 주는지 빠르게 감을 잡을 수 있습니다.

# 버전 A, 짧은 프롬프트
"신입 개발자를 위한 Git 가이드를 작성해줘."

# 버전 B, 4요소가 들어간 프롬프트
역할: 5년 경력 DevOps 엔지니어
대상: Git을 처음 쓰는 신입 개발자
형식:
- 핵심 명령어 10개
- 각 명령어마다 실제 사용 상황 한 줄
- 자주 하는 실수 한 가지
분량: 2000자 이내

두 결과를 나란히 놓고 보면 차이가 분명히 보입니다. 이런 비교를 몇 번만 해보면 자기만의 "이 작업에는 이 구조가 잘 통한다"는 감이 생깁니다.

3.3 외부로 내보내기 전 마지막 체크

실무에서 AI 답을 외부 자료·고객 응대·법적 문서 같은 데에 쓰기 전 반드시 확인해야 할 점들입니다. Air Canada와 Avianca 사례가 보여주듯, 이 단계를 건너뛴 비용은 매우 큽니다.

[ ] 사실과 추측을 분리해서 받았는가
[ ] 출처가 명시된 항목은 그 출처를 실제로 클릭해서 확인했는가
[ ] 숫자·날짜·고유명사는 별도로 한 번 더 검증했는가
[ ] 법률·의료·재무처럼 책임 수반 영역이라면 사람 전문가 검토를 거쳤는가
[ ] 회사 정책·약관과 어긋나지 않는지 확인했는가

특히 두 번째 항목, "출처가 명시되었다고 그 출처가 실제로 존재한다는 뜻은 아니다"를 잊지 않는 게 중요합니다. 모델은 출처 형식까지 그럴듯하게 만들어 내기 때문에, 사람이 한 번 더 클릭해 보는 단계가 마지막 안전장치입니다.

다음 4장부터는 프롬프트 자체를 넘어, AI에게 어떤 정보를 같이 보여줄 것인가를 다루는 컨텍스트 엔지니어링으로 넘어갑니다. 할루시네이션 대응의 본격적인 단계가 거기서부터입니다.