기반 데이터가 빈번하게 변경되거나 사용자에게 답변의 출처를 보여줘야 하는 경우에는 RAG (retrieval-augmented generation, 검색 증강 생성)를 사용하세요. 모델의 동작 방식 자체(어조, 출력 형식 또는 구조적으로 계속 틀리는 좁은 범위의 작업)가 문제라면 fine-tuning (미세 조정)을 사용하세요. 우리가 대화하는 대부분의 팀은 fine-tuning이 더 "커스텀"된 것처럼 들리기 때문에 이를 먼저 시도하지만, RAG가 훨씬 적은 비용과 복잡성으로 문제의 80%를 해결할 수 있었다는 사실을 나중에 깨닫게 됩니다.

각각이 실제로 하는 일

이 두 방식은 서로 다른 문제를 해결하며, 이를 혼동하는 과정에서 대부분의 창업자들이 몇 주를 허비하게 됩니다.

• RAG는 쿼리 시점에 관련 문서를 검색하여 이를 컨텍스트 (context)로서 프롬프트 (prompt)에 집어넣습니다. 모델의 가중치 (weights)는 전혀 변하지 않습니다. 여러분은 모델이 어떻게 "행동"하는지가 아니라, 모델이 무엇을 "아는지"를 확장하는 것입니다.
• Fine-tuning은 예시 데이터 세트를 통해 모델의 가중치를 조정합니다. 여러분은 모델에게 새로운 사실을 알려주는 것이 아니라, 모델이 어떻게 "응답"하는지(형식, 어조 또는 작업 특화된 추론 패턴)를 바꾸는 것입니다.

Lewis et al. (2020)의 원본 RAG 논문은 이를 정확히 다음과 같이 정의했습니다: 파라미터 모델 (parametric model)을 독립적으로 업데이트할 수 있는 비파라미터 메모리 (non-parametric memory)와 쌍을 이루는 것. 이것은 10년이 지난 지금도 여전히 핵심적인 트레이드오프 (tradeoff)입니다. 지식이 가중치 안에 머물기를 원하시나요, 아니면 재학습 없이 편집할 수 있는 저장소에 머물기를 원하시나요?

RAG가 승리하는 경우

다음 중 하나라도 해당된다면 RAG를 선택하세요:

RAG가 승리하는 경우

다음 중 하나라도 해당된다면 RAG를 선택하세요:

• 데이터가 매주 또는 매일 변경되는 경우. 가격표, 재고 목록, 정책 문서, 지원 티켓 등이 이에 해당합니다. 끊임없이 변하는 대상을 대상으로 Fine-tuning을 하면 지속적인 재학습이 필요합니다.
• 출처(citation)를 제시해야 하는 경우. 헬스케어, 법률, 금융 사용 사례는 일반적으로 출처를 보여줘야 합니다. RAG는 기록 추적 경로(paper trail)를 제공하지만, Fine-tuning은 감사할 수 없는 불투명한 가중치 행렬에 사실을 각인시킵니다.
• 아직 제품-시장 적합성(product-market fit) 단계가 아닌 경우. RAG를 사용하면 훈련된 아티팩트를 건드리지 않고도 기본 모델을 교체하거나 검색 로직을 조정할 수 있습니다. 저희는 RAG에 대한 개요에서 메커니즘을, 그리고 벡터 데이터베이스 설명에서 저장 계층을 다루었습니다.
• 예산이 빠듯한 경우. 훈련 실행 비용, GPU 임대료, 유지해야 할 MLOps 파이프라인이 없습니다. 업데이트 주기당이 아니라 쿼리당 비용을 지불합니다.

Fine-tuning이 승리하는 경우

Fine-tuning은 문제가 누락된 지식이 아니라 잘못된 행동일 때 그 가치를 발휘합니다:

• 모델이 계속해서 출력 형식을 무시하는 경우. 엄격한 JSON, 특정 톤, 또는 도메인별 추론 스타일(예: 분류 워크플로우)이 필요하며, 이는 프롬프팅만으로는 대규모로 일관되게 유지하기 어렵습니다.
• 올바른 행동에 대한 레이블링된 예제가 수천 개가 있고 패턴이 안정적인 경우. '새로운 사실'이라기보다는 '이 작업을 정확히 이런 방식으로 수행하라'는 지침입니다.
• 지연 시간(Latency)과 프롬프트 크기가 실제 제약 사항인 경우. 모든 RAG 쿼리는 검색 비용과 더 큰 프롬프트를 지불합니다. 만약 하루에 수백만 건의 호출을 한다면, 훈련 비용이 상각된 후에는 짧은 프롬프트로 Fine-tuning된 모델이 긴 RAG 컨텍스트보다 의미 있게 저렴하고 빠를 수 있습니다. 비용 분석에서 시간이 지남에 따라 이 숫자들이 실제로 어떻게 비교되는지 확인해 보세요.
• 도메인 어휘나 추론 패턴이 매우 특이하여 아무리 좋은 검색과 프롬프팅을 해도 범용 모델이 신뢰성 있게 안내하기 어려운 경우입니다 (예: 고도로 전문화된 임상 코딩 작업).

OpenAI의 fine-tuning (미세 조정) 문서는 fine-tuning (미세 조정)이 실제로 무엇에 유용한지에 대한 합리적인 참고 자료를 제공합니다. 즉, 새로운 사실을 주입하는 것이 아니라, 형식 준수 (format adherence), 어조 (tone), 그리고 좁은 범위의 작업 일관성 (narrow task consistency)에 유용합니다.

하이브리드 사례

실제로 가장 강력한 프로덕션 시스템은 두 가지를 모두 사용하지만, 첫날부터 동시에 사용하지는 않습니다.

1. RAG (검색 증강 생성)와 프롬프팅 (prompting)으로 출시합니다. 이는 반복 (iterate)하기 빠르고 변경 비용이 저렴합니다.
2. 모든 것을 계측 (instrument)합니다 — 모든 쿼리 (query), 검색 (retrieval), 그리고 출력을 로그 (log)로 남깁니다.
3. (가설적인 패턴이 아닌) 실제 실패 패턴이 파악되면, 문제가 되는 특정 동작에 대해 좁은 범위로 fine-tuning (미세 조정)을 수행합니다.

프로덕션 로그가 확보되기 전에 fine-tuning (미세 조정) 파이프라인을 구축하는 것은 어둠 속에서 설계하는 것과 같습니다. 실제 실패 모드 (failure modes)를 바탕으로 학습하는 대신, 무엇이 "좋은" 것인지 추측만 하게 됩니다.

실무에서 목격한 사례

저희는 잠재 고객의 사이트를 스크래핑하여 맞춤형 콜드 이메일 (cold email) 초안을 작성하는 자체 아웃리치 (outreach) 도구를 운영하고 있습니다. 저희의 첫 본능은 "적절한" 아키텍처를 구축하는 것이었습니다. 즉, 사실을 추출하고, 관련성을 추론한 다음, 초안을 작성하고, 스스로의 초안을 비판하는 에이전트 체인 (agent chain)을 만드는 것이었습니다. 하지만 이는 더 느리고 비용이 많이 들었으며, 스크래핑된 페이지를 컨텍스트 (context)로 제공하는 단일 구조화된 LLM 호출 — 본질적으로 코퍼스 (corpus) 대신 하나의 문서를 사용하는 RAG 패턴 — 보다 더 나쁜 이메일을 생성했습니다. 만약 그 단일 호출 방식이 수백 개의 이메일에 걸쳐 일관된 목소리를 유지하는 데 실패했다면 저희는 fine-tuning (미세 조정)을 고려했겠지만, 실패하지 않았습니다. 이 교훈은 일반화될 수 있습니다: 가벼운 도구가 불충분하다는 것이 증명되기 전에는 더 무거운 도구에 손을 대지 마십시오. 단 한 번의 호출로 충분할 때 과도하게 다단계 agent chain (에이전트 체인)을 구축하려는 본능은, 검색 (retrieval)으로 충분할 때 fine-tuning (미세 조정) 파이프라인을 과도하게 구축하려는 본능과 같습니다.

창업자를 위한 체크리스트

예산을 투입하기 전에 다음 질문에 답해 보십시오:

• 기초 데이터가 얼마나 자주 변경됩니까? 매일/매주 변경됨 → RAG. 거의/전혀 변경되지 않음 → 파인튜닝 (Fine-tuning)이 실행 가능함.
• 출처를 보여줘야 합니까? 예 → RAG, 또는 최소한 RAG와 파인튜닝의 결합. 파인튜닝 단독으로는 절대 불가.
• 실패 모드가 "잘못된 사실"입니까, 아니면 "잘못된 형식/행동"입니까? 잘못된 사실 → RAG. 잘못된 행동 → 파인튜닝 (Fine-tuning).
• 올바른 행동에 대한 라벨링된 예시 (Labeled examples)를 이미 보유하고 있습니까? 아니요 → 사용 사례와 상관없이 아직 파인튜닝을 할 준비가 되지 않았습니다.
• 쿼리(Query) 볼륨은 어느 정도입니까? 낮음~중간 → 쿼리당 발생하는 RAG의 오버헤드(Overhead)를 감수할 수 있음. 높고 지연 시간(Latency)에 민감함 → 파인튜닝의 분할 상환 비용 (Amortized cost)이 유리해지기 시작함.

새로 시작하는 것이 아니라 기존 제품에 둘 중 하나를 통합하려는 경우, 제품에 AI를 통합하는 가이드를 통해 모델 선택만큼이나 중요한 주변 아키텍처 결정 사항(인증, 속도 제한, 폴백(Fallback) 동작 등)을 살펴볼 수 있습니다.

두 접근 방식 중 어느 하나가 다른 방식보다 더 "고급"인 것은 아닙니다. 이들은 서로 다른 문제를 해결하며, 작동하는 제품으로 가는 가장 빠른 길은 대개 먼저 검증할 수 있는 더 저렴한 방법입니다. 귀하의 제품에 어떤 방식이 적합한지에 대해 제2의 의견이 필요하다면, 문의해 주세요.

원문은 Pykero 블로그에 게시되었습니다.