RAG vs Fine-tune — 2026년 시점의 결정 가이드
2023년 답: 거의 항상 RAG. 2026년 답: *조건부*. 4가지 결정 변수와, 둘을 *조합* 하는 게 답인 케이스.
2023년의 답은 깔끔했다 — RAG 가 거의 항상 답. 2024년에 fine-tuning 비용 = $thousands per run, RAG 비용 = vector DB 운영비. fine-tune 의 데이터 큐레이션 + retrain 사이클 도 컸다.
2026년 답은 조건부 다. 4 변수가 결정을 가른다.
변수 1 — 지식이 변하는 빈도
변경 빈도 | 권장
─────────────────────────┼──────────────
주 1회 이상 | RAG (fine-tune 따라잡지 못함)
월 1회 | RAG
분기 1회 | 둘 다 OK
연 1회 | fine-tune 가능
거의 안 변함 | fine-tune 권장지식이 자주 변하는 도메인 (회사 정책, 신규 제품 기능, 시장 데이터) = RAG. 거의 안 변하는 도메인 (의학 분야 기초, 법조문 해석, 회사 style guide) = fine-tune.
변수 2 — 검색의 정확도
RAG 의 핵심은 검색. 검색이 정확하면 RAG 는 fine-tune 보다 좋음. 부정확하면 fine-tune 보다 나쁨.
검색 정확도 (top-1 hit rate) | 권장
─────────────────────────────┼──────────────
> 80% | RAG
60~80% | RAG + fine-tune 조합
< 60% | fine-tune검색 정확도는 embedding model + chunking 전략 으로 결정. 기본 OpenAI ada-002 + 1024 토큰 chunk 면 보통 60~70%. 도메인 특화 embedding 으로 5~10% 추가.
변수 3 — style / format 일관성 요구
도메인 지식 정확도가 아니라 답변의 form 자체 가 정해져 있어야 하는 경우. 예:
- 모든 답변이 한국어 존댓말 (반말 X)
- 모든 답변이 3 문단 (긴 글 X)
- 모든 답변이 우리 회사의 톤
이런 style 통일 은 RAG 로 어려움. system prompt 로 강제 도 부분적. fine-tune 이 답.
CollabOps 사례 — 사용자에게 답변할 때 우리 톤 (특정 단어 우선, 특정 표현 회피). RAG + system prompt 만으로는 80% 일관성. fine-tune 후 95%+.
변수 4 — 비용 함수
시나리오 | RAG 비용 | Fine-tune 비용
──────────────────────────────────┼─────────────┼────────────────
초기 셋업 | $5,000 | $30,000+ (데이터 큐레이션 80%)
월 운영 비용 | $1,500 | $300 (단순 inference)
지식 갱신 (월 1회) | $200 | $5,000 (re-train)
모델 갱신 (분기 1회, 새 base 모델)| $0 | $30,000 (재 fine-tune)지식이 자주 갱신되거나 base 모델이 자주 변하면 RAG 압도적으로 싸다. 반대 시나리오면 fine-tune.
우리 결정 — 조합
CollabOps 의 결정은 둘 다 사용:
용도 | 방법
──────────────────────────┼────────────────────────────
도메인 지식 (자주 변함) | RAG (Pinecone + GPT-4)
회사 톤 / 답변 form | Fine-tune (Llama 3 base + 약 800 예시)
사용자 인터페이스 응답 | RAG + fine-tune 모델 (둘이 함께)
배경 분석 / 리포트 | RAG + 큰 모델 (Claude Opus)이 조합이 6개월 후 정착한 답. 처음엔 RAG 만 시도, style 일관성 약함을 알고 fine-tune 추가.
권장 의사결정 흐름
1. 지식이 자주 변하나?
예 → RAG
아니오 → 다음
2. 답변 form / style 의 일관성 요구가 있나?
예 → fine-tune (또는 RAG + fine-tune 조합)
아니오 → 다음
3. 검색 정확도가 80%+ 가능한가?
예 → RAG
아니오 → fine-tune
4. 둘 다 답이라면 — *비용 함수* 가 가르는 변수누가 이 글을 읽으면 좋은가
지금 LLM 기반 도메인 시스템 을 설계 중인 모든 팀. 기본 가정 으로 RAG 를 잡고 시작 — 그러나 위 4 변수 점검 후 fine-tune 또는 조합 의 답이 나올 수 있음. 처음에 잘 결정하면 6개월 후 재설계 비용 ↓.
비슷한 글
에이전틱 DevOps 12개월 후 — 첫 가설 중 무엇이 *맞았고* 무엇이 *틀렸나*
12개월 전 다음 10년의 DevOps는 에이전틱이다 의 가설들. 12개월의 데이터로 어느 가설이 맞고 어느 게 틀렸는지의 정직한 평가.
백재민
3 pillars 그 후 — 4 추가 신호의 *6개월 후* 운영 노트
3 pillars 가 더 이상 충분하지 않은 이유 발행 후 6개월. 4 추가 신호 (events / user journeys / deploy correlation / similarity) 가 운영에서 어떻게 작동했는지의 후속.
백재민
GitHub Actions vs 자체 호스팅 — *진짜 비용* 비교 (12개월 데이터)
GitHub Actions 가 *비싸 보임* 은 표면. 12개월 자체 호스팅 vs SaaS 비교 — 단순 *분당 비용* 이 아니라 *총 운영 비용* 으로.
백재민