현재 기업용 AI에서 가장 비싼 실수는 검색(Retrieval)이 실제 정답인 상황에서 파인튜닝(Fine-tuning)을 수행하는 것입니다.

예상보다 더 많은 비용이 드는 결정
기업용 AI 프로젝트에 도메인 특화 지식(domain-specific knowledge)이 필요할 때, 두 가지 경로가 명확해 보입니다. 데이터를 사용하여 모델을 파인튜닝(Fine-tune)하거나, 쿼리 시점에 모델에 데이터를 공급하는 검색 시스템(retrieval system)을 구축하는 것입니다.
대부분의 팀은 이 문제를 두고 몇 주 동안 토론합니다. 그러고 나서 잘못된 선택을 합니다.
LLM을 프로덕션에 배포하는 기업용 AI 팀의 70% 이상이 RAG를 주요 지식 근거(knowledge-grounding) 기술로 사용합니다. 파인튜닝(Fine-tuning)을 단독 접근 방식으로 사용하는 팀은 25% 미만입니다. 파인튜닝을 먼저 시도했다가 RAG로 전환한 팀들은 고통스러운 경험을 통해 한 가지 사실을 배웠습니다. 바로 파인튜닝(Fine-tuning)은 대부분의 기업 팀이 실제로 직면한 문제와는 다른 문제를 해결한다는 것입니다.

파인튜닝(Fine-tuning)이 실제로 하는 일
파인튜닝(Fine-tuning)은 모델이 행동하는 방식을 바꿉니다. 제공된 예시를 바탕으로 모델의 가중치(weights)를 조정하여, 모델이 다르게 추론하거나, 출력을 다르게 형식화하거나, 귀사의 용어를 사용하거나, 귀사의 브랜드 보이스를 채택하도록 만듭니다.
파인튜닝(Fine-tuning)이 하지 못하는 것은 모델이 이전에 알지 못했던 특정 사실에 대해 신뢰할 수 있는 접근 권한을 부여하는 것이 아닙니다.
이것이 대부분의 값비싼 파인튜닝(Fine-tuning) 프로젝트의 근본적인 오해입니다. 팀들은 모델을 자신들의 문서로 학습시키면, 질문을 받았을 때 해당 문서를 신뢰성 있게 회상할 것이라고 가정합니다. 그렇지 않습니다. 특정 코퍼스(corpora)로 학습된 LLM은 해당 코퍼스에서 통계적 패턴을 학습합니다. 코퍼스에 대한 쿼리 가능한 인덱스(queryable index)를 생성하는 것이 아닙니다. 파인튜닝(Fine-tuning)된 모델에게 특정 문서의 특정 조항에 대해 구체적인 질문을 던지면, 모델은 학습 데이터의 패턴을 기반으로 그럴듯하게 들리는 답변을 생성할 것입니다. 때때로 그 답변은 정확할 수 있습니다. 하지만 종종 그것은 자신감 있는 근사치(confident approximation)일 뿐입니다.
LoRA를 사용하여 7B 파라미터 모델을 파인튜닝(Fine-tuning)하는 데는 GPU 컴퓨팅 비용이 300달러에서 800달러가 듭니다. 40B 모델을 전체 파인튜닝(Full fine-tuning)하는 비용은 1회 실행당 35,000달러를 초과합니다.

그리고 이는 지식 베이스(knowledge base)가 변경될 때마다 요구되는 데이터 준비(data preparation), 평가(evaluation), 배포(deployment), 그리고 재학습(retraining) 실행 비용을 고려하기 전의 이야기입니다.

RAG가 실제로 해결하는 것
RAG는 모델의 동작 방식(behavior)을 바꾸지 않습니다. 대신 모델이 답변할 때 접근할 수 있는 정보가 무엇인지를 바꿉니다.
RAG 시스템은 주어진 쿼리(query)에 대해 구체적이고, 최신이며, 권위 있는 문서를 검색하여 이를 컨텍스트(context)로서 모델에 직접 전달합니다. 모델은 검색된 콘텐츠를 읽고 그에 기반하여(grounded) 답변을 생성합니다. 문서가 변경되면 인덱스(index)를 업데이트하기만 하면 됩니다. 모델은 업데이트된 버전을 바탕으로 자동으로 답변합니다. 재학습(retraining)이 필요하지 않습니다.
잘 조정된 검색 파이프라인(retrieval pipelines)을 갖춘 엔터프라이즈 RAG 시스템은 85%에서 90%의 답변 정확도를 달성합니다. 단순한(Naive) RAG 구현은 10%에서 40%만을 달성합니다. 파인튜닝(Fine-tuning)은 사실적 회상(factual recall) 작업에서 이 격차를 줄이지 못하는데, 그 이유는 이 격차가 모델의 동작 문제가 아니라 검색(retrieval) 문제이기 때문입니다.
시간 경과에 따른 비용 비교를 통해 상황은 더욱 명확해집니다. 프로덕션 RAG 시스템을 구축하는 데는 18,000달러에서 45,000달러가 들며, 중앙값은 약 28,000달러입니다. 지속적인 유지보수에는 인프라 비용 외에 매달 5~10시간의 엔지니어링 시간이 소요됩니다. 지식 베이스가 크게 변경될 때마다 재학습이 필요한 회당 35,000달러의 파인튜닝 비용은 빠르게 누적됩니다. 만약 데이터가 분기별로 변경된다면, 초기 구축 비용을 제외하고도 1년 차 비용만 140,000달러를 초과할 수 있습니다.
임베딩 모델(embedding model) 가격이 하락함에 따라 2026년 1분기 RAG 비용은 추가로 30% 감소했습니다. 반면 파인튜닝 비용은 대략 안정적인 상태를 유지하고 있습니다. 격차는 점점 더 벌어지고 있습니다.

정답을 밝혀내는 질문

논쟁을 즉시 종결시킬 수 있는 질문이 하나 있습니다. 바로 "데이터가 변경되는가?"입니다.

만약 대답이 "예"라면, RAG가 거의 확실히 올바른 선택입니다. 데이터가 변경될 때마다 모델이 그 변경 사항을 반영해야 한다면, 파인튜닝 (Fine-tuning)은 전체 재학습 (Retraining) 과정을 요구합니다. 분기별로 내부 정책을 업데이트하는 기업, 규제 문서를 지속적으로 업데이트하는 은행, 매 릴리스마다 도움말 문서를 업데이트하는 SaaS 제품 등, 각 사례에서 파인튜닝은 데이터 변경 속도에 따라 가중되는 유지보수 부담을 초래합니다.

RAG는 이를 자동으로 처리합니다. 새로운 문서가 인덱싱 (Indexing)됩니다. 검색 시스템 (Retrieval system)이 이를 찾아냅니다. 모델은 재학습 없이도 최신 정보를 바탕으로 답변합니다.

두 번째로 똑같이 중요한 질문은 다음과 같습니다. "사용자가 답변의 출처를 알아야 하는가?"

파인튜닝은 모델에게 출처를 밝힐 수 없는 지식을 부여합니다. 모델은 학습 데이터 (Training data)에 포함되어 있었기 때문에 무언가를 알고 있지만, 그 답변이 어떤 문서, 어떤 문단, 혹은 정책의 어떤 버전에서 왔는지는 말해줄 수 없습니다. 규제가 엄격한 산업, 법률적 맥락, 혹은 감사 가능성 (Auditability)이 중요한 모든 환경에서 이는 결격 사유가 되는 한계점입니다.

RAG는 인용 (Citation)에 최적화되어 있습니다. 검색된 청크 (Chunks)는 명시적이며, 로그가 남고, 추적 가능합니다. 만약 모델이 무언가를 잘못 인용하더라도, 무엇이 왜 검색되었는지 정확히 추적할 수 있습니다. 사용 사례에서 "그 정보를 어디서 가져왔는지 보여달라"는 요구가 있다면, RAG가 유일한 실질적인 선택지입니다.

파인튜닝 (Fine-tuning)이 실제로 의미 있는 경우

파인튜닝 (Fine-tuning)이 항상 틀린 답인 것은 아닙니다. 사실적 회상 (Factual recall) 측면에서는 틀린 답이지만, RAG가 해결할 수 없는 특정 문제 세트에 대해서는 정답입니다.

출력 형식의 일관성 (Output format consistency)이 가장 명확한 사례입니다. 만약 귀하의 AI 시스템이 특정 스키마(Schema)를 가진 구조화된 JSON을 생성해야 하거나, 정밀한 형식의 법률 문서를 작성해야 하거나, 조직 특유의 스타일로 코드를 작성해야 한다면, 파인튜닝 (Fine-tuning)은 프롬프트 엔지니어링 (Prompt engineering)만으로는 신뢰성 있게 달성할 수 없는 방식으로 모델의 출력 동작을 형성합니다.

도메인 추론 패턴 (Domain reasoning patterns)이 두 번째 사례입니다. 의학 문헌으로 파인튜닝 (Fine-tuning)된 모델은 단순히 의학적 사실만을 아는 것이 아닙니다. 의사가 하는 방식대로 의학적 문제에 대해 추론하는 법을 배웁니다. 그 추론 스타일은 가중치 (Weights)에 인코딩되어 쿼리 전반에 걸쳐 전달되며, 이는 학습 데이터에 포함되지 않았던 쿼리에도 적용됩니다.

대량의 좁은 범위 작업 (High-volume narrow tasks)이 세 번째 사례입니다. 만약 귀하의 시스템이 매우 제한된 작업에 대해 하루에 수백만 개의 쿼리를 처리한다면, 파인튜닝 (Fine-tuning)된 더 작은 모델이 대규모 범용 모델에 RAG 오버헤드를 더한 것보다 쿼리당 비용이 현저히 저렴할 수 있습니다. 좁은 범위에서 하루에 수백만 건의 API 호출이 발생하는 경우, 파인튜닝 (Fine-tuning)된 7B 모델은 프런티어 모델 (Frontier model)보다 실행 비용을 70%에서 90%까지 낮출 수 있습니다.

2026년 대부분의 기업 팀을 위한 실질적인 해답은 이분법적인 선택이 아닙니다. 2025년과 2026년에 걸친 프로덕션 배포 사례를 보면, 약 60%의 프로젝트가 두 가지를 모두 사용합니다. 모델의 동작, 출력 형식, 그리고 추론 스타일을 위해서는 파인튜닝 (Fine-tuning)을 수행하십시오. 모델이 행동하는 데 필요한 구체적이고 최신인 정보를 제공하기 위해서는 RAG를 사용하십시오. 이 두 가지 접근 방식은 상호 보완적입니다. 이들을 경쟁 관계인 옵션으로 취급하는 팀은 대개 잘못된 것을 최적화하고 있는 것입니다.

더 빠른 프로덕션(Production) 경로

어디서부터 시작할지 고민하는 팀에게 정답은 거의 언제나 RAG를 먼저 시작하는 것입니다.
잘 구축된 RAG 시스템은 4주에서 8주 안에 프로덕션(Production) 단계에 도달합니다. 데이터 준비, 학습 실행(training runs), 평가 및 배포를 포함한 파인튜닝(Fine-tuning)은 일반적으로 3개월에서 6개월이 소요됩니다. AI의 가치를 증명해야 한다는 압박을 받는 기업 팀에게는 비용 차이만큼이나 시간 차이도 중요합니다.

RAG로 시작하십시오. 고품질의 청킹(chunking), 높은 재현율(high-recall)을 가진 벡터 데이터베이스(vector database), 그리고 재순위화(re-ranking) 단계를 의미하는 검색 레이어(retrieval layer)를 올바르게 구축하십시오. 귀하의 특정 쿼리에 대한 정확도를 측정하십시오. 검색이 잘 작동한 후에도 모델의 출력 동작(output behaviour)을 여전히 조정해야 한다면, 검색으로 해결할 수 없는 동작 문제들을 위해 파인튜닝(Fine-tuning)을 추가하십시오.

이 순서를 따르는 대부분의 팀은 검색(retrieval)만으로도 원래 파인튜닝을 통해 해결하려고 계획했던 문제의 80%에서 90%를 해결할 수 있다는 사실을 발견합니다. 파인튜닝이 필요한 나머지 문제들은 규모가 더 작고, 더 명확하게 정의되어 있으며, 원래의 전체 파인튜닝 프로젝트를 수행하는 것보다 훨씬 저렴하게 해결할 수 있습니다.

Endee는 독립적인 벤치마크에서 가장 높은 재현율(recall)을 제공하는 오픈 소스 벡터 데이터베이스(Apache 2.0)입니다. 이는 RAG를 실제로 작동하게 만드는 검색 기반(retrieval foundation)입니다. endee.io에서 무료로 시작할 수 있습니다.