AI 서비스의 답이 틀리면 “RAG를 붙일까, 파인튜닝을 할까?”라는 질문부터 나오기 쉽습니다. 하지만 최신 이용 안내를 몰라서 틀린 답과, 안내를 읽고도 정해진 분류 규칙을 지키지 못한 답은 고쳐야 할 곳이 다릅니다. 먼저 실패의 종류를 나누면 학습 비용을 쓰거나 검색 시스템을 만드는 순서도 정할 수 있습니다.
이 글은 문서 기반 질의응답과 업무 자동화를 만드는 개발자를 위한 선택 가이드입니다. RAG의 검색·생성 흐름이 처음이라면 RAG 실전 설계와 답변 품질 평가를 먼저 읽고, 여기서는 “어느 부분을 바꿔야 내 문제가 해결되는가”에 집중해보세요.
RAG와 파인튜닝은 바꾸는 대상이 다릅니다
RAG는 질문에 필요한 외부 자료를 찾아 모델의 입력에 함께 넣는 방식입니다. 문서 내용을 갱신해 검색 결과에 반영하면 생성 모델을 다시 학습하지 않고도 새 자료를 참고하게 할 수 있습니다. 단, 원문을 고친 것과 검색 인덱스·캐시까지 갱신된 것은 다릅니다. 실제로 어떤 버전이 검색됐는지 확인해야 합니다.
파인튜닝은 사전학습된 모델을 추가 데이터로 학습해 특정 과제나 도메인에 적응시키는 과정입니다. 전체 가중치를 조정할 수도 있고, 일부 학습 가능한 파라미터만 조정할 수도 있습니다. Hugging Face의 파인튜닝 문서도 이미 학습된 모델에서 출발해 과제·도메인에 맞는 데이터로 학습을 계속하는 과정으로 설명합니다.
따라서 “RAG는 지식, 파인튜닝은 말투”라고만 나누면 부족합니다. 파인튜닝은 분류·정보 추출·도메인 언어 처리에도 활용할 수 있고 학습한 사실의 영향을 받을 수 있습니다. 다만 자주 바뀌는 사실을 정확히 교체하고 근거 문서를 추적하는 용도로는 외부 자료를 관리하는 방식이 더 직접적입니다. 이 글의 학습 데이터 예시는 입력과 기대 출력을 사용하는 지도 파인튜닝을 중심으로 합니다.
| 비교 항목 | RAG | 파인튜닝 |
|---|---|---|
| 주로 바꾸는 것 | 질문 시 제공하는 근거와 검색 과정 | 추가 학습으로 얻는 모델의 동작 |
| 새 자료 반영 | 문서·색인·캐시 갱신을 검증 | 학습 데이터 수정, 재학습과 재평가가 필요할 수 있음 |
| 준비할 데이터 | 검색 가능한 원문, 버전, 출처와 접근 권한 | 학습 목적에 맞는 데이터와 별도 평가 자료 |
| 먼저 볼 실패 | 필요한 근거가 검색·전달되는지 | 처음 보는 입력에서도 원하는 과제를 수행하는지 |
| 자동으로 보장되지 않는 것 | 정답, 올바른 인용, 최신성 | 정답, 최신성, 원문 단위의 출처 추적 |
학습 전에 프롬프트와 기준 답안부터 만듭니다
처음부터 두 방식 중 하나를 도입할 필요는 없습니다. 처리할 문서가 짧고 매번 명확하게 지정된다면 필요한 내용을 입력에 직접 넣는 것만으로 시작할 수 있습니다. 출력 규칙이 모호하다면 허용 값, 빠진 정보의 처리 방법, 올바른 예시를 먼저 정리하는 편이 실험하기 쉽습니다.
예를 들어 문의를 배송, 결제, 기타로 분류하는 서비스라면 “알맞게 분류하라”보다 범주별 정의와 경계 사례가 필요합니다. “배송비 결제가 두 번 됐다”를 어디로 보낼지 운영자가 합의하지 못했다면, 학습 데이터를 늘려도 서로 다른 정답을 가르치게 됩니다.
JSON을 반환해야 한다면 모델에 형식을 설명하는 것과 별개로 애플리케이션에서 파싱, 필수 필드, 허용 값, 자료형을 검사하세요. 사용하는 모델·API가 구조화된 출력을 지원하는지도 확인할 수 있습니다. 형식 준수와 내용의 정확도는 따로 평가해야 하며, 유효한 JSON이라는 이유만으로 올바른 업무 판단이라고 볼 수는 없습니다.
세 가지 개발 상황으로 선택해봅니다
다음은 실제 운영 결과가 아닌 설계 예시입니다. 기술 이름보다 지금 관찰한 실패를 기준으로 첫 실험을 정해보세요.
| 상황 | 먼저 해볼 일 | 다음 판단 기준 |
|---|---|---|
| 매주 바뀌는 제품 안내를 오래된 내용으로 답함 | 최신 문서의 수집·검색·버전 선택 확인 | 최신 근거를 전달했을 때 답이 고쳐지는가? |
| 원문은 충분한데 문의 분류가 일관되지 않음 | 분류 정의, 프롬프트, 예시와 기준 답안 정리 | 일관된 학습 자료가 있고, 별도 평가에서도 반복되는 오류인가? |
| 최신 안내도 필요하고 고정된 업무 형식도 필요함 | 기본 모델과 RAG로 기준 결과 확보 | 같은 근거를 받아도 남는 행동 오류를 추가 학습이 줄이는가? |
첫 번째 상황에서 모델을 다시 학습하면 다음 주 문서 변경 때 같은 문제가 생길 수 있습니다. 반대로 두 번째 상황에서 검색 결과만 더 많이 넣으면 이미 충분한 근거를 늘리는 데 그칠 수 있습니다. AWS의 RAG·파인튜닝 비교 안내도 자체 문서를 참조하는 질의응답에는 RAG부터 검토하고, 필요에 따라 두 방식을 함께 사용할 수 있다고 설명합니다.
유용한 진단 실험은 개발자가 올바른 근거를 직접 골라 넣어보는 것입니다. 그때 답이 크게 좋아지면 검색·자료 전달을 우선 살펴볼 이유가 있습니다. 그래도 오류가 남으면 지시문, 모델 역량, 출력 처리와 학습 가능성을 검토합니다. 이것은 원인 범위를 좁히는 실험이며, 한 번의 성공으로 운영 성능이 증명되지는 않습니다.
파인튜닝의 준비물은 문서 묶음보다 일관된 학습 목표입니다
지도 파인튜닝을 한다면 “모델이 무엇을 다르게 하길 원하는가”를 입력과 기대 출력으로 표현할 수 있어야 합니다. Amazon Bedrock의 모델 맞춤화 문서는 지도 파인튜닝에서 라벨이 있는 예시를 사용해 입력에 대응하는 출력을 학습하고 모델 파라미터를 조정한다고 설명합니다.
문서 기반 답변을 학습시키는 경우에는 질문과 정답만 모으기보다, 실제 서비스처럼 근거 문서와 질문을 함께 제시하는 구성을 검토할 수 있습니다. 문서에 없는 내용을 추측하지 않는 사례, 조건을 확인해야 하는 사례, 충분한 근거가 있을 때 답하는 사례도 목적에 맞게 준비합니다. 모든 요청을 거절하는 예시만 늘리면 필요한 답변까지 줄어들 수 있으므로 균형도 확인해야 합니다.
데이터 양을 목표로 삼기 전에 중복 예시, 상충하는 정답, 오래된 정책과 불필요한 개인정보를 점검하세요. 필요한 양은 과제 난도, 기본 모델과 데이터 다양성에 따라 달라집니다. “몇 건이면 충분하다”는 숫자를 다른 프로젝트에서 그대로 가져오기보다, 학습량을 늘릴 때 별도 평가 성능이 어떻게 달라지는지 보는 편이 유용합니다.
학습에 쓴 질문의 표현만 조금 바꿔 평가하면 실제보다 잘하는 것처럼 보일 수 있습니다. 같은 원문·사건에서 파생된 예시는 한쪽 묶음에 두는 등 분리 기준을 정하세요. scikit-learn의 데이터 누수 안내처럼 최종 평가 데이터를 모델 선택에 사용하지 않는 원칙을 지키되, 업무 자료의 시간 순서와 중복 관계도 함께 고려해야 합니다.
LoRA는 파인튜닝을 구현하는 방법 중 하나입니다
RAG, 파인튜닝, LoRA를 서로 대등한 세 가지 제품처럼 비교하면 선택이 복잡해집니다. LoRA는 원래 모델 가중치를 고정하고 선택된 계층에 작은 저랭크 행렬을 학습하는 파라미터 효율적 적응 방법입니다. LoRA 원 논문은 전체 파라미터를 학습하는 방식에 비해 학습 대상과 메모리 부담을 줄이는 접근을 제시합니다.
다만 LoRA를 선택했다고 데이터 정리와 평가가 쉬워지는 것은 아닙니다. 어떤 계층에 적용할지, 어느 정도 용량을 줄지, 어떤 기본 모델과 조합할지에 따라 결과가 달라집니다. 논문에서 보고한 비용·성능 수치를 자신의 모델과 하드웨어에서도 그대로 얻는다고 가정해서는 안 됩니다.
RAG와 파인튜닝을 함께 쓸 때는 역할을 분리합니다
두 방식은 함께 사용할 수 있습니다. 예를 들어 검색 계층은 현재 사용자가 볼 수 있는 최신 안내를 가져오고, 추가 학습한 생성 모델은 그 안내를 읽어 정해진 응답 형식으로 답하도록 구성할 수 있습니다. 이때 파인튜닝의 목표는 오래된 답을 암기시키는 것이 아니라 실제 서비스의 입력 구조에서 필요한 행동을 개선하는 것입니다.
- 애플리케이션이 사용자 권한과 문서 조건을 확인합니다.
- 검색 계층이 관련 근거와 출처·버전을 가져옵니다.
- 모델이 질문, 근거, 출력 규칙을 받아 답합니다.
- 애플리케이션이 필수 필드와 허용 값을 검사하고 필요한 검토 경로로 보냅니다.
접근 권한과 문서 선택은 프롬프트에 “권한을 지켜라”라고 쓰는 것만으로 해결되지 않습니다. Microsoft의 RAG 설명도 검색 시 허용된 자료만 접근하도록 하는 통제를 주요 과제로 다룹니다. 학습한 모델이 규칙을 잘 따르더라도 권한 필터와 출처 검증은 별도로 유지해야 합니다.
네 가지 조합을 비교하면 추가 학습의 가치를 분리해 볼 수 있습니다
파인튜닝 후보가 준비됐다면 아래처럼 비교군을 만들 수 있습니다. 검색을 붙인 효과와 모델을 바꾼 효과를 한 번에 섞지 않는 것이 목적입니다. 처음부터 네 가지를 모두 구현할 필요는 없으며, 기본 모델의 오류를 분석한 뒤 필요한 비교군을 추가하세요.
| 비교군 | 구성 | 확인할 질문 |
|---|---|---|
| A | 기본 모델 + 정리한 프롬프트 | 추가 시스템 없이 어디까지 가능한가? |
| B | A + RAG | 현재 근거를 제공하면 사실 오류가 줄어드는가? |
| C | 파인튜닝 모델 + 동일한 업무 지시 | 새 입력에서도 과제 수행이 나아지는가? |
| D | C + B와 같은 검색 결과 | 같은 근거를 읽는 조건에서 추가 학습의 이점이 있는가? |
B와 D를 비교할 때는 동일한 질문에 동일한 문서 조각을 전달하도록 검색 결과를 고정하면 생성 모델의 차이를 보기 쉽습니다. 이후에는 실제 검색까지 포함한 전체 흐름을 별도로 평가합니다. 모델 버전, 프롬프트, 생성 설정과 평가 시점도 기록하세요. 비교 도중 문서나 기준 답안이 바뀌면 무엇이 개선됐는지 해석하기 어렵습니다.
전체 정답률 하나로 결론을 내리지 말고, 형식 준수율, 내용의 정확도, 인용 근거의 적절성, 답할 수 없는 질문에서의 처리, 과제별 실패를 나눠 확인하세요. 작은 표본에서는 몇 개의 결과만 바뀌어도 비율이 크게 움직이므로 성공 건수와 전체 건수를 함께 적는 편이 좋습니다.
평가 기록에는 case_id, variant, document_version, schema_ok, answer_correct, latency_ms처럼 비교에 필요한 항목을 둘 수 있습니다. 식별자는 평가 사례용으로 만들고 실제 사용자 식별정보를 넣지 마세요. 스키마 통과는 코드로 확인하되 정답과 근거의 일치는 별도 판정 기준이 필요합니다. 자동 점수가 높더라도 오류 유형별로 실제 답을 읽어보는 과정이 유용합니다.
비용은 학습비와 한 번의 호출료를 넘어 계산합니다
RAG에는 자료 수집·정제·색인 갱신, 검색과 재정렬, 모델에 전달하는 문맥의 비용이 들어갑니다. 파인튜닝에는 학습 자료 작성·검수, 학습 실행, 모델 보관·배포, 재평가와 재학습 비용이 들어갑니다. 두 방식 모두 오류를 처리하는 사람의 시간과 운영 지연을 포함해야 합니다.
실험에서는 같은 품질 기준을 충족한 결과끼리 월간 예상 비용과 응답 시간을 비교하세요. 추가 학습으로 프롬프트를 줄일 가능성이 있어도 항상 더 저렴하거나 빨라지는 것은 아닙니다. 검색 결과를 줄여 호출비가 낮아졌더라도 필요한 조건을 빠뜨려 재질문이 늘었다면 전체 비용은 달라질 수 있습니다.
특정 금액이나 손익분기점을 일반화하기보다 예상 요청 수, 입력·출력량, 문서 갱신 빈도와 검수 시간을 적어두면 판단하기 쉽습니다. 품질을 통과한 요청 한 건을 처리하는 비용을 보되, 실패 요청에 쓴 비용도 분자에 포함해야 비교가 과하게 낙관적이지 않습니다.
오늘 할 일은 실패 사례를 고쳐야 할 위치로 나누는 것입니다
현재 서비스의 대표 실패를 모아 “근거가 없었음”, “근거를 잘못 찾았음”, “근거를 읽고도 잘못 판단함”, “출력 처리에서 실패함”으로 나눠보세요. 최신 자료를 직접 넣었을 때 고쳐지는지부터 확인하면 RAG 개선과 학습 실험의 우선순위를 정할 수 있습니다. 범주가 겹치는 경우도 기록해야 합니다.
개념과 주변 기술을 함께 정리하려면 ORBiS Tree의 Fine-tuning 문서와 RAG 문서로 이어서 읽을 수 있습니다. 기술을 정한 뒤 데이터를 끼워 맞추기보다, 해결하려는 실패와 통과해야 할 평가 기준을 먼저 정하는 것이 이 글에서 제안하는 출발점입니다.
출처 확인: 2026년 9월 30일. 표의 개발 상황과 비교 실험은 설명을 위해 구성한 예시이며 실측 성능 수치가 아닙니다. 코딩인파이와 ORBiS Tree는 같은 운영자가 운영합니다.