AI 도입 전략2026.09.07읽는 시간 13분
파인튜닝은 언제 필요할까? 5분 판단 기준과 RAG 차이
지식을 넣는 문제인지 행동을 고정하는 문제인지부터 가르면 학습 비용이 줄어듭니다.
—VIEWS
—LIKES
—SAVES
지식을 넣는 문제인지 행동을 고정하는 문제인지부터 가르면 학습 비용이 줄어듭니다.
"프롬프트를 열 번 넘게 고쳤는데 결과가 매번 다릅니다. 이제 파인튜닝을 해야 하는 것 아닌가요?" "우리 회사 내부 문서를 AI가 모르는데, 그럼 파인튜닝으로 학습시키면 되나요?" "파인튜닝을 하면 데이터가 몇 건이나 필요한가요?" AI 도입 상담에서 반복해서 듣는 질문입니다.
파인튜닝은 잘못 고르면 데이터 준비, 검수, 평가, 재학습 운영이 모두 따라붙는 선택입니다. 반대로 제대로 고르면 프롬프트로는 잡히지 않던 출력 흔들림을 한 번에 줄여 줍니다. 이 글은 파인튜닝이 무엇인지 설명하는 대신, 지금 우리 회사가 파인튜닝을 검토할 시점인지 5분 안에 판단하도록 기준·단계·체크리스트를 정리했습니다.
파인튜닝은 이미 학습을 마친 모델에 입력과 정답 출력의 예시를 추가로 학습시켜 원하는 응답 형식과 판단 패턴을 반복해서 지키게 만드는 방법입니다. 즉 모델의 지식을 늘리는 작업이 아니라 모델의 행동을 고정하는 작업입니다.
이 구분이 실무에서 가장 자주 어긋납니다. AI가 사내 규정이나 최신 제품 정보를 모른다는 이유로 파인튜닝을 검토하는 경우가 많은데, 이는 지식 접근 문제이지 행동 문제가 아닙니다. 지식 접근 문제의 표준 해법은 검색으로 문서를 찾아 모델에 넣어 주는 RAG입니다.
새로운 사실을 파인튜닝으로 주입하는 방식에는 검증된 부작용도 있습니다. Gekhman 외 연구진의 EMNLP 2024 논문 「Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?」는 모델이 사전학습에서 접하지 못한 새 지식이 담긴 학습 예시를 훨씬 느리게 습득하며 그 예시들을 학습해 갈수록 모델의 환각 경향이 선형적으로 증가한다고 보고했습니다. 없는 지식을 넣으려고 파인튜닝을 쓰면 틀린 답이 늘어난다는 뜻입니다.
정리하면 판단 질문은 하나입니다. 지금 틀리는 이유가 모델이 정보를 못 받아서인지, 정보를 받고도 행동이 흔들려서인지 먼저 구분해야 합니다. 앞쪽이면 RAG이고, 뒤쪽이면 파인튜닝입니다.
세 방법은 경쟁 관계가 아니라 해결하는 병목이 다릅니다. 아래 표는 같은 문제를 놓고 무엇을 먼저 집어야 하는지 기준을 정리한 것입니다.
구분 | 프롬프트 | RAG | 파인튜닝 |
|---|---|---|---|
해결하는 병목 | 지시가 모호해서 생기는 편차 | 모델이 모르는 사내 정보 | 정보를 줘도 흔들리는 출력 형식·판단 |
필요한 준비물 | 좋은 지시문과 예시 몇 개 | 문서 정리, 검색 인덱스, 권한 설계 | 검수된 입력·출력 쌍과 평가 세트 |
정보 갱신 방식 | 지시문을 고치면 즉시 반영 | 문서를 교체하면 즉시 반영 | 다시 학습해야 반영 |
첫 결과까지 | 수 시간~수일 | 2~4주 | 데이터가 준비된 뒤 2~4주 |
전형적 실패 신호 | 지시문이 수백 줄로 늘어남 | 검색이 엉뚱한 문서를 가져옴 | 학습 데이터가 서로 모순됨 |
이 표는 순서를 말합니다. 프롬프트로 베이스라인을 만들고 지식 공백은 RAG로 메운 뒤, 평가에서 남은 오류가 행동 문제일 때 파인튜닝으로 넘어가는 순서가 가장 비용이 적게 듭니다. OpenAI의 「Optimizing LLM Accuracy」 가이드도 프롬프트 엔지니어링에서 시작해 평가 세트를 베이스라인으로 확보한 뒤, 더 많은 맥락이 필요한지 더 일관된 행동이 필요한지를 갈라 다음 수단을 고르라고 권합니다.
RAG와 파인튜닝을 놓고 하나를 고르는 단계라면 RAG와 파인튜닝의 선택 기준에서 항목별 비교를 확인할 수 있습니다.
상담 기록을 항상 같은 JSON 구조로 변환하거나, 사내 분류 체계 8개 중 하나로 문의를 배정하는 업무가 여기에 해당합니다. 프롬프트로도 형식을 지정할 수 있지만 예외 규칙이 늘어날수록 지시문이 길어지고 규칙끼리 충돌합니다. 같은 패턴이 반복되고 정답 예시를 모을 수 있다면 파인튜닝 후보입니다.
문서 분류, 표현 변환, 정해진 절차에 따른 1차 판단처럼 입력을 보면 정답 출력이 정해지는 업무가 파인튜닝에 잘 맞습니다. 조건이 하나 붙습니다. 담당자 여러 명이 같은 입력을 보고 같은 정답에 합의할 수 있어야 합니다. 사람끼리 정답을 합의하지 못하는 업무는 학습 데이터도 서로 모순되게 쌓입니다.
규칙, 예시, 예외 조건을 계속 붙이다 보면 프롬프트 하나가 수백 줄로 자라고 한 줄을 고칠 때마다 다른 업무가 깨집니다. 다만 길이만 보고 파인튜닝으로 넘어가면 안 됩니다. 프롬프트 구조가 잘못됐거나 한 프롬프트에 업무 세 개를 밀어 넣은 경우가 더 흔하며, 이때는 워크플로우를 단계로 쪼개는 편이 빠릅니다.
담당자의 체감보다 평가 결과가 신뢰할 만한 신호입니다. 프롬프트를 고치고 필요한 문서까지 검색해 넣었는데도 동일한 오류 유형이 같은 비율로 남는다면, 그때부터 파인튜닝은 근거 있는 실험이 됩니다. 반대로 오류 유형을 분류해 본 적이 없다면 아직 판단할 재료가 없는 상태입니다.
평가 없이 도입을 결정하는 관행이 실제 사고로 이어지고 있기 때문입니다. VentureBeat의 VB Pulse가 2026년 6월 엔터프라이즈 실무자 157명을 조사한 결과, 절반은 내부 평가를 통과한 AI 기능을 배포한 뒤에도 고객이 겪는 실패를 경험했고 4분의 1은 그런 일을 두 번 이상 겪었습니다. 같은 조사에서 자동 평가 결과를 전적으로 신뢰한다고 답한 비율은 5%에 그쳤습니다.
이 상황에서 평가 체계 없이 파인튜닝부터 시작하면 두 번 손해입니다. 학습에 들어간 데이터 준비 비용을 회수하지 못하고 개선됐는지 아닌지도 증명하지 못합니다. 반대로 평가 세트를 먼저 만들어 두면 파인튜닝을 하든 하지 않든 모델 교체·프롬프트 수정 때마다 같은 잣대를 재사용할 수 있습니다.
"답변 품질을 높인다"는 목표로는 성공 여부를 판정할 수 없습니다. "고객 문의를 사내 8개 카테고리 중 하나로 분류하고 정확도 90% 이상을 유지한다"처럼 대상 업무와 판정 기준을 한 문장에 담습니다.
실제 업무에서 나온 입력과 정답을 모아 평가 세트를 만든 다음 지금 쓰는 프롬프트의 성적을 기록합니다. 이 숫자가 이후 모든 개선의 기준선이 됩니다. 평가 세트 규모는 업무 난이도와 오류 유형 수에 따라 달라지므로, 유형별로 최소 몇 건씩은 들어가도록 설계합니다.
틀린 사례를 지식 부족, 지시 불이행, 형식 오류, 판단 오류로 나눕니다. 이 분류가 다음 단계의 수단을 결정합니다. 지식 부족이 대부분이면 파인튜닝은 후순위입니다.
프롬프트 구조 개선, RAG 연결, 외부 도구 호출로 사라지는 오류를 먼저 제거합니다. 여기서 목표 성능에 도달하면 파인튜닝은 필요하지 않습니다.
남은 오류에 반복되는 입력·출력 패턴이 있고 정답 데이터를 모을 수 있다면 소규모 파인튜닝 실험으로 넘어갑니다. OpenAI의 지도 파인튜닝 가이드는 최소 10건으로도 학습이 가능하지만 보통 50~100건의 잘 만든 예시에서 개선이 나타난다고 안내합니다. 처음부터 수천 건을 모으는 대신 소량으로 효과를 확인하고 늘리는 편이 안전합니다.
평가 세트가 있고 현재 프롬프트의 성적을 숫자로 알고 있습니다
베이스라인 없이는 파인튜닝 효과를 증명할 수 없습니다.
오류를 유형별로 분류해 봤고 지식 부족보다 형식·판단 오류가 많습니다
지식 부족이 많다면 RAG가 먼저입니다.
프롬프트 개선과 RAG 적용을 이미 시도했고 같은 오류가 남아 있습니다
더 단순한 수단이 남아 있으면 그것부터 씁니다.
입력과 정답 출력이 명확히 짝지어진 사례를 50건 이상 모을 수 있습니다
소규모 실험을 시작할 최소 재료입니다.
담당자 여러 명이 같은 입력에 같은 정답을 낼 수 있습니다
정답 합의가 안 되면 학습 데이터가 모순됩니다.
학습 후에도 데이터 갱신과 재학습을 맡을 담당자가 정해져 있습니다
파인튜닝은 한 번 하고 끝나는 작업이 아닙니다.
6개 중 3개 이상에 해당하면 소규모 파인튜닝 실험을 검토할 시점입니다. 5개 이상이면 파일럿 예산을 배정해도 무리가 없습니다. 2개 이하라면 아직 프롬프트와 RAG 단계에서 얻을 것이 남아 있습니다.
파인튜닝 비용은 학습 요금보다 데이터 준비와 평가에 훨씬 많이 들어갑니다. 아래는 국내 중견기업 단위에서 업무 하나를 대상으로 검토할 때의 일반적인 단계 구성입니다.
단계 | 기간 | 무엇이 나오나 |
|---|---|---|
업무 정의와 평가 세트 설계 | 1~2주 | 목표 한 문장, 평가 데이터, 판정 기준 |
베이스라인 측정과 오류 분류 | 1~2주 | 현재 성적, 오류 유형별 비중 |
프롬프트·RAG 개선 | 2~4주 | 단순 수단으로 제거된 오류 |
학습 데이터 구축과 검수 | 2~4주 | 검수된 입력·출력 쌍 |
파인튜닝 실험과 비교 평가 | 2~4주 | 학습 전후 성적 비교표 |
이 표에서 파인튜닝 학습 자체는 전체 일정에서 가장 짧은 구간입니다. 일정이 늘어나는 곳은 언제나 데이터 검수와 평가 설계이므로, 견적을 받을 때도 학습 요금이 아니라 이 두 항목의 공수를 먼저 확인하는 편이 좋습니다.
첫째, 최신 사내 정보를 답하게 만드는 것이 주목적이라면 파인튜닝을 미룹니다. 가격표, 정책, 제품 사양처럼 자주 바뀌는 정보는 바뀔 때마다 재학습해야 하므로 운영 부담이 계속 쌓입니다. 이 경우 사내 데이터를 AI에 연결하는 방식을 먼저 검토하는 편이 낫습니다.
둘째, 학습 데이터를 검수할 사람이 없다면 파인튜닝을 시작할 조건이 아닙니다. 업무 기록이 많다는 사실과 학습 가능한 데이터가 있다는 사실은 다릅니다. 입력과 정답이 짝지어져 있고 품질을 확인할 사람이 있어야 학습 데이터라고 부를 수 있습니다.
셋째, 평가 기준이 없다면 파인튜닝의 성패를 판정할 수 없습니다. 학습 전후를 같은 잣대로 비교하지 못하면 개선 여부를 놓고 매번 감각에 의존한 논쟁이 반복됩니다.
오류 유형을 분류하지 않고 시작합니다
지식 부족 오류를 파인튜닝으로 고치려다 환각만 늘어납니다.
데이터 수량만 채웁니다
서로 모순된 정답이 섞인 5,000건은 검수된 200건보다 나쁩니다.
평가 세트를 학습 데이터에서 분리하지 않습니다
성적이 좋아 보이지만 실제 업무에서는 재현되지 않습니다.
한 번 학습하고 방치합니다
업무 규칙이 바뀌면 모델은 옛 규칙을 계속 지키므로, 갱신 주기와 담당자를 미리 정해야 합니다.
파인튜닝을 할지 말지보다, 지금 틀리는 원인이 지식 접근인지 행동 일관성인지를 먼저 가려야 합니다. 이 구분만 정확해도 불필요한 학습 데이터 구축 비용을 줄일 수 있습니다.
넥스트젠AI의 무료 AX 진단에서는 업무 목표, 데이터 상태, 현재 오류 유형을 함께 확인해 프롬프트·RAG·파인튜닝 중 어디부터 손댈지 우선순위를 정리해 드립니다. 전체 도입 순서를 먼저 보고 싶다면 AX 컨설팅 가이드를 함께 확인할 수 있습니다.
무료 AX 진단을 신청하시면 첫 미팅에서 현재 사용 중인 프롬프트와 오류 사례를 함께 보고 판단 기준을 정리합니다.
RAG는 필요한 문서를 검색해 모델에 넣어 주는 방식이고, 파인튜닝은 입력과 정답 예시를 학습시켜 모델의 응답 방식을 고정하는 방식입니다. 최신 사내 정보를 답하게 하려면 RAG, 정보를 줘도 형식과 판단이 흔들리면 파인튜닝을 검토합니다.
RELATED · 함께 읽으면 좋은 글
