GPT 파인튜닝과 RAG, 어떤 방식이 우리 서비스에 맞을까?

AI 서비스를 기획할 때 다음과 같은 요구가 자주 나옵니다.

• 우리 회사 문서를 학습시켜 주세요.
• 회사 말투로 답하게 만들고 싶습니다.
• 상품 정보를 정확하게 알고 답해야 합니다.
• 기존 상담 사례를 반영하고 싶습니다.
• 우리만의 AI 모델을 만들고 싶습니다.

이런 요구를 모두 파인튜닝이 필요하다고 표현하는 경우가 있습니다.

하지만 실제로는 다음 방법 중 하나 또는 여러 방법을 조합해 해결할 수 있습니다.

• 프롬프트 설계
• 문서 검색 기반 답변
• 파인튜닝
• 일반 코드와 규칙
• 외부 API와 데이터베이스 연결

각 방법은 해결하는 문제가 다릅니다.

따라서 기술 이름부터 정하기보다 다음 질문을 먼저 확인해야 합니다.

AI가 몰라서 문제인가, 말투와 형식이 일정하지 않아서 문제인가, 아니면 실제 시스템 데이터를 조회하지 못해서 문제인가?

먼저 용어를 구분해야 합니다

1. 프롬프트 설계

AI에게 해야 할 일과 결과 형식을 구체적으로 지시하는 방식입니다.

예시:

당신은 B2B 고객지원 담당자입니다.

답변은 다음 조건을 따라야 합니다.

- 세 문단 이내로 작성
- 확인되지 않은 정보는 추측하지 않음
- 환불 문의에는 공식 환불정책 링크 제공
- 정중한 한국어 사용

서비스 코드에서 사용자 입력과 함께 프롬프트를 구성할 수 있습니다.

2. RAG

사용자 질문과 관련 있는 문서나 데이터를 먼저 검색하고, 검색된 내용을 AI에게 전달해 답변하게 하는 구조입니다.

예시:

사용자 질문
→ 회사 문서 검색
→ 관련 규정 발견
→ 규정 내용을 AI에 전달
→ 답변과 출처 생성

사내 문서, 제품 설명과 정책처럼 자주 변경되는 정보를 다룰 때 검토할 수 있습니다.

3. 파인튜닝

기존 AI 모델에 여러 입력·출력 예시를 추가로 학습시켜 특정한 응답 경향을 갖도록 조정하는 방식입니다.

예시 데이터:

입력:
고객에게 일정이 지연된 사실을 안내해 주세요.

원하는 출력:
안녕하세요. 예정된 일정에 변동이 발생해 안내드립니다...

특정 말투, 분류 방식과 일관된 결과 형식을 만들 때 활용할 수 있습니다.

4. 일반 코드와 규칙

AI가 판단할 필요가 없는 정보는 일반 코드로 처리하는 편이 정확할 수 있습니다.

예시:

• 상품 가격
• 다음 결제일
• 예약 상태
• 회원 등급
• 배송 정보
• 남은 크레딧

이 값을 데이터베이스에서 직접 조회한 뒤 AI가 설명만 담당하도록 구성할 수 있습니다.

프롬프트만으로 충분할 수 있는 경우

1. 작업 범위가 명확합니다

• 이메일 초안
• 제목 생성
• 간단한 분류
• 문체 변환
• 정해진 항목 추출

충분한 지시와 예시를 프롬프트에 넣으면 원하는 결과를 얻을 수 있을 수 있습니다.

2. 참고 데이터가 많지 않습니다

브랜드 소개와 문체 가이드가 짧다면 매 요청에 함께 전달할 수 있습니다.

3. 빠른 MVP가 목적입니다

시장 반응을 먼저 확인해야 한다면 프롬프트 방식으로 시작하고 실제 문제를 수집한 뒤 다른 방식을 추가할 수 있습니다.

4. 요구사항이 계속 바뀝니다

프롬프트는 비교적 빠르게 수정하고 테스트할 수 있습니다.

파인튜닝을 먼저 진행하면 요구사항 변경 때 학습 데이터와 모델을 다시 관리해야 할 수 있습니다.

프롬프트의 장점

• 빠르게 실험 가능
• 초기 비용을 줄이기 쉬움
• 수정과 비교가 편리함
• 별도 학습 데이터가 적어도 시작 가능
• 여러 모델에 적용 가능성

프롬프트의 한계

• 지시문이 길어질 수 있음
• 요청마다 같은 정보를 전달해 비용이 증가할 수 있음
• 결과가 항상 동일하지 않음
• 긴 지시 일부를 놓칠 수 있음
• 기업 전체 문서를 모두 넣기 어려움

RAG가 적합할 수 있는 경우

1. 회사 문서를 기준으로 답해야 합니다

• 환불정책
• 제품 매뉴얼
• 사내 규정
• 교육 자료
• 기술 문서
• 계약 안내
• FAQ

2. 정보가 자주 변경됩니다

가격과 정책이 바뀔 때마다 모델을 다시 학습시키는 것보다 원본 문서를 수정하고 검색 데이터에 반영하는 방식이 효율적일 수 있습니다.

3. 출처가 중요합니다

사용자는 AI 답변뿐 아니라 원문 근거를 확인해야 할 수 있습니다.

근거:
서비스 이용약관 제8조

4. 문서별 권한이 있습니다

직원과 부서, 고객사별로 검색할 수 있는 문서가 다를 수 있습니다.

검색 단계에서 권한을 적용할 수 있습니다.

RAG의 장점

• 문서 변경을 비교적 빠르게 반영
• 답변 근거 표시 가능
• 많은 문서를 검색해 활용 가능
• 최신 정보 관리에 유리
• 문서별 접근 권한 적용 가능

RAG의 한계

• 관련 문서를 제대로 찾지 못할 수 있음
• 오래되거나 잘못된 문서가 있으면 답변도 틀릴 수 있음
• 표와 이미지 처리가 어려울 수 있음
• 문서 정제와 버전 관리 필요
• 검색 결과가 맞아도 AI가 잘못 설명할 수 있음

RAG를 사용한다고 사실 오류가 자동으로 사라지는 것은 아닙니다.

파인튜닝이 적합할 수 있는 경우

1. 결과 스타일을 일정하게 만들고 싶습니다

• 브랜드 말투
• 상담 답변 형식
• 보고서 구조
• 분류 기준
• 특정 문장 패턴

많은 예시를 통해 원하는 응답 경향을 학습시킬 수 있습니다.

2. 반복 작업의 입력과 출력이 명확합니다

예시:

상담 내용
→ 문의 카테고리·긴급도·담당 부서

정답 데이터가 충분히 있다면 일관된 분류에 도움이 될 수 있습니다.

3. 긴 프롬프트를 줄이고 싶습니다

매 요청마다 많은 예시와 규칙을 전달하고 있다면 일부 행동을 모델에 반영하는 방법을 검토할 수 있습니다.

다만 파인튜닝 비용과 모델 운영을 함께 비교해야 합니다.

4. 일반 모델이 특정 형식을 반복해서 어깁니다

충분한 프롬프트와 구조화 출력 설정을 사용해도 같은 문제가 반복된다면 파인튜닝을 검토할 수 있습니다.

파인튜닝의 장점

• 특정 형식과 스타일의 일관성 개선 가능
• 반복적인 예시를 매번 전달하지 않아도 될 수 있음
• 특정 분류와 변환 작업에 활용 가능
• 서비스만의 응답 패턴 구성 가능

파인튜닝의 한계

• 학습 데이터 준비 필요
• 잘못된 데이터가 결과에 반영될 수 있음
• 정책이 바뀌면 다시 조정해야 할 수 있음
• 최신 지식을 자동으로 알게 되는 것은 아님
• 모델 제공 업체와 버전에 영향을 받을 수 있음
• 평가와 재학습 운영 필요

파인튜닝은 회사 문서를 기억시키는 만능 방법이 아닙니다

많은 문서와 최신 정책을 정확하게 조회해야 한다면 파인튜닝보다 검색 기반 구조가 더 적합할 수 있습니다.

파인튜닝은 다음 문제에 더 가깝습니다.

어떻게 답할 것인가?
어떤 형식으로 분류할 것인가?
어떤 스타일을 유지할 것인가?

RAG는 다음 문제에 더 가깝습니다.

어떤 정보를 근거로 답할 것인가?

두 방식을 함께 사용할 수도 있습니다.

RAG:
최신 문서와 사실 검색

파인튜닝:
답변 말투와 구조 통일

실제 데이터 조회는 RAG만으로 해결되지 않을 수 있습니다

사용자가 다음과 같이 질문한다고 가정해 보겠습니다.

내 다음 결제일이 언제인가요?

이 답은 일반 문서에 없습니다.

사용자 계정의 실제 구독 데이터를 조회해야 합니다.

흐름:

사용자 인증
→ 구독 데이터 조회
→ 다음 결제일 확인
→ AI가 이해하기 쉽게 설명

예약, 주문과 크레딧처럼 실시간 사용자 데이터는 서비스 API와 연결해야 합니다.

규칙으로 처리하는 편이 나은 것

AI가 하지 않아도 되는 작업을 구분해야 합니다.

• 금액 계산
• 날짜 계산
• 회원 권한
• 결제 승인
• 재고 차감
• 쿠폰 조건
• 예약 중복 검사
• 개인정보 접근 제한

AI는 자연어 이해와 설명을 담당하고 중요한 업무 규칙은 코드로 검증하는 편이 안전할 수 있습니다.

방식별 비교

상황별 선택 예시

회사 FAQ 챗봇

RAG + 프롬프트

• 문서 검색
• 출처 표시
• 답변 말투 설정

브랜드 문안 생성

프롬프트부터 시작
→ 데이터가 충분히 쌓이면 파인튜닝 검토

문의 자동 분류

프롬프트·일반 모델 테스트
→ 정답 데이터 확보
→ 필요할 때 파인튜닝

주문 조회 챗봇

사용자 인증
+ 주문 API
+ AI 답변 생성

사내 규정 챗봇

RAG
+ 문서 권한
+ 출처
+ 답변 제한

정확한 숫자 계산 서비스

일반 코드로 계산
+ AI는 결과 설명

학습 데이터 준비

파인튜닝을 검토한다면 입력과 원하는 출력의 예시가 필요합니다.

좋은 데이터의 조건:

• 실제 서비스 목적과 일치
• 정답 기준이 명확
• 표현과 상황이 다양
• 잘못된 정보가 없음
• 개인정보 정리
• 중복 제거
• 형식 통일

데이터가 많다는 사실보다 품질과 일관성이 중요합니다.

기존 상담 기록을 그대로 사용하면 안 되는 이유

상담 기록에는 다음 문제가 있을 수 있습니다.

• 담당자마다 답변이 다름
• 오래된 정책
• 개인정보
• 오탈자
• 잘못된 답변
• 내부 메모
• 비공개 고객 정보

학습 전에 선별과 정제, 권리와 개인정보 검토가 필요할 수 있습니다.

정답 데이터와 평가 데이터 분리

모든 데이터를 학습에 사용하면 성능을 객관적으로 평가하기 어렵습니다.

다음처럼 나눌 수 있습니다.

학습용 데이터
검증용 데이터
최종 평가용 데이터

새로운 질문에서도 원하는 결과가 나오는지 확인해야 합니다.

품질 평가

어떤 방식을 사용하든 테스트가 필요합니다.

평가 항목:

• 사실 정확성
• 문서 근거
• 형식 준수
• 말투
• 누락
• 잘못된 추론
• 답변 거절
• 처리 시간
• 비용

운영 중 버전 관리

다음 요소가 바뀔 수 있습니다.

• 프롬프트
• 검색 설정
• 문서
• 파인튜닝 데이터
• 모델
• 후처리 코드

결과가 좋아지거나 나빠졌을 때 원인을 찾기 위해 버전을 기록하는 것이 좋습니다.

비용 구조

프롬프트 방식

• AI API 사용료
• 긴 입력에 따른 비용
• 프롬프트 관리

RAG 방식

• 문서 처리
• 검색 데이터 저장
• 문서 갱신
• AI API
• 관리자
• 권한

파인튜닝 방식

• 데이터 정제
• 학습
• 모델 사용
• 평가
• 재학습
• 버전 관리

일반 시스템 연동

• API 개발
• 권한
• 데이터 조회
• 오류 처리
• 관리자 로그

초기 구축비뿐 아니라 문서와 모델을 계속 관리하는 운영비를 함께 확인해야 합니다.

흔한 오해

“파인튜닝하면 최신 회사 정보를 모두 압니다.”

최신 정책을 계속 반영해야 한다면 별도 문서 검색이나 데이터 연동이 필요할 수 있습니다.

“RAG를 쓰면 틀린 답변을 하지 않습니다.”

검색 실패와 문서 오류, AI 해석 오류가 남을 수 있습니다.

“프롬프트만 잘 쓰면 모든 문제를 해결합니다.”

문서가 너무 많거나 실시간 데이터가 필요하면 구조적인 연동이 필요합니다.

“우리만의 모델을 만들면 경쟁사가 따라올 수 없습니다.”

서비스 경쟁력은 모델뿐 아니라 데이터, 운영 흐름, 사용자 경험과 고객 기반에서 나올 수 있습니다.

결정 순서

1. 해결할 업무를 정의한다.
2. 원하는 입력과 출력 예시를 만든다.
3. 일반 프롬프트로 테스트한다.
4. 최신 문서가 필요하면 RAG를 검토한다.
5. 실시간 데이터가 필요하면 API를 연결한다.
6. 스타일·분류 문제가 반복되면 파인튜닝을 검토한다.
7. 동일한 평가 데이터로 비교한다.

업체에 전달할 요구사항

AI가 수행할 업무:
현재 문제:
사용자 입력:
원하는 출력:
정답 예시:
참고 문서:
문서 변경 주기:
출처 표시:
실시간 데이터:
사용자별 데이터:
말투:
결과 형식:
현재 보유한 학습 데이터:
데이터 건수:
개인정보:
예상 사용량:
허용 가능한 응답 시간:
희망 일정:

업체에 물어볼 질문

• 프롬프트만으로 먼저 검증할 수 있나요?
• RAG가 필요한 이유는 무엇인가요?
• 파인튜닝이 해결하는 문제가 무엇인가요?
• 실시간 데이터는 어떻게 연결하나요?
• 문서가 바뀌면 어떻게 반영하나요?
• 답변 출처를 표시할 수 있나요?
• 품질은 어떤 질문으로 평가하나요?
• 학습 데이터는 누가 정제하나요?
• 모델 변경이 가능한 구조인가요?
• 구축 후 어떤 운영 비용이 발생하나요?

마무리

GPT 파인튜닝, RAG와 프롬프트는 경쟁하는 하나의 선택지가 아니라 서로 다른 문제를 해결하는 방법입니다.

• 작업과 형식을 빠르게 지시하려면 프롬프트
• 최신 회사 문서를 검색하려면 RAG
• 반복되는 스타일과 분류 패턴을 학습시키려면 파인튜닝
• 사용자별 실시간 데이터를 다루려면 API와 일반 코드

기술 이름부터 선택하지 말고 현재 AI 결과가 왜 부족한지부터 진단하는 것이 좋습니다.