Tech Blog

-tuning vs RAG — 언제 무엇을 선택해야 하는가

조회 51
-tuning vs RAG — 언제 무엇을 선택해야 하는가

온프레미스 LLM을 도입하기로 결정한 다음, 가장 많이 받는 질문이 있습니다.

"Fine-tuning을 해야 하나요, RAG를 써야 하나요?"

정답은 "상황에 따라 다릅니다"입니다. 그러나 이 말은 너무 무책임합니다. 바능이 실제 프로젝트에서 겪은 경험을 바탕으로, 언제 무엇을 선택해야 하는지 명확한 기준을 제시합니다.


두 기술의 본질적 차이

Fine-tuning

모델 자체를 전문가로 만든다

학습 데이터를 모델 가중치에 직접 반영. 한번 학습하면 추론 시 외부 검색 없이 즉시 응답. 스타일·어조·도메인 지식을 모델에 내재화.

RAG

모델에게 실시간으로 자료를 찾아준다

질문이 들어올 때마다 Vector DB에서 관련 문서를 검색해 모델에 제공. 지식이 DB에 있어 실시간 업데이트 가능. 모델 재학습 불필요.


Fine-tuning을 선택해야 할 때

1. 응답 스타일·형식이 일정해야 할 때

금융 보고서, 법률 문서, 공공기관 공문처럼 특정 형식과 어조가 엄격하게 요구되는 경우입니다. RAG는 검색된 문서를 참고해 답을 생성하지만, 출력 형식을 일관되게 통제하기 어렵습니다. Fine-tuning은 "항상 이런 형식으로 써라"를 모델에 직접 학습시킵니다.

바능 적용 사례

SK AX 프로젝트에서 사내 개발 가이드 문서를 Fine-tuning 데이터로 활용해, 항상 사내 표준 포맷으로 코드 리뷰 코멘트를 생성하도록 모델을 학습시켰습니다.

2. 도메인 전문 용어를 정확히 이해해야 할 때

"원리금균등상환", "HBM(High Bandwidth Memory)", "전자정부프레임워크" 같은 도메인 특화 용어는 범용 모델이 잘못 해석하거나 무시하는 경우가 있습니다. Fine-tuning으로 이 용어들의 정확한 의미와 문맥을 모델에 학습시키면 정확도가 크게 올라갑니다.

3. 응답 속도가 매우 중요할 때

RAG는 추론 전에 Vector DB 검색 과정이 추가됩니다. 실시간 챗봇처럼 200ms 이하의 응답이 필요한 경우, 검색 레이턴시가 부담이 됩니다. Fine-tuned 모델은 외부 검색 없이 바로 응답하므로 속도에서 유리합니다.


RAG를 선택해야 할 때

1. 지식이 자주 바뀔 때

Fine-tuning은 학습 후 모델 가중치가 고정됩니다. 새로운 정보를 반영하려면 재학습이 필요합니다. 반면 RAG는 Vector DB에 문서를 추가하거나 수정하기만 하면 즉시 반영됩니다. 법령·규정처럼 개정이 잦은 도메인, 매일 갱신되는 시장 데이터 등에 적합합니다.

바능 적용 사례

카카오뱅크 프로젝트에서 금융 상품 약관·금리 정보는 자주 변경됩니다. RAG로 구성해 약관 DB만 업데이트하면 모델 재학습 없이 최신 정보를 반영하도록 했습니다.

2. 답변의 근거를 보여줘야 할 때

RAG는 검색된 문서를 기반으로 답변을 생성하므로, "이 내용은 [문서명] p.23에서 가져왔습니다"처럼 출처를 함께 제공할 수 있습니다. 금융·법률·공공 도메인에서 Hallucination(모델이 사실이 아닌 내용을 자신 있게 말하는 현상)을 방지하는 데 매우 효과적입니다.

3. 학습 데이터 확보가 어려울 때

Fine-tuning은 고품질의 학습 데이터가 수천~수만 건 필요합니다. 데이터가 부족하거나 레이블링 비용이 클 때, RAG는 기존 문서를 그대로 Vector DB에 넣어 활용할 수 있어 초기 구축 비용이 낮습니다.


바능의 선택 기준표

판단 기준 Fine-tuning RAG
지식 업데이트 빈도 낮음 (분기~연간) 높음 (일~주 단위)
응답 형식 일관성 매우 중요 보통
출처·근거 제공 필요 어려움 용이
초기 구축 비용 높음 (데이터 수집·레이블링) 낮음
응답 속도 빠름 검색 레이턴시 추가
Hallucination 위험 존재 낮음 (출처 기반)
도메인 용어 정확도 높음 보통

바능의 실전 접근법 — 둘 다 쓴다

실제 프로젝트에서 Fine-tuning과 RAG는 경쟁 관계가 아닙니다. 바능은 두 기술을 레이어로 쌓는 방식을 선호합니다.

바능의 Hybrid 아키텍처

  1. 베이스 모델 Fine-tuning — 도메인 용어·응답 형식·어조를 모델에 내재화
  2. RAG 레이어 추가 — 자주 바뀌는 최신 정보(규정·상품 데이터)는 Vector DB에서 실시간 검색
  3. 출처 명시 — 검색된 문서의 출처를 응답과 함께 제공해 신뢰도 확보

예를 들어 SK AX 개발생산성 혁신 프로젝트에서 바능이 구성한 방식은 이렇습니다. 사내 코딩 컨벤션과 아키텍처 가이드를 Fine-tuning으로 모델에 학습시키고, 매일 갱신되는 이슈 트래커와 API 명세는 RAG로 실시간 검색해 답변에 반영했습니다. 그 결과 "사내 기준에 맞는 코드를 생성하면서, 최신 이슈도 반영하는" 개발 어시스턴트를 만들 수 있었습니다.


마치며 — 기술보다 문제 정의가 먼저

"Fine-tuning이 좋은가, RAG가 좋은가"는 잘못된 질문입니다. 올바른 질문은 이것입니다.

"이 시스템에서 AI가 틀리면 어떤 문제가 생기는가? 그리고 지식은 얼마나 자주 바뀌는가?"

이 두 질문에 대한 답이 나오면, 기술 선택은 자연스럽게 따라옵니다. 바능은 프로젝트 초기에 이 질문을 클라이언트와 함께 정의하는 것부터 시작합니다.

LLM 아키텍처 설계를 고민 중이라면, 바능과 먼저 이야기해 보세요.