에이전트 설계 ⑩ — 에이전트를 위한 RL: 평가 하네스가 곧 훈련 환경이 된다

프롬프트와 스캐폴드로 안 되는 마지막 구간은 학습으로 채운다 — 2025~26년, 에이전트 행동을 직접 훈련하는 도구들이 실용 단계에 들어왔다. 핵심 관점 전환부터: ⑨편에서 만든 평가 하네스가 그대로 RL 훈련 환경(gym)이 된다.

가장 낮은 진입장벽 — 관리형 RFT

OpenAI Reinforcement Fine-Tuning: 채점기(grader)만 정의하면 GPU 없이 RL 미세조정. 공개 사례의 숫자가 상당하다 — Harvey 법률 인용 F1 0.563→0.677, Ambience ICD-10 코딩 0.39→0.57(의사 베이스라인 +12pt), 세무 분석 ~40% 향상. 단 두 조건: 검증 가능한 좁은 도메인 + 명확한 채점기가 있을 때만(OpenAI 스스로의 가이드라인), 그리고 최신 프런티어가 아닌 o4-mini급에 묶인다는 트레이드오프.

오픈 스택 — 보상 설계의 병목이 풀렸다

• OpenPipe ART + RULER — 손으로 보상함수를 짜는 대신 LLM 심판이 같은 그룹의 궤적 N개를 상대 비교로 점수화해 GRPO에 투입: 4개 과제 중 3개에서 수작업 보상 이상, 개발 속도 2~3배. 대표 사례 ART·E: Qwen2.5-14B를 이메일 검색 에이전트로 훈련해 o3를 추월 — H100 1대 하루 미만, ~$80. 균형 잡힌 교훈: 그 승리는 "이메일 검색"이라는 극히 좁은 과제였다.
• verifiers + Environments Hub — RL 환경 정의의 사실상 표준 라이브러리. 환경을 자산으로 관리 — 같은 코드가 평가와 훈련에 모두 쓰인다.
• SkyRL — "RL은 데이터가 많이 필요하다"의 반례: SkyRL-SQL-7B는 653개 샘플의 멀티턴 RL로 text-to-SQL에서 GPT-4o·o4-mini 추월.
• rLLM — 2026년의 수렴점: 장난감 에이전트가 아니라 프로덕션에서 쓰는 진짜 하네스(Claude Code, mini-swe-agent 등)를 훈련 루프에 넣는다 — 평가 코드와 훈련 코드의 분포 불일치(train-serve skew)를 구조적으로 제거. 이 스택의 DeepSWE-32B가 공개 당시 오픈소스 SWE 에이전트 SOTA.

설계 원칙 두 가지

① 보상은 분해하라 — ToolRL: 도구 호출에 "정답 일치" 같은 거친 보상은 실패하고, 형식(format)과 정확성(correctness)을 분해한 세밀한 보상이 필요(+17% vs 베이스, 미지 시나리오 일반화 개선). ② 능력은 데이터 파이프라인에서 나온다 — Kimi K2 기술 보고서가 최대 스케일 증명: 수천 개 도구·시뮬레이션 환경에서 궤적을 대규모 합성하고 검증 가능 보상 + 자기비평 루브릭의 joint RL — 도구 스펙→시나리오→시뮬레이션 유저→궤적 필터링 파이프라인은 자체 도구셋용 학습 데이터를 만들려는 팀의 교과서다.

실무 순서는 명확하다: ① 프롬프트·도구 개선(②편) → ② 평가 하네스 구축(⑨편) → ③ 그래도 안 되는 좁고 검증 가능한 구간만 RL — 평가부터 만들면 훈련은 나중에 결정해도 같은 코드를 쓴다.

— 에이전트 설계 시리즈 ⑩ / 다음 글(완결): 프레임워크와 2026 스택