AI 워크플로 정의의 4가지 진화: Markdown에서 JS 스크립트를 거쳐 분산형 멀티 에이전트(Distributed

서문

"AI를 사용하여 개발 워크플로(Workflow)를 자동화하라" — 거의 모든 기술 기업이 이 이야기를 합니다.

하지만 다음 사항에 대해 진지하게 논의하는 기업은 매우 드뭅니다: 워크플로(Workflow) 자체를 어떻게 정의해야 하는가? 어떤 기술적 형태로 표현해야 하는가?

이는 부차적인 문제처럼 보일 수 있습니다. 하지만 실제로는 핵심적인 문제입니다. 워크플로(Workflow)가 어떻게 정의되느냐에 따라 그것이 안정적으로 실행될 수 있는지, 모니터링이 가능한지, 에이전트(Agents)가 업데이트되어도 안정성을 유지할 수 있는지, 그리고 팀 간에 공유 및 재사용이 가능한지가 결정됩니다.

이 글은 엔터프라이즈 AI 플랫폼 실무에서 워크플로(Workflow) 정의 방식이 어떻게 진화해 왔는지에 대한 완전한 회고입니다.

기술 진화의 4단계

1단계: Markdown 프롬프트 기반 워크플로 기술 (Markdown Prompt-Based Workflow Description)

초기 접근 방식: 자연어와 Markdown 형식을 사용하여 워크플로(Workflow)를 기술하고, 이를 지정된 디렉토리에 배치하여 에이전트(Agent)가 해당 기술에 따라 실행하도록 하는 방식입니다.

장점: 진입 장벽이 낮고, 유연하며, 사람이 읽기 쉽습니다. 복잡한 비즈니스 의도를 빠르게 표현할 수 있습니다.

근본적인 한계: 프롬프트(Prompt) 기술을 실행하는 LLM은 "실행(executing)"하는 것이 아니라 "해석(interpreting)"하는 것입니다. 즉, 동일한 기술이라도 실행할 때마다 새로운 해석을 만들어냅니다. 단계들이 엄격하게 순서대로, 그리고 조건에 따라 실행된다는 보장이 없습니다.

이는 프롬프트(Prompt) 품질의 문제가 아닙니다. 이러한 표현 방식이 가진 **이론적 한계(theoretical ceiling)**입니다. 완벽한 Markdown을 작성하더라도, LLM은 실행 시마다 예상된 단계 순서에서 벗어나거나, 특정 체크를 건너뛰거나, 분기 조건에 대해 일관되지 않은 판단을 내릴 수 있습니다.

2단계: 스크립트 기반 오케스트레이션 (Script-Based Orchestration, 플랫폼 내장 솔루션)

일부 엔터프라이즈 AI 플랫폼은 자연어 기술을 대체하고 결정론적 제어 흐름(deterministic control flow)을 달성하기 위해 내장된 프로세스 오케스트레이션(process orchestration) 스크립트 언어를 제공합니다.

진전 사항: 실행의 결정론적(determinism) 문제를 해결했습니다. 프로세스 실행 순서가 LLM의 해석이 아닌 코드에 의해 제어됩니다.

Hard limit encountered (한계 직면): 오케스트레이션 계층 (Orchestration layer)과 스킬 계층 (Skill layer)이 단절되어 있습니다. 만약 스크립트가 고정된 도구 세트(예: bash 명령어만 사용)만 호출할 수 있고, AI 스킬 계층 (AI Skill-layer)의 기능을 호출할 수 없다면, 워크플로 (Workflow) 실행은 심각하게 제한됩니다.

이는 중요한 요구사항을 드러냈습니다: 워크플로 오케스트레이션 계층 (Workflow orchestration layer)은 AI 스킬 (AI Skills)을 원활하게 호출할 수 있어야 합니다.

3단계: 거대 스킬로 정의된 워크플로 (과도기적 단계)

오케스트레이션 계층과 스킬 계층 사이의 단절을 해결하기 위한 일반적인 과도기적 접근 방식은, 전체 워크플로를 완전한 단계 설명이 포함된 하나의 거대한 스킬 (Skill)로 패키징하는 것입니다.

이 접근 방식에는 네 가지 내재적인 결함이 있습니다:

실행 정확도 변화 없음: 근본적으로 여전히 자연어를 해석하기 위해 LLM을 사용하므로, 결정론 (determinism) 측면에서 개선이 없습니다.
노드 수준의 모니터링 불가: 전체 워크플로가 블랙박스(black box) 상태가 되어, 어떤 단계에서 실패했는지 가시성을 확보할 수 없습니다.
개념적 혼재: 워크플로 오케스트레이션 로직이 원자적(atomic)인 역량을 가진 스킬 (Skills) 내에 뒤섞이게 됩니다.
에이전트 간 협업 불가: 모든 로직이 단일 에이전트 (Agent)의 컨텍스트 (context) 내에 존재하며, 분산 실행 (distributed execution)을 지원하지 않습니다.

4단계: 네이티브 JS 워크플로 (현재 가장 실행 가능한 형태)

Claude Code와 같은 엔터프라이즈 AI 코딩 플랫폼은 JS 스크립트를 기반으로 한 네이티브 워크플로 (Native Workflow) 메커니즘을 도입했습니다. 여기서는 각 단계가 코드 수준의 제어를 가지며, 에이전트 (Agents)는 프롬프트 (prompts)를 통해 작업을 완료하도록 지시받습니다.

이는 현재 엔지니어링 단계에 가장 근접한 형태이지만, 아래에서 논의할 새로운 경계 문제 (boundary problems)를 야기하기도 합니다.

AI 워크플로의 핵심 갈등: 표현력(Expressiveness) vs 실행 결정론(Execution Determinism)

자연어 (Natural language): 표현력(Expressiveness)이 높고, 모호성과 문맥 의존성(context dependencies)을 처리할 수 있으며, 사람이 읽고 쓰기 쉽습니다. 하지만 LLM의 실행이 예측 불가능하여 흐름의 결정론(flow determinism)을 보장할 수 없습니다.
코드 (Code): 실행 결정론(execution determinism)이 강력하고, 버전 관리(version-controllable) 및 테스트가 가능합니다. 하지만 개발자가 아닌 사용자에게는 기술적 장벽이 존재하며, 경직된 구조로 인해 에이전트(Agent)가 예상치 못한 상황에 스스로 적응하는 능력이 제한됩니다.

현재 가장 합리적인 설계 원칙은 다음과 같습니다: 코드(code)를 사용하여 흐름 구조(실행 순서, 분기 조건, 체크포인트)를 제어하고, 각 노드(node) 내의 작업 의미론(task semantics)을 정의하는 데는 자연어(natural language)를 사용하는 것입니다.

// 코드가 흐름 구조를 제어함 (결정론적)
phase('Bug Analysis')
const analysis = await agent('Analyze the root cause of this bug', { schema: BUG_ANALYSIS_SCHEMA })
...

현재 네이티브 워크플로(Native Workflow)에 대한 평가

핵심 장점

실행 결정론 (Execution determinism): 단계(Phase) 실행 순서, 조건부 분기(conditional branching), 루프 로직이 JS 코드로 제어됩니다. 워크플로의 "골격(skeleton)"은 실행 간에 변하지 않습니다.

노드 수준의 관측 가능성 (Node-level observability): 각 단계(Phase)의 실행 상태를 실시간 뷰로 추적할 수 있어, 워크플로의 현재 위치와 어느 단계에서 실패했는지를 명확하게 보여줍니다. 이는 프롬프트 기반 워크플로(Prompt-based Workflows)의 블랙박스 실행 방식에 비해 질적으로 향상된 부분입니다.

기술 호출(Skill invocation) 가능: JS 스크립트를 통해 특정 단계(Phase)에서 특정 기술(Skill)을 호출하도록 에이전트(Agent)에게 프롬프트로 명시적으로 지정할 수 있습니다. 이는 순수 프롬프트 설명보다 정확도가 높으며, 기술 호출과 워크플로 오케스트레이션(Workflow orchestration) 사이의 단절 문제를 상당 부분 해결합니다.

관리 가능한 코드 자산으로서의 워크플로: JS 스크립트는 git으로 관리하고, 코드 리뷰를 수행하며, 팀 간에 공유하고, 지속적으로 반복 개선할 수 있습니다. 이는 워크플로가 일회성 사용을 넘어 재사용 가능한 자산으로 발전하기 위한 전제 조건입니다.

결정적인 한계

프로세스 간 / 컨테이너 간 오케스트레이션(Cross-process / cross-container orchestration) 미지원

네이티브 워크플로 (Workflow) 실행 모델은 단일 세션 내의 마스터-서번트 (master-servant) 관계입니다. 즉, 하나의 메인 에이전트 (Agent)가 워크플로 정의를 읽고 실행 중에 동적으로 서브 에이전트 (subagent)를 생성하며, 모든 에이전트는 동일한 세션 컨텍스트 (session context)를 공유합니다.

하지만 엔터프라이즈 에이전트 플랫폼 (Agent Platform) 설계는 **멀티 프로세스 피어 협업 (multi-process peer collaboration)**을 목표로 합니다. 개발 에이전트, 테스트 에이전트, 요구사항 관리 에이전트가 각각 독립적인 프로세스로서 독립된 컨테이너에서 실행됩니다. 이 두 모델은 근본적으로 호환되지 않습니다.

네이티브 워크플로를 에이전트 플랫폼에 직접 적용하면 프로세스 간 오케스트레이션 (cross-process orchestration) 문제에 직면하게 됩니다. 즉, 한 인스턴스가 다른 인스턴스를 스케줄링할 수 있는 네이티브 메커니즘이 존재하지 않습니다.

도구 생태계 종속 (lock-in) 리스크

네이티브 JS 워크플로 형식과 실행 엔진은 특정 도구에 종속된 독점적 (proprietary) 기술입니다. 만약 나중에 AI 프로그래밍 도구를 교체하기로 결정한다면, 축적된 워크플로 스크립트 자산들을 직접 마이그레이션할 수 없으며 처음부터 다시 구현해야 합니다. AI 도구 선택이 안정화되지 않은 현 시점에서, 이는 명시적인 트레이드오프 (trade-off) 분석이 필요한 전략적 리스크입니다.

업계 현황: AI 워크플로를 위한 크로스 플랫폼 표준은 아직 부재함

현재 주류 AI 워크플로 도구의 정의 형식은 파편화되어 있습니다:

도구	워크플로 형식
Claude Code	JS 스크립트, 단계 기반 (phase-based), 세션 내부 실행
...

파편화의 직접적인 결과는 다음과 같습니다: 서로 다른 도구 간의 워크플로 자산을 수평적으로 재사용할 수 없습니다. 팀이 도구를 변경하면 워크플로 축적을 처음부터 다시 시작해야 합니다. 전통적인 BPM이 독점적 형식에서 BPMN 2.0 표준으로 진화하는 데 약 10년이 걸렸던 것처럼, AI 워크플로 역시 유사하게 혼란스러운 초기 단계에 있습니다.

권장 사항: 워크플로 의도 계층 (Intent Layer)과 실행 엔진 (Execution Engine)의 분리

표준이 확립되지 않고 형식이 파편화된 현재 상황을 고려할 때, 권장되는 설계 전략은 **의도 계층 (intent layer)을 실행 엔진 (execution engine)으로부터 분리 (decoupling)**하는 것입니다:

단기적 (Short-term): 특정 도구의 네이티브 형식(예: Claude Code JS, LangGraph Python)을 기업용 워크플로(Workflow) 저장 형식으로 사용하지 마십시오. 워크플로의 "의도 계층 (intent layer)"를 기술하기 위해 벤더 중립적인 형식(YAML/JSON 스펙)을 사용하십시오. 여기에는 다음 내용이 포함되어야 합니다: 이 워크플로가 달성하고자 하는 목표, 단계(phases), 각 단계의 입출력(inputs/outputs) 및 성공 기준, 체크포인트(checkpoints) 위치 등입니다. 실행 엔진(execution engine)은 이 스펙을 대상 플랫폼의 네이티브 형식으로 렌더링하여 실행하는 교체 가능한 어댑터 계층(adapter layer) 역할을 합니다.

중기적 (Medium-term): 기업 내부의 워크플로 스펙 표준을 수립하고, 서로 다른 실행 엔진을 위한 변환 계층(translation layers)을 제공하십시오. 초기 비용은 더 높지만, 진정한 이식성(portability)을 달성할 수 있습니다. 즉, 도구를 교체하더라도 워크플로에 축적된 비즈니스 지식을 잃지 않게 됩니다.

분산형 멀티 에이전트 (Distributed Multi-Agent) 시나리오를 위한 아키텍처 선택

에이전트 플랫폼(Agent Platform)의 목표가 여러 전문화된 에이전트(개발 에이전트, 테스트 에이전트, 요구사항 관리 에이전트)의 협업인 경우, 누가 워크플로 상태(Workflow state)를 보유하느냐가 핵심적인 아키텍처 질문이 됩니다.

세 가지 아키텍처 패턴

패턴 1: 오케스트레이터로서의 플랫폼 (Platform as Orchestrator)

에이전트 플랫폼 (Agent Platform, 워크플로 엔진)
    ├── 워크플로 상태 머신 (Workflow state machine) 유지
    ├── 현재 단계에 따라 호출할 에이전트 결정
...

가장 큰 장점은 책임 소재가 명확하다는 것입니다. 에이전트는 오직 "이 작업을 잘 수행하는 것"에만 집중하면 됩니다. 즉, 자신이 어떤 비즈니스 프로세스의 어느 단계에 있는지 알 필요가 없습니다. 워크플로의 비즈니스 로직이 변경되어도 에이전트 구현에는 영향을 주지 않으며, 에이전트의 기능이 업그레이드되어도 워크플로 정의에는 영향을 주지 않습니다.

패턴 2: 오케스트레이터 에이전트 모델 (Orchestrator Agent Model)

자체 컨테이너에서 실행되는 특수한 "오케스트레이터 에이전트 (orchestrator Agent)" 유형을 추가합니다. 이 에이전트는 워크플로 정의를 읽고, 상태를 유지하며, 플랫폼 API를 통해 다른 에이전트들을 호출하는 책임을 집니다.

워크플로 (Workflow) 로직이 복잡하고 흐름 경로를 결정하기 위해 AI의 판단이 필요한 시나리오에 적합합니다. 트레이드오프 (Trade-off)는 시스템 복잡성을 증가시키는 추가적인 에이전트 (Agent) 유형을 도입해야 한다는 점입니다.

패턴 3: 공유 워크스페이스 + 이벤트 기반 (Shared Workspace + Event-Driven)

에이전트들은 직접 통신하지 않고 — 공유 워크스페이스 (Git 리포지토리, 태스크 보드 등)를 통해 협업합니다. 워크플로는 어떤 트리거 조건 (Trigger conditions)이 각 에이전트의 개입을 유발하는지, 그리고 다음 이벤트를 트리거하기 위해 어떤 아티팩트 (Artifacts)를 생성해야 하는지를 정의합니다.

가장 견고하지만 (어느 한 에이전트가 실패하더라도 다른 에이전트에게 영향을 주지 않음), 워크플로의 전체 상태를 시각화하기 어렵고 디버깅 (Debug)이 까다롭습니다 — 따라서 강력한 감사 (Auditing)와 모니터링 (Monitoring)이 요구되는 엔터프라이즈 (Enterprise) 시나리오에는 적합하지 않습니다.

권장 사항: 플랫폼 오케스트레이션 + 에이전트 실행 (Platform Orchestration + Agent Execution)

엔터프라이즈 에이전트 플랫폼 (Agent Platforms)의 경우, 다음 원칙을 따르는 패턴 1을 기본 아키텍처로 권장합니다:

에이전트는 워크플로 지식을 보유하지 않음: 개발 에이전트 (Development Agent)는 자신이

플랫폼에서 워크플로 상태 유지 (Workflow state persisted at the platform): 플랫폼은 각 워크플로 (Workflow) 인스턴스의 상태(현재 단계, 각 단계의 입력/출력, 과거 실행 기록)를 유지해야 합니다. 이는 모니터링 및 감사 (Auditing)를 위한 기초가 될 뿐만 아니라, 체크포인트로부터 재개 (Resume-from-checkpoint) 기능을 지원하기 위한 전제 조건입니다. 즉, 특정 단계가 실패하더라도 전체 워크플로를 다시 시작할 필요 없이 마지막으로 성공한 체크포인트부터 다시 트리거할 수 있습니다.

구체적인 아키텍처 예시

"요구사항 분석 → 개발 → 테스트"로 이어지는 엔드 투 엔드 (End-to-end) 워크플로를 예로 들면 다음과 같습니다:

트리거 (Trigger): PM이 요구사항 기술서 제출

[플랫폼 워크플로 엔진 (Platform workflow engine)]
...

이 아키텍처에서 각 에이전트 (Agent)는 자신의 컨테이너 (Container) 내에서 독립적으로 실행되며, 플랫폼이 작업 분배 (Task distribution) 및 상태 전이 (State transitions)를 처리합니다. 또한 엔드 투 엔드 워크플로 뷰 (Workflow view)는 플랫폼 계층에서 완전히 가시적으로 확인됩니다.

요약

이전 단계에서 드러난 문제들을 각각 해결하며 발전해 온 AI 워크플로 정의의 4가지 진화 과정은 다음과 같습니다:

Markdown → 스크립트 오케스트레이션 (Script orchestration): 실행 결정론 (Execution determinism) 문제 해결
스크립트 오케스트레이션 → 대규모 스킬 (Large Skill): 스킬 호출 (Skill invocation) 문제 해결 (단, 새로운 문제 발생)
대규모 스킬 → 네이티브 JS 워크플로 (Native JS Workflow): 결정론과 스킬 호출 문제를 동시에 해결
네이티브 JS 워크플로 → 분리된 의도 계층 (Decoupled intent layer): 도구 종속성 (Tool lock-in) 및 프로세스 간 협업 문제 해결