코딩 에이전트에 개선 루프를 씌워 여러 날을 돌립니다 | DAKER 커뮤니티

2026년 9월 1일 상하이 AI Lab이 Harness-of-Harness(HoH)를 arXiv에 공개했습니다. 기존 코딩 에이전트 하네스 위에 계획–코딩–테스트 반복 루프를 씌워, 사람 개입 없이 소프트웨어를 여러 날에 걸쳐 개선합니다. Codex+GPT-5.5, OpenCode+DeepSeek-V4-Pro, Pi+MiniMax-M3 세 쌍에서 GameCraft-Bench·FrontierSWE·ProgramBench 기준 단독 하네스 대비 평균 상대 이득 52.25%, 최대 82.86%(3회 반복 후)를 보고합니다. FrontierSWE에서는 Codex+GPT-5.5(high)가 10회 반복으로 22%에서 72.67%까지 올랐습니다. 70회 이상 반복 배포로 FPS 게임도 자율 개발했다고 적습니다. 오늘 팀은 “한 번에 제출” 대신 “검증 가능한 작은 증분 + 독립 평가”를 README에 나눕니다.

코딩 에이전트에 개선 루프를 씌워 여러 날을 돌립니다

논문은 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는 새 에이전트를 처음부터 설계하기보다, 이미 쓰는 코딩 에이전트 하네스의 실행을 반복 루프로 조직합니다. 루프마다 수리와 능력 확장을 같이 보고, 개발 범위를 작고 검증 가능한 증분으로 자릅니다. 구현 중 테스트와 독립 평가를 분리합니다. 검증 가능한 산출물만 제약하고, 에이전트 워크플로 자체를 세세히 규정하지는 않습니다.

산출물·역할별 도구·스킬을 단계적으로 노출하고, 다시 만들기보다 재사용을 유도합니다. 버전 있는 프로젝트 이력을 유지합니다. 에이전트가 요구사항을 코드 조각이 아니라 실행 가능한 계획과 검증 단위로 옮기게 만드는 것이 핵심입니다.

DACON 알고리즘 대회와 DAKER 바이브코딩 해커톤 모두, “에이전트가 하루 종일 돌았다”는 문장만으로는 재현이 어렵습니다. 오늘 팀이 가져갈 한 줄은 이것입니다. 증분 단위·독립 평가 스위트·버전 이력을 제출 README에 같은 형식으로 적습니다.

세 벤치와 세 하네스–모델 쌍

평가 벤치는 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을 비우지 않습니다. DAKER 월간 해커톤 README의 에이전트 항목에 하네스 이름·모델·반복 횟수·독립 평가 스위트를 분리해 적습니다.

긴 자율 실행을 자랑할수록 실패 지점을 숨기기 쉽습니다. 어디까지 사람 개입 없이 갔는지, 어디서 멈췄는지 한 페이지로 적습니다. 토큰·시간·반복 상한을 공개합니다.

Controller와 Worker를 나누는 팀이면, 루프 지시와 모델 카드를 한 프롬프트에 섞지 마십시오. 지시 커밋 해시와 평가 로그 해시를 나란히 둡니다.

도구 권한과 공유 워크스페이스를 쓰는 팀이면 전역 설정을 별도 파일로 둡니다. 비밀키를 프롬프트에 넣지 않습니다. 실행 트레이스를 다른 사람이 열 수 있는 주소에 올립니다.

반복 루프를 제출 문서로 옮기는 방법

HoH의 planning–coding–testing 루프는 해커톤 README의 절 제목으로 바로 옮길 수 있습니다. 계획 절에는 요구사항 분해와 검증 가능한 산출물 목록을 둡니다. 코딩 절에는 변경 파일과 재사용 모듈을 적습니다. 테스트 절에는 구현 중 테스트 명령과, 그와 분리된 독립 평가 명령을 나란히 둡니다.

절대 이득 구간(GameCraft 16.62–22.08, FrontierSWE 19–29, ProgramBench 6.09–16.85)은 “우리 점수가 올랐다”는 문장 대신, 비교 축을 복제할 때만 씁니다. 10회 반복으로 22%에서 72.67%로 오른 FrontierSWE 사례는, 반복을 멈출 기준을 미리 정하라는 힌트로 읽습니다. 점수 정체·회귀가 두 번 연속이면 사람 점검을 넣는 규칙을 팀에 둡니다.

다일 FPS 배포 보고는 “에이전트가 게임을 만들었다”는 한 줄로 끝내지 마십시오. 스토리·핵심 메커닉·플레이 가능 여부·비주얼·오디오를 체크리스트로 나누고, 각 항목의 증거 링크를 붙입니다. DAKER 월간 해커톤에서도 배포 주소와 플레이 영상·빌드 커밋을 한 페이지에 모읍니다.

세 하네스–모델 쌍을 모두 재현할 필요는 없습니다. 팀이 실제로 쓰는 한 쌍만 고르고, 왜 그 쌍인지 한 문장으로 적습니다. GPT-5.5·DeepSeek-V4-Pro·MiniMax-M3 이름을 우리 실측 모델로 바꿔 쓰지 않습니다. 논문 조건과 우리 스택을 표의 다른 열에 둡니다.

이 글이 아닌 것입니다

모든 코딩 벤치에서 단독 하네스를 이긴다는 주장이 아닙니다. 보고된 세 벤치·세 쌍·상대·절대 이득 범위만 옮깁니다.

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

특정 모델 가중치를 HoH가 공개한다는 뜻이 아닙니다. 프레임워크가 기존 하네스 위에서 돈다는 설명입니다.

DACON·DAKER 공식 우승 공지가 아닙니다. 빌더가 옮길 수 있는 방법과 숫자 안내입니다.

상대 이득 52.25%가 모든 시드·모든 과제에서 같다는 확장이 아닙니다. 논문이 보고한 집계입니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2609.01481pdf를 같은 탭에 둡니다. 저자와 제출일 2026-09-01을 메모 첫 줄에 적습니다.

둘째, 코드를 북마크하십시오. GitHub Flesymeb/HarnessOfHarness와 라이선스를 저장합니다.

셋째, 우리 에이전트 파이프라인을 반복 표로 옮기십시오. 계획·코딩·테스트·독립 평가 열을 만듭니다. DAKER 월간 해커톤이나 DACON 코드 제출 과제 중 하나에 맞춥니다.

넷째, 비교 축만 복제하십시오. GameCraft·FrontierSWE·ProgramBench 숫자를 우리 실측처럼 쓰지 않습니다.

다섯째, 증분 크기와 검증 산출물을 한 페이지로 적으십시오. 무엇이 “완료”인지 체크리스트로 둡니다.

여섯째, 다일 실행 한도를 README에 남기십시오. 반복 횟수·시간·토큰은 논문 조건과 우리 실측을 섞지 않습니다.

일곱째, 버전 이력과 평가 로그를 공개 링크로 올리십시오. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2609.01481 — Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement (2026-09-01) · PDF · 코드/자료