Fine-tuning

1. 파인튜닝 대상 업무를 한 줄로 정의합니다 (예: "사내 문의를 5개 카테고리로 분류", "고객 문의 메일에 자사 톤으로 1차 답변 초안 작성").
2. 입력·정답 쌍 데이터 50~200건을 JSONL 형식으로 정리합니다. 라벨의 일관성을 두세 명이 교차 검토해 둡니다.
3. 베이스 모델을 정합니다. 영어 비중이 높으면 GPT-4o mini, 한국어 톤이 중요하면 Solar·Llama 계열을, 폐쇄망 운영이 필요하면 Llama·Qwen 같은 오픈웨이트 모델을 검토합니다.
4. OpenAI 콘솔·Amazon Bedrock·Hugging Face PEFT 중 한 곳에서 시범 학습을 돌리고, 파인튜닝 전후 정확도와 톤 일관성을 같은 검증셋으로 비교합니다.
5. 추론 비용과 정확도 개선분을 한 장 표로 정리해 결재 라인에 공유하고, 모델 버전 갱신 주기·재학습 책임자를 함께 명시해 둡니다.

파인튜닝이 만능 해법은 아닙니다. 학습 데이터가 적거나 라벨이 정확하지 않으면 베이스 모델보다 성능이 떨어질 수 있고, 데이터에 있는 편향이 그대로 출력에 새겨집니다 ^[1]. 모델 버전이 올라갈 때마다 다시 학습해야 하는 유지보수 부담도 따라옵니다. 또 단순 지식 주입이 목적이라면 RAG(Retrieval-Augmented Generation, 검색 증강 생성), 톤이나 형식 조정 정도라면 시스템 프롬프트가 더 저렴한 선택지인 경우가 많습니다 ^[7]. OpenAI 공식 가이드도 "프롬프트 엔지니어링과 RAG로 충분히 풀리지 않을 때" 파인튜닝을 검토하라고 권합니다 ^[5]. 추론 단가는 일반 모델보다 비싼 구간이 있고, 학습 데이터에 민감 정보가 섞이면 그대로 모델에 남는 보안 이슈도 함께 검토해야 합니다 ^[4]. 업계에서는 보통 "프롬프트로 안 되는 영역만 파인튜닝"이라는 순서를 권장합니다.

진화 방향은 두 갈래입니다. 첫째는 LoRA·QLoRA 계열의 효율화로, 풀 파인튜닝의 비용을 수십~수백 분의 1로 떨어뜨리는 흐름입니다 ^[2][3]. LoRA는 학습 가능한 파라미터를 만 배까지 줄이면서도 풀 파인튜닝에 근접한 성능을 보였고, QLoRA는 4비트 양자화로 65B 모델을 단일 48GB GPU 한 장에서 학습 가능한 수준까지 비용을 끌어내렸습니다 ^[2][3]. Hugging Face PEFT 라이브러리는 LoRA·QLoRA·AdaLoRA 등을 표준 인터페이스로 묶어 오픈소스 진영의 사실상 기준이 됐습니다 ^[7]. 둘째는 클라우드 매니지드 서비스화입니다. Amazon Bedrock의 Claude 3 Haiku 파인튜닝, OpenAI의 셀프서비스 콘솔처럼 머신러닝 엔지니어 없이도 사내 데이터를 업로드해 파인튜닝 모델을 운영하는 방식이 일반화되고 있습니다 ^[4][5]. 국내에서도 Upstage Solar처럼 한국어에 특화된 베이스 모델 위에 자사 데이터로 다시 파인튜닝하는 패턴이 표준으로 자리 잡고 있어 ^[6], 외산 모델 의존을 줄이는 흐름이 함께 진행되고 있습니다. 현재 시점에서는 파인튜닝이 단발성 기술이 아니라 RAG·시스템 프롬프트와 역할을 나눠 쓰는 도메인 특화 LLM 운영의 표준 부품으로 자리 잡았다고 봐도 무리가 없습니다.