코딩 에이전트 하네스 설계의 어떤 부분이 실제로 효과적인가

논문이 다루는 질문

코딩 에이전트는 언어 모델만으로 이루어져 있지 않습니다. 모델은 "하네스(harness)" 안에서 움직입니다. 하네스는 제어 루프, 도구 인터페이스, 그리고 모델이 상호작용 기록 중 무엇을 남길지 정하는 규칙을 담은 소프트웨어 계층입니다. 논문 「An Empirical Study of Harness Design for Coding Agents」(arXiv 2609.20804, 2026년 9월 17일 제출)는 이 계층의 어떤 부분이 실제로 일을 하는지 묻습니다. 저자는 아홉 명이며 UMass Amherst, Emory University, UNC Charlotte 소속입니다. 논문은 작업 일부가 Zoom Video Communications 인턴십 중에 이루어졌다고 밝힙니다.

저자들은 이전 연구가 대개 완성된 하네스를 통째로 비교했다고 말합니다. 논문은 하네스 간 비교 평가 하나를 인용합니다. 그 평가에서 Claude-Opus-4.5는 OpenHands에서 가장 좋았고, Claude-Sonnet-4.5는 SWE-Agent에서 가장 좋았습니다. 이런 결과로는 차이가 계획, 도구 설계, 컨텍스트 관리, 아니면 모델과의 상호작용 중 어디에서 오는지 알 수 없습니다. 그래서 저자들은 가벼운 하네스를 처음부터 만들었습니다. ReAct 루프는 고정입니다. 바꾸는 것은 세 가지 구성 요소뿐입니다. 계획(planning), 행동 공간(action space), 컨텍스트 관리(context management)입니다. 권한 처리, 편집 후 진단, 정체 감지는 모든 실험에서 고정입니다.

실험 설정

하네스는 LangGraph 위에 만들어졌고, 벤치마크는 Harbor를 통해 실행됩니다. 각 작업은 최대 300단계를 받습니다. 논문은 네 모델을 시험합니다. Nemotron-3의 세 크기(30B, 120B, 550B)와 Mistral-Medium-3.5-128B입니다. 벤치마크는 두 가지입니다. SWE-Bench Verified는 사람이 검증한 GitHub 이슈 500건을 담고 있습니다. Terminal-Bench 2.1은 명령줄 작업 89건을 담고 있습니다. 논문은 성공률과 작업당 평균 비용을 보고하며, 비용은 OpenRouter 가격으로 계산했습니다.

컨텍스트 관리는 다섯 단계입니다. T0는 아무것도 하지 않으며 윈도가 넘치면 오류로 종료합니다. T1은 오래된 도구 출력을 짧은 자리표시자로 바꿉니다(elision, 생략). T2는 여기에 외부 저장소와 recall_event 도구를 더해 생략된 내용을 다시 읽을 수 있게 합니다. T3는 LLM 요약만 씁니다. T4는 셋을 단계적으로 결합합니다. 먼저 생략하고, 그래도 기록이 너무 길 때만 요약합니다. 소프트 임계값과 하드 임계값은 사용 가능한 윈도의 0.6과 0.85입니다. 저자들은 다섯 단계를 32k, 64k, 96k, 128k 토큰 윈도에서 모두 실행합니다. 계획과 행동 공간(사전 정의 도구 대 bash만)은 T4와 128k 윈도에서만 따로 떼어 실험합니다. 합계 176개의 짝지은 설정이 됩니다. 저자들은 양측 정확 McNemar 검정으로 성공률을 비교하고 거짓 발견율을 0.05로 통제합니다.

네 가지 발견과 논문의 수치

1. 윈도가 좁을수록 컨텍스트 관리의 가치가 큽니다. 모델 평균으로, 윈도가 32k에서 128k로 커질 때 관리된 단계(T1~T4)와 T0의 격차는 SWE-Bench에서 35.7에서 15.9, 5.5, 2.7 퍼센트포인트로 줄어듭니다. Terminal-Bench에서는 9.5에서 7.5, 4.8, 2.8로 줄어듭니다. T0의 오버플로 실패율은 SWE-Bench에서 78.7%에서 8.7%로, Terminal-Bench에서 61.0%에서 12.1%로 떨어집니다. 관리된 모든 단계는 어떤 예산에서도 오버플로 실패가 0입니다. 표 3의 한 예로, 32k에서 Nemotron-3 550B의 SWE-Bench 성공률은 T0에서 6.40%, T4에서 55.60%입니다. 논문은 이익의 대부분이 이른 절단을 막는 데서 온다고 결론짓습니다. 2. 먼저 생략하고 나중에 요약하는 T4가 가장 효율적이며, 복구는 거의 이득이 없습니다. T4의 성공률은 T1~T3와 비슷합니다. 모델과 벤치마크의 여덟 조합 중 일곱에서 비용이 가장 낮고, 모든 윈도 예산에서 작업당 평균 비용이 가장 낮습니다. 네 예산 모두에서 최대 컨텍스트 비율도 가장 낮습니다. 32k에서 T1과 T2는 여전히 윈도 거의 전체에 이릅니다. 복구(recall) 메커니즘은 사정이 다릅니다. 짝지은 비교 32건에서 T2는 T1을 15건에서 이기고 14건에서 지고 3건에서 비겼습니다. 평균 차이는 마이너스 0.36포인트입니다. 64개 설정 중 36개(56.3%)에서 모델은 recall_event를 한 번도 부르지 않았습니다. 작업당 평균 복구 호출 수는 32k의 0.540에서 128k의 0.007로 떨어졌습니다.

3. 계획은 정확도 발판에서 비용 절감으로 바뀝니다. Nemotron-3 30B에서 계획은 성공률을 SWE-Bench에서 11.6포인트, Terminal-Bench에서 4.5포인트 높였지만 비용도 올랐습니다. 120B 모델에서는 일관된 이득이 없었습니다. Nemotron-3 550B와 Mistral-Medium-3.5-128B에서는 계획이 SWE-Bench 비용을 약 30%와 32% 낮췄고, 성공률은 2.0포인트와 0.4포인트 떨어졌습니다. 4. 최적의 행동 공간은 모델에 따라 다릅니다. Nemotron-3 30B에서 사전 정의 도구 세트는 성공률을 SWE-Bench에서 15.0포인트, Terminal-Bench에서 10.1포인트 높였습니다. Nemotron-3 550B에서는 bash만 쓰면 성공률이 3.6포인트와 5.6포인트 오르고 비용이 53%와 30% 줄었습니다. Mistral은 엇갈립니다. SWE-Bench에서는 전체 도구가 더 좋았고(23.2포인트 높음), Terminal-Bench에서는 bash만 쓸 때 6.7포인트가 더해졌습니다.

궤적 분석이 보여 주는 것

저자들은 LLM 판정기를 써서 에이전트 실행의 각 턴에 작업 단계 라벨을 붙였습니다. 이 분석이 위의 네 가지 발견을 설명합니다. 컨텍스트 관리는 주로 실행을 길게 만듭니다. 32k에서 관리가 없으면 SWE-Bench 궤적의 중앙값은 20~30턴이고, 대부분의 실행은 버그를 찾는 단계에서 멈춥니다. 관리가 있으면 중앙값이 약 50~180턴으로 늘고 실행은 검증 단계에 이릅니다. 계획은 약한 모델과 강한 모델에서 다르게 작용합니다. Nemotron-3 30B의 SWE-Bench에서 계획을 끄자 궤적 중앙값이 40턴에서 5턴으로 줄었습니다. 계획이 없으면 실행의 68.6%가 편집 없이 끝났고, 계획이 있으면 27.8%였습니다. 가장 강한 두 모델에서는 계획이 중앙 실행을 108턴에서 74턴(550B)으로, 68턴에서 53턴(Mistral)으로 줄였습니다. 저자들은 이 감소의 대부분을 편집 후 검증이 줄어든 탓으로 봅니다.

행동 공간은 코드를 쓰는 방식을 바꿉니다. Nemotron-3 30B의 Terminal-Bench에서는 bash만 쓴 실행의 66%가, 모델이 bash만 쓰는 등록부에 없는 도구를 호출한 뒤 종료했습니다. 평균 실행은 71턴에서 15턴으로 줄었습니다. 550B 모델의 Terminal-Bench에서는 bash만 쓰자 궤적 중앙값이 47에서 31 행동으로 줄었고, 코드 작성 행동의 비율이 16%에서 27%로 올랐습니다. 이미 편집한 파일에 대한 반복 패치는 네 모델 모두에서 줄었으며, 예를 들어 30B는 3.3에서 0.4가 되었습니다.

우리의 분석

우리가 보기에 이 논문의 핵심 메시지는 "승자"가 아니라 "조건"입니다. 모든 발견에는 "만약"이 붙어 있습니다. 윈도가 좁다면, 모델이 약하다면, 모델이 bash에 능숙하다면 하는 식입니다. 하나의 기본 하네스로는 이 모든 경우를 맞출 수 없습니다. "하네스 A가 하네스 B를 이긴다"고 보고하는 사람은 모델, 예산, 작업 유형도 함께 밝혀야 합니다.

두 번째 주제는 추가 장치가 공짜가 아니라는 점입니다. 복구 도구는 장치를 늘렸지만 모델은 거의 쓰지 않았습니다. 사전 정의 도구는 약한 모델을 도왔지만, 강한 모델에는 저자들의 표현으로 "행동 선택과 상호작용의 오버헤드"를 더한 것으로 보입니다. 동시에 결과는 "단순할수록 항상 좋다"고 말하지 않습니다. bash만 쓰면 550B 모델의 비용은 거의 절반이 되었지만, 30B 모델에는 큰 손해였고 Mistral의 SWE-Bench에도 손해였습니다.

세 번째 점은 비용입니다. 달러 수치는 이 모델들에 대한 2026년 8월 OpenRouter 가격에 달려 있습니다. 계획 뒤에 턴이 줄어드는 것과 같은 효과의 방향은 달러 값보다 다른 상황으로 옮기기 쉽습니다.

한계와 열린 질문

저자들은 몇 가지 한계를 직접 밝힙니다. 결과는 그들이 만든 구체적인 구성 요소에 대한 것이며 보편적으로 최선인 하네스를 찾은 것이 아닙니다. 계획과 행동 공간은 T4와 128k 윈도에서만 따로 실험했으므로, 다른 조합을 보려면 완전 요인 연구가 필요합니다. 각 설정은 작업마다 한 번만 실행했습니다. Terminal-Bench는 작업이 89건뿐이라 그곳의 많은 대비가 McNemar 검정에서 유의하지 않으며, 저자들은 모델과 예산에 걸친 일관된 방향에 의존합니다. SWE-Bench Verified는 Python만 다룹니다. 모델 크기는 능력의 불완전한 대리 지표이며, 저자들은 다른 모델군, 하네스, 작업에 쓰기 전에 교차점을 검증해야 한다고 말합니다. 또한 행동 공간의 변경에는 도구 유무, 프롬프트, 파일 상태 추적, 자동 진단이 함께 묶여 있다고 밝힙니다.

논문 본문만 읽은 입장에서 두 가지를 더합니다. 우리는 코드를 실행하지 않았고 표를 다시 확인하지도 않았습니다. 또 이 연구는 오픈 웨이트 모델군 하나와 다른 모델 하나를 썼습니다. 많은 상용 코딩 도구가 쓰는 폐쇄형 최전선 모델에 대해서는 아무것도 말하지 않습니다.

독자를 위한 실용적 시사점

코딩 에이전트를 만드는 팀에게 이 논문은 몇 가지 습관을 시사합니다. 영리한 기억 기능을 더하기 전에, 긴 실행이 컨텍스트 한계에 얼마나 자주 부딪히는지 먼저 재 보세요. 논문은 이익의 대부분이 오버플로를 피하는 데서 온다고 보기 때문입니다. LLM 요약에 비용을 쓰기 전에 값싼 규칙 기반 생략을 먼저 시험해 보세요. 복구 도구가 쓰일 것이라고 가정하지 말고 호출 로그를 확인하세요. 계획은 모델마다 따로 시험하세요. 약한 모델에서는 비용이 오르고 강한 모델에서는 내릴 수 있습니다. 강한 모델에는 bash만 쓰는 인터페이스를 시험해 보되, 셸 실력이 약한 모델에는 구조화된 도구를 남겨 두세요. 마지막으로, 모델이나 컨텍스트 예산을 바꿀 때는 이 점검을 다시 하세요.