정확한 답을 만들기 위해 검색을 붙였다고 해서 곧바로 좋은 RAG가 되는 것은 아니다. 많은 팀이 여기서 한 번 더 착각한다. 검색기가 관련 문서를 잘 찾아오면 문제의 절반은 끝났다고 생각하는 것이다. 하지만 실제 운영에서는 그다음 단계가 더 자주 시스템 품질을 갈라놓는다. 찾아온 문서를 모델에게 어떻게 보여 주는가가 답변의 정확도, 일관성, 근거성에 직접적인 영향을 주기 때문이다.
같은 검색 결과라도 한 시스템은 정확하고 차분한 답을 내고, 다른 시스템은 문서 안에 정답이 있는데도 엉뚱한 말을 한다. 차이는 대개 검색기 자체보다 프롬프트 아키텍처에서 난다. 긴 문서를 통째로 붙여 넣었는지, 관련 문단만 골랐는지, 출처를 추적할 수 있게 정리했는지, 문서 간 충돌을 처리하는 규칙이 있는지에 따라 결과가 크게 달라진다.
이 장에서는 RAG를 "검색 결과를 붙이는 기술"이 아니라 "근거를 읽히는 구조"로 이해해 보겠다. 핵심 질문은 네 가지다. 검색 결과를 어떤 형태로 주입할 것인가, 긴 컨텍스트를 어떻게 압축할 것인가, 여러 문단 중 무엇을 근거로 선택할 것인가, 마지막으로 답변 형식과 출처 표시는 어떻게 설계할 것인가.
RAG의 병목은 검색 이후에 자주 생긴다
RAG를 처음 도입한 팀은 보통 검색 품질에 먼저 집중한다. 물론 중요하다. 문서를 못 찾으면 아무 일도 시작되지 않는다. 하지만 검색이 어느 정도 작동하기 시작하면 병목은 곧 다른 곳으로 이동한다. 모델이 가져온 문서 중 어떤 부분을 중요하게 읽는지, 길고 복잡한 문맥 속에서 핵심 규정을 놓치지 않는지, 서로 다른 문서의 내용을 섞어 버리지 않는지 같은 문제가 더 크게 보이기 시작한다.
이유는 단순하다. 검색은 후보를 가져오지만, 답은 결국 모델이 생성한다. 즉 RAG의 품질은 "찾아왔다"에서 끝나지 않고 "읽히고 반영되었다"까지 가야 한다. 그래서 고급 RAG 설계에서는 검색과 생성 사이의 연결부, 다시 말해 retrieved context를 구성하는 방식이 핵심 자리가 된다.
실무에서 특히 자주 보이는 실패는 다음과 같다.
관련 문서는 가져왔지만 너무 긴 문맥 속에 묻혀 모델이 놓친다.
관련성은 낮지만 표현이 화려한 문단이 답변에 더 강하게 반영된다.
서로 다른 문서의 규정이 섞여 하나의 자연스러운 거짓말이 된다.
문서 요약 과정에서 숫자, 조건, 예외 조항이 손실된다.
출처는 표시했지만 실제 답변 문장과 근거 문단이 정확히 연결되지 않는다.
이 다섯 가지는 모두 "검색 실패"라기보다 "컨텍스트 설계 실패"에 가깝다. 그래서 RAG 프롬프트 설계는 검색 결과를 얼마나 많이 넣느냐보다, 얼마나 읽기 쉬운 근거 패키지로 바꾸느냐의 문제다.
검색 결과를 그대로 붙이면 왜 잘 안 되는가
가장 쉬운 구현은 검색된 문서를 통째로 붙여 넣고, 그 아래에 사용자 질문을 붙이는 방식이다. 데모 단계에서는 종종 이 방법도 그럴듯하게 작동한다. 하지만 운영 단계에서는 금방 흔들린다.
첫째, 모델은 문서를 사람처럼 차분히 정독하지 않는다. 긴 문맥이 들어오면 중요 정보와 주변 정보를 모두 같은 평면 위에서 보게 된다. 사람도 회의록 30페이지 중 단 한 줄의 예외 조항을 놓치기 쉬운데, 모델 역시 비슷한 문제를 겪는다.
둘째, 관련 없는 문장이 많아지면 모델은 평균적인 답을 만들기 쉬워진다. 예를 들어 사내 보안 정책 문서와 일반 업무 규정 문서가 함께 들어가 있으면, 정작 필요한 것은 보안 예외 조항인데도 모델은 두 문서의 공통적인 톤만 가져와 모호한 답을 만들 수 있다.
셋째, 문서 구조가 불친절하면 근거 추적이 불가능해진다. 나중에 잘못된 답이 나왔을 때 무엇을 보고 그런 답이 나왔는지 확인하려면, 최소한 문서 단위와 문단 단위의 식별자가 남아 있어야 한다.
그래서 좋은 RAG는 문서를 단순히 붙이지 않는다. 검색 결과를 모델이 읽기 쉬운 단위로 정렬하고, 답변에 필요한 부분만 드러나게 재가공한다. 다시 말해 검색 결과는 원재료이고, 프롬프트에 들어가는 컨텍스트는 조리된 재료다.
컨텍스트는 문서가 아니라 근거 패키지여야 한다
RAG 프롬프트를 설계할 때 retrieved context를 하나의 패키지로 생각하면 훨씬 명확해진다. 좋은 패키지는 적어도 네 가지 요소를 가진다. 문서가 어디서 왔는지 보여 주는 식별 정보, 실제 내용이 담긴 문단 본문, 답변 시 참고할 우선순위 정보, 그리고 인용에 사용할 수 있는 짧은 참조 키다.
예를 들어 모델에게 보여 주는 컨텍스트는 다음처럼 구성할 수 있다.
[Context 1]
source_id: HR-REMOTE-2026
title: 원격근무 운영정책
section: 4.2 해외 체류 중 근무
updated_at: 2026-02-10
relevance: high
content: 해외 체류 중 근무는 부서장 및 보안팀의 사전 승인 시 최대 30일까지 허용한다. 단, 고객 데이터 접근 권한이 필요한 직무는 제외한다.
[Context 2]
source_id: SECURITY-ACCESS-2026
title: 데이터 접근 통제 기준
section: 3.1 해외 네트워크 접속
updated_at: 2026-01-05
relevance: medium
content: 고객 데이터 접근 권한이 있는 계정은 승인된 국가 외 해외 네트워크에서 접속할 수 없다.이 형식의 장점은 분명하다. 모델이 각 문단을 독립된 근거 단위로 읽을 수 있고, 나중에 답변 문장 옆에 HR-REMOTE-2026 같은 키를 붙여 근거를 연결할 수 있다. 반대로 문서 이름도 없고 경계선도 없는 긴 텍스트 덩어리는 모델에게도, 운영자에게도 불친절하다.
검색 결과 주입의 기본 원칙
retrieved context를 프롬프트에 넣을 때는 양보다 배열이 중요하다. 모델은 입력의 모든 부분을 똑같이 다루지 않기 때문에, 무엇을 어디에 두는지가 실제 행동을 바꾼다. 실무에서는 다음 원칙이 특히 유용하다.
가장 관련 높은 근거를 앞쪽에 둔다.
각 근거는 짧고 자족적인 단위로 나눈다.
문서 제목, 섹션명, 식별자 같은 메타데이터를 함께 준다.
서로 다른 문서는 명확한 구분선으로 분리한다.
사용자 질문보다 먼저 근거 사용 규칙을 제시하고, 그다음 컨텍스트를 배치한다.
여기서 마지막 원칙이 중요하다. 모델에게 문서를 넣기만 하면 자동으로 근거 기반 답변을 할 것 같지만, 실제로는 "주어진 컨텍스트에 기반해 답하라", "컨텍스트에 없는 내용은 추정하지 말라", "근거가 충돌하면 충돌 사실을 먼저 설명하라" 같은 사용 규칙이 함께 있어야 한다. 즉 RAG 프롬프트는 보통 다음 순서를 가진다.
시스템 수준의 역할과 안전 규칙
컨텍스트 사용 규칙
검색된 근거 패키지
사용자 질문
출력 형식 지시
이 순서는 단순해 보이지만 효과가 크다. 모델이 먼저 무엇을 해야 하는지 이해하고, 그다음 무엇을 읽어야 하는지 보게 만들기 때문이다.
"몇 개의 문서를 넣을 것인가"보다 "몇 개의 근거를 남길 것인가"가 중요하다
많은 팀이 top-k 값을 조정하는 데 많은 시간을 쓴다. 문서를 3개 넣을지 5개 넣을지 10개 넣을지 고민하는 것이다. 물론 필요하다. 하지만 더 중요한 질문은 따로 있다. 답변에 실제로 필요한 근거가 몇 개인가다.
실무적으로는 "문서 개수"보다 "근거 문단 개수"를 관리하는 쪽이 더 유리하다. 이유는 간단하다. 하나의 문서 안에도 불필요한 문단이 많기 때문이다. 긴 정책 문서 두 개를 통째로 넣는 것보다, 그 안에서 정말 중요한 문단 네 개만 넣는 편이 더 정확한 경우가 많다.
특히 숫자, 예외 조건, 금지 조항이 중요한 도메인에서는 문단 단위 선별이 거의 필수다. 모델은 긴 문서 전체를 이해하는 것보다, 질문과 직접 연결된 짧은 조항을 읽을 때 더 안정적으로 근거를 반영한다. 다시 말해 RAG의 단위는 "문서"보다 "답변에 필요한 최소 근거 블록"에 가까워야 한다.
컨텍스트 압축은 요약이 아니라 손실 관리다
검색 결과가 길어지면 결국 압축이 필요하다. 여기서 가장 흔한 실수는 압축을 곧바로 "예쁘게 요약하기"로 이해하는 것이다. 그러나 RAG에서 압축의 목적은 문장을 매끄럽게 만드는 것이 아니라, 정답에 필요한 정보 손실을 최소화하면서 길이를 줄이는 것이다.
이 차이는 매우 중요하다. 일반 요약은 읽기 좋은 문장을 만드는 데 초점을 둔다. 하지만 RAG 압축은 숫자, 조건, 예외, 범위, 주체, 시점을 잃지 않는 데 초점을 둬야 한다. 즉 좋은 압축은 짧되, 위험한 부분을 덜어내지 않는다.
예를 들어 다음 두 문장은 길이는 비슷해 보여도 의미가 다르다.
압축 전: "해외 체류 중 근무는 사전 승인 시 최대 30일까지 가능하며, 고객 데이터 접근 권한이 필요한 직무는 적용 대상에서 제외한다."
잘못된 압축: "해외 체류 중 근무는 승인 시 가능하다."
두 번째 문장은 보기에는 깔끔하지만, 실제 운영에는 치명적이다. 30일 제한과 적용 제외 조건이 사라졌기 때문이다. 고급 RAG 설계에서는 이런 손실이 가장 위험하다.
컨텍스트 압축의 세 가지 방식
실무에서 자주 쓰는 압축 방식은 크게 세 가지다. 각 방식은 장단점이 다르며, 질문 유형에 따라 적절한 조합이 달라진다.
첫 번째는 추출형 압축이다. 원문에서 질문과 직접 관련 있는 문장이나 문단만 잘라 내는 방식이다. 법무, 정책, 매뉴얼처럼 원문 표현이 중요한 도메인에 특히 유리하다. 의미 왜곡이 적고 출처 추적도 쉽다. 대신 문장이 다소 거칠 수 있다.
두 번째는 질문 중심 재서술 압축이다. 검색된 문단을 바탕으로 질문과 관련 있는 부분만 짧게 다시 쓰는 방식이다. 읽기 쉬운 컨텍스트를 만들 수 있지만, 재서술 과정에서 조건이 빠질 위험이 있다. 따라서 숫자와 조건 항목은 원문 구절을 함께 남겨 두는 편이 안전하다.
세 번째는 계층형 압축이다. 먼저 문서 수준 요약으로 후보를 좁히고, 그다음 선택된 섹션에서 핵심 문단을 추출하는 방식이다. 긴 문서가 많고 컨텍스트 한도가 빡빡할 때 유용하다. 다만 단계가 늘어날수록 누적 손실 가능성도 커지므로, 각 단계의 실패를 따로 평가해야 한다.
고급 실무에서는 보통 추출형 압축을 기본으로 두고, 필요한 곳에만 제한적으로 재서술 압축을 섞는다. 이유는 단순하다. RAG는 아름다운 요약문보다 증거 보존이 우선이기 때문이다.
어떤 문단을 근거로 선택할 것인가
검색 결과 중에서 무엇을 최종 컨텍스트로 남길지 정하는 일은 사실상 RAG의 중심 작업이다. 여기서 흔히 관련성만 보면 된다고 생각하지만, 실제로는 그것만으로 부족하다. 좋은 근거 문단은 질문과 비슷한 단어를 많이 포함한 문단이 아니라, 답변의 책임을 질 수 있는 문단이어야 한다.
근거 문단을 고를 때는 보통 다음 기준을 함께 본다.
질문에 직접 답하는가
숫자, 기간, 예외 조항처럼 결정적 세부사항을 포함하는가
더 상위이거나 더 공식적인 문서에 속하는가
최신 버전인가
다른 후보 문단과 충돌하는가
예를 들어 사용자가 "출장비 숙박 한도"를 물었는데, 한 문단은 작년 공지이고 다른 문단은 최신 규정 본문이라면, 둘 다 관련성은 높을 수 있다. 하지만 근거로서의 품질은 다르다. 최신 공식 문서가 우선되어야 한다. 즉 근거 선택은 의미 유사도만의 문제가 아니라 권위, 최신성, 결정성의 문제이기도 하다.
문단 선택에서 특히 중요한 '결정 문장' 찾기
질문에 대한 답을 실제로 결정하는 문장을 찾는 습관도 중요하다. 모든 문단이 같은 무게를 갖는 것은 아니다. 어떤 문장은 배경 설명이고, 어떤 문장은 실제 판단 규칙이다. RAG는 후자를 중심으로 구성해야 한다.
예를 들어 정책 문서에 다음 세 문장이 있다고 해 보자.
원격근무는 업무 효율성과 직원 만족도 향상을 위해 운영한다.
원격근무 신청은 팀 리더와 인사팀의 협의를 거친다.
해외 체류 중 근무는 사전 승인 시 최대 30일까지 허용하며, 보안 제한 직무는 제외한다.
사용자 질문이 해외 체류 중 근무 가능 여부라면, 세 번째 문장이 결정 문장이다. 첫 번째와 두 번째는 맥락상 의미가 있지만, 답변의 핵심을 좌우하지는 않는다. 좋은 컨텍스트는 주변 설명보다 결정 문장을 앞으로 끌어온다. 모델이 덜 읽어도 중요한 조항을 놓치지 않게 하려는 것이다.
문서가 충돌할 때는 하나를 고르는 것이 아니라 충돌을 드러내야 한다
실제 조직 문서는 종종 깔끔하지 않다. 부서별 안내 페이지와 공식 정책 문서의 표현이 다를 수 있고, 개정 중인 문서가 인덱스에 함께 들어올 수도 있다. 이런 상황에서 모델이 가장 자연스러운 하나를 임의로 고르게 두면 위험하다. RAG 설계에는 문서 간 충돌을 드러내는 규칙이 필요하다.
예를 들어 최신 정책은 30일이라고 하고 오래된 FAQ는 14일이라고 하면, 답변은 "두 문서의 내용이 다르다"는 사실부터 밝혀야 한다. 그리고 가능하면 최신 공식 문서를 우선 근거로 제시해야 한다. 이때 프롬프트에는 이런 규칙이 직접 적혀 있어야 한다.
If retrieved sources conflict, do not merge them into one answer.
State that the sources conflict, prioritize the latest authoritative source, and cite both.이 한 줄의 효과는 생각보다 크다. 모델이 서로 다른 문장을 평균 내어 매끄러운 거짓 답을 만드는 일을 줄여 주기 때문이다.
답변 형식은 근거 사용을 강제하는 장치다
RAG에서 출력 형식은 단지 보기 좋게 만드는 문제가 아니다. 어떤 형식을 요구하느냐에 따라 모델이 근거를 사용하는 방식 자체가 달라진다. 그래서 답변 형식은 미관이 아니라 통제 장치로 설계해야 한다.
가장 단순한 형식은 자연어 답변 뒤에 출처를 붙이는 방식이다. 이 방식은 사용자 경험이 좋고 읽기 쉽다. 하지만 모델이 실제로 어떤 문장에 어떤 근거를 사용했는지 추적하기는 어렵다.
더 강한 방식은 답변을 구조화하는 것이다. 예를 들어 다음처럼 나눌 수 있다.
answer: 사용자에게 전달할 최종 답변
evidence: 사용한 source_id 목록
confidence: high | medium | low
insufficient_context: true | false
follow_up: 추가 확인이 필요하면 질문이 구조의 장점은 명확하다. 모델이 답변과 근거를 분리해서 제출해야 하므로, 운영 시스템이 사후 검증을 하기가 쉬워진다. 특히 insufficient_context 같은 필드는 근거 부족 상황을 표준화하는 데 유용하다. "모르면 모른다고 말하라"를 추상적 태도 규칙으로 두는 대신, 출력 구조 속에 실제 필드로 넣는 셈이다.
출처 표시는 장식이 아니라 추적 경로여야 한다
사용자에게 출처를 보여 주는 이유는 신뢰를 주기 위해서이기도 하지만, 운영 관점에서는 더 실용적인 목적이 있다. 잘못된 답이 나왔을 때 어떤 근거가 사용되었는지 추적하고 수정하기 위해서다. 따라서 좋은 citation은 보기 좋은 링크 모음이 아니라 답변 문장과 근거 블록을 연결하는 주소 체계여야 한다.
실무에서는 보통 다음 두 수준 중 하나를 쓴다.
첫 번째는 문서 수준 citation이다. 예를 들어 [HR-REMOTE-2026]처럼 문서 ID만 붙이는 방식이다. 구현이 단순하고 사용자에게도 덜 부담스럽다. 다만 긴 문서에서는 어느 부분을 근거로 썼는지 애매할 수 있다.
두 번째는 문단 수준 citation이다. 예를 들어 [HR-REMOTE-2026 §4.2 p3]처럼 섹션이나 chunk ID까지 붙이는 방식이다. 추적성과 검증성은 훨씬 좋다. 특히 정책, 법무, 의료처럼 작은 차이가 중요한 영역에서는 이쪽이 더 적합하다.
중요한 것은 citation을 답변 마지막에 한 번 몰아넣는 것보다, 핵심 주장 옆에 바로 붙이는 것이다. 예를 들어 "해외 체류 중 근무는 사전 승인 시 최대 30일까지 허용됩니다 [HR-REMOTE-2026 §4.2]"처럼 연결해야 근거성이 살아난다. 출처와 주장이 멀어질수록 사용자는 보기 힘들고, 시스템도 검증하기 어려워진다.
답변 형식은 질문 유형별로 달라져야 한다
모든 질문에 같은 출력 스키마를 쓰는 것은 편하지만, 늘 효율적이지는 않다. 사실 확인 질문과 비교 질문, 절차 안내 질문은 필요한 근거 구조가 다르다.
사실 확인 질문에서는 짧은 결론과 직접 근거가 가장 중요하다. 예를 들어 "가능한가?"라는 질문에는 예외 조건과 승인 필요 여부가 함께 나와야 한다.
비교 질문에서는 각 항목별 근거를 분리해 보여 주는 편이 좋다. 예를 들어 "정규직과 계약직의 교육비 지원 규정 차이"를 묻는다면 한 문장으로 뭉개기보다 표나 항목별 구조가 더 안전하다.
절차 안내 질문에서는 단계별 근거가 중요하다. "어떤 서류를 어디에 제출하는가" 같은 질문은 순서와 책임 주체가 빠지기 쉽기 때문이다.
즉 답변 형식 설계는 결국 "이 질문에서 무엇이 틀리면 가장 위험한가"를 기준으로 정해야 한다. RAG는 정보 검색 시스템이면서 동시에 오류 제어 시스템이기도 하다.
좋은 RAG 프롬프트는 세 개의 규칙을 함께 가진다
실무에서 안정적인 RAG 프롬프트는 대체로 세 종류의 규칙을 함께 가진다. 이 셋 중 하나라도 비면, 검색 결과가 좋아도 답변이 흔들릴 수 있다.
첫째는 근거 사용 규칙이다. 제공된 컨텍스트 안에서만 답하고, 근거가 없으면 부족하다고 말하며, 충돌 시 충돌을 드러내는 규칙이다.
둘째는 선택 규칙이다. 여러 근거가 있을 때 무엇을 우선할지 정하는 규칙이다. 예를 들어 최신 공식 정책 우선, 숫자와 조건을 포함한 문단 우선, FAQ보다 본 정책 우선 같은 기준이 여기에 들어간다.
셋째는 출력 규칙이다. 답변을 어떤 형식으로 내고, 어디에 citation을 붙이며, 추가 확인이 필요할 때 어떤 문구로 멈출지 정하는 규칙이다.
이 세 규칙이 분리되어 있으면 시스템을 디버깅하기도 쉬워진다. 답변이 잘못되었을 때 "검색 실패인지, 선택 실패인지, 출력 실패인지"를 구분할 수 있기 때문이다.
프롬프트 템플릿 예시
다음은 범용적인 RAG 프롬프트 구조의 예시다. 실제 서비스에서는 도메인에 맞게 더 구체화하면 된다.
You are a grounded assistant.
Use only the provided context when answering policy or internal knowledge questions.
If the context is insufficient, explicitly say that the answer cannot be confirmed from the provided documents.
If sources conflict, state the conflict and prioritize the latest authoritative source.
Cite source_ids for each key claim.
[Retrieved Context]
{{contexts}}
[User Question]
{{question}}
[Output Format]
- answer: concise but complete answer for the user
- evidence: source_ids used for the answer
- uncertainty: explain what is missing if the context is insufficient
- follow_up: ask one clarifying question only if needed여기서 중요한 점은 영어 문장 자체가 아니라 구조다. 역할, 근거 사용 범위, 부족한 경우의 처리, 충돌 처리, citation 규칙, 출력 스키마가 각각 독립적으로 들어 있다. 이런 템플릿은 모델이 바뀌어도 비교적 잘 견디는 편이다. 이유는 화려한 문장보다 행동 규칙이 분명하기 때문이다.
컨텍스트 앞단에서 질문을 정제하면 성능이 더 오른다
RAG는 흔히 검색과 생성의 문제로만 보이지만, 그 앞단의 질문 정제 역시 큰 차이를 만든다. 사용자의 질문이 모호하면 검색기도 흔들리고, 검색 결과가 흔들리면 프롬프트 설계가 아무리 좋아도 한계가 있다.
예를 들어 "출장 규정 알려줘"라는 질문은 너무 넓다. 국내 출장인지 해외 출장인지, 교통비인지 숙박비인지, 최신 규정이 필요한지조차 모른다. 이런 경우에는 바로 답변을 생성하기보다 질문을 좁히는 편이 낫다. RAG에서 좋은 재질문은 성가신 절차가 아니라, 불필요한 컨텍스트를 줄이는 압축 장치다.
실무에서는 질문이 다음 중 어느 유형인지 먼저 구분하는 것만으로도 성능이 오른다.
단일 사실 확인 질문
비교 질문
절차 질문
정책 해석 질문
범위가 지나치게 넓은 탐색 질문
질문 유형이 정리되면 필요한 근거 블록의 구조도 달라진다. 결국 RAG 프롬프트 설계는 컨텍스트 뒤쪽만이 아니라, 질문 앞쪽까지 포함하는 설계다.
흔한 실패 패턴과 수정 방법
RAG 시스템을 운영하다 보면 비슷한 실패가 반복된다. 이때 중요한 것은 프롬프트 문장을 감으로 손보는 것이 아니라, 어떤 구조가 실패했는지 분해해서 보는 것이다.
검색 결과는 맞는데 답이 틀리다면, 우선 컨텍스트가 너무 길지 않은지 확인해야 한다. 길다면 문단 단위 추출로 바꾸고, 결정 문장을 앞쪽에 재배치하는 것이 먼저다.
답변이 모호하다면, 출력 형식이 지나치게 자유로운 경우가 많다. "간결하게 답하라"만으로는 부족하다. 핵심 결론, 조건, 예외, citation을 별도 슬롯으로 나누면 모호함이 줄어든다.
서로 다른 문서 내용이 섞인다면, 충돌 처리 규칙이 약한 경우가 많다. 문서 간 불일치를 평균 내지 말고 드러내라는 지시를 명시해야 한다.
출처는 붙지만 근거가 부정확하다면, citation 단위를 문서 수준에서 문단 수준으로 낮출 필요가 있다. 특히 검증이 중요한 시스템에서는 chunk ID를 남기는 것이 큰 도움이 된다.
근거 부족 상황에서도 답을 억지로 만들어 낸다면, insufficient_context 같은 구조 필드와 거절 규칙을 더 강하게 넣어야 한다. 근거가 없을 때 짧게 멈추는 것이, 길게 틀리는 것보다 낫다.
작은 예시로 보는 설계 차이
질문이 "사내 교육비 지원은 계약직도 받을 수 있는가?"라고 해 보자.
좋지 않은 RAG는 이렇게 동작한다. 검색 결과 상위 5개 문서를 통째로 붙여 넣고, "친절하게 설명해 줘"라고 지시한다. 그러면 모델은 교육 제도의 목적, 복지 철학, 승인 절차, 정규직 기준을 길게 설명하면서 정작 계약직 예외 조항은 놓칠 수 있다.
좋은 RAG는 다르게 동작한다. 먼저 계약직 여부를 직접 언급하는 문단, 지원 대상 범위를 정의한 문단, 예외 조항이 있는 문단만 추출한다. 그리고 답변 형식을 "결론 → 조건 → 예외 → 근거"로 강제한다. 이 경우 모델은 훨씬 덜 흔들린다. 읽어야 할 정보가 명확하고, 어떤 형태로 말해야 하는지도 분명하기 때문이다.
차이는 문학적 표현력이 아니라 정보 흐름의 설계에서 나온다. 바로 이 점 때문에 RAG 프롬프트 설계는 프롬프트 기술이면서 동시에 아키텍처 문제다.
운영 관점에서 기억해야 할 체크포인트
RAG를 실제 서비스로 운영할 때는 프롬프트 본문만 예쁘게 다듬어서는 부족하다. 최소한 다음 질문에는 답할 수 있어야 한다.
검색된 문서 중 어떤 문단이 최종 컨텍스트로 선택되었는가
압축 과정에서 숫자, 조건, 예외가 손실되지 않았는가
답변의 각 핵심 주장에 대응하는 citation이 있는가
근거 부족과 문서 충돌 상황에서 정해진 fallback이 작동하는가
잘못된 답이 나왔을 때 검색, 선택, 생성 중 어디가 원인인지 추적 가능한가
이 체크포인트는 단순한 운영 메모가 아니다. RAG의 품질을 개선 가능한 시스템으로 만들기 위한 기본 조건이다. 검색 정확도만 보는 팀은 자주 같은 문제를 반복하고, 컨텍스트 구조까지 추적하는 팀은 더 빨리 좋아진다.
정리
RAG의 성패는 검색기를 붙였느냐에 달려 있지 않다. 검색으로 가져온 정보를 모델이 어떻게 읽고, 무엇을 근거로 삼고, 어떤 형식으로 답하게 만들었는가에 달려 있다. 그래서 retrieved context는 문서 묶음이 아니라 근거 패키지여야 하며, 긴 문맥은 무작정 요약하지 말고 손실을 통제하며 압축해야 한다. 또 근거 문단은 관련성만이 아니라 최신성, 권위, 결정성을 기준으로 선택해야 하고, 답변 형식은 citation과 근거 부족 처리를 강제하는 구조여야 한다.
짧게 말하면 좋은 RAG는 검색 결과를 많이 넣는 시스템이 아니다. 모델이 틀리기 어렵게 읽히는 근거 구조를 만드는 시스템이다. 다음 장에서는 한 걸음 더 들어가, 이렇게 설계된 RAG가 실제로 얼마나 근거에 충실한지, citation이 정말 정확한지, 그리고 문서 근거가 없을 때 어떻게 평가하고 통제할지를 다룬다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.