RAG는 AI 모델에 문서를 영구적으로 암기시키는 기능이 아니라, 질문에 맞는 근거를 찾아 답변할 때 함께 제공하는 설계 방식입니다. 따라서 챗봇의 답이 틀릴 때는 모델을 바꾸기 전에 어떤 문서를 검색했고, 그 문서에서 어떤 조건을 놓쳤는지부터 살펴봐야 합니다.
사내 매뉴얼, 제품 도움말, 기술 문서로 질문에 답하는 서비스를 만들고 싶다면 이 차이가 중요합니다. 이 글에서는 검색 증강 생성의 구조를 설명한 뒤, 문서 분할·검색·권한·평가를 어떻게 나누어 점검할지 살펴봅니다. 특정 유료 플랫폼을 도입해야만 적용할 수 있는 원칙은 아닙니다.
RAG가 해결하는 문제: 모델의 기억과 외부 문서는 다릅니다
언어 모델은 학습 과정에서 얻은 패턴을 바탕으로 문장을 생성합니다. 하지만 학습 이후에 바뀐 제품 설명이나 공개되지 않은 팀의 매뉴얼까지 저절로 알 수는 없습니다. RAG는 이 간격을 메우기 위해 외부 자료에서 질문과 관련된 내용을 찾아 입력 문맥에 넣습니다.
2020년 RAG 원 논문은 모델 파라미터에 저장된 지식과 외부 검색 저장소를 결합하는 구조를 제안했습니다. 오늘날 실무에서 쓰는 RAG라는 말은 이보다 넓은 검색·생성 파이프라인을 가리키기도 합니다. 논문의 특정 구현과 모든 현대 RAG 시스템이 동일하다는 뜻은 아닙니다.
모델·서비스·개발 도구의 구분이 아직 헷갈린다면 먼저 ChatGPT·GPT·OpenAI 차이를 읽으면 좋습니다. RAG는 이 구분 위에 ‘답변에 사용할 자료를 어디서 가져올 것인가’라는 층을 더합니다.
문서 준비와 질문 처리를 두 단계로 나누어 봅니다
일반적인 문서형 RAG는 자료를 미리 준비하는 과정과 실제 질문에 응답하는 과정으로 나눌 수 있습니다. 파일을 업로드했다는 사실만으로 두 과정이 모두 제대로 동작한다고 판단하면 안 됩니다.
| 단계 | 하는 일 | 먼저 확인할 것 |
|---|---|---|
| 문서 준비 | 텍스트를 추출하고, 검색할 단위로 나누고, 색인을 만든다 | 표·제목·조건이 누락되지 않았는가 |
| 검색 | 질문과 관련되고 접근 가능한 문서 조각을 찾는다 | 정답의 근거가 후보 안에 있는가 |
| 문맥 구성 | 중복을 줄이고 출처·버전과 함께 모델에 전달한다 | 핵심 근거가 입력 한도 안에 남는가 |
| 답변 생성 | 근거를 바탕으로 질문에 답하고 불확실성을 표시한다 | 문서에 없는 내용을 덧붙이지 않았는가 |
Microsoft의 RAG 설계 설명도 검색 의도, 입력 길이, 응답 속도, 접근 권한을 별개의 문제로 다룹니다. 문서를 모두 붙여 넣는 방법은 작은 실험에서는 가능하지만, 자료가 늘어날수록 필요한 부분을 고르는 설계가 중요해집니다.
문서 조각을 작게 만들면 항상 유리할까요?
문서 조각인 청크(chunk)는 검색의 기본 단위입니다. 너무 작으면 단서는 잘 맞아도 앞뒤 조건을 잃을 수 있고, 너무 크면 관련 없는 설명이 함께 들어옵니다. 문장 수나 토큰 수 하나를 모든 자료의 정답으로 정하기 어렵습니다.
예를 들어 제목 아래에 ‘관리자만 내보내기 가능’이라는 조건이 있고, 다음 문단에 내보내기 버튼 사용법이 있다고 해봅시다. 버튼 설명만 별도 청크가 되면 검색 결과는 사용법을 잘 찾으면서도 권한 조건은 놓칠 수 있습니다. 표의 행만 떼고 열 제목을 버리는 경우에도 의미가 바뀝니다.
첫 실험에서는 제목과 그 아래 설명을 함께 유지하고, 긴 섹션만 추가로 나누는 방식을 고려할 수 있습니다. 조각에 문서 제목·절 제목·원문 위치·버전을 붙이면 검색 결과를 사람이 검토하기도 쉽습니다. 고정 길이 분할과 일부 겹치기, 문서 구조 기반 분할의 차이는 Microsoft의 청킹 설계 가이드에서 확인할 수 있습니다.
벡터 검색과 키워드 검색은 잘하는 일이 다릅니다
임베딩은 텍스트를 수치 벡터로 표현하는 방법입니다. 벡터 검색은 질문과 표현이 달라도 의미가 가까운 자료를 찾는 데 활용할 수 있습니다. 다만 유사도 점수가 높다고 사실이 맞거나, 그 자료가 최신이라는 뜻은 아닙니다.
‘자료를 밖으로 저장하고 싶다’라는 질문은 ‘보고서 내보내기’ 문서와 연결할 필요가 있습니다. 반면 정확한 오류 코드, 제품 번호, 함수 이름은 같은 문자열을 찾는 것이 중요할 수 있습니다. 이 때문에 두 검색 결과를 결합하는 하이브리드 검색을 비교 대상으로 두는 것입니다. Azure AI Search의 하이브리드 검색 문서는 의미 유사성과 정확한 용어 일치가 서로 보완되는 사례를 설명합니다.
처음부터 검색 방식을 많이 붙이기보다 같은 질문 묶음으로 키워드 검색과 하이브리드 검색의 결과를 비교해보세요. 재정렬(reranking)을 추가한다면 ‘후보에는 있었지만 순위가 낮았던 근거’를 실제로 끌어올리는지 확인해야 합니다. 후보에 아예 없는 문서를 재정렬만으로 되살릴 수는 없습니다.
답이 틀렸을 때는 검색 실패와 생성 실패를 구분합니다
다음은 설명을 위해 만든 가상의 문서와 질문입니다. 실제 서비스의 정책이나 성능 측정 결과가 아닙니다.
- 현재 도움말: “팀 보고서는 관리자와 편집자가 CSV로 내보낼 수 있다.”
- 이전 도움말: “팀 보고서는 관리자만 CSV로 내보낼 수 있다.”
- 질문: “편집자도 팀 보고서를 내려받을 수 있나요?”
현재 문서를 찾지 못했다면 자료 수집·색인·검색을 확인해야 합니다. 이전 문서만 찾았다면 버전 관리가 문제입니다. 현재 문서를 전달했는데도 ‘관리자만 가능’이라고 답했다면 생성 단계나 문맥 구성에서 오류가 난 것입니다. 세 경우를 모두 ‘AI가 똑똑하지 않다’로 묶으면 개선할 위치를 놓칩니다.
| 관찰한 증상 | 확인할 범위 | 첫 조치 |
|---|---|---|
| 정답 문서가 후보에 없음 | 수집 누락·분할·검색어·필터 | 문서가 색인에 있는지부터 확인 |
| 정답은 후보에 있으나 입력에서 빠짐 | 순위·중복·문맥 길이 제한 | 모델에 실제 전달된 조각 확인 |
| 폐기된 설명으로 답함 | 버전·효력 시점·삭제 동기화 | 현재 자료를 선택하는 규칙 점검 |
| 근거보다 넓게 단정함 | 답변 생성·출처 연결 | 주장과 근거 문장을 대조 |
| 볼 수 없는 자료를 설명함 | 권한 필터·캐시 공유 범위 | 노출을 멈추고 접근 경계 점검 |
권한과 문서 갱신은 프롬프트 밖에서도 처리해야 합니다
사용자가 읽을 권한이 없는 문서를 모델에 전달한 뒤 ‘이 내용은 말하지 마’라고 지시하는 것만으로는 충분하지 않습니다. 접근 가능한 자료만 검색·전달하도록 애플리케이션과 검색 계층에서 제한해야 합니다. 검색 결과뿐 아니라 답변 캐시가 다른 권한의 사용자 사이에서 공유되지 않는지도 확인해야 합니다.
문서 수정은 새 조각을 추가하는 일로 끝나지 않습니다. 폐기한 버전이 계속 검색되거나 삭제한 문서가 색인에 남아 있으면 답이 다시 오래된 내용으로 돌아갑니다. 문서 식별자, 버전, 수정일, 접근 범위를 함께 관리하고, 원문 삭제·권한 변경이 검색 결과에도 반영되는지 검증할 필요가 있습니다.
OWASP가 설명하는 간접 프롬프트 주입처럼, 검색된 문서에 모델의 행동을 바꾸려는 문장이 섞일 수도 있습니다. 외부 문서는 답변의 자료로 다루고, 실행 권한을 부여하는 명령으로 취급하지 않는 설계가 필요합니다. 특히 답변을 넘어 파일 수정이나 외부 전송까지 하는 서비스라면 검색과 도구 실행의 권한을 따로 검토해야 합니다.
‘답변이 그럴듯하다’ 대신 무엇을 측정할까요?
검색과 답변을 따로 평가하면 개선 효과를 더 정확히 볼 수 있습니다. Microsoft의 RAG 평가 문서도 검색 결과의 적합성과 최종 답변의 근거 일치·질문 관련성·완전성을 구분합니다.
작은 시작점으로는 예상 질문 20개에 정답 근거 문서를 붙이는 방법을 제안합니다. 이 숫자는 표준이나 합격 기준이 아니라 첫 점검의 작업량 예시입니다. 답이 있는 질문뿐 아니라 자료에 답이 없는 질문, 버전을 구분해야 하는 질문, 접근 권한이 없는 질문도 넣어야 합니다.
| 평가 항목 | 이 글에서 제안하는 확인 방법 |
|---|---|
| 검색 성공 여부 | 상위 k개 결과에 사람이 지정한 근거가 포함됐는지 기록 |
| 근거 일치 | 답변의 핵심 주장이 전달된 문서로 뒷받침되는지 확인 |
| 완전성 | 답에 필요한 조건·예외를 빠뜨렸는지 확인 |
| 답변 보류 | 근거가 없을 때 추측하지 않고 부족한 정보를 알리는지 확인 |
| 운영 부담 | 질문당 처리 시간·토큰·검색 호출 수를 같은 조건으로 비교 |
예를 들어 답이 있는 20개 질문 중 16개에서 상위 5개 결과에 근거가 하나 이상 포함됐다면, 여기서 정의한 ‘질문별 근거 포함률’은 16/20, 즉 80%입니다. 이것은 가상 계산이며 최종 답변 정확도 80%라는 뜻이 아닙니다. 여러 근거를 모두 찾아야 하는 질문이라면 일부만 찾은 경우도 따로 표시해야 합니다.
같은 질문을 계속 보며 설정을 조정하면 그 질문에만 잘 맞출 수 있습니다. 개발 중 비교할 질문과 마지막에 처음 확인할 질문을 나누고, 변경 전후에 모델·문서 버전·평가 기준을 가능한 한 고정하세요. 자동 평가 점수도 사람의 근거 대조를 완전히 대신하지는 못합니다.
처음 만드는 서비스라면 작은 범위에서 실패를 보이게 만듭니다
첫 버전의 목표는 모든 문서를 한꺼번에 연결하는 것보다 한 종류의 자료에서 실패 원인을 구분할 수 있는 상태를 만드는 것입니다. 공개 도움말처럼 권한이 단순한 자료부터 시작하고, 검색된 문서 제목·버전·근거 위치를 답변과 함께 확인할 수 있게 구성해보세요.
- 답변할 범위를 한 주제로 정하고 현재 자료만 모읍니다.
- 대표 질문과 기대 근거를 먼저 적습니다.
- 생성 모델 없이 검색 결과부터 검토합니다.
- 검색이 맞으면 근거를 전달하고 출처를 붙여 답하게 합니다.
- 답이 없는 질문과 문서 갱신 사례까지 확인합니다.
개념을 다시 확인하거나 주변 기술로 이어서 읽고 싶다면 ORBiS Tree의 RAG 문서와 Embedding 문서를 참고할 수 있습니다. 이 글의 평가표와 가상 사례는 개념을 실제 설계 판단에 적용하기 위해 별도로 구성한 예시입니다.
출처 확인: 2026년 9월 28일. 코딩인파이와 ORBiS Tree는 같은 운영자가 운영합니다.