RAG는 검색 기능이 아니라 컨텍스트 공급망이다
LLM은 많은 것을 알고 있지만, 지금 회사 내부 문서가 어떻게 바뀌었는지, 특정 고객 계약서의 최신 조항이 무엇인지, 어제 배포된 장애 대응 절차가 무엇인지는 모른다. 모델의 학습 지식은 넓지만 고정되어 있고, 기업의 지식은 좁지만 계속 바뀐다. 이 간극을 메우는 대표적인 방식이 RAG, 즉 검색 증강 생성이다.
RAG를 "문서를 찾아 프롬프트에 붙이는 기능"으로 이해하면 금방 한계에 부딪힌다. 실제 RAG는 데이터가 모델의 컨텍스트로 들어오기까지의 공급망이다. 문서를 수집하고, 정제하고, 적절히 쪼개고, 메타데이터를 보존하고, 임베딩을 만들고, 인덱스에 저장하고, 질문에 맞게 다시 찾아오고, 재정렬하고, 필요한 만큼만 압축해 모델에 전달한다. 이 중 어느 한 단계가 허술하면 마지막 답변도 흔들린다.
컨텍스트 엔지니어링 관점에서 RAG는 Select 전략의 핵심 구현이다. 거대한 지식 저장소에서 지금 질문에 필요한 일부를 고르는 기술이다. 동시에 Compress와도 연결된다. 검색 결과를 그대로 넣지 않고, 질문에 필요한 단위로 줄이고 정리해야 하기 때문이다. 좋은 RAG는 "많이 넣는 시스템"이 아니라 "맞는 것을 넣는 시스템"이다.
인덱싱 품질이 답변 품질을 결정한다
RAG의 첫 단계는 사용자가 질문하기 전에 이미 시작된다. 이를 인덱싱이라고 부른다. 문서를 읽어올 수 있는 형태로 변환하고, 검색 가능한 조각으로 나누고, 각 조각을 벡터나 키워드 인덱스에 저장하는 과정이다. 이 단계는 눈에 잘 띄지 않지만, 답변의 사실성과 환각 감소 효과를 크게 좌우한다.
가장 먼저 중요한 것은 문서 정제다. PDF에서 추출된 머리말, 꼬리말, 깨진 표, 중복 페이지가 그대로 들어가면 검색 결과도 오염된다. 모델은 검색된 조각이 깨끗한지 더러운지 자동으로 구별하지 못한다. "쓰레기가 들어가면 쓰레기가 나온다"는 원칙은 RAG에서도 그대로 적용된다.
다음은 청킹이다. 청킹은 긴 문서를 작은 조각으로 나누는 일이다. 너무 작게 자르면 의미가 끊긴다. 예를 들어 "이 조건은 예외 조항에 따른다"라는 문장만 남고, 앞의 조건 설명이 다른 조각으로 분리되면 검색은 성공해도 답변은 실패한다. 반대로 너무 크게 자르면 관련 없는 문장이 함께 들어와 정밀도가 떨어진다. 기술 문서, 법률 문서, 코드, FAQ는 서로 다른 청킹 전략이 필요하다.
메타데이터도 본문만큼 중요하다. 문서 ID, 제목, 작성일, 버전, 작성 부서, 접근 권한, 섹션 번호, 페이지 위치를 함께 보존해야 한다. 그래야 모델이 "어느 문서의 어느 부분에 근거한 답변인지" 말할 수 있다. 또한 최신 정책과 오래된 정책이 함께 검색될 때 최신성을 기준으로 필터링할 수 있다.
임베딩 모델 선택도 가볍게 볼 일이 아니다. 임베딩은 텍스트의 의미를 숫자 벡터로 바꾸는 과정이다. 이 벡터가 좋아야 의미 검색이 잘 된다. 다국어 문서인지, 코드가 많은지, 짧은 FAQ인지, 긴 보고서인지에 따라 적합한 임베딩 모델이 달라진다. 벡터 데이터베이스만 도입한다고 RAG가 좋아지는 것이 아니다. 검색될 지식의 모양에 맞는 표현 방식을 선택해야 한다.
검색은 재현율과 정밀도의 균형이다
검색 단계의 목표는 단순히 비슷한 문서를 찾는 것이 아니다. 답변에 필요한 근거를 빠뜨리지 않으면서, 불필요한 노이즈를 줄이는 것이다. 여기서 두 가지 기준이 중요하다. 재현율은 필요한 정보를 얼마나 놓치지 않고 찾았는가를 뜻한다. 정밀도는 가져온 정보 중 실제로 유용한 정보의 비율을 뜻한다.
top-k 값을 크게 잡으면 더 많은 문서를 가져오므로 재현율은 올라갈 수 있다. 하지만 관련 없는 조각도 함께 들어올 가능성이 커진다. 반대로 top-k를 너무 작게 잡으면 컨텍스트는 깔끔해지지만, 결정적인 근거를 놓칠 수 있다. 유사도 점수 임계값도 마찬가지다. 기준을 높이면 잡음은 줄지만 필요한 문서를 버릴 수 있고, 기준을 낮추면 잡음이 늘어난다.
또 하나의 문제는 중복이다. 비슷한 문단 다섯 개가 상위 결과를 차지하면, 컨텍스트 창은 낭비되고 관점은 좁아진다. MMR 같은 방식은 유사도뿐 아니라 다양성도 고려해 중복된 결과를 줄인다. 같은 답을 반복하는 조각보다 서로 다른 근거를 제공하는 조각이 더 가치 있기 때문이다.
검색 방식도 하나만 고집하면 안 된다. 벡터 기반 의미 검색은 사용자의 표현과 문서의 표현이 달라도 비슷한 의미를 찾는 데 강하다. 하지만 고유명사, 제품 코드, 숫자, 정확한 조항 번호, 에러 메시지처럼 문자 그대로 일치해야 하는 질문에는 약할 수 있다. 이때 BM25 같은 키워드 검색이 유용하다. 실무에서는 벡터 검색과 키워드 검색을 결합한 하이브리드 검색이 더 안정적이다. 의미를 찾는 능력과 정확한 문자열을 찾는 능력을 함께 쓰기 때문이다.1
검색 결과를 그대로 넣지 않는다
초기 RAG 시스템은 질문을 벡터로 바꾸고, 가까운 문서 조각을 몇 개 찾고, 그대로 프롬프트에 붙였다. 작은 데모에서는 이 방식도 그럴듯하게 보인다. 그러나 실제 업무 문서는 더 복잡하다. 검색된 조각 사이에 상충 정보가 있을 수 있고, 일부는 오래된 버전일 수 있으며, 관련 있는 듯 보이지만 질문에는 답하지 않는 단락일 수 있다.
그래서 검색 전후의 처리가 필요하다. 먼저 질의 재작성이다. 사용자의 질문은 대개 검색에 최적화되어 있지 않다. "그거 지난번 정책에서 바뀐 거 있어?"처럼 대화 맥락에 의존하거나, 너무 짧거나, 모호할 수 있다. 시스템은 이를 "2026년 기준 휴가 정책 변경 사항은 무엇인가?"처럼 검색 가능한 질문으로 바꿀 수 있어야 한다.
복잡한 질문은 분해해야 한다. "A 제품을 유럽 고객에게 판매할 때 필요한 보안 인증과 계약 예외 조건은?"이라는 질문은 제품, 지역, 보안 인증, 계약 조건이라는 여러 축을 가진다. 한 번의 검색으로 끝내기보다 하위 질문으로 나누고, 각각의 근거를 모은 뒤 합성하는 편이 더 안정적이다.
다중 쿼리 생성도 효과적이다. 하나의 질문을 여러 표현으로 바꿔 검색하면, 문서 작성 방식의 차이로 인해 놓치는 정보를 줄일 수 있다. 예를 들어 "환불 정책", "refund eligibility", "cancellation and refund terms"처럼 표현을 넓히면 검색 재현율이 올라간다.
검색 후에는 재순위화가 필요하다. 1차 검색은 넓게 후보를 가져오고, 재순위화 모델은 질문과 각 문서를 함께 보며 실제 답변에 도움이 되는 순서로 다시 정렬한다. 이 과정은 비용과 지연 시간을 늘리지만, 상위 컨텍스트의 품질을 크게 개선한다.
마지막으로, 항상 검색해야 하는 것은 아니다. 어떤 질문은 모델의 일반 지식으로 충분하고, 어떤 질문은 내부 문서가 반드시 필요하다. 관련 없는 문서를 억지로 검색해 넣으면 오히려 답변이 나빠질 수 있다. Context Awareness Gate처럼 질문이 외부 컨텍스트를 필요로 하는지 먼저 판단하는 구조는 불필요한 검색과 노이즈 주입을 줄이는 데 도움이 된다.2
컨텍스트 압축은 손실을 관리하는 기술이다
검색된 문서를 모두 넣을 수 있다고 해서 모두 넣어야 하는 것은 아니다. 긴 컨텍스트 창이 있어도 모델이 모든 위치의 정보를 똑같이 잘 쓰는 것은 아니다. 관련 없는 정보가 많아지면 중요한 근거가 묻히고, 서로 충돌하는 문장이 모델의 판단을 흐린다.
컨텍스트 압축은 검색 결과에서 질문에 필요한 부분만 남기는 과정이다. 단락 전체를 넣는 대신 관련 문장만 추출할 수 있다. 긴 문서를 요약하되, 숫자·조건·예외·날짜 같은 사실은 보존해야 한다. 요약은 토큰을 줄이지만, 잘못하면 근거를 변형한다. 따라서 압축된 컨텍스트에는 원문 위치를 함께 남겨야 한다. 모델이 요약만 보고 답하더라도, 최종 인용은 원문으로 연결되어야 한다.
문맥 보존도 중요하다. 청크만 보면 의미가 불완전한 경우가 많다. "위 표의 기준에 따른다"라는 문장에는 표 제목과 주변 설명이 필요하다. 최근에는 각 청크 앞에 그 청크가 원문에서 어떤 역할을 하는지 짧은 설명을 붙여 검색 품질을 높이는 방식도 사용된다. 이를 contextual retrieval이라고 부르며, 청크가 원래 문서 안에서 어떤 의미를 갖는지 보존하려는 접근이다.3
GraphRAG는 관계를 컨텍스트로 만든다
전통적인 RAG는 텍스트 조각을 찾는다. 질문과 의미가 가까운 단락을 가져와 모델에 넣는다. 이 방식은 특정 문서에 답이 직접 적혀 있는 경우에 강하다. 하지만 복잡한 다단계 질문에는 약하다. 예를 들어 "이 시스템 변경이 어떤 팀의 어떤 운영 절차에 영향을 주는가?"라는 질문은 단일 문단보다 엔티티와 관계를 따라가야 답할 수 있다.
GraphRAG는 이 문제를 다르게 본다. 문서를 단락의 묶음이 아니라 엔티티와 관계의 네트워크로 바꾼다. 사람, 조직, 제품, 정책, 시스템, 날짜 같은 엔티티를 추출하고, "소유한다", "의존한다", "대체한다", "적용된다" 같은 관계를 연결한다. 그러면 검색 결과는 단순한 텍스트 조각이 아니라 관련 엔티티, 관계, 경로, 커뮤니티, 원문 출처를 포함한 구조화된 컨텍스트가 된다.
GraphRAG의 장점은 관계 추론이 필요한 질문에서 드러난다. 벡터 검색은 "비슷한 문장"을 찾지만, 그래프 검색은 "연결된 사실"을 따라간다. 특정 고객과 연결된 계약, 그 계약에 연결된 제품, 제품에 연결된 보안 인증, 인증에 연결된 만료일을 순서대로 찾을 수 있다. 또한 전체 말뭉치 수준의 요약에도 유용하다. 그래프의 커뮤니티를 분석하면 문서 전체에 흩어진 주제 묶음을 파악하고, 큰 흐름의 요약을 만들 수 있다.4
다만 GraphRAG는 공짜가 아니다. 지식 그래프를 만들려면 엔티티와 관계를 추출해야 하고, 동의어를 정리해야 하며, 잘못 연결된 엣지를 검증해야 한다. 그래프 탐색은 벡터 검색보다 느릴 수 있고, 운영 비용도 커질 수 있다. 최근 연구들은 그래프 구축 비용을 낮추고 벡터 검색과 그래프 탐색을 결합하는 하이브리드 방식을 제안한다. 기업 환경에서는 순수 GraphRAG보다 벡터 검색, 키워드 검색, 그래프 검색을 질문 유형에 따라 조합하는 방식이 현실적이다.5
근거 기반 답변을 위한 컨텍스트 계약
RAG의 목적은 모델이 "그럴듯한 답"을 하게 만드는 것이 아니라 "근거 있는 답"을 하게 만드는 것이다. 그러려면 검색 결과를 컨텍스트에 넣는 방식에도 계약이 필요하다.
각 컨텍스트 조각에는 최소한 다음 정보가 있어야 한다.
문서 ID와 제목
작성일, 수정일, 버전
작성자 또는 소유 부서
출처의 권위 수준
접근 권한
섹션, 페이지, 문단, URL 같은 인용 위치
원문과 요약문의 구분
이 정보가 없으면 모델은 출처를 표시할 수 없고, 사용자는 답변을 검증할 수 없다. 특히 기업 시스템에서는 권한이 중요하다. 사용자가 볼 수 없는 문서가 검색되어 모델 컨텍스트에 들어가면, 답변을 통해 정보가 유출될 수 있다. 검색은 생성보다 앞단에 있는 보안 경계다.
모델 지시문도 명확해야 한다. "제공된 근거 안에서만 답하라", "근거가 부족하면 모른다고 말하라", "상충하는 근거가 있으면 최신 문서와 권위 있는 문서를 우선하되 충돌 사실을 밝혀라", "핵심 문장마다 출처를 표시하라" 같은 제약이 필요하다. 이러한 지시문은 모델을 답변 생성기가 아니라 근거 합성기로 만든다.
RAG 평가는 답변만 보면 안 된다
RAG 시스템이 틀린 답을 했을 때 원인은 여러 가지다. 검색이 필요한 문서를 못 찾았을 수 있다. 찾았지만 순위가 너무 낮아 모델이 보지 못했을 수 있다. 컨텍스트에는 있었지만 모델이 무시했을 수 있다. 또는 모델이 근거에 없는 내용을 덧붙였을 수 있다. 최종 답변 점수만 보면 이 차이를 알 수 없다.
따라서 평가는 단계별로 나누어야 한다. 검색 단계에서는 재현율과 정밀도를 본다. 필요한 문서를 찾았는가, 가져온 문서가 실제로 관련 있는가, 관련 문서가 상위에 배치되었는가를 측정한다. 생성 단계에서는 faithfulness 또는 groundedness를 본다. 답변의 각 주장들이 제공된 컨텍스트에서 뒷받침되는지 확인하는 지표다. 답변 관련성도 따로 봐야 한다. 근거에는 충실하지만 사용자의 질문에 직접 답하지 않는 경우가 있기 때문이다.6
인용 정확도도 별도 지표로 관리해야 한다. 답변 내용은 맞지만 출처가 엉뚱하면 사용자는 검증할 수 없다. 반대로 출처는 맞지만 문장이 출처의 의미를 왜곡할 수도 있다. 운영 환경에서는 지연 시간과 비용도 함께 봐야 한다. 재순위화, 다중 검색, GraphRAG 탐색은 품질을 높일 수 있지만 응답 시간을 늘린다. 좋은 시스템은 품질, 비용, 지연 시간의 균형을 명시적으로 선택한다.
RAG 평가는 회귀 테스트처럼 운영되어야 한다. 청킹 전략을 바꾸거나 임베딩 모델을 교체하거나 top-k 값을 조정할 때마다 같은 평가 세트로 비교해야 한다. "느낌상 좋아졌다"는 프로덕션 기준이 될 수 없다.
검색은 모델이 현실을 보는 창이다
RAG와 GraphRAG는 컨텍스트 엔지니어링의 전부가 아니다. 하지만 현실의 지식을 모델에 연결하는 가장 중요한 통로다. 검색 품질이 낮으면 좋은 모델도 헛된 답을 한다. 검색 품질이 높아도 컨텍스트 조립이 나쁘면 답변은 흐려진다. 결국 중요한 것은 검색, 필터링, 압축, 근거 제시, 평가가 하나의 공급망으로 작동하는가이다.
이 장의 핵심은 단순하다. 검색은 문서를 넣는 기능이 아니다. 모델이 현실을 볼 수 있게 하는 컨텍스트 공급망이다. 이 공급망을 잘 설계할수록 모델은 덜 상상하고, 더 확인하며, 더 신뢰할 수 있는 답을 만든다.
참고
1Master RAG Architecture with Context Engineering: The Definitive Guide
2Context Awareness Gate For Retrieval Augmented Generation
3Understanding Context and Contextual Retrieval in RAG
4Architecture Overview - GraphRAG
5Towards Practical GraphRAG: Efficient Knowledge Graph Construction and Hybrid Retrieval at Scale
6How to Evaluate RAG Systems: Metrics, Methods, and What to Measure First
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.