이 글은 누구를 위한 것인가
- LLM을 서비스에 적용하려는데 파인튜닝과 RAG 중 무엇을 선택할지 결정하지 못한 팀
- RAG를 구축했지만 응답 품질이 기대에 못 미쳐 파인튜닝을 검토 중인 엔지니어
- 비용과 유지보수 부담 없이 도메인 특화 LLM을 만들고 싶은 ML 엔지니어
두 접근의 근본적 차이
파인튜닝과 RAG는 서로 다른 문제를 해결한다. 이 차이를 이해하면 선택이 쉬워진다.
| 파인튜닝 (Fine-tuning) | RAG | |
|---|---|---|
| 해결하는 문제 | 모델의 행동 방식 변경 | 모델의 지식 범위 확장 |
| 변경 위치 | 모델 가중치 | 검색 컨텍스트 |
| 업데이트 방식 | 재학습 필요 | 문서 추가로 즉시 반영 |
| 지식 유형 | 스타일, 포맷, 도메인 언어 | 최신 사실, 내부 문서, DB |
| 데이터 요구 | 수백~수만 개 학습 예제 | 원본 문서 |
한 문장으로 요약하면: "어떻게 말하는가"는 파인튜닝, "무엇을 말하는가"는 RAG다.
RAG를 선택해야 하는 경우
다음 조건 중 하나라도 해당하면 RAG를 먼저 시도해야 한다.
지식이 자주 바뀐다
내부 정책 문서, 제품 카탈로그, 법령, 뉴스 — 이런 정보는 주 단위 또는 일 단위로 바뀐다. 파인튜닝은 재학습 없이 이 변화를 반영할 수 없다. 문서를 업데이트하면 즉시 반영되는 RAG가 적합하다.
출처 추적이 필요하다
"이 답변의 근거가 어디 있는가"를 보여줘야 하는 서비스 — 법률, 의료, 금융 — 는 RAG가 유리하다. 검색된 청크를 함께 반환하면 인용 출처를 자동으로 제공할 수 있다.
학습 데이터가 없다
고품질 파인튜닝 데이터셋을 만드는 비용은 생각보다 크다. instruction-answer 쌍 500개를 만드는 데도 도메인 전문가의 상당한 시간이 필요하다. 문서만 있다면 RAG로 빠르게 프로토타입을 만들고 검증할 수 있다.
할루시네이션 리스크를 최소화해야 한다
RAG는 모델이 생성할 때 실제 문서를 참조하기 때문에, 잘 설계된 RAG는 모델이 지식 경계 밖의 내용을 창작하는 것을 억제한다. 파인튜닝된 모델은 여전히 학습 데이터에 없는 것을 그럴듯하게 지어낼 수 있다.
파인튜닝이 필요한 경우
파인튜닝은 모델의 행동과 스타일을 바꿔야 할 때 진가를 발휘한다.
특수한 출력 포맷이 필요하다
JSON 스키마를 항상 준수하는 구조화된 출력, 특정 의료 기록 양식, 사내 코딩 컨벤션을 반영한 코드 생성 — 프롬프트 엔지니어링만으로는 일관성을 보장하기 어렵다. 파인튜닝은 이 일관성을 모델 가중치에 구워 넣는다.
도메인 전용 언어/용어를 사용한다
반도체 FAB 공정 용어, 특정 법원의 문서 작성 관행, 특수 의학 분과의 약어 — 사전학습 모델이 잘 모르는 도메인 언어는 파인튜닝이 효과적이다.
모델 크기와 비용을 줄이고 싶다
GPT-4 급 모델을 매 요청마다 호출하는 것이 비용 부담이라면, 도메인에 특화된 소형 모델(7B~13B)을 파인튜닝해 동일한 품질을 훨씬 저렴하게 제공할 수 있다.
응답 톤/페르소나가 중요하다
브랜드 보이스를 일관되게 유지하는 고객 서비스 봇, 아동 교육 플랫폼의 친근한 어시스턴트 — 이 특성은 프롬프트로 주입해도 되지만, 파인튜닝이 훨씬 강건한 일관성을 제공한다.
비용·지연시간·유지보수 비교
초기 구축 비용
| 항목 | RAG | 파인튜닝 (LoRA, 7B 모델) |
|---|---|---|
| 데이터 준비 | 문서 수집·청킹·임베딩 | instruction-answer 쌍 수백~수천 개 |
| 인프라 | 벡터 DB, 임베딩 API | GPU 서버 (A100 기준 ~$2/hr) |
| 학습 시간 | 없음 | 7B 모델 1,000 샘플 기준 약 1~3시간 |
| 개발 기간 | 수일~2주 | 2~6주 (데이터 큐레이션 포함) |
운영 비용 (월간 1M 요청 기준 추정)
| 항목 | RAG (클라우드 LLM) | 파인튜닝 (자체 호스팅) |
|---|---|---|
| LLM 호출 비용 | 높음 (토큰 수 ↑) | 낮음 (전용 서버) |
| 벡터 DB | 중간 | 없음 |
| 유지보수 | 문서 업데이트 | 재학습 주기 관리 |
| 총 비용 추세 | 요청 수에 비례 | 고정 인프라 비용 중심 |
트래픽이 낮으면 RAG + 클라우드 LLM이 유리하다. 트래픽이 높고 지식이 안정적이라면 파인튜닝 + 자체 호스팅이 장기적으로 저렴하다.
지연시간
RAG는 검색 단계가 추가된다. 잘 최적화해도 벡터 검색 + LLM 호출의 합산 지연이 발생한다. 파인튜닝된 모델은 검색 단계가 없으므로 실시간 응답이 중요한 서비스에서 유리하다.
LoRA vs QLoRA: 파인튜닝 방법 선택
전체 모델 가중치를 재학습하는 Full Fine-tuning은 대부분의 팀에게 비현실적이다. LoRA와 QLoRA가 실질적인 선택지다.
LoRA (Low-Rank Adaptation)
원본 가중치를 고정하고 소수의 추가 행렬만 학습한다. 학습 가능한 파라미터가 전체의 1~5%에 불과하지만, 많은 태스크에서 Full Fine-tuning에 근접한 성능을 낸다.
- GPU 메모리: 7B 모델 기준 약 16~24GB VRAM
- 적합한 경우: A100/H100이 있고 빠른 학습이 필요할 때
QLoRA (Quantized LoRA)
4-bit 양자화로 원본 모델을 압축한 뒤 LoRA를 적용한다. 메모리 사용량을 획기적으로 줄인다.
- GPU 메모리: 7B 모델 기준 약 6~10GB VRAM (소비자용 GPU 가능)
- 적합한 경우: 제한된 GPU 환경, RTX 3090/4090으로 실험할 때
- 주의: LoRA 대비 학습 속도가 느리고 미세한 성능 손실이 있을 수 있음
실용 지침:
- A100 이상이 있고 품질이 우선이면 → LoRA
- 소비자급 GPU나 비용 제한이 있으면 → QLoRA
- 70B+ 모델을 쓰고 싶다면 → QLoRA만 현실적
하이브리드 전략: RAG + 파인튜닝
두 접근은 상호 배타적이지 않다. 실제로 가장 강력한 시스템은 둘을 결합한다.
언제 하이브리드를 쓰는가
- 스타일은 파인튜닝, 지식은 RAG: 도메인 언어와 포맷은 파인튜닝으로 모델에 학습시키고, 최신 문서 기반 답변은 RAG로 제공한다
- RAG 성능을 높이기 위한 파인튜닝: 일반 LLM이 검색 결과를 잘 활용하지 못할 때, RAG 컨텍스트를 처리하는 방식을 파인튜닝으로 개선할 수 있다 (RAG-aware fine-tuning)
- 임베딩 모델 파인튜닝: 검색 품질이 문제라면 도메인 텍스트로 임베딩 모델 자체를 파인튜닝하는 것이 LLM 파인튜닝보다 효과적일 수 있다
의사결정 플로우
문제가 무엇인가?
│
├─ 모델이 "올바른 방식으로" 말하지 않는다
│ (포맷, 톤, 도메인 언어 문제)
│ └─▶ 파인튜닝
│
├─ 모델이 "최신 정보를 모른다"
│ (사실, 문서, 내부 지식 문제)
│ └─▶ RAG
│
├─ 둘 다 문제다
│ └─▶ RAG 먼저 구축 → 스타일 문제가 남으면 파인튜닝 추가
│
└─ 아직 모른다
└─▶ RAG로 프로토타입 → 실제 실패 케이스 수집 → 재평가
원칙: RAG가 기본값이다. 파인튜닝은 RAG만으로 해결되지 않는 구체적인 문제가 식별된 뒤에 시작하는 것이 바람직하다. 파인튜닝 데이터를 만드는 비용과 재학습 주기 관리 비용을 과소평가하지 마라.
운영 중 평가 지표
| 지표 | RAG | 파인튜닝 |
|---|---|---|
| 응답 정확도 | Groundedness, Context Precision | Task-specific accuracy |
| 검색 품질 | Recall@K, MRR | N/A |
| 지식 최신성 | 문서 업데이트 후 즉시 반영 확인 | 재학습 전후 비교 |
| 응답 일관성 | 동일 쿼리 반복 실행 | 동일 쿼리 반복 실행 |
| 비용 | 토큰 비용 추적 | GPU 사용률·학습 비용 |
맺으며
2026년 현재 대부분의 팀에게 현실적인 출발점은 RAG다. 클라우드 LLM의 품질이 높아지고 벡터 DB 비용이 낮아진 지금, RAG는 몇 주 안에 검증 가능한 시스템을 만들 수 있다.
파인튜닝이 의미 있는 경우는 "모델이 어떻게 말해야 하는가"에 명확한 요구가 있고, 그것을 프롬프트로 해결하려는 시도가 이미 실패했을 때다. 파인튜닝을 시작하기 전에 실제 실패 케이스 100개를 수집하고, 그 원인이 지식 부족인지 행동 패턴인지부터 분류하는 것을 권장한다.