AI Engineering 북스터디에서 파인튜닝 챕터를 읽고, 스터디원들과 토론하며 정리한 글이다.

파인튜닝이 뭔데

파인튜닝은 이미 훈련된 AI 모델을 내 용도에 맞게 추가로 교육하는 것이다. 프롬프트가 "매번 쪽지를 건네는 것"이라면, 파인튜닝은 직원의 머릿속 자체를 바꾸는 것이다. 당연히 더 강력하지만, 훨씬 비싸다.

Chip Huyen은 이 챕터를 "책에서 가장 쓰기 어려웠다"고 했다. 개념 하나하나는 어렵지 않은데 범위가 넓어서란다. 실제로 읽어보니 정말 그렇다. 하지만 핵심 메시지 하나는 명쾌하다.

파인튜닝을 시도하기 전에, 프롬프트를 제대로 실험해 봤는가?

현장에서 자주 보는 풍경

책의 저자가 현장에서 자주 본다는 패턴이 있다.

누군가 "프롬프트가 안 먹혀서 파인튜닝해야겠다"고 주장한다. 살펴보면 프롬프트 실험이 엉성하다. 지시사항이 모호하고, 예시가 실제 데이터와 다르고, 측정 기준이 엉망이다. 프롬프트를 체계적으로 다듬자 충분히 돌아가는 경우가 많았다고 한다.

우리 스터디에서도 이 부분에 공감이 컸다. 실무에서 파인튜닝을 검토해 본 경험이 있는 한 스터디원은 "프롬프트 → RAG → 파인튜닝 순서가 맞다. 실제로 우리 회사에서도 그 순서를 따른다"고 했다.

그래서 언제 해야 하는데?

책의 핵심 판단 기준은 의외로 단순하다.

모델이 왜 틀리는지 보면 된다.

  • 정보가 없어서 틀린다면 → RAG(외부 지식을 검색해서 주는 방식)가 답이다
  • 형식이나 행동이 이상하다면 → 파인튜닝이 답이다

한마디로 줄이면, 파인튜닝은 형식(form)을 고치는 도구이고 RAG는 사실(facts)을 채우는 도구다.

실험 결과도 이를 뒷받침한다. Ovadia et al.(2024)의 연구에서 최신 정보 질문에 대해 RAG만으로도 파인튜닝을 이겼고, 심지어 기본 모델 + RAG가 파인튜닝 + RAG보다 나은 경우도 있었다.

스터디에서 얻은 실무 인사이트

단순히 책만 읽었다면 "그렇구나" 하고 넘어갔을 내용들인데, 한 스터디원의 발표에서 실무 맥락이 붙었다.

sLLM 인텐트 분류에서 JSON 깨짐 문제

그 스터디원의 회사에서는 소형 언어 모델(sLLM)로 사용자 의도를 분류하고 JSON으로 출력하는 파이프라인을 운영한다. 문제는 모델이 JSON 형식을 자꾸 깨뜨리는 것. 프롬프트로 아무리 "JSON으로 답해줘"라고 해도 불완전한 JSON이 나왔다고 한다.

이건 전형적인 "형식(form) 문제"다. RAG는 소용없다. 파인튜닝이 맞는 상황이었다. 실제로 파인튜닝 후 JSON 출력 안정성이 크게 개선됐다고 한다.

어댑터 운영 패턴: daily + weekly

흥미로웠던 건 파인튜닝을 한 번 하고 끝이 아니라, 지속적으로 업데이트하는 운영 패턴이다.

  • 매일(daily batch): LoRA 어댑터(작은 보조 가중치)만 새 데이터로 업데이트
  • 매주(weekly): 전체 모델을 재학습

왜 이중 구조인가? 파인튜닝을 계속하면 모델이 이전에 배운 것을 잊어버리는 현상(파국적 망각)이 있기 때문이다. 매일 어댑터를 살짝 고치다가, 주 1회 전체 리셋으로 기본기를 되찾는 구조다.

"전문 도메인엔 전문 모델" 함정

책에서 가장 인상 깊었던 사례는 BloombergGPT다.

Bloomberg는 2023년 3월에 금융 전용 모델(50B 파라미터)을 만들었다. A100 GPU 130만 시간, 비용 130만 ~ 260만 달러. 같은 달에 나온 GPT-4가 금융 벤치마크에서 BloombergGPT를 압도했다.

교훈: 도메인 전용 모델을 만들기 전에, 최신 범용 모델이 그 작업을 못하는지 먼저 확인해야 한다. 범용 모델의 발전 속도는 전용 모델 개발 속도를 앞지르는 경우가 많다.

비용을 무시하면 안 된다

파인튜닝의 진짜 비용은 GPU 요금만이 아니다.

  1. 데이터: 고품질 주석 데이터를 만드는 건 느리고 비싸다
  2. ML 지식: 학습률, 과적합, 옵티마이저를 이해해야 한다
  3. 서빙: 파인튜닝한 모델을 어떻게 운영할지도 고민해야 한다
  4. 유지보수: 새 기반 모델이 3~6개월마다 나오는데, 내 파인튜닝 모델은 금방 구식이 된다

그래서 내 판단 기준

이번 스터디를 통해 내가 정리한 판단 순서는 이렇다.

  1. 프롬프트를 체계적으로 3가지 이상 실험해 봤는가? → 아니면 아직 파인튜닝 단계가 아니다
  2. 모델이 왜 틀리는가? → 정보 부족이면 RAG, 형식/행동이면 파인튜닝
  3. 데이터가 있는가? → 수백 개면 LoRA, 수천 이상이면 full finetuning 고려
  4. 유지보수할 체력이 있는가? → 없으면 강한 범용 모델 + 프롬프트가 현실적

파인튜닝은 강력하다. 하지만 그게 필요한 상황은 생각보다 적다.

References

  • Chip Huyen, AI Engineering (O'Reilly, 2025), Chapter 7
  • Ovadia et al., "Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs" (EMNLP 2024)
  • 스터디 클럽++ AI Engineering 북클럽 8주차 세션