WEBVTT

00:00:00.000 --> 00:00:07.900
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?

00:00:08.300 --> 00:00:11.920
이번 1월, M365 컨이더 커진 규모로 돌아옵니다.

00:00:12.260 --> 00:00:18.260
전세계 MVP와 업계 전문가들이 선보이는 라이브 세션, 실무 데모, 실용적인 지식을 만나보세요.

00:00:18.500 --> 00:00:23.600
뻔한 슬라이드는 없습니다. 지루한 유행어도 없습니다. 우리는 실질적인 과제를 해결합니다.

00:00:23.820 --> 00:00:29.520
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 그리고 자동화까지 다룹니다.

00:00:29.520 --> 00:00:35.220
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위한 맞춤형 세션이 준비되어 있습니다.

00:00:35.560 --> 00:00:40.100
10일 동안 다양한 기술을 탐구하고 전세계 커뮤니티와 연결될 수 있습니다.

00:00:40.400 --> 00:00:44.600
실시간으로 시청하고 조직에 바로 적용할 수 있는 실무 인사이트를 얻어보세요.

00:00:44.940 --> 00:00:51.040
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티 등록이 지금 시작되었습니다.

00:00:51.460 --> 00:00:53.640
오늘 바로 여러분의 자리를 확보하세요.

00:00:55.320 --> 00:00:57.580
M365.com.net을 방문하세요.

00:00:57.580 --> 00:01:04.480
지금 M365.com.net에서 등록하고 1월 라이브 세션에서 뵙겠습니다.

00:01:04.840 --> 00:01:08.180
데이터가 손대지 않아도 스스로 작동할 수 있다고 상상해보셨나요?

00:01:08.440 --> 00:01:11.000
실시간으로 재고 감소를 감지한다고 상상해보세요.

00:01:11.340 --> 00:01:15.600
이메일을 보내거나 대시보드를 확인할 필요 없이 시스템이 알아서 재고를 주문하는 것입니다.

00:01:15.840 --> 00:01:17.460
이것은 가상의 이야기가 아닙니다.

00:01:17.640 --> 00:01:20.340
바로 패브릭 데이터 액티베이터 위 실제 모습입니다.

00:01:20.340 --> 00:01:33.400
오늘 우리는 원시 데이터, 즉각적인 알림, 자동화된 대응을 연결하고, 이것이 파워비아이, 시냅스 및 마이크로소프트 패브릭이 다른 서비스와 연동되어 지체 없이 인사이트를 행동으로 바꾸는 방법을 보여드립니다.

00:01:33.620 --> 00:01:35.700
데이터 루프에 빠진 연결고리입니다.

00:01:35.920 --> 00:01:43.320
대부분의 팀은 실시간으로 운영된다고 말하지만, 막상 자세히 들여다보면 실제로는 다음 날이 되어서야 알게 되는 경우가 많습니다.

00:01:43.320 --> 00:01:48.160
대시보드는 15분, 30분, 때로는 1시간에 한 번씩 새로 고침됩니다.

00:01:48.340 --> 00:01:55.380
그때쯤이면 이미 포착해야 할 패턴은 변했고, 보고서는 실시간 데이터라기보다 경기 종료 후의 분석처럼 느껴지죠.

00:01:55.540 --> 00:01:58.640
최종 스코어가 나온 후에야 경기 내용을 확인하는 셈입니다.

00:01:58.860 --> 00:02:02.220
문제는 BI 도구가 무슨 일이 일어나는지 보여주지 못하는 것이 아닙니다.

00:02:02.420 --> 00:02:04.060
보통 그런 부분은 매우 잘하죠.

00:02:04.240 --> 00:02:07.100
빠진 조각은 그것을 본 다음에 발생하는 일입니다.

00:02:07.100 --> 00:02:14.020
현재 대부분의 워크플로우는 사람이 변화를 알아차리고, 어떤 조치를 취할지 결정한 뒤 실행하는 데 의존합니다.

00:02:14.240 --> 00:02:15.960
그것이 병목 현상을 만듭니다.

00:02:16.140 --> 00:02:20.580
특정 지표가 떨어졌을 때 고객에게 이메일을 보내는 것 같은 기본적인 일조차,

00:02:21.160 --> 00:02:26.140
시스템이 인사이트를 행동으로 직접 연결하도록 설정되어 있지 않아 수동작업이 되고 맙니다.

00:02:26.340 --> 00:02:29.460
이러한 지연 때문에 수많은 기회가 사라지고 맙니다.

00:02:29.700 --> 00:02:33.980
매출 하락 후 3시간이나 늦게 시작된 프로모션은 긴급성을 잃게 되죠.

00:02:33.980 --> 00:02:40.780
웹사이트 오류 급증을 다음 검토 회의 때까지 방치하면 다시는 되찾을 수 없는 전환율을 잃게 됩니다.

00:02:41.060 --> 00:02:45.340
인지와 행동 사이의 간급, 바로 그 지점에 패브릭 데이터 액티베이터가 있으며,

00:02:45.780 --> 00:02:48.080
이 간급을 수초 내로 줄이도록 설계되었습니다.

00:02:48.440 --> 00:02:51.600
마이크로소프트 패브릭 내부에 기본적으로 포함되어 있어,

00:02:52.120 --> 00:02:56.340
데이터 소스를 지속적으로 내보내거나 연결하거나 관리할 필요가 없습니다.

00:02:56.720 --> 00:03:01.780
이벤트 스트림을 실시간으로 읽고 사용자가 정의한 조건이 충족되면 즉시 반응합니다.

00:03:01.780 --> 00:03:07.480
차이점은 단순히 알림에서 그치지 않고, 시스템 전체에 연쇄적인 반응을 일으킬 수 있다는 점입니다.

00:03:07.680 --> 00:03:11.820
실시간 판매 피드가 여러 지역의 성과를 모니터링하고 있다고 가정해보겠습니다.

00:03:12.260 --> 00:03:16.440
보통은 대시보드에서 특정 지역의 급격한 하락을 발견하고, 조사하고,

00:03:16.860 --> 00:03:20.460
맞춤 제안을 작성하고, 쓰인을 받고, 프로모션을 시작해야 합니다.

00:03:20.660 --> 00:03:22.480
1시간 정도 걸릴 수 있는 일이죠.

00:03:22.700 --> 00:03:25.540
데이터 액티베이터를 사용하면 동일한 하락 발생 시,

00:03:25.540 --> 00:03:29.280
사전 승인된 API 호출이 마케팅 자동화 시스템으로 전송되어,

00:03:29.700 --> 00:03:33.700
경쟁사가 약점을 발견하기도 전에 몇 분 안에 맞춤 제안을 시작할 수 있습니다.

00:03:33.960 --> 00:03:35.980
적절한 담당자가 확인하기를 기다릴 필요도,

00:03:36.300 --> 00:03:38.460
명확한 조치를 두고 고민할 시간도 필요 없습니다.

00:03:38.780 --> 00:03:40.300
그것이 바로 진정한 변화입니다.

00:03:40.540 --> 00:03:41.980
기존 BI 도구는 추적하지만,

00:03:42.380 --> 00:03:44.520
데이터 액티베이터는 경청하고 대응합니다.

00:03:44.720 --> 00:03:48.260
일반적인 파워 BI, 새로 고침 주기가 30분이라고 가정하면,

00:03:48.900 --> 00:03:53.120
변경이 시작된 시점부터 감지 자체만으로도 이미 지연이 발생할 수 있습니다.

00:03:53.120 --> 00:03:57.220
데이터 액티베이터 트리거는 이벤트 스트림에 대해 거의 실시간으로,

00:03:57.700 --> 00:03:59.760
소스에 따라 수초 내에 대응할 수 있어,

00:03:59.920 --> 00:04:04.600
실행 가능한 시점을 실제 이벤트 발생 시점과 훨씬 가깝게 맞출 수 있습니다.

00:04:04.820 --> 00:04:06.520
또한 패브릭에 통합되어 있기 때문에,

00:04:06.740 --> 00:04:09.360
단일 대시보드나 데이터 세트에 국한되지 않습니다.

00:04:09.560 --> 00:04:12.880
생태계 내에서 의미 있는 어떤 부분과도 연결될 수 있습니다.

00:04:13.520 --> 00:04:17.220
해당 스트리밍 피드는 시냅스 데이터 파이프라인의 일부가 되어,

00:04:17.480 --> 00:04:21.220
여러 하위 시스템 및 AI 모델에 데이터를 공급할 수 있습니다.

00:04:21.220 --> 00:04:26.920
중요한 일이 발생하면 데이터 액티베이터는 단순히 대시보드에 알리는데 그치지 않습니다.

00:04:27.120 --> 00:04:31.680
문제를 해결하거나 기회를 즉시 활용할 수 있는 시스템에 신호를 보냅니다.

00:04:32.040 --> 00:04:34.580
이것이 바로 관찰과 실행을 잇는 가교입니다.

00:04:34.880 --> 00:04:39.680
직원들이 점심 식사 후에나 볼법한 참고용 메시지로 팀 채팅을 채우는 대신,

00:04:40.120 --> 00:04:41.980
그 즉시 다음 단계를 실행합니다.

00:04:42.520 --> 00:04:47.220
모든 유효한 이벤트를 이미 완료된 결정이자 실행된 동작으로 바꿉니다.

00:04:47.220 --> 00:04:51.220
표준 BI 워크플로우와 비교했을 때 그 이점은 분명합니다.

00:04:51.400 --> 00:04:53.940
모니터링만 하면 상황을 파악하는 데 그칩니다.

00:04:54.220 --> 00:04:57.100
모니터링과 대응이 합쳐지면 결과를 바꿀 수 있습니다.

00:04:57.360 --> 00:05:02.840
기회의 창이 빠르게 닫히는 환경에서 그 차이는 단순한 편리함을 넘어 경쟁력이 됩니다.

00:05:03.340 --> 00:05:10.700
다음으로 관리해야 할 복잡성을 추가하지 않고도 이미 사용 중인 도구들과 얼마나 자연스럽게 어우러지는지 살펴보겠습니다.

00:05:11.180 --> 00:05:13.600
단순한 알림을 넘어 패브릭 웹을 확인해보세요.

00:05:13.600 --> 00:05:17.320
팀지 알림을 하나 더 보내는 것은 자동화가 아니라 그저 소음일 뿐입니다.

00:05:17.480 --> 00:05:18.740
어떤 의미인지 아실 겁니다.

00:05:19.060 --> 00:05:24.600
모든 화면에 쏟아지는 팝업홍수 속에서 하나하나가 중요할 수도 중요하지 않을 수도 있는 문제들을 확인하라고 재촉합니다.

00:05:24.820 --> 00:05:27.500
처음에는 상황을 잘 통제하고 있다는 느낌이 들지만,

00:05:28.020 --> 00:05:32.180
곧 팀원들은 중요한 정보가 혼란 속에 묻히면서 알림을 무시하기 시작합니다.

00:05:32.580 --> 00:05:37.960
아이러니하게도 정보를 제공하기 위해 만들어진 시스템이 결국 당신을 더 눈멀게 만드는 셈입니다.

00:05:37.960 --> 00:05:44.820
우리 모두 월요일 회의에서 알림이 평소와 다를 바 없어서 중요한 고객 문제를 놓쳤다는 이야기를 들어본 적이 있을 겁니다.

00:05:45.060 --> 00:05:50.620
문제의 근본 원인은 감지 기능의 부족이 아니라 다음에 무엇을 해야 할지에 대한 지능적 판단의 부재입니다.

00:05:50.860 --> 00:05:54.060
지나치게 민감한 트리거는 작은 변동도 위기처럼 다루고,

00:05:54.160 --> 00:05:57.760
이로 인해 모든 사람이 알림을 무시하도록 길들여지는 문화가 만들어집니다.

00:05:57.940 --> 00:06:03.480
바로 이 지점에서 마이크로소프트 패브릭 위 일환인 데이터 액티베이터 위 증가가가 드러나기 시작합니다.

00:06:03.480 --> 00:06:10.140
단순히 덧붙여진 기능이 아니라 파워비아이, 시냅스, 패브릭 데이터 웨어 하우징과 바로 나란히 작동합니다.

00:06:10.340 --> 00:06:15.180
즉, 이미 분석과 파이프라인을 실행 중인 도구들과 같은 환경에서 작동한다는 의미입니다.

00:06:15.360 --> 00:06:20.600
지표가 흔들릴 때마다 알림을 보내는 대신, 그 흔들림이 작업을 중단할 만큼 중요한지 판단할 수 있습니다.

00:06:20.840 --> 00:06:26.580
마치 옛날 교환원처럼 작동하지만, 각 호출의 긴급성을 정확히 이해하는 지능적인 교환원이라고 생각하면 됩니다.

00:06:26.860 --> 00:06:31.860
예를 들어 데이터피드에서 로드 도중 제품 명명 형식이 깨졌다는 신호를 보내는 상황을 가정해봅시다.

00:06:31.860 --> 00:06:35.640
데이터 액티베이터는 어떤 회선이 올바른 시스템과 연결되어 있는지 알고 있습니다.

00:06:35.880 --> 00:06:38.700
레일이나 일글 마케팅팀에 알림 메시지를 보내지 않습니다.

00:06:38.920 --> 00:06:44.900
문제의 원인을 즉시 파악하여 잘못된 데이터가 하위 보고서로 흘러들어가기 전에 시스템이 로드를 중단하도록 처리합니다.

00:06:45.120 --> 00:06:46.600
실제 사례를 하나 들어보겠습니다.

00:06:47.080 --> 00:06:50.780
시냅스 파이프라인이 몇 초마다 금융거래 데이터를 가져오고 있습니다.

00:06:51.120 --> 00:06:55.560
공급업체 측의 결함으로 인해 업스트림 시스템 중 하나가 중복 레코드를 보내기 시작합니다.

00:06:55.800 --> 00:06:56.940
일반적인 알림만 사용한다면,

00:06:56.940 --> 00:07:01.180
안녕하세요 중복 항목이 감지되었습니다. 라는 팀즈 메시지나 이메일을 보게 될 것입니다.

00:07:01.360 --> 00:07:03.720
그럼 이제 그것은 누군가의 할일 목록에 남게 됩니다.

00:07:03.960 --> 00:07:08.540
데이터 액티베이터를 사용하면 중복 데이터가 발생하는 즉시 파이프라인을 일시 중지시켜,

00:07:09.000 --> 00:07:13.320
데이터 엔지니어가 잘못된 데이터가 웨어하우스에 유입되기 전 문제를 해결할 여유를 줍니다.

00:07:13.580 --> 00:07:17.680
사람이 우연히 대시보드를 확인하는 것이 아니라 시스템 차원에서 수정이 이루어지는 것입니다.

00:07:17.920 --> 00:07:19.400
그것이 결정적인 차이입니다.

00:07:19.640 --> 00:07:23.120
데이터 액티베이터는 단일 데이터 세트 나좁은 스트림에 얽매이지 않습니다.

00:07:23.120 --> 00:07:29.620
다양한 입력 유형, 구조화된 웨어하우스 테이블, 이벤트 스트림 및 기타 패브릭 연결 데이터 소스 전반에서 작동하며,

00:07:30.060 --> 00:07:33.260
사용자가 일일이 신경 쓸 필요 없이 동일한 논리 규칙을 적용합니다.

00:07:33.440 --> 00:07:37.340
이러한 서비스 간 포괄적인 범위는 단순히 문제가 생겼음을 아는 것을 넘어섭니다.

00:07:37.520 --> 00:07:40.820
언제 브레이크를 받고 언제 출발해야 할지 정확히 알고 있습니다.

00:07:41.100 --> 00:07:46.620
변환 로직 및 저장소와 같은 생태계 안에 존재하기 때문에 데이터 흐름과 충돌하지 않습니다.

00:07:46.880 --> 00:07:48.960
그 흐름 속에 내재되어 있기 때문이죠.

00:07:48.960 --> 00:07:53.920
그래서 수집, 변환, 검증, 해결 과정이 하나의 흐름으로 이어지는 체인을 구축하여,

00:07:54.300 --> 00:07:57.040
사람들이 인수인계를 위해 서로 뒤쫓아 다닐 필요가 없습니다.

00:07:57.320 --> 00:08:04.760
데이터에 단순히 반응하는 것과 시스템이 중간 과정에서 스스로 적응하여 품질과 적시성을 유지하는 것의 차이입니다.

00:08:05.000 --> 00:08:11.300
하지만 진정한 이점은 이것을 단순한 알림 도구가 아닌 운영위사 결정계층으로 인식할 때 나타나기 시작합니다.

00:08:11.300 --> 00:08:16.640
상황에 기반해 대응하기 때문에 불필요한 노이즈는 획기적으로 줄고,

00:08:16.720 --> 00:08:20.240
실제 의미 있는 조치를 유발하는 알림의 비율은 높아집니다.

00:08:20.620 --> 00:08:22.540
더 이상 업무에 압도되지 않습니다.

00:08:22.800 --> 00:08:26.600
적은 수작업으로도 노이즈 속에서 신호를 명확히 포착할 수 있습니다.

00:08:26.880 --> 00:08:28.460
이러한 결정이 작업 일시 중지,

00:08:28.800 --> 00:08:29.720
레코드 업데이트,

00:08:30.080 --> 00:08:32.700
문제 해결 시작 등 실제 변경 사항을 트리거할 수 있으므로,

00:08:33.160 --> 00:08:35.960
단순히 인지와 실행 사이의 지연 시간을 줄이는 것을 넘어섭니다.

00:08:36.140 --> 00:08:38.220
그 간극 자체를 완전히 없애버리는 것이죠.

00:08:38.220 --> 00:08:40.820
이제 사람들의 이목을 끄는 부분, 즉 API를 호출하고,

00:08:40.960 --> 00:08:43.600
마이크로소프트 외부 세계와 상호작용하는 부분에 대해 알아보겠습니다.

00:08:43.800 --> 00:08:45.240
내부에서 외부 세계를 호출할 때,

00:08:45.620 --> 00:08:48.960
데이터는 사용자가 부재중 전화를 확인하기도 전에 먼저 전화를 걸 수 있습니다.

00:08:49.200 --> 00:08:50.100
비유가 아닙니다.

00:08:50.320 --> 00:08:53.060
이미 추적 중인 동일한 이벤트 스트림을 활용하여,

00:08:53.200 --> 00:08:58.280
실시간으로 마이크로소프트 패브릭 생태계 외부의 무언가를 트리거하는 것을 의미합니다.

00:08:58.960 --> 00:09:02.820
대시보드를 확인하거나 팀즈 알림을 클릭하기를 기다리는 대신,

00:09:03.460 --> 00:09:07.260
시스템이 조건이 충족되는 즉시 비유적 혹은 문자 그대로

00:09:07.260 --> 00:09:10.940
외부 애플리케이션이나 서비스에 직접 신호를 보냅니다.

00:09:11.160 --> 00:09:14.240
대부분의 BI 설정은 바로 이 지점에서 한계에 부딪힙니다.

00:09:14.420 --> 00:09:16.060
인사이트를 도출하는 데는 탁월하며,

00:09:16.380 --> 00:09:18.900
때로는 화려한 시각화나 AI 지원 해설까지 제공하지만,

00:09:19.360 --> 00:09:22.040
결국 공을 넘겨주고 사용자가 직접 처리하기를 기대합니다.

00:09:22.240 --> 00:09:24.320
여전히 CRM을 열어 주문을 전송하거나,

00:09:24.720 --> 00:09:25.940
ERP를 업데이트하거나,

00:09:26.280 --> 00:09:27.940
프로세스를 수동으로 시작해야 합니다.

00:09:28.160 --> 00:09:31.400
그 간극이 바로 사람으로 인한 병목 현상이 다시 발생하는 지점입니다.

00:09:31.400 --> 00:09:33.160
문제는 몇 분 만에 감지할 수 있지만,

00:09:33.660 --> 00:09:36.100
누군가 처리할 시간이 생길 때까지 기다려야 하므로,

00:09:36.260 --> 00:09:37.960
실제 실행은 몇 시간 뒤에 이루어집니다.

00:09:38.120 --> 00:09:42.080
데이터 액티베이터를 사용하면 그 단계는 단축되는 것이 아니라 아예 사라집니다.

00:09:42.260 --> 00:09:46.620
하루 일과 중에 재고 수준이 재주문 임계치 아래로 떨어지는 상황을 상상해보세요.

00:09:46.980 --> 00:09:50.920
일반적인 환경이라면 운영 담당자가 파워비아이에서 이를 확인하고,

00:09:51.140 --> 00:09:53.520
구매부서에 메모를 보낸 뒤 확인을 기다려야 합니다.

00:09:53.760 --> 00:09:57.680
그 사이 에도 제품은 계속 판매되고 품절 상태에 가까워지게 되죠.

00:09:57.680 --> 00:10:04.540
하지만 데이터 액티베이터는 데이터가 기준선을 넘는 즉시 공급업체의 주문 시스템으로 직접 API 호출을 보낼 수 있습니다.

00:10:04.740 --> 00:10:07.340
구매 주문이 접수되고 배송이 대기열에 추가됩니다.

00:10:07.520 --> 00:10:11.160
팀원 누구도 아직 알림을 확인하지 않았는데, 이미 수정 작업은 진행 중입니다.

00:10:11.380 --> 00:10:15.000
이것이 바로 패브릭 내부에서 외부 호출을 직접 실행할 때 얻는 가치입니다.

00:10:15.240 --> 00:10:18.980
SES CRM, 레거시 ERP, 맞춤형 네스트 엔드포인트,

00:10:19.400 --> 00:10:23.200
심지어 파트너의 API까지 마이크로소프트 도구에만 국한되지 않고,

00:10:23.400 --> 00:10:27.440
실시간 트리거를 연결하여 탐지와 해결 사이의 간극을 메울 수 있습니다.

00:10:27.680 --> 00:10:31.240
결과물은 웹훅의 데이터를 게시하는 것처럼 간단할 수도 있고,

00:10:31.900 --> 00:10:38.680
완전히 다른 플랫폼에서 다단계 워크플로우를 트리거하는 형식화된 페이로드를 보내는 것처럼 구조화될 수도 있습니다.

00:10:39.180 --> 00:10:47.360
이 지점이 바로 패브릭이 단순한 분석 도구 모음을 넘어 운영환경의 중추 신경계처럼 작동하기 시작하는 순간입니다.

00:10:48.140 --> 00:10:52.180
이벤트가 발생하면 신경은 단순히 눈으로 신호를 보내는 것에 그치지 않고,

00:10:52.180 --> 00:10:55.380
즉각적으로 행동할 수 있는 팔다리에 지시를 내립니다.

00:10:55.700 --> 00:11:00.320
이것이 바로 운영을 모니터링하는 수준에서 스스로 규제하는 수준으로 나아가는 방법입니다.

00:11:00.540 --> 00:11:03.760
IoT 활용도가 높은 산업에서 이런 사례를 확인할 수 있습니다.

00:11:04.060 --> 00:11:08.080
중요기계에 진동센서가 설치된 제조공장을 상상해 보십시오.

00:11:08.260 --> 00:11:11.400
이 센서들은 실시간으로 데이터를 패브릭으로 전송합니다.

00:11:11.400 --> 00:11:22.160
수치가 고장 경고 범위에 진입하는 순간, 데이터 액티베이터는 다이나믹스 365에서 작업 주문을 생성 및 할당하여 기계가 고장에 가까워지기도 전에 엔지니어 일정을 잡습니다.

00:11:22.400 --> 00:11:30.220
관리자가 업무를 멈추고 직접 전화를 걸 필요 없이 시스템이 자동으로 작업을 배정하고 기술자가 필요한 맥락 정보까지 함께 전달합니다.

00:11:30.440 --> 00:11:33.660
다운타임이 이슈가 되기도 전에 수리 작업이 시작됩니다.

00:11:33.880 --> 00:11:38.700
자동화된 모니터링과 아웃바운드 API 위 결합이 바로 실질적인 자율성을 실현합니다.

00:11:38.700 --> 00:11:45.120
단순히 관련성 있는 알림을 필터링하는 것을 넘어 필터링된 트리거를 즉각적으로 일어나는 실질적인 행동과 연결하는 것입니다.

00:11:45.260 --> 00:11:51.940
데이터 기반에서 데이터 활성화로 도약하는 것이며 시스템의 대응 속도가 탐지 속도만큼 빨라지는 것입니다.

00:11:52.280 --> 00:12:02.440
제대로 설정하면 프로세스는 사람의 미세 관리를 피할 뿐만 아니라 탐지와 행동 사이의 루프가 긴밀하고 일관되게 상시 작동함으로 능동적으로 개선됩니다.

00:12:02.680 --> 00:12:08.300
누군가 알림을 받는지 걱정하는 대신 더 나은 규칙과 로직을 설계하는 데 집중할 수 있습니다.

00:12:08.300 --> 00:12:12.560
하지만 가장 반응이 빠른 신경계라도 무시할 수 없는 한계치는 존재합니다.

00:12:12.720 --> 00:12:16.800
시작하기 전에 이를 알지 못하면 결과는 순식간에 엉망이 될 수 있습니다.

00:12:17.100 --> 00:12:18.960
구축 전 경계를 파악하는 것.

00:12:19.440 --> 00:12:24.780
모든 자동화 영웅에게는 기원 이야기와 미리 알았더라면 좋았을 주의사항들이 있습니다.

00:12:25.280 --> 00:12:33.120
데이터 액티베이터를 사용할 때 탐지와 반응이라는 개념은 무한해 보이지만 실제로는 그 이면에 매우 실용적인 프레임워크가 있습니다.

00:12:33.120 --> 00:12:43.580
이것은 마법이 아니면 여전히 패브릭 위, 아키텍처 위에서 실행됨으로 생태계의 다른 모든 요소에 적용되는 동일한 용량 모델, 서비스 제한 및 설계 과정의 제약을 받습니다.

00:12:43.840 --> 00:12:49.880
그런 경계들을 무시하면 선의로 시작한 자동화가 순식간에 중단되는 상황을 곧 마주하게 될 겁니다.

00:12:50.140 --> 00:12:54.260
까다로운 점은 실패 지점이 대개 개념 증명 단계에서는 나타나지 않는다는 것입니다.

00:12:54.460 --> 00:12:57.460
소규모 테스트에서는 모든 것이 즉각적으로 이루어지는 것처럼 느껴집니다.

00:12:57.460 --> 00:13:01.360
조건이 트리거되고 작업이 실행되며 거의 즉시 결과를 확인할 수 있으니까요.

00:13:01.460 --> 00:13:08.840
규모를 확장하여 여러 외부 시스템을 연결하고 트리거 볼륨을 늘리며 복잡한 로직을 추가할 때 비로소 제약 사항들이 드러나기 시작합니다.

00:13:09.060 --> 00:13:11.860
지연 시간이 쌓이고 용량 사용량이 급증합니다.

00:13:12.100 --> 00:13:16.460
갑자기 그 실시간 의사 결정 엔진은 제한되거나 대기열에 걸리게 됩니다.

00:13:16.760 --> 00:13:24.380
트리거가 기술적으로는 연결되어 있지만 패브릭 위 기본 서비스 내부에서 실행되지 않는 소스에 위존할 때 어떤 일이 벌어질지 생각해보세요.

00:13:24.380 --> 00:13:29.680
보고서에 데이터를 공급하는 외부 이벤트 허브에서 데이터 스트림을 가져오는 경우를 예로 들 수 있습니다.

00:13:29.920 --> 00:13:40.780
데이터 액티베이터가 해당 피드에 의존하여 중요한 프로세스를 실행하려 하지만 소스 측의 처리 간격이 패브릭 위 목표 반응 시간 보다 느리다면 기대하는 응답성을 절대 얻을 수 없습니다.

00:13:41.080 --> 00:13:47.140
트리거 로직의 속도를 따라가지 못하는 반정적, 세미스테틱, 데이터에 기반하여 조건을 설정했기 때문에 롤아웃이 중단되는 경우를 보았습니다.

00:13:47.320 --> 00:13:50.600
자동화 자체가 실패한 것은 아니었지만 너무 늦게 작동해 의미가 없어진 경우였죠.

00:13:50.600 --> 00:13:52.780
모든 것을 모니터링하고 싶은 유혹도 있습니다.

00:13:52.780 --> 00:13:54.720
처음에는 그럴듯해 보입니다.

00:13:55.080 --> 00:14:02.820
모니터링 조건을 늘리면 대응 기회도 많아질 것 같지만 정의하는 모든 트리거는 패브릭 용량의 부하를 가중시킵니다.

00:14:03.440 --> 00:14:10.000
즉, BI 새로 고침, 데이터 흐름, 웨어하우스 쿼리를 지원하는 것과 동일한 용량을 소모하게 됩니다.

00:14:10.240 --> 00:14:16.800
이를 너무 과도하게 밀어붙이면 트리거가 컴퓨팅 자원을 독점하면서 다른 워크로드가 느려지는 연쇄 반응이 발생합니다.

00:14:16.800 --> 00:14:22.560
용량 계획은 자동화가 자초한다운 타임으로 변질되지 않도록 막아주는 필수적인 원칙이므로 선택사항이 아닙니다.

00:14:22.740 --> 00:14:24.340
지연 시간 목표 또한 중요합니다.

00:14:24.560 --> 00:14:30.180
데이터 액티베이터는 수초 내에 반응할 수 있지만, 이는 업스트림 및 다운스트림 시스템이 그 속도를 감당할 수 있을 때만 가능합니다.

00:14:30.320 --> 00:14:34.620
트리거된 API 호출이 15분마다 배치 처리되는 ERP 통합을 가리키고 있다면,

00:14:35.200 --> 00:14:37.700
사실상 내장된 지연 상황을 스스로 만든 셈입니다.

00:14:37.900 --> 00:14:42.160
트리거는 실행되지만, 최종 결과는 다음 배치 처리 때까지 기다려야 하니까요.

00:14:42.160 --> 00:14:46.600
시스템을 연결하기 전에 서비스 주기에 이러한 차이를 미리 파악해야 합니다.

00:14:46.800 --> 00:14:51.160
더 안전한 방법은 가치가 높고 빈도가 낮은 조건부터 시작하는 것입니다.

00:14:51.380 --> 00:14:57.860
즉, 하루에 몇 번만 트리거되더라도 각각의 자동화가 분명한 가치를 지니는 시나리오를 선택하는 것이 좋습니다.

00:14:58.100 --> 00:15:03.860
용량을 넘치게 하거나 다운스트림 서비스에 과부하를 주지 않으면 서효과를 입증하는 것이 핵심입니다.

00:15:04.080 --> 00:15:08.900
트리거 로직을 미세 조정하고 처리 프로필을 이해한 뒤에야 확장을 시작해야 합니다.

00:15:08.900 --> 00:15:14.660
가격 책정과 용량이 단순히 스토리지나 새로 고침에 관한 것만이 아니라는 점도 기억해야 합니다.

00:15:14.860 --> 00:15:18.300
트리거 평가와 작업 실행은 모두 동일한 풀에서 리소스를 소비합니다.

00:15:18.520 --> 00:15:21.300
그 아웃바운드 API 호출도 결국 컴퓨팅 자원입니다.

00:15:21.520 --> 00:15:25.260
조건을 확인하기 전에 실행하는 변환 작업도 컴퓨팅 리소스를 사용합니다.

00:15:25.460 --> 00:15:31.640
패브릭 유닛의 풀을 고려하지 않고 조건과 연결을 확장하면 예상보다 빠르게 한계에 부딪히게 됩니다.

00:15:31.980 --> 00:15:35.940
다행인 점은 한계 지점을 파악하고 나면 이를 우회하도록 설계할 수 있다는 것입니다.

00:15:35.940 --> 00:15:38.160
스스로 작동하는 프로세스를 구축하게 됩니다.