자율 코딩 에이전트가 실제로 잘 일하느냐는 모델 자체의 똑똑함만이 아니라, 그 모델을 감싸는 '하네스(harness, 에이전트의 실행 뼈대)'가 얼마나 잘 설계됐느냐에 달려 있습니다. 이 논문은 지금까지 통째로만 평가되던 하네스를 계획·행동 공간·컨텍스트 관리라는 세 부품으로 분해해, 176개의 조건을 맞춰 하나씩 갈아 끼워가며 비교했습니다. 그 결과 "무엇이 언제 효과가 있는지"를 부품 단위로 밝혀냈다는 점이 핵심 성과입니다.
요리사(모델)가 아무리 실력이 좋아도, 주방(하네스)의 동선과 도구 배치가 엉망이면 좋은 요리가 나오기 어렵습니다. 코딩 에이전트도 마찬가지입니다. 같은 언어 모델을 쓰더라도 이 모델을 어떻게 계획시키고, 어떤 도구를 쥐여주고, 대화 기록을 어떻게 관리하느냐에 따라 긴 호흡의 소프트웨어 작업 성능이 크게 달라집니다.
문제는 기존 연구가 하네스를 하나의 '통짜 시스템'으로 놓고 평가해 왔다는 점입니다. 주방 전체를 A안과 B안으로만 비교하니, 정작 성능을 끌어올린 게 동선인지 칼인지 냉장고인지 알 수가 없었습니다. 어떤 개별 부품이 실제로 효과가 있는지가 흐릿하게 남아 있던 것입니다.
이 논문은 그래서 접근을 뒤집습니다. 실행 루프(에이전트가 관찰→판단→행동을 반복하는 골격)는 고정한 가벼운 하네스를 만들어 두고, 다음 세 부품만 바꿔가며 실험합니다.
연구진은 네 개의 모델을 두 종류의 벤치마크(SWE-Bench Verified, Terminal-Bench 2.1)에서 돌렸습니다. 앞의 것은 실제 소프트웨어 이슈를 고치는 과제, 뒤의 것은 터미널·명령줄 중심 과제라고 보면 됩니다. 그리고 조건을 정교하게 '맞춰서(matched)' 176가지로 비교했습니다. 다른 조건은 똑같이 두고 한 부품만 바꿔야, 성능 차이가 그 부품 때문이라고 말할 수 있기 때문입니다.
세 부품을 일상 비유로 풀면 이렇습니다.
컨텍스트 관리 — 책상 정리법. 작업이 길어지면 책상 위에 서류(대화·로그·코드)가 산더미로 쌓입니다. 책상(컨텍스트 창, 모델이 한 번에 볼 수 있는 정보량)에는 한계가 있어서, 넘치면 작업이 아예 무너집니다. 연구진은 다섯 가지 정리 전략을 비교했는데, 그중 두 가지 방식이 대비됩니다. 하나는 규칙 기반 삭제(elision, 정해진 규칙으로 덜 중요한 내용을 잘라내기), 다른 하나는 LLM 기반 요약(summarization, 모델이 알아서 줄이기)입니다. 또 하나의 변수는 "잘라낸 내용을 나중에 다시 꺼내볼 수 있게(recoverable) 만들 것인가"입니다.
계획 — 착수 전 메모. 일을 시작하기 전에 순서를 적어두는 습관입니다. 초보에게는 길을 잃지 않게 잡아주는 발판이 되고, 숙련자에게는 이미 아는 길이라 큰 도움은 안 되지만 헛걸음을 줄여주는 효과가 있습니다.
행동 공간 — 도구함의 구성. 에이전트에게 잘 정의된 전용 도구(predefined tools, 파일 편집·검색 같은 특화 기능)를 여러 개 쥐여줄 수도 있고, 반대로 셸 명령(bash) 하나만 주고 알아서 쓰게 할 수도 있습니다. 만능 맥가이버칼 하나냐, 용도별 도구 세트냐의 차이입니다.
초록이 정리한 발견은 네 가지입니다. 구체적 수치는 초록에 제시돼 있지 않아, 방향성 중심으로 옮깁니다.
| 부품 | 핵심 발견 |
|---|---|
| 컨텍스트 관리 | 컨텍스트 창 예산이 빠듯해질수록 가치가 커진다. 이득의 대부분은 컨텍스트 넘침(overflow)으로 인한 실패를 막는 데서 나온다. |
| 컨텍스트 전략 | 규칙 기반 삭제를 LLM 요약보다 먼저 배치(staging)하는 것이 전체 효율이 가장 좋다. 잘라낸 내용을 복구 가능하게 만드는 장치는 모델이 거의 쓰지 않아 정확도 이득이 없다. |
| 계획 | 약한 모델에겐 정확도를 받쳐주는 발판, 강한 모델에겐 비용을 아끼는 도구로 역할이 바뀐다. 정확도 변화는 크지 않다. |
| 행동 공간 | bash 숙련도가 낮은 모델은 전용 도구가 성능을 높여준다. 반대로 bash에 능한 모델은 셸만으로도 잘 작동하며, 특히 명령줄 중심 과제에서 비용을 크게 낮춘다. |
연구진은 궤적(trajectory, 에이전트가 과제를 푸는 전체 행동 흐름) 단위 분석으로 이 효과들을 설명합니다. 정리하면 세 부품은 서로 다른 곳에 작용합니다.
이 관점이 중요한 이유는, 각 부품이 "성능을 올린다"가 아니라 "어떤 방식으로 개입하는지"를 구분해 주기 때문입니다. 덕분에 모델의 강약과 예산 상황에 따라 하네스를 골라 맞추는 근거가 생깁니다.
솔직하게 짚을 부분이 있습니다.
첫째, 실험은 네 개 모델과 두 종류 벤치마크(SWE-Bench Verified, Terminal-Bench 2.1)에 한정됩니다. 다른 모델군이나 다른 성격의 과제에도 같은 결론이 성립하는지는 이 논문 범위 밖입니다.
둘째, 연구진은 실행 루프를 일부러 고정한 가벼운 하네스를 썼습니다. 통제된 비교를 위한 선택이지만, 실행 루프 자체가 정교한 실전 하네스에서는 부품 간 상호작용이 달라질 여지가 있습니다.
셋째, "복구 가능한 삭제 장치를 모델이 거의 안 쓴다"는 발견은 흥미롭지만, 이것이 현재 모델의 습관 때문인지 설계가 불편해서인지까지는 초록만으로 단정하기 어렵습니다. 앞으로 모델이 바뀌면 재검토가 필요한 대목입니다.
온틀은 AI 프로젝트 매니저를 파견하는 서비스입니다. 우리가 다루는 것도 결국 '오래 일하는 에이전트를 어떤 뼈대로 감쌀 것인가'라는 같은 문제입니다. 이 논문에서 실무로 가져올 만한 시사점을 정리하면 다음과 같습니다.
예산이 빠듯할수록 컨텍스트 관리부터. 컨텍스트 창을 넉넉히 쓸 수 없는 운영 환경이라면, 정리 전략의 가치가 특히 커집니다. 그리고 그 이득의 상당 부분이 "넘쳐서 통째로 실패하는 사고"를 막는 데서 온다는 점은, 실제 서비스 안정성에 직결됩니다. 값싼 규칙 기반 삭제를 먼저 태우고 그다음에 LLM 요약을 얹는 순서가 효율이 좋았다는 발견은 그대로 참고할 만합니다.
모델 세대에 따라 계획의 역할을 다르게. 약한 모델에는 계획이 정확도 발판이지만, 강한 모델에는 정확도보다 비용 절감 수단에 가깝습니다. 어떤 모델을 붙이느냐에 따라 "계획을 얼마나 강제할지"를 조절하는 게 합리적입니다.
도구를 무조건 많이 주는 게 답은 아니다. bash에 능한 모델이라면 셸 중심 인터페이스만으로도 잘 돌고, 명령줄 중심 작업에서는 오히려 비용이 크게 내려갑니다. 반대로 셸 숙련도가 낮은 모델에는 전용 도구가 성능을 받쳐줍니다. 하네스 설계는 '모델 인지·예산 인지(model- and budget-aware)'로 가야 한다는 것이 이 논문의 결론이자, 우리 제품 설계 철학과도 맞닿습니다.
무엇보다 이 연구가 준 가장 큰 선물은 '통짜 비교에서 부품 단위 비교로' 관점을 바꾼 모듈형 평가 틀입니다. 앞으로 새 하네스 부품이 나올 때마다 "이게 어디에, 왜 작용하는가"를 따져 물을 수 있는 공통 언어가 생긴 셈입니다.
언어 모델을 실제 코딩 작업에 투입하기 위해 감싸는 실행 뼈대입니다. 계획을 세우게 하고, 도구를 쥐여주고, 길어진 작업 기록을 관리하는 등 모델의 능력을 장기 소프트웨어 작업 성능으로 바꿔주는 장치 전체를 말합니다.
하나로 정할 수 없다는 것이 이 논문의 요지입니다. 컨텍스트 관리는 예산이 빠듯할수록, 계획은 모델이 약할수록, 전용 도구는 셸 숙련도가 낮은 모델일수록 가치가 커집니다. 상황에 따라 답이 달라집니다.
초록에 따르면 복구 가능하게 만드는 장치를 추가해도 모델이 그 기능을 거의 사용하지 않았고, 그 결과 정확도 이득이 없었습니다. 부가 장치의 복잡성만 늘어난 셈입니다.
주의가 필요합니다. 실험은 네 개 모델과 두 종류 벤치마크에 한정되며, 실행 루프를 고정한 가벼운 하네스에서 얻은 결과입니다. 방향성은 참고하되, 다른 환경에서는 재검증이 권장됩니다.