우리가 AI 챗봇을 만들 때 RAG와 파인튜닝 사이에서 고민하는 이유

솔직히 고백하겠습니다. 처음 AI 기술을 우리 서비스에 도입하려고 마음먹었을 때, 저 역시 '환상'에 빠져 있었습니다. 거대 언어 모델(LLM)이 우리 회사의 모든 데이터를 학습해서 마치 10년 차 직원처럼 똑똑하게 답변해 줄 것이라는 막연한 기대였죠.

"우리 도메인 지식만 다 때려 넣고 학습시키면 되는 거 아니에요?"

회의실에서 호기롭게 뱉었던 이 말이 얼마나 무모했는지 깨닫는 데는 그리 오랜 시간이 걸리지 않았습니다. 실제로 많은 기술 리더나 개발자들이 비슷한 고민을 안고 찾아옵니다. "CTO님, 우리 회사만의 AI챗봇을 만들고 싶은데 데이터를 학습시키는 게(Fine-tuning) 나을까요, 아니면 요즘 뜬다는 검색 증강 생성(RAG)을 붙이는 게 나을까요?"

이 질문은 단순히 기술 스택을 고르는 문제가 아닙니다. 비용, 시간, 그리고 무엇보다 '우리가 해결하려는 문제가 무엇인가'에 대한 본질적인 물음입니다. 오늘은 제가 겪었던 시행착오를 바탕으로, 이 두 가지 전략의 실체를 낱낱이 파헤쳐보려 합니다.

파인튜닝이라는 달콤한 유혹과 쓴맛

초창기, 저희 팀은 파인튜닝(Fine-tuning)에 꽂혀 있었습니다. 뭔가 '우리만의 모델'을 갖는다는 것이 기술적 해자(Moat)를 만드는 것처럼 느껴졌거든요. 사내 위키, 슬랙 대화 로그, 고객 응대 매뉴얼을 전처리해서 오픈소스 모델에 학습시키기 시작했습니다. GPU 서버를 돌리며 밤새 로스(Loss) 값이 떨어지는 그래프를 보며 흐뭇해하기도 했습니다.

그런데 결과물을 마주한 순간, 등골이 서늘해졌습니다.

분명 우리 회사 용어를 쓰긴 하는데, 전혀 엉뚱한 맥락에서 사용했습니다. 심지어 2년 전, 이미 폐기된 정책을 마치 현재 유효한 것처럼 자신 있게 답변하더군요. 더 큰 문제는 업데이트였습니다. 어제 바뀐 환불 규정을 반영하려면 모델을 다시 학습시켜야 했습니다. 비용도 비용이지만, 실시간성이 중요한 비즈니스 환경에서 모델 재학습을 기다려줄 고객은 없었습니다.

우리는 모델에게 '지식'을 주입하려고 했지만, 사실 파인튜닝은 지식 주입보다는 '말투'나 '형식', 혹은 특정한 '태스크 수행 능력'을 가르치는 데 더 적합한 도구였습니다. 교과서를 통째로 외우게 했는데, 정작 시험 문제는 오늘 아침 뉴스에서 나온 꼴이었습니다.

RAG, 현실적인 해결책이 되다

뼈아픈 실패 후, 우리는 전략을 전면 수정했습니다. 모델이 모든 것을 기억하게 하는 대신, 모델에게 '컨닝 페이퍼'를 쥐여주기로 했습니다. 바로 RAG(Retrieval-Augmented Generation)입니다.

RAG는 쉽게 말해 오픈북 테스트입니다. 사용자가 질문을 던지면, AI는 대답하기 전에 먼저 우리 데이터베이스(Vector DB)에서 관련 문서를 검색합니다. 그리고 그 내용을 바탕으로 답변을 생성하죠.

효과는 즉각적이었습니다. "A 상품의 최신 가격 정책이 뭐야?"라고 물으면, RAG 기반의 AI챗봇은 방금 업데이트된 DB 문서를 참고해 정확한 가격을 알려줍니다. 할루시네이션(거짓 답변)도 현격히 줄었습니다. 근거 문서가 없으면 "모르겠습니다"라고 대답하게 제어하기도 훨씬 쉬웠죠. 무엇보다 데이터가 바뀌면 DB만 업데이트하면 되니, 재학습이라는 무거운 짐을 벗어던질 수 있었습니다.

하지만 RAG가 만능열쇠는 아니었습니다. 검색 품질이 떨어지면 엉뚱한 문서를 가져와 이상한 답변을 내놓는 건 매한가지였습니다. 문서를 쪼개는 청크(Chunk) 전략, 임베딩 모델의 성능, 하이브리드 검색 구현 등 엔지니어링의 난이도는 모델 학습이 아닌 '검색 시스템 구축'으로 옮겨갔습니다.

어떤 전략을 선택해야 할까? CTO의 체크리스트

그렇다면 지금 이 글을 읽고 계신 여러분은 어떤 선택을 해야 할까요? 제가 실무에서 기준으로 삼는 몇 가지 질문을 공유합니다.

첫째, 데이터가 얼마나 자주 바뀌는가? 실시간 주가 정보, 매일 바뀌는 사내 식단, 수시로 업데이트되는 API 문서가 핵심이라면 고민할 것 없이 RAG입니다. 반면, 법률 용어 번역이나 고전 문학 분석처럼 지식이 거의 변하지 않고 고정된 도메인이라면 파인튜닝을 고려해볼 만합니다.

둘째, 문제의 본질이 '지식'인가 '스타일'인가? "우리 회사 톤앤매너로 고객에게 공감하는 답변을 해야 해"라거나, JSON 포맷을 아주 엄격하게 지켜야 한다면 파인튜닝이 강력합니다. 하지만 "정확한 팩트와 근거를 제시해야 해"라면 RAG가 압도적으로 유리합니다.

셋째, 가용 리소스는 어느 정도인가? 파인튜닝은 GPU 자원과 데이터 전처리에 상당한 비용과 전문 인력이 필요합니다. RAG는 상대적으로 초기 구축 비용이 낮고, LangChain이나 LlamaIndex 같은 도구들이 잘 갖춰져 있어 접근성이 좋습니다. 스타트업이나 초기 단계의 프로젝트라면 RAG로 시작해서 MVP(최소 기능 제품)를 검증하는 것을 추천합니다.

결국은 하이브리드다

최근 저희 팀은 이 두 가지를 섞는 방향으로 나아가고 있습니다. 기본적인 도메인 용어와 말투, 코드 스타일은 파인튜닝(혹은 프롬프트 엔지니어링 고도화)으로 모델에 내재화시키고, 구체적인 사실 정보는 RAG를 통해 실시간으로 주입하는 방식입니다.

기술은 계속 진화합니다. 100만 토큰을 처리하는 컨텍스트 윈도우를 가진 모델이 나오면서 RAG의 필요성이 줄어들 거라는 전망도 있고, 반대로 소형 언어 모델(sLLM)을 파인튜닝해서 엣지 디바이스에 올리는 시도도 늘고 있습니다.

중요한 건 "RAG냐 파인튜닝이냐"라는 이분법에 갇히지 않는 것입니다. 우리가 해결하려는 문제가 무엇인지, 사용자가 겪는 고통이 무엇인지 집요하게 파고들어야 합니다. AI챗봇은 결국 그 문제를 해결하기 위한 도구일 뿐이니까요.

지금 당장 거창한 모델을 학습시키려 하기보다, 작은 데이터셋으로 RAG 파이프라인부터 만들어보세요. 사용자가 묻는 질문이 무엇인지 로그를 들여다보는 것에서부터 진정한 혁신은 시작됩니다. 기술의 화려함보다 문제 해결의 본질에 집중하는 하루가 되시길 바랍니다.