Fine-tuning 완전 가이드: SFT, DPO, LoRA/QLoRA, 합성 데이터, 한국어 모델 (2025)

Season 4 Ep 4 — Ep 1–3은 모델을 그대로 쓰는 세계였다. Ep 4부터는 모델 자체를 바꾼다. 언제, 왜, 어떻게 바꿀지의 경계선을 긋는다.

• Prologue — 2025년에 Fine-tuning을 다시 꺼내는 이유
• 1장 · Fine-tuning의 종류
  • 1.1 학습 단계의 계층
  • 1.2 SFT (Supervised Fine-tuning)
  • 1.3 Preference tuning: RLHF, DPO, IPO, KTO
  • 1.4 언제 Preference까지 필요한가
• 2장 · LoRA / QLoRA — 소비자 GPU로도 가능한 이유
  • 2.1 Full fine-tuning의 비용
  • 2.2 LoRA (Low-Rank Adaptation)
  • 2.3 QLoRA (Dettmers et al., 2023)
  • 2.4 현실적 VRAM 가이드 (2025)
  • 2.5 LoRA/QLoRA 설정 시작점
• 3장 · 데이터가 전부다
  • 3.1 양 vs 질
  • 3.2 데이터 형태
  • 3.3 데이터 수집 3가지 길
  • 3.4 평가셋과 완전 분리
• 4장 · 합성 데이터 — 라벨 비용을 10분의 1로
  • 4.1 기본 아이디어
  • 4.2 주요 기법
  • 4.3 품질 관리
  • 4.4 법적·윤리 고려
  • 4.5 합성 + 실제 혼합
• 5장 · Fine-tune vs RAG vs Prompt — 경계선 재점검
  • 5.1 의사결정 트리
  • 5.2 함께 쓰는 조합
  • 5.3 자주 틀리는 사례
  • 5.4 비용·운영 비교
• 6장 · 한국어 모델 파인튜닝
  • 6.1 주요 오픈 모델 2025
  • 6.2 선택 가이드
  • 6.3 한국어 SFT 팁
  • 6.4 한국어 평가 벤치
• 7장 · 훈련 파이프라인 — Hugging Face TRL + Axolotl / Unsloth
  • 7.1 TRL (Transformers RL)
  • 7.2 Axolotl
  • 7.3 Unsloth
  • 7.4 LLaMA-Factory / torchtune
  • 7.5 하드웨어 선택
• 8장 · 평가 — Fine-tune 전후를 비교하라
  • 8.1 레이어
  • 8.2 일반 능력 회귀
  • 8.3 회귀 테스트 CI
• 9장 · 배포 — vLLM, TGI, TensorRT-LLM, Ollama
  • 9.1 옵션 비교
  • 9.2 vLLM 권장 설정
  • 9.3 비용 계산
• 10장 · 실전 케이스 3
  • 10.1 사내 분류기 치환
  • 10.2 응답 포맷·톤 고정
  • 10.3 온프레미스 법률 어시스턴트
• 11장 · 운영 — 버저닝, 모니터링, 롤백
  • 11.1 모델 버전 관리
  • 11.2 카나리 배포
  • 11.3 드리프트 감지
  • 11.4 재학습 주기
• 12장 · 안티패턴 10선
  • 12.1 RAG로 될 걸 Fine-tune으로
  • 12.2 데이터 1만 개 모으고 품질 검수 안 함
  • 12.3 평가셋과 훈련셋 섞임
  • 12.4 일반 능력 회귀 체크 안 함
  • 12.5 파인튜닝 한 번 하고 잊어버림
  • 12.6 rank·epoch 과도 설정
  • 12.7 base 모델 라이선스 확인 안 함
  • 12.8 합성 데이터 품질 필터 없음
  • 12.9 자체 호스팅 비용 계산 없이 시작
  • 12.10 어댑터 병합·핫스왑 테스트 안 함
• 13장 · 체크리스트 — Fine-tuning 프로젝트 킥오프 전 12가지
• 14장 · 다음 글 예고 — Season 4 Ep 5: "MCP (Model Context Protocol) 완전 해부"

Prologue — 2025년에 Fine-tuning을 다시 꺼내는 이유

"GPT-4o가 웬만한 거 다 하는데 Fine-tuning 왜 함?" 맞는 말이다. 2023년식 "모든 태스크마다 파인튜닝하자"는 완전히 오래됐다.

하지만 2025년에도 Fine-tuning이 필요한 순간은 분명 존재한다.

• 스타일·포맷 고정: JSON, 특정 말투, 사내 용어 일관성
• 작은 모델을 태스크 전문가로: 분류·추출·라우팅에서 큰 모델만큼 정확하면 비용 1/10
• 온프레미스 필수 환경: 외부 API 금지(금융·공공·의료)
• 특수 포맷(코드, 법률, 의료 용어): 일반 모델이 자주 틀리는 영역
• 라이선스·IP 이슈: 외부 모델 출력이 그대로 제품에 나가면 안 되는 경우

즉 **"모든 팀이 Fine-tuning할 필요는 없지만, 어떤 팀에겐 여전히 최선의 선택"**이다. 이 글은 그 경계선과 실전 방법을 정리한다.

1장 · Fine-tuning의 종류

1.1 학습 단계의 계층

Pre-training            : 수조 토큰으로 기초 모델 학습
   ↓
Supervised Fine-tuning  : 사람이 만든 지시-응답 쌍으로
   ↓
Preference tuning       : 좋음/나쁨 비교 피드백 (RLHF/DPO 등)
   ↓
(선택) Continual tuning  : 도메인 데이터로 추가 SFT

일반적으로 "Fine-tuning"이라고 하면 두 번째(SFT)와 세 번째(Preference)를 의미한다.

1.2 SFT (Supervised Fine-tuning)

입력: (prompt, response) 쌍 수백~수만 개. 목표: 모델이 "이런 입력에 이런 출력"을 내도록.

• 가장 쉽고 일반적. 대부분의 실무 파인튜닝은 SFT.
• 결과: 스타일·포맷·도메인 어휘가 원하는 방향으로 정렬.

1.3 Preference tuning: RLHF, DPO, IPO, KTO

RLHF (Reinforcement Learning from Human Feedback):

• Reward model 학습 → PPO로 정책 최적화
• ChatGPT의 비밀 소스. 하지만 구현·튜닝 난이도 높음.

DPO (Direct Preference Optimization, 2023):

• Reward model 없이 선호 쌍(chosen vs rejected)으로 직접 최적화
• 2024–2025년 사실상 표준. 구현 단순, 안정적.

IPO, KTO (2024):

• DPO의 변형. KTO는 단일 피드백(좋음/나쁨)만 있어도 작동. 라벨 비용 절감.

ORPO, SimPO (2024):

• SFT와 Preference를 한 단계로 합친 방법. 파이프라인 단순화.

1.4 언제 Preference까지 필요한가

• SFT로 충분한 경우: 포맷 고정, 분류, 추출
• Preference 필요한 경우: 톤·안전성·세밀한 선호 (같은 정답이 여러 개인데 어떤 게 더 좋은지 구분 필요)

실무 팁: 일단 SFT만 해보고, 결과 응답 중 품질 편차가 크면 Preference 단계 추가 검토.

2장 · LoRA / QLoRA — 소비자 GPU로도 가능한 이유

2.1 Full fine-tuning의 비용

• 7B 모델 full fine-tuning: VRAM 80–100GB+ 필요 (A100 80GB or H100)
• 70B 모델: 멀티 노드 GPU 클러스터
• 대부분의 팀에겐 비현실적

2.2 LoRA (Low-Rank Adaptation)

아이디어: 기존 가중치 W는 그대로 두고, 작은 rank-r 행렬 A·B만 학습한다.

W_final = W_base + (A × B)  # r=8~64

• 학습 파라미터 1–5% 수준 → VRAM 대폭 절감
• 저장: 어댑터 수십~수백 MB (full 수십 GB 대비)
• 성능: full fine-tune의 95%+ (대부분 태스크)

2.3 QLoRA (Dettmers et al., 2023)

• Base 모델을 4-bit 양자화 상태로 메모리에 올리고
• LoRA 어댑터만 16-bit로 학습
• 13B 모델도 24GB 소비자 GPU(4090) 한 장으로 파인튜닝 가능

2.4 현실적 VRAM 가이드 (2025)

배치 크기·시퀀스 길이·optimizer(Adam vs Adafactor)에 따라 ±30% 변동. 정확한 수치는 직접 프로파일링.

2.5 LoRA/QLoRA 설정 시작점

• rank: 16 또는 32 (간단 태스크면 8도 OK)
• alpha: rank와 동일 또는 2배
• target modules: attention의 q/k/v/o 또는 모든 linear
• learning rate: 1e-4 ~ 5e-4 (full fine-tune보다 5–10배 크게)
• warmup: 전체 step의 3–5%
• epoch: 1–3 (과적합 주의)

3장 · 데이터가 전부다

3.1 양 vs 질

• 10,000개 엉성한 샘플보다 1,000개 깔끔한 샘플이 낫다
• "덜 많이, 더 정확하게"가 2023년 Zephyr·LIMA 이후 일반화된 원칙
• 데이터 클리닝에 시간을 쓰는 팀이 Fine-tuning 성과가 좋음

3.2 데이터 형태

SFT 포맷 (예: ChatML):

{"messages": [
  {"role": "system", "content": "..."},
  {"role": "user", "content": "..."},
  {"role": "assistant", "content": "..."}
]}

DPO 포맷:

{"prompt": "...", "chosen": "...", "rejected": "..."}

3.3 데이터 수집 3가지 길

(a) 기존 로그 재활용

• 프로덕션에서 사용자 ↔ 모델 대화 로그
• 좋았던 응답만 추려서 SFT
• 썸업/썸다운 있으면 DPO 데이터 직행

(b) 사람이 작성

• 도메인 전문가가 "이런 질문엔 이렇게" 예시 직접 작성
• 100–1000개 고품질 샘플
• 비용 크지만 가장 신뢰성 높음

(c) 합성 데이터 (4장에서 자세히)

3.4 평가셋과 완전 분리

• 훈련/검증/테스트 분리 필수
• 평가셋은 훈련에 절대 노출 금지 (leakage 방지)
• 데이터 품질 검수는 학습 전에 마치기

4장 · 합성 데이터 — 라벨 비용을 10분의 1로

4.1 기본 아이디어

큰 모델(GPT-4o, Claude 3.5/4 등)로 훈련 데이터를 생성해서 작은 모델을 파인튜닝.

[작은 시드 예시 10–50개] → [대형 LLM이 유사 예시 1000개 생성] → [필터링] → [SFT]

4.2 주요 기법

• Self-instruct (2022): 시드로부터 instruction을 자가 생성
• Evol-instruct (WizardLM): 난이도를 단계적으로 올려서 "진화"
• Distillation: 큰 모델의 응답을 그대로 작은 모델에게 가르침
• Rejection sampling: 큰 모델이 여러 응답 생성 → 리워드 모델 or 필터로 베스트 선택
• Constitutional AI: 큰 모델이 스스로의 응답을 규칙에 따라 비판·수정

4.3 품질 관리

• 중복 제거: 임베딩 유사도 기반 필터
• 형식 검사: JSON 스키마, 길이, 금지 토큰
• LLM-as-judge: 또 다른 모델이 "이 샘플 학습에 쓸 만?"
• 사람 샘플 검수: 10–20% 무작위 샘플을 사람이 확인

4.4 법적·윤리 고려

• GPT-4o 출력으로 "GPT와 경쟁 모델" 훈련은 OpenAI 약관 위반 — 실제 배포 전 라이선스 확인
• 자사 모델(Claude, Llama 등)은 각자 약관 체크
• 오픈 모델(Llama, Qwen)로 합성 데이터 생성하면 이슈 회피 쉬움

4.5 합성 + 실제 혼합

실제 데이터가 적을 때, 합성 데이터로 보강하되 실제 데이터에 더 높은 샘플링 가중치를 주면 성능 안정적.

5장 · Fine-tune vs RAG vs Prompt — 경계선 재점검

5.1 의사결정 트리

"모델이 지식을 몰라서 틀리는가?" 
  YES → RAG
  NO  → "스타일/포맷/분류 정확도가 문제?"
         YES → Fine-tuning
         NO  → "그냥 프롬프트 수정으로 해결?"
                YES → Prompt Engineering
                NO  → 문제를 다시 정의 (어쩌면 에이전트가 필요)

5.2 함께 쓰는 조합

• RAG + Fine-tuned 응답 포맷 모델: 지식은 검색으로, 포맷은 학습으로
• Fine-tuned 분류기 + 큰 모델 생성: 라우팅은 작게, 생성은 크게
• Fine-tuned 태스크 + Prompt 메타 지시: 태스크별 어댑터 로드 + 상위 프롬프트로 조건부 동작

5.3 자주 틀리는 사례

• "회사 내부 지식을 모델에 주입하겠다" → Fine-tune로 하려 들지 말 것. RAG가 정답.
• "JSON 포맷이 자꾸 깨진다" → Prompt/Structured Output 먼저. 그래도 안 되면 SFT.
• "특정 키워드를 잘 못 쓴다" → 사전 검색 + 프롬프트로 먼저. Fine-tune은 최후.

5.4 비용·운영 비교

• 자주 바뀌는 것(지식, 정책) → RAG·Prompt
• 잘 안 바뀌는 것(톤, 포맷, 도메인 분류) → Fine-tuning

6장 · 한국어 모델 파인튜닝

6.1 주요 오픈 모델 2025

6.2 선택 가이드

• 가볍게 시작: Solar 10.7B, Qwen2.5 7B — 소비자 GPU 한 장으로 QLoRA 가능
• 영어-한국어 양쪽 강해야: Qwen, Llama 3.x
• 한국어 최우선: Solar, EXAONE
• 상업 라이선스 조심: Llama(월 사용자 7억 이상 제한), EXAONE(상업용 문의), Mixtral(EU 정책 확인)

6.3 한국어 SFT 팁

• 데이터 품질이 훨씬 중요 (영문 대비 공개 리소스 적음)
• 존댓말/반말, 문체 혼재 → 포맷을 강제하는 샘플 일관성 유지
• 한자어·외래어 표기 규칙을 샘플에 녹여라
• Tokenizer가 한국어 효율적인지 확인 (Solar·Qwen은 한국어 토크나이저 우수, Llama는 상대적으로 비효율)

6.4 한국어 평가 벤치

• KoBench, Ko-MT-Bench, LogicKor, KMMLU, HAE-RAE
• 하지만 본인 도메인 평가셋이 최우선 — 공개 벤치는 참고용

7장 · 훈련 파이프라인 — Hugging Face TRL + Axolotl / Unsloth

7.1 TRL (Transformers RL)

Hugging Face의 공식 학습 라이브러리. SFTTrainer, DPOTrainer, PPOTrainer, ORPOTrainer 등 제공.

from trl import SFTTrainer

trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=ds,
    args=training_args,
    peft_config=lora_config,
)
trainer.train()

7.2 Axolotl

YAML 설정 중심. 프로덕션용 파이프라인에 편리.

base_model: upstage/SOLAR-10.7B-v1.0
adapter: qlora
load_in_4bit: true
lora_r: 32
lora_alpha: 64
sequence_len: 4096
micro_batch_size: 4
num_epochs: 2

7.3 Unsloth

속도·메모리 최적화 라이브러리. LoRA/QLoRA 학습을 2–5배 빠르게. 소비자 GPU에 특히 유리.

7.4 LLaMA-Factory / torchtune

GUI/CLI 친화적 프레임워크. 빠른 실험에 유용. torchtune은 PyTorch 공식, 심플.

7.5 하드웨어 선택

• 클라우드 스팟: RunPod, Vast.ai, Lambda Labs, Modal — 저렴
• 자체 GPU: RTX 4090 / 5090 / 6000 Ada, H100 대여
• 파인튜닝 API: OpenAI, Together, Fireworks, Mistral — 데이터 업로드하면 끝. 편하지만 비쌈

8장 · 평가 — Fine-tune 전후를 비교하라

8.1 레이어

• Task 성능: 도메인 평가셋, Accuracy/F1/BLEU/ROUGE/판정 점수
• 일반 능력 회귀: 일반 벤치(MMLU, GSM8K, KMMLU 등)로 원래 능력 손실 여부 확인
• 안전성·편향: Harmful bench, 편향 측정
• 비용·지연: 실제 배포 조건으로

8.2 일반 능력 회귀

흔한 사고: "도메인 태스크는 잘하는데 일반 질문에 바보 됨." 과도한 데이터, 좁은 도메인에만 집중하면 생긴다.

예방:

• 훈련 데이터에 일반 대화 10–20% 섞기
• rank를 너무 높이지 않기
• epoch 1–2로 제한

8.3 회귀 테스트 CI

• 주요 벤치 5–10개를 매 학습 후 자동 실행
• 기준선 대비 5% 이상 떨어지면 빨간불
• 결과 대시보드에 시각화

9장 · 배포 — vLLM, TGI, TensorRT-LLM, Ollama

9.1 옵션 비교

9.2 vLLM 권장 설정

• tensor_parallel_size: GPU 수
• gpu_memory_utilization: 0.9 (여유 필요하면 0.85)
• max_model_len: 실제 사용 길이에 맞춰 (짧게 잡으면 TPS ↑)
• enable_prefix_caching: 반복 프롬프트 캐싱
• LoRA 어댑터 핫스왑: vLLM enable_lora로 지원

9.3 비용 계산

• 자체 호스팅 vs 외부 API 손익분기점
• 월 호출 1000만 회 이상, 단일 모델 집중 사용이면 자체가 유리한 경우 많음
• 다양한 모델 섞어 쓰면 외부 API가 편함

10장 · 실전 케이스 3

10.1 사내 분류기 치환

배경: 고객 지원 티켓 카테고리 분류 — GPT-4o로 API 호출 → 월 $500.

• SFT용 데이터: 6개월 분 티켓+카테고리 5,000건
• 모델: Qwen2.5 3B + QLoRA
• 학습: A100 한 장, 4시간
• 배포: vLLM on 자체 GPU
• 결과: Accuracy 93% (GPT-4o 94% 대비 -1%p), 월 비용 $40, 지연 50ms (GPT는 800ms)

교훈: 스코프가 좁은 태스크는 작은 모델이 거의 항상 이긴다.

10.2 응답 포맷·톤 고정

배경: B2B SaaS의 AI 답변이 너무 친근/격식 왔다갔다.

• DPO 데이터: "같은 답변을 격식 있게 vs 캐주얼하게" 쌍 2,000개
• 모델: Solar 10.7B LoRA
• 결과: 톤 일관성 사용자 만족도 +18%p

교훈: Preference tuning은 "스타일의 평균"을 이동시키는 데 특히 효과적.

10.3 온프레미스 법률 어시스턴트

배경: 로펌, 데이터 외부 전송 금지.

• 베이스: Qwen2.5 14B + QLoRA
• SFT: 내부 판례 요약 샘플 8,000건, 법리 해설 3,000건
• 배포: 자체 GPU 서버 (H100 2장) + vLLM
• RAG: 내부 판례 벡터 DB(pgvector) 연동
• 결과: 외부 API 없이 일반 법률 질의 94% 커버

교훈: 규제 환경에서 Fine-tuning + 자체 호스팅은 아직 유일한 길.

11장 · 운영 — 버저닝, 모니터링, 롤백

11.1 모델 버전 관리

• 어댑터(LoRA)마다 semver: v1.2.3-lora
• HuggingFace Hub 또는 사내 Model Registry (MLflow, Weights & Biases, BentoML)
• base 모델 + 어댑터의 조합을 기록

11.2 카나리 배포

• 트래픽 1–5%부터 새 버전 → 자동 회귀 체크 통과 시 확장
• 실패 시 즉시 기존 어댑터로 롤백

11.3 드리프트 감지

• 실제 사용 데이터의 분포 변화를 지표로 측정 (입력 길이, 주제 분포, 모델 confidence 분포 등)
• 드리프트 감지되면 재학습 알림

11.4 재학습 주기

• 정적 태스크(포맷·톤): 6–12개월에 한 번이면 충분
• 도메인 지식이 자주 바뀜: 1–3개월 주기 or RAG로 이전

12장 · 안티패턴 10선

12.1 RAG로 될 걸 Fine-tune으로

지식 주입은 RAG가 정답. 반복 강조.

12.2 데이터 1만 개 모으고 품질 검수 안 함

엉성한 1만보다 깔끔한 1천이 낫다.

12.3 평가셋과 훈련셋 섞임

Leakage 사고. CI로 해시 중복 체크.

12.4 일반 능력 회귀 체크 안 함

도메인만 잘하고 일반 질문엔 바보 되는 참사.

12.5 파인튜닝 한 번 하고 잊어버림

모델·데이터가 진화한다. 재학습 주기 설계.

12.6 rank·epoch 과도 설정

과적합, 일반화 손실. rank 16–32 / epoch 1–3 기본.

12.7 base 모델 라이선스 확인 안 함

상업 배포 후 경고 받음. Llama, Mixtral 조건 체크.

12.8 합성 데이터 품질 필터 없음

노이즈 섞여 모델이 이상한 습관 학습.

12.9 자체 호스팅 비용 계산 없이 시작

GPU 렌탈비가 외부 API보다 비쌌던 사례 흔함.

12.10 어댑터 병합·핫스왑 테스트 안 함

배포 시점에 디바이스 메모리 이슈 발견 → 지연.

13장 · 체크리스트 — Fine-tuning 프로젝트 킥오프 전 12가지

• RAG/Prompt로 해결되지 않는 문제인지 확인
• 명확한 성공 지표 (Accuracy/F1/판정 점수) 정의
• 평가셋 ≥ 300개, 훈련/검증/테스트 분리
• 훈련 데이터 500–5,000개 수집 계획
• Base 모델 라이선스 상업 사용 가능 여부
• LoRA/QLoRA 설정(rank, alpha, lr, epoch) 합의
• 일반 능력 회귀 벤치 5개 이상 선정
• 안전성·편향 테스트 최소 포함
• 배포 엔진(vLLM/TGI/TensorRT) 결정
• 어댑터 버저닝·카나리·롤백 절차
• 비용 비교표 (외부 API vs 자체 호스팅 손익분기)
• 재학습 주기 + 드리프트 감지 계획

14장 · 다음 글 예고 — Season 4 Ep 5: "MCP (Model Context Protocol) 완전 해부"

Ep 3(에이전트)에서 잠깐 나왔던 MCP. 2024년 말 Anthropic이 공개하고 2025년 표준화가 빠르게 진행 중인 이 프로토콜은 LLM 툴 생태계의 USB-C가 될 가능성이 높다.

• MCP 스펙: Resources, Tools, Prompts, Sampling
• stdio vs HTTP SSE vs Streamable HTTP
• 인증(OAuth 2.1, 토큰), 권한 스코프
• 유명 MCP 서버(GitHub, Slack, Linear, Filesystem, Chrome, Playwright)
• 직접 MCP 서버 만들기(TypeScript, Python)
• Claude Desktop / Claude Code / OpenAI Responses와의 연결
• 보안 모델·공격 벡터(악성 MCP, 프롬프트 인젝션)
• 엔터프라이즈 MCP(사내 데이터 접근)
• MCP vs OpenAPI·Function calling — 경계
• 한국 스타트업의 MCP 활용 사례

"모든 에이전트 프레임워크가 MCP를 말하게 된 2025년", 이 프로토콜을 이해하는 것은 필수가 됐다.

다음 글에서 만나자.

요약: Fine-tuning은 죽지 않았다. 2025년의 Fine-tuning은 좁은 태스크·작은 모델·LoRA/QLoRA·합성 데이터로 "돈 절약 + 속도 + 온프레미스"를 얻는 실용적 도구다. SFT 먼저, 필요 시 DPO, 합성 데이터로 라벨 비용을 줄이고, 일반 능력 회귀를 반드시 체크하며, vLLM으로 배포한다. **"RAG로 될 것을 Fine-tune으로 하지 말 것"**과 **"작은 전문가 모델이 큰 일반가 모델을 이기는 경우가 많다"**가 핵심 교훈.