OpenForge RL: 어떤 하네스든 어떤 환경이든 끝까지 훈련한다 — 하네스 네이티브 에이전트 RL의 오픈 인프라

핵심 요약

현대 AI 에이전트는 Claude Code, Codex, OpenClaw 같은 추론 하네스(inference harness) 없이는 제 역할을 할 수 없다. 하지만 이 하네스가 너무 복잡해서, 오픈소스 연구자가 에이전트를 끝까지(RL까지) 훈련하는 건 거의 불가능했다. OpenForge RL은 이 문제를 풀는 두 가지 핵심 컴포넌트를 제시한다:

1. 경량 프록시(proxy): 하네스의 모델 호출을 가로채서 RL 프레임워크의 추론 엔진으로 라우팅하고, 동시에 모든 프롬프트-응답 쌍을 훈련 데이터로 기록한다.
2. Kubernetes 오케스트레이터: 각 롤아웃을 독립적인 원격 컨테이너에서 실행해서, 훈련 노드와 분리된 환경에서 실행할 수 있게 한다.

이 조합으로 “어떤 하네스 × 어떤 환경” 이든 훈련할 수 있다. 그리고 훈련-배포 불일치(train–deploy mismatch)가 사라진다.

논문: OpenForgeRL: Train Harness-native Agents in Any Environment (Columbia University · Microsoft Research, 2026년 7월)

문제: 하네스는 강력하지만 훈련하기 어렵다

에이전트 성능은 기본 모델만큼이나 하네스에 좌우된다. SWE-Agent가 보여준 이래로, Claude Code·Codex·OpenClaw는 멀티턴 추론, 도구 사용, 컨텍스트 관리, MCP 서버 연동을 하네스 수준에서 처리한다. 최근 에이전트 벤치마크 개선의 상당 부분은 모델이 아니라 하네스에서 온다.

하지만 오픈소스 RL 프레임워크(veRL, Slime 등)는 단순한 롤아웃을 가정한다: 단일 생성 또는 가벼운 도구 호출. 하네스의 상태 저장형 멀티프로세스 추론, 서브에이전트, 긴 컨텍스트 관리는 이 가정을 완전히 깬다. 그래서 연구자들은 훈련용으로 단순화된 하네스를 다시 구현해야 하고, 이건 배포 환경과 다른 “train–deploy mismatch”를 만든다.

OpenForge RL 논문은 이 격차를 명확히 지적한다:

“이러한 격차로 인해 독점적 하네스 기반 시스템이 연구 커뮤니티가 훈련하고 연구할 수 있는 것보다 점점 더 앞서나가고 있다.”

OpenForge RL의 설계

그림 1에서 볼 수 있듯, OpenForge RL의 핵심 아이디어는 훈련과 추론을 분리하는 것이다. 기존 RL 프레임워크는 훈련 루프 안에서 롤아웃을 직접 실행하지만, OpenForge RL은 롤아웃을 원격 컨테이너로 오프로드하고 프록시로 연결한다.

프록시 아키텍처

그림 2가 보여주는 구조를 단계별로 풀면:

1. 오케스트레이터가 Kubernetes에서 롤아웃 컨테이너 파드를 생성·관리·삭제한다 (Microsoft Azure 기반).
2. 각 컨테이너 안에서 하네스(ZeroClaw, OpenClaw, Codex 등)가 LLM/VLM과 환경 사이에서 추론을 진행한다.
3. 하네스가 모델을 호출할 때마다 프록시가 이를 가로채서, RL 프레임워크의 추론 엔진(vLLM 등)으로 라우팅한다.
4. 프록시는 모든 프롬프트-응답 쌍을 기록하고, 롤아웃이 끝나면 궤적을 재구성해서 훈련 샘플로 만든다.

이 설계의 장점은 하네스 코드를 전혀 수정할 필요가 없다는 것이다. 새 하네스나 새 환경을 지원하려면 샌드박스 설정만 바꾸면 된다.

비동기 롤아웃과 에러 처리

복잡한 환경에서는 하나의 롤아웃이 응답하지 않으면 전체 훈련 배치가 멈출 수 있다. OpenForge RL은:

• wall-clock 타임아웃: 턴 수 제한 대신 시간 제한을 걸어서, 초과하면 해당 롤아웃을 종료하고 에러 신호를 반환한다. 나머지 롤아웃은 계속 진행.
• 에러 궤적 폐기: DAPO 전략을 따라 네트워크 문제·하네스 크래시·타임아웃으로 끝난 궤적의 샘플을 모두 버린다. 부분 롤아웃이 잘못된 훈련 신호를 주는 것을 방지.

데이터 합성 파이프라인

코딩 도메인과 달리, 일상 도구 사용이나 GUI 제어 도메인은 훈련 데이터가 턱없이 부족하다. OpenForge RL은 그림 3의 파이프라인으로 이 문제를 해결한다:

1. 실제 시나리오에서 착안한 태스크 지시어를 병렬로 제안
2. 저품질·중복 태스크 정제
3. 각 태스크마다 실행 가능한 환경과 검증 스크립트를 구축
4. 별도의 오픈 LLM/VLM으로 태스크를 테스트
5. 결함이 있으면 수정해서 통과할 때까지 반복

이 파이프라인은 Linux/CLI 환경(claw)부터 가상 디스플레이(Xvfb)를 쓰는 GUI 환경까지 자연스럽게 확장된다.

성과: 텍스트 도구 사용 (Claw 에이전트)

백본 모델로 Qwen3-30B-A3B-Thinking를 사용하고, 4가지 하네스(ReACT, ZeroClaw, OpenClaw, Codex)에서 훈련했다. SFT는 MiniMax-M2.5에서 증류하고, RL은 GRPO로 진행했다 (8×B200 GPU).

벤치마크	지표	베이스 모델	SFT	SFT+RL
ClawEval	pass³	22.4	28.2	31.7
ClawEval	pass@3	42.1	49.7	55.9
QwenClawBench	pass@1	17.8	28.6	33.7
MCPAtlas	pass@1	16.2	25.1	28.1

RL이 SFT 위에 모든 벤치마크에서 추가 개선을 가져왔다. 특히 ClawEval pass³(3회 시도 모두 성공)이 28.2→31.7로 오른 건 RL이 단순히 운 좋은 샘플이 아니라 신뢰성 자체를 높였다는 증거다.

성과: GUI 에이전트

백본 모델로 Qwen3-VL-8B-Thinking를 사용하고, Kimi-Agent와 Molmo-Web 하네스에서 훈련했다.

벤치마크	OpenForge-GUI (SFT+RL)	이전 최고 오픈 모델
OSWorld-Verified	37.7	~33 (OpenCUA)
Online-Mind2Web	63.0	~58 (MolmoWeb)
WebVoyager	72.3	~70 (UI-TARS)

주목할 점: MolmoWeb은 20만 개 태스크로 훈련했지만, OpenForge-GUI는 단 2,500개로 이를 능가한다. 그리고 8B 모델이 여러 배 큰 모델들과 경쟁한다.

하네스 선택이 학습에 미치는 영향

이 논문의 가장 흥미로운 분석 중 하나는 어떤 하네스로 훈련하느냐가 모델 성능에 큰 영향을 미친다는 것이다.

하네스별 평가 (ClawEval)

하네스	베이스	SFT+RL	개선
ReACT*	22.4	37.4	+15.0
ZeroClaw	23.1	48.5	+25.4
OpenClaw	20.3	29.8	+9.5
Codex	18.7	39.0	+20.3

단순하고 도구 추가가 쉬운 ReACT*와 ZeroClaw에서 가장 큰 개선이 나타났다. OpenClaw는 프롬프트와 컨텍스트가 너무 길어서 학습하기 더 어렵다. 이는 “더 정교한 하네스가 항상 더 낫다”는 통념에 대한 반례다.

보이지 않는 하네스로의 일반화

ZeroClaw만으로 훈련한 모델을 OpenClaw와 Codex로 평가해도, 베이스 대비 +3.3 / +4.6의 개선이 나타난다. 그리고 세 하네스(ZeroClaw + OpenClaw + Codex)로 함께 훈련하면 모든 하네스에서 최고 성능을 낸다. 다양한 하네스로 훈련하는 것이 일반화에 유리하다.

RL이 에이전트 행동을 어떻게 바꾸는가

그림 5는 SFT 모델과 SFT+RL 모델의 행동 프로파일을 비교한다. 핵심 발견:

• 도구 사용 전환: RL을 거치면 generic shell 도구 사용이 줄고, 전용 서비스 도구(email, calendar, helpdesk 등) 사용이 늘어난다. 모델이 “도구가 있다는 걸 알고” 의도적으로 선택한다.
• 자기 검증(self-verification) 증가: RL 모델은 작업 완료 후 스스로 결과를 확인하는 빈도가 크게 늘어난다.
• 다단계 계획 완성도 향상: 긴 계획을 끝까지 수행하는 비율이 올라간다.
• 하지만 에러 복구는 여전히 약하다: 이건 RL만으로 풀기 어려운 영역으로 남아있다.

왜 중요한가

OpenForge RL은 에이전트 훈련의 민주화라는 관점에서 의미가 크다:

1. train–deploy mismatch 제거: 모델이 배포되는 하네스에서 그대로 훈련된다.
2. 확장성: 새 하네스나 새 환경을 추가하려면 샌드박스만 바꾸면 된다. 훈련 코드를 고칠 필요가 없다.
3. 효율성: 수백~수천 개의 태스크만으로 기존 수만 개 태스크 기반 모델을 능가한다.
4. 연구 가능성: 처음으로 “어떤 하네스가 학습하기 좋은가”라는 질문에 데이터로 답할 수 있게 되었다.

한계도 명확하다: 에러 복구 능력이 아직 약하고, 부분 롤아웃에서의 크레딧 할당 문제가 남아있으며, GUI 환경에서 실시간 웹사이트 의존성(사이트가 변경되면 검증이 깨짐)이라는 실용적 과제가 있다.

더 실습해보고 싶은 분들께

에이전트 하네스와 RL 루프를 직접 만들어보고 싶다면, 다음 두 자료를 추천한다:

• 『이게 되네? 오픈클로 미친 활용법 50제』 — 하네스 수준에서 에이전트를 활용하는 50가지 패턴을 실습 중심으로 다룬다. OpenForge RL이 다루는 “하네스가 성능을 좌우한다”는 통찰을 직접 체감할 수 있다.
• 「모두를 위한 루프 엔지니어링」 — 에이전트 루프를 설계하고 직접 루프엔지니어링을 실습하는 강좌다. 이 글에서 다룬 하네스·RL 피드백 루프도 루프엔지니어링의 일부다.

마무리

OpenForge RL은 단순히 또 하나의 에이전트 훈련 프레임워크가 아니다. 이 연구는 **“하네스가 모델보다 중요할 수 있다”**는 가설을 처음으로 체계적으로 검증할 수 있는 도구를 제공했다. ZeroClaw vs OpenClaw vs Codex의 학습 난이도 차이, 다중 하네스 훈련의 일반화 이점, RL이 만드는 행동 변화 패턴——이 모든 건 하네스를 “배포용 래퍼”가 아니라 학습 대상 그 자체로 다루었기 때문에 볼 수 있던 것이다.

코드, 데이터, 모델이 모두 공개될 예정이라고 한다. 오픈 에이전트 연구 커뮤니티에 상당한 영향을 줄 작업이다.