요즘 AI 에이전트 이야기를 따라가다 보면 자꾸 같은 단어로 돌아온다. RL, 더 정확히는 RLVR(Reinforcement Learning with Verifiable Rewards) 이다. OpenAI Deep Research, Claude Code 같은 도구가 단순 prompt engineering만으로 좋아진 게 아니라, 브라우징·코딩·도구 사용 같은 실제 과제를 반복하며 강화학습으로 다듬어졌다는 설명이 계속 나온다.
Deep Learning with Yacine의 영상 What are RLVR environments for LLMs?는 이 흐름을 꽤 좋은 입문 뉴스레터처럼 풀어준다. 핵심은 이거다. 앞으로 에이전트 성능의 차이는 모델 크기만이 아니라, 어떤 “환경(environment)”에서 굴렸는가로 갈릴 가능성이 크다.
여기서 환경은 그냥 데이터셋이 아니다. 문제, 모델의 행동 공간, 도구, 채점 함수, 업데이트 루프까지 묶인 작은 훈련장이다.
이번 영상이 답하는 질문
이 글은 영상을 보며 제가 붙잡은 네 가지 질문을 따라갑니다.
- RLVR은 RLHF와 무엇이 다른가?
- 왜 작은 모델이 특정 업무에서 큰 모델을 이길 수 있다고 말하는가?
- Verifiers 같은 라이브러리는 RL 환경을 어떻게 패키징하는가?
- Vision SR1 사례가 보여주는 “좋은 환경 설계”의 감각은 무엇인가?
RLVR은 사람이 점수를 주지 않는 강화학습이다
먼저 용어부터 정리해야 한다. RLHF는 Reinforcement Learning from Human Feedback이다. 사람이 선호를 표시하고, 그 선호를 reward model로 학습한 뒤, 모델을 조정한다. ChatGPT 이후 많이 알려진 방식이다.
RLVR은 조금 다르다. 보상이 사람이 느끼는 선호가 아니라, 환경이 자동으로 검증할 수 있는 결과에서 나온다. 수학 문제라면 답이 맞는지 틀렸는지 볼 수 있다. 코딩 문제라면 test가 통과하는지 볼 수 있다. 브라우저 작업이라면 목표 페이지에 도달했는지, 필요한 정보를 찾았는지, API를 제대로 호출했는지 확인할 수 있다.
영상은 RLVR 루프를 네 덩어리로 설명한다.
- Dataset: prompt, question, ground truth, metadata
- Policy: 답을 생성하는 LLM, 즉 actor
- Rollouts: 모델이 실제로 만든 추론, 답변, tool call trajectory
- Reward / Rubric: rollout을 채점하는 함수
여기에 GRPO나 DAPO 같은 policy update 알고리즘이 붙는다. 모델은 한 번 답하고 끝나는 게 아니라, 여러 rollout을 만들고, reward가 높은 행동 쪽으로 조금씩 이동한다.
중요한 변화는 “정답지를 더 많이 보여준다”가 아니라 “시도하게 하고, 결과를 자동 채점한다”는 점이다.
이 차이는 에이전트에서 특히 크다. 에이전트는 정답 문장 하나를 외우는 문제가 아니라, 중간에 검색하고, 도구를 부르고, 실패하면 다른 경로를 시도하는 문제를 푼다. 그러면 필요한 것은 예쁜 instruction dataset만이 아니라, 시도와 실패를 받아줄 환경이다.
작은 모델이 이기는 구간은 “좁은 업무”다
영상에서 흥미로운 사례로 OpenPipe의 ART•E 이메일 검색 에이전트가 나온다. Enron Corpus 기반의 synthetic email QA dataset을 만들고, 작은 Qwen 계열 모델을 GRPO로 훈련한 사례다.
처음에는 작은 모델이 당연히 약하다. 그런데 특정 이메일 검색 업무에 맞춰 RLVR로 계속 굴리면, 범용 대형 모델보다 해당 업무에서는 더 싸고 빠르게 동작할 수 있다. 영상 속 인용에서는 1,000번 검색 기준으로 O3는 약 55달러, O4-mini는 약 8달러 수준으로 언급되고, 작은 Qwen 2.5 14B 계열로 가면 비용이 한 자릿수 더 내려간다는 취지의 설명이 나온다. 물론 이 수치는 특정 실험과 당시 가격·구성에 묶인 예시로 읽어야 한다.
핵심은 수치 자체보다 방향이다. 범용 지능을 조금 포기하고, 좁은 업무에서 성능·지연시간·비용을 얻는다.
이건 실무적으로 꽤 현실적인 감각이다. 모든 업무에 최고 모델을 쓰면 편하지만, unit economics가 맞지 않는다. 고객 요청이 하루 10건이면 괜찮다. 10만 건이면 이야기가 달라진다. 이때 특정 업무를 반복적으로 잘하는 작은 모델을 훈련할 수 있다면, 제품 구조가 달라진다.
다만 조건이 있다. 업무가 반복 가능해야 하고, 보상이 자동 검증 가능해야 하고, 환경을 만드는 비용을 회수할 만큼 자주 돌아야 한다. RLVR은 마법이 아니라, “채점 가능한 반복 업무”에 강한 공학 패턴이다.
환경은 데이터셋보다 큰 단위다
영상 중반부터 Prime Intellect의 Environment Hub와 Verifiers 라이브러리가 나온다. 여기서 제일 중요한 문장은 Hugging Face 글에도 비슷하게 나온다. LLM을 강화학습으로 훈련하고 평가하려면 static dataset 이상이 필요하다는 말이다. 환경은 data, harness, scoring rule을 담은 소프트웨어 artifact다.
이 말이 좋다. 우리가 그동안 모델 평가를 생각할 때는 대개 benchmark dataset을 떠올렸다. 문제와 정답이 있는 파일이다. 그런데 에이전트는 그렇게 단순하지 않다. 터미널을 열 수도 있고, Python을 실행할 수도 있고, 웹을 탐색할 수도 있다. 그러면 평가 대상은 “답변 문자열”이 아니라 “행동의 궤적”이 된다.
Verifiers는 이런 환경을 만들기 위한 라이브러리다. GitHub README 기준으로 “LLM을 훈련하고 평가하기 위한 환경을 만드는 라이브러리”이며, Prime Intellect의 Environment Hub, prime-rl, Hosted Training과 통합되어 있다. 원래 Will Brown이 만든 프로젝트로 소개된다.
영상은 Verifiers 환경 작성 흐름을 일곱 단계로 풀어준다.
- dataset을 정한다.
- single-turn, multi-turn, tool-use 같은 interaction style을 고른다.
- environment logic을 구현한다.
- reward function, 즉 rubric을 만든다.
- 필요한 경우 parser를 붙인다.
- 환경을 패키징한다.
- eval이나 training으로 실행한다.
여기서 저는 4번, rubric이 제일 중요해 보였습니다. Rubric은 단순 점수표가 아니다. 모델이 앞으로 어떤 행동을 더 자주 하게 될지 정하는 압력이다. 정답만 보면 정답 맞히는 모델이 되고, tool call 수까지 보면 도구를 경제적으로 쓰는 모델이 되고, format까지 보면 구조화된 답변을 내는 모델이 된다.
즉 RLVR 환경 설계는 “무엇을 보상할 것인가”의 설계다. 그리고 이건 제품 철학과도 바로 연결된다.
Vision SR1은 “정답”보다 “보는 과정”을 보상한다
영상 후반의 Vision SR1 사례가 좋았다. Alexine이 소개하는 vision-language RLVR 환경이다. 문제의식은 간단하다. 많은 VLM은 이미지를 정말 보는 게 아니라, 텍스트 prior로 그럴듯하게 맞힌다. “dog”, “snow” 같은 단서만 보고 통계적으로 문장을 완성하는 식이다.
Vision SR1은 이걸 두 단계로 쪼갠다.
첫 번째 pass에서 모델은 이미지를 보고, 먼저 <description> 안에 시각 설명을 쓴다. 그다음 <think>로 추론하고, 마지막 답을 낸다. 두 번째 pass에서는 이미지를 제거한다. 모델이 방금 만든 description과 질문만 보고 다시 답하게 한다. description만으로도 정답을 복원할 수 있다면, 모델이 실제로 유용한 시각 정보를 포착했다고 볼 수 있다.
이 설계가 흥미로운 이유는 reward가 정답만 보지 않는다는 점이다. 모델이 무엇을 봤다고 주장했는지, 그 설명이 답을 지탱하는지까지 본다.
에이전트 업무로 바꿔 생각해도 비슷하다. “결과가 맞았는가”만 보면 우연히 맞힌 경로와 안정적으로 재현 가능한 경로를 구분하기 어렵다. 좋은 환경은 최종 답만이 아니라, 답을 가능하게 만든 중간 산출물도 보상한다. 브라우저 에이전트라면 어떤 페이지를 확인했는지, 코딩 에이전트라면 어떤 테스트를 돌렸는지, 리서치 에이전트라면 어떤 출처를 근거로 삼았는지까지 환경이 볼 수 있어야 한다.
오픈소스 모델에는 오픈 환경이 필요하다
영상의 스폰서 맥락을 감안하더라도, Environment Hub가 던지는 문제는 꽤 중요하다. 큰 연구소는 자체적으로 고품질 RL 환경을 만들 수 있다. 브라우저 작업, 코딩 작업, 수학 문제, 도구 사용 task를 내부에서 쌓고, 그 위에서 모델을 반복 훈련할 수 있다.
문제는 open model 생태계다. 모델 가중치는 공개되더라도, 좋은 훈련 환경이 닫혀 있으면 격차는 계속 벌어진다. 데이터셋만 공유해서는 부족하다. 에이전트는 데이터셋이 아니라 환경에서 배운다.
그래서 Environment Hub의 포지션은 Hugging Face Hub의 환경 버전에 가깝다. 모델과 dataset을 공유하듯, RL environment도 publish, versioning, reuse하자는 흐름이다. MLE Bench, IFEval-confusables, Multi-Agent Path Planning, Vision SR1 같은 community environment가 소개되는 것도 이 맥락이다.
이게 잘 되면 좋은 점은 분명하다. 연구자는 매번 harness를 새로 짜지 않아도 된다. 모델 개발자는 동일 환경에서 eval과 training을 이어갈 수 있다. 커뮤니티는 “이 모델이 좋다”를 넘어서 “이 환경에서 이렇게 좋아졌다”를 비교할 수 있다.
반대로 어려운 점도 분명하다. 환경은 코드다. 깨질 수 있고, reward hacking이 생길 수 있고, 특정 framework에 묶일 수 있다. 그래서 환경 공유는 단순 업로드가 아니라 버전 관리, 재현성, 보안, sandboxing까지 같이 풀어야 한다.
실무자가 바로 가져갈 감각
이 영상을 보고 당장 모든 팀이 RLVR training을 해야 한다는 뜻은 아니다. GPU 비용, 환경 작성 비용, reward 설계 난이도가 있다. 하지만 사고방식은 바로 가져올 수 있다.
에이전트를 만들 때 이렇게 물어보면 된다.
- 이 업무는 정답이나 성공 조건을 자동 검증할 수 있는가?
- 모델이 실패했을 때, 어디서 실패했는지 trajectory로 볼 수 있는가?
- 최종 답만 볼 것인가, 중간 행동도 채점할 것인가?
- 이 환경을 eval로 먼저 쓰고, 나중에 training으로 확장할 수 있는가?
저는 특히 마지막 질문이 중요하다고 봅니다. 좋은 eval harness는 미래의 RL environment가 될 수 있다. 반대로 좋은 RL environment는 매일 돌릴 수 있는 eval이 된다. 둘을 따로 생각하지 않는 쪽으로 agent engineering이 이동하고 있다.
OpenClaw 같은 작업에서도 비슷하다. 스킬, 브라우저 자동화, 리서치 루프, 블로그 발행 루프를 만들 때 “잘하라”는 prompt보다 더 중요한 것은 작은 환경이다. 입력을 주고, 도구를 열어주고, 결과를 채점하고, 실패를 기록하는 루프다. 결국 에이전트는 말로만 똑똑해지지 않는다. 반복 가능한 환경에서 좋아진다.
더 실습해보고 싶은 분들을 위한 참고 자료도 붙여둡니다. 이런 에이전트 루프와 harness 감각을 손으로 다뤄보고 싶다면 코난쌤의 책 **이게 되네? 오픈클로 미친 활용법 50제**와 AI 에이전트 실전 강의: 모두를 위한 루프 엔지니어링 쪽이 이어서 보기 좋습니다. RLVR 환경까지 가지 않더라도, eval과 loop를 어떻게 잡는지가 먼저다.
이번 영상의 한 줄 요약
LLM 에이전트의 다음 경쟁력은 “더 좋은 답변”이 아니라 더 좋은 훈련장일 수 있다. 데이터셋만으로는 부족하다. 정책이 행동하고, rollout이 쌓이고, rubric이 채점하고, 그 결과가 다시 모델을 바꾸는 환경이 필요하다.
이 관점에서 RLVR은 단순한 학습 기법이라기보다, 에이전트 제품을 만드는 방식에 가깝다. 어떤 행동을 반복시킬 것인가. 무엇을 성공으로 볼 것인가. 실패를 어떻게 다시 학습 신호로 바꿀 것인가. 이 질문에 답하는 팀이 앞으로 더 강한 에이전트를 만들 가능성이 크다.
링크
- 원본 영상: What are RLVR environments for LLMs? | Policy - Rollouts - Rubrics
- Verifiers: PrimeIntellect-ai/verifiers
- Environment Hub: Prime Intellect Environments
- Hugging Face 글: Exploring Environments Hub
- OpenPipe ART: OpenPipe/ART