파인튜닝 vs 프롬프팅, 언제 무엇을 써야 할까?

한 줄 정의

• 프롬프팅: 입력 문장 설계로 모델 출력을 조정하는 방법
• 파인튜닝: 모델 가중치를 업데이트해 기본 행동 자체를 바꾸는 방법

왜 중요한가

둘을 혼동하면 비용과 일정이 크게 어긋납니다.
"빨리 개선"이 목표인지, "일관된 기본 행동"이 목표인지에 따라 선택이 완전히 달라집니다.

먼저 결론: 실무에서는 단계적으로 섞어 쓴다

많은 팀이 아래 순서로 진화합니다.

1. 프롬프팅으로 빠르게 품질 상한 확인
2. 필요 시 RAG로 최신성/근거 보강
3. 반복 패턴이 크면 파인튜닝으로 안정화

즉, 둘 중 하나를 영구 선택하는 문제가 아니라 문제 성격에 맞는 단계 선택에 가깝습니다.

언제 쓰는가 / 언제 안 쓰는가

프롬프팅이 좋은 경우

• 빠른 실험이 필요할 때
• 사용 사례가 자주 바뀔 때
• 데이터셋 준비가 어려울 때

파인튜닝이 좋은 경우

• 출력 형식/톤을 일관되게 맞춰야 할 때
• 같은 유형 요청이 대량으로 반복될 때
• 프롬프트만으로 품질 상한을 넘기기 어려울 때

결정 매트릭스 (간단 버전)

• 변화 속도 중요: 프롬프팅 우선
• 일관성 중요: 파인튜닝 우선
• 최신 문서 반영 중요: RAG 우선
• 세 가지가 모두 중요: 프롬프팅 + RAG 후 일부 파인튜닝

쉬운 예시

고객지원 답변 봇을 만든다고 가정합니다.

• 프롬프팅 접근:
  "친절한 톤, 3문장 이내, 마지막에 요약" 같은 지시를 프롬프트에 넣어 조정

• 파인튜닝 접근:
  실제 고객지원 Q&A 데이터로 학습해, 기본적으로 회사 톤과 형식을 따르도록 모델을 조정

비용/운영 관점에서 자주 놓치는 점

1. 프롬프팅은 빠르지만 프롬프트 복잡도가 커지면 유지보수 비용이 증가
2. 파인튜닝은 초기 학습 비용이 들지만 운영 일관성 확보에 유리
3. 데이터 품질이 낮은 파인튜닝은 품질 하락을 부를 수 있음
4. 평가 체계 없이 방법만 바꾸면 "왜 좋아졌는지"를 증명하기 어려움

자주 하는 오해

• 오해 1: 파인튜닝이 항상 더 정확하다
  현실: 데이터 품질이 낮으면 오히려 품질이 떨어질 수 있습니다.

• 오해 2: 프롬프팅은 임시방편이다
  현실: 운영에서도 충분히 강력하며, 많은 제품이 프롬프트+RAG 조합으로 해결합니다.

• 오해 3: 둘 중 하나만 선택해야 한다
  현실: 대부분은 단계적으로 결합합니다.

운영자 체크리스트

1. 목표를 "정확도/일관성/최신성"으로 분리했는가
2. 방법 변경 전후를 비교할 평가셋이 있는가
3. 비용 지표(요청당 원가, 지연시간)를 함께 측정하는가

관련 용어 / 다음 읽기

• 파인튜닝
• 프롬프트
• RAG