환각은 프롬프트만으로 해결되지 않는다

정확한 답을 만드는 일은 프롬프트 문장을 더 정교하게 다듬는 것만으로 끝나지 않는다. 많은 실무자가 처음에는 이렇게 기대한다. "정확하게 답해", "추측하지 마", "모르면 모른다고 말해" 같은 지시를 충분히 강하게 쓰면 모델이 틀린 말을 멈출 것이라고 생각한다. 하지만 실제 운영 환경에서는 이런 기대가 자주 무너진다. 모델은 그럴듯한 문장을 만드는 데 매우 능숙하고, 그 능력은 때로는 정확성보다 먼저 드러난다. 그래서 환각은 단순한 태도 문제라기보다 구조의 문제다.

이 장에서는 환각이 왜 생기는지, 왜 지시만으로는 충분하지 않은지, 그리고 왜 grounding, 즉 답변이 의존할 근거를 함께 설계해야 하는지를 살펴본다. 핵심은 간단하다. 정확성은 "정확하게 말하라"는 요구에서 자동으로 생기지 않는다. 정확할 수 있는 정보 공급 구조가 있어야 한다.

환각은 왜 생기는가

환각이라는 말은 자극적이지만, 실무적으로는 더 차분하게 이해할 필요가 있다. 모델이 아무 근거 없이 이상한 말을 한다는 뜻으로만 보면 본질을 놓치기 쉽다. 많은 경우 환각은 모델이 "거짓말을 하려는 것"이 아니라, 주어진 입력과 학습된 패턴을 바탕으로 가장 그럴듯한 다음 문장을 이어 가는 과정에서 생긴다.

언어 모델은 기본적으로 문장을 생성하는 시스템이다. 질문을 받으면 데이터베이스에서 단일한 정답을 꺼내는 방식이 아니라, 확률적으로 가장 자연스러운 출력을 조합한다. 바로 이 지점이 강점이면서 약점이다. 문장을 매우 유창하게 만들 수 있지만, 유창함과 사실성은 같은 것이 아니다. 말이 매끄럽다고 해서 근거가 있다는 뜻은 아니다.

환각이 생기는 원인을 조금 더 나누어 보면 이해가 쉬워진다.

• 모델이 질문에 답할 만한 최신 정보나 특정 조직 내부 정보를 갖고 있지 않은데도, 답변 형식을 유지하려고 할 때

• 질문이 애매하거나 누락된 조건이 많은데, 모델이 빈칸을 추정으로 메우려 할 때

• 학습 데이터 안에 비슷하지만 다른 패턴이 많아, 실제 사실 대신 평균적인 문장을 조립할 때

• 답변 형식이 지나치게 단정적이어서, 불확실성을 표현하기보다 완결된 문장을 우선 만들 때

• 프롬프트가 근거보다 완성도를 강하게 요구해서, 모델이 "답을 비워 두는 것"보다 "무언가를 채워 넣는 것"을 선택할 때

이 다섯 가지는 서로 따로 노는 문제가 아니다. 실제 서비스에서는 한꺼번에 섞여 나타난다. 예를 들어 사내 정책 문서를 묻는 질문에 모델이 최신 문서를 보지 못한 상태에서, 예전 규정과 일반적인 기업 정책의 패턴을 섞어 그럴듯한 답을 만들 수 있다. 읽는 사람은 자연스럽고 자신감 있는 문장을 보며 쉽게 속는다. 환각이 위험한 이유는 틀린 답이 허술하게 보이지 않기 때문이다.

환각은 무지의 표시가 아니라 과잉 완성의 결과이기도 하다

많은 초보 설계자는 모델이 모르면 침묵하거나 주저할 것이라고 생각한다. 하지만 언어 모델은 침묵보다 완성을 더 잘한다. 질문이 주어지면 무언가를 이어서 말하는 쪽이 기본 동작에 가깝다. 그래서 환각은 "아는 척"의 문제이기도 하지만, 더 정확하게는 "문장을 완성하려는 습관"의 문제다.

예를 들어 사용자가 "우리 회사 출장비 규정상 일본 출장은 1일 식비 한도가 얼마야?"라고 묻는다고 하자. 모델이 해당 회사 규정을 실제로 보지 못했다면 가장 안전한 답은 "근거 문서가 없으므로 확인이 필요하다"여야 한다. 하지만 모델은 종종 일반적인 출장비 규정의 상식, 과거에 봤을 법한 숫자, 또는 비슷한 문맥의 표현을 엮어 대답한다. 숫자 하나만 틀려도 업무상 문제는 충분히 커질 수 있다.

여기서 중요한 점은 모델이 숫자를 지어냈다는 사실보다, 그렇게 지어낸 숫자가 너무 자연스럽다는 사실이다. 환각은 대개 파손된 문장으로 오지 않는다. 완성도 높은 문장으로 온다. 그래서 더 위험하다.

"모르면 모른다고 말하라"는 왜 충분하지 않은가

실무 프롬프트에서 가장 자주 보이는 안전 장치 중 하나가 바로 이 문장이다. "모르면 모른다고 답하라." 얼핏 보면 아주 합리적이다. 하지만 이것만으로 환각을 막으려 하면 금방 한계에 부딪힌다.

첫째, 모델은 자신이 정말로 모르는 상태와, 어렴풋이 비슷한 패턴을 아는 상태를 명확하게 구분하지 못한다. 사람도 가끔 "정확히는 기억 안 나지만 아마…"라고 말하듯, 모델도 불완전한 신호를 바탕으로 답을 이어 간다. 즉, 모델에게는 "완전히 모름"과 "어딘가에서 본 듯함" 사이의 경계가 흐릴 수 있다.

둘째, 프롬프트 안의 지시들은 서로 경쟁한다. 한편에서는 "정확해야 한다"고 말하고, 다른 한편에서는 "친절하게 답하라", "빠짐없이 설명하라", "즉시 유용한 답을 주라"고 요구할 수 있다. 이런 상황에서 모델은 종종 침묵보다 생산적인 답변처럼 보이는 출력을 택한다. 다시 말해, "모르면 모른다고 해"라는 규칙은 다른 규칙들과 충돌하면 쉽게 밀릴 수 있다.

셋째, 질문 자체가 부분적으로만 주어졌을 때 모델은 빈틈을 메우려는 경향이 있다. 사용자가 배경 정보를 생략하면, 모델은 그것을 확인 질문으로 되돌리기보다 일반적인 전제를 놓고 답할 수 있다. 이때도 환각은 "모른다"를 말하지 못해서가 아니라, 질문의 빈칸을 자연스럽게 메우려는 생성 습관 때문에 일어난다.

넷째, 운영 환경에서는 사용자가 항상 정직하고 명확하게 묻지 않는다. 부정확한 질문, 혼란스러운 표현, 오래된 문서 이름, 내부 용어의 중복 같은 요소가 들어오면 모델은 더 쉽게 추정에 의존한다. "모르면 모른다고 답하라"는 한 줄은 이런 혼선을 정리해 주지 못한다.

그래서 이 지시는 필요는 하지만 충분하지 않다. 안전벨트는 필요하지만, 브레이크와 차체가 없는 자동차는 안전하지 않은 것과 비슷하다. 좋은 프롬프트 문장은 안전 장치의 일부일 뿐, 정확성 전체를 책임지는 구조는 아니다.

지시만으로는 정확성이 생기지 않는다

정확성은 크게 두 가지에서 나온다. 하나는 답을 생성하는 규칙이고, 다른 하나는 답에 사용할 정보다. 많은 팀이 첫 번째만 다듬는다. 문체를 조정하고, 금지 표현을 정하고, 불확실성을 표시하게 하고, 추측을 금지한다. 물론 필요하다. 하지만 두 번째가 비어 있으면 첫 번째는 한계가 뚜렷하다.

비유해 보자. 요리사에게 "정확한 맛을 내라"라고 아무리 지시해도 재료가 없거나 잘못 들어오면 결과는 흔들린다. 프롬프트는 조리법에 가깝고, grounding은 재료 공급에 가깝다. 조리법만 정교해도 좋은 식사가 나오지 않는다.

여기서 중요한 관점 전환이 있다. 우리는 종종 환각을 "모델의 실수"로만 본다. 하지만 실무 설계자 입장에서 더 유용한 질문은 이것이다.

"이 답변은 무엇을 근거로 만들어졌는가?"

이 질문을 시스템 설계의 중심에 놓는 순간, 프롬프트 엔지니어링은 문장 기술에서 아키텍처 문제로 이동한다. 답의 품질은 모델의 재능만이 아니라, 어떤 정보를 언제 어떻게 공급했는지에 의해 결정된다.

grounding이란 무엇인가

grounding은 모델이 답변을 만들 때 의존해야 할 근거를 외부에서 명시적으로 제공하거나 연결하는 설계다. 쉽게 말해, 모델이 기억과 추정만으로 말하지 않게 하고, 확인 가능한 자료를 바탕으로 말하게 만드는 것이다.

이 개념은 단순해 보이지만 효과는 크다. 모델이 자신이 가진 모호한 내부 기억 대신, 지금 주어진 문서 조각, 데이터, 검색 결과, 규정 원문, 제품 사양 같은 구체적인 입력을 사용하게 되면 정확성은 훨씬 관리 가능한 문제가 된다. 완벽해지지는 않지만, 최소한 "어디서 틀렸는지"를 추적할 수 있게 된다.

grounding은 특히 다음과 같은 상황에서 필수에 가깝다.

• 최신성이 중요한 질문

• 조직 내부 문서나 비공개 지식에 대한 질문

• 숫자, 정책, 계약, 절차처럼 작은 오류도 비용이 큰 질문

• 출처 제시가 필요한 질문

• 답변 실패 시 책임 소재를 분명히 해야 하는 질문

이런 영역에서 프롬프트만 믿는 것은 위험하다. 모델이 훌륭한 문장을 쓰는 것과, 검증 가능한 사실을 말하는 것은 다른 능력이기 때문이다.

grounding이 필요한 진짜 이유

grounding의 가치는 단지 "더 정확해질 수 있다"는 데 있지 않다. 더 중요한 이유는 정확성을 운영 가능한 방식으로 바꿔 준다는 점이다.

프롬프트만으로 정확성을 관리하면 실패 원인을 분석하기 어렵다. 같은 질문에도 응답이 조금씩 흔들릴 수 있고, 왜 그런 답이 나왔는지 추적하기도 쉽지 않다. 반면 grounding이 있으면 적어도 세 가지를 확인할 수 있다. 문서가 있었는지, 문서를 제대로 찾았는지, 찾은 문서를 답변에 제대로 반영했는지다. 문제를 구조적으로 나눌 수 있다는 뜻이다.

이 차이는 실무에서 매우 크다. 예를 들어 잘못된 답이 나왔을 때, 프롬프트 중심 접근은 "지시를 더 강하게 써 보자"로 끝나기 쉽다. 하지만 grounding 중심 접근은 "애초에 근거 문서가 검색되지 않았는가?", "검색은 됐지만 관련 문단이 잘려 나갔는가?", "관련 문단은 들어갔지만 모델이 엉뚱한 부분을 우선 사용했는가?" 같은 식으로 원인을 분해한다. 개선 포인트가 훨씬 선명해진다.

정리하면 grounding은 단순한 성능 향상 기법이 아니다. 정확성을 설명 가능하게 만들고, 실패를 디버깅 가능하게 만들며, 운영 리스크를 통제 가능하게 만드는 구조다.

"모른다고 말하기"와 "모를 수밖에 없게 만들기"는 다르다

이 장의 핵심을 한 문장으로 압축하면 이렇다.

모델에게 모르면 모른다고 말하라고 지시하는 것과, 실제로 근거가 없으면 답을 내기 어렵게 시스템을 설계하는 것은 전혀 다르다.

첫 번째는 태도 규칙이다. 두 번째는 구조 규칙이다.

태도 규칙은 유용하지만 흔들릴 수 있다. 구조 규칙은 상대적으로 강하다. 예를 들어 시스템이 먼저 관련 문서를 검색하고, 검색된 문서가 없으면 "근거 부족" 상태로 분기하며, 문서가 있어도 근거 문단이 특정 임계값 이하이면 답변 대신 확인 요청을 하게 만들 수 있다. 이런 설계에서는 모델이 자신감만으로 빈칸을 채우기 어려워진다.

즉, 좋은 설계는 모델의 선의를 기대하지 않는다. 근거가 없을 때 함부로 답하기 어렵도록 경로 자체를 제한한다. 고급 프롬프트 아키텍처가 필요한 이유가 바로 여기에 있다.

환각을 줄이기 위한 정보 공급 구조

실무에서는 "어떻게 질문하느냐" 못지않게 "어떤 정보를 함께 주느냐"가 중요하다. 환각을 줄이는 구조는 대체로 다음 흐름을 가진다.

먼저 질문의 범위를 해석한다. 사용자가 무엇을 묻는지, 내부 지식이 필요한지, 최신성이 필요한지, 단순 생성 작업인지 구분해야 한다. 이 단계가 없으면 모든 질문을 같은 방식으로 처리하게 되고, 그 자체가 환각의 시작점이 된다.

그다음 필요한 근거를 찾는다. 내부 문서, 정책 저장소, 제품 DB, 검색 인덱스, 승인된 레퍼런스 같은 소스에서 관련 정보를 가져온다. 이 단계는 나중에 다룰 RAG의 핵심이기도 하다.

이후에는 가져온 정보를 그대로 길게 붙이는 것이 아니라, 정말 관련 있는 부분을 선별해야 한다. 관련 없는 문맥이 많이 섞이면 오히려 모델이 길을 잃는다. 문맥이 많다고 항상 정확해지는 것은 아니다.

마지막으로 답변을 만들 때 근거 사용 규칙을 명확히 둔다. 예를 들어 제공된 자료에 없는 내용은 추정하지 않게 하고, 근거가 약하면 불확실성을 표시하게 하며, 필요하면 출처를 함께 제시하게 한다.

이 흐름을 보면 환각 방지는 사실상 정보 처리 파이프라인 설계라는 점이 보인다. 프롬프트 문장은 이 흐름을 제어하는 한 요소일 뿐이다.

환각은 질문의 문제이기도 하다

환각을 모델 탓으로만 돌리면 설계가 단순해진다. 하지만 실제로는 입력 설계도 큰 영향을 준다. 사용자의 질문이 모호하면 모델은 해석을 해야 하고, 해석이 늘어날수록 추정도 늘어난다.

예를 들어 "휴가 규정 알려줘"라는 질문은 지나치게 넓다. 연차인지 병가인지, 어떤 조직의 규정인지, 최신 버전이 무엇인지가 빠져 있다. 이런 질문에 모델이 매끄럽게 긴 답을 하면, 그럴듯함은 올라가고 정확성은 오히려 내려갈 수 있다.

그래서 환각 제어는 답변 프롬프트만의 문제가 아니다. 질문을 정제하고, 필요한 슬롯을 채우고, 정보가 모자라면 되묻는 상호작용 설계가 함께 필요하다. 모호한 질문을 바로 답변으로 밀어 넣는 시스템은, 환각을 초대하는 시스템과 비슷하다.

실무에서 자주 보이는 오해

환각을 다루는 팀에서 특히 자주 나타나는 오해가 몇 가지 있다.

첫 번째 오해는 "더 큰 모델이면 환각이 사라질 것"이라는 생각이다. 큰 모델은 종종 더 유창하고, 더 넓은 패턴을 기억한 듯 보이며, 불확실성 표현도 더 자연스러울 수 있다. 그러나 최신 내부 문서를 모르는 문제, 근거 없이 숫자를 만들어 내는 문제, 애매한 질문을 추정으로 메우는 문제는 모델 크기만으로 해결되지 않는다.

두 번째 오해는 "프롬프트를 길게 쓰면 안전해질 것"이라는 기대다. 지시가 많아지면 제약도 많아지겠지만, 동시에 충돌도 늘어난다. 길고 복잡한 규칙은 모델이 우선순위를 혼동하게 만들 수 있다. 무엇보다 근거가 없는 상태 자체를 바꾸지는 못한다.

세 번째 오해는 "출처를 붙이면 정확할 것"이라는 믿음이다. 근거 없는 답에 형식적으로 출처를 달아도 정확성이 생기지 않는다. 출처 표시는 grounding 이후의 문제다. 먼저 실제 근거가 존재해야 하고, 그 근거가 답변에 올바르게 연결되어야 한다.

네 번째 오해는 "모르면 모른다고 한 번 말하게 했으니 충분하다"는 생각이다. 실제 운영에서는 질문 유형, 문서 품질, 검색 성능, 문맥 길이, 출력 형식, 권한 경계까지 함께 설계해야 한다. 한 줄 규칙은 출발점일 뿐 종착점이 아니다.

작은 예시로 보는 차이

같은 질문을 두 방식으로 처리해 보자.

질문은 이렇다. "사내 원격근무 정책상 해외 체류 중 근무가 가능한가?"

프롬프트만 있는 시스템은 아마 이렇게 답할 가능성이 있다. "일반적으로 회사의 원격근무 정책에 따라 해외 체류 중 근무는 보안과 세무 이슈 때문에 제한될 수 있습니다. 회사 정책을 확인하세요." 언뜻 그럴듯하다. 하지만 이 답은 해당 회사 정책을 실제로 본 적이 없고, 일반론에 기대고 있다. 사용자는 이 답을 읽고도 오해할 수 있다.

grounding이 있는 시스템은 다르게 움직인다. 먼저 최신 정책 문서를 찾고, 관련 조항을 확인한다. 문서에 "해외 체류 중 근무는 사전 승인된 경우에 한해 최대 30일까지 허용"이라고 적혀 있다면, 답은 훨씬 구체적이고 검증 가능해진다. 반대로 관련 문서가 없으면 "확인된 정책 문서에서 근거를 찾지 못했다"고 답할 수 있다. 이 경우 답이 짧아 보여도 더 안전하다.

차이는 분명하다. 첫 번째 시스템은 말이 자연스럽다. 두 번째 시스템은 말의 근거가 있다. 운영 가능한 시스템이 선택해야 하는 쪽은 두 번째다.

정확할 수밖에 없는 구조를 향해

이 책에서 반복해서 다루는 주제가 하나 있다. 좋은 시스템은 모델에게 더 열심히 하라고 부탁하는 대신, 올바른 행동이 더 쉽게 일어나도록 구조를 바꾼다. 환각 문제도 마찬가지다.

정확한 답을 원한다면 모델에게 정직하라고 훈계하는 것만으로는 부족하다. 필요한 정보를 제때 공급하고, 정보가 없으면 없는 상태를 분기하고, 추정이 위험한 영역에서는 답변 경계를 분명히 하고, 나중에 검토할 수 있도록 근거를 남겨야 한다.

이 관점은 프롬프트 엔지니어의 역할을 바꾼다. 더 멋진 문장을 쓰는 사람이 아니라, 답변이 어떤 정보 흐름을 통해 생성되는지 설계하는 사람이 되어야 한다. 프롬프트는 여전히 중요하지만, 이제 프롬프트는 단독 해법이 아니라 시스템의 한 레이어다.

다음 장으로 이어지는 질문

여기까지 오면 자연스럽게 다음 질문이 생긴다. 그렇다면 필요한 근거를 시스템에 어떻게 넣어야 할까? 문서를 통째로 넣으면 되는가, 일부만 골라야 하는가, 여러 문서가 충돌하면 어떻게 해야 하는가, 답변에는 어떤 형식으로 근거를 드러내야 하는가.

바로 그 질문이 다음 장의 주제다. 환각은 프롬프트만으로 해결되지 않는다. 그렇다면 이제 해야 할 일은 분명하다. 모델이 추측 대신 근거를 사용하도록, 근거를 찾아 넣고 선택하고 압축하는 구조를 설계해야 한다. 그 중심에 있는 방법이 RAG다.

정리

이 장의 메시지는 단순하지만 중요하다. 환각은 주로 모델의 생성 특성과 정보 부족, 애매한 입력, 과도한 완성 지향이 결합해 생긴다. "모르면 모른다고 말하라"는 지시는 필요하지만, 그 자체로는 충분하지 않다. 정확성은 지시만으로 만들어지지 않으며, 근거를 공급하는 구조가 함께 설계되어야 한다.

즉, 고급 프롬프트 설계의 출발점은 더 강한 명령이 아니다. 더 나은 정보 흐름이다. 정확한 답은 잘 쓴 문장에서만 나오지 않는다. 잘 설계된 근거 체계에서 나온다.