LoopArena로 코딩 루프 제어 능력 측정

왜 중요한가

기존 코딩 벤치마크는 대체로 Worker를 포함한 전체 에이전트 시스템의 최종 저장소 상태를 평가하므로, 실패 원인이 코딩 실행 능력인지 루프 제어 능력인지 분리하기 어렵습니다. LoopArena는 Worker, 도구, 실행 예산, 평가기를 고정하고 Controller만 바꿔 비교해 장기 작업에서 구현·검증·복구·종료로 전환하는 제어 능력을 별도 평가합니다.

핵심 기여

런타임 루프 제어를 직접 평가하는 벤치마크

별도의 코딩 Worker에 다음 작업을 지시하고 종료 시점을 결정하는 Controller의 능력을 장기 저장소 작업에서 직접 측정합니다.

Controller 비교를 위한 통제된 프로토콜

Worker, 코딩 도구, 작업 환경, 실행 예산, 평가기, 제어 인터페이스를 고정해 모델 간 차이가 Controller 역할에서 비롯되도록 구성합니다.

결정·작업 구간·전체 작업의 세 단계 평가

Type I은 단일 Loop Contract 선택을 실행 없이 평가하고, Type II는 작업 일부를, Type III는 원래 상태에서 전체 작업을 실행해 비용과 성능을 함께 비교합니다.

핵심 아이디어 이해하기

일반적인 코딩 에이전트는 ReAct 루프 안에서 저장소를 관찰하고, 추론하고, 도구를 실행하는 과정을 반복합니다. 긴 작업에서는 일부 테스트만 통과한 상태를 완료로 오인하거나, 구현이 끝난 뒤 필요한 검증을 건너뛰거나, 실패 후 복구하지 못할 수 있습니다. 한 번의 최종 저장소 점수만으로는 이런 문제가 Worker의 코딩 능력에서 발생했는지, 다음 행동을 정한 제어 정책에서 발생했는지 구분하기 어렵습니다.

LoopArena는 이 문제를 Controller–Worker 구조로 분리합니다. Worker는 저장소를 읽고 수정하며 테스트를 실행하지만, Controller는 코딩 도구 없이 Evidence Packet만 읽습니다. Controller가 Loop Contract로 다음 작업 구간이나 검증 조건을 정하면 하네스가 이를 Worker의 다음 프롬프트로 바꾸고, Worker의 라운드가 끝나면 다시 상태를 수집합니다.

이 구조에서 Controller의 출력은 단순한 텍스트 조언이 아니라 다음 실행 구간을 제한하는 제어 입력입니다. 따라서 Controller는 현재 상태에 맞춰 구현을 계속할지, 특정 검증을 요청할지, 종료할지를 결정해야 합니다. Type I은 이 결정 하나를, Type II와 Type III는 반복 결정이 실제 작업 성공으로 이어지는지를 측정합니다.

방법론

모든 실행은 같은 Worker, 도구, 작업 환경, 실행 예산, 평가기를 사용하며 Controller만 교체합니다. Worker가 할당된 구간을 마치면 영속 대화가 일시 정지되고 제어 사이클이 시작됩니다. 하네스는 Worker 대화 기록의 복사본으로 임시 Reporter를 만들고, Reporter는 읽기 전용 도구로 현재 저장소를 확인해 작업 맥락, 완료 상태, 검증 근거, 남은 문제를 정리합니다.

하네스는 Reporter의 요약과 인용된 Worker 기록을 Evidence Packet으로 고정 형식화합니다. Controller 모델을 π, 최신 Packet을 x, 이전 Packet과 Contract를 포함한 대화 이력을 h라고 하면 Contract는 $c = π(x, h)$ 로 생성됩니다. 여기서 x는 Controller가 받는 입력, h는 누적된 제어 맥락, c는 Worker의 다음 구간·검증·종료를 지정하는 출력입니다. Controller가 계속 진행하도록 결정하면 하네스가 bounded assignment를 다음 Worker 지시문으로 렌더링하고, 종료를 선택하면 현재 저장소를 평가기에 보냅니다.

Type I은 복원 가능한 제어 지점에서 네 개의 후보 Loop Contract를 제시합니다. 벤치마크 구축 단계에서 동일한 복원 상태로 네 후보를 두 개의 사전 선언된 재생 일정에 따라 실행하고, 두 일정 모두에서 성공·비용 규칙상 유일한 승자가 된 후보를 정답으로 고정합니다. 이후 새 Controller는 Worker를 실행하지 않고 네 방향 선택 한 번만 수행합니다.

Type II는 이미 앞 단계가 완료된 중간 workspace에서 하나의 일관된 작업 구간을 실행하고, Type III는 같은 과제를 원래 저장소 상태에서 처음부터 끝까지 실행합니다. 두 설정 모두 작업당 K=3회 실행하며, Type II와 Type III의 Controller 순서가 얼마나 일치하는지는 Spearman’s ρ로 계산합니다.

주요 결과

Type III 전체 작업의 Strict Success Rate는 Controller에 따라 16.05%에서 24.69%까지였고, 최고치는 GPT-5.5의 24.69%였습니다. Type II에서는 GPT-5.5가 51.85%, Qwen3.7-Plus와 Claude Opus 4.8이 각각 48.15%였으며, Type III 비용은 Controller별 실행당 4.86달러에서 18.84달러였습니다.

고정 목표를 반복하는 Fixed control은 Type II에서 No control의 39.51%를 46.91%로 높였지만, Type III에서는 No control과 같은 18.52%였습니다. 제한된 작업 구간에서는 목표 재진술이 도움을 줄 수 있지만, 전체 작업에서는 현재 증거에 따라 구현·검증·복구·종료로 지시를 바꾸는 제어가 필요하다는 결과입니다.

Type II의 Controller별 추정 추론 비용은 Type III보다 평균 64.4% 낮았습니다. 주된 Core 기준에서 두 설정의 Controller 순위 상관은 Spearman’s ρ=0.9747이었고, 양쪽에서 순서가 완전히 뒤집힌 쌍은 없었으며 열 쌍 하나에는 동률이 있었습니다. 따라서 Type II는 평가 비용을 줄인 비교 설정으로 기능하지만, 전체 작업 성능 자체는 Type III가 측정합니다.

Type I Contract Accuracy는 72.22%에서 87.78%였고, 모든 응답이 후보 하나로 파싱되어 Invalid Rate는 0%였습니다. 가장 강한 결정적 지름길의 점수는 31.11%에 그쳐 Controller 점수에 미치지 못했으며, 새 Controller 평가에는 질문당 한 번의 응답만 필요합니다.

기술 상세

LoopArena의 핵심 실행 단위는 control cycle입니다. Worker는 영속 대화에서 ReAct 방식으로 저장소를 관찰하고 수정하며 검사를 수행하고, 라운드가 끝나면 Reporter가 대화 복사본과 읽기 전용 workspace 점검을 사용해 네 부분의 상태 보고서를 만듭니다. Reporter는 코드 실행·테스트·수정을 할 수 없고, 그 결과는 Controller가 읽는 Evidence Packet으로만 전달됩니다.

Controller는 Packet과 이전 제어 이력을 입력으로 받아 Loop Contract를 출력합니다. Contract는 다음 Worker 구간의 범위와 제어권 반환 조건을 지정하거나 종료를 선택합니다. Controller는 workspace와 코딩 도구에 직접 접근하지 않으므로, 실제 효과는 Contract가 Worker의 다음 프롬프트로 변환된 뒤 실행 결과와 평가기 점수에 반영됩니다.

실행 설정의 성공 변수 $Y_{p,i,r}$ 는 정책 p가 작업 i를 r번째 실행에서 성공했으면 1, 아니면 0입니다. 전체 작업 수가 $N$ 이고 작업당 실행 횟수가 $K=3$ 일 때 Strict Success Rate는 $SSR(p)=\frac{1}{NK}\sum_i\sum_r Y_{p,i,r}$ 로 계산합니다. 즉 각 실행의 평가기 통과 여부를 모두 더한 뒤 전체 실행 수로 나누며, 예를 들어 27개 작업을 3회씩 실행해 81회 중 20회가 성공하면 SSR은 20÷81≈24.69%입니다. 값이 높을수록 설정된 프로토콜까지 지킨 성공 실행이 많다는 뜻입니다.

Type I의 Contract Accuracy는 90개 질문에서 정답 후보를 고른 비율입니다. 후보 실행은 벤치마크 구축 때 미리 수행하고 결과를 고정하므로, 평가 시에는 Worker 비용이 발생하지 않습니다. Type II와 Type III는 각각 27개 작업을 사용하며, 표에 보고된 Worker turns는 Type II에서 Controller별 평균 51.38~~80.12회, Type III에서 139.81~~288.90회였습니다.

추정 추론 비용은 prompt caching을 가정하지 않고 각 호출의 기록 토큰 수에 고정된 표준 입력·출력 가격을 적용해 합산합니다. No control과 Fixed control은 Worker 호출을 포함하고, Controller-guided 실행은 Worker·Reporter·Controller 호출을 모두 포함합니다. Type II와 Type III의 순위 일치도는 Controller만 대상으로 Spearman’s ρ=0.9747로 계산했습니다.

한계점

현재 범위는 저장소 수준 코딩 작업과 구조화된 handoff를 사용하는 Controller–Worker 조직에 한정됩니다. 추가 소프트웨어 도메인, 다른 Worker 계열, 다중 Worker 구성, 다른 루프 조직으로 확장하려면 도메인별 작업 구성과 실행 가능한 평가기가 필요합니다.

실무 활용

LoopArena의 공개 데이터와 평가 코드를 사용하면 코딩 에이전트의 실행 모델과 별도로 루프 제어 모델을 비교할 수 있습니다. Type I으로 개별 지시 선택을 저비용 점검하고, Type II로 실행 비용을 줄인 작업 구간 평가를 수행한 뒤, 필요한 경우 Type III에서 전체 장기 작업을 확인하는 순서가 가능합니다.

동일한 Worker와 도구를 유지한 채 여러 Controller 모델의 다음 작업 지시 능력 비교
Type I의 네 후보 선택으로 개별 제어 결정과 오류 유형 점검
Type II에서 전체 작업보다 낮은 비용으로 Controller 순위의 예비 비교
Type III에서 원래 저장소 상태의 종단 간 Strict Success Rate 검증

코드 공개 여부: 공개

코드 저장소 보기

키워드

Loop Engineering(코딩 에이전트 루프 설계)Controller–Worker(제어자·작업자 구조)Loop Contract(다음 작업 제어 명령)Evidence Packet(구조화된 실행 상태 요약)Strict Success Rate(엄격 성공률)추론 비용Spearman’s ρ(순위 상관계수)

용어 해설

Loop Engineering: — 코딩 에이전트와의 반복 작업을 하나의 제어 루프로 구성하는 개발 방식입니다. 루프가 진행 상황을 확인하고 다음 작업을 배정하며 검증과 종료 여부를 결정해, 매 라운드마다 사람이 직접 프롬프트를 작성하지 않도록 합니다.
Controller–Worker 구조(Controller–Worker): — Controller가 별도의 Worker 코딩 에이전트에 다음 작업이나 검증 지시를 보내고, Worker가 저장소를 수정하고 도구를 실행하는 분업 구조입니다. 두 모델의 역할을 분리하면 Controller의 런타임 제어 능력만 따로 측정할 수 있습니다.
Loop Contract: — Controller가 Worker의 다음 작업 구간, 집중 검증 내용 또는 종료 결정을 구조화해 기록하는 제어 명령입니다. 하네스는 이 계약을 Worker의 다음 프롬프트로 변환하고, 지정된 시점에 다시 제어권을 회수합니다.
Evidence Packet: — Reporter가 Worker의 대화 기록과 읽기 전용 저장소 점검을 바탕으로 만든 구조화된 상태 요약입니다. 작업 맥락, 완료된 작업과 현재 상태, 검증 근거, 남은 문제를 담아 Controller의 다음 결정을 지원합니다.
Strict Success Rate: — 전체 작업 수와 반복 실행 횟수에 대한 성공 실행의 비율입니다. 실행 결과가 과제 평가기를 통과하고 해당 설정의 제어 프로토콜까지 지킨 경우만 성공으로 세므로, 단순 부분 완료보다 엄격한 종단 간 성능을 측정합니다.

LoopArena로 코딩 루프 제어 능력 측정

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

최종 점수를 넘어선 장기 AI 연구 에이전트 평가

코딩 에이전트의 정의와 성능 평가를 위한 벤치마크 연구 동향.

DeepSWE 소프트웨어 엔지니어링 벤치마크

LLM은 자신의 에이전트 하네스를 만들고 진화시킬 수 있는가

2026년 AI 코딩 에이전트 오픈소스 벤치마크 10선

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 기사

최종 점수를 넘어선 장기 AI 연구 에이전트 평가

코딩 에이전트의 정의와 성능 평가를 위한 벤치마크 연구 동향.

DeepSWE 소프트웨어 엔지니어링 벤치마크

LLM은 자신의 에이전트 하네스를 만들고 진화시킬 수 있는가

2026년 AI 코딩 에이전트 오픈소스 벤치마크 10선