프롬프트 엔지니어링으로 안 되면 RAG, RAG로도 안 되면 파인튜닝이라는 순서가 정답은 아닙니다. 세 가지는 애초에 해결하는 문제가 다르기 때문에, 비용과 유지보수 부담을 기준으로 먼저 갈라 보는 편이 실무에서는 더 빠릅니다. 이 글에서는 파인튜닝을 중심에 놓고 RAG, 프롬프트 엔지니어링과 어떤 지점에서 선택이 갈리는지 구체적인 조건으로 정리해 보겠습니다.
세 기술이 각각 바꾸는 대상이 다릅니다
프롬프트 엔지니어링은 모델의 가중치를 전혀 건드리지 않고, 입력으로 넣는 지시문과 예시만 바꿔서 출력을 조정하는 방식입니다. 모델 자체는 그대로 두고 “이번 요청에서 어떻게 답해야 하는지”를 매번 텍스트로 알려주는 셈입니다.
RAG(검색 증강 생성)는 모델 바깥에 문서 저장소를 두고, 질문이 들어올 때마다 관련 문서를 검색해서 프롬프트에 끼워 넣는 구조입니다. 모델은 그대로지만 참고할 자료가 실시간으로 바뀝니다. 이 개념은 위키백과의 Retrieval-augmented generation 문서에 원 논문 출처와 함께 잘 정리되어 있습니다.
파인튜닝은 이 둘과 다르게 모델의 가중치 자체를 특정 데이터셋으로 다시 학습시켜 바꿉니다. 응답 말투, 특정 형식 준수, 도메인 용어 사용 같은 “패턴”을 모델 내부에 새겨 넣는 작업이라, 지식을 새로 넣는 용도로는 잘 맞지 않습니다. OpenAI 공식 문서인 Fine-tuning 가이드에서도 파인튜닝을 “새로운 지식 주입”이 아니라 “행동 패턴 조정” 용도로 명시하고 있습니다.
비용은 정확히 어느 지점에서 갈리나요
프롬프트 엔지니어링은 초기 비용이 거의 없습니다. 다만 매 요청마다 지시문과 예시(few-shot)를 함께 보내야 해서 입력 토큰이 늘어나고, 이게 누적되면 API 비용이 서서히 커집니다.
RAG는 벡터 데이터베이스 구축비와 임베딩 생성 비용, 그리고 검색 인프라 운영비가 고정 비용으로 붙습니다. 대신 모델 자체를 바꾸지 않으므로 GPT-4o든 Claude든 원하는 모델을 그대로 교체해 쓸 수 있다는 유연성이 있습니다.
파인튜닝은 학습 시점에 목돈이 들어가는 구조입니다. 특히 풀 파인튜닝은 모델 전체 파라미터를 갱신하기 때문에 GPU 메모리 요구량이 크지만, LoRA나 QLoRA 같은 파라미터 효율적 학습(PEFT) 방식을 쓰면 일부 어댑터 파라미터만 학습해 필요 자원을 크게 줄일 수 있습니다. Hugging Face의 PEFT 라이브러리가 이 방식을 실제로 지원합니다.
| 구분 | 초기 비용 | 운영 비용 | 응답 속도 영향 |
|---|---|---|---|
| 프롬프트 엔지니어링 | 거의 없음 | 토큰량 증가로 서서히 상승 | 프롬프트 길수록 지연 증가 |
| RAG | 검색 인프라 구축 필요 | 벡터DB 운영·임베딩 비용 지속 발생 | 검색 단계만큼 지연 추가 |
| 파인튜닝(LoRA 기준) | 학습 시점 1회 목돈 | 추론 비용은 기본 모델과 유사 | 검색 단계 없어 상대적으로 빠름 |
유지보수 부담은 어느 쪽이 더 무겁나요
RAG는 문서만 갈아 끼우면 최신 정보가 즉시 반영됩니다. 회사 정책이나 상품 정보처럼 자주 바뀌는 내용을 다룬다면, 문서 저장소만 업데이트하면 되는 RAG 쪽이 운영 부담이 훨씬 가볍습니다.
파인튜닝된 모델은 그렇지 않습니다. 정보가 바뀌면 학습 데이터를 다시 만들고 재학습을 돌려야 하는데, 이 과정에서 기존에 잘 되던 답변 패턴이 흐트러지는 “파괴적 망각” 문제가 종종 나타납니다. 재학습 주기가 짧은 도메인이라면 이 비용이 누적되어 생각보다 부담이 커집니다.
버전 관리 측면에서도 차이가 있습니다. 파인튜닝 모델은 학습 시점의 스냅샷이라 어떤 데이터로 언제 학습했는지 이력을 꼼꼼히 관리해야 하고, 원본 베이스 모델이 사용 중단(deprecated)되면 그 위에 얹은 파인튜닝 모델도 함께 못 쓰게 되는 경우가 있습니다. RAG는 베이스 모델을 자유롭게 교체할 수 있어 이런 리스크에서 비교적 자유롭습니다.
그래서 파인튜닝은 언제, 어떤 조건에서 선택하나요
파인튜닝이 유리한 조건은 명확합니다. 출력 형식을 엄격하게 고정해야 하거나(예: 특정 JSON 스키마 준수), 특정 말투·문체를 대량으로 반복 재현해야 하거나, 프롬프트에 매번 넣기엔 예시가 너무 길어서 토큰 비용이 부담스러울 때입니다.
반대로 파인튜닝이 안 통하는 경우도 있습니다. “최신 뉴스에 답하게 해달라”거나 “우리 회사 매뉴얼 내용을 정확히 인용하게 해달라”는 요구는 파인튜닝만으로는 잘 해결되지 않습니다. 모델이 학습 데이터의 패턴은 흉내 내지만, 정확한 사실 인용은 보장하지 못하기 때문입니다. 이런 경우는 RAG로 근거 문서를 직접 붙여주는 쪽이 훨씬 안정적입니다.
실무에서는 아래처럼 두 기술을 함께 쓰는 경우가 많습니다. 답변 형식과 말투는 파인튜닝으로 고정하고, 사실 정보는 RAG로 채워 넣는 방식입니다.
# OpenAI 파인튜닝 잡 생성 예시 (openai python SDK 기준)
from openai import OpenAI
client = OpenAI()
job = client.fine_tuning.jobs.create(
training_file="file-abc123",
model="gpt-4o-mini-2024-07-18"
)
print(job.status) # "validating_files" 등으로 시작
이 코드는 사전에 jsonl 형식으로 준비한 학습 데이터를 업로드해 얻은 파일 ID(training_file)를 넘겨 파인튜닝 작업을 생성하는 실제 API 호출 구조입니다. 세부 파라미터와 지원 모델 목록은 위에서 링크한 OpenAI 공식 가이드에서 최신 상태를 확인하는 편이 안전합니다. 자체 서버에서 오픈소스 모델을 다룬다면 Hugging Face의 PEFT/TRL 라이브러리로 LoRA 파인튜닝을 진행하는 경로도 널리 쓰입니다.
파인튜닝을 했는데 왜 여전히 환각이 나오나요
이 질문을 실제로 자주 받습니다. 원인은 파인튜닝이 “지식 주입”이 아니라 “행동 패턴 학습”이라는 점에 있습니다. 모델은 학습 데이터에 있던 답변 스타일과 구조는 잘 흉내 내지만, 학습 데이터에 없던 질문이 들어오면 그 스타일 그대로 그럴듯한 오답을 만들어냅니다.
오히려 파인튜닝을 거치면 모델이 특정 형식으로 더 “자신 있게” 답하도록 학습되기 때문에, 틀린 내용도 확신에 찬 어조로 내놓아 환각이 더 눈에 띄는 경우도 있습니다. 사실 정확도가 핵심이라면 파인튜닝보다 RAG로 근거 문서를 강제로 참조시키는 구조가 우선입니다.
지금 프로젝트라면 이 기준으로 순서를 정해 보세요
먼저 프롬프트 엔지니어링으로 원하는 출력 형태가 나오는지 시험해 보는 편이 비용 대비 가장 빠릅니다. 그다음 정보가 자주 바뀌거나 사실 근거가 중요하다면 RAG를 붙이고, 형식·말투를 대량으로 고정해야 하거나 프롬프트 토큰 비용이 누적되어 부담스러워질 때 마지막으로 파인튜닝을 검토하는 순서가 실무적으로 안전합니다.
세 기술 중 하나만 정답으로 정해두기보다, 지금 프로젝트에서 자주 바뀌는 게 “정보”인지 “형식과 말투”인지부터 구분해 보시는 게 첫 단계입니다. 그 구분만 명확해도 파인튜닝을 할지 RAG로 갈지는 절반쯤 답이 나옵니다.
