RAG vs Fine-Tuning: 실제로 어떤 것을 선택해야 할까요?

LLM을 연결하고 당신의 제품에 대한 사용자 질문을 던졌더니, 모델이 존재하지도 않는 API 엔드포인트를 자신 있게 만들어낸 적이 있나요? 모든 엔지니어가 마주하게 되는 순간에 오신 것을 환영합니다. 베이스 모델 (base model)은 똑똑하지만, 당신의 도메인(domain)에 대해서는 아무것도 모릅니다.

두 가지 주류 해결책인 RAG와 파인튜닝 (fine-tuning) 이 있으며, 인터넷에는 "상황에 따라 다릅니다"라는 식의 모호한 답변들로 가득 차 있습니다. 이 포스트는 그 반대입니다. 언제 검색 (retrieval)이 재학습 (retraining)보다 나은지, 언제 그렇지 않은지, 각각의 코드가 실제로 어떻게 생겼는지, 그리고 제가 두 방식을 모두 출시하며 겪었던 주의 사항(gotchas)들을 다룹니다.

한 줄로 요약하는 멘탈 모델 (mental model)

RAG = 모델이 추론 (inference) 시점에 정보를 찾아봅니다. 지식은 가중치 (weights) 외부에 존재합니다.

파인튜닝 (Fine-tuning) = 훈련 (training)을 통해 새로운 동작을 가중치에 구워 넣습니다. 지식/동작이 모델 내부에 존재합니다.

이 둘을 구분하는 가장 유용한 단 하나의 질문:

내 문제가 모델이 내 사실 관계(facts)를 모르는 것인가, 아니면 내가 원하는 방식대로 동작하지 않는 것인가?

지식 격차 (Knowledge gap) → RAG. 동작 격차 (Behavior gap) → 파인튜닝 (fine-tuning). "파인튜닝이 필요합니다"라는 요청의 대부분은 사실 지식 격차를 숨기고 있는 것입니다.

코드로 보는 RAG (실행 가능)

전체 RAG 루프는 다음과 같습니다: 문서를 임베딩 (embed) 합니다 → 벡터 (vectors)를 저장합니다 → 쿼리 (query) 시점에 질문을 임베딩하고, 가장 가까운 청크 (chunks)를 찾아 (시맨틱 검색, semantic search), 이를 프롬프트 (prompt)에 집어넣습니다.

이 예제는 그대로 실행 가능합니다. 임베딩 (Embeddings)에는 sentence-transformers (로컬 실행, API 키 불필요)를 사용하며, 생성 (generation)에는 Claude를 사용합니다. 두 개의 model.encode(...) 호출을 교체하여 임베딩 모델을 호스팅 서비스(OpenAI, Voyage, Cohere)로 바꿀 수 있습니다.

pip install sentence-transformers numpy anthropic
export ANTHROPIC_API_KEY=sk-...   # 생성 단계를 위한 키

import numpy as np
from sentence_transformers import SentenceTransformer
from anthropic import Anthropic
...

프로덕션 환경에서는 수천 개의 청크를 넘어서도 검색 속도를 유지할 수 있도록 인메모리 (in-memory) NumPy 검색을 실제 벡터 데이터베이스 (vector database: pgvector, Qdrant, Weaviate, Pinecone)로 교체해야 합니다. 하지만 위의 로직이 바로 RAG입니다. "최근접 이웃 검색 (nearest-neighbor search) + 프롬프트 조립 (prompt assembly)"보다 더 신비로운 것은 없습니다.

엔지니어들이 RAG를 선택하는 이유:

문서를 변경함으로써 지식을 업데이트할 수 있습니다 - 재학습(retraining)이 필요 없습니다.
답변의 추적(traceable)이 가능합니다; 어떤 청크(chunk)가 답변을 생성했는지 알 수 있습니다.
민감한 데이터가 모델 가중치(weights)가 아닌 사용자의 저장소에 그대로 유지됩니다.

코드에서의 파인튜닝 (Fine-tuning in code)

파인튜닝 (Fine-tuning)은 아무것도 검색(retrieve)하지 않습니다. 원하는 동작이 내재될 때까지 모델에게 수백 개 이상의 입력→출력(input→output) 예시를 보여줍니다. 데이터 형식(data format)을 만드는 것이 실제 작업이며, 훈련 호출(training call)은 거의 부차적인 일에 가깝습니다.

전형적인 지도 파인튜닝 (supervised fine-tuning) 데이터셋은 한 줄당 하나의 예시가 포함된 JSONL 형식입니다:

{"messages": [{"role": "system", "content": "Classify the support ticket into: billing, bug, feature_request, other."}, {"role": "user", "content": "I was charged twice this month."}, {"role": "assistant", "content": "billing"}]}
{"messages": [{"role": "system", "content": "Classify the support ticket into: billing, bug, feature_request, other."}, {"role": "user", "content": "The export button does nothing on Safari."}, {"role": "assistant", "content": "bug"}]}
{"messages": [{"role": "system", "content": "Classify the support ticket into: billing, bug, feature_request, other."}, {"role": "user", "content": "Can you add dark mode?"}, {"role": "assistant", "content": "feature_request"}]}

그리고 대표적인 훈련 시작 코드입니다 (제공업체별 SDK는 다르지만, 형태는 일관적입니다):

# 사용 중인 제공업체의 파인튜닝 SDK에 맞게 조정하세요.
job = client.fine_tuning.jobs.create(
    training_file="ticket_classifier.jsonl",
...

엔지니어들이 이를 선택하는 이유:

매 프롬프트마다 다시 설명할 필요 없이, 대규모 환경에서 일관된 형식/톤/구조를 유지할 수 있습니다.

검색 가능한 문서로 표현하기 어려운 전문화된 판단력을 갖출 수 있습니다.

추론 (inference) 시 프롬프트가 짧아지며 (동작이 내재화되었기 때문), 이는 대량 호출 시 호출당 비용을 절감할 수 있습니다.

주의할 점: 요구 사항이 변경될 때마다 데이터를 큐레이션하고 다시 재학습해야 합니다. 실제 비용은 GPU 시간이 아니라 데이터 준비 (Data prep)에서 발생합니다.

결정 체크리스트

이 목록을 따라가며 검토하십시오; 강력한 신호가 나타나는 첫 번째 지점에서 멈추면 됩니다.

지식이 자주 변경되는가? → RAG. 문서가 업데이트될 때마다 재학습(Retraining)을 하는 것은 자학적인 행위입니다.
출처가 인용되거나 감사(Auditable) 가능한 답변이 필요한가? → RAG. 미세 조정(Fine-tuned)된 가중치(Weights)는 왜 그런 답변이 나왔는지 알려줄 수 없습니다.
모델이 사실 관계가 아니라 형식/톤/판단력을 계속 틀리는가? → 미세 조정 (Fine-tuning).
정제된 레이블링 예시(Labeled examples)가 수백 개 정도 있는가? 미세 조정을 위해 필요합니다. 없다면 RAG가 더 빠르게 시작할 수 있는 방법입니다.
여전히 확신이 서지 않는가? → RAG로 시작하세요. 구축 비용이 더 저렴하고, 디버깅이 쉬우며, 가장 흔한 실패 사례(모델이 사용자의 정보를 알지 못하는 문제)를 해결해 줍니다.

그리고 대부분의 게시물이 생략하는 부분은 이것입니다: 이 둘은 상호 배타적이지 않습니다. 성숙한 시스템은 행동 양식을 위해 미세 조정을 수행하고, 최신 사실을 위해 그 위에 RAG를 결합합니다. "RAG vs Fine-Tuning"은 점점 더 "RAG와 미세 조정(RAG and Fine-Tuning)"이 되어가고 있습니다.

제가 겪었던 주의사항 (Gotchas)

청킹(Chunking)이 정확도를 조용히 결정합니다. 잘못된 청크 경계(표의 중간 행을 나누거나, 2000-토큰 규모의 거대 청크를 사용하는 경우)는 모델이 질문을 접하기도 전에 검색(Retrieval) 단계를 망쳐버립니다. LLM을 탓하기 전에 청크 크기(Chunk size)와 중첩(Overlap)을 먼저 조정하세요.
RAG는 플러그 앤 플레이(Plug-and-play)가 아닙. "잘못된 컨텍스트를 검색함 → 자신 있게 틀린 답변을 내놓음"은 RAG의 가장 흔한 실패 모드입니다. 초기에 평가 세트(Eval set)를 추가하세요.
지식 문제를 미세 조정으로 해결하려는 것은 전형적이고 비용이 많이 드는 실수입니다. 해결책이 "우리의 현재 가격 정책을 가르치는 것"이라면, 미세 조정은 느리고 비용이 많이 들며 금방 구식이 됩니다. RAG를 사용하세요.
평가(Eval)가 없으면 진전도 없습니다. 출시 전에 작은 규모의 레이블링된 테스트 세트를 구축하세요. 이것 없이는 눈을 감고 튜닝하는 것과 같으며, "느낌상 더 나아진 것 같다"가 유일한 지표가 되어버립니다.
쓰레기가 들어가면, 자신감 넘치는 쓰레기가 나옵니다 (Garbage in, confident garbage out). 두 접근 방식 모두 입력되는 데이터를 증폭시킵니다. 먼저 데이터를 정제하세요.

RAG vs 미세 조정 (Fine-Tuning)의 차이점

RAG

해결 과제: 지식 격차 (Knowledge gaps)
지식 업데이트: 문서를 수정하면 되며, 재학습이 필요 없음
추적 가능한 답변: 예 - 어떤 청크가 답변을 생성했는지 알 수 있음
초기 비용: 낮음
대부분의 팀에게 가장 좋은 시작점: 예

미세 조정 (Fine-Tuning)

해결 사항: 행동 격차 (behavior gaps)
지식 업데이트: 재학습 (retrain)
추적 가능한 답변: 아니요
초기 비용: 높음 (데이터 준비가 실제 비용임)
대부분의 팀에게 가장 좋은 시작점: 행동 방식이 걸림돌이 되는 시점에 나중에 추가

결론

"RAG vs 미세 조정 (Fine-Tuning)" 논쟁은 영역 다툼이 아니라 라우팅 (routing) 결정의 문제입니다. 지식 문제에는 RAG를, 행동 문제에는 미세 조정을 할당하면 대부분의 혼란은 사라집니다.

대다수의 팀에게 올바른 첫 번째 단계는 RAG입니다. 구축 비용이 더 저렴하고, 디버깅이 훨씬 쉬우며, 몇 주가 아닌 며칠 만에 배포할 수 있고, 모델이 귀사의 정보를 알지 못하는 가장 흔한 실패 모드 (failure mode)를 직접적으로 해결하기 때문입니다. 모델이 이미 사실 관계는 알고 있지만 형식, 어조 또는 판단을 계속 틀리게 하고, 이를 가르칠 수 있는 수백 개의 깨끗한 예시를 확보했을 때 미세 조정을 고려하십시오. 복잡성을 감당할 준비가 되었다면 두 가지를 모두 사용하십시오. 행동 방식을 위해 미세 조정을 수행하고, 최신의 추적 가능한 사실을 위해 그 위에 RAG 레이어를 쌓는 것입니다.

피해야 할 값비싼 실수는 지식 격차를 해결하기 위해 미세 조정을 선택하는 것입니다. 이는 느리고, 정보가 금방 노후화되며, 검색 (retrieval) 레이어가 훨씬 짧은 시간 안에 그 역할을 수행했을 것입니다. 단순하게 시작하고, 실제 평가 세트 (eval set)로 측정하며, 증거가 필요하다고 말할 때만 시스템에 무게를 더하십시오.