RAG와 Fine-tuning 차이: LLM 커스터마이징 전략 선택 기준

LLM을 우리 데이터에 맞게 활용하려면 RAG와 Fine-tuning 중 어떤 방식을 선택해야 하는지, 비용·운영·품질 관점에서 판단 기준을 정리합니다.

핵심 요약

• RAG는 외부 지식을 검색하여 프롬프트에 제공하는 방식이고, Fine-tuning은 모델 자체를 추가 학습시키는 방식입니다.
• 자주 변경되는 지식 기반 시스템에는 RAG가, 특정 도메인의 언어 패턴이나 출력 형식을 학습시켜야 할 때는 Fine-tuning이 적합합니다.
• 두 방식은 상호 배타적이지 않으며, 운영 환경에서는 결합하여 사용하는 경우도 있습니다.
• 선택 기준은 "모델이 무엇을 알아야 하는가(지식)" vs "모델이 어떻게 답해야 하는가(행동)"로 구분할 수 있습니다.
• 비용, 운영 복잡도, 데이터 보안 요건에 따라 최적 전략이 달라집니다.

1. 문제 상황: LLM을 우리 데이터에 맞추려면

ChatGPT나 Claude 같은 범용 LLM에게 사내 문서에 대해 질문하면, 모델은 학습 데이터에 없는 내용을 그럴듯하게 만들어냅니다. 이 문제를 해결하는 두 가지 접근이 있습니다.

• 방법 A: 질문할 때마다 관련 문서를 찾아서 모델에게 "이걸 참고해서 답해"라고 전달 → RAG
• 방법 B: 우리 데이터로 모델을 추가 학습시켜서 모델 자체가 알게 만듦 → Fine-tuning

두 방식은 목적이 다릅니다. RAG는 "모델이 모르는 지식을 실시간으로 제공"하는 것이고, Fine-tuning은 "모델의 행동 방식을 변경"하는 것입니다.

예를 들어 이런 상황을 생각해 봅니다.

상황	적합한 방식	이유
사내 HR 정책을 질문-답변으로 제공하고 싶다	RAG	정책이 수시로 변경되고, 출처를 보여줘야 함
고객 응대 시 우리 회사 톤으로 답변하게 하고 싶다	Fine-tuning	응답 스타일/형식을 학습시켜야 함
의료 논문 기반으로 질문에 답하게 하고 싶다	RAG + Fine-tuning	최신 논문 검색(RAG) + 의료 용어 이해(Fine-tuning)

2. 동작 원리 비교

RAG와 Fine-tuning 동작 원리 비교

2.1 RAG 동작 원리

RAG(Retrieval-Augmented Generation)는 모델을 변경하지 않고, 질문 시점에 관련 문서를 검색하여 프롬프트의 컨텍스트로 제공합니다.

[사용자 질문] → [문서 검색] → [검색 결과 + 질문을 프롬프트로 조합] → [LLM 응답 생성]

핵심 특징: - 모델 가중치(weight)를 변경하지 않습니다. - 지식은 외부 저장소(Vector DB)에 있고, 질문마다 검색합니다. - 문서를 추가/수정하면 즉시 반영됩니다. - 응답에 출처를 명시할 수 있습니다.

2.2 Fine-tuning 동작 원리

Fine-tuning은 사전 학습된 모델에 추가 데이터를 학습시켜 모델의 가중치를 조정합니다.

[학습 데이터 준비] → [모델 추가 학습] → [새 모델 배포] → [추론 시 학습된 지식/행동 반영]

핵심 특징: - 모델 가중치가 변경됩니다. - 학습된 지식은 모델 내부에 녹아들어 있습니다. - 지식 업데이트 시 재학습이 필요합니다. - 응답의 출처를 추적할 수 없습니다.

2.3 핵심 차이: 지식 vs 행동

구분	RAG	Fine-tuning
변경 대상	프롬프트 (입력)	모델 가중치 (내부)
비유	시험 볼 때 참고 자료를 보는 것	시험 전에 공부해서 외우는 것
지식 위치	외부 저장소	모델 내부
업데이트	문서 추가/수정	재학습

3. 선택 기준: 의사결정 플로우차트

RAG vs Fine-tuning 선택 기준 의사결정 흐름

3.1 RAG를 선택하는 경우

• 지식이 자주 변경됩니다 (제품 문서, 정책, 가격표 등).
• 응답에 출처를 명시해야 합니다 (규제 요건, 신뢰성).
• 대량의 문서를 기반으로 답변해야 합니다.
• 모델 학습 인프라가 없거나 비용을 줄이고 싶습니다.
• 데이터가 민감하여 외부 학습 서비스에 보내기 어렵습니다.

3.2 Fine-tuning을 선택하는 경우

• 특정 도메인의 언어 패턴을 학습시켜야 합니다 (의료, 법률, 금융 용어).
• 응답 형식이나 톤을 일관되게 제어해야 합니다.
• 추론 시 지연 시간을 줄여야 합니다 (검색 단계 제거).
• 모델이 특정 작업(분류, 요약, 코드 생성 등)에 특화되어야 합니다.
• 프롬프트 길이 제한으로 충분한 컨텍스트를 제공할 수 없습니다.

3.3 결합하는 경우

• Fine-tuning으로 도메인 언어와 응답 형식을 학습시키고, RAG로 최신 지식을 제공합니다.
• 예: 의료 AI 어시스턴트 — Fine-tuning으로 의학 용어와 진단 형식을 학습, RAG로 최신 논문과 가이드라인을 검색.

4. 상세 비교

RAG와 Fine-tuning 비교 요약

4.1 비용 비교

항목	RAG	Fine-tuning
초기 구축 비용	검색 파이프라인 + Vector DB 구축	학습 데이터 준비 + GPU 학습 비용
운영 비용	검색 쿼리 + LLM 호출 (토큰 많음)	LLM 호출 (토큰 적음, 검색 없음)
지식 업데이트 비용	문서 재인덱싱 (저렴)	모델 재학습 (고비용)
인프라	Vector DB + Embedding API	GPU 클러스터 또는 학습 서비스

비용 관점에서의 판단: - 지식이 자주 변경되면 RAG가 유리합니다. Fine-tuning은 변경마다 재학습 비용이 발생합니다. - 호출량이 매우 많고 검색 결과가 길면, Fine-tuning으로 검색 단계를 제거하는 것이 토큰 비용을 줄일 수 있습니다. - 소규모 팀이라면 RAG가 진입 장벽이 낮습니다. Fine-tuning은 학습 데이터 준비에 상당한 노력이 필요합니다.

4.2 운영 복잡도 비교

항목	RAG	Fine-tuning
데이터 파이프라인	문서 수집 → Chunking → Embedding → 저장	학습 데이터 수집 → 정제 → 포맷팅
업데이트 주기	실시간~일 단위	주~월 단위
품질 관리	검색 품질 모니터링 + 응답 평가	학습 데이터 품질 관리 + 모델 평가
장애 포인트	Vector DB, Embedding API, LLM API	학습 인프라, 모델 서빙
롤백	문서 버전 관리로 가능	이전 모델 버전으로 롤백

4.3 품질 비교

항목	RAG	Fine-tuning
Hallucination	검색 품질에 의존 (좋은 검색 = 낮은 환각)	학습 데이터 품질에 의존
출처 추적	가능 (검색된 문서를 출처로 제시)	불가능 (모델 내부에 녹아듦)
응답 일관성	검색 결과에 따라 변동 가능	학습된 패턴으로 일관된 응답
도메인 전문성	검색된 문서 수준에 의존	모델 자체가 도메인 전문가
최신성	문서 업데이트로 즉시 반영	재학습 전까지 반영 불가

4.4 보안 비교

항목	RAG	Fine-tuning
데이터 노출 위험	검색된 문서가 프롬프트에 포함 → LLM API로 전송	학습 데이터가 학습 서비스로 전송
접근 제어	검색 시 사용자 권한 기반 필터링 가능	모델에 학습된 지식은 모든 사용자에게 노출
Prompt Injection	검색된 문서에 악의적 지시가 포함될 수 있음	학습 데이터 오염(Data Poisoning) 위험
규제 대응	문서 단위로 삭제/수정 가능 (GDPR 등)	특정 지식만 제거하기 어려움 (재학습 필요)

5. 실무 시나리오별 선택 가이드

시나리오 1: 사내 문서 검색 시스템

상황: 직원 500명, 사내 문서 10,000건, 매주 100건 이상 업데이트.

선택: RAG

이유: - 문서가 자주 변경되므로 재학습 비용이 비현실적입니다. - 부서별 접근 권한이 다르므로 검색 시 필터링이 필요합니다. - 답변에 출처 문서 링크를 제공해야 합니다. - 문서 추가만으로 즉시 새 지식을 반영할 수 있습니다.

시나리오 2: 고객 응대 챗봇 (특정 톤/형식)

상황: 이커머스 회사, 고객 문의에 브랜드 톤으로 답변, 반품/교환/배송 관련 정형화된 응답 필요.

선택: RAG + Fine-tuning 결합

이유: - Fine-tuning: 브랜드 톤, 응답 형식(인사 → 확인 → 안내 → 마무리), 금지 표현을 학습시킵니다. - RAG: 최신 반품 정책, 배송 일정, 프로모션 정보를 실시간으로 검색합니다. - Fine-tuning만으로는 정책 변경을 즉시 반영할 수 없고, RAG만으로는 일관된 톤을 보장하기 어렵습니다.

시나리오 3: 코드 리뷰 자동화

상황: 사내 코딩 컨벤션에 맞춰 PR을 자동 리뷰하는 시스템.

선택: Fine-tuning

이유: - 코딩 컨벤션은 자주 변경되지 않습니다. - "이 패턴은 우리 팀에서 금지", "이 경우 이렇게 작성해야 함" 같은 판단 기준을 모델에 학습시킵니다. - 매 리뷰마다 컨벤션 문서를 검색하는 것보다, 모델이 내재화하는 것이 응답 속도와 일관성 면에서 유리합니다.

시나리오 4: 법률 문서 분석

상황: 법률 사무소, 판례와 법령을 기반으로 질문에 답변.

선택: RAG + Fine-tuning 결합

이유: - Fine-tuning: 법률 용어, 판례 인용 형식, 논증 구조를 학습시킵니다. - RAG: 최신 판례, 개정 법령을 검색하여 제공합니다. - 출처(판례 번호, 법령 조항)를 반드시 명시해야 하므로 RAG가 필수입니다.

6. Fine-tuning 실무 고려사항

6.1 학습 데이터 준비

Fine-tuning의 품질은 학습 데이터 품질에 직접적으로 의존합니다.

항목	권장 기준
데이터 양	최소 수백~수천 건 (작업 복잡도에 따라 다름)
데이터 형식	입력-출력 쌍 (instruction-response)
품질 관리	중복 제거, 모순 제거, 형식 통일
다양성	다양한 질문 유형과 엣지 케이스 포함

6.2 학습 방식 비교

방식	설명	비용	적합한 경우
Full Fine-tuning	모든 파라미터를 업데이트	매우 높음 (대형 GPU 필요)	대규모 도메인 전환
LoRA/QLoRA	일부 파라미터만 업데이트	낮음 (단일 GPU 가능)	대부분의 실무 사례
API 기반 Fine-tuning	OpenAI, Anthropic 등 서비스 활용	중간 (API 과금)	인프라 없는 팀

운영 환경에서는 LoRA/QLoRA가 비용 대비 효과가 좋아 많이 사용됩니다. Full Fine-tuning 대비 90~95% 수준의 품질을 유지하면서 메모리와 비용을 크게 절감할 수 있습니다. 다만 특정 작업에서는 Full Fine-tuning과 다른 결과를 보일 수 있으므로, 평가 후 판단해야 합니다.

6.3 Fine-tuning의 한계

• Catastrophic Forgetting: 새 데이터를 학습하면 기존에 알던 지식을 잊을 수 있습니다.
• 과적합(Overfitting): 학습 데이터가 적으면 특정 패턴에만 맞춰져 일반화 능력이 떨어집니다.
• 지식 제거 어려움: 잘못 학습된 정보를 특정해서 제거하기 어렵습니다. 재학습이 필요합니다.
• 평가 어려움: "모델이 정말 도메인을 이해했는가"를 정량적으로 평가하기 어렵습니다.

7. 비용/운영 고려사항

주의
RAG와 Fine-tuning 모두 초기 구축보다 운영 비용이 더 클 수 있습니다. 트래픽 증가에 따른 비용 예측과 최적화 전략을 초기에 설계해야 합니다.

7.1 RAG 비용 구조 (월 기준 예시)

구성 요소	예상 비용	비고
Embedding 생성	$10~50	문서 10,000건 초기 인덱싱 + 일일 업데이트
Vector DB	$50~200	Pinecone Serverless 또는 OpenSearch Serverless
LLM 호출	$100~1,000+	일 1,000건 질문 기준, 모델에 따라 차이 큼
총 운영비	$160~1,250+	트래픽에 비례하여 증가

7.2 Fine-tuning 비용 구조

구성 요소	예상 비용	비고
학습 데이터 준비	인건비 (수일~수주)	데이터 수집, 정제, 포맷팅
모델 학습	$50~5,000+	LoRA: $50~200, Full: $1,000~5,000+
모델 서빙	$200~2,000+/월	GPU 인스턴스 또는 API 서비스
재학습 주기	월 1~2회	지식 업데이트 시마다

7.3 비용 최적화 전략

RAG 비용 최적화: - 응답 캐싱으로 동일 질문에 대한 LLM 호출을 줄입니다. - 간단한 질문은 작은 모델로 라우팅합니다. - Chunk 수(Top-K)를 최적화하여 불필요한 토큰을 줄입니다.

Fine-tuning 비용 최적화: - LoRA/QLoRA로 학습 비용을 줄입니다. - 증분 학습(Incremental Learning)으로 전체 재학습을 피합니다. - 모델 양자화(Quantization)로 서빙 비용을 줄입니다.

8. 보안 고려사항

Security Note
RAG와 Fine-tuning 모두 민감 데이터를 다루는 경우 데이터 유출 위험을 설계 단계에서 고려해야 합니다. 두 방식의 보안 위협 모델이 다르므로 각각에 맞는 대응이 필요합니다.

RAG 보안 위협과 대응

위협	설명	대응
데이터 유출	검색된 문서가 외부 LLM API로 전송	VPC 내 모델 배포 (Bedrock, Azure OpenAI)
권한 우회	사용자가 볼 수 없는 문서가 검색됨	메타데이터 기반 접근 제어 필터링
Prompt Injection	악의적 질문으로 시스템 프롬프트 유출	입력 검증 + 출력 필터링
Indirect Injection	인덱싱된 문서에 악의적 지시 포함	문서 수집 시 검증 파이프라인

Fine-tuning 보안 위협과 대응

위협	설명	대응
학습 데이터 유출	모델이 학습 데이터를 그대로 출력	학습 데이터에서 PII 제거, 출력 필터링
Data Poisoning	악의적 데이터로 모델 행동 조작	학습 데이터 검증, 이상 탐지
지식 제거 불가	GDPR 삭제 요청 시 특정 지식 제거 어려움	민감 데이터는 학습 대상에서 제외
모델 탈취	Fine-tuned 모델 자체가 유출	모델 접근 제어, 서빙 환경 격리

9. 자주 하는 실수

1. "Fine-tuning하면 모델이 우리 데이터를 다 알게 된다"는 오해: Fine-tuning은 행동 패턴을 학습시키는 것이지, 대량의 사실 정보를 기억시키는 데는 적합하지 않습니다. 사실 기반 질의응답에는 RAG가 더 적합합니다.
2. RAG 없이 Fine-tuning만으로 최신 정보를 제공하려는 시도: 정보가 변경될 때마다 재학습해야 하므로 비용과 시간이 비현실적으로 증가합니다.
3. RAG의 검색 품질을 무시하고 LLM 모델만 업그레이드하는 것: RAG 시스템에서 응답 품질의 80%는 검색 품질이 결정합니다. 모델을 바꾸기 전에 검색 파이프라인을 개선하는 것이 효과적입니다.
4. Fine-tuning 학습 데이터를 충분히 검증하지 않는 것: 잘못된 데이터가 포함되면 모델이 잘못된 패턴을 학습합니다. 학습 후에는 제거가 어려우므로 사전 검증이 중요합니다.
5. 두 방식의 결합을 고려하지 않는 것: 많은 실무 사례에서 RAG + Fine-tuning 결합이 단일 방식보다 좋은 결과를 보입니다. 처음부터 양자택일로 접근하면 최적 설계를 놓칠 수 있습니다.

10. 정리

• RAG는 "모델이 무엇을 알아야 하는가(지식)"를 해결하고, Fine-tuning은 "모델이 어떻게 답해야 하는가(행동)"를 해결합니다.
• 자주 변경되는 지식, 출처 추적이 필요한 경우, 접근 제어가 필요한 경우에는 RAG를 선택합니다.
• 도메인 언어 학습, 응답 형식 제어, 추론 지연 시간 최소화가 필요한 경우에는 Fine-tuning을 선택합니다.
• 운영 환경에서는 두 방식을 결합하는 것이 일반적이며, 요구사항에 따라 비중을 조정합니다.
• 선택 시 비용, 운영 복잡도, 데이터 보안 요건, 업데이트 빈도를 종합적으로 고려해야 합니다.

관련 글

• RAG란 무엇인가: LLM 애플리케이션 아키텍처 관점에서 이해하기
• Multi-modal RAG: 이미지와 테이블을 포함한 문서 검색 구현

참고 문서

• OpenAI 공식 문서: Fine-tuning
• AWS 공식 문서: Retrieval-Augmented Generation (RAG)
• Anthropic 공식 문서: Fine-tuning
• Google Cloud 공식 문서: Vertex AI Model Tuning