코딩 에이전트 하네스 설계 — 176개 실험이 짚은 네 가지

같은 모델에 같은 과제를 줘도, 그 모델을 둘러싼 틀을 어떻게 짜느냐에 따라 결과가 달라집니다. 도구를 더 쥐여 준다고 늘 잘하는 것도 아니었습니다.

코딩 에이전트에서 「하네스」는 모델의 능력을 실제 작업으로 바꿔 주는 바깥 틀을 말합니다. 계획을 세우게 할지, 어떤 도구를 줄지, 길어진 대화를 어떻게 추려 줄지 같은 설계입니다. 한 연구가 이 하네스를 통째가 아니라 부품 단위로 뜯어, 계획·도구·맥락 관리를 176가지 조합으로 바꿔가며 측정했습니다. 하네스가 모델만큼 중요하다는 이야기는 모델보다 하네스 글에서 다뤘는데, 이번엔 「그래서 어떤 부품이 언제 효과가 있나」를 숫자로 짚은 셈입니다. 공식 논문을 기준으로 정리했습니다.

짧게 정리하면

• 연구진은 실행 흐름은 고정한 채 계획·도구·맥락 관리 세 부품만 바꿔 176가지 설정을 비교했습니다.
• 맥락 창이 좁을수록 맥락 관리의 값어치가 커졌고, 이득 대부분은 「맥락이 넘쳐 실패하는 것」을 막는 데서 나왔습니다.
• 미리 만든 도구는 명령줄에 약한 모델에 도움이 됐고, 명령줄에 능한 모델은 셸만으로도 더 싸게 잘 해냈습니다.

2026년 9월 공개된 논문 「코딩 에이전트를 위한 하네스 설계 실증 연구」를 기준으로 했습니다. 특정 벤치마크와 네 개 모델에서 나온 결과이니, 모든 상황에 그대로 들어맞는다고 보긴 어렵습니다.

무엇을 어떻게 쟀나

연구진은 가벼운 하네스를 하나 만들고, 실행 반복 구조는 고정한 채 세 부품만 바꿨습니다. 계획을 세우게 할지, 어떤 행동 공간(도구)을 줄지, 길어진 맥락을 어떻게 관리할지입니다. 네 개 모델을 두 가지 소프트웨어 엔지니어링 과제 묶음에서 돌렸고, 다섯 가지 맥락 관리 방식과 네 가지 맥락 창 크기, 그리고 계획·도구를 떼었다 붙였다 한 조합을 더해 모두 176가지 설정을 비교했습니다. 부품을 따로따로 비교할 수 있게 설계한 점이 이 연구의 핵심입니다. 그동안은 하네스를 통째로 놓고 「이 도구가 저 도구보다 낫다」를 비교하는 경우가 많아, 정작 어느 부품이 성능을 끌어올리는지 가려내기 어려웠습니다. 실행 흐름을 고정하고 한 번에 한 부품만 바꾸니, 결과의 원인을 부품별로 짚을 수 있게 된 것입니다. 연구진은 작업 기록을 따라가며 왜 그런 차이가 나는지도 분석했는데, 맥락 관리는 작업을 더 오래 이어 가게 하고, 계획은 작업을 어디서 멈추는지를 바꾸며, 도구 구성은 코드를 얼마나 잘게 쪼개 쓰는지를 바꾸는 것으로 나타났습니다.

네 가지 결과

논문이 밝힌 주요 결과

부품	결과
맥락 관리	맥락 창이 좁을수록 값어치 커짐. 이득 대부분은 넘침 실패 방지
추리는 방식	규칙으로 먼저 덜고 그다음 요약이 가장 효율적. 되살리기 기능은 모델이 잘 안 씀
계획	약한 모델엔 정확도 버팀목, 강한 모델엔 비용 절감 수단. 정확도 변화는 작음
도구(행동 공간)	명령줄 약한 모델엔 전용 도구가 도움. 능한 모델은 셸만으로 더 싸게 처리

가장 눈길을 끄는 건 네 번째입니다. 미리 만든 전용 도구를 많이 붙이는 게 늘 정답은 아니었습니다. 명령줄을 잘 다루는 모델은 셸 하나만 줘도 비슷하게, 그것도 더 적은 비용으로 해냈다는 겁니다. 특히 명령줄 중심 작업에서 그 차이가 컸습니다. 도구를 늘리는 대신 줄이는 선택이 더 나을 수 있다는 반직관적인 결과입니다. 맥락이 왜 비용으로 이어지는지는 토큰 아끼는 실전 글과 함께 보면 이해가 쉽습니다.

그래서 어떻게 쓰나

실무로 옮기면 세 가지로 추려집니다. 첫째, 맥락 창이 빠듯한 환경이라면 맥락 관리부터 손보는 게 효과가 큽니다. 넘쳐서 실패하는 일을 막는 것만으로도 상당 부분 건집니다. 둘째, 맥락을 추릴 때는 규칙으로 먼저 덜어 내고 그다음 요약하는 순서가 효율적이고, 덜어 낸 걸 다시 꺼내 쓰게 만드는 복잡한 장치는 모델이 잘 쓰지 않으니 공들일 필요가 적습니다. 셋째, 쓰는 모델이 명령줄에 능하다면 전용 도구를 잔뜩 붙이기보다 셸 중심으로 단순하게 가는 편이 비용이 덜 듭니다. 에이전트 설정 파일을 어떻게 두는지는 에이전트 설정 파일 글, 여러 에이전트를 나눠 쓰는 법은 서브에이전트 글을 참고하세요.

논문 결과를 바탕으로 한 상황별 먼저 손볼 것(직접 정리)

내 상황	먼저 손볼 것
맥락 창이 빠듯함	맥락 관리부터. 넘침 실패 방지가 핵심
맥락을 추려야 함	규칙으로 먼저 덜고 요약. 되살리기 장치는 생략
명령줄에 능한 모델	전용 도구를 덜고 셸 중심으로. 비용 절감
명령줄에 약한 모델	전용 도구를 붙여 성능 보강

이 결과는 특정 벤치마크와 네 개 모델에서 나온 것입니다. 모델이 명령줄에 얼마나 능한지, 맥락 창이 얼마나 되는지에 따라 유리한 설정이 달라지므로, 그대로 베껴 쓰기보다 내 환경에서 작게 재 보고 정하는 편이 안전합니다. 특히 「도구를 줄이는 게 낫다」는 결과는 명령줄에 능한 모델에 해당하는 이야기여서, 약한 모델에는 반대로 전용 도구가 도움이 될 수 있습니다.

자주 묻는 질문

하네스가 정확히 뭔가요

모델을 둘러싼 실행 틀입니다. 계획을 세우게 할지, 어떤 도구를 줄지, 길어진 대화를 어떻게 추릴지 같은 설계를 묶어 부르는 말입니다. 같은 모델이라도 이 틀을 어떻게 짜느냐에 따라 성능과 비용이 달라집니다.

도구는 무조건 줄이는 게 좋나요

아닙니다. 논문은 명령줄에 능한 모델에서 셸 중심이 더 싸고 비슷한 성능을 냈다고 했을 뿐입니다. 명령줄에 약한 모델은 미리 만든 전용 도구가 성능을 올려 줬습니다. 쓰는 모델의 성향에 맞춰 정해야 합니다.

맥락 관리는 언제 중요한가요

맥락 창이 좁을 때입니다. 논문은 맥락 창이 빠듯할수록 맥락 관리의 값어치가 커졌고, 그 이득의 대부분이 맥락이 넘쳐 실패하는 것을 막는 데서 나왔다고 밝혔습니다. 창이 넉넉하면 효과는 상대적으로 줄어듭니다.

새 모델이 나올 때마다 성능 숫자에 눈이 가지만, 실제 체감은 그 모델을 어떤 틀에 끼우느냐에서 갈리는 경우가 많습니다. 저라면 이 논문의 결과를 정답표가 아니라 「무엇부터 실험해 볼지」 목록으로 쓰겠습니다. 맥락 창이 빠듯하면 맥락 관리부터, 명령줄에 능한 모델이면 도구를 덜어 보는 식으로 하나씩 바꿔 가며 비용과 정확도를 재 보면, 남의 설정을 베끼는 것보다 내 작업에 맞는 틀을 찾기 쉽습니다.

확인한 곳: 논문 「코딩 에이전트를 위한 하네스 설계 실증 연구」(2026년 9월 공개, 저자 9인). 계획·행동 공간·맥락 관리 세 부품을 두 벤치마크·네 모델에서 176가지 설정으로 비교. 맥락 관리·추리는 방식·계획·도구에 관한 네 가지 결과를 옮겼습니다. 특정 실험 환경 기준입니다.