그래서 최근 흐름은 “에이전트가 얼마나 똑똑하게 이어서 말하는가"보다, 작업을 어떤 노드로 쪼개고 어떤 산출물을 다음 노드에 넘기며 어디서 재시도와 승인을 제어할 것인가로 이동하고 있습니다. 이 관점은 Workflow State Contract, Agent Handoff Packet, Stateful Sandbox Snapshot, Test Evidence Pipeline, Review Ops Unified Human Gate와 한 줄로 이어집니다. 결국 좋은 자동화는 대화를 길게 유지하는 기술이 아니라, 실행을 잘게 나누고 다시 이어 붙이는 기술에 가깝습니다.

이 글에서 얻는 것

• 왜 복잡한 AI 자동화가 선형 채팅 세션보다 task graph 위에서 더 안정적으로 운영되는지 설명할 수 있습니다.
• 어떤 작업을 노드로 나누고, 어떤 경계에서 병렬화와 human gate를 넣어야 하는지 실무 기준을 잡을 수 있습니다.
• full replay, 무한 재시도, 승인 병목 같은 문제를 줄이기 위한 그래프 단위 KPI와 의사결정 기준을 얻을 수 있습니다.

핵심 개념/이슈

1) 선형 대화는 branch가 생기는 순간 운영 비용이 급등한다

간단한 질문 응답은 채팅 한 줄로 충분합니다. 하지만 실제 개발 작업은 보통 이렇게 갈라집니다.

• 코드 수정 초안 만들기
• 관련 테스트 보강하기
• 문서와 마이그레이션 체크하기
• 보안 또는 정책 점검하기
• 결과 요약과 리뷰 요청 만들기

이 다섯 개는 서로 연결돼 있지만 완전히 같은 작업도 아닙니다. 테스트가 실패했다고 문서 초안까지 다시 생성할 필요는 없고, 정책 점검이 막혔다고 코드 탐색 결과까지 버릴 이유도 없습니다. 그런데 선형 세션으로 처리하면 보통 한 단계 실패가 전체 재실행으로 번집니다. 이때 비용이 커지는 이유는 모델 호출 자체보다, 중간 산출물이 명시적 자산으로 남지 않기 때문입니다.

Task Graph Runtime은 이 문제를 단순하게 푼다고 볼 수 있습니다. 작업을 node, 연결을 edge, 중간 결과를 artifact로 다루면, 실패가 나도 해당 노드 주변만 다시 계산할 수 있습니다. 이건 AI 전용 개념이라기보다 빌드 시스템과 CI가 오래전부터 증명한 방식이 다시 적용되는 셈입니다.

2) 좋은 그래프는 에이전트를 많이 붙이는 것이 아니라 의존성을 줄이는 설계다

멀티에이전트라는 말이 자주 나오지만, 에이전트를 여러 개 띄우는 것만으로 throughput이 늘지는 않습니다. 진짜 중요한 것은 아래 세 가지입니다.

1. 독립 실행 가능한 노드가 실제로 분리돼 있는가
2. 다음 노드가 필요한 입력 계약이 명확한가
3. 중간 산출물을 다시 쓸 수 있는가

예를 들어 “코드 수정”, “테스트 실행”, “문서 업데이트”, “릴리즈 노트 생성"은 병렬 가능성이 있지만, “운영 배포 승인"은 그렇지 않습니다. 그래서 잘하는 팀은 그래프를 그릴 때 병렬화를 많이 넣는 것보다, critical path를 짧게 만드는 cut를 더 먼저 봅니다.

이 관점은 Agent Handoff Packet과 잘 맞습니다. 에이전트끼리 긴 채팅을 복사하는 대신, 문제 정의, 수정 대상, 증거, 남은 리스크를 패킷으로 넘기면 다음 노드는 훨씬 얇고 빨라집니다.

3) full replay보다 node-level retry와 artifact cache가 더 중요해진다

복잡한 자동화에서 제일 아까운 비용은 실패 자체보다 불필요한 재계산입니다. 테스트 한 케이스가 flaky했다고 코드 분석, 관련 파일 스캔, 변경 요약까지 다시 돌리는 식이면 비용과 지연이 같이 커집니다.

그래서 Task Graph Runtime의 핵심 운영 포인트는 대개 아래 두 개입니다.

• node-level retry: 실패한 노드만 제한적으로 재시도
• artifact reuse: 이전 노드 출력이 유효하면 재사용

실무 기준으로는 아래 정도를 먼저 둬볼 만합니다.

• 같은 노드 재시도 상한 2회
• 2회 연속 실패 시 상위 모델 승격보다 원인 분류 우선
• 반복 워크플로의 artifact cache hit rate 목표 40% 이상
• critical path 밖 노드는 가능하면 병렬 실행

이건 Synthetic Replay + Eval Gate와도 연결됩니다. 좋은 팀은 작업 전체를 매번 감으로 다시 돌리지 않고, 어떤 노드가 품질 병목인지 재현 가능한 형태로 비교합니다.

4) human gate는 마지막 문 앞보다 그래프의 cut point에 놓이는 쪽이 낫다

많은 팀이 사람 검토를 맨 마지막에만 둡니다. 하지만 그래프 관점에서 보면 이건 종종 늦습니다. 예를 들어 데이터 수정, 외부 전송, 권한 변경, 배포 같은 액션은 그 직전 노드에서 이미 위험이 확정됩니다. 이때 사람이 마지막 한 번에 모든 산출물을 몰아서 검토하면 병목이 커지고, 무엇을 기준으로 승인해야 하는지도 흐려집니다.

그래서 최근 운영은 human gate를 아래처럼 분산시키는 쪽이 더 실용적입니다.

• 범위 확정 cut: 이 작업이 무엇을 건드릴지 승인
• 증거 충족 cut: 테스트, 로그, 링크, diff가 충분한지 승인
• 외부 효과 cut: 실제 적용, 전송, 배포 전 최종 승인

이 구조는 Review Ops Unified Human Gate와 Escalation Policy Ladder가 말하는 방향과 같습니다. 사람은 모든 노드에 붙는 존재가 아니라, 그래프에서 irreversible edge를 넘기기 전에 책임을 갖는 존재가 됩니다.

5) KPI도 세션 단위에서 그래프 단위로 바뀐다

선형 세션 운영에서는 보통 총 소요 시간, 총 비용, 대충 된 것 같은 성공률 정도만 보게 됩니다. 하지만 그래프 기반 운영으로 넘어가면 더 유용한 지표가 생깁니다.

• critical_path_latency_p95
• node_retry_inflation_ratio
• artifact_cache_hit_rate
• stuck_edge_count
• human_gate_backlog_minutes
• reused_artifact_without_revalidation_rate

특히 human_gate_backlog_minutes와 stuck_edge_count는 실제 팀 생산성을 잘 드러냅니다. 모델이 빨라져도 승인 큐가 막히면 전체 처리량은 안 늘고, 산출물을 재사용해도 검증 규칙이 없으면 오래된 결과를 계속 끌고 가는 사고가 생깁니다. 결국 그래프를 운영한다는 말은, 어디서 시간이 새고 어디서 리스크가 누적되는지 경로 수준으로 본다는 뜻입니다.

실무 적용

1) 최소 Task Graph 스키마

처음부터 거대한 오케스트레이터가 없어도 됩니다. 아래 필드만 있어도 꽤 실용적입니다.

이 표가 중요한 이유는 “누가 무슨 일을 한다"보다, 어떤 출력이 다음 일을 가능하게 만드는가를 고정해 주기 때문입니다.

2) 코드 변경 워크플로 예시

아래처럼 나누면 작은 팀도 바로 체감할 수 있습니다.

1. analyze_scope
   • 입력: 이슈, 관련 파일 목록
   • 출력: 수정 후보 파일, 리스크 메모
2. draft_change
   • 입력: 범위, 파일
   • 출력: patch, 변경 설명
3. run_unit_tests
   • 입력: patch
   • 출력: 테스트 로그
4. update_docs
   • 입력: patch, 변경 설명
   • 출력: 문서 diff
5. evidence_bundle
   • 입력: patch, 테스트 로그, 문서 diff
   • 출력: 리뷰용 증거 묶음
6. human_review
   • 입력: 증거 묶음
   • 출력: approve / request-change

이 구조면 run_unit_tests만 실패했을 때 2번까지는 재사용 가능하고, 문서 diff를 다시 만들 필요도 없습니다. 이게 곧 그래프 기반 운영의 즉각적인 이점입니다.

3) 시작할 때 둘 숫자 기준

• node retry 상한: 2회
• 같은 노드 실패율이 20% 초과하면 프롬프트보다 입력 계약 재설계 우선
• evidence bundle 누락률: 5% 이하 목표
• human gate backlog p95: 30분 이하
• critical path latency p95가 baseline 대비 25% 상승하면 병렬화 또는 cut 재설계 검토
• artifact cache hit rate가 반복 워크플로에서 40% 미만이면 노드 분리가 과도하거나 산출물 설계가 불량한 신호

핵심은 그래프를 예쁘게 그리는 것이 아니라, 반복되는 비용이 어디서 발생하는지 숫자로 드러내는 것입니다.

4) 2주 파일럿 방법

1주차

• 가장 자주 반복되는 AI 워크플로 1개를 고릅니다.
• 작업을 5~7개 노드로 쪼갭니다.
• 각 노드의 입력, 출력, 재시도 상한, 사람 승인 여부를 적습니다.

2주차

• 실제 10건 정도를 그래프 기준으로 실행해 봅니다.
• full replay가 몇 번 줄었는지, 어떤 노드가 가장 자주 막히는지 봅니다.
• stuck edge, human gate backlog, artifact reuse 비율을 기록합니다.

이렇게 하면 거대한 플랫폼 투자를 하기 전에, 우리 팀이 진짜로 그래프화해야 할 병목이 무엇인지 먼저 알 수 있습니다.

어떤 팀부터 그래프화해야 하나

도입 판단에서 제일 많이 헷갈리는 지점은 “우리도 멀티에이전트가 있으니 당장 그래프로 가야 하나"입니다. 내 기준은 더 단순합니다. 반복성, 재시도 비용, 승인 병목 이 세 가지가 있는지부터 봐야 합니다.

1) 반복성: 같은 흐름을 주 3회 이상 반복하는가

반복성이 낮다면 그래프 설계보다 운영 체크리스트 정리가 먼저입니다. 반대로 비슷한 코드 수정, 테스트, 리뷰 번들 생성, 배포 승인 흐름이 계속 반복된다면 노드 분해 비용을 금방 회수합니다. 이 기준은 Approval-Driven Auto Remediation 같은 운영 자동화에도 그대로 적용됩니다.

2) 재시도 비용: 한 단계 실패가 전체 재실행으로 번지는가

선형 세션에서 가장 비싼 순간은 실패 그 자체가 아니라, 이미 끝난 분석과 문서화까지 다시 돌리는 상황입니다. Rollback Budget에서 말한 것처럼, 복구 비용이 큰 흐름일수록 부분 재시도 설계가 먼저 들어가야 합니다. 이때 노드별 retry budget과 artifact validity 기간을 함께 적어 두면 시행착오가 크게 줄어듭니다.

3) 승인 병목: 사람이 어디서 기다리고 있는지 보이는가

사람 검토가 느린 것이 아니라, 무엇을 보고 승인해야 하는지 불명확해서 느린 경우가 많습니다. 그래프가 필요한 팀은 보통 여기서 드러납니다. 승인 큐가 길어질수록 Review Ops Unified Human Gate처럼 증거 묶음과 승인 cut를 먼저 분리해야 합니다. 그렇지 않으면 모델을 더 붙여도 전체 throughput은 거의 늘지 않습니다.

결국 Task Graph Runtime은 “에이전트를 더 많이 붙이는 도구"가 아니라, 반복되는 작업을 다시 설명하지 않게 만드는 운영 구조에 가깝습니다.

트레이드오프/주의점

첫째, low-risk 작업까지 전부 그래프로 만들면 오히려 느려집니다. 자유형 탐색이 더 나은 구간은 남겨 둬야 합니다. 둘째, 노드 분리를 잘못하면 공유 상태가 숨어서 재현성이 떨어집니다. 특히 로컬 파일, 환경 변수, 세션 메모리에 의존하는 노드는 artifact만 저장해도 충분하지 않을 수 있습니다. 셋째, cache hit만 높이려다 오래된 산출물을 재검증 없이 재사용하면 품질 사고가 납니다. 그래프 운영은 재사용을 늘리는 기술이면서 동시에 재검증 규칙을 더 엄격하게 적는 기술이기도 합니다.

체크리스트 또는 연습

체크리스트

• 반복되는 AI 워크플로를 최소 5개 이하 노드로 나눠 설명할 수 있다.
• 각 노드의 입력 계약과 출력 산출물이 문서화돼 있다.
• 실패 시 전체 재실행이 아니라 node-level retry를 우선한다.
• 사람 검토는 마지막 몰아보기 대신 중요한 cut point에 배치돼 있다.
• critical path latency, artifact cache hit, stuck edge, human gate backlog를 본다.
• 재사용 산출물에 대해 어떤 경우 재검증이 필요한지 규칙이 있다.

연습 과제

1. 현재 팀의 AI 보조 작업 하나를 골라 노드 5개 이내로 분해해 보세요.
2. 각 노드마다 “실패했을 때 전체를 다시 돌릴 이유가 있는가"를 적어 보세요.
3. 사람 검토가 꼭 필요한 cut point를 2개만 남긴다면 어디인지 써 보세요.
4. 반복 작업 10건을 기준으로 artifact cache hit rate 목표를 몇 퍼센트로 둘지 정해 보세요.

관련 글

• Workflow State Contract
• Agent Handoff Packet
• Test Evidence Pipeline
• Review Ops Unified Human Gate
• Stateful Sandbox Snapshot
• Synthetic Replay + Eval Gate