AI가 작성한 사내 규정 안내문에 문서명과 조항 번호까지 붙어 있으면 검증이 끝난 것처럼 보인다. 하지만 해당 조항이 없거나, 원문에 없는 예외 조건을 덧붙였다면 문장이 자연스러워도 업무에는 사용할 수 없다.
기업에서 할루시네이션을 관리하려면 “어떤 모델이 더 똑똑한가”와 함께 “답변의 근거를 누가 확인하고, 확인이 안 되면 어디서 멈추는가”를 정해야 한다. 이 글은 언어모델의 오류 원인을 살펴보고, 사내 문서 요약과 규정 안내에 적용할 수 있는 검증 기준을 제안한다.
1. 할루시네이션은 사실과 근거가 어긋나는 현상
AI 할루시네이션은 생성형 AI가 사실과 다르거나 입력 자료로 뒷받침되지 않는 내용을 그럴듯하게 생성하는 현상이다. NIST는 이를 ‘Confabulation’이라는 위험 항목으로 다루며, 잘못된 내용뿐 아니라 입력과의 불일치, 허위 인용도 설명한다.[1]
업무에서는 존재하지 않는 보고서나 링크를 만드는 오류, 원문의 금액·기한을 바꾸는 오류, 조건부 규정을 모든 상황에 적용하는 오류로 나타날 수 있다. 특히 요약문은 문장 자체가 맞는지뿐 아니라 원문의 적용 대상과 예외까지 보존했는지 확인해야 한다.
의도적으로 허구를 만드는 창작 작업과 사실 기반 답변은 평가 기준이 다르다. 또한 잘못된 검색 결과를 그대로 전달한 경우에는 모델의 생성 오류와 별도로 원천 자료의 품질도 점검해야 한다. 실무적으로는 오류가 발생한 위치를 찾아야 재발 방지 방법을 정할 수 있다.
2. 자연스러운 문장을 생성하는 능력이 사실 검증 보장은 아님
언어모델은 학습한 패턴과 입력 문맥을 바탕으로 다음 토큰을 예측하며 문장을 생성한다. 이 과정만으로 모든 주장에 대해 원문을 조회하거나 참·거짓을 판정하는 것은 아니다. 반복적으로 등장하는 표현을 잘 배워도, 드물게 등장하는 이름·날짜·문서 번호처럼 패턴만으로 추론하기 어려운 사실은 틀릴 수 있다.[2]
모델이 접근할 수 없는 사내 정보나 최신 변경 사항을 물으면 빈틈이 더 커진다. 질문에 “그 규정의 승인 예외를 설명해줘”라고 적혀 있어도, 실제로 승인 예외가 존재하는지는 별도로 확인해야 한다. 질문 자체의 전제가 사실이라는 보장은 없다.
답변을 반드시 내놓도록 유도하는 학습·평가 방식도 한 원인이다. OpenAI 연구는 불확실성을 인정하는 응답보다 추측을 보상하는 평가 관행이 자신 있는 오답을 지속시킬 수 있다고 분석한다. 따라서 기업 평가에서도 정답률과 함께 오답 및 적절한 답변 보류를 구분해 봐야 한다.[2]
3. RAG와 출처 표시는 검증의 출발점
RAG는 관련 자료를 검색해 언어모델의 답변 생성에 활용하는 방식이다. 원래 연구는 모델 내부 지식에 외부 검색 자료를 결합하고, 지식 집약적 과제에서 사실성을 개선할 가능성을 보여줬다. 다만 특정 연구 결과가 모든 기업 문서와 구현의 정확성을 보장하지는 않는다.[3]
기업에 적용할 때는 검색과 생성 단계를 나누어 확인하는 편이 유용하다. 최신 규정이 검색되지 않았다면 자료 등록·갱신이나 검색 조건을 살펴보고, 올바른 원문이 제공됐는데 답변이 달라졌다면 요약·생성 단계의 오류를 살펴볼 수 있다.
출처 링크가 붙었다고 그 문장이 입증되는 것도 아니다. 링크가 실제로 열리는지, 인용 구절이 있는지, 해당 구절이 답변의 주장을 뒷받침하는지, 적용 대상과 시행일이 맞는지 확인해야 한다. 비슷한 주제의 문서를 인용해 놓고 원문에 없는 결론을 내릴 수도 있다.
검색 자료가 부족하면 답변을 보류하고 필요한 자료를 요청하도록 설계한다. 불확실성 인정, 원문 구절 추출, 주장별 출처 확인은 Anthropic 공식 문서가 제시하는 완화 방법이다. 이러한 지시는 오류를 줄이기 위한 장치이며 정확성 보증으로 취급해서는 안 된다.[4]
4. 업무별로 검증 수준을 다르게 설정
아래 표는 이 글에서 제안하는 운영 기준 예시다. 공식 표준의 등급표가 아니며, 실제 적용 수준은 오류의 영향과 되돌릴 수 있는 정도에 맞춰 정한다.
| 업무 상황 | 먼저 확인할 내용 | 사용 전 검증 기준 |
|---|---|---|
| 아이디어·표현 초안 | 사실 주장과 창작 표현의 구분 | 외부에 공개할 사실·수치는 별도로 확인 |
| 회의록·보고서 요약 | 누락, 부정 표현, 담당자, 기한 | 핵심 결정과 할 일을 원문에 대조 |
| 사내 규정·고객 안내 | 최신 버전, 대상, 예외 조건 | 주장별 근거 확인, 근거가 없으면 답변 보류 |
| 계약·인사 등 영향이 큰 판단 | 사실관계와 판단 권한 | 담당 전문가 검토와 승인 절차 적용 |
| 운영 명령·자동 실행 | 대상 환경, 권한, 예상 영향 | 분리된 환경에서 검증하고 실행 승인 적용 |
일반적인 표현 수정과 고객에게 적용할 규정 해석을 같은 검토 수준으로 묶으면, 중요한 답변을 놓치거나 모든 결과를 과도하게 검토하게 된다. 먼저 AI가 초안까지만 만드는 업무와 검토 후 실행하는 업무의 경계를 적어 두는 편이 현실적이다.
5. 가상 예시: 출장비 규정 안내에서 오답을 막는 방법
다음은 설명을 위한 가상 예시이며 실제 기업의 규정이나 운영 사례가 아니다. 사내 출장비 규정에는 “승인된 출장에 한해 정산한다”는 내용만 있고, 신청 기한은 적혀 있지 않다고 가정한다.
직원이 “출장 후 언제까지 신청해야 하나”라고 묻자 AI가 관행을 추측해 특정 기한을 제시하면, 회사가 정하지 않은 기준이 안내문에 생긴다. 안전한 답변은 “제공된 규정에서 신청 기한을 확인할 수 없다”고 밝히고, 확인한 문서의 이름·버전·관련 구절과 문의할 담당 부서를 안내하는 것이다. 담당 부서는 실제로 확인된 경우에만 적는다.
이 상황에 사용할 수 있는 요청문은 다음과 같다.
제공된 규정만 근거로 답변하라. 각 주장에 문서명·버전·해당 구절을 표시하라. 기한이나 예외가 원문에 없으면 추정하지 말고 ‘제공 자료에서 확인 불가’로 표시하라. 문서가 서로 충돌하면 차이를 보여주고 담당자 확인으로 넘겨라.
검토자는 “확인 불가”라는 표현이 있는지만 볼 것이 아니라, 실제로 필요한 구절을 놓치지는 않았는지도 확인해야 한다. 답변 보류가 과도하면 직원이 필요한 정보도 얻지 못하므로, 올바른 보류와 검색 실패를 구분해 개선한다.
6. 실무자 관점: 경고 문구보다 검토가 가능한 구조를 생성
“AI 결과는 부정확할 수 있습니다”라는 문구만으로는 검토자가 무엇을 확인할지 알기 어렵다. 이 글의 운영 제안은 결과물마다 핵심 주장, 근거 문서와 위치, 확인하지 못한 사항을 함께 남기도록 하는 것이다. 검토자에게는 원문 접근 권한과 수정·보류 권한도 있어야 한다.
도입 전 시험에는 정답이 있는 질문뿐 아니라 자료에 답이 없는 질문, 잘못된 전제를 담은 질문, 문서가 충돌하는 질문을 포함한다. 평가할 때는 오답 비율, 근거가 주장을 실제로 뒷받침하는 비율, 답이 없는 질문에서 적절히 보류한 비율을 함께 본다. 지표별 분모를 명시해야 서로 다른 시험 결과를 비교할 수 있다.
같은 AI에게 “이 답이 맞는지 다시 확인해줘”라고 묻는 작업은 보조 검토로 사용할 수 있다. 그러나 재확인 답변에도 원문 근거가 없다면 최초 답변의 정확성이 입증된 것은 아니다. 문제가 발견되면 질문·검색 자료·생성 답변·수정 내용을 묶어 원인을 분석하되, 기록에 포함된 민감정보의 접근 범위와 보존기간도 정한다.
7. 결론: 근거가 없을 때 멈출 수 있는 업무로 설계한다
AI 활용 범위를 정할 때는 답변의 자연스러움보다 오류가 미치는 영향과 검증 가능성을 먼저 본다. 원문을 확인할 수 있고 결과를 수정하기 쉬운 업무에서 시작한 뒤, 근거 확인과 답변 보류가 실제로 작동하는지 시험하는 방식이 적절하다.
특히 규정 안내나 대외 답변에는 “근거 없는 주장은 내보내지 않는다”는 기준을 적용할 수 있다. 문서가 없거나 서로 충돌하는 상황을 정상적인 확인 요청으로 처리할 수 있어야, AI가 만들어 낸 빈틈을 회사의 공식 기준으로 오해하는 일을 줄일 수 있다.