기업용 AI 프로젝트에서 반복적으로 나타나는 패턴이 있습니다. 한 팀이 멋진 데모를 구축하고, 회의실의 모든 사람이 감탄하지만, 프로덕션(production)에 도입하고 3개월이 지나면 전체 시스템이 흔들리기 시작합니다. 답변은 일관성이 없어지고, 비용은 폭등합니다. 컴플라이언스(compliance) 담당자가 "잠깐, 모델이 그 숫자를 어디서 가져온 거죠?"라고 물으면 아무도 제대로 된 답변을 하지 못합니다.

대부분의 경우, 근본 원인은 초기에 내린 후 다시 검토하지 않은 결정으로 거슬러 올라갑니다. 바로 기업용 AI를 위해 RAG (Retrieval-Augmented Generation)를 구축할 것인지, 아니면 Fine-tuning (미세 조정)을 할 것인지에 대한 결정입니다. 그리고 그 선택이 실제로 문제에 적합했는지, 아니면 단순히 팀이 처음 읽게 된 튜토리얼에 맞춘 것이었는지에 대한 문제입니다.

이것은 어떤 기술이 추상적인 의미에서 더 "나은가"에 대한 논쟁이 아닙니다. 아키텍처(architecture)를 비즈니스 현실에 맞추는 것에 관한 문제입니다. 실제로 이것이 실무에서 어떻게 나타나는지 살펴보겠습니다.

두 가지 서로 다른 철학, 경쟁하는 두 제품이 아님

RAG와 Fine-tuning을 서로 다른 두 가지 질문에 답하는 것으로 생각하면 도움이 됩니다.

RAG는 다음과 같은 질문에 답합니다: "모델이 이 질문에 올바르게 답하기 위해 지금 당장 무엇을 찾아봐야 하는가?" 이는 언어 모델을 검색 시스템(retrieval system)과 결합합니다. 일반적으로 질문이 던져지는 순간 문서, 위키(wiki) 또는 지식 베이스(knowledge base)를 검색하는 벡터 데이터베이스(vector database)를 사용하여 가장 관련성 높은 자료를 컨텍스트(context)로서 모델에 전달합니다.

Fine-tuning은 다음과 같은 질문에 답합니다: "모델이 별도의 지시 없이도 이미 무엇을 알고 있어야 하거나 어떻게 행동해야 하는가?" 이는 자체 예시를 사용하여 베이스 모델(base model)을 계속 학습시키는 과정을 포함하며, 이를 통해 모델의 내부 파라미터(parameters)가 특정 패턴(어휘, 어조, 작업별 추론, 도메인 로직)을 반영하도록 변화합니다.

마케팅 문구에서는 때때로 이 둘을 서로 대체 가능한 것처럼 묘사하지만, 어느 쪽도 다른 쪽의 즉각적인 대체재가 될 수 없습니다. 이들은 서로 다른 문제를 해결하며, 이 둘을 혼동하는 것이 보통 프로젝트가 잘못되는 지점입니다.

잘못된 선택의 실제 비용

기업들이 실패하는 이유는 보통 "더 나쁜" 기술을 선택했기 때문이 아닙니다. 그들은 자신들의 실제 제약 조건(constraints)과 일치하지 않는 기술을 선택했기 때문에 실패합니다.

문서가 매달 변경되는 정책 중심 산업을 위해 미세 조정(Fine-tuning) 모델을 구축하는 팀은, 최신 상태를 유지하기 위해 끊임없이 재학습을 수행하게 됩니다. 이는 RAG가 훨씬 더 우아하게 해결했을 문제를 위해 예산과 엔지니어링 시간을 낭비하는 결과로 이어집니다. 반대로, 깊고 일관된 도메인 추론(domain reasoning)이 필요한 작업(예: 미묘한 법적 리스크 분류)을 위해 RAG 시스템을 구축하는 팀은, 아무리 영리한 프롬프트 엔지니어링(prompt engineering)을 시도해도 모델이 근본적인 논리를 실제로 내재화하지 못했다는 사실을 깨닫게 되는 경우가 많습니다.

이는 가설적인 우려가 아닙니다. Stanford의 Human-Centered Artificial Intelligence 연구소가 추적한 학술 연구에 따르면, 조직이 AI 시스템을 파일럿 단계를 넘어 확장할 때 고려하는 주요 요인은 원시 능력(raw capability)이 아니라 신뢰성(reliability)과 설명 가능성(explainability)입니다. 즉, 어떤 기반 모델을 사용하는가보다 아키텍처(architecture) 결정이 점점 더 중요해지고 있습니다.

상황 판단하기: RAG가 적절한 경우

RAG는 몇 가지 특정 조건이 충족될 때 올바른 선택이 되는 경향이 있습니다.

데이터가 릴리스 주기보다 빠르게 변경되는 경우: 가격, 정책 문서 또는 제품 사양이 매주 업데이트된다면, RAG를 통해 모델 자체를 건드리지 않고도 소스 문서를 교체할 수 있습니다.

근거를 제시해야 하는 경우: 규제 산업에서는 시스템이 답변의 출처를 인용할 것을 점점 더 요구하고 있습니다. RAG는 암기된 가중치(weights)로부터 생성하는 대신 실제 소스 자료를 검색하기 때문에 이를 자연스럽게 지원합니다.

제한된 ML 인프라를 사용하는 경우: 임베딩(embeddings)과 벡터 저장소(vector store)를 구축하는 것은 전담 머신러닝 엔지니어가 없는 팀에게 전체 미세 조정(fine-tuning) 및 평가 파이프라인을 관리하는 것보다 일반적으로 접근성이 더 높습니다.

특정하고 지엽적인 사실에 대한 환각 (hallucination)을 제한하고 싶을 때가 있습니다. 검색된 텍스트에 답변의 근거를 두는 것(Grounding)은 모델이 깊이 학습하지 않은 세부 사항을 자신 있게 지어내는 위험을 (완전히 제거하지는 못하더라도) 줄여줍니다.

상황 판단하기: 미세 조정 (Fine-Tuning)이 의미 있는 경우

미세 조정 (Fine-tuning)은 다른 상황에서 그 가치를 발휘합니다.

문제의 핵심이 사실이 아닌 '행동 양식'에 있는 경우입니다. 일관된 톤, 형식, 또는 도메인 특화된 추론(reasoning)이 필요한 경우 — 예를 들어 내부 코드 생성 표준이나 미묘한 차이가 있는 분류 작업 등 — 미세 조정은 검색된 스니펫(snippets)에 간접적으로 의존하는 대신 모델 자체를 형성합니다.

도메인이 비교적 안정적인 경우입니다. 핵심 로직이 자주 바뀌지 않는, 기초 지식의 변화 속도가 느린 분야는 초기 학습 투자로부터 더 큰 효용을 얻을 수 있습니다.

프롬프트의 단순함과 응답 속도가 중요한 경우입니다. RAG 파이프라인은 종종 컨텍스트가 가득 채워진 긴 프롬프트를 요구합니다. 미세 조정된 모델은 종종 더 짧은 프롬프트로도 유사한 품질을 달성할 수 있으며, 이는 지연 시간(latency)과 토큰 비용이 누적되는 대규모 환경에서 매우 중요합니다.

매 요청마다 발생하는 검색(retrieval) 및 재순위화(reranking)의 지속적인 비용이 초기 학습 비용보다 큰, 높은 쿼리 볼륨을 처리하는 경우입니다.

이러한 트레이드오프(tradeoffs)가 다양한 산업과 데이터 환경에서 어떻게 나타나는지 알고 싶다면, 한 가지 접근 방식이 다른 방식보다 명확하게 우수한 성능을 보인 여러 사용 사례를 살펴보는 기업 배포를 위한 RAG 및 미세 조정 전략(RAG and fine-tuning strategies for enterprise deployments)의 상당히 철저한 비교 분석을 참고하십시오.

아무도 다루고 싶어 하지 않지만(그래야만 하는) 거버넌스(Governance) 측면

이러한 많은 논의에서 과소평가되는 한 가지는 거버넌스(governance)입니다. RAG 대 미세 조정을 순수하게 기술적인 결정으로 취급하기 쉽지만, 이는 무언가 잘못되었을 때 귀하의 AI 시스템이 얼마나 방어 가능한지(defensible)에 실질적인 영향을 미칩니다.

NIST AI Risk Management Framework는 신뢰할 수 있는 AI를 위해 정확성(accuracy)과 투명성(transparency)이 모두 필요하다고 정의하며, 이러한 특성들은 당연하게 가정되는 것이 아니라 능동적으로 관리되어야 한다고 언급합니다. 출처를 인용하는 RAG 시스템은 추론 과정이 가중치(weights) 속에 보이지 않게 내재화된 파인튜닝(fine-tuning) 모델보다 본질적으로 감사(audit)하기가 더 쉽습니다. 그렇다고 해서 파인튜닝이 나쁜 선택이라는 뜻은 아닙니다. 단지 파인튜닝을 선택하는 팀은 감소된 투명성을 보완하기 위해 평가(evaluation)와 문서화(documentation)에 더 의도적으로 투자해야 함을 의미합니다.

하이브리드 모델이 조용히 기본값(default)이 되고 있습니다

주의 깊게 살펴볼 만한 트렌드가 하나 있다면, 성숙한 기업용 배포 사례 중 어느 한 쪽만을 순수하게 선택하는 경우가 줄어들고 있다는 점입니다. 대신, 그들은 두 가지를 계층화(layering)하고 있습니다. 파인튜닝된 모델이 어조(tone), 구조(structure), 전문적인 추론(specialized reasoning)을 처리하고, 검색 계층(retrieval layer)이 그 토대 위에 최신의 검증 가능한 사실(verifiable facts)을 제공하는 방식입니다.

이는 단순히 결정을 내리지 못한 팀들의 타협안이 아닙니다. 각 방법의 강점을 진정으로 활용하는 방식입니다. 파인튜닝만 사용하면 정보의 노후화(staleness) 위험이 있습니다. RAG만 사용하면 미묘한 추론(nuanced reasoning)이나 엣지 케이스(edge cases)에서의 일관된 동작을 유지하는 데 어려움을 겪을 수 있습니다. 이 둘을 결합하면 최신성을 유지하면서도 일관성(coherent) 있는 시스템을 구축하는 경향이 있습니다.

결정을 내리기 전 짧은 체크리스트

아키텍처를 확정하기 전에, 몇 가지 근거 있는 질문들을 검토해 볼 가치가 있습니다.

• 기초 정보가 실제로 얼마나 자주 바뀌는가?
• 컴플라이언스(compliance)나 신뢰를 위해 출처를 인용해야 하는가?
• 핵심 과제가 사실적 회상(factual recall)인가, 아니면 행동의 일관성(behavioral consistency)인가?
• 귀하의 팀이 장기적으로 구축하고 유지 관리할 수 있는 현실적인 대역폭(bandwidth)은 어느 정도인가?
• 초기 비용(upfront cost)과 지속적인 운영 비용(ongoing operational cost) 중 무엇을 더 최적화하고 있는가?

이 질문들 중 모든 기업에 적용되는 단 하나의 정답은 없습니다. 질문의 답은 귀하의 특정 데이터, 산업군, 그리고 위험 허용 범위(risk tolerance)에 따라 달라집니다.

어떤 경로를 선택하든 수행할 가치가 있는 몇 가지 사항들

무엇보다 먼저 데이터 파이프라인(data pipeline)에 투자하십시오. 지저분하거나, 인덱싱(indexing)이 제대로 되지 않았거나, 일관성이 없는 소스 데이터는 RAG와 파인튜닝(fine-tuning) 모두를 저해할 것입니다.

단순히 출시 당일뿐만 아니라, 지속적인 프로세스에 평가(evaluation)를 포함시키십시오. 검색된 콘텐츠는 시간이 지나면 쓸모없게 되고, 도메인이 진화함에 따라 파인튜닝된 동작도 드리프트(drift)될 수 있습니다.

먼저 좁은 유스케이스(use case)를 대상으로 파일럿을 진행하십시오. 하나의 팀이나 워크플로우를 대상으로 한 제한적인 배포는 전체 배포보다 데이터 격차와 지연 시간(latency) 문제를 훨씬 더 빠르게 드러낼 것입니다.

특히 규제 산업(regulated industries)에서는 여러분의 논거를 문서화하십시오. 그래야 어떤 방식을 선택하더라도 나중에 정밀한 검토(scrutiny)를 견뎌낼 수 있습니다.

결정을 주기적으로 재검토하십시오. 파일럿 단계에서 타당했던 것이 사용 패턴과 데이터 볼륨이 실제로 확장(scale)된 이후에는 유효하지 않을 수 있습니다.

RAG와 파인튜닝 사이의 선택은 단순히 더 정교하게 들리는 옵션을 고르는 문제가 아닙니다. 그것은 여러분의 데이터가 어떻게 작동하는지, 조직에 실제로 어느 정도의 설명 가능성(explainability)이 필요한지, 그리고 초기 데모가 더 이상 누구에게도 감명을 주지 못하게 된 훨씬 이후에도 그 선택을 지원할 수 있는 엔지니어링 역량이 얼마나 되는지에 대해 스스로에게 솔직해지는 문제입니다.