SoL-Pi: 모델을 건드리지 않고 하니스만 자동 탐색해 코딩 에이전트 토큰을 최대 49.0% 줄였다

엔비디아 연구진이 코딩 에이전트의 하니스(harness)를 자동 탐색으로 개선해 토큰 사용량을 44.7~49.0% 줄인 SoL-Pi를 2026년 9월 17일 arXiv 2609.20519로 공개했다. 모델 가중치는 전혀 건드리지 않고 에이전트를 둘러싼 실행 계층만 바꿨으며, 51개 과제로 구성된 EdgeBench 평가에서 기준 하니스 Pi와 비슷한 점수를 유지한 채 API 비용을 약 3분의 1 줄였다. 논문이 제시한 절감액은 코덱스(Codex)와 클로드 코드(Claude Code) 기본 하니스 대비 시간당 8.75~13.50달러다. ASAP은 이 논문이 재귀적 자기개선을 모델이 아니라 하니스 층에 적용했다는 점을 중심으로 정리한다.

개선 대상이 모델이 아니라 하니스다

SoL-Pi가 손대는 것은 모델이 아니라 하니스다. 하니스는 모델과 실행 환경 사이에서 도구 호출을 중개하고 컨텍스트를 관리하며 관찰 결과를 되돌려주는 실행 계층이고, 논문은 재귀적 자기개선(RSI)의 아이디어를 이 층에 적용했다. 연구진의 기준선이자 개선 출발점은 Pi라는 기존 코딩 에이전트 하니스이며, SoL-Pi는 그 위에 선별된 기법 네 가지를 얹은 결과물이다.

논문이 문제로 잡은 것은 정확도가 아니라 토큰이다. 초록의 표현대로 코딩 에이전트가 감독받는 코드 완성에서 무인 상태의 연속 탐색으로 옮겨가면서, 작업은 고립된 예측 하나가 아니라 추론과 도구 사용과 피드백이 길게 이어지는 궤적이 됐다. 궤적이 길어질수록 같은 결과를 내는 데 드는 토큰이 비용의 지배적 항목이 되고, 토큰 효율이 재귀적 자기개선을 확장하는 조건이 된다는 것이 저자들의 출발점이다.

이 문제 설정 자체가 최근 하니스 연구의 흐름에서 한 칸 옮겨간 지점이다. 하니스를 학습 대상으로 본 선행 연구인 EvoHarness-RL은 강화학습으로 하니스 정책을 학습시켜 성공률을 끌어올리는 데 초점을 뒀다. SoL-Pi는 점수를 올리는 대신 같은 점수를 더 싸게 내는 쪽을 목표로 잡았고, 학습 대신 자동 탐색으로 기법을 발굴했다. 둘은 경쟁 관계가 아니라 하니스라는 같은 층을 서로 다른 목적 함수로 공략한 사례다.

152개 방향을 3,000회 넘게 돌려 네 가지만 남겼다

탐색 규모가 이 논문의 실질적 기여다. 연구진은 컨텍스트, 도구, 위임, 프롬프트와 정책, 개선과 평가라는 계열에 걸쳐 약 150개의 기법 방향을 제안했고, 깃허브 이슈와 풀 리퀘스트 쌍에서 만든 495개 환경과 검증기 기반 합성 과제 40개를 합쳐 약 500개의 실행 환경을 마련했다. 여기서 3,000회가 넘는 실행과 60,000회가 넘는 에이전트와 환경의 상호작용이 이뤄졌다.

구조는 두 단계 깔때기다. 바깥 탐색이 152개 방향을 넓게 훑고, 안쪽에서는 각 방향이 독립된 개발 주기를 돈다. 안쪽 주기는 랄프 루프(Ralph Loop)를 따르며, 구현자가 명시된 완료 기준을 채우도록 후보를 다듬으면 독립된 검토자가 이를 점검한 뒤에야 평가로 넘어가고 검토 실패는 수정으로 되돌아간다. 논문이 명시하는 설계 원칙은 개발 단계의 피드백이 최종 평가에 절대 닿지 않게 한 분리다. EdgeBench 134개 과제 가운데 공개된 51개를 쓰되, 11개만 개발 중 일방향 수용 시험에 열어두고 40개는 최종 미공개 평가용으로 남겼다.

이 깔때기에서 살아남은 기법은 네 개다. 액션 퓨전(Action Fusion)은 변경 작업과 그 후속 명령을 한 번의 요청으로 합친다. 온라인 컨텍스트 압축(Online Context Compact)은 과제 완료 경계에서 컨텍스트를 압축할지 판단한다. 옵저베이션팩(ObservationPack)은 큰 출력을 로컬에 보관하고 첫 요청 이후에는 전체 결과 대신 안정적인 핸들만 보낸다. 증거 보존 축약기(Evidence-Preserving Reducer)는 더 저렴한 모델로 빌드와 테스트 로그에서 핵심 증거만 뽑고 검증 실패 시 원본으로 되돌아간다.

네 기법의 공통점을 보면 탐색이 무엇을 발견했는지가 드러난다. 넷 모두 모델에게 더 잘 생각하라고 요구하지 않고, 모델의 눈앞에 놓이는 텍스트의 양을 줄인다. 왕복 횟수를 줄이거나(액션 퓨전), 누적분을 잘라내거나(온라인 컨텍스트 압축), 대용량 출력을 참조로 대체하거나(옵저베이션팩), 저가 모델에 전처리를 위임한다(증거 보존 축약기). 152개 방향 가운데 프롬프트와 정책 계열이 최종 네 개에 들지 못했다는 사실은, 이 규모의 탐색에서 실제로 돈을 아낀 것은 지시문의 개선이 아니라 입출력 배관의 개선이었음을 보여준다.

두 모델의 실측치는 같은 방향으로 움직였다

EdgeBench 51개 과제에서 나온 수치는 두 모델 모두에서 같은 형태를 보였다. GPT-5.6 Sol 기준으로 Pi는 토큰 21억 5,380만 개와 API 비용 1,339달러로 평균 44.833점을 냈고, SoL-Pi의 효율 구성은 토큰 10억 9,900만 개와 비용 894달러로 42.003점을 냈다. 토큰은 49.0%, 비용은 33.2% 줄었고 점수는 Pi의 93.7% 수준을 유지했다. 점수당 비용으로 환산하면 0.5855달러에서 0.4174달러로 28.7% 낮아진다.

Opus 5에서도 방향은 같다. Pi가 토큰 23억 6,970만 개와 비용 1,741달러로 44.756점을 냈고, SoL-Pi 효율 구성은 토큰 13억 101만 개와 비용 1,158달러로 42.224점을 냈다. 토큰 44.7%, 비용 33.5% 감소에 점수는 Pi의 94.3%다. 논문이 초록에 적은 44.7~49.0%라는 범위는 이 두 모델의 양 끝값이다.

주목할 구성이 하나 더 있다. GPT-5.6 Sol에서 SoL-Pi의 성능 구성은 토큰 20억 2,240만 개와 비용 1,271달러로 47.208점을 기록해, Pi보다 점수는 2.375점 높고 비용은 68달러 낮았다. 같은 기법 묶음을 절감 쪽으로 조이면 점수를 2.8점 내주고 비용을 3분의 1 줄이며, 성능 쪽으로 풀면 비용을 소폭 줄이면서 점수를 올린다는 뜻이다. 토큰 효율 개선이 성능과의 교환만은 아니라는 근거가 여기에 있다.

숫자를 읽을 때 신중해야 할 대목도 분명하다. 첫째, 시간당 8.75~13.50달러라는 절감액은 논문의 표현대로 추정치이며 에이전트가 쉬지 않고 돈다는 가정 위에 있다. 이 가정이 성립하는 것은 무인 야간 작업처럼 가동률이 100%에 가까운 운용이고, 사람이 사이에 끼는 일반적인 개발 흐름에서는 절감액이 그대로 재현되지 않는다. 둘째, 점수 44.833과 42.003의 차이가 실무에서 무엇을 뜻하는지는 EdgeBench 채점 방식에 달려 있으며, 3% 남짓의 점수 하락이 어떤 과제군에서 발생했는지는 평균값만으로 알 수 없다. 셋째, Pi와의 비교는 같은 계열 하니스 안에서의 개선이고, 코덱스와 클로드 코드 기본 하니스 대비 수치는 네이티브 구성과의 간접 비교다.

한국 개발 조직에 이 결과가 닿는 지점

이 논문의 실무적 함의는 비용 구조의 통제권이 어디 있는지에 관한 것이다. 국내 개발 조직 대다수는 모델을 학습시키지 않고 API로 코딩 에이전트를 돌리며, 이 조건에서 비용을 줄이는 선택지는 보통 더 싼 모델로 내려가거나 사용량을 제한하는 두 가지로 좁혀진다. SoL-Pi가 보여준 세 번째 선택지는 같은 모델을 그대로 쓰면서 모델에게 보내는 텍스트를 줄이는 것이고, 이 층은 API 사용자도 직접 손댈 수 있는 영역이다.

네 기법 가운데 옵저베이션팩과 증거 보존 축약기는 자체 구현 난도가 낮은 축에 속한다. 빌드 로그와 테스트 출력과 대용량 파일 덤프를 그대로 컨텍스트에 밀어 넣는 대신 로컬에 저장하고 참조만 넘기는 방식, 그리고 긴 로그를 저가 모델로 먼저 추려 넘기되 추린 결과가 부실하면 원본으로 되돌아가는 안전장치는 사내 에이전트 배관에 그대로 옮길 수 있는 형태다. 반대로 액션 퓨전은 도구 호출 규약을 바꾸는 일이라 기존 워크플로와의 충돌을 먼저 확인해야 한다.

한 가지 짚어둘 것은 이 논문이 제시한 절대 금액의 해석이다. EdgeBench 한 번을 도는 데 1,000달러 단위의 API 비용이 들었다는 사실 자체가, 무인 코딩 에이전트의 운용 비용이 이미 개인이 감당하는 수준을 넘었음을 보여준다. 토큰 효율 연구가 지금 활발해진 이유는 절약이 미덕이어서가 아니라, 에이전트를 24시간 돌리는 방식이 비용 때문에 막히기 시작했기 때문이다. 국내 조직이 야간 자동화나 상시 리팩터링 에이전트를 검토한다면, 먼저 계산해야 할 것은 성능 벤치마크가 아니라 가동 시간당 토큰 소모량이다.

저자들이 직접 적은 네 가지 한계

논문은 한계를 네 가지로 정리했고, 그 내용이 결과의 적용 범위를 좁힌다. 첫째는 하니스의 사전학습 문제다. 지속적인 이득을 얻으려면 지금보다 더 다양한 환경으로 탐색을 넓혀야 한다는 것이 저자들의 진단이다. 둘째는 다중 백엔드 학습이다. 현재 하니스는 GPT-5.6 Sol에서만 최적화됐고 Opus 5에서는 기법의 활성화 비율이 더 낮게 관측됐다. Opus 5로의 이전이 성립했다는 것과 Opus 5에서 최적이라는 것은 다른 이야기다.

셋째는 재귀적 효율 개선이 아직 이론에 머물러 있다는 점이다. 효율 향상이 다음 탐색 비용을 실제로 줄이는지는 검증되지 않았고, 재귀적 자기개선이라는 틀이 실제로 닫힌 고리를 이루려면 이 대목이 입증돼야 한다. 넷째는 탐색 비용이다. 계산 비용이 높아 고정 예산 아래에서 탐색의 넓이와 깊이를 통제된 방식으로 비교하지 못했다.

네 번째 한계에 한 가지를 덧붙일 필요가 있다. 논문은 3,000회 이상의 실행과 60,000회 이상의 상호작용을 밝혔지만, 이 탐색 자체에 든 비용은 공개하지 않았다. 시간당 8.75~13.50달러를 아끼는 하니스를 찾기 위해 얼마를 썼는지가 없으면, 이 방법론을 다른 조직이 자기 환경에서 재현할 가치가 있는지 판단할 수 없다. 발견된 네 기법을 그대로 가져다 쓰는 것과 같은 자동 탐색을 직접 돌리는 것은 전혀 다른 규모의 결정이고, 대다수 조직에 실질적으로 열려 있는 선택지는 전자다.

출처: arXiv 2609.20519 "SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness"(2026년 9월 17일 제출, 엔비디아 외) 초록과 본문 표 1·표 2 및 한계 절 기반 ASAP 정리. 비교 언급한 EvoHarness-RL은 arXiv 2608.05446이다.