파인튜닝 vs RAG — 언제 무엇을 택해야 하나

LLM에 우리 도메인 지식을 넣고 싶을 때 늘 나오는 갈림길이 있다. 파인튜닝(fine-tuning)으로 모델 자체를 우리 데이터로 다시 학습시킬 것인가, 아니면 RAG(검색 증강)로 필요한 정보를 그때그때 찾아 넣어줄 것인가. 이 선택을 헷갈려서 비싼 파인튜닝에 시간을 쏟았다가 정작 RAG면 됐을 문제였음을 뒤늦게 깨닫는 경우가 많다.

핵심 구분을 먼저 말하면 이렇다. RAG는 모델에게 무엇을 아는지(knowledge)를 바꾸고, 파인튜닝은 모델이 어떻게 행동하는지(behavior)를 바꾼다. 이 한 줄만 붙잡아도 절반은 정리된다. 최신 정보나 사실을 주입하려면 RAG, 특정 말투·형식·작업 방식을 몸에 배게 하려면 파인튜닝이다.

RAG가 맞는 경우

대부분의 "우리 데이터로 답하게 하고 싶다"는 요구는 사실 RAG의 영역이다. 사내 문서로 질문에 답하기, 제품 매뉴얼 기반 지원 봇, 최신 정보 반영 같은 것들. RAG의 강점은 명확하다. 지식을 바꾸려면 문서만 갈아 끼우면 된다. 모델을 다시 훈련하지 않는다. 정책이 바뀌면 문서를 업데이트하는 걸로 끝이고, 어떤 문서를 근거로 답했는지 추적도 된다. 틀린 정보가 있으면 그 문서만 고치면 된다.

파인튜닝이 맞는 경우

파인튜닝은 지식 주입 도구가 아니라 행동 교정 도구다. 이럴 때 값을 한다.

• 일관된 형식·말투 — 항상 정해진 톤이나 구조로 출력하게 만들고 싶을 때. 프롬프트로 매번 지시하기 번거로운 스타일을 몸에 배게 한다.
• 특수한 작업 패턴 — 프롬프트로 설명하기 힘든 미묘한 판단이나 분류를, 예시로 학습시켜 안정화할 때.
• 프롬프트 절약 — 매 요청에 긴 지시와 예시를 붙이던 걸 모델에 내재화해, 프롬프트를 짧게 하고 비용·지연을 줄일 때.

주의할 건, 파인튜닝으로 사실을 주입하려는 시도다. 특정 지식을 학습시켜도 모델은 그걸 어중간하게 기억하고, 정보가 바뀌면 다시 훈련해야 하며, 없는 사실을 지어내는 경향은 여전하다. 사실은 RAG로 넣는 게 맞다.

순서가 중요하다

실무 원칙은 이렇다. 프롬프트 → RAG → 파인튜닝 순으로 올라간다. 먼저 프롬프트만으로 될지 본다. 안 되면, 사실·지식 문제인지 행동 문제인지 나눈다. 지식이면 RAG. 프롬프트와 RAG로도 스타일·패턴이 안 잡히면, 그때 파인튜닝을 검토한다. 파인튜닝을 맨 앞에 두는 건 대개 비싼 우회로다. 데이터를 모으고 훈련하고 관리하는 부담이 크기 때문이다.

둘을 함께

가장 강력한 조합은 둘을 함께 쓰는 것이다. 파인튜닝으로 우리 도메인의 말투와 작업 방식을 새기고, RAG로 최신 사실을 실시간 주입한다. 행동은 모델에, 지식은 검색에 맡기는 것이다. 이러면 각자의 약점을 서로가 메운다. 다만 이건 두 방식을 다 다뤄본 뒤에 얹는 최적화지, 처음부터 벌일 일은 아니다.

자주 묻는 질문

우리 회사 문서로 답하게 하려면 파인튜닝인가요?

대개는 RAG가 맞다. 문서의 사실을 근거로 답하는 건 지식 주입이고, 그건 검색으로 그때그때 넣어주는 게 유연하고 저렴하다. 문서가 바뀌어도 재훈련 없이 교체만 하면 되고, 어떤 문서를 근거로 답했는지 추적도 된다. 파인튜닝으로 문서 내용을 학습시키는 건 갱신과 정확성 면에서 비효율적인 경우가 많다.

파인튜닝하면 환각이 사라지나요?

기대만큼은 아니다. 파인튜닝은 행동과 스타일을 바꾸는 데 강하지만, 없는 사실을 지어내는 성향 자체를 없애주진 않는다. 오히려 학습 데이터에 없는 걸 물으면 그럴듯하게 꾸며낼 수 있다. 사실 정확성이 목표라면, 근거 문서를 함께 제시하는 RAG가 환각 억제에 더 직접적으로 기여한다.

언제 파인튜닝을 진지하게 고려하나요?

프롬프트와 RAG로도 원하는 출력 형식·말투·판단 패턴이 안정적으로 안 나올 때다. 매 요청에 긴 지시와 예시를 붙여야 겨우 되는 상황이라면, 그 패턴을 모델에 내재화해 프롬프트를 줄이는 이점도 있다. 다만 충분한 양질의 예시 데이터와 유지·재훈련 부담을 감당할 수 있을 때 값을 한다는 점을 전제로 판단해야 한다.