파인튜닝이란 — 프롬프트·RAG와 무엇을 나눠 맡나
Fine-tuning takes an already-trained model and continues training it on a smaller, task-specific dataset, changing the weights themselves. It sits alongside two cheaper options that are often confused with it: prompt engineering, which changes only the instruction, and retrieval-augmented generation, which leaves the model untouched and feeds it the documents it needs at answer time. The rule of thumb is that RAG fixes what the model does not know, fine-tuning fixes how it behaves, and prompting fixes neither but is free. Techniques such as LoRA freeze most parameters and train only a small added set
파인튜닝은 이미 훈련된 모델을 작은 목적별 데이터로 다시 학습시켜 가중치 자체를 바꾸는 작업이다. 자주 혼동되는 선택지가 둘 더 있다 — 지시문만 바꾸는 프롬프트 엔지니어링과, 모델은 그대로 두고 답할 때 필요한 문서를 찾아 넣어 주는 RAG다. 갈라 쓰는 기준은 간단하다. 모르는 것을 채우는 일은 RAG, 행동 방식을 바꾸는 일은 파인튜닝, 둘 다 아니면 프롬프트다. LoRA 같은 기법은 대부분의 파라미터를 고정하고 일부만 학습한다
3줄 요약
- 정의 — 훈련된 모델을 목적별 데이터로 다시 학습시켜 가중치를 바꾸는 작업이다
- 구분 — 모르는 지식은 RAG, 말투·형식·판단 기준은 파인튜닝, 나머지는 프롬프트다
- 비용 — 프롬프트 < RAG < 파인튜닝 순서다. 위에서부터 시도하는 것이 정석이다
핵심 질문
- 파인튜닝이 정확히 무슨 작업이야
- **이미 훈련이 끝난 모델을 가져와 작은 데이터로 학습을 더 시키는 것**이다. 핵심은 **모델의 가중치가 실제로 바뀐다**는 점이다. 프롬프트를 아무리 길게 써도 모델 자체는 그대로지만, 파인튜닝을 하면 **다른 모델이 된다.** 처음부터 훈련하는 것과 다른 이유는 규모다 — 기반 모델 훈련에는 수천억~수조 개 토큰과 대규모 GPU 클러스터가 들어가지만, 파인튜닝은 **수백~수만 건 규모의 데이터**로도 의미 있는 변화를 만든다. 요즘 실무에서는 **LoRA·QLoRA** 같은 기법을 쓰는데, 이는 **기존 파라미터를 거의 전부 고정해 두고 작게 덧붙인 부분만 학습**하는 방식이다. 모델이 커질수록 전체 파라미터를 다시 학습시키는 것이 현실적으로 어렵기 때문이다.
- RAG랑 파인튜닝 중에 뭘 써야 해
- **바꾸려는 것이 '아는 것'이냐 '하는 방식'이냐**로 갈린다. 모델이 **모르는 정보**를 답에 넣어야 한다면 — 사내 규정, 오늘 자 가격표, 최신 뉴스 — **RAG**다. 답할 때마다 문서를 찾아 넣어 주므로 자료가 바뀌면 **문서만 갈아 끼우면 되고 모델은 건드리지 않는다.** 반대로 모델이 정보를 몰라서가 아니라 **말투·출력 형식·판단 기준이 우리 것과 다를 때**는 파인튜닝이다. 같은 사실을 알고도 우리 회사가 쓰는 방식으로 정리하게 만드는 일이다. 흔한 실수는 **최신 정보를 넣으려고 파인튜닝을 하는 것**이다 — 가능은 하지만 자료가 바뀔 때마다 다시 학습해야 하므로 비용이 계속 든다. 실무에서는 **둘을 함께 쓰는 경우**가 많다. 형식은 파인튜닝으로 고정하고 내용은 RAG로 공급한다.
- 파인튜닝하면 답이 더 정확해져?
- **지식의 정확도는 잘 올라가지 않는다.** 파인튜닝이 확실히 개선하는 것은 **형식·문체·작업 수행 방식**이고, **사실 관계**는 그만큼 확실하지 않다. 이유는 훈련 방식에 있다 — 파인튜닝은 "이런 입력에는 이런 출력"이라는 패턴을 학습시키는 것이지, 사실을 사전처럼 저장하는 절차가 아니다. 그래서 학습 데이터에 없는 질문을 받으면 **학습한 말투로 그럴듯하게 지어낼 위험이 오히려 커질 수 있다.** 사실 정확도를 원한다면 **근거 문서를 함께 넣어 주는 RAG** 쪽이 구조적으로 유리하다. 답의 출처를 표시할 수 있고, 틀렸을 때 어느 문서가 원인인지 추적할 수 있기 때문이다. 이 지면은 「AI 환각이란 — 모델이 '모르겠다'고 답하지 않도록 훈련된 이유」에서 이 위험의 뿌리를 다뤘다.
파인튜닝은 이미 훈련된 모델을 다시 학습시키는 작업이다.
프롬프트를 바꾸는 것과 다르다. 모델 자체가 바뀐다.
그런데 실무에서 파인튜닝이 정답인 경우는 생각보다 적다.
1. 세 개의 선택지
같은 문제 — "모델이 우리가 원하는 답을 안 준다" — 를 푸는 방법이 셋이다.
| 방법 | 무엇을 바꾸나 | 모델 가중치 |
|---|---|---|
| 프롬프트 엔지니어링 | 지시문 | 그대로 |
| RAG (검색 증강 생성) | 답할 때 넣어주는 자료 | 그대로 |
| 파인튜닝 | 모델 자체 | 바뀐다 |
세 번째만 모델을 건드린다. 앞의 둘은 모델 바깥을 손보는 일이다.
이 표를 먼저 보는 이유가 있다. 비용과 되돌리기 난이도가 아래로 갈수록 커진다. 프롬프트는 몇 분이면 고치고, RAG는 문서를 갈아 끼우면 되고, 파인튜닝은 학습을 다시 돌려야 한다.
2. 어떻게 갈라 쓰나
기준은 하나다. 바꾸려는 것이 '아는 것'인가, '하는 방식'인가.
| 문제 | 맞는 방법 | 이유 |
|---|---|---|
| 사내 규정을 모른다 | RAG | 문서를 넣어주면 된다 |
| 오늘 자 가격을 모른다 | RAG | 자료가 매일 바뀐다 |
| 말투가 우리 톤이 아니다 | 파인튜닝 | 형식은 학습으로 굳힌다 |
| 출력 형식이 매번 다르다 | 파인튜닝 | 패턴을 고정한다 |
| 지시를 잘 못 알아듣는다 | 프롬프트 | 지시문을 다시 쓴다 |
| 예시를 보여주면 잘한다 | 프롬프트 | 예시를 프롬프트에 넣는다 |
가장 흔한 실수는 최신 정보를 넣으려고 파인튜닝을 하는 것이다. 기술적으로 불가능하지는 않다. 문제는 자료가 바뀔 때마다 다시 학습해야 한다는 점이다. 매주 갱신되는 가격표를 파인튜닝으로 넣으면 매주 학습 비용이 나간다. 같은 일을 RAG로 하면 문서 하나 교체하는 작업이다.
3. 파인튜닝의 실제 모양
파인튜닝은 처음부터 훈련하는 것과 규모가 다르다.
| 구분 | 기반 모델 훈련 | 파인튜닝 |
|---|---|---|
| 데이터 | 수천억~수조 토큰 | 수백~수만 건 |
| 계산 자원 | 대규모 GPU 클러스터 | 훨씬 작다 |
| 결과 | 새 모델 | 기존 모델의 변형 |
요즘 실무에서 쓰는 방식은 전체를 다시 학습시키지 않는다. LoRA와 QLoRA 같은 기법은 기존 파라미터를 거의 전부 고정해 두고, 작게 덧붙인 부분만 학습한다. 모델이 커질수록 모든 파라미터를 다시 학습하는 것이 현실적으로 불가능해졌기 때문에 나온 절충이다.
학습 대상이 작다는 것은 두 가지를 뜻한다. 비용이 내려가고, 원본 모델의 능력이 덜 훼손된다. 전체 파인튜닝은 목적 작업을 잘하게 만드는 대신 원래 잘하던 다른 일을 잊게 만드는 부작용이 알려져 있다.
4. 파인튜닝이 잘 못 하는 일
여기가 가장 자주 오해되는 지점이다. 파인튜닝은 지식을 채워 넣는 절차가 아니다.
| 개선되는 것 | 잘 개선되지 않는 것 |
|---|---|
| 출력 형식 | 사실 정확도 |
| 문체·말투 | 최신 정보 |
| 작업 수행 방식 | 출처 표시 |
| 특정 도메인의 표현 관습 | 틀렸을 때의 추적 가능성 |
이유는 학습의 성격에 있다. 파인튜닝은 "이런 입력에는 이런 출력"이라는 패턴을 익히게 하는 일이지, 사실을 사전처럼 저장하는 일이 아니다.
그래서 부작용이 하나 생긴다. 파인튜닝된 모델은 학습 데이터에 없는 질문을 받아도 학습한 말투로 자신 있게 답한다. 형식은 완벽한데 내용이 틀린 답이 나오기 쉬워지고, 형식이 좋기 때문에 사람이 더 잘 믿는다.
사실 정확도가 목적이라면 RAG가 구조적으로 유리하다. 근거 문서를 함께 넣으므로 출처를 표시할 수 있고, 답이 틀렸을 때 어느 문서가 원인인지 추적할 수 있다. 이 지면은 「AI 환각이란 — 모델이 '모르겠다'고 답하지 않도록 훈련된 이유」에서 이 위험의 뿌리를 다뤘다.
5. 실무에서는 섞어 쓴다
셋 중 하나를 고르는 문제로 보면 답이 잘 안 나온다. 실제로는 층으로 쌓는다.
| 층 | 담당 |
|---|---|
| 파인튜닝 | 출력 형식·문체·도메인 표현을 고정 |
| RAG | 그때그때 필요한 사실을 공급 |
| 프롬프트 | 이번 요청의 구체적 지시 |
권장 순서는 위에서부터가 아니라 아래에서부터다. 프롬프트로 먼저 시도하고, 안 되면 RAG를 붙이고, 그래도 남는 문제가 형식·문체 쪽이면 그때 파인튜닝을 검토한다.
파인튜닝을 먼저 시작하면 문제의 원인을 모르는 채 가장 비싼 해법을 쓰게 된다. 프롬프트로 해결됐을 문제였는지, 자료가 없어서 생긴 문제였는지가 학습을 돌린 뒤에는 구분되지 않는다.
AI 에이전트를 만들 때도 같은 순서가 적용된다. 이 지면은 「AI 에이전트란 — 도구를 쥐여주면 무엇이 달라지나」에서 도구와 권한 설계를 다뤘는데, 에이전트가 잘 안 도는 원인은 모델의 능력보다 도구 설명과 권한 범위인 경우가 많다. 그 역시 파인튜닝으로는 풀리지 않는 문제다.
6. 확인하지 못한 것
- 필요한 데이터 양 — '수백~수천 건'은 소개 자료 기준이며 과제와 모델에 따라 크게 다르다.
- 사실 정확도 개선 폭 — 정량 비교를 확인하지 못했다. 본문은 방향 수준의 서술이다.
- 비용 순서 — 프롬프트 < RAG < 파인튜닝은 통념이며, 호출량이 매우 많으면 순서가 뒤집힐 수 있다.
- LoRA의 성능 손실 — 과제별로 보고가 갈리며 원 논문으로 대조하지 못했다.
- 조합 전략 — 층으로 쌓는 방식은 실무 관행이지 표준화된 방법론이 아니다.
- 관련 지면 — 「AI 학습과 추론 차이 — 같은 GPU가 두 번 팔리는 이유」에서 학습과 추론의 계산 구조를, 「AI 토큰 가격이란」에서 호출 비용의 구조를 다뤘다.