[LLM Fine-tuning] Day 1: Fine-tuning vs Prompting - 언제 파인튜닝을 선택하는가

서론: 파인튜닝은 항상 정답이 아니다

모델 성능이 기대에 못 미칠 때 파인튜닝으로 바로 향하는 팀이 많다. 하지만 파인튜닝은 비용이 크다. 데이터 큐레이션, 학습 인프라, 평가 파이프라인, 배포·유지보수가 모두 따라온다.

결정 전에 먼저 물어야 한다. “프롬프트 엔지니어링과 RAG로 충분한가?”

1. 문제 해결 계층

성능 개선 방법은 비용이 낮은 순으로 시도하는 것이 원칙이다.

1. Prompt Engineering (시스템 프롬프트, few-shot 예시)
2. RAG (외부 지식 주입)
3. PEFT / Fine-tuning (모델 가중치 변경)
4. 사전학습(Pre-training) 또는 도메인 적응 학습

상위 계층으로 해결되면 굳이 하위로 내려갈 필요가 없다.

2. 파인튜닝이 유리한 경우

상황	이유
특정 출력 형식을 일관되게 요구	프롬프트만으로 형식 안정성 확보 어려움
도메인 특화 어휘/스타일	기반 모델이 해당 분포를 학습하지 않음
응답 길이·구조 제어	반복 프롬프트로 처리하기엔 비효율
추론 비용 절감	소형 파인튜닝 모델이 대형 기반 모델 대체
시스템 프롬프트 은닉	지식을 가중치에 내재화

3. 파인튜닝이 불리한 경우

• 최신 지식이 필요한 경우: 학습 이후 발생한 정보는 모델이 알 수 없다. RAG가 적합하다.
• 데이터가 부족한 경우: 수백 건 미만의 예시로는 효과적인 파인튜닝이 어렵다.
• 기반 모델이 빠르게 교체되는 경우: 파인튜닝 비용이 교체 주기보다 길면 ROI가 낮다.
• 일반 능력이 중요한 경우: 파인튜닝은 특화 성능을 높이는 대신 일반 능력이 떨어질 수 있다(catastrophic forgetting).

4. 의사결정 흐름도

현재 성능이 기준 미달
  └─ Prompt Engineering 개선 → 충분? → 배포
  └─ RAG 도입 → 충분? → 배포
  └─ 데이터 충분 + 도메인 특화 필요 + 비용 감당 가능?
       └─ Yes → PEFT/Fine-tuning
       └─ No  → 요구사항 재정의 또는 모델 교체 검토

5. 비용 추정 체크포인트

파인튜닝 시작 전 확인할 항목:

• 학습 데이터 확보 비용 (라벨링, 큐레이션)
• 학습 컴퓨팅 비용 (GPU 시간)
• 평가 파이프라인 구축 비용
• 배포 후 모델 유지보수 비용 (재학습 주기 포함)

이 비용의 합이 프롬프트/RAG 개선보다 클 경우, 파인튜닝 선택을 재검토한다.

6. Day 1 체크리스트

1. 현재 문제를 프롬프트 엔지니어링과 RAG로 해결하려 시도했다.
2. 파인튜닝이 필요한 구체적 이유를 데이터/비용 관점에서 정의했다.
3. 학습 데이터 수량과 품질 요건을 사전 검토했다.
4. 파인튜닝 후 일반 능력 저하(catastrophic forgetting) 위험을 평가했다.

다음 글 예고

Day 2에서는 LoRA / QLoRA 메커니즘을 다룬다. 파라미터 효율적 파인튜닝이 어떻게 작동하고, 풀 파인튜닝 대비 어떤 트레이드오프가 있는지 분석한다.