같은 모델인데 대화는 멀쩡하고 Agent만 환각을 일으키는 이유는 무엇인가
← 전체 목차 · 이전: AI가 데이터를 지어내는 것을 어떻게 막나 · 다음: "한 번 더 검토하라"는 반성이 아니라면, 진짜 반성이란 무엇인가
"도구를 붙였으니 진짜 데이터를 쓰는데, 그래도 왜 틀린 결론이 나오나"는 Agent 환각의 가장 흔한 오해를 정확히 겨냥한다. 도구는 "모델이 모르는 것"을 메워줄 뿐 "모델이 알면서도 지어내는 것"은 고치지 못한다. 환각은 최종 답변 한 곳에서만 생기는 것이 아니라 의도 이해 → 작업 규획 → 파라미터 생성 → 결과 총괄이라는 전체 체인의 매 스텝에서 생길 수 있다.
대화형 모델과 Agent의 구조적 차이
| 차원 | 일반 대화 | Agent |
|---|
| 추론 형태 | 단일 회전 출력 | 다회전 자율 결정 |
| 체인 | 실행 체인 없음 | 추론 + 실행 이중 체인 |
| 결정 부담 | 없음 | 매 단계가 오류 가능 지점 |
| 환각 확률 | 극히 낮음 | 높음 |
대화 환각 = 모델 문제
Agent 환각 = 모델 + 아키텍처 + 체인 의 종합 엔지니어링 문제
다단계 연쇄 추론에서는 스텝마다 논리 편차·컨텍스트 잉여·시나리오 모호·파라미터 결손이 쌓이고, 이 편차들이 체인을 따라 누적되며 모델의 결함을 증폭시킨다.
환각이 발생하는 네 가지 전형 시나리오
| 시나리오 | 유발 조건 | 표현 |
|---|
| 도구 호출 환각 | 낯선 시나리오, 모호한 요구 | 존재하지 않는 도구를 지어내거나 파라미터를 되는대로 채움 — 호출은 발생한 것처럼 보이지만 실제로는 완전히 무효 |
| 작업 분해 환각 | 복잡한 비표준 작업 | 실행 경계를 정확히 못 잡아 과도하게 잘게 쪼개고, 같은 도구를 반복 호출하며 무한 순환에 빠짐 |
| 컨텍스트 환각 | 다회전 대화·다중 작업 중첩 | 이력 컨텍스트가 잉여로 쌓여 서로 다른 작업의 파라미터·논리를 혼동, 이전 회차 결과를 이번 회차에 잘못 적용 |
| 결과 추정 환각 | 도구 호출 실패, 데이터 공백, 조회 결과 없음 | 정상 폴백 안내 대신 스스로 데이터를 지어내거나 결과를 날조 — 오류를 내지 않고 조용히 가짜 데이터를 하류에 넘기는 가장 위험한 유형 |
"도구가 있으니 환각이 없다"는 가장 흔한 오해다. 도구가 해결하는 것은 지식 경계형 환각뿐이고, 규획 논리·파라미터 생성·결과 해석 단계의 환각은 여전히 남는다 — Agent가 데이터베이스에서 정확한 값을 조회하고도 총괄 단계에서 그 수치를 멋대로 고쳐 쓰는 사례가 이를 증명한다.
왜 완전히 없앨 수는 없는가
환각 = 대형모델 자기회귀 생성 메커니즘의 내재 속성
└─ Agent의 모든 결정/추론/생성 단계
└─ 전부 모델의 확률 출력에 의존
└─ 엔지니어링 수단은 "발생 확률을 낮출" 수만 있음
└─ 근원에서 완전히 제거할 수는 없음
환각은 지능형 Agent의 고유 속성이며, 할 수 있는 것은 리스크 관리이지 완전 소멸이 아니다.
위험 등급별 3층 방어
| 층 | 대상 | 방식 |
|---|
| 1층 · 업무 등급 구분 | 금액·규칙·권익 약속이 걸린 모든 고위험 내용 | "파라미터 추출 + 규칙 템플릿"을 강제: Agent는 대화·도구 결과에서 파라미터만 추출하고, 최종 출력은 고정 템플릿이 조립한다. 모델은 서술에 참여하지 않는다 |
| 유통 안내·상식 문의 등 저위험 내용 | RAG 강화 자유 생성을 허용해 유연성을 남겨 둔다 |
| 2층 · 생성 링크 검증·안전망 | 최종 회신 생성 전 | 출력 전 사실 검증: 핵심 수치·규칙 조항을 도구 반환·지식베이스와 대조, 불일치 시 재생성, 임계값 초과 시 안전망 문구 트리거 / 도구 결과 강제 바인딩: 구조화 데이터를 회신의 해당 위치에 강제 주입, 모델의 수치 변경 금지 / 환각 서킷 브레이커: 연속 두 라운드 사실 편차 발생 시 자동으로 사람 상담원 전환 |
| 3층 · 아키텍처 최적화 | 근원에서 환각 공간을 압축 | 지식베이스 정향 소환(구조화 분해+업무 시나리오 태깅으로 정밀 소환), 추론 제약 강화(시스템 프롬프트에 지식베이스·도구 결과로 뒷받침 안 된 결론 생성 금지 명시), 핵심 흐름 고정(반품·환불 등 표준 흐름을 사전 정의 노드로 워크플로화, Agent는 파라미터 전달만 담당하고 스스로 흐름을 규획하지 않음) |
엔트리 단계 방어 — 도구·경계·컨텍스트
| 대상 환각 | 방어 수단 |
|---|
| 도구 호출 환각 | 도구 화이트리스트(미지의 도구 일괄 불허) + 파라미터 3중 검증(형식/비어있음/타입, 불법 시 즉시 차단) + 호출 흔적 기록 |
| 작업 분해 환각 | 최대 실행 라운드·최대 도구 호출 횟수·타임아웃 설정, 초과 시 자동 종료 / 요구가 모호하면 분해 전에 전치 되묻기를 먼저 트리거 |
| 컨텍스트 환각 | 슬라이딩 윈도우 + 요약 압축으로 무효 이력을 자동 정리, 작업별 컨텍스트 격리 |
| 결과 추정 환각 | 실패/공백/결측의 세 분기에 명시적 안전망 문구를 강제, 모델의 자유 생성을 금지 |
핵심 통찰
- 환각의 심각도는 "체인의 길이"와 정비례하지 모델 성능과 정비례하지 않는다 — 같은 모델이 단일 대화에서는 거의 틀리지 않다가 도구를 붙이면 자주 뒤집힌다. 실행 체인이 매 스텝의 미세 편차를 층층이 증폭시키기 때문이다. Agent 환각을 줄이려는 노력은 체인을 짧게, 제약 있게 만드는 것을 최우선으로 삼아야 한다.
- "도구가 있으니 환각이 없다"는 가장 흔한 착각이다 — 도구가 메우는 것은 "모델이 모른다"이고, 못 고치는 것은 "모델이 알면서도 지어낸다"이다. 규획 논리·파라미터 생성·결과 해석 단계의 환각은 도구와 무관하게 그대로 남는다. 이것이 "진짜 업무 데이터를 붙였는데도 Agent가 틀린 결과를 낸다"는 역설을 설명한다.
- 완전 제거 불가능성은 생성 메커니즘 자체에서 온다 — 결정·추론·생성 세 종류 단계가 전부 확률 출력에 의존하는 한 오류율은 결코 0이 될 수 없다. 이 인정이 문제를 "고칠 수 있는가"에서 "오류율을 업무가 감당할 수 있는 수준까지 누를 수 있는가"로 바꾼다.
- 정적 흐름에 대해 "규획을 자유롭게 허용"하는 수익은 거의 0이고 리스크는 높다 — 반품·환불·항의 같은 표준화 흐름에서 Agent에게 자체 규획(planning)을 시키는 것은 재현 불가능한 분기만 끌어들인다. 사전 정의 노드로 워크플로를 짜고 Agent는 파라미터 전달만 하는 편이, "지능"을 옳은 곳에 쓰는 것이다.
- 리스크는 기능이 아니라 "출력 내용의 업무적 결과"로 나눠야 한다 — 같은 상담 Agent라도 "반품 절차가 어떻게 되나요"에 답하는 것과 "환불 금액이 얼마고 운임을 더 내야 하나요"에 답하는 것은 위험 등급이 전혀 다르다. 등급을 나눌 대상은 모듈이 아니라 "이 한마디가 캡처되면 약속이 되는가"이다.
- 고위험 출력에 대한 올바른 처방은 생성을 취소하고 조립으로 바꾸는 것이다 — 파라미터 추출 + 규칙 템플릿은 모델의 산출물을 구조화 파라미터로 만드는 것이지 자연어 결론이 아니다. 금액·기한·권익은 규칙 라이브러리에서 나와야 하며, 모델은 어느 칸을 채울지 찾는 역할만 한다.
- 안전망 없는 제약은 종이 위의 약속일 뿐이다 — 사실 검증에는 임계값과 안전망 문구가, 환각 서킷 브레이커에는 사람 상담원 진입구가 반드시 짝을 이뤄야 한다. 강등 경로 없는 검증 모듈은 압박이 걸리면 무한 재시도로 퇴화한다.
- 프롬프트 제약은 가장 약한 층이며 단독으로 쓰면 안 된다 — "뒷받침 안 된 결론 생성 금지"를 시스템 프롬프트에 쓰는 것은 3층(공간 압축)의 몫이며, 확정적 검증인 2층이 이를 받쳐줘야 한다. 세 층의 순서를 뒤바꾸면 안 된다.
엔지니어링 실전 Tips
- 도구가 고치는 환각의 종류와 못 고치는 종류를 먼저 구분할 것: 지식 경계형이면 도구·검색이 유효하고, 규획/파라미터/해석형이면 검증과 차단만 유효하다. 지식 경계형이 아닌데 도구를 더하는 것은 무효 투자다.
- "한 스텝 더 늘어난 것"도 사고로 취급할 것: 다단계 작업 중 불필요한 스텝 하나가 더 들어가는 것은 규획 잉여의 전형이다. 에러도 안 나고 멈추지도 않아서 가장 놓치기 쉽지만, 부작용 있는 작업에서는 대가가 가장 크다.
- 월권 파라미터는 안전 문제이지 정확도 문제가 아니다: 권한·범위를 벗어난 파라미터 생성은 호출 입구 실패이므로, 화이트리스트 검증은 결과가 나온 뒤가 아니라 실행 전에 걸어야 한다.
- 검증은 강제로 만들 것, 건의로 만들지 말 것: 모델이 결론과 원본 데이터의 일치성을 강제로 검증하게 해야 한다. 검증을 프롬프트 속 부탁 한 줄로 만들면 확률적 준수에 그친다.
- 인력 검토는 위험 등급별로 투입할 것: 전량 인력 검토는 비용을 감당 못 하고, 전자동은 고위험을 못 견딘다. 등급별 안전망의 가치는 제한된 인력을 정보량이 가장 큰 표본에 배치하는 데 있다.
- "완전히 없앨 수 없다"를 설계 문서에 명시할 것: 시스템 설계는 환각이 반드시 일어난다는 전제로 차단 지점·강등 지점·역추적 경로를 미리 남겨야 하며, 정확성을 전제 조건으로 삼으면 안 된다.
- 상용 Agent의 온라인 전 핵심 테스트는 환각 리스크 압박 테스트다: "통과했는가"가 아니라 "오류율과 차단률"을 통과 기준으로 삼는 것이, 오류가 반드시 발생한다는 것을 인정하는 검수 방식이다.