에이전트 워크플로우 (Agentic workflows)는 지루해져야 합니다.

첫 번째 단계는 탐색적일 수 있으며 꽤 비용이 많이 들 수 있습니다. 하지만 열 번째 단계는 지루해야 하며, 완전히 새로운 도구 세트를 통해 솔루션을 다시 발견할 필요가 없어야 합니다. 그러한 워크플로우는 승진할 자격이 있습니다.

이것이 새로운 Progressive Crystallization 논문이 주는 유용한 부분입니다. 이 논문은 에이전트 팀들이 고통스러운 방식으로 재발견하게 될 라이프사이클 (lifecycle)을 명명합니다: 에이전트가 탐색하고, 트레이스 (traces)가 반복되는 동작을 증명하며, 테스트가 해당 동작을 워크플로우 코드 (workflow code)로 변환하고, 해당 실행으로부터 얻은 텔레메트리 (telemetry)가 워크플로우를 언제 다시 에이전트 계층으로 강등시킬지 결정합니다.

이 논문은 실제 사고를 처리하는 클라우드 네트워크 운영 시스템의 데이터를 제시하는데, 여기서 결정론적 실행 (deterministic executions)은 8개월 동안 0%에서 45%로 증가했습니다. 그동안 사고당 에이전트 비용은 70% 이상 감소했고 사고 건수는 두 배로 늘어났습니다. 모델이 단순히 저렴해진 것이 아닙니다. 해결된 작업이 더 이상 에이전트 작업이 아니게 된 것입니다.

탐색은 상류(upstream)에 속해야 합니다

우리는 에이전트 워크플로우 (agentic workflows)가 고정된 아키텍처 선택지로 취급되는 것을 계속해서 보고 있습니다: 에이전트를 구축하고, 도구를 부여하고, 승인 단계를 추가하고, 관측성 (observability)을 추가한 뒤 루프 (loop)가 개선되기를 바라는 식입니다.

더 나은 형태는 라이프사이클 (lifecycle)입니다.

점진적 결정화 분류 체계 (Progressive Crystallization taxonomy)는 라이프사이클 에이전트 (lifecycle agent)에서 실행이 취할 수 있는 다양한 가능한 형태를 정리합니다. 실행의 Type 3 형태는 '에이전트 오케스트레이션 (agent-orchestrated)'입니다. 즉, 에이전트가 제한된 자율성 (bounded autonomy)을 가지고 문제를 조사하며, 체크포인트 (checkpoint)를 생성하고, 인간의 승인을 통해 읽기 작업을 확인하며 쓰기 작업을 라우팅 (route)합니다. Type 2 형태의 실행은 '하이브리드 (hybrid)'입니다. 하이브리드 실행에서는 단계별 워크플로우 (workflow)가 워크플로우에 의해 소유되지만, 모델은 워크플로우 내의 특정 범위가 지정된 지점 (scoped points)에서 정보를 해석하거나 분류하는 데 사용됩니다. Type 1 형태의 실행은 '결정론적 (deterministic)'입니다. 이는 타입이 지정된 API 호출 (typed API calls), 조건문 (conditionals) 등으로 구성되며, 이들이 모여 경직되고 타협 불가능한 실행 경로를 형성합니다. Type 1 워크플로우에는 런타임 (runtime) 중에 모델을 호출 (model invocation)할 공간이 없습니다.

Lifecycle spectrum showing Type 3 agent exploration promoting through Type 2 hybrid workflow into Type 1 deterministic execution

성숙도 곡선 (maturity curve)은 에이전시 (agency)를 반복적인 실행에서 분리하여 새로움 (novelty)을 위한 영역으로 남겨둡니다.

이것이 기업 팀들이 에이전트적 워크플로우 (agentic workflows)를 구축하는 방식입니다. 먼저, 도구 (tools)와 상태 (state)를 사용하여 새로운 사건 (novel incident)을 탐색합니다. 그다음, 해당 사건이 반복됨에 따라 팀은 그 작업 경로를 구현하는 워크플로우를 원하게 됩니다. 그러다 해당 워크플로우가 예외 케이스 (edge cases)에서 이상하게 작동하기 시작하면, 시스템은 다시 탐색으로 돌아갈 수 있는 경로가 필요합니다. 이것이 바로 우리가 기업용 에이전트를 위한 기반으로서의 LangGraph (LangGraph as the foundation for enterprise agents)에 대해 계속해서 말해온 내용입니다.

컴파일 단계 (compile step)는 경제적 경계입니다

먼저 우리는 문제에 대해 한 번 "추론 (reason)"합니다. 그다음, 동일한 문제에 대한 해결책을 동일한 사건의 반복으로서 계속해서 실행합니다. Progressive Crystallization 논문은 실제 세계의 결정화 워크플로우 (crystallization workflow)를 기록하고 있으며, 이는 이 근본적인 소프트웨어 패턴 (software pattern)의 직관적인 구현임이 드러납니다.

Compiled AI 논문은 LLM을 사용하여 한 번 아티팩트 (artifact)를 생성하고, 해당 아티팩트를 검증한 다음, 실행 토큰 (execution tokens)을 전혀 사용하지 않고 대량의 코드를 실행하는 일종의 라이브 AI 시스템 클래스를 설명합니다. 저자들은 함수 호출 (function-calling)을 평가하였으며, 실행 토큰이 0개인 상태에서 96%의 작업 완료율을 보고했고, 함수를 컴파일하기 위한 손익분기점(break-even point)은 17번의 트랜잭션(transactions)이라고 밝혔습니다. 또한 1,000번의 트랜잭션 시점에서 토큰 사용량이 57배 감소했다고 보고했습니다.

만약 워크플로우 (workflow)가 반복적으로 실행된다면 (즉, 반복 가능한 프로세스라면), 그것이 에이전트적 워크플로우 (agentic workflow)라는 사실은 해당 워크플로우가 실행되는 횟수에 비례하는 세금 (tax)이 됩니다. 그 세금은 런타임 추론 (runtime inference)에 의해 강제되며, 따라서 런타임 추론 단계의 수를 줄임으로써, 특히 워크플로우의 각 단계를 실행하는 데 필요한 실행 토큰 (execution tokens)의 수를 줄임으로써 가장 효과적으로 대응할 수 있습니다. 이를 수행하기 위한 다양한 접근 방식(예: 모델 라우팅 (model routing), 프롬프트 캐싱 (prompt caching), 워크플로우의 각 단계를 구현하는 데 사용되는 LLM의 크기 축소 등)이 존재하지만, 이들은 모두 동일한 아이디어를 가리키고 있습니다: 충분히 많이 반복되는 프로세스는 직접 호출할 수 있는 함수로 컴파일할 가치가 있다는 것입니다. 우리는 이전에 AI 에이전트 비용은 런타임 신호이다 (AI Agent Cost Is a Runtime Signal)에서 비용 측면의 논거를 제시한 바 있으나, 그것은 전체 에이전트 수준에서의 이야기였던 반면, 이 세금은 에이전트 내의 개별 워크플로우에 의해 발생할 수 있습니다. 이것이 바로 Compiled AI의 핵심적인 움직임입니다.

참고로, 승격된 (promoted) 워크플로우는 트레이스 (trace) 상에서 약간 다른 계약 (contract)을 갖게 됩니다. 트레이스는 후보 명세 (candidate specification) 역할을 하며, 결과적으로 수락 테스트 (acceptance tests)를 통과해야 합니다. 승격된 워크플로우의 단계들은 멱등성 (idempotent)을 가진 부작용 (side effects)을 가져야 합니다 (예: 키를 사용한 upsert, 쓰기 전 읽기 (read-before-writes)). 트레이스 내의 인간 승인 (human approvals)은 단순한 채팅 턴 (chat turns)이 아니라 명시적인 상태 (explicit states)로서 워크플로우에 인코딩되어야 합니다. 승격된 워크플로우 내 단계들의 실패 모드 (failure modes)는 특정 유형 (예: 타입화된 종료 (typed exits))이어야 합니다.

LangGraph는 이음매 (seam)를 가시적으로 유지합니다

그렇다면 탐색 (exploration)과 실행 (execution) 사이의 이음매는 어디로 가는 걸까요?

LangGraph는 이러한 상황에서 특히 유용한데, 팀이 자유 형식의 에이전트 루프 (agent loop)를 사용하는 것과 완전한 워크플로우 엔진 (workflow engine)을 구축하는 것 사이에서 하나를 선택하도록 강요하지 않기 때문입니다. 대신, 팀이 기존의 Python 제어 흐름 (control flow)을 사용하면서 API 호출 및 기타 실행 로직을 메모리 (memory) 및 체크포인팅 (checkpointing)과 같은 지속성 프리미티브 (persistence primitives)로 감쌀 수 있게 해줍니다. Functional API의 두 가지 프리미티브인 @entrypoint와 @task는 단순하지만, 결과적으로 강력합니다. 엔트리포인트 (entrypoint)는 워크플로우를 정의하고, 태스크 (task)는 주어진 워크플로우 내의 작업을 정의합니다.

이러한 단순함은 두 가지 이유로 중요합니다. 첫째, 에이전트를 통한 특정 경로의 반복적인 실행은 단순히 함수의 반복적인 실행일 뿐입니다. 따라서 해당 함수는 Python 코드로 작성될 수 있으며, 애플리케이션에 여전히 유효하다면 중간에 모델 호출 (model call)을 포함할 수도 있습니다. 둘째, 태스크 API를 통해 팀은 데이터베이스 레코드를 위한 하나의 태스크와 승인을 위한 또 다른 태스크를 작성할 수 있습니다. 첫 번째 태스크에서 쓰기 작업은 멱등성 키 (idempotency key)를 가질 수 있고, 승인 작업은 자체적인 키를 가질 수 있습니다. 이런 방식으로 워크플로우는 여전히 승인 단계를 수행할 수 있으며, 단일하고 까다로운 프롬프트 (prompt) 내에서 이를 처리하지 않고도 에이전트를 위한 지속된 런타임 상태 (persisted runtime state)의 이점을 그대로 누릴 수 있습니다.

LangGraph는 또한 과거 워크플로우 실행(workflow runs)의 변경 사항을 추적하며, 재현 가능한 워크플로우 API (reproducible workflow API)를 위한 중요한 시사점들을 구현합니다. 저장된 워크플로우 체크포인트는 엔트리포인트 (entrypoint)의 시작부터 재개된 워크플로우로 로드되어, @entrypoint 호출을 재실행하고 마지막 체크포인트 이전에 완료된 @task 호출로부터 저장된 결과들을 로드합니다. 하위 호환성 문서는 그 시사점을 명확하게 설명합니다: 마지막 재개 지점 이전에 태스크 (task) 호출을 추가, 제거 또는 순서를 변경하면 잘못된 캐시된 값 (cached values)이 재생(replay)될 수 있습니다. 태스크 외부의 비결정론적 (Nondeterministic) 코드 또한 재생 중에 동작을 변경할 수 있습니다.

컴파일된 코드와 마찬가지로, 결정화된 워크플로우 (crystallized workflow)는 반복해서 실행할 수 있는 무언가입니다. 이는 버전 번호를 가질 수 있습니다. 완료되어야 하는 시간 범위 (drain window)를 가질 수 있습니다. 실행 중간에 새로운 버전으로 마이그레이션하기 위한 규칙 세트 (migration plan)를 가질 수 있습니다. 그리고 에이전트 루프 (agent loop)에서 승격(promoted)되어 나온 경로는 이제 해당 경로 실행의 지속된 기록 (persisted record)에 대한 API 호출처럼 동작하는 무언가가 됩니다. 따라서 이는 개별 프롬프트 (prompts)에 대한 일련의 개별적인 수정이 아니라, 하나의

반복 가능한 경로를 주장하는 모델은 대체로 무의미합니다. 동일한 사례가 동일한 경로를 통과하는 트레이스 (traces)의 코퍼스 (corpus)가 훨씬 더 가치 있습니다. 후보 사양 (candidate specification)에 대한 테스트를 통과하는 제안된 워크플로우 (workflow)는 훨씬 더 가치 있습니다. 적절한 도구 권한 (tool permissions)에 의해 제한되고, 모든 부작용 (side effects)에 대해 멱등성 (idempotent)을 가지며, 깨끗한 롤백 (rollback) 의미론을 갖추고, 인간의 개입 (human overrides)이 없는 승격된 작업 경로는 내구성 있는 소프트웨어 (durable software)처럼 보이기 시작합니다.

첫째, 승인 대기열 (approval queues)은 에이전트형 AI 워크플로우의 런타임 (runtime)에 속해야 합니다. 경로가 알려지면, 에이전트 오케스트레이션 (agent orchestration)은 코드에 속해야 합니다. 평가 (Evals)는 변경이 발생하는 지점과 가까이 있어야 하며, 트레이스 (traces)는 결정이 내려지는 지점과 가까이 있어야 합니다. 따라서 "승격" (즉, 특정 사례에 대한 특정 경로의 실제 사용)으로 가는 관문은 이제 서비스의 또 다른 릴리스 게이트 (release gate)일 뿐입니다.

노드의 안전한 재실행 (replay)을 결정하기 위한 지속적 상태 (persistent state), 재실행 가능한 작업 (re-executable work), 멱등적 쓰기 (idempotent writes) 등의 체크리스트는 지루하지만 반드시 존재해야 합니다. 반복되는 에이전트 경로가 새로운 "내구성 있는" 함수 호출 (function calls)로 "승격"되기 위해서는 바로 그러한 요소들이 필요합니다. 그때까지 그것들은 지속적인 계약 (persistent contract)이 없는 취약한 루프 내 임시방편 (in-the-loop workarounds)으로 남아 있으며, 따라서 회귀 테스트 (regression testing)를 위해 추적, 테스트 또는 재현할 방법이 없습니다.

관측성 (Observability)이 강등을 결정한다

승격 (Promotion)은 돈과 관련된 논의를 불러일으키지만, 강등 (Demotion)은 시스템을 정직하게 유지합니다.

결정론적 워크플로우 (deterministic workflow)는 퇴보할 수 있습니다. 작업이 사용하는 API가 변경될 수 있습니다. 필드를 추가하기 위해 펌웨어 (firmware)가 업데이트될 수 있습니다. 지원 정책이 변경될 수 있습니다. 워크플로우는 구문 유효성 검사 (syntactic validation)를 계속 통과하면서도, 실제로 수행되는 작업으로부터 서서히 벗어날 수 있습니다. 승격된 시스템은 매 실행마다 에이전트의 비용을 발생시키지 않으면서 이러한 종류의 퇴보를 감지할 수 있는 방법이 필요합니다. 트레이스 (traces)가 제어 평면 (control plane)이 됩니다.

OpenTelemetry의 GenAI 관측성(observability) 포스트는 에이전트를 호출하고, 모델과 채팅하며, 도구(tool)를 실행하는 엔드 투 엔드(end-to-end) 워크플로우에 대한 단일 트레이스(trace)를 설명합니다. Honeycomb의 빠른 AI 피드백 루프 관련 글은 유사한 텔레메트리(telemetry)가 어떻게 SLO, 경고(alerts), 대시보드(dashboards)를 구동하는 데 사용될 수 있는지, 그리고 Honeycomb의 네이티브 쿼리 언어로 어떻게 쿼리할 수 있는지를 보여줍니다.

이것이 바로 Agent Traces Rewrite the Harness가 중요한 이유와 같습니다. 실제 트래픽 하에서의 에이전트적 워크플로우(agentic workflow) 실행 트레이스는 매우 중요합니다. 트레이스는 평가 케이스(eval cases)가 되고, 하네스 패치(harness patches)가 되며, 릴리스 게이트(release gates)가 됩니다. 또한 해결된 문제에 대한 수정 사항이 실제로 계속 유지되고 있다는 확실한 증거를 제공합니다.

Promotion and demotion loop showing traces feeding tests, deterministic workflow promotion, monitoring, and fallback when drift appears

관측성(Observability)은 에이전트 트레이스를 승급 증거(promotion evidence)로 바꾸고, 드리프트(drift)를 강등 트리거(demotion trigger)로 바꿉니다.

플랫폼이 이전에 이미 패턴을 확인했음에도 불구하고 여전히 전체 에이전트 루프를 소모하고 있는 반복적인 장애 발생 횟수는, 낭비 신호(waste signal)로서 경영진에게 보고되어야 합니다.

에이전시(agency)는 새로움에 사용하세요

목표는 에이전트적 워크플로우에서 에이전트를 제거하는 것이 아닙니다. 그것은 역효과를 낼 것이며, 이미 해결된 경로를 에이전트 루프 안에 영원히 남겨두는 것만큼이나 어리석은 일입니다.