파인튜닝 vs RAG vs 프롬프트 - 언제 무엇을 쓸까

LLM으로 뭔가 만들려고 하면 곧 이 갈림길을 만납니다. "우리 데이터를 어떻게 넣지? 파인튜닝? RAG? 아니면 프롬프트로 어떻게든?" 세 가지는 경쟁 기술이 아니라 서로 다른 문제를 푸는 도구입니다. 잘못 고르면 돈과 시간을 크게 낭비합니다.

이 글은 세 방법의 본질적 차이를 짚고, "언제 무엇을 쓸지"를 판단하는 의사결정 프레임워크에 집중합니다. RAG 내부 구현은 별도 글로 다루니 여기선 선택 기준만 봅니다.

1. 세 방법의 본질 차이

한 문장씩으로 정리하면 이렇습니다.

프롬프트: 요청할 때 지침·예시를 말로 넣는다. (모델은 그대로)
RAG: 답하기 직전에 관련 문서를 찾아 컨텍스트에 넣는다. (모델은 그대로, 지식만 외부 주입)
파인튜닝: 모델 가중치 자체를 추가 학습시킨다. (모델이 바뀐다)

비유하면 이렇습니다. 시험을 보는 학생이 있다고 합시다.

방법	비유
프롬프트	시험지에 "이런 식으로 답해"라고 요령을 적어 줌
RAG	오픈북 시험 — 관련 페이지를 펼쳐서 보게 함
파인튜닝	시험 전에 그 과목을 몸에 배도록 훈련시킴

여기서 결정적 감각이 나옵니다. RAG는 "무엇을 아는가(지식)" 를 다루고, 파인튜닝은 "어떻게 하는가(스타일·행동·형식)" 를 다룹니다. 프롬프트는 그 둘 다 가볍게 건드리지만 용량과 일관성에 한계가 있습니다.

2. 항목별 비교표

기준	프롬프트	RAG	파인튜닝
바꾸는 대상	요청 방식	주입되는 지식	모델 자체
최신 정보 반영	수동으로 넣어야	문서만 갱신하면 됨	재학습 필요
초기 구축 비용	거의 없음	중간(파이프라인)	높음(데이터+학습)
요청당 비용	낮음	중간(검색+긴 컨텍스트)	낮음(짧은 프롬프트)
출처 추적	어려움	가능(인용)	불가
스타일·형식 체화	제한적	제한적	강함
반영 속도	즉시	빠름(재색인)	느림(학습 주기)

이 표만 봐도 감이 옵니다. 최신성·출처가 중요하면 RAG, 말투·형식·행동의 일관성이 중요하면 파인튜닝, 일단 빠르게 검증하려면 프롬프트입니다.

3. 의사결정 프레임워크

실제로 고를 때 던지는 질문 순서입니다.

질문 1. 프롬프트만으로 되는가?

항상 여기서 시작하세요. 프롬프트는 가장 싸고 빠른 지렛대입니다. 역할·예시·출력 형식만 잘 잡아도 생각보다 많은 문제가 풀립니다. 여기서 안 되는 것만 다음으로 넘깁니다.

질문 2. 문제가 "지식"인가 "스타일"인가?

이게 가장 중요한 분기점입니다.

필요한 게 "사실/정보"인가?   → 지식 문제  → RAG
필요한 게 "말투/형식/행동"인가? → 행동 문제  → 파인튜닝

"우리 회사 환불 규정을 알려줘" → 지식 → RAG
"항상 우리 브랜드 톤으로, 정해진 JSON 스키마로 답해" → 행동 → (프롬프트로 안 되면) 파인튜닝

질문 3. 그 지식은 얼마나 자주 바뀌는가?

자주 바뀜(가격, 재고, 문서 업데이트)  → RAG (문서만 갱신)
거의 안 바뀜(도메인 상식, 고정 규칙)   → 파인튜닝도 후보

변동성이 핵심 판별자입니다. 자주 바뀌는 지식을 파인튜닝에 넣으면, 내용 하나 바뀔 때마다 재학습해야 하는 지옥이 열립니다. 변하는 지식은 RAG가 정답입니다.

질문 4. 비용·운영 여력이 되는가?

파인튜닝은 학습 데이터 구축(수백~수천 개의 양질 예시), 학습 비용, 그리고 모델 버전 관리라는 운영 부담이 따라옵니다. "요청당 프롬프트가 짧아져 추론 비용은 낮아지지만, 만드는 비용이 높다"는 트레이드오프를 감당할 수 있는지 봐야 합니다.

4. 결정 흐름도

위 질문들을 하나로 이으면 이렇습니다.

시작
 │
 ├─ 프롬프트로 충분한가? ── 예 → 프롬프트로 끝
 │        │ 아니오
 │        ▼
 ├─ 필요한 게 지식인가? ── 예 ─ 자주 바뀌나? ─ 예 → RAG
 │        │                        │ 아니오 → RAG(기본) / 고정 상식이면 파인튜닝 고려
 │        │ 아니오(스타일/행동)
 │        ▼
 └─ 프롬프트+few-shot으로 스타일이 잡히나?
          ├─ 예 → 프롬프트 유지
          └─ 아니오 → 파인튜닝

한 줄 요약: 프롬프트 → (지식이면) RAG → (스타일이 안 잡히면) 파인튜닝 순서로 올라갑니다.

5. 조합 전략 - 실무에선 대부분 섞는다

현실의 제품은 셋 중 하나만 쓰지 않습니다. 역할이 다르므로 함께 씁니다.

프롬프트 + RAG (가장 흔한 조합): RAG로 근거 문서를 넣고, 프롬프트로 "이 문서만 근거로 답하고 없으면 모른다고 해"라고 통제합니다. 대부분의 사내 챗봇·문서 QA가 이 구조입니다.
파인튜닝 + RAG: 파인튜닝으로 답변의 형식·톤·도메인 어투를 몸에 배게 하고, 최신 사실은 RAG로 공급합니다. "어떻게 말할지는 파인튜닝, 무엇을 말할지는 RAG"라는 분업입니다.
셋 다: 파인튜닝된 모델에, RAG로 지식을 넣고, 프롬프트로 세부 지시를 준다.

핵심 원칙: 지식은 RAG, 행동은 파인튜닝, 세부 통제는 프롬프트. 이 분업만 지켜도 설계가 깔끔해집니다.

6. 흔한 오해 바로잡기

"내 데이터를 넣으려면 파인튜닝해야 한다" → 아닙니다. 지식을 넣는 것은 대부분 RAG가 맞습니다. 파인튜닝은 지식 주입 도구가 아니라 행동 형성 도구입니다.
"파인튜닝하면 모델이 그 사실을 정확히 외운다" → 위험한 착각입니다. 파인튜닝은 경향(스타일·패턴) 을 학습시키지, 특정 사실을 DB처럼 정확히 기억하지 못합니다. 오히려 잘못 외우면 할루시네이션이 됩니다.
"롱 컨텍스트가 나왔으니 RAG는 끝났다" → 아닙니다. 문서를 통째로 넣으면 비용·속도·정확도(중간 내용 유실) 문제가 있고, 출처 추적도 어렵습니다. RAG는 필요한 부분만 골라 넣는 효율 도구로 여전히 유효합니다.
"파인튜닝이 제일 고급이니 좋은 것" → 아닙니다. 가장 비싸고 무거울 뿐입니다. 가장 값싼 방법으로 문제가 풀리면 그게 최선입니다.

마무리

세 방법은 우열이 아니라 역할 분담입니다.

기억할 것은 세 가지입니다.

프롬프트부터 시작하라. 가장 싸고 빠른 검증 수단이다.
지식 문제는 RAG, 스타일·행동 문제는 파인튜닝. 변동성이 크면 무조건 RAG다.
실무에선 대부분 섞어 쓴다. "지식은 RAG, 행동은 파인튜닝, 통제는 프롬프트."

"무엇을 아는가"를 바꿀지, "어떻게 말하는가"를 바꿀지 — 이 한 질문이 대부분의 선택을 결정합니다.