Fine-tuning vs Prompting vs RAG 비교
이 세 가지는 LLM을 특정 작업에 맞추는 대표적 방법입니다. 올바른 선택이 프로젝트 성공을 좌우합니다.| 항목 | Prompting | RAG | Fine-tuning |
|---|---|---|---|
| 비용 | 낮음 (API 호출만) | 중간 (벡터 DB + 검색) | 높음 (GPU + 데이터 준비) |
| 구현 시간 | 수 시간 | 수 일~수 주 | 수 주~수 개월 |
| 구현 난이도 | 쉬움 | 중간 | 어려움 |
| 지식 업데이트 | 즉시 | 즉시 (문서 업데이트) | 재학습 필요 (수 일) |
| 정확도 | 보통 | 높음 (검색 품질 의존) | 높음 (데이터 품질 의존) |
| 환각(Hallucination) | 높음 | 낮음 (출처 기반) | 중간 |
| 데이터 필요량 | 없음 | 문서 코퍼스 필요 | 수천~수만 예시 필요 |
| Databricks 도구 | AI Playground | Vector Search + Agent | Mosaic AI Training |
| 적합한 경우 | 범용 작업, 빠른 테스트 | 사내 문서 Q&A, 최신 정보 필요 | 도메인 특화 언어/스타일, 특수 포맷 |
성공 실무 권장 순서: Prompting으로 시작 → 부족하면 RAG 추가 → 그래도 부족하면 Fine-tuning 검토. 대부분의 Enterprise 사용 사례는 RAG로 충분합니다.
비유로 이해하기
- Prompting: 전문가에게 “이런 방식으로 대답해주세요”라고 요청하는 것
- RAG: 전문가에게 관련 문서를 건네주고 “이 문서를 참고해서 대답하세요”라고 요청하는 것
- Fine-tuning: 전문가를 특정 분야에서 추가로 교육시키는 것
LLM 추론 최적화 (Inference Optimization)
LLM 서빙은 비용이 매우 높습니다. 하나의 대형 모델을 서빙하는 데 고가의 GPU가 여러 대 필요하며, 사용자 수가 늘어날수록 비용이 급격히 증가합니다. 추론 최적화 기법을 이해하면, 고객에게 비용 구조를 설명하고 적절한 아키텍처를 제안할 수 있습니다.KV Cache (Key-Value 캐시)
LLM은 토큰을 하나씩 순차적으로 생성합니다(Autoregressive Generation). 매 토큰 생성 시 이전 모든 토큰의 Key-Value 쌍을 다시 계산하면 엄청난 낭비가 발생합니다.- 원리: 이미 계산된 Key-Value 쌍을 GPU 메모리에 캐싱하여, 새 토큰 생성 시 재사용
- 효과: 토큰 생성 속도를 수십 배 향상
- 대가: GPU 메모리를 추가로 사용 (컨텍스트가 길수록 KV Cache 크기 증가)
- 컨텍스트 윈도우 제한과의 관계: 128K 토큰 컨텍스트에서 KV Cache만으로 수십 GB 메모리 필요
Quantization (양자화)
모델 가중치의 수치 정밀도를 낮추어 메모리 사용량과 연산 비용을 줄이는 기법입니다.| 정밀도 | 비트 수 | Llama 70B 메모리 | 정확도 손실 | 비고 |
|---|---|---|---|---|
| FP32 | 32비트 | ~280 GB | 없음 (기준) | 학습 시 사용 |
| FP16/BF16 | 16비트 | ~140 GB | 거의 없음 | 일반적 추론 기준 |
| INT8 | 8비트 | ~70 GB | 미미함 | 널리 사용되는 양자화 |
| INT4 | 4비트 | ~35 GB | 소폭 존재 | 비용 민감한 환경 |
Batching (배칭)
여러 사용자의 요청을 동시에 처리하여 GPU 활용률을 극대화합니다.- Static Batching: 고정된 배치 크기로 요청을 묶어 처리. 짧은 요청도 가장 긴 요청이 끝날 때까지 대기
- Continuous Batching (vLLM 방식): 완료된 요청을 즉시 빼고 새 요청을 동적으로 삽입. GPU 유휴 시간 최소화
- 효과: 동일 GPU에서 처리량(throughput) 2~10배 향상
Speculative Decoding (투기적 디코딩)
작고 빠른 모델(Draft Model)이 여러 토큰을 미리 생성하고, 큰 모델(Target Model)이 이를 한꺼번에 검증합니다.- 원리: 작은 모델이 5~10개 토큰을 빠르게 생성 → 큰 모델이 병렬로 한 번에 검증 → 맞는 토큰은 채택, 틀린 지점부터 재생성
- 효과: 출력 품질은 큰 모델과 동일하면서 속도 2~3배 향상
- 조건: Draft Model의 예측이 Target Model과 자주 일치해야 효과적
추론 최적화 기법 비교
| 기법 | 최적화 대상 | 효과 | 트레이드오프 |
|---|---|---|---|
| KV Cache | 속도 | 토큰 생성 수십 배 가속 | GPU 메모리 추가 사용 |
| Quantization | 메모리, 비용 | 메모리 2~4배 절약 | 소폭 정확도 손실 가능 |
| Continuous Batching | 처리량, 비용 | 처리량 수 배 향상 | 구현 복잡도 증가 |
| Speculative Decoding | 속도 | 생성 속도 2~3배 향상 | Draft Model 추가 필요 |
성공 Databricks 연결: Databricks Foundation Model APIs와 Model Serving은 이러한 최적화를 자동으로 적용합니다. 고객이 직접 vLLM을 설정하거나 양자화를 수행할 필요 없이, 엔드포인트를 생성하면 최적화된 추론 환경이 제공됩니다.
전문가의 실전 노하우
이 섹션은 수년간 LLM 프로젝트를 수행하면서 얻은 실무적 인사이트를 정리한 것입니다. 교과서에는 없지만, 프로젝트 성공에 직결되는 노하우입니다.모델 선택 실전 가이드
“성능 최고 모델 = 최적 모델”이 아닌 이유 고객이 가장 흔히 하는 실수: “그냥 GPT-4 (또는 Claude Opus) 쓰면 되지 않나요?” 물론 성능은 최고입니다. 하지만 실무에서는 속도, 비용, 정확도 의 3축 트레이드오프를 고려해야 합니다. 3축 트레이드오프:| 기준 | GPT-4o / Claude Opus (대형) | GPT-4o-mini / Claude Haiku (소형) | Llama 70B (셀프호스팅) |
|---|---|---|---|
| 정확도 | 최고 (95점) | 양호 (80~85점) | 양호 |
| 속도 (TTFT) | 느림 (1~3초) | 빠름 (0.3~0.8초) | 중간 (하드웨어 의존) |
| 비용 (1M 토큰) | $3~15 | $0.15~0.25 | GPU 비용 (고정) |
| 데이터 주권 | 외부 API 전송 | 외부 API 전송 | 자체 인프라 |
- 대부분의 Enterprise 작업(분류, 추출, 요약)은 소형 모델로 충분
- 비용 절감분으로 더 많은 사용 사례 를 커버 가능
- 속도가 빨라 사용자 경험 향상
- 남은 예산으로 RAG 품질 향상에 투자 → 전체 시스템 정확도 상승
LLM 선택 의사결정 플로차트
고객에게 모델을 추천할 때 사용하는 실전 의사결정 프레임워크입니다. Step 1: 작업 유형 판단| 작업 유형 | 권장 모델 크기 | 이유 |
|---|---|---|
| 텍스트 분류 / 감성 분석 | BERT 또는 소형 LLM (7~8B) | 양방향 이해만으로 충분. 대형 모델은 과잉 |
| 정보 추출 (NER, 키워드) | 소형 LLM (7~8B) | 구조화된 출력, 복잡한 추론 불필요 |
| 단순 요약 / 번역 | 중형 LLM (70B) 또는 소형 API | 충분한 품질, 합리적 비용 |
| 복잡한 추론 / 다단계 분석 | GPT-4o / Claude Sonnet/Opus | 추론 능력이 핵심, 비용 감수 |
| 코드 생성 / 디버깅 | Claude Sonnet / GPT-4.1 | 코드 특화 성능이 중요 |
| 에이전트 (도구 사용) | Claude Sonnet / GPT-4o | 도구 호출 안정성이 핵심 |
| 제약 조건 | 영향 | 대응 |
|---|---|---|
| 데이터 주권(금융, 공공) | 외부 API 사용 불가 | Llama 4 / Mistral 등 오픈웨이트 모델 자체 호스팅 |
| 한국어 특화 | 글로벌 모델의 한국어 성능 부족 | Solar, HyperCLOVA X 검토. 또는 RAG로 한국어 문서 보강 |
| 실시간 응답(<500ms) | 대형 모델 사용 불가 | 소형 모델 + GPU 최적화 (양자화, vLLM) |
| 월 예산 제한 | 대형 모델 API 비용 초과 | 소형 모델 API 또는 셀프호스팅 |
성공 Databricks 팁: Databricks AI Playground에서 여러 모델을 동일 프롬프트로 나란히 테스트할 수 있습니다. Foundation Model API에서 DBRX, Llama, Mixtral 등을 별도 배포 없이 즉시 비교 가능합니다.
비용 최적화 팁 5가지
프로덕션 LLM 시스템의 비용을 50~80% 절감할 수 있는 검증된 전략입니다. 1. Cascade (계단식) 처리 가장 효과적인 비용 최적화 전략입니다. 작은 모델로 먼저 처리하고, 필요한 경우에만 큰 모델을 사용합니다.- 정확히 같은 질문: 해시 기반 캐시 (Redis 등)
- 의미적으로 유사한 질문: Vector 유사도 기반 캐시 (임베딩 비교)
- 효과: 반복 질문이 많은 고객 서비스 챗봇에서 API 호출 30~50% 절감
| 최적화 전략 | 절감 효과 |
|---|---|
| System Prompt를 영어로 작성 (한국어 대비 토큰 50% 절약) | 15~25% |
| 불필요한 예시 제거 (few-shot → zero-shot 가능하면) | 10~30% |
| 반복 지시 통합 | 5~10% |
- OpenAI Batch API: 일반 대비 50% 할인
- Databricks Model Serving: 배치 추론으로 GPU 활용률 극대화
- 처리 시간은 24시간 이내이지만, 비용 절감 효과가 큼
max_tokens 파라미터를 적절히 설정하여, 모델이 불필요하게 긴 응답을 생성하는 것을 방지합니다.
- 분류 작업:
max_tokens=10(레이블만 필요) - 요약 작업:
max_tokens=200~500(요약은 간결해야) - 출력 토큰은 입력 토큰보다 비용이 3~4배 높으므로, 제한 효과가 큼
참고 비용 최적화 종합 효과: 위 5가지 전략을 모두 적용하면, 초기 구현 대비 60~80% 비용 절감 이 가능합니다. 월 1,000만 원이던 LLM API 비용을 200~400만 원으로 줄일 수 있습니다. 이 절감분을 RAG 품질 향상이나 추가 사용 사례 개발에 재투자하는 것이 현명합니다.
고객이 자주 묻는 질문
참고 아래는 고객 미팅에서 자주 받는 질문과 권장 답변입니다. SA/CSE가 고객 대응 시 참고하세요.
”Fine-tuning과 RAG 중 뭘 해야 하나요?”
90%의 경우 RAG로 충분합니다. Fine-tuning이 필요한 경우는 생각보다 제한적입니다.| 상황 | 권장 방법 | 이유 |
|---|---|---|
| 사내 문서 기반 Q&A | RAG | 문서가 바뀌면 즉시 반영, 출처 제공 가능 |
| 최신 정보 활용 필요 | RAG | Fine-tuning은 재학습 필요 (수 일) |
| 특수한 응답 형식/스타일 | Fine-tuning | 예: 특정 보고서 형식, 법률 문서 스타일 |
| 도메인 전문 용어·약어 이해 | RAG + Prompting 우선 시도 | Fine-tuning은 마지막 수단 |
| 기밀 데이터 학습 | RAG(데이터가 모델에 학습되지 않음) | Fine-tuning은 데이터가 모델에 내재화됨 |
”우리 모델 호스팅하면 비용이 얼마나 들까요?”
자체 호스팅 비용은 주로 GPU 비용 에 의해 결정됩니다.| 비교 항목 | Foundation Model API (관리형) | 자체 호스팅 (Model Serving) |
|---|---|---|
| 비용 구조 | 토큰당 과금 (사용한 만큼) | GPU 시간당 과금 (켜 놓은 만큼) |
| 적합한 경우 | 트래픽이 불규칙, 빠른 시작 | 트래픽이 안정적, 커스텀 모델 |
| Llama 70B 서빙 예시 | API 호출 비용만 | A100 80GB × 2대 상시 운영 |
| 운영 부담 | 없음 | 모델 배포, 스케일링, 모니터링 |
| 커스터마이징 | 제한적 | Fine-tuned 모델 배포 가능 |
성공 권장: 초기에는 Foundation Model API로 시작하고, 트래픽이 안정화되고 비용이 예측 가능해지면 자체 호스팅(Model Serving)으로 전환을 검토하세요.
”한국어 성능이 떨어지는데 어떻게 하나요?”
대부분의 글로벌 LLM은 영어 중심으로 학습되어 한국어 성능이 상대적으로 낮을 수 있습니다. 단계별 개선 전략:- RAG로 한국어 문서 제공(가장 효과적): 한국어 사내 문서를 Vector Search에 인덱싱하고, RAG로 제공하면 한국어 답변 품질이 크게 향상됩니다. 모델이 “한국어를 잘 모르는” 것이 아니라 “한국어 맥락을 모르는” 경우가 많기 때문입니다.
- 프롬프트에 한국어 응답 지시: System Prompt에 “반드시 한국어로 답변하세요”를 명시하고, few-shot 예시를 한국어로 제공합니다.
-
한국어 특화 모델 고려: 한국어 데이터로 추가 학습된 모델을 사용합니다.
- Solar(Upstage): 한국어 성능이 우수한 오픈소스 모델
- KULLM(Korea University): 한국어 지시 수행에 특화
- HyperCLOVA X(Naver): 한국어 최강, 비공개 API
- Fine-tuning(마지막 수단): 한국어 (지시, 응답) 쌍으로 SFT를 수행합니다. 수천 개의 고품질 한국어 데이터가 필요합니다.
연습 문제
- Self-Attention이 RNN 대비 가지는 두 가지 핵심 장점은 무엇인가요?
- “안녕하세요, Databricks에 오신 것을 환영합니다”라는 문장이 영어 동일 의미 문장보다 토큰 수가 더 많은 이유를 설명하세요.
- 사내 규정 Q&A 챗봇을 만들 때, Prompting / RAG / Fine-tuning 중 어떤 방법이 가장 적합하며 그 이유는?
- Temperature 0.0과 1.0의 차이를 “주사위”에 비유하여 설명하세요.
- Hallucination이 발생하는 근본적 원인은 무엇이며, RAG가 이를 어떻게 완화하나요?
참고 자료
- Vaswani et al., “Attention Is All You Need” (2017)
- Databricks Foundation Model APIs
- Databricks AI Playground
- DBRX 기술 블로그
- Liu et al., “Lost in the Middle” (2023)
< 이전: 주요 LLM 모델 비교 | LLM 기초 목차로 돌아가기