평가 벤치마크와 분리된 데이터로 에이전트 하네스를 다섯 모듈로 나눠 진화시키는 ModularRSI

무엇인가

CLI 에이전트의 성능은 기반 모델만으로 결정되지 않는다. 실행 흐름, 도구 상호작용, 컨텍스트 관리, 환경 피드백을 관장하는 하네스가 성능을 좌우하며, 최근에는 실행 경험으로부터 하네스 자체를 개선하는 재귀적 자기개선(RSI) 연구가 나왔다. 이 논문은 그런 하네스 RSI가 일반화되기 어려운 이유를 세 가지로 정리한다. 첫째는 데이터 수준 문제로, 평가 벤치마크나 그 부분집합 위에서 하네스를 진화시키면 재사용 가능한 개선과 벤치마크 특화 적응을 구분할 수 없다. 둘째는 궤적 수준 모호성으로, 단일 궤적에서 뽑은 업데이트는 체계적인 하네스 결함과 인스턴스 고유의 추론·해법 세부를 뒤섞어 전이가 나쁜 수정을 만든다. 셋째는 메커니즘 수준의 크레딧 할당 문제로, 모놀리식 하네스 안에서 반복되는 행동 결함이 어느 구성요소 책임인지 찾기 어렵고, 하네스 전체를 최적화하면 무관한 메커니즘이 얽혀 귀속과 검증이 어려워진다.

어떻게 동작하나

ModularRSI는 이 세 문제를 대조(contrastive)와 모듈화로 푼다. 전체 절차는 대조적 궤적 샘플링·분석, 모듈별 하네스 진화, 검증 게이트의 세 단계다. 먼저 하네스의 행동 메커니즘을 다섯 기능 모듈로 분해한다. Agent Loop는 추론-행동-관찰 반복 과정과 실행 흐름, 상호작용 제어, 복구 행동을 맡고, Tool Use는 외부 도구의 선택·호출·검증을, Observation Management는 환경 피드백에서 과제 관련 정보를 보존하며 잡음을 걸러내거나 압축하는 일을, Context Management는 실행 단계 전반의 상호작용 이력을 유지·조직하는 일을, Task Completion Detection은 과제 완료 여부와 추가 상호작용 필요성을 판단하는 일을 담당한다. 샌드박스 초기화나 병렬 실행, LLM 통신처럼 시스템 인프라에 속하는 구성요소는 진화 대상에서 제외하고, 에이전트-환경 상호작용을 직접 매개하는 메커니즘만 진화시킨다. 출발점은 Harbor의 Terminus-2 하네스다.

무엇과 다른가

대조적 분석은 같은 과제를 K번 롤아웃해 얻은 이진 보상으로 과제를 세 그룹으로 나누는 데서 시작한다. 전부 성공하면 Positive, 일부만 성공하면 Contrastive, 전부 실패하면 Negative다. 별도의 Trajectory Memory에 과제별 과거 궤적과 보상을 에폭에 걸쳐 저장해, 현재 롤아웃만으로 대조 증거가 부족할 때 보강한다. Contrastive 그룹에서는 같은 과제의 성공 궤적과 실패 궤적을 짝지어 비교해 결과 차이를 만든 함수 수준 요인을 찾는다. Negative 그룹에서는 먼저 메모리에서 같은 과제의 과거 성공 궤적을 조회해 현재 실패 궤적과 대조하고, 그런 궤적이 없으면 반복 루프, 잘못된 도구 사용, 비효율적 복구, 조기 종료처럼 명백한 실행 결함을 단면 진단한다. Positive 그룹에서는 중복 행동, 반복 탐색, 불필요한 도구 호출 같은 실행 품질·효율 개선 기회를 본다. 배치의 모든 과제를 분석한 뒤 진단 결과는 담당 모듈, 지지 궤적 증거, 수정 찬반 근거, 제안 변경을 담은 JSON 구조화 findings로 통합된다.

어떻게 쓰나

모듈별 수정 단계에서는 같은 함수를 겨냥한 의미적으로 유사한 진단을 후보로 묶고, 서로 다른 과제가 얼마나 지지 증거를 제공했는지로 투표 수를 매겨 여러 과제가 지지하는 후보를 우선한다. 함수별 Evolution History에 이전 코드 변경과 각 개정이 도입한 기능을 기록해, 중복되거나 모순되는 수정과 에폭 간 진화 진동을 줄인다. 수정은 반드시 검증 게이트를 통과해야 유지된다. Program Check는 AST 검증, 임포트 검사, 프로토콜 준수, discovery-contract 검증, 정적 self-attribute 감사를 수행하고 실패하면 기록된 diff로 롤백한다. Diff Review는 변경이 과제 특화 해법이나 일반화되기 어려운 휴리스틱·조건을 인코딩했는지 검토해 그런 수정을 거부·롤백한다. Execution Validation은 배치에서 무작위로 두 과제를 뽑아 수정된 하네스로 실행해 런타임 오류나 프로토콜 위반이 나오면 롤백한다. 다섯 모듈이 독립적으로 진화한 뒤에는 Cross-Module Integration 에폭을 한 번 더 돌려 통합 하네스를 만들고, 중복 메커니즘 제거, 모듈 책임 명확화, 조정 로직 조정으로 충돌을 해소한다. 함수 라이브러리 관리를 위해 Function Merge가 유사 기능을 병합하고, Task-Aware Function Composer가 과제 설명과 각 함수 설명을 보고 과제 관련 함수 부분집합만 활성화한다.

전제와 한계

진화 데이터는 평가 벤치마크와 분리해서 직접 구축했다. TerminalBench와 SWE-Bench 계열에서 고수준 도메인 라벨만 추출해 검색 가이드로 쓰고, GitHub, Hugging Face, Kaggle, Linux 커널 문서 같은 외부 소스에서 자료를 모아 Harbor 형식의 새 실행 과제를 만든다. 벤치마크 인스턴스나 과제 특화 정보는 구축에 쓰지 않는다. 품질 관리는 LLM 기반 필터링으로 환경 완전성, 실용성·비자명성, 평가자 유효성을 평가하고, reference solution.sh가 모든 테스트를 통과하면서 no-op 제출은 보상을 받지 못하는지 실행 검증하며, 수동 검토와 의미 유사도 스크리닝으로 벤치마크와 겹치는 인스턴스를 제거하는 다단계 파이프라인이다. 그 결과 2,000개의 벤치마크 분리 진화 인스턴스가 만들어졌고, TB 관련과 SWE 관련 분포가 비교적 균형을 이룬다.

실험은 TerminalBench 2.0(장기 터미널 과제 89개)과 SWE-Bench Verified(실제 저장소 기반 소프트웨어 엔지니어링 과제 500개)에서 Harbor 프레임워크로 수행했다. 지표는 평균 성공률 Acc, 3회 시도 중 하나라도 성공하면 해결로 세는 Pass@3, 롤아웃당 평균 상호작용 스텝 수 StepNum, 3회 모두 성공해야 해결로 세는 Pass^3다. 진화는 3 에폭, 2,000개 중 TB 관련 120개와 SWE 관련 120개를 사용했고, DeepSeek-V4-Flash-Preview와 DeepSeek-V4-Flash-0731을 주 모델로 TPM 200만, 배치 크기 10으로 돌렸다. in-domain 설정에서 Acc는 TerminalBench 2.0에서 47.57에서 52.43으로, SWE-Bench Verified에서 73.40에서 76.45로 올랐다. 도메인 전이도 나타나 TB 데이터로 진화한 하네스가 SWE-Bench Verified를 75.80까지, SWE 데이터로 진화한 하네스가 TerminalBench 2.0을 49.40까지 끌어올렸다. TerminalBench 2.0의 Pass^3는 30.34에서 35.96으로 오르며 반복 시행에서의 실행 신뢰성이 개선됐음을 보였다. 모델 전이 실험에서는 TB 진화 세트로 만든 하네스를 고정해 다른 기반 모델에 적용했을 때 GLM-5.2가 59.55에서 61.80으로, MiniMax-2.5가 41.57에서 44.94로 개선됐다.

모듈화의 효과도 통제 실험으로 확인했다. 모듈을 독립 진화시킨 뒤 통합하는 방식이 Acc 47.57에서 52.43으로 가장 좋았고, joint 진화와 비모듈 진화는 오히려 베이스라인 아래로 떨어졌다. 통합 전 단일 모듈 변형들은 모두 베이스라인을 웃돌았는데, Agent Loop가 단일 모듈 정확도 이득이 가장 컸고 Observation Management는 평균 실행 스텝 수를 크게 줄였다. 기존 RSI 방법과의 비교에서는 AHE와 Meta-Harness를 같은 Harbor 프로토콜, 같은 120개 진화 인스턴스, 총 진화 라운드 수를 맞춘 16 에폭, 동일 모델과 TPM 제한, 웹 검색 비활성 조건으로 재현했는데, 둘 다 Terminus-2 베이스라인 대비 약 1%포인트 변화에 그친 반면 ModularRSI는 5%포인트 이상 개선됐다. 대조 쌍 비율은 에폭이 진행될수록 줄어들었고, 진화 데이터 난이도 실험에서는 Medium-centered 분포가 SWE-Bench Verified에서 76.45%로 Hard & Easy 분포의 74.25%를 2.20%포인트 앞섰다.

저자들이 밝힌 한계는 두 가지다. 대조적 궤적 분석의 기여를 분리하는 전용 ablation을 수행하지 않았고, 궤적 분석과 사례 연구로만 간접적으로 뒷받침한다. 또한 계산 비용 때문에 주요 진화 실험이 2,000개 큐레이션 인스턴스의 일부만 사용했으며, 더 넓은 비교와 대규모 연구는 향후 과제로 남긴다. 실무자 관점에서 이 논문이 쓸모 있는 지점은 하네스를 하나의 덩어리로 프롬프트 엔지니어링하는 대신 다섯 기능 경계로 나눠 국소 수정하고, 과제별 투표와 검증 게이트로 과적합 패치를 걸러내는 워크플로를 제시한다는 것이다. 도입을 검토한다면 진화 데이터가 실제 평가셋과 분리돼 있는지, 모듈 경계가 자신의 하네스 구조와 맞는지, Task-Aware Function Composition이 만드는 활성 하네스가 재현 가능한지, 그리고 함수 라이브러리가 커질 때 Function Merge가 학습된 기능을 보존하는지를 확인해야 한다. 코드와 데이터셋은 공개 저장소에 있다.