Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Copilot 에이전트 거버넌스: Microsoft 365 관리 센터와 Copilot Studio로 완벽하게 통제하기 (AI 더빙)

Transcript

Copilot 에이전트 거버넌스: Microsoft 365 관리 센터와 Copilot Studio로 완벽하게 통제하기 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365, 코파일럿, AI, 에이적, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?
0:08
이번 1월, M365 컨이더 커진 규모로 돌아옵니다.
0:12
전세계 MVP와 업계 전문가들이 전하는 라이브 세션, 실전 데모, 실용적인 지식을 함께하세요.
0:18
뻔한 슬라이드나 끝없는 유행원은 없습니다.
0:21
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제를 다룹니다.
0:29
IT 전문가, 개발자, 비즈니스 리더 등 누구에게나 맞는 세션이 준비되어 있습니다.
0:35
10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 연결될 수 있습니다.
0:40
라이브로 시청하고 실무에 바로 적용할 수 있는 인사이트를 얻어가세요.
0:44
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티 등록이 지금 시작되었습니다.
0:52
지금 바로 자리를 확보하세요.
0:56
m365.com.net입니다.
0:58
m365.com.net에서 등록하시고 1월 라이브 행사에서 뵙겠습니다.
1:04
AI 에이전트가 여러분도 모르는 사이에 결정을 내리기 시작한다면 무슨 일이 벌어질까요?
1:09
오늘 세션에서는 거버넌스가 왜 더 이상 선택사항이 아닌지,
1:12
그리고 마이크로소프트 365 관리센터가 어떻게 필요한 제어판을 제공할 수 있는지 알아봅니다.
1:16
에이전트가 제멋대로 작동하지 않도록 방지하면서 팀이 필요한 것을 구축할 수 있도록 지원하는 정확한 도구를 살펴보겠습니다.
1:21
통제력을 잃지 않으면 서코파일럿 위 이점을 활용하는 방법이 궁금하셨다면 제대로 찾아오셨습니다.
1:27
왜 많은 조직이 AI 에이전트를 두려워할까요?
1:30
AI 에이전트의 이점이 서류상으로 명확해 보이는데도 왜 기업들은 망설이는 걸까요?
1:34
수작업 감소, 더 빠른 위사 결정, 데이터 활용 능력 향상 때문이죠.
1:38
표면적으로는 쉽게 승인할 수 있는 성공 사례처럼 보입니다.
1:40
하지만 논의가 슬라이드에서 실제 배포 단계로 넘어가면 리더십 팀이 주춤하는 것을 볼 수 있습니다.
1:45
이러한 망설임은 기술에 대한 신뢰가 부족해서가 아닙니다.
1:49
수백, 수천 개의 작은 자동화 작업이 명확한 감독 없이 백그라운드에서 실행될 때 어떤 일이 벌어질지 모른다는 두려움 때문입니다.
1:56
거대한 잠재력과 그만큼 큰 불확실성 사이의 긴장감 때문에 많은 조직이 예상보다 훨씬 오래 파일럿 모드에 머물러 있습니다.
2:04
사실 AI 에이전트가 사람들을 불안하게 만드는 이유는 다른 도구들처럼 작동하지 않기 때문입니다.
2:09
엔드포인트 관리로 직원이 새 생산성 앱을 설치하는 시점을 제어하거나 소프트웨어를 차단할 수는 있지만 에이전트는 기존의 틀 안에 깔끔하게 들어맞지 않습니다.
2:16
에이전트는 때로는 빠르게, 때로는 여러 시스템에 걸쳐 작동하도록 설계되었습니다.
2:20
일단 배포되면 스스로 움직이는 것처럼 느껴질 수 있습니다.
2:23
통제, 표준화, 거버넌스라는 관점에서 생각하도록 훈련받은 IT 리더들에게는 눈에 보이지 않는 백그라운드 프로세스가 실제 정보 흐름을 형성한다는 사실이 조직에 대한 통제력을 잃는 것처럼 느껴질 수 있습니다.
2:32
이런 상황이 어떻게 전개되는지 보여주는 사례는 아주 많습니다.
2:35
한 연구팀이 데이터 세트를 추출하고 정리하는 봇을 실행합니다.
2:38
누군가 그 작동 모습을 보고 약간 수정하여 복제합니다.
2:41
몇 주 안에 회사는 잘 관리된 에이전트 하나를 운영하는 것이 아니게 됩니다.
2:44
버전 관리도 없고 책임자도 불분명한, 작은 차이만 있는 20개의 복제본이 운영됩니다.
2:49
이제 베를린의 분석가는 뉴욕의 관리자가 사용하는 것과는 조금 다른 데이터 세트로 위사결정을 내리고,
2:55
재무팀은 두 버전 모두 보고서에 반영되면서 혼란에 빠집니다.
2:58
이를 각자 속도를 높이려는 수십 개의 부서로 확대해보면,
3:02
생산성 향상은 순식간에 도대체 어떤 수치를 믿어야 할지 모르는 상황으로 변질됩니다.
3:07
자동화가 결코 건드려서는 안 될 영역까지 침범한 사례도 보았습니다.
3:11
한 회사는 온 보딩을 간소화하려고 내부 스크립트가 고객 정보를 시스템 간에 조용히 이동시키게 했지만,
3:17
데이터 전송이 규정 준수 표준을 따르는지 검토한 사람은 아무도 없었습니다.
3:21
감사관들이 들이 닥쳤을 때, 두 직은 누가 스크립트를 작성했는지, 왜 실행되었는지, 어떤 규칙을 따랐는지에 대한 기록을 전혀 제시하지 못했습니다.
3:28
그것은 AI 기능의 실패가 아니었습니다. 그것은 감독의 실패였습니다.
3:32
시간을 절약하기 위해 설계된 기술이 회사 역사상 가장 큰 규정 준수 골칫거리를 만들어낸 것입니다.
3:37
리더들이 신중하게 반응하는 이유는 어렵지 않게 알 수 있습니다.
3:40
경계없는 에이전트를 도입하는 것은 모든 직원에게 드론을 쥐어주고 마음대로 날리게 하는 것과 같습니다.
3:46
처음 몇 대는 원활하게 이륙할지 몰라도, 곧 하나는 건물에 충돌하고, 다른 하나는 행방불명되며, 세 번째는 응급 헬기에 착륙을 방해하게 됩니다.
3:55
관제탑이 없다면 효율성을 높여야 할 바로 그 기술이 공공의 위험이 됩니다.
4:00
지식 노동에서도 동일한 원칙이 적용됩니다.
4:03
자동화 자체가 두려움의 원인은 아닙니다.
4:05
통제의 부재가 두려움의 원인입니다.
4:07
설문조사 결과는 이러한 이야기들에서 이미 짐작할 수 있는 내용을 뒷받침합니다.
4:10
임원들은 엔터프라이즈 AI에 대한 핵심 우려사항으로 규정 준수, 보안, 데이터 유출을 지속적으로 꼽습니다.
4:16
기술이 성과를 내는지 여부는 문제가 되지 않는 경우가 많습니다.
4:19
우려는 잘못된 정보가 유출되거나, 사후에 아무도 추적할 수 없는 조치를 보시 취할까 하는 것입니다.
4:25
단순한 운영상의 실수가 문제가 아닙니다.
4:28
이는 평판, 규제의 위험, 고객 신뢰와 직결되는 문제입니다.
4:32
고객이 귀사에 자동화가 노출해서는 안 될 데이터를 노출했다고 믿게 되면, 신뢰를 회복하는 데 수년이 걸립니다.
4:37
그렇기에 진짜 문제를 정확하게 정의하는 것이 중요합니다.
4:40
기업은 코파일럿, 에이전트 그 자체를 두려워하지 않습니다.
4:43
기업은 에이전트를 통제하지 못하는 것을 두려워합니다.
4:45
누가 어떤 에이전트를 만들었는지, 마지막으로 검토한 시점이 언제인지, 왜 민감한 시스템에서 정보를 가져오는지 잊어버리는 것을 두려워합니다.
4:51
문제는 소프트웨어가 아니라, 신뢰성과 예측 가능성을 유지하고, 조직의 규칙에 맞게 작동하도록 하는 안전장치가 없다는 점입니다.
4:57
일단 그렇게 바라보면 나아갈 길이 훨씬 명확해집니다.
4:59
바로 이 지점에서 대부분의 사람들이 놀라곤 합니다.
5:02
많은 조직이 부재하다고 느끼는 제어판은 사실 이미 마이크로소프트 365 안에 있습니다.
5:07
별도의 추가 기능이 아닙니다. 숨겨진 프리미엄 기능도 아닙니다.
5:10
관리센터에 이미 내장되어 있습니다.
5:12
많은 조직이 포털을 라이선스 할 땅이나 기본적인 팀제정책 설정용으로만 사용하지만,
5:17
사실 이곳은 조용히 코파일럿 에이전트를 위한 항공 관제탑 역할을 해왔습니다.
5:21
다시 말해, 여러분에게 필요한 안전장치는 이미 여러분 앞에 놓여 있습니다.
5:24
관건은 여러분이 올바른 패널을 열었느냐 하는 것뿐입니다.
5:27
여러분에게 있는지 조차 몰랐던 제어판입니다.
5:29
AI 에이전트를 관리하기 위한 조종석이 이미 여러분 앞에 있었고,
5:33
단지 대부분의 관리자가 알아차리지 못했던 것이라면 어떨까요?
5:35
믿기 어렵겠지만, 사실 마이크로소프트 365 관리센터는 많은 조직이 그토록 찾아 헤매던 제어 장치를 조용히 품고 있습니다.
5:43
아이러니하게도 많은 IT팀이 매일이 포털을 열면서도 에이전트 거버넌스의 가장 중요한 부분은 무심코 지나치고 있습니다.
5:50
생각해보면 익숙함이 오히려 방해가 되는 상황 중 하나입니다.
5:54
내용을 잘 안다고 가정하기 때문에 평소 무시하던 탭 뒤에 새로운 제어 수단이 숨겨져 있으리라고는 예상하지 못하는 것이죠.
6:00
수년간 관리센터는 단순한 유틸리티 패널처럼 취급되어 왔습니다.
6:04
라이선스를 배포하고, 익스체인지 사소함을 구성하고, 팀제 정책을 한두 개 조정하기 위해 열어보는 곳이었죠.
6:09
사용자에게 기능을 맵핑하고, 티켓을 요청한 사람들이 결국 원하는 서비스에 접근할 수 있도록 확인하는 작업 공간이었습니다.
6:16
종종 강과되는 점은 이곳이 얼마나 더 풍성해졌느냐 하는 것입니다.
6:19
같은 인터페이스 뒤에는 관리자가 단순히 접근 권한을 관리하는 것을 넘어, 사용자가 어떻게 자동화를 생성하고, 사용하고 공유하는지까지 통제할 수 있는 기능들이 계속 늘어나고 있습니다.
6:27
코파일럿 에이전트가 통제 범위를 벗어날까 봐 걱정해왔다면, 그 안전장치는 불과 몇 번이 클릭거리 안에 있습니다.
6:33
불일치는 분명합니다.
6:34
IT 포럼의 모든 대화는 AI로 인한 혼란, 부서마다 나타나는 정체불명의 봇, 민감한 데이터를 건드리는 자동화, 또는 미세하지만 치명적인 차이로 중복되는 워크플로우에 대한 두려움을 중심으로 돌아갑니다.
6:46
하지만 정작 그런 걱정을 하는 조직들은 바로 그러한 문제를 막기 위해 설계된 중앙 대시보드는 거의 쳐다보지도 않습니다.
6:52
이상한 불일치입니다.
6:53
통제력을 잃을까 두려워하면서도, 비행을 조율하기 위해 존재하는 제어판을 제대로 활용하지 못하고 있습니다.
6:58
이는 모퉁이의 신호 등은 무시한 채 예측 불가능한 교통 상황을 불평하는 것과 같습니다.
7:03
대규모 기업 내부의 전형적인 시나리오를 상상해보십시오.
7:06
마케팅 부서에서는 고객 피드백 수집을 위해 에이전트를 만들고, 운영 부서에서는 주문 추적을 간소화할 곳을 설계합니다.
7:12
위도적 인시에도 IT는 하나도 없습니다.
7:14
그저 업무를 더 쉽게 만들려는 열정적인 직원들의 노력일 뿐입니다.
7:17
하지만 에이전트가 출시되면 통합된 기록 없이 여러 사일로로 흩어지게 됩니다.
7:21
IT 부서가 이를 발견했을 때는 이미 누가 무엇을 소유하고 있는지, 어떤 데이터 소스를 활용하는지 알 수 없는 상태입니다.
7:26
갑자기 규정 준수 관련 대화가 탐정 작업으로 변해버립니다.
7:29
도대체 누가 이걸 만든 걸까요? 언제 업데이트 되었나요? 어떤 권한이 암묵적으로 상속되었나요?
7:34
명확한 감독이 없으면 작은 자동화라도 눈덩이처럼 불어나 예상치 못한 규정 준수 격차를 만듭니다.
7:39
관리센터는 이러한 보이지 않는 활동을 한 곳으로 모아이 문제를 직접 해결합니다.
7:43
추측할 필요 없이 어떤 에이전트가 존재하고, 어떤 커넥터에 의존하며, 누가 수정하거나 개시할 권한이 있는지 확인할 수 있습니다.
7:50
정책을 통해 애초에 어떤 그룹이 자동화를 만들 수 있는지 정의함으로 실험과 공식 배포를 분리할 수 있습니다.
7:56
한 팀 내에서 내부 프로토타입을 만드는 것과 전체 CRM이나 HR 플랫폼에 영향을 주는 기능을 설정하는 것은 매우 다르기 때문에 이는 매우 중요합니다.
8:04
관리센터는 이 두 영역을 구분하도록 해줍니다. 권한 관리는 안전성을 한층 더 높여줍니다.
8:09
열정적인 모든 직원이 에이전트를 구축할 뿐만 아니라 전체 테넌트에 배포할 수 있다면 얼마나 위험할지 상상하기 쉽습니다.
8:16
더 나은 모델은 아이디어 구축에는 폭넓은 참여를 허용하되 배포 권한은 지정된 역할로 제한하는 것입니다.
8:22
실제로 재무 분석가는 보고 요구사항에 맞춰 초안 에이전트를 만들고 IT 거버넌스 팀만이 해당 초안을 프로덕션 환경으로 배포할지 결정하는 방식이 될 수 있습니다.
8:33
관리센터 내에서 이러한 규칙을 구성함으로써 누가 공역의 규칙을 정할지 미리 결정하게 됩니다.
8:38
보고 기능은 마지막 단계를 완성합니다.
8:40
무엇인가 고장나서야 보세 존재를 알게 되는 대신 사용 추세를 추적하고 어떤 부서가 활발히 실험하는지 파악하며 터진 스프레드 시트를 뒤질 필요 없이 감사를 수행할 수 있습니다.
8:49
이러한 데이터 기반 관점은 규정 준수를 넘어 전략 수립에 도움을 줍니다.
8:54
지원팀들이 비슷한 에이전트를 반복적으로 만들고 있다면 수십 개의 유사한 봇을 방치하기보다는 표준화된 솔루션에 투자할 때가 된 것입니다.
9:02
가시선과 통제력을 결합하면 자동화는 골칫거리에서 관리 가능한 기회로 바뀝니다.
9:07
따라서 에이전트가 제멋대로 돌아다니는 것을 상상하는 대신 관리센터를 항공관제탑으로 생각하십시오.
9:13
모든 비행계획은 기록되고 모든 출발은 정책에 따라 승인되며 누군가 전체 하늘을 보고 있기 때문에 충돌은 발생하지 않습니다.
9:20
하나의 중앙데시보드가 이러한 강력한 기능을 갖추고 있음을 알게 되면 에이전트를 숨겨진 위협으로 대하는 대신 구조화된 운영 방식으로 관리하게 될 것입니다.
9:28
이러한 프레임워크가 마련되면 대화의 방향이 바뀝니다.
9:31
관리자는 감독 권한을 갖지만 직원들은 여전히 규정을 어기지 않으면 서 자유롭게 구축하고 실험할 공간이 필요하기 때문입니다.
9:37
바로 그 지점에서 코파일러 스튜디오가 역할을 합니다.
9:40
혼란 없는 혁신, 코파일러 스튜디오의 활약입니다.
9:43
조직을 혼란에 빠뜨리지 않으면 서직원들이 직접 AI 기반 솔루션을 만들게 하려면 어떻게 해야 할까요?
9:49
그것이 바로 코파일러 스튜디오와 관련된 핵심 과제입니다.
9:52
한편으로 이 도구는 부서 전반의 창의성을 발휘하도록 설계되어
9:55
일상의 고충을 가장 잘 이해하는 사람들이 이를 직접 자동화할 기회를 제공합니다.
10:00
다른 한편으로 감독 없이 구축 도구를 배포하면 통제되지 않은 워크플로우가 급증하여
10:04
IT 부서가 실제로 무엇이 실행 중인지 파악하느라 애를 먹을 수 있습니다.
10:09
처음 보기엔 까다로운 균형처럼 보입니다.
10:11
사용자에게 권한을 부여하고 혼란을 감수할까요?
10:14
아니면 모든 것을 잠그고 발전을 저해할까요?
10:16
코파일러 스튜디오는 그 중간 지점을 자처합니다.
10:18
직원들이 솔루션을 시도하고 상호작용을 테스트하며
10:21
업무 방식을 개선하기 위해 에이전트를 게시할 수 있는 워크숍이라고 생각하세요.
10:25
이것과 과거의 DIY 자동화 사이의 차이는 간단합니다.
10:29
플랫폼의 안전장치가 이미 내장되어 있습니다.
10:31
IT 부서에 사후 수습을 맡기는 대신
10:34
스튜디오는 관리센터에서 관리하는 것과
10:37
동일한 거버넌스 원칙을 설계 환경에 직접 반영합니다.
10:40
그것이 도구를 위험한 것이 아닌 실용적인 것으로 만듭니다.
10:43
그럼에도 관리자가 느끼는 긴장감은 매우 현실적입니다.
10:46
열정적인 직원이 스크립팅 도구를 손에 넣었을 때
10:48
어떤 일이 벌어지는지 본 적이 있다면
10:49
단순한 테스트가 얼마나 빨리 미션 크리티컬 한 위존성으로 발전하는지 알 것입니다.
10:53
문제는 악의가 아니라는 점입니다.
10:55
대부분의 사용자는 단지 자신의 업무 병목 현상을 해결하고 싶어 할 뿐입니다.
10:58
하지만 로컬에서 구축된 솔루션이 고객 데이터, 재무 기록 또는 인사 파일과 상호작용하기 시작하면
11:03
유용한 실험에서 순식간에 규정 준수 영역으로 넘어가게 됩니다.
11:06
일단 그 경계를 넘어서면 책임과 감독은 더 이상 선택사항이 아닙니다.
11:11
이런 시나리오를 그려보세요.
11:12
재무 분석가가 고객 잔액을 자동으로 가져와 주간보고서를 생성하는 에이전트를 만듭니다.
11:18
수동 작업 시간을 몇 시간이나 절약해 주어 금세 인기를 얻습니다.
11:21
몇몇 동료들이 이를 가져다 쓰고 곧 부서 전체로 퍼져나갑니다.
11:25
하지만 문제는 여기서 발생합니다.
11:26
누가 그 에이전트가 민감한 필드를 노출하지 않는다고 보장했나요?
11:30
데이터 소스가 금융정보 처리에 관한 규정 준수 규칙을 따랐는지 누가 확인했나요?
11:34
규제기관이 조사를 나온다면 이것이 사이드 프로젝트가 아니라
11:37
정책에 따라 구축 및 배포되었다는 것을 누가 증명할까요?
11:40
적절한 구조가 없으면 그 단순한 보순 책임 소재가 됩니다.
11:44
바로 이 지점에서 코파일러 스튜디오 가 상황을 경고하게 만듭니다.
11:47
이 플랫폼은 모든 제작자가 전문 개발자라고 가정하지 않습니다.
11:50
전체 설계에는 비기술 사용자를 위한 보호 기능이 포함되어 있습니다.
11:53
관리자는 사용 가능한 작업과 커넥터 그리고 프로덕션 환경에 배포할 권한을 가진 사용자를 정의합니다.
11:59
직원들은 완전한 창의적 자유를 누린다고 느낄 수 있지만 실제로는 세심하게 제한된 범위 내에서 실험이 이루어집니다.
12:05
이러한 차이 덕분에 기업은 또 다른 섀도우 IT 문제에 직면하지 않고도 에이전트 도입을 확장할 수 있습니다.
12:10
제어 지점은 구체적입니다.
12:12
마케팅 부서에 모든 직원이 에이전트 초안을 만들게 할 수 있지만
12:14
샌드박스 환경을 넘어 이를 게시할 수 있는 사람은 지정된 개인으로 제한할 수 있습니다.
12:17
셰어포인트나 다이나믹스와 같이 승인된 커넥터만 사용 가능하게 할 수도 있습니다.
12:22
민감한 타사 서비스와 연결되는 모든 항목은 사용이 제한됩니다.
12:25
그뿐만 아니라 어떤 시스템 작업을 제한할지도 직접 결정할 수 있습니다.
12:28
예를 들어 데이터베이스 조회는 허용하되
12:30
실수로 인한 피해를 방지하기 위해 주요 필드를 직접 업데이트하는 것은 차단할 수 있습니다.
12:34
요약하자면 사용자는 아이디어를 자유롭게 시도할 수 있지만
12:37
명시적인 승인 없이는 프로덕션 기록을 변경할 수 없습니다.
12:39
간단한 비유가 도움이 됩니다.
12:41
놀이터의 모래 상자와 같습니다.
12:43
아이들은 상자 안에서 원하는 만큼 성을 쌓을 수 있지만
12:45
상자 주변에는 명확한 경계가 있습니다.
12:48
울타리는 놀이를 안전하게 유지하면서도
12:50
창의성을 발휘할 충분한 여지를 남겨둡니다.
12:52
스튜디오는 에이전트 구축에도 동일한 개념을 적용합니다.
12:55
직원들은 혁신에 필요한 자유를 얻고
12:57
관리자는 보이지 않는 울타리가
12:59
실제 위험으로 확장되는 것을 막고 있음을 알게 됩니다.
13:02
따라서 적절한 권한과 정책으로 코파일럿 스튜디오를 설정하면
13:06
보안 골칫거리가 아닌 본래 의도된 안전한 혁신 실험실이 됩니다.
13:09
각 부서는 업무에 맞는 에이전트를 탐색하고 새로운 방식을 실험하며
13:13
초기 아이디어를 공유할 수 있습니다.
13:14
이 모든 과정은 규정을 준수하고 승인되지 않은 워크플로우를 생성하지
13:17
않은 범위 내에서 이루어집니다.
13:19
혁신은 계속되지만 혼란은 발생하지 않습니다.
13:21
그러한 보호장치가 있더라도 간과할 수 없는 한 가지 안전장치가 더
13:24
있는데 바로 가시성입니다.
13:26
가드레일이 아무리 강력하더라도 실시간으로 어떤 일이 벌어지는지
13:28
계속 지켜봐야 하기 때문입니다.
13:30
그것이 바로 모니터링과 추적이 필요한 이유입니다.
13:32
감시탑처럼 에이전트 활동을 모니터링하고 추적하는 것입니다.
13:35
만약 에이전트가 보이지 않는 곳에서 수백 번의 결정을 조용히 내린다면
13:38
어떻게 될까요?
13:39
이는 결코 비현실적인 시나리오가 아닙니다.
13:41
조직이 통제수단은 마련했지만 나머지 절반을 잊었을 때 정확히 발생할
13:45
수 있는 일입니다.
13:46
권한과 정책은 울타리와 같습니다.
13:48
직원들이 어디에서 작업할 수 있고 어떤 도구를 사용할 수 있는지
13:51
알려줍니다.
13:52
하지만 가시성이 없으면 누군가 확인되지 않은 구역으로 들어갔는지
13:55
혹은 에이전트가 의도된 범위를 벗어나 조용히 작동 중인지 알 방법이
13:59
없습니다.
13:59
모니터링은 이 거버넌스 이야기를 추측해서 명확성으로 바꾸는 핵심
14:03
요소입니다.
14:06
우리가 평소에 IT문제를 어떻게 다루는지 생각해보십시오.
14:07
무언가 고장나고 사용자가 티켓을 제출하면 우리는 무엇이 바뀌었는지
14:10
부랴부랴 추적해야 합니다.
14:11
그것은 수동적인 대응 방식입니다.
14:13
작은 규모에서는 효과가 있을지 몰라도 수백 개의 자동화로 확장
14:16
되면 감당하기 힘든 골칫거리가 됩니다.
14:18
AI 에이전트의 경우 문제가 너무 늦게 발견될 수 있어 위험 요소가
14:21
훨씬 큽니다.
14:22
제멋대로 작동하는 워크플로우는 아무도 모르는 사이에 몇 주 동안
14:25
인하 실행될 수 있습니다.
14:25
눈에 띄는 오류를 일으키는 것이 아니라 겉보기에는 정상적인 결정을
14:29
조용히 내리기 때문입니다.
14:30
왜 데이터가 맞지 않는지 누군가 묻게 될 때쯤이면 미래를 예방하는
14:33
대신 과거를 조사하느라 바쁠 것입니다.
14:35
모니터링은 이러한 흐름을 완전히 바꿔놓습니다.
14:38
눈을 감고 일하는 대신 어떤 에이전트가 존재하고 누가 만들어두면 어떻게
14:41
사용되고 있는지 실시간으로 파악할 수 있습니다.
14:43
마이크로소프트 365는 이러한 가시성을 자체 생태계 안에 내장하고
14:46
있습니다.
14:47
사용 분석을 통해 어떤 부서가 에이전트를 빠르게 도입하는지 누가 에이전트를
14:51
많이 만드는지 어디에서 예기치 않은 활동이 시작되는지 파악할 수
14:55
있습니다.
14:56
감사 로그는 세부사항을 추적합니다.
14:58
에이전트가 언제 수정되었는지 어떤 커넥터에 연결되었는지 누가 작업을
15:01
실행했는지 기록합니다.
15:02
이런 기록은 단순히 규정 준수를 만족시키는 것 이상의 역할을 합니다.
15:05
이는 추측에 의존하는 대신 실제 운영 환경을 제대로 이해할 수 있게
15:08
해줍니다.
15:09
이러한 통찰의 가치는 매우 평범한 시나리오를 상상해보면 분명해집니다.
15:13
마케팅팀이 고객 피드백 설문조사를 분석하기 위해 에이전트를 만듭니다.
15:16
처음에는 한 번이 캠페인과 수천 건의 데이터로 작게 시작하지만 결과는
15:20
유용해 보입니다.
15:21
시간이 지나면서 누군가 이를 다른 프로젝트에 복제하고 또 다른 팀이
15:24
템플릿을 가져와 수정하기 시작합니다.
15:26
모니터링이 없으면 이제 여러 버전의 에이전트가 병렬로 실행되며 각각
15:30
데이터에 조금씩 다르게 접근하게 됩니다.
15:32
방치해두면 이러한 차이는 결국 보고서에까지 스며들어 고의 의사 결정자들을
15:36
혼란스럽게 합니다.
15:37
모니터링을 켜두면 에이전트 사용 급증을 조기에 감지하고 늘어나는 중복
15:42
버전을 발견하여 공식 버전을 표준화하거나 혼란을 야기하기 전에
15:45
추가 버전들을 정리할 수 있습니다.
15:48
때로는 가시성 하나가 사소한 수정 으로 끝낼지 아니면 대형 사고로
15:51
이어질지를 결정짓습니다.
15:53
내부 예측 속도를 높이기 위해 민감한 재무 데이터를 가져오는 에이전트
15:56
의 사례를 생각해 보십시오.
15:58
만약 실수로 너무 많은 세부 정보가 노출되거나 재무부서 외부로 데이터
16:01
가 공유된다면 규정 준수 위험이 빠르게 커질 것입니다.
16:04
하지만 모니터링이 있다면 비정상적인 접근이 로그에 명확하게 나타납니다.
16:08
규제기관이나 고객이 문제를 제기하기 전에 해당 에이전트를 중지하거나
16:11
권한을 조정할 수 있습니다.
16:13
이는 제작자의 나쁜 의도를 가정하라는 뜻이 아닙니다.
16:15
아무리 신중한 팀이라도 실험 과정에서 실수를 할 수 있다는 점을 인정해야
16:19
한다는 것입니다.
16:20
가시성은 그러한 실수를 재앙이 아닌 되돌릴 수 있는 것으로 만들어줍니다.
16:23
보고 기능은 또한 감사인과의 관계를 원만하게 만들어줍니다.
16:27
감사를 받아본 사람이라면 누구든 문서 수집, 승인 내역 확인, 변경
16:30
시점 파악, 통제 조치 이행 여부 확인을 위해 고군분투했던 고통스러운
16:33
경험을 알고 있을 겁니다.
16:35
수동 추적은 오류가 발생하기 쉽고 스트레스가 큽니다.
16:38
보고 시스템이 이미 해당 기록을 보관하고 있다면 더 이상 허둥
16:41
될 필요가 없습니다.
16:42
규제 요구 사항에 부합하는 형식으로 에이전트 활동 기록을 생성할 수
16:46
있습니다.
16:47
이는 인적 업무 부담을 줄여줄 뿐만 아니라 중요한 사항을 놓칠
16:50
위험도 방지합니다.
16:51
운영 측면에서도 사후의 일회성 감사 추적을 만드는 데 허비되는 수많은
16:56
시간을 절약해 줍니다.
16:57
모니터링이 강력한 이유는 전체 책임의 틀을 완전히 재구성하기
17:01
때문입니다.
17:02
불만 제기를 기다리는 대신 현재 상황을 실시간 지도로 파악할 수 있습니다.
17:06
추세가 명확해지고 예상치 못한 상황이 발생할 확률은 낮아집니다.
17:09
단순히 권한으로 규칙을 강제하는 것이 아니라 규칙이 실제로 잘 작동
17:13
하는지 확인할 수 있습니다.
17:14
이는 교차로의 표지판만 믿는 대신 실시간 교통 cctv로 도시를 지켜보는
17:19
것과 같은 차이입니다.
17:21
한 방식은 확신을 주지만 다른 방식은 다음 사고 소식을 불안하게 기다리게
17:25
만듭니다.
17:26
따라서 정책 통제와 모니터링을 결합하면 거버넌스 모델은 수동적
17:29
인 상태에서 벗어나 진정으로 능동적으로 변합니다.
17:32
추측은 감독으로 대체되며 이 감독 이야말로 몇 달 뒤에야 드러날
17:35
잠재적 위험이 조용히 쌓이는 것을 막아줍니다.
17:38
망로와 같은 관점은 최악의 시나리오를 방어할 뿐만 아니라 누군가 상황을
17:42
주시하고 있다는 믿음을 주어 팀이 계속해서 실험할 수 있는 자신감을
17:45
제공합니다.
17:46
그리고 이는 자연스럽게 다음 질문으로 이어집니다.
17:49
가시성이 이토록 강력하다면 왜 많은 조직이 여전히 이러한 보호책을
17:53
무력화하는 전형적인 거버넌스 실수에 빠지는 걸까요?
17:57
전형적인 거버넌스 실수 피하기.
17:59
코파일럿 에이전트와 관련된 가장 큰 거버넌스 실패는 도구의 부재가
18:03
아니라 도구를 잘못 사용하는 데서 비롯됩니다.
18:06
제가 조직에서 목격한 대부분의 실수는 관리자가 관리센터를 모르거나
18:10
코파일럿 스튜디오의 존재를 몰라서 발생한 것이 아닙니다.
18:14
진짜 문제는 기능을 대규모로 올바르게 유지하기 위해 어떤 프레임워크가
18:17
필요한지 고민하지 않은 채 기능을 활성화했다는 것입니다.
18:21
마치 공동사무실의 열쇠를 모든 부서에 나눠주면서 밤에 누가 문을
18:25
잠글지 정하지 않은 것과 같습니다.
18:27
관리자가 활성화가 곧 거버넌스라고 가정하는 것이 흔한 패턴입니다.
18:31
관리센터에 새 기능이 나타나면 스위치를 켜고 모두가 할 일을 다
18:35
했다고 생각하는 식입니다.
18:36
하지만 기술이 스스로 경계를 설정하지는 않습니다.
18:39
권한이 불분명하거나 모니터링이 켜져 있지 않거나 팀 간 소통 없이
18:43
소유권이 나뉘어 있다면 혼란은 조용하고 꾸준하게 스며듭니다.
18:47
가장 무서운 점은 보통 즉각적인 문제가 발생하지 않는다는 것입니다.
18:51
서서히 쌓이다가 감사, 사건 또는 규제 관련 질문 한 번에 통제되고 있다고
18:55
믿었던 것들이 사실은 발견되길 기다리는 일련의 허점이었음이 드러나게
19:00
됩니다.
19:00
첫 번째 함정은 권한과 관련되어 있습니다.
19:03
누가 에이전트를 만들고 게시하고 공유할 수 있는지 정의되지 않으면
19:06
사용자들이 종종 스스로 그 빈자리를 채우게 됩니다.
19:09
이는 에이전트 중복 생성, 테스트 없이 운영 환경에 게시되는 에이전트
19:12
또는 접근해서는 안들 데이터에 접근하는 워크플로로 이어질 수 있습니다.
19:15
명확한 경계가 없으면 IT 부서는 무언가 문제가 발생한 뒤에야 알게 되는
19:19
섀도우 자동화 목록을 떠안게 됩니다.
19:21
접근 권한을 제한하지 않고 기능을 활성화하는 것은 혁신을 지원하는 것이
19:24
아니라 백지수표를 나눠주는 것과 같습니다.
19:27
두 번째 함정은 모니터링을 건너뛰는 것입니다.
19:29
권한 설정만으로 충분하다고 생각했던 관리자들을 자주 보았지만 실제로는
19:33
그 규칙들이 제대로 작동하는지에 대한 통찰력이 전혀 없었습니다.
19:36
그 결과 무슨 일이 일어나고 있는지 전혀 알지 못하게 됩니다.
19:38
감사 로그를 켜두지 않으면 누가 무엇을 했는지 증명할 수 없습니다.
19:41
사용량 지표를 확인하지 않으면 어떤 에이전트가 널리 쓰이는지 활동 패턴이
19:45
비정상적인지 알 수 없습니다.
19:47
그런 데이터 없이 운영하는 것은 잠시동안은 괜찮아 보이지만 외부 규제기관이나
19:51
사내 규정 준수팀이 답변할 수 없는 질문을 던지는 순간 문제가 됩니다.
19:54
일관성 없는 정책은 세 번째 지뢰입니다.
19:57
조직의 한 부서는 영격하게 관리하지만 다른 부서는 개시 권한을 완전히 열어둘 수 있습니다.
20:01
이러한 불일치는 통제되는 에이전트와 통제되지 않는 에이전트가 같은
20:04
패넌트 내에 뒤섞이는 혼란을 야기합니다.
20:06
외부에서 보기에는 정책이 존재하기 때문에 전략을 잘 수립했다고 생각할 수도 있습니다.
20:11
하지만 규정 준수팀과 보안검토팀은 정책이 존재한다는 증거를 넘어
20:15
조직 전체에 일관되게 적용되고 있다는 증거를 원합니다.
20:18
지역마다 다른 규제가 적용되는데 자체 정책이 이에 부합하지 않을 경우
20:21
이러한 격차는 방어하기가 훨씬 더 어려워집니다.
20:24
다음은 전형적인 소유권 분절 사례입니다.
20:27
IT 부서는 규칙을 정하고 보안팀은 다른 계층의 보호를 가정하며
20:31
사업 부서는 마음대로 개시할 수 있다고 생각할 수 있습니다.
20:34
각 그룹은 다른 누군가가 사각지대를 지키고 있을 거라 생각하지만
20:36
실제로는 아무도 지키지 않습니다.
20:38
이러한 명확성 부족은 중복된 권한이나 최종 권한을 가진 팀이
20:41
불분명하여 발생하는 에이전트 유출 같은 예방 가능한 문제들을 만들어냅니다.
20:45
제가 대화했던 한 회사가 정확히 이런 경험을 했습니다.
20:47
그들은 모든 직원에게 에이전트를 자유롭게 개시할 수 있도록 허용했습니다.
20:50
처음에는 권한을 부여하는 것처럼 보였습니다.
20:52
모두가 실험하고 개선사항을 내놓을 수 있었지만
20:54
누구도 개시 권한과 감사 로그를 연결해두지 않았습니다.
20:57
몇 달 후 규제기관이 특정 자동화를 누가 배포했는지 증명하라고 요구했을 때
21:00
그들이 가진 자료는 아무것도 없었습니다.
21:02
기록도 없었고 책임자도 없어둬며
21:04
감사 시 자신을 방어할 능력조차 없었습니다.
21:06
자동화를 대중화하려는 노력으로 시작된 일이 결국 심각한 규정 준수 결함으로 이어졌습니다.
21:11
이러한 사례들은 작은 실수가 어떻게 빠르게 대규모 위험으로 변할 수 있는지를 잘 보여줍니다.
21:16
권한 설정 오류나 관리되지 않는 에이전트는 소규모 파일럿 단계에서는 사소해 보일 수 있지만
21:20
기업 규모에서는 똑같은 실수가 알려지지 않은 곳에서 수백 개의 에이전트가 실행되는 결과로 이어집니다.
21:25
문제는 선형적으로 증가하지 않습니다.
21:27
모든 통제되지 않은 에이전트가 데이터 무결성, 신뢰성, 보완에 반한 의문을 남기기 때문에 문제는 기하급수적으로 커집니다.
21:33
다행인 점은 함정이 무엇인지 잘 알려져 있고 이를 피할 방법도 있다는 것입니다.
21:37
관리센터에서 기본 가드레일을 정의하는 것부터 시작하세요.
21:40
누가 빌드하고 누가 게시할 수 있는지 명확한 역할을 설정하세요.
21:43
모니터링을 선택사항이 아닌 필수로 만들어 문제가 심각해지기 전에 알림을 받도록 하세요.
21:48
지역 간에도 정책을 일관되게 유지하여 버버넌스 프레임워크를 자신있게 뒷받침할 수 있도록 하세요.
21:53
그리고 무엇보다 중요한 것은 첫날부터 보안 및 규정 준수팀과 협력하는 것입니다.
21:58
나중으로 미루면 거의 항상 역효과가 발생합니다.
22:00
이미 수많은 조직이 효과적인 플레이북을 만들어두었습니다.
22:04
분기별 정책 검토 체크리스트, 감사로깅을 게시 권한과 직접 연결하는 정책,
22:09
IT 부서의 공식 배포 전 혁신팀이 먼저 실험하는 프레임워크 등이 그 예입니다.
22:13
이러한 경험을 활용한다는 것은 그들의 실수를 되풀이할 필요가 없다는 것을 의미합니다.
22:17
다른 기업들이 실패를 보고했을 때 그 원인은 대부분 가드레일이 문서상으로는 존재했으나 실제로는 제대로 적용되지 않았기 때문이었습니다.
22:23
그들의 교훈을 조기에 내재화함으로써 여러분은 비용을 피할 수 있습니다.
22:26
감사합니다.
22:27
감사합니다.
22:28
감사합니다.