LLM 워크플로를 '에이전트 계산 그래프(ACG)'로 보고, 구조를 언제 정하나(고정 vs 동적)를 축으로 최적화 연구를 정리한 서베이.
한 줄 요약
LLM 호출·검색·툴·코드실행·메모리·검증을 엮은 워크플로 전체를 '에이전트 계산 그래프(ACG, Agentic Computation Graph)'로 보고, "이 그래프 구조를 언제 정하느냐"를 축으로 기존 워크플로 최적화 연구를 정리한 지도다.
ACG 란 무엇인가
LLM 에이전트가 하는 일을 자세히 보면 사실 작은 컴퓨테이션 그래프다 — 노드는 LLM 호출, 검색, 툴 실행, 코드 실행, 메모리 read/write, verifier 체크 같은 단위 작업이고, 엣지는 데이터 흐름과 의존이다. 서베이는 이걸 ACG 라는 한 용어로 묶어, 제각각 이름으로 불리던 라우터·플래너·툴유저·검증자·메모리 모듈을 같은 그래프 위의 노드로 정리한다.
그림 1. ACG 의 단위 노드들. 모든 LLM 워크플로는 이 노드들을 어떻게 연결하느냐의 문제로 환원된다.
핵심 축 — 구조를 언제 정하느냐
서베이가 강조하는 가장 결정적인 구분은 워크플로 구조가 확정되는 시점이다. Static 은 배포 전에 한 번 골격을 짜두고 모든 런이 같은 모양으로 흐른다 — 재사용·예측·검증이 쉽지만 입력 편차에 약하다. Dynamic 은 런마다 구조를 새로 선택·생성·수정한다 — 적응이 잘 되지만 디버깅·평가가 어렵다.
그림 2. Static vs Dynamic 의 본질적 차이와, 그 위에 더해지는 정리 3축
혼동하기 쉬운 3가지 — 템플릿 vs 실현 그래프 vs trace
저자는 워크플로 연구에서 자꾸 뒤섞이는 세 개념을 명확히 분리해야 한다고 본다. 이걸 합쳐서 보면 "설계가 좋다는 건지 / 실제로 그렇게 배치된 건지 / 실제로 그렇게 굴러간 건지"가 다 같이 뒤엉킨다.
그림 3. ① 템플릿(설계) → ② 실현 그래프(이번 런 배치) → ③ 실행 trace(실제 일어난 일). 셋을 섞어 보면 평가가 망가진다.
제안 — Structure-aware 평가
기존 평가는 대부분 downstream task metric(정답률·점수)만 본다. 서베이는 그것만으론 부족하다고 본다. 정답률은 같아도 어떤 워크플로는 두 배 더 비싸고, 어떤 워크플로는 입력 한두 줄만 바뀌어도 구조가 흔들린다.
그래프 수준 속성 — 노드 수·깊이·분기 폭·재사용도
실행 비용 — 토큰·시간·외부 호출 횟수
견고함(robustness) — 입력이 흔들릴 때 구조와 결과가 얼마나 안정적인가
구조 변이 — 같은 입력 분포에서 그래프가 얼마나 일관되게 모이는가
이 네 가지를 task metric 과 같이 보는 게 structure-aware evaluation.
우리한테 어떤 의미인가
멀티에이전트 fan-out, 라우팅, verifier 패널 같은 우리 워크플로가 정확히 이 static↔dynamic 스펙트럼 위에 있다. 서베이가 주는 가장 큰 이득은 "이번에 만든 워크플로가 어디쯤 있나"를 한 번에 짚을 수 있는 좌표계다 — 그리고 "정답률만 본다"는 흔한 평가의 빈틈을 메우는 4가지 추가 지표.