MissionFlows 대 Workflows: 적응형 에이전트 실행이 정적 DAG를 대체하는 방법

기존의 워크플로우 엔진은 첫 단계가 실행되기 전에 실행 경로가 알려져 있다고 가정합니다. Airflow DAG, Temporal 워크플로우, Prefect 파이프라인 등은 제어 흐름을 나타내는 엣지(edge)를 가진 작업들의 그래프를 인코딩합니다. 세 번째 단계에서 실패하면, 그 세 번째 단계를 재시도합니다. 특정 조건이 false로 평가되면, 미리 정의된 else 분기를 따릅니다.

에이전트 기반 시스템은 이러한 가정을 깨뜨립니다. 경로를 정의하는 대신, 임무(mission)를 정의하고 LLM을 백본으로 하는 에이전트가 런타임에 단계를 결정하도록 합니다. SFTP가 실패하면, 에이전트는 API를 시도합니다. 자격 증명(credentials)이 만료되면, 이를 새로 고칩니다. 주 엔드포인트가 다운되면, 대체 경로(fallback)를 선택합니다. 임무는 일정하게 유지됩니다. 실행 경로는 나타납니다.

이러한 변화는 새로운 인프라 문제를 야기합니다. 스스로 작성하는 워크플로우를 어떻게 관찰할 수 있을까요? YAML 대신 프롬프트에 존재하는 실행 로직을 어떻게 버전 관리할 수 있을까요? 미리 정의된 재시도 분기가 없을 때 실패로부터 어떻게 복구할 수 있을까요?

Workflows가 제공하는 것

워크플로우 엔진은 세 가지 보장을 제공합니다:

1. 결정론적 실행 그래프(Deterministic execution graph). 실행 전에 DAG를 시각화할 수 있습니다. 모든 노드와 엣지가 명시적입니다.
2. 체크포인트 경계(Checkpoint boundaries). 작업 경계에서 상태가 저장됩니다. 재시도 로직은 선언적(declarative)입니다.
3. 감사 추적(Audit trail). 어떤 작업이, 어떤 순서로 실행되었고, 무엇을 반환했는지 알 수 있습니다.

이러한 보장 덕분에 워크플로우는 디버깅이 가능합니다. 파이프라인에 실패하면, UI를 열어 빨간색 노드를 보고, 로그를 검사하고, 작업을 수정할 수 있습니다. 실패 표면은 DAG 구조에 의해 경계가 지어집니다.

MissionFlow가 포기하는 것

MissionFlow는 DAG를 목표(goal)와 일련의 가드레일(guardrails)로 대체합니다. 에이전트는

• 어떤 프로토콜을 사용할지 (SFTP, API, S3 presigned URL).
• 자격 증명 만료 처리 방법 (refresh token 사용, 새로운 자격 증명 요청, 사람에게 에스컬레이션).
• 성공의 정의 (파일 전송 완료, 체크섬 검증 완료, 다운스트림 시스템 승인).

실행 경로는 미리 정해져 있지 않습니다. 대신 런타임 컨텍스트(API 가용성, 자격 증명 유효성, 네트워크 상태, 에이전트가 미션을 해석하는 방식)에 따라 추론 단계들을 거치며 발견됩니다.

이는 세 가지 새로운 실패 모드를 도입합니다:

1. 추론 표류 (Reasoning drift). 에이전트가 미션을 잘못 해석하여 문자 그대로의 목표는 충족하지만 암묵적인 제약 조건을 위반하는 경로를 추구합니다.
2. 무한 탐색 (Unbounded exploration). 명시적인 가드레일(guardrails) 없이는 에이전트가 수십 가지 접근 방식을 시도하여, 수렴하지 못하면서 토큰과 시간을 소모할 수 있습니다.
3. 재현 불가능한 실패 (Non-reproducible failure). 동일한 입력으로 같은 미션을 수행하더라도 다른 실행 경로를 생성할 수 있어 디버깅이 더 어려워집니다.

DAG가 없는 관측 가능성 (Observability Without a DAG)

전통적인 워크플로우 UI는 노드를 녹색 또는 빨간색으로 색칠한 그래프를 렌더링합니다. 한눈에 실행 경로를 볼 수 있습니다. MissionFlows는 다른 관측 가능성 모델이 필요합니다.

추론 단계의 트레이스 로그 (Trace Logs of Reasoning Steps)

작업 경계 대신, 추론 단계를 기록합니다:

{
  "mission_id": "file-transfer-20261013-1847",
  "step": 3,
...
}

각 단계는 다음을 포착합니다:

• 에이전트가 관찰한 것 (SFTP 시간 초과).
• 무엇을 결정했는지 (서비스 레지스트리 조회).
• 무엇을 했는지 (레지스트리 API 호출).
• 무엇을 배웠는지 (대체 엔드포인트 발견).

이 로그 구조가 DAG 시각화를 대체합니다. 추적(trace)을 읽음으로써 실행 경로를 재구성할 수 있습니다.

추론 중간의 상태 체크포인트 (State Checkpoints Mid-Reasoning)

워크플로우는 작업 경계에서 체크포인트를 저장합니다. MissionFlows는 에이전트가 일시 중지하거나, 사람의 입력을 요청하거나, 외부 조건이 발생할 때까지 기다릴 수 있기 때문에 추론 중간에 체크포인트가 필요합니다.

체크포인트에는 다음이 포함됩니다:

• 임무 정의(mission definition).
• 지금까지의 추론 과정(reasoning trace).
• 현재 컨텍스트(자격 증명, 엔드포인트, 부분 결과).
• 에이전트가 다음으로 계획하는 행동.

에이전트가 충돌하거나 시간 초과되면 마지막 체크포인트부터 재개할 수 있습니다. 에이전트는 추적 과정을 다시 읽고, 컨텍스트를 재평가하며 계속 진행합니다.

실행 가능한 제약 조건으로서의 가드레일(Guardrails as Executable Constraints)

명시적인 가드레일 없이는 에이전트가 임무를 만족시키는 모든 경로를 추구할 수 있습니다. 가드레일은 탐색 공간을 제한하는 제약 조건입니다:

• 허용된 도구(Allowed tools). 에이전트는 sftp_transfer, api_upload, s3_presigned_url을 호출할 수 있지만, ssh_exec는 안 됩니다.
• 자격 증명 범위(Credential scope). 에이전트는 토큰을 새로 고칠 수는 있지만, 새로운 API 키를 요청할 수는 없습니다.
• 시간 예산(Time budget). 에이전트는 30분 이내에 임무를 완료하거나 상위 단계로 보고해야 합니다(escalate).
• 승인 게이트(Approval gates). 만약 에이전트가 승인된 목록에 없는 대체 엔드포인트를 사용하려면, 인간의 승인을 요청해야 합니다.

가드레일은 LLM이 아닌 오케스트레이션 레이어에서 강제됩니다. 에이전트가 행동을 제안하고, 오케스트레이터는 실행 전에 이를 가드레일에 따라 확인합니다.

사전에 정의된 재시도 로직 없는 실패 복구(Failure Recovery Without Predefined Retry Logic)

워크플로우에서는 재시도 로직이 선언적입니다:

task: transfer_file
  retry:
    max_attempts: 3
...

반면, MissionFlow에서는 에이전트가 재시도할지, 다른 접근 방식을 시도할지, 아니면 상위 단계로 보고할지를 결정합니다. 실행 경로가 고정되어 있지 않기 때문에 오케스트레이터는

에이전트가 진전을 만들 수 없을 때, 에스컬레이션(escalation)을 수행합니다. 에스컬레이션은 가드레일(guardrail)입니다:

• 에이전트가 세 가지 다른 접근 방식을 시도했지만 모두 실패한 경우, 인간 운영자에게 에스컬레이션합니다.
• 에이전트가 승인된 목록 외의 도구를 사용해야 하는 경우, 승인을 요청합니다.
• 미션 마감일이 다가오고 에이전트가 완료할 수 있다는 확신이 없는 경우, 조기에 에스컬레이션합니다.

에스컬레이션 경계는 무한 탐색을 방지합니다. 이는 잠재적으로 무한한 검색을 인간의 개입(human in the loop)을 통해 제한된 검색으로 바꿉니다.

미션 정의 버전 관리 (Versioning Mission Definitions)

워크플로우(Workflows)는 코드로 버전 관리됩니다. YAML 파일을 Git에 커밋하면, 워크플로우 엔진이 해당 버전을 실행합니다.

반면, 미션플로우(MissionFlows)는 프롬프트와 가드레일로 버전 관리됩니다. 미션 정의에는 다음 내용이 포함됩니다:

• 목표 진술 (자연어).
• 가드레일 (허용된 도구, 자격 증명 범위, 시간 예산, 승인 게이트).
• 컨텍스트 스키마 (에이전트가 런타임에 받는 정보).

미션을 버전 관리한다는 것은 프롬프트 템플릿과 가드레일 구성을 버전 관리하는 것을 의미합니다. 프롬프트의 변경은 코드를 변경하지 않고도 실행 경로를 바꿀 수 있습니다.

프롬프트 드리프트 (Prompt Drift)

워크플로우 DAG는 결정론적(deterministic)입니다. 동일한 입력은 동일한 실행 경로를 생성합니다. 하지만 미션플로우는 그렇지 않습니다. LLM의 동작이 변경되면 (모델 업데이트, 온도 설정, 토큰 예산 등), 동일한 미션과 동일한 입력이라도 다른 실행 경로를 생성할 수 있습니다.

프롬프트 드리프트를 완화하기 위해:

• LLM 버전 및 매개변수를 고정(Pin)합니다.
• 모든 추론 단계에 대한 전체 프롬프트와 응답을 기록(Log)합니다.
• 알려진 시나리오의 실행 경로를 검증하는 회귀 테스트(regression tests)를 실행합니다.

미션플로우의 회귀 테스트는 실행 경로가 고정되어 있지 않기 때문에 워크플로우보다 어렵습니다. 경로는 아닌, 결과(outcomes)를 테스트해야 합니다.

아키텍처: 오케스트레이터, 에이전트, 및 도구 계층 (Architecture: Orchestrator, Agent, and Tool Layer)

미션플로우 시스템은 세 개의 계층으로 구성됩니다:

에이전트는 상태를 유지하지 않는 (stateless) 역할을 합니다. 미션, 현재 컨텍스트, 그리고 추론 과정을 받습니다. 다음 행동(next action)을 반환합니다. 오케스트레이터는 가드레일을 기반으로 해당 행동을 실행할지 결정합니다.

툴 계층(tool layer) 역시 상태를 유지하지 않습니다. 각 툴은 매개변수를 받아 결과를 반환하는 함수입니다. 툴들은 미션이나 에이전트에 대해 알지 못합니다. 이들은 재사용 가능한 기본 요소(primitives)입니다.

예시: 파일 전송 미션 (File Transfer Mission)

# 미션 정의
mission = {
    "goal": "17:00 이전에 파일을 목적지로 안전하게 전송하고 처리 과정을 검증"
... 

오케스트레이터는 에이전트가 SFTP를 사용할지 API를 사용할지 미리 알지 못합니다. 오케스트레이터는 가드레일을 적용하고 추적 기록을 남깁니다. 행동 경로(path)를 결정하는 것은 에이전트입니다.

트레이드오프: MissionFlows 사용 시점

기술적 결론 (Technical Verdict)

MissionFlows는 실행 경로를 미리 결정할 수 없고 에이전트가 런타임 조건에 따라 적응해야 할 때 사용하세요. 이는 여러 대체 옵션이 있는 통합 시나리오, 근본 원인이 알려지지 않은 인시던트 대응(incident response), 그리고 가용성이 다른 이기종 시스템을 아우르는 데이터 파이프라인에 적용됩니다.

실행 경로가 안정적이고 실패 모드가 잘 이해되어 있다면 MissionFlows 사용을 피하세요. 관찰 가능성(observability) 및 디버깅 복잡도가 더 높습니다. 워크플로우를 이해하기 쉽게 만드는 결정론적 실행 그래프(deterministic execution graph)를 잃게 됩니다. 파이프라인이 매번 같은 방식으로 실행된다면, 전통적인 워크플로우 엔진이 더 간단하고 신뢰성이 높습니다.

관찰 가능성 인프라에 투자할 것을 예상하세요. 추론 단계의 트레이스 로그(trace logs), 체크포인트 관리(checkpoint management), 가드레일 적용(guardrail enforcement), 그리고 에스컬레이션 경계(escalation boundaries)가 필요합니다. MissionFlows를 위한 도구는 워크플로우보다 덜 성숙합니다. 사용자 정의 계측(custom instrumentation)을 구축해야 합니다.

가드레일부터 시작하세요. 명시적인 제약 조건 없이는 에이전트가 무한 탐색 공간(unbounded search spaces)을 탐색합니다. MissionFlow를 프로덕션에 배포하기 전에 허용되는 도구, 자격 증명 범위(credential scope), 시간 예산(time budgets), 그리고 승인 게이트(approval gates)를 정의하세요.

출처 링크

• 워크플로우에서 MissionFlows로 (Dev.to)