[arXiv 2607.21557] OpenForge RL: 실제 배포 하네스 그대로 에이전트를 학습하는 분산 강화학습

OpenForge RL: Train Harness-native Agents in Any Environment

https://arxiv.org/abs/2607.21557

Xiao Yu, Baolin Peng, Ruize Xu, Hao Zou, Qianhui Wu, Hao Cheng, Wenlin Yao, Nikhil Singh, Zhou Yu, Jianfeng Gao | Columbia University, Dartmouth College, Microsoft Research | arXiv:2607.21557 | 2026년 7월

---

1. 서론: 배포 때 쓰는 하네스가 학습 때 사라지는 문제

1.1 모델 하나로 설명되지 않는 에이전트 성능

요즘의 AI 에이전트는 언어 모델 한 번을 호출해 답을 받는 프로그램과 구조가 다르다. Claude Code, Codex, OpenClaw 같은 추론 하네스(inference harness)는 대화 이력과 작업 상태를 관리하고, 셸·파일·브라우저·MCP 도구를 연결하며, 필요하면 계획 모드나 하위 에이전트를 실행한다. 같은 기반 모델을 넣어도 어떤 하네스가 어떤 문맥을 구성하고 도구 오류를 어떻게 되돌려 주느냐에 따라 결과가 크게 달라진다. 따라서 실제 에이전트의 정책은 모델 가중치만으로 결정되지 않고 모델과 하네스, 환경이 결합된 실행계에서 나타난다.

문제는 공개 SFT·RL 학습 스택이 이런 실행계를 그대로 다루기 어렵다는 데 있다. veRL 같은 학습 프레임워크는 보통 trainer가 프롬프트와 생성 과정을 직접 통제한다고 가정하지만, 복잡한 하네스는 내부에서 여러 모델 호출과 도구 호출을 만들고 문맥을 재구성한다. 연구자는 학습을 위해 하네스의 축소판을 다시 구현하게 되고, 배포에서는 원래 하네스로 돌아간다. OpenForge RL은 이 학습–배포 불일치(train–deploy mismatch)를 새 학습 알고리즘보다 모델 호출 중계와 실행 환경 분리라는 시스템 설계로 풀려 한다.

논문의 제안은 두 부품으로 압축된다. 첫째, 가벼운 프록시가 하네스가 보내는 모든 모델 생성 요청을 학습용 inference server로 전달하고 입출력 쌍을 기록한다. 둘째, Kubernetes orchestrator가 rollout 하나마다 독립 원격 컨테이너를 만들고 종료해, 서로 다른 하네스와 환경을 학습 노드 밖에서 병렬 실행한다. 이렇게 얻은 기록을 표준 trajectory로 복원하면 veRL과 GRPO 같은 기존 학습 스택이 하네스 내부 구현을 몰라도 실제 배포 하네스에서 나온 행동을 최적화할 수 있다.

Figure 1: 하네스·환경·원격 rollout·RL 학습을 연결한 OpenForge RL의 전체 구성과 주요 결과

Figure 1의 왼쪽은 CLI, 브라우저, 컴퓨터 사용 하네스를 원격 컨테이너 풀과 연결하고, 프록시가 수집한 trajectory를 RL 학습으로 되돌리는 구조를 보여 준다. 오른쪽 막대그래프는 30B-A3B Claw 모델과 8B GUI 모델이 SFT 뒤 RL을 거치며 여러 벤치마크에서 상승하는 흐름을 한 화면에 묶는다. 그림의 핵심은 특정 에이전트 하나의 최적화에 머물지 않고 하네스와 환경을 바꿔도 같은 학습 경로를 유지한다는 점이다.

1.2 논문이 검증하려는 세 가지 주장

OpenForge RL은 단순히 분산 rollout을 더 많이 돌릴 수 있다는 시스템 보고에 머물지 않는다. 논문은 실제 하네스를 그대로 학습에 넣을 수 있는지, 그 구조가 텍스트 도구 사용과 멀티모달 GUI 모두에서 작동하는지, 그리고 RL이 에이전트의 행동 양식을 어떻게 바꾸는지를 함께 묻는다. 이를 위해 OpenForge-Claw와 OpenForge-GUI라는 두 모델 계열을 학습하고 ClawEval, QwenClawBench, MCPAtlas, OSWorld-Verified, Online-Mind2Web, WebVoyager의 여섯 평가 환경을 사용한다. 하네스별 비교와 미관측 하네스 전이, 도구 사용 분포와 자기 검증 행동까지 분석한다는 점이 일반적인 leaderboard 논문보다 넓다.

검증 질문	논문의 설계	관찰 지표
실제 하네스를 재구현 없이 학습할 수 있는가	프록시와 원격 컨테이너 orchestrator	rollout 수집, trajectory 복원, 학습 안정성
서로 다른 환경으로 확장되는가	Claw·computer-use·browser-use 학습	6개 벤치마크 성공률
RL이 무엇을 학습하는가	SFT와 SFT+RL trajectory 비교	도구 분포, 자기 검증, 오류 회복, 단계 효율

세 질문은 서로 연결돼 있다. 학습이 가능하다는 주장만으로는 실제 배포 성능을 설명할 수 없고, 벤치마크 점수만으로는 향상이 모델의 추론 능력인지 하네스 적응인지 분리하기 어렵다. 논문은 같은 기반 모델과 과제를 두고 하네스를 바꾸거나 SFT와 RL 체크포인트를 비교해 원인을 좁힌다. 이 때문에 결과를 읽을 때는 최고 점수보다 하네스가 정책의 일부로 취급됐는가와 행동 변화가 어떤 trajectory 증거로 확인됐는가를 먼저 보는 편이 정확하다.

2. 배경 및 관련 연구: 모델·하네스·환경을 한 정책으로 보는 관점

2.1 ReAct 루프에서 상태적 다중 프로세스 실행으로

전통적인 ReAct형 에이전트는 관찰을 받고 생각과 행동을 출력한 뒤, 도구 결과를 다음 관찰로 붙이는 반복 구조로 설명할 수 있다. 이때 학습기는 대체로 전체 메시지 이력과 각 생성 토큰을 볼 수 있으며, 어느 토큰이 모델 출력이고 어느 부분이 환경 관찰인지 구분하기 쉽다. 반면 코딩·GUI 하네스는 자체 압축 규칙, 계획 파일, 스킬 문서, 하위 프로세스, 재시도 정책을 갖는다. 모델이 실제로 받는 문맥은 원시 환경 이력보다 하네스가 편집한 상태이며, 한 번의 외부 task가 내부적으로 여러 generation request로 쪼개진다.

이 차이는 학습 데이터의 단위를 바꾼다. 단일 응답을 하나의 sample로 보면 하네스가 만든 여러 호출 사이의 인과 관계와 terminal reward를 잃는다. 반대로 전체 로그를 거대한 문자열로 합치면 각 호출의 prompt boundary와 마스킹 범위가 흐려져 표준 RL 코드가 처리하기 어렵다. OpenForge RL은 하네스가 실제로 보낸 프롬프트를 $s_t^{\mathcal{H}}$로 기록하고 그에 대한 모델 응답 $a_t$를 짝지어, 하나의 task rollout을 여러 prompt–response pair의 trajectory로 복원한다. 하네스의 내부 상태를 이해하지 않고도 학습기가 관찰한 실질 문맥을 보존하는 절충이다.

2.2 하네스 공학과 모델 학습의 경계

SWE-Agent와 OpenHands 계열 연구는 도구 인터페이스와 실행 루프를 잘 설계하면 같은 모델의 성능이 크게 바뀐다는 사실을 일찍 보여 줬다. 최근의 Claude Code나 Codex는 파일 편집, 셸 실행, 계획 관리, 컨텍스트 압축과 권한 처리를 제품 수준으로 결합한다. 여기서 하네스는 단순 wrapper를 넘어 모델이 볼 수 있는 상태와 가능한 행동을 정의하는 정책의 외부 구조가 된다. 모델만 학습하고 하네스는 고정된 주변부로 보는 관점에서는 실제 실패의 상당 부분을 놓친다.

기존 공개 에이전트 RL 연구는 보통 특정 환경에 맞춘 경량 rollout loop를 학습 코드 안에 직접 작성한다. 이 방식은 실험 통제가 쉽지만, 배포용 하네스가 별도로 존재하면 학습 중 익힌 행동 규약과 배포 시 도구 규약이 어긋날 수 있다. 복잡한 하네스를 학습 프레임워크 안으로 옮겨 심는 방법도 있으나, 하네스가 업데이트될 때마다 training loop를 다시 고쳐야 하고 여러 프로세스·언어·런타임을 지원하기 어렵다. OpenForge RL은 이 경계를 API 프록시 앞에서 끊어, 하네스는 평소처럼 inference endpoint를 호출하고 학습기는 표준 sample만 받도록 한다.

2.2.1 네 개의 독립된 실행 평면

시스템 관점에서 OpenForge RL은 모델 계산, 하네스 제어, 환경 실행, 학습 업데이트의 네 평면을 분리한다. 모델 평면은 GPU inference server가 맡고, 하네스 평면은 각 pod 안에서 prompt와 tool flow를 구성한다. 환경 평면은 파일·service·browser·GUI state를 변화시키며, 학습 평면은 복원된 sample로 policy를 업데이트한다. 이 분리는 한 평면을 교체할 때 다른 평면의 코드를 최소한으로 건드리게 하지만, 네 평면 사이의 식별자와 시간 순서가 어긋나면 trajectory 자체가 오염되므로 observability가 필수다.

예를 들어 하네스가 내부 retry로 같은 모델 요청을 두 번 보내면 프록시는 두 응답을 모두 학습 sample로 기록할지, 최종 채택된 응답만 남길지 결정해야 한다. 하위 에이전트가 병렬로 실행되면 호출 순서는 wall-clock과 논리적 dependency가 다를 수 있다. 한 task의 reward를 어느 branch에 귀속할지도 단순 시간 정렬로 해결되지 않는다. 논문은 본 실험의 하네스에서 실용적인 reconstruction을 보이지만 concurrent subagent와 speculative call이 많은 제품형 하네스에서는 causal graph 수준의 trace schema가 필요해진다.

모델 API 호환성도 범용성의 실제 경계를 정한다. text-only chat completion은 prompt와 response가 비교적 단순하지만 vision request는 screenshot binary, message ordering, image tokenization metadata를 함께 보존해야 한다. streaming response와 tool-call JSON은 중간 chunk를 합치고 stop reason을 유지해야 하며, provider별 system message나 hidden prefix가 있으면 재현성이 달라진다. 따라서 proxy가 OpenAI-compatible endpoint를 제공한다는 설명 뒤에는 request canonicalization, tokenizer version, multimodal payload hash 같은 세부 계약이 따라야 한다.

하네스 업데이트는 policy distribution shift로도 작용한다. tool description 한 문장, default timeout, context compression threshold가 바뀌면 같은 모델이 받는 상태와 가능한 action이 달라진다. OpenForge RL이 배포 하네스를 그대로 학습한다는 장점은 특정 version에서는 강하지만, 배포 직전 하네스가 바뀌면 다시 rollout을 수집하고 alignment를 점검해야 한다. 모델 checkpoint와 함께 harness commit·container digest·skill bundle을 하나의 release unit으로 관리하는 agent stack versioning이 필요하다.

이 관점은 하네스 성능을 모델 성능과 분리해 보고하던 기존 평가 방식도 바꾼다. 동일 모델을 여러 하네스에 넣은 matrix와 동일 하네스에 여러 모델을 넣은 matrix를 함께 측정해야 model effect, harness effect, interaction effect를 추정할 수 있다. OpenForge의 cross-harness table은 그 출발점이지만 tool registration 방식과 prompt budget까지 완전히 통제한 factorial experiment는 아니다. 후속 연구에서 하네스의 기능 수, prompt 길이, tool schema 직접성, error feedback granularity를 독립 축으로 조절하면 학습 난이도의 원인을 더 정확히 찾을 수 있다.

2.3 기존 위키 흐름과의 연결

이 구조는 이전에 정리한 sandboxed agent harness와 agentic harness evaluation의 교차점에 놓인다. 전자는 파일·네트워크·도구 권한을 격리된 실행 공간 안에 두는 운영 계층을 강조하고, 후자는 최종 답뿐 아니라 도구 호출 수, timeout, 근거 경로, formatting failure까지 평가해야 한다고 본다. OpenForge RL은 같은 sandbox를 평가용 격리막에 그치지 않고 rollout 생성 장치로 사용한다. 각 컨테이너의 terminal reward와 프록시 기록이 학습 신호로 돌아가면서 격리·관찰·최적화가 하나의 폐루프를 이룬다.

OpenThoughts-Agent의 agentic SFT pipeline이 task source, teacher rollout, trajectory filtering을 데이터 레시피로 분해했다면, OpenForge RL은 그 다음 병목인 실제 하네스 기반 온라인 rollout을 다룬다. 두 연구 모두 성공 trajectory만 모으는 SFT와 환경 상호작용을 통한 RL을 구분하지만 초점은 다르다. OpenThoughts-Agent는 어떤 과제와 trajectory를 섞을지에 무게를 두고, OpenForge RL은 그 trajectory를 어떤 하네스·컨테이너·학습 엔진 연결에서 만들지에 무게를 둔다. 데이터 레시피와 실행 substrate가 결합돼야 공개 모델이 제품형 에이전트 루프에 적응할 수 있다는 계보가 보인다.

접근	학습 단위	장점	주요 위험
단일-turn SFT/RL	프롬프트–응답	구현과 attribution이 단순함	배포 하네스 행동을 반영하지 못함
환경별 custom loop	도구 상호작용 trajectory	특정 task에 정밀하게 맞출 수 있음	하네스마다 training code가 분기됨
OpenForge RL	하네스가 만든 호출 쌍의 집합	실제 배포 루프와 학습 루프를 일치시킴	프록시 기록·보상·오류 분류의 정확성에 의존함

표의 마지막 위험은 중요하다. 하네스를 재구현하지 않는다고 해서 관찰 편향이 사라지는 것은 아니다. 프록시가 어느 요청을 한 trajectory로 묶는지, timeout이나 harness crash를 정책 실패와 어떻게 구분하는지, terminal reward를 중간 호출에 어떻게 전파하는지가 새 학습 계약이 된다. OpenForge RL의 기여는 복잡성을 없앤 데 있지 않고 복잡성이 머무는 위치를 하네스 내부에서 기록·복원·오류 처리 경계로 옮긴 데 있다.

3. 방법론: 프록시 기록과 원격 sandbox로 하네스-native trajectory 만들기

3.1 하네스가 편집한 상태를 정책 입력으로 정의하기

논문은 장기 task를 MDP $\langle \mathcal{S},\mathcal{A},\mathcal{T},\mathcal{R},\gamma \rangle$로 놓는다. 시점 $t$에서 정책 $\pi_\theta$는 환경 관찰을 받아 행동을 내지만, 실제 시스템에서 모델이 받는 입력은 원시 상태 $s_t$가 아니라 하네스가 도구 설명·압축된 이력·계획 정보를 붙여 만든 $\mathcal{H}(s_t)$다. 따라서 관찰 기록은 환경 로그보다 실제 generation request body를 기준으로 해야 한다. 이 정의 덕분에 OpenClaw와 Codex가 서로 다른 방식으로 문맥을 구성해도 학습기는 각 하네스가 모델에 제공한 입력을 그대로 sample로 취급한다.

한 rollout에서 프록시는 $(s_t^{\mathcal{H}},a_t)$ 쌍을 시간 순서대로 모으고 task 종료 시 terminal reward $r_T$를 받는다. 복원된 trajectory는 $$\tau=((s_0^{\mathcal{H}},a_0,r_0),\ldots,(s_T^{\mathcal{H}},a_T,r_T))$$로 표현된다. 중간 보상은 $r_t=\gamma^{T-t}r_T$로 두며, 실험에서는 보통 $\gamma=1.0$을 사용한다. 즉 성공 rollout의 여러 모델 호출에 같은 terminal signal이 전달되고, GRPO에서는 같은 task에서 샘플링한 서로 다른 trajectory의 평균 보상을 비교해 advantage를 계산한다.

이 설계는 구현상 간단하지만 credit assignment 관점에서는 강한 가정을 포함한다. 마지막 성공을 만든 중요한 도구 선택과 불필요한 우회 호출이 같은 보상을 받을 수 있고, 실패 rollout 안의 올바른 prefix도 0 또는 음성 신호로 묶인다. 논문은 부분 rollout이 인프라 오류로 끊긴 경우에는 trajectory 전체를 버리는 보수적 정책을 택한다. 잘못된 negative signal을 피하는 대신, 오류 직전까지의 유용한 탐색을 학습에 재사용하지 못한다는 비용이 생긴다.

3.2 프록시와 trajectory reconstruction

프록시는 하네스와 vLLM·SGLang 같은 inference server 사이에 들어간다. 하네스 입장에서는 평소의 모델 API를 호출하지만 실제 요청은 프록시를 거쳐 trainer가 관리하는 inference engine으로 전달된다. 프록시는 요청 프롬프트, 생성 응답, rollout 식별자와 종료 reward를 수집한다. 이 방식은 하네스가 Python이든 Rust든 별도 프로세스이든 상관없이 모델 호출 프로토콜만 맞으면 같은 관찰 경계를 사용할 수 있게 한다.

Figure 2: RL trainer와 원격 하네스 sandbox 사이에서 generation request와 trajectory를 교환하는 구조

Figure 2에서 RL training node는 trainer와 inference server를 유지하고, 별도 OpenForge RL 영역은 rollout orchestrator·proxy server·trajectory reconstruction을 맡는다. orchestrator가 여러 sandbox pod를 띄우면 각 pod의 하네스가 프록시에 generation request를 보내고, 종료된 호출 묶음은 reward가 붙은 trajectory로 trainer에 돌아간다. 모델 계산과 CPU·메모리 중심 환경 실행을 분리해 비동기 병목을 줄이는 동시에, 하네스별 차이를 sandbox 이미지 안으로 국소화한다.

Trajectory reconstruction이 필요한 이유는 하네스가 한 task에서 모델 API를 여러 번 부르기 때문이다. 프록시는 개별 호출을 독립 sample로 저장하는 데서 끝나지 않고 동일 rollout ID에 속한 호출을 모아 terminal reward와 연결해야 한다. 도구 출력은 모델이 생성한 토큰이 아니므로 loss mask를 구분하고, assistant response만 정책 업데이트 대상으로 남겨야 한다. 논문은 이 복원 결과가 표준 RL sample 형식이기 때문에 backend가 하네스 제어 흐름을 직접 실행할 필요가 없다고 설명한다.

3.2.1 reconstruction에서 보존해야 할 데이터 계보

학습 sample을 정확히 재현하려면 prompt text와 response text만으로는 부족하다. rollout ID, task ID, harness version, model checkpoint, sampling seed, tool schema hash, environment image digest, 시작·종료 시간, reward source가 함께 연결돼야 한다. group-based RL에서는 같은 task의 여러 trajectory가 동일 policy snapshot에서 생성됐는지도 중요하다. 오래된 rollout과 최신 rollout이 한 group에 섞이면 advantage가 policy 차이를 task 난이도 차이로 오해할 수 있다.

비동기 수집은 GPU utilization을 높이지만 policy staleness를 만든다. 느린 GUI pod가 10분 이상 실행되는 동안 trainer가 새 parameter로 갱신되면 batch 안의 trajectory가 서로 다른 behavior policy에서 나올 수 있다. 논문의 wall-clock timeout은 batch block을 막지만 stale sample 처리 규칙을 대신하지는 않는다. rollout 시작 시 policy version을 고정하고, 허용 staleness를 넘긴 sample은 별도 queue로 보내거나 importance correction을 적용하는 선택지가 필요하다.

GRPO의 group 구성도 환경 비용과 연결된다. Claw와 Computer-Use는 task당 group size 8이므로 같은 instruction을 여덟 환경에서 독립 실행해야 advantage 대비가 가능하다. 성공률이 지나치게 낮으면 group 전체 reward가 0이 돼 gradient signal이 사라지고, 지나치게 높으면 모두 성공해 역시 구분력이 낮아진다. task sampler가 현재 정책의 중간 난이도 영역을 유지해야 sample 효율이 높아지며, 합성 task pool의 난이도 추정과 curriculum이 시스템 성능에 직접 영향을 준다.

멀티모달 request에서는 screenshot의 실제 픽셀과 tokenized representation 사이 계보가 특히 중요하다. browser zoom, display resolution, color profile, image compression이 바뀌면 같은 화면도 다른 시각 token을 만든다. 프록시가 URL이나 임시 경로만 기록하면 나중에 원본이 사라져 trajectory를 audit할 수 없다. 개인정보를 제거한 screenshot hash와 제한된 보관 기간을 두고, model input으로 사용된 최종 resize 결과를 추적하는 방식이 재현성과 privacy를 함께 다룰 수 있다.

도구 결과에 포함된 비결정성도 별도 표시가 필요하다. 검색 순위, 이메일 inbox 시각, 실시간 website 상태, remote API 응답은 같은 action을 재실행해도 달라질 수 있다. policy가 좋아져서 성공했는지 환경 운이 좋아서 성공했는지 구분하려면 외부 observation snapshot과 verifier evidence를 남겨야 한다. OpenForge의 proxy trace에 environment provenance를 결합하면 training sample을 단순 대화 로그가 아닌 실행 가능한 evidence bundle로 관리할 수 있다.

3.3 Kubernetes rollout orchestration과 실패 격리

하네스 rollout은 GPU 생성만 필요한 작업이 아니다. task마다 Docker image, 파일, mock service, 브라우저, 가상 디스플레이, CPU와 메모리가 필요하다. 이를 training node에 함께 올리면 환경 의존성이 충돌하고 rollout 수를 늘릴수록 GPU 노드가 비효율적으로 사용된다. OpenForge RL은 Orchard를 바탕으로 Kubernetes orchestrator가 cloud VM pool에 pod를 생성·할당·삭제하도록 하고, 모델 serving은 GPU 학습 노드에 남긴다.

원격 실행에서는 step count만으로 hang을 막기 어렵다. Codex처럼 내부 turn 제한을 노출하지 않는 하네스가 있고, 같은 ‘한 단계’가 하네스마다 전혀 다른 작업량을 의미할 수 있기 때문이다. 논문은 rollout job 전체에 넉넉한 wall-clock timeout을 둔다. 제한을 넘으면 pod를 종료하고 proxy와 reconstruction 모듈에 error signal을 보내 나머지 rollout이 batch 수집을 계속하게 한다.

오류 분류도 학습 안정성에 직접 관여한다. 네트워크 장애, harness crash, browser service 실패는 정책이 잘못된 행동을 선택한 결과와 다르지만 terminal success만 보면 모두 실패로 보일 수 있다. 저자들은 이런 인프라 오류 trajectory를 통째로 버려 잘못된 보상 전파를 막는다. 다만 정책이 실제로 무한 루프를 만들었는지 외부 서비스가 멈췄는지 경계가 모호한 사례에서는 discard 규칙이 어려운 행동을 선택적으로 지워 학습 분포를 낙관적으로 만들 가능성이 있다.

3.4 task synthesis: 제안에서 검증 가능한 환경까지

공개 RL-ready agent task가 부족하므로 논문은 task와 실행 환경을 자동으로 합성하는 별도 파이프라인을 사용한다. 입력은 목표 도메인과 필요한 task 수이며, reference asset pool에는 기존 task, 웹·X 검색 결과, API 검색, 파일 자료가 들어간다. Claude Agent SDK 위의 Opus 4.6 agent들이 후보를 제안하고, 중복·저품질 항목을 가지치기한 뒤, Dockerfile·도구 서버·mock data·verifier를 포함한 실행 환경을 만든다. 다른 모델이 실제 rollout을 수행해 성공 여부와 ambiguity를 확인한 후 오류가 있으면 환경이나 지시를 수정한다.

Figure 3: Propose–Prune–Build–Test–Refine으로 검증 가능한 agent task를 만드는 자동 합성 절차

Figure 3은 target domain과 task 수를 입력받아 reference pool에서 후보를 제안하고, 품질 필터를 거쳐 실행 파일과 환경을 구축하는 세로 흐름을 보여 준다. Test 단계의 별도 모델 rollout이 통과하면 instruction·test·artifact·Dockerfile을 묶은 verified task가 되고, 실패하면 Refine agent가 결함을 고친 뒤 재시험한다. 단순 instruction 생성과 달리 verifier가 반복 RL에서도 일관된 reward를 줄 수 있는지 실제 실행으로 점검한다는 점이 비용과 품질을 함께 결정한다.

SFT task와 RL task에는 다른 비용 정책이 적용된다. Claw SFT는 test·refine을 생략하고 GPT-5.4 judge로 성공 trajectory를 한 번 필터링하지만, RL task는 반복 rollout에서 verifier가 계속 사용되므로 전체 test–refine loop를 유지한다. 논문이 보고한 평균 합성 비용은 Claw SFT task가 5.2분·0.86달러, Claw RL task가 16.1분·4.36달러다. Computer-use에서는 SFT가 4.0분·1.37달러, RL task가 21.3분·6.12달러로 올라가 GUI 환경 검증의 부담이 더 크다.

3.5 학습 알고리즘과 하네스 독립성

OpenForge RL의 RL 실험은 GRPO를 사용하지만 프레임워크 자체는 특정 알고리즘에 묶이지 않는다. proxy가 복원한 sample에 prompt, response, reward와 group 정보가 있으면 PPO·GRPO·REINFORCE 계열 backend가 각각 필요한 advantage와 loss를 계산할 수 있다. 논문의 ‘any harness × any environment’는 모든 조합이 설정 없이 자동 작동한다는 뜻보다 하네스별 training loop 재작성 없이 공통 rollout interface에 연결된다는 뜻으로 읽어야 한다. sandbox image와 verifier, action space는 여전히 환경마다 만들어야 한다.

또한 하네스 독립성은 정책 독립성과 같지 않다. 같은 기반 모델이 ZeroClaw, OpenClaw, Codex에서 받는 프롬프트 길이와 tool affordance가 다르기 때문에 학습 난이도와 최적 정책도 달라진다. OpenForge RL은 이 차이를 지우지 않고 오히려 실제 학습 데이터 안에 보존한다. 그 결과 어떤 하네스가 모델 능력과 잘 정렬되는지, 여러 하네스의 trajectory를 섞으면 unseen harness로 전이되는지를 실험적으로 비교할 수 있다.

4. 실험 설정: Claw·컴퓨터·브라우저를 같은 학습 계약으로 묶기

4.1 데이터셋 및 task 분포

Claw 실험은 일상 도구 사용을 중심으로 한다. ClawHub의 skill·use case와 ZClawBench task를 reference pool로 삼아 이메일, 검색, helpdesk, 파일 처리, finance와 workflow task를 합성한다. 각 task는 ReAct, ZeroClaw, OpenClaw, Codex 가운데 하나의 하네스와 짝지어 rollout을 만든다. SFT에는 MiniMax-M2.5 teacher를 사용해 task당 세 번 생성하고 성공 trajectory만 남긴다.

Computer-use는 AgentNet의 2만 2천 instruction, X 검색 사례, Synthetic-Computer-Use의 파일·데이터를 seed로 사용한다. 전통적인 QEMU 기반 전체 VM 대신 Xvfb로 메모리 안에 가상 디스플레이를 렌더링해 컨테이너를 가볍게 만든다. 수정된 Kimi-Agent harness가 screenshot을 보고 mouse·keyboard·bash·file-edit tool을 호출한다. 이 구성은 시각 입력과 저수준 행동을 포함하면서도 Kubernetes pod 단위 병렬화를 가능하게 한다.

Browser-use는 현실 웹사이트와 database를 합성하기 어렵기 때문에 기존 WebGym task에서 시작한다. 평가 benchmark와 겹치는 task, parent intent를 잘게 나눈 중복 task, long-tail website를 제거하고 Qwen3-Embedding-8B cosine similarity 기반 greedy deduplication을 적용한다. SFT 후보 2,500개에서 Kimi-K2.5를 task당 최대 30 turn·4회 실행해 성공 trajectory를 모은 뒤 가장 짧은 것만 남겨 1,496개를 사용한다. RL은 InSTA-v3 600개와 PAE-WebVoyager 300개를 SFT pool과 겹치지 않게 구성한다.

Figure 4: Claw, Computer-Use, Browser-Use RL task의 범주별 비율

Figure 4에서 Claw RL은 Data Finance가 47.8%로 가장 크고 Security 19.1%, Workflow 22.0%가 뒤를 잇는다. Computer-Use는 Multi-app 24.8%를 중심으로 Media 13.2%, System 12.8%, Coding 11.8% 등으로 분산되며, Browser-Use는 Science & Research 32.3%, Misc. 23.9%, Lifestyle & Leisure 23.1%가 대부분을 차지한다. 도메인마다 task entropy가 다르므로 세 평균 점수를 같은 난이도 축처럼 직접 비교하면 안 된다.

항목	Claw	GUI Computer	GUI Browser
하네스	ReAct, ZeroClaw, OpenClaw, Codex	수정 Kimi-Agent	수정 Molmo-Web
SFT trajectory	892	795	1,496
RL task	343	252	900
기반 모델	Qwen3-30B-A3B-Thinking	Qwen3-VL-8B-Thinking	Qwen3-VL-8B-Thinking

표에서 눈에 띄는 점은 수십만 task보다 수백에서 수천 수준으로 학습했다는 사실이다. 논문의 주장은 대규모 pretraining 대신 배포 하네스와 맞는 환경 상호작용을 적은 수의 검증 가능 task로 제공하면 의미 있는 향상이 나온다는 것이다. 다만 각 task가 여러 rollout과 긴 도구 상호작용을 포함하므로 단순 task 수가 계산량을 대표하지 않는다. 특히 task 합성·teacher distillation·RL sampling까지 합치면 실제 환경 실행 횟수와 GPU·CPU 시간이 훨씬 커진다.

4.2 구현 세부사항과 자원 구성

Claw와 Computer-Use는 GRPO batch size 8, group size 8을 사용하고 Browser-Use는 batch size 12, group size 5를 사용한다. 학습률은 각각 $1\times10^{-6}$, $5\times10^{-7}$, $1\times10^{-6}$다. KL coefficient는 0.001, 0.01, 0.0으로 다르며 Browser-Use만 entropy coefficient 0.001을 둔다. rollout 시간 제한은 Claw·Browser 900초, Computer 600초다.

하이퍼파라미터	Claw	Computer-Use	Browser-Use
학습률	$1\times10^{-6}$	$5\times10^{-7}$	$1\times10^{-6}$
Batch / group	8 / 8	8 / 8	12 / 5
KL / entropy	0.001 / 0	0.01 / 0	0 / 0.001
최대 rollout	900초	600초	900초
학습 step / 시간	100 / 48시간	80 / 36시간	100 / 32시간
Pod 자원	2 CPU, 2GiB	4 CPU, 4GiB	2 CPU, 6GiB

세 설정 모두 policy training은 단일 8×B200 GPU node에서 실행된다. Claw pod는 Azure D128ads v5 pool에, Computer-Use pod는 D64ads v5 pool에 배치되고, Browser-Use pod는 D128ads v7과 Browser-Use Cloud의 원격 Chromium을 함께 쓴다. Browser rollout은 최대 48개를 동시에 실행한다. 이 자원표는 ‘가벼운 proxy’와 ‘저렴한 전체 학습’이 같은 말이 아님을 보여 준다.

4.2.1 rollout 처리량과 비용을 결정하는 병목

분산 agent RL의 처리량은 GPU token generation 속도만으로 정해지지 않는다. pod image pull, container cold start, browser session 발급, website latency, verifier 호출, artifact upload가 모두 batch 완료 시간을 늘린다. group 하나에서 가장 느린 rollout을 기다리는 barrier가 있으면 평균보다 tail latency가 중요하다. 논문의 timeout과 비동기 orchestration은 이 tail을 제한하지만, 실제 효율을 비교하려면 GPU utilization과 함께 p50·p95 rollout latency, timeout rate, discarded sample rate를 보고해야 한다.

자원 분리는 비용 이동도 만든다. training node에서 CPU 환경을 떼어 내면 비싼 B200의 idle time은 줄지만 Azure VM pool과 remote browser 비용이 추가된다. Claw는 pod당 2 CPU·2GiB, Computer-Use는 4 CPU·4GiB, Browser-Use는 2 CPU·6GiB여서 task 유형에 따라 CPU·memory 압력이 다르다. 동일 성공률 향상을 얻는 데 든 GPU-hour, VM-hour, browser-minute, teacher·judge API 비용을 합산한 cost per verified improvement가 있어야 배포 팀이 방법을 비교할 수 있다.

SFT와 RL의 비용 구조도 다르다. SFT는 성공 teacher trajectory를 모은 뒤 여러 epoch 재사용할 수 있지만, on-policy RL은 policy가 바뀔 때마다 새로운 environment interaction이 필요하다. QwenClawBench에서 RL 추가 이득이 1.6점에 그친 경우와 WebVoyager에서 10.8점 오른 경우의 marginal cost는 같지 않다. benchmark별 성능 곡선을 environment step과 dollar 축에 함께 그리면 어느 domain에서 online interaction이 실제로 가치가 있는지 판단할 수 있다.

동시 rollout 수를 무조건 늘리는 것도 해답은 아니다. inference server가 여러 긴 context request를 받으면 prefill이 몰리고 KV cache pressure가 커져 token latency가 악화될 수 있다. 하네스는 모델 응답을 기다리는 동안 CPU에서 tool을 실행하므로 generation과 environment phase가 교대로 나타난다. orchestrator가 현재 inference queue 길이와 pod phase를 보고 concurrency를 조절하는 backpressure가 있어야 GPU와 CPU pool을 함께 포화시킬 수 있다.

재시도 정책은 비용과 데이터 분포를 동시에 바꾼다. network error에 자동 retry를 허용하면 infrastructure noise는 줄지만 쉬운 task가 더 많은 sample을 만들거나 특정 service의 rate limit을 우회해 실제 배포와 다른 조건이 될 수 있다. retry 횟수와 timeout 연장도 trajectory metadata에 기록하고 평가 때 동일 정책을 적용해야 한다. 그렇지 않으면 학습 점수는 policy 능력과 운영 layer의 회복 기능을 분리하기 어렵다.

4.3 베이스라인과 평가 계약

ClawEval은 2026-04-08 general-domain release와 공식 ReAct형 loop를 사용하고 $pass^3$와 $pass@3$를 보고한다. $pass@3$는 세 번 중 적어도 한 번 성공할 가능성을 반영하고, $pass^3$는 세 번 모두 성공해야 하므로 반복 신뢰성에 더 엄격하다. QwenClawBench는 OpenClaw harness 아래 $pass@1$을 사용한다. MCPAtlas는 credential이나 별도 초기화가 필요 없는 기본 20개 server 설정에서 ground-truth tool call이 모두 지원되는 89개 task만 남기고 claim coverage 0.75 이상을 성공으로 센다.

GUI 평가는 OSWorld-Verified의 평균 성공률, Online-Mind2Web와 WebVoyager의 $pass@1$을 사용한다. Online-Mind2Web는 AgentTrek protocol과 o4-mini judge를, WebVoyager는 공식 protocol과 GPT-4o judge를 사용한다. 모든 OpenForge GUI 모델은 screenshot을 시각 입력으로 받으며, 최대 step 수는 비교 모델마다 30·50·100으로 다를 수 있다. 이 차이 때문에 표의 점수는 모델 크기뿐 아니라 action budget과 harness·judge 계약까지 포함한 시스템 결과다.

벤치마크	영역	하네스·평가	읽을 때 주의할 점
ClawEval	일상 도구 사용	공식 ReAct, $pass^3$·$pass@3$	평균 성공과 반복 안정성을 분리해야 함
QwenClawBench	Claw task	OpenClaw, $pass@1$	배포형 하네스 적응이 점수에 포함됨
MCPAtlas	MCP tool use	89 task, claim coverage ≥0.75	500개 전체가 아닌 실행 가능한 subset
OSWorld-Verified	desktop GUI	공식 평균 성공률	최대 step과 action space 차이 확인
Online-Mind2Web	실시간 웹	AgentTrek, o4-mini judge	website 변화와 judge 의존성
WebVoyager	실시간 웹	공식 protocol, GPT-4o judge	baseline별 보고 출처가 다름

평가 계약이 다양한 것은 프레임워크의 범용성을 보여 주지만 통합 score를 만들기 어렵게 한다. 여섯 benchmark의 성공 정의, judge, action budget, harness가 서로 다르므로 숫자를 단순 평균해 하나의 ‘agent intelligence’로 부르는 것은 근거가 약하다. 논문도 도메인별 표를 분리해 제시한다. 가장 설득력 있는 비교는 같은 benchmark와 같은 harness 안에서 base, SFT, SFT+RL을 이어 보는 것이다.

5. 주요 실험 결과: 적은 task로 얻은 Claw·GUI 성능 향상

5.1 Claw agent의 반복 신뢰성과 도구 전이

OpenForge-Claw는 Qwen3-30B-A3B-Thinking을 기반으로 하며 약 3B active parameter를 사용하는 MoE다. 기반 모델은 ClawEval에서 $pass^3$ 14.3, $pass@3$ 39.8을 기록한다. SFT 뒤에는 21.7과 52.1로 오르고, SFT+RL은 31.7과 55.9에 도달한다. $pass@3$ 상승보다 $pass^3$ 상승이 더 크다는 점은 RL이 한 번의 운 좋은 성공보다 반복 성공의 안정성을 더 많이 개선했음을 시사한다.

모델	ClawEval $pass^3$	ClawEval $pass@3$	QwenClawBench	MCPAtlas
LLaMA-4-Scout-17B-16E	0.6	16.8	2.6	2.3
Qwen3-32B	6.8	31.7	14.6	22.5
Qwen3-30B-A3B-Thinking base	14.3	39.8	21.8	12.4
OpenForge-Claw SFT	21.7	52.1	32.1	23.6
OpenForge-Claw SFT+RL	31.7	55.9	33.7	28.1

QwenClawBench에서는 base 21.8에서 SFT 32.1, SFT+RL 33.7로 올라 SFT가 대부분의 향상을 담당한다. MCPAtlas에서는 base가 12.4, SFT가 23.6, SFT+RL이 28.1로 RL의 추가 이득이 더 크다. Claw training에 MCPAtlas task가 포함되지 않았으므로 저자들은 이를 novel MCP tool-use 전이로 해석한다. 다만 89개 default-server subset과 LLM judge threshold를 쓴 결과이므로 전체 500개 task 일반화로 확대해서 읽으면 안 된다.

대형 폐쇄 모델과 비교하면 여전히 격차가 크다. Claude Opus 4.6은 ClawEval $pass^3$ 70.8, QwenClawBench 59.5, MCPAtlas 76.4를 기록하고 GPT-5.4도 각각 60.2, 56.7, 68.5다. 논문의 강점은 frontier model을 이겼다는 데 있지 않고 비슷한 크기의 공개 모델과 base checkpoint 대비 일관된 향상을 만들었다는 데 있다. 특히 하네스별 데이터가 적은 조건에서 반복 신뢰성을 두 배 이상 끌어올린 결과가 시스템 기여와 맞물린다.

5.2 GUI agent의 computer·browser 결과

OpenForge-GUI는 Qwen3-VL-8B-Thinking을 기반으로 한다. OSWorld-Verified에서 base 29.4, SFT 34.4, SFT+RL 37.7을 기록한다. Online-Mind2Web에서는 38.7에서 57.4, 63.0으로 크게 오르고 WebVoyager에서는 49.2에서 61.5, 72.3으로 상승한다. 세 benchmark 모두 RL 추가 학습이 SFT보다 높은 결과를 내므로 proxy·orchestrator가 멀티모달 장기 rollout에서도 학습 signal을 전달했다는 증거가 된다.

모델	최대 step	OSWorld-Verified	Online-Mind2Web	WebVoyager
OpenCUA-7B	50	28.2	–	–
UI-TARS-1.5-7B	100	27.4	31.3	66.4
MolmoWeb-8B	30	–	35.3	78.2
Qwen3-VL-8B base	50	29.4	38.7	49.2
OpenForge-GUI SFT	30	34.4	57.4	61.5
OpenForge-GUI SFT+RL	30	37.7	63.0	72.3

Online-Mind2Web의 base 대비 총 상승은 24.3점이고 WebVoyager는 23.1점이다. OSWorld-Verified 상승은 8.3점으로 상대적으로 작다. browser task는 실시간 웹과 judge를 사용해 환경 변동성이 크지만, OpenForge-GUI는 MolmoWeb-8B보다 훨씬 적은 2,500개 SFT 후보를 사용하면서 Online-Mind2Web에서 높은 점수를 얻는다. WebVoyager에서는 MolmoWeb-8B의 78.2보다 낮은 72.3이므로 모든 browser benchmark에서 최고라는 해석은 맞지 않는다.

OpenForge-GUI와 대형 모델 비교도 조건을 맞춰 봐야 한다. Qwen3-VL-235B-A22B는 OSWorld 38.1, Online-Mind2Web 63.7, WebVoyager 66.4로 OpenForge의 37.7, 63.0, 72.3과 엇갈린다. 8B 모델이 수십 배 큰 모델과 근접하거나 일부 지표에서 앞선다는 저자 주장은 이 표에서 지지된다. 그러나 GPT-5.4와 Claude Opus 4.6은 100 step budget 아래 OSWorld 75.0과 72.7을 기록해 최상위 시스템과의 절대 격차는 유지된다.

5.3 결과를 task 효율로 읽을 때의 조건

논문은 ‘수백에서 수천 task’라는 데이터 효율을 강조한다. Browser SFT 후보 2,500개는 MolmoWeb이 사용한 20만 개 이상보다 작고, Claw RL 343개와 Computer RL 252개도 task 수만 보면 적다. 하지만 각 task는 teacher의 세 번 또는 네 번 rollout, 검증과 refinement, GRPO group sampling을 포함한다. 데이터 효율은 instruction 개수 기준으로 높지만 environment interaction 수나 dollar·GPU-hour 기준 비용 효율은 별도 계산이 필요하다.

또한 SFT와 RL의 기여 비율이 benchmark마다 다르다. QwenClawBench는 SFT 10.3점 상승 뒤 RL이 1.6점을 더하고, MCPAtlas는 SFT 11.2점 뒤 RL이 4.5점을 더한다. Online-Mind2Web는 SFT 18.7점과 RL 5.6점, WebVoyager는 SFT 12.3점과 RL 10.8점으로 나타난다. RL이 항상 주요 향상원이라고 일반화하기보다 SFT가 tool grammar와 성공 trajectory prior를 만들고 RL이 반복 신뢰성과 환경별 적응을 보강한다고 읽는 편이 데이터와 맞는다.

5.3.1 점수 차이를 해석할 때 필요한 통계적 여유

ClawEval의 $pass@3$와 $pass^3$는 같은 세 번의 반복에서 서로 다른 신뢰성 측면을 본다. 예를 들어 SFT+RL의 $pass@3$ 55.9와 $pass^3$ 31.7 사이 간격은 task별 성공 확률이 균일하지 않고 불안정한 task가 상당함을 뜻한다. 단일 Bernoulli 확률을 가정하면 두 지표가 단순 공식으로 연결되지만 실제 task마다 난이도와 상관된 failure mode가 달라 그 관계가 깨진다. task-level 세 번 결과와 confidence interval이 공개되면 RL이 어떤 난이도 구간에서 반복성을 높였는지 더 정밀하게 분석할 수 있다.

MCPAtlas 89개 task에서 4.5%포인트 상승은 약 네 task의 성공 차이에 해당한다. judge threshold가 0.75이고 한 trajectory만 생성하므로 몇 개의 borderline 판정이 순위를 바꿀 수 있다. bootstrap interval, judge 재평가 agreement, threshold sensitivity가 없으면 23.6과 28.1의 차이를 안정적인 일반화 이득으로 확정하기 어렵다. 그럼에도 base 12.4에서 SFT+RL 28.1로 이어지는 전체 상승은 더 크므로, 데이터·학습 전체 pipeline의 효과와 RL 단독 효과를 분리해서 보고할 필요가 있다.

GUI benchmark는 실시간 website와 LLM judge를 사용해 반복 측정의 중요성이 더 크다. Online-Mind2Web의 63.0과 대형 Qwen3-VL의 63.7 차이는 환경 시점과 judge variance 안에서 사실상 동률일 수 있다. WebVoyager의 72.3과 MolmoWeb의 78.2도 두 결과가 동일 날짜·동일 website snapshot·동일 action budget에서 측정됐는지 확인해야 공정하다. 논문은 공식 또는 기술 보고서 수치를 섞어 제시하므로 근접한 수치의 순위보다 base 대비 내부 개선을 우선 해석해야 한다.

Baseline fairness에는 하네스와 step budget도 포함된다. OpenForge-GUI는 최대 30 step인데 OpenCUA와 Qwen base는 50, UI-TARS와 frontier model은 100 step을 쓰는 항목이 있다. 적은 step에서 높은 성공률을 얻은 것은 효율성의 긍정적 신호지만, action granularity가 다르면 한 step의 의미가 달라진다. click과 type을 별도 action으로 세는 하네스와 script block을 한 action으로 실행하는 하네스를 동일 step 수로 비교할 수 없으므로 raw tool call과 wall-clock latency를 함께 봐야 한다.

결과표가 보여 주는 가장 일관된 pattern은 학습이 특정 benchmark 하나에만 맞춰진 형태가 아니라는 점이다. Claw에서는 official ReAct, OpenClaw, MCP loop가 섞이고 GUI에서는 Kimi-Agent와 Molmo-Web 계열이 섞이는데 base 대비 상승이 모두 관찰된다. 이 breadth는 OpenForge RL의 interface가 여러 환경에서 작동한다는 증거다. 반면 각 domain에서 한 기반 모델 계열만 사용했으므로 Llama·Mistral·Gemma 계열에서도 같은 learning dynamics가 나오는지는 아직 열려 있다.

모델 계열을 확장할 때는 tokenizer와 tool-call pretraining 차이를 고려해야 한다. Qwen3 계열은 thinking과 structured tool use prior가 강해 하네스 prompt를 빠르게 습득할 수 있지만, 다른 모델은 SFT 단계에서 schema alignment에 더 많은 data가 필요할 수 있다. proxy는 어떤 모델도 연결할 수 있어도 학습 난이도가 동일하다는 보장은 없다. 최소 두 개 이상의 독립 base family에서 harness mixing과 RL gain을 반복해야 framework generality와 Qwen-specific compatibility를 분리할 수 있다.

6. 추가 분석 및 Ablation Study: 하네스 난이도와 RL이 바꾼 행동

6.1 같은 모델도 하네스에 따라 학습 난이도가 달라진다

저자들은 동일한 ClawEval task를 ReAct, ZeroClaw, OpenClaw, Codex 네 하네스에서 평가한다. ReAct와 ZeroClaw는 custom tool을 직접 등록할 수 있지만 OpenClaw와 Codex는 ClawEval 전용 도구를 SKILL.md로 설명하고 bash를 통해 호출한다. 더 풍부한 built-in tool과 control flow가 있는 하네스가 반드시 높은 점수를 주지 않는다. prompt가 길고 custom tool integration이 간접적이면 모델이 필요한 action을 찾기 어려워질 수 있다.

모델	ReAct $pass@1$	ZeroClaw	OpenClaw	Codex	ReAct $pass@3$	ZeroClaw	OpenClaw	Codex
Base	26.1	32.5	11.4	12.2	39.8	44.7	19.3	18.6
SFT	36.2	44.5	16.7	21.1	52.1	66.5	24.2	35.4
SFT+RL	45.1	48.5	20.9	32.5	55.9	67.1	27.8	51.5

SFT+RL의 $pass@1$은 ZeroClaw 48.5, ReAct 45.1, Codex 32.5, OpenClaw 20.9 순이다. Base 대비 증가는 ReAct +19.0, ZeroClaw +16.0, OpenClaw +9.5, Codex +20.3으로 Codex는 초기 점수가 낮지만 학습 이득이 크다. OpenClaw는 긴 prompt와 context를 소비하면서 상승폭이 제한적이다. 이 결과는 하네스 기능 수보다 모델이 도구와 control flow를 얼마나 명시적으로 이해할 수 있는지가 학습 가능성을 좌우함을 보여 준다.

6.2 보지 못한 하네스로 전이되는가

두 번째 분석은 같은 task와 recipe를 쓰되 rollout을 만든 하네스만 바꾼다. 한 모델은 ZeroClaw trajectory로만 SFT+RL하고, 다른 모델은 ZeroClaw·OpenClaw·Codex를 섞어 학습한다. ZeroClaw-only 모델에서 OpenClaw와 Codex는 학습 중 보지 못한 하네스다. 이 비교는 task 지식이 아닌 tool grammar와 control-flow 다양성이 전이에 주는 영향을 좁힌다.

SFT+RL 학습 하네스	ZeroClaw $pass@1$	OpenClaw $pass@1$	Codex $pass@1$
없음(base)	32.5	11.4	12.2
ZeroClaw만	46.0 (+13.5)	14.7 (+3.3)	16.8 (+4.6)
세 하네스 혼합	48.5 (+16.0)	20.9 (+9.5)	32.5 (+20.3)

ZeroClaw-only 학습도 unseen OpenClaw에서 +3.3, Codex에서 +4.6을 얻어 일부 행동 prior가 전이된다. 세 하네스를 섞으면 OpenClaw +9.5와 Codex +20.3으로 상승폭이 커지고, seen ZeroClaw도 46.0에서 48.5로 개선된다. 저자들은 다양한 tool call과 control flow 노출이 robustness를 높인다고 해석한다. 다만 세 하네스 혼합은 총 trajectory 종류와 prompt 분포가 넓어지므로 순수한 ‘다양성 효과’와 데이터량 효과를 완전히 분리했다고 보기는 어렵다.

6.3 RL은 범용 셸 의존을 줄이고 전문 도구 사용을 늘린다

저자들은 SFT와 SFT+RL 체크포인트에서 각각 100개 ClawEval trajectory를 수집한다. ZeroClaw에서는 전체 tool call 분포를 비교하고 Codex에서는 format robustness, error recovery, self-verification, tool coverage, step efficiency를 rule-based 기준으로 판정한다. 이 분석은 성공률 변화만으로 알 수 없는 정책 습관을 보여 준다. RL이 같은 답을 더 긴 경로로 우연히 얻는지, 도구 선택과 검증 절차를 실제로 바꾸는지 확인하는 장치다.

Figure 5: ZeroClaw에서 RL 전후 전문 도구와 범용 shell 호출 비중의 변화

Figure 5에서 generic shell 비중은 SFT 22.6%에서 SFT+RL 13.9%로 8.7%포인트 줄고, web_search는 6.2%에서 7.1%, file_read는 5.3%에서 6.3%로 늘어난다. contacts_search와 helpdesk_get_ticket은 소폭 감소하며, 나머지 전문 도구 묶음은 48.4%에서 56.2%로 커진다. 평균 trajectory 길이도 13.0에서 12.2로 줄어, 전문 도구 전환이 무조건 더 긴 탐색을 만든 결과는 아니다.

이 변화는 reward가 도구 이름을 직접 가르치지 않았다는 점에서 의미가 있다. 환경 성공 여부만으로 GRPO를 수행했는데도 정책은 범용 shell에서 service-specific tool로 이동했다. 전용 도구는 argument schema와 결과 구조가 명확해 성공한 trajectory에서 credit를 받기 쉽고, shell은 자유도가 높지만 quoting·path·parsing 오류가 누적될 수 있다. RL은 하네스가 제공하는 affordance 중 성공 확률이 높은 경로를 경험적으로 선택한 것으로 해석할 수 있다.

6.4 자기 검증은 늘지만 오류 회복은 여전히 약하다

Figure 6: Codex trajectory에서 측정한 형식 안정성·오류 회복·자기 검증·도구 포괄성·단계 효율

Figure 6의 radar chart는 SFT+RL이 format robustness 85.7, error recovery 26.0, self-verification 59.9, tool coverage 80.9를 기록해 SFT의 79.3, 17.4, 41.9, 54.5보다 높아진 모습을 보인다. 반면 step efficiency는 84.5에서 79.2로 낮아진다. RL agent가 write 뒤 read-back이나 추가 확인을 수행해 성공 신뢰성을 높이는 대신 최단 성공 경로보다 몇 단계를 더 쓰는 trade-off가 나타난다.

행동 지표	SFT	SFT+RL	변화
Format robustness	79.3	85.7	+6.4
Error recovery	17.4	26.0	+8.6
Self-verification	41.9	59.9	+18.0
Tool coverage	54.5	80.9	+26.4
Step efficiency	84.5	79.2	−5.3

가장 큰 상승은 task에 필요한 여러 service를 모두 호출하는 tool coverage다. 자기 검증도 크게 늘어 long-horizon 완료 조건을 확인하는 습관이 강화됐다. 그러나 error recovery는 상승 후에도 26.0으로 다섯 지표 중 가장 낮다. terminal success reward만으로는 실패 command 뒤 상태를 진단하고 대안을 세우는 드문 trajectory에 충분한 학습 신호를 주기 어렵다는 저자 해석이 타당하다.

6.5 학습 곡선이 보여 주는 안정성과 남은 변동성

Figure 7: Claw RL의 training success, validation success, episode length 변화

Figure 7의 Claw training success는 큰 batch 변동을 보이지만 초반 약 0.2 수준에서 후반 0.35~0.4 부근으로 이동한다. validation success는 step 0의 약 0.37에서 step 80 전후 0.51까지 올라간 뒤 마지막에 소폭 낮아지고, episode length는 약 18~20에서 15~16으로 완만히 줄어든다. 보상 상승과 경로 단축이 함께 나타나지만 100 step과 소수 validation checkpoint만으로 수렴 형태를 확정하기는 어렵다.

Claw 곡선의 moving average 뒤에도 training success 분산이 크다는 점은 task 난이도와 하네스 조합이 이질적임을 반영한다. 같은 batch 안에서도 간단한 검색 task와 긴 multi-service workflow가 섞이고, pod·network 오류로 제외되는 rollout도 있다. 평균 reward만 보고 optimizer 안정성을 판단하기보다 error discard 비율, harness별 sample count, group 내 reward variance를 함께 공개하면 시스템 병목과 정책 학습을 더 잘 분리할 수 있다.

Figure 8: Computer-Use RL의 training success, validation success, episode length 변화

Figure 8에서 Computer-Use training success의 평활선은 약 0.45에서 0.65 이상으로 오르고 마지막에는 0.7대에 닿는다. validation success는 약 0.27에서 0.34로 상승하며, episode length는 13~15 범위에서 큰 추세 변화 없이 흔들린다. Claw처럼 길이가 줄기보다 성공률이 개선되는 동안 행동 수가 유지돼, GUI RL이 더 짧은 경로보다 같은 budget 안에서 정확한 click·type·검증을 학습했을 가능성이 크다.

두 곡선을 비교하면 domain마다 reward 개선 방식이 다르다. 텍스트 도구 사용은 전문 tool로 이동하며 trajectory가 조금 짧아졌고, GUI는 저수준 조작을 생략하기 어려워 episode length가 유지된다. 따라서 ‘효율적인 agent’를 단일 step count로 평가하면 GUI의 필수 행동과 Claw의 불필요한 shell 우회를 같은 비용으로 취급하게 된다. 하네스별 action semantics를 반영한 latency·token·tool cost 측정이 다음 분석에 필요하다.

7. 한계점 및 향후 연구 방향: 보상·비용·재현성의 숨은 계약

7.1 terminal reward와 부분 trajectory 폐기의 한계

첫 번째 한계는 terminal success를 모든 중간 호출에 동일하게 전파하는 credit assignment다. 성공 trajectory 안에도 불필요한 command와 우연한 복구가 섞일 수 있고, 실패 trajectory 안에도 정확한 계획과 유용한 탐색이 들어 있다. $\gamma=1$에서 모든 step이 같은 reward를 받으면 어느 행동이 결과를 바꿨는지 구분하지 못한다. 향후에는 verifier subgoal, state diff, tool result validity를 이용한 process reward와 terminal reward를 함께 쓰는 방법이 필요하다.

인프라 오류 trajectory를 버리는 정책도 안전하지만 정보 손실이 크다. network failure나 browser crash 직전까지 올바르게 수행한 행동은 정책 개선에 쓸 수 있으며, 모델이 비정상적으로 긴 명령이나 반복 요청을 만들어 timeout을 유발했다면 외부 오류보다 정책 실패로 분류해야 할 수 있다. 오류 taxonomy를 단순 discard flag보다 세분화하고, 마지막 유효 checkpoint까지 truncated return을 계산하는 연구가 필요하다. 이를 위해 pod event, proxy trace, environment state를 함께 보존해야 한다.

7.2 합성 task와 verifier 편향

두 번째 한계는 합성 task와 verifier가 같은 모델 생태계에 크게 의존한다는 점이다. Opus 4.6이 task를 제안·수정하고, GPT-5.4가 일부 SFT 성공을 판정하며, Kimi 계열이 teacher trajectory를 만든다. 이 조합은 높은 생산성을 주지만 teacher가 선호하는 도구 경로와 judge가 쉽게 확인하는 completion pattern이 데이터에 반복될 수 있다. 공개된 실제 사용자 task나 독립 human audit 없이 합성 task가 현실 업무 분포를 얼마나 대표하는지 판단하기 어렵다.

Browser-Use의 reward는 GPT-4.1, Online-Mind2Web 평가는 o4-mini, WebVoyager는 GPT-4o judge에 의존한다. LLM judge가 페이지 상태와 task 완료를 잘못 판정하면 RL이 judge shortcut을 학습할 수 있다. website 변화, cookie banner, locale, CAPTCHA가 성공 label을 흔들 가능성도 있다. DOM state assertion과 backend transaction log 같은 hard verifier를 가능한 task에 우선 적용하고, LLM judge task에는 다중 judge agreement와 human sample audit를 보고하는 것이 바람직하다.

7.3 시스템 비용과 공개 재현성

세 번째 한계는 시스템 연결은 가볍지만 전체 실험 자원은 무겁다는 점이다. 8×B200 GPU node, Azure Kubernetes VM pool, Browser-Use Cloud, 여러 frontier teacher와 judge API가 필요하다. 학습 시간은 32~48시간이고 RL task 하나를 합성하는 데 최대 평균 21.3분·6.12달러가 든다. 코드와 data·model을 공개하겠다는 약속은 중요하지만 동일 결과를 재현하려면 cloud quota, API version, website snapshot, harness commit까지 함께 고정해야 한다.

논문이 arXiv에 올라온 시점에는 “will release” 표현이 남아 있어 코드·데이터·모델의 실제 공개 범위와 license를 확인해야 한다. 특히 Codex·OpenClaw·Kimi-Agent 같은 하네스는 빠르게 업데이트되므로 같은 모델 checkpoint라도 prompt와 tool schema가 달라질 수 있다. harness version, SKILL.md, container digest, proxy protocol, evaluator prompt를 artifact로 남겨야 결과가 재현된다. 이 정보가 빠지면 framework 코드는 실행돼도 표의 점수 계보를 다시 만들기 어렵다.

7.4 보안과 권한 경계

실제 하네스를 원격 container에서 돌리는 방식은 보안 경계를 학습 파이프라인의 핵심으로 만든다. 합성 task가 외부 웹과 API를 사용하고 하네스가 shell·file tool을 갖기 때문에 prompt injection, credential leakage, network exfiltration 가능성을 고려해야 한다. 논문은 container isolation과 default no-credential server를 사용하지만 egress policy, secret injection, artifact sanitization을 상세 보안 실험으로 다루지는 않는다. 배포 환경으로 확장하려면 capability 향상과 함께 최소 권한·network allowlist·audit log가 필요하다.

RL은 성공하는 행동을 강화하므로 verifier가 허용한 우회 경로를 빠르게 학습할 수 있다. mock service의 hidden endpoint, 파일 시스템의 정답 artifact, judge prompt 노출 같은 취약점이 있으면 benchmark score는 올라가도 실제 agent 품질은 나빠진다. task 생성 agent와 red-team agent를 분리하고, environment exploitability를 held-out 검사하는 절차가 필요하다. 하네스를 policy의 일부로 학습한다는 발상은 하네스의 취약점도 policy가 활용할 수 있다는 뜻을 함께 가진다.

7.5 운영 배포 전에 추가해야 할 평가 프로토콜

실제 서비스 배포에서는 benchmark success만으로 승인하기 어렵다. 동일 task를 여러 번 실행했을 때의 reliability curve, token·tool·wall-clock 예산을 넘기는 비율, 사람이 개입해야 하는 escalation rate를 함께 봐야 한다. OpenForge의 proxy는 이미 호출과 종료 상태를 수집하므로 이 지표를 계산할 기반이 있다. 학습 reward와 별개로 운영 SLO를 held-out evaluator로 두면 점수 상승이 비용 폭증이나 silent failure로 바뀌는 상황을 찾을 수 있다.

Canary 배포에서는 base, SFT, SFT+RL을 같은 하네스 version과 traffic slice에 놓고 task family별 차이를 측정해야 한다. 평균 성공률이 올라도 finance·email처럼 side effect가 큰 domain에서 오류가 늘면 전체 교체를 중단해야 한다. write action은 read-only replay보다 위험하므로 tool 권한별 평가 cohort를 분리하고, irreversible action 앞에는 사람 승인이나 dry-run verifier를 유지하는 편이 안전하다. RL이 자기 검증을 늘렸다는 결과도 실제 side effect 검증과 동일하다고 가정해서는 안 된다.

행동 분석은 100개 trajectory에서 rule-based 기준을 적용했으므로 표본 확대와 inter-rater audit가 필요하다. self-verification은 파일을 다시 읽었다는 형식만으로 잡힐 수 있지만, 읽은 결과가 의도와 일치하는지 판단하지 않으면 의례적인 read-back도 성공으로 센다. error recovery 역시 오류 뒤 다른 command를 실행했다는 사실과 원인을 진단해 올바른 대안을 택했다는 능력을 구분해야 한다. capability rubric에 evidence span과 최종 state diff를 연결하면 행동 지표의 의미가 더 단단해진다.

학습 후 회귀 검사도 하네스-native 관점으로 구성해야 한다. 특정 tool 사용이 늘면서 일반 대화, 안전 거절, instruction following, 긴 문맥 요약이 손상될 수 있고, RL이 익힌 verbose verification이 latency를 늘릴 수 있다. agent benchmark 외에 기반 모델의 일반 능력과 안전성 benchmark를 함께 돌려 capability gain과 regression을 한 표에 둬야 한다. KL coefficient가 domain마다 크게 다른 설정에서는 이런 회귀의 크기도 다르게 나타날 수 있다.

마지막으로 운영 로그를 다음 학습 round로 되돌릴 때 개인정보와 consent 경계를 분명히 해야 한다. 실제 하네스 prompt에는 이메일, 파일 내용, browser session 정보가 포함될 수 있어 원본 trajectory를 그대로 저장하면 위험하다. proxy 단계에서 field-level redaction, tenant 분리, retention limit, 학습 opt-out을 적용하고 reward에 필요한 evidence만 남겨야 한다. OpenForge RL의 기록 경계는 강력한 학습 자산인 동시에 민감 데이터가 집중되는 감사 지점이다.

8. 내 해석: 약점 1과 후속 제안 1

내가 이 실험에서 가장 걸리는 약점은 프레임워크의 범용성과 reward 계약의 범용성이 충분히 분리되지 않았다는 점이다. 프록시와 Kubernetes 경계는 여러 하네스를 실제로 연결했지만, 성능 향상은 domain별 합성기·verifier·teacher·judge가 잘 맞아떨어진 결과이기도 하다. 같은 OpenForge RL 연결을 유지한 채 reward quality를 낮추거나 verifier distribution을 바꾼 실험이 없어, 점수 상승 중 어느 정도가 실행 substrate의 일반성에서 왔고 어느 정도가 비싼 task curation에서 왔는지 분해하기 어렵다.

내가 확장한다면 먼저 교차 verifier 실험을 붙일 것 같다. 동일 task·동일 하네스 rollout에 대해 원래 verifier, 독립 rule-based verifier, 다른 계열 LLM judge, 소규모 human audit의 네 reward를 만들고, 각각으로 학습한 정책을 공통 held-out environment에서 비교한다. 여기에 proxy trace 기반 process signal을 추가해 terminal-only 모델과 error-recovery 전용 curriculum을 나누면, OpenForge RL이 연결 계층을 넘어 보상 오류에 얼마나 견디는 training substrate인지 확인할 수 있다.

이 제안은 이전에 정리한 OpenThoughts-Agent의 데이터 레시피와도 직접 연결된다. task source와 trajectory filtering을 바꾸는 실험을 OpenForge의 실제 하네스 rollout 위에서 수행하면 ‘어떤 데이터를 만들 것인가’와 ‘어떤 실행계에서 학습할 것인가’를 한 표에서 분해할 수 있다. 특히 unseen harness 전이와 unseen verifier 전이를 동시에 측정하면 모델이 특정 tool grammar를 외운 것인지, 실패를 확인하고 복구하는 더 일반적인 agent 행동을 배운 것인지 구분할 수 있다.

9. 결론: 에이전트 학습의 단위를 모델 호출에서 실행계로 넓히기

OpenForge RL은 복잡한 inference harness를 학습 코드 안에 다시 구현하지 않고도 end-to-end RL에 연결하는 방법을 제안한다. proxy는 하네스의 실제 generation request와 response를 기록하고, Kubernetes orchestrator는 각 rollout을 독립 container에서 실행한다. 종료 reward가 붙은 호출 묶음은 표준 trajectory로 복원돼 veRL·GRPO 같은 기존 backend에 전달된다. 이 경계 설정으로 CLI Claw, desktop GUI, browser-use를 같은 학습 계약 아래 다룬다.

실험에서 OpenForge-Claw SFT+RL은 ClawEval $pass^3$ 31.7, $pass@3$ 55.9, QwenClawBench 33.7, MCPAtlas 28.1을 기록한다. OpenForge-GUI는 OSWorld-Verified 37.7, Online-Mind2Web 63.0, WebVoyager 72.3에 도달한다. 하네스 혼합 학습은 unseen OpenClaw와 Codex로 전이되고, RL은 shell 의존을 줄이며 tool coverage와 self-verification을 높인다. 반면 error recovery는 26.0에 머물고 step efficiency는 낮아져 신뢰성과 비용의 trade-off가 남는다.

이 논문의 가장 실용적인 메시지는 모델 checkpoint만으로 agent를 정의하지 말아야 한다는 것이다. 어떤 하네스가 어떤 도구와 상태를 노출하고, 어떤 sandbox에서 어떤 verifier로 종료를 판정하는지까지 정책 성능을 구성한다. OpenForge RL은 이 실행계를 학습 가능한 대상으로 끌어들였고, 공개 agent 연구가 제품형 하네스를 분석할 수 있는 관찰면을 제공한다. 다음 단계는 reward·오류·보안·비용까지 같은 계보로 기록해 하네스-native 학습의 재현성을 높이는 일이다.

10. 요약 정리: OpenForge RL에서 기억할 열 가지

• 문제 정의: 실제 배포 하네스는 상태적 다중 프로세스 실행을 만들지만 기존 공개 SFT·RL 스택은 이를 직접 표현하기 어려워 학습–배포 불일치가 생긴다.
• 핵심 구조: 프록시가 하네스의 generation request를 inference server로 중계·기록하고 Kubernetes orchestrator가 rollout별 원격 container를 관리한다.
• 학습 단위: 하네스가 편집한 prompt와 모델 response의 쌍을 terminal reward와 묶어 표준 trajectory로 복원한다.
• 데이터 파이프라인: Propose–Prune–Build–Test–Refine 절차로 instruction, verifier, artifact, Dockerfile이 포함된 RL-ready task를 만든다.
• Claw 결과: OpenForge-Claw SFT+RL은 ClawEval $pass^3$ 31.7·$pass@3$ 55.9, QwenClawBench 33.7, MCPAtlas 28.1을 기록한다.
• GUI 결과: OpenForge-GUI SFT+RL은 OSWorld-Verified 37.7, Online-Mind2Web 63.0, WebVoyager 72.3에 도달한다.
• 하네스 효과: custom tool을 직접 노출하는 ZeroClaw와 ReAct가 복잡한 OpenClaw보다 학습하기 쉬웠고, 세 하네스 혼합 학습은 unseen harness 전이를 높였다.
• 행동 변화: RL 뒤 shell 사용은 22.6%에서 13.9%로 줄고 self-verification과 tool coverage는 각각 59.9와 80.9로 상승했다.
• 남은 병목: error recovery는 26.0으로 낮고 step efficiency는 84.5에서 79.2로 떨어져 추가 확인과 실행 비용 사이의 trade-off가 남는다.
• 해석 범위: 프레임워크 연결의 범용성과 합성 task·teacher·verifier 품질의 효과를 분리하고, 보상 오류·보안·cloud 비용까지 재현 가능한 artifact로 남겨야 한다.