RAG와 파인튜닝(fine-tuning) 차이, 고르는 기준과 GraphRAG 정리

RAG(검색 증강 생성)는 모델이 답을 만들기 전에 학습 데이터 밖의 자료를 찾아 참고하게 만드는 방식입니다. 파인튜닝은 입력과 출력 예시를 학습시켜 모델이 답하는 방식 자체를 바꾸는 작업입니다. 회사 자료나 내 자료를 AI에 물리려 할 때 둘 중 무엇을 골라야 할지 막히는 경우가 많은데, 판단은 바꾸려는 대상이 참고 자료인지 답하는 방식인지에서 시작합니다.

이 글은 두 방식이 각각 무엇을 바꾸는지, 고르는 기준 다섯 가지, 시작하기 전에 확인할 숫자를 공식 문서 기준으로 정리합니다.

AWS 공식 RAG 흐름 다이어그램. 프롬프트와 질의가 들어오면 지식 소스를 검색해 관련 정보를 가져오고, 그 정보를 붙인 프롬프트를 대규모 언어 모델 엔드포인트에 보내 응답을 받는 5단계가 번호로 표시됨

위 다이어그램은 AWS 공식 문서에 실린 RAG 흐름입니다. 질문이 들어오면 먼저 지식 소스를 검색하고, 찾은 자료를 질문에 붙여 모델에 보낸 뒤 답을 받습니다. 모델 자체는 손대지 않고 모델에 들어가는 입력만 바꾸는 구조입니다.

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

AWS 공식 문서는 RAG를 "대규모 언어 모델의 출력을 최적화해, 답을 만들기 전에 학습 데이터 소스 밖의 신뢰할 수 있는 지식 기반을 참조하게 하는 과정"으로 정의합니다. 모델 가중치를 건드리지 않는다는 점이 핵심입니다.

파인튜닝은 반대 방향입니다. 입력과 출력 예시를 모아 학습시켜 모델이 그 형식과 어투, 판단 방식을 따르게 만듭니다. 지식을 넣는 작업이 아니라 행동을 고정하는 작업에 가깝습니다.

항목	RAG	파인튜닝
바꾸는 대상	모델에 들어가는 입력	모델 자체
잘하는 일	최신 자료 반영, 출처 표시	형식 고정, 어투 통일, 분류 일관성
자료가 바뀔 때	검색 색인만 다시 만들면 됨	다시 학습해야 함
출처 표시	가능	어려움
준비물	문서와 검색 인프라	입출력 예시 데이터셋
비용 성격	검색과 저장 비용이 계속 발생	학습 비용이 크고 이후 추론은 저렴

AWS 공식 문서는 비용을 이렇게 적고 있습니다. 조직이나 도메인 특화 정보를 위해 파운데이션 모델을 재학습하는 계산 비용과 금전 비용이 높고, RAG가 더 비용 효율적인 접근이라는 설명입니다. 또 RAG는 답변에 인용이나 참조를 포함해 출처를 표시할 수 있다고 밝히고 있습니다.

여기서 자주 나오는 질문이 사내 위키와의 관계입니다. 위키나 노션에 문서를 정리해 두는 것과 RAG는 대체 관계가 아닙니다. 위키는 사람이 검색해 읽는 저장소이고, RAG는 그 저장소에서 AI가 답에 쓸 자료를 찾아오게 만드는 장치입니다. 문서가 여러 곳에 흩어져 있다면 RAG를 붙이기 전에 정리부터 하는 것이 순서입니다.

고르는 기준 다섯 가지

자료의 변경 주기: 매주 갱신되는 정책 문서나 가격표라면 RAG입니다. 파인튜닝은 자료가 바뀔 때마다 다시 학습해야 합니다.
출처 표시 필요 여부: 답변에 근거 문서를 함께 내보내야 하는 업무라면 RAG입니다. 파인튜닝한 모델은 어느 자료에서 나온 답인지 가리키지 못합니다.
바꾸려는 대상이 지식인지 형식인지: 없는 지식을 채우려면 RAG, 매번 같은 JSON 구조나 사내 문서 양식으로 뽑으려면 파인튜닝입니다.
학습용 예시 확보 여부: 좋은 입출력 쌍을 수십 개 이상 모으지 못하면 파인튜닝은 시작 자체가 어렵습니다.
자료와 모델의 분리 요건: 계약이나 규정 때문에 원본 자료가 모델 안으로 들어가면 안 되는 경우 RAG가 맞습니다.

다섯 가지 가운데 세 개 이상이 RAG를 가리키면 파인튜닝은 뒤로 미뤄도 됩니다. 반대로 답변 형식이 매번 흔들리는 것이 유일한 문제라면 자료를 아무리 많이 붙여도 해결되지 않습니다.

파인튜닝을 시작하기 전에 확인할 숫자

OpenAI 공식 문서는 지도 파인튜닝의 최소 학습 예시를 10개로 정하고 있습니다. 그리고 50개에서 100개 예시로 학습했을 때 개선이 보인다고 적으며, 잘 만든 시연 50개로 시작하라고 권합니다.

공식 문서에서 정작 중요한 대목은 그다음에 나옵니다. 예시 50개로도 효과가 없으면 학습 데이터를 더 넣기 전에 과제나 프롬프트를 다시 생각하라고 안내합니다. 데이터를 늘려서 풀 문제가 아닐 수도 있다는 뜻입니다.

같은 문서는 파인튜닝에 돈을 쓰기 전에 평가 체계부터 만들라고 강조합니다. 원문 표현은 "Good evals first!"입니다. 무엇이 좋아졌는지 재지 못하면 학습 결과를 판단할 방법이 없습니다.

OpenAI가 제시하는 최적화 순서도 참고할 만합니다.

평가 체계를 만듭니다.
프롬프트 엔지니어링을 합니다.
그래도 부족하면 파인튜닝으로 넘어갑니다.
테스트 데이터로 평가를 돌립니다.
결과를 보고 프롬프트나 학습 데이터를 고칩니다.

공식 문서는 프롬프트 엔지니어링 과정만으로도 좋은 결과를 얻기에 충분할지 모른다고 적고 있습니다. 파인튜닝이 첫 선택지가 아니라는 점을 문서가 먼저 밝히고 있는 셈입니다.

RAG를 켠다고 검색이 잘되지는 않습니다

RAG를 고르고 나면 그때부터 결정할 것이 늘어납니다.

마이크로소프트 Azure 공식 RAG 설계 다이어그램. 문서를 청크로 나누고 정제하고 임베딩해 저장하는 각 단계마다 청킹 방법, 메타데이터 구성, 임베딩 모델 선택, 검색 인덱스 설정을 묻는 질문 상자가 붙어 있음

위 그림은 마이크로소프트 Azure 공식 문서에 실린 RAG 설계 안내입니다. 문서를 청크로 나누고, 청크를 정제하고, 임베딩하고, 색인에 저장하는 단계마다 결정해야 할 질문이 붙어 있습니다. 청킹 방법, 메타데이터 구성, 임베딩 모델 선택, 검색 방식(벡터, 전문 검색, 하이브리드), 재순위 여부가 모두 선택지입니다.

앤트로픽은 이 선택이 성능에 실제로 영향을 준다는 것을 수치로 밝혔습니다. 기존 방식이 문서를 청크로 자를 때 맥락을 잃어 필요한 정보를 못 찾는 문제를 지적하며, 청크 앞에 그 청크의 맥락 설명을 붙이는 Contextual Retrieval 기법을 공개했습니다.

아래 표에 나오는 BM25는 뜻이 가까운 문서를 찾는 임베딩 검색과 달리 단어가 그대로 일치하는지를 보는 방식이고, 재순위는 검색해 온 결과를 다시 정렬해 상위를 추리는 단계입니다. 검색 실패율 변화는 이렇습니다.

구성	검색 실패율	감소폭
기존 청크 방식	5.7%	기준
맥락 임베딩 적용	3.7%	35% 감소
맥락 임베딩 + BM25	2.9%	49% 감소
재순위까지 적용	1.9%	67% 감소

같은 문서를 같은 모델에 물려도 검색을 어떻게 만드느냐에 따라 실패율이 세 배 차이입니다. RAG를 붙였는데 답이 시원치 않다면 모델이 아니라 검색 쪽을 먼저 봐야 합니다.

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

지금까지 설명한 방식은 문서를 조각내 임베딩하고 뜻이 가까운 조각을 찾아오는 구조입니다. 마이크로소프트 GraphRAG 공식 문서는 이런 방식을 기본 RAG(baseline RAG)라고 부르며, 두 가지 상황에서 약하다고 지적합니다.

흩어진 사실을 이어야 하는 질문: 여러 조각에 나뉜 정보를 공통 속성으로 따라가며 새 결론을 만들어야 할 때 기본 RAG는 점을 잇지 못한다고 적고 있습니다.
큰 자료를 통째로 파악해야 하는 질문: 많은 양의 자료나 하나의 긴 문서 전체를 요약해 이해해야 할 때 성능이 떨어진다고 봅니다.

GraphRAG는 원문에서 개체와 관계를 뽑아 지식 그래프를 만들고, 비슷한 것끼리 묶은 계층을 더해 답을 만드는 방식입니다. 공식 문서는 이를 평범한 텍스트 조각을 쓰는 의미 검색 방식과 대비되는 구조적이고 계층적인 접근으로 정의합니다.

질문 성격으로 나누면 판단이 쉬워집니다. 환불 정책이 어떻게 되나요처럼 한 문단 안에 답이 들어 있는 질문은 벡터 검색으로 충분합니다. 반대로 이 고객사와 3년간 어느 담당자가 어떤 건으로 얽혀 있었나요처럼 여러 문서에 흩어진 사실을 이어야 하는 질문은 조각을 아무리 잘 찾아와도 답이 만들어지지 않습니다.

다만 GraphRAG는 개체와 관계를 뽑는 작업이 먼저 들어갑니다. 문서를 넣으면 되는 벡터 RAG보다 초기 비용이 큽니다. 처음부터 그래프로 시작하기보다 벡터 RAG로 어떤 질문이 막히는지 확인한 다음 검토하는 순서가 안전합니다.

도구가 대신 해 주는 부분

직접 만들지 않아도 되는 경우가 늘었습니다. 앤트로픽 공식 문서는 클로드 프로젝트의 RAG를 프로젝트가 이전보다 훨씬 많은 지식을 저장하고 꺼내 쓰게 해 주는 기술로 정의합니다. 프로젝트가 컨텍스트 한계에 가까워지거나 넘어설 때 자동으로 켜지며, 저장 가능한 분량은 최대 10배까지 늘어납니다.

사용자가 켜고 끄는 설정이 아니라 자동으로 관리되는 구조입니다. 사내 자료 수백 건을 다루는 정도라면 벡터 데이터베이스를 직접 세우기 전에 이런 기능부터 써 보는 편이 시간을 아낍니다.

실무 예시. 마케팅 팀이 3년치 캠페인 회고 문서 300건을 AI에 넣어 두고 비슷한 캠페인에서 무엇을 배웠는지 묻고 싶다고 하겠습니다. 이 경우는 RAG입니다. 문서가 계속 늘어나고, 어느 캠페인 문서에서 나온 답인지 확인해야 하고, 회고 문서를 학습 예시 형태로 가공할 방법도 마땅치 않기 때문입니다. 반대로 그 팀이 매번 같은 항목과 같은 순서로 회고 문서를 뽑아내게 만들고 싶다면 그때는 파인튜닝이나 잘 만든 프롬프트 템플릿 쪽이 맞습니다.

둘을 함께 쓰는 구성

실무에서는 둘을 함께 쓰는 사례가 늘고 있는 것으로 보입니다. 작은 모델을 형식과 어투로 파인튜닝해 두고 그 앞에 RAG를 붙이는 구성이 자주 언급됩니다. 형식은 학습으로 고정하고 내용은 검색으로 채우는 방식입니다.

다만 이 구성은 관리할 것이 두 배가 됩니다. 학습 데이터도 유지해야 하고 검색 색인도 유지해야 합니다. 처음부터 둘을 같이 시작하기보다 프롬프트로 어디까지 되는지 재고, 모자란 쪽을 하나씩 붙이는 편이 안전합니다.

자주 묻는 질문 (AEO)

Q. RAG와 파인튜닝의 가장 큰 차이는 무엇인가요?

A. RAG는 모델에 들어가는 입력을 바꾸고, 파인튜닝은 모델 자체를 바꿉니다. RAG는 답할 때 참고할 자료를 붙여 주는 방식이고, 파인튜닝은 예시를 학습시켜 답하는 형식과 어투를 고정하는 방식입니다.

Q. 파인튜닝에 예시가 몇 개나 필요한가요?

A. OpenAI 공식 문서는 최소 10개를 요구하고, 50개에서 100개 예시에서 개선이 보인다고 적고 있습니다. 잘 만든 시연 50개로 시작하라고 권합니다.

Q. 사내 문서를 AI가 읽게 하려면 파인튜닝을 해야 하나요?

A. 대부분 RAG가 맞습니다. AWS 공식 문서는 도메인 특화 정보를 위해 모델을 재학습하는 비용이 높고 RAG가 더 비용 효율적이라고 밝히고 있습니다. 문서가 바뀔 때 색인만 다시 만들면 되는 점도 큽니다.

Q. RAG를 붙였는데 답이 정확하지 않으면 무엇을 봐야 하나요?

A. 검색 단계를 먼저 봅니다. 앤트로픽 자료에서 청크에 맥락을 붙이고 BM25와 재순위를 더했을 때 검색 실패율이 5.7%에서 1.9%까지 내려갔습니다. 모델을 바꾸기 전에 청킹과 검색 방식을 점검하는 편이 빠릅니다.

Q. 사내 위키가 있는데 RAG가 따로 필요한가요?

A. 위키는 사람이 검색해 읽는 저장소이고, RAG는 그 문서를 AI가 찾아 답에 쓰게 만드는 장치입니다. 둘은 대체 관계가 아니며, 위키 문서가 잘 정리되어 있을수록 RAG 결과도 좋아집니다.

Q. GraphRAG는 일반 RAG와 무엇이 다른가요?

A. 일반 RAG는 문서 조각을 임베딩해 뜻이 가까운 조각을 찾아오고, GraphRAG는 개체와 관계를 뽑아 지식 그래프를 만든 뒤 그 연결을 따라갑니다. 마이크로소프트 GraphRAG 공식 문서는 여러 정보를 이어 새 결론을 만들어야 하는 질문과 큰 자료를 통째로 이해해야 하는 질문에서 기본 RAG가 약하다고 지적합니다.

Q. 프롬프트만으로 해결되는 경우도 있나요?

A. 그렇습니다. OpenAI 공식 문서는 프롬프트 엔지니어링 과정만으로도 좋은 결과를 얻기에 충분할지 모른다고 적고 있습니다. 평가 체계를 먼저 만들고 프롬프트로 어디까지 되는지 재 본 다음에 RAG나 파인튜닝을 검토하는 순서를 권합니다.

3줄 요약:

RAG는 모델에 들어가는 입력을 바꾸고 파인튜닝은 모델 자체를 바꾸므로, 자료를 채우려면 RAG, 형식과 어투를 고정하려면 파인튜닝입니다.
파인튜닝은 OpenAI 기준 최소 예시 10개에 권장 시작점 50개이고, 50개로 효과가 없으면 데이터를 늘리기 전에 과제와 프롬프트를 다시 봐야 합니다.
RAG는 켜는 것으로 끝나지 않고 청킹과 검색 방식이 성능을 정합니다. 앤트로픽 자료에서 구성에 따라 검색 실패율이 5.7%에서 1.9%까지 달라졌습니다.