몇 달에 한 번씩, 어떤 고객들은 자신들에게 잘 구성된 검색 시스템(retrieval system)이 실제로 필요한 상황임에도 불구하고, 맞춤형 AI 모델을 훈련해야 한다고 확신하며 제 앞에 앉곤 합니다. 이러한 혼란은 이해할 수 있습니다. 업계에서는 "Fine-tuning (미세 조정)"과 "RAG (검색 증강 생성)"를 서로 경쟁하는 종교처럼 다루지만, 실제로는 이들이 근본적으로 다른 문제를 해결하기 때문입니다. Web3, 토큰화(tokenization), 디지털 포렌식 분야에서 20년 동안 시스템을 구축하며 제가 배운 것은, 여기서 잘못된 선택을 하면 수억 원의 비용과 수개월의 엔지니어링 낭비를 초래할 수 있다는 점입니다.

각 접근 방식이 진정으로 제 역할을 하는 시점을 설명해 드리겠습니다.

각 기술이 실제로 하는 일

**Fine-tuning (미세 조정)**은 모델의 내부 가중치(internal weights)를 조정하여 새로운 행동(behaviors), 어조, 또는 추론 패턴을 가르칩니다. 즉, 모델이 어떻게 생각하는지를 바꾸는 것입니다. 이는 비용이 많이 듭니다. LoRA와 같은 매개변수 효율적(parameter-efficient) 방법론을 사용하더라도, 깨끗하게 라벨링된 데이터셋(종종 1,000개 이상의 고품질 예시 필요), GPU 시간, 그리고 지식이 바뀔 때마다 재학습 파이프라인이 필요합니다.

**RAG (Retrieval-Augmented Generation, 검색 증강 생성)**는 모델을 건드리지 않습니다. 대신, 쿼리 시점에 관련 문서를 가져와 프롬프트(prompt)에 주입합니다. 이는 모델이 추론하는 방식이 아니라, 모델이 무엇을 아는지를 바꾸는 것입니다. 업데이트는 벡터 데이터베이스(vector database)에 문서를 추가하는 것만큼 간단합니다.

제가 자주 공유하는 구체적인 수치가 있습니다. 제 프로젝트 중 하나에서 특화된 법률 작업을 위해 7B 파라미터 모델을 Fine-tuning 하는 데 컴퓨팅 비용으로 약 $4,000와 3주간의 데이터 준비 시간이 소요되었습니다. 반면, 그와 대등한 RAG 파이프라인은 4일 만에 인프라 비용 $300 미만으로 가동되었습니다. 또한 RAG 버전은 감사 가능(auditable) 했습니다. 이는 어떤 소스가 정확히 답변을 생성했는지 증명해야 하는 포렌식급 시스템을 작업할 때 매우 중요합니다.

RAG를 선택해야 할 때

당신의 과제가 **행동(behavior)**이 아닌 **지식(knowledge)**에 관한 것이라면 RAG를 선택하십시오. 구체적으로는 다음과 같습니다:

• 빈번하게 변경되는 데이터 (Frequently changing data). 제가 자문을 맡았던 Stellar 기반 토큰화 플랫폼의 경우, 규제 문서와 자산 메타데이터가 매주 변경되었습니다. 모델을 매주 재학습(Retraining)시키는 것은 비이성적이지만, 벡터 인덱스(Vector index)를 업데이트하는 것은 매우 간단합니다.
• 감사 가능성 요구사항 (Auditability requirements). 디지털 포렌식(Digital forensics) 분야에서는 정확한 출처를 인용해야 합니다. RAG는 추적 가능한 참조를 제공하지만, 파인튜닝(Fine-tuned)된 모델은 근거가 없는 확신에 찬 환각(Hallucinations)을 제공할 뿐입니다.
• 대규모의 희소 지식 베이스 (Large, sparse knowledge bases). 데이터가 수백만 개의 문서로 구성되어 있지만 개별 쿼리가 그중 극히 일부만 다루는 경우, 모든 것을 가중치(Weights)에 밀어 넣는 것보다 검색(Retrieval) 방식이 훨씬 더 잘 확장(Scale)됩니다.

André Dias Moreira Prol로서, 저는 기업용 유스케이스(Use cases)의 약 80%에 대해 기본적으로 RAG를 선택합니다. 그 이유는 대부분의 비즈니스 문제가 본질적으로 지식 문제이기 때문입니다.

파인튜닝 (Fine-Tuning)이 승리하는 경우

파인튜닝은 _행동(behavior)_을 일관되게 재형성해야 할 때 적절한 도구가 됩니다:

• 도메인 특화 언어 및 형식 (Domain-specific language and format). 모든 출력이 엄격한 구조를 따라야 하는 경우 — 예를 들어, 매우 특정한 스타일로 Soroban 스마트 컨트랙트 보일러플레이트(Boilerplate)를 생성해야 하는 경우 — 파인튜닝은 매번 프롬프트 토큰(Prompt tokens)을 소비하며 설명할 필요 없이 해당 패턴을 안정적으로 내재화합니다.
• 대규모 환경에서의 지연 시간(Latency) 및 비용. RAG는 검색 오버헤드(Retrieval overhead)를 추가하고 프롬프트를 팽창시킵니다. 만약 좁은 범위의 작업을 수행하며 수백만 건의 저지연(Low-latency) 요청을 처리해야 한다면, 더 작은 파인튜닝된 모델이 호출당 비용이 더 저렴할 수 있습니다.
• 톤(Tone) 및 페르소나 (Persona). 특정한 방식으로 말해야 하는 고객 대응 봇은 프롬프트 엔지니어링(Prompt engineering)보다 파인튜닝을 통해 훨씬 더 큰 이점을 얻습니다.

제가 배포하는 가장 강력한 아키텍처는 하이브리드(Hybrid) 방식입니다. 즉, 추론 스타일과 형식을 처리하는 가볍게 파인튜닝된 모델에, 실시간으로 검증 가능한 사실을 제공하는 RAG를 결합하는 것입니다. 최근 진행한 Web3 컴플라이언스(Compliance) 어시스턴트 사례에서, 이러한 조합은 파인튜닝만 사용했을 때보다 환각(Hallucination) 발생률을 60% 이상 낮추면서도 모든 답변을 출처 문서로 추적할 수 있게 했습니다. 이는 정확히 포렌식 작업이 요구하는 표준입니다.

제가 팀들에게 제안하는 빠른 의사결정 휴리스틱(Heuristic)은 다음과 같습니다: 만약 적절한 문서를 프롬프트(Prompt)에 붙여넣음으로써 질문에 답할 수 있다면, RAG가 필요합니다. 만약 컨텍스트(Context)와 상관없이 모델이 근본적으로 해당 작업을 수행하는 방법 자체를 모른다면, 파인튜닝(Fine-tuning)이 필요합니다.

결론

진정한 기술은 어느 한쪽을 선택하는 것이 아닙니다. 당신의 문제가 지식(Knowledge)에 관한 것인지 아니면 행동(Behavior)에 관한 것인지를 진단한 다음, 그에 맞춰 설계하는 것이며, 종종 두 가지를 혼합하는 것입니다. 만약 토큰화(Tokenization), 블록체인(Blockchain), 또는 포렌식급(Forensic-grade) 시스템에서 AI 프로젝트를 계획하고 있다면, 저 André Dias Moreira Prol에게 연락해 주세요. 잘못된 방식에 예산을 낭비하기 전에 당신의 데이터에 실제로 적합한 접근 방식을 설계해 봅시다.

André Dias Moreira Prol의 더 많은 기사를 Medium에서 확인하세요.