Fine-tuning vs RAG vs 프롬프트: 비용 기준 선택

Fine-tuning vs RAG vs 프롬프트 엔지니어링: 비용 효율적인 LLM 커스터마이징 전략

"우리 도메인에 맞게 LLM을 커스터마이징하려면 파인튜닝을 해야 하지 않나요?" — 이 질문에 대한 답은 대부분 "아니요"입니다. 방법 선택이 잘못되면 수천만 원을 쓰고도 원하는 결과를 못 얻습니다.

세 가지 방법의 본질적 차이

실제 사용량으로 비용 비교하기

2026-09-30 확인 기준, 토큰 단가와 파인튜닝 사용 가능 여부는 공급사·모델별로 다릅니다. OpenAI는 2026년 5월 신규 사용자의 파인튜닝 플랫폼 접근 종료를 공지했습니다. 도입 계획 전에 계정의 이용 자격을 확인하세요. 이 글의 근거 없는 고정 금액 예시는 제거했습니다.

각 방안에 대해 요청당 입력·출력 토큰, 월 요청량, 검색·저장 비용, 평가 인건비, 학습·재학습 비용을 기록합니다. 토큰 비용은 확인일이 있는 공식 단가를 사용해 (입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가) / 1,000,000으로 계산합니다. 같은 평가 세트에서 검색과 프롬프트의 추가 토큰도 측정하세요.

출처: OpenAI 가격표, OpenAI 파인튜닝 이용 변경 공지, Anthropic 가격표. 이 비교에서 모델 API 호출이나 실제 업무 비용 측정은 수행하지 않았습니다.

언제 무엇을 선택할 것인가

프롬프트 엔지니어링 선택 조건:
  ✓ 빠른 프로토타입이 필요할 때
  ✓ 출력 형식만 제어하면 될 때
  ✓ 예산이 제한적일 때

RAG 선택 조건:
  ✓ 최신 정보나 사내 문서가 필요할 때
  ✓ 출처 추적이 중요할 때
  ✓ 지식이 자주 업데이트될 때

Fine-tuning 선택 조건:
  ✓ 특정 스타일·형식을 완전히 고정해야 할 때
  ✓ 저지연 극한 최적화가 필요할 때
  ✗ 지식 주입이 목적이라면 → RAG가 거의 항상 더 낫다

조합 전략이 최선

# 실전 조합: 고객 지원 봇
# 1단계: 프롬프트 엔지니어링으로 응답 형식·톤 고정
# 2단계: RAG로 최신 제품 정보·FAQ 검색
# 3단계: Fine-tuning은 불필요

system_prompt = """당신은 [회사명] 고객 지원 전문가입니다.
- 항상 정중하고 공감하는 톤을 유지하세요
- 제공된 참고 문서만 기반으로 답변하세요"""

def answer_customer(question):
    context = vector_search(question, top_k=3)
    response = llm.chat([
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": f"참고 문서:\n{context}\n\n질문: {question}"}
    ])
    return response

다음 편에서는 AI 프로젝트의 ROI를 실제로 계산하고 경영진에게 보고하는 방법을 다룹니다.

요구사항별 최종 의사결정표

운영 원칙: 프롬프트 → RAG → FT 순서로 올라가고, 내려올 수 있는지도 점검하세요. FT는 데이터 재구축·재학습 비용이 반복 발생하는 유일한 선택지이므로, "이 문제를 프롬프트나 검색으로 정말 못 푸는가"를 문서화한 뒤에 도입하는 것이 비용 사고를 막습니다.

선택 매트릭스

비용 감각: 프롬프트 < RAG 운영 < 풀 FT 데이터셋

선택이 맞았는지 검증하는 단계별 실험

세 방법 중 무엇을 쓸지는 토론보다 작은 실험을 순서대로 돌려 보면 빠르게 결론이 납니다. 흔한 실수는 최신 지식 반영이 목적인데 파인튜닝부터 시작하는 것입니다. 파인튜닝은 말투·형식·특정 작업 방식을 익히게 하는 데 적합하고, 자주 바뀌는 사실을 넣는 용도로는 갱신 비용이 큽니다.

실험 순서

1. 평가 세트 준비: 실제 질문 100건 안팎과 정답(또는 채점 기준)을 만듭니다.
2. 프롬프트만으로 기준선 측정: 지시문과 예시(few-shot)를 다듬어 정확도·형식 준수율을 기록합니다.
3. RAG 추가: 실패한 문항이 "지식이 없어서"인지 확인하고, 그런 문항이 많으면 검색을 붙여 재측정합니다.
4. 여전히 실패하는 문항이 "형식·스타일·작업 방식" 문제라면 그때 파인튜닝을 검토합니다.

# 실패 원인 태깅 예시: 결과를 원인별로 집계
from collections import Counter
reasons = Counter(r["fail_reason"] for r in results if not r["correct"])
print(reasons.most_common())   # 원인별 실패 건수가 많은 순서로 출력

missing_knowledge가 많으면 RAG, format이 많으면 프롬프트 형식 지시나 파인튜닝, reasoning이 많으면 더 강한 모델이나 단계 분해를 우선 검토합니다.

비용 비교 방법

• 단계마다 1,000건 처리 기준의 토큰 비용, 검색 인프라 비용, 학습 비용(파인튜닝 시)과 재학습 주기를 같은 표에 적습니다.
• 정확도 향상 폭 대비 추가 비용을 보고, 향상이 미미하면 이전 단계에서 멈춥니다.

재발 방지

• 평가 세트를 저장소에 두고 모델·프롬프트·데이터가 바뀔 때마다 같은 순서로 재측정합니다.

참고 자료

• OpenAI fine-tuning
• AWS RAG

검증 환경·편집자 주

• 2026-09. “일단 FT”는 대부분 과투자입니다.

자주 묻는 질문 (FAQ)

Q. RAG와 FT를 같이 쓰나요?
가능. FT로 형식, RAG로 사실을 담당하는 조합이 흔합니다.

코드 검증 범위 (2026-09-30)

Python 3.14.6에서 코드 블록의 문법을 ast.parse로 확인했습니다. 외부 SDK 호출·실제 서비스 연결·성능 수치는 이 검사에 포함되지 않습니다. 예시의 의존성과 모델 사용 가능 여부는 실행 환경에서 별도 확인해야 합니다.

공식 참고: OpenAI pricing, fine-tuning availability update.