StateGraph와 씨름하고, 조건부 에지를 연결하고, 새벽 2시에 상태 딕셔너리를 디버깅해 본 적도 있죠. 동작은 하지만 — 어느 순간부터 프로덕션으로 가는 더 나은 길이 없을까 고민하게 됩니다.
있습니다. CrewAI Flows는 이벤트 기반 오케스트레이션, 조건부 라우팅, 공유 상태라는 동일한 힘을 훨씬 적은 보일러플레이트와 실제로 다단계 AI 워크플로우를 생각하는 방식에 잘 맞는 정신적 모델로 제공합니다.
이 글은 핵심 개념을 나란히 비교하고 실제 코드 비교를 보여주며, 다음으로 손이 갈 프레임워크가 왜 CrewAI Flows인지 설명합니다.
정신적 모델의 전환
LangGraph는 그래프로 생각하라고 요구합니다: 노드, 에지, 그리고 상태 딕셔너리. 모든 워크플로우는 계산 단계 사이의 전이를 명시적으로 연결하는 방향 그래프입니다. 강력하지만, 특히 워크플로우가 몇 개의 결정 지점이 있는 순차적 흐름일 때 이 추상화는 오버헤드를 가져옵니다. CrewAI Flows는 이벤트로 생각하라고 요구합니다: 시작하는 메서드, 결과를 듣는 메서드, 실행을 라우팅하는 메서드. 워크플로우의 토폴로지는 명시적 그래프 구성 대신 데코레이터 어노테이션에서 드러납니다. 이것은 단순한 문법 설탕이 아니라 — 파이프라인을 설계하고 읽고 유지하는 방식을 바꿉니다. 핵심 매핑은 다음과 같습니다:
실제로 어떻게 보이는지 살펴보겠습니다.
데모 1: 간단한 순차 파이프라인
주제를 받아 조사하고, 요약을 작성한 뒤, 결과를 포맷팅하는 파이프라인을 만든다고 해봅시다. 각 프레임워크는 이렇게 처리합니다.LangGraph 방식
CrewAI Flows 방식
@start()는 진입점을 표시하고, @listen(method_name)은 단계들을 연결합니다. 상태는 타입 안전성, 검증, IDE 자동 완성까지 제공하는 제대로 된 Pydantic 모델입니다.
데모 2: 조건부 라우팅
여기서 흥미로워집니다. 콘텐츠 유형에 따라 서로 다른 처리 경로로 라우팅하는 파이프라인을 만든다고 해봅시다.LangGraph 방식
CrewAI Flows 방식
@router() 데코레이터는 메서드를 결정 지점으로 만듭니다. 리스너와 매칭되는 문자열을 반환하므로, 매핑 딕셔너리도, 별도의 라우팅 함수도 필요 없습니다. 분기 로직이 Python if 문처럼 읽히는 이유는, 실제로 if 문이기 때문입니다.
데모 3: AI 에이전트 Crew를 Flow에 통합하기
여기서 CrewAI의 진짜 힘이 드러납니다. Flows는 LLM 호출을 연결하는 것에 그치지 않고 자율적인 에이전트 Crew 전체를 오케스트레이션합니다. 이는 LangGraph에 기본으로 대응되는 개념이 없습니다.데모 4: 병렬 실행과 동기화
실제 파이프라인은 종종 작업을 병렬로 분기하고 결과를 합쳐야 합니다. CrewAI Flows는and_와 or_ 연산자로 이를 우아하게 처리합니다.
@start() 데코레이터는 병렬로 실행됩니다. @listen 데코레이터의 and_() 결합자는 synthesize_report가 세 가지 상위 메서드가 모두 완료된 뒤에만 실행되도록 보장합니다. 어떤 상위 작업이든 끝나는 즉시 진행하고 싶다면 or_()도 사용할 수 있습니다.
LangGraph에서는 병렬 분기, 동기화 노드, 신중한 상태 병합이 포함된 fan-out/fan-in 패턴을 만들어야 하며 — 모든 것을 에지로 명시적으로 연결해야 합니다.
프로덕션에서 CrewAI Flows를 쓰는 이유
깔끔한 문법을 넘어, Flows는 여러 프로덕션 핵심 이점을 제공합니다: 내장 상태 지속성. Flow 상태는 LanceDB에 의해 백업되므로 워크플로우가 크래시에서 살아남고, 재개될 수 있으며, 실행 간에 지식을 축적할 수 있습니다. LangGraph는 별도의 체크포인터를 구성해야 합니다. 타입 안전한 상태 관리. Pydantic 모델은 즉시 검증, 직렬화, IDE 지원을 제공합니다. LangGraph의TypedDict 상태는 런타임 검증을 하지 않습니다.
일급 에이전트 오케스트레이션. Crews는 기본 프리미티브입니다. 역할, 목표, 배경, 도구를 가진 에이전트를 정의하고, Flow의 구조적 틀 안에서 자율적으로 협업하게 합니다. 다중 에이전트 조율을 다시 만들 필요가 없습니다.
더 단순한 정신적 모델. 데코레이터는 의도를 선언합니다. @start는 “여기서 시작”, @listen(x)는 “x 이후 실행”, @router(x)는 “x 이후 어디로 갈지 결정”을 의미합니다. 코드는 자신이 설명하는 워크플로우처럼 읽힙니다.
CLI 통합. crewai run으로 Flows를 실행합니다. 별도의 컴파일 단계나 그래프 직렬화가 없습니다. Flow는 Python 클래스이며, 그대로 실행됩니다.
마이그레이션 치트 시트
LangGraph 코드베이스를 CrewAI Flows로 옮기고 싶다면, 다음의 실전 변환 가이드를 참고하세요:- 상태를 매핑하세요.
TypedDict를 PydanticBaseModel로 변환하고 모든 필드에 기본값을 추가하세요. - 노드를 메서드로 변환하세요. 각
add_node함수는Flow서브클래스의 메서드가 됩니다.state["field"]읽기는self.state.field로 바꾸세요. - 에지를 데코레이터로 교체하세요.
add_edge(START, "first_node")는 첫 메서드의@start()가 됩니다. 순차적인add_edge("a", "b")는b메서드의@listen(a)가 됩니다. - 조건부 에지는
@router로 교체하세요. 라우팅 함수와add_conditional_edges()매핑은 하나의@router()메서드로 통합하고, 라우트 문자열을 반환하세요. - compile + invoke를 kickoff으로 교체하세요.
graph.compile()를 제거하고flow.kickoff()를 호출하세요. - Crew가 들어갈 지점을 고려하세요. 복잡한 다단계 에이전트 로직이 있는 노드는 Crew로 분리할 후보입니다. 이 부분에서 가장 큰 품질 향상을 체감할 수 있습니다.
시작하기
CrewAI를 설치하고 새 Flow 프로젝트를 스캐폴딩하세요:type = "flow"가 이미 설정된 pyproject.toml이 포함된 프로젝트 구조가 생성됩니다. 다음으로 실행하세요:
마무리
LangGraph는 AI 워크플로우에 구조가 필요하다는 사실을 생태계에 일깨워 주었습니다. 중요한 교훈이었습니다. 하지만 CrewAI Flows는 그 교훈을 더 빠르게 쓰고, 더 쉽게 읽으며, 프로덕션에서 더 강력한 형태로 제공합니다 — 특히 워크플로우에 여러 에이전트의 협업이 포함될 때 그렇습니다. 단일 에이전트 체인을 넘는 무엇인가를 만들고 있다면, Flows를 진지하게 검토해 보세요. 데코레이터 기반 모델, Crews의 네이티브 통합, 내장 상태 관리를 통해 배관 작업에 쓰는 시간을 줄이고, 중요한 문제에 더 많은 시간을 쓸 수 있습니다.crewai create flow로 시작하세요. 후회하지 않을 겁니다.