Harness-of-Harness가 보여준 다일 자율 개발, 코딩 에이전트 운영 방식이 바뀌는 이유 | DAKER 커뮤니티

2026년 9월 1일 상하이 AI Lab이 Harness-of-Harness(HoH)를 arXiv에 공개했습니다. 기존 코딩 에이전트 하네스 위에 계획–코딩–테스트 반복 루프를 얹어, 사람 개입 없이 소프트웨어를 여러 날에 걸쳐 개선하는 방식입니다. 새 에이전트를 처음부터 설계하는 대신, 이미 쓰는 하네스를 더 오래, 더 검증 가능하게 운용하는 쪽에 초점을 둔 점이 눈에 띕니다.

지금 이 내용을 읽을 만한 이유도 여기에 있습니다. 코딩 에이전트가 오래 돌았다는 사실만으로는 재현도 비교도 어렵습니다. HoH는 긴 자율 실행을 작은 증분, 독립 평가, 버전 이력으로 나눠 다루는 틀을 제시합니다. 오늘 팀이 바로 가져갈 수 있는 포인트는 화려한 데모보다 제출 문서와 실행 기록을 어떻게 남길지에 가깝습니다.

논문은 2026-09-01 arXiv에 올라왔습니다. 초록은 arXiv:2609.01481에서 확인할 수 있습니다. 영문 제목은 Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement입니다. 저자는 Haoyang Yan, Min-Le Su, Hangfan Zhang, Zhanhao Li, Chen Zhang, Shao Zhang, Yang Chen, Lei Bai, Shuyue Hu (Shanghai AI Laboratory)입니다. PDF는 같은 번호의 pdf이며, 코드는 GitHub Flesymeb/HarnessOfHarness에 공개되어 있습니다. 이 글은 제공된 사실과 초록·본문에서 확인한 범위만 옮깁니다.

코딩 에이전트 위에 개선 루프를 올린다는 것

HoH의 핵심은 기존 코딩 에이전트 하네스를 반복 루프로 조직하는 데 있습니다. 각 루프에서 단순한 버그 수정만 보는 것이 아니라, 수리와 능력 확장을 함께 다룹니다. 개발 범위는 작고 검증 가능한 증분으로 나누고, 구현 중 테스트와 독립 평가를 분리합니다. 중요한 것은 검증 가능한 산출물을 요구한다는 점이지, 에이전트의 내부 워크플로를 세세하게 고정한다는 뜻은 아닙니다.

또한 산출물, 역할별 도구, 스킬을 단계적으로 노출하고, 새로 만드는 것보다 재사용을 유도합니다. 버전이 남는 프로젝트 이력을 유지하면서, 요구사항을 단순한 코드 조각이 아니라 실행 가능한 계획과 검증 단위로 바꾸게 만드는 구조입니다.

에이전트가 오래 돌았다는 설명보다, 증분 단위와 독립 평가, 버전 이력이 함께 남는 구조가 더 중요합니다.

세 벤치와 세 하네스–모델 쌍에서 나온 결과

평가 벤치는 GameCraft-Bench, FrontierSWE, ProgramBench입니다. 하네스–모델 쌍은 Codex with GPT-5.5(high), OpenCode with DeepSeek-V4-Pro, Pi with MiniMax-M3입니다. 논문은 세 쌍 모두에서 HoH가 대응 단독 하네스를 앞섰다고 보고합니다. 3회 반복 후 평균 상대 이득은 52.25%, 최대 이득은 82.86%입니다.

절대 이득은 GameCraft-Bench에서 16.62–22.08점, FrontierSWE에서 19–29점, ProgramBench에서 6.09–16.85점으로 제시됩니다. FrontierSWE에서는 Codex+GPT-5.5(high)가 10회 반복 동안 22%에서 72.67%까지 올랐습니다. 또 다른 설정에서는 70회가 넘는 다일 배포를 통해 1인칭 슈팅 게임을 자율 개발했고, 스토리, 핵심 메커닉, 사람 플레이 가능 경험, 비주얼, 오디오 통합을 보고합니다.

논문이 강조하는 것은 한 번의 제출 성능보다, 반복을 거치며 성능이 계속 개선되는 운영 방식입니다.

실무 문서로 옮길 때 남겨야 할 것

이 논문을 팀 운영에 적용하려면 실행 로그를 한 덩어리 채팅처럼 남기기보다 반복, 증분, 평가 단위로 나누는 것이 좋습니다. 각 반복에서 무엇을 고쳤는지, 무엇을 새로 확장했는지, 어떤 평가로 확인했는지를 분리해 기록하면 됩니다. 구현 중 테스트와 최종 평가 명령이 같은 스크립트에 섞이지 않게 두는 것도 중요합니다.

공개 저장소를 참고할 때는 Flesymeb/HarnessOfHarness의 README와 라이선스를 먼저 확인하는 편이 좋습니다. 출처 URL을 비우지 않고, 하네스 이름, 모델, 반복 횟수, 독립 평가 스위트를 문서에서 따로 적어 두면 비교 축이 분명해집니다.

긴 자율 실행일수록 실패 지점이 가려지기 쉽습니다. 어디까지 사람 개입 없이 진행됐는지, 어디서 멈췄는지, 반복 횟수와 시간, 토큰 상한이 무엇이었는지를 한 페이지에 정리해 두면 재현성과 해석 가능성이 높아집니다.

README 구조로 바꾸면 더 선명해집니다

HoH의 planning–coding–testing 루프는 그대로 제출 문서의 구조가 될 수 있습니다. 계획 절에는 요구사항 분해와 검증 가능한 산출물 목록을 두고, 코딩 절에는 변경 파일과 재사용 모듈을 적으면 됩니다. 테스트 절에는 구현 중 테스트 명령과, 그와 분리된 독립 평가 명령을 함께 두는 식이 자연스럽습니다.

FrontierSWE에서 10회 반복으로 22%에서 72.67%까지 오른 사례는 반복을 오래 돌릴 수 있다는 점만 보여주는 것이 아닙니다. 언제 멈출지 기준을 미리 정해야 한다는 힌트로도 읽을 수 있습니다. 점수 정체나 회귀가 이어질 때 사람 점검을 넣는 규칙을 두면 운영이 더 명확해집니다.

70회 이상 반복한 FPS 개발 사례도 마찬가지입니다. 에이전트가 게임을 만들었다는 한 줄보다, 스토리, 핵심 메커닉, 플레이 가능 여부, 비주얼, 오디오를 나눠 증거를 붙이는 방식이 더 유용합니다. 배포 주소, 플레이 영상, 빌드 커밋을 한 페이지에 모아 두면 결과를 해석하기 쉬워집니다.

배포가 제출이고, 올린 링크가 제출이라는 관점은 긴 자율 실행을 설명 가능한 결과물로 바꾸는 데 도움이 됩니다.

이 글이 말하지 않는 것

모든 코딩 벤치에서 단독 하네스를 이긴다는 뜻은 아닙니다. 이 글은 논문이 보고한 세 벤치, 세 쌍, 상대·절대 이득 범위만 옮깁니다.

70회 반복 FPS가 상용 게임 품질이라는 보증도 아닙니다. 다일 자율 배포에서 스토리, 메커닉, 플레이 가능, 비주얼, 오디오를 갖췄다고 보고한 내용입니다.

특정 모델 가중치를 HoH가 공개했다는 뜻도 아닙니다. 프레임워크가 기존 하네스 위에서 동작한다는 설명에 가깝습니다.

DACON·DAKER 공식 우승 공지 역시 아닙니다. 빌더가 옮겨 볼 수 있는 방법과 숫자를 정리한 글입니다.

상대 이득 52.25%가 모든 시드와 모든 과제에서 같다는 의미도 아닙니다. 논문이 보고한 집계 수치입니다.

참고 자료

arXiv:2609.01481 — Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement (2026-09-01)
PDF
GitHub Flesymeb/HarnessOfHarness

여러분의 팀이라면 긴 코딩 에이전트 실행 기록을 어떤 기준으로 증분과 평가 단위로 나눠 보시겠습니까?