WEBVTT 00:00:00.110 --> 00:00:12.290 mc65 fm 팟캐스트에 오신 여러분 모두 환영합니다. 오늘은 마이크로소프트 365 코파일럿 프론프트 엔지니어링과 관련하여 가장 흔히 논의되는 주제 중 하나를 다뤄보겠습니다. 00:00:12.810 --> 00:00:28.830 한 기업에서 코파일럿을 본격적으로 사용하기 시작하면서 어떻게 하면 더 나은 프론프트를 작성할 수 있을까? 라는 질문에서 코파일럿을 우리 회사에서 실제로 실행되는 애플리케이션, 데이터, 앱, 비즈니스 프로세스 및 지식에 어떻게 연결할 수 있을까? 00:00:28.830 --> 00:00:34.510 라는 질문으로 빠르게 바뀌었습니다. 바로 이 지점에서 코파일럿 확장성 테스트가 중요해집니다. 00:00:34.950 --> 00:00:43.650 오늘 게스트는 스위스에 있는 AI IT 그룹의 마이크로소프트 MVP이자 비즈니스 애플리케이션 컨설턴트인 에바스 하베스트입니다. 00:00:43.930 --> 00:00:55.690 에바스는 마이크로소프트 365, 에이저 다이나믹스 365 및 파워 플랫폼 전반에서 활동하며 특히 에이전트 및 사용자 지정 개발을 통해 마이크로소프트 365 코파일럿을 확장하는 데 중점을 두고 있습니다. 00:00:55.690 --> 00:01:09.850 오늘 우리는 마이크로소프트 365 코파일럿 확장성, 코파일럿 스튜디오, 마이크로소프트 에이저 파운드리, 이름이 정확히 기억나지 않지만 마이크로소프트 그래프, MCPS 등에 대해 살펴보겠습니다. 00:01:10.290 --> 00:01:13.610 네, MC65 팟캐스트에 오신 것을 환영합니다. 00:01:14.130 --> 00:01:15.550 안녕하세요, 여러분. 00:01:15.830 --> 00:01:17.150 초대해 주셔서 감사합니다. 00:01:18.150 --> 00:01:20.890 이렇게 좋은 기회를 갖게 되어 정말 기쁩니다. 00:01:21.430 --> 00:01:22.830 초대해 주셔서 감사합니다. 00:01:22.830 --> 00:01:24.990 네, 감사합니다. 00:01:26.150 --> 00:01:34.510 본격적인 기술적인 이야기를 하기 전에 어떻게 마이크로소프트 생태계에 합류하게 되셨는지 간략하게 말씀해 주시겠어요? 00:01:36.050 --> 00:01:37.570 네, 네, 물론이죠. 00:01:38.510 --> 00:01:42.530 사실 저는 마이크로소프트에서 경력을 시작한 건 아니었어요. 00:01:45.470 --> 00:01:50.490 애플에서 맥 플랫폼 소프트웨어 엔지니어로 일하다가 iOS 쪽으로 옮겼죠. 00:01:50.490 --> 00:01:59.580 그리고 꽤 오래 전, 아마 15년이나 20년 전 쯤일 거예요. 00:01:59.920 --> 00:02:02.040 마이크로소프트로 이직하게 됐습니다. 00:02:02.360 --> 00:02:09.580 솔직히 말해서 샤프에서 경력을 시작했고, 그 후 클라우드, 애저, M3 요구 쪽으로 옮겼습니다. 00:02:09.580 --> 00:02:15.060 음, 제가 온 프레미스 환경에서 시작했다면 이랬을 겁니다. 00:02:15.400 --> 00:02:22.780 그리고 클라우드 서비스로 옮겨갔고, 마지막으로는 파워 플랫폼, 그리고 가장 최근에는 AI 관련 기술들을 다루게 되었습니다. 00:02:23.140 --> 00:02:27.320 솔직히 말씀드리면, AI는 이제 M2고 위 큰 부분을 차지하고 있기 때문입니다. 00:02:27.500 --> 00:02:30.880 왜냐하면 이제는 자동화된 전환이 이루어졌기 때문이죠. 00:02:30.880 --> 00:02:37.130 간단히 말해서 이것이 제 여정을 요약한 것입니다. 00:02:37.370 --> 00:02:41.690 저는 소프트웨어 엔지니어링 분야에서 경력을 시작했는데, 오늘날. 00:02:43.630 --> 00:02:46.310 많은 사람들이 이 용어를 잊어버리는 것 같습니다. 00:02:47.450 --> 00:02:55.250 왜냐하면 지금은 AI 관련 기술들이 많아졌고, 이러한 활동이나 직종들이 AI 분야로 이동했기 때문입니다. 00:02:55.250 --> 00:02:59.030 그래서 20년 전과는 상당히 다릅니다. 00:03:03.120 --> 00:03:08.620 네, SharePoint와 GraphSpeak Dynamic Power Platform을 다루신다고 하셨는데, 00:03:09.340 --> 00:03:13.560 이러한 배경이 현재의 AI 개발 환경에 어떻게 도움이 되었나요? 00:03:17.700 --> 00:03:25.000 음, 기본적으로 제 프로필은 정말 다방면에 걸쳐있다고 할 수 있어요. 00:03:25.300 --> 00:03:29.160 왜냐하면 저는 경력 내내 정말 다양한 제품을 다뤄왔거든요. 00:03:30.740 --> 00:03:33.400 마이크로소프트 제품이든 아니든 말이죠. 00:03:33.600 --> 00:03:38.900 그래서 기본적으로 저는 다양한 기술과 도구에 대한 폭넓은 스킬을 보유하고 있습니다. 00:03:40.720 --> 00:03:44.320 이러한 모든 경험들이 제게 좋은 배경을 만들어주었어요. 00:03:47.720 --> 00:03:53.120 특히 지금의 AI는 여러 접근 방식과 기술이 존재하는 백지 상태와 같죠. 00:03:55.580 --> 00:03:59.780 에이전트 방식도 있고, 워크플로우 방식도 있고, 여러 가지가 있잖아요. 00:03:59.780 --> 00:04:07.980 솔직히 말해서 제 이전 직무 경험들은 지금의 AI 전환에 필요한 많은 스킬을 쌓는 데 도움이 되었어요. 00:04:08.620 --> 00:04:13.440 로우코드 개발부터 비프로세스 코드 개발까지 다양한 분야를 경험했거든요. 00:04:13.440 --> 00:04:28.490 네, 이러한 모든 기회와 활동들이 AI 분야에서 성공하는 데 필요한 스킬을 갖추는 데 큰 도움이 되었습니다. 00:04:28.490 --> 00:04:32.250 그리고 지금 당신은 AI 테스트 리더 시네요. 00:04:32.490 --> 00:04:35.470 AI 테스트 리더는 구체적으로 어떤 일을 하나요? 00:04:35.770 --> 00:04:35.970 음. 00:04:37.590 --> 00:04:39.050 정말 좋은 질문이에요. 00:04:39.370 --> 00:04:41.390 많은 분들이 저에게 물어보시거든요. 00:04:41.670 --> 00:04:42.710 제 업무는 기능. 00:04:48.410 --> 00:04:50.490 명세와 기술 스택을 연결하는 거예요. 00:04:51.230 --> 00:04:52.050 비즈니스. 00:04:52.050 --> 00:04:55.710 분석이 완료되면 제가 주도적으로 나서죠. 00:04:55.890 --> 00:04:56.290 AI. 00:05:01.860 --> 00:05:11.400 관련 사용 사례와 시나리오를 정의하고 비즈니스 분석을 모두 마친 후에 저는 이러한 요구 사항들을 기술 스택에 맞춰 연결하는 역할을 합니다. 00:05:15.410 --> 00:05:19.550 그리고 개발 준비가 완료되면 도구와 솔루션 구현을 총괄하죠. 00:05:20.110 --> 00:05:21.370 네, 흥미롭네요. 00:05:21.370 --> 00:05:40.220 사실 많은 회사들이 직원들에게 교육을 제공하는데 특히 신속 엔지니어링 분야에 집중적으로 교육을 시키는 것 같아요. 00:05:40.500 --> 00:05:43.340 그런데 왜 그것만으로는 부족하다고 생각하시나요? 00:05:46.660 --> 00:05:50.580 요즘은 신속 엔지니어링만 교육하는 시대인가요? 00:05:50.840 --> 00:05:57.300 네, 왜, 왜, 왜, 왜, 그들은 왜, 그건 단지 아시다시피 00:05:57.300 --> 00:06:03.800 회사 입장에서는 사람들에게 즉각적인 엔지니어링 기술만 가르치는 것으로는 충분하지 않기 때문이죠. 00:06:04.360 --> 00:06:05.800 아, 네, 알겠습니다. 00:06:06.140 --> 00:06:07.360 네, 네, 응. 00:06:09.740 --> 00:06:15.240 솔직히 말해서 요즘에는 제가 전에 말씀드렸듯이 다양한 도구와 기술이 많습니다. 00:06:16.520 --> 00:06:23.140 그래서 기본적으로 AI는 어느 시점에서는 무엇을 해야 할지 이해하고 어느 정도 안내해 줄 수 있습니다. 00:06:23.140 --> 00:06:34.470 하지만 제 생각에는 예를 들어 아키텍트나 소프트웨어 설계자의 역할에는 고객을 이해해야 하기 때문에 뒤에 사람이 있어야 합니다. 00:06:36.740 --> 00:06:40.800 기본적으로 AI는 때때로 고객의 맥락을 이해하지 못합니다. 00:06:41.960 --> 00:06:44.940 음, 보시다시피 전체 네트워크는 보이지만 00:06:44.940 --> 00:06:49.740 그 이면에는 즉각적인 엔지니어링에만 집중하는 것이 좋을 수도 있지만 00:06:49.740 --> 00:06:51.740 더 많은 것이 필요합니다. 00:06:51.740 --> 00:07:04.930 왜냐하면 그 이면에는 아키텍트, 소프트웨어 엔지니어, 그리고 시어포인트, 온드라이브, 세일즈포스와 같은 00:07:04.930 --> 00:07:08.170 정보 기술 분야의 전문가들이 필요하기 때문입니다. 00:07:14.600 --> 00:07:16.280 AI는 많은 것을 이해하고 안내해 줄 수 있으며 00:07:16.280 --> 00:07:18.100 훌륭한 기술 또는 기능 문서를 생성할 수 있지만 00:07:18.100 --> 00:07:21.960 그 문서가 제대로 만들어졌는지 고객의 요구에 부합하는지 등을 검토하고 검증하는 사람이 필요합니다. 00:07:33.880 --> 00:07:37.140 그래야만 즉각적인 엔지니어링에만 집중할 수 있는 것이죠. 00:07:37.140 --> 00:07:41.880 제 생각에는, 네, 시간적 여유가 없거나 특정 기술 습득에 투자할 여력이 없다면 00:07:41.880 --> 00:07:43.740 하나의 선택지가 될 수 있을 것 같습니다. 00:07:51.600 --> 00:07:56.140 하지만 제 생각에는 솔루션을 구축하려는 분야의 기초 기술에 대한 탄탄한 실력이 필요하다고 생각합니다. 00:08:00.000 --> 00:08:11.380 네, 그리고 코파일럿 확장성 전문가이신데 00:08:11.380 --> 00:08:15.320 표준 코파일럿 마이크로소프트 365 코파일럿은 어디까지 확장되고 00:08:15.320 --> 00:08:17.600 코파일럿 확장성은 어디서부터 시작되는 건가요? 00:08:18.500 --> 00:08:19.940 네, 좋은 질문입니다. 00:08:19.940 --> 00:08:24.720 솔직히 말해서 2년 전 코파일럿이 처음 출시되었을 때 00:08:24.720 --> 00:08:27.080 아마도 첫 번째 버전이었을 텐데 00:08:27.080 --> 00:08:32.360 채팅 기능이 정말 최소한에 그쳤습니다. 00:08:33.480 --> 00:08:36.120 기본적으로 GPT 기반의 채팅이었죠. 00:08:36.780 --> 00:08:42.540 하지만 마이크로소프트는 마이크로소프트 365 코파일럿을 많이 발전시켰습니다. 00:08:43.600 --> 00:08:46.500 기본적으로 지금은 다양한 기능을 갖추고 있지만 00:08:46.500 --> 00:08:51.800 확장성은 예전보다 떨어졌습니다. 00:08:51.800 --> 00:08:57.810 예전에는 플러그인 등을 개발할 수 있었지만 00:08:57.810 --> 00:09:03.770 솔직히 말해서 지금은 확장성이란 무언가를 구축하고 사용자 정의하고 싶을 때 00:09:03.770 --> 00:09:07.270 예를 들어 오케스트레이터를 사용자 정의하거나 00:09:07.270 --> 00:09:10.330 사용자 인터페이스를 좀 더 개인화하고 싶을 때 00:09:10.330 --> 00:09:14.430 또는 상담원을 마이크로소프트 365 채팅뿐만 아니라 00:09:14.430 --> 00:09:17.210 웹사이트에도 통합하고 싶을 때를 말합니다. 00:09:23.260 --> 00:09:28.200 즉, 확장성은 백그라운드에서 더 많은 사용자 정의를 원할 때 시작됩니다. 00:09:28.200 --> 00:09:39.700 오케스트레이터를 사용자 정의하거나 00:09:39.700 --> 00:09:42.320 인터페이스를 사용자 정의하거나 00:09:42.320 --> 00:09:45.960 코파일럿 채팅이 기본적으로 할 수 없는 기능 00:09:45.960 --> 00:09:50.880 예, SN응답을 사용자 정의하고 싶을 때 확장성이 발휘됩니다. 00:09:55.110 --> 00:09:58.210 많은 사람들이 상담원에 대해 이야기하는 부분입니다. 00:09:58.730 --> 00:10:04.220 음, 뭐죠? 뭐죠? 왜죠? 00:10:04.580 --> 00:10:09.120 왜 지금 이렇게 많은 에이전트가 코파일럿 에이전트에 의존하는 걸까요? 00:10:09.120 --> 00:10:17.360 그리고 왜 모든 걸 위한 하나의 큰 코파일럿을 만들지 않는 걸까요? 00:10:18.980 --> 00:10:21.220 네, 정말 흥미로운 질문입니다. 00:10:21.440 --> 00:10:25.780 솔직히 말해서 마이크로소프트는 앞서 말씀드린 것처럼 많이 발전했습니다. 00:10:26.880 --> 00:10:33.440 아마 6개월 전만 해도 에이전트는 그저 화제거리였을 겁니다. 00:10:33.440 --> 00:10:38.100 하지만 이제 마이크로소프트는 코파일럿 코워크를 도입했고 00:10:38.100 --> 00:10:43.060 솔직히 말해서 요즘 코파일럿 코워크는 많은 에이전트를 대체할 수 있습니다. 00:10:45.960 --> 00:10:49.240 에이전트라는 용어는 단지 구분을 위한 것일 뿐입니다. 00:10:50.140 --> 00:10:53.600 이제 우리는 각 에이전트가 자신의 범위와 책임을 갖는 00:10:53.600 --> 00:10:56.300 멀티 에이전트 모델에 더 집중하고 있습니다. 00:10:56.300 --> 00:11:02.280 그리고 큰 코파일럿을 만들지 않는 이유는 기본적으로 성능 때문입니다. 00:11:02.740 --> 00:11:10.330 첫째, 명령어와 도구가 너무 많으면 성능 면에서 문제가 발생할 수 있습니다. 00:11:10.850 --> 00:11:14.090 그리고 요즘 아키텍처는 멀티 에이전트 방식입니다. 00:11:15.010 --> 00:11:17.090 코파일럿 스튜디오를 사용할 수도 있고 00:11:17.090 --> 00:11:22.310 직접 코드를 작성하거나 사용자 정의 개발을 통해 에이전트를 구현할 수도 있습니다. 00:11:22.310 --> 00:11:26.890 하지만 요즘에는 각 에이전트가 성능 측면에서 00:11:26.890 --> 00:11:31.450 자신의 범위와 책임을 갖는 멀티 에이전트 접근 방식이 더 좋습니다. 00:11:33.290 --> 00:11:37.410 또한 에이전트 아키텍처를 명확하게 정의하는 것이 중요합니다. 00:11:45.050 --> 00:11:46.030 네, 그렇습니다. 00:12:08.820 --> 00:12:12.080 기본적인 AI 에이전트 아키텍처를 생각해보면 00:12:12.080 --> 00:12:15.540 예를 들어 비밀번호를 처리한다고 가정해보겠습니다. 00:12:15.540 --> 00:12:25.320 하지만 추론, 도구, 지식, 그리고 명령어를 어떻게 00:12:25.320 --> 00:12:29.500 AI 에이전트 아키텍처에 통합할지 생각해봐야 합니다. 00:12:37.260 --> 00:12:41.440 가장 먼저 답해야 할 질문은 바로 이 에이전트의 목표는 무엇인가? 00:12:44.730 --> 00:12:45.070 입니다. 00:12:48.890 --> 00:12:50.970 기본적으로 에이전트 아키텍처는 00:12:50.970 --> 00:12:55.470 로우 코드 방식 인지 커스텀 개발 방식 인지에 따라 크게 달라집니다. 00:12:59.340 --> 00:12:59.880 커스텀 00:12:59.880 --> 00:13:07.630 개발 방식에서는 보안, 호스팅 등 모든 것을 직접 관리해야 합니다. 00:13:07.650 --> 00:13:10.610 반면 로우 코드 방식에서는 명령어를 입력하고 00:13:10.610 --> 00:13:13.570 필요한 도구를 선택하는 방식으로 간단하게 구현할 수 있습니다. 00:13:26.070 --> 00:13:29.830 로우 코드 방식의 아키텍처는 생각만큼 간단하지는 않지만 00:13:29.830 --> 00:13:32.930 명령어를 정의하고 도구를 선택하거나 00:13:32.930 --> 00:13:35.610 연결하려는 다른 에이전트를 선택하는 등 00:13:35.610 --> 00:13:37.550 빠른 속도를 제공할 수 있습니다. 00:13:39.330 --> 00:13:42.730 하지만 커스텀 개발 방식, 즉 시멘틱 커널 이나 00:13:42.730 --> 00:13:47.610 에이전트 파머와 같은 도구를 직접 개발하는 경우에는 훨씬 간단합니다. 00:13:47.610 --> 00:13:55.990 아크틱 아키텍처는 보안과 같은 고급 개념을 다뤄야 하기 때문에 훨씬 더 복잡할 수 있습니다. 00:14:00.180 --> 00:14:02.500 예를 들어 여러 도구를 사용하고 00:14:02.500 --> 00:14:07.620 ncp를 통합하거나 리버스 프록시로 보호되는 내부 도구에 연결하려는 경우 00:14:07.620 --> 00:14:09.740 인증 측면에서 더욱 그렇습니다. 00:14:13.410 --> 00:14:16.150 따라서 코파일럿 스튜디오와 같은 환경에서 00:14:16.150 --> 00:14:18.210 사용자 지정 에이전트를 다룰 때는 00:14:18.210 --> 00:14:21.610 아키텍처 측면에서 더 많은 것을 고려해야 합니다. 00:14:21.610 --> 00:14:31.500 사용자 지정 개발 방식을 사용하면 아키텍처를 빠르게 정의할 수 있지만 00:14:31.500 --> 00:14:33.620 고급 개념을 다뤄야 함으로 00:14:33.620 --> 00:14:37.460 많은 사람들에게는 기초적인 부분이 어려워 보일 수 있습니다. 00:14:43.880 --> 00:14:47.920 솔직히 말씀드리면 저는 다양한 요구사항을 다뤄왔습니다. 00:14:48.460 --> 00:14:49.840 커스텀 개발일 수도 있고 00:14:49.840 --> 00:14:51.940 코파일럿 스튜디오일 수도 있고 00:14:51.940 --> 00:14:56.180 에이전트 빌더에서 아주 간단하고 깔끔한 에이전트를 만들 수도 있습니다. 00:14:56.180 --> 00:15:00.040 기본적으로 아키텍처를 정의하는 것은 00:15:00.040 --> 00:15:03.200 어떤 접근방식을 택하느냐에 따라 달라집니다. 00:15:04.860 --> 00:15:07.880 기본적으로 일반적인 아키텍처를 만들 수는 있지만 00:15:07.880 --> 00:15:12.740 그 후에는 로우 코드 방식 인지 포 코드 방식 인지에 따라 결정됩니다. 00:15:14.180 --> 00:15:16.620 네, 네, 음 00:15:16.620 --> 00:15:24.790 일반적인 엔터프라이즈 AI 에이전트의 구조를 설명해 주시겠습니까? 00:15:24.790 --> 00:15:28.850 네, 가능합니다. 00:15:34.600 --> 00:15:35.500 간단히 말해서 00:15:35.500 --> 00:15:39.480 예를 들어 IT 지원 에이전트와 같은 요구사항이 있을 때 00:15:39.480 --> 00:15:42.640 기본적으로 여러 에이전트가 있을 수 있습니다. 00:15:48.120 --> 00:15:50.120 하지만 요즘에는 말씀드린 것처럼 00:15:50.120 --> 00:15:52.760 멀티 에이전트 방식을 사용하고 있으며 00:15:52.760 --> 00:15:57.560 저는 첫 번째 에이전트를 프런트엔드, 즉 최전선에 배치합니다. 00:15:58.760 --> 00:16:01.800 그러니까 이 담당자가 프런트 에이전트이고 00:16:01.800 --> 00:16:07.180 이 프런트 에이전트는 모든 요청을 예를 들어 다른 에이전트로 라우팅합니다. 00:16:08.880 --> 00:16:12.580 예를 들어 사용자가 세일즈포스 관련 질문을 하면 00:16:12.580 --> 00:16:17.980 이 담당자는 모든 요청을 세일즈포스 IT 지원 담당자에게 전달합니다. 00:16:18.920 --> 00:16:23.400 보시다시피 저희는 일부 고객을 위해 이러한 아키텍처를 구축했는데 00:16:23.400 --> 00:16:27.120 각 에이전트가 담당하는 범위가 다르기 때문입니다. 00:16:29.260 --> 00:16:32.480 세일즈포스나 M365 같은 제품일 수도 있습니다. 00:16:33.940 --> 00:16:36.420 그리고 백그라운드에서 각 에이전트는 00:16:36.420 --> 00:16:39.620 일련의 지침과 두 개의 작업 세트를 가지고 있습니다. 00:16:40.360 --> 00:16:43.520 요즘에는 MCP 서버를 사용하는 것이 더 좋습니다. 00:16:44.840 --> 00:16:50.280 MCP 서버는 이제 여러 서비스를 AI와 통합하는 범용 플러그인이기 때문입니다. 00:16:54.880 --> 00:16:57.600 그래서 저는 여러 대의 MCP 서버와 지라, 00:16:58.100 --> 00:17:01.860 서비스나우 지식 기반과 같은 내부 지식 소스를 가지고 있습니다. 00:17:02.220 --> 00:17:08.100 따라서 에이전트별로 일련의 지침이 제공됩니다. 00:17:08.900 --> 00:17:14.980 그리고 이러한 지침들은 에이전트의 범위와 각 에이전트의 역할을 정의합니다. 00:17:17.630 --> 00:17:23.150 그 후에는 MCPS 서버 세트와 PDF 파일과 같은 지식 소스가 있을 수 있습니다. 00:17:23.150 --> 00:17:28.550 따라서 여러 종류의 데이터 소스가 있을 수 있습니다. 00:17:28.550 --> 00:17:38.930 그리고 사용자가 예를 들어 메인 에이전트에 요청을 하면 00:17:38.930 --> 00:17:44.110 메인 에이전트는 해당 작업을 각 에이전트에 위임해야 한다고 정의합니다. 00:17:47.370 --> 00:17:55.820 이제 코파일럿 스튜디오가 전체 아키텍처에서 어떤 역할을 하는지 좀 더 자세히 살펴보겠습니다. 00:17:55.820 --> 00:18:05.220 솔직히 말해서 코파일럿 스튜디오는 마이크로소프트 위 로컬 도구입니다. 00:18:05.420 --> 00:18:18.230 따라서 아키텍처 측면에서 코파일럿 스튜디오는 기본적으로 개발자가 아닌 사람들을 위한 메이커 도구입니다. 00:18:19.710 --> 00:18:21.890 그리고 아키텍처 측면에서 말씀드리자면 00:18:22.510 --> 00:18:26.890 예를 들어 제가 앞서 언급했던 IT 지원 사례를 다시 살펴보면 00:18:26.890 --> 00:18:29.890 코파일럿 스튜디오가 적합할 것입니다. 00:18:30.130 --> 00:18:34.790 왜냐하면 아키텍처 측면에서 코파일럿 스튜디오는 필요한 기능을 제공하기 때문입니다. 00:18:35.210 --> 00:18:38.850 코파일럿 스튜디오를 사용하면 MCP 서버를 정의하고 00:18:38.850 --> 00:18:43.470 필요에 따라 외부 또는 내부 지식 소스를 쉽게 통합할 수 있습니다. 00:18:46.420 --> 00:18:47.980 하지만 앞서 말씀드린 것처럼 00:18:47.980 --> 00:18:53.500 예를 들어 오케스트레이터를 조금 더 사용자 정의하고 싶은 사용 사례가 있다고 가정해보겠습니다. 00:18:53.840 --> 00:18:58.060 코파일럿 스튜디오의 기본 설정으로는 오케스트레이터를 사용자 정의할 수 없습니다. 00:18:58.380 --> 00:19:01.760 AI 오케스트레이터를 활성화하는 것만으로 충분하기 때문입니다. 00:19:01.980 --> 00:19:06.340 예를 들어 원하는 작업의 우선순위를 사용자 정의할 수는 없습니다. 00:19:06.920 --> 00:19:09.920 코파일럿 스튜디오가 내부적으로 실행 계획을 정의하고 00:19:09.920 --> 00:19:12.400 사용자는 그 계획을 실행하게 됩니다. 00:19:12.660 --> 00:19:17.900 하지만 좀 더 세밀한 맞춤 설정이 필요하다면 00:19:17.900 --> 00:19:23.440 예를 들어 시멘틱 커널이나 롱체인 같은 프레임워크를 사용하는 것이 좋습니다. 00:19:23.440 --> 00:19:29.460 최근 마이크로소프트에서 출시하니 프레임워크를 사용하면 00:19:29.460 --> 00:19:32.140 오케스트레이션을 쉽게 맞춤 설정하고 00:19:32.140 --> 00:19:36.320 워크플로우를 정의하고 원하는 대로 설정할 수 있습니다. 00:19:39.800 --> 00:19:44.200 코파일럿 스튜디오는 개발자와 제작자를 위해 설계된 아키텍처로 00:19:44.200 --> 00:19:47.260 에이전트를 구성하는 것이 매우 간단합니다. 00:19:48.340 --> 00:19:52.300 다만 코파일럿 스튜디오의 유일한 단점은 라이선스 문제입니다. 00:19:52.300 --> 00:19:57.980 아키텍처를 설계할 때 라이선스 문제를 반드시 고려해야 합니다. 00:20:00.370 --> 00:20:04.830 라이선스는 이제 모든 솔루션에서 중요한 부분을 차지하기 때문입니다. 00:20:07.490 --> 00:20:12.050 요즘 코파일럿 스튜디오는 사용량 기반 요금제로 조금 바뀌었기 때문에 00:20:12.050 --> 00:20:14.070 비용 예측에 주의해야 합니다. 00:20:16.070 --> 00:20:20.610 달성하고자 하는 목표에 따라 맞춤 개발이 더 나은 경우도 있기 때문입니다. 00:20:20.610 --> 00:20:25.790 맞춤 개발을 하면 원하는 위치에 호스팅하고 모든 비용을 직접 관리할 수 있어 00:20:25.790 --> 00:20:28.470 지금보다 비용을 더 쉽게 예측할 수 있습니다. 00:20:31.560 --> 00:20:37.520 코파일럿 크레딧 방식으로는 한 달, 두 달 등의 비용을 정확히 예측하기 어려운 경우가 있습니다. 00:20:42.870 --> 00:20:46.150 그리고 코파일럿 스튜디오의 제한사항은 무엇일까요? 00:20:47.350 --> 00:20:51.410 스튜디오, 음, 제가 선택해야 한다면, 음, 네, 00:20:51.410 --> 00:20:57.350 마이크로소프트 파운드리, 에이저, 파운드리, 정확한 이름이 뭔지 잘 모르겠네요. 00:21:01.520 --> 00:21:02.480 그리고 좋아요. 00:21:03.040 --> 00:21:06.760 완전히 사용자 정의 개발을 해야 한다면 이라고 말해야 할 때 00:21:06.760 --> 00:21:09.060 가장 먼저 답해야 할 질문은 00:21:09.060 --> 00:21:11.880 오케스트레이션을 사용자 정의해야 할까요? 00:21:15.230 --> 00:21:15.590 입니다. 00:21:15.850 --> 00:21:17.850 이게 제게는 첫 번째 질문입니다. 00:21:17.850 --> 00:21:22.550 왜냐하면 이 질문을 통해 오케스트레이션을 사용자 정의하고 싶지 않거나 00:21:22.550 --> 00:21:28.950 오케스트레이션이 어떻게 구성되는지, 계획이 어떻게 생성되는지 깊이 파고들고 싶지 않다면 00:21:28.950 --> 00:21:33.170 코파일럿 비디오 빌더 같은 로우 코드 방식을 사용할 수 있습니다. 00:21:33.930 --> 00:21:35.730 라는 것을 알 수 있기 때문입니다. 00:21:35.930 --> 00:21:40.750 또한, 간단한 사용 사례의 경우 이러한 도구를 사용할 수 있습니다. 00:21:40.750 --> 00:21:49.490 하지만, 오케스트레이션을 사용자 지정하려면 특정 개발 환경이 필요하며 00:21:49.490 --> 00:21:57.220 이 경우, 모델 개발을 위해 파운드리를 사용하거나 자체 플랫폼을 사용해야 합니다. 00:21:57.680 --> 00:21:59.560 사용자 지정 개발의 장점은 00:21:59.560 --> 00:22:05.060 마이크로소프트 파운드리에 호스팅되지 않은 모델도 통합할 수 있다는 것입니다. 00:22:10.720 --> 00:22:16.960 원한다면 파운드리 모델뿐만 아니라 AWS, 구글, 제미나이와 같은 플랫폼이나 00:22:16.960 --> 00:22:22.320 외부에 배포한 모델도 사용자 지정 방식을 통해 에이전트에 직접 통합할 수 있습니다. 00:22:27.920 --> 00:22:29.300 이는 또 다른 장점입니다. 00:22:29.300 --> 00:22:36.800 오케스트레이션, 플랜 생성 방식 등 모든 것을 사용자 지정한 후에는 00:22:36.800 --> 00:22:40.200 파운드리 에이전트에서 모든 작업을 처리하게 됩니다. 00:22:41.640 --> 00:22:46.760 현재 파운드리 위 문제는 초기에는 단순히 모델 호스팅 플랫폼이었다는 점입니다. 00:22:48.600 --> 00:22:54.020 몇 년 전만 해도 파운드리는 간단한 모델 카탈로그를 제공하고 배포하는 방식이었습니다. 00:22:54.320 --> 00:22:57.380 오늘날 마이크로소프트는 이 제품을 발전시켜 00:22:57.380 --> 00:23:05.190 코파일러 스튜디오와 같은 사용자 인터페이스를 통해 코드를 전혀 작성하지 않고도 00:23:05.190 --> 00:23:07.210 에이전트를 생성할 수 있도록 했습니다. 00:23:09.560 --> 00:23:12.360 거버넌스 관리, 다양한 기능 관리가 가능하며 00:23:12.360 --> 00:23:18.220 로컬 코드 등을 위한 코파일러 스튜디오와 같은 진정한 에이전트 플랫폼으로 진화했습니다. 00:23:18.220 --> 00:23:27.300 하지만 현재 파운드리는 빠르게 발전하고 있기 때문에 생태계 내에서 위치를 정확히 파악하기가 어렵습니다. 00:23:33.690 --> 00:23:39.370 마이크로소프트는 MCP 통합 등 코파일러 스튜디오와 유사한 기능을 몇 가지 도입했습니다. 00:23:44.180 --> 00:23:49.890 그러나 코파일러 스튜디오의 주요 한계는 모델 기능에 있습니다. 00:23:51.530 --> 00:23:54.750 코드를 통합하거나 시각화하는 기능만 제공됩니다. 00:23:54.750 --> 00:24:01.520 하지만 예를 들어 특정 버전의 모델을 가지고 있어서 직접 통합하고 싶다면 00:24:01.520 --> 00:24:06.200 기본적으로는 불가능하고 자체 개발 도구를 사용해야 합니다. 00:24:07.720 --> 00:24:10.600 예를 들어 LN 플랫폼을 사용하는 경우처럼요. 00:24:10.780 --> 00:24:14.600 제 고객 중에는 AWS 플랫폼을 사용하는 분이 있는데 00:24:14.600 --> 00:24:20.140 이 경우에는 외부에서 관리하는 가격 책정 방식으로 모델을 통합할 수 있습니다. 00:24:20.140 --> 00:24:24.380 네, 맞습니다. 00:24:25.180 --> 00:24:26.960 그리고 에이전트를 개발할 때도 00:24:26.960 --> 00:24:31.070 마찬가지로 00:24:31.070 --> 00:25:01.980 많은 사람들이 모델 컨텍스트 프로토콜 MCP에 대해 이야기합니다. 00:25:03.980 --> 00:25:08.560 왜 MCP가 에이전트 개발에서 가장 중요한 주제 중 하나가 되었을까요? 00:25:11.120 --> 00:25:15.100 아직 MCP를 사용해 본 적이 없는 분들을 위해 설명드리자면 00:25:15.100 --> 00:25:16.880 MCP는 무엇일까요? 00:25:18.380 --> 00:25:19.540 좀 어려운 단어죠. 00:25:19.540 --> 00:25:23.480 간단히 말해서 많은 사람들이 MCP에 대해 이야기하는 이유는 00:25:23.480 --> 00:25:26.240 MCP가 중요한 문제를 해결하기 때문입니다. 00:25:29.260 --> 00:25:33.220 MCP는 도구, 기술, 그리고 어쩌면 외부 툴까지 00:25:33.220 --> 00:25:36.240 AI에 통합하는 방법을 통합하는 기술입니다. 00:25:38.600 --> 00:25:40.080 과거에는 MCP가 없었기 때문에 00:25:40.080 --> 00:25:42.340 여러 서비스들이 서로 다른 방식으로 통신하고 00:25:42.340 --> 00:25:46.580 각기 다른 기술 프로토콜과 아키텍처 접근 방식을 사용하면서 혼란스러웠습니다. 00:25:54.300 --> 00:25:56.040 MCP는 이러한 서비스들을 00:25:56.040 --> 00:26:00.200 AI 에이전트 또는 AI 솔루션에 통합하는 역할을 합니다. 00:26:00.200 --> 00:26:03.280 좀 더 일반적인 표현으로 말하자면 00:26:03.280 --> 00:26:09.940 MCP는 외부 툴이든 내부 툴이든 00:26:09.940 --> 00:26:12.720 둘 다 통합하는 핵심적인 방법입니다. 00:26:14.180 --> 00:26:17.720 MCP는 기술적인 측면에서 통합을 제공하기 때문에 00:26:17.720 --> 00:26:21.260 AI 아키텍처에서 매우 중요한 부분을 차지합니다. 00:26:21.260 --> 00:26:25.940 과거에는 API 통합이 중요했지만 00:26:25.940 --> 00:26:28.920 지금은 MCP가 그 역할을 하고 있습니다. 00:26:30.900 --> 00:26:33.460 물론 이것은 진화라기보다는 00:26:33.460 --> 00:26:37.600 과거에는 API를 통해 에이전트를 통합했던 방식입니다. 00:26:38.240 --> 00:26:42.980 인증 방법이나 관리 방법 또는 도구를 호출하는 방법을 관리해야 합니다. 00:26:42.980 --> 00:26:46.280 하지만 AI는 이제 이 도구를 사용할 수 있으니 00:26:46.280 --> 00:26:48.960 목표 달성에 필요한 것을 선택할 수 있습니다. 00:26:49.680 --> 00:26:50.820 라고 말할 수 있습니다. 00:26:50.820 --> 00:26:57.320 MCP에서 API 연결로 바뀌면서 00:26:57.320 --> 00:26:59.380 실제로 무엇이 달라져들까요? 00:27:05.110 --> 00:27:07.430 기본적으로 과거에는 통합 측면에서 00:27:07.430 --> 00:27:09.970 API는 지능적이지 않았습니다. 00:27:14.830 --> 00:27:17.350 API는 단순히 도구를 호출하고 00:27:17.350 --> 00:27:19.590 데이터를 제공하는 방식이었죠. 00:27:22.300 --> 00:27:25.700 MCP와의 차이점은 MCP가 아키텍처 측면에서 00:27:25.700 --> 00:27:27.660 훨씬 더 지능적이라는 것입니다. 00:27:30.910 --> 00:27:34.690 MCP는 단순히 데이터나 정보를 제공하는 도구뿐만 아니라 00:27:34.690 --> 00:27:37.690 지시 능력과 다양한 기능을 갖추고 있어 00:27:37.690 --> 00:27:40.070 진정으로 지능적인 플랫폼이 됩니다. 00:27:42.730 --> 00:27:44.930 기본적으로 MCP는 AI에게 00:27:44.930 --> 00:27:47.570 좋아요, 그걸 달성하고 싶으세요. 00:27:50.020 --> 00:27:52.780 요청에 딱 맞는 도구를 제공해 드릴 수 있습니다. 00:27:53.660 --> 00:27:54.800 라고 말할 수 있습니다. 00:27:54.800 --> 00:27:57.840 AI는 하나의 도구만 호출할 수 있는 것이 아니라 00:27:57.840 --> 00:28:01.460 원하는 결과를 얻기 위해 이러한 도구들을 호출해야 합니다. 00:28:01.720 --> 00:28:03.340 이것이 MCP의 역할입니다. 00:28:03.640 --> 00:28:06.660 MCP는 AI에게 이러한 도구들이 있습니다. 00:28:07.060 --> 00:28:11.340 이제 이 도구, 저 도구, 또는 여러 도구를 호출하여 00:28:11.340 --> 00:28:12.800 목표를 달성할 수 있습니다. 00:28:13.520 --> 00:28:14.360 라고 알려줍니다. 00:28:14.360 --> 00:28:19.260 MCP는 AI에게 모든 것의 실제 맥락을 제공합니다. 00:28:20.800 --> 00:28:24.180 API는 단순히 도구와 설명만 제공하는 것이고 00:28:24.180 --> 00:28:25.600 그게 전부입니다. 00:28:26.940 --> 00:28:28.240 그렇다면 MCP는 00:28:28.240 --> 00:28:34.810 메타데이터와 유사한 모델 컨텍스트 프로토콜이라고 할 수 있을까요? 00:28:39.500 --> 00:28:43.120 아니요. MCP는 내부적으로 작동하는 프로토콜입니다. 00:28:43.360 --> 00:28:46.540 B, 기본적으로 MCP는 기술 프로토콜입니다. 00:28:46.540 --> 00:28:56.350 그리고 그 이면에는 메타데이터, 설명, 그리고 AI 스킬이 있습니다. 00:28:56.790 --> 00:29:01.070 AI에 초점을 맞추니 프로토콜은 기본적으로 스킬과 명령어를 제공하며 00:29:01.070 --> 00:29:03.690 AI는 이 도구들은 이런 기능을 하고 00:29:03.690 --> 00:29:05.530 저 도구는 저런 기능을 한다. 00:29:05.710 --> 00:29:07.450 이 스킬들을 호출할 수 있고 00:29:07.450 --> 00:29:11.830 MCP 서버에의 정보를 요청해서 원하는 결과를 얻을 수 있다. 00:29:12.050 --> 00:29:13.270 라고 이해할 수 있습니다. 00:29:14.910 --> 00:29:16.910 하지만 메타데이터도 필요합니다. 00:29:16.910 --> 00:29:21.870 도구의 이름과 내부 작동 방식 등을 정의해야 하기 때문입니다. 00:29:25.980 --> 00:29:28.000 MCP가 미래라고 할 수 있을까요? 00:29:30.360 --> 00:29:33.440 기업들이 수백 개의 레스트 API를 보유하고 있다면 00:29:33.440 --> 00:29:37.660 이러한 API들을 기반으로 MCP 서버를 구축해야 할까요? 00:29:37.660 --> 00:29:45.890 네, MCP 서버는 API와 함께 작동합니다. 00:29:46.130 --> 00:29:48.930 물론 기존 API를 대체하는 것은 아닙니다. 00:29:49.710 --> 00:29:53.450 음, 요약하자면 MCP 서버는 괜찮은 편입니다. 00:29:53.450 --> 00:29:55.810 컨텍스트를 제공하고 00:29:55.810 --> 00:29:59.290 MCP는 백그라운드에서 API를 호출할 수 있습니다. 00:29:59.510 --> 00:30:01.270 백그라운드에서 작동하는 것이지 00:30:01.270 --> 00:30:03.590 MCP 서버는 프런트엔드입니다. 00:30:03.870 --> 00:30:07.210 즉, 사용자가 호출해야 하는 프런트엔드 도구입니다. 00:30:07.610 --> 00:30:10.090 백그라운드에서는 사용자의 요청에 따라 00:30:10.090 --> 00:30:12.470 API가 전달되기 때문입니다. 00:30:12.470 --> 00:30:18.690 내부적으로는 API, 데이터베이스, 여러 도구 등이 사용될 수 있지만 00:30:18.690 --> 00:30:23.750 자체 MCP 서버를 구축하려면 이러한 요소들을 모두 처리해야 합니다. 00:30:25.810 --> 00:30:34.170 예를 들어, 회사 내부에 다양한 API와 서비스, 예, 재무서비스, 인사서비스가 있다고 가정해보겠습니다. 00:30:34.170 --> 00:30:41.040 자체 MCP를 구축하려면 이러한 API들을 모두 관리해야 하며 00:30:41.040 --> 00:30:44.840 MCP 서버는 이러한 API들을 노출해야 합니다. 00:30:46.180 --> 00:30:52.020 즉, 어떤 서비스, 어떤 도구, 어떤 스킬 등이 제공되는지 명확히 해야 합니다. 00:30:52.020 --> 00:31:02.270 또한, API마다 인증 방식이 다르기 때문에 내부적으로 인증 처리도 필요합니다. 00:31:03.570 --> 00:31:05.790 키 입력 방식 등 다양한 인증 방식이 존재하므로 00:31:05.790 --> 00:31:08.210 MCP는 이러한 요소들을 모두 처리해야 합니다. 00:31:08.570 --> 00:31:11.030 MCP는 사용 가능한 도구들을 제공하고 00:31:11.030 --> 00:31:15.030 이러한 도구들은 내부적으로 여러 API를 호출할 수 있습니다. 00:31:15.290 --> 00:31:18.210 하나의 API는 여러 가지 방식으로 작동할 수 있으며 00:31:18.210 --> 00:31:20.570 내부 아키텍처 또한 다양할 수 있습니다. 00:31:20.570 --> 00:31:32.470 그리고, MCP는 100에서 500개의 AI 에이전트가 있을 때 어떤 도구를 선택하나요? 00:31:37.100 --> 00:31:39.040 우선 몇 가지 사항을 고려합니다. 00:31:40.920 --> 00:31:45.000 에이전트의 요청이 들어오면 사용 가능한 모든 도구를 검색합니다. 00:31:46.420 --> 00:31:49.620 MCP 서버는 사용 가능한 도구가 모두 있습니다. 00:31:49.620 --> 00:31:51.060 라고 확인합니다. 00:31:51.660 --> 00:31:58.360 그러면, 에이전트의 오케스트레이터는 이 도구를 사용할 수 있습니다. 00:31:59.020 --> 00:31:59.900 LLM도 있습니다. 00:32:00.240 --> 00:32:01.220 라고 인식합니다. 00:32:01.480 --> 00:32:03.320 그 후 실행 계획을 생성합니다. 00:32:04.600 --> 00:32:05.660 간단히 요약하면, 00:32:06.080 --> 00:32:08.700 수행할 작업을 포함하는 계획을 생성하고 00:32:08.700 --> 00:32:10.020 이 작업 내에서 00:32:10.020 --> 00:32:18.010 하나, 둘, 셋 또는 그 이상의 도구를 호출하여 00:32:18.010 --> 00:32:20.610 사용자가 요청한 작업을 완료할 수 있습니다. 00:32:20.990 --> 00:32:25.410 즉, 에이전트의 오케스트레이터는 MCP 도구를 이해하고 00:32:25.410 --> 00:32:28.090 요청에 가장 적합한 도구를 선택합니다. 00:32:28.690 --> 00:32:29.710 보시다시피 00:32:29.710 --> 00:32:35.390 이것이 바로 LLM의 도움을 받아 도구를 선택하는 등의 작업을 수행하는 00:32:35.390 --> 00:32:37.350 오케스트레이터의 역할입니다. 00:32:38.470 --> 00:32:39.190 LLM은 00:32:39.190 --> 00:32:44.660 일종의 두뇌 역할을 하며, 00:32:45.080 --> 00:32:51.540 오케스트레이터는 LLM 및 도구와 소통하여 작업을 달성하기 위한 최적의 선택과 계획을 세웁니다. 00:32:51.540 --> 00:32:57.910 네, 저는 많은 회사들이 한동안 파워셀로 시작해서 00:32:57.910 --> 00:33:02.510 지금은 마이크로소프트 그래프 API를 사용하고 있다고 생각합니다. 00:33:04.030 --> 00:33:06.170 그래프 API와 MCP는 00:33:06.170 --> 00:33:10.720 어떻게 작동하나요? 00:33:14.070 --> 00:33:17.310 사실 그래프 API 자체에는 MCP가 없습니다. 00:33:17.310 --> 00:33:27.860 마이크로소프트 클라우드 플랫폼 00:33:27.860 --> 00:33:35.440 CFT 환경에서는 마이크로소프트 그래프 API를 기반으로 하는 여러 MCP 서버를 제공하고 있습니다. 00:33:38.170 --> 00:33:41.430 예를 들어, 팀의 LCP 서버를 사용하고 싶다면 00:33:41.430 --> 00:33:46.730 백그라운드에서 MCP 서버를 사용할 때 그래프 API가 호출됩니다. 00:33:46.730 --> 00:33:53.990 따라서 마이크로소프트 365 환경에서 그래프 AI는 매우 중요합니다. 00:33:55.190 --> 00:33:59.450 백그라운드에서 MCP가 그래프와 통신하여 요청을 처리하고 00:33:59.450 --> 00:34:04.270 원활하게 작동하도록 하기 때문입니다. 00:34:04.510 --> 00:34:05.490 네, 맞습니다. 00:34:05.490 --> 00:34:09.370 요즘 그래프는 코파일럿에서도 핵심적인 역할을 합니다. 00:34:10.990 --> 00:34:14.830 코파일럿 위 의미 론적 인덱스는 원시 데이터를 기반으로 하지만 00:34:14.830 --> 00:34:18.390 실제로는 MCP를 통해 그래프를 사용합니다. 00:34:19.190 --> 00:34:40.120 현재, 마이크로소프트 365에는 조직의 컨텍스트, 문서, 회의, 이메일, 담당자, 팀, 대화 내용, 콘텐츠 공유 등 엄청난 가치가 담겨 있습니다. 00:34:40.500 --> 00:34:47.570 이러한 컨텍스트를 보안 문제를 일으키지 않고 어떻게 노출할 수 있을까요? 00:34:51.340 --> 00:34:53.760 거버넌스 측면에서 말씀하시는 건가요? 00:34:56.100 --> 00:35:01.880 네, 많은 사람들이 제대로 된 거버넌스 체계를 구축하지 않고 에이전트를 개발하기 때문에 00:35:01.880 --> 00:35:03.220 항상 문제가 됩니다. 00:35:07.000 --> 00:35:11.860 에이전트를 만들고 배포하면 이 에이전트는 많은 데이터를 처리하게 되는데 00:35:11.860 --> 00:35:13.800 어떻게 관리해야 할까요? 00:35:16.760 --> 00:35:20.820 첫 번째 질문은 에이전트 거버넌스를 어떻게 구축하느냐입니다. 00:35:20.820 --> 00:35:25.060 이전에는 말씀하신 것처럼 혼란스러웠습니다. 00:35:26.900 --> 00:35:32.120 많은 사람들이 에이전트를 만들고 싶어 하거나 AI 솔루션을 만들고 싶어 하지만 00:35:32.120 --> 00:35:37.180 그 이면에는 예를 들어 마이크로소프트 365 환경에서 라면 00:35:37.180 --> 00:35:41.300 가장 먼저 해야 할 일 중 하나가 데이터를 이해하는 것입니다. 00:35:42.840 --> 00:35:45.000 데이터를 이해하지 못하면 길을 잃게 됩니다. 00:35:45.480 --> 00:35:47.560 데이터를 이해하는 것은 매우 중요합니다. 00:35:48.680 --> 00:35:51.460 예를 들어 기밀 데이터를 다루고 있는지 00:35:51.460 --> 00:35:56.320 아니면 매우 기밀성이 높은 데이터를 다루고 있는지 등을 파악해야 합니다. 00:35:56.320 --> 00:36:00.520 음, 먼저 데이터를 이해해야 합니다. 00:36:03.290 --> 00:36:05.650 마이크로소프트 CR을 사용하는 경우 00:36:05.650 --> 00:36:10.070 예를 들어 DLP 기능, 민감도 분석 등을 설정해야 합니다. 00:36:13.350 --> 00:36:15.850 이러한 기능이 없으면 문제가 발생할 수 있습니다. 00:36:16.110 --> 00:36:18.610 또한 데이터를 어느 정도 정리해야 합니다. 00:36:20.350 --> 00:36:25.150 AI는 데이터가 불량하면 에이전트가 제대로 작동하지 않기 때문입니다. 00:36:28.600 --> 00:36:32.160 예를 들어 SharePoint, Team Channel 등의 마스크가 있는 경우 00:36:32.160 --> 00:36:41.230 에이전트 방식이 제대로 작동하지 않을 수 있습니다. 00:36:42.170 --> 00:36:44.950 따라서 데이터를 이해하는 것이 매우 중요합니다. 00:36:46.070 --> 00:36:50.050 몇 가지 기본적인 보안, 예를 들어 인증 등을 마련해야 합니다. 00:36:54.290 --> 00:36:59.110 제가 말씀드렸듯이 퍼뷰는 이러한 모든 보안 및 거버넌스 기능을 구현하는 데 00:36:59.110 --> 00:37:01.010 핵심적인 솔루션이 되었습니다. 00:37:06.390 --> 00:37:07.690 데이터를 정리하고 00:37:07.690 --> 00:37:14.960 기본적인 보안 조치를 취한 후에는 라이선스에 대해서도 이해해야 합니다. 00:37:14.960 --> 00:37:24.700 에이전트를 구축하기 전에 개발자들이 무엇을 할 수 있는지, 00:37:25.340 --> 00:37:26.680 관련 교육을 받았는지, 00:37:27.300 --> 00:37:28.860 라이선스가 적절한지, 00:37:29.380 --> 00:37:31.820 구독 방식이 필요한지 등을 파악해야 합니다. 00:37:38.180 --> 00:37:40.940 또한 가장 큰 문제 중 하나는 툴링입니다. 00:37:41.000 --> 00:37:48.430 모든 툴을 개발 환경과 에이전트에 어떻게 제대로 통합해야 할까요? 00:37:48.430 --> 00:37:53.630 어떤 부분을 제한해야 할까요? 00:37:59.260 --> 00:38:03.020 솔직히 말해서 고려해야 할 사항이 많아 큰 문제입니다. 00:38:03.520 --> 00:38:07.540 하지만 제 생각에 가장 중요한 것은 데이터를 이해하는 것입니다. 00:38:09.990 --> 00:38:13.050 기업이 데이터를 이해하지 못하면 처음부터 문제가 발생할 수 있습니다. 00:38:13.050 --> 00:38:34.280 네, 그리고 보안 주제에 대해서는 두 가지 유형의 사람들이 있다고 생각합니다. 00:38:38.240 --> 00:38:42.480 한쪽에서는 사용자 권한이 필요하다고 하고, 00:38:42.980 --> 00:38:46.040 다른 쪽에서는 애플리케이션 권한이 필요하다고 합니다. 00:38:46.780 --> 00:38:49.260 에이전트 생성은 어떻게 이루어져야 할까요? 00:38:50.320 --> 00:38:53.600 에이전트는 일반적으로 어떻게 작동해야 할까요? 00:38:58.400 --> 00:39:01.920 제 최고의 권장사항은 에이전트 기반 솔루션을 다룰 때는 00:39:01.920 --> 00:39:05.300 항상 사용자 권한 위임 방식을 사용하는 것입니다. 00:39:08.400 --> 00:39:11.700 보안 측면에서 솔직히 말해서 더 낫기 때문입니다. 00:39:12.920 --> 00:39:17.140 사용자는 자신이 접근 권한이 있는 데이터와 도구만 사용하게 됩니다. 00:39:18.300 --> 00:39:20.220 이것이 가장 중요한 원칙입니다. 00:39:22.320 --> 00:39:24.920 특정 API나 특정 컨텍스트에 대해 00:39:24.920 --> 00:39:28.480 애플리케이션 권한이 필요한 경우 애는 사용할 수 있습니다. 00:39:29.900 --> 00:39:35.700 하지만 애플리케이션 권한을 직접 사용하지 마세요. 00:39:35.860 --> 00:39:39.620 래퍼 컨텍스트 내에서 구현하세요. 00:39:41.520 --> 00:39:43.240 예를 들어 MCP 서버를 만들고, 00:39:44.100 --> 00:39:47.240 이 MCP를 백그라운드에서 애플리케이션 권한과 통합하세요. 00:39:49.240 --> 00:39:54.020 그러면 MCP가 백그라운드에서 애플리케이션 권한을 사용하여 00:39:54.020 --> 00:40:02.840 API를 호출하고 필요한 정보를 제공합니다. 00:40:03.940 --> 00:40:07.680 사용자는 애플리케이션 권한을 직접 사용하지 않아도 됩니다. 00:40:07.680 --> 00:40:11.560 예를 들어, 사용자 권한으로 MCP 서버를 호출하면 00:40:11.560 --> 00:40:17.680 MCP 서버는 전용 애플리케이션 권한을 가진 애플리케이션이나 서비스를 백그라운드에서 호출합니다. 00:40:18.560 --> 00:40:19.680 차이점을 이해하시겠습니까? 00:40:21.560 --> 00:40:22.660 네, 알겠습니다. 00:40:23.740 --> 00:40:24.560 흥미롭네요. 00:40:24.560 --> 00:40:31.090 아키텍처에 대해 생각할 때 좀 더 깊이 살펴봐야 한다고 생각합니다. 00:40:35.060 --> 00:40:37.700 아키텍처에는 크게 세 가지 주제가 있습니다. 00:40:39.280 --> 00:40:47.300 검색, 인자 생성, 지식, 그리고 백도어 엔터프라이즈 검색입니다. 00:40:47.300 --> 00:40:53.530 먼저, RAG부터 시작해 보겠습니다. 00:40:54.110 --> 00:40:57.030 RAG는 아키텍처에서 어떤 역할을 할까요? 00:40:58.070 --> 00:40:59.450 아, RAG 말입니다. 00:40:59.710 --> 00:41:07.240 솔직히 말해서 RAG는 성능 측면에서 가장 뛰어납니다. 00:41:09.260 --> 00:41:12.340 AI는 다양한 종류의 데이터를 이해해야 하는데 00:41:12.340 --> 00:41:19.760 RAG는 기본적으로 질문에 답하기 위해 존재합니다. 00:41:19.760 --> 00:41:28.780 과거에는 RAG가 없었기 때문에 다른 접근방식을 사용해야 했습니다. 00:41:29.720 --> 00:41:31.700 구식은 아니었지만 복잡했습니다. 00:41:33.120 --> 00:41:35.280 하지만 RAG가 핵심적인 이유는 00:41:35.280 --> 00:41:38.220 RAG가 다양한 종류의 데이터를 이해하고 00:41:38.220 --> 00:41:46.170 필요한 정보를 검색할 수 있기 때문입니다. 00:41:47.850 --> 00:41:49.730 데이터는 여러 유형일 수 있습니다. 00:41:49.990 --> 00:41:54.170 따라서 RAG는 오늘날 AI 아키텍처에서 매우 중요합니다. 00:41:54.170 --> 00:42:00.590 네, 하지만 많은 사용자들이 RAG에 대해 이야기할 때 00:42:00.590 --> 00:42:04.230 그 이면에 숨겨진 원리를 잘 모르는 건 사실입니다. 00:42:05.990 --> 00:42:07.930 마이크로소프트 나달은 많은 00:42:07.930 --> 00:42:16.930 소프트웨어 회사들이 요즘 RAG에 대해 자세히 설명하지 않기 때문이죠. 00:42:17.610 --> 00:42:19.810 예를 들어 코파일러 스튜디오 같은 곳에서도 00:42:19.810 --> 00:42:23.670 사용자들은 그 이면에 RAG가 있다는 사실을 이해하지 못합니다. 00:42:23.670 --> 00:42:28.710 요즘에는 좀 더 깊이 파고들면 이런 개념을 알 수 있지만 00:42:28.710 --> 00:42:32.810 많은 사용자들은 RAG가 무엇인지 전혀 모릅니다. 00:42:35.490 --> 00:42:37.130 그저 도구를 사용할 뿐이죠. 00:42:38.490 --> 00:42:38.790 그리고 00:42:38.790 --> 00:42:42.070 다음 주제는 지식입니다. 00:42:44.310 --> 00:42:47.110 AI 시스템은 어떻게 지식을 얻는 걸까요? 00:42:47.110 --> 00:42:50.730 J보드에서 수집하는 걸까요? 00:42:51.530 --> 00:42:54.470 아니면 다른 방식으로 작동하는 걸까요? 00:42:56.910 --> 00:42:58.950 솔직히 말해서 지식은 여러 00:42:58.950 --> 00:43:05.800 다양한 시스템에 저장될 수 있습니다. 00:43:07.900 --> 00:43:09.360 텍스트 파일일 수도 있고 00:43:09.360 --> 00:43:11.340 마크다운 파일일 수도 있고 00:43:11.340 --> 00:43:13.340 지식 기반 파일일 수도 있고 00:43:13.340 --> 00:43:14.840 무엇이든 될 수 있습니다. 00:43:14.840 --> 00:43:17.580 하지만 사실 MCP 서버가 있다면 00:43:17.580 --> 00:43:19.720 이러한 지식에 접근할 수 있습니다. 00:43:19.720 --> 00:43:22.540 또는 예를 들어 저는 잘 모르겠지만 00:43:22.540 --> 00:43:24.780 SharePoint 커넥터가 있거나 00:43:24.780 --> 00:43:28.420 요즘에는 많은 서비스와 연결되는 커넥터가 있기 때문에 00:43:28.420 --> 00:43:31.640 지식에 접근하는 것이 예전보다 훨씬 쉬워졌습니다. 00:43:31.820 --> 00:43:32.620 솔직히 말해서 00:43:32.620 --> 00:43:34.640 과거에는 플러그인을 만들고 00:43:34.640 --> 00:43:36.440 모든 것을 일일이 확인해야 했습니다. 00:43:36.980 --> 00:43:38.940 하지만 지금은 어떤 시스템에든 00:43:38.940 --> 00:43:41.340 직접 연결할 수 있는 커넥터가 있어서 00:43:41.340 --> 00:43:44.560 대규모 개발 인력 없이도 지식을 통합할 수 있습니다. 00:43:44.560 --> 00:43:56.120 저는 종종 우리가 지식을 모아두는 경우가 있는데 00:43:56.120 --> 00:44:00.520 예를 들어 AI는 어떤 문서가 준비되지 않았거나 00:44:00.520 --> 00:44:04.300 오래되었거나 중복되었는지 어떻게 구분할까요? 00:44:09.870 --> 00:44:12.870 AI 시스템은 어떻게 이러한 것들을 이해하고 00:44:12.870 --> 00:44:14.710 무엇을 사용해야 할까요? 00:44:14.710 --> 00:44:22.170 음, 기본적으로 RAG를 사용하는 이유는 00:44:22.170 --> 00:44:26.190 백그라운드에서 데이터가 무엇인지 이해해야 하기 때문입니다. 00:44:26.190 --> 00:44:33.460 솔직히 말씀드리면 간단히 요약하자면 00:44:33.460 --> 00:44:35.320 프롬프트에서 시작합니다. 00:44:35.640 --> 00:44:36.240 사용자는 00:44:36.240 --> 00:44:43.360 예를 들어 지식기반이나 온 드라이브에서 검색하고 싶어합니다. 00:44:46.860 --> 00:44:50.220 백그라운드에서 오케스트레이터는 LME 도움을 받아 00:44:50.220 --> 00:44:52.760 프롬프트와 사용자 의도를 파악합니다. 00:44:53.860 --> 00:44:59.200 백그라운드에서는 인덱스가 작동합니다. 00:45:00.540 --> 00:45:03.300 예를 들어 콤류대는 시멘틱 인덱스가 있는데 00:45:03.300 --> 00:45:12.600 이 시멘틱 인덱스는 모든 정보를 담고 있으며 00:45:12.600 --> 00:45:17.320 시멘틱 인덱스 커리를 통해 AI가 직접 인덱스를 조회하여 00:45:17.320 --> 00:45:18.720 RAG를 수행하고 00:45:18.720 --> 00:45:27.440 필요에 따라 적절한 문서를 선택할 수 있도록 합니다. 00:45:28.000 --> 00:45:30.820 하지만 코파일럿에는 시멘틱 인덱스가 있고 00:45:30.820 --> 00:45:35.920 AI는 백그라운드에서 자연어로의 인덱스를 직접 커리할 수 있습니다. 00:45:37.200 --> 00:45:41.900 예를 들어 회사 VPN, PN을 어떻게 설정해야 하는지 모르겠습니다. 00:45:42.780 --> 00:45:47.240 라고 질문하면 백그라운드에서 시멘틱 인덱스의 RAG, 00:45:47.240 --> 00:45:50.880 리서치 어세스먼트 그룹을 적용하여 00:45:50.880 --> 00:45:55.080 회사 VPN 설정에 필요한 모든 정보를 담은 문서를 검색합니다. 00:45:56.040 --> 00:45:59.000 마이크로소프트 365 코파일럿 채팅의 경우 00:45:59.240 --> 00:46:02.520 백그라운드에서 그래프 API를 사용합니다. 00:46:02.680 --> 00:46:06.140 앞서 말씀드린 것처럼 시멘틱 인덱스가 그래프 API를 기반으로 00:46:06.140 --> 00:46:07.360 구축되어 있기 때문입니다. 00:46:07.520 --> 00:46:10.560 백그라운드에서 그래프 API 기능이 작동하는 것이죠. 00:46:10.560 --> 00:46:12.660 하지만 사용자 지정 개발의 경우 00:46:12.660 --> 00:46:15.020 예를 들어 파운드리 AQ를 사용합니다. 00:46:16.960 --> 00:46:19.020 이전에는 다른 이름의 에이저 서비스였지만 00:46:19.540 --> 00:46:23.480 이제는 원하는 경우 자체 렉 시스템을 구축할 수 있습니다. 00:46:24.680 --> 00:46:26.020 사용자 지정 에이전트를 사용하면 00:46:26.020 --> 00:46:30.100 파운드리 AQ 인스턴스에 직접 질문할 수 있습니다. 00:46:33.670 --> 00:46:36.810 어, 저는 VPN 회사 설정을 사용하고 싶고 00:46:36.810 --> 00:46:39.910 AI가 필요한 문서를 검색할 수 있습니다. 00:46:39.910 --> 00:46:45.920 PDF, Word, Excel 등 어떤 파일이든 가능합니다. 00:46:53.120 --> 00:46:55.580 검색 기능은 이런 식으로 작동하는 거죠. 00:46:59.080 --> 00:46:59.380 아니면 00:46:59.380 --> 00:47:03.500 백그라운드에서 작동하는 건가요? 00:47:03.840 --> 00:47:05.400 네, 백그라운드에서 작동하는군요. 00:47:05.400 --> 00:47:07.700 네, 검색 기능이 있습니다. 00:47:08.700 --> 00:47:09.060 하지만 00:47:09.060 --> 00:47:11.760 요즘에는 00:47:11.760 --> 00:47:17.880 코파일럿 채 뒤 백그라운드에서 00:47:17.880 --> 00:47:19.500 세 가지 기능을 제공합니다. 00:47:19.500 --> 00:47:21.420 첫 번째는 표준 검색으로 00:47:21.420 --> 00:47:28.920 간단히 키워드를 입력하여 문서 전체를 검색하는 기능입니다. 00:47:30.680 --> 00:47:34.520 구글처럼 키워드 검색을 하는 것과 같은 간단한 검색이죠. 00:47:34.960 --> 00:47:35.600 그 외에 00:47:35.600 --> 00:47:39.240 두 가지 다른 기능이 있습니다. 00:47:40.480 --> 00:47:41.240 첫 번째는 00:47:41.240 --> 00:47:44.640 백그라운드에서 작동하는 기능입니다. 00:47:45.640 --> 00:47:47.700 그래프에는 RAG 기능이 있고 00:47:47.700 --> 00:47:51.200 코파일럿 시멘틱 인덱스 검색 기능도 있습니다. 00:47:54.230 --> 00:47:58.830 RAG는 코파일럿 시멘틱 인덱스 검색보다 훨씬 고급 기능입니다. 00:48:01.720 --> 00:48:03.160 하지만 이 세 가지 기능은 00:48:03.160 --> 00:48:05.180 모두 백그라운드에서 작동하여 00:48:05.180 --> 00:48:07.340 사용자가 직접 조작하는 것이 아니라 00:48:07.340 --> 00:48:09.400 AI가 자동으로 호출하여 00:48:09.400 --> 00:48:12.520 온드라이브, 팀즈, M365 등 00:48:12.520 --> 00:48:15.600 다양한 플랫폼의 데이터를 검색할 수 있도록 합니다. 00:48:18.910 --> 00:48:20.710 코파일럿 시멘틱 인덱스에는 00:48:20.710 --> 00:48:22.870 코파일럿 커넥터도 포함됩니다. 00:48:24.030 --> 00:48:25.970 예를 들어, 세일즈 포스를 00:48:25.970 --> 00:48:27.950 코파일럿 커넥터로 연결하면 00:48:27.950 --> 00:48:30.430 세일즈 포스, 서비스 나우 등 00:48:30.430 --> 00:48:33.270 여러 도구의 모든 데이터를 검색할 수 있습니다. 00:48:35.590 --> 00:48:37.030 코파일럿 커넥터를 통해 00:48:37.030 --> 00:48:39.570 모든 데이터를 그래프, 인덱스, 00:48:40.090 --> 00:48:41.690 시멘틱 인덱스에 통합하면 00:48:41.690 --> 00:48:44.670 외부 시스템을 직접 커리할 수 있기 때문입니다. 00:48:47.320 --> 00:48:48.360 네, 알겠습니다. 00:48:51.880 --> 00:48:54.220 그리고 음, 에이전트를 구축할 때 00:48:54.220 --> 00:48:56.260 거버넌스 부분을 고려해야 하는데 00:48:56.260 --> 00:48:57.700 그 중 하나가 바로 00:48:57.700 --> 00:49:04.300 에이전트 수명주기 관리입니다. 00:49:04.900 --> 00:49:05.320 실제로 00:49:05.320 --> 00:49:09.300 어떻게 구현될까요? 00:49:11.520 --> 00:49:12.440 솔직히 말해서 00:49:12.440 --> 00:49:14.380 마이크로소프트 생태계에서는 00:49:14.380 --> 00:49:15.820 상당히 간단합니다. 00:49:16.660 --> 00:49:18.380 예를 들어 로우코드 애플리케이션인 00:49:18.380 --> 00:49:19.980 코파일럿 스튜디오를 사용할 때 00:49:19.980 --> 00:49:22.620 파워 플랫폼 컨셉 IM을 사용하고 있으며 00:49:22.620 --> 00:49:24.100 아무것도 변하지 않았습니다. 00:49:27.240 --> 00:49:29.240 솔루션, ALM, 파이프라인이 00:49:29.240 --> 00:49:30.180 이미 구축되어 있습니다. 00:49:30.720 --> 00:49:36.400 따라서 코파일럿 스튜디오를 사용할 때도 00:49:36.400 --> 00:49:37.860 이전과 크게 다르지 않습니다. 00:49:37.860 --> 00:49:42.720 파워 플랫폼 거버넌스, 수명주기, ALM 측면에서 투자했던 모든 것이 그대로 적용되기 때문입니다. 00:49:44.910 --> 00:49:45.930 이는 좋은 점인데 00:49:45.930 --> 00:49:47.070 많은 사람들이 00:49:47.070 --> 00:49:49.770 코파일럿 스튜디오는 어떻게 관리하나요? 00:49:49.970 --> 00:49:50.590 바른가요? 00:49:50.850 --> 00:49:52.010 라고 묻기 때문입니다. 00:49:52.270 --> 00:49:52.770 아닙니다. 00:49:53.010 --> 00:49:57.910 앱별 또는 코어 오토메이트 애플리케이션 수명주기 관리처럼 매우 간단합니다. 00:49:58.470 --> 00:50:01.170 이 경우에는 에이전트 수명주기 관리라고 하지만 00:50:01.170 --> 00:50:04.650 내부적으로는 코어 플랫폼과 동일한 개념입니다. 00:50:04.650 --> 00:50:12.100 예를 들어 사용자 정의 개발을 할 때는 00:50:12.100 --> 00:50:15.540 넷 애플리케이션 등을 구축하는 것과 비슷합니다. 00:50:16.240 --> 00:50:22.800 코드, 관리, 프레임워크 관리, 보안관리 등 모든 것을 직접 관리하기 때문입니다. 00:50:26.790 --> 00:50:30.230 솔직히 말해서 애플리케이션 및 에이전트 수명주기 관리 측면에서는 00:50:30.230 --> 00:50:31.430 이전과 개념이 거의 같습니다. 00:50:39.050 --> 00:50:40.170 이는 제게 좋은 점인데 00:50:40.170 --> 00:50:43.790 수명주기 프로세스 등에 많은 투자를 할 필요가 없기 때문입니다. 00:50:43.790 --> 00:50:46.150 물론 몇 가지 변경사항이 있지만 00:50:46.150 --> 00:50:48.190 가장 큰 변화 중 하나는 00:50:48.190 --> 00:50:51.910 이제 LLM, 배포 등을 관리해야 한다는 것입니다. 00:50:53.370 --> 00:50:56.410 하지만 내부적으로는 과거 데봅스 접근 방식 00:50:56.410 --> 00:50:59.350 즉 파이프라인과 같은 방식과 유사합니다. 00:51:00.570 --> 00:51:01.410 제 생각에는 00:51:01.410 --> 00:51:06.170 에이전트 관리 방식이 이전과 크게 달라지지 않았습니다. 00:51:07.170 --> 00:51:09.130 맞춤 개발이든 기존 방식이든 00:51:09.130 --> 00:51:13.190 솔직히 말해서 지금도 이전과 같은 접근 방식을 사용합니다. 00:51:13.790 --> 00:51:14.670 그리고 00:51:14.670 --> 00:51:25.610 만약 어떤 회사가 이전에는 AI를 사용하지 않았지만 00:51:25.610 --> 00:51:29.710 디펜더 및 모든 도구에 대한 완벽한 환경 설정을 갖추고 있다면 00:51:29.710 --> 00:51:31.890 다음에 해야 할 일이 있을까요? 00:51:35.960 --> 00:51:38.700 아니면 AI 준비 상태를 의미하는 걸까요? 00:51:39.260 --> 00:51:44.120 아, 이건 정말 중요한 질문입니다. 00:51:45.240 --> 00:51:48.520 마이크로소프트의 AI 준비 상태는 괜찮습니다. 00:51:50.770 --> 00:51:53.710 수수료를 높이고 이런 것들을 관리하는 것이죠. 00:51:53.710 --> 00:51:59.110 하지만 제게 있어 준비 상태는 단순히 기술적인 접근 방식만을 의미하는 것이 아닙니다. 00:51:59.290 --> 00:52:02.630 기술적 인 측면에서는 우리가 무엇을 해야 하는지 알고 있습니다. 00:52:03.310 --> 00:52:06.090 여러 서비스에 걸쳐 권한을 관리해야 하죠. 00:52:07.090 --> 00:52:12.250 제게 있어 AI 준비 상태는 데이터, 즉 데이터 관리까지 포함해야 합니다. 00:52:12.750 --> 00:52:13.030 이해하시겠습니까? 00:52:13.030 --> 00:52:17.730 왜냐하면 앞서 말씀드렸듯이 데이터를 이해하지 못하면 00:52:17.730 --> 00:52:22.870 기술적 인 부분을 관리할 수 없기 때문입니다. 00:52:23.070 --> 00:52:28.370 예를 들어 무엇이 기밀이고 무엇이 아닌지 모르면 보안 조치를 마련하기 어렵습니다. 00:52:28.590 --> 00:52:32.850 하지만 마이크로소프트의 사례를 보면 AI 준비 상태는 괜찮습니다. 00:52:32.850 --> 00:52:45.610 권한 관리, 민감도 레이블 지정, GLP, 일반 데이터 보호 규정, 준수 등을 할 수 있습니다. 00:52:47.450 --> 00:52:50.310 하지만 더 높은 차원의 측면도 고려해야 합니다. 00:52:54.870 --> 00:53:01.750 제 생각에 AI 준비 상태는 기술적 인 측면뿐만 아니라 기능적, 고차원적인 측면도 포함합니다. 00:53:01.750 --> 00:53:05.550 솔직히 말해서 요즘은 그런 측면도 중요하게 생각해야 합니다. 00:53:05.550 --> 00:53:11.140 네, 정말 흥미로운 이야기네요. 00:53:13.220 --> 00:53:15.480 많은 기업들이 AI를 도입했지만 00:53:15.480 --> 00:53:20.100 이제는 에이전트 때문에 내 이메일이 전부 삭제됐어, 라거나 00:53:20.100 --> 00:53:26.500 악의적인 행동을 했다는 불만을 토로하는 경우가 많습니다. 00:53:27.380 --> 00:53:32.040 음, 기업들이 AI를 두려워한다고 말할 거라고 어떻게 생각하세요? 00:53:35.850 --> 00:53:36.910 좋은 질문입니다. 00:53:37.690 --> 00:53:39.270 저는 스위스에 살고 있는데 00:53:39.270 --> 00:53:42.110 스위스에는 많은 개인은행들이 있고 00:53:42.110 --> 00:53:45.950 솔직히 말해서 굉장히 민감한 고객들이 많습니다. 00:53:47.190 --> 00:53:47.550 그래서 00:53:47.550 --> 00:53:55.030 가장 중요한 건 데이터가 어디서 처리되는가? 라는 질문입니다. 00:53:56.450 --> 00:53:56.810 그리고 00:53:56.810 --> 00:54:01.590 AI 간의 이메일을 검색하는 건가? 00:54:02.050 --> 00:54:03.210 같은 질문도 있죠. 00:54:03.210 --> 00:54:06.270 그래서 그들은 항상 이런 질문을 합니다. 00:54:10.350 --> 00:54:12.530 하지만 그들에게 가장 중요한 건 00:54:12.530 --> 00:54:16.210 데이터가 어디서 처리되는지 알아야 한다는 것이고 00:54:16.210 --> 00:54:19.050 또 내가 AI 위 소유자인데 00:54:19.050 --> 00:54:20.890 라는 생각도 한다는 겁니다. 00:54:24.950 --> 00:54:27.350 그래서 저는 AI에게 지시를 내리고 00:54:27.350 --> 00:54:30.150 AI가 뒤에서 작업을 수행합니다. 00:54:31.770 --> 00:54:34.150 그런데 사람들은 자율적인 측면을 두려워합니다. 00:54:34.150 --> 00:54:38.270 왜냐하면 요즘에는 그런 작업이 가능하고 00:54:38.270 --> 00:54:41.110 AI는 뒤에서 무언가를 검색하고 00:54:41.110 --> 00:54:43.630 질의하고 처리하기 때문입니다. 00:54:44.350 --> 00:54:47.990 사람들은 제가 AI에게 무언가를 하도록 지시했을 때 00:54:47.990 --> 00:54:50.970 뒤에서 어떤 일이 일어나는지 궁금해합니다. 00:54:53.280 --> 00:54:54.980 네, 이런 질문이 많습니다. 00:54:55.340 --> 00:55:01.200 AI 에이전트나 AI 서비스의 전체 프로세스를 00:55:01.200 --> 00:55:03.040 어떻게 제어할 수 있을까요? 00:55:07.780 --> 00:55:09.360 네, 이런 질문들이 있지만 00:55:09.360 --> 00:55:12.240 이는 결국 도입과 교육의 문제입니다. 00:55:16.240 --> 00:55:17.500 AI를 이해하고 00:55:17.500 --> 00:55:20.180 뒤에서 정확히 어떤 일이 수행되는지 00:55:20.180 --> 00:55:22.160 이해하는 교육을 마련해야 합니다. 00:55:22.840 --> 00:55:25.320 그리고 투명성도 중요한 포인트입니다. 00:55:26.740 --> 00:55:28.220 모든 AI 솔루션에는 00:55:28.220 --> 00:55:30.500 투명성이 필수적이기 때문입니다. 00:55:32.900 --> 00:55:35.540 투명성은 저에게 매우 중요한 주제입니다. 00:55:37.060 --> 00:55:39.220 모든 것을 투명하게 만들어야 합니다. 00:55:39.220 --> 00:55:41.540 AI 솔루션은 투명해야 합니다. 00:55:42.060 --> 00:55:44.440 백그라운드에서 어떤 작업이 수행되는지 00:55:44.440 --> 00:55:46.460 어떤 데이터가 커리되는지 00:55:46.460 --> 00:55:49.080 모든 것을 추적하고 기록해야 합니다. 00:55:49.320 --> 00:55:51.000 따라서 오늘날의 솔루션에서는 00:55:51.000 --> 00:55:52.880 모든 것이 투명해야 합니다. 00:55:53.340 --> 00:55:55.860 백그라운드에서 어떤 작업이 수행되는지 00:55:55.860 --> 00:55:58.000 어떤 데이터가 처리되는지 00:55:58.000 --> 00:56:00.740 그리고 그 배경에 어떤 논리가 있는지 00:56:00.740 --> 00:56:02.760 정확히 이해해야 하기 때문입니다. 00:56:02.960 --> 00:56:03.500 좋습니다. 00:56:05.420 --> 00:56:07.000 어떤 사실들을 바탕으로 00:56:07.000 --> 00:56:08.680 이러한 계획을 세우셨나요? 00:56:09.220 --> 00:56:10.540 멋지네요. 00:56:10.860 --> 00:56:12.700 아, 시간이 조금 부족하네요. 00:56:13.940 --> 00:56:14.700 죄송합니다. 00:56:16.000 --> 00:56:17.600 정말 멋진 시간이었습니다. 00:56:17.780 --> 00:56:21.520 저는 모든 팟캐스트에서 속사포 질문 코너를 진행하고 있습니다. 00:56:21.800 --> 00:56:22.060 제가 00:56:22.060 --> 00:56:25.680 짧은 문장을 말씀드리면 00:56:25.680 --> 00:56:28.160 여러분은 짧게 답변해 주시면 됩니다. 00:56:28.660 --> 00:56:29.600 준비되셨나요? 00:56:30.260 --> 00:56:30.460 네. 00:56:30.680 --> 00:56:32.280 코파일럿 스튜디오를 사용하셨나요? 00:56:32.660 --> 00:56:34.560 아니면 사용자 정의 코드를 사용하셨나요? 00:56:34.740 --> 00:56:35.900 코파일럿 스튜디오 00:56:35.900 --> 00:56:39.380 마이크로소프트 파운드리 아니면 코파일럿 스튜디오 00:56:39.380 --> 00:56:41.280 코파일럿 스튜디오 00:56:41.280 --> 00:56:42.760 파이프 스튜디오를 사용하셨나요? 00:56:42.760 --> 00:56:46.200 아니면 사이페 스튜디오를 사용하셨나요? 00:56:46.200 --> 00:56:48.440 기터브 아니면 네이저 데봅스 00:56:48.440 --> 00:56:49.700 기터브 00:56:49.700 --> 00:56:52.260 렉 아니면 파인 튜닝 00:56:52.260 --> 00:56:54.620 좋습니다. 00:56:55.620 --> 00:57:00.520 가장 과소평가된 마이크로소프트 365 API는 무엇일까요? 00:57:04.460 --> 00:57:05.800 레그 레그 API 00:57:05.800 --> 00:57:12.480 2026년에 모든 마이크로소프트 개발자가 배워야 할 기술은 무엇일까요? 00:57:12.740 --> 00:57:16.940 기터브 코파일럿 00:57:16.940 --> 00:57:18.620 세타이어 니달리아가 와서 00:57:18.620 --> 00:57:23.300 우리 AI 플랫폼을 개선하는 데 필요한 모든 자금과 리소스를 제공하고 00:57:23.300 --> 00:57:25.840 기능 하나만 개발할 수 있게 해준다면 00:57:25.840 --> 00:57:27.440 무엇을 개발하시겠습니까? 00:57:27.620 --> 00:57:28.400 라고 묻는다면 00:57:28.400 --> 00:57:29.980 무엇을 개발하시겠습니까? 00:57:31.480 --> 00:57:34.620 필요한 모든 거버넌스 관련 기능들을 개발하고 00:57:34.620 --> 00:57:37.500 다음 팟캐스트에는 누구를 초대해서 00:57:37.500 --> 00:57:38.840 어떤 질문을 할까요? 00:57:48.090 --> 00:57:49.230 좋은 질문이네요. 00:57:49.530 --> 00:57:50.550 친구가 많지만 00:57:50.550 --> 00:57:59.280 예를 들어 클로 모로에게 질문해 볼 수 있습니다. 00:58:00.160 --> 00:58:02.620 그녀는 이전에는 기능 컨설턴트였지만 00:58:02.620 --> 00:58:05.080 지금은 기술 분야를 담당하고 있습니다. 00:58:05.520 --> 00:58:08.400 그리고 그녀는 동적 세계에서 기능적인 측면 00:58:08.400 --> 00:58:11.360 즉 기술적인 측면보다 더 중요한 부분에 대한 00:58:11.360 --> 00:58:13.380 정말 좋은 이야기를 가지고 있습니다. 00:58:13.680 --> 00:58:14.160 그러니 00:58:14.160 --> 00:58:16.200 그녀를 초대해서 00:58:16.200 --> 00:58:18.940 요즘 기능적인 업무와 기술적인 업무를 00:58:18.940 --> 00:58:20.960 어떻게 조화롭게 처리해야 할까요? 00:58:21.160 --> 00:58:22.280 라고 물어보는 건 어떨까요? 00:58:22.280 --> 00:58:25.560 그 부분에 있어서 정말 큰 어려움이 있잖아요. 00:58:26.860 --> 00:58:29.400 네, 그리고 제 마지막 질문은 이것입니다. 00:58:32.150 --> 00:58:35.110 이 세션에서 사람들이 한 가지를 얻어갈 수 있다면 00:58:35.110 --> 00:58:36.750 무엇을 얻어가야 할까요? 00:58:42.540 --> 00:58:45.500 기본적으로 AI는 빠르게 발전하고 있습니다. 00:58:45.500 --> 00:58:50.720 그리고 요즘 최신 정보를 얻으려면 00:58:50.720 --> 00:58:52.400 모든 것을 따라가야 합니다. 00:58:52.880 --> 00:58:56.140 왜냐하면 요즘 AI는 정말 마이크로소프트의 00:58:56.140 --> 00:58:58.260 모든 영역에 걸쳐 있기 때문입니다. 00:58:59.700 --> 00:59:02.440 그리고 요즘 여러분이 이해해야 할 것 중 하나는 00:59:02.440 --> 00:59:04.240 진화가 매우 빠르다는 것입니다. 00:59:07.900 --> 00:59:10.460 항상 최신 정보를 파악하고 있어야 합니다. 00:59:13.150 --> 00:59:16.470 그렇지 않으면 언젠가 중요한 것을 놓치게 될 것입니다. 00:59:16.790 --> 00:59:19.370 이러한 진화를 이해하고 배우지 않으면 안 됩니다. 00:59:19.370 --> 00:59:24.920 네, 네, 함께해 주셔서 감사합니다. 00:59:26.620 --> 00:59:28.680 이 대화에서 가장 중요한 점은 00:59:28.680 --> 00:59:31.620 마이크로소프트 C65 코파일럿 위 확장성이 00:59:31.620 --> 00:59:35.080 단순히 점점 더 정교한 프롬프트를 작성하는 것에 00:59:35.080 --> 00:59:36.580 그치지 않는다는 것입니다. 00:59:38.580 --> 00:59:41.080 코파일럿과 에이전트가 조직 지식, 00:59:41.500 --> 00:59:44.700 마이크로소프트 그래프 비즈니스 애플리케이션 등을 00:59:44.700 --> 00:59:48.160 연결할 수 있는 아키텍처로 나아가고 있다고 생각합니다. 00:59:48.160 --> 00:59:54.120 네, 코파트 스튜디오, 마이크로소프트 파운들이 00:59:54.120 --> 00:59:56.980 사용자 지정 개발 및 MCP와 같은 기술은 00:59:57.500 --> 00:59:59.980 개발자에게 놀랍고 강력한 도구를 제공합니다. 01:00:03.990 --> 01:00:04.990 네, 맞습니다. 01:00:07.490 --> 01:00:09.890 에이전트의 기능이 향상될수록 기본 요소들, 01:00:10.250 --> 01:00:13.650 즉 신원 확인, 권한 관리, 보안, 거버넌스, 01:00:14.070 --> 01:00:18.010 테스트, 관찰 가능성, 애플리케이션 수명 주기 관리 등이 01:00:18.010 --> 01:00:18.970 더욱 중요해집니다. 01:00:18.970 --> 01:00:24.590 네, 이 모든 주제에 대해 정말 좋은 개요를 제공해 주셨습니다. 01:00:25.030 --> 01:00:26.490 함께해 주셔서 감사합니다. 01:00:28.170 --> 01:00:32.030 청취자 여러분께서는 MC65 FM 팟캐스트 페이지의 01:00:32.030 --> 01:00:34.970 쇼노트에서 모든 정보를 확인하실 수 있으며, 01:00:35.530 --> 01:00:38.110 EES의 활동도 살펴보실 수 있습니다. 01:00:40.760 --> 01:00:42.200 함께해 주셔서 감사합니다. 01:00:42.600 --> 01:00:43.820 좋은 시간이었습니다.