에이전트가 기대만큼 일을 끝내지 못하면 계획 단계, 도구, 검토 역할을 더 붙이고 싶어집니다. 필요한 보완일 수 있습니다. 다만 기능이 늘었다는 사실만으로 성공률이 높아졌다고 판단하기는 어렵습니다. 빌더가 먼저 찾을 것은 지금 작업이 멈추는 지점과, 그 지점을 바꾸는 데 드는 비용입니다.
최근 AI타임스의 하네스 비용 비교 보도와 마이크로소프트 Agensh 협업 보도는 함께 읽을 만합니다. 한쪽은 하네스를 바꾸어도 성능 개선이 뚜렷하지 않았다는 연구를, 다른 쪽은 에이전트를 늘려 테스트 통과율을 높인 실험을 소개합니다. 두 결과는 서로 다른 변수를 바꿨습니다.
우리 작업에 적용하려면 질문을 나누는 편이 좋습니다. 같은 모델이 일하는 실행 환경을 두껍게 만들 필요가 있는지, 그리고 동시에 진행할 수 있는 일이 충분히 남아 있는지입니다. 앞의 질문에는 호출당 문맥과 실패 복구를, 뒤의 질문에는 작업 분할과 통합 부담을 함께 살펴야 합니다.
하네스의 복잡도와 에이전트 수는 다른 축입니다
하네스는 모델이 실제 작업을 이어가도록 감싸는 실행 환경입니다. 시스템 지시문, 도구 정의, 도구 결과를 전달하는 방식, 대화 기록 관리, 중단 뒤 복구 같은 선택이 여기에 들어갑니다. 협업 구성을 더하면 작업 소유권, 동료의 발견 전달, 결과 검증과 통합도 설계해야 합니다.
두 층을 구분하면 단순함의 의미도 선명해집니다. 개별 작업자에게 주는 도구와 문맥은 작게 유지하면서 작업자는 여럿 둘 수 있습니다. 반대로 작업자가 하나여도 긴 지시문과 많은 도구, 여러 검토 단계를 거치게 할 수 있습니다. 화면에 보이는 에이전트 수만으로 실행 비용이나 운영 난도를 짐작해서는 안 됩니다.
| 비교할 질문 | 하네스 비교 연구 | Agensh 연구 |
|---|---|---|
| 바꾼 것 | 같은 모델을 감싸는 실행 하네스 | 같은 모델로 일하는 에이전트 수 |
| 작업 성격 | 기존 저장소의 이슈 수정 | 참조 프로그램의 동작을 처음부터 구현 |
| 주요 관찰 | 성공률의 반복 변동과 토큰 비용 | 제한 시간 안의 테스트 통과율과 협업 |
| 도입 때 따질 것 | 추가 문맥과 복구가 실제로 유용한가 | 병렬 진행의 이득이 조정 부담을 넘는가 |
이 구분은 각 논문의 실험 설계와 Agensh 평가에 근거합니다. 따라서 두 결과를 같은 성능표에 올려 단순한 하네스와 대규모 협업 중 승자를 고르는 방식은 적절하지 않습니다.
같은 모델의 하네스를 바꾸면 무엇이 달라졌나요
What Does a Harness Buy? Tokens, Mostly는 Claude Code, mini-SWE-agent, OpenCode를 비교했습니다. 오프라인에서 실행 가능한 SWE-bench Verified 492개 과제를 어려운 45개와 나머지 447개로 나눴습니다. 어려운 집합에는 모델 5종을, 큰 집합에는 로컬 Qwen 모델 2종을 사용했습니다. Opus는 Claude Code 안에서만 기준점으로 사용했으므로 모든 모델을 모든 하네스에서 비교한 실험은 아닙니다.
큰 집합에서 Claude Code와 mini-SWE-agent의 성공률은 연구진이 정한 5%포인트 동등성 범위 안에 들어갔습니다. 어려운 집합에서는 하네스를 바꿨을 때와 같은 구성을 다시 실행했을 때 성공·실패가 뒤집히는 비율의 중앙값이 모두 약 13%였습니다. 이는 해당 과제와 모델에서 반복 변동을 함께 봐야 한다는 결과입니다. 모든 하네스의 성능이 항상 같다는 선언으로 읽을 수는 없습니다. 논문 초록과 결과에서 비교 범위를 볼 수 있습니다.
비용은 같은 모델·과제의 토큰 사용량에 같은 가격표를 적용했을 때 하네스 사이에 최대 약 3배 차이가 났습니다. 논문의 금액 분석은 DeepSeek-V4-Flash와 GLM-5.3-Flash를 대상으로 합니다. 로컬 모델의 토큰 수나 구독형 사용료를 모두 같은 실제 청구액으로 취급한 결과가 아닙니다. 저자들의 공개 데이터와 분석 코드도 함께 볼 수 있습니다.
실행 예산에도 조건이 있습니다. 모델 호출 상한은 과제당 300회로 맞췄지만, 로컬 Qwen 실행의 벽시계 제한은 하네스마다 달랐습니다. 버전과 기본 동작도 실험 당시 설정에 묶여 있습니다. 제품의 현재 버전이나 다른 업무로 결과를 옮길 때는 이 차이를 다시 확인해야 합니다. 실험 설정과 부록 A가 그 출발점입니다.
비용은 첫 호출과 마지막 호출 사이에서 쌓입니다
이 연구의 비용 분석은 시작 문맥의 크기, 단계마다 늘어나는 기록, 전체 호출 횟수를 나눠 보게 합니다. 시스템 지시문과 도구 정의는 작업 파일을 읽기 전부터 문맥을 차지합니다. 기록을 다음 호출에 얼마나 다시 보내는지도 비용에 영향을 줍니다. 논문은 모델에 따라 가벼운 하네스가 더 많은 단계를 밟는 경우도 보고합니다. 비용 분석 절을 보면 가장 작은 시작 문맥만으로 최저 비용을 고를 수 없는 이유가 드러납니다.
빌더의 측정도 이 구분을 따라가면 좋습니다. 첫 호출의 입력을 시스템 지시문, 도구 설명, 작업 내용으로 나눠 기록합니다. 이후에는 파일 내용과 도구 출력, 모델이 남긴 기록이 얼마나 붙는지 봅니다. 도구가 많아서 비싼지, 같은 파일을 거듭 읽어서 비싼지에 따라 수정할 곳이 달라집니다.
캐시 입력과 일반 입력, 출력은 따로 보관하는 편이 좋습니다. 입력 토큰 합계만 있으면 가격표가 바뀔 때 비용을 다시 계산하기 어렵습니다. 제공자가 돌려주는 사용량과 실제 청구 내역도 구분해 두어야 합니다. 캐시가 적용된 긴 문맥과 캐시가 적용되지 않은 짧은 문맥은 토큰 합계만으로 비교하기 어렵기 때문입니다.
계획과 검토 단계도 같은 방식으로 살펴야 합니다. 계획을 더 쓴 뒤 재작업이 줄었는지, 검토자가 실제 결함을 찾아냈는지, 검토 요청을 위해 같은 문맥을 다시 보내고 있는지 기록합니다. 각 단계에 어떤 실패를 줄이려는지 목적을 붙여 두면, 비용이 늘었을 때 그 값을 지불할 이유를 설명할 수 있습니다.
짧게 끝난 실행도 따로 들여다봐야 합니다. 일을 다 끝내서 저렴한 경우와, 중간에 포기해서 저렴한 경우는 운영에서 다르게 취급해야 합니다. 결과 파일이 있다는 사실을 완료로 삼으면 후자를 놓치기 쉽습니다. 기대한 동작을 확인하는 검증과 실행 종료 사유를 같이 남겨야 합니다.
단순한 구성으로 충분한지 판단하는 방법
먼저 작업 경계를 적어 봅니다. 입력이 분명하고, 고칠 범위가 좁고, 결과를 재현 가능한 방법으로 판정할 수 있다면 작은 실행 루프를 기준선으로 삼기 좋습니다. 필요한 자료를 읽고, 변경하고, 검증하고, 실패하면 수정하는 흐름입니다. 여기서 단순하다는 말에는 완료를 확인하는 절차도 포함됩니다.
가령 팀이 작은 버그 수정 업무를 평가한다고 가정해 봅니다. 검토 역할을 추가하기 전에 기존 실행에서 왜 실패했는지 나눕니다. 요구를 잘못 이해했는지, 필요한 파일을 못 찾았는지, 수정은 맞았으나 검증 명령을 잘못 골랐는지 봅니다. 서로 다른 원인을 모두 계획 부족으로 묶으면 추가 단계의 효과를 판단하기 어렵습니다.
추가 도구를 고를 때도 같은 질문이 도움이 됩니다. 이미 셸과 파일 읽기로 해결 가능한 작업에서 전용 도구를 넣으려면 어떤 오류를 줄이는지 설명할 수 있어야 합니다. 반대로 경로 제한이나 구조화된 오류가 필요한 업무에서는 전용 도구가 유용할 수 있습니다. 판단 기준을 도구 목록의 길이 대신 작업 결과에 두는 것입니다.
복구 기능은 실패 원인에 맞춰 검토합니다. 출력 한도, 문맥 초과, 도구 실행 오류, 모델의 완료 선언을 구분하고 재시도 가능한 상태를 정합니다. 모든 실패에 같은 프롬프트를 다시 보내는 방식은 원인을 가릴 수 있습니다. 어느 시점까지 작업이 보존됐는지, 재시도 뒤 무엇을 다시 검증해야 하는지도 정해 둡니다.
연구 결과를 이유로 권한 확인이나 승인 절차를 빼서는 안 됩니다. 품질을 높이려는 계획 단계와 외부 쓰기를 통제하는 경계는 목적이 다릅니다. 단순화할 대상은 효과를 설명하지 못하는 중복 단계입니다. 데이터 접근 범위와 되돌릴 수 없는 행동에 대한 통제는 업무 요구로 따로 유지해야 합니다.
Agensh의 다수 에이전트 실험은 무엇을 보여줬나요
마이크로소프트의 Agensh 논문은 GPT-5.6-sol의 high 추론 설정과 Copilot 하네스를 사용했습니다. 인터넷을 차단하고, 참조 실행 결과와 제공 문서로 프로그램 동작을 재구현하는 ProgramBench의 어려운 5개 과제를 평가했습니다. 시간 예산은 6시간이었습니다.
해당 조건에서 에이전트 1개와 128개의 평균 최종 테스트 통과율은 각각 19.31%, 28.78%였습니다. 차이는 9.47%포인트이며, 상대 개선율로는 약 49%입니다. 이는 과제 전체를 완수한 비율과 구분해야 합니다. Pandoc 과제에서만 규모를 1,024개까지 늘렸고, 그 비교의 통과율은 33.89%에서 55.06%로 올랐습니다. 공식 저장소의 결과 요약에 조건과 수치가 함께 나와 있습니다.
같은 시간 예산은 같은 비용 예산과 다릅니다. 에이전트가 늘면 총 모델 사용량과 실행 자원도 함께 따져야 합니다. 논문은 작업자를 순차적으로 활성화하므로 인원수에 시간 한도를 곱해 실제 사용량이라고 계산해서도 안 됩니다. 이 결과만으로 비용 효율이나 중앙 관리자 방식 대비 우위를 결론 내릴 수는 없습니다. 논문 실험 상세를 함께 읽어야 합니다.
Agensh는 개별 하네스 위에 협업 층을 둡니다. 공유 작업 공간, 메시지, 재사용할 발견을 남기는 문맥을 통해 작업자가 범위를 정하고 검증한 결과를 통합합니다. 중앙 관리자가 없다는 설명에도 협업 기반 시설은 존재합니다. 논문의 구조 설명은 이 두 층을 구분합니다.
따라서 빌더가 가져올 질문은 우리 업무에도 그만큼 나눠 진행할 일이 있는가입니다. 현재 과제가 앞 단계의 결과를 기다려야만 풀리는지, 독립적으로 조사하거나 구현할 부분이 있는지 먼저 봅니다. 업무가 분할되지 않은 상태에서 작업자만 늘리면 무엇을 병렬화하려 했는지 평가하기도 어렵습니다.
다수 에이전트를 검토할 조건
병렬화를 평가할 후보는 작업 경계를 먼저 그릴 수 있는 업무입니다. 서로 다른 입력 형식을 조사하거나, 합의된 인터페이스를 따르는 모듈을 구현하는 상황을 가정할 수 있습니다. 이때 각 작업의 완료 조건과 최종 통합 조건을 따로 써 봅니다. 완료 조건을 나누기 어렵다면 먼저 요구사항을 더 구체화할 필요가 있습니다.
공유하는 파일과 실행 자원도 경계에 넣어야 합니다. 코드 경로가 달라도 같은 데이터 파일이나 테스트 포트, 빌드 산출물을 건드릴 수 있습니다. 평가에서는 동시 실행 때문에 생긴 오류를 모델의 구현 실패와 구분해 둡니다. 그래야 작업자를 줄일지, 자원을 격리할지 결정할 수 있습니다.
정보를 공유하는 방식도 측정 대상입니다. 동료의 발견을 전부 매 호출에 넣을 필요가 있는지, 현재 작업과 관련된 항목만 찾아 읽어도 되는지 비교합니다. 공유 기록에는 무엇을 관찰했는지와 어떤 조건에서 성립했는지를 남기는 편이 좋습니다. 아직 검증하지 않은 추정을 사실처럼 전파하면 여러 작업이 같은 잘못된 전제를 따를 수 있습니다.
통합 가능 여부는 개별 작업의 성공과 별도로 확인합니다. 각자 통과한 변경도 합친 뒤에는 깨질 수 있습니다. 누구의 어떤 변경을 기준으로 검사했는지, 통합 후 어떤 검증을 다시 수행했는지 남겨야 합니다. 코드가 많이 생성됐다는 신호보다 최종 결과에 반영된 변경이 무엇인지가 도입 판단에 더 직접적으로 쓰입니다.
시간 제약은 병렬화의 목적을 구체화해 줍니다. 기다릴 수 있는 업무라면 낮은 비용을 우선할 수 있고, 납기가 고정된 업무라면 허용 예산 안에서 완료 시점을 앞당기는 것이 중요할 수 있습니다. 어느 쪽이든 목표를 실행 전에 정해야 합니다. 결과를 보고 나서 비용과 시간 중 유리한 축으로 목표를 바꾸면 비교가 흔들립니다.
도입 전에 남길 측정표
아래 항목은 두 연구를 업무 평가로 옮기기 위한 제안입니다. 논문의 점수를 우리 서비스의 예상 성과로 대입하기보다, 같은 입력과 완료 기준으로 후보 구성을 비교하는 데 사용하면 좋겠습니다.
| 항목 | 남길 기록 | 결정에 쓰는 방법 |
|---|---|---|
| 완료 품질 | 합의한 테스트 결과, 누락 요구, 회귀 | 완료 선언과 실제 통과를 구분합니다 |
| 사용량과 비용 | 일반·캐시 입력, 출력, 도구·실행 비용 | 같은 가격표와 실제 청구를 나눠 봅니다 |
| 소요 시간 | 시작부터 검증·통합까지의 경과 시간 | 빠른 첫 응답과 완성 시점을 구분합니다 |
| 실패와 복구 | 종료 사유, 재시도, 보존된 진행 | 어떤 보완이 필요한지 찾습니다 |
| 협업 부담 | 중복 작업, 충돌, 검토·통합 대기 | 병렬화가 막히는 곳을 찾습니다 |
| 사람의 개입 | 수정·승인·복구에 쓴 시간과 사유 | 자동 실행 비용 밖의 부담을 봅니다 |
실패한 실행의 비용도 합산해야 합니다. 성공한 실행만 추려 평균 비용을 내면 재시도 비용이 사라집니다. 완료된 작업에 든 비용을 계산할 때에는 해당 평가 묶음의 전체 사용량을 함께 제시하고, 무엇을 성공으로 판정했는지 적습니다. 성공이 없는 묶음은 작업당 성공 비용을 억지로 숫자로 만들지 않고 실패로 남깁니다.
시간도 전체 경로로 잽니다. 모델이 답을 쓰는 시간 밖에 도구 실행, 호출 제한 대기, 검토 대기, 충돌 해결이 있습니다. 평균과 함께 오래 걸린 실행을 살펴야 납기 위험을 볼 수 있습니다. 사람의 개입을 기록할 때에는 중간에 요구를 바꾼 경우와 에이전트 오류를 수습한 경우를 구분하는 편이 좋습니다.
평가 묶음에는 평소 작업과 실패하기 쉬운 작업을 함께 둡니다. 정상 입력만 있으면 복구 기능의 가치를 보기 어렵고, 극단적 사례만 있으면 일상 비용을 놓칠 수 있습니다. 구성마다 같은 작업을 주고, 실행 전에 완료 기준을 고정합니다. 실패한 사례를 결과표에서 조용히 제외하지 않는 것도 중요합니다.
변경을 채택할 실험 순서
우선 현재의 작은 구성을 보존하고 같은 작업을 다시 실행해 봅니다. 같은 설정에서도 결과와 비용이 얼마나 달라지는지 알아야 새 구성이 만든 차이를 읽을 수 있습니다. 성공률을 비교할 때에는 전체 평균뿐 아니라 같은 과제가 어떻게 바뀌었는지 짝지어 살펴봅니다. 다른 실패를 우연히 메웠는지, 반복해서 같은 문제를 해결하는지 구분하기 위해서입니다.
그다음은 변경 이유가 분명한 후보를 고릅니다. 문맥을 줄이는 변경, 실패 복구를 더하는 변경, 작업자를 늘리는 변경을 각각 평가하면 원인을 설명하기 쉽습니다. 모델과 추론 설정까지 동시에 바꿨다면 결과는 그 조합의 결과로 남겨야 합니다. 하네스만의 개선이라고 이름 붙이지 않습니다.
반복 실행 횟수와 과제 수는 보고 싶은 차이에 맞춰 정합니다. 작은 평가 묶음에서 근소한 차이가 보였을 때에는 실행별 결과와 불확실성을 함께 보고 추가 평가가 필요한지 결정합니다. 샘플이 적다는 이유로 모든 차이를 무시할 필요도 없고, 한 번의 최고 기록을 기본 성능으로 삼을 필요도 없습니다.
채택 기준에는 품질 하한, 허용 비용, 완료 시간, 사람의 개입 한도를 함께 적습니다. 비용이 줄어도 필수 검증을 통과하지 못하면 채택할 수 없습니다. 시간이 줄어든 대신 운영자의 복구 부담이 커졌다면 그 교환을 드러내야 합니다. 추가된 단계마다 어떤 기록이 그 단계를 유지할 근거인지 연결해 두면 이후 정리도 쉬워집니다.
운영에 반영한 뒤에는 되돌릴 기준도 남깁니다. 평가에 없던 작업이 들어오거나 모델·하네스 버전이 바뀌면 같은 구성이 다른 행동을 보일 수 있습니다. 이전 구성과 사용량 기록을 보존해 두면 변경 뒤의 문제를 비교할 수 있습니다. 채택 당시의 점수만 남기는 것보다 어떤 조건에서 선택했는지를 남기는 편이 유용합니다.
복잡도를 늘리기 전에 정할 것
지금 필요한 것이 실행 실패를 줄이는 보완인지, 독립적인 작업을 동시에 진행할 여력인지부터 정하면 좋겠습니다. 호출당 문맥을 줄일 필요가 있을 수도 있고, 검증된 결과를 합치는 과정이 병목일 수도 있습니다. 같은 성공 기준 아래에서 비용과 시간, 통합 이후의 품질을 함께 남기면 추가한 기능의 값을 판단할 수 있습니다.
빌더에게 유용한 하네스는 필요한 작업을 끝내는 데 기여하는 구성을 설명할 수 있는 하네스입니다. 작은 기준선에서 출발해 실제로 줄이고 싶은 실패와 기다림을 고르고, 변화가 반복되는지 살펴봅시다. 복잡도의 크기보다 어떤 조건에서 도움이 됐는지가 다음 선택의 근거가 됩니다.
마치며
하이프마크 빌더 커뮤니티는 에이전트를 만들 때 참고할 연구와 운영 판단 기준을 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.