12.7.4 LLM이 생성한 쿼리의 환각(Hallucination) 패턴 분석: 존재하지 않는 컬럼/테이블

자연어를 입력받아 SQL을 추출해 내는(Text-to-SQL) 프롬프트 태스크의 세계에서, 대규모 언어 모델(LLM)이 저지르는 가장 흔하고 지독한 오류는 단순한 문법적 오타나 괄호 누락 같은 구문 파괴(Syntax Error)가 결코 아니다. 이보다 수십 배나 빈번하고 엔지니어링 적으로 해결이 까다로운 끔찍한 문제는, 문법적이고 구조적인 뼈대 자체는 완벽하게 우아하지만, 시스템의 RAG 문맥(Context Window) 프롬프트 힌트나 데이터베이스의 실제 DDL 스키마 상에 전혀 선언되지 않은 가상의 유령(Ghost) 데이터 객체(존재하지 않는 테이블, 허구의 컬럼)를 망각 속에 지어내어 뻔뻔하게 호출을 시도해 버리는 극단적인 망상 환각(Hallucination) 현상이다.

오라클의 실행기(Executor) 샌드박스는 엔진에 이러한 유령 객체 호출 트리거가 타격되는 순간, 가차 없이 Table not found 또는 Column does not exist 예외를 내다 버리며 Execution Error (0점)를 선고한다. 그러나 진정으로 훌륭한 아키텍트라면, 이 심오한 인지적 붕괴 현상을 12.5.5절에서 다룬 단순한 오타 기반의 Syntax Error 와 똑같이 뭉뚱그려 치부해 버려서는 안 된다. 만약 그렇게 방치한다면, 데이터 사이언티스트는 AI 신경망 파이프라인의 어느 계층(Attention, Prompt, Schema Map)에서 논리가 꼬였는지 평생 영원히 디버깅할 수 없게 된다.

따라서 오라클의 로그 분석기는 데이터베이스 엔진이 내뱉는 그 짧은 에러 시그니처를 정밀하게 해부하여, LLM의 치명적인 환각 현상을 구체적인 원인에 따라 다음의 3가지 심층 패턴으로 발라내어 분류(Classification)하고 피드백해야만 한다.

1. 사전 학습 상식망의 강제 오버라이드 (World Knowledge Override)

가장 빈번한 환각 패턴이다. 엔터프라이즈 환경에서 “오늘 가입한 사용자의 프로필 데이터를 조회해 줘“라고 프롬프트를 날렸으나, 오라클이 RAG 메타데이터를 통해 컨텍스트로 제공한 정확한 컬럼 이름은 registered_datetime 이나 usr_cre_dt 같은 레거시 네이밍이었다고 치자.
이 찰나의 순간, LLM의 뇌리 속에서는 수조 개의 파라미터로 사전에 학습(Pre-train)된 거대한 오픈소스 커뮤니티의 ’상식적인 네이밍 통계 구조’가 로컬 컨텍스트 윈도우의 제어력을 찢어발기고 튀어나온다. 결국 모델은 주어진 RAG 스키마를 깡그리 무시하고 깃허브(GitHub)에서 가장 흔해빠진 created_at 이나 join_date 라는 유령 컬럼으로 마음대로 조작해서 호출해 버린다.

이 현상은 LLM의 언어 능력이 나쁜 것이 아니라, **“모델의 사전 상식망 크기가 RAG 프롬프팅의 제약 통제력(Attention Constraints)을 억눌러버리고 압도한 현상(World Knowledge Override)”**이다. 오라클의 디버깅 메트릭은 예외를 즉각 파싱하여 이 에러를 HALLUCINATION_TYPE_SCHEMA_OVERRIDE 로 맵핑하고, 프롬프트 엔지니어에게 “모델에 주입하는 스키마 정보의 어텐션 가중치(Weight/Focus)를 더 강력히 고정할 것“이라는 처방을 내려야 한다.

2. 모호성 해소 실패와 축약 환각 (Ambiguous Identifier Collapse)

이 환각은 거대한 다중 조인(Multi-Join) 파이프라인에서 극도로 빈번하게 창궐한다. 두 개 테이블의 조인축을 세팅하면서 양쪽 엔티티 테이블에 모두 id 형식의 범용 식별자 컬럼이나 status 같은 상태 컬럼이 중복으로 존재할 때 폭발한다.

SELECT id FROM employees JOIN departments ON employees.dept_id = departments.id;

LLM이 어텐션(Attention) 자원을 조인 연산 자체에 모조리 쏟아붓느라 집중력이 소진된 나머지, 정작 SELECT 프로젝션 절의 id가 도대체 employees.id를 뜻하는 것인지 departments.id를 뜻하는 것인지 소속 접두사(Prefix Alias) 매핑을 까먹고 누락해 버린 전형적 패턴이다. 엔진은 분노하여 column reference "id" is ambiguous 예외를 던진다.
오라클 시스템은 이 에러를 차단하여, “AI 자체가 스키마를 못 읽는 것이 아니라, 조인 계층에서의 추상적 다형성 명확화(Alias Resolution) 코딩 논리(Logic)가 훈련되지 않아 상실되었다“는 치명타 분석 피드백(HALLUCINATION_TYPE_AMBIGUOUS_ALIAS)을 리포팅한다.

3. 벡터 매핑 실패에 의한 동의어 창조 환각 (Synonym Merging Hallucination)

인간 사용자가 추상적인 자연어로 “월간 영업군의 총 누적 매출(Total Revenue)을 가져와“라고 지시했을 때, 실제 프로덕션 DB 내부에는 고지식하게 sales_volume 테이블과 tx_amount 컬럼만이 존재함에도 불구하고, 멍청한 LLM이 비즈니스 용어와 물리 스키마를 연결하지 못하고 멋대로 revenue 또는 total_revenue라는 가상의 테이블이나 컬럼 객체를 뻔뻔하게 창조하여 구문 트리를 던질 때 발현된다.

이것은 근본적으로 AI 모델 자신의 잘못이라기보다는, 쿼리를 작성하기 위해 힌트를 제공한 RAG 검색 시스템 파이프라인이 정교한 브랜치 동의어 사전(Synonym Dictionary Mapping)이나 의미론적 밀집 벡터 검색(Dense Vector Search)을 제대로 지원하지 않아서 벌어지는 인프라의 파탄이다. 즉, LLM이 어휘 도메인을 수학적으로 융합(Reasoning)해야 하는 번역의 부담감을 독박으로 덮어쓰면서 벌어지는 **메타데이터 파이프라인 붕괴 현상(HALLUCINATION_TYPE_RAG_MISSING_LINK)**으로 판독해야 한다.

결론적으로, 위대하고 완벽한 오라클(Oracle)은 생성 엔진이 실패했을 때 단순히 0점(False)을 뱉어내고 파이프라인을 종료시키는 단무지 같은 쓰레기 단두대가 결코 아니다. 이처럼 환각이라는 깊고 난해한 에러들을 시스템 콜 커넥션 텍스트 시그니처 층에서 역으로 파싱(Parsing)해 발라내어, “LLM의 어텐션 제어 결핍 문제인가(1번)”, “AI의 네이티브 SQL 코딩 논리 부족인가(2번)”, 아니면 **“애당초 RAG 검색 파이프라인의 아키텍처 박살인가(3번)”**를 명확하고 투명하게 짚어 역공학(Reverse Engineering)해 내는 궁극의 원인 규명기(Root Cause Analyzer)로 승격 발전되어야만 한다.