Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Microsoft Graph 변경 알림 쉽게 설명: 폴링 대신 실시간으로 (AI 더빙)

Transcript

Microsoft Graph 변경 알림 쉽게 설명: 폴링 대신 실시간으로 (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:49
지금 바로 등록이 가능합니다.
0:51
M365 con.net에 접속하여 오늘 바로 자리를 확보하세요.
0:56
주소는 M365 con.net입니다.
0:59
M365 con.net에서 참여하시고 1월 라이브 세션에서 뵙겠습니다.
1:04
오늘의 주제는 마이크로소프트 365로 개발하는 사람이라면 누구나 들어봤을 만한 내용입니다.
1:09
하지만 대부분의 사람들은 그 내부 작동 원리를 정확히 이해하지 못하고 있죠.
1:12
바로 마이크로소프트 그래프 변경 알림에 관한 이야기입니다.
1:15
도대체 무엇이며 왜 관심을 가져야 할까요?
1:18
먼저 이 기능이 해결하는 문제부터 살펴보겠습니다.
1:20
마이크로소프트 365에서 무언가 변경되었을 때 이를 감지해야 하는 앱을 만든다고 가정해보세요.
1:24
새 이메일이 도착하거나 누군가 셰어포인트 파일을 수정하거나 사내 디렉터리에 새 사용자가 추가되는 경우처럼 말이죠.
1:29
앱은 어떻게 이런 변경사항을 알아낼까요?
1:31
문제는 기존 방식인 폴링, 폴링 에 있습니다.
1:33
앱이 몇 분마다 마이크로소프트 그래프에 요청을 보내 마지막 확인 이후 새로운 소식이니? 라고 묻는 방식입니다.
1:38
변경사항이 없다면 요청 하나를 낭비한 셈이 있죠.
1:41
만약 확인 직후 5초 뒤에 변경이 발생했다면 다음 주기까지는 알 수 없습니다.
1:45
너무 자주 확인하면 리소스 낭비와 스로틀링 위험이 있고 너무 드물게 확인하면 정보를 놓치게 됩니다.
1:49
마이크로소프트는 과도하게 폴링하는 앱에 대해 실제로 스로틀링을 적용합니다.
1:53
개발자들은 이를 그래프 감옥이라 부르는데 요청수가 너무 많아 앱이 한동안 차단되는 현상입니다.
1:59
그렇다면 더 좋은 방법은 없을까요?
2:01
앱이 계속 새로운 변경사항을 묻는 대신 시스템이 무언가 바뀌었을 때 직접 알려준다면 어떨까요?
2:06
그것이 바로 변경알림이 하는 역할입니다.
2:08
마이크로소프트 그래프 변경알림이란 무엇일까요?
2:11
가장 간단한 정의를 말씀드리겠습니다.
2:13
변경알림은 앱이 끊임없이 확인하지 않아도 마이크로소프트 365위 이벤트에 즉각 반응하도록 해줍니다.
2:19
우편함의 동작감지 센서를 생각하면 이해가 쉽습니다.
2:22
매시간 우편함을 확인하러 갈 필요 없이 우편이 도착하는 순간 알려주는 센서를 설치하는 것과 같죠.
2:26
불필요한 확인으로 시간을 낭비할 필요가 없고 배달된 우편을 놓칠 일도 없습니다.
2:30
그것이 바로 변경알림이 여러분의 앱을 위해 해주는 일입니다.
2:33
새 이메일, 업데이트된 파일, 일정 이벤트 등 무언가가 변경되면 마이크로소프트 그래프가 앱으로 알림을 자동으로 보냅니다.
2:39
폴링은 필요하지 않습니다.
2:41
이 시스템은 구독과 알림이라는 두 가지 요소로 구성되며 이 둘은 함께 작동합니다.
2:45
구독은 무엇을 모니터링할지 마이크로소프트 그래프에 알려주는 단계입니다.
2:49
예를 들어 이 받은 편지함에 새 메시지가 오면 알려줘 라고 설정하는 것이죠.
2:53
또는 이 셰어포인트 라이브러리에서 파일이 업데이트되면 알려줘 와 같이 말입니다.
2:56
관심 항목을 등록하면 그래프가 이를 기록합니다.
2:59
그 다음 단계가 알림입니다.
3:00
변경사항이 발생하면 그래프는 사용자가 제공한 엔드포인트로 http 포스트를 보냅니다.
3:04
앱이 해당 포스트를 수신하면 변경사항을 인지하고
3:07
새 데이터를 가져오거나 워크플로우를 트리거하거나 데이터베이스를 업데이트하는 등의 다음 작업을 결정할 수 있습니다.
3:12
이것이 풀링과의 핵심적인 차이점입니다.
3:15
알림은 자동으로 전달됩니다.
3:17
앱이 일일이 물어볼 필요 없이 변경이 발생하는 즉시 시스템이 정보를 푸시합니다.
3:20
이것이 바로 이 시스템의 마법입니다.
3:22
마이크로소프트 그래프는 다양한 리소스에 대한 변경 알림을 지원합니다.
3:26
메시지, 이벤트, 연락처, 사용자, 그룹, 파일, 팀제 메시지, 보안 경고 등
3:30
그래프를 통해 액세스할 수 있는 거의 모든 항목을 변경 모니터링할 수 있습니다.
3:33
그런데 이를 실제로 어떻게 설정할까요?
3:35
무엇을 모니터링하고 어디로 알림을 보낼지 어떻게 그래프에 알릴까요?
3:38
구독을 생성하여 그래프에 모니터링할 대상을 지정하는 것입니다.
3:40
그렇다면 구독이란 무엇일까요?
3:42
단순한 등록 요청입니다.
3:43
앱이 이런 일이 발생하면 나에게 알려져 라고 요청하는 것이죠.
3:46
그 요청을 마이크로소프트 그래프 API로 보냅니다.
3:48
그러면 그래프는 이를 저장하고 대기합니다.
3:50
요청 시 그래프에 몇 가지 세부 정보를 제공해야 합니다.
3:52
첫째, 모니터링하려는 리소스, 즉 데이터 경로입니다.
3:55
예를 들어 사용자 계정 변경 사항을 모니터링한다면 우저스를 사용합니다.
3:59
또는 새 이메일을 확인하려면 미, 메일 폴더즈, 인박스, 메시지스를 사용합니다.
4:03
둘째, 변경 유형입니다.
4:04
항목이 생성, 업데이트, 삭제될 때 알림을 받고 싶으신가요?
4:08
하나만 선택할 수도 있고 세 가지 모드를 요청할 수도 있습니다.
4:10
셋째, 알림 URL입니다.
4:12
이것은 엔드포인트의 주소로 변경 사항 발생 시 그래프가 알림을 보내야 할 곳입니다.
4:15
공개적으로 액세스 가능한 HTTPS 엔드포인트여야 합니다.
4:18
다른 우회 방법은 없습니다.
4:19
넷째, 만료 날짜입니다.
4:21
구독은 영원히 지속되지 않습니다.
4:23
구독이 만료될 미래의 날짜와 시간을 선택해야 합니다.
4:25
하지만 리소스마다 최대 수명이 다릅니다.
4:28
아울록 메시지는 최대 7일까지 유지될 수 있습니다.
4:30
팀즈 채팅 메시지는 최대 3일까지 유지됩니다.
4:34
상태 정보는 어떨까요? 그 정보는 1시간 후에 만료됩니다.
4:38
구체적인 예를 들어보겠습니다.
4:39
회사 동료의 직함이 변경될 때 알림을 받고 싶다고 가정해봅시다.
4:42
사용자 리소스에 대해 업데이트됨, 변경 유형으로 구독을 생성합니다.
4:46
알림 URL을 지정하고 만료 기한을 며칠 뒤로 설정합니다.
4:50
누군가 에이저 AD에서 프로필을 업데이트하면
4:52
그래프 가엔드포인트로 알림 페이로드를 전송합니다.
4:55
그 페이로드에는 사용자 ID와 변경된 내용이 포함되어 있습니다.
4:58
그러면 앱이 이를 처리하여 HR 시스템을 업데이트하거나
5:01
관리자에게 알림을 보내는 등 필요한 작업을 수행할 수 있습니다.
5:03
그래프는 구독 요청에 대해 구독 ID로 응답합니다.
5:06
나중에 구독을 관리, 갱신, 업데이트 또는 삭제할 때의 ID가 필요합니다.
5:10
하지만 중요한 점이 있습니다.
5:12
그래프는 알림을 보내기 전에 엔드포인트가 실제로 활성화되어
5:15
대기 중인지 확인해야 합니다.
5:17
이를 위해서는 핸드쉐이크가 필요합니다.
5:19
핸드쉐이크 유효성 검사 토큰에 대해 설명하겠습니다.
5:22
구독을 생성할 때 마이크로소프트 그래프는
5:24
엔드포인트를 무조건 신뢰하지 않습니다.
5:26
먼저 테스트핑, 핑인 확인 요청을 보냅니다.
5:29
그 핑에는 이미 문자열인 유효성 검사 토큰이 포함되어 있습니다.
5:32
엔드포인트는 해당 토큰을 받아 10초 이내에 일반 텍스트로 다시 보내야 합니다.
5:36
배달기사가 택배를 두고 가기 전에 초인종을 눌러 집에 있는지 확인하는 것과 같습니다.
5:41
아무도 응답하지 않으면 기사는 아무것도 남기지 않습니다.
5:43
여기서도 마찬가지입니다.
5:45
엔드포인트가 유효성 검사 토큰을 다시 보내지 않으면
5:47
그래프는 알림을 보내지 않습니다.
5:49
응답은 json이나 xml이 아닌 일반 텍스트, 즉 원본 토큰 문자열 이어야 합니다.
5:53
형식이 잘못되면 핸드쉐이크는 실패합니다.
5:56
이는 보안 확인 절차입니다.
5:57
엔드포인트가 활성화되어 대기 중이며 귀하의 통제하에 있음을 증명합니다.
6:01
이는 누군가 타인의 알림을 가로채려고 본인이 소유하지 않은 url로 구독을 연결하는 것을 방지합니다.
6:06
핸드쉐이크가 없으면 구독도 없습니다.
6:08
그래프가 생성 요청을 거부하고 오류가 발생합니다.
6:11
엔드포인트를 수정하고 다시 시도해야 합니다.
6:13
핸드쉐이크가 성공하면 구독이 활성화되고 알림이 전송되기 시작합니다.
6:17
하지만 한 가지 기억할 점이 있습니다.
6:18
알림은 영원히 전송되지 않습니다.
6:20
연결 유지하기, 구독 갱신, 모든 구독에는 만료 날짜가 있습니다.
6:25
생성할 때 만료일을 설정합니다.
6:26
그래프가 이를 강제로 적용합니다.
6:28
만료일이 되면 구독이 중단됩니다.
6:30
더 이상 알림은 오지 않습니다.
6:32
주차 미터기를 생각해보세요.
6:34
시간을 설정해두고 시간이 다 되면 미터기 표시가 만료되는 것과 같습니다.
6:38
리소스마다 제한시간이 다릅니다.
6:40
아울룩 메시지는 7일, 팀즈 채팅 메시지는 3일,
6:43
셰어포인트 파일은 약 30일, 상태 정보는 1시간 동안 유지됩니다.
6:47
따라서 앱이 구독을 생성한 후 방치해서는 안됩니다.
6:50
구독을 계속 유지하는 프로세스가 필요합니다.
6:52
갱신은 간단합니다.
6:53
구독 아이디와 함께 패치, 패치 요청을 보내세요.
6:56
새 만료 날짜를 포함합니다.
6:57
현재 구독이 만료되기 전에 수행하면 그래프가 구독을 연장해줍니다.
7:01
제가 권장하는 모범 사례는 다음과 같습니다.
7:03
받는 모든 알림에서 만료 타임 스탬프를 확인하세요.
7:06
예를 들어 만료가 하루 내로 다가왔다면 즉시 갱신하세요.
7:09
그렇게 하면 구독 관리만을 위한 별도의 백그라운드 작업이 필요하지 않습니다.
7:13
마이크로소프트는 수명주기 알림 기능도 추가했습니다.
7:15
이 경고들은 구독이 만료되기 전에 미리 알려줍니다.
7:18
구독이 종료되려 하거나 액세스 토큰의 재인증이 필요할 때 이를 알려줍니다.
7:22
이를 구독하면 문제가 발생하기 전에 앱이 갱신할 수 있습니다.
7:25
하지만 엔드포인트가 다운되거나 갱신기간을 놓치면 어떻게 될까요?
7:29
그때 바로 안전망이 필요합니다.
7:31
문제가 발생했을 때를 위한 신뢰성과 안전망입니다.
7:34
구독은 활성화되어 있고 엔드포인트는 수신 중이며 알림이 잘 흐르고 있습니다.
7:37
모든 것이 좋아 보이지만 무언가 고장나면 어떻게 될까요?
7:40
엔드포인트가 유지 보수로 다운되거나 네트워크 문제로 알림이 누락되거나
7:43
단순히 갱신기간을 놓쳐 구독이 만료될 수 있습니다.
7:46
이런 일은 발생할 수 있습니다.
7:48
문제는 어떻게 복구하느냐입니다.
7:49
마이크로소프트 그래프는 웹북 엔드포인트가 3초 이내에 빠르게 응답할 것을 기대합니다.
7:53
시간이 더 걸리면 그래프는 이를 느린 것으로 표시합니다.
7:56
10분 동안 응답의 10% 이상이 3초를 초과하면 그래프는 알림을 10분간 지연시킵니다.
8:01
복구 여부를 확인하기 위해 적은 샘플만 보냅니다.
8:03
상황은 더 악화될 수 있습니다.
8:05
응답의 15% 이상이 10초의 제시도 타임아웃을 초과하면 그래프는 엔드포인트를 삭제된 것으로 표시합니다.
8:10
알림이 10분 동안 완전히 중단됩니다.
8:11
모두 사라집니다.
8:12
다시는 되돌릴 수 없습니다.
8:14
따라서 엔드포인트는 빠르고 안정적이어야 합니다.
8:16
모든 알림을 3초 이내에 처리해야 한다는 의미는 아닙니다.
8:20
200이 승인 응답으로 빠르게 수신 확인만 하고 알림은 비동기적으로 처리하세요.
8:24
Q에 넣으세요.
8:25
나중에 처리하면 됩니다.
8:27
핵심은 빠른 응답입니다.
8:28
완벽한 엔드포인트라도 문제는 발생할 수 있습니다.
8:30
구독은 만료될 수 있습니다.
8:32
네트워크 장애는 일어납니다.
8:33
드문 경우지만 마이크로소프트 그래프 자체가 알림을 놓칠 수도 있습니다.
8:36
그렇기 때문에 안전망인 델타 커리가 필요합니다.
8:39
이렇게 생각해보세요.
8:40
변경 알림은 화재 경보기입니다.
8:41
지금 무슨 일이 일어나고 있는지 알려줍니다.
8:43
델타 커리는 스프링클러 시스템입니다.
8:45
경보기가 놓친 모든 것을 잡아냅니다.
8:47
둘은 함께 작동합니다.
8:48
알림은 실시간 인식 기능을 제공합니다.
8:50
델타 커리는 언제든 조정 가능한 완전한 그림을 제공합니다.
8:53
권장되는 패턴은 간단합니다.
8:55
변경 알림을 사용하여 즉각적으로 파악하세요.
8:57
몇 시간 또는 하루에 한 번씩 델타 커리를 실행하여 놓친 항목을 확인하세요.
9:02
이렇게 하면 알림이 손실되거나 구독이 만료되더라도 변경 사항을 연구적으로 놓치지 않습니다.
9:07
실제 활용 사례입니다.
9:08
무엇을 구축할 수 있을까요?
9:10
그렇다면 이것이 실제로 무엇을 가능하게 할까요?
9:12
몇 가지 실제 사례를 살펴보겠습니다.
9:13
인사 자동화를 예로 들어보겠습니다.
9:15
내일 회사에 누군가 입사한다고 가정해보세요.
9:17
엔트라 아이디가 새 사용자를 생성하는 순간 변경 알림이 발생합니다.
9:21
앱이 프로필을 가져와 인사 플랫폼, 근태 관리, 건물 출입 권한 계정을 몇 초 만에 모두 생성합니다.
9:26
폴링도 없고 지연도 없습니다.
9:28
보안 경고의 경우 사용자 계정이 비활성화된다고 가정해봅시다.
9:31
변경 알림이 의심스러운 변경 사항을 확인하고 보안팀에 알리는 워크플로우를 트리거합니다.
9:35
예전에는 몇 분마다 폴링해야 했습니다.
9:38
이제는 즉시 알 수 있습니다.
9:39
콘텐츠 처리도 같은 방식으로 작동합니다.
9:41
셰어포인트 문서 라이브러리에 파일이 올라오면 그것이 송장인지 확인하고 싶을 것입니다.
9:45
알림을 통해 새 파일이 있음을 알 수 있습니다.
9:47
앱이 파일을 가져와 AI로 분류하고 적절한 비용 처리 시스템으로 전송하며 이 모든 것이 자동으로 이루어집니다.
9:52
실시간 대시보드를 통해 몇 시간 전 데이터가 아닌 발생하는 즉시 분석 결과를 확인할 수 있습니다.
9:56
변경 알림은 데이터버스와 패브릭을 즉시 동기화합니다.
9:59
파워비아이 대시보드가 거의 실시간으로 업데이트됩니다.
10:05
앱소프트는 웹북을 통해 실시간 동기화를 추가하여 AI 에이전트가 데이터가 변경되는 즉시 대응하게 합니다.
10:10
다이나믹스 365에서 고객 기록이 업데이트되면 코파일럿 에이전트가 기다릴 필요 없이 즉시 후속 조치를 생성합니다.
10:17
이 모든 사례에는 공통점이 하나 있습니다.
10:19
변경 알림 이전에는 매시간 또는 매일 폴링하는 예약된 작업을 구축해야 했습니다.
10:24
작동은 했지만 느리고 비효율적이며 불안정했습니다.
10:27
변경 알림은 이러한 모델을 완전히 뒤바꿉니다.
10:29
실시간, 이벤트 기반, 즉각적입니다.
10:32
적절한 전달 채널 선택하기.
10:33
모든 앱이 동일한 전달 방식을 필요로 하지는 않습니다.
10:36
옵션을 살펴보겠습니다.
10:37
웹북크가 가장 간단합니다.
10:39
그래프가 엔드포인트로 http 포스트를 보내면 이를 처리하고 넘어가면 됩니다.
10:43
시간당 수백 개의 알림 수준인 낮거나 중간 정도의 볼륨에는 충분합니다.
10:46
하지만 더 큰 규모를 구축 중이라면 어떨까요?
10:48
초당 수천 개의 알림은 단일 엔드포인트에 과부하를 줄 수 있습니다.
10:51
더 강력한 무언가가 필요합니다.
10:53
이벤트 헙스는 초당 수백만 개의 이벤트를 처리합니다.
10:56
그래프가 알림을 하나씩 보내는 대신 허브로 보냅니다.
10:59
앱이 자신의 속도에 맞춰 읽어오므로 플러딩 위험이 낮습니다.
11:02
이는 수천 개의 셰어포인트 사이트나 수백만 개의 사소함과 같은 대규모 엔터프라이즈 시나리오를 위한 것입니다.
11:06
그리고 서버 리스 옵션인 이벤트 그리드 가 있습니다.
11:09
에이저 펑션스나 로직 앱스로 알림을 전송하며
11:11
제시도 및 데드 레터링을 자동으로 처리합니다.