WEBVTT 00:00:00.000 --> 00:00:06.240 마이크로소프트 365 코파일럿을 도입하는 것은 마치 전설적인 아이템을 얻은 기분이지만 사실 그건 시작에 불과하다는 것을 곧 깨닫게 됩니다. 00:00:06.420 --> 00:00:10.480 기본 상태에서는 모델의 기초 지식과 테넌트 내부의 콘텐츠를 기반으로 작동합니다. 00:00:10.680 --> 00:00:16.000 유용하긴 하지만 먼지가 쌓인 SOP, 인사 매뉴얼, 구석에 숨겨진 거대한 ERP 시스템은 어떻게 할까요? 00:00:16.160 --> 00:00:19.700 커넥터, 그라운딩, 사용자 지정 에이전트 없이는 코파일럿 이 그것들을 활용할 수 없습니다. 00:00:19.940 --> 00:00:22.000 다행인 점은 그것들을 학습시킬 수 있다는 것입니다. 00:00:22.000 --> 00:00:28.180 관건은 언제 코파일럿 스튜디오를 사용하고 언제 팀즈 툴키드로 전환할지 그리고 거버넌스, 모니터링, 나이선싱을 어떻게 운영할지 아는 것입니다. 00:00:28.360 --> 00:00:29.700 진짜 반전은 이제부터입니다. 00:00:29.920 --> 00:00:32.440 첫 번째 에이전트를 구축하는 것이 최종 보스전은 아닙니다. 00:00:32.600 --> 00:00:34.080 그저 튜토리얼이 끝난 것 뿐입니다. 00:00:34.300 --> 00:00:35.900 빌드 자체가 보스전은 아닙니다. 00:00:36.100 --> 00:00:41.040 첫 에이전트를 테스트하고 프롬프트가 작동하며 데모 데이터가 깔끔해 보이면 잠시 게임을 클리어했다는 기분이 듭니다. 00:00:41.180 --> 00:00:42.140 그게 바로 함정입니다. 00:00:42.420 --> 00:00:46.560 진짜 작업은 그 빌드를 프로덕션 환경에 적용할 때 시작되며 그곳은 완전히 다른 규칙으로 돌아갑니다. 00:00:46.560 --> 00:00:50.080 너무 많은 제작자가 테스트해서 깔끔한 답변이 나오면 임무 환수라고 착각합니다. 00:00:50.260 --> 00:00:52.740 사실 그건 쉬움 난이도의 스토리 모드일 뿐입니다. 00:00:52.940 --> 00:00:57.380 프로덕션 환경은 여러분의 개발 노트북에서 개념 증명이 잘 작동했는지 따지지 않습니다. 00:00:57.580 --> 00:01:04.380 프로덕션이 요구하는 것은 스트레스 상황에서의 안정성이며 컴플라이언스 검사, 아이디 가드레일, 가동시간 표준이 늘 뒤따릅니다. 00:01:04.600 --> 00:01:07.020 이제 여기서 첫 번째 보스 몬스터들이 등장합니다. 00:01:07.260 --> 00:01:10.940 확장성, 에이전트가 엔터프라이즈 부하를 문제없이 처리할 수 있을까요? 00:01:11.120 --> 00:01:14.720 거기서 코파일럿 제어 시스템의 모니터링 및 진단 로그가 중요해집니다. 00:01:14.720 --> 00:01:20.300 오래된 그라운딩, 시어포인트나 데이터버스 위 데이터가 변경될 때 에이전트가 올바른 스냅샷을 계속 유지할까요? 00:01:20.400 --> 00:01:22.880 커넥터와 그래프 그라운딩이 그 안전장치입니다. 00:01:23.080 --> 00:01:25.040 컴플라이언스와 감사 가능성입니다. 00:01:25.240 --> 00:01:31.920 규제기관이나 내부 감사자가 확인을 요청할 때 완벽한 로그와 민감도 레이블을 갖춘 에이전트 기록을 검토할 수 있을까요? 00:01:32.120 --> 00:01:35.440 이 중 하나라도 실패하면 승리의 화면은 순식간에 사라집니다. 00:01:35.620 --> 00:01:40.540 코파일럿 스튜디오에서 테스트를 실행하는 것은 무한 체력 포션이 있는 훈련장에서 대련하는 것과 같습니다. 00:01:40.540 --> 00:01:50.420 주문을 외우고 프롬프트를 바꿔도 모든 게 화려해 보이지만 실제 사용 시에는 방화벽 차단으로 주문이 실패하고 외부 데이터 소스 과부하로 응답이 거북이 걸음이 됩니다. 00:01:50.640 --> 00:01:54.560 바로 그 순간 사용자는 이를 스마트하다고 부르는 대신 티켓을 발행하기 시작합니다. 00:01:54.780 --> 00:01:57.920 가장 흔한 실패 사례는 거버넌스를 미루는 팀들에서 나옵니다. 00:01:58.120 --> 00:02:03.260 나중에 챙기면 된다고 생각하지만 거버넌스를 미루는 것은 거의 항상 불쾌한 놀라움으로 돌아옵니다. 00:02:03.420 --> 00:02:08.040 확장성 문제, 데이터 불일치, 컴플라이언스 공백은 꼭 필요한 순간에 나타납니다. 00:02:08.040 --> 00:02:10.940 보안과 컴플라이언스는 선택적인 사이드 퀘스트가 아닙니다. 00:02:11.060 --> 00:02:12.640 캠페인 맵의 필수적인 부분입니다. 00:02:12.820 --> 00:02:14.440 이제 아키텍처에 대해 이야기해봅시다. 00:02:14.600 --> 00:02:16.660 코파일럿 위 두뇌는 단일 블록이 아니기 때문입니다. 00:02:16.820 --> 00:02:22.100 기반 모델인 원시 언어 엔진이 있고, 그 위에는 어떤 함수가 언제 호출될지 정렬하는 오케스트레이터가 있습니다. 00:02:22.360 --> 00:02:27.440 마이크로소프트 365 코파일럿은 기본적으로 이러한 오케스트레이션을 제공함으로 모든 요청에 구조가 갖춰집니다. 00:02:27.600 --> 00:02:31.940 다음은 적지, 그라운딩인데, 이는 답변이 조작되지 않도록 엔터프라이즈 콘텐츠와 연결하는 역할을 합니다. 00:02:31.940 --> 00:02:36.220 마지막으로 실제 작업을 수행하는 맞춤형 플러그인 이나 커넥터인 기술, 스킬즈, 이 있습니다. 00:02:36.520 --> 00:02:40.160 이 4가지 요소를 분리된 사일로로 취급하면 전체 타워가 흔들리게 됩니다. 00:02:40.380 --> 00:02:43.420 적지가 없는 견고한 기술은 그저 화려한 환각에 불과합니다. 00:02:43.660 --> 00:02:45.960 규정 준수 제어가 없는 기반은 부채가 됩니다. 00:02:46.280 --> 00:02:49.520 이 계층들이 하나의 스택으로 처리될 때만 에이전트는 견고하게 유지됩니다. 00:02:49.720 --> 00:02:51.960 그렇다면 실제 환경에서의 성공이란 어떤 모습일까요? 00:02:52.120 --> 00:02:54.060 데모 프롬프트에 깔끔하게 답하는 것과는 다릅니다. 00:02:54.260 --> 00:02:55.540 그건 연습 모드일 뿐입니다. 00:02:55.540 --> 00:03:02.660 성공의 증표는 급여 처리 중, 데이터 마이그레이션 진행 중, 규정 준수 담당자의 감시 하에 높은 요청 부하를 견뎌내는 것입니다. 00:03:02.840 --> 00:03:05.540 그때 비로소 에이전트가 실행될 자격이 있음을 입증하는 것입니다. 00:03:05.700 --> 00:03:07.780 그리고 많은 빌드가 실패하는 또 다른 이유가 있습니다. 00:03:08.040 --> 00:03:11.060 조직들이 이를 운영체제가 아닌 일회성 프로젝트로 생각하기 때문입니다. 00:03:11.240 --> 00:03:15.020 누군가 프로토타입을 만들고 화려한 데모를 선보인 후 모니터링 없이 방치합니다. 00:03:15.220 --> 00:03:19.960 곧 여러 부서가 각자의 것을 만들지만 문서화는 안 되어 있고 모두가 제어 없이 토큰만 소모하게 됩니다. 00:03:19.960 --> 00:03:28.040 간단한 운영 매뉴얼 없이는 커넥터 소유자, 접지 감사자, 크레딧 사용량 확인자가 누구인지 알 수 없어 상황이 엉망진창이 됩니다. 00:03:28.280 --> 00:03:30.240 관점을 바꾸면 훨씬 쉬워집니다. 00:03:30.420 --> 00:03:32.860 운영 마인드 셋으로 시작하면 설계가 바뀝니다. 00:03:33.040 --> 00:03:35.660 첫 번째 테스트가 깔끔했는지 애만 신경 쓰지 않게 됩니다. 00:03:35.920 --> 00:03:38.160 일상적인 캠페인을 위해 시스템을 강화하게 됩니다. 00:03:38.380 --> 00:03:43.160 감사 로그, 관리자 게이트, 백업, 상태 확인은 압박 속에서도 신뢰를 구축하고 시스템을 유지합니다. 00:03:43.160 --> 00:03:50.020 관리자는 이미 마이크로소프트 365 관리센터에서 사용 가능한 제어 기능을 통해 시나리오를 관리하고 진단 피드백을 조기에 확인할 수 있습니다. 00:03:50.200 --> 00:03:54.140 이러한 도구에 의존하는 것이 일회성 에이전트와 신뢰할 수 있는 운영자를 구분지는 기준입니다. 00:03:54.300 --> 00:03:56.880 그렇기에 에이전트를 빌드했다고 해서 승자가 되는 것은 아닙니다. 00:03:57.060 --> 00:03:58.880 테스트 환경은 1단계에 불과합니다. 00:03:59.120 --> 00:04:03.180 거버넌스와 모니터링이 갖춰진 실제 배포가 진정한 생존의 시작입니다. 00:04:03.420 --> 00:04:07.320 그 길로 너무 깊이 들어가기 전에 싸움에 필요한 올바른 무기가 있어야 합니다. 00:04:07.740 --> 00:04:10.780 마이크로소프트는 서로 다른 규칙을 가진 두 가지 키트를 제공합니다. 00:04:10.780 --> 00:04:14.180 잘못 선택하면 레이드의 플라스틱 검을 들고 가는 기분이 될 것입니다. 00:04:14.340 --> 00:04:17.580 코파일럿 스튜디오와 팀즈 툴킷 중에서 무기를 선택해야 합니다. 00:04:17.800 --> 00:04:19.420 거기서 진짜 질문이 시작됩니다. 00:04:19.680 --> 00:04:21.180 어떤 도구를 선택하시겠습니까? 00:04:21.320 --> 00:04:22.260 코파일럿 스튜디오일까요? 00:04:22.560 --> 00:04:25.840 아니면 마이크로소프트 365 에이전트 툴킷이라고도 불리는 팀즈 툴킷일까요? 00:04:26.020 --> 00:04:30.420 둘 다 코파일럿을 확장한다고 해서 비슷해 보이지만 서로 다른 유형의 개발자와 요구사항을 대상으로 합니다. 00:04:30.640 --> 00:04:34.920 잘못된 선택은 시간과 예산을 낭비하게 만들며 실전에서 데모가 제대로 작동하지 않을 경우 신뢰도 마저 잃을 수 있습니다. 00:04:34.920 --> 00:04:37.240 코파일럿 스튜디오는 제작자를 위한 공간입니다. 00:04:37.420 --> 00:04:40.260 속도와 명확성을 위해 설계된 로우 코드 시각적 빌더입니다. 00:04:40.460 --> 00:04:44.380 드래그 앤 드롭 방식의 흐름, 템플릿, 안내형 대화, 내장된 분석 기능을 제공합니다. 00:04:44.620 --> 00:04:55.280 스튜디오에는 마이크로소프트 365 데이터 소스에 연결하는 다양한 커넥터가 포함되어 있어 파워 유저는 코드를 한 줄도 작성하지 않고 시어포인트 콘텐츠를 가져오거나 팀즈 메시지를 모니터링하거나 인사 정책 문서를 제공할 수 있습니다. 00:04:55.280 --> 00:05:02.900 마이크로소프트 365 코파일럿에 직접 테스트하고 수정하여 개시하거나 최소한의 단계로 독립형 에이전트로 출시할 수도 있습니다. 00:05:03.120 --> 00:05:08.860 내년 회계 연도가 아닌 이번 분기에 작동하는 워크플로우가 필요한 부서에게 스튜디오는 가장 빠른 길입니다. 00:05:09.080 --> 00:05:16.900 이미 16만 개 이상의 고객사가 재무 데이터 조정, 직원 온 보딩, 소매업 제품 문외응대 등 바로 이 목적으로 스튜디오를 사용하고 있습니다. 00:05:17.160 --> 00:05:18.600 그 이유는 복잡하지 않습니다. 00:05:18.820 --> 00:05:20.420 진입장벽을 낮춰주기 때문입니다. 00:05:20.420 --> 00:05:26.260 팀이 이미 파워 앱스를 다루거나 파워 오토메이트로 일상적인 보고서를 자동화하고 있다면 스튜디오는 아주 익숙한 환경이 될 것입니다. 00:05:26.420 --> 00:05:32.140 소프트웨어 엔지니어가 아니어도 명확한 목표와 기본적인 로우코드 능력만 있다면 클릭과 구성, 배포가 가능합니다. 00:05:32.320 --> 00:05:34.060 이제 팀즈 툴키드로 넘어가 보겠습니다. 00:05:34.380 --> 00:05:36.740 이곳은 풀스택 개발자가 역량을 발휘하는 곳입니다. 00:05:36.940 --> 00:05:39.800 툴키드는 드래그 앤 드롭 캔버스가 아닌 데코드에 통합됩니다. 00:05:39.800 --> 00:05:48.720 여기서는 구조화된 규칙을 가진 선언적 에이전트를 설계하거나 한 걸음 더 나아가 오케스트레이션 모델 호출과 API 처리를 처음부터 직접 정의하는 커스텀 엔진 에이전트를 만들 수 있습니다. 00:05:48.920 --> 00:05:57.300 코파일럿 내부뿐만 아니라 팀즈, 마이크로소프트 365 앱, 웹, 외부 채널 전반에 걸쳐 스케폴딩, 디버깅, 구성, 개시 경로를 확보할 수 있습니다. 00:05:57.500 --> 00:06:02.880 코파일럿 스튜디오가 카탈로그에서 고른 조립식 가구라면 툴키드는 직접 한 자를 자르고 배선을 설계하여 집을 지는 것과 같습니다. 00:06:03.160 --> 00:06:06.700 자유도는 엄청나지만 그만큼 모든 못 하나와 퓨즈 하나까지 직접 책임져야 합니다. 00:06:06.700 --> 00:06:09.780 진정한 혼란은 둘 다 코파일럿을 확장한다고 말한다는 점입니다. 00:06:09.940 --> 00:06:17.220 실제로 스튜디오는 마이크로소프트가 정의한 가드레일, 안전한 커넥터, 관리자 제어 및 가벼운 거버넌스 범위 내에서 확장하는 것을 의미합니다. 00:06:17.400 --> 00:06:25.500 툴키드는 가드레일을 다시 작성하고 직접 오케스트레이션을 구현하고 외부 LLM을 호출하거나 마이크로소프트가 기본적으로 제공하지 않는 에이전트 동작을 구축하는 것을 의미합니다. 00:06:25.680 --> 00:06:30.480 하나는 템플릿으로 안전함을 보장하고 다른 하나는 강력한 권한을 부여하며 이를 책임감 있게 다룰 것을 요구합니다. 00:06:30.680 --> 00:06:33.440 많은 사람이 도구 선택이 UI 위 차이로 이어진다고 생각합니다. 00:06:33.440 --> 00:06:38.580 아닙니다. 최종 사용자는 에이전트를 스튜디오로 만들었든 툴키드로 만들었든 동일한 프롬프트 창과 답변 카드를 보게 됩니다. 00:06:38.760 --> 00:06:43.380 이는 의도된 것으로 UX계층은 통일되어 있습니다. 실제로 바뀌는 것은 보이지 않는 뒷단입니다. 00:06:43.600 --> 00:06:46.480 그라운딩 옵션, 확장성, 그리고 관리 제어 방식입니다. 00:06:46.680 --> 00:06:49.140 그렇기 때문에 이 결정은 거칠애가 아닌 운영상의 문제입니다. 00:06:49.320 --> 00:06:51.000 실질적인 규칙을 하나 알려드리겠습니다. 00:06:51.300 --> 00:06:58.060 셰어포인트 콘텐츠, 팀제 채팅 및 회의, 내장 파일, 데이터버스 데이터, 이메일 및 인물 검색 커넥터와 같은 일부 접지, 그라운딩. 00:06:58.060 --> 00:07:04.140 기능은 테넌트에서 마이크로소프트 365 코파일럿 라이선스를 보유하거나 코파일럿 스튜디오 미터링이 활성화된 경우에만 작동합니다. 00:07:04.300 --> 00:07:07.780 해당 권한이 없다면 스튜디오를 선택해도 그런 기능을 사용할 수 없습니다. 00:07:08.060 --> 00:07:11.520 이 라이선스 확인 여부 하나가 어떤 경로를 선택할지 결정하는 핵심 요소가 될 수 있습니다. 00:07:11.740 --> 00:07:13.600 그렇다면 어떻게 선택을 단순화할 수 있을까요? 00:07:13.780 --> 00:07:15.180 간단한 체크리스트를 만들어보세요. 00:07:15.440 --> 00:07:20.080 첫째, IT 부서에 위존하지 않고 파워 유저가 직접 구축할 수 있는 빠르고 감사 가능하며 관리자가 제어하는 에이전트가 필요하신가요? 00:07:20.240 --> 00:07:21.860 그렇다면 코파일럿 스튜디오를 선택하세요. 00:07:21.860 --> 00:07:26.940 둘째, 사용자 지정 오케스트레이션, 외부 AI 모델 또는 기업의 핵심 시스템과 직결되는 신층적 인통합 작업이 필요하신가요? 00:07:27.100 --> 00:07:28.700 그렇다면 에이전트 툴킷을 선택하세요. 00:07:28.900 --> 00:07:32.000 셋째, 이름에 현혹되지 말고 팀의 실제 기술 역량과 목표를 믿으세요. 00:07:32.180 --> 00:07:33.700 저는 주택건설에 비유하곤 합니다. 00:07:33.940 --> 00:07:38.080 스튜디오는 조립식 주택과 같아서 색상과 캐비닛은 직접 고르지만 배관과 배선은 이미 안전하게 갖춰져 있습니다. 00:07:38.280 --> 00:07:43.120 툴킷은 빈 땅과 같아서 모든 것을 직접 설계해야 하지만 설계가 잘못될 경우 발생하는 모든 위험도 직접 감수해야 합니다. 00:07:43.280 --> 00:07:44.880 둘 다 멋진 집을 완성할 수 있습니다. 00:07:44.880 --> 00:07:48.660 하나는 더 빠르고 덜 복잡하며 다른 하나는 한계가 없지만 제대로 관리하지 않으면 취약할 수 있습니다. 00:07:48.820 --> 00:07:50.720 둘 다 접지, 그라운딩 없이는 무너집니다. 00:07:50.860 --> 00:07:54.940 어떤 도구를 선택하든 구축은 가능하지만 올바른 데이터를 입력하지 않으면 자신있게 헛소리만 더 빨리 생성할 뿐입니다. 00:07:55.080 --> 00:07:57.300 커넥터가 없는 스튜디오 에이전트는 앵무새일 뿐입니다. 00:07:57.480 --> 00:08:00.280 접지되지 않은 툴킷 에이전트는 코드로 작성된 앵무새일 뿐입니다. 00:08:00.480 --> 00:08:03.860 어느 쪽이든 사용자에게 추측성 답변만 늘어놓는 새와 함께하는 셈입니다. 00:08:03.860 --> 00:08:10.760 이것이 바로 모든 에이전트의 생명줄, 즉 에이전트가 불안전한 정보로 점쟁이 노릇을 하지 않도록 붙잡아주는 데이터 연결의 중요성입니다. 00:08:10.900 --> 00:08:14.080 에이전트를 접지하고 공허함이 아닌 지식으로 두뇌를 채워야 합니다. 00:08:14.280 --> 00:08:18.240 접지는 에이전트가 가짜 지혜를 멈추고 실제 지식을 활용하기 시작하는 지점입니다. 00:08:18.440 --> 00:08:22.600 올바른 소스를 제공하면 에이전트는 허풍에서 벗어나 검증 가능한 답변을 내놓기 시작합니다. 00:08:22.800 --> 00:08:28.380 이를 생략하면 겉으로는 완벽해 보이던 답변도 도대체 그 답이 어디서 나온 거죠? 라는 질문 하나에 금방 무너지고 맙니다. 00:08:28.380 --> 00:08:32.800 마이크로소프트 365코파일럿은 이미 마이크로소프트 그래프를 통해 볼 수 있는 데이터를 기반으로 작동합니다. 00:08:32.940 --> 00:08:35.780 파일, 채팅, 회의, 심지어 일정 이벤트까지 포함됩니다. 00:08:35.960 --> 00:08:39.800 그것은 좋은 시작이지만 가장 가치 있는 콘텐츠는 그 핵심 범위를 넘어선 곳에 있습니다. 00:08:40.080 --> 00:08:48.320 ERP는 재고를 CRM은 고객 수명 주기를 관리하며 HR은 셰어포인트 깊숙한 곳의 플레이북을 법무팀은 보안 폴더에 정책 문서를 보관합니다. 00:08:48.520 --> 00:08:55.120 이러한 소스에 에이전트를 접지하지 않으면 검증 가능한 정보 대신 일반 모델의 지식만으로 자신있게 추측할 것입니다. 00:08:55.120 --> 00:08:59.100 이들을 연결하는 것은 단순한 드래그 앤 드롭이 아니라 세심한 배관 공사와 같습니다. 00:08:59.380 --> 00:09:08.220 코파일럿 스튜디오와 마이크로소프트 그래프 커넥터를 사용하면 셰어포인트 위 저장된 문서, 데이터버스 위 구조화된 테이블, 익스체인지 위 메일 기록, 팀즈 위 채팅 내용까지 접근할 수 있습니다. 00:09:08.420 --> 00:09:14.080 마이크로소프트 위 핵심 서비스를 넘어 파워 플랫폼을 통한 1200개 이상의 커넥터가 외부 시스템으로 연결되는 통로를 열어줍니다. 00:09:14.260 --> 00:09:16.900 재무, 인사, 티켓팅 등 무엇이든 가능합니다. 00:09:16.900 --> 00:09:22.060 기성 제품이 맞지 않는다면 미리 구축된 커넥터가 없는 업무용 앱도 api를 통해 연결할 수 있습니다. 00:09:22.280 --> 00:09:26.500 올바르게 구축된 에이전트는 해당 저장소에서 최신 정보를 가져와 문맥과 함께 제시합니다. 00:09:26.720 --> 00:09:29.160 마법처럼 보이는 것은 그저 잘 설계된 파이프라인 덕분입니다. 00:09:29.320 --> 00:09:30.500 한 가지 주의할 점이 있습니다. 00:09:30.720 --> 00:09:33.540 일부 그라운딩, 그라운딩 옵션을 기본적으로 무료로 제공되지 않습니다. 00:09:33.700 --> 00:09:40.560 셰어포인트 콘텐츠, 팀즈 미팅, 이메일, 데이터버스와 같은 소스에 접근하려면 종종 테넌트에서 코파일럿 나이선스 나미터링 활성화가 필요합니다. 00:09:40.560 --> 00:09:46.200 이 권한이 없으면 커넥터가 작동하지 않으며 AI 비서가 가장 중요한 데이터 중 일부를 인식하지 못하게 됩니다. 00:09:46.380 --> 00:09:48.980 단순한 스위치 조작만으로 모든 것이 해결될 것이라 생각하지 마십시오. 00:09:49.100 --> 00:09:50.480 먼저 라이선스 맵을 확인하세요. 00:09:50.660 --> 00:09:52.660 인사, HR, 헬프 데스크 예시를 생각해봅시다. 00:09:52.800 --> 00:09:55.500 누군가가 육아 휴직 정책이 무엇인가요? 라고 묻습니다. 00:09:55.740 --> 00:09:59.500 그라운딩이 없으면 에이전트는 일반적인 모델 지식을 바탕으로 그럴듯한 답변을 조립합니다. 00:09:59.640 --> 00:10:02.160 도움이 되는 것처럼 들리지만 출처 링크나 증거가 없습니다. 00:10:02.160 --> 00:10:08.260 그라운딩이 적용되면 에이전트는 시어포인트에서 실제 정책을 찾아 문서 제목을 참조하고 핸드북으로 연결되는 인용 링크를 제공할 수 있습니다. 00:10:08.440 --> 00:10:13.160 이런 작은 차이가 검증되지 않은 진술을 감사관과 인사팀이 승인할 수 있는 신뢰할 만한 답변으로 바꿉니다. 00:10:13.320 --> 00:10:15.800 이러한 감사추적이야말로 진정한 성능 형상 요소입니다. 00:10:15.980 --> 00:10:19.860 그라운딩된 답변에는 사용자와 규제기관을 원본소스로 안내하는 인용구가 포함될 수 있습니다. 00:10:20.060 --> 00:10:23.520 컴플라이언스 팀에서 보시 왜 그런 답변을 했는지 물을 때 길게 설명할 필요가 없습니다. 00:10:23.780 --> 00:10:25.020 로그가 그 과정을 보여줍니다. 00:10:25.260 --> 00:10:26.240 여기에 프롬프트가 있습니다. 00:10:26.240 --> 00:10:27.700 여기에 가져온 문서가 있습니다. 00:10:28.000 --> 00:10:29.300 여기에 생성된 답변이 있습니다. 00:10:29.540 --> 00:10:32.640 운에 맡길 필요는 없지만 모든 연결은 곧 위험요소이기도 합니다. 00:10:32.800 --> 00:10:37.680 인사 데이터에 허술하게 연결하면 공개된 FAQ와 함께 비공개 직원 기록이 노출될 수 있습니다. 00:10:37.920 --> 00:10:41.920 ERP 접근 권한을 잘못 설정하면 어느 순간 영업사원이 급여 정보를 보게 될 수도 있습니다. 00:10:42.160 --> 00:10:44.480 이러한 실수들은 운영상 치명적인 오류입니다. 00:10:44.700 --> 00:10:49.240 더 안전한 방법은 그라운딩 계획에 민감도 레이블과 퍼뷰 분류 체계를 계층화하는 것입니다. 00:10:49.460 --> 00:10:55.380 그렇게 하면 에이전트는 데이터 분류를 무시하는 대신 권한 규칙에 맞는 콘텐츠만 검색하여 데이터 보완을 준수하게 됩니다. 00:10:55.380 --> 00:10:56.740 경고는 간단합니다. 00:10:56.940 --> 00:11:02.040 그라운딩 되지 않은 에이전트는 권위있게 거짓을 만들어내고 잘못 그라운딩된 에이전트는 외부로 유출되어서는 안 될 정보를 노출합니다. 00:11:02.220 --> 00:11:06.260 어느 쪽이든 회사에 로고를 걸고 오류를 퍼뜨리거나 민감한 세부 정보를 유출하는 결과를 낳게 됩니다. 00:11:06.440 --> 00:11:08.980 퍼뷰와 같은 거버넌스 도구가 존재하는 데에는 이유가 있습니다. 00:11:09.240 --> 00:11:11.680 데이터 커넥터와 분류 체계를 첫날부터 함께 구성하세요. 00:11:11.920 --> 00:11:15.240 그렇지 않으면 나중에 인식 문제와 컴플라이언스 문제로 골머리를 앓게 될 것입니다. 00:11:15.440 --> 00:11:16.660 그러니 교훈은 분명합니다. 00:11:16.880 --> 00:11:19.220 그라운딩, 그라운딩은 고급 부가 기능이 아닙니다. 00:11:25.380 --> 00:11:27.400 이를 뒷받침하는 로그로 근거를 확보할 수 있습니다. 00:11:27.540 --> 00:11:31.960 잘못 수행하면 티켓을 생성하기도 전에 조직 전반의 환각현상과 데이터 유출이 확산될 수 있습니다. 00:11:32.180 --> 00:11:34.120 그렇기에 다음 과제 또한 매우 중요합니다. 00:11:34.320 --> 00:11:36.600 그라운딩된 에이전트 하나는 관리할 수 있기 때문입니다. 00:11:36.760 --> 00:11:39.740 감독 없이 수십 개의 에이전트가 방치되면 진짜 문제가 시작됩니다. 00:11:39.940 --> 00:11:43.100 거버넌스는 에이전트가 통제불능 상태가 되기 전에 확산을 막는 것입니다. 00:11:43.320 --> 00:11:48.040 여기서 거버넌스란 코파일럿 에이전트가 무질서하게 변하는 것을 방지하는 규칙 세트입니다. 00:11:48.040 --> 00:11:53.520 누가 에이전트를 만들 수 있는지, 어디서 실행되는지, 어떤 데이터에 접근할 수 있는지를 우연에 맡기지 않고 결정하는 방법입니다. 00:11:53.820 --> 00:11:56.440 마이크로소프트는 이미 이를 강제할 도구를 제공하고 있습니다. 00:11:56.700 --> 00:12:08.080 마이크로소프트 365관리센터의 코파일럿 제어 시스템, 파워 플랫폼 관리센터의 수명주기 관리, 민감도 레이블링 및 DLP를 위한 마이크로소프트 퍼뷰, 그리고 감사를 위한 코파일럿 진단 로그가 있습니다. 00:12:08.400 --> 00:12:12.020 이들을 모래성이 무너지지 않게 지탱하는 4개의 기둥이라고 생각하십시오. 00:12:12.020 --> 00:12:17.360 먼저 알아두어야 할 점은 코파일럿 시나리오 관리는 관리자 권한이 있다고 누구나 할 수 있는 일이 아니라는 것입니다. 00:12:17.540 --> 00:12:20.740 전역관리자나 AI 관리자와 같은 특정 역할이 필요합니다. 00:12:20.940 --> 00:12:25.460 최소 권한 원칙을 준수하여 본인도 모르는 사이에 큰 위험을 초래할 수 있는 권한을 함부로 부여하지 마십시오. 00:12:25.600 --> 00:12:28.660 누가 스위치를 조작할 수 있는지 제안하는 것 자체가 하나의 거버넌스입니다. 00:12:28.860 --> 00:12:32.240 그 다음, 사후 조치가 아닌 설계 단계부터 수명주기 규칙을 적용하십시오. 00:12:32.360 --> 00:12:37.720 첫 번째 규칙, 누가 에이전트를 생성할 수 있는지 정의하고 이를 파워 플랫폼 관리센터의 환경과 연결하십시오. 00:12:37.720 --> 00:12:44.640 두 번째 규칙, 365관리센터의 코파일럿 설정을 사용하여 누가 에이전트를 개시하고 릴리스를 승인하거나 차단할 수 있는지 정의하십시오. 00:12:44.760 --> 00:12:50.640 세 번째 규칙, 에이전트가 실행될 수 있는 위치를 격리된 환경으로 할당하여 프로덕션 환경이 무방비로 노출되지 않게 하십시오. 00:12:50.760 --> 00:12:53.360 네 번째 규칙, 크레딧 할당 방법을 정의하십시오. 00:12:53.500 --> 00:12:56.000 이때 코파일럿 에이전트 사용량 측정기가 필요합니다. 00:12:56.200 --> 00:13:00.720 이 측정기는 리소스가 너무 빨리 소진될 때 그 수치를 명확히 보여주고 누가 이를 사용하는지 알려줍니다. 00:13:00.720 --> 00:13:06.020 퍼뷰는 문서와 메일 관리에 이미 사용 중인 규정 준수망이며 여기에서도 동일하게 작동합니다. 00:13:06.200 --> 00:13:11.580 데이터의 민감도 레이블을 적용하면 에이전트가 소스에 연결되더라도 레이블이 응답까지 따라갑니다. 00:13:11.760 --> 00:13:16.680 DLP 정책을 사용하여 에이전트가 응답 과정에서 기밀 필드를 노출하지 못하도록 차단하십시오. 00:13:16.820 --> 00:13:22.900 보존 정책은 오래된 콘텐츠가 남지 않게 하여 에이전트가 몇 주 전에 만료되어 넣어야 할 데이터에 근거하지 않도록 합니다. 00:13:23.120 --> 00:13:27.180 일단 안전장치를 설정하면 모든 에이전트가 자동으로 관리 체계를 상속받습니다. 00:13:27.180 --> 00:13:30.640 대부분의 팀이 간과하는 또 다른 단계는 진단 로그 활성화입니다. 00:13:30.820 --> 00:13:34.080 스위치를 켜면 모든 상호작용을 명확하게 파악할 수 있습니다. 00:13:34.300 --> 00:13:39.500 프론프트, 응답, 콘텐츠 참조, 시스템 로그는 모두 나중에 사용할 수 있는 기록으로 남습니다. 00:13:39.720 --> 00:13:44.420 관리자가 에이전트가 잘못된 지침을 내린 이유를 물으면 어깨를 으쓱하는 대신 기록을 다시 재생해볼 수 있습니다. 00:13:44.620 --> 00:13:49.200 더 좋은 점은 최종 사용자가 직접 피드백을 보내지 않아도 관리자가 대신 로그를 제출할 수 있다는 것입니다. 00:13:49.380 --> 00:13:51.960 그 덕분에 문제 해결이 사후 대응이 아닌 선제적 조치가 됩니다. 00:13:52.220 --> 00:13:54.960 이는 혁신을 늦추려는 것이 아니라 혁신의 방향을 잡기 위한 것입니다. 00:13:54.960 --> 00:13:57.900 스튜디오를 사용하면 파워 유저가 오후까지 쉽게 플로우를 만들 수 있고, 00:13:58.320 --> 00:14:01.660 툴킷을 사용하면 개발자가 무거운 빌드를 프로덕션 환경으로 빠르게 배포할 수 있습니다. 00:14:01.820 --> 00:14:04.760 제어 장치가 없으면 그런 속도는 중복과 모순을 야기합니다. 00:14:04.960 --> 00:14:09.840 거버넌스가 갖춰지면 같은 속도로도 규정을 준수하고 모니터링되는 재사용 가능한 자산을 확보할 수 있습니다. 00:14:10.040 --> 00:14:14.880 차이는 직원의 창의성이 아니라 직원을 둘러싼 프레임워크가 얼마나 체계적 인지에 달려있습니다. 00:14:15.060 --> 00:14:17.100 비용 추적 또한 거버넌스의 일부입니다. 00:14:17.320 --> 00:14:21.080 관리센터의 소비 측정기는 단순한 회계보기가 아니라 균형을 맞추는 다이얼입니다. 00:14:21.080 --> 00:14:26.440 크레딧팩을 할당하고, 종량제 모델로 초과 사용량을 모니터링하며, 예산 범위 내에서 사용량을 유지할 수 있습니다. 00:14:26.600 --> 00:14:31.340 이를 무시하면 크레딧이 소진되어 에이전트가 워크플로우 도중 갑자기 멈출 때 제한사항을 처음으로 실감하게 될 것입니다. 00:14:31.520 --> 00:14:34.260 연료가 바닥난 상태에서 프로덕션 문제를 디버깅하고 싶지는 않을 것입니다. 00:14:34.440 --> 00:14:37.100 거버넌스가 성공적으로 작동하면 마치 갑옷을 입은 것과 같습니다. 00:14:37.380 --> 00:14:42.220 빌더들이 빠르게 움직일 수 있을 만큼 유연하면서도, 한 번이 실수로 전체 팀이 무너지지 않도록 보호해줍니다. 00:14:42.400 --> 00:14:45.180 관리를 소홀히 하여 승인 없이 에이전트가 생성되도록 방치하면, 00:14:51.080 --> 00:14:55.880 그리고 생존은 던전의 숨겨진 다음 함정으로 이어집니다. 00:14:56.000 --> 00:15:00.260 거버넌스를 통제하더라도 다음 놀라운 일은 기술적인 문제가 아니라 재정적인 문제이기 때문입니다. 00:15:00.420 --> 00:15:03.840 재무팀이 사용량을 확인할 때 관리자들이 식은땀을 흘리며 깨어나는 데는 다 이유가 있습니다. 00:15:04.080 --> 00:15:07.460 잘 작동하는 빌드라도 청구서를 보는 순간 그 가치는 순식간에 퇴색됩니다. 00:15:07.660 --> 00:15:10.540 라이선스와 비용, 그것은 미쳐보지 못한 함정카드입니다. 00:15:10.760 --> 00:15:14.800 라이선스와 비용은 대부분의 팀이 이미 상황이 벌어진 후에야 깨닫게 되는 함정카드입니다. 00:15:15.120 --> 00:15:17.720 마이크로소프트는 빠른 빌드와 화려한 데모라는 환상을 팔지만, 00:15:17.720 --> 00:15:22.600 크레딧이 월중에 사라지거나 커넥터가 조용히 새로운 라이선스 요구사항을 추가하면 아무 소용이 없습니다. 00:15:22.860 --> 00:15:25.280 이는 부수적 인사항이 아니라 관리해야 할 핵심 요소이며, 00:15:25.700 --> 00:15:29.260 그렇지 않으면 사람들이 의존하기 시작하는 바로 그 순간 에이전트가 멈춰버릴 것입니다. 00:15:29.440 --> 00:15:32.100 코파일럿 스튜디오는 코파일럿 크레딧으로 작동합니다. 00:15:32.300 --> 00:15:36.440 크레딧팩을 구매하거나 페넌트 당월 약 200달러에 2만 5천 크레딧, 00:15:36.720 --> 00:15:41.240 조직의 소비량에 따라 기간 종료 시 청구되는 종량제 측정 방식을 사용할 수 있습니다. 00:15:41.520 --> 00:15:45.680 관대하게 들리지만 문서를 확인해보면 소비량이 일정하지 않다는 사실을 알 수 있습니다. 00:15:45.680 --> 00:15:51.820 계층화된 요금제를 사용하는데, 표준비 생성형 작업은 비용이 적게 드는 반면 생성형 답변은 더 많은 비용이 소모됩니다. 00:15:51.980 --> 00:15:54.680 정확한 수치는 마이크로소프트 위 라이선스 가이드에 따라 변경되므로, 00:15:55.620 --> 00:15:57.920 청구 관련 문서를 빌드키트의 일부처럼 다루세요. 00:15:58.100 --> 00:16:01.940 핵심은 테스트 프롬프트와 운영응답 모두 동일한 풀에서 차감된다는 점입니다. 00:16:02.160 --> 00:16:05.680 시스템 어디에도 숨겨진 무료 샌드박스는 없으며, 아무리 간절히 원해도 마찬가지입니다. 00:16:06.460 --> 00:16:08.060 크레딧은 테넌트 전체에 적용되므로, 00:16:08.200 --> 00:16:10.740 인사팀에 온 보딩보디든, 영업팀의 거래지원보디든, 00:16:10.740 --> 00:16:14.180 재무팀의 보고 어시스턴트 등 모든 에이전트가 동일한 풀을 사용합니다. 00:16:14.340 --> 00:16:15.900 이러한 설계는 유연성을 제공하지만, 00:16:16.300 --> 00:16:20.700 한 부서의 집중적인 테스트 작업이 다른 팀의 운영 리소스를 소진시킬 수 있음을 의미하기도 합니다. 00:16:20.840 --> 00:16:24.580 풀이 비워지면 코파일럿 스튜디오는 속도를 제한하거나 부드럽게 경고하지 않습니다. 00:16:24.780 --> 00:16:28.080 단순히 크레딧이 충전될 때까지 해당 에이전트를 일시 중지합니다. 00:16:28.300 --> 00:16:32.260 다른 그룹이 밤새 테스트 루프를 돌려놓은 탓의 실시간 지원 보시 거래 도중, 00:16:32.420 --> 00:16:35.060 멈춘 이유를 설명해야 하는 상황은 피하고 싶을 것입니다. 00:16:35.060 --> 00:16:40.700 종량제 방식은 성결제를 피하고 싶을 때 유용하며, 해당 월에 실제로 소모한 만큼만 지불하면 됩니다. 00:16:40.940 --> 00:16:43.200 하지만 측정기는 냉혹할 정도로 공정합니다. 00:16:43.400 --> 00:16:47.080 간단한 프로토타입 테스트도 운영 워크플로와 동일한 방식으로 크레딧을 소모함으로, 00:16:47.520 --> 00:16:50.140 예산 알림이 없으면 과도한 지출이 발생하기 매우 쉽습니다. 00:16:50.320 --> 00:16:55.320 안전한 접근 방식은 테스트 빌드조차 크레딧 계획의 일부로 간주하여 일찍 한도를 설정하는 것입니다. 00:16:55.520 --> 00:16:59.180 팀즈 툴킷 인하되 코드 위 에이전트 툴킷은 다른 관점을 취합니다. 00:16:59.180 --> 00:17:06.080 제품군에 개시하면 사용자의 마이크로소프트 365 코파일럿 나이선스 하에서 작업이 실행됨으로 프롬프트당 크레딧이 보이지 않습니다. 00:17:06.280 --> 00:17:09.680 스튜디오에 비하면 자유로워 보이지만 기본사항만 다룰 뿐입니다. 00:17:09.880 --> 00:17:14.240 맞춤형 엔진 에이전트를 구축하거나 외부 서비스에 연결하는 순간 비용이 쌓이기 시작합니다. 00:17:14.460 --> 00:17:18.580 api는 자체 측정기가 있고, 엔터프라이즈 커넥터는 별도의 나이선스가 필요한 경우가 많으며, 00:17:18.960 --> 00:17:21.420 관리자 동의에 따라 예상치 못한 요금계층이 적용될 수도 있습니다. 00:17:21.420 --> 00:17:25.120 스튜디오는 작업당 요금을 청구하고, 툴킷은 크레딧 모델을 우회하게 해줍니다. 00:17:25.300 --> 00:17:27.360 하지만 두 경우 모두 비용은 어딘가로 정가됩니다. 00:17:27.560 --> 00:17:29.380 이를 공짜가 아닌 상충관계라고 부릅니다. 00:17:29.600 --> 00:17:32.500 실질적인 규칙은 팀즈 툴킷은 통합 및 서비스 계층에 비용을 숨기는 반면, 00:17:32.900 --> 00:17:34.920 스튜디오는 크레딧으로 미리 지불하게 만든다는 것입니다. 00:17:35.100 --> 00:17:37.280 어느 쪽도 모든 상황에서 더 저렴하지는 않습니다. 00:17:37.480 --> 00:17:41.540 경로를 선택하기 전에 예상 워크플로우를 문서화된 가격 정책에 맞춰 맵핑해야 합니다. 00:17:41.540 --> 00:17:46.640 쉐어포인트를 기반으로 한 가벼운 승인보순 스튜디오에서 크레딧을 적게 쓰며 효율적으로 운영될 수 있습니다. 00:17:46.840 --> 00:17:48.360 외부 CRM과 크게 통합하는 경우, 00:17:48.480 --> 00:17:52.060 N은 코파일럿 크레딧을 소모하는 대신 CRM 위 API 요금을 지불하더라도, 00:17:52.220 --> 00:17:54.220 툴킷을 사용하는 것이 더 합리적일 수 있습니다. 00:17:54.420 --> 00:17:56.160 중요한 것은 비용이 어디로 이동하느냐이지, 00:17:56.480 --> 00:17:57.800 이를 완전히 피하는 방법이 아닙니다. 00:17:57.960 --> 00:18:00.800 그렇다면 예상치 못한 비용 함정을 피하려면 어떻게 해야 할까요? 00:18:00.940 --> 00:18:03.960 첫째, 코파일럿 에이전트 사용량 측정기나 종량제 보고서를 통해 00:18:03.960 --> 00:18:05.840 테넌트 수준의 사용량 모니터링을 활성화하세요. 00:18:05.840 --> 00:18:10.880 둘째, 예산이 소진되기 전에 재무 및 IT 부서의 알림이 가도록 경고 임계값을 설정하세요. 00:18:11.060 --> 00:18:15.140 셋째, 지정된 크레딧팩이나 명확한 내부 정책을 통해 사업부별로 예산을 할당하여, 00:18:15.500 --> 00:18:18.080 한 팀이 단일 스프린트에서 예산을 전부 소진하지 않도록 하세요. 00:18:18.260 --> 00:18:21.280 이 세 가지 제어장치만으로도 대부분의 당혹스러운 상황을 줄일 수 있습니다. 00:18:21.480 --> 00:18:23.320 확장 개발은 또 다른 계층을 추가합니다. 00:18:23.560 --> 00:18:25.860 통합에는 종종 명시적인 관리자 동의가 필요하며, 00:18:26.240 --> 00:18:28.740 각 동의는 기본적으로 새로운 비용을 발생시킬 수 있습니다. 00:18:28.960 --> 00:18:33.320 테스트 중에 연결한 외부 API는 마이크로소프트가 아닌 여러분에게 비용을 청구합니다. 00:18:33.320 --> 00:18:35.720 설계 단계에서 라이선스와 커넥터를 목록화하고, 00:18:36.080 --> 00:18:38.800 배포 전에 각각의 비용 지불 주체를 확인하는 것이 현명한 방법입니다. 00:18:38.960 --> 00:18:41.980 이를 단순히 기능적인 관점이 아닌 비용 측면의 변경 관리로 다루십시오. 00:18:42.120 --> 00:18:44.500 라이선스는 약관의 세부 사항이 아니라 아키텍처의 일부입니다. 00:18:44.660 --> 00:18:47.160 레이드에서 토큰을 사용하듯 신중하게 크레딧을 소비하세요. 00:18:47.360 --> 00:18:48.860 무분별하게 사용해서는 안 됩니다. 00:18:49.180 --> 00:18:52.080 시작부터 적절한 라이선스를 갖추고 사용량을 모니터링하며, 00:18:52.420 --> 00:18:54.840 새로운 커넥터마다 통합 비용이 발생할 것임을 예상하세요. 00:18:54.840 --> 00:18:59.260 사람들이 에이전트에 의존할 때 항상 이용 가능하게 만들 여면이 중 어느 하나도 선택사항이 아니면, 00:18:59.700 --> 00:19:01.000 이것이 마지막 단계로 이어집니다. 00:19:01.120 --> 00:19:04.960 에이전트 구축, 기반 마련, 거버넌스 및 자금 조달은 필수적인 점검 사항이지만, 00:19:05.360 --> 00:19:07.820 진정한 성공은 운영이 아니라 장기적인 캠페인 유지에 있습니다. 00:19:08.080 --> 00:19:10.800 바로 그 지점에서 최종적인 관점이 가장 중요해집니다. 00:19:10.960 --> 00:19:11.880 결론은 이렇습니다. 00:19:12.160 --> 00:19:13.160 성공은 화려한 데모가 아니라, 00:19:13.520 --> 00:19:16.360 에이전트가 무분별하지 않고 유용하게 작동하도록 규칙을 따르는 데 있습니다. 00:19:16.620 --> 00:19:18.680 첫째, 빌드 경로를 혁명하게 선택하세요. 00:19:18.880 --> 00:19:20.180 로우코드 속도를 위한 코파일러 스튜디오, 00:19:20.180 --> 00:19:22.840 완전한 사용자 지정 엔진과 더 깊은 제어를 위한 팀즈 툴킷이 있습니다. 00:19:23.020 --> 00:19:25.260 둘째, 출시 시점부터 거버넌스를 확립하세요. 00:19:25.420 --> 00:19:29.900 개시하기 전에 퍼뷰 레이블, 관리자 역할, 진단로그 및 사용량 모니터링을 모두 활성화해야 합니다. 00:19:30.100 --> 00:19:31.600 셋째, 지출을 계획하세요. 00:19:31.840 --> 00:19:34.660 스튜디오는 페넌트 전체 크레딧팩이나 종량제 측정기를 사용하지만, 00:19:35.080 --> 00:19:37.160 툴킷은 외부 API 및 서비스로 비용을 전환합니다. 00:19:37.340 --> 00:19:37.900 이상입니다. 00:19:38.140 --> 00:19:40.420 구독과 알림 설정을 누르고 댓글을 남겨주세요. 00:19:40.640 --> 00:19:43.320 다음 퀘스트를 위해 스튜디오와 툴킷 중 무엇을 선택하시겠습니까?