RAG 완벽 정리｜생성형 AI가 문서를 검색해 답하는 방식·파인튜닝 차이·도입 체크리스트

NIST·NeurIPS·ACL·Microsoft Learn·AWS 공식 자료 최종 확인: 2026년 8월 5일

먼저 확인할 결론

RAG는 생성형 AI가 가진 지식을 새로 학습시키는 기능이 아니라, 질문할 때 별도의 검색 시스템에서 근거를 찾아 모델의 입력 문맥으로 넣는 설계 방식입니다. 문서 수집·정제, 청킹, 메타데이터, 임베딩, 인덱스, 권한 필터, 검색, 재정렬, 프롬프트, 답변 생성, 인용과 평가가 연결돼야 하나의 RAG 시스템이 됩니다. 벡터 데이터베이스 하나를 설치했다고 완성되는 구조가 아닙니다.

좋은 RAG는 환각 가능성을 줄이고 최신 사내 문서를 근거로 답하게 만들 수 있습니다. 그러나 원문이 틀렸거나 오래됐고, 관련 조각을 검색하지 못했거나, 권한 없는 자료가 섞였거나, 모델이 근거를 잘못 해석하면 출처가 붙은 오답도 나옵니다. 따라서 도입 여부는 데모 화면의 자연스러운 문장보다 검색 재현율, 근거 충실성, 답변 완전성, 인용 정확성, 거절 성능, 권한 누출과 최신성 지연을 분리해 평가한 뒤 결정해야 합니다.

색인 전원문과 권한 정리문서 소유자·버전·시행일·공개 범위를 확정합니다.

검색 단계후보를 넓게 찾기키워드와 벡터 검색을 조합하고 권한을 먼저 거릅니다.

생성 단계근거 안에서 답하기부족하거나 충돌하는 자료는 추측하지 않게 합니다.

운영 단계검색과 답변 따로 평가오답이 어느 단계에서 생겼는지 추적합니다.

RAG는 검색 결과를 문맥으로 공급하는 전체 시스템입니다

NIST는 RAG를 생성형 AI 모델과 별도의 정보 검색 시스템 또는 지식베이스를 짝지어, 질문과 관련된 정보를 찾아 모델의 문맥으로 제공하는 시스템으로 설명합니다. 2020년 NeurIPS에 발표된 초기 RAG 연구도 모델 매개변수에 저장된 지식과 외부의 비매개변수 메모리를 결합했습니다. 핵심은 “AI가 문서를 외웠다”가 아니라 질문 시점에 외부 근거를 꺼내 모델이 참고하게 한다는 데 있습니다.

이 구분은 운영에서 중요합니다. 인사규정이 개정됐을 때 파인튜닝한 모델의 가중치를 다시 만드는 대신, 승인된 최신 규정을 색인에 반영하면 다음 검색부터 새 근거를 공급할 수 있습니다. 다만 원문 변경이 실제 색인에 반영되기까지의 지연, 삭제 문서가 검색에서 빠지는 시간, 과거 버전과 현행 버전을 가르는 규칙은 별도로 설계해야 합니다. “원본 폴더에 최신 파일을 올렸다”는 사실과 “RAG가 최신 조각을 검색한다”는 사실은 같지 않습니다.

색인 흐름

원문 승인 → 파싱·OCR → 청킹 → 메타데이터 → 임베딩 → 검색 인덱스

질의 흐름

질문 분석 → 사용자 권한 필터 → 검색 → 재정렬 → 문맥 구성 → 생성·인용

검증 흐름

검색 평가 → 답변 평가 → 인용 검증 → 보안·최신성 점검 → 개선

세 흐름 중 하나라도 빠지면 오류 원인을 찾기 어렵습니다. 예를 들어 답이 틀렸을 때 모델 프롬프트만 고치기 전에 정답 문서가 색인됐는지, 권한 필터 뒤에도 남았는지, 상위 결과에 들어왔는지, 재정렬에서 밀리지 않았는지부터 봐야 합니다. 검색이 정답 근거를 전달하지 못했다면 생성 모델을 바꿔도 안정적으로 해결되지 않습니다.

색인 단계는 문서를 잘게 자르는 작업보다 원문 관리가 먼저입니다

첫 단계는 연결 가능한 파일을 전부 모으는 일이 아닙니다. 어떤 자료가 공식 원문인지, 누가 소유하고 승인하는지, 어느 날짜부터 효력이 있는지, 누가 볼 수 있는지를 정해야 합니다. 초안과 승인본, 현행판과 폐기판, 본사 공통 규정과 부서별 예외가 같은 폴더에 있다면 임베딩 품질이 좋아도 상충하는 근거가 함께 검색됩니다. 최소한 원문 URL 또는 저장 위치, 문서 ID, 제목, 소유 부서, 버전, 발행일·시행일, 만료일, 보안 등급, 접근 그룹, 언어와 색인 시각을 메타데이터로 남기는 편이 좋습니다.

1. 승인된 출처를 선별합니다. 공식 규정·매뉴얼·계약서·FAQ의 소유자와 원본 위치를 정하고, 초안·중복본·폐기본은 구분합니다.
2. 구조를 보존하며 파싱합니다. PDF의 표·각주·머리글, 스캔 문서의 OCR 오류, 슬라이드의 읽기 순서가 본문 의미를 바꾸지 않았는지 표본 검수합니다.
3. 문서 유형에 맞게 청킹합니다. 제목과 본문, 원칙과 예외, 표의 열 이름과 값이 떨어지지 않게 자르고 필요한 만큼만 겹침을 둡니다.
4. 검색용 메타데이터를 붙입니다. 버전·시행일·제품·지역·부서·권한·원문 링크를 필터와 인용에 쓸 수 있는 필드로 저장합니다.
5. 같은 모델로 임베딩합니다. 문서 조각과 질문을 수치 벡터로 바꿔 의미상 가까운 후보를 찾게 하며, 모델 교체 시 재색인 범위를 계획합니다.
6. 변경·삭제를 동기화합니다. 추가뿐 아니라 수정본 교체, 폐기본 제거, 권한 회수도 색인에 전파하고 실패한 작업을 알림으로 남깁니다.

청킹에는 모든 문서에 통하는 정답 크기가 없습니다. 조각이 지나치게 크면 질문과 무관한 내용까지 문맥에 들어가 비용과 혼선을 늘리고, 너무 작으면 조건·예외·표 머리글이 분리돼 답의 전제가 사라집니다. 고정 길이와 겹침은 시작점일 수 있지만, 규정은 조·항·호, 매뉴얼은 작업 단계, FAQ는 질문과 답, 표는 열 머리글과 행의 관계를 보존하는 식으로 구조 기반 분할을 함께 시험해야 합니다.

너무 큰 조각의 신호

• 검색 결과에 질문과 무관한 문단이 많음
• 모델이 여러 규칙을 섞어 답함
• 한 문서가 문맥 대부분을 차지함
• 입력 토큰·지연·비용이 빠르게 증가함

너무 작은 조각의 신호

• 대명사와 표 값의 대상이 사라짐
• 예외 조항이 원칙과 따로 검색됨
• 출처를 열어도 문맥을 찾기 어려움
• 여러 조각을 합쳐야만 한 답이 완성됨

임베딩은 문장과 질문의 의미를 비교하기 위한 수학적 표현입니다. 유사한 표현을 찾는 데 유용하지만, 벡터가 가깝다는 사실은 문서가 최신이거나 공식이고, 사용자가 볼 권한이 있으며, 질문에 대한 정답이라는 보장이 아닙니다. 유사도 점수를 사실 확률이나 답변 신뢰도로 표시하면 안 됩니다. 정확한 상품 코드·조항 번호·날짜·약어는 의미 검색보다 키워드 검색이 더 잘 잡을 수 있으므로 실제 질문으로 조합을 비교해야 합니다.

질의 단계는 권한 필터부터 후보 검색과 재정렬까지 나눠 봅니다

사용자가 질문하면 먼저 언어, 제품명, 날짜, 부서, 문서 유형과 같은 조건을 추출할 수 있습니다. 이어서 사용자의 신원이 검증됐다는 전제 아래 검색 가능한 테넌트·그룹·문서 등급을 정하고, 그 범위 안에서만 후보를 찾습니다. 권한 없는 문서를 검색한 뒤 마지막 화면에서 가리는 방식은 이미 모델 문맥에 민감정보가 들어갈 수 있어 안전하지 않습니다. 문서 단위 권한이 다르면 검색 시점의 필터 또는 권한 인식 인덱스로 막아야 하며, 한 문서 안에서도 행·구역별 권한이 다르면 더 세밀한 분리가 필요합니다.

단계	하는 일	잘 맞는 질문	대표적인 실패
키워드 검색	정확한 단어·코드·번호와 일치하는 후보를 찾음	PRD-4821, 제17조, 오류 E104처럼 표기가 중요한 질문	동의어와 자연어 표현 변화를 놓칠 수 있음
벡터 검색	질문과 의미상 가까운 조각을 찾음	같은 뜻을 다른 말로 묻는 설명형 질문	비슷한 주제지만 답은 아닌 조각을 상위에 둘 수 있음
하이브리드 검색	키워드와 벡터 후보를 합쳐 재현율을 높임	전문용어와 일상어가 섞인 사내 검색	가중치와 합산 방식이 데이터에 맞지 않으면 잡음이 늘어남
재정렬	넓게 찾은 후보를 질문에 답하는 정도로 다시 순위화	비슷한 문서가 많아 상위 후보의 질을 높여야 하는 경우	추가 지연이 생기며 관련성을 권위·정확성으로 오해할 수 있음
문맥 구성	중복을 없애고 제목·버전·주변 문단과 함께 모델에 전달	여러 조항과 예외를 함께 봐야 하는 질문	토큰 한도로 중요한 근거가 잘리거나 충돌 순서를 잘못 정함

Microsoft의 RAG 검색 설계 안내도 벡터 유사도는 일반적인 의미 관련성을 보지만 특정 조각이 질문에 실제로 답하는지는 보장하지 않는다고 설명합니다. 재정렬은 처음 검색한 후보를 질문 관점에서 더 깊게 비교해 순서를 개선하는 단계입니다. 그러나 재정렬 점수 역시 문서의 법적 효력, 작성자 권위, 최신성 또는 진실 확률이 아닙니다. 이런 조건은 메타데이터 필터와 업무 규칙으로 별도 적용해야 합니다.

질문 재작성이나 하위 질문 분해는 “우리 회사 휴가 어떻게 돼?” 같은 모호한 질문의 검색 범위를 개선할 수 있습니다. 반면 원래 의도를 바꾸거나 중요한 한정어를 빼면 다른 문서를 찾습니다. 운영 로그에는 원 질문, 재작성된 질문, 적용한 필터, 검색 후보, 재정렬 결과와 최종 문맥을 연결해 남겨야 원인을 재현할 수 있습니다. 개인정보가 포함될 수 있는 질문 로그는 수집 최소화·마스킹·보존기간·열람 권한을 별도로 정합니다.

프롬프트와 인용은 근거 부족을 숨기지 않게 설계합니다

검색 결과를 모델에 전달할 때에는 원 질문과 검색 문서를 명확히 구분하고, 문서 안의 문장을 시스템 명령으로 취급하지 않도록 경계를 둡니다. 프롬프트에는 허용된 근거만 사용하고, 근거가 부족하면 부족하다고 말하며, 상충하는 문서가 있으면 버전·시행일과 충돌 사실을 표시하고, 계산이나 해석은 원문 사실과 구분하라는 규칙을 넣을 수 있습니다. 다만 프롬프트 한 줄만으로 보안과 정확성이 보장되지는 않으므로 검색·권한·출력 검증과 함께 사용해야 합니다.

• 근거 범위: 승인된 검색 문맥 안에서 답하고 일반 지식으로 빈칸을 메우지 않습니다.
• 부족한 정보: 직군·계약 유형·적용일처럼 결론에 필요한 조건을 사용자에게 다시 묻습니다.
• 충돌 처리: 현행 여부를 판단할 메타데이터가 없으면 임의로 하나를 고르지 않고 충돌을 알립니다.
• 문장별 인용: 핵심 주장 가까이에 원문 제목·조항·링크를 연결해 사용자가 확인할 수 있게 합니다.
• 계산과 추론 표시: 원문에 직접 적힌 내용과 시스템이 계산·요약한 결론을 구분합니다.
• 고위험 답변: 법률·의료·인사 처분·금융 승인·보안 조치는 담당자의 최종 확인 단계로 보냅니다.

인용이 보인다고 답이 검증된 것은 아닙니다. 링크가 실제로 열리는지, 사용자가 그 원문을 볼 권한이 있는지, 인용 조각이 바로 앞 주장을 지지하는지, 답의 중요한 주장에 빠진 인용은 없는지를 봐야 합니다. 모델이 문서 A를 근거로 쓰면서 문서 B 링크를 붙이거나, 일부 조건만 지지하는 조각으로 더 넓은 결론을 만들 수도 있습니다. 그래서 인용 정확성과 인용 커버리지를 따로 평가합니다.

RAG가 환각을 줄이는 조건과 여전히 틀리는 이유를 구분하세요

RAG가 환각을 줄이는 이유는 모델이 답변 시점에 구체적인 외부 근거를 받을 수 있기 때문입니다. 승인된 최신 원문이 색인돼 있고, 질문에 필요한 조각이 검색되며, 모델이 그 근거 안에서 답하고, 근거가 없을 때 거절하도록 평가했다면 매개변수 지식만으로 답할 때보다 사실성과 추적성을 높일 수 있습니다. 하지만 RAG는 오류를 없애는 장치가 아니라 오류 지점을 검색 파이프라인까지 넓히는 구조이기도 합니다.

오류 지점	무슨 일이 생기나	확인 방법	개선 방향
원문	잘못된 초안·폐기본·서로 충돌하는 규정이 색인됨	문서 소유자·승인 상태·버전·시행일 대조	정본 목록과 폐기 규칙, 충돌 우선순위 관리
파싱·청킹	표 머리글, 각주, 예외 조항 또는 OCR 숫자가 사라짐	원문과 추출 텍스트·조각을 표본 비교	문서 유형별 파서와 구조 기반 청킹 적용
검색	정답 조각이 상위 K개에 없거나 권한 필터가 잘못됨	정답 문서가 포함된 테스트 질문으로 Recall@K 확인	하이브리드 검색, 메타데이터, 쿼리 개선
문맥 구성	중복 조각이 공간을 차지하거나 핵심 근거가 잘림	최종 프롬프트에 들어간 조각과 순서 검토	중복 제거, 주변 문맥 보강, 토큰 예산 조정
생성	모델이 없는 조건을 추정하거나 여러 조항을 잘못 결합함	주장별로 근거가 실제 지지하는지 검토	근거 제한·모호성 질문·거절 규칙과 모델 평가
인용	관련은 있지만 해당 주장을 지지하지 않는 링크를 붙임	인용 정확성과 중요 주장 커버리지를 분리 평가	문장 단위 근거 연결과 후처리 검증

예를 들어 “계약 해지는 30일 전에 통보하면 되는가”라는 질문에서 검색된 조항은 일반 계약의 원칙만 담고, 별도 부속합의서에는 60일 예외가 있을 수 있습니다. 일반 조항이 매우 관련성 높게 검색돼도 해당 계약의 정답은 아닐 수 있습니다. 사용자 계약 유형과 적용 날짜를 다시 묻고 부속합의서까지 검색하지 않으면 자연스럽고 출처가 붙은 오답이 됩니다.

실제 적용 예시는 답보다 필요한 조건을 먼저 찾게 해야 합니다

인사팀이 “육아휴직 복귀 후 남은 연차를 이월할 수 있나요?”라는 사내 도우미를 만든다고 가정해 보겠습니다. 지식베이스에는 2026년 7월 1일부터 시행된 취업규칙 4판, 이전 3판, 정규직 운영지침, 기간제 근로자 예외 안내와 FAQ가 있습니다. 답을 만들려면 최신판 한 문서만 찾는 것이 아니라 질문자의 고용 형태, 복귀일, 휴직 기간, 이월 대상 연차의 발생연도와 별도 단체협약 적용 여부가 필요할 수 있습니다.

좋은 처리 흐름

1. 로그인한 사용자의 소속과 열람 그룹을 확인하고 허용된 문서만 검색 대상으로 둡니다.
2. “육아휴직·복귀·연차·이월” 키워드 검색과 의미 검색을 함께 실행합니다.
3. 시행일이 질문 시점에 맞는 4판을 우선하고, 기간제 예외와 단체협약 조각을 후보에 포함합니다.
4. 재정렬 후 일반 원칙과 예외가 함께 문맥에 들어가는지 확인합니다.
5. 고용 형태가 없으면 단정하지 않고 추가 질문을 하며, 답에는 규정명·판·조항·시행일을 표시합니다.
6. 인사상 권리 확정이나 분쟁 가능성이 있으면 인사 담당자 확인 경로를 함께 안내합니다.

나쁜 흐름은 3판의 “휴직자 연차” 조각이 의미상 가까워 상위에 올라왔다는 이유로 그대로 답하는 것입니다. 더 나쁜 경우는 4판의 원칙만 찾고 기간제 예외가 다른 조각에 있어 누락되는 상황입니다. 이 사례에서는 답변 문장 품질보다 현행 4판 회수, 예외 조각 동시 회수, 모호한 조건에 대한 추가 질문, 인용 위치가 성공 기준입니다.

제품 지원에서는 오류 코드와 모델명이 정확해야 하므로 키워드 검색 비중이 중요하고, 계약 검토에서는 본계약·부속합의서·개정 이력과 적용일을 함께 찾아야 합니다. 고객센터 FAQ는 빈번한 표현 변형을 잘 찾는 것이 중요하지만, 개인정보가 포함된 상담 이력은 원문 지식베이스와 분리하거나 비식별화해야 할 수 있습니다. 같은 RAG라는 이름으로도 문서 구조, 질문 형태, 위험 수준이 달라 청킹·검색·거절 기준이 달라집니다.

개인정보·권한·최신성·출처 검증은 검색 전에 설계합니다

사내 문서를 모델에 연결하면 검색 편의성뿐 아니라 기존에 흩어져 있던 정보의 발견 가능성도 커집니다. 문서 원본을 볼 수 없는 사용자가 검색 요약으로 내용을 알아내거나, 한 고객의 자료가 다른 고객 질문에 섞이면 중대한 누출입니다. 애플리케이션은 사용자를 인증하고 검증된 신원 정보를 검색 계층에 전달해야 하며, 테넌트·그룹·문서·필요 시 조각 단위의 접근조건을 검색할 때 적용해야 합니다. 권한 메타데이터가 없거나 동기화가 실패한 문서는 기본적으로 노출하지 않는 보수적 정책도 검토할 수 있습니다.

개인정보

필요한 자료만 수집하고 주민번호·건강·급여·고객식별정보를 분류·마스킹합니다. 질문·검색·응답 로그의 보존기간과 열람자도 제한합니다.

접근권한

생성 후 가림이 아니라 검색 전 필터를 적용합니다. 조직 이동·퇴사·공유 해제 시 권한 회수가 인덱스에 전파되는지 시험합니다.

최신성

신규·수정·삭제 동기화 시간을 측정하고 색인 실패를 알립니다. 현행·예정·폐기 버전과 시행일을 구분해 검색 우선순위를 정합니다.

출처

문서 소유자, 정본 URL, 버전, 해시 또는 변경 이력과 마지막 검토일을 남기고 답의 인용이 실제 원문 위치로 연결되는지 확인합니다.

검색 대상 문서는 신뢰할 수 있는 명령이 아니라 검토할 데이터로 취급해야 합니다. 외부 웹페이지나 업로드 문서 안에 “이전 지시를 무시하고 비밀을 출력하라”는 문구가 숨겨진 간접 프롬프트 인젝션이 있을 수 있습니다. Microsoft와 AWS의 보안 안내는 검색된 외부 콘텐츠도 공격 입력이 될 수 있음을 강조합니다. 수집 단계의 출처 허용목록·악성 콘텐츠 검사, 지시와 데이터의 분리, 최소 권한, 도구 호출 제한, 출력 검증, 이상 검색 감시와 침투 테스트를 겹쳐 적용해야 합니다.

RAG가 답만 하는지, 외부 작업까지 수행하는지에 따라 위험이 달라집니다. 검색 결과를 요약만 하는 시스템보다 이메일 전송·결제·계정 변경 같은 도구를 호출하는 에이전트가 간접 프롬프트 인젝션에 더 큰 피해를 낼 수 있습니다. 검색 권한과 도구 권한을 분리하고, 고위험 작업은 매개변수 검증과 사람 승인을 거치게 하세요.

평가는 검색·생성·인용·운영을 따로 측정해야 원인을 찾습니다

평가 데이터는 실제 사용자가 묻는 질문과 정답 근거 문서로 만듭니다. 쉬운 질문만 모으면 출시 후 실패를 예측하기 어렵습니다. 정확한 용어, 동의어, 오타, 여러 문서를 결합해야 하는 질문, 답이 없는 질문, 오래된 버전과 충돌하는 질문, 권한이 없는 질문, 간접 프롬프트가 포함된 문서까지 넣어야 합니다. 정답 문서뿐 아니라 예상 답변과 반드시 물어야 할 추가 조건을 함께 기록하면 검색과 생성 실패를 구분하기 쉽습니다.

평가 층	대표 질문·지표	낮을 때 먼저 볼 곳
검색	정답 조각이 상위 K개에 있는가: Precision@K, Recall@K, MRR·순위 품질	청킹, 메타데이터, 임베딩, 하이브리드 가중치, 필터, 재정렬
답변	질문에 정확하고 빠짐없이 답했는가: 정확성·완전성·관련성	문맥 구성, 프롬프트, 생성 모델, 질문 모호성 처리
근거	주장이 검색 근거에 충실한가: faithfulness·groundedness	근거 제한, 충돌 처리, 문장별 주장 검증
인용	인용이 주장을 지지하고 중요 주장에 모두 붙었는가: 인용 정확성·커버리지	조각 ID 연결, 인용 생성 방식, 후처리 검증
거절	답이 없거나 권한이 없을 때 추측하지 않는가	음성 테스트 질문, 임계값, 추가 질문·상담 연결 규칙
운영·보안	지연·비용·색인 지연·누출·공격 탐지·삭제 전파가 기준 안인가	파이프라인 알림, 로그, 권한 동기화, 방어 테스트

예를 들어 최종 답변 정확도가 낮아도 Recall@5가 높다면 정답 근거는 들어왔지만 모델이 해석을 잘못했을 가능성이 큽니다. 반대로 근거 충실성은 높지만 답이 틀리다면 모델이 검색된 잘못된 문서에 충실했을 수 있습니다. 검색 점수와 답변 점수를 하나로 합치면 이런 차이를 놓칩니다. 변경 전후에는 같은 테스트 세트와 설정을 사용해 비교하고, 임베딩 모델·청킹 크기·검색 개수·재정렬·프롬프트·생성 모델과 버전을 기록해야 합니다.

자동 평가 모델은 많은 사례를 빠르게 비교하는 데 유용하지만 정답 그 자체는 아닙니다. 특히 법무·의료·인사·재무·보안처럼 오답 비용이 큰 업무는 도메인 담당자의 표본 검수와 오류 등급을 함께 운영해야 합니다. 출시 후에도 새로운 질문과 문서가 들어오므로 답변 피드백만 모으지 말고 검색된 조각, 빠진 근거, 권한 필터 결과와 색인 상태를 재현할 수 있게 관찰해야 합니다.

긴 컨텍스트·파인튜닝·AI 에이전트는 해결하는 문제가 다릅니다

방식	적합한 상황	강점	주의할 점
긴 컨텍스트	한 번에 몇 개 문서의 전체 흐름을 비교·요약	별도 색인 없이 원문 맥락을 넓게 볼 수 있음	대량 문서 반복 검색, 권한·버전·비용 관리가 자동 해결되지 않음
RAG	많은 문서에서 질문마다 관련 근거를 찾아 출처와 함께 답변	외부 지식을 재학습 없이 갱신하고 검색 범위를 통제할 수 있음	검색 누락, 원문 오류, 권한·최신성·인용 검증이 필요함
파인튜닝	말투·출력 형식·분류·특정 작업 행동을 반복적으로 맞춤	원하는 응답 패턴과 작업 수행 방식을 학습시킬 수 있음	자주 바뀌는 사실의 최신 조회와 원문 인용을 대신하지 않음
AI 에이전트	검색 외 여러 도구를 선택해 계획·실행하고 결과를 확인	다단계 업무와 외부 시스템 작업을 연결할 수 있음	도구 권한·오작동·승인·간접 프롬프트 위험이 커지며 RAG와 별개 평가가 필요함

수십 페이지짜리 계약서 한 건을 한 번 분석한다면 긴 컨텍스트가 단순할 수 있습니다. 수만 개 규정과 매뉴얼에서 질문마다 현행 근거를 찾아야 한다면 RAG가 적합할 가능성이 큽니다. 답변을 회사 양식의 JSON으로 안정적으로 내거나 특정 분류 작업을 익히는 목적이라면 파인튜닝을 검토할 수 있습니다. 여러 시스템을 조회하고 티켓까지 만드는 목적이면 에이전트가 상위 흐름을 맡고 RAG를 하나의 검색 도구로 사용할 수 있습니다. 이 방식들은 경쟁 관계가 아니라 필요에 따라 조합되지만, 조합한다고 각 방식의 실패 조건이 사라지지는 않습니다.

자주 묻는 질문

Q1. 벡터 데이터베이스만 연결하면 RAG가 완성되나요?
A. 아닙니다. 벡터 저장소는 의미 검색을 위한 한 구성요소입니다. 원문 승인과 파싱, 청킹, 메타데이터, 권한 필터, 키워드·벡터 검색, 재정렬, 문맥 구성, 생성, 인용, 평가와 변경 동기화가 함께 작동해야 합니다.

Q2. 벡터 유사도 점수가 높으면 답이 맞다는 뜻인가요?
A. 아닙니다. 유사도는 질문과 조각의 의미상 가까움을 나타낼 뿐 사실 확률, 최신성, 공식성, 권한 또는 답변 신뢰도가 아닙니다. 정답 근거 포함 여부와 생성된 주장의 근거 충실성을 별도로 평가해야 합니다.

Q3. 청크는 몇 자로 나누는 것이 가장 좋나요?
A. 공통 정답은 없습니다. 규정·표·FAQ·매뉴얼처럼 문서 구조와 질문 형태가 다르기 때문입니다. 원칙과 예외, 제목과 본문, 표 머리글과 값이 보존되는 후보를 만들고 실제 질문 세트로 Recall@K, 답변 완전성, 비용과 지연을 비교하세요.

Q4. RAG를 쓰면 환각이 없어지나요?
A. 줄일 수는 있지만 없어지지 않습니다. 원문 자체의 오류, 검색 누락, 과거 버전 혼입, 문맥 잘림, 모델의 잘못된 결합과 인용 불일치가 남습니다. 근거 부족 시 답하지 않는 규칙과 고위험 답변의 사람 확인이 필요합니다.

Q5. 최신 문서를 올리면 바로 새 답이 나오나요?
A. 원본 변경이 파싱·임베딩·인덱스에 성공적으로 반영되고 과거 조각이 제거돼야 합니다. 변경·삭제 동기화 지연, 색인 실패와 캐시를 측정하고 답에 문서 버전·시행일을 표시해야 실제 최신성을 확인할 수 있습니다.

Q6. 파인튜닝 대신 항상 RAG를 쓰면 되나요?
A. 아닙니다. 자주 바뀌는 문서 사실을 검색하고 출처를 보여주는 목적에는 RAG가 유리한 반면, 말투·분류·출력 형식과 반복 작업 행동을 맞추는 목적에는 파인튜닝이 더 적합할 수 있습니다. 두 방식을 함께 쓰는 경우도 있습니다.

Q7. 출처 링크가 붙으면 사람 검토를 생략해도 되나요?
A. 아닙니다. 링크가 해당 주장을 실제로 지지하는지, 현행 원문인지, 사용자가 열 수 있는지 확인해야 합니다. 법률·의료·인사·재무·보안 등 오답 비용이 큰 결정은 담당자 승인 경로를 유지하세요.

Q8. 사내 문서는 모두 색인하는 것이 좋은가요?
A. 아닙니다. 업무 목적에 필요한 승인 원문만 최소한으로 수집하고 개인정보·영업비밀·자격증명·초안·폐기본을 분류해야 합니다. 권한 없는 자료가 검색되지 않도록 신원 검증과 검색 전 필터를 적용하세요.

핵심 정리

• RAG는 별도의 검색 시스템에서 질문 관련 근거를 찾아 생성형 AI의 입력 문맥으로 제공하는 전체 설계입니다.
• 색인 단계에서는 정본·버전·시행일·소유자·권한을 정한 뒤 구조를 보존해 파싱하고 청킹해야 합니다.
• 임베딩과 벡터 검색은 의미 유사도를 찾지만 진실·최신성·공식성·접근권한을 보증하지 않습니다.
• 정확한 코드와 조항에는 키워드 검색, 표현 변화에는 벡터 검색이 유용하며 하이브리드 검색과 재정렬을 실제 질문으로 비교합니다.
• 검색 전 권한 필터, 변경·삭제 동기화, 원문 출처와 버전 보존이 개인정보 누출과 과거 답변 위험을 줄입니다.
• 근거 부족·문서 충돌·질문 모호성에서는 추측보다 추가 질문이나 답변 거절을 선택하도록 설계합니다.
• 검색 관련성, 답변 정확성·완전성, 근거 충실성, 인용 정확성·커버리지와 거절 성능을 따로 평가합니다.
• RAG는 환각 가능성을 줄일 수 있지만 원문 오류·검색 누락·문맥 잘림·모델 해석 오류를 없애지는 못합니다.
• 긴 컨텍스트·파인튜닝·에이전트는 목적이 다르며 조합할 때도 각 방식의 권한과 실패 조건을 따로 관리해야 합니다.

공식 확인처

• NIST CSRC Glossary · Retrieval-Augmented Generation — 모델과 별도의 정보 검색 시스템을 결합하는 RAG의 공식 용어 정의를 확인합니다.
• NeurIPS 2020 · Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — 매개변수 지식과 외부 비매개변수 메모리를 결합한 초기 RAG 연구를 확인합니다.
• ACL Anthology · Dense Passage Retrieval for Open-Domain Question Answering — 질문과 문서의 밀집 표현을 이용한 검색 연구 배경을 확인합니다.
• Microsoft Learn · Design and develop a RAG solution — 청킹·메타데이터·임베딩·검색·생성과 단계별 평가 구조를 확인합니다.
• Microsoft Learn · RAG information retrieval — 키워드·벡터·하이브리드 검색, 필터와 재정렬 및 검색 지표를 확인합니다.
• Microsoft Learn · Secure multitenant RAG — 사용자와 테넌트가 권한 있는 근거만 검색하도록 하는 설계를 확인합니다.
• AWS · RAG 평가 지표 — 문맥 관련성·커버리지, 정확성·완전성·충실성, 인용 정확성·커버리지 지표를 확인합니다.
• AWS Prescriptive Guidance · RAG와 파인튜닝 비교 — 자주 바뀌는 문서와 출처 제시, 작업 맞춤 목적의 차이를 확인합니다.
• AWS Agentic AI Lens · 간접 프롬프트 인젝션 방어 — 검색된 외부 문서를 포함한 모든 입력 경로의 다층 방어 원칙을 확인합니다.

최종 확인일: 2026년 8월 5일

꼭 확인하세요

RAG는 문서 검색 기능이지 정답 보증 장치가 아닙니다. 관련 문서를 찾았더라도 그 문서가 승인된 현행본인지, 질문자의 상황에 적용되는지, 예외와 부속 문서가 빠지지 않았는지 확인해야 합니다. 출처 링크와 높은 유사도 점수만으로 법률·의료·인사·재무·보안 결정을 자동 확정하지 마세요.

권한은 답변 화면이 아니라 검색 단계에서 제한해야 합니다. 사용자를 인증하고 검증된 신원·테넌트·그룹 정보로 허용 문서만 검색하세요. 개인정보와 영업비밀은 수집 최소화·마스킹·암호화·로그 보존기간·열람 권한을 정하고, 조직 이동·퇴사·공유 해제 후 권한이 실제 색인과 캐시에 반영되는지 시험해야 합니다.

검색된 문서 안의 문구도 공격 입력일 수 있습니다. 외부 웹페이지·이메일·업로드 파일·문서 메타데이터의 숨은 지시가 모델 행동을 바꾸는 간접 프롬프트 인젝션을 고려하세요. 허용된 출처만 수집하고 문서를 검사하며, 검색 데이터와 시스템 지시를 분리하고, 도구 호출에는 최소 권한·매개변수 검증·고위험 작업 승인 절차를 두어야 합니다.

출시 후에는 최신성과 실패 원인을 계속 측정해야 합니다. 원문 수정·삭제가 색인에 반영되는 시간, 색인 실패, 정답 조각의 검색 여부, 근거 충실성과 인용 정확성을 기록하세요. 모델·임베딩·청킹·검색 설정 또는 프롬프트를 바꿀 때에는 같은 평가 세트로 회귀 테스트하고, 고위험 업무는 담당자의 최종 확인을 유지하세요.

함께 보면 좋은 글

• AI 에이전트 완벽 정리｜챗봇과 차이·작동 방식·도입 전 체크리스트
• 생성형 AI 환각 완벽 정리｜원인·검증법·업무 활용 체크리스트
• 생성형 AI 개인정보 보호 완벽 정리｜입력 전 확인·사내 문서·설정 체크리스트