AI가 스스로 하네스를 고쳐 토큰을 줄이는 자동 연구 루프, SoL-Pi

무엇인가

코딩 에이전트가 감독된 코드 완성에서 무인 24시간 탐색으로 옮겨가면서, 에이전트의 작업은 단일 예측이 아니라 추론·도구 사용·피드백이 이어지는 긴 궤적으로 바뀌었다. 이 논문은 그 결과 토큰 효율이 재귀적 자기개선(RSI)을 확장하는 데 일차적인 시스템 문제가 된다고 본다. 기존 효율 연구는 어텐션 커널과 서빙 인프라, 양자화 같은 모델 압축, 더 저렴한 모델 사용처럼 토큰당 비용을 낮추는 쪽에 집중했지만, 저자들은 모델과 환경 사이를 매개하는 하네스 자체를 최적화하는 직교적 방향을 택한다. 하네스 최적화가 어려운 이유는 도구 사용, 컨텍스트 관리, 검증, 위임, 복구, 종료가 강하게 결합돼 있어 국소적으로 이득인 변경이 하위 단계 실패를 유발하거나 토큰 비용을 실행 후반으로 옮길 수 있기 때문이다. 실제 개발에서는 사람이 긴 실행 트레이스를 들여다보고 반복되는 실패 모드를 찾아 코드로 옮겨야 하는데, 이 과정은 값비싸고 과제·환경 전반으로 확장하기 어렵다.

어떻게 동작하나

제안 방법은 RSI에서 착안한 자동 연구 루프다. 연구 AI가 베이스 하네스를 돌리는 별도 에이전트의 실행 트레이스를 관찰하고 후보 변경을 제안한 뒤 준비된 연구 환경에서 시험하며, 능력 검사와 효율 검사가 후보의 채택 여부를 정하고 개발 결과가 다음 반복을 이끈다. 설계 원칙은 세 가지다. 폭과 깊이(폭은 가설 커버리지를 넓히고 깊이는 유망 후보를 반복 구현·리뷰·경화한다), 독립 검증(held-out 증거는 후보가 동결된 뒤에만 평가되고 검색으로 되돌아가지 않아 검증 실패를 과제 특화 해법으로 패치하는 것을 막는다), 확장 가능한 오케스트레이션(격리된 일회용 계보가 후보 간 실패를 결합시키지 않는다). 저자들은 약 150개 제안 방향, 약 500개 실행 환경, 3,000회 이상의 런, 60,000회 이상의 에이전트-환경 상호작용으로 이 루프를 확장했다. 검색은 넓게에서 깊게로 가는 두 단계로 구성된다. 바깥 단계는 152개 제안 방향을 컨텍스트, 진행, 도구, 위임, 프롬프트·정책, 개선·평가의 여섯 제안 패밀리로 탐색하고, Oracle Analysis가 기존 개발 트레이스에서 회피 가능한 작업을 식별한다. 안쪽 단계는 선택된 방향을 독립적으로 개발하며, Ralph Loop에 기반한 반복 구현 루프를 덧붙인다. 구현자가 명시적 완료 기준을 만족하도록 후보를 다듬고 독립 리뷰어가 평가 전에 검사하며, 리뷰 실패는 수정을 촉발한다. 각 반복은 여러 탐색 궤적을 낼 수 있고 독립 분석기들이 반복 행동, 컨텍스트 증가, 큰 관찰, 희소한 진단 신호를 각각 살핀 뒤 reducer가 이를 후보 수준 요약으로 통합해 다음 제안을 안내한다. 채택 규칙은 실험 전에 능력 지표, 허용 오차, 효율 지표를 고정하고 최적화 에이전트의 통제에서 엄격히 격리한다. 두 개의 순차 게이트를 적용하는데, 모든 능력 지표가 사전 선언된 허용 오차 안에 있어야 하고 최소 하나의 선언된 효율 지표를 개선해야 한다. 통과한 후보 중에서는 선언된 지표에서 비지배(nondominated) 결과를 유지한다. 검색 환경은 535개 실행 환경으로, GitHub 이슈-풀리퀘스트 쌍에서 파생된 495개 저장소 과제와 실행 가능한 성공 검증기를 가진 40개 합성 과제로 이뤄진다. 저장소 환경은 패치 전에는 테스트가 실패하고 패치 후에는 통과하는 것만 남기며, 풀리퀘스트와 회귀 테스트는 에이전트에게 숨긴다.

무엇과 다른가

검색이 남긴 네 가지 재사용 가능한 메커니즘은 각각 행동 실행, 컨텍스트 관리, 관찰 저장, 위임 읽기를 겨냥한다. Action Fusion은 Pi가 파일을 편집한 뒤 테스트·빌드·실행 명령을 따로 내는 패턴을 하나의 도구 요청으로 합쳐 두 결과를 단일 관찰로 반환함으로써 중간 모델 왕복을 제거한다. 변경 결과를 검사해야 하는 명령은 분리해 둔다. Online Context Compact는 update_plan으로 유지되는 계획의 단계 완료를 압축 시점 재고의 기준으로 삼는다. 완료 경계마다 완료된 단계 사이에서 관측된 요청 수와 남은 단계 수로 남은 모델 요청을 추정하고, 관측된 증가율로 현재 컨텍스트 윈도를 채울 요청 수를 상한으로 둔다. 비용 게이트는 예상 입력 절감과 프롬프트 캐시 재작성의 추정 추가 비용을 비교하며, 이후 압축은 회수되지 않은 재작성 비용까지 반영해 더 큰 절감 마진을 요구한다. 게이트를 통과하거나 컨텍스트 사용량이 윈도 한계에 근접했고 압축이 컨텍스트를 줄일 수 있을 때 Pi의 네이티브 압축을 호출한다. ObservationPack은 큰 도구 출력이 나중 요청에서 반복 전송되는 문제를 다룬다. 임계값 10 KiB를 넘는 결과를 로컬에 보관하고 다음 두 번의 프로바이더 요청에는 전문을 보내며, 세 번째 요청부터는 안정적인 핸들, 원래 크기, 완전한 머리·꼬리 줄의 짧은 발췌로 대체한다. 에이전트는 핸들로 정확한 페이지를 필요할 때 검색할 수 있고 더 작은 결과는 그대로 둔다. Evidence-Preserving Reducer는 미리 정의된 명령 집합에서 나온 4 KiB 이상의 빌드·테스트 로그를 압축하되 파일 읽기와 검색 결과는 우회시킨다. 정확한 출력을 보관하고 저비용 모델인 GPT-5.6 Luna(high)에게 핵심 증거를 간결한 영수증으로 추출하게 하며, 결정적 검증기가 영수증의 스키마, 소스 해시, 종료 상태, 정확한 인용, 크기를 검사한다. 검증 실패, 자격 증명 의심, 크기 절감 없음이면 원본 로그로 폴백한다. 이 reducer는 ObservationPack이 모델 컨텍스트를 투영하기 전에 도구 결과를 처리하고, ObservationPack은 영수증 마커를 인식해 해당 결과를 건너뛰어 검증된 증거를 보존한다. 보조 모델은 증거 추출만 담당하고 진단과 행동 선택은 메인 에이전트가 유지한다.

어떻게 쓰나

평가는 EdgeBench의 공개 51개 과제(전체 134개 중)를 사용하되 11개는 동결 후보의 단방향 수용에, 나머지 40개는 일반화 최종 평가에 예약했다. 두 운용점을 보고한다. SoL-Pi [Efficiency]는 네 메커니즘 전체 스택으로 1.10B 토큰을 써서 Pi보다 49.0% 적었고 Pi 평균 점수의 93.7%를 유지했으며(42.0 대 44.8) 토큰 비용은 33.2% 낮았다. SoL-Pi [Performance]는 백엔드별로 평균 점수가 가장 높은 단일 메커니즘 구성으로, GPT-5.6 Sol에서는 ObservationPack에 해당하며 평균 점수를 44.8에서 47.2로 5.3% 올리면서 토큰 트래픽을 6.1% 줄이고 토큰 효율을 9.8% 개선했다. 전이 실험에서는 GPT-5.6 Sol로 개발한 SoL-Pi를 추가 검색이나 적응 없이 Opus 5에 적용해 Pi 평균 점수의 94.3%를 유지하면서 토큰 트래픽을 44.7%, API 비용을 33.5% 줄였다.

전제와 한계

다른 벤치마크에서도 비용 우위가 나타난다. Terminal-Bench 4의 CPU 전용 63개 과제에서 Codex와 Pi가 각각 18개를 해결한 반면 SoL-Pi는 15개를 해결했지만, Pi 대비 총 모델 비용을 26.3% 줄였고(211.12달러 대 286.45달러) 해결 과제당 비용도 11.6% 낮췄다(14.07달러 대 15.91달러). IMO 2026에서는 GPT-5.6 Sol(xhigh)로 Lean 4 형식화·검증을 요구했을 때 6문제 중 3개를 통과하며 총 62.69달러, 통과 문제당 20.90달러로 Codex의 22.89달러, Pi의 25.32달러보다 낮았다. 커널 최적화 스웜 실험(2시간 런, 사이클 단위 측정)에서는 단일 Codex 에이전트가 1,333 사이클에 39.20달러, Codex 코디네이터와 Pi 워커 20개가 1,366 사이클에 82.12달러, Codex 코디네이터와 SoL-Pi 워커 20개가 1,127 사이클에 60.11달러를 기록해 SoL-Pi 스웜이 Pi 기준 스웜보다 API 비용을 26.8% 줄였다. 시작점은 147,734 사이클이 필요했다. SoL-Pi 스웜과 단일 에이전트는 8개 속도 임계값을 모두 통과했지만 Pi 기준 스웜은 7개만 통과해 1,363 사이클 미만이라는 마지막 임계값을 놓쳤다. 메커니즘별 기여를 보는 add-one 평가에서는 모든 구성 요소가 두 백엔드에서 총 토큰 수를 줄였고, GPT-5.6 Sol에서는 ObservationPack이, Opus 5에서는 Action Fusion이 가장 높은 평균 점수를 냈으며 완전 스택이 두 백엔드 블록 모두에서 최저 토큰 수와 비용을 기록했다. 다만 메커니즘 활성화는 Opus 5에서 트리거율과 트리거 강도가 모두 낮았는데, 하네스가 GPT-5.6 Sol 궤적으로만 최적화된 결과로 보인다. 캐시 관련해서는 GPT-5.6 Sol에서 완전 스택이 캐시 읽기 트래픽을 2.1326B에서 1.0605B 토큰으로 줄이는 대신 캐시 쓰기를 0.0141B에서 0.0316B로 늘렸지만, 총 모델 비용은 1,339달러에서 894달러로 떨어졌다. Action Fusion의 개발 계보는 27회 반복에 걸쳐 oracle 분석, 베이스라인 구축, 프롬프트·도구 스키마 최적화, 최종 held-out 검증의 네 단계를 거쳤고, oracle 분석은 완전 트리거 시 11.5% 토큰 절감을 추정했으며 프롬프트만으로 트리거하는 방식이 불안정하자 도구 스키마를 확장하고 트리거율을 중간 수용 지표로 도입했다.

실무자에게 이 논문이 주는 실질적 시사점은 비용 병목을 모델 교체가 아니라 하네스 설계에서 찾으라는 것이다. 장시간 자율 실행되는 코딩 에이전트, 여러 워커가 도는 스웜, 빌드·테스트 로그가 반복적으로 컨텍스트에 실리는 워크플로라면 여기서 제시한 네 메커니즘(편집과 후속 명령의 결합, 계획 단계 경계에서의 압축 판단, 큰 관찰의 핸들 치환, 로그 증거 추출과 검증)은 모델을 바꾸지 않고도 적용 가능한 패턴이다. 도입 시 확인할 점도 분명하다. SoL-Pi [Efficiency]는 점수의 93.7%만 유지하는 대가로 비용을 크게 줄이는 운용점이므로 성능과 비용 중 어느 쪽을 우선할지 먼저 정해야 한다. 메커니즘 트리거율이 백엔드에 따라 달라지므로 자사 모델 조합에서 활성화 패턴을 측정해야 하고, 컨텍스트 압축은 캐시 재사용을 깨뜨릴 수 있으므로 캐시 적중률이 아니라 과제 전체 비용으로 판단해야 한다. 또한 증거 추출이 실패하거나 자격 증명이 의심될 때 원본으로 폴백하는 경로가 실제로 동작하는지 확인해야 한다. 마지막으로 이 논문의 핵심 방법론적 교훈은 검색에 쓰는 과제와 최종 평가 과제를 분리하라는 것이다. 자체적으로 하네스 개선 루프를 돌린다면 평가 과제를 검색 피드백에 노출시키는 순간 과적합 위험이 생긴다.

저자들이 밝힌 한계는 네 갈래다. 첫째, RSI로 발견한 하네스 아티팩트의 일반화는 여전히 고질적 난제이며 이 결과는 자동 연구 루프 확장이 이를 완화할 수 있다는 예비적 증거에 그친다. 저자들은 하네스를 많은 과제에 노출하고 그 궤적으로 갱신하는 과정을 모델 사전학습에 비유해 하네스 사전학습(pretraining the harness)이라는 장기 방향을 가설로 제시한다. 둘째, 현재 하네스는 단일 LLM이 생성한 궤적으로만 갱신됐고 다른 백엔드에서는 메커니즘이 덜 자주, 덜 강하게 트리거되며, 다중 백엔드 학습·검증이 견고성을 높일 수 있다는 방향을 남긴다. 셋째, 더 효율적인 하네스가 그 후속 하네스를 만드는 자동 연구 비용을 낮춘다는 재귀적 효율 개선은 이 연구가 입증한 복리 효과가 아니라 장기 비전이라고 명시한다. 넷째, 완전한 자동 연구 루프 실행은 계산 비용이 커서 고정 예산 아래에서 검색 폭과 깊이를 통제 비교하기 어렵고 스케일링 법칙은 향후 과제로 남긴다. 논문은 또한 검색 규모 수치(약 150개 방향, 약 500개 환경, 3,000회 이상 런)가 검색의 범위를 설명할 뿐 스케일링 법칙을 확립하지 않는다고 밝히고, 각 구성의 자체 트리거 과제 부분집합에서의 비교는 메커니즘 간 상호작용 효과를 분리하지 못한다고 인정한다.