LLM을 제품에 적용할 때 가장 먼저 마주치는 갈림길은 파인튜닝(Fine-tuning)과 RAG(검색 증강 생성) 중 어느 방향으로 갈 것인지입니다. 둘 다 “모델이 모르는 정보를 다루게 한다”는 목표를 공유하는 것처럼 보이지만, 작동 원리와 비용 구조, 유지보수 부담이 전혀 다릅니다. 잘못 선택하면 수백만 원의 GPU 비용을 쏟아붓고도 며칠 뒤 업데이트된 데이터 때문에 처음부터 다시 해야 하거나, 반대로 RAG를 고집하다가 모델이 조직의 글쓰기 스타일을 끝내 따라오지 못하는 상황이 생깁니다. 이 글은 두 기법의 차이를 구조적으로 정리하고, 어떤 조건에서 어느 쪽을 택해야 하는지 실무 기준으로 설명합니다.
파인튜닝과 RAG, 무엇이 다른가
파인튜닝은 사전 학습된 LLM의 가중치를 추가 학습 데이터로 업데이트해 모델 자체를 변형하는 방법입니다. 학습이 끝나면 모델 파라미터 안에 새로운 지식이나 행동 패턴이 녹아들어, 추론 시점에 외부 자료를 따로 공급하지 않아도 됩니다. 2022년 마이크로소프트 연구팀이 발표한 LoRA(Low-Rank Adaptation)는 전체 가중치를 건드리지 않고 저랭크 행렬만 학습시켜 파인튜닝 비용을 크게 낮췄으며, 현재 파인튜닝의 사실상 표준 기법으로 자리잡고 있습니다(Hu et al., ICLR 2022).
RAG는 모델 가중치를 바꾸지 않습니다. 대신 쿼리가 들어오면 외부 벡터 데이터베이스나 검색 엔진에서 관련 문서를 실시간으로 꺼내, 그것을 컨텍스트에 함께 주입해 모델이 답변을 생성하게 합니다. Facebook AI Research 팀이 2020년 NeurIPS에서 “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”로 개념을 공식화했으며(Lewis et al., 2020), 이후 LangChain·LlamaIndex 같은 프레임워크가 보급되면서 현재 실무에서 가장 널리 쓰이는 LLM 활용 패턴이 됐습니다.
| 구분 | 파인튜닝 | RAG |
|---|---|---|
| 지식 주입 방식 | 모델 가중치에 내재화 | 추론 시 컨텍스트로 공급 |
| 데이터 업데이트 | 재학습 필요 (시간·비용 발생) | 검색 DB만 교체하면 즉시 반영 |
| 적용 난이도 | 데이터 수집·학습 파이프라인 필요 | 임베딩 파이프라인 + 벡터 DB |
| 추론 지연 | 추가 지연 없음 | 검색 시간 + 컨텍스트 길이 증가 |
| 출처 추적 | 어렵고 불투명 | 검색 결과 문서 직접 노출 가능 |
| 환각(Hallucination) | 줄일 수 있지만 완전 제거 불가 | 출처 기반이라 상대적으로 적음 |
| 스타일·톤 적응 | 강점 (패턴 학습) | 약점 (프롬프트로 유도해야 함) |
언제 파인튜닝을 선택해야 하는가
파인튜닝이 진정한 강점을 발휘하는 영역은 “지식 추가”보다 “행동 패턴 교정”에 가깝습니다. 모델이 특정 출력 형식을 반드시 따라야 하거나, 조직 특유의 문체·어조·용어 체계를 일관되게 사용해야 할 때, 프롬프트 엔지니어링만으로는 한계가 있습니다. 수백 개의 입출력 예시를 학습시키면 모델이 그 패턴을 내면화해 매번 긴 지시 없이도 원하는 스타일로 응답합니다.
또한 추론 비용이 중요한 고빈도 서비스에서도 파인튜닝이 유리합니다. RAG는 매 요청마다 검색 + 긴 컨텍스트를 처리하지만, 파인튜닝된 소형 모델은 짧은 입력으로도 필요한 답변을 낼 수 있기 때문입니다. 고객센터 분류, 정형 데이터 추출, 도메인 특화 코드 자동완성처럼 입출력 패턴이 고정적이고 요청 수가 많은 경우에 파인튜닝 + 소형 모델 조합이 장기적으로 더 경제적입니다.
- 조직 특유의 문체·어조·용어 체계를 일관되게 유지해야 하는 경우
- 모델 출력이 엄격한 JSON·XML 등 특정 포맷을 항상 따라야 하는 경우
- 도메인 특화 전문용어나 略語(약어)가 많아 기반 모델이 자주 오류를 내는 경우
- 하루 수만 건 이상 고빈도 요청이 발생해 장기 추론 비용을 최소화해야 하는 경우
- 입출력 예시(학습 데이터)가 수백 쌍 이상 확보된 경우
언제 RAG를 선택해야 하는가
RAG가 압도적으로 유리한 상황은 데이터가 자주 바뀌거나, 최신 정보를 모델이 반드시 알아야 하는 경우입니다. 파인튜닝은 학습 데이터가 모델에 고정되는 순간 이후의 변경사항을 반영하려면 재학습이 필요합니다. 반면 RAG는 검색 DB를 업데이트하는 것만으로 모델이 즉시 새로운 정보를 사용할 수 있습니다. 법령, 제품 스펙, 사내 문서, 뉴스 등 살아 움직이는 데이터를 다루는 서비스에는 RAG가 기본 선택지입니다.
출처 투명성도 RAG의 핵심 강점입니다. 사용자가 “이 정보 어디서 나왔어요?”라고 물었을 때 참고 문서를 직접 보여줄 수 있다는 점은 법률·의료·금융 도메인처럼 신뢰성과 감사 추적이 중요한 영역에서 결정적인 차이를 만듭니다. Anthropic은 2024년 발표한 Contextual Retrieval 기법에서 BM25 키워드 검색과 임베딩 벡터 검색을 결합하는 하이브리드 방식으로 리콜(recall)을 크게 높일 수 있음을 보였습니다.
- 데이터가 주·월 단위 이상으로 자주 바뀌어 재학습 주기를 따라가기 어려운 경우
- 수만 페이지 이상의 대규모 문서에서 정확한 내용을 찾아 답변해야 하는 경우
- 답변 근거 문서를 사용자에게 직접 노출해야 하는 경우 (법률·의료·컴플라이언스)
- 학습 데이터가 충분하지 않거나 라벨링 작업 리소스가 없는 초기 단계
- 여러 도메인의 지식을 동시에 커버해야 하는 범용 지식 기반 서비스
비용 비교 — 학습 비용 vs 운영 비용
두 방법의 비용 구조는 근본적으로 다릅니다. 파인튜닝은 초기 학습 비용이 크고 추론 비용은 낮은 구조이며, RAG는 학습 비용 없이 운영을 시작하지만 추론마다 검색·긴 컨텍스트 비용이 누적됩니다. 어떤 쪽이 저렴한지는 월간 요청 수와 컨텍스트 길이에 따라 역전됩니다.
소형 모델(7B~13B)을 LoRA로 파인튜닝하는 경우 A100 80GB GPU 기준 수 시간~수십 시간이 소요되며, 클라우드 비용으로 수십만 원 선에서 시작됩니다. GPT-4o mini처럼 API 기반 파인튜닝은 토큰 단가가 사전 학습 비용에 반영돼 학습 자체는 저렴하지만 파인튜닝된 모델을 호출할 때 단가 프리미엄이 붙는 구조입니다(OpenAI 파인튜닝 공식 문서 참고, 2026년 기준 정책·단가는 변동될 수 있음). RAG는 임베딩 비용과 벡터 DB 호스팅 비용, 매 요청마다 컨텍스트에 실리는 문서 토큰 비용이 합산됩니다.
| 비용 항목 | 파인튜닝 (LoRA 소형 모델 기준) | RAG (API 모델 기준) |
|---|---|---|
| 초기 구축 비용 | GPU 학습 비용 (수십만~수백만 원) | 임베딩 파이프라인 + 벡터 DB 설정 |
| 데이터 업데이트 비용 | 재학습 시 GPU 비용 재발생 | 문서 재임베딩만 (상대적으로 저렴) |
| 추론 단가 | 낮음 (소형 모델, 짧은 컨텍스트) | 검색 비용 + 긴 컨텍스트 입력 토큰 |
| 월 1만 건 요청 시 | 모델 호스팅 고정비 위주 | 검색 + LLM 호출 합산 (변동비) |
| 월 100만 건 요청 시 | 소형 모델이면 RAG 대비 유리 | 컨텍스트 비용 누적으로 불리할 수 있음 |
| 손익분기 기준 (일반적) | 고빈도·고정 패턴에 유리 | 저빈도·가변 데이터에 유리 |
파인튜닝은 “저장된 지식”을 최신 상태로 유지하는 비용을 과소평가하기 쉽습니다.
모델을 한 번 학습시켜 놓으면 끝이 아닙니다. 제품 스펙이 바뀌고, 정책이 개정되고, 새로운 사례가 쌓이면 재학습해야 합니다. 데이터 변경 주기가 월 1회 이상이라면, 파인튜닝의 총 소유 비용(TCO)은 초기 비용보다 운영 단계의 재학습 누적 비용이 훨씬 클 수 있습니다.
선택 기준 플로차트
다음 질문에 순서대로 답하면 방향이 결정됩니다
- 데이터가 월 1회 이상 바뀌는가?
→ 예: RAG 우선 검토 / 아니오: 2번으로 - 출처 문서를 사용자에게 직접 보여줘야 하는가?
→ 예: RAG / 아니오: 3번으로 - 특정 출력 형식이나 문체를 일관되게 강제해야 하는가?
→ 예: 파인튜닝 검토 / 아니오: 4번으로 - 하루 1만 건 이상의 고빈도 요청이 예상되는가?
→ 예: 파인튜닝 + 소형 모델 비용 분석 / 아니오: 5번으로 - 학습용 입출력 예시가 500쌍 이상 확보됐는가?
→ 예: 파인튜닝 고려 가능 / 아니오: RAG로 시작 후 데이터 축적
위 흐름에서 핵심은 RAG로 시작해서 파인튜닝으로 보완하는 순서가 대부분의 프로젝트에서 더 안전하다는 점입니다. RAG는 별도 학습 없이 빠르게 프로토타입을 만들 수 있고, 어디서 실패하는지 실제 데이터로 관찰할 수 있습니다. 그 실패 패턴(반복되는 오류, 부정확한 포맷, 특정 표현의 불일치)이 쌓이면 그것이 파인튜닝의 학습 데이터가 됩니다.
하이브리드 전략 — 파인튜닝과 RAG를 함께 쓰는 경우
상용 AI 제품 중 상당수는 파인튜닝된 모델 위에 RAG를 얹는 하이브리드 구조를 사용합니다. 파인튜닝으로 모델이 도메인의 어휘·형식·어조를 체화하게 하고, RAG로 최신 정보와 긴 문서를 실시간 공급하는 방식입니다. 두 기법의 단점을 상호 보완하는 구조입니다.
예를 들어 법률 AI 서비스라면, 법률 문서 문체와 형식을 파인튜닝으로 학습시키고, 실제 판례와 법령 조문은 RAG로 매번 꺼내 오는 식입니다. 이렇게 하면 파인튜닝만 쓸 때의 “정보 진부화” 문제와 RAG만 쓸 때의 “어색한 어투” 문제를 동시에 해결할 수 있습니다.
| 서비스 유형 | 권장 전략 | 이유 |
|---|---|---|
| 사내 문서 QA 챗봇 | RAG 단독 | 문서 업데이트 잦음, 출처 투명성 중요 |
| 고객센터 자동 분류 | 파인튜닝 단독 | 고정 패턴, 고빈도, 포맷 일관성 필요 |
| 법률·의료 자문 보조 | 파인튜닝 + RAG | 전문 문체 + 최신 법령·지침 실시간 반영 |
| 뉴스 요약 서비스 | RAG 단독 | 데이터가 실시간으로 변함 |
| 도메인 특화 코드 생성 | 파인튜닝 우선 | API·라이브러리 패턴 고정, 형식 엄격 |
| 지식 기반 제품 추천 | RAG 우선 후 하이브리드 검토 | 카탈로그 변경 빈번, 초기엔 RAG로 속도 |
흔한 실패 패턴
파인튜닝의 실패 패턴
데이터 오염(data contamination)은 가장 흔한 원인입니다. 학습 데이터에 오류가 있는 예시, 레이블 불일치, 원치 않는 포맷이 섞이면 모델이 잘못된 행동을 학습합니다. 특히 크롤링으로 자동 수집한 데이터를 검수 없이 학습에 쓰는 경우에 자주 발생합니다. 학습 전 데이터 품질 검수가 파인튜닝 성패의 70%를 결정한다고 해도 과언이 아닙니다.
과적합(overfitting)도 주의해야 합니다. 학습 데이터가 너무 적거나 에폭(epoch)을 너무 많이 돌리면 모델이 학습 예시를 암기해 다른 입력에 일반화하지 못합니다. 소규모 데이터셋(수백 쌍)에서 LoRA를 쓸 때는 에폭 수를 보수적으로 유지하고 검증 손실을 반드시 모니터링해야 합니다.
RAG의 실패 패턴
검색 실패(retrieval failure)가 전체 파이프라인을 무너뜨립니다. 모델이 아무리 뛰어나도 검색 단계에서 관련 문서를 꺼내오지 못하면 좋은 답변이 나올 수 없습니다. 청킹(chunking) 전략이 잘못돼 문서 경계가 의미 단위를 잘라내거나, 임베딩 모델이 도메인에 맞지 않아 관련도 계산이 부정확한 경우에 발생합니다. Anthropic의 Contextual Retrieval 연구는 청크마다 전체 문서 맥락을 요약해 덧붙이는 방식으로 리콜을 최대 67%까지 개선할 수 있음을 보였습니다.
컨텍스트 과부하(context stuffing)도 자주 봅니다. 관련 문서를 많이 넣을수록 좋다는 생각에 상위 10~20개 문서를 모두 컨텍스트에 주입하면, 오히려 모델이 정작 중요한 내용을 무시하는 “lost in the middle” 현상이 발생합니다(Liu et al., 2023). 상위 3~5개 문서를 정밀하게 선별하는 편이 20개를 뭉텅이로 넣는 것보다 답변 품질이 높은 경우가 많습니다.
RAG를 도입했다고 환각이 사라지는 것은 아닙니다.
모델은 검색된 문서를 무조건 따르지 않습니다. 문서에 없는 내용을 추가하거나, 여러 문서의 내용을 잘못 혼합하거나, 검색 결과를 무시하고 사전 지식으로 답변하는 경우가 여전히 발생합니다. 중요 사실은 항상 반환된 소스 문서와 대조 검증하는 레이어를 별도로 두는 것이 좋습니다.
자주 묻는 질문
- 파인튜닝과 RAG 중 환각이 더 적은 쪽은 어느 쪽인가요?
- 일반적으로 RAG가 출처 기반이라 환각이 적습니다. 검색된 문서가 모델의 참고 자료로 컨텍스트에 실리기 때문에 사실 근거를 추적할 수 있습니다. 파인튜닝은 지식이 가중치에 녹아 있어 어디서 틀렸는지 추적하기 어렵고, 학습 데이터에 없는 패턴에서는 여전히 환각을 일으킬 수 있습니다. 다만 RAG도 검색이 실패하면 환각이 발생하므로, 검색 품질 자체를 철저히 관리해야 합니다.
- 학습 데이터가 적을 때 파인튜닝을 해도 되나요?
- 수십 쌍으로는 효과가 미미하고 과적합 위험이 큽니다. 일반적으로 LoRA 파인튜닝에는 최소 수백 쌍 이상, 형식 학습이 목표라면 1,000쌍 이상을 권장합니다. 데이터가 부족한 초기에는 RAG로 시작하면서 실제 서비스 로그에서 좋은 예시를 수집해 학습 데이터를 쌓는 편이 현실적입니다.
- 오픈소스 모델과 클로즈드 API 모델 중 파인튜닝하기 좋은 쪽은?
- 오픈소스 모델(LLaMA, Mistral, Qwen 계열 등)은 가중치를 직접 수정할 수 있어 LoRA·QLoRA 등 다양한 기법을 자유롭게 적용할 수 있습니다. 반면 OpenAI GPT-4o mini나 Gemini 같은 클로즈드 API는 공식 파인튜닝 기능을 통해서만 가능하며, 학습 방식과 파라미터 조정 범위에 제한이 있습니다. 완전한 통제와 데이터 보안이 중요하다면 오픈소스 + 자체 인프라가 유리합니다.
- RAG의 검색 품질을 높이는 가장 빠른 방법은?
- 청킹 전략 개선과 하이브리드 검색 도입이 가장 즉각적인 효과를 냅니다. 의미 단위로 청킹하고, 임베딩 기반 시맨틱 검색과 BM25 키워드 검색을 결합한 하이브리드 방식(Anthropic Contextual Retrieval, 2024)으로 리콜을 크게 높일 수 있습니다. 검색 후 LLM이 관련성을 다시 평가하는 리랭킹(reranking) 단계를 추가하는 것도 효과적입니다.
- 파인튜닝된 모델에도 RAG를 얹을 수 있나요?
- 네, 가능하며 실제로 많은 상용 서비스가 이 하이브리드 구조를 씁니다. 파인튜닝으로 도메인 어휘·형식·어조를 체화시키고, RAG로 최신 정보를 실시간 공급합니다. 특히 전문 어휘가 많고 데이터 업데이트가 잦은 의료·법률·금융 도메인에서 두 방법의 장점을 조합하는 하이브리드가 단독보다 성능이 높은 경우가 많습니다.
이 글은 Lewis et al.(NeurIPS 2020), Hu et al.(ICLR 2022), Anthropic Contextual Retrieval 공식 블로그(2024), OpenAI 파인튜닝 공식 문서 등 공개된 연구 및 기술 문서를 기반으로 작성됐습니다. GPU 단가, API 가격, 파인튜닝 최소 데이터 요건 등 수치는 시점·제공사·모델에 따라 달라지므로 실제 적용 전 각 공식 문서와 가격 페이지를 반드시 확인하시기 바랍니다.