LoopArena가 보여준 것: 코딩 에이전트의 Controller를 따로 평가해야 하는 이유 | DAKER 커뮤니티

코딩 에이전트를 잘 쓰는 팀일수록 이제는 모델 하나의 성능보다, 그 모델을 어떤 루프로 운영하느냐가 결과를 가르는 경우가 많습니다. 진행을 어떻게 감시할지, 언제 검증을 돌릴지, 다음 행동을 무엇으로 정할지에 따라 같은 Worker도 전혀 다른 성과를 낼 수 있기 때문입니다.

그런데 끝단의 성공과 실패만 보면 무엇이 좋았는지 분리하기 어렵습니다. 루프 안내가 좋았는지, 아니면 Worker 자체가 강했는지 한 번에 섞여 보이기 쉽습니다. 2026년 8월 28일 arXiv에 공개된 LoopArena는 바로 이 지점을 겨냥해 Controller와 Worker를 분리해 측정합니다.

한 번의 끝단 결과만으로는 루프 안내의 품질과 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가 평가하는 대상은 Worker가 아니라 Controller입니다. 각 코딩 라운드 뒤에 Controller는 실행의 구조화된 요약을 받고, 고정된 Worker 코딩 에이전트에게 다음에 무엇을 하거나 검증할지 지시하거나 중단을 결정합니다. Worker는 고정이고, 바뀌는 쪽은 Controller입니다. 이 분리가 벤치의 핵심입니다.

Worker를 고정한 뒤 Controller의 지시 품질을 따로 재는 것이 LoopArena의 중심 설계입니다.

DACON과 DAKER처럼 짧은 기간 안에 에이전트 루프를 돌리는 환경에서는 이 구분이 특히 중요합니다. 모델 하나를 고르는 일과 루프 지휘 방식을 고르는 일을 같은 표에 놓으면, 무엇이 성능 차이를 만들었는지 해석하기 어려워집니다.

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입니다.

성공률만 보면 놓치는 것이 있고, 비용만 봐도 놓치는 것이 있습니다. LoopArena는 둘을 함께 보게 만듭니다.

이 구조는 실무에도 그대로 옮겨볼 수 있습니다. 값싼 다음 행동 선택 점검을 먼저 두고, 과제 조각에서 반복 제어를 시험한 뒤, 마지막에 전체 과제 성공률과 비용을 함께 적는 방식입니다. 초록이 세 설정을 나란히 둔 이유도 여기에 있습니다.

끝단 성공만으로 루프를 평가하지 않습니다

초록이 강조하는 지점은 분명합니다. 한 번의 끝단 결과만으로는 그것이 루프 안내의 성과인지, Worker 능력의 성과인지 말해주지 않습니다. 제출이 통과했다고 해서 곧바로 루프 설계가 좋았다고 적기 어려운 이유입니다.

따라서 Worker를 바꾼 실험과 Controller를 바꾼 실험은 분리해 기록하는 것이 좋습니다. Controller 프롬프트, 중단 규칙, 검증 체크리스트와 같은 항목은 Worker 모델 이름과 다른 칸에 두어야 해석이 가능합니다. 오래된 진행 메모 신뢰, 검증 생략, 예산 오배분, 조기 중단 같은 실패도 루프 쪽 점검 항목으로 따로 보는 편이 적절합니다.

Controller 문제와 Worker 문제를 같은 실패 로그에 섞어 두면 원인을 다시 찾기 어려워집니다.

공개 코드가 있어 재현의 출발점이 분명합니다

평가 코드가 GitHub에 공개되어 있으므로, 저장소와 초록을 함께 보며 자체 루프 Controller 후보를 정리해 볼 수 있습니다. 이때 계획에는 Worker를 어떻게 고정할지, Type I·II·III에 대응하는 자체 점검을 어떻게 둘지, Strict Success와 비용을 어떤 형식으로 적을지 포함하는 것이 좋습니다.

다른 팀의 루프 데모를 볼 때도 같은 기준을 적용할 수 있습니다. Controller와 Worker가 한 프롬프트에 섞여 있으면 LoopArena식 비교는 어려워집니다. 지시 로그와 검증 결과를 저장소에 남기고 날짜를 기록해 두면 재현성과 비교 가능성이 높아집니다.

이 연구를 읽을 때 과장하지 말아야 할 점

이 글은 Worker 코딩 모델 순위표를 소개하는 글이 아닙니다. 평가 대상은 Controller이며, Worker는 고정입니다.

또 모든 루프가 24.69%를 낸다는 뜻도 아닙니다. 이는 전체 과제에서 관찰된 최고 Strict Success Rate입니다. 우리 과제의 실측처럼 옮겨 적으면 안 됩니다.

Type II가 Core와 Spearman ρ=0.9747로 비슷한 순서를 만든다는 보고 역시 Type III가 필요 없다는 뜻은 아닙니다. 비용이 낮은 평가와 전체 과제 평가는 서로 다른 역할을 가집니다.

마찬가지로 평균 64.4% 비용 감소도 언제나 같은 폭으로 줄어든다는 보장이 아니라, Controller들 사이 짝 비교에서 보고된 추정 추론 비용 감소 평균입니다.

초록의 숫자는 연구 결과이지, 그대로 가져다 쓸 수 있는 우리 팀의 실측값은 아닙니다.

참고 자료

arXiv:2608.28281
PDF
GitHub AMAP-ML/LoopArena

여러분의 팀에서는 Controller와 Worker를 지금 얼마나 분리해서 기록하고 계신가요?