지난 2년 동안 대규모 언어 모델을 커스터마이징하는 이야기는 지도 학습 미세 조정에 관한 이야기였습니다. 좋은 행동의 예를 수집하고 LoRA 또는 전체 미세 조정을 실행한 후 모델이 그것을 모방하도록 학습시켰습니다. 이 접근 방식은 성숙하고, 저렴하며, 잘 이해되어 있습니다. 그리고 증가하는 문제 종류에 대해 충분하지 않습니다. 당신이 관심 있는 것이 스타일이 아닌 결과일 때 — 에이전트가 티켓을 해결했는가, 멀티 스텝 도구 시퀀스가 실제로 올바른 답을 검색했는가, 협상이 거래에 도달했는가 — 모방은 한계에 도달합니다. 긴 분기 상호작용의 모든 단계에서 최적의 작업에 대한 지도 예를 수집할 수 없습니다. 왜냐하면 당신은 최적의 작업이 무엇인지 모르기 때문입니다. 당신이 할 수 있는 것은 에이전트가 행동하도록 하고, 결과를 점수 매기고, 더 높은 점수를 생성했던 것으로 밀어붙이는 것입니다. 그것이 강화 학습이며, 2026년에는 exotic 연구 추구가 아닌 에이전트를 학습시키기 위한 실용적이고 접근 가능한 기술이 되었습니다.
이 변화는 주로 하나의 알고리즘과 그 주변의 도구 물결에 의해 주도되었습니다. GRPO (Group Relative Policy Optimization)은 고전적 RLHF를 고통스럽게 만든 많은 기계를 제거했고, 오픈소스 프레임워크 세트 — ART, verl, OpenRLHF — 은 연구소의 인프라 없이도 실행 가능하게 만들었습니다. 이 가이드는 2026년에 에이전트를 위한 강화 학습이 실제로 어떻게 작동하는지 설명하고, 대부분의 팀이 선택하는 세 가지 프레임워크를 비교하며, 리워드 설계 및 RL이 가치 있을 때에 대한 구체적인 지침을 제공합니다.
왜 지도 학습 미세 조정이 한계에 도달하는가
지도 학습 미세 조정(SFT)은 기본적으로 다음 토큰 모방입니다. 모델에 입력-출력 쌍을 보여주면 출력의 조건부 분포를 학습합니다. 좋은 행동이 예제로 잘 캡처되는 작업의 경우 — 톤 맞추기, 형식 따르기, 도메인 질문에 답하기 — 이는 아름답게 작동하며 SFT는 RL을 포함한 모든 것보다 첫 번째 선택으로 남아야 합니다. 더 저렴하고, 더 안정적이며, 무엇보다 디버그하기 쉽습니다.
한계는 많은 단계에 걸쳐 펼쳐지는 결과로 정의되는 좋은 행동일 때 나타납니다. 내부 문서를 검색하여 질문에 답하는 에이전트를 생각해보세요. 쿼리를 발행하고, 결과를 읽고, 다시 검색할지 결정하고, 마지막으로 답을 작성합니다. 당신이 실제로 가진 품질 신호는 최종 답이 올바른지 여부입니다. "이 부분 컨텍스트가 주어졌을 때 1단계에서 발행할 올바른 쿼리"가 레이블된 것이 없습니다. 왜냐하면 올바른 쿼리는 무엇이 돌아오는가에 달려 있고, 그것은 문서 저장소에 달려 있고, 그것은 변합니다. SFT는 에이전트가 당신이 기록한 몇 가지 추적을 모방하도록 가르칠 수 있지만, 많은 상호작용 가능성의 거대한 공간에서 end-to-end 결과를 최적화하도록 가르칠 수 없습니다. 에이전트는 기본 목표를 학습하는 대신 예제의 표면 형태에 과적합됩니다.
강화 학습은 설정을 반전시킵니다. 올바른 작업을 시연하는 대신, 에이전트가 자신의 작업을 수행하도록 하고, 결과를 관찰하고, 리워드를 할당하고, 높은 리워드 행동이 더 가능성이 높도록 정책을 조정합니다. 에이전트는 탐색하고 리워드(고정 스크립트가 아닌)는 성공을 정의합니다. 이는 정확히 멀티 스텝, 도구 사용 에이전트가 살고 있는 체제이며, 이것이 RL이 에이전트를 SFT 혼자서 도달할 수 있는 것 이상으로 밀어붙이기 위한 기술 선택이 된 이유입니다.
GRPO: 이를 실용적으로 만든 알고리즘
RL for LLMs이 오랫동안 닿을 수 없게 느껴진 이유는 PPO, 원래 RLHF 뒤의 workhorse 알고리즘 때문입니다. PPO는 강력하지만 운영상 무겁습니다. 정책과 나란히 별도의 value (비평가) 모델을 학습하고 제공해야 하며, 대략적으로 메모리를 두 배로 늘리고 조정하고 안정적으로 유지할 두 번째 모델을 추가합니다. 대부분의 팀에서 그 오버헤드는 금지되었습니다.
GRPO의 핵심 통찰력은 학습된 value 함수 없이 작업이 얼마나 좋았는지 추정할 수 있다는 것입니다. 같은 프롬프트에 대해 여러 샘플된 응답을 서로 비교합니다. 완성 그룹을 생성하고, 모두에 점수를 매기고, 그룹의 평균 점수를 기준선으로 사용합니다. 그룹 평균을 이기는 완성은 긍정적 장점을 받습니다. 아래로 떨어지는 것은 음수입니다. 그룹 내의 상대적 순위는 PPO의 비평가가 제공한 절대 value 추정을 대체합니다. 비평가 모델이 없고, 훨씬 적은 메모리, 그리고 추론하기 극적으로 더 간단한 학습 루프입니다.
이것이 2026년의 거의 모든 에이전트-RL 프레임워크가 GRPO를 중심으로 하는 이유입니다. 이는 "헌신적 ML 팀과 클러스터가 필요합니다"와 "합리적 양의 코드로 단일 capable GPU에서 이를 실행할 수 있습니다" 사이의 차이를 만들었습니다. 아래의 프레임워크는 주로 GRPO를 사용 가능한 인프라로 래핑하는 방법에 대한 다양한 의견입니다.
ART: 코드에 살고 있는 강화 학습
ART (Agent Reinforcement Trainer) OpenPipe에서 가장 에이전트 네이티브한 입장을 취합니다. 정의적 설계 선택은 클라이언트와 백엔드 사이의 분할입니다. 클라이언트는 에이전트의 rollouts — 에이전트가 행동하는 실제 에피소드 — 를 자신의 애플리케이션 코드 내에서 실행하고 표준 OpenAI 호환 chat completions 엔드포인트를 통해 모델과 대화합니다. 백엔드는 무거운 기계를 처리합니다. vLLM로 모델을 제공하고 Unsloth 최적화 커널로 GRPO 학습을 실행합니다. 두 절반이 다른 머신에서 실행될 수 있으므로 에이전트 로직은 노트북에 머물 수 있고 학습은 클라우드 GPU에서 발생합니다.
이 아키텍처는 이미 작성한 에이전트와 동일한 방식으로 rollouts을 작성할 수 있다는 것을 의미하기 때문에 중요합니다. 모델을 호출하고, 도구를 사용하도록 하고, 궤적을 캡처하고, 일반적인 Python으로 리워드를 할당합니다. 그러면 ART가 이러한 궤적의 그룹을 가져와 GRPO 업데이트를 수행합니다. 에이전트를 특수 RL 환경으로 리프레이밍할 필요가 없습니다. RL은 이미 작성한 코드 주변으로 래핑되어 있습니다. ART는 또한 깨끗한 수치 메트릭이 없을 때 그룹 내 궤적을 순위 지정하기 위해 모델을 사용하는 RULER라는 헬퍼를 제공합니다 — "더 나음"이 판단 가능하지만 직접 측정 가능하지 않은 많은 실제 작업에 유용합니다.
ART는 이미 구축한 특정 에이전트를 개선하는 것이 목표일 때, 특히 멀티 턴, 도구 사용 에이전트일 때, 그리고 rollout 로직을 자신의 환경에 유지하고 싶을 때 올바른 시작점입니다. 이 단일 에이전트, on-the-job 학습 사용 사례에 대해 최고 수준의 학습 효율을 대상으로 하지만, sprawling 분산 파이프라인은 아닙니다.
verl: 처리량 및 연구 유연성
verl (Volcano Engine Reinforcement Learning)은 다른 방향에서 나옵니다. LLM을 위한 고성능, 대규모 RL입니다. 분배를 위해 Ray와 빠른 생성을 위해 vLLM을 중심으로 구축되었으며, verl은 처리량과 알고리즘 및 리워드 체계를 실험해야 하는 연구원 필요성에 대한 유연성을 위해 설계되었습니다. PPO, GRPO, 그리고 증가하는 변형 가족을 지원하며, 여러 GPU에서 효율적으로 확장하도록 설계되었습니다.
트레이드오프는 verl이 더 많은 RL 기계를 노출한다는 것입니다. 당신은 학습 토폴로지, 알고리즘 세부 사항, 그리고 성능 노브에 대한 제어를 얻지만, 또한 더 많은 개념적 부하를 맡습니다. verl은 심각하고 컴퓨팅 집약적 RL을 하는 팀에 빛을 발합니다 — 더 큰 모델 학습, 많은 실험 실행, 또는 알고리즘 경계에서 밀어붙이기 — raw 처리량과 구성 가능성이 가파른 설정을 정당화하는 곳. 이는 "내 기존 에이전트를 래핑" 도구가 아니며 더 많은 연구 및 스케일 플랫폼입니다.
OpenRLHF: 생산 RLHF 규모
OpenRLHF는 자신을 고성능, 생산 준비 RLHF 프레임워크로 청구하며, Ray 및 vLLM에도 구축되었으며, 통합 에이전트 기반 설계가 있습니다. 광범위한 알고리즘 메뉴 — PPO, GRPO, REINFORCE++, RLOO 등 — 을 최적화 트릭과 함께 실제적 RLHF를 구현합니다. 이는 규모에서 안정적으로 유지하기 위해 필요한 것들입니다. 혈통은 전체 RLHF 파이프라인입니다. 리워드 모델링, 선호도 최적화, 분산 하드웨어에 걸친 정책 학습.
OpenRLHF는 필드가 가는 곳에서 보조를 맞출 유지했습니다. 2026년 릴리스는 멀티 턴 vision-language RL을 추가했으며, 팀이 여러 단계에 걸쳐 end-to-end 이미지를 추론하는 VLM을 학습할 수 있게 했습니다 — 에이전트 RL이 텍스트를 넘어 멀티모달 도구 사용으로 확장되고 있다는 신호입니다. OpenRLHF는 성숙하고 확장 가능한 RLHF 스택이 필요할 때, 광범위한 알고리즘 선택이 있고, 분산 시스템 운영에 편한 경우의 자연스러운 선택입니다.
세 가지 중 선택
결정은 문제의 형태와 인프라에 대한 식욕을 추적합니다. ART에 선택하세요. 이미 작성한 특정 에이전트를 개선하고, rollout 로직을 자신의 코드에 유지하는 것을 중시하고, 적절한 하드웨어에서 편하게 실행되는 split 아키텍처를 선호할 때. verl에 선택하세요. 처리량과 알고리즘 유연성이 우위 — 큰 모델, 많은 실험, 연구 경향 — 그리고 더 hands-on 설정을 흡수할 수 있을 때. OpenRLHF에 선택하세요. 규모에서 생산 등급, 광범위하게 capable RLHF 플랫폼이 필요하고, Ray 기반 분산 시스템을 실행할 운영 용량이 있을 때.
세 가지 모두 같은 엔진실에서 수렴합니다 — 알고리즘용 GRPO, 빠른 생성용 vLLM — 따라서 선택은 raw 능력이 아니라 작동하고자 하는 추상화 수준에 관한 것입니다. 유용한 정신 모델: ART는 에이전트 주변으로 RL을 래핑하고, verl과 OpenRLHF는 자신의 RL 플랫폼으로 에이전트를 가져오도록 요청합니다.
학습 루프의 구체적 그림
추상화를 구체화하는 데 도움이 됩니다. 문서 연구 에이전트를 학습시킨다고 상상해보세요 — 내부 지식 기반을 검색하여, 결과를 읽고, 답을 작성하여 질문에 답하는 종류입니다. GRPO 아래에서 루프는 다음과 같습니다. 각 학습 질문에 대해 그룹의 완전한 에이전트 에피소드를 샘플합니다. 8개라고 말합시다. 각 에피소드는 전체 rollout입니다. 에이전트는 검색을 발행하고, 결과를 읽고, 검색을 계속할지 결정하고, 최종 답을 생성합니다. 샘플링이 확률적이므로, 8개 에피소드는 다릅니다 — 어떤 것은 올바른 문서를 빠르게 찾고, 어떤 것은 방황하고, 어떤 것은 자신감 있게 하지만 잘못 답합니다.
그런 다음 각 에피소드를 리워드 함수로 점수 매기고 8개의 숫자를 생성합니다. GRPO는 그룹의 평균을 계산하고 각 에피소드에 평균 위 또는 아래로 얼마나 멀리 떨어져 있는지와 같은 장점을 할당합니다. 답을 정확히 맞힌 2개 에피소드는 긍정적 장점을 받습니다. 환각한 3개는 음수를 받습니다. 정책 업데이트는 모델이 높은 장점 행동을 더 가능성 높게 만들고 낮은 장점 행동을 덜 가능성 높게 만들도록 nudges 합니다 — 그룹의 모든 에피소드의 모든 토큰에 걸쳐. 많은 질문과 많은 단계에 걸쳐 반복하면, 에이전트는 점진적으로 리워드를 얻는 것으로 무엇이든 향해 자신의 전체 전략을 이동합니다. 더 나은 쿼리, 검색을 멈챌 때 알기, 검색된 텍스트에 답을 반영합니다.
이를 에이전트에 강력하게 만드는 것은 리워드가 오직 최종 결과를 판단하기만 하면 된다는 것입니다. 단계 1에서 올바른 쿼리를 레이블하지 않았습니다. 에이전트는 비교와 강화를 통해 특정 쿼리 패턴이 더 높은 리워드 끝으로 이어진다는 것을 발견했습니다. 그것은 SFT가 할 수 없는 것이며, 실제로 실행할 수 있는 루프로 표현됩니다. ART는 이를 동시에 수집된 궤적 그룹으로 구조화합니다. verl과 OpenRLHF는 Ray 기반 rollout 워커를 통해 같은 개념을 표현합니다. 어휘는 다르지만 GRPO 심장의 그룹 상대 비교는 세 가지 모두에서 동일합니다.
하드웨어 및 비용 기대
강화 학습 미세 조정은 SFT보다 무겁고, 시작하기 전에 기대를 설정할 가치가 있습니다. 지배적 비용은 생성입니다. 모든 학습 단계는 멀티 스텝 rollouts의 전체 그룹을 샘플링해야 하며, 도구 사용 에이전트의 경우 각 rollout은 여러 모델 호출과 도구 자체의 지연 시간을 포함할 수 있습니다. 이것이 모든 심각한 프레임워크가 vLLM에 기울어진 이유입니다 — 빠른 배치 inference는 여기서 어떤 것이 아니라, 학습 실행이 하룻밤에 끝나는 것과 끝나지 않는 것 사이의 차이입니다.
LoRA 스타일 어댑터를 사용하는 작은 모델의 경우 3–8B 범위에서, 단일 현대 데이터센터 GPU는 종종 실제 신호를 보기에 충분하며, ART의 Unsloth 최적화 백엔드가 특히 이 단일 GPU 효율성을 위해 조정될 때입니다. 더 큰 모델 또는 더 큰 그룹 크기로 확장하면 verl과 OpenRLHF가 구축된 멀티 GPU, Ray 기반 토폴로지로 밀어붙입니다. 실용적 수열은 작은 가능 모델에서 리워드와 rollout을 프로토타이핑하고, 리워드 곡선이 작은 데이터셋에서 상향으로 추세하는 것을 확인한 후, 더 큰 실행에만 클라우드 GPU를 커밋하는 것입니다. split 클라이언트/서버 설계 ART는 프로토타입 rollout 코드가 백엔드를 더 큰 하드웨어로 이동할 때 변경되지 않게 유지하기 때문에 편합니다.
리워드 설계가 실제 작업
어떤 프레임워크를 선택하든, 프레임워크는 프로젝트가 성공하거나 실패할 곳이 아닙니다. 리워드 함수입니다. 강화 학습은 정확히 당신이 리워드한 것을 최적화합니다. 즉, 어수선한 리워드가 당신에게 잘못된 것에 탁월한 에이전트를 얻습니다 — "리워드 해킹"이라는 현상입니다. 몇 가지 원칙은 일관되게 도움이 됩니다.
리워드를 경계 내로 유지하고 잘 확장합니다. GRPO는 그룹 내 상대 장점에서 작동하며, 크게 변하거나 경계 없는 리워드는 이러한 장점 추정을 소음이 많이 나고 학습을 불안정하게 만듭니다. 표현이 아닌 결과에 리워드합니다. 답이 표현되는 방법에 점수를 매기면, 에이전트는 해결하지 않고 표현을 배울 것입니다. 멀티 스텝 신용 할당이 어려울 때, 중간 성공에 대한 작은 shaping 리워드 — 유용한 데이터를 반환한 도구 호출, 올바른 문서를 타격한 검색 — 은 에이전트가 그들을 지시하지 않고 좋은 전략을 발견하도록 도움을 줄 수 있습니다. 그리고 확장하기 전에 손수 검사한 몇 가지 rollouts에서 리워드를 검증합니다. 에이전트가 실제로 높은 점수를 얻기 위해 무엇을 했는지 읽고, 당신의 의도와 일치하는지 확인합니다. 거의 모든 RL 실패는 팀이 의미한 것과 미묘하게 다른 것을 측정한 리워드를 추적합니다.
마지막으로, RL과 함께 오는 비용과 불안정성을 존중합니다. 이는 SFT보다 컴퓨팅 집약적이고 더 finicky입니다. 신호를 표시할 수 있는 가장 작은 모델과 데이터셋으로 시작하고, 리워드 및 손실 곡선을 강박적으로 기록합니다 (세 프레임워크 모두 Weights & Biases와 통합됨). 리워드와 추세를 신뢰할 때만 확장합니다. RL은 결과 최적화라는 특정 직업을 위한 강력한 도구이며, SFT가 소진되기 전에 선택되면 좌절스러운 것입니다.
요약
강화 학습 미세 조정은 2026년에 주류로 크로싱했습니다. GRPO가 RLHF 비실용적 만든 비평가 모델 오버헤드를 제거했고, ART, verl, OpenRLHF가 알고리즘을 사용 가능한 인프라로 변환했기 때문입니다. 먼저 SFT를 사용합니다. 이는 더 저렴하고 더 안정적인 기본값으로 남아 있습니다. 성공이 많은 단계에 걸쳐 펼쳐지고 모방으로 캡처될 수 없는 결과일 때 RL로 전환합니다. 이미 있는 에이전트를 래핑하기 위해 ART에 선택하고, 처리량과 연구 유연성을 위해 verl에, 확장 가능하고 멀티 capable 생산 RLHF를 위해 OpenRLHF에 선택합니다. 그런 다음 노력의 대부분을 프레임워크가 아닌 리워드 함수에 쏟습니다 — 강화 학습에서는 정확히 당신이 요청한 것을 얻습니다.
참고 문헌 및 리소스
프레임워크
- ART (Agent Reinforcement Trainer) — GitHub 및 launch post
- verl — GitHub
- OpenRLHF — GitHub
- vLLM 및 Unsloth (inference + training 백엔드)
알고리즘 및 배경
관련 1337skills cheatsheets
추가 읽기