네 가지 접근 방식, 근본적인 차이점

워크플로 프레임워크를 선택한다는 것은 실행 모델 (execution model), 엔지니어링 비용, 그리고 팀의 역량을 맞추는 것을 의미합니다. 보편적으로 더 나은 옵션이란 존재하지 않습니다.

접근 방식         워크플로 정의         상태 지속성 (State persistence)    실행 엔진 (Execution engine)
──────────────────────────────────────────────────────────────────────────────
Prompt-based     Markdown + YAML         수동 작성된 JSON               LLM (A-layer)
...

처음 세 가지 방식은 의미론적 분기 (semantic branching, confidence >= 0.95)를 지원합니다. n8n은 불리언 표현식 (boolean expressions)으로 제한됩니다. LangGraph와 Temporal은 결정론적 코드 (deterministic code)를 실행 엔진으로 사용하는 반면, Prompt-based는 LLM 자체를 사용합니다.

Prompt-based

워크플로 정의 (Workflow definition): Markdown + YAML 파일

# workflow.md
## Phase 3: Root Cause Analysis
Execute subagent: rnd-automotive-issue-analyzer
...

강점 (Strengths):

• 엔지니어가 아닌 사람도 워크플로 정의를 읽고 수정할 수 있음
• Markdown을 변경하는 것이 코드를 변경하는 것보다 빠름 — 빈번한 반복 (iteration)에 적합
• LLM이 라우팅 로직 (routing logic)을 실행함; 모든 예외 케이스 (edge case)를 하드코딩할 필요가 없음
• 낮은 시작 비용; POC 및 빠른 검증에 적합

약점 (Weaknesses):

• LLM이 실행하는 라우팅은 비결정론적 (non-determinism)임: 동일한 입력이라도 실행 시마다 라우팅이 달라질 수 있음
• 언어 수준의 타입 시스템 (type system)이나 테스트 도구 지원이 없음
• 관찰 가능성 (Observability)을 위해 수동으로 Langfuse를 통합해야 함 — 기본 제공되지 않음
• Markdown 파일의 수가 증가함에 따라 유지보수 난이도가 높아짐

최적의 용도 (Best for):

• 코드를 편집하는 것보다 Markdown을 편집하는 것이 유리한, 빈번하게 변경되는 워크플로
• 전담 엔지니어가 없거나, 비기술 인력이 워크플로 로직을 유지 관리하는 팀
• 빠른 POC 검증 — 3일 만에 작동하는 MVP 구축

LangGraph

워크플로 정의 (Workflow definition): Python 코드 (그래프 구조)

from langgraph.graph import StateGraph, END
from typing import TypedDict

...

Prompt-based의 대응 개념과 매핑된 LangGraph 개념:

LangGraph 개념 | Prompt-based 대응 개념
────────────────────────────────────────────────────────
WorkflowState (TypedDict) | workflow_state.json 구조
...

이러한 매핑을 이해하면 처음부터 다시 작성하는 것이 아니라 체계적인 전환이 가능해집니다.

강점 (Strengths):

• 라우팅 로직 (Routing logic)이 순수 Python으로 작성되어 결정론적이며 단위 테스트 (unit-testable)가 가능함
• TypedDict 상태 스키마 (State Schema)가 타입 체크 (type checking)를 제공하여, 개발 단계에서 누락된 필드를 포착할 수 있음
• LangSmith 통합 기능 내장; 즉시 사용 가능한 트레이스 (Trace) 제공
• 복잡한 상태 머신 (state machines)을 위한 중첩된 서브그래프 (nested subgraphs) 지원

약점 (Weaknesses):

• 워크플로 정의가 코드 형태이므로, 엔지니어가 아닌 사람은 읽거나 수정할 수 없음
• 변경 사항이 코드 리뷰를 거쳐야 하므로, Markdown보다 반복 (iteration) 속도가 느림
• 학습 곡선: 그래프 구조와 StateGraph API에 대한 이해가 필요함

적합한 경우 (Best for):

• 정밀한 상태 머신 제어가 필요한 복잡한 워크플로 로직
• Python에 익숙하며, 워크플로가 비교적 안정적인 (매일 바뀌지 않는) 팀
• 코드 수준의 타입 체크 및 테스트 커버리지 요구 사항이 있는 경우

Temporal

워크플로 정의 (Workflow definition): Python 또는 TypeScript 코드

from temporalio import workflow, activity
from datetime import timedelta

...

강점 (Strengths):

• 코드 계층에서의 진정한 내구성 있는 실행 (Durable Execution) — 수동으로 작성한 상태 파일 없이도 충돌 복구 (crash recovery) 보장
• 장기 실행 워크플로 (며칠, 몇 주 단위)에 대한 네이티브 지원, SLA가 관리되는 엔터프라이즈 프로세스에 적합
• 내장된 시각화 UI 및 완전한 워크플로 히스토리 제공
• 액티비티 (Activities)와 워크플로 (Workflows)의 엄격한 분리

약점 (Weaknesses):

• 복잡한 배포: 실행 중인 Temporal Server가 필요함
• 높은 학습 곡선: Temporal의 프로그래밍 모델은 표준 비동기 (async) 코드와는 명확하지 않은 방식으로 다름
• Temporal의 액티비티 타임아웃 (Activity timeout) 및 재시도 (retry) 모델이 LLM 호출 동작과 깔끔하게 일치하지 않음

적합한 경우 (Best for):

• 1시간 이상 실행되며, 긴 대기 시간이 포함된 인간의 승인 (human approval)이 필요한 워크플로
• 강력한 일관성 보장 (consistency guarantees)이 필요한 엔터프라이즈급 프로세스
• 인프라를 관리하는 전담 백엔드 엔지니어가 있는 팀

n8n

워크플로 정의 (Workflow definition): 시각적 캔버스 (Visual canvas) + JSON

[HTTP Request] → [AI Agent] → [Condition] → [Jira Comment]
                              ↓
                           [Send Email]

강점 (Strengths):

• 시각적임; 비기술적 사용자도 워크플로를 구축하고 이해할 수 있음
• 방대한 내장 통합 노드 라이브러리 보유 (Jira, GitHub, Slack, 데이터베이스 등)
• 셀프 호스팅 (Self-hosted); 데이터가 온프레미스 (on-premises)에 유지됨

약점 (Weaknesses):

• 분기 (Branching)가 불리언 표현식 (boolean expressions)으로 제한됨; 의미론적 라우팅 (semantic routing)을 위해서는 외부 LLM 노드가 필요함
• 복잡한 상태 관리 (state management) (재시도 카운터, 후보 결과 집계 등)를 시각적 인터페이스에서 수행하기가 까다로움
• 버전 관리: JSON 파일의 차이점 (diffs)을 읽기 어려우며, 병합 충돌 (merge conflicts) 해결이 고통스러움
• AI Agent 노드의 기능이 제한적임 — 오케스트레이터-서브에이전트 (Orchestrator-Subagents) 패턴을 구현할 수 없음

적합한 경우 (Best for):

• 주로 API 통합을 목적으로 하며, AI는 여러 단계 중 하나로 사용되는 경우
• 비기술적 이해관계자에게 워크플로가 가시적으로 보여야 하는 경우
• 복잡한 상태 관리 요구사항이 없는 단순한 작업

의사결정 트리 (Decision Tree)

워크플로가 빈번하게 변경되는가; 비엔지니어가 이를 유지 관리해야 하는가?
  → Prompt-based (Markdown)

...

하이브리드 사용 (Hybrid use): 이러한 접근 방식들은 서로 배타적이지 않습니다. 실제 시스템에서는 트리거 및 알림 통합(예: 새로운 Jira 티켓 감지 → Feishu 알림 전송)을 위해 n8n을 사용하는 한편, 핵심 AI Agent 워크플로 로직은 LangGraph 또는 Prompt-based 방식을 사용할 수 있습니다.

Prompt-based에서 LangGraph로의 마이그레이션 (Migrating from Prompt-based to LangGraph)

매핑 과정은 체계적입니다. 작업의 핵심은 워크플로를 재설계하는 것이 아니라, 암시적인 LLM 라우팅 (implicit LLM routing)을 명시적인 Python 코드로 변환하는 것입니다.

1단계: workflow.md의 컨텍스트 구조를 WorkflowState로 변환

class WfBugE2EState(TypedDict):
    jira_key: str
    bug_info: dict | None
...

2단계: 각 단계(Phase)의 템플릿을 노드(Node) 함수로 변환

def phase3_analyze_node(state: WfBugE2EState) -> dict:
    result = spawn_subagent(
        template="templates/analyze.md",
...

3단계: workflow.md의 라우팅 조건(routing conditions)을 조건부 엣지(conditional_edges)로 변환

def route_after_analyze(state: WfBugE2EState) -> str:
    conf = state["analysis"]["confidence"]
    retries = state["analyze_retries"]
...

핵심 설계(단계(Phase) 구조, 컨텍스트 전달(Context passing), 승인 게이트(approval gates))는 양쪽 모두 동일합니다. 달라지는 점은 라우팅 로직이 "LLM이 조건을 해석하는 방식"에서 "Python이 조건을 평가하는 방식"으로 이동한다는 것입니다.

요약

1. 보편적으로 가장 좋은 프레임워크는 없으며, 오직 가장 적합한 프레임워크만 존재함: 빠른 반복(iteration)과 비기술적 유지보수를 위해서는 Prompt-based; 코드 수준의 테스트가 필요한 복잡한 상태 머신(state machines)에는 LangGraph; 장기 실행되는 엔터프라이즈 프로세스에는 Temporal; API 통합 및 시각적 표현에는 n8n이 적합합니다.
2. LangGraph와 Prompt-based는 상호 변환 가능함: WorkflowState = workflow_state.json, Node = Phase/Step, conditional_edges = routing conditions — 일대일 매핑이 가능하며 체계적인 마이그레이션(migration)이 가능합니다.
3. 프레임워크 선택이 핵심 엔지니어링을 바꾸지는 않음: 컨텍스트 전달(Context passing) 모드, 승인 게이트(approval gates), 멱등성(idempotency), 버전 바인딩(version binding) — 이러한 원칙들은 어떤 프레임워크를 사용하든 동일하게 적용됩니다.

실제 엔터프라이즈급 워크플로에서 검증된 AI 에이전트와 기술의 큐레이션 마켓플레이스인 PrimeSkills를 확인해 보세요. 불필요한 내용은 빼고, 실제로 작동하는 것들만 모았습니다.

제 홈페이지에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.