파인튜닝 vs RAG: 프로덕션 LLM에서 각 접근법을 언제 사용해야 할까

LLM을 프로덕션에 배포하다 보면 어느 순간 반드시 이 질문에 부딪힌다. “우리 서비스에 맞게 모델을 커스터마이징해야 하는데, 파인튜닝을 해야 할까, RAG를 써야 할까?”

팀 전체가 회의실에 모여 열띤 토론을 벌이는 상황—누군가는 “모델을 직접 학습시켜야 진짜 성능이 나온다”고 주장하고, 다른 누군가는 “그냥 문서 넣어서 검색하면 되는 거 아닌가요?”라고 말한다. 둘 다 틀리지 않았다. 문제는 어떤 상황에서 무엇을 선택하느냐다.

이 글은 그 선택을 잘못했을 때 치르는 비용—수백만 원짜리 GPU 학습 비용, 몇 달짜리 개발 일정, 배포 후 발견한 치명적 한계—을 경험하기 전에 올바른 결정을 내릴 수 있도록 돕기 위해 쓰였다. 솔직히 고백하자면, 나도 첫 번째 프로젝트에서 이 선택을 틀렸다. RAG로 충분했을 시스템에 파인튜닝을 먼저 시도하면서 몇 주를 날렸다.

파인튜닝과 RAG, 무엇이 다른가

먼저 두 접근법이 근본적으로 무엇을 해결하는지부터 짚고 넘어가야 한다.

파인튜닝(Fine-tuning)은 사전학습된 모델의 가중치를 도메인 특화 데이터로 추가 학습시키는 방법이다. 모델 내부에 지식을 “새겨넣는” 방식이라고 볼 수 있다. 학습이 끝나면 그 지식은 추론 시 별도의 외부 참조 없이 모델 자체에서 나온다.

RAG(Retrieval-Augmented Generation)는 모델 가중치는 건드리지 않고, 질의가 들어올 때마다 외부 데이터 소스에서 관련 문서를 검색해 컨텍스트로 주입하는 방법이다. 모델에게 “참고자료를 줘가며 답변하게 하는” 방식이다.

이 차이가 왜 중요하냐면, 두 접근법은 서로 다른 문제를 해결하기 때문이다. 이걸 헷갈리는 팀이 생각보다 많다.

구분	파인튜닝	RAG
해결 문제	행동 방식, 어조, 형식	지식의 최신성, 출처 추적
지식 갱신	재학습 필요	문서 업데이트로 즉시 반영
초기 비용	높음 (GPU 학습)	낮음 (인프라 구축)
운영 복잡도	낮음 (추론만)	높음 (검색 파이프라인 유지)
설명 가능성	낮음	높음 (출처 제공 가능)

파인튜닝이 진짜 필요한 순간

파인튜닝이 압도적 우위를 보이는 시나리오가 분명히 있다. 아래 세 가지가 그 핵심이다.

특정 출력 형식과 어조가 핵심일 때

법률 문서 검토 서비스를 만든다고 해보자. 사용자가 계약서를 올리면 리스크 포인트를 뽑아주는 기능이 필요하다. 여기서 중요한 건 단순히 “법률 지식”이 아니라, 출력의 형식이다. 조항 번호를 어떻게 인용하는지, 심각도 등급을 어떤 기준으로 분류하는지, 문장의 단호함은 어느 정도여야 하는지—이런 것들은 RAG로 주입할 수 있는 “정보”가 아니라 모델이 내면화해야 할 “행동 패턴”이다.

# 파인튜닝 학습 데이터 예시 (JSONL 형식)
{
  "messages": [
    {
      "role": "user",
      "content": "다음 조항을 검토해주세요: '본 계약의 지식재산권은 갑에게 귀속됩니다.'"
    },
    {
      "role": "assistant", 
      "content": "【리스크 등급: 높음】\n【해당 조항: 제7조 1항】\n\n귀속 대상이 '을이 개발한 성과물' 전체로 해석될 수 있어 계약 종료 후에도 을의 독자적 사용이 제한될 수 있습니다.\n\n【권고사항】 '본 계약 이행 목적으로 특별히 개발된 산출물'로 범위를 한정하는 문구 추가를 검토하십시오."
    }
  ]
}

이 형식—대괄호 태그, 조항 인용, 권고사항 분리—을 프롬프트로 지시해도 어느 정도 동작하지만, 수만 건의 실제 사례로 파인튜닝된 모델은 이 패턴을 훨씬 안정적으로, 훨씬 짧은 프롬프트로 재현한다. 내 경험상 프롬프트 길이가 절반 이하로 줄고, 형식 이탈 빈도도 눈에 띄게 낮아진다. 토큰 비용도 자연히 줄어든다.

모델이 특수한 언어나 기호 체계를 다뤄야 할 때

의료 분야의 SNOMED CT 코드, 금융의 FIX 프로토콜 메시지, 특정 회사만의 내부 DSL—이런 것들은 범용 모델이 제대로 이해하기 어렵다. RAG로 “FIX 메시지 형식 설명서”를 넣어줄 수는 있지만, 모델이 그 형식으로 직접 생성하거나 파싱하는 능력은 학습을 통해 길러지는 쪽이 훨씬 효과적이다.

추론 속도와 프롬프트 길이가 제약 조건일 때

모바일 앱에 탑재하거나 실시간 응답이 필요한 경우, RAG가 추가하는 레이턴시(검색 + 컨텍스트 구성)와 토큰 증가가 치명적일 수 있다. 파인튜닝된 소형 모델(7B~13B)이 RAG 없이도 충분한 성능을 낸다면, 전체 시스템 아키텍처가 단순해진다.

RAG가 압도적으로 유리한 상황

반대로, RAG가 유일한 현실적 선택지인 상황도 분명히 존재한다.

지식이 자주 바뀔 때

회사 내부 정책, 제품 문서, 규정—이런 것들은 분기마다, 심지어 매달 바뀐다. 파인튜닝된 모델은 재학습 없이 이 변화를 반영할 수 없다. 반면 RAG는 문서 저장소를 업데이트하는 것만으로 즉시 반영된다.

# RAG 파이프라인 기본 구조 (LangChain 사용 예)
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA

# 문서 업데이트 시 벡터 저장소만 갱신
embeddings = OpenAIEmbeddings()
vectorstore = Chroma(
    collection_name="company_docs",
    embedding_function=embeddings,
    persist_directory="./chroma_db"
)

# 새 정책 문서 추가 (재학습 불필요)
vectorstore.add_documents(new_policy_docs)

# QA 체인 구성
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
    return_source_documents=True  # 출처 추적 가능
)

result = qa_chain.invoke({"query": "재택근무 장비 지원 기준이 어떻게 되나요?"})
print(result["result"])
print("출처:", [doc.metadata["source"] for doc in result["source_documents"]])

답변의 근거를 제시해야 할 때

금융, 의료, 법률 영역에서는 “왜 그렇게 답했는가”를 추적할 수 있어야 한다. RAG는 어떤 문서에서 어떤 내용을 참조했는지 출처를 함께 반환할 수 있다. 파인튜닝된 모델의 지식은 가중치 속에 분산되어 있어 출처 추적이 근본적으로 불가능하다—이건 규제 환경에서는 치명적인 약점이다.

도입 속도와 초기 비용이 중요할 때

MVP를 빠르게 검증해야 하는 스타트업이나 파일럿 프로젝트라면, 파인튜닝의 학습 파이프라인 구축—데이터 수집, 정제, 학습, 평가, 배포—에 드는 시간과 비용을 감당하기 어려울 수 있다. RAG는 벡터 데이터베이스 세팅과 문서 임베딩만으로 며칠 안에 프로토타입을 만들 수 있다.

긴 문서나 대용량 지식 베이스를 다룰 때

수천 개의 제품 매뉴얼, 수년치 판례, 회사 전체의 위키—이런 분량을 모두 파인튜닝 데이터로 쓰는 건 비효율적이다. 컨텍스트 윈도우 한계로 인해 한 번에 처리할 수 없는 대용량 문서는 RAG의 검색 메커니즘이 필요하다.

비용과 운영 복잡도: 현실적인 계산

의사결정에서 기술적 적합성만큼 중요한 게 운영 현실이다.

파인튜닝의 실제 비용 구조

초기 학습: GPT-4o 파인튜닝 기준, 학습 데이터 1M 토큰당 약 $25. 1만 건의 고품질 예시가 평균 500 토큰이라면 약 $125. 여기에 데이터 수집·정제 인건비가 훨씬 크다.
재학습 주기: 지식이 바뀔 때마다 반복 발생
추론 비용: 파인튜닝된 모델은 베이스 모델 대비 추론 비용이 높은 경우가 많다 (OpenAI 기준 2~4배)
평가 비용: 파인튜닝 후 성능 회귀 여부를 검증하는 평가 파이프라인이 필요하다

RAG의 실제 비용 구조

인프라: 벡터 DB (Pinecone, Weaviate, pgvector 등) 월 $50~$500+ (규모에 따라)
임베딩 비용: 문서 업데이트 시마다 발생. OpenAI text-embedding-3-small 기준 1M 토큰당 $0.02로 저렴하지만, 수백만 문서라면 누적된다
검색 레이턴시: 평균 100~300ms 추가. 실시간 서비스에서 체감될 수 있다
유지보수: 청킹 전략, 임베딩 모델 업데이트, 검색 품질 모니터링 등 지속적 관리 필요

가장 흔한 실수는 RAG를 “단순히 문서 붙이면 되는 것”으로 과소평가하는 것이다. 청킹 전략 하나만 봐도—고정 길이, 의미 단위, 계층적 청킹, 문서 구조 기반 청킹—제대로 설계하는 데 상당한 노력이 든다. 실제로 나는 512 토큰 고정 청킹으로 시작했다가 검색 품질이 너무 들쑥날쑥해서 전체 파이프라인을 뜯어고친 경험이 있다. 처음부터 도메인 구조에 맞는 청킹을 설계하는 게 훨씬 낫다.

실무 결정 프레임워크

파인튜닝 vs RAG 선택 시 아래 질문들을 순서대로 답해보자.

1. 지식이 주기적으로 바뀌는가?
   → YES: RAG 우선 검토
   → NO: 다음 질문으로

2. 답변 출처 추적이 필수 요건인가?
   → YES: RAG 필수
   → NO: 다음 질문으로

3. 모델의 출력 형식/어조/스타일이 핵심 차별점인가?
   → YES: 파인튜닝 검토
   → NO: 다음 질문으로

4. 특수 기호 체계나 도메인 언어를 생성해야 하는가?
   → YES: 파인튜닝 강력 권고
   → NO: 다음 질문으로

5. 초기 데이터가 충분한가? (최소 수천~수만 건의 고품질 예시)
   → YES: 파인튜닝 진행 가능
   → NO: RAG로 시작 후 파인튜닝 검토

6. 추론 레이턴시가 100ms 이하여야 하는가?
   → YES: 파인튜닝된 소형 모델 검토
   → NO: 요구사항에 따라 선택

하이브리드 접근법: 둘 다 써야 할 때

실무에서 가장 성능이 좋은 시스템 중 상당수가 파인튜닝과 RAG를 함께 쓴다. 역할을 명확히 나누면 시너지가 난다.

파인튜닝이 담당하는 것:
– 출력 형식과 어조 일관성
– 도메인 특화 언어 이해
– 짧은 프롬프트로도 원하는 행동 유도

RAG가 담당하는 것:
– 최신 정보 주입
– 구체적 사실 관계 (수치, 날짜, 이름)
– 출처 제공

# 하이브리드 패턴 예시
from openai import OpenAI

client = OpenAI()

def hybrid_query(user_question: str, retrieved_docs: list[str]) -> str:
    # 파인튜닝된 모델이 형식과 어조를 담당
    # RAG가 가져온 문서가 최신 지식을 공급
    context = "\n\n".join(retrieved_docs)

    response = client.chat.completions.create(
        model="ft:gpt-4o-mini:your-org:legal-reviewer:abc123",  # 파인튜닝 모델
        messages=[
            {
                "role": "system",
                "content": "당신은 법률 문서 검토 전문가입니다."
            },
            {
                "role": "user",
                "content": f"참고 자료:\n{context}\n\n질문: {user_question}"
            }
        ],
        temperature=0.1
    )
    return response.choices[0].message.content

다만 하이브리드는 복잡도도 두 배다. 두 시스템을 모두 유지·개선해야 하므로, 팀 규모와 역량을 냉정하게 평가한 뒤 도입해야 한다. “일단 다 쓰면 더 좋겠지”라는 생각으로 시작했다가 유지보수 부담에 지치는 팀을 꽤 봤다.

자주 저지르는 실수 3가지

1. 데이터 없이 파인튜닝 계획 세우기
“파인튜닝하면 잘 되겠지”라는 기대로 시작했다가, 고품질 학습 데이터 수집이 프로젝트 전체 일정의 80%를 잡아먹는 경우가 흔하다. 파인튜닝을 결정하기 전에 학습 데이터 확보 계획부터 세워라.

2. RAG 청킹을 대충 설계하기
512 토큰 고정 청킹으로 시작해서 “왜 검색이 엉뚱한 걸 가져오지?”를 반복하다가 결국 전체를 다시 설계하는 팀이 많다. 도메인에 맞는 청킹 전략—FAQ는 Q&A 단위, 기술 문서는 섹션 단위, 계약서는 조항 단위—을 처음부터 고민하라. (그리고 청킹 전략을 바꾸면 기존 임베딩을 전부 재생성해야 한다는 것도 미리 염두에 두자.)

3. 평가 없이 배포하기
파인튜닝 후 “느낌상 좋아진 것 같다”로 배포하거나, RAG 검색 품질을 수동으로만 확인하는 경우가 많다. 정량 평가 지표—파인튜닝은 포맷 일치율, RAG는 검색 정밀도(Precision@K)와 답변 충실도—를 배포 전에 반드시 측정하라.

기술보다 요구사항이 먼저다

파인튜닝 vs RAG는 “무엇이 더 좋은가”의 문제가 아니다. 어떤 문제를 해결하려는가에 따라 답이 달라지는 도구 선택의 문제다.

지식이 자주 바뀌고 출처 추적이 필요하다면 RAG가 맞다. 출력의 형식과 스타일이 차별점이고 학습 데이터가 있다면 파인튜닝이 맞다. 둘 다 필요하다면 하이브리드를—단, 그 복잡도를 감당할 준비가 됐을 때만.

가장 실용적인 조언은 이것이다: 먼저 베이스 모델 + RAG로 시작하라. 이게 충분하지 않은 구체적인 이유가 발견됐을 때 파인튜닝을 추가해라. 반대 순서로 하면 불필요한 비용과 시간을 낭비하는 경우가 더 많다—내가 그랬던 것처럼.

다음 단계로 고민 중이라면:

실제 프로젝트에서 파인튜닝 또는 RAG를 적용하면서 겪은 구체적인 문제—학습 데이터 설계, 청킹 전략, 평가 파이프라인 구성—가 있다면 댓글로 남겨주세요. 후속 글에서 실제 사례 기반으로 다뤄보겠습니다.