파인튜닝 vs 프롬프팅: 언제 어떤 방법을 선택해야 할까?
LLM 커스터마이징의 두 가지 접근법, 파인튜닝과 프롬프팅의 차이점과 선택 기준을 정리합니다.
LLM 커스터마이징이 필요한 이유
범용 LLM은 다양한 작업을 수행할 수 있지만, 특정 도메인이나 업무에 최적화되어 있지는 않습니다. 의료 용어를 정확히 사용하거나, 회사 고유의 문체를 따르거나, 특정 형식의 출력을 일관되게 생성하려면 커스터마이징이 필요합니다.
커스터마이징에는 크게 파인튜닝과 프롬프팅 두 가지 접근법이 있습니다.
파인튜닝 (Fine-tuning)
파인튜닝은 사전 학습된 모델의 가중치를 추가 데이터로 업데이트하는 방법입니다. 모델 자체를 변경하는 것이므로, 학습 후에는 별도의 프롬프트 없이도 원하는 동작을 수행합니다.
파인튜닝이 적합한 경우
- 일관된 출력 형식: 항상 같은 구조의 JSON, 특정 양식의 보고서 등
- 도메인 전문 용어: 의료, 법률, 금융 등 전문 분야 용어 사용
- 대량 반복 작업: 수천 건의 동일 유형 작업을 처리
- 레이턴시 최소화: 긴 프롬프트 없이 빠른 응답이 필요
- 비용 절감: 장기적으로 프롬프트 토큰 비용을 줄이고 싶을 때
파인튜닝의 한계
- 학습 데이터 준비에 시간과 비용 소요 (최소 수백~수천 개)
- GPU 자원 필요
- 모델 업데이트 시 재학습 필요
- 과적합(overfitting) 위험
- 새로운 지식 주입에는 한계 (환각 증가 가능)
프롬프팅 (Prompting)
프롬프팅은 모델을 변경하지 않고, 입력 프롬프트를 통해 원하는 동작을 유도하는 방법입니다. 시스템 프롬프트, few-shot 예시, RAG 등을 활용합니다.
프롬프팅이 적합한 경우
- 빠른 실험과 반복: 즉시 테스트하고 수정 가능
- 다양한 작업: 하나의 모델로 여러 유형의 작업 수행
- 최신 정보 반영: RAG로 실시간 정보 제공
- 소규모 프로젝트: 학습 데이터가 부족하거나 투자 여력이 없을 때
- 유연한 변경: 요구사항 변경 시 프롬프트만 수정
프롬프팅의 한계
- 긴 프롬프트는 토큰 비용 증가
- 매 요청마다 컨텍스트 전달 필요
- 복잡한 프롬프트의 유지보수 어려움
- 일관성이 파인튜닝보다 낮을 수 있음
비교표
| 기준 | 파인튜닝 | 프롬프팅 |
|---|---|---|
| 초기 비용 | 높음 (데이터 + GPU) | 낮음 |
| 운영 비용 | 낮음 (짧은 프롬프트) | 중간~높음 (긴 프롬프트) |
| 구현 시간 | 며칠~몇 주 | 몇 시간~며칠 |
| 유연성 | 낮음 | 높음 |
| 일관성 | 높음 | 중간 |
| 최신 정보 | 재학습 필요 | RAG로 즉시 반영 |
| 기술 난이도 | 높음 | 낮음~중간 |
실전 의사결정 프레임워크
Step 1: 프롬프팅부터 시작
대부분의 경우 프롬프팅으로 충분합니다. 시스템 프롬프트와 few-shot 예시로 원하는 결과를 얻을 수 있는지 먼저 확인하세요.
Step 2: RAG 추가
도메인 지식이 필요하다면 파인튜닝 전에 RAG를 시도합니다. 외부 문서를 검색하여 컨텍스트로 제공하면 대부분의 전문 분야 요구를 충족할 수 있습니다.
Step 3: 파인튜닝 검토
다음 조건을 모두 만족할 때 파인튜닝을 고려합니다:
- 프롬프팅+RAG로는 품질이 부족
- 충분한 학습 데이터 (500개 이상) 보유
- 반복적이고 일관된 유형의 작업
- 비용/성능 최적화가 중요
Step 4: 하이브리드 접근
파인튜닝된 모델에 RAG를 결합하면 최상의 결과를 얻을 수 있습니다. 모델은 도메인 문체와 형식을, RAG는 최신 사실 정보를 담당합니다.
2026년 트렌드
- 파인튜닝 민주화: LoRA, QLoRA 등 경량 파인튜닝 기법으로 비용과 진입 장벽이 크게 낮아짐
- 프롬프트 → 컨텍스트 엔지니어링: 단순 프롬프트에서 전체 컨텍스트 설계로 진화
- 자동 최적화: AI가 최적의 프롬프트나 파인튜닝 데이터를 자동으로 생성
마치며
파인튜닝과 프롬프팅은 양자택일이 아닌 스펙트럼입니다. 대부분의 프로젝트에서는 프롬프팅+RAG로 시작하고, 필요에 따라 점진적으로 파인튜닝을 도입하는 것이 현실적인 전략입니다. 가장 중요한 원칙은 **"가장 단순한 방법부터 시도하라"**는 것입니다.