에이전트가 많다고 팀이 되는 것은 아니다
멀티에이전트라는 말을 들으면 많은 사람이 먼저 숫자를 떠올린다. 에이전트 하나보다 둘, 둘보다 다섯이 더 강할 것 같기 때문이다. 하지만 실제로는 정반대의 경우가 자주 벌어진다. 역할이 겹치고, 서로 같은 정보를 다시 묻고, 결과는 충돌하고, 누가 최종 결정을 내리는지도 모호해진다. 사람 팀에서도 회의 참가자가 늘어난다고 자동으로 성과가 좋아지지 않는 것과 비슷하다.
그래서 멀티에이전트의 핵심은 에이전트 수를 늘리는 것이 아니라 협업 구조를 설계하는 것이다. 누가 먼저 일하는지, 누가 병렬로 움직이는지, 누가 라우팅하는지, 누가 책임을 지고 최종 답을 조합하는지, 상태는 어디에 저장되는지를 정해야 한다. 이 조정의 기술을 오케스트레이션이라고 부른다.12
좋은 멀티에이전트 시스템은 마치 잘 짜인 주방과 닮았다. 요리사가 많아도 재료가 어디 있는지 모르고, 같은 도마를 두고 싸우고, 접시는 아무도 안 내면 식사는 엉망이 된다. 반대로 역할과 흐름이 분명하면 두세 명만으로도 훨씬 안정적으로 움직인다.
먼저 물어야 할 질문: 정말 여러 에이전트가 필요한가
멀티에이전트는 멋있지만 공짜가 아니다. 조정 비용, 지연 시간, 토큰 사용량, 실패 지점이 함께 늘어난다. 그래서 설계의 첫 질문은 "어떻게 여러 에이전트를 조합할까?"가 아니라 "정말 여러 에이전트가 필요한가?"여야 한다.13
보통은 다음 순서로 생각하는 편이 안전하다.
한 번의 모델 호출로 끝나는가
단일 에이전트에 도구 몇 개를 붙이면 충분한가
그래도 프롬프트가 너무 복잡해지거나, 도구가 너무 많아지거나, 보안 경계가 분리되어야 해서 역할 분담이 꼭 필요한가
예를 들어 간단한 분류, 요약, 번역은 멀티에이전트가 아니라 좋은 프롬프트 한 장이면 충분하다. 주문 조회와 정책 확인처럼 하나의 도메인 안에서 도구 몇 개를 쓰는 일도 대개 단일 에이전트가 더 낫다. 반면 한 요청 안에 조사, 분석, 작성, 검토, 시스템 반영이 함께 들어 있거나, 서로 다른 데이터 권한 경계를 지켜야 하거나, 여러 관점의 독립 판단이 필요하다면 그때 멀티에이전트가 설득력을 갖기 시작한다.13
즉, 멀티에이전트는 기본값이 아니라 복잡성이 단일 에이전트의 한계를 넘었을 때 쓰는 구조적 해법이다.
오케스트레이션은 무엇을 설계하는 일인가
오케스트레이션은 여러 에이전트를 "어떻게 부를지"만 정하는 일이 아니다. 더 정확히 말하면 다음 다섯 가지를 함께 설계하는 일이다.
작업 분해: 큰 목표를 어떤 하위 작업으로 쪼갤 것인가
실행 순서: 순차로 할지, 병렬로 할지, 동적으로 갈아탈지
상태 공유: 중간 결과와 문맥을 어디에 저장하고 어떻게 넘길 것인가
책임 배분: 누가 라우팅하고, 누가 검증하고, 누가 최종 답을 책임질 것인가
실패 처리: 한 에이전트가 틀리거나 멈췄을 때 어떻게 복구할 것인가
이 다섯 가지가 정리되면 멀티에이전트는 꽤 차분해진다. 반대로 이 다섯 가지가 흐리면, 에이전트는 여러 명인데 일하는 방식은 오히려 한 명보다 불안정해진다.12
멀티에이전트에서 가장 먼저 보는 세 가지 축
패턴 이름을 외우기 전에, 세 가지 축부터 보는 것이 이해에 도움이 된다.
첫째는 제어가 중앙집중형인가 분산형인가다. 중앙의 감독자가 모든 일을 나누고 모으면 이해와 감사 추적이 쉽다. 대신 병목이 생기기 쉽다. 반대로 에이전트끼리 직접 넘겨주면 유연하고 대화가 자연스럽지만, 흐름이 보이지 않기 쉽다.14
둘째는 작업 간 의존성이 강한가 약한가다. 앞 단계의 결과 없이는 뒤 단계가 움직일 수 없다면 순차 구조가 자연스럽다. 각자가 독립적으로 판단할 수 있다면 병렬 구조가 더 빠르다.12
셋째는 최종 목표가 하나의 결과물인가, 여러 관점의 수렴인가다. 계약서 초안처럼 한 결과물로 정리되어야 하는 문제는 파이프라인이나 감독형 구조가 어울린다. 반대로 아이디어 발산이나 다면 분석처럼 서로 다른 시각을 일부러 모으는 문제는 병렬 협업이나 그룹 대화형 구조가 더 잘 맞는다.14
이 세 축을 먼저 잡아 두면, 패턴 선택이 훨씬 덜 막막해진다.
패턴 1: 순차 오케스트레이션
순차 오케스트레이션은 가장 이해하기 쉬운 멀티에이전트 패턴이다. 한 에이전트의 출력이 다음 에이전트의 입력이 되는 파이프라인 구조다. 연구자 에이전트가 자료를 모으고, 작성 에이전트가 초안을 쓰고, 검토 에이전트가 다듬고, 형식화 에이전트가 최종 출력으로 바꾸는 식이다.12
이 패턴의 장점은 예측 가능성이다. 순서가 정해져 있으니 테스트하기 쉽고, 각 단계의 입출력 계약도 분명해진다. "초안 → 검토 → 수정"처럼 점진적으로 품질을 올리는 작업에 특히 잘 맞는다.12
하지만 순차 구조에는 뚜렷한 약점도 있다. 앞 단계가 틀리면 뒤 단계가 그 틀린 결과를 정성스럽게 다듬는 일이 벌어진다. 쉽게 말해, 잘못된 재료로 정교한 요리를 하는 셈이다. 또 모든 단계가 앞 단계를 기다려야 하므로 지연 시간이 누적된다.1
그래서 순차 패턴은 다음 조건에서 강하다.
단계 간 의존성이 분명할 때
결과를 점진적으로 정제해야 할 때
흐름을 재현 가능하게 유지해야 할 때
반대로 서로 독립적인 하위 작업이라면 굳이 줄 서서 기다릴 필요가 없다.
패턴 2: 병렬 오케스트레이션
병렬 오케스트레이션은 여러 에이전트가 동시에 움직이는 구조다. 같은 질문을 서로 다른 관점에서 분석하게 할 수도 있고, 문서 묶음을 쪼개 각 에이전트가 나눠 읽게 할 수도 있다. 흔히 fan-out/fan-in 구조라고 부르는 방식이다. 바깥으로 흩어져 일하고, 다시 모여 결과를 합친다.12
예를 들어 시장 분석 요청이 들어왔다고 해 보자. 경쟁사 분석 에이전트, 고객 반응 분석 에이전트, 가격 전략 에이전트가 동시에 일한 뒤, 마지막 합성 단계가 종합 보고서를 만드는 식이다. 또는 긴 문서를 여러 조각으로 나눠 병렬 요약한 뒤 전체 요약으로 모을 수도 있다.
병렬 구조의 매력은 속도와 다양성이다. 독립 작업이면 전체 시간이 크게 줄어든다. 또 서로 다른 관점의 결과를 모아 더 풍부한 답을 만들 수 있다.1
그 대신 병렬 구조는 마지막에 꼭 어려운 숙제를 남긴다. 결과를 어떻게 합칠 것인가다. 결과가 서로 충돌하면 다수결로 정할지, 점수 기반으로 고를지, 규칙 기반으로 병합할지, 사람 검토로 넘길지 정해야 한다. 이 합의 규칙이 없다면 병렬은 빠르기만 하고 믿기 어렵다.12
즉, 병렬 패턴의 핵심은 동시에 일시키는 데 있지 않고, 충돌하는 결과를 다루는 규칙까지 포함해 설계하는 데 있다.
패턴 3: 라우팅
라우팅은 사용자의 요청이나 중간 상태를 보고 "다음에 누가 일해야 하는가"를 고르는 패턴이다. 겉으로 보기에는 단순해 보이지만, 실제로는 많은 멀티에이전트 시스템의 입구를 담당한다.45
가장 쉬운 예는 고객 지원이다. 결제 문제는 결제 에이전트로, 배송 문의는 주문 에이전트로, 반품 문제는 반품 에이전트로 보내는 식이다. 여기서는 모든 에이전트를 동시에 부를 필요가 없다. 올바른 전문가에게 빨리 보내는 것이 중요하다.
라우팅은 두 가지 방식으로 생각할 수 있다. 하나는 규칙 기반 라우팅이다. 키워드, 분류 결과, 권한 정책처럼 비교적 명시적인 기준으로 보낸다. 다른 하나는 모델 기반 라우팅이다. 분류 모델이나 상위 에이전트가 요청의 의도를 해석해 적절한 하위 에이전트를 고른다.45
좋은 라우팅의 조건은 단순히 분류 정확도가 높다는 것만이 아니다. 왜 이 에이전트로 보냈는지 설명 가능해야 하고, 애매할 때의 대체 경로가 있어야 한다. 그렇지 않으면 시스템은 처음부터 잘못된 문으로 들어가 버린다.
패턴 4: 감독형 오케스트레이션
감독형 패턴은 중앙의 조정자가 있고, 그 아래 여러 전문 에이전트가 일하는 구조다. 감독자는 요청을 받으면 계획을 세우고, 하위 작업을 나누고, 적절한 에이전트에게 일을 맡기고, 돌아온 결과를 모아 최종 답을 만든다. 사람 조직으로 치면 팀장에 가깝다.14
이 패턴이 인기 있는 이유는 사람에게 익숙하기 때문이다. 누가 무슨 일을 했는지 추적하기 쉽고, 품질 관리 지점을 두기도 편하다. 서로 다른 도메인의 작업을 한 요청 안에서 묶어야 할 때 특히 강하다.14
예를 들어 금융 업무에서 "자동차 대출을 적금 계좌로 상환해 줘" 같은 요청은 겉보기보다 복잡하다. 대출 금액 조회, 계좌 잔액 확인, 한도 및 사기 방지 정책 검토, 실제 이체 실행이 모두 필요하다. 감독자가 각 전문 에이전트를 조정하면 흐름을 통제하면서도 역할별 최소 권한을 유지하기 쉽다.
하지만 감독형 패턴에는 늘 그림자가 따라온다. 중앙 노드가 병목이 된다는 점이다. 모든 상호작용이 감독자를 거치면 응답이 느려질 수 있고, 감독자가 너무 많은 문맥을 안고 있어야 하므로 비용도 커진다.14
그래서 감독형 패턴은 통제와 설명 가능성을 얻는 대신 속도와 단순성을 일부 포기하는 선택이라고 보는 편이 정확하다.
패턴 5: 핸드오프
핸드오프는 감독자가 모든 대화를 끝까지 쥐고 있는 구조와 다르다. 한 에이전트가 직접 다른 에이전트에게 제어권을 넘긴다. 전화 상담을 받다가 "이건 기술 지원 부서가 더 잘 도와드릴 수 있습니다" 하고 자연스럽게 연결되는 장면을 떠올리면 이해가 쉽다.15
핸드오프의 핵심은 두 가지다. 제어권 이전과 문맥 유지다. 다음 에이전트는 단순히 새로 호출되는 도구가 아니라, 이어받은 대화의 주체가 된다. 따라서 이전 대화 맥락, 지금까지의 결정, 필요한 메타데이터가 같이 넘어가야 한다.15
이 패턴은 사용자가 직접 여러 전문 에이전트와 이어서 대화해야 하는 상황에 특히 잘 맞는다. 예를 들어 초기 상담 에이전트가 문제를 파악한 뒤 기술 지원 에이전트로 넘기고, 기술 지원이 다시 환불 에이전트로 넘기는 식이다. 사용자는 같은 대화를 이어가는 느낌을 받아야 한다.
다만 핸드오프는 아주 쉽게 순환 루프에 빠질 수 있다. A가 B에게 넘기고, B가 다시 A에게 돌려보내는 식이다. 그래서 누가 누구에게 넘길 수 있는지, 몇 번까지 넘길 수 있는지, 실패 시 누가 책임지고 종료할지를 미리 정해야 한다.15
감독형 패턴이 중앙 관제탑이라면, 핸드오프는 전문가 사이의 자연스러운 릴레이에 가깝다.
패턴 6: 그룹 대화형 협업
모든 멀티에이전트가 위계적일 필요는 없다. 어떤 문제는 오히려 에이전트들이 서로 의견을 주고받으며 탐색하는 편이 더 잘 풀린다. 제품 아이디어 발상, 전략 토론, 대안 비교처럼 정답이 하나로 딱 떨어지지 않는 작업이 그렇다.14
이 구조에서는 각 에이전트가 역할을 가진 동료처럼 행동한다. 예를 들어 시장 조사 담당, UX 담당, 기술 담당, 사업성 담당이 서로의 아이디어를 보완하고 반박하면서 점차 수렴해 간다. 사람 브레인스토밍을 닮은 구조다.
이 패턴의 강점은 다양성과 창발성이다. 중앙의 단일 시각에 갇히지 않고, 서로 다른 역할이 아이디어 공간을 넓힌다. 특히 창의적 문제 해결이나 초기 탐색 단계에서 도움이 된다.1
하지만 자유로운 협업은 쉽게 산만해진다. 누가 결론을 내리는지, 언제 토론을 멈추는지, 무엇을 공통 사실로 삼는지가 없으면 멋진 회의만 길어진다. 그래서 자유 협업에도 사실상 보이지 않는 규칙이 필요하다. 말차례, 공용 메모, 종료 조건 같은 기본 질서가 있어야 한다.14
즉, 그룹 대화형 협업은 "통제가 없는 자유"가 아니라 느슨한 규칙이 있는 자율 협업이다.
패턴 7: 계층형 구조
감독형 패턴을 더 크게 확장하면 계층형 구조가 된다. 최상위 에이전트가 있고, 그 아래 매니저 에이전트들이 있고, 그 아래 전문 작업 에이전트가 있는 트리 구조다.4
이 패턴은 에이전트 수가 늘어날수록 자연스럽다. 예를 들어 전체 제품 출시 프로젝트를 총괄하는 상위 에이전트 아래에, 마케팅 팀장 에이전트와 엔지니어링 팀장 에이전트가 있고, 그 아래 작성자·디자이너·QA 같은 세부 에이전트가 붙는 식이다.
계층형 구조의 장점은 확장성이다. 에이전트 수가 많아져도 한 층씩 요약해서 올리면 된다. 그러나 단점도 명확하다. 층이 늘수록 지연이 늘고, 중간 요약에서 중요한 맥락이 잘릴 위험이 커진다. 또 모든 문제가 위로 에스컬레이션되면 오히려 병목이 심해진다.4
그래서 계층형 구조는 에이전트가 많을 때 자동으로 좋은 답이 되는 것이 아니라, 상위층은 결정과 조정, 하위층은 실행과 세부 작업이라는 경계가 분명할 때만 힘을 발휘한다.
상태 공유가 없으면 협업이 아니라 전달 실수다
멀티에이전트 시스템이 생각보다 자주 실패하는 이유는 모델이 부족해서가 아니라 상태 공유가 엉성해서다. 누가 무슨 결론을 냈는지, 어떤 파일이 최신인지, 어떤 도구 호출이 이미 실행됐는지, 사용자의 제약 조건이 무엇인지가 제대로 남지 않으면 에이전트는 같은 일을 반복하거나 서로 모순된 행동을 한다.13
상태 공유는 크게 두 종류로 나눠 생각하면 편하다.
첫째는 작업 상태다. 현재 단계, 담당 에이전트, 중간 산출물, 성공 여부, 재시도 횟수 같은 운영 정보다. 둘째는 업무 문맥이다. 사용자 목표, 근거 자료, 정책 제약, 핵심 결정, 아직 해결되지 않은 질문 같은 내용 정보다.
멀티에이전트에서는 이 둘을 구분해 관리하는 것이 좋다. 작업 상태는 기계가 읽기 쉬운 구조로, 업무 문맥은 요약과 근거 중심으로 관리하는 편이 안정적이다. 모든 대화 전체를 무작정 다음 에이전트에게 넘기는 방식은 금방 비싸지고 지저분해진다.13
결국 좋은 상태 공유란 "많이 넘기는 것"이 아니라 다음 에이전트가 제대로 일하는 데 필요한 만큼만, 그러나 빠뜨리지 않고 넘기는 것이다.
공용 메모리와 블랙보드 방식
일부 시스템은 에이전트끼리 직접 길게 대화하기보다, 공용 작업판에 읽고 쓰는 방식으로 협업한다. 흔히 블랙보드 패턴이라고 부른다. 여러 전문 에이전트가 하나의 공용 상태판에 가설과 검사 결과를 적고, 컨트롤러가 다음 전문가를 부르는 식이다.34
이 방식의 장점은 기록이 남는다는 점이다. 누가 어떤 근거로 무엇을 추가했는지 보기 쉽고, 새로운 에이전트가 들어와도 현재 상황을 빠르게 파악할 수 있다. 반면 설계가 느슨하면 작업판이 잡동사니 메모장처럼 변한다. 그래서 공용 메모리도 필드 구조, 갱신 규칙, 충돌 해결 규칙이 필요하다.
자원 경합과 충돌 해결
여러 에이전트가 동시에 움직이면 똑똑함보다 먼저 부딪히는 문제가 있다. 파일 잠금, API 호출 제한, 데이터베이스 동시 수정, 같은 티켓에 대한 중복 처리 같은 자원 경합이다.3
예를 들어 두 에이전트가 같은 고객 주문을 동시에 수정하면 마지막에 저장한 쪽이 이긴다. 그런데 이게 진짜 승리인지는 아무도 모른다. 멀티에이전트에서는 이런 문제를 모델이 알아서 해결해 주지 않는다. 시스템 설계로 막아야 한다.
그래서 실무에서는 다음 같은 장치가 자주 들어간다.
공유 자원에 대한 잠금 또는 예약
상태 버전 관리와 충돌 감지
쓰기 작업 전 최종 검증 단계
같은 작업에 대한 중복 실행 방지 키
이런 장치는 덜 화려하지만, 멀티에이전트를 시연용이 아니라 운영 가능한 시스템으로 바꿔 준다.
보안 경계와 권한 분리
멀티에이전트의 장점 중 하나는 권한을 역할별로 나눌 수 있다는 점이다. 모두가 모든 데이터와 모든 도구를 볼 필요가 없다. 결제 에이전트는 결제 도구만, 문서 검색 에이전트는 검색 도구만, 민감 정보가 있는 데이터는 특정 권한의 에이전트만 다루게 만들 수 있다.34
이 분리는 단순한 보안 장식이 아니다. 단일 에이전트가 너무 많은 도구와 데이터를 한꺼번에 쥐면 프롬프트는 비대해지고, 실수 가능성은 커지고, 최소 권한 원칙도 무너지기 쉽다. 멀티에이전트는 때때로 성능 향상보다 안전한 분업 때문에 선택되기도 한다.
다만 권한을 나눴다면 오케스트레이터나 감독자가 무심코 모든 민감 문맥을 다시 모아버리지 않도록 주의해야 한다. 분리의 이점을 마지막 합성 단계에서 스스로 깨뜨릴 수도 있기 때문이다.
관측성: 누가 무엇을 했는지 보여야 고칠 수 있다
단일 에이전트도 디버깅이 쉽지 않은데, 멀티에이전트는 더 어렵다. 그래서 운영 단계에서는 답변 품질 못지않게 흐름의 가시성이 중요하다. 어떤 에이전트가 선택되었는지, 어떤 상태를 넘겼는지, 어디서 시간이 오래 걸렸는지, 어떤 결과가 합쳐졌는지 보여야 한다.23
좋은 멀티에이전트 로그는 단순한 채팅 기록이 아니다. 최소한 다음은 남아야 한다.
실행된 에이전트와 호출 순서
입력과 출력의 요약
핸드오프나 라우팅의 이유
도구 호출 결과와 실패 원인
최종 집계 규칙과 선택 근거
그래야 "왜 틀렸지?"를 "어느 단계에서 어긋났지?"로 바꿔 볼 수 있다. 이것이 운영 가능한 오케스트레이션의 출발점이다.
어떤 패턴을 고를까: 실전 선택 기준
패턴 선택은 유행이 아니라 문제 형태에 따라 결정해야 한다. 아주 거칠게 정리하면 이렇다.
단계 의존성이 뚜렷하면 순차 패턴
독립 작업이 많고 속도가 중요하면 병렬 패턴
요청 종류가 다양하고 전문가 선택이 중요하면 라우팅
품질 관리와 설명 가능성이 중요하면 감독형 패턴
사용자가 자연스럽게 전문가를 넘나들며 대화해야 하면 핸드오프
창의적 탐색과 다면 토론이 중요하면 그룹 대화형 협업
규모가 크고 조직 구조를 닮아야 하면 계층형 구조
현실에서는 이 중 하나만 쓰는 경우보다 섞어 쓰는 경우가 많다. 예를 들어 감독형 조정자가 먼저 작업을 나눈 뒤, 조사 단계는 병렬로 돌리고, 최종 작성은 순차 검토를 붙이는 식이다. 또는 초기 분류는 라우팅으로 처리하고, 이후 전문 에이전트끼리는 핸드오프로 이어질 수 있다.12
중요한 것은 패턴을 조합하되, 각 경계가 무엇을 책임지는지 명확히 두는 것이다. 섞는 것 자체는 문제가 아니다. 왜 이 지점에서 이 패턴을 쓰는지 모르는 채 섞는 것이 문제다.
흔한 안티패턴
멀티에이전트를 처음 설계할 때 자주 빠지는 함정도 있다.
첫째, 역할만 다르고 실제로는 같은 일을 하는 에이전트를 여러 개 두는 것이다. 이름은 전략가, 분석가, 조언가인데 셋 다 비슷한 답을 하면 복잡성만 늘어난다.
둘째, 모든 걸 감독자에게 다시 몰아주는 것이다. 처음엔 통제감이 좋아 보이지만, 결국 모든 판단과 문맥이 중앙에 쌓여 병목이 된다.4
셋째, 상태 전달을 대화 전체 복사로 해결하려는 것이다. 쉬워 보여도 금방 비싸지고 불안정해진다. 다음 단계에 필요한 핵심만 구조적으로 넘겨야 한다.3
넷째, 종료 조건이 없는 자유 협업이다. 토론은 화려한데 결론이 없다. 에이전트도 토론만 잘하는 회의 체질이 될 수 있다.
다섯째, 병렬 실행의 충돌 해결 규칙이 없는 것이다. 동시에 일시켜 놓고 마지막에 "잘 알아서 합쳐라"라고 하면, 그때부터 진짜 문제가 시작된다.12
작은 시스템부터 멀티에이전트답게 만드는 법
처음부터 거대한 구조를 만들 필요는 없다. 오히려 다음 순서가 실용적이다.
먼저 단일 에이전트로 충분한지 확인한다. 그다음 정말 역할 분리가 필요한 지점 하나만 떼어 두 번째 에이전트를 만든다. 그리고 그 둘 사이의 계약을 분명히 한다. 입력 형식, 출력 형식, 실패 시 행동, 상태 전달 규칙을 정한다. 이후 병렬화나 감독형 구조, 핸드오프 같은 것은 문제의 실제 병목이 드러났을 때 단계적으로 추가한다.12
이 방식이 좋은 이유는 멀티에이전트의 본질을 숫자가 아니라 관계로 보게 해 주기 때문이다. 두 에이전트만 있어도 협업 구조를 제대로 설계할 수 있다. 반대로 열 개를 만들어도 관계가 엉성하면 시스템은 산만해진다.
이 장의 핵심
멀티에이전트 시스템의 본질은 "에이전트를 많이 붙이는 기술"이 아니다. 작업을 어떤 구조로 나누고, 어떤 규칙으로 조정하고, 어떤 상태를 공유하며, 누가 책임을 질지 설계하는 기술이다.
순차 패턴은 의존성이 강한 작업에, 병렬 패턴은 독립 작업과 다면 분석에, 라우팅은 적절한 전문가 선택에, 감독형 패턴은 중앙 통제와 품질 관리에, 핸드오프는 자연스러운 전문 전환에, 그룹 대화형 협업은 아이디어 탐색에 강하다. 계층형 구조는 이 기본 패턴들을 더 큰 규모로 확장한 형태라고 볼 수 있다.
무엇보다 기억할 점은 하나다. 멀티에이전트의 핵심은 수가 아니라 협업 구조다.
에이전트가 다섯 명이라고 해서 자동으로 팀이 되지는 않는다. 하지만 구조가 좋다면 둘만으로도 팀처럼 일할 수 있다.
참고
1Microsoft Learn의 Agent Framework 오케스트레이션 패턴
2Azure Architecture Center의 AI Agent Orchestration Patterns
3Google Cloud의 에이전트 AI 시스템 설계 패턴 선택 가이드
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.