LLM 파인튜닝 RAG 차이, 학습이 필요한 세 경우

LLM 파인튜닝 RAG 차이는 모델의 가중치를 바꾸는 학습과, 답변할 때 필요한 문서를 찾아 제공하는 검색의 차이입니다. 사내 규정이나 매뉴얼에 답하는 AI라면 대체로 파인튜닝보다 RAG부터 검토하는 편이 맞습니다. 이 글에서는 검색을 먼저 적용할 이유, 학습을 검토할 세 가지 경우, 우리 데이터로 두 방식의 성능과 비용을 비교하는 기준을 제시합니다.

파인튜닝과 RAG는 사내 데이터를 어떻게 쓰나?

파인튜닝은 모델이 답하는 방식을 바꾸고, RAG는 모델이 답할 때 참고할 정보를 공급합니다.

파인튜닝은 기존 모델에 업무 데이터를 추가로 학습시켜 모델의 가중치 일부 또는 전체를 조정하는 방법입니다. 예를 들어 문의 문장과 정답 부서가 짝을 이룬 데이터를 학습시켜, 회사의 업무 구분에 맞게 문의를 분류하도록 만들 수 있습니다.

RAG는 검색 증강 생성입니다. 질문이 들어오면 사내 문서에서 관련 부분을 검색하고, 그 내용을 질문과 함께 모델에 전달해 답하게 합니다. 기본 모델의 가중치는 바꾸지 않습니다. 문서를 검색용으로 가공하고 임베딩하는 작업이 있어도, 그것을 답변 모델의 추가 학습과 같은 일로 보면 안 됩니다.

“우리 데이터로 학습시켜 주세요”라는 요구에는 두 가지 뜻이 섞여 있습니다. 회사 규정을 읽고 답해 달라는 요구인지, 회사가 정한 방식으로 분류하고 작성해 달라는 요구인지부터 나눠야 합니다.

AWS의 비교 가이드도 자체 문서를 참조하는 질의응답에는 RAG부터 시작할 것을 권고합니다. 이것은 모든 업무에서 RAG가 더 정확하다는 뜻이 아니라, 문서 질의응답의 요구에 검색 방식이 먼저 맞는다는 뜻입니다.

사내 문서 질의응답은 왜 검색이 먼저인가?

사내 문서 질의응답은 정보를 외우는 능력보다 최신 근거를 찾고 접근 권한을 지키는 능력이 먼저 필요하기 때문입니다.

가령 출장비 규정이 바뀌어 다음 달부터 숙박비 한도가 달라진다고 가정합니다. 직원은 현재 기준과 다음 달 기준을 구분해서 물을 수 있습니다. 필요한 것은 두 버전의 시행일을 확인하고 필요한 조항을 가져오는 일입니다. 규정 파일을 모델에 학습시켰다는 사실만으로 이 구분이 보장되지는 않습니다.

RAG에서는 문서에 시행일, 개정일, 담당 부서 같은 정보를 붙이고 검색 조건에 반영할 수 있습니다. 잘못 답했을 때도 오래된 조항을 검색했는지, 최신 조항을 받았는데 잘못 해석했는지 나눠 확인할 수 있습니다. 파인튜닝만으로 답하면 특정 답변이 어느 학습 문서에서 나왔는지 확인하기 어렵습니다.

권한도 중요합니다. 인사팀 문서와 전 직원 공개 규정은 같은 검색 범위에 넣으면 안 됩니다. 사용자 권한에 맞춰 검색 후보를 제한하고, 모델에 전달하기 전에 다시 검사해야 합니다. RAG를 사용한다는 사실 자체가 보안을 보장하지는 않습니다.

문서 변경이 잦을수록 갱신 절차도 차이가 납니다. RAG는 수정 문서의 추출과 색인 갱신으로 반영할 수 있지만, 실제 반영 시간은 파일 처리량과 운영 방식에 따라 달라집니다. 파인튜닝은 데이터 준비와 학습, 회귀 평가, 배포까지 고려해야 합니다.

다만 문서가 적고 한 번의 입력에 모두 담을 수 있다면, 별도 검색 시스템보다 문서를 직접 제공하는 방식이 더 단순할 수 있습니다. 먼저 작은 프롬프트 실험으로 답변 기준을 확인하고, 문서량과 권한 요구가 커질 때 RAG를 붙이는 순서가 낫습니다. 처음부터 벡터 데이터베이스와 학습 환경을 모두 구축할 필요는 없습니다.

파인튜닝이 필요한 경우는 무엇인가?

파인튜닝은 최신 사실을 넣기 위해서가 아니라, 프롬프트와 검색만으로 해결되지 않는 반복 행동을 바꾸려 할 때 검토합니다.

다음 세 경우는 학습 후보입니다. 어느 경우든 기존 모델에 지시문과 예시를 주는 방식으로 먼저 시험하고, 남는 오류가 학습으로 개선되는지 확인해야 합니다.

1. 회사 고유의 작성 방식이 반복해서 무너질 때

보고서를 늘 같은 항목 순서로 작성하거나, 고객 답변에서 특정 표현을 일관되게 사용해야 하는 업무입니다. 정답 예시를 제공해도 금지 표현이나 문장 구조를 반복해서 어긴다면 파인튜닝을 검토할 수 있습니다.

단순히 출력 형식을 맞추려는 목적이라면 구조화 출력과 검증 규칙부터 적용합니다. 필수 항목 누락을 프로그램으로 잡을 수 있는데 모델부터 학습시키면, 비용을 들이고도 검증 장치는 여전히 필요합니다. 학습 데이터는 규정 원문만 모으기보다 승인된 입력과 출력의 쌍으로 구성하는 편이 목적에 맞습니다.

2. 회사 고유의 분류 기준을 익혀야 할 때

“로그인이 안 됩니다”라는 문의를 계정 문제로 보낼지, 인증 장애로 보낼지는 회사의 업무 체계에 달려 있습니다. 필요한 것은 문서를 찾아 요약하는 능력보다 실제 문의를 정해진 범주에 배정하는 능력입니다.

AWS의 Amazon Nova 파인튜닝 가이드는 의도 분류기를 구현하는 용도를 제시합니다. 다만 분류 기준이 자주 바뀌거나 담당자마다 정답이 다르면 학습보다 기준 정리가 먼저입니다. 서로 다른 라벨을 붙인 사례는 모델이 아니라 사람이 먼저 합의해야 합니다.

3. 특정 작업을 작은 모델에 맡겨야 할 때

sLLM 파인튜닝은 큰 모델이 처리하던 좁은 업무를 작은 모델로 옮기는 수단이 될 수 있습니다. 대량 문의 분류처럼 작업 범위가 고정돼 있고, 지연시간이나 운영 비용의 제약이 있는 경우입니다.

큰 모델의 출력을 학습 자료로 활용하는 모델 증류도 이 범주에 들어갑니다. OpenAI의 모델 증류 발표는 강한 모델의 출력으로 작은 모델을 파인튜닝하는 방식을 설명합니다. 다만 큰 모델의 답도 오답일 수 있으므로 표본 검수와 별도 평가가 필요합니다. 작은 모델이 모든 업무에서 큰 모델을 대체한다는 뜻은 아닙니다.

이 세 경우도 RAG와 경쟁 관계일 필요는 없습니다. 규정은 검색으로 가져오고, 검색한 내용을 회사 양식에 맞춰 작성하는 행동은 파인튜닝으로 보완할 수 있습니다.

우리 데이터로 무엇을 비교해야 학습 여부를 결정할 수 있나?

최종 답변 점수만 비교하지 말고, 검색 실패와 답변 행동 실패를 분리해야 학습 예산을 잘못 쓰지 않습니다.

다음은 문서 질의응답용 평가 질문 120개를 만든다는 가정의 실험안입니다. 일반 질문 60개, 개정 문서 질문 20개, 답이 없는 질문 20개, 접근 제한 질문 20개로 구성합니다. 비율은 예시이며 실제 업무의 빈도와 위험에 맞춰 조정합니다.

학습용 자료와 평가 자료는 분리합니다. 같은 문서의 표현만 조금 바꾼 질문이 양쪽에 있으면 성능이 부풀려질 수 있습니다. 문서 계열이나 개정 시점을 기준으로 나누고, 프롬프트와 모델을 조정할 때 쓰지 않을 최종 평가 세트도 남겨 둡니다.

비교의 핵심은 정답 근거를 직접 주는 시험입니다. 담당자가 올바른 조항을 골라 모델에 제공하고 답하게 합니다. 이 조건에서도 틀리면 검색만 개선해 해결할 수 없습니다. 반대로 정답 근거를 주면 맞고 실제 RAG에서만 틀리면 문서 추출, 검색, 버전 필터를 먼저 고칩니다. 원문이 없는 질문은 이 시험에서 제외하고, 답변 거부 능력을 따로 평가합니다.

기준선은 같은 모델에 같은 출력 지시를 준 RAG로 잡습니다. 그다음 파인튜닝 모델 단독, 파인튜닝과 RAG 결합을 비교하되, 검색을 쓰는 두 조건에는 같은 검색 결과를 전달해야 학습 효과를 구분할 수 있습니다.

평가 항목은 정답률 하나로 합치지 않습니다. 사실 정확성, 인용한 근거의 적합성, 답이 없을 때의 거부, 권한 준수, 출력 형식 준수를 따로 기록합니다. 권한 위반을 평균 점수에 섞으면 다른 답을 잘해서 치명적인 오류를 덮는 일이 생깁니다.

예를 들어 정답 근거를 직접 제공했을 때 120개 중 평가 가능한 질문 대부분을 맞히는데 실제 검색에서는 많이 틀린다면, 추가 학습보다 검색 개선이 우선입니다. 반대로 같은 근거를 받아도 분류나 작성 규칙을 반복해서 어긴다면 파인튜닝 실험의 근거가 생깁니다. 통과 기준은 결과를 본 뒤 유리하게 정하지 말고 실험 전에 합의합니다.

비용과 보안은 어떤 순서로 확인해야 하나?

초기 학습비가 아니라 운영 중의 재처리 비용과 데이터 통제 가능성까지 비교해야 합니다.

월 2만 건을 처리하는 업무를 가정합니다. 방식 A의 사람 재검수율이 10%, 방식 B가 4%이고 건당 검수에 3분이 걸린다면, B는 월 1,200건의 검수를 줄입니다. 시간으로는 60시간입니다. 시간당 내부 인건비를 3만 원으로 가정하면 월 180만 원으로 계산됩니다. 이는 예시 계산이며 실제로 인력이나 지출이 그만큼 줄어든다는 보장은 아닙니다.

여기서 B의 추가 운영비와 학습비 상각액, 유지보수비를 빼야 합니다. RAG에는 문서 추출, 검색 색인, 검색 서버, 모델 입력 비용이 있습니다. 파인튜닝에는 데이터 라벨링, 학습, 추론, 재학습과 평가 비용이 있습니다. 작은 모델을 써도 검색 문서가 길거나 운영량이 적으면 기대한 절감이 나오지 않을 수 있습니다.

보안팀에는 “RAG라서 안전합니다” 대신 데이터 흐름을 제시합니다. 원문, 검색 색인, 모델 입력, 응답 로그, 학습 데이터, 모델 파일이 각각 어디에 저장되는지 표시합니다. 외부 API의 데이터 처리 조건도 실제 계약과 설정으로 확인해야 합니다.

특히 문서 삭제와 모델에서의 정보 제거는 같은 작업이 아닙니다. RAG도 원문만 삭제하면 색인과 캐시, 로그에 내용이 남을 수 있습니다. 파인튜닝은 특정 학습 데이터의 영향을 모델에서 제거하는 일이 더 복잡할 수 있습니다. 개인정보가 포함된다면 개인정보보호위원회의 생성형 AI 개인정보 처리 안내서를 기준으로 처리 근거와 안전조치를 검토합니다.

LLM 파인튜닝과 RAG에 관해 자주 묻는 질문

사내 데이터 활용, 폐쇄망 운영, 작은 모델 도입은 각각 학습 여부와 분리해서 판단해야 합니다.

검색 오류를 먼저 고치려면 RAG 구축, 사내 문서 검색 AI가 틀리는 이유부터를, 평가 기준을 만들려면 생성형 AI 답변 품질 평가, 감이 아니라 숫자로 재는 법을 이어 읽을 수 있습니다.

KITDI는 AI를 연구하고 이를 서비스와 기업 솔루션으로 구현합니다. 업무 선정과 검증 설계의 범위는 AX 컨설팅에서 확인할 수 있습니다.