RUDA DIRECTOR · AI 깊이 이해하기 — 자율 시스템 설계까지 · CHAPTER 09
RAG와 Fine-tuning 중 무엇을 선택해야 할까?
30초 답: 답에 필요한 사실이 없거나 자주 바뀐다면 RAG(Retrieval-Augmented Generation)로 현재 Context를 공급해야 한다. 근거는 충분하지만 형식·분류 기준·응답 방식이 반복해서 흔들린다면 Fine-tuning으로 Model의 행동을 조정할 수 있다. 둘은 경쟁 기술이 아니다. 먼저 오류를 지식·검색·행동 문제로 분해한 뒤, 필요한 축만 고르는 것이 가장 작고 검증 가능한 설계다.
OpenAI의 정확도 최적화 가이드는 최신·비공개·학습되지 않은 정보가 부족한 경우를 Context 최적화 문제로, 형식·말투·일관된 지시 수행이 흔들리는 경우를 Model 최적화 문제로 구분한다. Retrieval은 외부 데이터를 검색해 입력에 추가하고, Fine-tuning은 예시 데이터로 추가 학습해 특정 작업의 행동 패턴을 바꾼다. 따라서 “회사 문서를 학습시키고 싶다”는 한 문장만으로는 결정을 내릴 수 없다. 문서를 매번 찾아야 하는지, 반복 행동을 익혀야 하는지를 먼저 물어야 한다.
정확한 경계: RAG는 Context를 바꾸고 Fine-tuning은 Weight를 바꾼다
| 관찰된 문제 | 먼저 검토할 방법 | 이유 |
|---|---|---|
| 가격·정책·재고처럼 사실이 바뀜 | RAG | 최신 source를 추론 시점에 공급 |
| 근거는 맞지만 출력 형식·톤이 흔들림 | Fine-tuning 후보 | 반복 예시로 행동 일관성을 학습 |
| 최신 사실과 복잡한 행동이 모두 필요 | RAG + Fine-tuning 후보 | Context와 행동을 서로 다른 축에서 보완 |
| 오류 원인과 기준선이 아직 없음 | Prompt + Evaluation | 복잡도를 추가하기 전에 실패를 측정 |
RAG는 문서를 Model의 Weight에 영구 저장하는 방식이 아니다. 질문이 들어오면 검색 가능한 저장소에서 관련 chunk를 찾고, 그 결과를 Prompt의 Context에 넣은 뒤 답을 생성한다. 반대로 Fine-tuning은 입력·정답 예시로 학습을 이어가 Weight를 업데이트한다. 최신 정책을 Fine-tuning으로 외우게 하면 다음 개정 때 다시 학습해야 하고, 어떤 문서 revision에서 나온 답인지 추적하기도 어렵다. 반대로 정확한 출력 Schema를 매번 긴 Prompt와 예시로 강제하고 있다면 Fine-tuning이 일관성과 Token 효율을 개선할 후보가 될 수 있다. 단, 실제 개선 여부는 held-out Evaluation으로 확인해야 한다.
메커니즘: 데이터와 결정은 어디를 통과하는가
- 실패 수집: 틀린 답을 지식 부족, 검색 실패, 근거 해석 오류, 행동 불일치로 분류한다.
- Source 준비: RAG라면 문서 ID·revision·상태·권한을 보존해 index를 만든다. Fine-tuning이라면 실제 입력 분포를 닮은 고품질 예시와 분리된 검증 세트를 만든다.
- Runtime 처리: RAG는 query → retrieval → reranking/filtering → Context 조립 → generation 순서로 움직인다. Fine-tuned Model은 입력을 받아 학습된 행동 패턴으로 응답하지만, 최신 source를 자동 조회하지는 않는다.
- 검증: RAG는 retrieval recall과 source freshness, answer support를 각각 본다. Fine-tuning은 기준 Model 대비 held-out task 성능과 regression을 본다.
- 갱신: 문서가 바뀌면 index와 freshness 규칙을 갱신한다. 행동 기준이 바뀌면 학습 예시·평가 세트·Model revision을 함께 관리한다.
핵심은 retrieval 성공과 answer 정답을 같은 지표로 묶지 않는 것이다. 관련 문서를 찾았어도 Model이 범위를 과장할 수 있고, 올바른 행동을 학습했어도 입력에 최신 사실이 없으면 현재 값을 만들 수 없다. 관측 지점도 최소한 검색된 source revision → 사용된 chunk → 생성된 claim → claim을 지지한 근거로 분리해야 한다.
실행한 합성 실험: 문서가 바뀌면 검색은 무엇을 반환하는가
아래 실험은 실제 Model이나 실제 서비스의 성능 측정이 아니다. Python 표준 라이브러리만 사용한 결정론적 retrieval fixture다. 같은 정책의 두 revision을 만들었다. policy_v1은 적용 대상이 모든 계정, 시행일이 10월 1일이며 상태는 superseded다. policy_v2는 신규 계정, 10월 15일이며 상태는 current다. 질문은 “현재 신규 계정 정책의 적용 대상과 시행일”이다.
| 실행 경로 | 반환 | 판정 |
|---|---|---|
| 단순 단어 겹침 검색 | policy_v1 · score 4 | 관련성은 높지만 오래된 문서 |
| current 상태 필터 후 검색 | policy_v2 · score 2 | 현재 revision 반환 |
| 동적 지식 + 행동 오류 없음 | RAG | Context 축만 먼저 수정 |
| 안정된 지식 + 행동 오류 + 예시 있음 | Fine-tuning 후보 | held-out Evaluation 전제 |
| 오류는 있으나 예시·기준선 없음 | Prompt + Evaluation | 학습보다 진단이 먼저 |
관찰 결과: 단순 유사도는 질문의 단어를 더 많이 포함한 오래된 문서를 골랐다. 문서 상태를 먼저 제한하자 overlap score가 더 낮아도 현재 revision이 선택됐다. 이 결과는 특정 RAG 제품의 우수성을 증명하지 않는다. Embedding이나 keyword score만으로 freshness를 대신할 수 없고, metadata와 revision 규칙이 retrieval 계약에 포함돼야 한다는 구조적 사실을 보여준다. Fine-tuning 경로는 실제 학습을 수행하지 않았으므로 설계 후보일 뿐, 성능 개선으로 보고하지 않는다.
자주 실패하는 다섯 가지 선택
- 변하는 사실을 Fine-tuning으로 외운다. 새 revision이 나올 때 Weight가 자동으로 갱신되지 않는다. 출처와 유효 기간도 응답에서 분리하기 어렵다.
- RAG를 붙이면 사실성이 보장된다고 본다. 오래된 문서, 잘못된 권한 범위, 나쁜 chunk가 검색되면 오류에 source 모양만 더해진다.
- 검색 hit와 정답을 같은 성공으로 센다. 올바른 chunk를 찾은 뒤에도 Model이 날짜·범위·예외를 잘못 조합할 수 있다. retrieval과 claim support를 별도로 평가해야 한다.
- Training set으로 다시 평가한다. 본 예시를 재현하는 능력과 새 입력에 일반화하는 능력을 구분할 수 없다. held-out case와 기준 Model이 필요하다.
- 처음부터 RAG와 Fine-tuning을 모두 넣는다. index, 학습 데이터, Model revision, Latency, Cost, 권한, 회귀 실패 표면이 동시에 늘어난다. 오류 축이 하나라면 하나만 고쳐야 원인도 관측할 수 있다.
Trade-off: 정확도보다 운영 경계를 먼저 본다
| 선택 | 강점 | 주요 비용·위험 |
|---|---|---|
| Prompt만 사용 | 가장 빠른 기준선 | 긴 지시와 예시가 Context를 소비 |
| RAG | 최신·비공개 source와 provenance | 검색 Latency, index 갱신, 권한·Prompt Injection 표면 |
| Fine-tuning | 행동 일관성, 짧은 Prompt 가능성 | 학습·검증 Cost, dataset 편향, regression, 갱신 지연 |
| RAG + Fine-tuning | 현재 지식과 반복 행동을 함께 다룸 | 관측·배포·rollback 복잡도와 실패 표면 증가 |
권한 경계도 다르다. RAG는 사용자가 볼 수 없는 문서를 검색하지 않도록 retrieval 단계에서 access control을 지켜야 한다. Fine-tuning은 민감한 데이터를 학습 세트에 넣기 전에 보존·삭제·재학습 정책을 검토해야 한다. Cost 역시 호출당 Token만 비교하면 부족하다. RAG에는 수집·chunking·index·검색·reranking 운영이, Fine-tuning에는 데이터 정제·학습 실행·모델 버전·회귀 평가가 따라온다.
언제 RAG도 Fine-tuning도 쓰지 말아야 하나
짧은 Prompt와 몇 개의 예시로 목표 품질이 나오거나, 계산기·데이터베이스·규칙 엔진이 정확한 답을 직접 반환하는 작업이라면 두 방법 모두 과하다. 문서가 소수이고 Context 한도 안에 안정적으로 들어간다면 검색 시스템을 먼저 만들 이유도 약하다. Fine-tuning은 실패 사례와 고품질 정답 예시가 충분하지 않거나, 요구 행동이 계속 바뀌는 초기 단계에서는 특히 이르다. 이때는 Prompt, Structured Output, deterministic validation, Evaluation부터 고정하는 편이 싸고 되돌리기 쉽다.
실무 적용 원칙: 선택 전에 답할 여덟 질문
- 틀린 답은 정보 부재인가, 검색 실패인가, 행동 불일치인가?
- 필요한 사실의 변경 주기와 authoritative source는 무엇인가?
- 각 source의 ID·revision·유효 상태·접근 권한을 보존할 수 있는가?
- retrieval hit와 final claim support를 따로 측정하는가?
- Fine-tuning 후보 행동을 보여주는 대표 예시와 held-out case가 있는가?
- Prompt만 사용한 기준선보다 실제로 나아졌는가?
- Latency·Token·학습·index 운영비와 rollback 비용을 포함했는가?
- 둘을 결합해야만 해결되는 두 개의 독립된 실패 축이 관찰됐는가?
학습 결론: RAG는 Model에게 최신 사실을 “가르치는” 기술이라기보다 필요한 순간에 근거를 보여주는 기술이다. Fine-tuning은 문서 저장소를 대신하기보다 반복되는 행동을 익히게 하는 기술이다. 선택 기준은 유행이나 복잡도가 아니라, 오류가 발생한 위치다. 사실이 없으면 Context를 고치고, 행동이 흔들리면 Model을 검토하며, 아직 모르면 먼저 측정한다.
공식 참고 자료
- OpenAI — Optimizing LLM Accuracy (확인: 2026-10-02)
- OpenAI — Model Optimization (확인: 2026-10-02)
- OpenAI — Retrieval (확인: 2026-10-02)
- Anthropic — Contextual Retrieval (확인: 2026-10-02)
시리즈 탐색
Previous: Chapter 08 — AI Hallucination은 왜 생기는가: 그럴듯한 오답을 막는 검증 설계
Next: Chapter 10 — Evaluation: 정답 예시를 보고 만든 평가는 왜 믿기 어려운가
Related: Chapter 05 — Pretraining과 Post-training의 차이: 지식·행동·선호는 어디서 바뀌는가
Series start: Chapter 01 — LLM의 학습과 추론: 프롬프트를 고치면 모델도 배우는가