또 다른 지식의 조각에 오신 것을 환영합니다.당신이 회사를 운영하며 뛰어난 전문가팀, 즉 세계적인 수준의 여행 플래너,직원은 보딩 전문가, IT 지원 담당자를 고용했다고 상상해보세요.하지만 그들 중 누구도 서로 대화하지 않습니다.두 사람의 협력이 필요한 업무가 생길 때마다 당신이 직접 책상 사이를 오가며 정보를 전달해야 합니다.현재 대부분의 AI 에이전트가 정확히 그렇게 작동하고 있습니다.분명히 팀워크가 필요한 문제임에도 불구하고 그들은 고립된 채로 작동합니다.그래서 오늘은 에이전트들이 어떻게 서로 소통하고 업무를 인계하며 실제 팀처럼 행동할 수 있는지 이야기해보려 합니다.저는 미르코 피터스입니다. 이것은 미래의 개념이 아닙니다.멀티 에이전트 오케스트레이션은 이미 현실에서 일어나고 있습니다.그리고 그것은 AEA라는 프로토콜에 위해 구동됩니다.우리는 문제점부터 시작하여 해당 프로토콜을 하나씩 분석하고마이크로소프트가 코파일러 스튜디오와 애저 AI 내에서 이를 어떻게 사용하는지 살펴보겠습니다.커피 한 잔 들고 바로 시작해보죠.그렇다면 실제 문제는 무엇일까요?오늘날의 AI 에이전트는 마치 고립된 전문가들과 정확히 같습니다.각자는 자신만의 지식, 도구, 그리고 목표를 가지고 있습니다.날씨 에이전트는 예보를 알고 있습니다.호텔 에이전트는 객실 예약 현황을 알지만 그들은 아무것도 공유하지 않습니다.이제 사용자가 다음 주 시애틀 여행을 위해 사무실 근처 호텔을 예약해달라고 요청하는 상황을 그려보세요.단일 에이전트가 날씨 전문가, 여행 전문가, 지역 비즈니스 전문가가 되어야만 합니다.이는 모든 가능한 기능을 하나의 시스템에 밀어넣는 거대하고 비대해진 프롬프트를 의미하며그런 프롬프트는 끊임없이 오류를 일으킵니다.과거의 해결책은 커스텀 코드를 작성하는 것이 없습니다.날씨 에이전트와 호텔 에이전트 사이에 다리를 놓고호텔 에이전트와 항공권 에이전트 사이에 또 다른 다리를 놓으며캘린더 에이전트를 위해 또 추가해야 합니다.

처음에는 잘 작동하지만 새로운 에이전트를 추가할 때마다 또 다른 통합작업을 수행해야 합니다.머지않아 하나만 변경해도 모든 것이 망가지는 스파게티 같은 복잡한 점대점 연결의 악몽에 빠지게 됩니다. AI가 가져다주기로 했던 생산성 향상은 유지 보수 작업으로 인해 완전히 사라져버립니다.실제 비즈니스의 고충을 살펴보겠습니다.여러분의 조직에는 이미 업무인계가 포함된 프로세스가 있습니다.티켓이 생성되면 누군가 분류하고 누군가 해결하고 누군가 기록하며 각 단계는 업무인계입니다.과거에는 각 단계를 별도의 에이전트로 자동화한 다음 그들을 연결하는 데 몇 주씩 소유해야 했습니다.하지만 에이전트들이 별도의 커스텀 브릿지 없이 서로를 발견하고 협력할 수 있게 해주는 프로토콜이 있다면 어떨까요?그것이 바로 AEA가 하는 일입니다.쉽게 말해 AEA는 에이전트들이 서로 대화하고 업무를 주고받으며 팀으로서 일을 처리하는 표준 방식입니다. AEA란 무엇일까요? 간단한 정의입니다. AEA는 에이전트 투 에이전트 에이전트 대 에이전트 위 약자입니다.

할 수 있게 해주는 오픈 프로토콜입니다. 에이전트를 위한 HTTP라고 생각하면 됩니다. HTTP가 웹브라우저와 서버 간의 통신 언어라면 AEA는 에이전트들을 위해 같은 역할을 수행합니다.마이크로소프트 코파일러 스튜디오에서 IT팀이 만든 에이전트와 구글 클라우드에서 다른 회사가 만든 에이전트가 AEA를 지원한다면 서로 대화할 수 있습니다.이것은 결코 작은 프로젝트가 아닙니다. AEA는 구글, 마이크로소프트, 시스코, 세일즈포스, 셉 등 8개 주요 기업이 후원하며 리눅�스 재단이 호스팅합니다.버전 1.0은 안정적이고 실제 사용이 가능하며 이는 특정 기업이 프로토콜을 독점하지 않음을 의미합니다.구글이나 마이크로소프트만의 것이 아닙니다.업계 전체를 위한 것입니다.설계는 위도적으로 단순하게 이루어졌습니다. AEA는 모든 개발자가 이미 알고 있는 HTTP 및 JSONRPC와 같은 기존 웹표준을 기반으로 합니다.특별하거나 독점적인 요소는 없습니다.따라서 기업들이 기존 인프라를 교체할 필요 없이 쉽게 도입할 수 있습니다. MCP, 모델 컨텍스트 프로토콜, 라는 또 다른 프로토콜에 대해 들어보셨을지도 모릅니다.차이점은 다음과 같습니다. MCP는 에이전트와 도구를 연결하여 외부 데이터 소스 및 API와 에이전트를 연결합니다. AEA는 에이전트 간을 직접 연결하는 에이전트 대 에이전트 프로토콜입니다.이들은 경쟁관계가 아니라 상호보완적인 관계입니다. MCP는 에이전트에서 도구로 향하는 수직적 연결, AEA는 에이전트들 간의 수평적 연결로 생각하세요.또 하나의 설계 선택이 있습니다. AEA는 에이전트를 불투명하게 처리합니다.따라서 한 에이전트가 다른 에이전트와 대화할 때 상대방의 내부출원, 도구, 개인 데이터는 볼 수 없습니다.보낸 작업과 돌아오는 결과만 볼 수 있을 뿐입니다.이는 개인정보와 지적재산을 보호합니다.

날씨 에이전트는 호텔 에이전트가 어떻게 객실을 예약하는지 알 필요 없이 단지 예보만 전달하면 됩니다.이제 첫 번째 퍼즐 조각인 에이전트 카드를 살펴보겠습니다.에이전트 카드, 즉 이력서입니다.모든 AEA 호환 에이전트는 에이전트 카드라는 것을 게시합니다.이 카드는 에이전트 도메인의 표준 URL, 구체적으로는 well-known-agent-card.json, 경로에 존재하는 기계 판독 가능한 문서입니다.에이전트의 위치를 안다면 카드를 가져와 협업에 필요한 모든 것을 배울 수 있습니다.에이전트 카드를 이력서 남용함으로 생각하십시오.이는 다른 에이전트에게 자신이 누구이며 무엇을 할 수 있는지 알려줍니다.카드에는 에이전트 이름, 기능에 대한 일반 텍스트 설명, 그리고 검색을 돕는 스킬 태그가 포함되어 있습니다.또한 요청을 수신할 엔드포인트 URL, 인증 요건, 그리고 허용되는 입출력 형식을 나열합니다.구체적인 예를 들어보겠습니다.날씨 전문 에이전트가 있다고 가정해봅시다.해당 에이전트 카드에는 어떤 도시든 현재 날씨와 오일 예보를 제공할 수 있습니다.라고 적혀 있습니다.또한 도시 이름을 입력받아 기온과 기상 상태를 json 형식으로 반환하는 api 엔드포인트를 명시합니다.그게 전부입니다.내부 로직이나 비밀을 노출하지 않고 무엇을 할 수 있는지 명확하게 선언하는 것 뿐입니다.탐색 과정은 다음과 같이 작동합니다.오케스트레이터 에이전트는 알려진 에이전트 URL 목록을 가지고 있거나 사용자가 직접 구성할 수 있습니다.작업이 들어오면 오케스트레이터는 에이전트 카드를 가져와 설명을 읽고 가장 적합한 에이전트를 결정합니다.날씨 카드는 날씨를 처리함으로 날씨 작업은 그곳으로 전달됩니다.호텔 카드는 호텔을 처리함으로 호텔 작업은 그곳으로 전달됩니다.중앙 등록소가 필요 없다는 점에 주목하세요.에이전트는 전역 디렉터리에 등록할 필요가 없습니다.

그저 알려진 위치에 카드를 게시하기만 하면 해당 URL을 아는 다른 에이전트가 찾아낼 수 있습니다.이는 시스템을 분산되고 유연하게 유지하기 위한 의도적인 설계 선택입니다.오케스트레이터의 URL을 알려주기만 하면 새로운 전문가를 네트워크에 추가할 수 있으며 탐색은 자동으로 이루어집니다.이제 오케스트레이터는 누가 사용 가능한지 알게 되었습니다.그런데 이들은 실제로 어떻게 작업을 전달할까요? aea 통신이 작동하는 방식입니다.오케스트레이터는 에이전트 카드를 통해 어떤 에이전트를 사용할 수 있는지 알고 있습니다.하지만 이 에이전트들은 실제로 서로 어떻게 작업을 넘겨줄까요?답은 간단합니다.모든 통신은 오늘날 대부분의 웹서비스를 구동하는 프로토콜인 json-rpc 메시지를 사용하여 http를 통해 이루어집니다.특별하거나 복잡한 것 없이 두 에이전트 사이를 오가는 표준 웹 트래픽일 뿐입니다.중요한 점이 있습니다.모든 작업이 동일하지는 않습니다. aea는 필요한 상황에 따라 세 가지 다른 상호작용 패턴을 지원합니다.즉각적인 응답은 원격 에이전트가 바로 답변할 수 있는 빠른 조회 작업을 처리합니다.요청을 보내면 즉시 회신이 오고 작업이 완료됩니다.날씨 에이전트에게 오늘 예보를 묻는 것이 정확히 이런 방식이며 비동기식 회신으로 빠르게 끝납니다.스트리밍은 더 긴 작업을 처리합니다.전문가 에이전트가 여러 데이터베이스를 검색하거나 복잡한 분석을 실행해야 할 수도 있습니다.단일 응답을 기다리게 하는 대신 에이전트는 서버 전송 이벤트 sse를 사용하여 작업하면서 상태 업데이트를 보냅니다.진행 상황 보고를 받는 도중에 마지막으로 최종 결과가 도착합니다.택배 배송 추적도 같은 방식으로 작동합니다.각 단계가 진행될 때마다 그 과정을 확인할 수 있습니다.비동기 알림은 원격 에이전트가 몇 분 몇 시간 심지어 며칠이 걸릴 수도 있는 장기 실행 작업을 처리합니다.

직원 온보딩이 좋은 예시입니다.한 전문가는 it 계정을 프로비저닝하고 다른 전문가는 며칠에 걸쳐 복미 후생 등록을 처리합니다.클라이언트 에이전트는 요청을 제출하고 작업 아이디를 받은 뒤 자신의 작업을 계속합니다.나중에 원격 에이전트가 웹훅을 통해 결과를 보냅니다.클라이언트는 해당 작업 아이디를 풀링하여 언제든 진행 상황을 확인할 수도 있습니다.모든 상호작용은 동일한 구조를 따르며 전부 작업 단위로 구성됩니다.클라이언트가 요청을 보내면 원격 에이전트는 작업을 생성하고 작업 아이디를 반환합니다.그 아이디는 이후에 발생하는 모든 일에 대한 추적 핸들이 됩니다.작업 내부의 메시지에는 보낸 사람을 알리는 역할과 일반 텍스트, 이미지 나문서 같은 바이너리 데이터, JSON 페이로드 또는 다른 곳에 저장된 파일을 가리키는 URL 등이 포함될 수 있습니다.인증은 표준 웹관레인 OOS, API 키, 베어러 토큰을 따릅니다.익숙한 방식들이라 새로 배울 것은 없습니다.에이전트 카드는 클라이언트에 사용할 인증 방식을 알려주고,클라이언트는 다른 API 호출과 동일한 방식으로 이를 처리합니다.실제로 어떻게 작동하는지 살펴보겠습니다.오케스트레이터가 여행을 위해 날씨 데이터가 필요하다고 가정해봅시다.날씨 전문가에게 작업을 보냅니다.날씨 전문가는 요청을 접수하고 처리를 시작하며 진행 상황을 실시간으로 업데이트합니다.데이터 가져오는 중, 결과 분석 중, 완료, 그런 다음 최종 예보를 전송합니다.오케스트레이터는 날씨 에이전트의 내부 도구, API 키 또는 추론 과정을 전혀 볼 수 없습니다.오직 결과물만 볼 수 있습니다.이것이 핵심 설계 원칙으로 에이전트 간의 명확한 경계를 유지하고,내부 상태가 외부로 유출되지 않도록 하는 것입니다.하지만 에이전트 간 통신, AEA만으로는 부족합니다.이 모든 전문가를 조율할 똑똑한 관리자가 필요합니다.

여기서 오케스트레이터 전문가 패턴이 등장합니다.오케스트레이터 전문가 패턴입니다.이제 모든 것이 연결됩니다.오케스트레이터 전문가 패턴은 오늘날 프로덕션 멀티 에이전트 시스템에서 가장 흔한 아키텍처입니다. IT, 인사, 재무 등 각 분야를 담당하는 부서가 있는 회사와 같다고 생각하면 됩니다.중앙결정권자가 작업을 전문팀에 배분하고,각 팀은 자신이 가장 잘하는 일에 집중하는 방식입니다.오케스트레이터는 전체적인 큰 그림을 가지고 있습니다.사용자의 요청을 받아 무엇을 해야 할지 파악하고,각 부분을 어떤 전문가가 처리할지 결정합니다.사용자가 다음 주 시애틀 여행을 계획해줘 라고 요청하면,오케스트레이터는 직접 항공권을 예약하거나 호텔을 확인하지 않습니다.비행기 전문가, 호텔 전문가, 날씨 전문가가 있다는 것을 알고 있기 때문입니다.요청을 해당 부분들로 나누고 각각 위임합니다.각 전문가는 좁은 범위에 집중합니다.한 에이전트는 항공권 예약을, 다른 에이전트는 호텔 검색을,세 번째 에이전트는 사고 대응을 담당합니다.서로의 영역에 대해 알 필요가 없습니다.항공편 전문가는 항공사, 노선, 가격 정보를 알고 있습니다.호텔 객실 유형이나 취소 정책에 대해서는 전혀 알 필요가 없습니다.그 좁은 집중력 덕분에 각 에이전트는 단순하고 유지관리와 테스트가 쉬어집니다.중요한 부분은 바로 이것입니다.오케스트레이터는 작업을 실행하지 않습니다.작업을 라우팅하고 결과를 병합할 뿐입니다.그것이 유일한 업무입니다.오케스트레이터의 역할은 모든 것을 하려는 슈퍼 에이전트가 아니라 스마트한 배포자가 되는 것입니다.오케스트레이터가 전문가의 일을 시작하게 하면 이 패턴의 모든 이점을 잃게 됩니다.다시 모 논리식 한 엉망인 상태가 됩니다.흔한 실수를 주의하세요.일부 팀은 전문가 영역을 중복해서 만듭니다.두 에이전트가 모두 고객 지원이나 데이터 조회를 처리할 수 있다고 주장하면 라우팅 혼란이 발생합니다.

오케스트레이터는 무엇을 선택해야 할지 모르고 사용자는 일관되지 않은 결과를 얻게 됩니다.해결책은 간단합니다.각 전문가는 겹치지 않는 명확하게 제한된 영역을 소유해야 합니다.두 에이전트가 같은 일을 할 수 있다면 통합하거나 영역을 더 깔끔하게 나누세요.마이크로소프트 위 코파일럿 스튜디오는 이 패턴을 기본적으로 사용합니다.메인 코파일럿은 오케스트레이터 역할을 하고 하위 에이전트와 연결된 에이전트는 전문가 역할을 합니다.사용자가 여러 영역에 걸친 질문을 하면 메인 코파일럿은 AEA를 통해 적절한 전문가에게 위임합니다.플랫폼에 내장되어 있으므로 오케스트레이션 로직을 처음부터 코딩할 필요가 없습니다.여기서 큰 이점은 모듈성입니다.호텔 예약 제공업체를 교체해야 하나요?오케스트레이터나 다른 에이전트를 건드리지 않고 호텔 전문가만 교체하세요.새로운 기능을 추가하시나요?새 전문가를 만들고 오케스트레이터에 등록하기만 하면 됩니다.각 에이전트는 작고 관리하기 쉬우며 독립적으로 배포할 수 있는 상태로 유지됩니다.그것이 모 논리식 에이전트에서 다중 에이전트 시스템으로 전환하는 핵심 이유입니다.이제 프로토콜, 에이전트 카드, 패턴을 확인했습니다.실제 시나리오에서 어떻게 작동하는지 살펴보겠습니다.실제 작동 중인 AEA 위 사례들입니다.그렇다면 현실 세계에서 AEA는 실제로 어떤 모습일까요?간단한 예시부터 시작해보겠습니다. AI 비서에게 다음 주 시애틀 여행을 계획되죠 라고 말합니다.기존 방식이라면 단일 비서가 날씨, 항공편, 호텔, 식당 등 모든 것을 한꺼번에 알아야 합니다.프롬프트 하나에 요구하기에는 너무 많은 양입니다. AEA를 사용하면 오케스트레이터가 이를 세분화합니다.날씨 전문가에게 해당 특정 날짜의 예보를 요청하는 작업을 보냅니다.동시에 항공편 전문가에게는 화요일 오전 도착, 목요일 저녁 출발하는 항공편을 찾도록 요청하고,호텔 전문가에게는 시애틀 시내 근처에서 산박을 할 숙소를 찾도록 요청합니다.

각 전문가는 독립적으로 작업하며, 저마다의 데이터 소스, 도구, 전문 지식을 가지고 있기 때문에 다른 에이전트와 대화할 필요가 없습니다.오케스트레이터는 모든 결과를 수집하여 하나의 응답으로 병합합니다.사용자는 단일 답변을 보게 됩니다.여기 일기 예보가 있습니다.항공편 옵션을 이거리며, 사무실 근처 호텔 3곳은 여기 있습니다.보이지 않는 곳에서 3명이 개별 에이전트가 별도의 통화 코드 없이 함께 작업했습니다.이제 비즈니스 시나리오를 살펴보겠습니다.노트북이 vpn에 연결되지 않습니다.라는 티켓이 들어왔다고 가정해보죠.오케스트레이터는 이것이 네트워크 문제임을 파악합니다.오케스트레이터는 표준 절차를 알고 있는 런북 전문가에게 티켓을 전달합니다. vpn 클라이언트 상태 확인, 네트워크 자격 증명 검증, 서비스 재시작을 수행합니다.해당 전문가는 처리 단계를 반환합니다.그런 다음 오케스트레이터는 결과를 티켓 작성 전문가에게 전달하여 시스템의 해결 내역을 기록합니다.이 모든 과정은 사람의 개입 없이 몇 초 만에 이루어지며,자동화된 단계로 해결되지 않을 때만 IT팀이 개입합니다.직원 온보딩도 또 다른 예의지만, 이 과정은 몇 초가 아니라 며칠이 걸립니다.오케스트레이터는 IT 전문가를 호출하여 계정을 생성하고 하드웨어를 할당하는데,이는 몇 시간이 걸릴 수 있습니다.동시에 인사복리 후생 전문가를 호출하여 등록 양식을 처리하고,나중에 시설 전문가를 호출하여 책상과 출입증 권한을 처리합니다.각 전문가는 자신의 장기 작업을 독립적으로 실행하며,오케스트레이터는 앞서 언급한 작업 아이디를 사용하여 진행 상황을 추적합니다.따라서 IT 전문가가 작업을 마치면 오케스트레이터가 이를 파악하고,시설 전문가의 작업이 지연되면 후속 조치를 취할 수 있습니다.사용자는 하나의 매끄러운 온 보딩 흐름을 보지만,이면에서는 여러 날에 걸쳐 팀이 조율하며 작업하고 있습니다.

이것은 단지 이론이 아닙니다.코카콜라 베버리지 아프리카는 이미 다이나믹스 365와 함께코파일러 스튜디오 에이전트를 사용하여 계획 주기를 자동화하고 있습니다.기존 기획자들은 매일 최대 1시간 30분을 반복적 인 작업에 소비하곤 했습니다.멀티 에이전트 오케스트레이션을 통해 이러한 주기는 스스로 실행됩니다.오케스트레이터는 공급망 계획 프로세스의 각 부분을 담당하는 전문가들에게 작업을 위임합니다.그 결과 사람이 직접 시스템 간의 정보를 옮길 필요 없이 에이전트들이 서로 소통하게 함으로써 1인당 하루에 1시간 이상을 절약하게 되었습니다.결국 이 모든 예시에서 패턴은 동일합니다.각 에이전트는 자신의 도메인과 도구를 가진 독립적인 전문가이며,다른 에이전트에 대해 알 필요가 없습니다. AEA는 사용자 지정 코드 없이도 에이전트들이 협업할 수 있도록 간단한 통신계층을 제공합니다.브릿지나 지점 간 통합, 유지관리에 번거로움 없이 표준 프로토콜과 스마트 오케스트레이터를 사용할 수 있습니다.마이크로소프트는 이 기술의 전력을 다하고 있습니다.코파일러 스튜디오와 에이저 AI가 어떤 역할을 하는지 살펴보겠습니다.마이크로소프트의 생태계, 코파일러 스튜디오, 그리고 에이저 AI입니다.그렇다면 이 모든 것에서 마이크로소프트의 위치는 어디일까요?바로 중심에 있습니다.코파일러 스튜디오는 이제 AEA를 기본적으로 지원하며, 2026년 4월부터 정식으로 제공되고 있습니다.이는 미리 보기나 베타 버전이 아닙니다.프로덕션 준비가 완료된 상태로 자격을 갖춘 고객이라면 지금 바로 사용할 수 있습니다.중요한 점은 다음과 같습니다.외부 에이전트를 코파일러 스튜디오 오케스트레이터에 연결할 수 있다는 것입니다.제가 외부라고 말할 때, 그것은 진정한 의미의 외부를 뜻합니다.구글 클라우드, AWS 또는 AEA 프로토콜을 지원하는 다른 플랫폼에서 구축된 에이전트들을 말합니다.

오케스트레이터는 에이전트가 어디에 있는지, 어떤 프레임워크로 구축되었는지 신경 쓰지 않습니다. AEA만 지원한다면 그 어떤 에이전트도 팀에 합류할 수 있습니다.설정 방법은 간단합니다.코파일러 스튜디오에서 연결된 에이전트, 커넥티드 에이전트라는 것을 생성하면 됩니다.에이전트의 엔드포인트 URL을 붙여넣기만 하면 됩니다.코파일러 스튜디오는 해당 URL에서 앞서 언급한 에이전트 카드 JSON 파일을 자동으로 가져옵니다.그러면 에이전트의 기능, 인증 요구 사항, 입출력 형식을 읽어드립니다.그 다음 내부적으로 사용자 지정 커넥터를 구축하여 오케스트레이터가 즉시 작업을 위임할 수 있게 합니다.수동 통합 작업이나 사용자 지정 코드가 필요하지 않습니다. URL을 붙여넣기만 하면 모든 과정이 완료됩니다.에이저 측면에서는 에이저 AI 파운드리, 에이전트 서비스 또 AEA를 지원합니다.여기에는 오토젠, 랭체인, 시멘티 커널과 같은 오픈소스 오케스트레이터가 파운드리 에이전트를 호출할 수 있는 전용 AEA API 엔드포인트가 있습니다.따라서 해당 프레임워크로 구축한 에이전트가 있다면 아무것도 수정할 필요 없이 마이크로소프트 생태계에 연결할 수 있습니다.이는 양방향으로 작용합니다.마이크로소프트는 우리가 설명해온 것과 동일한 오케스트레이터 전문가 패턴을 따릅니다.코파일러 스튜디오의 메인 에이전트는 오케스트레이터 역할을 하고 하위 에이전트와 연결된 에이전트들은 전문가 역할을 합니다.각 에이전트는 자신의 영역을 처리하고 오케스트레이터는 이를 라우팅하고 병합합니다.동일한 아키텍처가 마이크로소프트 플랫폼 위에서 실행되는 것입니다.하지만 알아두어야 할 몇 가지 제한사항이 있습니다.첫째, 모든 추가적인 오케스트레이션 단계는 지연 시간을 발생시킵니다.메인 에이전트가 연결된 에이전트를 호출하고 그 에이전트가 다시 다른 전문가를 호출하면 단계마다 네트워크 시간이 추가됩니다.

실시간 대화의 경우 단계가 너무 많으면 반응이 느리게 느껴질 수 있습니다.둘째, 과도한 위임은 라우팅 혼란을 야기합니다.영역이 겹치는 전문가가 너무 많으면 오케스트레이터가 잘못된 라우팅 결정을 내리기 시작합니다.따라서 전문가의 수를 적절히 유지하고 도메인을 명확하게 분리하세요.셋째, 패브릭 데이터 에이전트에는 특정 제한사항이 있습니다.메인 에이전트가 마이크로소프트 365 코파일럿에 배포되면 작동하지 않습니다.배포 대상이 M365라면 그에 맞춰 계획을 세우세요.이러한 제약은 분명히 존재하지만 관리 가능한 수준입니다.플랫폼은 실제 운영 환경에서 사용하기에 충분히 성숙했으며마이크로소프트는 이러한 격차를 해소하기 위해 적극적으로 노력하고 있습니다.

즉 모든 요소가 어떻게 조화를 이루는지 알아보겠습니다.한 걸음 물러나서 이러한 조각들이 어떻게 연결되는지 확인해봅시다. AEA는 에이전트들이 서로 통화하는 전화 시스템입니다.에이전트 카드는 일종의 전화번호부입니다.카드를 통해 누구에게 연락할지, 각 에이전트가 무엇을 담당하는지 알 수 있습니다.오케스트레이터는 호출을 올바른 부서로 연결하는 안내원 역할을 합니다.이 구성 요소들은 단독으로 작동하지 않습니다.세 가지가 모두 필요합니다.전화번호부가 없으면 누구에게 연락해야 할지 알 수 없습니다.안내원이 없으면 누구도 트래픽을 관리할 수 없습니다.그리고 전화 시스템이 없으면 안내원이 누구도 연결할 수 없습니다.이들은 팀으로 움직일 때만 작동합니다.그 지점에서 모듈성이 중요해집니다.전문가들이 모듈화되어 있으면 기존에 작동 중인 기능을 건드리지 않고도 새로운 기능을 추가할 수 있습니다.예를 들어 여행 도우미의 렌터카 전문가를 추가하고 싶다면,전문가를 만들고 에이전트 카드를 게시한 뒤 오케스트레이터에 URL을 제공하면 됩니다.완성입니다.항공편 전문가와 호텔 전문가는 그대로 유지됩니다.오케스트레이터도 변경할 필요가 없습니다.새로운 요소를 연결하기만 하면 시스템이 알아서 적응합니다.프로토콜이 개방되어 있으므로 특정 벤더에 종속될 일이 없습니다.오케스트레이터는 코파일러 스튜디오에서 실행하고,날씨 에이전트는 구글 클라우드에,호텔 에이전트는 AWS에 둬며,내부 시스템은 에이저에 유지할 수 있습니다.이들은 모두 같은 언어로 소통합니다.그것이 바로 개방형 표준의 장점입니다.특정 벤더에 고정되지 않고 각 작업에 가장 적합한 도구를 선택할 수 있게 합니다. AEA는 모든 것을 알고 있는 하나의 초지능 에이전트를 만드는 것이 아닙니다.필요에 따라 재배치할 수 있는 유연한 전문가 집단을 구축하는 것입니다.에이전트를 교체하는 대신 재배치하는 것입니다.

새로운 에이전트를 추가합니다.오래된 에이전트는 교체합니다.시스템은 병목현상을 일으키는 대신 여러분과 함께 성장합니다.그렇다면 오늘 당장이 지식으로 무엇을 할 수 있을까요?실행 가능한 핵심 내용입니다.작게 시작하세요.조직 내에서 여러 시스템이 관여하는 반복적인 프로세스 하나를 선택하세요.예를 들어 티켓 처리, 직원 온 보딩, 경비보고 등이 있습니다.단계 간의 전달이 명확한 프로세스여야 합니다.그런 다음 하나의 오케스트레이터와 두 명의 전문가로 프로토타입을 만들어 보세요.거창한 아키텍처는 필요하지 않습니다.배울 수 있는 작동하는 예시 하나만 있으면 충분합니다.이미 이를 지원하는 도구를 사용하세요.코파일럿 스튜디오에는 AA 기능이 내장되어 있고,에이저 AI 파운드리도 마찬가지입니다.처음부터 프로토콜을 만들거나 맞춤형 통화 코드를 작성할 필요가 없습니다. URL을 붙여넣고 에이전트를 구성한 다음 위임을 시작하세요.흔히 발생하는 함정을 주의하세요.전문가 영역이 서로 겹치지 않게 하세요.두 에이전트가 같은 일을 할 수 있다면 합치거나 영역을 더 명확히 나누세요.오케스트레이터는 실행이 아닌 라우팅만 담당하게 하세요.그리고 오케스트레이션 단계에서 발생하는 지연 시간을 주의하세요.응답 시간이 늘어나 기시작한다면 위임 단계가 너무 많을 수 있습니다.가장 좋은 첫 걸음은 간단합니다.기존 워크플로에서 작업이 넘어가는 지점을 파악하세요.사람이나 시스템 사이에서 정보가 어디로 전달되나요?그곳이 바로 에이전트가 대신할 수 있는 지점입니다.모든 인계 과정은 하나의 기회입니다.지금까지 AA 시스템을 핵심만 요약해드렸습니다.세 가지 간단한 요소가 함께 작동하는 것입니다.에이전트는 고립에서 벗어나 실제 팀처럼 움직이기 시작합니다.인계 지점이 명확한 워크플로 하나를 골라 거기서부터 시작하세요.더 쉬운 설명을 원하시면 구독해주시고 도움이 되셨다면 댓글을 남겨주세요.