서론

SFT와 GRPO라는 성질이 다른 두 가지 학습 데이터를 사용하여 fine-tuning을 수행할 때, "어떻게 chat 기반의 일관된 파이프라인을 구축할 것인가", "데이터의 혼합 비율을 어떻게 제어할 것인가", "로컬과 SaaS 중 어느 곳에서 어떤 도구를 사용해야 하는가"를 정리한다.

결론부터 말하자면, SFT와 GRPO는 데이터 포맷이 아니라 계산 그래프(computation graph) 자체가 다르기 때문에, 단순히 데이터를 섞어서 하나의 배치(batch)로 흘려보낼 수는 없다. 페이즈(phase)를 나누어 순차적으로 실행하고, 체크포인트(checkpoint)를 가교로 삼는 설계가 현실적인 해답이다.

1. Claude Code / ChatGPT에서 MCP 연동을 통한 FT 오케스트레이션이 가능한가

결론: 둘 다 기술적으로는 가능하다. 다만 성숙도에 차이가 있다.

Claude Code의 경우

Claude Code는 MCP 클라이언트로서 네이티브하게 설계되어 있으며, 다음과 같은 파이프라인을 구축할 수 있다.

데이터 클렌징 (Data Cleansing) (Claude Code가 로컬에서 bash/Python을 직접 실행) - SFT/GRPO 각각의 파일 형식 체크, 중복 제거, 리크(leak) 탐지

• GRPO의 경우 보상 함수(reward function)나 페어와이즈 비교(pairwise comparison) 데이터의 정합성 체크도 필요

FT 작업 기동 (FT Job Launching) (MCP 경유) - 자체 MCP 서버가 학습 백엔드(Unsloth, Together.ai, Fireworks, 자사 GPU 클러스터 상의 트레이닝 API 등)를 래핑(wrap)하고 있다면,
upload_dataset

→ start_finetune

과 같은 도구 호출로 실행할 수 있다.

• 자체 MCP 서버가 학습 백엔드(Unsloth, Together.ai, Fireworks, 자사 GPU 클러스터 상의 트레이닝 API 등)를 래핑하고 있다면,

모니터링/평가 (Monitoring/Evaluation) (MCP 경유) - 작업 상태 폴링(polling), 학습 곡선 취득, held-out 평가

모델 취득 (Model Acquisition) (MCP 경유) - LoRA 어댑터(adapter) 병합, 익스포트(export), 추론 엔드포인트로의 배포

기존 구현 사례로서 Unsloth MCP Server와 같은 프로젝트가 이미 존재하며, fine-tuning → 테스트 → 익스포트까지의 일련의 도구를 MCP를 통해 제공하고 있다.

ChatGPT의 경우

ChatGPT도 2025년 9월에 Developer Mode라는 커스텀 MCP 서버 대응을 추가하였으며, read/search에 한정되었던 기존 커넥터에서 write/modify 액션을 포함하는 풀(full) MCP 대응까지 진화했다.

"태스크를 끝까지 완수하는 멀티 스텝 에이전트(multi-step agent)"로서의 완성도는 Claude Code가 앞서는 반면, ChatGPT도 "채팅에서 도구를 호출한다"는 용도로는 충분히 실용적으로 변하고 있다.

2. 데이터 혼합 비율 제어 — 물리적 파일의 비율 변경만이 수단은 아니다

"학습 데이터의 혼합 비율을 바꾸고 싶다"고 할 때, 선택지는 업로드 파일의 물리적인 비율 변경만이 아니다. 다만 어떤 학습 기반을 사용하는지에 따라 사용할 수 있는 레버(lever)가 달라진다.

관리형 FT API (OpenAI FT API, Together.ai 등)

데이터셋 단위의 가중치 파라미터가 공개되지 않은 경우가 많아, 행의 중복(oversampling)이나 다운샘플링(downsampling)을 통해 파일 내의 비율을 물리적으로 바꾸는 것이 현실적인 유일한 수단이 되기 쉽다.

자체 트레이닝 루프/프레임워크

샘플링 가중치 (dataset weights) — interleave_datasets와 같은 메커니즘으로, 데이터셋마다 샘플링 확률을 직접 지정. 물리적 파일은 바꾸지 않고 DataLoader의 배치 구성 비율만 변경

온도 기반 믹싱 (Temperature-based mixing) — T5/mT5 스타일로, 각 데이터셋의 크기에 온도 파라미터를 적용한 후 정규화

손실 측 가중치 부여 (Loss-side weighting) — 샘플 단위/소스 단위로 loss 계수를 변경

동적 리웨이팅 (Dynamic reweighting) — DoReMi 방식으로, 학습 중 각 도메인에서의 loss 감소 추이를 보고 가중치를 순차적으로 업데이트

에포크 수 변경 — 데이터셋마다 서로 다른 에포크 수를 실행

GRPO의 경우에는 「데이터의 비율」보다, 롤아웃 (rollout) 시의 태스크 종류별 샘플링 비율이나 보상 (reward) 스케일링 설계가 더 효과적인 경우가 많다.

3. SFT와 GRPO를 「섞는 것」의 한계와 interleave_datasets의 활용처

interleave_datasets 자체는 여러 개의 Dataset/IterableDataset을 지정된 확률로 샘플링하여 하나의 스트림으로 만드는 기능일 뿐이다. 스키마 (schema)가 다른 데이터셋이라도 사전에 공통 포맷으로 map 해두면 기계적으로 섞는 것 자체는 가능하다.

하지만 본질적인 장벽이 있다. SFT는 티처 포싱 (teacher-forcing)으로 크로스 엔트로피 손실 (cross-entropy loss)을 계산하는 1회의 forward/backward로 완결되는 반면, GRPO는 프롬프트 (prompt)에 대해 온라인으로 그룹 롤아웃 (group rollout)을 생성 → 보상 계산 → 그룹 내 상대적 어드밴티지 (relative advantage) 계산 → 정책 경사 손실 (policy gradient loss)이라는 다단계 처리를 필요로 한다. 동일한 배치 (batch) 내에 SFT 예시와 GRPO 예시가 혼재하면 일반적인 Trainer로는 처리가 파괴된다.

실무상의 패턴은 3가지다:

• 태그 지정 + 커스텀 collate/training_step — 예시에 type 태그를 붙이고, training_step 측에서 type별로 처리를 분기하는 자체 제작 Trainer를 작성한다.
• 페이즈 분리 (가장 일반적) — SFTTrainer → GRPOTrainer와 같이, 애초에 별개의 페이즈 (phase)로서 순차적으로 실행한다. 「섞는 것」이 아니라 「SFT로 기초를 다진 후 GRPO로 정교화한다」는 순차적 패턴이다.
• 스텝/에포크 단위의 인터리브 (interleave) — 행 (row) 단위가 아니라 「N 스텝마다 1회만 GRPO 스텝을 삽입한다」는 스케줄링. 파괴적 망각 (catastrophic forgetting)을 방지할 목적으로 사용된다.

4. 페이즈별 FT를 위한 기존 솔루션

TRL (HuggingFace) — 가장 유력한 후보

HuggingFace의 TRL은 2026년 4월에 v1.0에 도달하여 SFTTrainer, DPO Trainer, KTO Trainer, ORPO Trainer, GRPO Trainer, Reward Trainer를 하나의 라이브러리로 통합했다. v1.0부터는 Unsloth의 커널 (kernel)까지 포함되어 있다.

구현 패턴으로는 SFTTrainer를 몇 에포크 먼저 실행하고, 그 결과인 체크포인트 (checkpoint)를 GRPOTrainer의 시작점으로 전달하기만 하면 된다. DeepSeek-R1의 파이프라인에서도 SFT는 「콜드 스타트 (cold start)」 페이즈로 기능하며, 고품질 궤적 (trajectory)의 소규모 세트로 RL 시작 전에 일관된 포맷과 추론 패턴을 사전 구축하는 설계로 되어 있다. 이것이 없으면 베이스 모델 (base model)로부터의 RL-from-scratch는 조기에 불안정한 동작 (언어 혼재 등의 포맷 붕괴)을 일으키기 쉽다.

MCP 서버 설계로서는, run_sft_phase(dataset, epochs) → run_grpo_phase(checkpoint_from_sft, dataset, steps)와 같이 두 개의 도구를 체인 (chain)으로 호출할 수 있게 해두면, 채팅에서 "SFT를 2 에포크, 그 후 GRPO를 500 스텝"이라는 지시가 그대로 작업 그래프 (job graph)에 반영된다.

더 대규모라면 verl / OpenRLHF

verl, OpenRLHF, TRL은 모두 리워드 모델 (reward model) 훈련 + PPO 최적화를 해결하지만, 스케일, 이기종 하드웨어 대응, 셋업의 복잡도 측면에서 서로 다른 트레이드오프 (trade-off)를 가진다. 이미 SFT가 완료되었고, 그 위에 풀 RLHF 레이어를 추가하고 싶은 팀에게 적합하다.

VLA/embodied AI 문맥이라면 RLinf

신체성 AI (embodied AI)나 물리 로봇을 위한 정책 최적화가 목적이라면, PPO, GRPO, SAC를 이기종 하드웨어 풀 (hardware pool) 전반에서 지원하고 VLA 트레이닝을 네이티브로 지원하는 RLinf가 적합하다.

5. 로컬 실행 선택지

TRL을 기반으로 삼으면서, 하드웨어 규모에 따라 다음 중 선택하는 것이 현실적이다.

단일 GPU/워크스테이션용: TRL + Unsloth 통합

TRL v1.0은 Unsloth의 커널을 통합하고 있기 때문에, 현재는 "TRL vs Unsloth" 사이에서 고민할 필요 없이 TRL API를 그대로 사용하면서 Unsloth의 가속 성능을 누릴 수 있다. 단일 GPU에서의 LoRA/QLoRA라면 2026년 시점에서 Unsloth가 명확하게 더 빠르며, 메모리 사용량도 30~70% 적게 소모된다. 멀티 GPU, 풀 정밀도 학습 (Full Precision Training), PPO를 이용한 본격적인 RLHF, 또는 Unsloth가 지원하지 않는 아키텍처의 경우에는 TRL을 그대로 사용한다.

16GB급 중급 GPU (RTX 4070 등)에서도 4bit 양자화 (Quantization) + LoRA + GGUF 익스포트 (Export) 조합으로 실용적으로 구동 가능하다.

Config 기반으로 프로덕션 운영에 가깝게 구성하려면 Axolotl

yaml 추상화를 통해 프로덕션 규모의 학습을 다루기 쉽게 만들었으며, GRPO도 지원한다. config + accelerate launch -m axolotl.cli.train config.yml 명령만으로 완결되는 구성으로, SFT · LoRA · QLoRA · DPO · KTO · ORPO · GRPO · 풀 리워드 모델링 (Full Reward Modeling)까지 일련의 과정을 모두 지원하며, 128K를 초과하는 컨텍스트 학습을 위한 시퀀스 병렬화 (Sequence Parallelism)도 구현되어 있다.

MCP 서버 측에서 "yaml을 생성하여 axolotl.cli.train을 호출한다"는 설계로 가져가면, SFT/GRPO 페이즈 전환도 yaml 교체만으로 해결되므로 채팅 기반의 오케스트레이션 (Orchestration)과 궁합이 좋다.

GUI가 필요하다면 LLaMA-Factory

Star 수가 가장 많은 프레임워크로, 브라우저에서 학습을 설정하고 시작할 수 있는 Web UI (LlamaBoard)가 동봉되어 있다. 다만 Unsloth와 같은 커스텀 커널이 없기 때문에 단일 GPU에서의 속도는 떨어진다. 채팅을 통한 자동화에 주안점을 둔다면 우선순위가 낮아진다.

Mac 로컬 환경에 집중한다면 MLX-LoRA

TRL 생태계와는 별개의 것이며, GRPO와 같은 복잡한 RL 기법에 대한 지원은 Unsloth/TRL/Axolotl만큼 성숙하지 않았다. 가벼운 검증 용도로 한정하고, 실제 프로덕션 GRPO 페이즈는 GPU 서버 측으로 넘기는 구성이 현실적이다.

GRPO 특유의 주의사항

GRPO는 크리틱 (Critic) 모델을 배제하므로 PPO보다 낮은 VRAM으로 구동 가능하지만, 롤아웃 생성 (Rollout Generation)을 위해 vLLM을 병행 사용하는 구성이 전제되는 경우가 많다. 로컬 GPU 1장인 경우, 정책 (Policy) 모델용과 vLLM용 VRAM 배분을 의어할 필요가 있다.

요약

SFT와 GRPO를 "섞는" 것이 아니라 "페이즈로서 연결하는" 설계로 방향을 잡고, 그 연결 지점(체크포인트 전달, 페이즈 길이 및 순서 결정)을 MCP 도구의 인터페이스로 구현하는 것이 채팅 기반의 조작성과 구현의 간결함을 양립할 수 있는 타협점이 될 것으로 보인다.

Discussion