fine-tuning 은 정말 필요한가, 우리 케이스에서는

새로운 기능에 LLM 을 붙일 때 자연스럽게 나오는 질문이 있다. “우리 데이터로 fine-tuning 하면 더 잘 되지 않을까?” 팀 내에서 이 질문이 나왔고, 우리는 꽤 진지하게 따져봤다. 결론부터 말하면 지금은 하지 않기로 했고, 그 이유를 공유한다.

fine-tuning 이 실제로 해결하는 것

fine-tuning 은 모델이 특정 출력 형식, 도메인 용어, 응답 스타일을 더 안정적으로 따르게 만들 때 효과적이다. “이런 식으로 대답해”를 반복해서 가르치는 것에 가깝다.

반면 fine-tuning 으로 해결하기 어려운 것도 있다. 모델이 몰랐던 사실 정보를 가르치는 것, 자주 바뀌는 최신 데이터를 반영하는 것, 복잡한 추론 능력을 새로 획득하는 것은 fine-tuning 의 영역이 아니다. 이 세 가지가 필요한 상황이라면 RAG 나 컨텍스트 보강이 더 맞는 접근이다.

우리가 실제로 겪은 문제

우리 케이스에서 LLM 의 응답 품질 문제는 크게 두 종류였다. 첫째는 형식이 불안정한 것, 둘째는 도메인 맥락을 모르는 것이었다.

형식 불안정 문제는 프롬프트 개선과 구조화 출력 요청으로 대부분 해결됐다. JSON 스키마를 지정하거나, 원하는 형식의 예시를 few-shot 으로 넣으면 안정성이 충분히 높아졌다. fine-tuning 없이도 해결 가능한 문제였다.

도메인 맥락 문제는 RAG 로 접근했다. 관련 문서를 검색해서 컨텍스트에 넣으면 모델이 그 내용을 바탕으로 답한다. 데이터가 바뀌어도 인덱스를 업데이트하면 되고, fine-tuning 처럼 재학습 사이클이 필요 없다.

fine-tuning 의 실제 비용

기술적 판단 외에 현실적인 비용도 검토했다.

• 데이터 준비: 품질 좋은 학습 데이터를 수백~수천 건 만드는 것은 단순 레이블링이 아니다. 우리 도메인에서는 전문 지식이 필요한 작업이라 시간 비용이 크다.
• 재학습 주기: 서비스 요구사항이 바뀌면 데이터를 다시 만들고 재학습해야 한다. 빠르게 변하는 초기 제품에서는 이 오버헤드가 부담이다.
• 평가: fine-tuning 결과가 실제로 더 나은지 평가하는 것 자체가 쉽지 않다. 평가 파이프라인을 갖추지 않으면 “더 좋아진 것 같다”는 주관적 판단에 그칠 수 있다.

어떤 상황에서 고려할 것인가

fine-tuning 이 의미 있는 상황은 분명히 있다. 응답 스타일이 매우 중요하고, 프롬프트만으로 일관성을 유지하기 어렵고, 데이터 규모와 품질이 충분하고, 재학습 사이클을 감당할 여유가 있을 때다. 우리 팀은 현재 이 조건을 모두 만족하지 못한다.

결국 fine-tuning 은 “쓰면 좋다”가 아니라 “이 상황에서 필요한가”를 먼저 물어야 하는 도구다. 먼저 프롬프트 엔지니어링과 RAG 로 할 수 있는 만큼 해보고, 그래도 해결되지 않는 문제가 있을 때 fine-tuning 을 꺼내는 순서가 맞다고 생각한다.

— by mings