From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution
Agent Loop을 스케줄러로 형식화하고 정적 DAG 실행기 SGH를 제안한 포지션 페이퍼를 검토한다. 구현·실험이 없는 만큼, 회복 프로토콜과 문맥 분할의 실용적 가치, 준비집합 축·종료 보장·70개 프로젝트 조사에서 드러나는 내부 불일치를 분리해 읽는다.
Paper: Wei, H. (2026). From agent loops to structured graphs: A scheduler-theoretic framework for LLM agent execution (arXiv:2604.11378v1). arXiv. https://arxiv.org/abs/2604.11378
Abstract: 이 글은 LLM 에이전트의 실행 구조를 스케줄링 이론의 어휘로 다시 쓰는 포지션 페이퍼를 검토한다. 논문의 제안은 Agent Loop을 준비집합 크기가 제한된 스케줄러로 특성화하고, 그 위에 정적 DAG·계획 버전·3계층 분리·경계 있는 회복을 결합한 SGH(Structured Graph Harness)를 설계하는 것이다. 논문 스스로 구현과 실험 결과가 없다고 밝히므로, 성능을 평가하기보다 회복 에스컬레이션과 실행·진단 문맥 분할이 주는 실용적 가치, 그리고 준비집합 축·종료 보장·조인 의미론·70개 프로젝트 조사에 남은 내부 불일치를 분리해 읽는다.
Executive Summary
| 항목 | 설명 |
|---|---|
| 연구 질문 | LLM 에이전트의 지배적 구현 방식인 Agent Loop(문맥창을 읽고 다음 행동 하나를 정하는 반복)을 스케줄러로 형식화하면, 루프와 그래프 실행기를 같은 축 위에서 비교할 수 있는가. 그리고 그 축에서 통제 가능성을 최대화한 설계는 어떤 모습인가. |
| 핵심 기여 | ① 실행 시스템을 튜플 (\mathcal{S},\mathcal{U},\mathcal{P},\mathcal{O},\Delta)로 형식화하고 준비집합 크기 \lvert\mathcal{U}\rvert와 정책 명시성으로 매개변수화한 "스케줄러 연속체". ② 70개 오픈소스 프로젝트 조사에서 끌어낸 4개 설계 원칙과 그 대가. ③ 정적 DAG·3계층 분리·계획 버전 불변성·노드 상태기계·3단계 회복 프로토콜로 이루어진 SGH 형식 명세. ④ 이득을 항목별로 귀속시키는 7군 실험 프로토콜. |
| 방법적 결과 | Agent Loop = 비결정적 single-ready-unit 스케줄러라는 특성화(논문 표기: Observation, 정리 아님). 정적 DAG 선택의 근거표, 10상태 노드 상태기계, 회복 3단계(local_retry → local_patch → request_replan)와 단계 건너뛰기 금지 불변식, 조인 모드 all_of·any_of 지원과 first_of 배제. |
| 실험 결과 | 없음. 논문은 "position paper and design proposal"이며 "not a production implementation or empirical results"라고 명시한다(§1 Scope). LangGraph 비교표에서도 자기 설계를 "Design only; no empirical validation", "an unimplemented design"으로 적는다(§2.4). 논문에 등장하는 수치는 조사 통계, 예시 트레이스의 단계 수, 실행되지 않은 프로토콜의 설계 값(50개 과제, 10회 반복 등), 구현 규모 추정치뿐이다. |
| 핵심 한계 | ① Agent Loop을 \lvert\mathcal{U}\rvert=1로 규정한 뒤 §3.2에서 병렬 tool_calls·비동기 연산은 \lvert\mathcal{U}\rvert>1이라고 스스로 인정한다. 그러면 "핵심 매개변수는 준비집합 크기"라는 프레임의 축이 흔들린다. ② "무한 재계획을 막는다"는 주요 설계 주장에 대응하는 형식 결과가 없다. Theorem 6.2는 계획 버전 하나에 대한 종료 진술이고, 계획 버전 수의 상한도 재계획 프로토콜의 정의도 논문에 없다. ③ 조사의 계수가 본문·Table 7·부록 A.7에서 서로 다르다(70 / 68 / 69 / 77). ④ 대표 예시가 쓰는 any_of는 논문 자신이 "배제한다"고 선언한 경쟁적 병렬성의 정의와 겹치고, "완전한 상태 전이표"에는 그 동작에 해당하는 전이가 없다. |
목차
- 서론 — 문제 설정과 논문의 지위
- 예비 지식 — 실행 시스템을 스케줄러로 쓰기
- 스케줄러 연속체와 작동 예시
- SGH의 설계 원칙과 정적 DAG 모형
- 노드 상태기계·회복 프로토콜·조인 의미론
- 70개 시스템 조사: 무엇을 세었고 계수는 맞는가
- 실험 프로토콜(제안) — 7군 설계와 이득 분해
- 한계와 확장
- 결론
1. 서론 — 문제 설정과 논문의 지위
1.1 Agent Loop의 세 약점
논문의 출발점은 지금 대부분의 LLM 에이전트가 같은 모양이라는 관찰이다. 하나의 언어 모델이 계속 길어지는 문맥창을 읽고 다음에 무엇을 할지 정하는 반복, 즉 Agent Loop이다. §1은 이 방식의 구조적 약점을 셋으로 정리한다.
첫째, 단계 사이의 의존관계가 암묵적이고 검증 불가능하다. "코드를 고친 다음 테스트를 돌려라"에서 두 번째가 첫 번째에 의존한다는 사실은 문맥창 안에만 존재한다. 모델이 추론 시점에 그 의존관계를 기억해야 하며, 순서를 어긴 실행을 막는 구조적 장치가 없다.
둘째, 실패 회복에 경계 의미론이 없다. 어떤 단계가 실패하면 모델이 재시도할지, 건너뛸지, 다시 계획할지를 스스로 정한다. 어떤 실패 유형에 어떤 회복 행동이 허용되는지 명시한 계약도 없고, 시도 횟수의 상한도 없다.
셋째, 실행 계획이 조용히 다시 쓰인다. 모델이 실행 중간에 계획을 수정하면 원래 계획은 문맥에서 덮인다. 실행이 끝난 뒤에 "어떤 계획이 어떤 행동을 관장했는가"를 충실하게 재구성할 수 없다.
논문은 이것이 예외적 사례가 아니라고 말하며 조사를 근거로 든다. "Our analysis of 70 open-source LLM agent projects reveals that 60% (42 out of 70) adopt the Agent Loop pattern." 이 조사의 계수 문제는 6장에서 따로 확인한다.
1.2 논문이 던지는 질문
| 질문 | 내용 |
|---|---|
| Q1 | Agent Loop과 그래프 기반 실행기를 하나의 의미론적 연속체 위에 놓을 수 있는가. 그 축은 무엇인가. |
| Q2 | 그 축 위에서 통제 가능성을 최우선으로 놓으면 어떤 설계가 나오는가. 무엇을 표현력에서 포기해야 하는가. |
| Q3 | 그렇게 얻은 실행 모형에 대해 어떤 성질을 형식적으로 보장할 수 있는가(종료, 건전성, 회복의 경계). |
| Q4 | "그래프 구조가 도움이 된다"는 주장을 계획 품질의 기여와 분리해서 측정하려면 실험을 어떻게 설계해야 하는가. |
Q1~Q3은 논문 안에서 답이 제시되고, Q4는 프로토콜만 제시된 채 실행되지 않는다.
1.3 논문의 지위: 포지션 페이퍼
이 논문을 읽을 때 가장 먼저 고정해야 할 사실은 구현도 실험도 없다는 점이다. 논문은 이를 감추지 않고 여러 곳에서 반복해서 말한다. §1의 Scope 문단은 "This paper contributes a theoretical framework, a design analysis, and an experimental protocol—not a production implementation or empirical results"라고 쓴다. §2.4의 LangGraph 비교표는 "Production maturity" 행에서 LangGraph를 "Widely deployed; community-validated", 자기 설계를 "Design only; no empirical validation"으로 적고, 바로 아래 "Fairness disclaimer" 문단에서 "Graph Harness is an unimplemented design"이라고 못 박는다. §11 결론도 "The most significant limitation of this work is the absence of empirical validation"으로 시작한다.
포지션 페이퍼에 실험이 없다는 사실 자체는 흠이 아니다. 따라서 이 해설은 "실험을 하지 않았다"를 비판으로 삼지 않는다. 대신 두 가지를 본다. 형식화가 실제로 무엇을 말하게 해주는가, 그리고 형식적 주장과 조사 근거가 논문 자신의 다른 부분과 맞아떨어지는가이다.
| 항목 | 값 |
|---|---|
| 발표 형태 | arXiv 프리프린트(2604.11378), 심사 통과 학회·저널 표기 없음 |
| 분류 | cs.AI(주), eess.SY |
| 분량 | arXiv 코멘트 필드 기준 51쪽(내려받은 PDF는 50쪽), 도판 4개, 표 16개, 참고문헌 28편 |
| 저자 | Hu Wei 단독 |
| 인용 수 | 이 해설은 인용 수를 조회하지 않았다. |
명칭에 관해 한 가지 짚어둔다. arXiv 초록 페이지는 제안 시스템을 "SGH, Structured Graph Harness"로 소개하지만, HTML 본문 초록은 "We propose Graph Harness (Structured Graph Harness)"로, §1은 "we propose Graph Harness (Graph Harness)"로 적는다. 마지막 것은 약어 치환이 깨진 흔적으로 보인다. 본문 전체에서 "Graph Harness"가 117회, "SGH"가 34회 쓰이며 둘을 같은 대상으로 혼용한다. 이 해설은 SGH로 통일한다.
2. 예비 지식 — 실행 시스템을 스케줄러로 쓰기
논문의 형식화는 단순하다. 실행 시스템을 다섯 항 튜플로 쓴다.
Definition 3.1 (Execution System). 실행 시스템은
\mathcal{E}=(\mathcal{S},\mathcal{U},\mathcal{P},\mathcal{O},\Delta)이다.
각 항의 뜻은 다음과 같다.
\mathcal{S}={(v,s_v)\mid v\in V,\ s_v\in\Sigma}: 노드 상태의 집합.V는 실행 단위인 노드 집합,\Sigma는 노드 상태 집합(5장 Definition 6.1).\mathcal{U}:\mathcal{S}\to 2^{V}: 전역 상태를 준비집합(ready set), 즉 지금 디스패치 가능한 노드 집합으로 보내는 함수. 구체적으로
\mathcal{U}(\mathcal{S})=\{v\in V\mid s_v=\mathit{ready}\ \land\ \forall (u,v)\in E:\ s_u=\mathit{executed}\}\mathcal{P}:2^{V}\to V: 준비집합에서 노드 하나를 고르는 **스케줄링 정책**. 비결정적 시스템에서는 함수가 아니라 관계로 둔다.
- \mathcal{O}=\{\mathit{success},\mathit{failure},\mathit{retry},\mathit{escalate}\}: 노드 실행 결과의 공간.
- \Delta:\mathcal{S}\times V\times\mathcal{O}\to\mathcal{S}: 결과에 따라 노드 상태를 갱신하고 새 전역 상태의 준비집합을 다시 계산하는 전이 함수.
정책을 함수가 아닌 관계로 두는 선택이 이 틀의 핵심이다. 그래야 결정적 스케줄러와 비결정적 스케줄러를 한 틀에 담을 수 있고, 논문은 Agent Loop을 후자에 넣는다.
여기서 두 정의가 나온다.
Definition 3.2 (Single-Ready-Unit Scheduler). 도달 가능한 모든 상태
s에서\lvert\mathcal{U}(s)\rvert\le 1이면 single-ready-unit 스케줄러다.
Definition 3.3 (Multi-Ready-Unit Scheduler).
\lvert\mathcal{U}(s)\rvert>1인 도달 가능 상태s가 하나라도 있으면 multi-ready-unit 스케줄러다.
\lvert\mathcal{U}\rvert\le 1이면 정책 \mathcal{P}는 공허해진다. 고를 것이 하나뿐이니 스케줄링 결정이라 할 것이 없고, "다음에 무엇을 할지"는 준비집합의 다음 원소를 만들어내는 과정이 사실상 결정하는데, Agent Loop에서 그것은 LLM 추론이다. 논문은 이 대목을 "Observation"이라 라벨하고, 정리로 올리지 않는다. "The Agent Loop is a non-deterministic, single-ready-unit scheduler."
직관적 예시. 준비집합 크기가 왜 축이 되는지는 같은 작업을 두 방식으로 그려보면 보인다.
Agent Loop: [ctx] → LLM → 행동 1 → [ctx'] → LLM → 행동 2 → …
준비집합은 매 시점 원소 1개, 그 1개를 정하는 것이 LLM 추론
Graph Harness: 준비집합 {A, B} → A, B 동시 디스패치
↓ 둘 다 executed
준비집합 {C} → C 디스패치
준비집합은 DAG 위상에서 계산, 정책은 코드
논문의 관심은 왼쪽에서 오른쪽으로 가는 것 자체가 아니라, 그 이동을 하나의 좌표로 말하는 데 있다.
3. 스케줄러 연속체와 작동 예시
3.1 연속체의 세 축
§3.4는 실행 시스템을 세 축으로 배열한다. 첫째는 준비집합 크기, 둘째는 정책 명시성(문맥에 대한 LLM 추론 / 구조화된 프롬프트 / 형식 상태 위의 명시적 정책), 셋째는 정책 결정성(\mathcal{P}가 관계인가 함수인가)이다. 논문은 이 배열에 "Framework observation"이라는 라벨을 붙이고 바로 다음 문장에서 성격을 못 박는다. "This is a classification framework, not a theorem."
그림 1. Wei (2026), Figure 2의 원도판 크롭본. Naive Loop부터 SGH까지 준비집합과 정책 명시성의 차이를 배열한다. 해설을 위해 인용. arXiv:2604.11378.
이 그림에 딸린 본문 문장은 "Moving from left to right, the ready set grows and the scheduling policy becomes more explicit"이다. 그런데 그림 자체를 보면 두 번째 칸 Parallel Loop이 \lvert\mathcal{U}\rvert\ge 1이고, 그 오른쪽의 Planner Loop과 Structured Loop은 \lvert\mathcal{U}\rvert=1이다. 준비집합은 좌에서 우로 단조 증가하지 않는다. 실제로 단조롭게 변하는 것은 두 번째 축인 정책 명시성뿐이며, 그림 하단의 화살표 라벨도 그 축만 가리킨다.
표기에도 걸리는 데가 있다. Definition 3.3은 multi-ready-unit을 \lvert\mathcal{U}\rvert>1로 정의하는데, 본문·그림·표는 반복해서 \lvert\mathcal{U}\rvert\ge 1로 쓴다. \ge 1은 =1을 포함하므로 single과 multi를 가르는 구분이 되지 못한다.
3.2 이 틀이 만들어내는 예측
연속체에서 세 가지 "theoretical predictions"가 나온다고 논문은 말한다. G_{\mathit{graph}}>0(단일 준비단위에서 다중 준비단위로 옮기면 계획 품질과 무관하게 측정 가능한 이득이 있다), G_{\mathit{graph}}는 과제 복잡도와 함께 증가한다, G_{\mathit{replan}}>0은 실패가 잦은 과제에서만 성립한다. 세 예측 각각의 지위는 논문이 직접 밝힌다.
"These predictions are not empirically validated in this paper... They are logical consequences of the framework's assumptions and the scheduler-theoretic model. While plausible, they may not hold in practice... We present these predictions as guidance for future research, not as proven claims."
§3.5는 같은 세 가설을 한 번 더 열거하는데, 여기서는 세 번째가 G_{\mathit{replan}}이 아니라 G_{\mathit{recovery}}>0로 적혀 있다. G_{\mathit{recovery}}는 논문 전체에서 이 한 줄에만 나오고 어디에서도 정의되지 않는다. §8.2 Definition 8.1이 정의하는 이득은 G_{\mathit{plan}},G_{\mathit{scaffold}},G_{\mathit{graph}},G_{\mathit{patch}},G_{\mathit{replan}} 다섯 개뿐이다.
같은 절에 복잡도에 관한 진술도 있다. "we do not prove that computing the optimal schedule under budget constraints is NP-hard (though this is likely, given the reduction from classical DAG scheduling)"인데, 여기 붙은 참고문헌은 Topcuoglu 외(2002)의 HEFT로 휴리스틱 스케줄링 알고리즘 논문이며 NP-난해성 환원의 출처가 아니고, 환원 자체도 제시되지 않는다. 논문은 이 대목을 §9.5 Limitation 5에서 거의 같은 문장으로 다시 인정한다.
3.3 프레임의 축이 흔들리는 지점
논문에서 가장 자주 반복되는 문장은 Agent Loop이 \lvert\mathcal{U}\rvert=1이라는 것이다. §2.1은 "all Agent Loop systems share the same structural limitation: \lvert\mathcal{U}\rvert=1 at every execution step"이라 쓰고, §3.4는 "Only a graph-based executor can reach the multi-ready-unit regime"이라 쓴다. 결론(§11)은 부등호를 느슨하게 해 "Agent Loops are single-ready-unit schedulers (\lvert\mathcal{U}\rvert\le 1)"로 적지만, Definition 3.2가 single-ready-unit을 \lvert\mathcal{U}\rvert\le 1로 정의하므로 결론도 같은 주장을 한다.
그런데 §3.2는 경계 사례 셋을 열거하면서 이 구분을 스스로 좁힌다. 병렬 tool 호출에 대해 "In our framework, this corresponds to \lvert\mathcal{U}\rvert>1 but with a non-deterministic \mathcal{P}"라 하고, 비동기 연산에 대해서도 "this also corresponds to \lvert\mathcal{U}\rvert>1 with a non-deterministic policy"라 한다. Definition 3.3을 그대로 적용하면 병렬 tool 호출이나 비동기 연산을 포함한 Agent Loop은 이미 multi-ready-unit으로 분류될 수 있다. Figure 2도 Parallel Loop을 \lvert\mathcal{U}\rvert\ge 1 칸에 넣는다.
그러면 남는 차이는 준비집합 크기가 아니라 정책의 결정성과 명시성이다. 실제로 §3.2의 양보 문단은 그 결론에 스스로 도달한다. "Graph Harness's advantage is not merely parallelism, but explicit parallelism" 문제는 논문이 그 뒤로도 "key parameter는 준비집합 크기"라는 서술을 유지하고, 핵심 예측 G_{\mathit{graph}}의 정의 자체를 "moving from single-ready-unit to multi-ready-unit"로 못 박는다는 점이다. 양보를 반영하면 G_{\mathit{graph}}는 준비집합 크기의 이득이 아니라 정책 결정성의 이득으로 다시 써야 하고, 그러면 §8의 G3↔G4 비교가 무엇을 분리하는지도 다시 정의해야 한다.
3.4 작동 예시: 버그 수정 과제
§3.6은 하나의 과제를 두 방식으로 추적한다. 파이썬 인증 버그를 조사·수정하면서 동시에 문서를 갱신하는 과제이고, 열 단계로 분해된다.
그림 2. Wei (2026), Figure 1의 원도판 크롭본. 첫 병렬 파도는 두 검색, 다음 병렬 파도는 두 패치 후보와 문서 갱신이다. 해설을 위해 인용. arXiv:2604.11378.
캡션은 "Blue nodes form the first parallel wave; green nodes form the second"라고 설명하는데, 도판에서 파란 노드는 search 둘과 read 둘 네 개로 두 파도에 걸쳐 있고, 두 번째 병렬 상자 안에는 초록 노드 둘과 노란 update_docs가 함께 들어 있다. 노드 색으로 읽으면 캡션과 맞지 않는다. 다만 두 병렬 상자의 점선 테두리가 각각 파랑과 초록이므로, 캡션이 노드가 아니라 상자 색을 가리킨 것일 수는 있다.
캡션 뒤에 붙은 단서는 이 예시의 성격을 정확히 규정하므로 그대로 옮긴다. 이 예시는 "planner가 병렬 구조를 모두 올바르게 식별하고, 의존관계가 계획 시점에 완전히 알려져 있고, LLM이 각 노드를 올바르게 실행하는" 이상적 조건에서의 잠재적 이득을 보여줄 뿐이며, 실제 과제가 이렇게 깨끗한 병렬성을 보이지 않을 수 있다고 논문은 덧붙인다.
두 트레이스의 요약은 이렇다. Agent Loop은 11턴이 걸린다. 1턴 auth 검색, 2턴 utils 검색(순차), 3·4턴 파일 읽기, 5턴 분석, 6턴 패치 A 작성, 7턴 테스트 — 여기서 두 개가 실패한다 — 8턴 패치 B, 9턴 테스트 통과, 10턴 문서, 11턴 보고. SGH는 6개의 스케줄링 라운드에 10회 노드 디스패치로 끝난다. 준비집합은 {search_auth, search_utils} → {read_auth, read_utils} → {analyze} → {fix_A, fix_B, update_docs} → {run_tests} → {report}로 전개되고, 네 번째 라운드에서 fix_A가 일시적 오류로 실패하지만 fix_B가 성공하므로 any_of 조인이 만족되고 fix_A는 skipped로 넘어간다.
이 비교는 SGH의 구조적 성질을 보여주는 데는 효과적이다. 다만 두 트레이스를 나란히 놓고 읽으면 대조 조건이 같지 않다.
첫째, 두 쪽에 서로 다른 실패 유형이 배정되어 있다. Agent Loop 쪽에서 패치 A는 의미적으로 틀려서 테스트를 통과시키지 못한다("FAIL: 2 tests still failing"). SGH 쪽에서 fix_A는 일시적 오류로 실패하고, run_tests는 한 번에 통과한다. SGH 트레이스에는 "패치가 테스트를 통과하지 못한다"는 사건이 아예 없다. any_of는 먼저 성공한 후보를 고르는데 여기서 성공은 노드 계약 통과이지 테스트 통과가 아니므로, fix_A가 정상 종료했다면 틀린 패치를 들고 run_tests로 갔을 것이다. 그 경로는 트레이스에 나오지 않는다.
둘째, 단위가 다르다. "10 node dispatches across 6 scheduling rounds"는 논문 자신의 표현이다. LLM 호출 횟수로 보면 10회 대 11회다. 덧붙이면 같은 절 안에서 병렬 라운드 수가 두 번 다르게 적힌다. "Structural differences" 문단은 "three ready-set expansions produce \lvert\mathcal{U}\rvert>1"이라 하고 트레이스도 그렇게 읽히는데(\lvert\mathcal{U}\rvert = 2, 2, 1, 3, 1, 1), 바로 다음 "Step count comparison" 문단은 "4 of those rounds dispatching multiple nodes in parallel"이라 적는다. §1의 요약 문장은 이 중 6과 11만 나란히 놓는다. 게다가 SGH의 6라운드에는 DAG를 만드는 플래너 호출이 포함되지 않는다. 트레이스가 "Plan version 1 generated"에서 시작하기 때문이다. §10.2의 고정 오버헤드 가설 H4는 구조적 비용을 "DAG validation, per-node state tracking, and the three-layer protocol"로 열거하고 플래너 호출은 넣지 않으므로, 이 비용은 논문이 세운 가설 바깥에 있다.
셋째, "the system does not waste budget"이라는 §3.6의 서술은 §10.1의 서술과 방향이 반대다. §10.1은 any_of를 "execute all, skip those blocked by a successful sibling"이라 하면서 "at the cost of full execution"이라고 적는다. 트레이스에서 SGH는 fix_A와 fix_B를 둘 다 디스패치하는 반면 Agent Loop은 A가 실패한 뒤에야 B를 만든다. 토큰 비용만 놓고 보면 SGH 쪽이 더 클 수 있다.
"Wall-clock time is reduced proportionally to the degree of available parallelism"이라는 문장도 근거 없이 놓여 있다. 노드별 지연 모형도 없고, 병렬 라운드의 비용이 그 라운드에서 가장 느린 노드에 묶인다는 점도 다루지 않는다.
3.5 계획이 틀렸을 때: 다섯 가지 실패 유형
§3.7은 위 예시가 완벽한 플래너를 가정한다는 점을 인정하고, 계획 실패를 다섯 유형으로 나눈 뒤 각각의 결과를 짚는다. 이 절은 논문에서 가장 실용적인 부분에 속한다.
| 계획 실패 | 무슨 일이 일어나는가 | SGH가 잡아내는가 |
|---|---|---|
| 의존관계 누락 | analyze가 read_auth 없이 실행되어 불완전한 입력을 받음 | 계약 검증에서 실패 → 회복 프로토콜 발동 |
| 불필요한 의존관계 추가 | 독립인 두 검색을 직렬화, \lvert\mathcal{U}\rvert가 2에서 1로 |
잡지 못함. DAG는 구조적으로 유효하고, 비용은 낭비된 시간 |
| 조인 선택 오류 | 대안 패치에 any_of 대신 all_of를 써서 둘 다 성공을 요구 | 실패 패치를 재시도·패치·재계획까지 끌고 감 |
| 과분해 | 노드가 지나치게 잘게 쪼개져 조정 오버헤드 증가 | 잡지 못함. 노드를 병합하는 기제가 없음 |
| 미분해 | 두 검색을 한 노드로 묶어 병렬성 상실, 오류 귀속도 어려워짐 | 잡지 못함. 재계획 없이는 잃은 병렬성 회복 불가 |
논문의 요약은 정직하다. 구조 검증은 순환·도달 불가·조인 불일치를 잡고, 계약 검증은 누락된 의존관계를 실행 시점에 잡지만, 불필요한 의존관계와 잘못된 분해 입도는 잡지 못한다.
4. SGH의 설계 원칙과 정적 DAG 모형
4.1 네 원칙과 각각의 대가
§4는 설계를 네 원칙으로 정리하고, 각 원칙이 무엇을 얻고 무엇을 포기하는지를 명시적으로 짝지어 놓는다. 원칙마다 "Sacrificed" 항목을 강제로 채운 구성은 이 논문의 미덕이다.
| 원칙 | 포기하는 것 | 얻는 것 |
|---|---|---|
| 통제 가능성 우선 | 경쟁적 병렬성, 재귀적 하위그래프 확장, 부모 사슬 롤백 | 예측 가능한 실행, 검증 가능한 트레이스 |
| 안정적 실행 확약 | 실행 중 동적 계획 수정 | 감사 가능한 계획 이력, 신뢰할 수 있는 귀속 |
| 경계 있는 회복 | 임기응변식 LLM 주도 회복 | 결정적 에스컬레이션, 실패 루프 방지 |
| 부수효과 분류 | 제약 없는 병렬 디스패치 | 안전 보장, 위험이 제한된 스케줄링 |
원칙 1의 근거로 논문은 조사에서 관찰한 패턴을 든다. graph/flow 오케스트레이션 계열에서는 실패 루프가 자주 보였고("3 out of 4 projects") 상태기계 기반 시스템에서는 드물었다("0 out of 7 projects")는 것이다. 다만 같은 문단이 곧바로 단서를 단다. "We did not formally quantify this observation due to the subjective nature of classifying 'failure-loop behavior,' and different reviewers might reach different conclusions." 이 분모들이 논문 자신의 부록과 맞지 않는 문제는 6장에서 다룬다.
원칙 2의 근거도 같은 성격이다. 버전 이력을 남기는 시스템이 가변 이력 시스템보다 디버깅에 유리해 보였다는 관찰인데, 논문은 "we did not formally measure success rates and this observation is based on subjective assessment"라고 덧붙이고 별도의 Caveat 문단까지 붙인다.
원칙 4에는 "Rationale from survey"가 아니라 그냥 "Rationale"이 붙어 있고, 내용도 조사 관찰이 아니라 개념적 논증이다(읽기 전용 API 호출은 자유롭게 재시도할 수 있지만 데이터베이스 쓰기는 그렇지 않다). §1이 "Each principle is justified by qualitative observations from the survey"라고 적은 것과는 어긋난다.
4.2 계획을 확약으로 다루기
Definition 5.1 (Execution Plan). 실행 계획은
\Pi=(\mathit{id},\mathit{version},V,E,\sigma,\kappa)이다.\sigma:V\to\mathrm{NodeConfig}는 각 노드에 설정(행동, 재시도 정책, 부수효과 수준)을 배정하고,\kappa는 계획이 완료 시 산출해야 할 출력 계약이다.
Definition 5.2 (Plan Invariant). 계획 버전
v의 수명 동안 구조(V,E)는 불변이다. 다른 구조를 만들어내는 유일한 기제는 재계획 프로토콜을 통한 새 버전v+1의 생성이다.
여기서 불변성의 범위를 정확히 봐야 한다. 초록은 "an execution plan is immutable for the duration of a plan version"이라고 쓰지만, Definition 5.2가 고정하는 것은 (V,E), 즉 위상뿐이다. 노드 설정 \sigma는 포함되지 않는다. 뒤에 나오는 회복 2단계 local_patch의 범위가 정확히 "현재 노드의 설정"이므로, 새 계획 버전 없이 \sigma가 바뀌는 경로가 열린다. 계획은 구조적으로 불변이지 전면적으로 불변인 것은 아니다.
정적 DAG를 고른 이유는 세 가지로 정리된다. 순환이 없으므로 준비집합이 항상 전진할 수 있고, 노드 수가 고정이므로 실행 단계 수의 상한이 정해지며, 위상 정렬이 정책이 다듬을 수는 있어도 위반할 수는 없는 표준 일정을 제공한다. 논문은 재귀 확장 그래프·부모 사슬 롤백 그래프·동적 위상 그래프 세 대안을 표현력 높음/예측 가능성 낮음/검증 가능성 낮음으로 평가하고 기각한다.
4.3 세 계층 분리
그림 3. Wei (2026), Figure 3의 원도판 크롭본. 런타임은 계획 구조를 직접 바꾸지 않고 실패를 회복 계층에 보고한다. 해설을 위해 인용. arXiv:2604.11378.
- 플래너 계층: 과제 의도를 받아 검증된 실행 계획
\Pi를 산출한다. LLM일 수도, 템플릿 생성기일 수도, 혼합일 수도 있다. - 런타임 계층:
\Pi를 받아(V,E)를 수정하지 않고 실행한다. 노드별 상태를 유지하고 준비집합을 계산하고 정책을 적용하고 관측을 기록한다. 실패를 회복 계층에 보고할 뿐 처리 방법을 정하지 않는다. - 회복 계층: 실패 보고를 받아 근본 원인을 진단하고 회복 행동을 고른다. 그 판단은 런타임의 실행 문맥에는 보이지 않는 진단 문맥에 근거한다.
이 분리를 뒷받침하는 것이 문맥 분할이다.
Definition 5.3 (Context Partition). 실행 문맥
\mathcal{C}{\mathit{exec}}(입력, 가시 산출물, 런타임 상태, 예산)와 진단 문맥\mathcal{C}{\mathit{diag}}(실패 이력, 플래너 주석, 이전 계획 버전)를 서로소로 유지한다. 노드 실행 중\mathcal{C}{\mathit{exec}}\cap\mathcal{C}{\mathit{diag}}=\emptyset이며, 진단 정보는 오직 플래너를 거쳐 새 계획 버전의 일부로만 실행 문맥에 들어갈 수 있다.
논문이 막으려는 병리는 구체적이다. 실패 이력이 이후 실행 단계의 암묵적 입력이 되어 회복 판단과 실행 논리가 얽히는 상황이다. 문맥 분할은 이 병리를 겨냥하며, 그래프 위상과 독립적으로 검토할 수 있는 설계 요소다.
다만 이 정의와 회복 2단계 사이에는 정리되지 않은 지점이 있다. local_patch는 진단 결과에 따라 노드 설정을 바꾸지만 새 계획 버전을 만들지 않는다(그것은 3단계다). 그러면 진단 문맥에서 나온 정보가 플래너를 거치지 않고 다음 실행에 반영되는 셈인데, Definition 5.3은 그 경로를 허용하지 않는다. 논문은 이 충돌을 다루지 않는다.
5. 노드 상태기계·회복 프로토콜·조인 의미론
5.1 상태와 전이
Definition 6.1 (Node State). 각 노드의 상태는
\Sigma={\texttt{pending},\texttt{ready},\texttt{running},\texttt{waiting_human},\texttt{blocked},\texttt{executed},\texttt{failed_retryable},\texttt{failed},\texttt{cancelled},\texttt{skipped}}에서 온다. 종료 상태는\Sigma_{\mathit{term}}={\texttt{executed},\texttt{failed},\texttt{cancelled},\texttt{skipped}}이다.
Definition 6.2 (Bounded Execution). 각 노드는 타임아웃
\tau_v와 재시도 예산b_v를 가진다.waiting_human상태의 노드에는 유한한T_{\mathit{human}}이 적용된다. 경과 시간이\tau_v를 넘거나 재시도가b_v를 넘으면running에서failed로 전이한다.
그림 4. Wei (2026), Figure 4의 원도판 크롭본. 회색 노드는 종료 상태이며, 세부 전이는 Appendix Table 15에서 보완된다. 해설을 위해 인용. arXiv:2604.11378.
원 도판은 라벨이 겹쳐 인쇄되어 있다. "transient err"와 "dep lost"가 같은 자리에 포개지고, "timeout"과 "cancel"도 마찬가지다. 부록 A.1의 Table 15가 전이 15개를 표로 다시 적어주므로 실제 명세는 그쪽을 봐야 읽힌다.
전이의 골자는 이렇다. 의존관계가 충족되면 pending → ready, 스케줄러가 고르면 ready → running, 계약을 만족하면 running → executed. 선행 노드가 종료 성공 상태를 벗어나면 ready → blocked이고 막힘이 풀리면 blocked → pending이다. 일시적 오류는 running → failed_retryable로, 예산이 남아 있으면 failed_retryable → pending으로 돌아가고 소진되면 failed로 간다. 부수효과 수준이 임계를 넘으면 running → waiting_human이고, 승인되면 ready로, 취소되거나 T_{\mathit{human}}이 지나면 cancelled로 간다.
이 표를 명세로 놓고 읽으면 몇 군데가 맞지 않는다.
blocked에 들어가는 경로는 ready → blocked 하나뿐이고 그 조건은 "A predecessor left terminal-success state"인데, 같은 절의 "Terminal stability"는 종료 상태에 들어간 노드의 상태는 이후 어떤 사건으로도 바뀌지 않는다고 못 박는다. executed와 skipped는 둘 다 종료 상태이므로 선행 노드가 종료 성공 상태를 "벗어나는" 일은 명세상 일어날 수 없다. 그러면 blocked는 도달할 수 없는 상태가 되고 blocked → pending도 발화하지 않는다. 그럼에도 blocked는 \Sigma에 포함되고 Proposition 6.1의 비종료 상태 목록에 들어가며, 그 증명 스케치는 "The DAG's acyclicity ensures that no deadlock cycle can form among blocked nodes"라며 도달 불가능한 상태들 사이의 교착을 논한다.
cancelled로 들어가는 행은 waiting_human에서 출발하는 두 개뿐이다. 즉 사람 승인을 요구한 적이 없는 노드는 cancelled가 될 수 없다. 그런데 Definition 7.2의 실패 전파 조항은 모든 후보가 종료 실패 상태(failed 또는 cancelled)에 이르렀을 때 조인이 실패한다고 쓰고, Proposition 6.1도 cancelled를 일반적으로 가능한 종료 전이로 나열한다.
Definition 6.2가 규정한 두 종료 조건도 표에 대응하는 행이 없다. 타임아웃 초과와 재시도 예산 초과 시 running → failed로 간다고 정의했는데, Table 15의 running → failed 행은 트리거가 "Structural error", 조건이 "Dependency missing, invalid plan"으로만 적혀 있다. 예산 초과는 표에서 failed_retryable → failed라는 다른 경로로 처리된다. 계약 검증 실패로 인한 전이도 마찬가지다. §6.1 본문은 계약을 만족하지 못하면 failed_retryable이나 failed로 간다고 하지만, 표의 두 행은 각각 일시적 오류와 구조적 오류만 트리거로 갖는다. Definition 7.2의 조인 실패로 후속 노드가 failed가 되는 전이(pending → failed)도 표에 없다.
Proposition 6.1이 나열하는 종료 상태 목록에서는 skipped가 빠져 있다(executed, failed, cancelled 셋만).
준비집합의 정의도 세 곳에서 다르다. Definition 3.1은 모든 선행 노드가 executed일 것을 요구해 skipped를 받지 않으므로, any_of가 쓰인 DAG에서는 어떤 후속 노드도 준비 상태가 되지 못한다. Definition 7.2는 후보 중 하나가 executed이면 후속 노드가 진입 가능하다고 존재 한정으로 쓴다. Table 15는 모든 선행 노드가 \Sigma_{\mathit{term}}^{+}(all_of면 {executed}, any_of면 {executed, skipped})에 있을 것을 전칭 한정으로 요구한다. 두 번째와 세 번째는 형제가 아직 running일 때 후속 노드가 준비 상태가 되는지에서 갈린다.
5.2 무엇이 보장되는가
논문이 제시하는 형식 진술은 여섯 개다. 본문 §6에 넷(Proposition 6.1, Theorem 6.2, Theorem 6.3, Proposition 6.4), 부록 A.3에 둘(Proposition A.1, A.2)이다. §1은 이를 "theoretically proven termination and soundness guarantees"라고 요약하는데, 실제로 "Proof"라는 표제가 붙은 것은 부록 Proposition A.1 하나뿐이다. Proposition 6.1과 두 정리에는 "Proof sketch"가 붙고, Proposition 6.4와 A.2에는 증명이 없다.
Proposition 6.1 (Progress Guarantee). 유한 DAG에서 경계 있는 실행 아래, 비종료 상태의 노드가 하나라도 있으면 어떤 노드가 ready로 가는 전이나 종료 상태로 가는 전이가 활성화되어 있다. 증명 스케치는 유한성과 비순환성에서 "모든 선행 노드가 종료 상태인 노드가 항상 존재한다"를 끌어낸 뒤 상태별로 경우를 나눈다.
Theorem 6.2 (Bounded Termination). 유한하고 비순환이며 모든 노드가 진입 노드에서 도달 가능한 DAG에서, 유한한 \tau_v와 b_v 아래 SGH 주 루프는 확률 1로 종료하며 모든 노드가 유한 시간 안에 종료 상태에 이른다. 총 시간 상한은 \sum_v \tau_v(b_v+1)+\sum_{v\in \mathit{waiting_human}} T_{\mathit{human}}(v)이다.
이 정리의 내용은 증명 스케치가 그대로 보여준다. 노드 수가 유한하고, 노드당 비종료 상태 수가 유한하고, 종료 상태에서 나가는 전이가 없으니 전체 전이 수가 \lvert V\rvert\cdot\lvert\Sigma\setminus\Sigma_{\mathit{term}}\rvert로 묶인다는 것이다. 타임아웃과 재시도 상한을 둔 고정 DAG가 유한 시간에 멈춘다는 진술이며, 같은 유한성 가정을 두는 실행 체계에도 적용 가능한 논증이다. 다만 증명은 결정적 계수 논증이므로 "확률 1로"라는 수식어가 어떤 추가 역할을 하는지는 분명하지 않다.
더 중요한 것은 이 정리가 무엇을 덮지 않는가다. Theorem 6.2는 주어진 하나의 유효한 DAG에 대한 진술이다. 그런데 회복 3단계 request_replan은 새 (V',E')를 만들어 다음 계획 버전으로 넘어간다. 계획 버전의 개수에 상한을 두는 진술은 논문 어디에도 없다. Definition 6.2가 상한을 주는 것은 노드별 타임아웃 \tau_v와 재시도 예산 b_v이고, Proposition 6.4가 강제하는 것은 단계의 순서이지 3단계가 몇 번 발동할 수 있는지가 아니다. 그런데 §1은 "recovery actions follow a strict escalation protocol that prevents unbounded replanning"이라고 적는다. 무한 재계획을 막는다는 핵심 주장에 대응하는 형식 결과는 제시되지 않는다. 각 계획 버전 안에서 종료가 보장될 뿐 버전의 사슬 자체는 열려 있다.
같은 문제가 회복 단계별 상한에도 있다. 1단계는 b_v로 명시적으로 묶이지만, 2단계 local_patch의 횟수 상한은 명시되지 않는다(노드당 1회라는 것이 recovery_state가 세 값짜리라는 사실에서 간접적으로 추론될 뿐이다). 3단계에는 상한이 없다.
그리고 논문은 재계획 프로토콜 자체를 정의하지 않는다. "replan protocol"이라는 표현은 다섯 곳에 나오지만, §5의 하위 절은 5.1~5.4뿐이고 어느 절도 무엇이 새 버전으로 이월되는지(완료된 노드의 산출물은 재사용되는가), (V',E')가 이전 버전과 어떤 관계여야 하는지, 버전 수에 상한이 있는지를 규정하지 않는다.
Theorem 6.3 (Conditional Soundness under Validation Reliability). 노드 v의 계약 검증이 통과 출력을 올바로 식별할 확률을 p_v라 하고 검증 오류가 독립이면,
\Pr[\text{모든 출력이 참으로 옳음}]\ \ge\ \prod_{v\in V}p_v .이 정리의 값어치는 결과보다 그것이 명시하는 간극에 있다. 논문은 이를 "validation gap"이라 부르고, 계약 검증을 모두 통과해도 시스템의 정확성은 검증 방법의 신뢰도에 묶인다고 말한다. 구문 검증(필드 존재, 타입, 형식)은 코드가 수행하므로 p_v\approx 1이지만, 의미 검증("이 수정이 옳은가")은 테스트 스위트일 수도 LLM일 수도 있고 후자면 p_v가 1보다 상당히 낮을 수 있다는 것이다. 다만 진술 자체는 독립 사건의 곱셈 법칙을 다시 쓴 것이고, 정작 중요한 의미 검증의 p_v를 어떻게 추정할지에 대해서는 논문이 방법을 제시하지 않는다. 완화책으로는 세 가지를 든다. 부수효과가 큰 노드는 코드 기반 검증을 쓰게 하고, waiting_human으로 사람 검토를 끼우고, 하류 노드가 실패하면서 상류의 잘못된 통과가 드러나게 하는 것이다. 셋 다 간극을 관측 가능하고 통제 가능하게 만들 뿐 없애지는 못한다고 논문 스스로 인정한다.
Proposition 6.4 (Escalation Invariant). 회복 행동은 엄격한 단계 순서를 따른다. 단계 i가 소진되어야 i+1을 부를 수 있고 건너뛰기는 금지된다. 증명은 붙지 않는다. 대신 논문은 이것을 규범이 아니라 기계적으로 강제되는 성질로 만드는 방법을 제시한다. 노드별 회복 상태 \mathit{recovery_state}[v]\in{\texttt{pristine},\texttt{retried},\texttt{patched}}를 두고, 회복 계층이 노출하는 세 진입점 attempt_retry(v)·attempt_patch(v, cfg)·request_replan(reason)에 전제조건을 건다. attempt_patch는 해당 노드가 retried 이상일 때만, request_replan은 실패한 모든 노드가 patched 이상일 때만 받아들여진다. API를 우회해 노드 상태를 직접 건드리는 구현은 보장 바깥이라고 명시하며, 타입 안전 언어의 unsafe 블록에 빗댄다.
5.3 3단계 회복
| 단계 | 행동 | 발동 조건 | 범위 |
|---|---|---|---|
| 1 | local_retry |
일시적 오류(네트워크, 타임아웃) | 해당 노드만, 계획 구조 불변 |
| 2 | local_patch |
계약 위반, 인증 오류 | 해당 노드의 설정, 계획 구조 불변 |
| 3 | request_replan |
의존관계 누락, 잘못된 계획 구조 | 계획 버전 전체, 새 (V',E') 생성 |
진단은 규칙 기반일 수도 LLM 보조일 수도 있으며(논문은 둘 중 하나를 고르지 않는다), 진단 결과는 튜플 d=(\varphi,c,r,\alpha)로 표현된다. 관측된 실패 \varphi, 근본 원인 가설 c, 권고 회복 행동 r, 진단 신뢰도 \alpha\in[0,1]이다. 진단자는 실행 문맥이 아니라 진단 문맥 위에서 작동한다. 다만 \alpha는 정의된 뒤 다시 쓰이지 않는다. 어떤 임계값에서 어떤 행동을 바꾸는지, 에스컬레이션에 어떻게 반영되는지가 없다.
트리거 배정과 에스컬레이션 강제 사이에도 어긋남이 있다. Table 10은 계약 위반과 인증 오류를 2단계 local_patch의 트리거로 배정한다. 그런데 기계적 강제 규칙은 attempt_patch를 \mathit{recovery_state}[v]\ge\texttt{retried}일 때만 받아들인다. 그러면 계약 위반으로 진단된 실패도 2단계에 닿기 전에 1단계 재시도를 한 번 소비해야 한다. 진단자가 r=\texttt{local_patch}를 권고해도 API가 거부하는 구조다. 재시도로 고쳐질 리 없는 실패 유형에 재시도를 강제하는 셈이라, "가장 덜 파괴적인 행동을 먼저 시도한다"는 원칙과 "실패 유형별로 적절한 회복을 배정한다"는 Table 10이 여기서 충돌한다.
이 프로토콜은 SGH에서 그래프와 가장 무관하게 떼어낼 수 있는 부분이다. 논문도 그렇게 본다. §9.4는 실패 루프로 고생하는 어떤 LLM 에이전트 시스템이든, 단일 준비단위 스케줄러 안에서도 비슷한 에스컬레이션 프로토콜을 채택해 이득을 볼 수 있다고 적으며 이를 "portable design contribution"이라 부른다.
5.4 조인 의미론과 first_of 배제
지원하는 조인은 둘이다.
Definition 7.1 (all_of).
\mathit{ready}_{\texttt{all_of}}(v)\iff \forall p\in P:\ \sigma(p)=\texttt{executed}.
Definition 7.2 (any_of). 후보들은 결정적 전순서(예: 노드 식별자 오름차순)로 모두 디스패치된다. 후보 중 하나가
executed에 도달하면 후속 노드가 준비 상태가 될 수 있고, 나머지 후보 중pending·ready·running·failed_retryable에 있던 것들은skipped로 전이한다. 모든 후보가 실패로 끝나면 조인이 실패하고 후속 노드는failed가 된다.
배제되는 것은 first_of다. 후보 중 무엇이든 완료(성공이든 실패든)하는 즉시 후속을 열고 나머지를 실행 중에 취소하는 의미론이다. 배제 이유의 개수부터 두 번 다르게 적힌다. §7.3과 §10.1 모두 "We exclude this for two reasons"로 시작하지만, 몇 줄 뒤 §7.3은 "The three concerns above"라 쓰며 셋을 가리킨다. 열거된 것은 셋이다. 패자 취소가 부분 결과를 다루는 보상 프로토콜을 요구한다는 것, 어느 시점을 확정으로 볼지 모호하다는 것, 준비집합이 비결정적이 된다는 것이다. 이 문제들이 원리상 풀 수 없는 것은 아니지만(분산 트랜잭션 문헌에 보상 프로토콜과 합의 기제가 있다) 구현 복잡도와 자체 실패 양상을 들여온다는 것이 논문의 판단이다.
여기서 세 가지가 서로 맞지 않는다.
첫째, §1은 경쟁적 병렬성을 "하나의 분기만 필요하고 나머지는 취소할 수 있는 경우(예: 서로 다른 두 수정을 시도하다가 하나가 성공하면 멈추는 것)"로 정의하고 SGH가 이를 배제한다고 선언한다. 그런데 논문의 대표 예시가 하는 일이 정확히 그것이다. 두 대안 패치를 시도하고 먼저 성공한 쪽을 채택하며 다른 쪽을 건너뛴다. §10.4도 first_of를 경쟁적 병렬성과 등치시킨다. 배제한다고 선언한 능력이 대표 도판 안에서 작동하고 있는 셈이다.
둘째, first_of를 배제하는 첫째 이유가 "실행 중인 패자 노드를 중단하는 데 보상 프로토콜이 필요하다"인데, Definition 7.2의 형제 건너뛰기는 running 상태의 형제를 skipped로 보낸다. 같은 중단이 일어나는데 왜 any_of에는 보상 문제가 생기지 않는지 논문은 설명하지 않는다. Definition 7.3 기준으로 두 조인의 형식적 차이는 둘뿐이다. 발화 조건(first_of는 완료 시, any_of는 성공 시)과 패자가 가는 종료 상태(first_of는 cancelled, any_of는 skipped)다.
셋째, any_of의 서술이 세 곳에서 다르다. §7.1은 실행 중 형제를 중단시킨다고 하고, §10.1은 "execute all, skip those blocked by a successful sibling"이라며 "at the cost of full execution"이라고 한다. 그리고 논문이 "Complete state transition table"이라 부르는 부록 A.1의 Table 15에는 skipped로 가는 전이가 ready → skipped와 failed_retryable → skipped 둘뿐이며, running → skipped도 pending → skipped도 없다. Definition 7.2가 네 개의 출발 상태를 나열한 것과 어긋나고, Proposition 6.1의 증명 스케치가 "remaining pending predecessors with no successful sibling are skipped"라고 쓴 것과도 어긋난다.
넷째, 부록 A.2의 계획 검증 규칙 5는 "부수효과 수준이 높은 노드는 투기적 병렬 실행에 배정되어서는 안 된다"이다. 대표 예시의 fix_A와 fix_B는 코드에 패치를 쓰는 노드이고 any_of 아래에서 병렬로 디스패치된다. 이 규칙을 문자 그대로 적용하면 논문 자신의 동기 예시 DAG가 검증에서 거부된다. 논문은 예시 노드들에 부수효과 수준을 배정하지 않으므로 이 충돌은 판정되지 않은 채 남는다.
first_of를 배제한 대가로 논문이 제시하는 우회책도 문제를 온전히 풀지 못한다. §10.1은 "A, B, C를 all_of로 병렬 실행한 뒤 하류 노드 D가 모든 출력을 검사해 최선을 고르라"고 한다. all_of는 전부 기다리므로 먼저 끝난 것을 취해 시간을 버는 이득이 사라진다. 논문도 "This sacrifices the cancellation efficiency but preserves the selection logic"이라고 적어 이 점을 인정한다.
표현력 경계는 표로 정리된다. 순차 실행·병렬 실행·대안 경로는 지원하고, 경쟁적 병렬성·재귀적 하위그래프 확장·동적 위상 변경·부모 사슬 롤백은 지원하지 않는다.
부록 A.3은 조인의 형식적 성질 둘을 제시한다. all_of의 준비집합은 단조롭다(실행 완료 노드가 늘면 준비 노드가 줄지 않는다). 증명은 집합 포함 관계 한 줄이다. any_of는 단조롭지 않다(후보 하나가 선택되면 형제들이 준비집합에서 빠진다). 이쪽에는 증명이 붙지 않으며 진술 자체가 정의의 재확인에 가깝다.
6. 70개 시스템 조사: 무엇을 세었고 계수는 맞는가
6.1 조사가 논문에서 맡은 역할
이 논문에 실험은 없지만 경험적 성격의 재료가 하나 있다. 70개 오픈소스 LLM 에이전트 프로젝트를 실행 패턴별로 분류한 조사다. 이 조사는 세 곳에서 하중을 진다. §1의 "60%가 Agent Loop을 채택한다"는 진단, §4에서 네 설계 원칙 중 셋에 붙은 "Rationale from survey", 그리고 §9.3.2와 §10.1이 제시하는 과제 수준 비율이다. 따라서 조사의 방법과 계수를 확인하는 것은 부수적인 일이 아니라 논문의 근거 사슬을 확인하는 일이다.
논문이 조사를 어떻게 규정하는지는 부록 A.4가 명확히 밝힌다.
"The survey of 70 open-source projects described below is not peer-reviewed and should be interpreted as qualitative evidence rather than quantitative proof."
이어 세 가지 단서를 단다. 프로젝트 선정이 주관적이고 체계적으로 표집되지 않았다는 것, 실패 루프 행동 등 정성 지표의 분류가 GitHub 이슈와 코드의 수동 검사에 근거하며 평가자에 따라 결론이 달라질 수 있다는 것, 그리고 조사가 2026년 4월 시점의 상태를 반영한다는 것이다.
부록 A.5는 선정 과정을 단계별로 적는데, 이 부분은 정성 조사치고 구체적이다. GitHub 검색(2023~2025년, 키워드 네 개, 별 100개 이상), 큐레이션 목록(Awesome LLM Agents, LangChain 템플릿, AutoGPT 생태계), 인용 사슬(ReAct·Plan-and-Solve·LangGraph의 전후방 인용)로 340개를 모은 뒤, 포크·미러 제거로 210개, 관련성 필터(LLM을 핵심 추론에 쓰지 않거나, 도구 호출·다단계 실행을 지원하지 않거나, 튜토리얼·데모인 것 제외)로 95개, 품질 필터(별 100개 이상이거나 알려진 벤치마크에 등장하거나 심사 통과 발표가 있을 것)로 70개를 남겼다. 분류는 다섯 축으로 했다. 주 스케줄러 유형, 계획 능력(없음/인라인/분리), 회복 기제(없음/재시도/재계획/구조화), 문맥 관리(단일/범위화/분리), 구현 복잡도(활성 스케줄링 코드 줄 수 기준 상·중·하)다. 깔때기는 정확히 70에서 멈추는데, 정작 그 70개를 인쇄한 목록은 70이 되지 않는다(6.2절). 그리고 다섯 축으로 분류했다고 적지만, 논문이 실제로 보고하는 것은 첫 번째 축의 분포뿐이다. 계획 능력·회복 기제·문맥 관리·구현 복잡도의 분포는 어디에도 나오지 않는다.
이 자인은 정직하지만 §4와 §11의 서술과는 온도가 다르다. §11 결론은 "The trade-offs are not arbitrary—they are derived from a systematic analysis of 70 existing agent systems"라고 적는다. 부록 A.5의 서두도 조사 대상을 "identified through the following systematic process"로 소개하는데, A.4의 첫 단서는 같은 선정을 "not systematically sampled"이라고 말한다. 같은 조사가 체계적이라고도 아니라고도 서술된다.
한 가지 어긋남은 시점이다. 식별 단계의 GitHub 검색 범위는 2023~2025년인데, A.4는 조사가 "2026년 4월 시점의 상태"를 반영한다고 밝힌다.
분류 자체는 두 평가자가 독립 수행했고 평가자 간 일치도 \kappa=0.84, 이견은 논의로 해소했다고 A.5에 적혀 있다. 단독 저자 논문이므로 두 평가자가 누구인지는 밝혀지지 않는다. 그리고 이 \kappa는 범주 분류에 대한 것이지, §4가 실제로 인용하는 "실패 루프 행동" 관찰에 대한 것이 아니다. 그 관찰에는 논문 스스로 "We did not formally quantify this observation"이라는 단서를 달았다.
6.2 계수를 직접 세어보면
부록 A.7은 "the complete list of 70 projects analyzed in this survey"를 범주별로 싣는다. 이 목록을 그대로 세면 다음과 같다.
| 범주 | §4.1 Table 7 | A.7 헤더 | A.7에 실제로 인쇄된 항목 |
|---|---|---|---|
| Agent Loop | 60% | 41개 (60%) | 50개 |
| Event-driven | 15% | 11개 (16%) | 11개 |
| State-machine | 10% | 4개 (6%) | 4개 |
| Graph/flow orchestration | 5% | 5개 (7%) | 5개 |
| Hybrid | 10% | 7개 (10%) | 7개 |
| 합계 | 100% | 68개 / 99% | 77개 |
세 계수 중 어느 것도 70이 아니다. 헤더의 합은 68이고 백분율의 합은 99%다. 실제로 인쇄된 항목은 77개인데, 그중 8개 프로젝트가 두 범주에 중복 등재되어 있다. autobot·babyclaw·hiclaw·nanoclaw는 Agent Loop과 Event-driven 양쪽에, minion-code·oh-my-openagent·safeclaw·supaclaw는 Agent Loop과 Hybrid 양쪽에 나온다. 중복을 제거하면 고유 프로젝트는 69개이며, 그중 하나는 claude-code-src — closed-source but accidentally leaked로 GitHub URL이 없고 애초에 오픈소스가 아니다. 이를 빼면 68개가 남는다.
본문과 부록의 수치도 어긋난다. §1은 "60% (42 out of 70)"라고 쓰고 A.7 헤더는 "41 projects"라고 쓴다. 41/70은 58.6%, 42/70은 60.0%다. Agent Loop 항목을 직접 세면 50개이고, 여기서 중복 8개를 빼면 42가 되어 §1의 수치와 맞는다. 즉 목록 인쇄 과정에서 중복 등재가 생겼고 헤더의 41은 갱신되지 않은 값으로 보이지만, 이는 재구성일 뿐 논문이 어디에서도 밝히지 않는다.
백분율에도 규칙 위반이 있다. A.5는 "Percentages in Table 7 are rounded to the nearest 5%"라고 명시하고 Table 7은 그 규칙을 지킨다(60/15/10/5/10). 그런데 A.7 헤더의 16%·6%·7%은 5% 단위가 아니며 Table 7 값과도 다르다. State-machine은 Table 7에서 10%인데 A.7에서는 4개(6%)다. 4개로는 어떤 반올림 규칙으로도 10%가 나오지 않는다.
경계 사례의 수도 세 곳에서 다르다. A.5의 Confidence 문단은 "the 12 boundary projects (those combining patterns)"에 대한 민감도 분석을 언급하고, A.7 말미의 분류 근거 문단은 "Six projects combined multiple patterns"라고 적으며, 실제로 두 범주에 등재된 프로젝트는 8개다. 그리고 Table 7의 캡션은 "Categories are mutually exclusive based on the primary execution pattern observed"라고 선언한다.
대표 프로젝트 표(부록 A.6, Table 16)에도 두 가지가 걸린다. 본문은 "nine representative projects... one from each major category"라고 소개하지만 실제로는 5개 범주에 9개가 배정되어 대부분 두 개씩이다. 그리고 표에 State-machine 대표로 오른 codex는 A.7의 "complete list"에 나오지 않는다. 게다가 §8.1은 같은 이름을 "state-of-the-art prompt-augmented Agent Loop"의 예로 든다. 여기서 §8.1이 가리키는 것은 상용 제품이므로 분류 충돌이라 단정할 수는 없지만, Table 16이 codex를 State-machine 대표로 올린 것과는 나란히 놓기 어렵다. autoresearchclaw는 Table 16에서 Hybrid, A.7에서 State-machine으로 분류된다. Table 16의 평점(4.0~5.0, 4.85와 4.5 포함)은 척도의 상한도 평가 축도 논문 어디에도 정의되어 있지 않다.
6.3 프로젝트를 세고 과제 비율을 말하는 문제
계수와 별개로 더 큰 문제가 하나 있다. 조사의 단위는 프로젝트인데, 논문에서 가장 실질적인 두 수치는 과제에 대한 비율이다.
§9.3.2는 "From our survey of 70 open-source projects, we observed that approximately 30–40% of agent tasks exhibit some degree of natural parallelism"이라 적고, 곧바로 "This is a rough estimate based on manual inspection"이라는 단서를 단다. §10.1은 "Based on our survey of 70 agent projects, only 8% of agent tasks require true first_of semantics"라고 적는데 여기에는 단서가 없다.
두 수치 모두 프로젝트 표본에서 과제 표본으로 단위를 옮긴다. 과제 표본이 무엇이었는지, 몇 개였는지, 어떻게 뽑았는지는 논문 어디에도 없다. 이 점이 중요한 이유는 30~40%라는 값이 논문의 적용 범위를 스스로 규정하는 숫자이기 때문이다. §9.3.2는 이어서 나머지 60~70%의 과제가 "essentially linear chains or have parallelism that is difficult to identify without domain expertise"라고 적는다. 즉 논문의 표제 기여인 다중 준비단위 스케줄링은 저자 자신의 추정으로도 과제의 3분의 1 남짓에서만 발동한다.
7. 실험 프로토콜(제안) — 7군 설계와 이득 분해
7.1 일곱 개 군
§8이 제안하는 설계의 핵심 아이디어는 단순하고 좋다. "그래프가 도움이 된다"는 주장은 대개 계획 품질의 기여와 뒤섞여 측정되므로, 한 번에 한 기능씩 더해가는 사다리를 만들어 인접한 두 군의 차이로 각 기능의 기여를 분리하자는 것이다.
| 군 | 스케줄러 유형 | 구조 | 회복 |
|---|---|---|---|
| G0: SOTA Loop | 단일 준비단위 | 계획 프롬프트 + 자기반성 | 인라인 재계획 |
| G1: Naive Loop | 단일 준비단위 | 없음 | 문맥 연장 |
| G2: Planner Loop | 단일 준비단위 | 없음 | 문맥 + 재계획 |
| G3: Structured Loop | 단일 준비단위 | 스캐폴드 | 스캐폴드 회복 |
| G4: GH-Core | 다중 준비단위 | 정적 DAG | 재시도만 |
| G5: GH+Patch | 다중 준비단위 | 정적 DAG | 재시도 + 국소 패치 |
| G6: GH+Replan | 다중 준비단위 | 정적 DAG | 재시도 + 패치 + 재계획 |
G0의 존재 이유를 설명하는 대목은 이 절의 중요한 통제 논리다. G0가 없으면 "그래프 구조 덕분"이라고 귀속한 개선이 실은 시스템에 더 풍부한 과제 정보를 준 효과일 수 있다는 것이다. 실제 배포된 에이전트(Claude Code, OpenAI Codex 에이전트 모드 같은 프롬프트 보강 루프)를 기준선에 넣지 않으면 불충분한 비교군이 된다는 문제의식이다.
통제 변수는 같은 50개 과제, 같은 기반 모델과 동일한 온도·최대 토큰, 같은 도구 집합, 같은 과제별 타임아웃(예: 10분)과 토큰 예산(예: 10만 토큰)이다. 측정 변수는 성공률(이진), 벽시계 시간, 토큰 비용, 디스패치된 노드 수, 회복 행동의 수와 유형, 계획 버전 수다. 편향 항목도 다섯 가지를 미리 적어둔다. 과제 선정 편향(병렬화 가능한 과제가 과대 대표되면 G_{\mathit{graph}}가 부풀려진다), 구현 편향, LLM 비결정성(과제당 10회 반복 후 평균±표준편차 보고), 도구 지연 편향, 순서 효과다.
과제는 세 계층으로 나눈다. 단순(1~3단계, 선형 사슬), 중간(4~8단계, 2~3개 분기, all_of와 any_of 혼용 — 논문이 주 평가 계층으로 지목), 복잡(9단계 이상, 중첩 분기와 깊은 의존 사슬). 계층별 과제 수 배분은 명시되지 않는다.
사다리 자체에도 두 군데 문제가 있다. 첫째, 표의 캡션은 "Each row adds exactly one feature to the previous row"인데 표가 그렇지 않다. G0에서 G1로 가면 계획 프롬프트·자기반성·인라인 재계획이 빠지고, G3에서 G4로 가면 스케줄러 유형·구조·회복 세 열이 한꺼번에 바뀐다. 특히 G3→G4는 G_{\mathit{graph}}를 정의하는 자리인데, 한 요소만 변한 비교가 아니므로 그 차이를 "순수 구조 이득"으로 부르기 어렵다.
둘째, G4의 회복 서술이 표와 본문에서 다르다. 표는 G4의 회복을 "재시도만"으로 적지만, 상세 구성은 "G4: GH-Core (\lvert\mathcal{U}\rvert\ge 1, no recovery). Multi-ready-unit scheduling with deterministic policy, but recovery is unbounded (no escalation protocol)"이라고 적는다. 무한 재시도는 원칙 3과 에스컬레이션 불변식이 막으려는 바로 그 병리인데, SGH의 핵심 군에 해당하는 G4가 그 상태로 정의되어 있다. 게다가 G1·G3·G4는 회복이 무한하므로 공유된 10분·10만 토큰 상한에서 종료하게 되고, 그 군들의 측정 비용은 상한에 붙박이게 된다.
7.2 이득 분해
Definition 8.1 (Attributable Gains).
G_{\mathit{plan}}=\mathrm{Perf}(G2)-\mathrm{Perf}(G1),G_{\mathit{scaffold}}=\mathrm{Perf}(G3)-\mathrm{Perf}(G2),G_{\mathit{graph}}=\mathrm{Perf}(G4)-\mathrm{Perf}(G3),G_{\mathit{patch}}=\mathrm{Perf}(G5)-\mathrm{Perf}(G4),G_{\mathit{replan}}=\mathrm{Perf}(G6)-\mathrm{Perf}(G5).
논문이 기대하는 용법은 명확하다. G_{\mathit{graph}}\gg G_{\mathit{plan}}이면 이득의 주인은 스케줄러 구조이지 계획이 아니고, G_{\mathit{replan}}\approx 0이면 재계획 프로토콜은 해당 과제군에서 값을 더하지 않는다.
여기에 세 가지를 짚어둘 만하다.
첫째, "total gain"이 두 절에서 서로 다른 양을 가리킨다. §8.1의 인접쌍 목록은 "G6 − G0 measures the total gain: the combined effect of planning, structure, and recovery over a production Agent Loop"이라 적는데, §8.2는 "The total structural gain of Graph Harness over a naive loop is"라 쓴 뒤 G_{\mathit{total}}=G_{\mathit{plan}}+G_{\mathit{scaffold}}+G_{\mathit{graph}}+G_{\mathit{patch}}+G_{\mathit{replan}}을 놓는다. 다섯 항의 합은 망원 소거로 \mathrm{Perf}(G6)-\mathrm{Perf}(G1)이 되므로, 두 "총 이득"은 기준선이 다르다. 앞의 것은 실제 배포 수준 루프 대비, 뒤의 것은 최소 루프 대비다. 논문은 두 값을 구분하지 않고 같은 이름으로 부른다. G0를 기준선에 넣은 §8.1의 좋은 판단이 §8.2의 분해식에서는 사라진다.
둘째, §8.1은 "G1 − G0 isolates the information vs. structure effect... A negative value indicates that structure (not information) drives G1–G6 improvements"라고 적는다. 그러나 G1은 최소 루프이고 G0는 프롬프트가 풍부한 루프다. 두 군의 정보량 차이만으로도 이 값이 음수가 될 수 있으므로, 그 부호만으로 이후 G2~G6의 이득이 구조에서 왔다고 식별할 수는 없다.
셋째, 논문 스스로 분해의 전제를 흔든다. §8.4의 "Limitation of additive decomposition"은 이득의 가법성을 가정한다는 점을 인정하고, 계획과 구조가 상호작용하면 — 좋은 계획일수록 그래프 구조의 덕을 더 본다면 — G_{\mathit{graph}}=\mathrm{Perf}(G4)-\mathrm{Perf}(G3)가 순수 구조 효과와 계획×구조 상호작용 항을 뒤섞는다고 적는다. 그리고 대응책까지 제시한다. "We can detect such interaction by estimating G_{\mathit{graph}} at different levels of planning quality"이다. 계획 품질을 독립적으로 변주하는 두 번째 축이 필요하다는 진단을 논문이 이미 내려두었다. 문제는 그 진단이 §8.1의 7군 설계와 Definition 8.1에 반영되지 않았다는 점이다. G0~G6은 한 방향으로만 변하는 1차원 사다리이고, 계획 품질을 여러 수준으로 두는 군은 정의되어 있지 않다. 경고와 처방은 §8.4의 문장으로만 남고 프로토콜은 그대로다.
통계 계획은 §8 안에서는 "과제당 10회 반복, 평균±표준편차"가 전부다. 검정 방법은 §8이 아니라 §9.5의 후속 연구 전략에 한 줄 나온다. "Statistical significance should be assessed using repeated trials (minimum 10 runs per task per group) and appropriate hypothesis tests (e.g., paired t-tests for within-task comparisons)"이다. 유의수준, 검정력, 다중비교 보정은 어디에도 없다. 성공률이 이진 결과인데 여섯 개의 인접쌍 대비와 총합을 같은 자료 위에서 검정한다는 점을 생각하면 이 한 줄로는 부족하다. 7군 × 50과제 × 10회면 3,500회 실행인데(이 산술은 논문에 없다) 그 규모의 예산·기간 추정도 제시되지 않는다.
평가 지표는 다섯 묶음으로 나열된다. 효과성(과제 성공률, 계약 충족률), 효율성(과제당 평균 LLM 호출, 중복 단계 비율, 벽시계 시간), 안정성(반복 시행 간 분산, 실패 루프 발생률), 관측 가능성(트레이스 완결성, 실패 국소화 정확도), 귀속(다섯 이득 항목). 각 지표는 한 줄 설명뿐이고 계산식은 주어지지 않는다. "trace completeness"나 "failure localization accuracy"처럼 정의가 여러 갈래일 수 있는 지표일수록 이 공백이 크다.
지표 목록과 측정 변수 목록도 서로 맞물리지 않는다. §8.1이 측정하겠다고 적은 것은 성공률·실행 시간·토큰 비용·노드 수·회복 행동 수·계획 버전 수인데, §8.4가 요구하는 계약 충족률·중복 단계 비율·실패 루프 발생률·트레이스 완결성·실패 국소화 정확도는 그중 어느 것으로도 계산되지 않는다. 반대로 토큰 비용은 측정되지만 §8.4의 어떤 지표로도 이어지지 않는다.
가설 번호도 정리되지 않았다. §10.2의 고정 오버헤드 가설은 H4로 불리지만 H1·H2·H3은 논문 어디에도 없다. §3.5의 세 가설은 (1)(2)(3)으로 번호가 매겨져 있을 뿐이다. 그리고 H4는 "비용은 측정 가능하게 더 들면서 성공률은 그에 비례해 오르지 않는다"는 비용 대비 효과에 관한 진술인데, Definition 8.1의 이득은 모두 \mathrm{Perf}의 차이이고 \mathrm{Perf}는 성공률·계약 충족률 같은 효과 지표다. 지금 분해식으로는 H4를 검정할 수 있는 양이 정의되지 않는다.
기준선 G0의 예시로 상용 제품(Claude Code, OpenAI Codex 에이전트 모드)을 지목한 것도 통제 변수와 상충한다. 이들의 프롬프트 스캐폴딩은 공개되지 않고 버전에 따라 바뀌므로, "나머지를 모두 고정한다"는 §8.1의 원칙을 기준선 자체가 만족하지 못한다.
8. 한계와 확장
8.1 논문이 밝힌 한계
논문의 적용 경계는 §9.5의 한계 절에 가장 명시적으로 정리되어 있다. 이 절은 여섯 가지를 번호를 붙여 나열한다.
1. 실험 검증 없음. 프로토콜은 있으나 프로토타입과 벤치마크가 필요하며 둘 다 진행 중이라고 말한다.
2. 정적 DAG 가정. 과제 구조를 실행 전에 정적 DAG로 완전히 서술할 수 있다는 가정은 세 부류에서 깨진다. 중간 결과를 봐야 하위 과제 집합이 정해지는 탐색적 과제, 진단이 조사에 의존하고 수정이 진단에 의존하는 식으로 목표가 진화하는 과제, 그리고 수정 구조가 생성된 내용에 달린 창작 과제다. §9.7은 이런 과제에는 동적 그래프 시스템이나 인라인 재계획을 하는 Agent Loop이 더 낫다고 명시한다.
3. LLM 오류 전파. 다중 준비단위 스케줄링은 오류 전파 위험을 키운다. 단일 준비단위 루프에서는 t단계의 추론 오류를 t+1단계에서 자원 낭비 없이 정정할 수 있지만, SGH에서는 DAG 생성 단계의 오류가 실행 전체에 걸쳐 확정된다.
4. 콜드 스타트. 실행을 시작하려면 잘 구조화된 DAG가 먼저 있어야 한다. 선례가 없는 새 과제·도메인에서 플래너가 하위 목표를 식별하고 의존관계를 정하고 조인 의미론을 고르는 일은 사소하지 않다.
5. 복잡도 이론적 보장 부재. 예산 제약 아래 최적 일정 계산이 NP-난해임을 증명하지 않았고, 근사 성질도 규정하지 않았다고 인정한다.
6. 구현 복잡도. DAG 검증 엔진 1,000~2,000줄, 동시 스케줄러 800~1,500줄, 상태 영속 계층 500~1,000줄, 회복 엔진 600~1,200줄, 계약 검증 프레임워크 400~800줄로 최소 구현이 약 3,300~6,500줄이며, 단순 Agent Loop(300~500줄)보다 한 자릿수 크고 Airflow 같은 실무 워크플로 엔진보다는 작거나 비슷하다고 추정한다. 논문은 이 수치가 유사 시스템 분석에 근거한 추정이며 실제 구현으로 검증되어야 한다고 곧바로 덧붙인다. 비교 대상으로는 Airflow 5만 줄 이상, Prefect 3만 줄 이상을 든다.
여기에 §9.8과 §10.2를 함께 놓아야 논문의 자기 규정이 온전해진다.
§9.8은 제목부터 "SGH as a Degenerate single-ready-unit Scheduler"다. 플래너가 선형 사슬을 만들면 모든 상태에서 \lvert\mathcal{U}\rvert\le 1이므로 SGH는 자신이 넘어서려던 것과 같은 부류가 된다. 그때 Agent Loop 대비 남는 이점은 셋뿐이다. 경계 있는 회복, 계획 버전 불변성에 의한 감사 가능성, 실행 문맥과 진단 문맥의 분리다. 그리고 "SGH's value is bounded by planner quality"라고 못 박는다.
§10.2는 가설 H4를 세운다. "On simple tasks, Graph Harness's structural overhead results in measurably higher cost (LLM calls, latency) than an Agent Loop baseline, without a proportional success-rate improvement." SGH를 옹호하는 논문이 단순 과제에서는 SGH가 더 나쁠 수 있다고 미리 적어둔 셈이다.
§2.4의 "Fairness disclaimer"도 같은 성격이다. LangGraph는 수천 건의 배포로 검증된 성숙한 프레임워크이고 SGH는 미구현 설계이므로, 비교는 구조적인 것이지 평가가 아니며 SGH가 LangGraph보다 낫다고 주장하지 않는다고 선을 긋는다.
8.2 적용 가능성과 남는 기여
앞 절의 한계와 각 방법 절에서 확인한 내부 불일치를 함께 놓으면, SGH의 기여는 모든 Agent Loop을 대체하는 일반 이론보다 정책을 명시적으로 만들고 회복 경계를 구조화하는 설계 제안으로 읽을 때 가장 분명하다.
회복 에스컬레이션 프로토콜. retry → patch → replan의 단계와 건너뛰기 금지를 API 전제조건으로 강제하는 방식은 그래프 위상과 분리해 평가할 수 있는 설계 후보다. 다만 고정 계획 버전을 벗어난 재계획 횟수의 상한은 별도로 정의해야 한다.
실행 문맥과 진단 문맥의 분리. 실패 이력이 후속 실행의 암묵적 입력이 되는 일을 막으려는 경계다. local_patch가 진단 정보를 새 계획 버전 없이 실행 설정에 반영하는 경로와 이 원칙이 어떻게 양립하는지는 구현 전에 정리할 필요가 있다.
계획 실패 유형과 검증 범위. §3.7은 구조 검증이 순환·도달 불가·조인 불일치를 잡는 반면, 불필요한 의존관계와 잘못된 분해 입도는 잡지 못한다고 구분한다. 이 목록은 그래프 기반 실행기를 설계할 때 검증 범위를 정하는 점검표로 사용할 수 있다.
G0 기준선. 프롬프트가 풍부한 실무형 Agent Loop을 비교군에 포함해야 정보량과 구조의 효과를 구분할 수 있다는 문제 제기는 유효하다. 다만 실제 프로토콜에서는 한 번에 여러 요소가 바뀌고 가법성 상호작용도 남으므로, 계획 품질을 독립 축으로 둔 후속 설계가 필요하다.
9. 결론
9.1 핵심 기여 요약
| 기여 | 내용 | 실제로 확보된 정도 |
|---|---|---|
| 스케줄러 연속체 | 실행 시스템을 (\mathcal{S},\mathcal{U},\mathcal{P},\mathcal{O},\Delta)로 쓰고 준비집합 크기와 정책 명시성·결정성으로 배열 |
논문 스스로 "classification framework, not a theorem". 축 중 하나(준비집합 크기)는 §3.2의 자기 양보로 흔들림. 남는 유효 축은 정책 명시성·결정성 |
| 4개 설계 원칙 | 통제 가능성 우선, 안정적 확약, 경계 있는 회복, 부수효과 분류 — 각각 포기하는 것을 명시 | 원칙과 대가를 짝지어 적는 형식은 유효. 근거로 인용된 조사 통계는 부록과 맞지 않음 |
| 형식 명세 | 10상태 노드 상태기계, 3계층 분리, 문맥 분할, 3단계 회복과 에스컬레이션 불변식, all_of·any_of 조인 | 3계층과 문맥 분할, 회복 에스컬레이션의 API 수준 강제는 구현 후보로 구체적이다. 다만 종료·건전성 진술은 고정 DAG와 독립 검증 가정에 한정되고, 재계획 프로토콜은 정의되지 않았으며, any_of 의미론과 상태 전이표는 서로 어긋난다 |
| 7군 실험 프로토콜 | G0~G6 사다리와 다섯 이득 항목으로 기여를 분리 | 설계 아이디어, 특히 G0 기준선은 유용하다. 아직 실행되지 않았고, 가법성 가정·동시 변경 요소·사전 기각 기준 부재 때문에 각 이득의 식별 범위가 제한된다 |
9.2 이 논문을 어떻게 읽을 것인가
논문이 스스로 정한 지위, 곧 포지션 페이퍼이자 설계 제안이라는 기준으로 보면 평가는 두 갈래로 갈린다.
설계 문서로서. 구체적인 검토 항목을 제공한다. 노드 상태기계, 3단계 회복 에스컬레이션과 API 전제조건, 실행 문맥과 진단 문맥의 분리, 계획 실패 다섯 유형과 구조 검증 범위는 구현 전에 확인할 수 있는 설계 체크리스트다. 특히 회복 프로토콜과 문맥 분리는 DAG 위상과 독립적으로 평가할 수 있다.
이론적 기여로서. 보장의 범위는 제한적이다. 고전 스케줄링 결과는 소개되지만 LLM 노드에서 전제가 깨진다고 인정된 뒤 SGH의 성질을 증명하는 데 사용되지 않는다. 종료와 건전성 진술은 각각 고정 DAG의 유한 상한과 검증 오류의 독립 가정에 의존한다. 또한 준비집합 크기만으로 Agent Loop과 그래프 실행기를 가르는 구분은 §3.2의 병렬 tool call·비동기 연산 사례를 포함하지 못한다.
논문 안에서 더 좁고 검증 가능한 중심 명제는 §3.2의 "Graph Harness's advantage is not merely parallelism, but explicit parallelism"이다. 병렬 tool call이 가능한 루프까지 포함하면 차이는 병렬성의 존재 자체보다, 그 병렬성이 LLM 추론의 부산물인지 DAG 위상에서 계산되는 명시적 정책인지에 놓인다. 이 명제를 중심에 두면 경계 사례를 수용하면서 G_{\mathit{graph}}를 정책 명시성·결정성의 이득으로 다시 정의할 수 있다.
9.3 열린 문제
- 명시적 병렬성의 이득을 계획 품질의 이득과 분리해 측정하려면 계획 품질을 독립 축으로 변주해야 한다. §8.4는 이 처방을 문장으로 적어두었지만 7군 설계에는 넣지 않았다. 프로토콜을 실제로 그렇게 고치는 것이 첫 번째 후속 작업이다.
any_of와first_of사이의 경계를 형식적으로 다시 그어야 한다. 지금 상태로는 "실행 중 형제를 중단한다"는 성질이 지원 조인과 배제 조인 양쪽에 걸쳐 있다.- 의미 검증의 신뢰도
p_v를 추정하는 방법이 없으면 Theorem 6.3은 조건부 진술로만 남는다. 테스트 스위트와 LLM 판정의 위양성률을 과제 유형별로 측정하는 것이 선행 과제다. - 플래너가 병렬 구조를 식별하지 못할 때 자동으로 경량 루프로 우회하는 이중 경로 설계를 논문은 §9.8에서 공개 질문으로 남긴다. 이 질문은 §9.3.2의 30~40% 추정과 §10.2의 H4를 함께 놓고 보면 부차적 최적화가 아니라 설계의 중심 문제에 가깝다.
References
Bai, J., Aldossary, A., Swanick, T., Müller, M., Kang, Y., Zhang, Z., Lee, J. W., Ko, T. W., Vakili, M. G., Bernales, V., & Aspuru-Guzik, A. (2026). El Agente Gráfico: A semantic execution runtime for scientific agents (arXiv:2602.17902v1). arXiv. https://arxiv.org/abs/2602.17902v1
Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. (2009). Introduction to algorithms (3rd ed.). MIT Press.
Graham, R. L. (1969). Bounds on multiprocessing timing anomalies. SIAM Journal on Applied Mathematics, 17(2), 416–429. https://doi.org/10.1137/0117039
Li, Y., Xu, B., Tian, X., Xu, X., & Shen, H. (2026). Beyond entangled planning: Task-decoupled planning for long-horizon agents (arXiv:2601.07577). arXiv. https://arxiv.org/abs/2601.07577
Liu, Y., Zhang, G., Wang, K., Li, S., & Pan, S. (2025). Graph-augmented large language model agents: Current progress and future prospects (arXiv:2507.21407). arXiv. https://arxiv.org/abs/2507.21407
Sinnen, O. (2007). Task scheduling for parallel systems. John Wiley & Sons.
Topcuoglu, H., Hariri, S., & Wu, M. (2002). Performance-effective and low-complexity task scheduling for heterogeneous computing. IEEE Transactions on Parallel and Distributed Systems, 13(3), 260–274. https://doi.org/10.1109/71.993206
Wei, H. (2026). From agent loops to structured graphs: A scheduler-theoretic framework for LLM agent execution (arXiv:2604.11378v1). arXiv. https://arxiv.org/abs/2604.11378
Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., Zhang, S., Liu, J., Awadallah, A. H., White, R. W., Burger, D., & Wang, C. (2023). AutoGen: Enabling next-gen LLM applications via multi-agent conversation (arXiv:2308.08155). arXiv. https://arxiv.org/abs/2308.08155
Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. International Conference on Learning Representations. https://arxiv.org/abs/2210.03629
Zhuge, M., Wang, W., Kirsch, L., Faldor, M., Zhang, J., Li, C., Li, K., Liu, Y., Xiong, W., & Schmidhuber, J. (2024). Language agents as optimizable graphs. International Conference on Machine Learning. https://arxiv.org/abs/2402.16823