루프 엔지니어링 첫 벤치마크, 루프만 바꿔도 해결률이 2.6배 갈렸다

루프 엔지니어링이 성적을 얼마나 바꾸는지 처음으로 측정됐다. 모델을 하나로 묶어두고 루프만 갈아끼우자 해결률이 2.6배 갈렸다.

말은 지난 6월부터 쏟아졌다. 에이전트에게 단계마다 프롬프트를 던지지 말고 반복 실행 구조를 통째로 설계하라는 주장인데, 그게 결과를 얼마나 움직이는지 잰 자료는 없었다.

마이크로소프트(Microsoft)와 세 개 대학 연구진이 지난달 31일 그 숫자를 내놓았다. 코딩 에이전트의 반복 실행 구조를 재는 벤치마크 LoopsBench다. 112개 과제 가운데 최고 조합이 끝낸 것은 28개, 25%였다.

1위는 클로드 오푸스 4.7(Claude Opus 4.7)과 클로드 코드(Claude Code)를 붙이고 외부 연속 실행을 켠 구성이었다. 이 구성이 손대지 못하고 남긴 과제가 84개다. 앞 작업이 뒤 작업의 전제가 되는 긴 개발을 통째로 던져놓고, 에이전트가 그 순서를 지키며 끝까지 가는지를 재는 방식이다.

루프는 다섯 부품으로 되어 있다

루프 엔지니어링이라는 말을 처음 정리한 문서는 지난 6월 arXiv에 올라온 포지션 페이퍼다. 브라질 연구자가 공개 코퍼스에서 루프 50개를 손으로 코딩해 부품을 다섯 개로 추렸다.

트리거는 루프를 언제 시작할지, 목표는 무엇을 끝으로 볼지 정한다. 검증은 결과를 어떻게 확인할지, 종료 규칙은 어떤 상태에서 멈출지를 정한다. 메모리는 턴이 바뀌어도 디스크에 남는 상태다.

다섯 가지를 명시해두면 사람이 단계마다 개입하지 않아도 에이전트가 혼자 돈다는 게 주장의 뼈대다. 하지만 같은 코퍼스에서 78%는 여전히 사람이 직접 눌러야 돌아갔고 예약 실행은 12%뿐이었다. 자율 구간에서 검증된 루프가 70%, 종료 상태에 이름을 붙여둔 루프가 74%, 모델을 심판으로 세운 루프가 22%였다.

저자는 통제 실험을 하지 않았다. 사용 데이터를 만들어내지 않았다고 논문에 못 박았다. LoopsBench가 채운 자리가 여기다.

SWE-bench로는 왜 안 되나

연구진은 기존 벤치마크의 문제를 한 문장으로 적었다. 과제 추상화가 여전히 종착점에 머물러 있다. 에이전트는 그 자체로 완결된 이슈나 평평한 명세를 받고, 최종 성공 여부로만 채점된다. 이 방식은 이슈 해결 능력만 잰다. 에이전트가 중간 의무를 보존하는지, 회귀를 피하는지, 밟을 수 있는 순서로 가는지는 드러나지 않는다고 연구진은 짚었다.

측정 대상이 바뀐 이유는 도구가 바뀌었기 때문이다. 코덱스(Codex)와 클로드 코드는 이미 목표 모드와 동적 워크플로를 얹어 한 세션을 몇 시간씩 끌고 간다. 종착점만 재는 자로는 이 구간에서 무슨 일이 벌어지는지 볼 수 없다.

연구진이 하네스와 루프를 가르는 기준도 여기서 나온다. 하네스 엔지니어링(harness engineering)은 개별 테스트 실행 사이클과 국소 과제의 코드 생성을 받치는 인프라다. 루프 엔지니어링(loop engineering)은 그 위에서 목표와 진행 기준, 작업 분배를 관리하는 제어면이다.

112개 과제는 어떻게 만들어졌나

과제는 세 갈래에서 왔다. 깃허브(GitHub) 저장소의 커밋 이력을 쪼갠 PR Sequences 29개, 대학 강의 과제를 쪼갠 Course Labs 57개, 논문의 인용 관계를 따라간 Research Evolutions 26개다. 전체 개발 단위는 5300개가 넘고, 과제 하나당 47개꼴이다. 8개 언어와 9개 도메인에 걸쳐 있다.

핵심은 이 단위들이 평평하게 놓이지 않았다는 점이다. 연구진은 단위 사이의 선행 관계를 방향성 비순환 그래프(DAG)로 인코딩했다. 순차 연쇄, 구조 재사용, API 엣지, 조합 계층이라는 네 가지 근거 패턴으로 의존 관계를 복원했다.

문턱도 걸었다. 후보로 뽑히려면 커밋 이력이 최소 2.5개월에 걸쳐 있어야 하고 해법 규모가 1200줄을 넘어야 하는데, 하루 만에 끝나는 작업은 루프를 시험하지 못하기 때문이다.

외부 연속 실행이 8%포인트를 만든다

실제 LoopsBench 평가에서는 동일한 구성을 외부 연속 실행(루프) 없이 돌렸을 때와, 루프를 켜고 재시작했을 때의 해결률과 의존성 깊이를 나란히 측정해 비교했다.

외부 연속 실행은 처음 실행에서 남은 단위를 바깥에서 다시 집어넣는 재시작 장치다. 오푸스 4.7은 모델을 그대로 두고 루프만 한 겹 덧대 8.04%포인트를 얻었다. 다만 Qwen2.5-72B처럼 바닥이 0인 구성은 덧대도 달라지지 않는다.

맨 오른쪽 의존성 깊이는 에이전트가 선행 사슬을 얼마나 깊이 파고들었는지를 정규화한 값이다. 약한 모델은 사슬 앞부분에서 맴돌다 멈춘다. 루프를 클로드 코드로 고정하고 모델만 갈아끼우면 오푸스 4.7 25%, GPT-5.5 20.54%, GLM-5.1과 DeepSeek-V4P 각 18.75% 순이 된다. 제미나이(Gemini) 3.1 프로가 14.29%, Qwen3.6-Plus 9.82%, 키미(Kimi) 2.6 6.25%, Grok-4.1-FR 4.46%로 뒤를 이었다.

반대로 모델을 GPT-5.4로 고정하고 루프만 갈아끼우면 순위가 이렇게 나온다.

같은 모델인데 루프에 따라 2.6배가 벌어진다.

컨텍스트를 자주 갈아엎을수록 좋은가

루프 프로파일 네 곳의 컨텍스트 갱신 횟수와 회귀 발생 빈도를 비교해 보면, 해결률 상승과 안정성 사이에 뚜렷한 상충 관계(트레이드오프)가 드러난다.

동적 워크플로는 작업을 좁은 문맥의 하위 작업자에게 흩뿌리는 방식이라 목표 모드보다 세 배 자주 컨텍스트를 비우는데, 해결률이 가장 높은 대신 깨뜨리는 것도 가장 많다.

연구진은 그 이유를 이렇게 적었다. 하위 작업자가 일을 마치고 돌아올 때 이미 끝난 의무는 여전히 상태를 따로 붙들어 둬야 한다. 문맥을 쪼개도 상태 연속성 문제는 사라지지 않는다.

반대편의 Ralph 루프는 매번 바깥에서 새로 시작하는데, 해결률은 꼴찌였다. 경계를 세게 그을수록 진행이 끊긴다는 쪽을 보여준다. 컨텍스트를 얼마나 자주 비우느냐가 아니라 비운 뒤 무엇을 되찾아 오느냐가 갈랐다.

계획은 세우는데 지키질 못한다

에이전트가 사전에 세운 실행 계획이 실제 개발의 선행 구조와 얼마나 일치하는지를 정밀 측정한 결과다. 엣지 F1은 선행 관계를 얼마나 맞혔는지를, 계층 ρ는 작업 배치 순서가 실제 순서와 얼마나 같은지를 나타낸다.

가장 잘한 구현이 세운 계획도 실제 선행 구조와 0.71밖에 겹치지 않았다. 오픈소스 구현은 여기서 뚝 떨어진다. 한편 패치 길이는 참조 해법의 1.58배(클로드 코드)에서 2.54배(mini-swe-agent) 사이에 흩어졌다. 참조 해법과 실제로 겹치는 코드의 비율은 0.62에서 0.76 구간에 몰렸다. 길게 쓰지만 사람이 짠 답과 실제로 겹치는 부분은 6~7할에 머문다.

테스트를 작성한 개수는 클로드 코드가 28개, mini-swe-agent가 11개였다. 실패를 통과로 바꾼 비율은 0.47과 0.28 사이로 벌어진다.

여기서 숫자 하나가 어긋난다. 회귀율은 가장 많이 끝낸 클로드 코드가 7.11%로 가장 높고, 가장 적게 끝낸 mini-swe-agent가 0.24%로 가장 낮다.

적게 건드리는 루프는 적게 깨뜨리는 대신 아무것도 끝내지 못한다.

게이트를 걸면 무엇이 달라지나

같은 시기 나온 다른 논문들은 루프의 어느 부품을 손볼 때 결과가 움직이는지를 따로 쟀다.

검증을 통과 조건으로 강제한 실험이 먼저다. 지난 7월 공개된 Proof-or-Stop은 기계로 검증할 수 있는 증거가 게이트를 만족할 때만 다음 단계로 넘어가게 설계했다. 셀 9240개를 비교한 결과 거짓 통과가 1800건 중 31건에서 2건으로 줄었다. 리뷰어를 한 명 더 붙이는 데 그치지 않고 리뷰를 의무 게이트로 걸었을 때는 14건이 2건이 됐다. 사람이 지켜보지 않는 실행 열 번에서 끝나지 않은 일을 끝났다고 선언한 경우는 없었고, 증거를 위조하는 18가지 수법도 전부 걸러냈다. 연구진은 이 방식을 자기 논문 작업에 그대로 적용해 테스트 시나리오 565개에서 지적 1007건을 받았고 그중 94.8%를 해소했다고 적었다.

검증을 붙이는 데는 돈이 든다. 다른 실험은 반복 루프를 의미 변화가 멈추는 지점에서 끊어 운영 토큰을 38% 줄였다. 품질 점수는 사실상 그대로였다. 하지만 매 라운드 심판 모델을 불러 검증하는 전체 구성으로 가자 비용이 오히려 140% 늘었다. 다중 홉 질의응답 60건에 라마(Llama) 3.1 8B를 붙여 잰 소규모 결과라는 점은 저자도 한계로 적어뒀다.

싸게 끊는 신호를 먼저 쓰고 비싼 판정을 뒤로 미루는 순서가 관건이다. 하네스와 루프의 경계도 흔들린다. 에이전트가 실행 로그에서 자기 실패 유형을 찾아 하네스를 직접 고치게 한 연구도 있다. Terminal-Bench-2.0에서 MiniMax M2.5의 통과율이 40.5%에서 61.9%로 뛰었다. GLM-5는 42.9%가 57.1%, Qwen3.5-35B-A3B는 23.8%가 38.1%가 됐다. 루프가 하네스를 고치기 시작하면 두 층을 나누던 선이 흐려진다.

그러면 루프를 잘 짜면 되는가

연구진이 먼저 선을 그었다. 복원한 DAG는 개발의 완전한 인과 그래프가 아니라 선행 구조의 하한선이라고 적었다. 설정 파일과 데이터 형식, 빌드 시스템, 서비스 간 동작에 숨은 의존 관계는 잡히지 않는다.

지표도 공개된 테스트 스위트에 묶여 있다. 해결률과 테스트 통과율, 회귀율은 실행 가능한 의무를 재는 것이지 의미가 같은지를 재지 않는다. 모델을 써서 과제를 만든 탓에 문구와 경계, 테스트가 한쪽으로 기울었을 수 있고, 공개 출처를 쓴 만큼 오염 위험도 남는다. 모바일과 프런트엔드 중심, 하드웨어 인접 프로젝트는 아예 빠졌다.

루프 바깥에서 벌어지는 사고도 있다. 한 연구진은 실제 에이전트 저장소 6549개의 코드를 훑어 멈추지 않는 루프 68건을 47개 프로젝트에서 확인했다. 랭체인(LangChain)과 랭그래프(LangGraph), 오토젠(AutoGen), 크루AI(CrewAI)를 포함한 8개 주요 프레임워크가 대상이었다.

돈으로 번진 사례는 2023년부터 2026년까지 모였다. 한 독립 연구자는 21개 오케스트레이션 프레임워크에서 예산 초과 사고 63건을 깃허브 이슈와 메인테이너 발언으로 확인해 정리했다. 재시도 루프 하나가 운영자가 알아채기 전에 수천달러를 쌓는 구조다.

이 담론을 연 문서에 실험이 없었다는 사실도 그대로 남아 있다. 루프 50개를 손으로 코딩한 포지션 페이퍼가 부품 목록을 세웠고, 그 목록이 맞는지는 아직 아무도 대조하지 않았다.

남은 문제

회귀는 네 루프 프로파일 전부에서 보였다. 컨텍스트를 자주 비우는 쪽에서도, 거의 비우지 않는 쪽에서도 사라지지 않았다. 연구진이 기록할 수 있었던 것은 현재 루프 구현과 평가 어댑터가 밖으로 내주는 기록뿐이다. 그 인터페이스 바깥의 내부 사건은 측정되지 않았다.

비용은 표에 없다. 논문은 부록에 과제당 청구 토큰을 기록해뒀지만, 본문 어디에도 이 평가에 얼마가 들었는지를 합쳐 적지 않았다. 25%를 얻는 데 든 값은 공개된 수치로는 계산되지 않는다. 에이전트에게 일을 맡기는 쪽이 알고 싶은 숫자가 정확히 그 자리에 비어 있다.

25%가 천장인지 출발선인지는 아직 아무도 모른다.