Multi-Agent Patterns 아키텍처 완벽 가이드

AI 에이전트 시스템에서 여러 에이전트가 협력하는 방법을 알아봅니다. Supervisor, Peer-to-Peer, Hierarchical 패턴의 차이점과 토큰 경제학까지 실무에서 바로 적용할 수 있는 멀티 에이전트 아키텍처를 다룹니다.

---

목차

1. 왜_멀티_에이전트인가_컨텍스트_격리의_핵심
2. Supervisor_Orchestrator_패턴_중앙_제어
3. Peer_to_Peer_Swarm_패턴_직접_통신
4. Hierarchical_패턴_전략_계획_실행
5. 토큰_경제학_15배_소비의_진실
6. 프레임워크_분석

---

1. 왜 멀티 에이전트인가 컨텍스트 격리의 핵심

김개발 씨는 요즘 AI 에이전트 개발에 푹 빠져 있습니다. 하나의 거대한 프롬프트로 모든 것을 처리하려다 보니 점점 복잡해지고, 에이전트가 엉뚱한 대답을 하기 시작했습니다.

"왜 이렇게 산만해지지?" 고민하던 중, 선배가 다가와 말했습니다. "멀티 에이전트 패턴을 써봐.

역할을 나누면 훨씬 깔끔해져."

멀티 에이전트 시스템은 하나의 거대한 AI 대신 여러 개의 전문화된 에이전트가 협력하는 구조입니다. 마치 대기업에서 각 부서가 전문 분야를 담당하는 것과 같습니다.

핵심은 컨텍스트 격리인데, 각 에이전트가 자신의 역할에만 집중하도록 정보를 분리하는 것입니다. 이를 통해 복잡한 작업도 명확하고 예측 가능하게 처리할 수 있습니다.

다음 코드를 살펴봅시다.

// 단일 에이전트의 문제점 - 컨텍스트 오염
const singleAgentPrompt = `
  당신은 코드 리뷰어이면서 테스터이고 문서 작성자입니다.
  코드를 분석하고, 테스트하고, 문서도 작성하세요.
`; // 역할이 뒤섞여 혼란 발생

// 멀티 에이전트 - 컨텍스트 격리
const reviewerAgent = { role: "코드 리뷰만 담당" };
const testerAgent = { role: "테스트만 담당" };
const writerAgent = { role: "문서 작성만 담당" };

// 각 에이전트는 자신의 역할에만 집중
async function processWithIsolation(code: string) {
  const review = await reviewerAgent.analyze(code);
  const tests = await testerAgent.generate(code);
  const docs = await writerAgent.write(code);
  return { review, tests, docs };
}

김개발 씨는 AI 에이전트를 만들면서 한 가지 이상한 현상을 발견했습니다. 처음에는 똑똑하게 대답하던 에이전트가 기능을 추가할수록 점점 이상해지는 것이었습니다.

코드 리뷰를 요청했는데 갑자기 테스트 케이스 이야기를 하고, 문서 작성을 시키면 엉뚱하게 버그를 찾겠다고 나섭니다. 선배 박시니어 씨가 코드를 보더니 고개를 저었습니다.

"이거 전형적인 컨텍스트 오염 문제야. 프롬프트에 너무 많은 역할을 넣어서 에이전트가 혼란스러워하는 거지." 그렇다면 컨텍스트 오염이란 무엇일까요?

쉽게 비유하자면, 한 사람에게 동시에 요리사, 의사, 변호사 역할을 맡기는 것과 같습니다. 아무리 똑똑한 사람이라도 세 가지 전문직을 동시에 수행하라고 하면 혼란스러울 수밖에 없습니다.

AI 에이전트도 마찬가지입니다. 하나의 컨텍스트 윈도우에 너무 많은 역할과 정보를 담으면 성능이 급격히 저하됩니다.

이 문제를 해결하기 위해 등장한 것이 멀티 에이전트 패턴입니다. 멀티 에이전트 시스템의 핵심 원리는 컨텍스트 격리입니다.

각 에이전트에게 명확하게 한 가지 역할만 부여하고, 필요한 정보만 전달하는 것입니다. 마치 회사에서 마케팅팀은 마케팅만, 개발팀은 개발만 담당하는 것처럼 말입니다.

위의 코드를 살펴보면 그 차이가 명확합니다. 단일 에이전트 방식에서는 하나의 프롬프트에 "코드 리뷰어이면서 테스터이고 문서 작성자"라는 복합 역할을 부여합니다.

반면 멀티 에이전트 방식에서는 reviewerAgent, testerAgent, writerAgent로 역할을 완전히 분리합니다. 실제 현업에서 멀티 에이전트가 빛을 발하는 순간은 복잡한 워크플로우를 처리할 때입니다.

예를 들어 코드 배포 파이프라인을 생각해 봅시다. 코드 분석, 보안 검사, 테스트 실행, 문서 업데이트 등 여러 단계가 있는데, 각 단계를 전문 에이전트가 담당하면 훨씬 안정적으로 처리할 수 있습니다.

하지만 주의할 점도 있습니다. 멀티 에이전트 시스템은 단순히 에이전트를 여러 개 만든다고 끝이 아닙니다.

에이전트 간의 통신 방식과 조율 메커니즘이 핵심입니다. 이것이 바로 다음에 살펴볼 아키텍처 패턴들의 핵심 주제입니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 선배의 조언을 듣고 에이전트를 역할별로 분리했더니, 각 에이전트가 자기 일에만 집중하면서 결과물의 품질이 눈에 띄게 좋아졌습니다.

"아, 혼자 다 하려고 하지 말고 팀으로 움직여야 하는구나!"

실전 팁

💡 - 에이전트 하나에 역할은 하나만 부여하세요. 명확한 역할 정의가 품질을 결정합니다.

• 컨텍스트 윈도우의 한계를 이해하고, 꼭 필요한 정보만 전달하세요.
• 에이전트 분리 전에 먼저 워크플로우를 명확히 설계하세요.

---

2. Supervisor Orchestrator 패턴 중앙 제어

김개발 씨가 멀티 에이전트 시스템을 구축하려는데 문득 의문이 들었습니다. "에이전트들이 여럿인데, 누가 전체를 관리하지?" 마치 오케스트라에 지휘자가 필요한 것처럼, 여러 에이전트를 조율할 무언가가 필요했습니다.

이때 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다.

Supervisor 패턴은 중앙의 오케스트레이터가 모든 에이전트를 관리하는 구조입니다. 마치 프로젝트 매니저가 팀원들에게 작업을 분배하고 결과를 취합하는 것과 같습니다.

모든 통신이 중앙을 거치므로 흐름을 파악하기 쉽고, 전체 상태를 한눈에 관리할 수 있습니다. 가장 직관적이고 구현하기 쉬운 패턴입니다.

다음 코드를 살펴봅시다.

// Supervisor/Orchestrator 패턴 구현
class Supervisor {
  private agents: Map<string, Agent> = new Map();

  // 에이전트 등록
  register(name: string, agent: Agent) {
    this.agents.set(name, agent);
  }

  // 중앙에서 작업 분배 및 조율
  async orchestrate(task: Task): Promise<Result> {
    // 1단계: 코드 분석 에이전트 호출
    const analysis = await this.agents.get("analyzer")!.run(task);

    // 2단계: 분석 결과로 리뷰 에이전트 호출
    const review = await this.agents.get("reviewer")!.run(analysis);

    // 3단계: 최종 결과 취합
    return this.aggregate([analysis, review]);
  }
}

박시니어 씨가 화이트보드에 그린 그림은 별 모양이었습니다. 중앙에 큰 원이 있고, 주변에 작은 원들이 연결되어 있습니다.

"이게 바로 Supervisor 패턴이야. 중앙의 오케스트레이터가 모든 것을 관리하는 거지." 이 패턴을 이해하기 위해 콜센터를 떠올려 봅시다.

고객 전화가 오면 먼저 안내 시스템이 받아서 적절한 상담원에게 연결해 줍니다. 기술 문의는 기술팀으로, 결제 문의는 결제팀으로 보내는 식입니다.

이때 안내 시스템이 바로 Supervisor 역할을 합니다. Supervisor 패턴의 가장 큰 장점은 명확한 제어 흐름입니다.

모든 작업이 중앙을 거치기 때문에 지금 무슨 일이 일어나고 있는지 한눈에 파악할 수 있습니다. 디버깅할 때도 중앙의 로그만 보면 전체 상황을 이해할 수 있어 문제 해결이 쉽습니다.

위의 코드에서 Supervisor 클래스가 핵심입니다. orchestrate 메서드를 보면 작업 순서가 명확합니다.

먼저 analyzer 에이전트가 코드를 분석하고, 그 결과를 reviewer 에이전트에게 전달합니다. 마지막으로 Supervisor가 모든 결과를 취합합니다.

실제 현업에서 이 패턴이 자주 사용되는 곳은 CI/CD 파이프라인입니다. Jenkins나 GitHub Actions 같은 도구를 생각해 보세요.

중앙의 파이프라인 엔진이 빌드, 테스트, 배포 각 단계를 순차적으로 호출하고 관리합니다. 이것이 바로 Supervisor 패턴의 전형적인 예입니다.

하지만 이 패턴에도 약점이 있습니다. 바로 단일 장애점 문제입니다.

중앙의 Supervisor가 다운되면 전체 시스템이 멈춥니다. 또한 모든 통신이 중앙을 거치므로 Supervisor에 부하가 집중될 수 있습니다.

김개발 씨가 질문했습니다. "그러면 Supervisor 없이 에이전트들끼리 직접 대화하면 안 되나요?" 박시니어 씨가 미소를 지었습니다.

"좋은 질문이야. 그게 바로 다음에 배울 Peer-to-Peer 패턴이야."

실전 팁

💡 - 작업 순서가 명확하고 선형적인 워크플로우에 적합합니다.

• Supervisor의 상태 관리 로직을 견고하게 설계하세요. 여기가 전체 시스템의 두뇌입니다.
• 복잡한 분기가 많다면 상태 머신 패턴을 함께 사용하는 것도 좋습니다.

---

3. Peer to Peer Swarm 패턴 직접 통신

김개발 씨는 Supervisor 패턴을 구현하다가 한 가지 불편함을 느꼈습니다. 에이전트 A와 B가 자주 데이터를 주고받는데, 매번 Supervisor를 거쳐야 하니 비효율적이었습니다.

"그냥 둘이 직접 대화하면 안 될까?" 이 고민의 답이 바로 Peer-to-Peer 패턴입니다.

Peer-to-Peer 패턴은 에이전트들이 중앙 조율자 없이 서로 직접 통신하는 구조입니다. 마치 슬랙 채널에서 팀원들이 자유롭게 대화하는 것과 같습니다.

각 에이전트가 자율적으로 판단하고 필요한 동료 에이전트에게 직접 요청을 보냅니다. Swarm 패턴이라고도 불리며, 유연하고 확장성이 뛰어납니다.

다음 코드를 살펴봅시다.

// Peer-to-Peer/Swarm 패턴 구현
interface Agent {
  name: string;
  capabilities: string[];
  handleMessage(msg: Message): Promise<Response>;
}

class SwarmNetwork {
  private agents: Agent[] = [];

  // 에이전트가 다른 에이전트에게 직접 요청
  async handoff(from: Agent, capability: string, data: any) {
    // 필요한 능력을 가진 에이전트 찾기
    const target = this.agents.find(a =>
      a.capabilities.includes(capability)
    );

    if (target) {
      // 직접 전달 - 중앙 거치지 않음
      return target.handleMessage({ from: from.name, data });
    }
    throw new Error(`No agent with capability: ${capability}`);
  }
}

박시니어 씨는 또 다른 그림을 그렸습니다. 이번에는 모든 원들이 서로 연결된 그물망 형태였습니다.

"이건 Peer-to-Peer 패턴이야. 에이전트들이 필요할 때 서로 직접 대화하는 거지." 이 패턴을 이해하려면 개미 군집을 떠올려 보세요.

개미에게는 사령관이 없습니다. 각 개미가 페로몬이라는 화학 신호를 통해 동료들과 직접 소통하며, 전체적으로는 놀라울 정도로 조직적인 행동을 보여줍니다.

이것이 바로 Swarm 지능의 원리입니다. Peer-to-Peer 패턴의 가장 큰 장점은 유연성입니다.

새로운 에이전트를 추가하거나 제거해도 전체 시스템에 미치는 영향이 적습니다. 중앙 조율자가 없으므로 단일 장애점 문제도 사라집니다.

위 코드에서 핵심은 handoff 메서드입니다. 에이전트가 특정 능력이 필요할 때, 그 능력을 가진 다른 에이전트를 찾아 직접 메시지를 보냅니다.

Supervisor를 거치지 않고 점대점으로 통신하는 것입니다. OpenAI의 Swarm 프레임워크가 바로 이 패턴을 구현한 좋은 예입니다.

Swarm에서는 에이전트가 작업 중 다른 에이전트가 필요하면 "핸드오프"를 통해 직접 제어권을 넘깁니다. 마치 릴레이 경주에서 바통을 넘기는 것처럼요.

하지만 이 패턴에도 단점이 있습니다. 전체 시스템에서 지금 무슨 일이 일어나고 있는지 파악하기 어렵습니다.

에이전트들이 자율적으로 움직이다 보니 예상치 못한 행동이 나올 수도 있습니다. 디버깅이 까다롭고, 무한 루프에 빠질 위험도 있습니다.

김개발 씨가 고개를 갸웃거렸습니다. "그러면 Supervisor의 명확함과 Peer-to-Peer의 유연함을 둘 다 가질 수는 없나요?" 박시니어 씨의 눈이 반짝였습니다.

"바로 그 고민의 답이 Hierarchical 패턴이야."

실전 팁

💡 - 에이전트 간 통신 프로토콜을 명확히 정의하세요. 혼란을 방지합니다.

• 무한 루프 방지를 위해 핸드오프 횟수 제한을 두는 것이 좋습니다.
• 분산 추적 시스템을 도입하면 전체 흐름을 파악하는 데 도움이 됩니다.

---

4. Hierarchical 패턴 전략 계획 실행

"회사 조직도를 생각해 봐." 박시니어 씨가 말했습니다. "CEO가 전략을 세우고, 팀장이 계획을 짜고, 실무자가 실행하잖아.

에이전트 시스템도 이렇게 계층을 만들 수 있어." 김개발 씨의 눈이 커졌습니다. 복잡한 AI 시스템을 회사 조직처럼 설계한다니, 정말 그럴듯했습니다.

Hierarchical 패턴은 에이전트를 여러 계층으로 구성하는 구조입니다. 상위 계층은 전략을 수립하고, 중간 계층은 계획을 세우며, 하위 계층이 실제 작업을 수행합니다.

마치 군대의 지휘 체계처럼 명령이 위에서 아래로 흐르고, 보고는 아래에서 위로 올라갑니다. 복잡한 대규모 시스템에 적합한 패턴입니다.

다음 코드를 살펴봅시다.

// Hierarchical 패턴 - 3계층 구조
class StrategicAgent {
  // 최상위: 전략 수립
  async defineStrategy(goal: string): Promise<Strategy> {
    return { objectives: ["분석", "리팩토링", "테스트"] };
  }
}

class TacticalAgent {
  // 중간: 계획 수립
  async createPlan(strategy: Strategy): Promise<Plan> {
    return strategy.objectives.map(obj => ({
      objective: obj,
      tasks: this.breakdownTasks(obj)
    }));
  }
}

class OperationalAgent {
  // 최하위: 실제 실행
  async execute(task: Task): Promise<Result> {
    return await this.performWork(task);
  }
}

// 계층 간 조율
async function hierarchicalFlow(goal: string) {
  const strategy = await strategicAgent.defineStrategy(goal);
  const plan = await tacticalAgent.createPlan(strategy);
  const results = await Promise.all(
    plan.flatMap(p => p.tasks.map(t => operationalAgent.execute(t)))
  );
  return results;
}

박시니어 씨가 세 개의 층으로 된 피라미드를 그렸습니다. 맨 위에는 "전략", 가운데에는 "계획", 맨 아래에는 "실행"이라고 적었습니다.

"이게 Hierarchical 패턴의 핵심이야." 쉽게 비유하자면, 집을 짓는 과정을 생각해 봅시다. 건축주가 "3층짜리 현대식 주택을 짓고 싶어요"라고 말하면, 이것이 전략 수준입니다.

건축가가 이를 받아서 상세 설계도를 그리고 공정 계획을 세우는 것이 계획 수준입니다. 실제로 벽돌을 쌓고 배관을 설치하는 것이 실행 수준입니다.

이 패턴의 강점은 복잡성 관리입니다. 아무리 복잡한 목표도 계층을 거치면서 점점 구체적이고 실행 가능한 작업으로 분해됩니다.

상위 계층은 큰 그림에 집중하고, 하위 계층은 세부 작업에 집중할 수 있습니다. 위 코드에서 세 가지 에이전트 클래스를 주목하세요.

StrategicAgent는 목표를 받아 전략을 수립합니다. TacticalAgent는 전략을 받아 구체적인 계획으로 변환합니다.

OperationalAgent는 개별 작업을 실제로 수행합니다. 실제 현업에서 이 패턴이 빛나는 곳은 자율 코딩 에이전트입니다.

예를 들어 "이 레거시 코드를 현대화해줘"라는 요청이 들어오면, 전략 에이전트가 현대화 방향을 정하고, 계획 에이전트가 파일별 수정 계획을 세우고, 실행 에이전트가 실제 코드를 수정합니다. 주의할 점도 있습니다.

계층이 많아질수록 통신 오버헤드가 증가합니다. 상위 계층의 판단 오류가 하위 계층 전체에 영향을 미치는 오류 전파 문제도 있습니다.

따라서 각 계층의 역할을 명확히 정의하고, 적절한 피드백 루프를 설계하는 것이 중요합니다. 김개발 씨가 메모를 하며 물었습니다.

"근데 에이전트가 많아지면 비용도 많이 들지 않나요?" 박시니어 씨의 표정이 진지해졌습니다. "맞아, 그게 바로 다음에 이야기할 토큰 경제학이야."

실전 팁

💡 - 계층은 2-3개가 적당합니다. 너무 많으면 오버헤드가 커집니다.

• 각 계층 간 인터페이스를 명확히 정의하세요.
• 하위 계층에서 상위 계층으로의 피드백 메커니즘도 설계하세요.

---

5. 토큰 경제학 15배 소비의 진실

김개발 씨가 멀티 에이전트 시스템을 열심히 만들어서 배포했습니다. 그런데 한 달 후 청구서를 보고 깜짝 놀랐습니다.

API 비용이 예상보다 무려 15배나 나온 것입니다. "뭐가 잘못된 거지?" 당황한 김개발 씨에게 박시니어 씨가 다가왔습니다.

"토큰 경제학을 고려 안 했구나?"

토큰 경제학은 멀티 에이전트 시스템에서 토큰 소비를 분석하고 최적화하는 개념입니다. 에이전트가 늘어날수록 토큰 사용량은 기하급수적으로 증가할 수 있습니다.

각 에이전트마다 시스템 프롬프트, 컨텍스트, 도구 정의 등이 반복되기 때문입니다. 비용 효율적인 시스템을 위해서는 토큰 소비 패턴을 이해하고 최적화 전략을 세워야 합니다.

다음 코드를 살펴봅시다.

// 토큰 소비 분석 예시
const tokenAnalysis = {
  singleAgent: {
    systemPrompt: 500,    // 시스템 프롬프트
    context: 2000,        // 사용자 컨텍스트
    tools: 300,           // 도구 정의
    total: 2800           // 요청당 토큰
  },

  multiAgent5x: {
    // 5개 에이전트 각각에 프롬프트 필요
    systemPrompts: 500 * 5,     // 2,500
    contexts: 2000 * 5,         // 10,000 (공유시 줄일 수 있음)
    tools: 300 * 5,             // 1,500
    orchestration: 1000,        // 조율 오버헤드
    total: 15000                // 약 5배 이상
  }
};

// 토큰 최적화 전략
function optimizeTokenUsage(agents: Agent[]) {
  // 1. 컨텍스트 압축
  const compressed = compressContext(context);
  // 2. 필요한 에이전트만 호출
  const activeAgents = selectRelevantAgents(task);
  // 3. 결과 캐싱
  return getCachedOrExecute(activeAgents, compressed);
}

박시니어 씨가 화이트보드에 숫자들을 적기 시작했습니다. "단일 에이전트가 요청당 3,000토큰을 쓴다고 치자.

그런데 5개 에이전트 시스템을 만들면 얼마나 쓸 것 같아?" 김개발 씨가 계산했습니다. "음, 15,000토큰?" 박시니어 씨가 고개를 저었습니다.

"그건 최소치야. 실제로는 에이전트 간 통신, 컨텍스트 전달, 조율 오버헤드까지 더해지면 15배 이상도 나올 수 있어." 왜 이런 일이 벌어질까요?

첫 번째 이유는 시스템 프롬프트 중복입니다. 각 에이전트마다 역할을 정의하는 시스템 프롬프트가 필요합니다.

5개 에이전트면 5개의 시스템 프롬프트가 각각 전송됩니다. 두 번째 이유는 컨텍스트 전달입니다.

에이전트 A의 결과를 에이전트 B에게 전달할 때, 이 정보가 토큰으로 변환되어 전송됩니다. 계층이 깊어질수록 누적되는 컨텍스트도 커집니다.

세 번째 이유는 도구 정의 반복입니다. 각 에이전트가 사용할 도구들의 스키마가 매 호출마다 함께 전송됩니다.

그렇다면 어떻게 최적화할 수 있을까요? 컨텍스트 압축이 첫 번째 전략입니다.

에이전트에게 전체 대화 내역을 주는 대신, 핵심 정보만 요약해서 전달합니다. 이것만으로도 토큰 사용량을 절반 이하로 줄일 수 있습니다.

선택적 에이전트 호출도 중요합니다. 모든 에이전트를 매번 호출하는 대신, 작업에 필요한 에이전트만 선별해서 호출합니다.

라우터 패턴을 사용하면 효과적입니다. 결과 캐싱도 빼놓을 수 없습니다.

동일한 입력에 대한 결과를 캐싱해두면 불필요한 API 호출을 줄일 수 있습니다. 김개발 씨가 깨달음을 얻었습니다.

"아, 에이전트를 많이 만드는 것보다 꼭 필요한 에이전트만 효율적으로 운영하는 게 중요하군요." 박시니어 씨가 고개를 끄덕였습니다. "맞아.

그리고 이런 최적화를 도와주는 프레임워크들이 있어."

실전 팁

💡 - 프로덕션 전에 반드시 토큰 사용량을 프로파일링하세요.

• 작은 모델로 충분한 작업은 작은 모델을 사용하세요 (예: GPT-4 대신 GPT-3.5).
• 에이전트 호출 전 필요성을 검증하는 라우터 로직을 추가하세요.

---

6. 프레임워크 분석

"멀티 에이전트 시스템을 처음부터 다 만들 필요는 없어." 박시니어 씨가 노트북을 열며 말했습니다. "이미 좋은 프레임워크들이 많거든.

각각 장단점이 있으니까, 프로젝트에 맞는 걸 선택하는 게 중요해." 김개발 씨가 의자를 끌어당기며 화면을 주시했습니다.

멀티 에이전트 시스템을 구축할 때 활용할 수 있는 다양한 프레임워크가 있습니다. LangGraph는 그래프 기반의 복잡한 워크플로우에 강점이 있고, AutoGen은 대화형 에이전트 협업에 특화되어 있습니다.

OpenAI Swarm은 가볍고 단순한 핸드오프 패턴을, CrewAI는 역할 기반 팀 협업을 지원합니다. 프로젝트 요구사항에 맞는 프레임워크를 선택하는 것이 성공의 열쇠입니다.

다음 코드를 살펴봅시다.

// LangGraph - 상태 기반 그래프 워크플로우
const workflow = new StateGraph({ state: AgentState })
  .addNode("analyzer", analyzerAgent)
  .addNode("reviewer", reviewerAgent)
  .addEdge("analyzer", "reviewer")
  .compile();

// OpenAI Swarm - 단순한 핸드오프
const triage = Agent({ name: "Triage",
  handoffs: [salesAgent, supportAgent]
});

// CrewAI - 역할 기반 팀
const crew = Crew({
  agents: [researcher, writer, editor],
  tasks: [researchTask, writeTask, editTask],
  process: "sequential"
});

// AutoGen - 대화형 협업
const groupChat = GroupChat({
  agents: [coder, reviewer, executor],
  max_round: 10
});

박시니어 씨가 화면에 네 개의 프레임워크를 띄웠습니다. "각각 다른 철학을 가지고 있어.

하나씩 살펴보자." LangGraph는 LangChain 팀이 만든 프레임워크입니다. 핵심 개념은 상태 그래프입니다.

에이전트들이 노드가 되고, 이들 사이의 전환이 엣지가 됩니다. 복잡한 조건부 분기나 순환 워크플로우를 표현하기 좋습니다.

다만 학습 곡선이 있어서 처음에는 어렵게 느껴질 수 있습니다. OpenAI Swarm은 OpenAI가 공개한 실험적 프레임워크입니다.

"가볍고 단순하게"가 모토입니다. 에이전트 간 핸드오프라는 개념으로 제어권을 넘기는데, 코드가 직관적이어서 빠르게 프로토타입을 만들기 좋습니다.

하지만 프로덕션 수준의 기능은 부족합니다. CrewAI는 역할 기반 협업에 초점을 맞춥니다.

연구원, 작가, 편집자처럼 명확한 역할을 가진 에이전트들이 팀으로 일합니다. 마치 실제 회사 팀처럼 작업을 할당하고 협업하는 구조입니다.

비개발자도 이해하기 쉬운 추상화가 장점입니다. AutoGen은 Microsoft Research에서 만들었습니다.

대화 기반 협업이 특징입니다. 에이전트들이 그룹 채팅을 하듯 대화하면서 문제를 해결합니다.

코드 실행 결과를 다시 대화에 반영하는 등 동적인 상호작용이 가능합니다. 김개발 씨가 질문했습니다.

"어떤 걸 선택해야 할까요?" 박시니어 씨가 대답했습니다. "프로젝트 성격에 따라 달라.

복잡한 워크플로우면 LangGraph, 빠른 프로토타입이면 Swarm, 팀 협업 시뮬레이션이면 CrewAI, 대화형 문제 해결이면 AutoGen이 좋아." 실제 선택할 때는 몇 가지 기준을 고려해야 합니다. 먼저 커뮤니티와 문서화 수준입니다.

LangGraph는 LangChain 생태계의 지원을 받아 문서가 풍부합니다. 다음으로 확장성입니다.

프로덕션에서 수천 건의 요청을 처리해야 한다면 해당 프레임워크가 이를 지원하는지 확인해야 합니다. 마지막으로 팀의 기술 스택입니다.

Python 팀이면 대부분의 프레임워크를 사용할 수 있지만, TypeScript 팀이라면 선택지가 줄어듭니다. 김개발 씨가 메모를 마무리하며 말했습니다.

"이제 멀티 에이전트 패턴의 전체 그림이 보이는 것 같아요!" 박시니어 씨가 미소 지었습니다. "좋아, 이제 직접 만들어보면서 배우는 거야.

실전이 최고의 선생님이니까."

실전 팁

💡 - 처음에는 가장 단순한 프레임워크로 시작하고, 필요에 따라 복잡한 것으로 전환하세요.

• 프레임워크에 종속되지 않도록 핵심 로직은 추상화해두는 것이 좋습니다.
• 공식 예제를 먼저 실행해보고 프레임워크의 철학을 이해한 뒤 프로젝트에 적용하세요.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!