코딩 에이전트 harness 설계의 실증 연구

TL;DR Highlight

harness 구성요소를 하나씩 바꿔 보니 모델·예산별로 최적 조합이 달랐다

Who Should Read

코딩 에이전트의 컨텍스트 관리·플래닝·도구 구성을 어떻게 잡을지 고민하는 백엔드 개발자

Core Mechanics

context 예산이 빡빡할수록 관리가 값어치 있다
- 컨텍스트 윈도우 예산이 좁아질수록 context management의 가치가 커진다.
- 이득의 대부분은 context overflow(컨텍스트 넘침) 실패를 막는 데서 나온다.
규칙 기반 elision 먼저, LLM 요약은 그다음
- elision(오래된 내용을 잘라 내기)을 규칙 기반으로 먼저 하고 LLM 요약을 뒤에 두는 방식이 5가지 전략 중 효율이 가장 좋았다.
- 잘린 내용을 나중에 되살릴 수 있게 한 방식은 모델이 거의 쓰지 않아 정확도 이득이 없었다.
planning은 약한 모델엔 정확도, 강한 모델엔 비용 절감
약한 모델에게 planning은 정확도를 받치는 비계 역할을 한다.
- 강한 모델에게는 정확도 변화는 작고 주로 비용을 줄여 준다.
bash 잘하는 모델은 bash만 줘도 된다
- bash 숙련도가 낮은 모델은 미리 정의된 도구를 주면 성능이 오른다.
- bash를 잘하는 모델은 bash 전용 인터페이스로도 잘 돌고 비용이 크게 낮아진다.
- 특히 커맨드라인 중심 작업에서 그 차이가 컸다.
각 구성요소가 에이전트 궤적을 바꾸는 방식이 다르다
- context management는 에이전트 행동은 거의 안 바꾸고 실행 궤적만 길게 늘린다.

Community Reactions

Nemotron·Mistral만 써서 현재 프런티어와 거리가 있다는 의견
- 실험 모델이 Nemotron 계열과 Mistral이라 저가 중국 모델이나 Claude/GPT 대형 모델 상황과 맞지 않는다는 의견이 있었다.
- Qwen이나 DeepSeek이 빠진 점이 아쉽다는 반응도 있었다.
프런티어 모델은 planning 도구가 필요 없다는 정황이라는 의견
- Claude Code에서 Todo/task 추적 도구가 Opus 4.8 등 신형 모델에서 기본 제공되지 않고 환경변수로만 켠다는 이슈가 공유됐다.
- 이를 근거로 Anthropic도 강한 모델에는 세션 내 planning 도구가 필요 없다고 본다는 의견이 나왔다.
컨텍스트 25~30%에서 체크포인트하고 새로 시작했다는 경험
- 한 댓글러는 세션이 윈도우의 25~30%에 이르면 상태를 PROGRESS.md와 요구사항 JSON에 쓰고 새 세션을 시작한다고 했다.
- 논문에서 32k 때 관리 유무 차이가 35.7%p, 128k 때 2.7%p라는 수치를 인용하며 맥락이 같다고 했다.
단순한 에이전트가 복잡한 harness를 이기는 경우가 많다는 의견
- mini-swe-agent 제작자는 복잡한 harness가 아주 단순한 에이전트를 꾸준히 이기는 벤치마크가 많지 않다고 했다.
- 같은 회사의 harness와 모델 조합이 범용 harness보다 경험이 훨씬 좋았다는 경험담도 있었다.

How to Apply

긴 세션을 25~30%에서 끊고 상태 파일로 이어가기
- 오늘 쓰는 에이전트 세션에서 컨텍스트가 일정 비율에 닿으면 진행 상태를 PROGRESS.md로 저장하게 하라.
- 새 세션을 열어 그 파일만 읽히고 작업을 이어가게 하라.
컨텍스트 압축은 규칙 기반 자르기부터 넣기
- 오래된 툴 출력 같은 것을 규칙으로 먼저 잘라 내라.
- 그래도 모자랄 때만 LLM 요약을 뒤에 붙여라.
- 잘린 내용을 되살리는 도구는 일단 넣지 마라.
모델별로 bash-only와 전용 도구 세트를 A/B 하기
- 같은 태스크 셋에서 bash만 준 구성과 전용 도구를 준 구성을 돌려 성공률과 비용을 함께 비교하라.
- 성공률 차이가 없으면 도구를 줄여라.
강한 모델에서는 planning 단계를 빼 보기
- planning on/off로 같은 태스크를 돌려 토큰 비용과 성공률을 비교하라.
- 성공률이 비슷하면 planning을 끄고 비용을 줄여라.

Try It

복사해서 바로 해보기

# Claude Code 또는 ChatGPT에 붙여넣기 (논문 방법의 간이 버전: harness 구성요소 점검)

나는 코딩 에이전트 harness를 운영 중이다. 아래 구성을 보고 '모델·예산에 맞게 불필요하거나 부족한 구성요소'를 점검해 달라.

- 사용 모델: {{모델명}}
- 컨텍스트 윈도우 예산: {{예: 32k / 128k}}
- 현재 context 관리 방식: {{예: 없음 / 요약 / 잘라내기}}
- planning 단계: {{있음 / 없음}}
- 제공 도구 목록: {{도구 목록}}
- 주요 태스크 유형: {{예: 쉘 중심 / 코드 수정 중심}}

다음 순서로 답해 달라.
1. context overflow 실패가 날 위험이 있는지, 규칙 기반 elision을 먼저 넣은 뒤 LLM 요약을 붙이는 구조로 바꾸는 방법
2. planning 단계가 이 모델에 정확도용인지 비용 절감용인지, 빼도 되는지
3. bash-only로 줄여도 되는지, 전용 도구가 꼭 필요한 이유가 있는지
4. 위 세 가지를 검증할 A/B 실험 계획(측정할 지표: 성공률, 토큰 비용)

이어서 해 볼 것: 같은 태스크 10개로 구성을 바꿔 가며 성공률과 비용을 표로 정리해 달라고 요청해 보세요.

Terminology

harnessLLM을 감싸서 도구 호출, 실행 루프, 컨텍스트 관리를 맡는 겉틀이다. 자동차에서 엔진 말고 바퀴와 기어박스에 해당한다.

context management컨텍스트 윈도우가 넘치지 않게 대화·툴 출력을 줄이거나 정리하는 일이다. 책상이 꽉 차기 전에 서류를 치우는 것과 같다.

elision오래된 내용을 규칙에 따라 잘라 내거나 생략하는 것이다. 요약과 달리 LLM 호출이 필요 없다.

action space에이전트가 쓸 수 있는 도구와 명령의 범위다. bash만 줄지, 파일 편집 같은 전용 도구를 줄지가 여기에 해당한다.

SWE-Bench Verified실제 오픈소스 이슈를 에이전트가 고치게 해서 코딩 능력을 재는 벤치마크다.

Terminal-Bench터미널 명령 환경에서 에이전트가 작업을 수행하는 능력을 재는 벤치마크다.