WEBVTT 00:00:00.000 --> 00:00:07.880 마이크로소프트 365, 코파일럿, AI, 에이적, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요? 00:00:08.260 --> 00:00:11.920 이번 1월, M365 컨이더 커진 규모로 돌아옵니다. 00:00:12.340 --> 00:00:18.640 전세계 MVP와 업계 전문가들이 전하는 라이브 세션, 실전 데모, 실용적인 지식을 함께하세요. 00:00:18.860 --> 00:00:21.340 뻔한 슬라이드나 끝없는 유행원은 없습니다. 00:00:21.740 --> 00:00:29.320 코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제를 다룹니다. 00:00:29.320 --> 00:00:35.080 IT 전문가, 개발자, 비즈니스 리더 등 누구에게나 맞는 세션이 준비되어 있습니다. 00:00:35.600 --> 00:00:40.160 10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 연결될 수 있습니다. 00:00:40.560 --> 00:00:44.600 라이브로 시청하고 실무에 바로 적용할 수 있는 인사이트를 얻어가세요. 00:00:44.840 --> 00:00:51.080 2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티 등록이 지금 시작되었습니다. 00:00:52.880 --> 00:00:54.660 지금 바로 자리를 확보하세요. 00:00:56.920 --> 00:00:58.580 m365.com.net입니다. 00:00:58.580 --> 00:01:04.540 m365.com.net에서 등록하시고 1월 라이브 행사에서 뵙겠습니다. 00:01:04.920 --> 00:01:09.180 AI 에이전트가 여러분도 모르는 사이에 결정을 내리기 시작한다면 무슨 일이 벌어질까요? 00:01:09.360 --> 00:01:11.840 오늘 세션에서는 거버넌스가 왜 더 이상 선택사항이 아닌지, 00:01:12.160 --> 00:01:16.100 그리고 마이크로소프트 365 관리센터가 어떻게 필요한 제어판을 제공할 수 있는지 알아봅니다. 00:01:16.300 --> 00:01:21.760 에이전트가 제멋대로 작동하지 않도록 방지하면서 팀이 필요한 것을 구축할 수 있도록 지원하는 정확한 도구를 살펴보겠습니다. 00:01:21.760 --> 00:01:27.280 통제력을 잃지 않으면 서코파일럿 위 이점을 활용하는 방법이 궁금하셨다면 제대로 찾아오셨습니다. 00:01:27.420 --> 00:01:30.100 왜 많은 조직이 AI 에이전트를 두려워할까요? 00:01:30.260 --> 00:01:34.340 AI 에이전트의 이점이 서류상으로 명확해 보이는데도 왜 기업들은 망설이는 걸까요? 00:01:34.500 --> 00:01:37.900 수작업 감소, 더 빠른 위사 결정, 데이터 활용 능력 향상 때문이죠. 00:01:38.040 --> 00:01:40.900 표면적으로는 쉽게 승인할 수 있는 성공 사례처럼 보입니다. 00:01:40.900 --> 00:01:45.760 하지만 논의가 슬라이드에서 실제 배포 단계로 넘어가면 리더십 팀이 주춤하는 것을 볼 수 있습니다. 00:01:45.960 --> 00:01:49.080 이러한 망설임은 기술에 대한 신뢰가 부족해서가 아닙니다. 00:01:49.260 --> 00:01:56.660 수백, 수천 개의 작은 자동화 작업이 명확한 감독 없이 백그라운드에서 실행될 때 어떤 일이 벌어질지 모른다는 두려움 때문입니다. 00:01:56.860 --> 00:02:04.000 거대한 잠재력과 그만큼 큰 불확실성 사이의 긴장감 때문에 많은 조직이 예상보다 훨씬 오래 파일럿 모드에 머물러 있습니다. 00:02:04.340 --> 00:02:09.000 사실 AI 에이전트가 사람들을 불안하게 만드는 이유는 다른 도구들처럼 작동하지 않기 때문입니다. 00:02:09.000 --> 00:02:16.080 엔드포인트 관리로 직원이 새 생산성 앱을 설치하는 시점을 제어하거나 소프트웨어를 차단할 수는 있지만 에이전트는 기존의 틀 안에 깔끔하게 들어맞지 않습니다. 00:02:16.240 --> 00:02:19.820 에이전트는 때로는 빠르게, 때로는 여러 시스템에 걸쳐 작동하도록 설계되었습니다. 00:02:20.100 --> 00:02:22.860 일단 배포되면 스스로 움직이는 것처럼 느껴질 수 있습니다. 00:02:23.060 --> 00:02:32.660 통제, 표준화, 거버넌스라는 관점에서 생각하도록 훈련받은 IT 리더들에게는 눈에 보이지 않는 백그라운드 프로세스가 실제 정보 흐름을 형성한다는 사실이 조직에 대한 통제력을 잃는 것처럼 느껴질 수 있습니다. 00:02:32.880 --> 00:02:35.560 이런 상황이 어떻게 전개되는지 보여주는 사례는 아주 많습니다. 00:02:35.560 --> 00:02:38.740 한 연구팀이 데이터 세트를 추출하고 정리하는 봇을 실행합니다. 00:02:38.900 --> 00:02:41.480 누군가 그 작동 모습을 보고 약간 수정하여 복제합니다. 00:02:41.680 --> 00:02:44.720 몇 주 안에 회사는 잘 관리된 에이전트 하나를 운영하는 것이 아니게 됩니다. 00:02:44.940 --> 00:02:49.180 버전 관리도 없고 책임자도 불분명한, 작은 차이만 있는 20개의 복제본이 운영됩니다. 00:02:49.360 --> 00:02:54.540 이제 베를린의 분석가는 뉴욕의 관리자가 사용하는 것과는 조금 다른 데이터 세트로 위사결정을 내리고, 00:02:55.100 --> 00:02:58.300 재무팀은 두 버전 모두 보고서에 반영되면서 혼란에 빠집니다. 00:02:58.300 --> 00:03:01.480 이를 각자 속도를 높이려는 수십 개의 부서로 확대해보면, 00:03:02.080 --> 00:03:06.980 생산성 향상은 순식간에 도대체 어떤 수치를 믿어야 할지 모르는 상황으로 변질됩니다. 00:03:07.300 --> 00:03:11.540 자동화가 결코 건드려서는 안 될 영역까지 침범한 사례도 보았습니다. 00:03:11.800 --> 00:03:17.080 한 회사는 온 보딩을 간소화하려고 내부 스크립트가 고객 정보를 시스템 간에 조용히 이동시키게 했지만, 00:03:17.640 --> 00:03:21.180 데이터 전송이 규정 준수 표준을 따르는지 검토한 사람은 아무도 없었습니다. 00:03:21.180 --> 00:03:28.300 감사관들이 들이 닥쳤을 때, 두 직은 누가 스크립트를 작성했는지, 왜 실행되었는지, 어떤 규칙을 따랐는지에 대한 기록을 전혀 제시하지 못했습니다. 00:03:28.520 --> 00:03:32.380 그것은 AI 기능의 실패가 아니었습니다. 그것은 감독의 실패였습니다. 00:03:32.780 --> 00:03:37.600 시간을 절약하기 위해 설계된 기술이 회사 역사상 가장 큰 규정 준수 골칫거리를 만들어낸 것입니다. 00:03:37.820 --> 00:03:40.600 리더들이 신중하게 반응하는 이유는 어렵지 않게 알 수 있습니다. 00:03:40.840 --> 00:03:46.040 경계없는 에이전트를 도입하는 것은 모든 직원에게 드론을 쥐어주고 마음대로 날리게 하는 것과 같습니다. 00:03:46.040 --> 00:03:55.240 처음 몇 대는 원활하게 이륙할지 몰라도, 곧 하나는 건물에 충돌하고, 다른 하나는 행방불명되며, 세 번째는 응급 헬기에 착륙을 방해하게 됩니다. 00:03:55.460 --> 00:04:00.060 관제탑이 없다면 효율성을 높여야 할 바로 그 기술이 공공의 위험이 됩니다. 00:04:00.360 --> 00:04:02.920 지식 노동에서도 동일한 원칙이 적용됩니다. 00:04:03.160 --> 00:04:05.380 자동화 자체가 두려움의 원인은 아닙니다. 00:04:05.560 --> 00:04:07.340 통제의 부재가 두려움의 원인입니다. 00:04:07.600 --> 00:04:10.980 설문조사 결과는 이러한 이야기들에서 이미 짐작할 수 있는 내용을 뒷받침합니다. 00:04:10.980 --> 00:04:16.540 임원들은 엔터프라이즈 AI에 대한 핵심 우려사항으로 규정 준수, 보안, 데이터 유출을 지속적으로 꼽습니다. 00:04:16.700 --> 00:04:19.740 기술이 성과를 내는지 여부는 문제가 되지 않는 경우가 많습니다. 00:04:19.960 --> 00:04:25.520 우려는 잘못된 정보가 유출되거나, 사후에 아무도 추적할 수 없는 조치를 보시 취할까 하는 것입니다. 00:04:25.760 --> 00:04:28.200 단순한 운영상의 실수가 문제가 아닙니다. 00:04:28.420 --> 00:04:32.460 이는 평판, 규제의 위험, 고객 신뢰와 직결되는 문제입니다. 00:04:32.680 --> 00:04:37.660 고객이 귀사에 자동화가 노출해서는 안 될 데이터를 노출했다고 믿게 되면, 신뢰를 회복하는 데 수년이 걸립니다. 00:04:37.900 --> 00:04:40.420 그렇기에 진짜 문제를 정확하게 정의하는 것이 중요합니다. 00:04:40.420 --> 00:04:43.060 기업은 코파일럿, 에이전트 그 자체를 두려워하지 않습니다. 00:04:43.220 --> 00:04:45.320 기업은 에이전트를 통제하지 못하는 것을 두려워합니다. 00:04:45.560 --> 00:04:51.380 누가 어떤 에이전트를 만들었는지, 마지막으로 검토한 시점이 언제인지, 왜 민감한 시스템에서 정보를 가져오는지 잊어버리는 것을 두려워합니다. 00:04:51.600 --> 00:04:57.000 문제는 소프트웨어가 아니라, 신뢰성과 예측 가능성을 유지하고, 조직의 규칙에 맞게 작동하도록 하는 안전장치가 없다는 점입니다. 00:04:57.160 --> 00:04:59.820 일단 그렇게 바라보면 나아갈 길이 훨씬 명확해집니다. 00:04:59.960 --> 00:05:02.340 바로 이 지점에서 대부분의 사람들이 놀라곤 합니다. 00:05:02.600 --> 00:05:07.180 많은 조직이 부재하다고 느끼는 제어판은 사실 이미 마이크로소프트 365 안에 있습니다. 00:05:07.180 --> 00:05:10.800 별도의 추가 기능이 아닙니다. 숨겨진 프리미엄 기능도 아닙니다. 00:05:10.980 --> 00:05:12.600 관리센터에 이미 내장되어 있습니다. 00:05:12.960 --> 00:05:17.000 많은 조직이 포털을 라이선스 할 땅이나 기본적인 팀제정책 설정용으로만 사용하지만, 00:05:17.540 --> 00:05:20.900 사실 이곳은 조용히 코파일럿 에이전트를 위한 항공 관제탑 역할을 해왔습니다. 00:05:21.120 --> 00:05:24.460 다시 말해, 여러분에게 필요한 안전장치는 이미 여러분 앞에 놓여 있습니다. 00:05:24.780 --> 00:05:27.480 관건은 여러분이 올바른 패널을 열었느냐 하는 것뿐입니다. 00:05:27.720 --> 00:05:29.920 여러분에게 있는지 조차 몰랐던 제어판입니다. 00:05:29.920 --> 00:05:32.980 AI 에이전트를 관리하기 위한 조종석이 이미 여러분 앞에 있었고, 00:05:33.340 --> 00:05:35.800 단지 대부분의 관리자가 알아차리지 못했던 것이라면 어떨까요? 00:05:35.980 --> 00:05:42.940 믿기 어렵겠지만, 사실 마이크로소프트 365 관리센터는 많은 조직이 그토록 찾아 헤매던 제어 장치를 조용히 품고 있습니다. 00:05:43.260 --> 00:05:50.160 아이러니하게도 많은 IT팀이 매일이 포털을 열면서도 에이전트 거버넌스의 가장 중요한 부분은 무심코 지나치고 있습니다. 00:05:50.520 --> 00:05:54.240 생각해보면 익숙함이 오히려 방해가 되는 상황 중 하나입니다. 00:05:54.240 --> 00:06:00.580 내용을 잘 안다고 가정하기 때문에 평소 무시하던 탭 뒤에 새로운 제어 수단이 숨겨져 있으리라고는 예상하지 못하는 것이죠. 00:06:00.780 --> 00:06:03.920 수년간 관리센터는 단순한 유틸리티 패널처럼 취급되어 왔습니다. 00:06:04.120 --> 00:06:09.340 라이선스를 배포하고, 익스체인지 사소함을 구성하고, 팀제 정책을 한두 개 조정하기 위해 열어보는 곳이었죠. 00:06:09.500 --> 00:06:16.140 사용자에게 기능을 맵핑하고, 티켓을 요청한 사람들이 결국 원하는 서비스에 접근할 수 있도록 확인하는 작업 공간이었습니다. 00:06:16.360 --> 00:06:19.540 종종 강과되는 점은 이곳이 얼마나 더 풍성해졌느냐 하는 것입니다. 00:06:19.540 --> 00:06:27.320 같은 인터페이스 뒤에는 관리자가 단순히 접근 권한을 관리하는 것을 넘어, 사용자가 어떻게 자동화를 생성하고, 사용하고 공유하는지까지 통제할 수 있는 기능들이 계속 늘어나고 있습니다. 00:06:27.520 --> 00:06:33.100 코파일럿 에이전트가 통제 범위를 벗어날까 봐 걱정해왔다면, 그 안전장치는 불과 몇 번이 클릭거리 안에 있습니다. 00:06:33.380 --> 00:06:34.600 불일치는 분명합니다. 00:06:34.840 --> 00:06:46.340 IT 포럼의 모든 대화는 AI로 인한 혼란, 부서마다 나타나는 정체불명의 봇, 민감한 데이터를 건드리는 자동화, 또는 미세하지만 치명적인 차이로 중복되는 워크플로우에 대한 두려움을 중심으로 돌아갑니다. 00:06:46.340 --> 00:06:52.360 하지만 정작 그런 걱정을 하는 조직들은 바로 그러한 문제를 막기 위해 설계된 중앙 대시보드는 거의 쳐다보지도 않습니다. 00:06:52.520 --> 00:06:53.680 이상한 불일치입니다. 00:06:53.880 --> 00:06:58.540 통제력을 잃을까 두려워하면서도, 비행을 조율하기 위해 존재하는 제어판을 제대로 활용하지 못하고 있습니다. 00:06:58.760 --> 00:07:02.980 이는 모퉁이의 신호 등은 무시한 채 예측 불가능한 교통 상황을 불평하는 것과 같습니다. 00:07:03.280 --> 00:07:06.260 대규모 기업 내부의 전형적인 시나리오를 상상해보십시오. 00:07:06.260 --> 00:07:12.080 마케팅 부서에서는 고객 피드백 수집을 위해 에이전트를 만들고, 운영 부서에서는 주문 추적을 간소화할 곳을 설계합니다. 00:07:12.240 --> 00:07:14.040 위도적 인시에도 IT는 하나도 없습니다. 00:07:14.340 --> 00:07:17.200 그저 업무를 더 쉽게 만들려는 열정적인 직원들의 노력일 뿐입니다. 00:07:17.380 --> 00:07:20.860 하지만 에이전트가 출시되면 통합된 기록 없이 여러 사일로로 흩어지게 됩니다. 00:07:21.120 --> 00:07:26.360 IT 부서가 이를 발견했을 때는 이미 누가 무엇을 소유하고 있는지, 어떤 데이터 소스를 활용하는지 알 수 없는 상태입니다. 00:07:26.560 --> 00:07:29.200 갑자기 규정 준수 관련 대화가 탐정 작업으로 변해버립니다. 00:07:29.200 --> 00:07:34.280 도대체 누가 이걸 만든 걸까요? 언제 업데이트 되었나요? 어떤 권한이 암묵적으로 상속되었나요? 00:07:34.400 --> 00:07:39.020 명확한 감독이 없으면 작은 자동화라도 눈덩이처럼 불어나 예상치 못한 규정 준수 격차를 만듭니다. 00:07:39.160 --> 00:07:43.180 관리센터는 이러한 보이지 않는 활동을 한 곳으로 모아이 문제를 직접 해결합니다. 00:07:43.380 --> 00:07:49.760 추측할 필요 없이 어떤 에이전트가 존재하고, 어떤 커넥터에 의존하며, 누가 수정하거나 개시할 권한이 있는지 확인할 수 있습니다. 00:07:50.000 --> 00:07:56.400 정책을 통해 애초에 어떤 그룹이 자동화를 만들 수 있는지 정의함으로 실험과 공식 배포를 분리할 수 있습니다. 00:07:56.400 --> 00:08:04.620 한 팀 내에서 내부 프로토타입을 만드는 것과 전체 CRM이나 HR 플랫폼에 영향을 주는 기능을 설정하는 것은 매우 다르기 때문에 이는 매우 중요합니다. 00:08:04.820 --> 00:08:09.700 관리센터는 이 두 영역을 구분하도록 해줍니다. 권한 관리는 안전성을 한층 더 높여줍니다. 00:08:09.900 --> 00:08:16.260 열정적인 모든 직원이 에이전트를 구축할 뿐만 아니라 전체 테넌트에 배포할 수 있다면 얼마나 위험할지 상상하기 쉽습니다. 00:08:16.420 --> 00:08:22.620 더 나은 모델은 아이디어 구축에는 폭넓은 참여를 허용하되 배포 권한은 지정된 역할로 제한하는 것입니다. 00:08:22.620 --> 00:08:32.840 실제로 재무 분석가는 보고 요구사항에 맞춰 초안 에이전트를 만들고 IT 거버넌스 팀만이 해당 초안을 프로덕션 환경으로 배포할지 결정하는 방식이 될 수 있습니다. 00:08:33.080 --> 00:08:38.240 관리센터 내에서 이러한 규칙을 구성함으로써 누가 공역의 규칙을 정할지 미리 결정하게 됩니다. 00:08:38.500 --> 00:08:40.500 보고 기능은 마지막 단계를 완성합니다. 00:08:40.740 --> 00:08:49.820 무엇인가 고장나서야 보세 존재를 알게 되는 대신 사용 추세를 추적하고 어떤 부서가 활발히 실험하는지 파악하며 터진 스프레드 시트를 뒤질 필요 없이 감사를 수행할 수 있습니다. 00:08:49.820 --> 00:08:53.980 이러한 데이터 기반 관점은 규정 준수를 넘어 전략 수립에 도움을 줍니다. 00:08:54.180 --> 00:09:02.400 지원팀들이 비슷한 에이전트를 반복적으로 만들고 있다면 수십 개의 유사한 봇을 방치하기보다는 표준화된 솔루션에 투자할 때가 된 것입니다. 00:09:02.600 --> 00:09:07.660 가시선과 통제력을 결합하면 자동화는 골칫거리에서 관리 가능한 기회로 바뀝니다. 00:09:07.840 --> 00:09:13.700 따라서 에이전트가 제멋대로 돌아다니는 것을 상상하는 대신 관리센터를 항공관제탑으로 생각하십시오. 00:09:13.700 --> 00:09:20.680 모든 비행계획은 기록되고 모든 출발은 정책에 따라 승인되며 누군가 전체 하늘을 보고 있기 때문에 충돌은 발생하지 않습니다. 00:09:20.860 --> 00:09:28.320 하나의 중앙데시보드가 이러한 강력한 기능을 갖추고 있음을 알게 되면 에이전트를 숨겨진 위협으로 대하는 대신 구조화된 운영 방식으로 관리하게 될 것입니다. 00:09:28.540 --> 00:09:31.440 이러한 프레임워크가 마련되면 대화의 방향이 바뀝니다. 00:09:31.640 --> 00:09:37.660 관리자는 감독 권한을 갖지만 직원들은 여전히 규정을 어기지 않으면 서 자유롭게 구축하고 실험할 공간이 필요하기 때문입니다. 00:09:37.660 --> 00:09:40.460 바로 그 지점에서 코파일러 스튜디오가 역할을 합니다. 00:09:40.660 --> 00:09:43.520 혼란 없는 혁신, 코파일러 스튜디오의 활약입니다. 00:09:43.740 --> 00:09:48.920 조직을 혼란에 빠뜨리지 않으면 서직원들이 직접 AI 기반 솔루션을 만들게 하려면 어떻게 해야 할까요? 00:09:49.120 --> 00:09:52.140 그것이 바로 코파일러 스튜디오와 관련된 핵심 과제입니다. 00:09:52.360 --> 00:09:55.560 한편으로 이 도구는 부서 전반의 창의성을 발휘하도록 설계되어 00:09:55.560 --> 00:10:00.100 일상의 고충을 가장 잘 이해하는 사람들이 이를 직접 자동화할 기회를 제공합니다. 00:10:00.320 --> 00:10:04.660 다른 한편으로 감독 없이 구축 도구를 배포하면 통제되지 않은 워크플로우가 급증하여 00:10:04.660 --> 00:10:09.260 IT 부서가 실제로 무엇이 실행 중인지 파악하느라 애를 먹을 수 있습니다. 00:10:09.500 --> 00:10:11.600 처음 보기엔 까다로운 균형처럼 보입니다. 00:10:11.840 --> 00:10:13.880 사용자에게 권한을 부여하고 혼란을 감수할까요? 00:10:14.160 --> 00:10:16.000 아니면 모든 것을 잠그고 발전을 저해할까요? 00:10:16.160 --> 00:10:18.700 코파일러 스튜디오는 그 중간 지점을 자처합니다. 00:10:18.980 --> 00:10:21.740 직원들이 솔루션을 시도하고 상호작용을 테스트하며 00:10:21.740 --> 00:10:25.640 업무 방식을 개선하기 위해 에이전트를 게시할 수 있는 워크숍이라고 생각하세요. 00:10:25.880 --> 00:10:29.060 이것과 과거의 DIY 자동화 사이의 차이는 간단합니다. 00:10:29.300 --> 00:10:31.700 플랫폼의 안전장치가 이미 내장되어 있습니다. 00:10:31.700 --> 00:10:34.220 IT 부서에 사후 수습을 맡기는 대신 00:10:34.220 --> 00:10:37.160 스튜디오는 관리센터에서 관리하는 것과 00:10:37.160 --> 00:10:40.520 동일한 거버넌스 원칙을 설계 환경에 직접 반영합니다. 00:10:40.700 --> 00:10:43.480 그것이 도구를 위험한 것이 아닌 실용적인 것으로 만듭니다. 00:10:43.660 --> 00:10:46.060 그럼에도 관리자가 느끼는 긴장감은 매우 현실적입니다. 00:10:46.240 --> 00:10:48.260 열정적인 직원이 스크립팅 도구를 손에 넣었을 때 00:10:48.260 --> 00:10:49.700 어떤 일이 벌어지는지 본 적이 있다면 00:10:49.700 --> 00:10:53.620 단순한 테스트가 얼마나 빨리 미션 크리티컬 한 위존성으로 발전하는지 알 것입니다. 00:10:53.820 --> 00:10:55.340 문제는 악의가 아니라는 점입니다. 00:10:55.540 --> 00:10:58.620 대부분의 사용자는 단지 자신의 업무 병목 현상을 해결하고 싶어 할 뿐입니다. 00:10:58.620 --> 00:11:03.500 하지만 로컬에서 구축된 솔루션이 고객 데이터, 재무 기록 또는 인사 파일과 상호작용하기 시작하면 00:11:03.500 --> 00:11:06.660 유용한 실험에서 순식간에 규정 준수 영역으로 넘어가게 됩니다. 00:11:06.840 --> 00:11:11.020 일단 그 경계를 넘어서면 책임과 감독은 더 이상 선택사항이 아닙니다. 00:11:11.160 --> 00:11:12.560 이런 시나리오를 그려보세요. 00:11:12.840 --> 00:11:17.820 재무 분석가가 고객 잔액을 자동으로 가져와 주간보고서를 생성하는 에이전트를 만듭니다. 00:11:18.000 --> 00:11:21.280 수동 작업 시간을 몇 시간이나 절약해 주어 금세 인기를 얻습니다. 00:11:21.580 --> 00:11:24.980 몇몇 동료들이 이를 가져다 쓰고 곧 부서 전체로 퍼져나갑니다. 00:11:25.140 --> 00:11:26.760 하지만 문제는 여기서 발생합니다. 00:11:26.760 --> 00:11:30.240 누가 그 에이전트가 민감한 필드를 노출하지 않는다고 보장했나요? 00:11:30.320 --> 00:11:34.660 데이터 소스가 금융정보 처리에 관한 규정 준수 규칙을 따랐는지 누가 확인했나요? 00:11:34.800 --> 00:11:37.700 규제기관이 조사를 나온다면 이것이 사이드 프로젝트가 아니라 00:11:37.700 --> 00:11:40.680 정책에 따라 구축 및 배포되었다는 것을 누가 증명할까요? 00:11:40.840 --> 00:11:43.920 적절한 구조가 없으면 그 단순한 보순 책임 소재가 됩니다. 00:11:44.200 --> 00:11:47.260 바로 이 지점에서 코파일러 스튜디오 가 상황을 경고하게 만듭니다. 00:11:47.440 --> 00:11:50.500 이 플랫폼은 모든 제작자가 전문 개발자라고 가정하지 않습니다. 00:11:50.700 --> 00:11:53.840 전체 설계에는 비기술 사용자를 위한 보호 기능이 포함되어 있습니다. 00:11:53.840 --> 00:11:59.640 관리자는 사용 가능한 작업과 커넥터 그리고 프로덕션 환경에 배포할 권한을 가진 사용자를 정의합니다. 00:11:59.820 --> 00:12:05.400 직원들은 완전한 창의적 자유를 누린다고 느낄 수 있지만 실제로는 세심하게 제한된 범위 내에서 실험이 이루어집니다. 00:12:05.560 --> 00:12:10.440 이러한 차이 덕분에 기업은 또 다른 섀도우 IT 문제에 직면하지 않고도 에이전트 도입을 확장할 수 있습니다. 00:12:10.680 --> 00:12:12.020 제어 지점은 구체적입니다. 00:12:12.280 --> 00:12:14.560 마케팅 부서에 모든 직원이 에이전트 초안을 만들게 할 수 있지만 00:12:14.560 --> 00:12:17.980 샌드박스 환경을 넘어 이를 게시할 수 있는 사람은 지정된 개인으로 제한할 수 있습니다. 00:12:17.980 --> 00:12:21.820 셰어포인트나 다이나믹스와 같이 승인된 커넥터만 사용 가능하게 할 수도 있습니다. 00:12:22.020 --> 00:12:25.240 민감한 타사 서비스와 연결되는 모든 항목은 사용이 제한됩니다. 00:12:25.440 --> 00:12:28.740 그뿐만 아니라 어떤 시스템 작업을 제한할지도 직접 결정할 수 있습니다. 00:12:28.980 --> 00:12:30.500 예를 들어 데이터베이스 조회는 허용하되 00:12:30.500 --> 00:12:34.280 실수로 인한 피해를 방지하기 위해 주요 필드를 직접 업데이트하는 것은 차단할 수 있습니다. 00:12:34.480 --> 00:12:37.160 요약하자면 사용자는 아이디어를 자유롭게 시도할 수 있지만 00:12:37.160 --> 00:12:39.720 명시적인 승인 없이는 프로덕션 기록을 변경할 수 없습니다. 00:12:39.980 --> 00:12:41.420 간단한 비유가 도움이 됩니다. 00:12:41.680 --> 00:12:43.020 놀이터의 모래 상자와 같습니다. 00:12:43.020 --> 00:12:45.740 아이들은 상자 안에서 원하는 만큼 성을 쌓을 수 있지만 00:12:45.740 --> 00:12:47.940 상자 주변에는 명확한 경계가 있습니다. 00:12:48.180 --> 00:12:50.140 울타리는 놀이를 안전하게 유지하면서도 00:12:50.140 --> 00:12:52.500 창의성을 발휘할 충분한 여지를 남겨둡니다. 00:12:52.720 --> 00:12:55.720 스튜디오는 에이전트 구축에도 동일한 개념을 적용합니다. 00:12:55.960 --> 00:12:57.880 직원들은 혁신에 필요한 자유를 얻고 00:12:57.880 --> 00:12:59.680 관리자는 보이지 않는 울타리가 00:12:59.680 --> 00:13:02.560 실제 위험으로 확장되는 것을 막고 있음을 알게 됩니다. 00:13:02.820 --> 00:13:06.220 따라서 적절한 권한과 정책으로 코파일럿 스튜디오를 설정하면 00:13:06.220 --> 00:13:09.880 보안 골칫거리가 아닌 본래 의도된 안전한 혁신 실험실이 됩니다. 00:13:09.880 --> 00:13:13.180 각 부서는 업무에 맞는 에이전트를 탐색하고 새로운 방식을 실험하며 00:13:13.180 --> 00:13:14.660 초기 아이디어를 공유할 수 있습니다. 00:13:14.840 --> 00:13:17.780 이 모든 과정은 규정을 준수하고 승인되지 않은 워크플로우를 생성하지 00:13:17.780 --> 00:13:19.040 않은 범위 내에서 이루어집니다. 00:13:19.200 --> 00:13:21.560 혁신은 계속되지만 혼란은 발생하지 않습니다. 00:13:21.780 --> 00:13:24.720 그러한 보호장치가 있더라도 간과할 수 없는 한 가지 안전장치가 더 00:13:24.720 --> 00:13:26.080 있는데 바로 가시성입니다. 00:13:26.300 --> 00:13:28.940 가드레일이 아무리 강력하더라도 실시간으로 어떤 일이 벌어지는지 00:13:28.940 --> 00:13:30.180 계속 지켜봐야 하기 때문입니다. 00:13:30.380 --> 00:13:32.700 그것이 바로 모니터링과 추적이 필요한 이유입니다. 00:13:32.900 --> 00:13:35.820 감시탑처럼 에이전트 활동을 모니터링하고 추적하는 것입니다. 00:13:35.820 --> 00:13:38.800 만약 에이전트가 보이지 않는 곳에서 수백 번의 결정을 조용히 내린다면 00:13:38.800 --> 00:13:39.460 어떻게 될까요? 00:13:39.620 --> 00:13:41.720 이는 결코 비현실적인 시나리오가 아닙니다. 00:13:41.880 --> 00:13:45.680 조직이 통제수단은 마련했지만 나머지 절반을 잊었을 때 정확히 발생할 00:13:45.680 --> 00:13:46.420 수 있는 일입니다. 00:13:46.620 --> 00:13:48.320 권한과 정책은 울타리와 같습니다. 00:13:48.740 --> 00:13:51.700 직원들이 어디에서 작업할 수 있고 어떤 도구를 사용할 수 있는지 00:13:51.700 --> 00:13:52.280 알려줍니다. 00:13:52.500 --> 00:13:55.660 하지만 가시성이 없으면 누군가 확인되지 않은 구역으로 들어갔는지 00:13:55.660 --> 00:13:59.380 혹은 에이전트가 의도된 범위를 벗어나 조용히 작동 중인지 알 방법이 00:13:59.380 --> 00:13:59.680 없습니다. 00:13:59.980 --> 00:14:03.640 모니터링은 이 거버넌스 이야기를 추측해서 명확성으로 바꾸는 핵심 00:14:03.640 --> 00:14:06.200 요소입니다. 00:14:06.200 --> 00:14:07.240 우리가 평소에 IT문제를 어떻게 다루는지 생각해보십시오. 00:14:07.380 --> 00:14:10.680 무언가 고장나고 사용자가 티켓을 제출하면 우리는 무엇이 바뀌었는지 00:14:10.680 --> 00:14:11.700 부랴부랴 추적해야 합니다. 00:14:11.880 --> 00:14:13.460 그것은 수동적인 대응 방식입니다. 00:14:13.680 --> 00:14:16.260 작은 규모에서는 효과가 있을지 몰라도 수백 개의 자동화로 확장 00:14:16.260 --> 00:14:17.840 되면 감당하기 힘든 골칫거리가 됩니다. 00:14:18.080 --> 00:14:21.620 AI 에이전트의 경우 문제가 너무 늦게 발견될 수 있어 위험 요소가 00:14:21.620 --> 00:14:22.240 훨씬 큽니다. 00:14:22.420 --> 00:14:25.020 제멋대로 작동하는 워크플로우는 아무도 모르는 사이에 몇 주 동안 00:14:25.020 --> 00:14:25.960 인하 실행될 수 있습니다. 00:14:25.960 --> 00:14:29.440 눈에 띄는 오류를 일으키는 것이 아니라 겉보기에는 정상적인 결정을 00:14:29.440 --> 00:14:30.620 조용히 내리기 때문입니다. 00:14:30.760 --> 00:14:33.960 왜 데이터가 맞지 않는지 누군가 묻게 될 때쯤이면 미래를 예방하는 00:14:33.960 --> 00:14:35.720 대신 과거를 조사하느라 바쁠 것입니다. 00:14:35.920 --> 00:14:38.000 모니터링은 이러한 흐름을 완전히 바꿔놓습니다. 00:14:38.240 --> 00:14:41.520 눈을 감고 일하는 대신 어떤 에이전트가 존재하고 누가 만들어두면 어떻게 00:14:41.520 --> 00:14:43.300 사용되고 있는지 실시간으로 파악할 수 있습니다. 00:14:43.500 --> 00:14:46.780 마이크로소프트 365는 이러한 가시성을 자체 생태계 안에 내장하고 00:14:46.780 --> 00:14:47.080 있습니다. 00:14:47.360 --> 00:14:51.780 사용 분석을 통해 어떤 부서가 에이전트를 빠르게 도입하는지 누가 에이전트를 00:14:51.780 --> 00:14:55.680 많이 만드는지 어디에서 예기치 않은 활동이 시작되는지 파악할 수 00:14:55.680 --> 00:14:56.060 있습니다. 00:14:56.360 --> 00:14:58.240 감사 로그는 세부사항을 추적합니다. 00:14:58.500 --> 00:15:01.800 에이전트가 언제 수정되었는지 어떤 커넥터에 연결되었는지 누가 작업을 00:15:01.800 --> 00:15:02.700 실행했는지 기록합니다. 00:15:02.900 --> 00:15:05.540 이런 기록은 단순히 규정 준수를 만족시키는 것 이상의 역할을 합니다. 00:15:05.720 --> 00:15:08.640 이는 추측에 의존하는 대신 실제 운영 환경을 제대로 이해할 수 있게 00:15:08.640 --> 00:15:09.040 해줍니다. 00:15:09.280 --> 00:15:12.820 이러한 통찰의 가치는 매우 평범한 시나리오를 상상해보면 분명해집니다. 00:15:13.020 --> 00:15:16.640 마케팅팀이 고객 피드백 설문조사를 분석하기 위해 에이전트를 만듭니다. 00:15:16.640 --> 00:15:20.420 처음에는 한 번이 캠페인과 수천 건의 데이터로 작게 시작하지만 결과는 00:15:20.420 --> 00:15:21.100 유용해 보입니다. 00:15:21.300 --> 00:15:24.660 시간이 지나면서 누군가 이를 다른 프로젝트에 복제하고 또 다른 팀이 00:15:24.660 --> 00:15:26.420 템플릿을 가져와 수정하기 시작합니다. 00:15:26.640 --> 00:15:30.320 모니터링이 없으면 이제 여러 버전의 에이전트가 병렬로 실행되며 각각 00:15:30.320 --> 00:15:32.200 데이터에 조금씩 다르게 접근하게 됩니다. 00:15:32.440 --> 00:15:36.660 방치해두면 이러한 차이는 결국 보고서에까지 스며들어 고의 의사 결정자들을 00:15:36.660 --> 00:15:37.560 혼란스럽게 합니다. 00:15:37.860 --> 00:15:42.260 모니터링을 켜두면 에이전트 사용 급증을 조기에 감지하고 늘어나는 중복 00:15:42.260 --> 00:15:45.980 버전을 발견하여 공식 버전을 표준화하거나 혼란을 야기하기 전에 00:15:45.980 --> 00:15:47.800 추가 버전들을 정리할 수 있습니다. 00:15:48.020 --> 00:15:51.680 때로는 가시성 하나가 사소한 수정 으로 끝낼지 아니면 대형 사고로 00:15:51.680 --> 00:15:53.100 이어질지를 결정짓습니다. 00:15:53.320 --> 00:15:56.700 내부 예측 속도를 높이기 위해 민감한 재무 데이터를 가져오는 에이전트 00:15:56.700 --> 00:15:57.960 의 사례를 생각해 보십시오. 00:15:58.120 --> 00:16:01.580 만약 실수로 너무 많은 세부 정보가 노출되거나 재무부서 외부로 데이터 00:16:01.580 --> 00:16:04.560 가 공유된다면 규정 준수 위험이 빠르게 커질 것입니다. 00:16:04.760 --> 00:16:08.420 하지만 모니터링이 있다면 비정상적인 접근이 로그에 명확하게 나타납니다. 00:16:08.640 --> 00:16:11.860 규제기관이나 고객이 문제를 제기하기 전에 해당 에이전트를 중지하거나 00:16:11.860 --> 00:16:13.000 권한을 조정할 수 있습니다. 00:16:13.000 --> 00:16:15.780 이는 제작자의 나쁜 의도를 가정하라는 뜻이 아닙니다. 00:16:15.940 --> 00:16:19.400 아무리 신중한 팀이라도 실험 과정에서 실수를 할 수 있다는 점을 인정해야 00:16:19.400 --> 00:16:20.080 한다는 것입니다. 00:16:20.260 --> 00:16:23.700 가시성은 그러한 실수를 재앙이 아닌 되돌릴 수 있는 것으로 만들어줍니다. 00:16:23.920 --> 00:16:26.980 보고 기능은 또한 감사인과의 관계를 원만하게 만들어줍니다. 00:16:27.180 --> 00:16:30.680 감사를 받아본 사람이라면 누구든 문서 수집, 승인 내역 확인, 변경 00:16:30.680 --> 00:16:33.880 시점 파악, 통제 조치 이행 여부 확인을 위해 고군분투했던 고통스러운 00:16:33.880 --> 00:16:34.860 경험을 알고 있을 겁니다. 00:16:35.080 --> 00:16:38.060 수동 추적은 오류가 발생하기 쉽고 스트레스가 큽니다. 00:16:38.060 --> 00:16:41.580 보고 시스템이 이미 해당 기록을 보관하고 있다면 더 이상 허둥 00:16:41.580 --> 00:16:42.440 될 필요가 없습니다. 00:16:42.760 --> 00:16:46.480 규제 요구 사항에 부합하는 형식으로 에이전트 활동 기록을 생성할 수 00:16:46.480 --> 00:16:46.880 있습니다. 00:16:47.180 --> 00:16:50.460 이는 인적 업무 부담을 줄여줄 뿐만 아니라 중요한 사항을 놓칠 00:16:50.460 --> 00:16:51.540 위험도 방지합니다. 00:16:51.760 --> 00:16:56.340 운영 측면에서도 사후의 일회성 감사 추적을 만드는 데 허비되는 수많은 00:16:56.340 --> 00:16:57.660 시간을 절약해 줍니다. 00:16:57.940 --> 00:17:01.440 모니터링이 강력한 이유는 전체 책임의 틀을 완전히 재구성하기 00:17:01.440 --> 00:17:02.040 때문입니다. 00:17:02.220 --> 00:17:06.100 불만 제기를 기다리는 대신 현재 상황을 실시간 지도로 파악할 수 있습니다. 00:17:06.100 --> 00:17:09.520 추세가 명확해지고 예상치 못한 상황이 발생할 확률은 낮아집니다. 00:17:09.520 --> 00:17:13.500 단순히 권한으로 규칙을 강제하는 것이 아니라 규칙이 실제로 잘 작동 00:17:13.500 --> 00:17:14.700 하는지 확인할 수 있습니다. 00:17:14.940 --> 00:17:19.720 이는 교차로의 표지판만 믿는 대신 실시간 교통 cctv로 도시를 지켜보는 00:17:19.720 --> 00:17:21.180 것과 같은 차이입니다. 00:17:21.420 --> 00:17:25.840 한 방식은 확신을 주지만 다른 방식은 다음 사고 소식을 불안하게 기다리게 00:17:25.840 --> 00:17:26.360 만듭니다. 00:17:26.520 --> 00:17:29.840 따라서 정책 통제와 모니터링을 결합하면 거버넌스 모델은 수동적 00:17:29.840 --> 00:17:32.320 인 상태에서 벗어나 진정으로 능동적으로 변합니다. 00:17:32.320 --> 00:17:35.980 추측은 감독으로 대체되며 이 감독 이야말로 몇 달 뒤에야 드러날 00:17:35.980 --> 00:17:38.220 잠재적 위험이 조용히 쌓이는 것을 막아줍니다. 00:17:38.220 --> 00:17:42.220 망로와 같은 관점은 최악의 시나리오를 방어할 뿐만 아니라 누군가 상황을 00:17:42.220 --> 00:17:45.420 주시하고 있다는 믿음을 주어 팀이 계속해서 실험할 수 있는 자신감을 00:17:45.420 --> 00:17:46.000 제공합니다. 00:17:46.200 --> 00:17:48.840 그리고 이는 자연스럽게 다음 질문으로 이어집니다. 00:17:49.000 --> 00:17:53.280 가시성이 이토록 강력하다면 왜 많은 조직이 여전히 이러한 보호책을 00:17:53.280 --> 00:17:56.540 무력화하는 전형적인 거버넌스 실수에 빠지는 걸까요? 00:17:57.640 --> 00:17:59.900 전형적인 거버넌스 실수 피하기. 00:17:59.900 --> 00:18:03.900 코파일럿 에이전트와 관련된 가장 큰 거버넌스 실패는 도구의 부재가 00:18:03.900 --> 00:18:06.900 아니라 도구를 잘못 사용하는 데서 비롯됩니다. 00:18:06.900 --> 00:18:10.900 제가 조직에서 목격한 대부분의 실수는 관리자가 관리센터를 모르거나 00:18:10.900 --> 00:18:14.040 코파일럿 스튜디오의 존재를 몰라서 발생한 것이 아닙니다. 00:18:14.240 --> 00:18:17.980 진짜 문제는 기능을 대규모로 올바르게 유지하기 위해 어떤 프레임워크가 00:18:17.980 --> 00:18:21.020 필요한지 고민하지 않은 채 기능을 활성화했다는 것입니다. 00:18:21.240 --> 00:18:25.240 마치 공동사무실의 열쇠를 모든 부서에 나눠주면서 밤에 누가 문을 00:18:25.240 --> 00:18:27.100 잠글지 정하지 않은 것과 같습니다. 00:18:27.100 --> 00:18:31.340 관리자가 활성화가 곧 거버넌스라고 가정하는 것이 흔한 패턴입니다. 00:18:31.480 --> 00:18:35.140 관리센터에 새 기능이 나타나면 스위치를 켜고 모두가 할 일을 다 00:18:35.140 --> 00:18:36.360 했다고 생각하는 식입니다. 00:18:36.580 --> 00:18:39.320 하지만 기술이 스스로 경계를 설정하지는 않습니다. 00:18:39.560 --> 00:18:43.680 권한이 불분명하거나 모니터링이 켜져 있지 않거나 팀 간 소통 없이 00:18:43.680 --> 00:18:47.160 소유권이 나뉘어 있다면 혼란은 조용하고 꾸준하게 스며듭니다. 00:18:47.360 --> 00:18:50.880 가장 무서운 점은 보통 즉각적인 문제가 발생하지 않는다는 것입니다. 00:18:51.140 --> 00:18:55.800 서서히 쌓이다가 감사, 사건 또는 규제 관련 질문 한 번에 통제되고 있다고 00:18:55.800 --> 00:19:00.000 믿었던 것들이 사실은 발견되길 기다리는 일련의 허점이었음이 드러나게 00:19:00.000 --> 00:19:00.320 됩니다. 00:19:00.580 --> 00:19:02.900 첫 번째 함정은 권한과 관련되어 있습니다. 00:19:03.260 --> 00:19:06.500 누가 에이전트를 만들고 게시하고 공유할 수 있는지 정의되지 않으면 00:19:06.500 --> 00:19:09.000 사용자들이 종종 스스로 그 빈자리를 채우게 됩니다. 00:19:09.200 --> 00:19:12.400 이는 에이전트 중복 생성, 테스트 없이 운영 환경에 게시되는 에이전트 00:19:12.400 --> 00:19:15.540 또는 접근해서는 안들 데이터에 접근하는 워크플로로 이어질 수 있습니다. 00:19:15.740 --> 00:19:19.680 명확한 경계가 없으면 IT 부서는 무언가 문제가 발생한 뒤에야 알게 되는 00:19:19.680 --> 00:19:21.480 섀도우 자동화 목록을 떠안게 됩니다. 00:19:21.480 --> 00:19:24.960 접근 권한을 제한하지 않고 기능을 활성화하는 것은 혁신을 지원하는 것이 00:19:24.960 --> 00:19:26.900 아니라 백지수표를 나눠주는 것과 같습니다. 00:19:27.160 --> 00:19:29.360 두 번째 함정은 모니터링을 건너뛰는 것입니다. 00:19:29.580 --> 00:19:33.060 권한 설정만으로 충분하다고 생각했던 관리자들을 자주 보았지만 실제로는 00:19:33.060 --> 00:19:35.800 그 규칙들이 제대로 작동하는지에 대한 통찰력이 전혀 없었습니다. 00:19:36.040 --> 00:19:38.400 그 결과 무슨 일이 일어나고 있는지 전혀 알지 못하게 됩니다. 00:19:38.640 --> 00:19:41.480 감사 로그를 켜두지 않으면 누가 무엇을 했는지 증명할 수 없습니다. 00:19:41.780 --> 00:19:45.800 사용량 지표를 확인하지 않으면 어떤 에이전트가 널리 쓰이는지 활동 패턴이 00:19:45.800 --> 00:19:47.160 비정상적인지 알 수 없습니다. 00:19:47.160 --> 00:19:51.240 그런 데이터 없이 운영하는 것은 잠시동안은 괜찮아 보이지만 외부 규제기관이나 00:19:51.240 --> 00:19:54.520 사내 규정 준수팀이 답변할 수 없는 질문을 던지는 순간 문제가 됩니다. 00:19:54.700 --> 00:19:56.820 일관성 없는 정책은 세 번째 지뢰입니다. 00:19:57.060 --> 00:20:01.320 조직의 한 부서는 영격하게 관리하지만 다른 부서는 개시 권한을 완전히 열어둘 수 있습니다. 00:20:01.540 --> 00:20:04.540 이러한 불일치는 통제되는 에이전트와 통제되지 않는 에이전트가 같은 00:20:04.540 --> 00:20:06.460 패넌트 내에 뒤섞이는 혼란을 야기합니다. 00:20:06.660 --> 00:20:11.040 외부에서 보기에는 정책이 존재하기 때문에 전략을 잘 수립했다고 생각할 수도 있습니다. 00:20:11.320 --> 00:20:15.280 하지만 규정 준수팀과 보안검토팀은 정책이 존재한다는 증거를 넘어 00:20:15.280 --> 00:20:18.080 조직 전체에 일관되게 적용되고 있다는 증거를 원합니다. 00:20:18.280 --> 00:20:21.840 지역마다 다른 규제가 적용되는데 자체 정책이 이에 부합하지 않을 경우 00:20:21.840 --> 00:20:24.640 이러한 격차는 방어하기가 훨씬 더 어려워집니다. 00:20:24.800 --> 00:20:27.220 다음은 전형적인 소유권 분절 사례입니다. 00:20:27.460 --> 00:20:31.020 IT 부서는 규칙을 정하고 보안팀은 다른 계층의 보호를 가정하며 00:20:31.020 --> 00:20:33.960 사업 부서는 마음대로 개시할 수 있다고 생각할 수 있습니다. 00:20:34.160 --> 00:20:36.660 각 그룹은 다른 누군가가 사각지대를 지키고 있을 거라 생각하지만 00:20:36.660 --> 00:20:38.120 실제로는 아무도 지키지 않습니다. 00:20:38.300 --> 00:20:41.280 이러한 명확성 부족은 중복된 권한이나 최종 권한을 가진 팀이 00:20:41.280 --> 00:20:44.820 불분명하여 발생하는 에이전트 유출 같은 예방 가능한 문제들을 만들어냅니다. 00:20:45.000 --> 00:20:47.420 제가 대화했던 한 회사가 정확히 이런 경험을 했습니다. 00:20:47.740 --> 00:20:50.500 그들은 모든 직원에게 에이전트를 자유롭게 개시할 수 있도록 허용했습니다. 00:20:50.780 --> 00:20:52.580 처음에는 권한을 부여하는 것처럼 보였습니다. 00:20:52.800 --> 00:20:54.580 모두가 실험하고 개선사항을 내놓을 수 있었지만 00:20:54.580 --> 00:20:57.060 누구도 개시 권한과 감사 로그를 연결해두지 않았습니다. 00:20:57.220 --> 00:21:00.800 몇 달 후 규제기관이 특정 자동화를 누가 배포했는지 증명하라고 요구했을 때 00:21:00.800 --> 00:21:02.440 그들이 가진 자료는 아무것도 없었습니다. 00:21:02.680 --> 00:21:04.620 기록도 없었고 책임자도 없어둬며 00:21:04.620 --> 00:21:06.960 감사 시 자신을 방어할 능력조차 없었습니다. 00:21:06.960 --> 00:21:11.540 자동화를 대중화하려는 노력으로 시작된 일이 결국 심각한 규정 준수 결함으로 이어졌습니다. 00:21:11.700 --> 00:21:15.900 이러한 사례들은 작은 실수가 어떻게 빠르게 대규모 위험으로 변할 수 있는지를 잘 보여줍니다. 00:21:16.060 --> 00:21:20.120 권한 설정 오류나 관리되지 않는 에이전트는 소규모 파일럿 단계에서는 사소해 보일 수 있지만 00:21:20.120 --> 00:21:25.380 기업 규모에서는 똑같은 실수가 알려지지 않은 곳에서 수백 개의 에이전트가 실행되는 결과로 이어집니다. 00:21:25.540 --> 00:21:27.520 문제는 선형적으로 증가하지 않습니다. 00:21:27.780 --> 00:21:33.800 모든 통제되지 않은 에이전트가 데이터 무결성, 신뢰성, 보완에 반한 의문을 남기기 때문에 문제는 기하급수적으로 커집니다. 00:21:33.800 --> 00:21:37.460 다행인 점은 함정이 무엇인지 잘 알려져 있고 이를 피할 방법도 있다는 것입니다. 00:21:37.600 --> 00:21:40.400 관리센터에서 기본 가드레일을 정의하는 것부터 시작하세요. 00:21:40.620 --> 00:21:43.600 누가 빌드하고 누가 게시할 수 있는지 명확한 역할을 설정하세요. 00:21:43.800 --> 00:21:48.140 모니터링을 선택사항이 아닌 필수로 만들어 문제가 심각해지기 전에 알림을 받도록 하세요. 00:21:48.340 --> 00:21:53.500 지역 간에도 정책을 일관되게 유지하여 버버넌스 프레임워크를 자신있게 뒷받침할 수 있도록 하세요. 00:21:53.720 --> 00:21:57.780 그리고 무엇보다 중요한 것은 첫날부터 보안 및 규정 준수팀과 협력하는 것입니다. 00:21:58.020 --> 00:22:00.580 나중으로 미루면 거의 항상 역효과가 발생합니다. 00:22:00.580 --> 00:22:03.720 이미 수많은 조직이 효과적인 플레이북을 만들어두었습니다. 00:22:04.020 --> 00:22:08.700 분기별 정책 검토 체크리스트, 감사로깅을 게시 권한과 직접 연결하는 정책, 00:22:09.080 --> 00:22:12.980 IT 부서의 공식 배포 전 혁신팀이 먼저 실험하는 프레임워크 등이 그 예입니다. 00:22:13.200 --> 00:22:17.040 이러한 경험을 활용한다는 것은 그들의 실수를 되풀이할 필요가 없다는 것을 의미합니다. 00:22:17.220 --> 00:22:23.240 다른 기업들이 실패를 보고했을 때 그 원인은 대부분 가드레일이 문서상으로는 존재했으나 실제로는 제대로 적용되지 않았기 때문이었습니다. 00:22:23.420 --> 00:22:26.380 그들의 교훈을 조기에 내재화함으로써 여러분은 비용을 피할 수 있습니다. 00:22:26.380 --> 00:22:27.380 감사합니다. 00:22:27.380 --> 00:22:28.380 감사합니다. 00:22:28.380 --> 00:22:29.380 감사합니다.