> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 실전 가이드

> 이 문서는 **[GenAI 개념](/blog/guides/genai-concepts/overview)** 섹션의 일부입니다.

[\< LLM 기초 목차로 돌아가기](overview)

***

## 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       | 소폭 존재   | 비용 민감한 환경   |

FP16 기준 Llama 70B를 서빙하려면 A100 80GB GPU가 2대 필요하지만, INT4로 양자화하면 1대로도 가능합니다.

### 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점)                    | 양호~~우수 (80~~90점)  |
| **속도 (TTFT)**  | 느림 (1\~3초)                | 빠름 (0.3\~0.8초)                  | 중간 (하드웨어 의존)      |
| **비용 (1M 토큰)** | \$3\~15                   | \$0.15\~0.25                    | GPU 비용 (고정)       |
| **데이터 주권**     | 외부 API 전송                 | 외부 API 전송                       | 자체 인프라            |

**핵심 인사이트**: 실무에서는 **"80% 성능의 저렴한 모델"이 "95% 성능의 비싼 모델"보다 나은 경우가 압도적으로 많습니다.**

이유:

1. 대부분의 Enterprise 작업(분류, 추출, 요약)은 소형 모델로 충분
2. 비용 절감분으로 **더 많은 사용 사례** 를 커버 가능
3. 속도가 빨라 **사용자 경험** 향상
4. 남은 예산으로 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      | 도구 호출 안정성이 핵심           |

**Step 2: 제약 조건 확인**

| 제약 조건               | 영향                | 대응                                        |
| ------------------- | ----------------- | ----------------------------------------- |
| **데이터 주권**(금융, 공공)  | 외부 API 사용 불가      | Llama 4 / Mistral 등 오픈웨이트 모델 자체 호스팅       |
| **한국어 특화**          | 글로벌 모델의 한국어 성능 부족 | Solar, HyperCLOVA X 검토. 또는 RAG로 한국어 문서 보강 |
| **실시간 응답**(\<500ms) | 대형 모델 사용 불가       | 소형 모델 + GPU 최적화 (양자화, vLLM)               |
| **월 예산 제한**         | 대형 모델 API 비용 초과   | 소형 모델 API 또는 셀프호스팅                        |

**Step 3: 검증 전략**

어떤 모델을 선택하든, 반드시 **실제 데이터로 A/B 테스트** 를 수행하세요. 벤치마크 점수가 높은 모델이 특정 도메인에서는 낮은 점수의 모델보다 못할 수 있습니다.

> **성공**
> **Databricks 팁**: Databricks AI Playground에서 여러 모델을 동일 프롬프트로 나란히 테스트할 수 있습니다. Foundation Model API에서 DBRX, Llama, Mixtral 등을 별도 배포 없이 즉시 비교 가능합니다.

### 비용 최적화 팁 5가지

프로덕션 LLM 시스템의 비용을 50\~80% 절감할 수 있는 검증된 전략입니다.

**1. Cascade (계단식) 처리**

가장 효과적인 비용 최적화 전략입니다. 작은 모델로 먼저 처리하고, 필요한 경우에만 큰 모델을 사용합니다.

```
[사용자 요청] → [소형 모델 (GPT-4o-mini)] → 신뢰도 높음? → 바로 응답
                                            → 신뢰도 낮음? → [대형 모델 (GPT-4o)] → 응답
```

실무에서 80~~90%의 요청은 소형 모델로 충분합니다. 이 전략만으로 비용을 60~~70% 절감할 수 있습니다.

**2. 의미론적 캐싱 (Semantic Caching)**

동일하거나 유사한 질문이 반복되면, 이전 응답을 캐시에서 반환합니다.

* 정확히 같은 질문: 해시 기반 캐시 (Redis 등)
* 의미적으로 유사한 질문: Vector 유사도 기반 캐시 (임베딩 비교)
* **효과**: 반복 질문이 많은 고객 서비스 챗봇에서 API 호출 30\~50% 절감

**3. 프롬프트 압축**

System Prompt가 불필요하게 긴 경우가 많습니다. 매 API 호출마다 전송되므로 비용 영향이 큽니다.

| 최적화 전략                                   | 절감 효과   |
| ---------------------------------------- | ------- |
| System Prompt를 영어로 작성 (한국어 대비 토큰 50% 절약) | 15\~25% |
| 불필요한 예시 제거 (few-shot → zero-shot 가능하면)   | 10\~30% |
| 반복 지시 통합                                 | 5\~10%  |

**4. Batch 처리**

실시간 응답이 필요 없는 작업(일일 보고서 생성, 대량 분류 등)은 Batch API를 사용하세요.

* OpenAI Batch API: 일반 대비 **50% 할인**
* Databricks Model Serving: 배치 추론으로 GPU 활용률 극대화
* 처리 시간은 24시간 이내이지만, 비용 절감 효과가 큼

**5. 불필요한 출력 제한**

`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은 영어 중심으로 학습되어 한국어 성능이 상대적으로 낮을 수 있습니다.

**단계별 개선 전략**:

1. **RAG로 한국어 문서 제공**(가장 효과적): 한국어 사내 문서를 Vector Search에 인덱싱하고, RAG로 제공하면 한국어 답변 품질이 크게 향상됩니다. 모델이 "한국어를 잘 모르는" 것이 아니라 "한국어 맥락을 모르는" 경우가 많기 때문입니다.

2. **프롬프트에 한국어 응답 지시**: System Prompt에 "반드시 한국어로 답변하세요"를 명시하고, few-shot 예시를 한국어로 제공합니다.

3. **한국어 특화 모델 고려**: 한국어 데이터로 추가 학습된 모델을 사용합니다.
   * **Solar**(Upstage): 한국어 성능이 우수한 오픈소스 모델
   * **KULLM**(Korea University): 한국어 지시 수행에 특화
   * **HyperCLOVA X**(Naver): 한국어 최강, 비공개 API

4. **Fine-tuning**(마지막 수단): 한국어 (지시, 응답) 쌍으로 SFT를 수행합니다. 수천 개의 고품질 한국어 데이터가 필요합니다.

***

## 연습 문제

1. Self-Attention이 RNN 대비 가지는 두 가지 핵심 장점은 무엇인가요?
2. "안녕하세요, Databricks에 오신 것을 환영합니다"라는 문장이 영어 동일 의미 문장보다 토큰 수가 더 많은 이유를 설명하세요.
3. 사내 규정 Q\&A 챗봇을 만들 때, Prompting / RAG / Fine-tuning 중 어떤 방법이 가장 적합하며 그 이유는?
4. Temperature 0.0과 1.0의 차이를 "주사위"에 비유하여 설명하세요.
5. Hallucination이 발생하는 근본적 원인은 무엇이며, RAG가 이를 어떻게 완화하나요?

***

## 참고 자료

* [Vaswani et al., "Attention Is All You Need" (2017)](https://arxiv.org/abs/1706.03762)
* [Databricks Foundation Model APIs](https://docs.databricks.com/en/machine-learning/foundation-models/index.html)
* [Databricks AI Playground](https://docs.databricks.com/en/large-language-models/ai-playground.html)
* [DBRX 기술 블로그](https://www.databricks.com/blog/introducing-dbrx-new-state-art-open-llm)
* [Liu et al., "Lost in the Middle" (2023)](https://arxiv.org/abs/2307.03172)

***

[\< 이전: 주요 LLM 모델 비교](models) | [LLM 기초 목차로 돌아가기](overview)