RAG와 파인튜닝 차이: 고르는 기준 다섯 가지와 GraphRAG

회의 공지 문서에는 회의 시작이 오전 10시로 바뀌어 있는데 AI가 오전 9시라고 답했다면, AI가 바뀐 문서를 보지 못했을 수 있습니다. 반대로 시간은 정확히 찾았는데 요청한 세 줄 요약 대신 긴 글을 썼다면 답하는 형식의 문제입니다. 두 경우는 고칠 곳이 다릅니다.

RAG(검색 증강 생성)는 질문에 필요한 자료를 찾아 모델이 답할 때 참고하는 입력에 더하는 방식입니다. 파인튜닝(Fine-tuning)은 추가 학습으로 모델의 매개변수를 조정하는 작업이고, 매개변수는 모델이 답을 만들 때 쓰는 내부 수치입니다. 파인튜닝은 형식이나 어투, 분류 같은 특정 작업을 더 잘하게 만들 때 씁니다.

RAG는 참고 자료를 찾아 펼쳐 주는 일에, 파인튜닝은 예시를 반복해 보여 주며 특정 작업을 익히게 하는 일에 가깝습니다. 두 방식을 함께 쓸 수도 있고, 자료가 몇 개뿐이라면 필요한 문서를 직접 붙이고 요청을 다듬는 것으로 끝나기도 합니다.

상황별로 맞는 방식부터 보여 드립니다. 근거는 아래 다섯 단계 비교에 있습니다.

이런 경우라면 이 방식

이런 경우	자료 첨부프롬프트와 예시	RAG검색 증강 생성	파인튜닝추가 학습
참고할 문서가 몇 개뿐이다	제공	–	–
매주 바뀌는 정책이나 가격표로 답한다	–	제공	–
답변마다 근거 원문을 대조해야 한다	–	제공	–
답 형식이 한두 번 어긋났다	제공	–	–
예시를 고쳐도 형식이나 분류가 계속 어긋난다	–	–	제공
여러 문서에 흩어진 관계를 이어야 한다	–	GraphRAG 검토	–

RAG와 파인튜닝이 각각 바꾸는 것

AWS의 RAG 설명 그림은 질문이 들어온 뒤 자료를 찾고, 찾은 자료를 모델 입력에 더해 답을 받는 순서를 보여 줍니다.

오른쪽 Knowledge Sources가 참고 자료가 있는 곳이고, 아래 모델에는 질문과 검색 결과가 함께 들어갑니다. 이 흐름 어디에도 모델을 다시 학습시키는 단계는 없습니다. RAG가 바꾸는 것은 입력이고, 파인튜닝이 바꾸는 것은 모델 자체입니다.

두 방식이 바꾸는 곳과 드는 비용

항목	RAG	파인튜닝
바꾸는 곳	답할 때 참고하는 입력	모델의 매개변수
새 내용 반영	검색 대상과 색인 캐시 갱신	다시 학습
드는 비용	자료 처리, 저장 검색, 답변	학습, 평가 배포, 답변

파인튜닝으로도 지식을 어느 정도 학습시킬 수 있습니다. 그래도 수시로 바뀌는 가격표를 정확하게 갱신하고 답변의 출처까지 추적해야 한다면 자료 검색이 먼저입니다. 위 표의 캐시는 다시 쓰려고 임시로 보관한 결과로, 원문을 고친 뒤에도 옛 검색 결과나 답변이 남아 있을 수 있습니다. RAG가 늘 더 싸지도 않고, 파인튜닝한 뒤 응답 비용이 늘 낮아지지도 않습니다.

1. 자료가 바뀌는 빈도

매주 바뀌는 정책이나 가격표라면 최신 자료를 검색해 넣는 RAG가 맞습니다. 파인튜닝은 내용이 바뀔 때마다 다시 학습해야 합니다. RAG에서도 새 파일을 올리는 것으로 끝나지 않고, 고친 문서가 실제 검색 결과에 나올 때까지 몇 단계를 거칩니다.

문서를 고친 뒤 RAG 답변에 반영되는 순서

1. 11. 원문 수정새 버전 저장
   이전 버전 구분
2. 22. 색인 갱신검색용 구조를
   새 원문으로
3. 33. 캐시 비우기옛 검색 결과와
   답변 지우기
4. 44. 적용일 표시작성일과 별도로
   언제부터 적용인지
5. 55. 질문으로 확인바뀐 내용을 묻고
   새 답이 나오는지

4번이 자주 빠집니다. 나중에 작성된 안내라도 다음 달부터 적용하는 내용일 수 있어서, 작성일만으로 현재 기준을 정하지 않고 적용 날짜를 문서에 함께 둡니다.

이 단계에서는 RAG가 유리합니다. 자료가 바뀌어도 다시 학습하지 않고 색인과 캐시를 갱신해 반영합니다.

2. 답변에 근거가 필요한지

RAG는 검색한 원문과 위치를 답변에 함께 남길 수 있어서, 답이 맞는지 원문과 바로 대조하기 쉽습니다. 파인튜닝한 모델의 답변은 어느 자료에서 나온 내용인지 학습만으로는 추적할 수 없습니다.

근거가 붙은 답변을 대조하는 모습

Claude

이번 주 회의는 몇 시에 시작하나요?

오전 10시에 시작합니다.
근거: 회의 공지 10월 3일 수정본, 2번째 문단

링크가 붙어도 원문과 직접 대조

근거 문서를 열어 2번째 문단에 실제로 오전 10시라고 적혀 있는지 봅니다.

근거 링크가 붙었다고 답이 그 원문을 정확히 옮긴 것은 아닙니다. 근거 링크는 원문을 열어 해당 문장이 답과 같은지 볼 때 쓸모가 있습니다.

이 단계에서는 RAG가 유리합니다. 답마다 근거 원문을 남길 수 있어서 틀린 답을 찾기 쉽습니다.

3. 틀리는 부분이 무엇인지

답이 틀렸다면 원인이 자료에 있는지 답하는 방식에 있는지부터 나눕니다. 처음 예시의 회의 시간으로 따져 보면 원인은 세 가지 가운데 하나입니다.

틀린 답의 원인을 좁히는 순서

1. 11. 받은 자료 보기10월 3일 수정본이
   입력에 들어갔는지
2. 22. 못 찾음수정본이 없음
   검색, 자료 제공 문제
3. 33. 잘못 씀수정본을 받고도 9시
   자료 사용 문제
4. 44. 형식 다름내용은 맞고 길이가 다름
   프롬프트, 예시 문제

2번이면 검색이나 자료 제공을 고치고, 3번이면 검색은 제대로 됐으니 답변 단계를 봅니다. 4번처럼 내용은 맞는데 형식이 어긋났다면 명확한 양식과 예시, 도구가 지원하는 출력 형식 제한 기능부터 씁니다. 형식 오류가 한 번 났다고 추가 학습을 시작하지 않고, 프롬프트와 예시를 고쳐도 같은 오류가 반복될 때 파인튜닝을 검토합니다.

이 단계에서는 자료를 못 찾았다면 RAG가, 형식과 판단이 반복해서 어긋난다면 파인튜닝이 유리합니다.

4. 학습과 평가에 쓸 예시가 있는지

평가(Evaluation)는 기대하는 답과 실제 답을 비교하는 과정입니다. 회의 시간 예시처럼 어떤 답이면 맞는지 먼저 적어 둡니다. 지도 파인튜닝은 입력과 원하는 답을 짝으로 주는 추가 학습 방식이고, OpenAI의 지도 파인튜닝 안내는 필요한 예시 개수를 아래처럼 제시합니다.

OpenAI 지도 파인튜닝 안내의 예시 개수

• 10개최소 예시
• 50개시작 권장잘 만든 예시로
• 50~100개개선이 나타나는 범위

개수를 채웠다고 효과가 보장되지는 않고, OpenAI에서 직접 학습시키려면 이용 가능 여부도 봅니다. 2026년 10월 기준 OpenAI는 파인튜닝 플랫폼을 단계적으로 종료하고 있어 신규 이용자는 접근할 수 없고, 기존 이용자는 제공 종료 안내의 일정을 따릅니다.

OpenAI의 모델 최적화 안내는 "Good evals first!"라고 강조합니다. 좋은 평가 자료를 먼저 준비하라는 말입니다. 학습할 때 보여 준 예시만 다시 맞히는지 검사하면 새 질문에서도 잘하는지 알 수 없어서, 평가 자료는 학습 예시와 따로 둡니다.

파인튜닝 전에 거치는 순서

1. 11. 평가 자료질문과 기대 답
   학습 예시와 분리
2. 22. 프롬프트 개선양식과 예시를
   먼저 고치기
3. 33. 비교같은 평가 자료로
   고치기 전후 비교
4. 44. 추가 학습그래도 반복되는
   오류가 있을 때
5. 55. 다시 평가학습 전후를
   같은 자료로

이 단계에서는 평가 자료와 잘 만든 예시가 준비된 경우에만 파인튜닝이 후보가 됩니다. 예시가 없다면 프롬프트와 자료 첨부가 유리합니다.

5. 자료를 어디까지 보낼 수 있는지

RAG는 모델을 추가 학습시키지 않지만, 질문할 때마다 검색한 본문을 답변 모델에 보냅니다. 외부 전송이 금지된 자료라면 RAG를 쓴다는 것만으로는 문제가 해결되지 않습니다.

RAG에서 자료가 이동하는 순서

1. 11. 원문 저장소사내 문서
   위키, 노션
2. 22. 검색 서버색인을 두고
   질문에 맞는 조각 찾기
3. 33. 모델로 전송찾은 본문이
   답변 모델 입력으로
4. 44. 답변사용자별
   접근 권한 적용

위키나 노션은 문서를 관리하는 공간이고, RAG는 그 자료를 검색해 답변에 쓰는 구성이라서 둘을 함께 씁니다. 문서가 잘 정리돼 있어도 연결과 검색, 답변이 올바른지는 따로 봅니다.

이 단계에서는 방식보다 실행 위치가 먼저입니다. 검색 서버와 모델의 실행 위치, 보관 정책, 사용자별 접근 권한이 회사 규정에 맞는 구성만 후보로 남습니다.

RAG에서 검색이 어긋나는 이유

Azure의 RAG 설계 그림은 문서를 검색할 수 있게 준비하는 과정과 질문에 답하는 과정을 나눠 보여 줍니다.

그림 아래쪽 흐름은 문서를 나누고 설명 정보를 보완한 뒤 검색용 표현을 만들어 저장하는 준비 과정이고, 위쪽은 사용자의 질문에서 검색과 답변 생성으로 이어지는 과정입니다. 이어서 설명하는 청크, 임베딩, 색인은 모두 이 준비 과정에 속합니다.

청크(Chunk)는 검색과 입력에 쓰는 문서 조각입니다. "회의는 오전 10시"만 잘라 내고 문서 날짜와 변경 이유를 버리면 어느 회의의 최신 정보인지 알 수 없어서, 제목과 날짜 같은 설명 정보를 청크에 함께 붙입니다.

임베딩(Embedding)은 문장의 특징을 숫자 묶음으로 바꾸는 방법이고, 이 숫자가 비슷한 문장을 찾는 것이 벡터 검색입니다. 색인(Index)은 자료를 빠르게 찾도록 정리한 검색용 구조여서, 원문을 바꿔도 색인을 갱신하지 않으면 옛 정보가 검색됩니다.

단어를 기준으로 찾는 방법도 있습니다. BM25는 단어가 나온 횟수와 문서 길이를 반영해 관련성을 계산합니다. 벡터 검색과 단어 검색을 함께 쓰는 방식은 하이브리드 검색이라고 하고, 찾은 후보를 다시 평가해 순서를 바꾸는 단계는 재순위(Reranking)입니다.

앤트로픽은 2024년 Contextual Retrieval 연구에서 청크마다 맥락 설명을 붙였을 때 검색 실패가 얼마나 줄었는지 공개했습니다. 실패율은 1 - recall@20, 즉 관련 자료가 상위 20개 검색 결과에 들어오지 못한 비율입니다.

상위 20개 검색 결과의 실패율

• 기준 구성5.7%
• 맥락 임베딩3.7%기준 대비 약 35% 감소
• 맥락 임베딩과 맥락 BM252.9%기준 대비 약 49% 감소
• 재순위까지 적용1.9%기준 대비 약 67% 감소

5.7%에서 1.9%로 3.8%포인트, 상대적으로 약 67% 줄었습니다. 이 수치는 검색 단계의 결과이고 최종 답변의 오답률이 아닙니다. 그래서 필요한 정보가 검색 결과에 들어왔는지와 최종 답이 맞는지를 따로 평가하고, 우리 자료에서도 같은 질문 묶음으로 직접 비교합니다.

벡터 검색만이 RAG는 아닙니다

RAG는 검색한 자료를 답변에 쓰는 구성이고, 검색 방법은 벡터 검색 말고도 단어 검색, 데이터베이스 조회, 여러 단계에 걸친 검색이 있습니다.

마이크로소프트의 GraphRAG는 문서에서 사람과 조직 같은 개체와 그 관계를 뽑아내고, 서로 연결된 묶음마다 요약을 만들어 질문에 씁니다. 공식 문서는 단순한 벡터 유사도 검색이 여러 문서의 관계를 잇거나 자료 전체의 큰 주제를 파악하는 데 약하다고 설명합니다.

질문 종류에 따라 맞는 검색 방식

질문	일반 RAG벡터, 단어 검색	GraphRAG개체와 관계
환불 기한이 며칠인가요?	제공	–
3년간 여러 프로젝트를 함께 맡은 담당자는 누구인가요?	여러 문서 연결이 어려움	제공
자료 전체의 큰 주제는 무엇인가요?	전체 파악이 어려움	제공

첫 질문은 근거 한 곳만 찾으면 되고, 둘째와 셋째 질문은 여러 문서를 이어야 답이 나옵니다. GraphRAG도 관계를 잘못 뽑을 수 있고, 자료를 처리하는 비용과 갱신 작업이 늘어납니다. 단순한 검색으로 풀리지 않는 질문이 실제로 있는지 먼저 모아 본 뒤, 그 질문들로 그래프 방식의 답과 비용을 비교합니다.

이미 쓰는 도구로 RAG를 시험하기

검색 시스템을 직접 설치하지 않아도 RAG를 쓸 수 있습니다. Claude 프로젝트는 지원되는 유료 요금제에서 프로젝트 지식이 컨텍스트 한계에 가까워지면 RAG를 자동으로 사용합니다. 컨텍스트는 모델이 한 번 응답할 때 참고하는 입력 범위입니다. 공식 안내의 "최대 10배"는 RAG를 쓸 때 프로젝트에 넣을 수 있는 자료의 양이 늘어나는 정도이고, 답변 하나를 만들 때는 그중 질문에 맞는 부분을 찾아 씁니다.

Claude 프로젝트로 RAG를 시험하는 순서

1. 11. 자료 올리기민감 정보가 없는
   업무 문서 몇 개
2. 22. 질문하기답이 정해진
   질문 몇 개
3. 33. 근거 대조답과 원문 문장이
   같은지
4. 44. 조건 보기요금제의 기능과 용량
   자료 처리 조건

파일을 많이 올렸다고 답이 좋아질 것으로 기대하기보다, 답이 정해진 질문 몇 개로 실제 답과 근거를 대조해 보는 편이 정확합니다.

단계별 판정과 함께 쓰는 경우

다섯 단계에서 유리했던 방식을 한 장에 모았습니다.

단계별로 유리한 방식

비교 단계	자료 첨부프롬프트와 예시	RAG검색 증강 생성	파인튜닝추가 학습
1. 자주 바뀌는 자료	–	제공	–
2. 답변별 근거 대조	–	제공	–
3. 자료를 못 찾는 오류	–	제공	–
3. 한두 번의 형식 오류	제공	–	–
3. 반복되는 형식, 판단 오류	–	–	제공
4. 평가 자료와 예시가 없음	제공	–	–
5. 외부 전송 금지 자료	실행 위치 먼저	실행 위치 먼저	실행 위치 먼저

파인튜닝한 모델에 RAG로 찾은 자료를 넣을 수도 있습니다. 분류 예시로 학습시킨 모델이 최신 안내문을 참고해 답하게 하는 식입니다. 대신 학습 데이터와 검색 자료를 모두 관리해야 합니다. 프롬프트와 작은 자료 첨부부터 시작해, 확인된 문제를 푸는 기능을 하나씩 더하면 어떤 기능이 효과를 냈는지 구별하기 쉽습니다.

자주 묻는 질문

자료가 몇 개 없는데 RAG를 구축해야 하나요?

필요한 문서를 직접 첨부하거나 요청에 넣는 것으로 충분한 경우가 많습니다. 자료가 많아져 질문마다 필요한 부분을 자동으로 골라야 할 때 검색 구성을 만듭니다. 기준은 문서 개수보다 질문마다 찾아야 하는 범위입니다.

답변 형식이 틀리면 파인튜닝이 필수인가요?

필수는 아닙니다. 먼저 요청을 구체적으로 쓰고 올바른 예시를 보여 줍니다. 도구가 지원하면 출력 형식을 제한하는 기능도 씁니다. 그래도 같은 문제가 반복되면 평가 결과를 근거로 파인튜닝을 검토합니다.

RAG를 쓰면 자료가 모델 학습에 쓰이지 않나요?

RAG 처리와 모델의 추가 학습은 별개의 작업입니다. 다만 검색한 내용은 모델에 전달되고, 서비스가 그 내용을 어떻게 저장하고 활용하는지는 제품과 계약 조건이 정합니다. 외부 전송과 보관, 학습 정책은 RAG라는 이름이 아니라 쓰는 서비스의 약관으로 판단합니다.

Sources

• AWS RAG 공식 설명
• OpenAI 모델 최적화 가이드
• OpenAI 지도 파인튜닝 가이드
• OpenAI 제공 종료 안내
• Anthropic: Introducing Contextual Retrieval
• Microsoft GraphRAG 공식 문서
• Claude 프로젝트 RAG 공식 안내
• Microsoft Azure RAG 설계 가이드