코딩 루프를 지휘하는 제어 모델을 따로 평가합니다 | DAKER 커뮤니티
2026년 8월 28일 Yi Wang 연구팀이 코딩 에이전트를 돌리는 루프를 지휘하는 제어 모델(Controller)을 따로 평가하는 LoopArena를 arXiv에 공개했습니다. 실무에서는 프롬프트를 매번 손으로 쓰기보다, 진행을 감시하고 일을 배정하고 검사를 돌리고 다음에 무엇을 할지 정하는 루프를 설계합니다. 이를 Loop Engineering이라고 부릅니다. 그런데 한 번의 끝단 성공·실패만으로는 루프 안내가 좋았는지, Worker 코딩 에이전트 능력이 좋았는지가 갈라지지 않습니다. LoopArena는 그 구분을 위해 Controller와 Worker를 분리해 측정합니다.
논문은 2026년 8월 28일 arXiv에 올라왔습니다. 초록은 arXiv:2608.28281에서 확인할 수 있습니다. 저자는 Yi Wang, Haopeng Zhang, Chengxiang Huang, Rui Dai, Kaikui Liu, Piotr Koniusz, Xiangxiang Chu입니다. PDF는 같은 번호의 pdf입니다. 벤치마크 데이터와 평가 코드는 GitHub AMAP-ML/LoopArena에 공개되어 있습니다. 오늘 본문은 초록이 적은 범위만 옮깁니다. 초록에 없는 벤치 이름과 퍼센트는 쓰지 않습니다.
루프와 Worker를 나눕니다
Loop Engineering은 코딩 에이전트 주변에서 개발 작업을 조직하는 실천입니다. 루프는 진행을 감시하고, 일을 배정하고, 검사를 돌리고, 다음에 에이전트가 할 일을 정합니다. 능력이 있는 코딩 에이전트가 있어도 루프는 오래된 진행 메모를 믿거나, 필요한 검증을 건너뛰거나, 예산을 잘못된 방향에 쓰거나, 제출이 안전한 시점 전에 멈출 수 있습니다.
LoopArena가 평가하는 대상은 Controller입니다. 각 코딩 라운드 뒤에 Controller는 실행의 구조화된 요약을 받고, 따로 고정된 Worker 코딩 에이전트에게 다음에 무엇을 하거나 검증할지 지시하거나 중단을 결정합니다. Worker는 고정입니다. 바꾸는 쪽은 Controller입니다. 이 한 줄이 벤치의 핵심입니다.
DACON과 DAKER처럼 팀이 짧은 기간에 에이전트 루프를 돌리는 자리에서는, “모델 하나”만 고르는 것과 “루프 지휘”를 고르는 것을 같은 표에 두지 말아야 합니다. 오늘 팀이 가져갈 한 줄은 이것입니다. Worker를 고정한 뒤 Controller 지시 품질을 따로 재십시오.
Type I·II·III로 비용을 나눕니다
LoopArena는 실행 범위와 비용이 다른 세 설정으로 Controller를 평가합니다. Type I은 Worker를 평가 시점에 돌리지 않고, 실행으로 검증된 질문을 통해 다음 단계 Loop Contract 선택을 점수화합니다. Type II는 전체 과제 중 고른 조각에 대해 반복 제어를 실행합니다. Type III는 원래 상태에서 짝을 이룬 전체 과제를 평가합니다.
전체 과제에서 관찰된 최고 Strict Success Rate는 24.69%입니다. 긴 구간 루프 제어에는 개선 여지가 크다는 뜻입니다. Controller들 사이에서 추정 추론 비용의 짝 비교 감소는 평균 64.4%입니다. Type II는 본 기준 Core에서 비슷한 순서를 만들며, Spearman ρ는 0.9747입니다. 없는 리더보드 순위를 붙이지 않습니다. 초록이 준 숫자만 옮깁니다.
빌더 팀에 옮기면 세 줄입니다. 첫째, Type I처럼 값싼 다음 행동 선택 점검을 먼저 둡니다. 둘째, Type II처럼 과제 조각에서 반복 제어를 돌립니다. 셋째, Type III처럼 전체 과제 성공률과 비용을 같이 적습니다. 성공률만 보면 비용 감소 64.4%를 놓칩니다.
끝단 성공만으로 루프를 평가하지 않습니다
초록은 한 번의 끝단 결과가 루프 안내인지 Worker 능력인지 말해 주지 않는다고 적습니다. 해커톤에서 제출이 통과했다고 해서 루프 설계가 좋았다고 적지 마십시오. Worker를 바꾼 실험과 Controller를 바꾼 실험을 표에서 분리합니다.
DAKER 월간 해커톤 제출 README에는 Controller 프롬프트·중단 규칙·검증 체크리스트 URL을 Worker 모델 이름과 다른 칸에 둡니다. “모델 이름만” 적힌 문서는 LoopArena가 지적한 혼동을 그대로 남깁니다. 배포가 제출입니다. 올린 링크가 제출입니다.
오래된 진행 메모를 믿는 실패, 검증 생략, 예산 오배분, 조기 중단은 루프 쪽 점검 항목으로 고정합니다. Worker 코드 품질 이슈와 섞지 않습니다. 실패 로그에 태그를 달아 Controller 지시 문제와 Worker 실행 문제를 나눕니다.
공개 코드로 재현을 시작합니다
평가 코드가 GitHub에 있으므로, 팀은 오늘 저장소와 초록을 같은 탭에 두고 자체 루프 Controller 후보를 적어 볼 수 있습니다. 계획에는 Worker 고정 방법, Type I·II·III에 대응하는 자체 점검, Strict Success와 비용 추정 칸이 들어가야 합니다.
다른 팀의 루프 데모를 받을 때도 같은 규칙을 씁니다. Controller와 Worker가 한 프롬프트에 섞여 있으면 LoopArena식 비교가 불가능합니다. DAKER와 DACON 제출은 다른 사람이 열 수 있는 주소를 요구합니다. 지시 로그와 검증 결과를 저장소에 두고 날짜를 남기십시오.
오늘 팀이 Worker만 바꾸고 Controller 지시를 비우면, 내일 긴 과제에서 24.69% 구간에 머물 가능성이 큽니다. 그 순환을 끊는 일이 이 글을 읽는 이유입니다. Controller를 따로 재십시오.
해커톤 루프 표를 나눕니다
해커톤처럼 시간이 짧을수록 Type I 성격의 다음 행동 선택 점검을 먼저 두는 편이 재현에 유리합니다. 전체 과제 Type III만 매일 돌리면 비용이 커집니다. 초록이 세 설정을 나란히 둔 이유를 팀 표에 그대로 옮기십시오.
팀이 오늘 할 일은 제출 페이지에 “Controller 규칙”과 “Worker 고정본”을 표로 나누는 것입니다. Controller 칸에는 중단 조건과 검증 호출을 적습니다. Worker 칸에는 모델·도구 버전을 적습니다. 초록이 말한 분리는 이 표가 공개 주소에 있을 때 성립합니다.
비용 칸도 같이 둡니다. Strict Success만 올리다가 추론 비용이 커지면 운영이 무너집니다. 초록의 평균 64.4% 비용 감소는 Controller 선택이 비용에도 영향을 준다는 신호입니다. 우리 표에도 성공과 비용을 같은 날짜에 적습니다.
Controller 지시문을 버전 관리하십시오. 날짜마다 지시문이 바뀌면 Type II 조각 평가의 순서가 흔들립니다. 저장소에 Controller 지시 커밋 해시를 남기고, Worker 고정본 해시와 나란히 적습니다. 해커톤 마감 직전에 두 해시를 한꺼번에 바꾸지 마십시오. 바꾼 쪽만 적어 재현을 지킵니다.
Spearman ρ=0.9747은 Type II가 본 Core 순서와 가깝다는 보고입니다. 우리 팀 표에도 “저비용 점검 순위”와 “전체 과제 순위”를 같은 주에 적어 두십시오. 둘이 어긋나면 Controller 규칙의 어느 문장이 긴 구간에만 영향인지 점검합니다. 없는 상관계수를 우리 데이터에 붙이지 않습니다.
Controller 평가 표를 주간 단위로 고정하십시오. 한 주에 Worker를 바꾸고 다음 주에 Controller만 바꾸면 인과가 섞입니다. 초록이 강조한 분리를 캘린더에도 적용합니다. DAKER 스프린트 보드에 “Worker 고정 주”와 “Controller 실험 주”를 칸으로 나누면 리뷰가 빨라집니다.
Loop Contract 선택 문항을 사내에 만들 때는 실행으로 검증된 정답을 같이 둡니다. Type I이 Worker를 돌리지 않는 이유는 비용입니다. 우리 팀도 값싼 문항 세트를 먼저 만들고, 통과한 Controller 후보만 Type II 조각으로 보냅니다. 문항 정답을 채팅에만 두지 말고 저장소에 둡니다.
추정 추론 비용을 적을 때는 토큰·라운드·도구 호출 중 무엇을 쓰는지 한 줄로 정의합니다. 초록의 64.4%는 짝 비교 평균입니다. 우리 표에도 같은 Controller 쌍을 나란히 두고 감소율을 계산합니다. 정의가 바뀌면 주간 비교가 무효입니다.
Strict Success Rate 24.69%는 최고 관찰값입니다. 팀 내부 목표가 더 높아도 괜찮습니다. 다만 공개 글이나 제출 문서에 초록 숫자를 우리 실측처럼 쓰지 마십시오. 출처 칸에 arXiv 번호를 남깁니다.
공개 평가 코드를 클론한 뒤에는 Type I 문항 형식만 먼저 읽어 사내 루프에 맞게 문항을 복제합니다. 전체 Type III를 즉시 돌리려 하면 비용이 커져 실험이 멈춥니다. 초록이 세 설정을 나눈 이유를 일정표에 반영하십시오.
이 글이 아닌 것입니다
Worker 코딩 모델 순위표가 아닙니다. 평가 대상은 Controller입니다. Worker는 고정입니다. 코딩 모델 리더보드로 바꾸어 쓰지 않습니다.
모든 루프가 24.69%를 낸다는 보장이 아닙니다. 전체 과제에서 관찰된 최고 Strict Success Rate입니다. 우리 과제 점수와 같다고 쓰지 않습니다.
Type II만 하면 Type III가 필요 없다는 처방이 아닙니다. Type II 순서가 Core와 Spearman ρ=0.9747로 비슷하다는 보고입니다. Type III를 폐기하라는 뜻이 아닙니다.
특정 회사 제품 출시 공지가 아닙니다. 연구 벤치마크와 공개 코드 안내입니다.
비용이 항상 64.4% 줄어든다는 수학 증명도 아닙니다. Controller들 사이 짝 비교에서 추정 추론 비용 감소 평균입니다. 과장하지 않습니다.
오늘 할 일
첫째, 초록과 PDF를 직접 여십시오. arXiv:2608.28281와 pdf를 같은 탭에 둡니다. 요약 카드만 보고 Loop Engineering을 정의하지 않습니다. 저자 목록과 제출일 2026-08-28을 메모 첫 줄에 적습니다.
둘째, 공개 코드를 북마크하십시오. AMAP-ML/LoopArena와 라이선스·README를 저장합니다. 클론만 하고 출처 URL을 비우지 않습니다.
셋째, 우리 팀의 Controller·Worker 분리 표를 한 페이지로 쓰십시오. Worker 고정본, Controller 지시 규칙, 중단 조건, 검증 체크를 네 칸으로 나눕니다. DAKER 월간 해커톤이나 DACON 코드 제출 과제 가운데 하나에 맞춰 적습니다.
넷째, Type I·II·III에 대응하는 자체 점검을 정하십시오. 값싼 다음 행동 선택, 조각 과제 반복 제어, 전체 과제 Strict Success를 표로 남깁니다. 한 지표만 보지 않습니다.
다섯째, 성공률과 추정 비용을 같은 표에 적으십시오. 초록의 24.69%와 64.4%를 우리 숫자로 바꾸어 쓰지 말고, 같은 형식의 칸만 복제합니다.
여섯째, 실패 로그에 Controller·Worker 태그를 달십시오. 오래된 메모 신뢰, 검증 생략, 예산 오배분, 조기 중단을 Controller 태그로 둡니다.
일곱째, 분리 표와 점검 결과를 공개 링크로 올리십시오. DAKER와 DACON에는 빌더와 대회 기록이 쌓여 있습니다. 배포가 제출입니다. 올린 링크가 제출입니다.