WEBVTT

00:00:00.000 --> 00:00:02.000
또 다른 지식의 조각에 오신 것을 환영합니다.

00:00:02.180 --> 00:00:05.460
당신이 회사를 운영하며 뛰어난 전문가팀, 즉 세계적인 수준의 여행 플래너,

00:00:05.740 --> 00:00:08.580
직원은 보딩 전문가, IT 지원 담당자를 고용했다고 상상해보세요.

00:00:08.800 --> 00:00:10.840
하지만 그들 중 누구도 서로 대화하지 않습니다.

00:00:11.020 --> 00:00:15.180
두 사람의 협력이 필요한 업무가 생길 때마다 당신이 직접 책상 사이를 오가며 정보를 전달해야 합니다.

00:00:15.360 --> 00:00:17.920
현재 대부분의 AI 에이전트가 정확히 그렇게 작동하고 있습니다.

00:00:18.180 --> 00:00:21.220
분명히 팀워크가 필요한 문제임에도 불구하고 그들은 고립된 채로 작동합니다.

00:00:21.400 --> 00:00:25.600
그래서 오늘은 에이전트들이 어떻게 서로 소통하고 업무를 인계하며 실제 팀처럼 행동할 수 있는지 이야기해보려 합니다.

00:00:25.600 --> 00:00:28.520
저는 미르코 피터스입니다. 이것은 미래의 개념이 아닙니다.

00:00:28.700 --> 00:00:31.000
멀티 에이전트 오케스트레이션은 이미 현실에서 일어나고 있습니다.

00:00:31.240 --> 00:00:33.660
그리고 그것은 AEA라는 프로토콜에 위해 구동됩니다.

00:00:33.860 --> 00:00:35.980
우리는 문제점부터 시작하여 해당 프로토콜을 하나씩 분석하고

00:00:35.980 --> 00:00:39.360
마이크로소프트가 코파일러 스튜디오와 애저 AI 내에서 이를 어떻게 사용하는지 살펴보겠습니다.

00:00:39.620 --> 00:00:41.300
커피 한 잔 들고 바로 시작해보죠.

00:00:41.480 --> 00:00:43.020
그렇다면 실제 문제는 무엇일까요?

00:00:43.220 --> 00:00:45.900
오늘날의 AI 에이전트는 마치 고립된 전문가들과 정확히 같습니다.

00:00:46.220 --> 00:00:48.640
각자는 자신만의 지식, 도구, 그리고 목표를 가지고 있습니다.

00:00:48.840 --> 00:00:50.380
날씨 에이전트는 예보를 알고 있습니다.

00:00:50.380 --> 00:00:53.640
호텔 에이전트는 객실 예약 현황을 알지만 그들은 아무것도 공유하지 않습니다.

00:00:53.780 --> 00:00:57.680
이제 사용자가 다음 주 시애틀 여행을 위해 사무실 근처 호텔을 예약해달라고 요청하는 상황을 그려보세요.

00:00:57.880 --> 00:01:02.180
단일 에이전트가 날씨 전문가, 여행 전문가, 지역 비즈니스 전문가가 되어야만 합니다.

00:01:02.360 --> 00:01:05.980
이는 모든 가능한 기능을 하나의 시스템에 밀어넣는 거대하고 비대해진 프롬프트를 의미하며

00:01:05.980 --> 00:01:07.980
그런 프롬프트는 끊임없이 오류를 일으킵니다.

00:01:08.140 --> 00:01:10.420
과거의 해결책은 커스텀 코드를 작성하는 것이 없습니다.

00:01:10.760 --> 00:01:12.700
날씨 에이전트와 호텔 에이전트 사이에 다리를 놓고

00:01:12.700 --> 00:01:15.400
호텔 에이전트와 항공권 에이전트 사이에 또 다른 다리를 놓으며

00:01:15.400 --> 00:01:17.300
캘린더 에이전트를 위해 또 추가해야 합니다.

00:01:17.440 --> 00:01:21.300
처음에는 잘 작동하지만 새로운 에이전트를 추가할 때마다 또 다른 통합작업을 수행해야 합니다.

00:01:21.480 --> 00:01:25.440
머지않아 하나만 변경해도 모든 것이 망가지는 스파게티 같은 복잡한 점대점 연결의 악몽에 빠지게 됩니다.

00:01:25.660 --> 00:01:29.280
AI가 가져다주기로 했던 생산성 향상은 유지 보수 작업으로 인해 완전히 사라져버립니다.

00:01:29.520 --> 00:01:31.160
실제 비즈니스의 고충을 살펴보겠습니다.

00:01:31.580 --> 00:01:34.100
여러분의 조직에는 이미 업무인계가 포함된 프로세스가 있습니다.

00:01:34.100 --> 00:01:39.080
티켓이 생성되면 누군가 분류하고 누군가 해결하고 누군가 기록하며 각 단계는 업무인계입니다.

00:01:39.200 --> 00:01:43.640
과거에는 각 단계를 별도의 에이전트로 자동화한 다음 그들을 연결하는 데 몇 주씩 소유해야 했습니다.

00:01:43.940 --> 00:01:48.840
하지만 에이전트들이 별도의 커스텀 브릿지 없이 서로를 발견하고 협력할 수 있게 해주는 프로토콜이 있다면 어떨까요?

00:01:49.020 --> 00:01:50.840
그것이 바로 AEA가 하는 일입니다.

00:01:51.000 --> 00:01:56.100
쉽게 말해 AEA는 에이전트들이 서로 대화하고 업무를 주고받으며 팀으로서 일을 처리하는 표준 방식입니다.

00:01:56.400 --> 00:01:58.700
AEA란 무엇일까요? 간단한 정의입니다.

00:01:58.920 --> 00:02:01.580
AEA는 에이전트 투 에이전트 에이전트 대 에이전트 위 약자입니다.

00:02:04.100 --> 00:02:07.660
할 수 있게 해주는 오픈 프로토콜입니다. 에이전트를 위한 HTTP라고 생각하면 됩니다.

00:02:07.940 --> 00:02:12.940
HTTP가 웹브라우저와 서버 간의 통신 언어라면 AEA는 에이전트들을 위해 같은 역할을 수행합니다.

00:02:13.120 --> 00:02:20.600
마이크로소프트 코파일러 스튜디오에서 IT팀이 만든 에이전트와 구글 클라우드에서 다른 회사가 만든 에이전트가 AEA를 지원한다면 서로 대화할 수 있습니다.

00:02:20.860 --> 00:02:22.940
이것은 결코 작은 프로젝트가 아닙니다.

00:02:23.180 --> 00:02:31.020
AEA는 구글, 마이크로소프트, 시스코, 세일즈포스, 셉 등 8개 주요 기업이 후원하며 리눅�스 재단이 호스팅합니다.

00:02:31.020 --> 00:02:36.780
버전 1.0은 안정적이고 실제 사용이 가능하며 이는 특정 기업이 프로토콜을 독점하지 않음을 의미합니다.

00:02:36.900 --> 00:02:39.040
구글이나 마이크로소프트만의 것이 아닙니다.

00:02:39.200 --> 00:02:40.440
업계 전체를 위한 것입니다.

00:02:40.700 --> 00:02:42.020
설계는 위도적으로 단순하게 이루어졌습니다.

00:02:42.820 --> 00:02:47.820
AEA는 모든 개발자가 이미 알고 있는 HTTP 및 JSONRPC와 같은 기존 웹표준을 기반으로 합니다.

00:02:48.000 --> 00:02:49.960
특별하거나 독점적인 요소는 없습니다.

00:02:50.320 --> 00:02:54.140
따라서 기업들이 기존 인프라를 교체할 필요 없이 쉽게 도입할 수 있습니다.

00:02:54.140 --> 00:02:58.680
MCP, 모델 컨텍스트 프로토콜, 라는 또 다른 프로토콜에 대해 들어보셨을지도 모릅니다.

00:02:58.820 --> 00:03:00.020
차이점은 다음과 같습니다.

00:03:00.360 --> 00:03:04.540
MCP는 에이전트와 도구를 연결하여 외부 데이터 소스 및 API와 에이전트를 연결합니다.

00:03:04.780 --> 00:03:08.100
AEA는 에이전트 간을 직접 연결하는 에이전트 대 에이전트 프로토콜입니다.

00:03:08.320 --> 00:03:10.800
이들은 경쟁관계가 아니라 상호보완적인 관계입니다.

00:03:11.020 --> 00:03:14.080
MCP는 에이전트에서 도구로 향하는 수직적 연결,

00:03:14.540 --> 00:03:17.940
AEA는 에이전트들 간의 수평적 연결로 생각하세요.

00:03:18.140 --> 00:03:19.640
또 하나의 설계 선택이 있습니다.

00:03:20.000 --> 00:03:22.300
AEA는 에이전트를 불투명하게 처리합니다.

00:03:22.300 --> 00:03:27.400
따라서 한 에이전트가 다른 에이전트와 대화할 때 상대방의 내부출원, 도구, 개인 데이터는 볼 수 없습니다.

00:03:27.640 --> 00:03:30.100
보낸 작업과 돌아오는 결과만 볼 수 있을 뿐입니다.

00:03:30.300 --> 00:03:32.420
이는 개인정보와 지적재산을 보호합니다.

00:03:32.680 --> 00:03:37.420
날씨 에이전트는 호텔 에이전트가 어떻게 객실을 예약하는지 알 필요 없이 단지 예보만 전달하면 됩니다.

00:03:37.700 --> 00:03:40.660
이제 첫 번째 퍼즐 조각인 에이전트 카드를 살펴보겠습니다.

00:03:41.120 --> 00:03:43.080
에이전트 카드, 즉 이력서입니다.

00:03:43.400 --> 00:03:46.840
모든 AEA 호환 에이전트는 에이전트 카드라는 것을 게시합니다.

00:03:46.840 --> 00:03:55.880
이 카드는 에이전트 도메인의 표준 URL, 구체적으로는 well-known-agent-card.json, 경로에 존재하는 기계 판독 가능한 문서입니다.

00:03:56.080 --> 00:04:00.060
에이전트의 위치를 안다면 카드를 가져와 협업에 필요한 모든 것을 배울 수 있습니다.

00:04:00.320 --> 00:04:02.800
에이전트 카드를 이력서 남용함으로 생각하십시오.

00:04:02.980 --> 00:04:06.280
이는 다른 에이전트에게 자신이 누구이며 무엇을 할 수 있는지 알려줍니다.

00:04:06.460 --> 00:04:12.940
카드에는 에이전트 이름, 기능에 대한 일반 텍스트 설명, 그리고 검색을 돕는 스킬 태그가 포함되어 있습니다.

00:04:12.940 --> 00:04:19.540
또한 요청을 수신할 엔드포인트 URL, 인증 요건, 그리고 허용되는 입출력 형식을 나열합니다.

00:04:19.700 --> 00:04:21.080
구체적인 예를 들어보겠습니다.

00:04:21.460 --> 00:04:22.940
날씨 전문 에이전트가 있다고 가정해봅시다.

00:04:23.640 --> 00:04:27.020
해당 에이전트 카드에는 어떤 도시든 현재 날씨와 오일 예보를 제공할 수 있습니다.

00:04:27.180 --> 00:04:27.840
라고 적혀 있습니다.

00:04:28.080 --> 00:04:33.660
또한 도시 이름을 입력받아 기온과 기상 상태를 json 형식으로 반환하는 api 엔드포인트를 명시합니다.

00:04:33.880 --> 00:04:34.780
그게 전부입니다.

00:04:35.040 --> 00:04:39.260
내부 로직이나 비밀을 노출하지 않고 무엇을 할 수 있는지 명확하게 선언하는 것 뿐입니다.

00:04:39.480 --> 00:04:41.220
탐색 과정은 다음과 같이 작동합니다.

00:04:41.220 --> 00:04:45.920
오케스트레이터 에이전트는 알려진 에이전트 URL 목록을 가지고 있거나 사용자가 직접 구성할 수 있습니다.

00:04:46.080 --> 00:04:51.540
작업이 들어오면 오케스트레이터는 에이전트 카드를 가져와 설명을 읽고 가장 적합한 에이전트를 결정합니다.

00:04:51.760 --> 00:04:54.700
날씨 카드는 날씨를 처리함으로 날씨 작업은 그곳으로 전달됩니다.

00:04:54.840 --> 00:04:57.760
호텔 카드는 호텔을 처리함으로 호텔 작업은 그곳으로 전달됩니다.

00:04:57.960 --> 00:04:59.980
중앙 등록소가 필요 없다는 점에 주목하세요.

00:05:00.260 --> 00:05:02.600
에이전트는 전역 디렉터리에 등록할 필요가 없습니다.

00:05:02.920 --> 00:05:07.440
그저 알려진 위치에 카드를 게시하기만 하면 해당 URL을 아는 다른 에이전트가 찾아낼 수 있습니다.

00:05:07.440 --> 00:05:11.120
이는 시스템을 분산되고 유연하게 유지하기 위한 의도적인 설계 선택입니다.

00:05:11.300 --> 00:05:15.780
오케스트레이터의 URL을 알려주기만 하면 새로운 전문가를 네트워크에 추가할 수 있으며 탐색은 자동으로 이루어집니다.

00:05:15.920 --> 00:05:18.020
이제 오케스트레이터는 누가 사용 가능한지 알게 되었습니다.

00:05:18.280 --> 00:05:20.380
그런데 이들은 실제로 어떻게 작업을 전달할까요?

00:05:20.540 --> 00:05:22.300
aea 통신이 작동하는 방식입니다.

00:05:22.600 --> 00:05:25.880
오케스트레이터는 에이전트 카드를 통해 어떤 에이전트를 사용할 수 있는지 알고 있습니다.

00:05:26.140 --> 00:05:28.980
하지만 이 에이전트들은 실제로 서로 어떻게 작업을 넘겨줄까요?

00:05:29.180 --> 00:05:30.100
답은 간단합니다.

00:05:30.100 --> 00:05:36.540
모든 통신은 오늘날 대부분의 웹서비스를 구동하는 프로토콜인 json-rpc 메시지를 사용하여 http를 통해 이루어집니다.

00:05:36.640 --> 00:05:40.400
특별하거나 복잡한 것 없이 두 에이전트 사이를 오가는 표준 웹 트래픽일 뿐입니다.

00:05:40.580 --> 00:05:41.500
중요한 점이 있습니다.

00:05:41.800 --> 00:05:43.380
모든 작업이 동일하지는 않습니다.

00:05:43.600 --> 00:05:46.780
aea는 필요한 상황에 따라 세 가지 다른 상호작용 패턴을 지원합니다.

00:05:46.980 --> 00:05:50.760
즉각적인 응답은 원격 에이전트가 바로 답변할 수 있는 빠른 조회 작업을 처리합니다.

00:05:50.980 --> 00:05:53.640
요청을 보내면 즉시 회신이 오고 작업이 완료됩니다.

00:05:53.860 --> 00:05:58.720
날씨 에이전트에게 오늘 예보를 묻는 것이 정확히 이런 방식이며 비동기식 회신으로 빠르게 끝납니다.

00:05:58.720 --> 00:06:00.820
스트리밍은 더 긴 작업을 처리합니다.

00:06:01.000 --> 00:06:05.400
전문가 에이전트가 여러 데이터베이스를 검색하거나 복잡한 분석을 실행해야 할 수도 있습니다.

00:06:05.600 --> 00:06:10.680
단일 응답을 기다리게 하는 대신 에이전트는 서버 전송 이벤트 sse를 사용하여 작업하면서 상태 업데이트를 보냅니다.

00:06:10.840 --> 00:06:13.780
진행 상황 보고를 받는 도중에 마지막으로 최종 결과가 도착합니다.

00:06:13.980 --> 00:06:16.080
택배 배송 추적도 같은 방식으로 작동합니다.

00:06:16.280 --> 00:06:18.440
각 단계가 진행될 때마다 그 과정을 확인할 수 있습니다.

00:06:18.640 --> 00:06:23.580
비동기 알림은 원격 에이전트가 몇 분 몇 시간 심지어 며칠이 걸릴 수도 있는 장기 실행 작업을 처리합니다.

00:06:23.800 --> 00:06:25.360
직원 온보딩이 좋은 예시입니다.

00:06:25.360 --> 00:06:30.420
한 전문가는 it 계정을 프로비저닝하고 다른 전문가는 며칠에 걸쳐 복미 후생 등록을 처리합니다.

00:06:30.600 --> 00:06:34.700
클라이언트 에이전트는 요청을 제출하고 작업 아이디를 받은 뒤 자신의 작업을 계속합니다.

00:06:34.900 --> 00:06:37.460
나중에 원격 에이전트가 웹훅을 통해 결과를 보냅니다.

00:06:37.640 --> 00:06:40.920
클라이언트는 해당 작업 아이디를 풀링하여 언제든 진행 상황을 확인할 수도 있습니다.

00:06:41.160 --> 00:06:44.200
모든 상호작용은 동일한 구조를 따르며 전부 작업 단위로 구성됩니다.

00:06:44.400 --> 00:06:48.460
클라이언트가 요청을 보내면 원격 에이전트는 작업을 생성하고 작업 아이디를 반환합니다.

00:06:48.660 --> 00:06:51.700
그 아이디는 이후에 발생하는 모든 일에 대한 추적 핸들이 됩니다.

00:06:51.700 --> 00:06:58.240
작업 내부의 메시지에는 보낸 사람을 알리는 역할과 일반 텍스트, 이미지 나문서 같은 바이너리 데이터,

00:06:58.620 --> 00:07:03.820
JSON 페이로드 또는 다른 곳에 저장된 파일을 가리키는 URL 등이 포함될 수 있습니다.

00:07:04.680 --> 00:07:09.180
인증은 표준 웹관레인 OOS, API 키, 베어러 토큰을 따릅니다.

00:07:09.440 --> 00:07:11.640
익숙한 방식들이라 새로 배울 것은 없습니다.

00:07:12.000 --> 00:07:14.260
에이전트 카드는 클라이언트에 사용할 인증 방식을 알려주고,

00:07:14.660 --> 00:07:17.380
클라이언트는 다른 API 호출과 동일한 방식으로 이를 처리합니다.

00:07:17.580 --> 00:07:19.240
실제로 어떻게 작동하는지 살펴보겠습니다.

00:07:19.240 --> 00:07:22.160
오케스트레이터가 여행을 위해 날씨 데이터가 필요하다고 가정해봅시다.

00:07:22.280 --> 00:07:23.980
날씨 전문가에게 작업을 보냅니다.

00:07:24.140 --> 00:07:28.440
날씨 전문가는 요청을 접수하고 처리를 시작하며 진행 상황을 실시간으로 업데이트합니다.

00:07:28.620 --> 00:07:33.700
데이터 가져오는 중, 결과 분석 중, 완료, 그런 다음 최종 예보를 전송합니다.

00:07:34.100 --> 00:07:38.820
오케스트레이터는 날씨 에이전트의 내부 도구, API 키 또는 추론 과정을 전혀 볼 수 없습니다.

00:07:39.080 --> 00:07:40.420
오직 결과물만 볼 수 있습니다.

00:07:40.740 --> 00:07:43.180
이것이 핵심 설계 원칙으로 에이전트 간의 명확한 경계를 유지하고,

00:07:43.300 --> 00:07:44.940
내부 상태가 외부로 유출되지 않도록 하는 것입니다.

00:07:44.940 --> 00:07:47.280
하지만 에이전트 간 통신, AEA만으로는 부족합니다.

00:07:47.400 --> 00:07:49.760
이 모든 전문가를 조율할 똑똑한 관리자가 필요합니다.

00:07:49.920 --> 00:07:52.200
여기서 오케스트레이터 전문가 패턴이 등장합니다.

00:07:52.440 --> 00:07:54.220
오케스트레이터 전문가 패턴입니다.

00:07:54.440 --> 00:07:55.880
이제 모든 것이 연결됩니다.

00:07:56.100 --> 00:08:00.540
오케스트레이터 전문가 패턴은 오늘날 프로덕션 멀티 에이전트 시스템에서 가장 흔한 아키텍처입니다.

00:08:00.760 --> 00:08:05.340
IT, 인사, 재무 등 각 분야를 담당하는 부서가 있는 회사와 같다고 생각하면 됩니다.

00:08:05.900 --> 00:08:07.960
중앙결정권자가 작업을 전문팀에 배분하고,

00:08:08.400 --> 00:08:11.080
각 팀은 자신이 가장 잘하는 일에 집중하는 방식입니다.

00:08:11.500 --> 00:08:13.780
오케스트레이터는 전체적인 큰 그림을 가지고 있습니다.

00:08:14.020 --> 00:08:16.260
사용자의 요청을 받아 무엇을 해야 할지 파악하고,

00:08:16.640 --> 00:08:18.820
각 부분을 어떤 전문가가 처리할지 결정합니다.

00:08:19.000 --> 00:08:21.640
사용자가 다음 주 시애틀 여행을 계획해줘 라고 요청하면,

00:08:22.020 --> 00:08:24.780
오케스트레이터는 직접 항공권을 예약하거나 호텔을 확인하지 않습니다.

00:08:24.940 --> 00:08:29.040
비행기 전문가, 호텔 전문가, 날씨 전문가가 있다는 것을 알고 있기 때문입니다.

00:08:29.220 --> 00:08:31.600
요청을 해당 부분들로 나누고 각각 위임합니다.

00:08:31.820 --> 00:08:33.680
각 전문가는 좁은 범위에 집중합니다.

00:08:33.920 --> 00:08:36.400
한 에이전트는 항공권 예약을, 다른 에이전트는 호텔 검색을,

00:08:36.660 --> 00:08:38.200
세 번째 에이전트는 사고 대응을 담당합니다.

00:08:38.200 --> 00:08:40.080
서로의 영역에 대해 알 필요가 없습니다.

00:08:40.320 --> 00:08:43.380
항공편 전문가는 항공사, 노선, 가격 정보를 알고 있습니다.

00:08:43.560 --> 00:08:46.680
호텔 객실 유형이나 취소 정책에 대해서는 전혀 알 필요가 없습니다.

00:08:46.960 --> 00:08:50.900
그 좁은 집중력 덕분에 각 에이전트는 단순하고 유지관리와 테스트가 쉬어집니다.

00:08:51.080 --> 00:08:52.500
중요한 부분은 바로 이것입니다.

00:08:52.800 --> 00:08:54.560
오케스트레이터는 작업을 실행하지 않습니다.

00:08:54.780 --> 00:08:56.740
작업을 라우팅하고 결과를 병합할 뿐입니다.

00:08:56.940 --> 00:08:58.100
그것이 유일한 업무입니다.

00:08:58.320 --> 00:09:02.320
오케스트레이터의 역할은 모든 것을 하려는 슈퍼 에이전트가 아니라 스마트한 배포자가 되는 것입니다.

00:09:02.720 --> 00:09:06.160
오케스트레이터가 전문가의 일을 시작하게 하면 이 패턴의 모든 이점을 잃게 됩니다.

00:09:06.160 --> 00:09:08.300
다시 모 논리식 한 엉망인 상태가 됩니다.

00:09:08.540 --> 00:09:09.800
흔한 실수를 주의하세요.

00:09:10.040 --> 00:09:12.420
일부 팀은 전문가 영역을 중복해서 만듭니다.

00:09:12.600 --> 00:09:17.580
두 에이전트가 모두 고객 지원이나 데이터 조회를 처리할 수 있다고 주장하면 라우팅 혼란이 발생합니다.

00:09:17.840 --> 00:09:21.740
오케스트레이터는 무엇을 선택해야 할지 모르고 사용자는 일관되지 않은 결과를 얻게 됩니다.

00:09:21.960 --> 00:09:23.140
해결책은 간단합니다.

00:09:23.380 --> 00:09:26.500
각 전문가는 겹치지 않는 명확하게 제한된 영역을 소유해야 합니다.

00:09:26.680 --> 00:09:30.140
두 에이전트가 같은 일을 할 수 있다면 통합하거나 영역을 더 깔끔하게 나누세요.

00:09:30.340 --> 00:09:33.360
마이크로소프트 위 코파일럿 스튜디오는 이 패턴을 기본적으로 사용합니다.

00:09:33.360 --> 00:09:38.180
메인 코파일럿은 오케스트레이터 역할을 하고 하위 에이전트와 연결된 에이전트는 전문가 역할을 합니다.

00:09:38.320 --> 00:09:43.980
사용자가 여러 영역에 걸친 질문을 하면 메인 코파일럿은 AEA를 통해 적절한 전문가에게 위임합니다.

00:09:44.160 --> 00:09:48.260
플랫폼에 내장되어 있으므로 오케스트레이션 로직을 처음부터 코딩할 필요가 없습니다.

00:09:48.600 --> 00:09:50.240
여기서 큰 이점은 모듈성입니다.

00:09:50.480 --> 00:09:52.500
호텔 예약 제공업체를 교체해야 하나요?

00:09:52.660 --> 00:09:56.040
오케스트레이터나 다른 에이전트를 건드리지 않고 호텔 전문가만 교체하세요.

00:09:56.280 --> 00:09:57.580
새로운 기능을 추가하시나요?

00:09:57.580 --> 00:10:00.740
새 전문가를 만들고 오케스트레이터에 등록하기만 하면 됩니다.

00:10:00.960 --> 00:10:04.500
각 에이전트는 작고 관리하기 쉬우며 독립적으로 배포할 수 있는 상태로 유지됩니다.

00:10:04.700 --> 00:10:07.960
그것이 모 논리식 에이전트에서 다중 에이전트 시스템으로 전환하는 핵심 이유입니다.

00:10:08.120 --> 00:10:10.460
이제 프로토콜, 에이전트 카드, 패턴을 확인했습니다.

00:10:10.740 --> 00:10:12.800
실제 시나리오에서 어떻게 작동하는지 살펴보겠습니다.

00:10:13.180 --> 00:10:15.120
실제 작동 중인 AEA 위 사례들입니다.

00:10:15.320 --> 00:10:17.900
그렇다면 현실 세계에서 AEA는 실제로 어떤 모습일까요?

00:10:18.080 --> 00:10:19.540
간단한 예시부터 시작해보겠습니다.

00:10:19.940 --> 00:10:23.380
AI 비서에게 다음 주 시애틀 여행을 계획되죠 라고 말합니다.

00:10:23.380 --> 00:10:29.560
기존 방식이라면 단일 비서가 날씨, 항공편, 호텔, 식당 등 모든 것을 한꺼번에 알아야 합니다.

00:10:29.720 --> 00:10:31.900
프롬프트 하나에 요구하기에는 너무 많은 양입니다.

00:10:32.100 --> 00:10:34.600
AEA를 사용하면 오케스트레이터가 이를 세분화합니다.

00:10:34.780 --> 00:10:38.220
날씨 전문가에게 해당 특정 날짜의 예보를 요청하는 작업을 보냅니다.

00:10:38.400 --> 00:10:43.220
동시에 항공편 전문가에게는 화요일 오전 도착, 목요일 저녁 출발하는 항공편을 찾도록 요청하고,

00:10:43.740 --> 00:10:47.420
호텔 전문가에게는 시애틀 시내 근처에서 산박을 할 숙소를 찾도록 요청합니다.

00:10:47.420 --> 00:10:54.880
각 전문가는 독립적으로 작업하며, 저마다의 데이터 소스, 도구, 전문 지식을 가지고 있기 때문에 다른 에이전트와 대화할 필요가 없습니다.

00:10:55.380 --> 00:10:58.700
오케스트레이터는 모든 결과를 수집하여 하나의 응답으로 병합합니다.

00:10:58.940 --> 00:11:00.700
사용자는 단일 답변을 보게 됩니다.

00:11:00.980 --> 00:11:02.100
여기 일기 예보가 있습니다.

00:11:02.400 --> 00:11:05.380
항공편 옵션을 이거리며, 사무실 근처 호텔 3곳은 여기 있습니다.

00:11:05.680 --> 00:11:09.580
보이지 않는 곳에서 3명이 개별 에이전트가 별도의 통화 코드 없이 함께 작업했습니다.

00:11:09.880 --> 00:11:11.460
이제 비즈니스 시나리오를 살펴보겠습니다.

00:11:11.840 --> 00:11:13.420
노트북이 vpn에 연결되지 않습니다.

00:11:13.580 --> 00:11:15.020
라는 티켓이 들어왔다고 가정해보죠.

00:11:15.020 --> 00:11:17.660
오케스트레이터는 이것이 네트워크 문제임을 파악합니다.

00:11:17.940 --> 00:11:21.520
오케스트레이터는 표준 절차를 알고 있는 런북 전문가에게 티켓을 전달합니다.

00:11:21.700 --> 00:11:26.280
vpn 클라이언트 상태 확인, 네트워크 자격 증명 검증, 서비스 재시작을 수행합니다.

00:11:26.460 --> 00:11:28.380
해당 전문가는 처리 단계를 반환합니다.

00:11:28.600 --> 00:11:33.360
그런 다음 오케스트레이터는 결과를 티켓 작성 전문가에게 전달하여 시스템의 해결 내역을 기록합니다.

00:11:33.560 --> 00:11:36.300
이 모든 과정은 사람의 개입 없이 몇 초 만에 이루어지며,

00:11:36.760 --> 00:11:39.760
자동화된 단계로 해결되지 않을 때만 IT팀이 개입합니다.

00:11:39.760 --> 00:11:43.980
직원 온보딩도 또 다른 예의지만, 이 과정은 몇 초가 아니라 며칠이 걸립니다.

00:11:45.020 --> 00:11:49.980
오케스트레이터는 IT 전문가를 호출하여 계정을 생성하고 하드웨어를 할당하는데,

00:11:50.420 --> 00:11:51.600
이는 몇 시간이 걸릴 수 있습니다.

00:11:51.800 --> 00:11:54.760
동시에 인사복리 후생 전문가를 호출하여 등록 양식을 처리하고,

00:11:55.180 --> 00:11:58.140
나중에 시설 전문가를 호출하여 책상과 출입증 권한을 처리합니다.

00:11:58.340 --> 00:12:00.940
각 전문가는 자신의 장기 작업을 독립적으로 실행하며,

00:12:01.340 --> 00:12:04.820
오케스트레이터는 앞서 언급한 작업 아이디를 사용하여 진행 상황을 추적합니다.

00:12:05.040 --> 00:12:07.920
따라서 IT 전문가가 작업을 마치면 오케스트레이터가 이를 파악하고,

00:12:07.920 --> 00:12:10.640
시설 전문가의 작업이 지연되면 후속 조치를 취할 수 있습니다.

00:12:10.800 --> 00:12:12.900
사용자는 하나의 매끄러운 온 보딩 흐름을 보지만,

00:12:12.900 --> 00:12:15.840
이면에서는 여러 날에 걸쳐 팀이 조율하며 작업하고 있습니다.

00:12:16.120 --> 00:12:17.540
이것은 단지 이론이 아닙니다.

00:12:17.720 --> 00:12:20.800
코카콜라 베버리지 아프리카는 이미 다이나믹스 365와 함께

00:12:20.800 --> 00:12:23.840
코파일러 스튜디오 에이전트를 사용하여 계획 주기를 자동화하고 있습니다.

00:12:24.100 --> 00:12:27.620
기존 기획자들은 매일 최대 1시간 30분을 반복적 인 작업에 소비하곤 했습니다.

00:12:27.940 --> 00:12:31.040
멀티 에이전트 오케스트레이션을 통해 이러한 주기는 스스로 실행됩니다.

00:12:31.400 --> 00:12:35.880
오케스트레이터는 공급망 계획 프로세스의 각 부분을 담당하는 전문가들에게 작업을 위임합니다.

00:12:35.880 --> 00:12:43.320
그 결과 사람이 직접 시스템 간의 정보를 옮길 필요 없이 에이전트들이 서로 소통하게 함으로써 1인당 하루에 1시간 이상을 절약하게 되었습니다.

00:12:43.520 --> 00:12:45.780
결국 이 모든 예시에서 패턴은 동일합니다.

00:12:46.000 --> 00:12:49.720
각 에이전트는 자신의 도메인과 도구를 가진 독립적인 전문가이며,

00:12:50.260 --> 00:12:52.140
다른 에이전트에 대해 알 필요가 없습니다.

00:12:52.480 --> 00:12:57.100
AEA는 사용자 지정 코드 없이도 에이전트들이 협업할 수 있도록 간단한 통신계층을 제공합니다.

00:12:57.280 --> 00:13:02.980
브릿지나 지점 간 통합, 유지관리에 번거로움 없이 표준 프로토콜과 스마트 오케스트레이터를 사용할 수 있습니다.

00:13:02.980 --> 00:13:05.320
마이크로소프트는 이 기술의 전력을 다하고 있습니다.

00:13:05.500 --> 00:13:08.160
코파일러 스튜디오와 에이저 AI가 어떤 역할을 하는지 살펴보겠습니다.

00:13:08.460 --> 00:13:11.540
마이크로소프트의 생태계, 코파일러 스튜디오, 그리고 에이저 AI입니다.

00:13:11.720 --> 00:13:13.980
그렇다면 이 모든 것에서 마이크로소프트의 위치는 어디일까요?

00:13:14.160 --> 00:13:15.000
바로 중심에 있습니다.

00:13:15.320 --> 00:13:17.780
코파일러 스튜디오는 이제 AEA를 기본적으로 지원하며,

00:13:18.080 --> 00:13:20.020
2026년 4월부터 정식으로 제공되고 있습니다.

00:13:20.260 --> 00:13:21.920
이는 미리 보기나 베타 버전이 아닙니다.

00:13:22.060 --> 00:13:25.020
프로덕션 준비가 완료된 상태로 자격을 갖춘 고객이라면 지금 바로 사용할 수 있습니다.

00:13:25.220 --> 00:13:26.300
중요한 점은 다음과 같습니다.

00:13:26.300 --> 00:13:29.540
외부 에이전트를 코파일러 스튜디오 오케스트레이터에 연결할 수 있다는 것입니다.

00:13:29.660 --> 00:13:32.400
제가 외부라고 말할 때, 그것은 진정한 의미의 외부를 뜻합니다.

00:13:32.580 --> 00:13:37.320
구글 클라우드, AWS 또는 AEA 프로토콜을 지원하는 다른 플랫폼에서 구축된 에이전트들을 말합니다.

00:13:37.500 --> 00:13:40.940
오케스트레이터는 에이전트가 어디에 있는지, 어떤 프레임워크로 구축되었는지 신경 쓰지 않습니다.

00:13:41.140 --> 00:13:43.540
AEA만 지원한다면 그 어떤 에이전트도 팀에 합류할 수 있습니다.

00:13:43.740 --> 00:13:44.900
설정 방법은 간단합니다.

00:13:45.080 --> 00:13:48.260
코파일러 스튜디오에서 연결된 에이전트, 커넥티드 에이전트라는 것을 생성하면 됩니다.

00:13:48.260 --> 00:13:50.980
에이전트의 엔드포인트 URL을 붙여넣기만 하면 됩니다.

00:13:51.180 --> 00:13:57.000
코파일러 스튜디오는 해당 URL에서 앞서 언급한 에이전트 카드 JSON 파일을 자동으로 가져옵니다.

00:13:57.200 --> 00:14:01.580
그러면 에이전트의 기능, 인증 요구 사항, 입출력 형식을 읽어드립니다.

00:14:01.880 --> 00:14:06.800
그 다음 내부적으로 사용자 지정 커넥터를 구축하여 오케스트레이터가 즉시 작업을 위임할 수 있게 합니다.

00:14:07.020 --> 00:14:09.620
수동 통합 작업이나 사용자 지정 코드가 필요하지 않습니다.

00:14:09.840 --> 00:14:12.020
URL을 붙여넣기만 하면 모든 과정이 완료됩니다.

00:14:12.220 --> 00:14:15.760
에이저 측면에서는 에이저 AI 파운드리, 에이전트 서비스 또 AEA를 지원합니다.

00:14:15.760 --> 00:14:22.840
여기에는 오토젠, 랭체인, 시멘티 커널과 같은 오픈소스 오케스트레이터가 파운드리 에이전트를 호출할 수 있는 전용 AEA API 엔드포인트가 있습니다.

00:14:23.020 --> 00:14:28.420
따라서 해당 프레임워크로 구축한 에이전트가 있다면 아무것도 수정할 필요 없이 마이크로소프트 생태계에 연결할 수 있습니다.

00:14:28.620 --> 00:14:29.940
이는 양방향으로 작용합니다.

00:14:30.240 --> 00:14:33.740
마이크로소프트는 우리가 설명해온 것과 동일한 오케스트레이터 전문가 패턴을 따릅니다.

00:14:33.940 --> 00:14:39.000
코파일러 스튜디오의 메인 에이전트는 오케스트레이터 역할을 하고 하위 에이전트와 연결된 에이전트들은 전문가 역할을 합니다.

00:14:39.000 --> 00:14:42.740
각 에이전트는 자신의 영역을 처리하고 오케스트레이터는 이를 라우팅하고 병합합니다.

00:14:42.860 --> 00:14:45.880
동일한 아키텍처가 마이크로소프트 플랫폼 위에서 실행되는 것입니다.

00:14:46.080 --> 00:14:48.440
하지만 알아두어야 할 몇 가지 제한사항이 있습니다.

00:14:48.700 --> 00:14:51.960
첫째, 모든 추가적인 오케스트레이션 단계는 지연 시간을 발생시킵니다.

00:14:52.120 --> 00:14:57.600
메인 에이전트가 연결된 에이전트를 호출하고 그 에이전트가 다시 다른 전문가를 호출하면 단계마다 네트워크 시간이 추가됩니다.

00:14:57.780 --> 00:15:01.400
실시간 대화의 경우 단계가 너무 많으면 반응이 느리게 느껴질 수 있습니다.

00:15:01.620 --> 00:15:04.360
둘째, 과도한 위임은 라우팅 혼란을 야기합니다.

00:15:04.360 --> 00:15:09.520
영역이 겹치는 전문가가 너무 많으면 오케스트레이터가 잘못된 라우팅 결정을 내리기 시작합니다.

00:15:09.700 --> 00:15:13.420
따라서 전문가의 수를 적절히 유지하고 도메인을 명확하게 분리하세요.

00:15:13.640 --> 00:15:16.820
셋째, 패브릭 데이터 에이전트에는 특정 제한사항이 있습니다.

00:15:17.100 --> 00:15:20.880
메인 에이전트가 마이크로소프트 365 코파일럿에 배포되면 작동하지 않습니다.

00:15:21.080 --> 00:15:23.720
배포 대상이 M365라면 그에 맞춰 계획을 세우세요.

00:15:23.940 --> 00:15:26.400
이러한 제약은 분명히 존재하지만 관리 가능한 수준입니다.

00:15:26.600 --> 00:15:28.700
플랫폼은 실제 운영 환경에서 사용하기에 충분히 성숙했으며

00:15:28.700 --> 00:15:31.420
마이크로소프트는 이러한 격차를 해소하기 위해 적극적으로 노력하고 있습니다.

00:15:34.360 --> 00:15:36.720
즉 모든 요소가 어떻게 조화를 이루는지 알아보겠습니다.

00:15:36.900 --> 00:15:39.400
한 걸음 물러나서 이러한 조각들이 어떻게 연결되는지 확인해봅시다.

00:15:39.580 --> 00:15:42.040
AEA는 에이전트들이 서로 통화하는 전화 시스템입니다.

00:15:42.240 --> 00:15:43.900
에이전트 카드는 일종의 전화번호부입니다.

00:15:44.100 --> 00:15:46.900
카드를 통해 누구에게 연락할지, 각 에이전트가 무엇을 담당하는지 알 수 있습니다.

00:15:47.160 --> 00:15:49.340
오케스트레이터는 호출을 올바른 부서로 연결하는 안내원 역할을 합니다.

00:15:49.540 --> 00:15:51.160
이 구성 요소들은 단독으로 작동하지 않습니다.

00:15:51.340 --> 00:15:52.400
세 가지가 모두 필요합니다.

00:15:52.600 --> 00:15:54.580
전화번호부가 없으면 누구에게 연락해야 할지 알 수 없습니다.

00:15:54.800 --> 00:15:56.980
안내원이 없으면 누구도 트래픽을 관리할 수 없습니다.

00:15:56.980 --> 00:15:59.880
그리고 전화 시스템이 없으면 안내원이 누구도 연결할 수 없습니다.

00:16:00.120 --> 00:16:01.720
이들은 팀으로 움직일 때만 작동합니다.

00:16:01.900 --> 00:16:03.540
그 지점에서 모듈성이 중요해집니다.

00:16:03.740 --> 00:16:07.620
전문가들이 모듈화되어 있으면 기존에 작동 중인 기능을 건드리지 않고도 새로운 기능을 추가할 수 있습니다.

00:16:07.820 --> 00:16:09.880
예를 들어 여행 도우미의 렌터카 전문가를 추가하고 싶다면,

00:16:10.320 --> 00:16:13.560
전문가를 만들고 에이전트 카드를 게시한 뒤 오케스트레이터에 URL을 제공하면 됩니다.

00:16:13.800 --> 00:16:14.380
완성입니다.

00:16:14.640 --> 00:16:17.180
항공편 전문가와 호텔 전문가는 그대로 유지됩니다.

00:16:17.560 --> 00:16:19.220
오케스트레이터도 변경할 필요가 없습니다.

00:16:19.580 --> 00:16:22.060
새로운 요소를 연결하기만 하면 시스템이 알아서 적응합니다.

00:16:22.060 --> 00:16:25.220
프로토콜이 개방되어 있으므로 특정 벤더에 종속될 일이 없습니다.

00:16:25.520 --> 00:16:27.520
오케스트레이터는 코파일러 스튜디오에서 실행하고,

00:16:27.860 --> 00:16:29.200
날씨 에이전트는 구글 클라우드에,

00:16:29.460 --> 00:16:31.100
호텔 에이전트는 AWS에 둬며,

00:16:31.420 --> 00:16:32.920
내부 시스템은 에이저에 유지할 수 있습니다.

00:16:33.120 --> 00:16:34.820
이들은 모두 같은 언어로 소통합니다.

00:16:35.060 --> 00:16:36.860
그것이 바로 개방형 표준의 장점입니다.

00:16:37.060 --> 00:16:40.220
특정 벤더에 고정되지 않고 각 작업에 가장 적합한 도구를 선택할 수 있게 합니다.

00:16:40.420 --> 00:16:43.520
AEA는 모든 것을 알고 있는 하나의 초지능 에이전트를 만드는 것이 아닙니다.

00:16:43.680 --> 00:16:46.780
필요에 따라 재배치할 수 있는 유연한 전문가 집단을 구축하는 것입니다.

00:16:46.780 --> 00:16:49.060
에이전트를 교체하는 대신 재배치하는 것입니다.

00:16:49.240 --> 00:16:50.520
새로운 에이전트를 추가합니다.

00:16:50.720 --> 00:16:52.000
오래된 에이전트는 교체합니다.

00:16:52.220 --> 00:16:54.500
시스템은 병목현상을 일으키는 대신 여러분과 함께 성장합니다.

00:16:54.660 --> 00:16:56.660
그렇다면 오늘 당장이 지식으로 무엇을 할 수 있을까요?

00:16:56.820 --> 00:16:58.160
실행 가능한 핵심 내용입니다.

00:16:58.360 --> 00:16:59.200
작게 시작하세요.

00:16:59.440 --> 00:17:03.140
조직 내에서 여러 시스템이 관여하는 반복적인 프로세스 하나를 선택하세요.

00:17:03.380 --> 00:17:06.600
예를 들어 티켓 처리, 직원 온 보딩, 경비보고 등이 있습니다.

00:17:06.920 --> 00:17:09.060
단계 간의 전달이 명확한 프로세스여야 합니다.

00:17:09.280 --> 00:17:12.080
그런 다음 하나의 오케스트레이터와 두 명의 전문가로 프로토타입을 만들어 보세요.

00:17:12.280 --> 00:17:13.920
거창한 아키텍처는 필요하지 않습니다.

00:17:13.920 --> 00:17:16.300
배울 수 있는 작동하는 예시 하나만 있으면 충분합니다.

00:17:16.500 --> 00:17:18.180
이미 이를 지원하는 도구를 사용하세요.

00:17:18.380 --> 00:17:20.320
코파일럿 스튜디오에는 AA 기능이 내장되어 있고,

00:17:20.620 --> 00:17:22.140
에이저 AI 파운드리도 마찬가지입니다.

00:17:22.320 --> 00:17:25.440
처음부터 프로토콜을 만들거나 맞춤형 통화 코드를 작성할 필요가 없습니다.

00:17:25.720 --> 00:17:28.660
URL을 붙여넣고 에이전트를 구성한 다음 위임을 시작하세요.

00:17:28.860 --> 00:17:30.500
흔히 발생하는 함정을 주의하세요.

00:17:30.760 --> 00:17:32.660
전문가 영역이 서로 겹치지 않게 하세요.

00:17:32.840 --> 00:17:35.980
두 에이전트가 같은 일을 할 수 있다면 합치거나 영역을 더 명확히 나누세요.

00:17:36.320 --> 00:17:38.500
오케스트레이터는 실행이 아닌 라우팅만 담당하게 하세요.

00:17:38.500 --> 00:17:41.080
그리고 오케스트레이션 단계에서 발생하는 지연 시간을 주의하세요.

00:17:41.260 --> 00:17:44.100
응답 시간이 늘어나 기시작한다면 위임 단계가 너무 많을 수 있습니다.

00:17:44.320 --> 00:17:45.860
가장 좋은 첫 걸음은 간단합니다.

00:17:46.080 --> 00:17:48.440
기존 워크플로에서 작업이 넘어가는 지점을 파악하세요.

00:17:48.660 --> 00:17:50.960
사람이나 시스템 사이에서 정보가 어디로 전달되나요?

00:17:51.160 --> 00:17:53.240
그곳이 바로 에이전트가 대신할 수 있는 지점입니다.

00:17:53.460 --> 00:17:55.080
모든 인계 과정은 하나의 기회입니다.

00:17:55.300 --> 00:17:57.700
지금까지 AA 시스템을 핵심만 요약해드렸습니다.

00:17:57.900 --> 00:17:59.880
세 가지 간단한 요소가 함께 작동하는 것입니다.

00:18:00.100 --> 00:18:02.760
에이전트는 고립에서 벗어나 실제 팀처럼 움직이기 시작합니다.

00:18:03.000 --> 00:18:05.760
인계 지점이 명확한 워크플로 하나를 골라 거기서부터 시작하세요.

00:18:05.760 --> 00:18:09.380
더 쉬운 설명을 원하시면 구독해주시고 도움이 되셨다면 댓글을 남겨주세요.