생성형 AI의 환각은 운영 단계에서 어떻게 줄입니까?

환각은 없애는 대상이 아니라 관리하는 대상입니다

생성형 AI가 근거 없이 그럴듯한 내용을 만들어 내는 현상을 환각이라고 부릅니다. 생성형 AI는 사실을 조회하는 장치가 아니라 문맥상 그럴듯한 다음 말을 만들어 내는 장치입니다. 문장이 매끄럽다는 것과 내용이 맞다는 것은 별개이고, 그래서 틀린 답도 맞는 답과 같은 확신의 어조로 나옵니다.

Anthropic은 공식 문서에서 환각을 줄이는 기법을 소개하면서도, 이 기법들이 환각을 크게 줄일 수는 있지만 완전히 없애지는 못하므로 중요한 정보는 반드시 검증하라고 적고 있습니다. OWASP도 2025년판 LLM 애플리케이션 10대 위험에 잘못된 정보(Misinformation)를 별도 항목으로 둡니다. 사내 문서를 근거로 붙이는 RAG도 마찬가지입니다. 근거를 주면 줄어들지만, 근거를 잘못 읽거나 근거에 없는 내용을 덧붙이는 일은 남습니다. 그래서 운영의 목표는 환각을 줄이고, 남은 환각을 드러내고, 피해가 큰 곳에서 사람이 거르는 것입니다.

답을 만들 때: 지시로 줄이는 세 가지

1. 모른다고 답할 권한 주기근거가 부족하면 「확인할 수 없습니다」라고 답하라고 명시합니다
2. 인용을 먼저 뽑게 하기긴 문서는 관련 문장을 그대로 먼저 뽑고, 그 인용만으로 답하게 합니다
3. 외부 지식 제한제공한 문서에 있는 정보만 쓰고 일반 지식으로 채우지 말라고 지시합니다

세 가지 모두 Anthropic이 제시하는 방법입니다. 실무에서 자주 빠지는 것은 첫 번째입니다. 모델에게 항상 답하라는 압력만 주면 근거가 없을 때도 답을 지어냅니다. 「모른다」가 정답인 질문을 평가 기준에 넣어야 이 지시가 실제로 지켜지는지 확인할 수 있습니다.

인용을 먼저 뽑게 하는 방법은 긴 문서를 다루는 작업에서 특히 효과가 있습니다. 모델이 문서 전체를 막연히 참고하는 대신 실제 문장을 앞에 꺼내 놓고 그 범위 안에서 답하게 되므로, 근거와 답 사이의 거리가 짧아집니다. 사람이 결과를 검토할 때도 인용과 답을 나란히 놓고 보면 어긋난 곳이 바로 드러납니다.

답이 나온 뒤: 근거와 대조하고 드러냅니다

• 인용 검증: 답의 주장마다 근거 문장을 붙이게 하고, 근거를 찾지 못한 주장은 지우게 합니다. 사람이 답을 검토할 때도 근거 링크가 있으면 확인 시간이 줄어듭니다.
• 근거 일치 검사: Amazon Bedrock Guardrails의 contextual grounding check처럼, 답이 검색된 근거에서 벗어나거나(grounding) 질문과 관련이 없을 때(relevance) 점수를 매겨 차단하거나 표시하는 관리형 기능을 쓸 수 있습니다.
• 반복 일관성: 중요한 판단은 같은 질문을 여러 번 실행해 결과가 갈리는지 봅니다. 결과가 실행마다 다르면 환각을 의심할 신호입니다.

이 단계의 검사도 확률적입니다. AWS 문서가 설명하듯 근거 일치 검사의 기준값을 높이면 근거 없는 답이 걸러질 가능성이 커지는 대신 차단도 늘어나므로, 기준값은 실제 업무 데이터로 시험해 정해야 합니다. 또 이 검사는 등급에 따라 지원 언어가 다릅니다. 등급을 지정하지 않으면 쓰이는 Classic 등급은 영어·프랑스어·스페인어만 지원하고, 한국어는 Standard 등급에서 지원됩니다. Standard 등급은 가드레일에 교차 리전 추론을 켜야 하고 일부 리전에서만 쓸 수 있으므로, 데이터 처리 위치 요건과 함께 확인해야 합니다(2026년 10월 AWS 문서 기준).

드러내는 것도 운영입니다. 답 옆에 근거 문서와 해당 문장을 보여 주면 사용자가 스스로 확인할 수 있습니다. 근거 일치 점수가 낮은 답을 무조건 막기보다 「근거 확인 필요」 같은 표시와 함께 내보내는 선택지도 있습니다. AWS의 근거 일치 검사도 차단하지 않고 탐지 정보만 돌려주도록 설정할 수 있습니다.

사람이 거를 곳을 위험도로 정합니다

모든 답을 사람이 볼 수는 없습니다. 틀렸을 때의 피해와 사람이 확인하기 쉬운지로 나누면 검토를 어디에 집중할지 정해집니다.

고객에게 나가는 금액·약관·법률 안내, 의료·안전 관련 안내는 대부분 「피해 큼」에 들어갑니다. 사내 회의록 요약처럼 원문을 곧바로 확인할 수 있는 업무는 「확인 쉬움」에 가깝습니다. 검토 위치를 정할 때는 검토하는 사람의 부담도 함께 계산합니다. 모든 답을 승인 대상으로 두면 검토가 형식이 되고, 결국 아무도 꼼꼼히 보지 않게 됩니다. 사람의 확인은 피해가 큰 곳에 모아 둘 때 효과가 있습니다.

고객 응대라면 「모른다」 다음 단계도 설계해야 합니다. AI가 답을 확인할 수 없다고 말한 뒤 담당자 연결이나 문의 접수로 자연스럽게 넘어가지 않으면, 사용자는 같은 질문을 표현만 바꿔 다시 묻고 그 과정에서 지어낸 답을 받을 가능성이 커집니다.

오답을 평가 세트로 되돌립니다

환각 관리는 한 번 설정하고 끝나는 일이 아닙니다. 사용자가 오답을 신고할 수 있게 하고, 신고된 사례의 원인을 나눠 고친 뒤 같은 사례를 평가 세트에 넣어 다시 틀리지 않는지 확인합니다.

1. 오답 신고
2. 원인 분류
3. 수정
4. 평가 세트에 추가
5. 재평가 후 반영

원인은 대체로 네 갈래로 나뉩니다. 검색이 맞는 문서를 못 찾은 경우, 찾았지만 잘못 읽은 경우, 근거 없이 지어낸 경우, 근거 문서 자체가 틀리거나 낡은 경우입니다. 검색 실패는 문서 분할과 검색 설정을, 근거 오독은 생성 지시와 인용 방식을, 근거 없는 창작은 「모른다」 지시와 근거 일치 검사를, 낡은 문서는 문서 개정 절차와 색인 갱신을 고칩니다. 원인마다 고칠 곳이 다르므로 「모델이 틀렸다」로 뭉뚱그리지 않는 것이 중요합니다.

참고 자료

• Anthropic — Reduce hallucinations
• AWS — Amazon Bedrock Guardrails contextual grounding check
• AWS — Amazon Bedrock Guardrails 지원 언어
• OWASP Top 10 for LLM Applications 2025