WEBVTT

00:00:00.000 --> 00:00:04.200
티켓팅은 이론상 깔끔해 보입니다. 수치와 대기열, 대시보드를 얻을 수 있으니까요.

00:00:04.340 --> 00:00:08.120
하지만 현실에서 그 모델은 시스템이 이미 고장난 뒤의 고통만을 측정할 뿐입니다.

00:00:08.300 --> 00:00:10.920
문제의 진짜 비용이 발생하는 지점은 훨씬 이전입니다.

00:00:11.140 --> 00:00:14.240
직원이 10분, 20분을 허비하다 결국 포기할 때 시작되죠.

00:00:14.400 --> 00:00:16.440
다시 시도합니다. 동료에게 물어봅니다.

00:00:16.680 --> 00:00:19.760
정상적인 경로가 막혀서 회의를 놓치거나 잘못된 파일을 공유하게 됩니다.

00:00:20.020 --> 00:00:22.640
그것이 바로 대부분의 지원팀이 여전히 보지 못하는 부분입니다.

00:00:22.840 --> 00:00:25.860
오늘날 최고의 내부 지원 모델은 더 빠른 분류에 관한 것이 아닙니다.

00:00:25.860 --> 00:00:28.560
분류라는 과정 자체를 없애는 것이 핵심입니다.

00:00:28.560 --> 00:00:32.940
마이크로소프트 365 내부에서 맥락을 파악하고 마찰을 조기에 발견하며

00:00:32.940 --> 00:00:36.940
사람이 포털을 열기도 전에 조치를 취하는 자율 에이전트를 상상해보세요.

00:00:37.200 --> 00:00:41.040
이번 에피소드에서는 헬프 데스크 모델이 왜 무너지는지, 무엇이 이를 대체하는지,

00:00:41.340 --> 00:00:43.920
그리고 어떻게 혼란 없이 이를 관리할 수 있는지 보여드리고자 합니다.

00:00:44.100 --> 00:00:47.400
이 변화가 여러분의 업무에 중요하다면 M365FM을 구독하세요.

00:00:47.620 --> 00:00:51.660
더 깊이 들어가보면 진짜 문제는 대기열이 아니라 그 이면의 모델이기 때문입니다.

00:00:51.840 --> 00:00:54.880
티켓의 종말, 낡은 지원 방식은 여전히 도처에 깔려 있습니다.

00:00:54.880 --> 00:00:57.560
무언가 고장납니다. 사용자가 이를 알아차립니다.

00:00:57.560 --> 00:01:03.540
사용자가 설명하려 노력합니다. 그러면 IT 부서가 그 설명을 범주, 우선순위, 할당그룹으로 변환합니다.

00:01:03.720 --> 00:01:08.360
문제가 대기열에 진입합니다. 누군가 이를 분류합니다. 다른 누군가가 더 많은 세부정보를 요청합니다.

00:01:08.520 --> 00:01:12.040
또 다른 팀이 개입합니다. 시간은 계속 흐르지만 실제 업무는 정체됩니다.

00:01:12.240 --> 00:01:16.380
익숙하기 때문에 그 과정이 정상처럼 느껴지지만 익숙함과 효율성은 별개의 문제입니다.

00:01:16.560 --> 00:01:20.220
티켓은 지원이 아닙니다. 티켓은 지원이 너무 늦었다는 증거일 뿐입니다.

00:01:20.420 --> 00:01:24.540
티켓이 존재할 때쯤이면 직원은 이미 마찰을 겪고 업무 맥락을 잃어버린 상태입니다.

00:01:24.540 --> 00:01:30.700
그들은 이미 하려던 업무에서 주의를 돌린 뒤입니다. 대기열은 서비스가 아닙니다. 대기열은 실패의 기록입니다.

00:01:30.900 --> 00:01:34.660
대규모 마이크로소프트 365 환경에서는 수동 분류가 실제 병목 현상이 됩니다.

00:01:34.900 --> 00:01:41.100
이는 지원팀이 게을러서 발생하는 일이 아닙니다. 사람에게 환경의 규모에 더 이상 맞지 않는 일을 요구하기 때문에 발생하는 것입니다.

00:01:41.300 --> 00:01:49.340
더 많은 사용자, 기기, 앱 정책이 존재하니까요. 팀, 시어포인트, 익스체인지, 인튠, 엔트라를 동시에 가로지르는 더 많은 예외 사례가 발생합니다.

00:01:49.340 --> 00:01:56.740
단순히 양만 늘어나는 것이 아닙니다. 조합의 수가 늘어나는 것입니다. 그 지점에서 낡은 모델은 무너집니다. 대부분의 팀은 더 많은 구조를 추가하며 대응합니다.

00:01:56.900 --> 00:02:03.780
또 다른 포털, 또 다른 못, 또 다른 나우팅 규칙을 만드는 시기죠. 하지만 현실적으로 그것은 직원과 해결책 사이에 한 겹의 단계를 더 추가할 뿐입니다.

00:02:03.980 --> 00:02:09.540
시스템은 여전히 사용자가 문제를 알아차리고, 설명하고, 올바른 방식으로 도움을 요청하기만을 기다리고 있습니다.

00:02:09.840 --> 00:02:17.200
업무는 지원 포털에서 시작되지 않습니다. 팀즈, 아웃룩, 당장 필요한 문서, 혹은 30초 뒤에 시작될 회의에서 시작됩니다.

00:02:17.200 --> 00:02:22.040
그곳이 바로 지원 수요가 실제로 발생하는 지점이며, 티켓팅 모델은 그 순간과 완전히 동떨어져 있습니다.

00:02:22.280 --> 00:02:26.580
숨겨진 비용은 대기열 보고서에 나타나는 것보다 훨씬 큽니다. 사람들은 문맥을 전환해야 합니다.

00:02:26.820 --> 00:02:30.560
중복된 사건들이 서로 다른 나벨 아래 사여갑니다. 지식 문서는 낡아버립니다.

00:02:30.840 --> 00:02:35.460
분석가들은 문제를 직접 해결하는 대신 하루 종일 분류하고, 전달하고, 명확히 하는 데 시간을 씁니다.

00:02:35.640 --> 00:02:41.120
모든 인수인계는 지연을 초래하고, 모든 지연은 원래의 맥락을 앗아가기 때문에 해결 시간은 길어집니다.

00:02:41.120 --> 00:02:48.720
에이전트 AI와 IT 운영에 대한 연구는 동일한 구조적 문제를 지적합니다. 최소 80%의 노력이 여전히 수동적인 ITIL 방식의 업무에 갇혀 있습니다.

00:02:48.980 --> 00:02:52.260
그 수치가 중요한 이유는 노동력이 정확히 어디에 투입되고 있는지 알려주기 때문입니다.

00:02:52.440 --> 00:02:55.180
그것은 회복력이나 예방이 아닌 사후 대응에 투입되고 있습니다.

00:02:55.460 --> 00:02:59.480
일단 그것을 알게 되면, 티켓은 운영 모델이라기보다는 하나의 증상처럼 보이기 시작합니다.

00:02:59.640 --> 00:03:02.520
피해가 가시화된 후에야 대응하는 시스템의 증상인 셈입니다.

00:03:02.720 --> 00:03:07.740
따라서 다음 질문은 티켓을 더 빨리 처리하는 법이 아니라, 티켓이 필요하기 전에 시스템이 무엇을 해야 하는가입니다.

00:03:07.740 --> 00:03:11.720
보이지 않는 직원 모델입니다. 그렇다면 무엇이 티켓을 실제로 대체할까요?

00:03:11.900 --> 00:03:17.140
그것은 똑같은 혼란 위에 얹혀진 또 다른 책봇이 아니면, 분명 똑같은 기존 대기열의 더 예쁜 입구도 아닙니다.

00:03:17.320 --> 00:03:24.020
변화는 그보다 훨씬 깊습니다. 보이지 않는 직원은 마이크로소프트 365 환경 안에서 살아가는 운영자이기 때문입니다.

00:03:24.220 --> 00:03:30.940
이 에이전트는 고유한 신원, 정의된 업무 범위, 어제 수행 한 일에 대한 기여, 그리고 무엇을 다룰 수 있는지에 대한 엄격한 규칙을 가지고 있습니다.

00:03:31.180 --> 00:03:37.220
그 차이는 중요합니다. 책봇은 사용자가 프롬프트를 입력하기를 기다리지만, 보이지 않는 직원은 조건 변화를 지켜봅니다.

00:03:37.220 --> 00:03:46.420
그것은 대화가 아닌 맥락에서 시작합니다. 로그인 상태, 장치 상태, 라이선스 상태, 파일 공유 방식을 볼 수 있기 때문에 문제가 발생할 때까지 기다릴 필요가 없습니다.

00:03:46.700 --> 00:03:51.640
무언가 고장난 뒤에 무엇을 도울지 묻는 대신, 백그라운드에서 끊임없이 다른 질문을 던집니다.

00:03:51.820 --> 00:03:57.460
지금 이 직원이 업무를 수행하는데 필요한 상태에서 무엇이 벗어나 있는가? 바로 그 지점에서 변화가 시작됩니다.

00:03:57.460 --> 00:04:08.280
이 모델은 업무 그 자체에 직접 내장되어 있습니다. 회의에 참여할 때 오디오 라우팅이 실패하거나, 게스트가 방금 받은 파일을 열 수 없을 때, 과거의 방식은 보고서를 만들고 인수인계를 합니다.

00:04:08.520 --> 00:04:15.440
새로운 모델에서 에이전트는 패턴을 즉시 파악하고, 조건이 알려진 문제와 일치하는지 확인한 뒤, 이를 해결하기 위한 다음 안전조치를 취합니다.

00:04:15.680 --> 00:04:21.840
경로를 재설정하거나 정책검사를 트리거할 수도 있고, 요청을 재라우팅하고 MFA를 요청한 뒤 수정사항을 기록할 수도 있습니다.

00:04:21.840 --> 00:04:27.640
핵심은 간단합니다. 첫 번째 대응을 위해 더 이상 사람이 모호한 설명을 읽고, 무슨 일이 일어났는지 추측할 필요가 없습니다.

00:04:27.940 --> 00:04:32.840
제대로 작동하면 대기실도 없고, 카테고리를 선택하세요, 같은 양식도 없기 때문에 존재조차 느껴지지 않습니다.

00:04:33.020 --> 00:04:39.800
지원은 복구된 워크플로우의 형태로 나타납니다. 직원은 바로 업무에 복귀하며, 많은 경우 뒤에서 작동하는 시스템조차 보지 못합니다.

00:04:40.100 --> 00:04:43.360
이것이 인력 운영 방식을 어떻게 변화시키는지 이미 알 수 있을 것입니다.

00:04:43.620 --> 00:04:48.980
기존 모델은 업무량을 감당하고, 요청을 분류하며, 팀 간의 단절된 맥락을 정리하기 위해 사람을 고용합니다.

00:04:48.980 --> 00:04:56.700
새로운 모델은 분류 작업을 하는 사람은 줄이고 가드레일을 설계하고, 목표 상태를 정의하며, 에이전트의 작동 방식을 감독할 더 많은 사람이 필요합니다.

00:04:56.880 --> 00:05:00.580
인간은 시스템 내에 남지만, 일상의 업무 형태는 완전히 달라집니다.

00:05:00.740 --> 00:05:04.460
지원 분야의 에이전트 AI에 대한 연구는 계속해서의 방향을 가리키고 있습니다.

00:05:04.740 --> 00:05:11.580
일상적인 지원은 예외 기반 처리로 전환될 수 있으며, 환경과 정책이 잘 정의되어 있을 때 엄청난 효율성 향상을 가져옵니다.

00:05:11.800 --> 00:05:14.440
이것은 마법이 아니기에 마지막 부분이 매우 중요합니다.

00:05:14.440 --> 00:05:20.440
데이터가 취약하거나 프로세스가 복잡하다면, 단순히 자율적이라고 부른다고 해서 에이전트가 똑똑해지는 것은 아닙니다.

00:05:20.620 --> 00:05:26.340
에이전트를 소프트웨어 기능이 아닌 사원증을 가진 비인간 직원으로 보기 시작했을 때 모든 것이 이해되기 시작했습니다.

00:05:26.620 --> 00:05:31.040
실제 근로자에게는 신원, 직무 기술서, 권한, 그리고 보고할 관리자가 필요합니다.

00:05:31.340 --> 00:05:33.240
에이전트에게도 똑같은 것이 필요합니다.

00:05:33.440 --> 00:05:37.680
가치는 채팅창이 재치있는 언어가 아닌 시스템 내에 신뢰할 수 있는 실행에서 나오기 때문입니다.

00:05:37.880 --> 00:05:40.360
보이지 않는 직원은 단순한 UI 트릭이 아닙니다.

00:05:40.360 --> 00:05:49.180
이는 마이크로소프트 365 환경 전반의 마찰을 감시하고, 정책 내에서 행동하며, 인간의 판단이 꼭 필요한 예외 상황에만 사람의 주의를 집중시키는 새로운 지원계층입니다.

00:05:49.320 --> 00:05:52.320
이 모델이 명확해지면 다음 질문은 매우 실용적인 것으로 바뀝니다.

00:05:52.480 --> 00:05:54.440
선제적 대응은 실제로 어떻게 작동할까요?

00:05:54.560 --> 00:05:56.080
선제적 대응의 아키텍처입니다.

00:05:56.320 --> 00:05:59.700
그렇다면 마이크로소프트 365 내부에서 선제적 대응은 실제로 어떻게 작동할까요?

00:05:59.840 --> 00:06:03.040
요청과 응답 중심에서 이벤트 추론과 오케스트레이션으로 변화합니다.

00:06:03.240 --> 00:06:06.260
기술적으로 들릴 수 있지만, 분석해보면 모델은 간단합니다.

00:06:06.260 --> 00:06:11.040
먼저 환경에서 무언가가 변경되고, 시스템이 그 변경이 위험인지 변화인지 해석한 뒤,

00:06:11.440 --> 00:06:14.640
마지막으로 스택에 이미 있는 도구를 사용하여 승인된 작업을 수행합니다.

00:06:14.800 --> 00:06:16.380
이벤트 계층부터 시작하겠습니다.

00:06:16.720 --> 00:06:19.780
마이크로소프트 365는 이미 도처에서 신호를 생성하고 있으며,

00:06:20.220 --> 00:06:24.020
엔트라는 로그인 동작을 확인하고, 인튜는 장치 상태와 규정 준수 여부를 추적합니다.

00:06:24.220 --> 00:06:29.600
디펜더는 의심스러운 활동을 감시하고, 팀즈는 회의가 실패하거나 통화 품질이 떨어지는 시점을 정확히 보여줍니다.

00:06:29.800 --> 00:06:32.900
셰어포인트와 익스체인지는 액세스 패턴과 콘텐츠 활동을 노출하며,

00:06:32.900 --> 00:06:36.240
서비스 상태 신호는 플랫폼 자체에 문제가 있을 때 이를 알려줍니다.

00:06:36.380 --> 00:06:39.900
여기에 사용자 작업까지 더해지면 끊임없는 컨텍스트 흐름이 형성됩니다.

00:06:40.080 --> 00:06:44.380
대부분의 조직이 이러한 신호를 수집하지만, 실제로 이를 지원 시스템으로 활용하는 곳은 매우 드뭅니다.

00:06:44.580 --> 00:06:46.520
원시 이벤트만으로는 도움이 되지 않습니다.

00:06:46.760 --> 00:06:49.220
소음을 이해하기 위한 추론계층이 필요하기 때문입니다.

00:06:49.400 --> 00:06:53.780
바로 이 지점에서 보이지 않는 직원은 보여주기식 자동화에서 벗어나 실제 운영자처럼 작동하기 시작합니다.

00:06:53.980 --> 00:06:56.800
에이전트는 신호를 확인하고 현재 상태를 원하는 상태와 비교하여,

00:06:57.120 --> 00:06:59.340
어떤 유형의 조치를 취하는 것이 안전한지 결정합니다.

00:06:59.340 --> 00:07:04.640
회의 오디오 문제는 위험한 로그인과 다르며, 공유 링크 오류는 라이선스 불일치와는 다른 문제입니다.

00:07:04.840 --> 00:07:06.780
에이전트는 먼저 문제를 분류해야 합니다.

00:07:06.940 --> 00:07:10.160
분류 없이 조치를 취하는 것은 그저 실수를 더 빨리 유발할 뿐이기 때문입니다.

00:07:10.320 --> 00:07:12.040
그 다음은 오케스트레이션 단계입니다.

00:07:12.260 --> 00:07:15.520
문제를 이해한 에이전트는 올바른 메커니즘을 사용하여 대응할 수 있습니다.

00:07:15.760 --> 00:07:20.900
워크플로우에는 파워 오토메이트, 로직에는 코파일럿 스튜디오, 시스템 작업 및 컨텍스트에는 마이크로소프트 그래프가 사용될 수 있습니다.

00:07:21.080 --> 00:07:24.360
도구도 중요하지만, 더 중요한 점은 도구들이 서로 어떻게 연결되는지입니다.

00:07:24.360 --> 00:07:29.480
단 하나의 똑똑한 프롬프트를 만드는 것이 아니라, 감지, 결정, 실행, 검증이 가능한 체인을 구축하는 것입니다.

00:07:29.620 --> 00:07:31.600
마지막 부분은 항상 간과되기 쉽습니다.

00:07:31.800 --> 00:07:34.900
자기 수정 시스템은 조치가 취해졌다고 해서 멈추지 않습니다.

00:07:35.100 --> 00:07:41.740
이 시스템은 문제를 감지하고, 조건을 테스트하고, 수정 사항을 적용하고, 결과를 검증한 뒤 기록하는 루프를 실행합니다.

00:07:41.920 --> 00:07:49.220
자기 수정 로직 연구에 따르면, 이러한 시스템은 언어 모델의 단일 답변이 아닌 피드백 및 수정 패턴을 통해 작동함이 분명합니다.

00:07:49.220 --> 00:07:55.720
첫 번째 조치가 실패하면, 시스템은 그 이유를 평가하여 정의된 한도 내에서 다음 단계를 수정할 수 있어야 합니다.

00:07:55.920 --> 00:07:59.500
마이크로소프트 365의 몇 가지 사례에서 이를 명확하게 확인할 수 있습니다.

00:07:59.760 --> 00:08:05.840
라이선스와 정책 범위가 일치하지 않아 사용자가 차단되면, 에이전트가 불일치를 감지하고, 위도된 역할 프로필을 확인합니다.

00:08:06.040 --> 00:08:11.800
에이전트는 허용된 수정 사항을 적용하고, 사용자의 액세스 권한을 확인하며, 별도의 문외 없이 변경 사항을 기록합니다.

00:08:12.020 --> 00:08:17.640
엔트라에서 위험한 로그인이 발생하면, 에이전트는 위험 이벤트를 확인하고, 즉시 조건부 액세스 규칙을 검사합니다.

00:08:19.220 --> 00:08:24.000
강력한 인증을 요구하거나 액세스를 차단하고, 사람이 나중에 검토할 수 있도록 결과를 기록합니다.

00:08:24.200 --> 00:08:30.440
쉐어포인트에서 오래된 공유 링크가 계속 실패하면, 에이전트는 현재 권한 경로를 예상되는 공유 규칙과 비교합니다.

00:08:30.660 --> 00:08:40.480
손상된 루트를 승인된 것으로 대체하고, 수정된 링크를 컨텍스트 내에서 전송함으로써, 데스크 분석가가 긴급 액세스 문제라는 티켓을 읽기도 전에 문제를 해결합니다.

00:08:40.700 --> 00:08:42.180
회의 지원도 좋은 예입니다.

00:08:42.180 --> 00:08:48.760
통화 시작 몇 초 전에 회의실 장치가 실패하거나 연결 경로가 끊기면, 에이전트가 상태를 감지하고 오류를 검증할 수 있습니다.

00:08:48.760 --> 00:08:54.260
위험 부담이 적은 복구 단계를 시도하고, 업무가 진행 중인 팀즈 내에서 주최자에게 상태 업데이트를 알립니다.

00:08:54.500 --> 00:08:57.060
이러한 통신계층은 설계의 핵심적인 부분입니다.

00:08:57.280 --> 00:08:59.700
지원은 중단이 발생하는 곳에서 이루어져야 합니다.

00:08:59.920 --> 00:09:05.300
업무가 팀즈, 아울룩, M365 작업 공간에서 이루어진다면, 지원 역시 그곳에서 제공되어야 합니다.

00:09:05.480 --> 00:09:09.400
컨텍스트 내에서 상황에 대응할 수 있는데, 굳이 사용자를 다른 곳으로 유도할 필요는 없습니다.

00:09:09.720 --> 00:09:12.420
그렇다고 모든 작업에 자동화를 적용하라는 뜻은 아닙니다.

00:09:12.420 --> 00:09:14.220
그것은 무모한 일이기 때문입니다.

00:09:14.360 --> 00:09:18.920
위험이 낮은 작업은 자동으로 실행될 수 있지만, 영향력이 큰 변경사항은 여전히 사람의 승인이 필요합니다.

00:09:19.100 --> 00:09:23.740
승인 경로는 나중에 추가되는 것이 아니라, 설계 단계부터 아키텍처의 일부로 포함되어야 합니다.

00:09:23.960 --> 00:09:27.920
에이전트는 언제 행동하고, 언제 요청하며, 정확히 언제 멈춰야 할지 알아야 합니다.

00:09:28.120 --> 00:09:31.940
일단 이를 흐름에 구축하고 나면, 대화의 주제는 자동화 기능에서 벗어나게 됩니다.

00:09:32.200 --> 00:09:36.460
대신 제어, 거버넌스, 신뢰, 그리고 에이전트 아이디에 대한 논의로 전환됩니다.

00:09:36.460 --> 00:09:40.020
지원이 스스로 작동하기 시작하면, 즉시 어려운 질문이 떠오릅니다.

00:09:40.240 --> 00:09:42.240
실제로 누가 이 작업을 수행하고 있는가?

00:09:42.380 --> 00:09:45.040
그에 대한 답이 모호하다면, 전체 모델은 무너지고 맙니다.

00:09:45.240 --> 00:09:49.560
에이전트는 광범위한 액세스 권한을 가져 누나 명확한 소유자가 없는 불분명한 조력자로, 환경 내에 존재해서는 안 됩니다.

00:09:49.780 --> 00:09:51.640
엔트라 내에 실제 아이디가 필요합니다.

00:09:51.880 --> 00:09:56.600
지정된 소유자, 정의된 범위, 그리고 특정 이유로 시작되고, 종료되는 수명 주기가 필요합니다.

00:09:56.800 --> 00:10:00.880
해당 에이전트가 데이터를 읽거나, 워크플로우를 트리거하거나, 사용자에게 메시지를 보낼 수 있다면,

00:10:00.880 --> 00:10:03.260
테넌트 내의 능동적인 구성원처럼 관리해야 합니다.

00:10:03.380 --> 00:10:06.140
누군가 켜놓고 잊어버린 기능처럼 취급해서는 안 됩니다.

00:10:06.440 --> 00:10:09.400
이것이 바로 에이전트 아이디가 시스템에 매우 중요한 이유입니다.

00:10:09.580 --> 00:10:14.680
에이전트가 정확히 무엇인지, 어떤 시스템에 접근할 수 있는지, 그리고 문제가 발생했을 때 누가 연락을 받는지 알아야 합니다.

00:10:14.840 --> 00:10:16.960
여기서 최소 권한 원칙이 기준이 되어야 합니다.

00:10:17.140 --> 00:10:21.340
광범위한 편의성에 안주하거나, 나중에 권한을 강화하겠다고 스스로를 속녀서는 안 됩니다.

00:10:21.640 --> 00:10:27.980
지원 에이전트의 영향 범위는 전적으로 권한에 달려있기 때문에, 권한 설계는 지원 설계의 핵심 부분입니다.

00:10:27.980 --> 00:10:34.720
에이전트 365는 전체 에이전트 자산을 명확하게 보여주기 때문에의 구성에서 필수적인 제어계층 역할을 합니다.

00:10:34.900 --> 00:10:39.900
이는 시스템을 안전하게 운영하는 레지스트리, 승인 워크플로, 정책 템플릿을 제공합니다.

00:10:40.120 --> 00:10:44.820
이러한 요소들이 단순히 행정적인 업무처럼 들릴 수 있지만, 실제로는 거대한 구조적 문제를 해결합니다.

00:10:44.980 --> 00:10:51.060
대부분의 조직은 AI 기능이 부족해서가 아니라, 환경 내에서 무엇이 실행 중인지 확인하거나 제어할 수 없어서 어려움을 겪습니다.

00:10:51.280 --> 00:10:53.320
이 점에 대한 연구 결과는 매우 명확합니다.

00:10:53.320 --> 00:10:58.720
대기업 중 극소수만이 현재 시스템에서 실행 중인 모든 에이전트의 목록을 완전히 파악하고 있습니다.

00:10:58.980 --> 00:11:03.400
리더들이 자율 지원 확장을 논하기 전에 훨씬 더 간단한 질문에 답해야 합니다.

00:11:03.600 --> 00:11:07.180
우리는 어떤 에이전트가 존재하고 지금 무엇을 하고 있는지 알고 있습니까?

00:11:07.360 --> 00:11:10.100
감독 수준 또한 수반되는 위험 수준에 맞춰야 합니다.

00:11:10.320 --> 00:11:16.200
좁은 범위에서 작업하는 개인 생산성 에이전트와 공유 콘텐츠를 다루는 협업 에이전트는 전혀 다른 문제입니다.

00:11:16.200 --> 00:11:21.100
민감한 워크플로우 전반에서 동작하는 엔터프라이즈 에이전트는 또 다른 범주의 위험에 속합니다.

00:11:21.300 --> 00:11:25.360
이것이 바로 개인, 협업, 엔터프라이즈로 나뉘는 위험 영역 모델이 중요한 이유입니다.

00:11:25.540 --> 00:11:28.560
귀하의 제어 모델은 잠재적 영향력과 함께 강화되어야 합니다.

00:11:28.760 --> 00:11:35.240
모든 에이전트를 동일하게 취급하면 저위험 작업은 느린 승인 절차에 묻히고, 고위험 작업은 느슨한 검토를 틈타 빠져나갑니다.

00:11:35.400 --> 00:11:39.600
최소한 마이크로소프트 365위 제어 스택은 팀에게 익숙한 형태여야 합니다.

00:11:39.600 --> 00:11:44.340
엔트라위 아이디, 퍼뷰위 데이터 경계, 디펜더위 모니터링 기능을 사용하십시오.

00:11:44.440 --> 00:11:49.580
조건부 액세스를 통해 접근 조건을 적용하고 처음부터 감사 가능성이 내장되도록 해야 합니다.

00:11:49.780 --> 00:11:54.360
사건 발생 후 추측할 필요 없이 정확히 무슨 일이 일어났는지 재구성할 수 있어야 합니다.

00:11:54.560 --> 00:11:58.700
민적감독은 위기 상황에서 즉흥적으로 하는 것이 아니라 논리에 설계되어 있어야 합니다.

00:11:58.920 --> 00:12:02.320
영향력이 큰 작업은 항상 사람의 승인을 거치도록 일시 정지해야 합니다.

00:12:02.520 --> 00:12:06.060
추론 과정은 사람이 직접 검토하고 이해할 수 있는 형태로 기록되어야 합니다.

00:12:06.060 --> 00:12:10.000
첫 번째 자율작업이 시작되기 전에 반드시 롤백 경로가 존재해야 합니다.

00:12:10.200 --> 00:12:12.760
에이전트가 액세스를 업데이트하거나 라우팅 정책을 변경하면

00:12:12.760 --> 00:12:16.180
누군가는 그 결정을 추적하고 깔끔하게 되돌릴 수 있는 방법이 있어야 합니다.

00:12:16.360 --> 00:12:19.900
초기 데모가 매우 좋아 보이기 때문에 리더들이 종종 간과하는 또 다른 요소가 있습니다.

00:12:20.160 --> 00:12:21.380
재작업에 드는 비용입니다.

00:12:21.600 --> 00:12:25.760
에이전트가 팀을 위해 정리 루프를 생성한다면 예상했던 절감 효과는 즉시 사라집니다.

00:12:25.940 --> 00:12:27.460
이것이 바로 재작업의 대가입니다.

00:12:27.720 --> 00:12:30.560
이는 잘못된 결과물을 수정하거나 잘못된 동작을 되돌리거나

00:12:30.560 --> 00:12:32.960
위도치 않은 부작용을 추적하는 데 소비되는 시간입니다.

00:12:32.960 --> 00:12:36.200
팀이 실행 시간을 10분 절약했지만 그 뒷처리를 하느라 8분을 쓴다면

00:12:36.200 --> 00:12:38.620
사실상 지원 업무를 자동화한 것이 아닙니다.

00:12:38.760 --> 00:12:41.380
단지 프로세스의 다른 부분으로 마찰을 옮겼을 뿐입니다.

00:12:41.580 --> 00:12:44.500
신뢰는 잘 꾸며진 정책 문서 나 거창한 출시 발표에서 나오지 않습니다.

00:12:44.700 --> 00:12:46.180
신뢰는 넌타임의 증거에서 나옵니다.

00:12:46.380 --> 00:12:48.480
사람들은 에이전트가 무엇을 보았고 어떤 결정을 내렸으며

00:12:48.480 --> 00:12:50.460
시스템에서 실제로 무엇이 바뀌었는지 확인해야 합니다.

00:12:50.640 --> 00:12:52.820
그것이 자율지원 시스템에 대한 신뢰를 쌓는 방법입니다.

00:12:53.040 --> 00:12:56.280
증명은 프로젝트의 브랜딩이 아니라 도구의 행동 안에 있어야 합니다.

00:12:56.520 --> 00:12:58.140
거버넌스의 기반이 탄탄해지면

00:12:58.140 --> 00:13:01.940
보안 전문 용어 중심의 대화에서 경영진의 언어로 전환할 수 있습니다.

00:13:02.220 --> 00:13:04.420
이것이 수익에 실제로 어떤 변화를 가져올까요?

00:13:04.620 --> 00:13:07.220
보이지 않는 지원의 새로운 ROI, 투자 대비 수익입니다.

00:13:07.400 --> 00:13:10.740
리더들이 제어 모델을 수용하면 재무적 관점에서의 질문이 달라지기 시작합니다.

00:13:10.940 --> 00:13:13.560
기존 모델에서는 지원의 가치를 티켓 처리, 통화 응대,

00:13:13.860 --> 00:13:15.960
SLA 성과와 같은 가시적인 업무로 측정했습니다.

00:13:16.180 --> 00:13:17.540
그 수치들이 여전히 중요하지만

00:13:17.540 --> 00:13:19.900
그것은 문제에 대한 대응만을 설명할 뿐입니다.

00:13:20.080 --> 00:13:21.860
그 수치로는 문제가 조기에 해결되어

00:13:21.860 --> 00:13:25.140
Q에 도달하지 않은 방해 요소 나 보호된 직원들의 시간을 알 수 없습니다.

00:13:25.460 --> 00:13:27.300
그것이 핵심적인 회계 문제점입니다.

00:13:27.300 --> 00:13:30.160
보이지 않는 지원은 부재를 통해 가치를 창출합니다.

00:13:30.320 --> 00:13:31.820
티켓이나 에스컬레이션이 없고

00:13:31.820 --> 00:13:33.900
분석가가 불안전한 기록을 토대로

00:13:33.900 --> 00:13:36.120
20분씩 문제를 재구성할 필요가 없을 때

00:13:36.120 --> 00:13:37.320
그 가치가 드러납니다.

00:13:37.560 --> 00:13:39.520
지원팀의 가시적인 노력만 측정한다면

00:13:39.520 --> 00:13:41.740
실제로 원했던 결과는 놓치게 됩니다.

00:13:41.980 --> 00:13:44.920
당신이 원했던 것은 방해 요소가 줄어든 안정적인 업무 환경입니다.

00:13:45.120 --> 00:13:47.680
티켓 수만 단독으로 보면 신호로서의 의미가 약합니다.

00:13:47.900 --> 00:13:49.980
티켓이 줄었다는 것은 수요가 감소했음을 의미할 수도 있지만

00:13:49.980 --> 00:13:53.040
환경이 더 건강해지고 지원계층이 더 스마트해졌음을 의미할 수도 있습니다.

00:13:53.240 --> 00:13:54.840
이 둘은 완전히 다른 이야기입니다.

00:13:54.840 --> 00:13:58.520
경영진은 이 둘의 차이를 구분할 수 있는 KPI 세트가 필요합니다.

00:13:58.680 --> 00:14:01.100
자율 해결률을 확인하는 것부터 시작해야 합니다.

00:14:01.360 --> 00:14:03.020
이것은 보시 몇 건의 대화를 했느냐가 아니라

00:14:03.020 --> 00:14:04.560
사람이 전혀 개입하지 않고

00:14:04.560 --> 00:14:07.420
얼마나 많은 지원 이벤트가 끝까지 해결되었느냐에 관한 것입니다.

00:14:07.600 --> 00:14:10.580
평균 해결 시간, MTTR, 위 단축도 추적해야 합니다.

00:14:10.800 --> 00:14:13.100
AI 기반 환경에서는 진단이 중요한 흐름에서

00:14:13.100 --> 00:14:15.640
40에서 60% 범위의 개선이 자주 나타납니다.

00:14:15.840 --> 00:14:17.500
그런 다음 해결당 비용과 되찾는

00:14:17.500 --> 00:14:19.420
사용자 생산성을 살펴볼 수 있습니다.

00:14:19.420 --> 00:14:24.180
마지막 지표는 표준 서비스 데스크 보고서에 깔끔하게 들어가지 않아 간과하기 쉽습니다.

00:14:24.380 --> 00:14:26.740
하지만 종종 진정한 가치는 바로 그곳에 있습니다.

00:14:27.040 --> 00:14:29.840
티켓을 열기도 전에 15분 동안 업무가 막힌 사람은

00:14:29.840 --> 00:14:31.820
이미 회사에 비용을 발생시킨 것입니다.

00:14:32.040 --> 00:14:35.080
이를 대규모 조직 전반의 회의 중단 및 접근 마찰과 곱해보면

00:14:35.080 --> 00:14:38.120
숨겨진 손실은 Q가 보여주는 것보다 훨씬 큽니다.

00:14:38.320 --> 00:14:39.420
이것이 비즈니스 케이스에서

00:14:39.420 --> 00:14:42.100
무대음 비용, 코스트 오브 인액션, 모델이 중요한 이유입니다.

00:14:42.260 --> 00:14:45.700
공식적인 지원이 시작되기 전에 수동 노력에 소비된 시간을 계산하는 것입니다.

00:14:45.940 --> 00:14:48.380
여기에 오류와 반복 작업으로 인한 비용을 더해보십시오.

00:14:48.380 --> 00:14:51.480
그러면 선제적 대응에 대한 주장이 더 이상 이론처럼 들리지 않게 됩니다.

00:14:51.680 --> 00:14:54.360
단순히 미래지향적 인 지원 체계에 투자하는 것이 아닙니다.

00:14:54.540 --> 00:14:57.500
수년간 일상 업무 속에 숨겨져 있던 세금을 제거하는 것입니다.

00:14:57.700 --> 00:15:00.640
특정 사례에 대한 경제적 효과를 보면 이 점이 더욱 분명해집니다.

00:15:00.820 --> 00:15:02.640
에이전트 기반 IT 지원 연구에 따르면

00:15:02.640 --> 00:15:05.280
사람의 처리 비용은 건당 약 8.75 달러입니다.

00:15:05.520 --> 00:15:07.520
반면 특정 목적의 에이전트 처리는

00:15:07.520 --> 00:15:10.560
시스템 구축 후 건당 50센트 미만으로 떨어질 수 있습니다.

00:15:10.880 --> 00:15:13.360
모든 지원 작업이 그렇게 저렴해진다는 뜻은 아님으로

00:15:13.360 --> 00:15:15.760
리더는 광범위한 평균치를 주의해야 합니다.

00:15:15.760 --> 00:15:19.440
텔레메트리 품질과 거버넌스는 항상 최종 비용에 영향을 주지만

00:15:19.440 --> 00:15:21.200
추세의 방향은 명확합니다.

00:15:21.380 --> 00:15:25.020
이제 IT가 과거의 비용 중심적인 이야기에서 벗어나는 순간입니다.

00:15:25.220 --> 00:15:26.540
지원이 사라지는 것이 아니라

00:15:26.540 --> 00:15:31.240
배경에서 직원들의 생산성을 보호하는 신뢰성 계층으로 전환되기 때문입니다.

00:15:31.460 --> 00:15:33.380
기업은 이를 극적인 지원 이벤트가 아닌

00:15:33.380 --> 00:15:35.340
더 원활한 업무 환경으로 체감합니다.

00:15:35.560 --> 00:15:37.600
중단은 줄어들고 복구는 빨라지며

00:15:37.600 --> 00:15:40.100
나우팅과 확인에 낭비되는 노동력도 감소합니다.

00:15:40.100 --> 00:15:43.200
하지만 잘못된 측정은 쉽게 진척도를 왜곡할 수 있습니다.

00:15:43.420 --> 00:15:44.460
텔레메트리가 취약하면

00:15:44.460 --> 00:15:46.340
에이전트는 문제를 실제로 예방하기보다

00:15:46.340 --> 00:15:48.220
장애를 더 빨리 요약하는 데 그칠 수 있습니다.

00:15:48.420 --> 00:15:49.880
재작업이 대시보드에서 누락되면

00:15:49.880 --> 00:15:52.100
ROI는 실제보다 훨씬 더 좋아 보일 것입니다.

00:15:52.280 --> 00:15:54.980
확보된 시간이 다시 저 부가가치 활동으로 흘러가면

00:15:54.980 --> 00:15:56.900
리더는 성과를 과대평가하게 됩니다.

00:15:57.160 --> 00:15:58.960
재무적 파당성은 예방된 사고와

00:15:58.960 --> 00:16:01.600
수동 작업 감소 같은 확실한 증거에 기반해야 합니다.

00:16:01.860 --> 00:16:03.540
실질적으로 유용한 업무에 되돌려

00:16:03.540 --> 00:16:04.920
진 시간을 측정해야 합니다.

00:16:05.160 --> 00:16:06.280
이를 제대로 측정하면

00:16:06.280 --> 00:16:09.340
지원 기능은 더 이상 줄여야 할 오버헤드로 보이지 않습니다.

00:16:09.540 --> 00:16:12.520
비로소 기업이 되찾는 운영 역량으로 보이기 시작합니다.

00:16:12.840 --> 00:16:14.940
이것이 지원팀에 어떤 영향을 미칠까요?

00:16:15.200 --> 00:16:17.400
이 변화는 단순히 인력을 감축하는 것이 아니라

00:16:17.400 --> 00:16:20.200
구성원들이 하루를 보내는 방식을 바꾸는 것이기에

00:16:20.200 --> 00:16:22.340
현장팀에 미칠 영향을 생각해 보십시오.

00:16:22.480 --> 00:16:25.400
기존 방식에서는 비밀번호 재설정, 티켓 나우팅,

00:16:25.720 --> 00:16:28.280
끝없는 확인 절차의 지원 역량의 대부분이 소모됩니다.

00:16:28.500 --> 00:16:30.540
서로 통신하도록 설계되지 않은 시스템 사이에서

00:16:30.540 --> 00:16:33.160
데이터를 옮기고 업데이트를 쫓아다니는데 시간을 허비합니다.

00:16:33.160 --> 00:16:35.200
그런 작업은 환경을 안정시키지 못하며

00:16:35.200 --> 00:16:37.440
단지 대기열이 넘치지 않게 막을 뿐입니다.

00:16:37.600 --> 00:16:39.660
예측 가능한 반복 업무를 에이전트가 대신하면

00:16:39.660 --> 00:16:42.520
사람의 노력은 비로소 한 단계 더 높은 곳으로 향합니다.

00:16:42.700 --> 00:16:44.860
지원 엔지니어는 건강한 상태를 정의하고

00:16:44.860 --> 00:16:47.700
승인 로직을 조정하는 데 시간을 할애하기 시작합니다.

00:16:47.940 --> 00:16:50.740
이들은 지식 소스를 개선하고 정책의 동작을 테스트하며

00:16:50.740 --> 00:16:53.960
에이전트가 주어진 경계 내에서 작동하도록 관리하는 데 집중합니다.

00:16:54.180 --> 00:16:55.800
그것은 하루 종일 제목을 쳐다보며

00:16:55.800 --> 00:16:59.340
사용자가 실제로 무엇을 원하는지 추측하는 업무와는 완전히 다릅니다.

00:16:59.560 --> 00:17:02.180
바로 이 지점에서 대부분의 도입 작업이 정체됩니다.

00:17:02.180 --> 00:17:05.120
조직들은 기존에 낡고 비효율적인 프로세스를 유지하면서

00:17:05.120 --> 00:17:07.720
에이전트만 추가하여 더 나은 결과를 기대하곤 합니다.

00:17:07.840 --> 00:17:09.540
하지만 프로세스는 여전히 수동적이고

00:17:09.540 --> 00:17:12.580
업무 인계는 복잡하며 기반이 되는 지식은 여전히 부족합니다.

00:17:12.760 --> 00:17:15.760
에이전트는 무너져가는 벽에 칠하는 또 하나의 페인트 칠이 될 뿐입니다.

00:17:15.940 --> 00:17:17.260
질문에 더 빨리 답할 수는 있겠지만

00:17:17.260 --> 00:17:19.700
지원을 전제로 설계된 지원 모델을 고칠 수는 없습니다.

00:17:19.960 --> 00:17:22.320
더 나은 방법은 업무를 먼저 재설계하는 것입니다.

00:17:22.540 --> 00:17:24.700
판단력이나 세심한 소통이 필요한 작업은

00:17:24.700 --> 00:17:26.780
사람이 직접 수행하도록 결정해야 합니다.

00:17:27.000 --> 00:17:28.680
그런 다음 결과가 예측 가능하고

00:17:28.680 --> 00:17:31.180
행동이 안전한 업무는 자율 흐름으로 전환합니다.

00:17:31.400 --> 00:17:32.820
지원팀이 사라지는 것은 아니기에

00:17:32.820 --> 00:17:34.280
이러한 구분은 매우 중요합니다.

00:17:34.480 --> 00:17:35.740
그들은 이제 제어장치를 설계하고

00:17:35.740 --> 00:17:37.580
예외 상황을 처리하는 전문가로 거듭나게 됩니다.

00:17:37.800 --> 00:17:40.360
이는 곧 인력을 교육하는 방식도 바뀌어야 함을 의미합니다.

00:17:40.540 --> 00:17:42.520
팀은 단순히 수동작업을 실행하는 대신

00:17:42.520 --> 00:17:44.480
시스템을 감독하는 법을 배워야 합니다.

00:17:44.680 --> 00:17:46.320
롤백 로직, 감사 검토,

00:17:46.640 --> 00:17:49.180
그리고 에이전트 배포 전 패스트 방법을 이해해야 합니다.

00:17:49.180 --> 00:17:50.900
또한 자동화된 잘못된 워크플로우 역시

00:17:50.900 --> 00:17:52.480
여전히 잘못된 워크플로우일 뿐이기에

00:17:52.480 --> 00:17:54.580
모델이 실패하는 시점을 포착할 수 있어야 합니다.

00:17:54.740 --> 00:17:56.560
그저 문제를 더 빨리 일으킬 뿐이니까요.

00:17:56.700 --> 00:17:58.040
이러한 미래를 대비해 채용 중이라면

00:17:58.040 --> 00:17:59.760
티켓을 분류할 또 다른 제너럴리스트는

00:17:59.760 --> 00:18:00.600
아마 필요 없을 것입니다.

00:18:00.780 --> 00:18:02.820
마이크로소프트 365 스택 전반에서

00:18:02.820 --> 00:18:03.720
흐름을 조정하고

00:18:03.720 --> 00:18:05.280
에이전트를 제어할 통제 장치를

00:18:05.280 --> 00:18:06.580
정의할 인재가 필요합니다.

00:18:06.780 --> 00:18:08.860
단순히 쌓여가는 지원 요청을 줄이고

00:18:08.860 --> 00:18:11.400
환경을 개선할 수 있는 사람들이 필요합니다.

00:18:11.680 --> 00:18:13.320
그렇다면 거대한 단연 프로젝트로

00:18:13.320 --> 00:18:14.280
변질되지 않으면

00:18:14.280 --> 00:18:16.160
서어떻게의 일을 시작할 수 있을까요?

00:18:16.360 --> 00:18:17.220
가장 좋은 방법은

00:18:17.220 --> 00:18:18.980
마이크로소프트 365 환경에서

00:18:18.980 --> 00:18:20.200
지속적인 마찰을 일으키는

00:18:20.200 --> 00:18:21.720
단 하나의 흐름을 선택하는 것입니다.

00:18:21.940 --> 00:18:23.680
액세스 권한 복구는 훌륭한 후보이며

00:18:23.680 --> 00:18:24.620
회의 지원이나

00:18:24.620 --> 00:18:27.000
장치 규정 준수 인계 과정도 고려할 수 있습니다.

00:18:27.260 --> 00:18:28.200
어떤 것을 선택하든

00:18:28.200 --> 00:18:29.780
해당 패턴이 자주 발생하고

00:18:29.780 --> 00:18:31.280
성공적인 결과가 무엇인지

00:18:31.280 --> 00:18:32.940
정확히 알고 있다면 문제 없습니다.

00:18:33.260 --> 00:18:34.160
목표가 정해졌다면

00:18:34.160 --> 00:18:35.440
철저한 규율을 가지고

00:18:35.440 --> 00:18:36.980
기본 사항을 정의해야 합니다.

00:18:37.180 --> 00:18:38.260
정상 상태가 무엇인지

00:18:38.260 --> 00:18:39.740
그리고 어떤 특정 이벤트가

00:18:39.740 --> 00:18:40.780
상황이 벗어나고 있음을

00:18:40.780 --> 00:18:41.960
알려주는지 알아야 합니다.

00:18:41.960 --> 00:18:43.880
어떤 작업을 자동화하는 것이 안전한지

00:18:43.880 --> 00:18:45.200
그리고 정확히 어느 시점에

00:18:45.200 --> 00:18:46.880
사람이 개입해야 하는지 결정하십시오.

00:18:47.000 --> 00:18:47.820
대포를 시작하기 전에

00:18:47.820 --> 00:18:49.640
티켓 건수, 수동 작업 횟수

00:18:49.640 --> 00:18:50.980
그리고 현재 사용자가 해결을 위해

00:18:50.980 --> 00:18:52.020
얼마나 기다리는지에 대한

00:18:52.020 --> 00:18:53.100
기준치를 확보하십시오.

00:18:53.180 --> 00:18:53.840
또한 첫날부터

00:18:53.840 --> 00:18:55.760
거버넌스를 체계적으로 갖추어야 합니다.

00:18:55.980 --> 00:18:57.860
에이전트의 구체적인 정체성을 부여하고

00:18:57.860 --> 00:18:58.960
담당자를 지정하며

00:18:58.960 --> 00:19:00.520
명확한 승인 규칙을 설정하세요.

00:19:00.720 --> 00:19:02.420
에이전트가 수행하는 모든 작업은

00:19:02.420 --> 00:19:03.360
기록되어야 합니다.

00:19:03.560 --> 00:19:05.040
또한 에이전트가 은퇴하거나

00:19:05.040 --> 00:19:07.000
재배정될 때를 대비한 계획을 세워

00:19:07.000 --> 00:19:08.920
유령 자동화가 되지 않도록 해야 합니다.

00:19:09.100 --> 00:19:10.940
첫 번째 워크플로우가 작동하기 시작하면

00:19:10.940 --> 00:19:12.800
전체 운영 모델이 변화하기 시작합니다.

00:19:13.040 --> 00:19:14.660
지원 부서는 문제에 단순히 반응하는

00:19:14.660 --> 00:19:16.680
안내데스크처럼 행동하는 것을 멈춥니다.

00:19:16.880 --> 00:19:18.460
대신 시스템에 직접 구축된

00:19:18.460 --> 00:19:20.660
신뢰성 엔진처럼 작동하기 시작합니다.

00:19:20.920 --> 00:19:22.240
지원은 가시적 인 대응에서

00:19:22.240 --> 00:19:23.840
내재된 예방으로 전환되고 있습니다.

00:19:24.120 --> 00:19:25.940
티켓은 결코 서비스 그 자체가 아니었습니다.

00:19:26.240 --> 00:19:28.460
그것은 서비스가 너무 늦게 도착했다는 증거일 뿐입니다.

00:19:28.660 --> 00:19:30.560
이번 분기에 지원 워크플로우 하나를 선택하여

00:19:30.560 --> 00:19:32.580
대응이 아닌 선제적 조치를 위해 재설계하세요.

00:19:32.580 --> 00:19:34.360
M365 코파일럿, A죠?

00:19:34.680 --> 00:19:37.080
보안 및 AI 운영 모델에 대해 더 알고 싶으시다면

00:19:37.080 --> 00:19:39.720
M365 FM을 구독하고 리뷰를 남겨주세요.

00:19:39.920 --> 00:19:42.040
링크딘에서 저 미르코 피어터와 연결하여

00:19:42.040 --> 00:19:43.960
다음에 다루어 누면 하는 주제를 제안해주세요.