Fine-tuning vs RAG: 언제 어떤 방식을 선택해야 할까

LLM을 가져다 쓰다 보면 반드시 부딪히는 지점이 있다. "이 모델이 우리 데이터를 알게 하려면 어떻게 해야 하지?" 범용 모델은 똑똑하지만 우리 회사 내부 문서, 특정 도메인 용어, 조직만의 규칙 같은 건 모른다. 당연하다. 학습 데이터에 없었으니까.

이 문제를 푸는 방법이 크게 두 가지다. 파인튜닝(Fine-tuning)과 RAG(Retrieval-Augmented Generation). 둘 다 "LLM에 새로운 지식을 주입한다"는 목적은 같지만, 접근 방식이 완전히 다르다.

파인튜닝이란

기존 LLM의 가중치를 추가 데이터로 재학습시키는 것이다.

비유하자면 이렇다. 범용 AI가 의대를 졸업한 일반의라면, 파인튜닝은 전문의 수련 과정이다. 특정 분야의 데이터를 집중적으로 학습시켜서 모델의 행동 자체를 바꾼다.

구체적으로는:

학습 데이터를 준비한다 (질문-답변 쌍, 혹은 텍스트 데이터셋)
기존 모델의 가중치 일부 또는 전체를 업데이트한다
새로운 모델이 만들어진다

LoRA나 QLoRA 같은 기법이 나오면서 전체 가중치를 건드리지 않고 일부 파라미터만 학습하는 것도 가능해졌다. 이런 방식을 PEFT(Parameter-Efficient Fine-Tuning)라고 부르는데, GPU 자원을 훨씬 적게 쓰면서도 괜찮은 결과를 얻을 수 있다.

RAG란

모델을 건드리지 않는다. 대신 질문이 들어올 때마다 관련 문서를 검색해서 프롬프트에 함께 넣어준다.

오픈북 시험이라고 생각하면 된다. 모델이 답을 "아는" 게 아니라, 참고 자료를 보면서 답하는 것이다.

문서를 청크로 나누고 벡터 DB에 저장한다
사용자 질문이 오면 관련 문서를 검색한다
검색 결과를 프롬프트의 컨텍스트로 넣는다
LLM이 해당 컨텍스트를 참고해서 답변한다

모델 자체는 그대로다. 바뀌는 건 모델에 주어지는 입력뿐이다.

핵심 차이점 비교

	파인튜닝	RAG
모델 변경	가중치를 수정함	모델 그대로
지식 업데이트	재학습 필요	문서만 교체
초기 비용	높음 (GPU, 데이터 준비)	중간 (벡터 DB 구축)
운영 비용	낮음 (추론만)	중간 (검색 + 추론)
데이터 최신성	재학습 전까지 고정	실시간 반영 가능
할루시네이션	통제 어려움	출처 명시로 완화
응답 속도	빠름	검색 단계만큼 느림
구현 난이도	높음	중간

이 표만 보면 RAG가 거의 모든 면에서 나아 보인다. 실제로 대부분의 프로젝트에서 RAG가 첫 번째 선택이 되는 이유도 이것이다. 하지만 파인튜닝이 필요한 경우가 분명히 존재한다.

파인튜닝이 맞는 경우

모델의 "행동 방식"을 바꿔야 할 때. 특정 톤으로 말하게 하고 싶거나, 특정 포맷으로 출력하게 하고 싶거나, 도메인 특화 용어를 자연스럽게 사용하게 하고 싶을 때. RAG는 지식을 주입하지만, 모델이 그 지식을 어떤 스타일로 전달하는지까지 제어하기는 어렵다.

예를 들어 법률 분야에서 쓴다고 치면. "계약 해지 통보 요건"에 대한 답변을 법률 전문가 톤으로, 조문 인용 형식에 맞춰, 일정한 구조로 출력하게 하고 싶다면 파인튜닝이 효과적이다.

추론 비용을 줄여야 할 때. RAG는 매번 검색을 하고 긴 컨텍스트를 넣기 때문에 토큰 소비가 많다. 파인튜닝한 모델은 지식이 내재화되어 있어서 짧은 프롬프트로도 원하는 답을 얻을 수 있다. 호출 빈도가 매우 높은 서비스라면 이 차이가 비용에 직접 영향을 준다.

특수한 작업을 잘하게 만들 때. 감정 분석, 분류, 특정 포맷 추출 같은 작업에서 범용 모델이 80점이라면, 해당 작업에 특화된 데이터로 파인튜닝하면 95점까지 끌어올릴 수 있다. 작은 모델을 파인튜닝해서 큰 모델 수준의 성능을 특정 작업에서 내는 것도 가능하다.

RAG가 맞는 경우

데이터가 자주 바뀔 때. 이게 RAG의 가장 큰 강점이다. 새 문서가 추가되거나 기존 문서가 수정되면 벡터 DB만 업데이트하면 된다. 파인튜닝은 데이터가 바뀔 때마다 모델을 재학습해야 하는데, 이건 현실적으로 유지하기 어렵다.

사내 위키, 제품 매뉴얼, 고객 FAQ처럼 지속적으로 업데이트되는 문서 기반 시스템에는 RAG가 거의 필수다.

답변의 근거를 보여줘야 할 때. RAG는 검색된 문서를 참조해서 답변하니까, "이 답변은 어떤 문서의 몇 번째 단락을 근거로 합니다"라고 출처를 명시할 수 있다. 파인튜닝한 모델은 "그냥 아는" 거라서 근거를 추적하기 어렵다.

의료, 법률, 금융 같은 영역에서는 답변의 근거가 명확해야 한다. 할루시네이션이 발생했을 때도 "참조 문서에 이런 내용이 없는데?"라고 확인할 수 있으니 검증이 수월하다.

빠르게 시작해야 할 때. RAG 파이프라인은 며칠이면 프로토타입을 만들 수 있다. 파인튜닝은 데이터 정제, 학습, 평가까지 최소 몇 주는 걸린다. 일단 RAG로 시작하고 부족한 부분을 파악한 뒤에 파인튜닝을 고려하는 게 현실적인 접근이다.

비용 분석

비용 구조가 근본적으로 다르다.

파인튜닝 비용:

초기 학습 비용: GPU 사용료 (모델 크기에 따라 수십~수천 달러)
데이터 준비 비용: 라벨링, 정제 인건비
재학습 비용: 데이터 변경 시 반복
추론 비용: 일반 모델과 비슷하거나 약간 저렴 (짧은 프롬프트)

RAG 비용:

벡터 DB 운영: 월 수십~수백 달러 (관리형 서비스 기준)
임베딩 생성: 문서 양에 비례
추론 비용: 컨텍스트가 길어서 토큰 소비가 많음
검색 인프라: 지속적인 운영 비용

소규모로 시작하면 RAG가 저렴하다. 하지만 호출량이 많아지면 매번 검색하고 긴 컨텍스트를 넣는 RAG의 추론 비용이 누적되면서 파인튜닝 쪽이 유리해지는 지점이 온다. 어디서 교차하는지는 사용 패턴에 따라 다르다.

하이브리드 접근

실무에서 가장 효과적인 건 둘을 섞는 것이다.

대표적인 패턴이 "파인튜닝으로 행동을 잡고, RAG로 지식을 공급하는" 방식이다. 도메인 톤과 출력 형식은 파인튜닝으로 학습시키고, 실시간 데이터나 변동성이 큰 정보는 RAG로 주입한다.

[파인튜닝] 모델이 법률 문서 형식으로 답변하도록 학습
    +
[RAG] 최신 판례와 법률 조문을 검색해서 컨텍스트로 제공
    =
도메인 전문가 스타일로 최신 법률 정보를 답변하는 시스템

또 다른 패턴은 "RAG 결과를 파인튜닝 데이터로 활용하는" 것이다. RAG 시스템을 운영하면서 품질 좋은 질문-답변 쌍을 모으고, 이걸 파인튜닝 데이터로 쓰는 선순환 구조. 시간이 갈수록 모델 자체의 성능이 좋아진다.

의사결정 플로우

뭘 써야 할지 모르겠다면 이 순서로 생각해보자.

데이터가 자주 바뀌나? → 바뀐다면 RAG 우선
답변의 출처를 보여줘야 하나? → 그렇다면 RAG 우선
모델의 톤/스타일/형식을 바꿔야 하나? → 파인튜닝 고려
특정 작업의 정확도를 극한까지 올려야 하나? → 파인튜닝 고려
호출량이 매우 많은가? → 파인튜닝이 비용 효율적일 수 있음

대부분의 경우 1번과 2번에 해당해서 RAG로 시작하게 된다. 그러다 특정 영역에서 성능이 부족하면 그 부분만 파인튜닝을 추가하는 순서가 자연스럽다.

한 가지 더. 파인튜닝과 RAG 중 뭘 선택하든, 결국 좋은 데이터가 핵심이다. 파인튜닝은 학습 데이터의 품질이 모델 성능을 결정하고, RAG는 검색되는 문서의 품질이 답변 품질을 결정한다. 기술 스택을 고민하기 전에 데이터부터 정리하는 게 순서다.