에이전틱AI 구조 패턴 - Assiworks Claude LangGraph CrewAI 등

에이전틱 AI는 “LLM 하나에 툴 몇 개 붙인 챗봇”을 넘어서, 여러 역할의 에이전트가 협동·분업·검증을 수행하는 작업 시스템(work system) 으로 진화하고 있다. 이때 핵심은 모델 자체가 아니라, 에이전트들이 어떤 형태로 연결되고 제어되는가, 다시 말해 구조 패턴(architecture pattern) 이다. 

1. 개요 

먼저 구조 패턴을 독립적으로 정리한 뒤, 이어서 Assiworks, Claude Code·LangGraph·OpenAI Swarm·CrewAI 등이 각각 어떤 패턴 조합을 채택하고 있는지, 솔루션 관점에서 구분해 설명한다.

2. 구조 패턴 A: 단일 에이전트 루프(Single-Agent / ReAct)

단일 에이전트 루프는 가장 기본적인 형태로, 에이전트 1개가 “생각 → 툴 호출 → 관찰 → 다음 생각”을 반복하며 전체 태스크를 책임지는 구조다. 보통 ReAct, Tool Calling 기반의 고전적인 에이전트가 여기에 해당하며, 대부분의 프레임워크에서 “기본 에이전트 모드”로 제공된다.

2.1. 구조 요약

• 구성: 단일 LLM 에이전트가 하나의 대화 컨텍스트를 유지하며, 여러 도구(코드 실행, 검색, DB, HTTP 등)를 필요할 때마다 호출한다. 이때 플로우 제어 로직은 별도 그래프나 상태머신 없이, 대부분 모델의 체인 오브 소트(CoT)와 툴 선택 능력에 내장된다.
• 흐름: 사용자가 프롬프트를 주면 에이전트는 내부적으로 계획을 세우고, 필요한 툴을 호출해 관찰 결과를 얻은 뒤, 이를 바탕으로 다시 추론을 이어가는 식으로 루프를 돈다. 이 과정이 “추론–행동–관찰”의 반복으로 모델 내부에서 암묵적으로 구현된다는 점이 특징이다.

2.2. 장단점

• 장점: 아키텍처와 인프라 요구사항이 단순해, 초기 구현과 디버깅이 매우 용이하다. 작은 범위의 문제나 단일 도메인(예: 특정 사내 시스템에 붙인 질의응답, 단일 문서 보조 등)에서는 이 구조만으로도 충분한 성능과 생산성을 낼 수 있다.
• 단점: 모든 의사결정과 컨텍스트가 하나의 에이전트에 집중되기 때문에, 프로젝트 규모가 커질수록 컨텍스트 폭발, 역할 혼합, 책임 추적 어려움이 한꺼번에 발생한다. 특히 장기 플로우·여러 도메인·권한 분리가 필요한 업무에는 구조적 한계가 분명하다.

3. 구조 패턴 B: 허브–스포크 Orchestrator–Worker

허브–스포크 패턴은 중앙의 오케스트레이터(Orchestrator) 가 여러 워커(Worker) 에이전트를 조율하는 구조로, 요즘 멀티에이전트 아키텍처에서 가장 많이 언급되는 패턴 중 하나다. LangGraph Supervisor 튜토리얼에서 “Supervisor pattern”으로 정식 명명하고 있고, 여러 프레임워크가 이 개념을 변형해 채택하고 있다.

3.1. 구조 요약

• Orchestrator: 사용자의 입력과 현재 시스템 상태를 종합적으로 파악한 뒤, 전체 작업을 서브태스크로 분해하고, 각 태스크를 어떤 Worker에게 맡길지 결정하는 중앙 관제 역할을 수행한다. 오케스트레이터는 작업 순서, 재시도, 실패 처리, 최종 응답 조립까지 책임지므로, 사실상 “AI 팀의 PM/Tech Lead”에 해당한다.
• Workers: 각 Worker 에이전트는 특정 역할(리서처, 코더, 리뷰어, DB 쿼리 담당 등)에 특화되어 있고, 자신에게 위임된 서브태스크를 처리한 뒤 결과(요약, 코드 패치, 분석 리포트 등)를 오케스트레이터에게 반환한다. Worker들끼리는 직접 통신하지 않고, 항상 Orchestrator를 단일 허브로 사용한다는 점이 구조적으로 중요하다.

3.2. 장단점

• 장점: 역할과 책임이 명확하게 분리되어, 개별 에이전트를 교체·확장·튜닝하기가 상대적으로 쉽다. 또한 중앙에서 품질 기준, 안전 정책, 우선순위를 일관되게 적용할 수 있어, 엔터프라이즈 환경에서 거버넌스·모니터링 관점에서 유리하다.
• 단점: 모든 흐름이 중앙을 거치므로, 오케스트레이터가 병목이 되거나 로직이 과도하게 비대해질 위험이 있다. 더불어 Orchestrator가 잘못 설계되면, 결국 “단일 에이전트 루프에 Worker를 얇게 감싼 것”과 다르지 않은 구조로 퇴화할 수 있다.

4. 구조 패턴 C: 그래프·상태머신 기반 오케스트레이션

그래프·상태머신 패턴은 에이전트 호출 흐름 전체를 노드(Node)와 엣지(Edge) 로 모델링하고, 공유 상태(State)를 명시적으로 다루는 접근이다. LangGraph가 대표적으로 이 패턴을 프레임워크 레벨로 끌어올렸고, n8n이나 기타 워크플로우 엔진은 GUI 기반으로 비슷한 개념을 제공한다.

4.1. 구조 요약

• Node: 개별 노드는 LLM 에이전트 호출, 특정 툴 실행, 평가·필터링·라우팅 같은 작업 단위를 나타낸다. 각 노드는 입력 상태를 받아 출력을 생성하고, 그 결과를 다시 상태에 반영한다.
• Edge 및 State: 엣지는 “어떤 조건에서 어느 노드로 이동하는지”를 정의하는 전이 규칙이며, 이때 기준이 되는 것이 공유 상태(State)다. 상태 객체에는 메시지, 중간 산출물, 플래그, 에러 정보 등이 저장되고, 상태 값에 따라 다음 노드(다음 에이전트 또는 툴)가 선택된다.

4.2. 장단점

• 장점: 플로우가 코드 또는 DSL로 명시되므로, 체크포인트, 롤백, 재시도, 분기 조건 변경 등을 체계적으로 관리할 수 있다. 특히 멀티스텝 업무 자동화나 복잡한 승인 프로세스와 결합할 때, 디버깅과 관찰가능성이 크게 향상된다.
• 단점: 설계 난이도가 높고, 초기 모델링 비용이 크다. 또한 비즈니스 요구사항이 자주 바뀌는 조직에서는 그래프 정의를 지속적으로 리팩토링해야 하므로, 운영팀에 일정 수준 이상의 소프트웨어·모델링 역량이 필요하다.

5. 구조 패턴 D: 계층형(Hierarchical) 멀티에이전트

계층형 멀티에이전트 패턴은 Planner–Manager–Worker와 같이 여러 레벨의 에이전트 계층을 두는 구조다. LangGraph Supervisor 라이브러리나 CrewAI의 Hierarchical Process에서 “매니저 에이전트가 하위 에이전트들을 관리한다”는 개념으로 구체화되어 있다.

5.1. 구조 요약

• 상위 레벨(Planner/Supervisor): 전체 목표를 해석하고, 서브 목표 또는 서브태스크로 분해하는 전략적 역할을 수행한다. 이 레벨은 어떤 매니저·워커 그룹을 사용할지 선택하고, 필요 시 사람이 개입해야 할 지점도 판단한다.
• 중간 레벨(Manager): 특정 도메인 또는 서브 목표 단위의 조정자 역할을 수행하며, 하위 워커에게 업무를 배분하고 결과를 검토·통합하는 역할을 맡는다. CrewAI의 계층형 프로세스에서는 이 매니저 에이전트가 자동으로 생성되어, 팀 내 업무 분배와 검증을 담당한다.
• 하위 레벨(Worker): 실제 툴을 사용해 코드를 작성하거나, 리서치를 수행하거나, 요약을 생성하는 등 구체적인 실행 행동을 담당한다. 상위 레벨의 지시 없이 독자적으로 플랜을 짜기보다는, 주어진 태스크 범위 내에서 최선의 결과를 만들어내는 쪽에 집중한다.

5.2. 장단점

• 장점: 대형 과제를 “전략–전술–실행” 층위로 나눠 다루므로, 복잡성을 공간적으로 분산시키는 효과가 있다. 또한 계층별로 권한, 보안, 검토 강도를 다르게 설정할 수 있어, 규제가 강한 도메인에서 리스크 관리 측면의 장점이 크다.
• 단점: 계층 수가 늘어날수록 의사결정 경로가 길어지고, 지연(latency)과 오버헤드가 증가한다. 잘못 설계할 경우, 실제로는 일을 하지 않고 상호 리뷰와 회의만 반복하는 “조직 정치형 에이전트 시스템”이 될 위험도 존재한다.

6. 구조 패턴 E: 팀·크루 기반 협업(Team / Crew)

팀·크루 패턴은 여러 에이전트를 하나의 팀으로 묶고, 사람 조직과 유사한 협업 모델을 제공하는 구조다. CrewAI는 Crew·Agent·Task·Process 개념으로 이를 공식화하고 있으며, AutoGen 역시 그룹 채팅 기반 팀 구조를 제공한다.

6.1. 구조 요약

• Team/Crew: 프로젝트 또는 업무 단위로 정의되는 에이전트 집합이며, 각 에이전트는 리서처, 라이터, 리뷰어, 코더 등 명확한 역할을 가진다. 팀에는 작업 리스트(Task)와 실행 방식(Process: Sequential, Hierarchical 등)이 함께 정의된다.
• 협업 방식: Sequential 프로세스에서는 태스크가 정의된 순서대로 차례로 실행되고, 이전 태스크의 결과가 다음 태스크의 컨텍스트로 이어진다. Hierarchical 프로세스에서는 매니저 에이전트가 팀의 작업을 관리하며, 어떤 태스크를 누구에게 할당할지 동적으로 결정한다.

6.2. 장단점

• 장점: 사람 조직과 거의 동일한 메타포를 사용하므로, 비전문가도 “PM, 개발자, QA로 팀 구성”처럼 직관적으로 설계할 수 있다. 또한 역할 단위로 책임을 나눌 수 있어, 로그·품질 문제 발생 시 어느 역할에서 실패가 발생했는지 추적하기 쉽다.
• 단점: 메시지 기반 협업 구조라, 조정자가 약하거나 프로세스 정의가 느슨할 경우, 에이전트들이 불필요하게 서로 토론만 하다가 시간과 토큰을 소비하는 상황이 생기기 쉽다. 또한 팀 규모가 커질수록, 사람이 팀을 설계·튜닝하는 부담도 함께 증가한다.

7. 구조 패턴 F: 경량 멀티에이전트 / Swarm 스타일

경량 멀티에이전트 또는 Swarm 스타일은, 복잡한 그래프 엔진 없이 얇은 런타임과 메타 명령(handoff, routine) 으로 에이전트 간 전환과 협업을 구현하는 방식이다. OpenAI의 Swarm은 이를 학습·실험용 프레임워크로 제시하고 있으며, 이후 Agents SDK에서 보다 실전적인 형태로 계승하고 있다.

7.1. 구조 요약

• 에이전트 정의: 각 에이전트는 비교적 단순한 구조(프롬프트, 툴, 몇 가지 메타데이터)를 가지며, 응답 내부에 다른 에이전트로의 handoff를 나타내는 함수 호출을 포함할 수 있다. Swarm/Agents SDK 런타임은 이 함수를 해석해 다음에 실행할 에이전트를 선택한다.
• 제어 루프: 전체 플로우를 제어하는 코드는 매우 얇은 파이썬 루프로 구성되며, 별도의 그래프 DSL 없이도 멀티에이전트 계열 실험을 손쉽게 구성할 수 있다. 즉, 복잡한 오케스트레이션을 모두 프레임워크에 위임하기보다는, 개발자가 코드 차원에서 직접 orchestration 로직을 짜는 형태에 가깝다.

7.2. 장단점

• 장점: 구조가 가볍고, 멀티에이전트 개념을 빠르게 실험하거나 교육용 데모를 만들기에 적합하다. 특히 routines·handoffs 같은 핵심 개념을 코드 수준에서 투명하게 볼 수 있어, 자체 프레임워크를 설계하려는 팀에게 좋은 레퍼런스 역할을 한다.
• 단점: 공식적으로도 Swarm은 프로덕션 용도가 아니라 “교육·실험용”이라고 명시되어 있으며, 강한 거버넌스나 대규모 운영 기능은 별도로 구현해야 한다. 따라서 엔터프라이즈·대형 시스템에서는 Swarm 패턴을 아이디어 레벨로만 차용하고, 실제로는 더 무거운 오케스트레이션 레이어와 결합하는 경우가 많다.

8. 솔루션별 구조 조합

이제 위에서 정리한 구조 패턴을 기준으로, 대표 솔루션들이 어떤 조합을 채택하고 있는지 정리한다. 여기서는 “이 솔루션이 지원하는 구조”에만 초점을 두고, 사용법·API 디테일은 의도적으로 배제한다.

8.1. AIFactory의 Assiworks (노코드 에이전틱AI 프레임워크)

Assiworks는 복잡한 코딩 없이 GUI 환경에서 '유닛(Unit)'이라는 빌딩 블록을 조립하여 에이전틱 시스템을 구축하는 노코드 플랫폼이다. 주요 구조 패턴은 다음과 같다.

• Workflow: ToolChain 유닛이 이 패턴에 해당한다. 사용자는 캔버스 위에서 입력/출력/실행 노드(Node)를 배치하고 엣지(Edge)로 연결하여 정해진 순서와 데이터 흐름에 따라 작동하는 결정론적 파이프라인을 시각적으로 설계한다.
• 단일 에이전트 루프: Agent 유닛이 이 패턴을 담당한다. 특히 Planning Mode에서는 에이전트가 사용자 목표를 분석하고 스스로 실행 계획(Plan)을 수립한 뒤, 적절한 Tool을 순차적으로 호출(Action)하고 결과를 관찰(Observation)하는 Router/Planning 루프를 수행한다.
• E (팀/크루 기반 구조): Team 유닛을 통해 구현된다. 서로 다른 전문성(예: 시장 분석, 콘텐츠 제작)을 가진 여러 Agent를 그룹핑하여 협업하게 만드는 구조로, CrewAI와 유사한 조직형 협업 모델을 노코드로 제공한다.

8.2. Claude Code / Claude Agent SDK

Claude Code와 Claude Agent SDK는 “개발자 생산성”이라는 명확한 도메인에 초점을 맞춘 에이전틱 시스템으로, Subagent 기능을 통해 허브–스포크 패턴을 자연스럽게 구현한다.

• 단일 에이전트 루프: 기본적으로 하나의 메인 코딩 에이전트가 프로젝트 컨텍스트를 유지하며, 파일 시스템·터미널·테스트 실행 등 여러 도구를 호출하는 루프를 돈다.
• 허브–스포크 Orchestrator–Worker: 커스텀 서브에이전트는 별도의 시스템 프롬프트·툴 세트·컨텍스트 윈도우를 가진 “전문 에이전트”로 정의되고, 메인 에이전트가 필요 시 이들을 Task처럼 호출하여 특정 서브태스크를 처리하게 한다.
• 얕은 계층형(Hierarchical, depth 1): 서브에이전트가 다시 서브에이전트를 생성하는 식의 중첩 계층은 허용하지 않고, 항상 메인 에이전트가 유일한 허브로 남도록 설계되어 있다. 이로 인해 구조는 단순해지지만, 디버깅과 관찰가능성이 높아지는 장점이 있다.
• Claude Code는 “단일 메인 루프 + 제한된 허브–스포크 + depth 1 계층형”이라는 구조 조합을 통해, 그래프·상태머신 DSL 없이도 실용적인 에이전틱 코딩 환경을 제공한다.

8.2. LangChain + LangGraph

LangChain/LangGraph는 특정 도메인에 특화되기보다는, 범용 에이전트·워크플로우 오케스트레이션 프레임워크를 지향한다. 특히 LangGraph는 멀티에이전트 협업·Supervisor 패턴·계층형 시스템을 코드 레벨에서 구현하는 데 초점을 맞추고 있다.

• 단일 에이전트 루프: 기본 Agent+Tool(ReAct) 구조를 그대로 제공하며, 간단한 에이전트 시스템은 이 레벨에서 완성된다.
• 허브–스포크 Orchestrator–Worker: Supervisor 튜토리얼과 Supervisor 라이브러리에서, 중앙 Supervisor가 여러 Worker 에이전트를 조정하는 패턴을 공식적으로 지원한다.
• 그래프·상태머신: LangGraph의 핵심은 노드/엣지/상태를 기반으로 전체 플로우를 모델링하는 것으로, 에이전트 노드·툴 노드·평가 노드를 자유롭게 조합해 복잡한 플로우를 만들 수 있다.
• 계층형 멀티에이전트: LangGraph Supervisor 라이브러리는 계층형 시스템에 특화되어 있으며, 단일 Supervisor가 모든 사용자 상호작용을 처리하면서, 여러 레벨의 Worker를 조정하는 구조를 손쉽게 구현하도록 돕는다.
• LangGraph는 “단일 루프 → 허브–스포크 → 그래프·상태머신 → 계층형”까지 전체 스펙트럼을 포괄하며, 강한 통제·체크포인트·관찰가능성이 요구되는 엔터프라이즈급 에이전틱 시스템에 적합한 구조 조합을 제공한다.

8.3. OpenAI Swarm 및 Agents SDK

OpenAI Swarm은 멀티에이전트 오케스트레이션 개념을 교육·실험용으로 보여주는 경량 프레임워크이고, 이후 발표된 Agents SDK는 이러한 패턴을 보다 실전적인 형태로 발전시킨 것이다.

• Swarm: 단일 에이전트 루프에 handoff/routine 기반 허브–스포크를 얇게 얹은 구조로, 에이전트가 응답 내에서 다른 에이전트로의 handoff를 선언하면 런타임이 다음 에이전트를 선택해 실행한다. Swarm 자체는 생산 환경용이 아니라, 멀티에이전트 협업의 핵심 개념을 탐구하는 실험용·교육용으로 명시된다.
• Agents SDK: Swarm에서 검증된 handoff·routine 개념을 유지하면서, 보다 강력한 상태 관리, 관찰, 도구 연결을 제공해 실제 제품 수준의 에이전틱 워크플로우를 구현하도록 설계된 것으로 소개된다.
• Swarm/Agents SDK 계열은 “경량 멀티에이전트 / Swarm 스타일 + handoff 중심 허브–스포크” 조합으로, 그래프 DSL은 없되 코드 레벨에서 플로우를 유연하게 제어하는 방향에 초점을 둔다.

8.4. CrewAI

CrewAI는 이름 그대로 “크루(팀)”를 중심 개념으로 삼는 멀티에이전트 프레임워크다. Sequential·Hierarchical 프로세스를 제공하며, 매니저 에이전트를 자동으로 생성해 팀 내 업무를 조정하게 하는 구조로 설계되어 있다.

• 단일 에이전트 루프: 각 Agent는 프롬프트·툴·개인 설정을 가진 기본 LLM 에이전트로, 자신에게 할당된 태스크를 개별 루프로 처리한다.
• 팀·크루 기반 협업: Crew(에이전트 집합)와 Task 목록, 그리고 실행 Process(Sequential, Hierarchical 등)를 정의하여 팀 단위 협업 구조를 만든다. Sequential 모드에서는 태스크가 정의된 순서대로 실행되고, 각 태스크의 결과가 다음 태스크의 컨텍스트로 전달된다.
• 계층형 멀티에이전트: Hierarchical 모드에서는 매니저 에이전트가 자동으로 생성되어, 어떤 태스크를 어떤 에이전트에게 줄지, 결과를 어떻게 검증할지 결정하는 상위 조정자 역할을 수행한다.
• CrewAI는 “단일 에이전트 루프 + 팀·크루 패턴 + 계층형 매니저”라는 구조 조합을 통해, 사람 팀 구조에 가장 근접한 멀티에이전트 경험을 제공하는 솔루션이라고 볼 수 있다.

8.5. AutoGen

AutoGen은 에이전트 간 그룹 채팅과 선택적 컨트롤러 에이전트를 통해 협업을 구현하는 프레임워크로, “에이전트들이 서로 메시지를 주고받으며 문제를 푼다”는 메타포에 집중한다.

• 단일 에이전트 루프: 각 에이전트 자체는 LLM+툴 구조의 단일 루프를 가진다.
• 팀·크루 기반 협업: 여러 에이전트가 공용 대화 컨텍스트를 공유하며 그룹 채팅 방식으로 상호작용하고, 각 에이전트는 자신이 처리할 수 있는 메시지에 반응한다.
• 선택적 Orchestrator–Worker: 컨트롤러 에이전트를 두면 중앙에서 메시지 흐름을 조정하는 허브–스포크 구조가 되고, 컨트롤러 없이 구성하면 보다 P2P에 가까운 다자 협업 구조가 된다.
• AutoGen은 “단일 루프 + 그룹 채팅형 팀 구조 + 필요 시 Orchestrator”라는 유연한 구조 조합을 제공하며, 대화 중심 협업 시나리오에 특히 잘 맞는다.

8.6. n8n·Make.com 등 워크플로우 엔진 + AI 에이전트

n8n·Make.com 같은 워크플로우 엔진은 본래 자동화·BPM을 위한 도구였으나, 최근에는 AI 에이전트를 노드로 포함시켜 에이전틱 워크플로우를 시각적으로 설계하는 방향으로 확장되고 있다.

• 그래프·상태머신: 전체 플로우는 GUI 기반 그래프/상태머신으로 정의되며, 조건 분기·루프·에러 핸들링이 시각적 노드/엣지로 표현된다.
• 간접 Orchestrator–Worker: 워크플로우 엔진 자체가 Orchestrator 역할을 수행하고, 개별 AI 에이전트 노드는 Worker처럼 동작한다. 즉, 에이전트는 워크플로우 내의 하나의 처리 노드일 뿐이고, 상위 구조는 전통적인 BPM 엔진이 책임지는 형태다.
• 이 계열 솔루션은 “그래프·상태머신 + AI 에이전트를 노드로 삽입”하는 구조 조합을 취하며, 기존 RPA/BPM 환경에 에이전틱 AI를 비교적 자연스럽게 끼워 넣을 수 있다는 점이 강점이다.
  
   

9. 정리

요약하면, 현재 에이전틱 AI 아키텍처는 ① 단일 에이전트 루프, ② 허브–스포크, ③ 그래프·상태머신, ④ 계층형·팀/크루·Swarm 구조라는 스펙트럼 위에서 다양한 조합 형태로 구현되고 있다. AssiWorks는 “순차적 도구 체인(ToolChain) + 단일 에이전트 루프(Agent) + 팀/크루(Team)”의 조합을 노코드 환경에서 모듈(Unit) 조립 방식으로 제공하여, 비개발자도 복잡한 프로세스 자동화와 자율적 에이전트 협업 시스템을 직관적으로 구축할 수 있는 솔루션 이다. Claude Code는 이 중 “단일 메인 루프 + 제한된 허브–스포크” 조합을 중심으로 코딩 도메인에 최적화되어 있으며, LangGraph는 “그래프·상태머신 + Supervisor–Worker + 계층형” 구조를 통해 오케스트레이션과 제어 능력을 극대화한다. Swarm/Agents SDK는 “경량 handoff 기반 허브–스포크” 패턴을 전면에 내세워 실험·경량 워크플로우에 적합한 형태를 제공하고, CrewAI와 AutoGen은 “팀/크루 메타포 + 간단한 오케스트레이터” 조합으로 사람 조직에 가까운 협업 모델을 구현한다.

이와 같은 구조적 관점을 전제로 하면, 새로운 에이전트 프레임워크를 검토할 때 해당 솔루션이 단일 루프를 확장한 형태인지, 허브–스포크 중심인지, 그래프·상태머신을 노출하는지, 또는 팀/크루 메타포에 기반하는지 등을 신속히 분류할 수 있다. 나아가 각 조직은 자사의 도메인 특성, 기존 업무 프로세스, 거버넌스 요구 수준, 운영 난이도 등을 종합적으로 고려해, 위 스펙트럼 상에서 어떤 구조 조합을 채택할지 전략적으로 결정할 수 있다.