한계와 완화 전략

신뢰는 낙관이 아니라 설계에서 나온다

ChatGPT를 잘 쓰는 사람과 위험하게 쓰는 사람의 차이는 "AI를 믿느냐, 안 믿느냐"가 아니다. 정말 중요한 차이는 언제 믿을 수 없는지 아는가에 있다. 생성형 AI는 놀라울 만큼 유창하게 말하지만, 그 유창함이 곧 사실성이나 책임성을 뜻하지는 않는다. 오히려 가장 위험한 순간은 답변이 허술해 보일 때가 아니라, 틀린 답이 그럴듯하고 단정적인 문장으로 포장될 때다.

그래서 이 장의 출발점은 단순하다. ChatGPT를 신뢰하려면 먼저 실패를 이름 붙일 수 있어야 한다. "환각이 있다"는 말만으로는 부족하다. 어떤 환각인지, 어느 단계에서 생겼는지, 어떤 장치로 줄일 수 있는지까지 나누어 보아야 한다. 최근 환각 완화 연구들도 대체로 같은 방향으로 움직인다. 모델 자체를 완벽하게 만드는 것보다, 외부 지식 검색, 추론 검증, 도구 사용, 인간 검토를 결합해 검증 가능한 시스템을 만드는 쪽이 현실적인 해법으로 여겨진다¹.

이 장에서는 ChatGPT의 실패를 겁주기 위한 목록이 아니라, 업무 설계자가 손에 쥘 수 있는 진단표로 정리한다. 실패는 피할 수 없지만, 실패가 조용히 통과하는 구조는 피할 수 있다.

환각은 하나가 아니다

많은 사람이 환각을 "AI가 거짓말을 하는 현상"이라고 부른다. 이해하기 쉬운 표현이지만 정확하지는 않다. ChatGPT는 보통 사람처럼 사실을 알고도 속이기 위해 거짓말을 한다기보다, 주어진 문맥에서 그럴듯한 다음 문장을 생성하다가 실제 세계, 제공 문서, 사용자의 지시와 어긋나는 내용을 만들어 낸다. 따라서 환각을 윤리적 의도보다 실패 유형으로 보아야 한다.

실무에서는 다음처럼 나누어 보는 편이 유용하다.

이 구분이 중요한 이유는 대응책이 서로 다르기 때문이다. 최신성 부족은 "더 생각해 봐"라고 해도 해결되지 않는다. 웹 검색이나 최신 데이터베이스 연결이 필요하다. 형식 위반은 검색을 잘한다고 해결되지 않는다. JSON 스키마, 필드 검증, 후처리 파서가 필요하다. 출처 왜곡은 "출처를 달아 줘"만으로는 부족하다. 답변 문장과 근거 문장을 실제로 대조해야 한다.

환각은 크게 지식 기반 오류와 논리 기반 오류로 나누어 볼 수도 있다. 지식 기반 오류는 모델이 모르거나 오래된 지식을 갖고 있을 때 생기고, 논리 기반 오류는 주어진 정보가 있어도 단계적 판단이 어긋날 때 생긴다. RAG는 전자에 강하고, 검증 루프와 도구 기반 추론은 후자에 더 강하다¹.

실패는 어느 단계에서 생겼는가

ChatGPT 답변 하나는 단순히 "모델이 말했다"로 끝나지 않는다. 특히 업무 시스템에서는 사용자의 질문이 들어오고, 필요한 문서가 검색되고, 그 문서가 문맥으로 구성되며, 모델이 답을 만들고, 출력 형식이 후처리된다. 실패도 이 흐름 어딘가에서 생긴다.

먼저 모델 지식 단계의 실패가 있다. 모델이 학습 시점 이후의 사건을 모르거나, 특정 조직의 내부 규정처럼 공개되지 않은 지식을 알지 못하는 경우다. "우리 회사의 2026년 출장비 규정에 맞춰 답해 줘"라고 했는데 규정을 제공하지 않으면, 모델은 일반적인 회사 규정처럼 보이는 답을 만들어 낼 수 있다.

다음은 검색 단계의 실패다. RAG나 파일 검색을 붙였는데도 엉뚱한 문서 조각을 가져오는 경우다. 질문은 "퇴직금 중간정산 조건"인데 검색 결과가 "연차수당 정산" 문서 위주라면, 모델은 검색된 문서를 억지로 이용해 틀린 답을 낼 수 있다. 이때 문제는 모델의 문장력이 아니라 검색 품질이다.

세 번째는 문맥 구성 단계의 실패다. 관련 문서를 찾았더라도 너무 작게 쪼개 핵심 조건이 빠졌거나, 반대로 너무 크게 넣어 중요한 문장이 묻힐 수 있다. 문서의 앞부분에는 원칙이 있고 뒷부분에는 예외가 있는데 예외 조항만 검색되면 답변은 틀어진다.

마지막은 생성 단계의 실패다. 근거가 충분해도 모델이 결론을 과장하거나, 사용자 요구 형식을 깨거나, 모르는 부분을 모른다고 하지 않고 빈칸을 채우는 경우다. 그래서 "좋은 모델을 쓰면 된다"는 말은 절반만 맞다. 좋은 모델은 필요하지만, 좋은 입력·검색·검증·운영 절차가 없으면 실패는 계속 새어 나온다.

RAG는 만능 해결책이 아니다

RAG, 즉 검색 증강 생성은 ChatGPT의 환각을 줄이는 가장 대표적인 방법이다. 모델에게 모든 것을 기억하게 하려 하지 않고, 답변 직전에 외부 문서나 데이터베이스에서 관련 정보를 찾아 문맥으로 넣어 주는 방식이다. 쉽게 말해, 시험을 볼 때 기억에만 의존하지 않고 참고 자료를 펼쳐 놓고 답하게 하는 것이다.

하지만 참고 자료를 펼쳐 준다고 늘 정답을 쓰는 것은 아니다. 잘못된 자료를 펼쳐 주면 더 자신 있게 틀릴 수 있다. RAG 기반 시스템에서도 환각은 검색 전, 검색 중, 검색 후 여러 단계에서 발생한다. RAG 환각 완화 연구들은 이 문제를 단일 프롬프트가 아니라 수집, 분할, 검색, 재정렬, 생성, 검증을 포함한 파이프라인 전체의 문제로 다룬다².

좋은 RAG는 대체로 다음 흐름을 갖는다.

1. 사용자의 질문을 검색하기 좋은 형태로 바꾼다.

2. 신뢰할 수 있는 문서 범위를 정하고 최신성을 관리한다.

3. 문서를 적절한 크기로 나누고 메타데이터를 붙인다.

4. 임베딩 검색, 키워드 검색, 필터링을 조합해 후보를 찾는다.

5. 재랭킹으로 실제 질문에 더 맞는 근거를 앞에 둔다.

6. 충돌하는 근거가 있으면 답변 전에 표시하거나 우선순위를 정한다.

7. 최종 답변이 근거에 충실한지 다시 검사한다.

여기서 첫 단계인 쿼리 재작성은 생각보다 중요하다. 사용자는 "이거 가능한가요?"라고 묻지만, 검색 시스템은 "육아휴직 중 겸직 가능 여부, 내부 인사규정, 근로계약, 승인 절차" 같은 키워드를 필요로 할 수 있다. 질문을 검색용으로 바꾸지 않으면 관련 문서를 놓치기 쉽다.

문서 수집 범위도 중요하다. 사내 규정 챗봇을 만들면서 오래된 규정, 폐기된 양식, 개인 메모까지 함께 색인하면 검색 결과가 오염된다. 지식베이스는 많을수록 좋은 것이 아니라, 정확하고 관리되는 문서가 많을수록 좋다. 이 차이를 놓치면 RAG는 환각 방지 장치가 아니라 환각 공급 장치가 된다.

청킹, 즉 문서 분할은 RAG의 품질을 크게 좌우한다. 너무 작게 나누면 답변에 필요한 조건과 예외가 떨어져 나간다. 너무 크게 나누면 검색은 되었지만 모델이 핵심 문장을 놓칠 수 있다. 계약서라면 조항 단위, 매뉴얼이라면 절차 단위, FAQ라면 질문-답변 쌍 단위처럼 문서의 성격에 맞게 잘라야 한다.

재랭킹은 검색된 후보 중 실제로 질문에 가장 잘 맞는 문서를 다시 정렬하는 과정이다. 임베딩 검색은 의미가 비슷한 문서를 잘 찾지만, 의미가 비슷하다고 답이 있는 것은 아니다. 예를 들어 "환불 불가 예외"를 묻는 질문에 "환불 정책 일반 안내"가 먼저 나올 수 있다. 재랭킹은 이런 후보를 더 정밀하게 고르는 단계다.

마지막으로 근거 충실성 검사가 필요하다. 답변 문장 하나하나가 검색된 근거에서 실제로 지지되는지 확인해야 한다. "문서에 따르면"이라는 말이 붙었다고 문서 기반 답변이 되는 것은 아니다. 답변의 각 주장 옆에 근거 문서 ID, 조항, 페이지, 문장을 연결할 수 있어야 한다.

도구는 서로 다른 문제를 줄인다

ChatGPT에 도구를 붙이면 더 안전해진다고 생각하기 쉽다. 맞는 말이지만, 조건이 있다. 어떤 도구가 어떤 실패를 줄이는지 알아야 한다. 도구는 마법의 안전벨트가 아니라 각각 다른 사고를 막는 장비다.

웹 검색과 파일 검색은 주로 "무엇을 근거로 답할 것인가"를 개선한다. 함수 호출은 "어떤 시스템 작업을 정확히 실행할 것인가"를 다룬다. structured outputs는 "출력이 시스템이 읽을 수 있는 형식인가"를 통제한다. 이 셋은 서로 대체재가 아니다.

예를 들어 고객 서비스 자동화에서 고객의 환불 가능 여부를 판단한다고 하자. 파일 검색은 환불 정책 문서를 가져온다. DB 조회는 해당 고객의 주문일, 결제 상태, 배송 상태를 확인한다. 모델은 정책과 주문 정보를 종합해 초안을 만든다. structured outputs는 결과를 eligible, reason, next_action 같은 필드로 정리한다. 함수 호출은 승인된 경우에만 환불 요청 티켓을 생성한다. 고액 환불이면 human-in-the-loop 단계에서 사람이 승인한다. 이 흐름이 바로 도구를 "많이" 쓰는 것이 아니라 "제자리에" 쓰는 방식이다.

특히 structured outputs에 대해서는 오해를 조심해야 한다. JSON 형식으로 답을 받으면 뭔가 더 정확해 보이지만, 그것은 형식 안정성의 문제다. "risk_level": "low"라는 값이 스키마에 맞게 들어왔다고 해서 실제 위험이 낮다는 뜻은 아니다. 형식 검증은 필요조건이지 사실 검증이 아니다.

답을 검증하는 질문을 따로 설계하라

좋은 프롬프트는 좋은 답을 얻는 데 도움이 된다. 그러나 신뢰할 수 있는 업무 흐름에서는 답을 얻는 프롬프트와 답을 검증하는 프롬프트를 분리해야 한다. 생성과 검증은 성격이 다르기 때문이다. 답을 만드는 일은 넓게 탐색해야 하지만, 답을 검증하는 일은 좁고 엄격해야 한다.

실무에서 바로 쓸 수 있는 검증 루프는 다음과 같다.

1단계: 초안 생성
- 주어진 문서와 질문을 바탕으로 답변 초안을 만든다.
- 모르는 내용은 '근거 없음'으로 표시한다.

2단계: 근거 추출
- 답변의 핵심 주장 5개 이내를 뽑는다.
- 각 주장에 대응하는 근거 문장, 문서명, 위치를 연결한다.

3단계: 대조 검증
- 각 주장이 근거에서 직접 지지되는지 판단한다.
- 직접 지지 / 간접 추론 / 근거 부족 / 근거와 충돌로 표시한다.

4단계: 반례 탐색
- 결론을 뒤집을 수 있는 예외 조건이나 반대 근거를 찾는다.

5단계: 최종 답변
- 근거 부족 또는 충돌이 있는 주장은 삭제하거나 불확실성으로 표시한다.

이 루프의 핵심은 "더 신중하게 답해"가 아니라 검사 가능한 중간 산출물을 요구하는 데 있다. 근거 문장을 요구하면 출처 왜곡을 줄일 수 있고, 반례 찾기를 요구하면 권위 편향과 과도한 단정을 줄일 수 있다. 다중 샘플 비교도 유용하다. 같은 질문에 대해 여러 번 답을 생성했을 때 결론이 크게 갈리면, 그 자체가 경고 신호다.

여기서 한 걸음 더 나아간 아이디어가 semantic entropy, 즉 의미적 엔트로피 방식의 불확실성 진단이다. 이 방법은 여러 답변을 생성한 뒤 표현이 아니라 의미가 같은 답끼리 묶고, 의미 집합이 얼마나 흩어져 있는지를 본다. 문장은 다양하지만 결론이 같으면 불확실성이 낮고, 서로 다른 의미의 답이 여러 갈래로 나뉘면 모델이 임의로 지어낼 가능성이 높다고 보는 방식이다³.

실무자는 이 개념을 꼭 수식으로 구현하지 않아도 된다. 중요한 질문에는 같은 모델에 여러 번 묻거나, 다른 모델·다른 검색 조건·다른 프롬프트로 재질문해 보라. 답변들의 말투가 다른 것은 괜찮다. 그러나 결론, 수치, 근거, 추천 행동이 크게 갈린다면 바로 사용하지 말고 사람 검토나 추가 검색으로 넘겨야 한다.

고위험 업무에는 사람이 들어가야 한다

AI 자동화에서 가장 위험한 문장은 "이제 사람은 필요 없다"이다. 실제 현업에서는 사람을 모두 빼는 것보다, 사람이 들어갈 지점을 정확히 정하는 편이 훨씬 강력하다. human-in-the-loop는 AI가 할 수 없는 일을 사람이 대신 반복한다는 뜻이 아니다. AI가 대량 처리와 초안 생성을 맡고, 사람은 책임·맥락·윤리·예외 판단이 필요한 지점에 개입하는 구조다.

특히 의료, 법률, 금융, 인사, 보안 업무에서는 오답 비용이 크다. 잘못된 의료 안내는 환자의 안전을 해칠 수 있고, 잘못된 법률 문구는 계약상 손해로 이어질 수 있다. 금융 리스크 메모의 오류는 투자자나 소비자에게 피해를 줄 수 있으며, 인사 평가 자동화의 편향은 개인의 경력에 영향을 미친다. 보안 자동화의 잘못된 실행은 시스템을 중단시키거나 민감 정보를 노출할 수 있다.

이런 영역에서는 다음 네 가지 통제를 기본값으로 두어야 한다.

• 인간 승인: 최종 판단, 외부 발송, 금전 이동, 권한 변경, 의료·법률·금융 조언에는 승인자를 둔다.

• 승인 로그: 누가, 언제, 어떤 근거로 승인했는지 기록한다.

• 출처 보존: 최종 답변뿐 아니라 근거 문서, 검색 시점, 사용한 버전을 함께 남긴다.

• 감사 가능성: 나중에 오류가 발견되었을 때 입력, 검색 결과, 모델 출력, 사람 수정 내역을 추적할 수 있게 한다.

LangChain 같은 에이전트 프레임워크도 민감한 도구 호출 전에 사람 승인을 요구하거나, 개인정보를 탐지해 마스킹·차단하는 가드레일을 제공한다. 이런 장치는 편의 기능이 아니라 운영 리스크를 줄이는 안전장치다⁴.

반면 모든 업무에 동일한 무게의 검토를 붙이면 자동화의 장점이 사라진다. 회의록 초안, 아이디어 발상, 문체 변환, 내부 브레인스토밍처럼 회복 가능한 저위험 작업은 더 많이 자동화해도 된다. 다만 저위험 업무라도 완전히 방치해서는 안 된다. 샘플링 검수, 실패 알림, 사용자 신고 버튼, 정기 품질 점검을 붙이면 작은 오류가 반복되어 큰 신뢰 하락으로 번지는 일을 막을 수 있다.

위험도에 따라 자동화 수준을 다르게 정하라

업무를 자동화할지 말지 판단할 때는 "AI가 할 수 있는가"보다 "틀렸을 때 어떤 일이 생기는가"를 먼저 물어야 한다. 다음 기준표를 조직의 AI 사용정책 초안으로 삼을 수 있다.

이 표의 목적은 AI 사용을 막는 것이 아니다. 오히려 안전한 사용 범위를 넓히기 위한 것이다. 저위험 업무까지 모두 금지하면 사람들은 비공식적으로 AI를 쓰기 시작한다. 반대로 고위험 업무까지 무심코 자동화하면 한 번의 오류가 조직 전체의 신뢰를 무너뜨릴 수 있다.

좋은 운영 원칙은 명확하다. 회복 가능한 일은 빠르게 자동화하고, 회복하기 어려운 일은 느리게 승인하라.

지속적 품질관리로 이어져야 한다

환각 완화는 프롬프트 몇 줄로 끝나지 않는다. 실제 조직에서 필요한 것은 지속적 품질관리 체계다. 처음에는 잘 작동하던 챗봇도 문서가 바뀌고, 정책이 바뀌고, 사용자의 질문 패턴이 바뀌면 성능이 흔들린다. 그래서 운영 중 모니터링이 필요하다.

품질관리는 다음 흐름으로 설계할 수 있다.

1. 지식베이스 관리: 승인된 문서만 색인하고, 문서 소유자·버전·폐기일을 관리한다.

2. 검색 품질 평가: 대표 질문 세트를 만들고, 정답 근거 문서가 상위 검색 결과에 나오는지 주기적으로 확인한다.

3. 답변 형식 검증: JSON, 표, 필수 필드, 금지 표현을 자동 검사한다.

4. 근거 기반 채점: 답변의 핵심 주장이 실제 근거로 지지되는지 평가한다.

5. 사용자 피드백 수집: "도움 됨/안 됨" 수준을 넘어 오류 유형, 누락 문서, 잘못된 근거를 받는다.

6. 운영 모니터링: 실패율, 재질문율, 사람 승인 반려율, 비용, 지연시간을 추적한다.

이때 중요한 것은 단순 만족도보다 실패 신호를 보는 것이다. 사용자가 같은 질문을 반복한다면 답이 불명확했을 수 있다. 사람이 승인 단계에서 자주 고친다면 모델보다 검색이나 지시문에 문제가 있을 수 있다. 특정 문서가 검색 결과에 자주 나오지만 답변 오류도 함께 늘어난다면 그 문서가 오래되었거나 청킹이 잘못되었을 수 있다.

전문가 검토는 모든 출력에 붙일 필요는 없지만, 고위험·고불확실성·고빈도 업무에는 반드시 필요하다. 보안 코드 분석처럼 전문성이 높은 영역에서는 AI가 근거와 의심 지점을 정리하고, 인간 전문가가 최종 판단을 내리는 방식이 책임성과 효율성을 함께 높일 수 있다⁵.

실무용 실패 진단 프롬프트

아래 프롬프트는 AI 답변을 받은 뒤 바로 붙여서 쓸 수 있는 점검용이다. 중요한 보고서, 고객 답변, 리서치 메모를 만들 때 초안 생성 프롬프트와 분리해 사용하면 좋다.

아래 답변을 검증하라.

검증 대상 답변:
[여기에 답변 붙여넣기]

사용 가능한 근거:
[문서, 링크, 데이터, 내부 규정 등 붙여넣기]

검증 기준:
1. 핵심 주장 5개 이내로 분해하라.
2. 각 주장에 대해 근거가 있는지 표시하라.
   - 직접 근거 있음
   - 간접 추론만 가능
   - 근거 부족
   - 근거와 충돌
3. 날짜, 수치, 고유명사, 법령명, 금액을 별도로 점검하라.
4. 답변이 근거보다 과장한 부분을 찾아라.
5. 반례나 예외 조건이 있으면 제시하라.
6. 최종적으로 다음 중 하나로 판정하라.
   - 그대로 사용 가능
   - 수정 후 사용
   - 추가 근거 필요
   - 전문가 검토 필요

출력 형식:
- 종합 판정:
- 수정이 필요한 문장:
- 근거 부족 주장:
- 추가 확인 질문:
- 전문가 검토 필요 여부:

이 프롬프트의 장점은 모델에게 "네가 맞니?"라고 묻지 않는다는 데 있다. 대신 주장을 쪼개고, 근거와 대조하고, 불확실성을 표시하게 한다. 검증은 겸손한 태도의 문제가 아니라 구조의 문제다.

실패를 줄이는 조직의 습관

ChatGPT를 안전하게 쓰는 조직은 대개 비슷한 습관을 갖고 있다. 첫째, 중요한 지식을 채팅창에만 두지 않는다. 원본 문서, 승인된 템플릿, 버전 관리된 정책 저장소를 따로 둔다. 둘째, 모델의 답변을 최종 산출물이 아니라 검토 가능한 초안으로 본다. 셋째, 실패 사례를 숨기지 않고 분류한다. "AI가 이상했다"가 아니라 "검색 누락", "출처 왜곡", "형식 위반", "승인 누락"처럼 기록한다.

넷째, 자동화의 성공을 사용량으로만 측정하지 않는다. 사용자가 많이 썼다는 사실은 가치의 증거가 아니다. 재작업 시간이 줄었는지, 오류율이 낮아졌는지, 승인 반려율이 감소했는지, 고객 불만이 줄었는지 보아야 한다. 다섯째, 사람의 개입을 실패로 보지 않는다. 좋은 human-in-the-loop는 자동화가 덜 된 상태가 아니라, 책임 있는 자동화가 완성된 상태다.

마지막으로, AI를 믿을 수 있게 만드는 가장 현실적인 방법은 AI에게 더 큰 권한을 주는 것이 아니라 더 좋은 경계와 더 좋은 피드백을 주는 것이다. 신뢰할 수 있는 지식베이스, 정교한 검색, 엄격한 형식 검증, 근거 기반 평가, 인간 승인, 운영 모니터링이 함께 움직일 때 ChatGPT는 위험한 말솜씨가 아니라 강력한 업무 파트너가 된다.

이 장의 결론은 단순하다. 환각을 완전히 없애는 비법은 없다. 그러나 환각이 중요한 결정을 통과하지 못하게 만드는 설계는 가능하다. AI 시대의 신뢰는 "모델이 완벽하다"는 믿음에서 나오지 않는다. 틀릴 수 있음을 전제로 만든 시스템에서 나온다.

참고

¹Mitigating Hallucination in Large Language Models (LLMs): An Application-Oriented Survey on RAG, Reasoning, and Agentic Systems

²Hallucination Mitigation for Retrieval-Augmented Large Language Models: A Review

³Detecting hallucinations in large language models using semantic entropy

⁴Guardrails - Docs by LangChain

⁵Scaling Expert Oversight of AI: HackerOne's Human-in-the-Loop Methodology