RAG와 파인튜닝은 무엇이 다르고, 기업은 무엇을 선택해야 하는가

“우리 데이터로 똑똑하게 만들어 달라”는 요청은 자주 오지만, 그 한 문장 안에는 서로 다른 두 가지 방법이 섞여 있습니다. 하나는 답할 때마다 우리 문서를 찾아보게 하는 것이고, 다른 하나는 모델 자체를 우리 방식에 맞게 다시 가르치는 것입니다. 앞의 것을 RAG, 뒤의 것을 파인튜닝이라고 부릅니다.

두 단어가 대안처럼 들리기 때문에 “둘 중 무엇을 할까”로 논의가 시작되지만, 실제로는 바꾸는 대상이 다른 도구입니다. 이 글은 두 방식의 원리를 소개하는 데 무게를 두지 않습니다. RAG 자체가 무엇이고 언제 필요한지는 RAG란 무엇이고 언제 필요한가에서 따로 다루므로, 여기서는 우리 문제에 무엇이 맞는지를 가르는 선택 기준에 집중합니다.

”우리 데이터로 똑똑하게”에 섞여 있는 두 가지

혼동의 뿌리는 “똑똑하게”라는 말이 두 가지를 동시에 가리킨다는 데 있습니다. 하나는 무엇을 근거로 답하는가이고, 다른 하나는 어떻게 답하는가입니다.

• “우리 규정을 알고 답했으면 좋겠다” — 이것은 근거의 문제입니다. 모델이 우리 문서를 읽고 그 내용대로 답해야 합니다.
• “우리 회사 말투와 보고서 서식으로 답했으면 좋겠다” — 이것은 방식의 문제입니다. 모델이 정해진 형태로 출력하게 만들어야 합니다.

RAG는 앞쪽을, 파인튜닝은 뒤쪽을 바꿉니다. 그래서 “무엇을 하고 싶은가”를 이 두 갈래로 먼저 나누면, 대개 어느 방식이 맞는지가 저절로 드러납니다. 뒤섞인 채로 업체 견적을 비교하기 시작하면, 서로 다른 목적의 두 상품을 같은 표에 놓고 값만 견주게 됩니다.

RAG는 답변의 근거를 바꾼다

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 모델이 답하기 전에 먼저 사내 문서에서 관련 부분을 찾아오고, 그 내용만을 근거로 답을 만들게 하는 방식입니다. 모델 자체는 그대로 두고, 답할 때 참고하는 자료만 우리 문서로 바꿉니다.

핵심은 두 가지입니다. 첫째, 문서가 바뀌면 색인만 갱신하면 됩니다. 규정이 개정되면 모델을 다시 만드는 것이 아니라 바뀐 문서를 다시 색인에 넣는 것으로 끝나고, 다음 답변부터 바로 반영됩니다. 둘째, 답변마다 근거가 남습니다. 어느 문서의 어느 부분에서 답이 나왔는지 각주로 제시할 수 있어, 사람이 원문을 열어 확인할 수 있습니다.

AWS는 검색 증강 생성이 무엇인지를 공식 문서에서 벤더 중립적으로 정리해 두었고, 색인·검색 구성 요소를 서비스가 맡는 Amazon Bedrock Knowledge Bases 같은 완전 관리형 옵션도 제공합니다. 관리형 옵션을 쓰면 별도의 머신러닝 전문지식 없이도 시작할 수 있다는 점이, 뒤에서 볼 파인튜닝과 갈리는 지점입니다.

파인튜닝은 답하는 방식을 바꾼다

파인튜닝은 이미 학습된 모델에 예시 데이터를 더 주어 추가로 학습시키는 방식입니다. 바꾸는 것은 근거가 아니라 모델이 과제를 수행하는 방식과 출력의 형태입니다. 정해진 서식으로 일관되게 정리하게 하거나, 특정 어투를 유지하게 하거나, 요약처럼 특정 과제를 더 잘 수행하게 만드는 것이 파인튜닝의 자리입니다.

가장 흔한 방식은 지도 방식(supervised fine-tuning)으로, Amazon Bedrock의 모델 커스터마이징 문서가 설명하듯 원하는 입력과 출력을 짝지은 라벨링된 데이터를 제공해 학습시킵니다. 여기서 중요한 것은, 파인튜닝이 문서의 내용을 사실로 외우게 하는 작업이 아니라는 점입니다. 서식과 어투를 가르칠 수는 있어도, 개별 규정 조항을 정확히 인용하게 하는 데에는 적합하지 않습니다.

한 가지 먼저 밝혀 둘 것이 있습니다. 모델을 학습시키는 영역, 즉 AI/ML 모델 개발·학습과 데이터 사이언스는 빌드업웍스가 직접 수행하지 않고 전문 파트너를 연결합니다. 이 글에서 파인튜닝은 두 방식을 가르기 위한 비교 대상으로 다루며, 실제로 파인튜닝이 필요한 상황으로 판단되면 그 부분은 파트너와 함께 진행합니다.

무엇이 갈리는가 — 한눈에 비교

두 방식은 도구의 성능이 아니라 바꾸는 대상에서 갈립니다. 아래 표는 그 차이를 실무에서 부딪히는 항목으로 나눠 본 것이며, AWS Prescriptive Guidance의 RAG·파인튜닝 비교 문서가 정리한 대비를 따릅니다.

표에서 무게가 실리는 세 줄은 문서가 바뀔 때, 출처 제시, 준비물입니다. 사내 문서 질의응답은 이 세 항목에서 거의 언제나 RAG 쪽이 유리합니다. 문서는 계속 바뀌고, 답의 근거를 사람이 확인해야 하며, 우리에게 있는 것은 라벨링된 학습 데이터가 아니라 정리해야 할 문서이기 때문입니다.

한 가지 유의할 점은 오른쪽 열이 틀렸다는 뜻이 아니라는 것입니다. 파인튜닝은 다른 문제를 푸는 도구이고, 그 문제가 우리 문제일 때는 파인튜닝이 맞습니다. 그 경우는 뒤에서 따로 다룹니다.

우리 문제에는 무엇이 맞는가

선택은 회사 규모나 예산이 아니라 바꾸려는 것이 근거인가 방식인가로 하는 편이 정확합니다. 아래 갈래로 자신의 요구를 넣어 보시면 됩니다.

• “자주 바뀌는 규정·매뉴얼을 근거로, 출처까지 확인하며 답하게 하고 싶다” → RAG입니다. 이것이 사내 문서 질의응답의 전형이고, AWS Prescriptive Guidance도 이런 경우에는 RAG 기반 접근에서 시작할 것을 권합니다. 실제 구축은 AI 문서검색 솔루션 관점에서 다룹니다.
• “정해진 보고서 서식이나 회사 어투로 대량의 문서를 일관되게 정리하게 하고 싶다” → 방식의 문제이므로 파인튜닝이 후보입니다. 단, 정말 파인튜닝까지 필요한지, 프롬프트로 형식을 지정하는 것으로 충분한지를 먼저 따져야 합니다.
• “요약·분류처럼 특정 과제를 반복적으로, 안정적으로 수행하게 하고 싶다” → 과제 수행 방식을 바꾸는 일이므로 파인튜닝이 맞을 수 있습니다.
• “정확한 수치를 조회하고 싶다(이번 달 미수금 등)” → 둘 다 아닙니다. 이것은 문서를 찾는 문제가 아니라 값을 조회하는 문제이고, 검색이 아니라 조회 기능을 호출하는 방식으로 설계해야 합니다.

대부분의 “사내 문서를 아는 AI” 요청은 첫 번째 갈래에 속합니다. 그래서 방향을 정하는 자리에서 파인튜닝이 먼저 떠올랐다면, 정말 바꾸려는 것이 답의 방식인지 근거인지를 한 번 더 확인하시길 권합니다.

파인튜닝에 실제로 드는 것

파인튜닝이 “한 번 하면 끝나는 더 좋은 방법”으로 오해되는 경우가 많아, 실제 요건을 짚어 둡니다. AWS 문서가 명시하는 조건은 다음과 같습니다.

• 라벨링된 학습 데이터 — 원하는 입력과 출력을 짝지은 예시가 필요하고, 그 데이터를 만들고 검증하는 일 자체가 프로젝트입니다. 양과 품질이 결과를 좌우합니다.
• 데이터 사이언스 역량 — AWS는 파인튜닝에 데이터 사이언티스트가 필요할 수 있다고 안내합니다. 학습 기법과 파라미터를 이해하고 조정할 사람이 필요하다는 뜻입니다.
• 학습에 드는 시간 — 학습은 수 시간에서 수일이 걸릴 수 있습니다. 문서가 자주 바뀌면 그때마다 다시 학습해야 하므로, AWS는 자주 바뀌는 문서에는 파인튜닝이 적합하지 않다고 못 박습니다.
• 재학습의 반복 — 첫 학습으로 끝나지 않습니다. 대상이 바뀌면 데이터 준비부터 학습까지의 과정이 되풀이됩니다.

이 요건들이 앞서 본 “준비물” 줄의 실체입니다. RAG의 준비물은 정리된 문서인 반면, 파인튜닝의 준비물은 라벨링된 데이터와 그것을 다룰 사람입니다. 두 준비물의 성격이 다르기 때문에, 우리에게 무엇이 있는지를 보면 어느 쪽이 현실적인지도 함께 보입니다.

함께 쓰는 경우

두 방식은 배타적이지 않습니다. AWS도 비교 문서에서 하나의 구성 안에 둘을 결합할 수 있다고 설명합니다. 전형적인 결합은 이렇습니다. 근거는 RAG로 문서에서 가져와 최신성과 출처 추적을 확보하고, 답변을 특정 서식이나 어투로 일관되게 내보내는 부분만 파인튜닝으로 다룹니다. 즉 RAG 구조는 그대로 두고 생성 단계의 형식만 손보는 형태입니다.

다만 결합은 두 방식의 운영 부담을 모두 떠안는 선택입니다. 색인과 검색을 유지하면서 학습 데이터도 관리해야 하므로, 처음부터 결합을 목표로 잡는 것은 대개 이릅니다. 순서로는 RAG만으로 답의 근거 문제를 먼저 풀고, 그 뒤에도 출력 형식이 실무에서 계속 걸리는 것이 확인될 때 파인튜닝을 얹는 편이 위험이 적습니다.

흔한 오해 두 가지

방향을 정하는 자리에서 반복해서 나오는 두 오해가, 대개 잘못된 선택의 출발점입니다.

• “파인튜닝하면 우리 문서를 다 안다” — 아닙니다. 파인튜닝은 방식을 가르치는 작업이지 문서를 사실로 저장하는 작업이 아닙니다. 학습 이후 바뀐 문서를 알지 못하고, 답이 어느 문서에서 나왔는지도 제시하지 못합니다. 문서를 근거로 정확히 답하게 하려는 목적이라면 파인튜닝이 아니라 RAG입니다.
• “RAG면 AI가 최신 정보를 학습한다” — 아닙니다. RAG는 모델을 학습시키지 않습니다. 답할 때마다 문서를 검색해 그때그때 근거로 넣어 줄 뿐이고, 최신으로 유지되는 것은 참고하는 문서이지 모델이 아닙니다. “학습”과 “검색해서 참고”를 같은 말로 쓰면 두 방식의 차이가 통째로 흐려집니다.

두 오해 모두 “학습”이라는 단어가 근거와 방식을 뭉뚱그려 쓰이는 데서 나옵니다. 바꾸려는 것이 무엇을 근거로 답하는가인지, 어떻게 답하는가인지를 나누면 오해도 함께 풀립니다.

파인튜닝이 오히려 맞는 경우

지금까지 사내 문서 질의응답은 거의 언제나 RAG라고 말했지만, RAG가 답이 아닌 조건도 분명히 있습니다. 아래에 해당하면 파인튜닝이나 결합을 검토할 값이 있습니다.

• 바꾸려는 것이 근거가 아니라 형식일 때 — 답의 내용은 이미 맞는데 서식·어투·구조가 매번 흔들리는 것이 문제라면, 그 일관성은 검색으로 풀리지 않습니다.
• 특정 과제 수행 자체를 안정화해야 할 때 — AWS는 요약처럼 추가적인 과제를 수행하게 하려는 경우를 파인튜닝의 용도로 듭니다. 근거를 찾는 것이 아니라 정해진 처리를 반복하는 일이 중심이라면 방식을 바꾸는 쪽이 맞습니다.
• 근거가 될 문서가 애초에 존재하지 않을 때 — 검색해서 가져올 문서 자체가 없다면 RAG가 딛고 설 근거가 없습니다. 이 경우는 두 방식의 선택 이전에, 무엇을 근거로 삼을지부터 정해야 하는 단계입니다.

이런 판단은 모델을 고르기 전에 우리 데이터와 목적이 어느 자리에 있는지를 먼저 보아야 내려집니다. 구축에 드는 금액 기준이 궁금하시면 본문에서 수치를 단정하는 대신 구축 요금 안내로 확인하시고, 관리형으로 시작할지 직접 구성할지는 Amazon Bedrock으로 구축할 때를 참고하시면 됩니다.

다음 단계

RAG와 파인튜닝 중 무엇을 택할지는 대개 도구의 문제가 아니라 우리 데이터와 목적의 문제입니다. 그래서 방향을 정하기 전에 현재 상태부터 확인하시는 것이 순서상 먼저입니다. AI 준비도 진단은 데이터와 거버넌스 상태를 항목별로 점검해, 이 글에서 나눈 기준을 자신의 환경에 대입해 볼 수 있게 합니다. 연락처를 남기지 않아도 결과는 바로 확인하실 수 있습니다.

사내 문서를 근거로 답하고 각주로 원문을 확인하는 구성 쪽으로 방향이 기울었다면, AI · 앱 개발 서비스 범위에서 어디까지가 저희 몫이고 어디부터 파트너와 함께하는 부분인지 나눠 적어 둔 것을 보십시오. 각주를 눌러 근거 원문이 어떻게 확인되는지 먼저 보시려면 아래 데모를 열어 보시고, 우리 문제에 무엇이 맞을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS Prescriptive Guidance — Comparing RAG and fine-tuning
• AWS — 검색 증강 생성(RAG)이란 무엇인가
• Amazon Bedrock — 모델 커스터마이징(Customize your model)
• Amazon Bedrock Knowledge Bases 개발자 문서