LLM 파인튜닝 전략

LLM 기반 기능을 만들 때 본능적으로 바로 파인튜닝으로 뛰어들고 싶어지죠. 대부분의 경우 그건 성급한 거예요. 이 글에서는 프롬프트 엔지니어링에서 RAG를 거쳐 LoRA 파인튜닝까지 3계층 진행 과정을 살펴보고, 각 계층에 투자할 가치가 있는 시점을 설명해요.

3계층 아키텍처

LLM 커스터마이징을 세 개의 계층으로 생각하세요. 각 계층은 이전 계층 위에 구축돼요. 규칙은: 계층 1과 2가 소진되기 전에 계층 3으로 뛰어들지 마세요.

계층 1 — 프롬프트 엔지니어링: 비용 제로, 인프라 제로. 시스템 프롬프트, few-shot 예시, chain-of-thought 추론. 이게 베이스라인이고 생각보다 멀리까지 데려다줘요.

계층 2 — RAG 컨텍스트 주입: 관련 컨텍스트(문서, 사용자 히스토리, 골든 예시)를 검색해서 프롬프트에 주입해요. 여전히 학습 비용 제로 — 추론 시점에 프롬프트를 동적으로 강화하는 거예요.

계층 3 — LoRA 파인튜닝: 모델의 가중치를 수정하는 태스크별 어댑터를 학습해요. 여기서부터 라벨링된 데이터, 학습 인프라, 명확한 평가 파이프라인이 필요해요.

파인튜닝 접근법 선택

계층 3에 도달했을 때, 방법의 선택은 데이터와 팀 규모에 따라 달라져요:

접근법	필요한 데이터	컴퓨팅	사용 시점
SFT (Supervised Fine-Tuning)	(입력, 타겟) 쌍	낮음	골드 스탠다드 출력이 있을 때
DPO (Direct Preference Optimization)	(입력, 선호, 비선호) 삼중항	중간	사용자 수정이나 평점이 있을 때
RLHF (PPO)	평점 → 보상 모델 → 정책 그래디언트	높음	1000+ 평가된 예시로 스케일할 때
Few-shot (in-context)	프롬프트에 2-5개 예시	제로 (추론만)	학습 전 빠른 성과

솔로 개발자와 소규모 팀에게는 DPO가 RLHF보다 나아요. DPO는 선호도 쌍을 직접 사용해요 — “이 출력이 저 출력보다 낫다” — 별도의 보상 모델을 학습할 필요가 없어요. RLHF는 완전한 보상 모델에 PPO 정책 그래디언트 최적화까지 필요해요. 소규모에서는 컴퓨팅과 데이터 요구사항이 훨씬 높은데 개선폭은 미미해요.

학습 시그널의 출처

사용자 리뷰(수정 편집)와 사용자 평점(0-N 스케일)이 있는 시스템에서, 데이터는 파인튜닝 방법에 깔끔하게 매핑돼요:

리뷰 diff → SFT 또는 DPO: 사용자 편집이 SFT용 (입력, 수정된출력) 쌍을 제공해요. 원본 LLM 출력과 결합하면 DPO용 (입력, 선호=사용자편집, 비선호=llm_출력) 삼중항도 만들어져요.
평점 → DPO 선호도 쌍: 같은 입력 컨텍스트에서, 평점 3 출력은 평점 0 출력보다 선호돼요. DPO가 개선을 보이려면 대략 200+ 쌍이 필요해요.
골든 셋 프로모션: 높은 평점의 출력(평점 3/3)은 SFT나 계층 2 few-shot 프롬프팅을 위한 골든 셋으로 승격할 수 있어요.

LoRA 멀티태스크 아키텍처

N개의 별도 파인튜닝 모델을 배포하는 대신, 하나의 베이스 모델에 태스크별 LoRA 어댑터를 사용하세요:

Base Model (동결, 공유)
    ├── LoRA 어댑터 A: 요약 (리뷰 수정으로 학습)
    ├── LoRA 어댑터 B: 추천 (평점 선호도 쌍으로 학습)
    └── LoRA 어댑터 C: 인텐트 분류 (인텐트 수정으로 학습)

모델 1개와 같은 GPU 메모리. 요청마다 어댑터 핫스왑.

Anyscale이나 Predibase 같은 회사가 공유 GPU 인프라에서 수백 개의 파인튜닝 모델을 서빙하는 방식이에요. LoRA는 파라미터의 ~1-5%만 학습하므로, 어댑터가 작고 스왑이 빨라요.

TIES-Merging: 태스크별 학습, 단일 어댑터 서빙

런타임이 하나의 어댑터만 로드할 수 있을 때 — Ollama는 Modelfile당 하나의 LoRA만 지원하고, NAS는 여러 모델 인스턴스를 위한 RAM이 제한적일 때 — 태스크별 어댑터를 하나로 병합할 수 있어요:

학습 (격리, 태스크별):
  LoRA A: 분류  ─┐
  LoRA B: 요약  ─┤─→ TIES-Merge ─→ 단일 병합 LoRA
  LoRA C: 추천  ─┘

서빙 (단일 프로세스):
  Ollama 베이스 모델 + 병합 LoRA = 하나의 프로세스, ~5 GB

태스크별 학습은 업계 표준이에요(OpenAI, Google Vertex AI, HuggingFace PEFT 모두 권장). 태스크별 데이터 분포가 다르고, 최적 하이퍼파라미터가 다르고, 태스크별로 독립적인 평가와 롤백이 필요하기 때문이에요.

TIES-Merging (Yadav et al., 2023)은 어댑터를 결합할 때 파라미터 충돌을 해결해요 — 중복 파라미터를 트리밍하고, 부호 충돌을 해결하고, 합의된 방향만 병합해요. HuggingFace의 mergekit이 TIES, DARE, 선형 병합 방법을 구현해요. 병합된 어댑터가 어떤 평가 메트릭에서 5% 이상 하락하면, 이전 병합으로 되돌리고 문제가 된 태스크의 LoRA를 재학습하세요.

계층 2: 파인튜닝 전에 피드백 루프 닫기

대부분의 ML 시스템은 열린 피드백 루프를 가지고 있어요: 사용자 평점이 수집되고 측정되지만, 모델에 다시 피드백되지는 않아요. 계층 2는 프롬프트 엔지니어링만으로 이 갭을 닫아요 — 학습 인프라가 필요 없어요.

패턴은 골든 셋에서 few-shot이에요:

사용자 피드백 수집 (평점 0-3, 수정)
우수한 예시(평점 3)를 골든 셋으로 승격
추론 시, 현재 입력의 컨텍스트와 매칭되는 골든 셋 예시를 쿼리
해당 예시를 프롬프트에 few-shot 데모로 주입
사용자가 지속적으로 낮게 평가하는 입력-인텐트 조합은 스킵

이건 프롬프트 자체에 적용된 검색 증강 생성(RAG)이에요 — 자체 사용자의 검증된 피드백을 in-context learning 예시로 사용하는 거예요. 계층 2는 그 자체로 상당한 품질 향상을 제공하는 경우가 많고 계층 3(파인튜닝)과 독립적으로 배포할 수 있어요.

캐스케이드 vs. 멀티모달

중요한 아키텍처 구분이 하나 있어요: 오디오, 이미지, 링크를 LLM으로 처리하기 전에 텍스트로 변환한다면, 캐스케이드 아키텍처이지 멀티모달이 아니에요.

캐스케이드 (대부분의 프로젝트가 실제로 필요한 것):
  오디오 → STT 모델 (Whisper) ─┐
  이미지 → OCR 모델 (Tesseract) ├→ 텍스트 → LLM (텍스트 전용) → 출력
  링크  → HTTP fetch + 추출    ─┘
  파인튜닝: 표준 text-to-text SFT/DPO

멀티모달 (진짜 필요할 때):
  오디오 ─┐
  이미지  ├→ 멀티모달 LLM (GPT-4V, Gemini Vision) → 출력
  텍스트 ─┘
  파인튜닝: 멀티모달 학습 데이터, 비전/오디오 인코더 필요

리소스가 제한된 대부분의 프로젝트는 캐스케이드 접근법을 사용해야 해요. 멀티모달 학습 비용 없이 멀티모달 기능을 얻을 수 있어요.

중요한 주의사항: 파인튜닝은 모델에 종속적

LoRA 어댑터는 학습된 정확한 기반 모델에서만 동작해요. 토크나이저(모델 간 토큰 ID가 다름), 가중치 차원, 레이어 아키텍처가 모두 모델에 특화돼 있어요. 베이스 모델을 바꾸면 모든 어댑터를 처음부터 재학습해야 해요.

이게 3계층 접근법이 중요한 이유예요: 계층 1과 2(프롬프트 엔지니어링과 RAG)는 모델 간 이식 가능해요. 계층 3(LoRA)은 모델에 종속적이에요. 학습 데이터(ChatML JSONL 형식)는 어댑터가 안 살아남아도 모델 변경에서 살아남아요.

핵심 교훈

파인튜닝으로 바로 뛰어들지 마세요. 프롬프트 엔지니어링과 RAG를 먼저 소진하세요 — 더 싸고, 이터레이션이 빠르고, 모델 간 이식 가능해요. 파인튜닝할 때는 파라미터 효율성을 위해 LoRA를, 소규모 팀에는 RLHF 대신 DPO를, 런타임이 하나의 어댑터만 서빙할 수 있을 때는 TIES-Merging을 사용하세요. 계층 3에 대한 투자는 계층 1과 2가 충분하지 않다는 명확한 증거로 정당화되어야 해요.