RAG vs 파인튜닝: 언제 무엇을 쓸까 (실제 수치 포함)

RAG vs 파인튜닝: 언제 무엇을 쓸까 (실제 수치 포함)

시중의 RAG vs 파인튜닝 조언 대부분은 같은 태스크에서 두 방식을 직접 측정한 유일한 실험을 건너뜁니다. Balaguer 외(arXiv:2401.08406, 162회 인용)는 농업 QA 세트를 양쪽 모두에 통과시켰습니다. 파인튜닝으로 정확도가 6%p 이상 올랐고, RAG는 그 위에 5%p를 더 쌓았습니다. 논문의 Table 18을 보면 GPT-4는 기본 75%, 파인튜닝 시 81%, 검색을 더하면 86%입니다. 그런데 왜 우리는 여전히 대부분의 팀에게 RAG부터 시작하라고 말할까요? 최신성, 인용, 그리고 아래 비용 계산이 1%p 정확도 격차보다 더 많은 프로젝트의 운명을 결정하기 때문입니다.

핵심 요약

• 지식이 자주 바뀌거나 답변에 출처 인용이 필수라면 RAG가 기본입니다. 파인튜닝은 일관된 형식과 지연 시간에서 이깁니다.
• 파인튜닝 비용은 앞단(학습)에서 발생하고, RAG 비용은 쿼리마다(임베딩 + 추가 입력 토큰) 발생합니다.
• 동일 태스크 공개 근거: 파인튜닝이 정확도 6%p를 더했고, RAG가 그 위에 5%p를 추가했으며, 하이브리드는 단독 사용 양쪽을 모두 이겼습니다.
• 학습 코드 한 줄 쓰기 전에 다섯 가지 점검(데이터 최신성, 레이블 예시, 지연 시간, 인용, 팀 역량)을 먼저 돌리세요.

RAG vs 파인튜닝, 언제 써야 할까? (빠른 결론)

지식이 자주 바뀌거나 답변에 인용이 달려야 한다면 RAG를 고르세요. 일관된 출력 형식과 낮은 지연 시간이 필요하고 레이블된 예시를 수백 개 이상 보유하고 있다면 파인튜닝을 고르세요. 배포가 성숙해지면 둘 다 씁니다. RAG는 모델이 읽는 컨텍스트를 바꾸고, 파인튜닝은 모델 자체를 바꿉니다. 대부분의 팀에게 필요한 것은 전자이지 후자가 아닙니다.

한 줄로 남길 것: RAG는 모델이 무엇을 읽느냐를 바꾸고, 파인튜닝은 모델이 무엇이냐를 바꿉니다. 태스크가 실제로 어느 쪽을 필요로 하는지에 따라 고르세요.

교과서적 정의가 궁금하다면 NVIDIA의 RAG 용어집이 검색 쪽을 깔끔하게 정의해 줍니다. 다만 정의가 아키텍처를 골라 주지는 않습니다. 근거가 골라 주죠. 그러니 근거부터 보세요.

근거는 무엇을 보여줄까? 하나의 태스크, 두 방식, 실측

이 쿼리의 Google 상위 5개 중 동일 태스크 실측 비교를 담은 유일한 글은 Balaguer 외 2024입니다. 162회 인용된 Microsoft Research 연구죠. 이 팀은 하나의 농업 QA 태스크를 RAG 파이프라인, 파인튜닝된 모델, 그리고 둘의 하이브리드에 각각 통과시킨 뒤 GPT-4로 답변을 채점했습니다. 그 셋업에서 파인튜닝 단독이 RAG 단독을 근소하게 앞섰고, 둘을 쌓으면 어느 한쪽보다 더 큰 격차로 이겼습니다.

농업 사례 연구 (arXiv:2401.08406)

2024년 1월에 Angels Balaguer와 15명의 공저자가 제출한 이 연구는 농민에게 지역 특화 인사이트를 제공하려면 무엇이 필요한지를 묻습니다. 이들의 파이프라인은 PDF에서 정보를 추출하고, 그로부터 질문-답변 쌍을 생성하며, Llama2-13B, GPT-3.5, GPT-4를 검색 유무에 따라 평가합니다.

Balaguer 등은 파인튜닝으로 정확도가 6%p 이상 증가했다고 보고하며, 이는 RAG와 누적됩니다. RAG는 그 위에 5%p를 더했죠. 하이브리드 파이프라인은 어느 한쪽 단독보다 우수했습니다. Table 18은 GPT-4의 순서를 이렇게 보여줍니다. 도움 없이 75%, RAG로 80%, 파인튜닝으로 81%, 파인튜닝 + RAG로 86%. 80%와 81%가 얼마나 가까운지 주목하세요. RAG 단독과 파인튜닝 단독의 격차는 1%p인 반면, 하이브리드는 양쪽에서 5%p나 앞서 있습니다. 한 실험에서 파인튜닝된 모델은 다른 지역의 지식을 끌어와 지역별 질문에 답했고, 답변 유사도가 47%에서 72%로 뛰었습니다.

경제성 근거

Snorkel AI의 공개 연구(2022년 11월)는 비용 쪽을 다룹니다. 100개 클래스 법률 분류 벤치마크(LEDGAR, 계약 조항 80,000건)에서 파인튜닝된 RoBERTa 모델은 파인튜닝된 GPT-3과 동급 성능을 내면서 크기는 1,400분의 1, 정답 레이블은 1% 미만만 사용했고, 프로덕션 추론 비용은 파인튜닝된 GPT-3 모델의 0.1%, 즉 약 천 분의 1로 실행됐습니다. 총 구축 비용은 프로그래매틱 레이블링으로 $1,915, 수동 어노테이션 + GPT-3 파인튜닝으로 $7,418이었습니다. 한 가지 주의할 점: 이것은 분류이지 생성형 QA가 아니므로, 비율은 방향성으로만 받아들이세요.

우리의 해석

저희 해석은 이렇습니다. 그 셋업은 파인튜닝에게 가장 유리한 경우였고, 그런데도 겨우 1%p 이겼습니다. Balaguer 등은 고정된 PDF 코퍼스로 학습하고 그 동일하게 얼어붙은 코퍼스로 평가했기 때문에, 가중치가 배운 것이 실험 도중에 낡을 일이 없었습니다. 대부분의 프로덕션 지식 베이스는 그렇게 가만히 있지 않죠. 지난주 릴리스에 대한 질문에 답하는 지원 봇은 재학습 주기마다 6%p를 다시 벌어와야 하지만, RAG에 공급하는 인덱스는 같은 날 오후에 업데이트됩니다. 그래서 저희는 1%p 정확도 우위를 이 결정에서 가장 약한 입력으로, 최신성을 가장 강한 입력으로 읽습니다. 근거가 일반화되지 않는 부분: Snorkel의 결과는 분류 벤치마크이고, 두 연구 모두 톤이나 형식 제어는 테스트하지 않았습니다. 그 영역은 여전히 파인튜닝의 가장 강한 근거로 남아 있습니다.

파인튜닝이 정답인 경우는 팀들이 생각하는 것보다 드뭅니다. "파인튜닝하자"고 말하는 프로젝트 대부분은 사실 "검색하자"는 뜻입니다.

RAG는 어떻게 동작하고, 언제 이길까?

RAG(검색 증강 생성)는 모델이 학습 중 외운 것이 아니라 여러분이 통제하는 문서에서 답을 찾습니다. Lewis 등이 2020년에 처음 제안한 뒤 지식 작업의 기본이 됐는데, 지식이 모델 바깥에 살기 때문입니다. 인덱스만 업데이트하면 재학습 없이 내일부터 모든 답변이 바뀝니다.

파이프라인은 네 단계입니다:

1. 수집. 문서(PDF, 위키, 티켓)를 파싱해 코퍼스로 만듭니다.
2. 청킹과 임베딩. 수백 토큰 단위의 청크로 나누고, 임베딩 모델로 각 청크를 벡터로 변환합니다.
3. 검색. 쿼리 시점에 가장 유사한 청크 top-K를 찾고, SKU나 오류 코드처럼 정확한 문자열은 키워드 매칭으로 잡습니다.
4. 증강과 생성. 그 청크들을 프롬프트에 넣고 LLM이 출처와 함께 답하게 합니다.

RAG는 세 가지 축에서 이깁니다. 최신성(재학습 대신 재인덱싱), 인용(모든 답변이 출처 청크를 가리킴), 데이터 통제(고객 데이터가 학습에 들어가지 않음). 전체 구축 과정이 궁금하다면 RAG 애플리케이션 단계별 구축 가이드를 참고하세요.

검색 품질에 대한 경고 하나: 파이프라인의 품질은 임베딩과 검색 조합의 품질을 넘지 못합니다. Anthropic의 Contextual Retrieval은 기본 셋업에서 top-20 검색 실패율 5.7%를 측정했고, 컨텍스트 임베딩 + BM25로 2.9%까지, 리랭커를 추가하면 1.9%까지 떨어졌습니다. 완전 일치 쿼리가 계속 실패한다면 하이브리드 검색(BM25 vs 벡터)이 해법입니다.

파인튜닝은 언제 이길까? (그리고 PEFT란?)

파인튜닝은 모델이 무엇을 아느냐가 아니라 어떻게 답하느냐가 문제일 때 이깁니다. 일관된 출력 형식, 브랜드 톤, 또는 검색 왕복이 없는 빡빡한 지연 시간 예산 같은 것이죠. 소형 모델 경제학을 실현하는 레버이기도 합니다. 위에서 본 Snorkel의 "GPT-3급 품질을 비용의 0.1%로" 결과는 누군가 대형 모델을 서빙하는 대신 소형 모델을 파인튜닝했기에 존재합니다.

풀 파인튜닝 vs PEFT (LoRA / QLoRA)

풀 파인튜닝은 모델의 모든 가중치를 업데이트합니다. 비싸고, 느리고, 대형 연구소 밖에서는 드뭅니다. 거의 모든 사람은 대신 PEFT(파라미터 효율적 파인튜닝)을 배포합니다. LoRA(Hu 등 2021)는 기본 가중치를 고정하고 작은 저랭크 어댑터를 학습하며, 보통 파라미터 수의 0.1-1%입니다. QLoRA는 그 위에 4비트 양자화를 더해 13B 모델이 소비자용 GPU 하나에 올라갑니다. 알아 둘 관련 용어가 하나 더 있습니다. 연속 사전학습(continuous pretraining)으로, 모델이 레이블 예시에 대한 지도 파인튜닝 전에 원시 도메인 코퍼스로 사전학습을 계속하는 방식(비지도)입니다.

Hugging Face PEFT 문서에 따른 최소 LoRA 설정:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

데이터셋 준비, 에포크 수, 평가는 단계별 파인튜닝 가이드를 참고하세요.

위험은 실재합니다. 소형 데이터셋에서의 과적합(수백 개 예시는 학습이 아니라 암기를 합니다), 노후화(가중치는 학습 시점 기준으로 지식을 고정합니다), 그리고 출처 귀속 불가(파인튜닝된 모델은 영수증을 보여줄 수 없습니다). 이 셋 중 하나라도 거래 파탄 요인이라면, 방금 스스로를 RAG 쪽으로 설득한 셈입니다.

RAG vs 파인튜닝 vs 프롬프트 엔지니어링: 나머지는 어디에 들어맞을까?

셋은 사다리이지 경쟁자가 아닙니다. 프롬프트 엔지니어링은 명령어를 바꾸고, RAG는 모델이 읽는 컨텍스트를 바꾸며, 파인튜닝은 가중치를 바꿉니다. OpenAI의 자체 파인튜닝 가이드도 파인튜닝을 루프의 맨 뒤에 둡니다. 먼저 평가, 다음으로 프롬프트, 프롬프트로 부족해질 때만 학습. 비교적 새로운 선택지 두 가지가 도구 상자를 마저 채웁니다.

짚고 넘어갈 혼동 하나: MCP 서버와 에이전트 프레임워크는 커스터마이징이 아니라 오케스트레이션입니다. 모델이 닿을 수 있는 도구와 출처를 결정하지, 모델이 어떻게 답하는지는 바꾸지 않습니다. 에이전트 안에서 RAG 파이프라인을 돌리고 그 아래 모델을 파인튜닝할 수 있으며, 많은 프로덕션 시스템이 실제로 둘 다 합니다. 자동완성 전쟁("vs mcp", "vs agents")은 범주 오류입니다.

RAG가 파인튜닝보다 저렴한가? 실제 비용 모델

짧은 답: 현실적인 쿼리량에서는 그렇습니다. 파인튜닝 청구서는 앞단(레이블 데이터 + 학습)에서 도착하고, RAG 청구서는 쿼리마다(임베딩 + 추가 입력 토큰) 도착합니다. OpenAI의 파인튜닝 문서는 학습을 토큰 단위로 과금하지만, 토큰 요금은 레이블 예시의 인건비 옆에서는 푼돈입니다. 공개 가격 기준 계산은 이렇습니다.

손익분기 질문: RAG의 누적 쿼리당 세금이 파인튜닝 투자액과 같아지려면 쿼리가 몇 번 필요할까?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

월 50,000 쿼리라면 10년이 넘습니다. 대부분의 제품에서 파인튜닝 투자는 토큰 절약만으로 회수되지 않습니다. 파인튜닝은 형식과 지연 시간을 위해 하는 것이지, 비용에서 RAG를 이기려고 하는 것이 아닙니다. 계산은 월 수백만 쿼리를 넘거나 검색된 컨텍스트가 매우 클 때 뒤집힙니다. 그리고 비대칭성에 주목하세요. 파인튜닝 청구서는 데이터 드리프트가 재학습을 강제할 때마다 갱신되지만, RAG는 볼륨 × 청크 크기에 비례해 선형으로 커집니다. 쿼리당 비용이 진짜 걱정이라면 먼저 쿼리당 LLM 비용 줄이기부터 시작하세요. 그래도 학습 길을 간다면, 수표를 쓰기 전에 파인튜닝 도구를 비교하세요.

최신성 참고: 2026년 7월 기준으로 OpenAI의 파인튜닝 문서는 호스팅 플랫폼이 신규 사용자에게 단계적으로 종료되고 있으며, 기존 사용자는 앞으로 몇 달간 학습 접근을 유지한다고 밝힙니다. 팀들이 오픈 모델 PEFT나 순수 RAG 쪽으로 기우는 이유가 하나 더 늘었습니다.

선택 전 5가지 점검

학습 코드를 쓰기 전에 이 다섯 가지 예/아니요 점검을 돌리세요. 답변의 패턴은 어떤 벤치마크보다 더 신뢰성 있게 RAG, 파인튜닝, 하이브리드를 가리킵니다. 솔직하게 답한 뒤 세어 보세요.

1. 지식이 재학습할 수 있는 속도보다 빠르게 바뀌는가? 예 → RAG. 문서 업데이트마다 재학습하는 것은 운영 계획이 아닙니다.
2. 레이블된 예시가 수백 개 있는가? 아니요 → RAG 또는 프롬프트 엔지니어링. 예시 40개로 파인튜닝하면 암기하지 학습하지 않습니다.
3. 경성 지연 시간 예산이 있는가? 빡빡함 → 파인튜닝 우세. 검색 왕복을 건너뛰면 50-200ms를 아낍니다.
4. 답변에 인용이나 감사 추적(audit trail)이 필수인가? 예 → RAG. 파인튜닝된 모델은 출처 청크를 가리킬 수 없습니다.
5. 팀에 ML 역량과 학습용 GPU 또는 API 예산이 있는가? 아니요 → RAG. 다시 만들 수 있는 인덱스가 다시 학습할 수 없는 가중치보다 낫습니다.

1, 4, 5에서 대부분 예 → RAG. 안정적인 도메인에서 2와 3이 대부분 예 → 파인튜닝. 답변이 갈리거나 실제 트래픽이 있는 성숙한 제품 → 하이브리드(다음 섹션). 체크리스트의 요점은 습관이 아니라 근거로 결정하는 것입니다. 이번 달 피드에서 유행하는 기법이 아니라요.

RAG와 파인튜닝을 함께 쓸 수 있을까?

네. 성숙한 배포에서는 하이브리드 패턴이 예외가 아니라 표준입니다. 도메인 유창성과 출력 형식은 파인튜닝으로(어떻게), 추론 시점의 사실은 검색으로(무엇을). Balaguer 등은 농업 태스크에서 정확히 이것을 보고했습니다. 하이브리드 파이프라인이 어느 한쪽 단독을 이겼고, RAG의 5%p 이득이 파인튜닝의 6%p 위에 쌓였습니다.

저희가 권하는 성숙도 경로: 프롬프트 엔지니어링으로 시작하고, 답변에 비공개 또는 최신 데이터가 필요해지는 순간 RAG를 추가하며, 형식 불일치나 지연 시간이 프로덕션에서 아프기 시작할 때만 파인튜닝을 추가하세요. 바로 파인튜닝으로 직행하면 검색이 이미 문제를 해결했는지 알기 전에 학습 세금을 냅니다.

하이브리드 패턴은 타협이 아닙니다. 성숙한 배포에서는 그것이 기본입니다. 형식은 파인튜닝, 사실은 검색.

승자는 어떻게 평가할까?

데이터베이스를 고르듯 승자를 고르세요. 감이 아니라 여러분의 워크로드로 측정하는 것입니다. 레시피는 한 단락이고, 실제로 결정하는 네 가지 수치를 다룹니다.

• 보류 질문 세트. 실사용자 질문 100-300개. 합성 질문은 안 되고, 학습이나 인덱싱 중 본 것도 절대 안 됩니다.
• 충실도와 답변 정확도. 충실도는 답변이 검색된 컨텍스트에 근거하는지를, 답변 정확도는 실제로 맞는지를 묻습니다. RAGAS로 대중화된 이 쌍은 환각과 검색 누락을 둘 다 잡습니다.
• p95 지연 시간, 평균이 아니라요. 검색은 왕복을 추가합니다. 꼬리를 측정하세요.
• 1,000 쿼리당 비용, 토큰 + 인프라, 추측이 아니라 실측.
• 드리프트 시 재실행. 새 문서, 새 모델 스냅샷, 새 분기: 세트를 다시 돌리세요.

도구를 포함한 전체 지표 분석은 LLM 평가 가이드에 있습니다.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 클라이언트를 위한 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 구축합니다. Techsy 팀이 실제로 프로덕션에서 사용하는 LLM 도구 스택에 대해 씁니다. LinkedIn에서 연결하세요.

자주 묻는 질문

RAG와 파인튜닝을 함께 쓸 수 있나요?

네. 출력 형식과 도메인 유창성은 파인튜닝으로 잡고, 추론 시점의 사실은 검색으로 유지하세요. Balaguer 등은 농업 QA 태스크에서 이 하이브리드를 측정했고, 어느 한쪽 단독보다 우수하며 정확도 이득이 누적된다는 것을 확인했습니다. 대부분의 성숙한 프로덕션 시스템은 결국 여기에 도달합니다. 어떻게는 가중치로, 무엇은 검색으로.

파인튜닝을 쓰지 말아야 할 때는?

지식이 재학습 속도보다 빠르게 바뀔 때, 레이블된 예시가 수백 개 미만일 때, 답변에 인용이나 감사 추적이 필수일 때, 데이터 드리프트마다 재학습할 예산이 없을 때는 파인튜닝을 건너뛰세요. 이 네 가지 조건은 대부분의 초기 단계 제품을 설명하며, 그래서 RAG가 보통 올바른 첫 수입니다.

파인튜닝은 끝났나요?

아니요. 다만 영역이 줄었습니다. 긴 컨텍스트 윈도우와 저렴한 RAG가 2023년에 파인튜닝을 요구하던 유스케이스를 흡수했습니다. 남은 것은 실재합니다. 엄격한 출력 형식, 브랜드 톤, 검색 왕복 없는 지연 시간 예산, 소형 모델 경제학. 문제가 모델이 무엇을 아느냐가 아니라 어떻게 답하느냐라면, 파인튜닝은 여전히 도구입니다.

RAG vs 파인튜닝, 언제 무엇을 쓰나요?

답변이 비공개 또는 자주 업데이트되는 지식에 의존하거나 인용이 필요할 때는 RAG를 쓰세요. 일관된 형식, 톤, 지연 시간이 필요하고 레이블 예시를 충분히 보유하고 있을 때는 파인튜닝을 쓰세요. 제품이 성숙해지면 둘 다 쓰세요. 확신이 없다면 RAG로 시작하세요. 학습 실행보다 되돌리기 저렴합니다.

RAG가 파인튜닝보다 저렴한가요?

초기에는 그렇습니다. RAG 비용은 쿼리당(임베딩 + 추가 입력 토큰) 발생하는 반면, 파인튜닝은 학습과 레이블 데이터에 한 번 과금하고 재학습할 때마다 갱신됩니다. 공개 가격 기준으로, 저희 계산 예시에서 손익분기는 약 640만 쿼리 지점에 있으므로, 일반적인 볼륨에서는 제품 수명 내내 RAG가 더 저렴합니다.

환각에는 RAG가 파인튜닝보다 나은가요?

보통 그렇지만, 공짜는 아닙니다. RAG는 답변을 검색된 청크에 근거시키므로 출처를 인용하고 실패를 감사할 수 있습니다. 다만 나쁜 검색은 답변을 오염시킵니다. Anthropic은 기본 셋업에서 top-20 검색 실패율 5.7%를 측정했고, 컨텍스트 검색 + 리랭킹으로 1.9%까지 줄였습니다. 한편 파인튜닝은 오류를 가중치에 새기며 추적할 방법이 없습니다.

RAG vs 파인튜닝 vs 프롬프트 엔지니어링: 차이가 뭔가요?

프롬프트 엔지니어링은 보내는 명령어를 바꿉니다. RAG는 쿼리 시점에 모델이 읽는 컨텍스트를 바꿉니다. 파인튜닝은 모델의 가중치를 바꿉니다. 각각은 이전보다 더 큰 개입입니다. 먼저 프롬프트를 시도하고, 지식이 병목일 때 검색을 추가하며, 형식, 톤, 지연 시간이 여전히 아플 때만 학습하세요.

RAG vs 파인튜닝 성능은 어떻게 평가하나요?

실사용자 질문 100-300개로 보류 세트를 만들고 두 방식을 그 위에서 채점하세요. 충실도(근거가 있는가?), 답변 정확도(맞는가?), p95 지연 시간, 1,000 쿼리당 비용. 문서나 모델 스냅샷이 바뀔 때마다 세트를 다시 돌리세요. 합성 질문은 양쪽 다 좋아 보이게 만들고, 실제 질문은 둘을 갈라놓습니다.

새로운 지식에 대한 멀티홉 질문은 파인튜닝 vs RAG?

더 나은 검색을 갖춘 RAG입니다. 메커니즘이 이것을 결정합니다. 파인튜닝된 모델은 가중치가 흡수한 것에 대해서만 추론할 수 있으므로, 한 번도 보지 못한 지식은 아무리 잘 학습했어도 닿을 수 없습니다. 검색은 쿼리 시점에 누락된 조각을 건넵니다. 함정은 검색 한 번으로는 모든 홉을 좀처럼 모으지 못한다는 점입니다. 그래서 단일 top-K 조회가 아니라 쿼리 분해나 반복 검색 + 리랭커를 계획하세요.

결론

헷지 없이 요약하면:

• RAG는 바뀌는 지식과 인용 있는 답변의 기본입니다. 파인튜닝은 형식, 톤, 지연 시간의 전문의입니다.
• 동일 태스크 근거(Balaguer 등)는 파인튜닝에 +6%p, 그 위에 RAG +5%p를 주며, 하이브리드가 셋 중 최고입니다. RAG로 시작하라는 저희 조언은 그 점수판이 아니라 최신성, 인용, 비용에 근거합니다.
• 비용 계산은 현실적인 볼륨에서 RAG 쪽으로 섭니다. 저희 계산 예시에서 손익분기는 약 640만 쿼리였습니다.
• 습관이 아니라 다섯 가지 점검으로 결정하세요.

RAG를 골랐다면? 파이프라인 주변 스택은 RAG 도구 순위 리스트를 참고하세요.