2027년 4월 1일 Exchange Online의 EWS 종료: 연동을 Microsoft Graph로 옮기기

어두운 방에서 이메일 받은 편지함을 띄운 노트북

Microsoft가 Exchange Online에서 Exchange Web Services(EWS)를 끄기 시작했습니다. 첫 강제 조치가 이번 달에 진행되고, 그 뒤로는 EWS 설정을 한 번도 건드리지 않은 테넌트가 하나씩 차단되며, 2027년 4월 1일부터는 모든 Microsoft 365 테넌트에서 EWS가 사라집니다. Microsoft는 2027년 4월 이후에는 예외가 없다고 분명히 밝혔습니다.

귀사가 만든 무언가가 EWS로 Microsoft 365 사서함과 통신한다면, 늦어도 그날, 어쩌면 훨씬 일찍 작동을 멈춥니다. 흔한 예는 이렇습니다. 고객 이메일을 거래처별로 정리하는 CRM, 보관이나 보존 스크립트, 회의실 예약 화면, 공유 지원 사서함을 읽는 티켓 시스템, 팀별 이메일 수를 세는 보고 작업입니다. 해결책은 Microsoft Graph를 대상으로 다시 작성하는 것이고, EWS로 할 수 있던 일 가운데 일부는 Graph에 대응하는 기능이 아예 없습니다.

날짜별로 일어나는 일

Microsoft는 테넌트별로 EWSEnabled 설정을 통해 EWS를 제어하며, 이 설정에는 Null(기본값), True, False의 세 값이 있습니다. 그 옆에 이제 두 번째 설정 EWSAllowedAppIDs가 생겼습니다. 여전히 EWS를 쓸 수 있는 애플리케이션 ID의 목록입니다. 현재 Microsoft Learn 페이지는 개요를 이렇게 제시합니다. "2026년 10월: 모든 조직에서 EWS가 전역적으로 비활성화되기 시작합니다", "2027년 4월: EWS가 완전히 비활성화됩니다."

세부 내용은 Exchange 팀이 10월 1일에 올린 글 EWS Deprecation Is Here에 있습니다. 전 세계 상용 클라우드 기준입니다.

2026년 10월 2일 태평양 시간 기준 하루 끝: Microsoft는 EWSEnabled가 True로 설정되어 있지만 허용 목록이 없는 모든 테넌트를 기록합니다.
2026년 10월 8일과 9일: 해당 테넌트에 대해 Microsoft가 허용 목록을 만들고, 지난 60일 동안 EWS를 사용한 애플리케이션 ID로 채웁니다.
2026년 10월 10일부터: EWSEnabled가 True이면 허용 목록이 필수입니다. 목록에 없는 앱은 거부됩니다.
그 뒤의 두 번째 단계: 여전히 Null인 테넌트는 EWSEnabled가 False로 설정되어 모든 애플리케이션의 EWS가 차단됩니다. 각 테넌트는 메시지 센터에서 7일 전에 경고를 받고, Microsoft가 그 직전에 60일간의 사용 기록으로 허용 목록을 채워 두므로 관리자는 True로 EWS를 다시 켤 수 있습니다.
2027년 4월 1일: EWS가 "완전히, 영구적으로 비활성화"되고, 테넌트 관리자는 EWSEnabled를 더 이상 바꿀 수 없습니다.

Microsoft의 다른 클라우드에 있는 테넌트는 메시지 센터를 통해 각자의 일정을 받습니다.

허용 목록은 해결책이 아니라 시간을 버는 수단입니다

자동 목록은 60일간의 트래픽으로 만들어지며, Microsoft 자신의 9월 4일 자 안내는 이 목록이 "드물게 실행되는 애플리케이션을 놓칠 수 있다"고 경고합니다. 분기 말 내보내기나 연말 보관 작업은 목록에 없을 것이고, 다음번 실행 때 실패할 것입니다.

허용 목록 변경은 적용되기까지 24시간이 걸리고, EWSEnabled 변경은 약 1시간이 걸립니다. 실패 후에 하는 수정은 최소 하루가 듭니다.

테넌트의 현재 상태를 보려면 Exchange Online PowerShell 권한이 있는 관리자가 다음을 실행하면 됩니다.

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

누구를 위한 글이고, 누가 여기서 그만 읽어도 되는가

온프레미스 Exchange Server는 영향을 받지 않습니다. Microsoft는 이번 종료가 "Microsoft 365와 Exchange Online에만" 적용되며 "Exchange Server의 EWS에는 변경이 없다"고 말합니다. 모든 사서함이 자체 서버에 있다면 여기서 그만 읽으셔도 됩니다.

하이브리드 구성은 더 자세히 봐야 합니다. 온프레미스 사서함은 계속 EWS를 쓸 수 있지만 클라우드 사서함은 Graph로 옮겨야 합니다. Microsoft의 9월 30일 자 하이브리드 관련 글은 지금 조치가 필요한 두 가지 경우를 다루며, 그중에는 보관 사서함이 Exchange Online에 있는 온프레미스 사서함도 있습니다. 이 경우 현재의 권고는 EWS를 켜 두고 하이브리드 애플리케이션을 허용 목록에 넣는 것입니다.

패키지 소프트웨어는 벤더의 몫입니다. EWS를 호출하는 것이 상용 제품이라면 Graph 버전을 내놓는 것은 벤더의 일이고, 귀사가 할 일은 벤더에게서 날짜를 받아 업데이트를 설치하는 것입니다. Microsoft 자체 클라이언트도 다르지 않습니다. 일부는 여전히 사용 보고서에 나타나며, 업데이트될 때까지 허용 목록이 필요합니다.

사내 코드는 귀사의 몫입니다. 스크립트, 사내 서비스, 커스터마이징한 오픈소스 도구, 몇 년 전 외주 업체가 만든 연동은 고쳐 줄 상위 공급자가 없습니다. 작업은 바로 여기에 있습니다. 규모를 가늠해 보자면, EWS로 Exchange와 통신하는 Python 라이브러리 exchangelib는 지난 한 달 동안 PyPI에서 1,174,625회 다운로드되었습니다. 그중 일부는 온프레미스 용도이지만, 얼마나 많은 코드가 EWS와 직접 통신하는지 짐작하게 해 줍니다.

1단계: EWS를 쓰는 모든 것 찾기

Microsoft 365 관리 센터의 EWS 사용 현황 보고서(보고서, 사용 현황, Exchange, EWS 사용 현황 탭)에서 시작하십시오. 애플리케이션마다 Microsoft Entra 애플리케이션 ID, 그 애플리케이션이 호출한 모든 SOAP 작업, 호출량, 마지막 활동 날짜를 보여 줍니다. 7일, 30일, 90일 단위로 거슬러 볼 수 있고 CSV로 내보낼 수 있습니다.

이 보고서에 대해 알아 둘 세 가지가 있습니다.

데이터는 주 단위로 집계되며 표시되기까지 최대 10일이 걸릴 수 있습니다.
애플리케이션 ID는 담당자가 아닙니다. 각 ID를 Microsoft Entra의 엔터프라이즈 애플리케이션과 대조한 뒤, 그것을 운영하는 사람이나 팀을 찾으십시오. 아무도 알아보지 못하는 ID가 몇 개 나올 것입니다.
SOAP 작업 열은 작업 규모를 알려 줍니다. FindItem과 GetItem만 호출하는 앱은 짧은 작업입니다. SyncFolderItems, Subscribe, ExportItems를 호출하는 앱은 프로젝트입니다.

90일로도 연간 작업은 놓치므로 반대쪽도 확인하십시오. 예약 작업과 cron 항목, 그리고 EWS 엔드포인트(Exchange.asmx), .NET용 EWS Managed API, exchangelib를 검색한 코드 저장소입니다. Microsoft의 지원 중단 안내 페이지에는 .NET 코드용 EWS 분석기(Visual Studio와 VS Code에서 EWS 호출을 표시하고 Graph 대응 기능을 제안)와 AI 지원 리팩터링 튜토리얼 링크도 있습니다.

2단계: 각 연동의 행방 정하기

목록의 모든 애플리케이션은 네 가지 답 중 하나를 받습니다.

폐기한다. 어떤 연동은 아무도 끄지 않았다는 이유만으로 남아 있습니다.
업데이트한다. 벤더 제품은 벤더 업그레이드를 받습니다. 날짜를 지금 합의하십시오.
Microsoft Graph로 다시 작성한다. 사내 코드의 기본 선택입니다.
다시 설계한다. Graph가 앞으로도 갖추지 않을 기능에 의존하는 모든 것이 해당합니다(아래 참조).

Microsoft는 워크플로를 다시 구현하는 방법으로 Power Platform도 제시합니다. 첨부 파일을 폴더로 전달하는 스크립트라면 이것이 가장 저렴한 답일 수 있습니다.

Graph로 다시 작성할 때 실제로 필요한 것

대부분의 EWS 작업에는 Graph에 직접 대응하는 기능이 있으며, Microsoft는 EWS와 Graph의 대응표를 관리합니다. 대응표는 쉬운 부분입니다. 어려운 부분은 대응표에 나오지 않는 것들입니다.

권한이 좁아지고, 그것은 장점입니다

로그인한 사용자 없이 EWS를 쓰는 앱은 EWS 애플리케이션 권한을 갖고 있으며, Microsoft는 이를 "모든 사서함에 대한 전체 액세스"라고 설명합니다. Graph는 이를 Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read 등 개별 권한으로 나눕니다.

앱이 접근할 수 있는 사서함도 제한할 수 있습니다. Exchange Online의 애플리케이션용 RBAC는 관리 범위나 관리 단위를 대상으로 권한을 할당하며, 이전의 애플리케이션 액세스 정책을 대체합니다. 회의실 예약 화면은 회의실 사서함 열두 개의 일정만 읽고 그 밖에는 아무것도 읽지 못하게 할 수 있습니다. 함정이 하나 있습니다. 이 방식으로 부여한 권한은 Microsoft Entra의 테넌트 전체 권한에 더해지므로, 그곳에서 Mail.Read에 아직 동의가 되어 있다면 범위 제한은 아무것도 제한하지 못합니다. Entra의 권한 부여를 제거하십시오.

가능하면 앱 인증에는 클라이언트 비밀 대신 인증서를 쓰고, 자격 증명은 스크립트와 저장소 밖에 두십시오.

동기화와 알림은 옮기는 것이 아니라 다시 만드는 것입니다

사서함 데이터의 로컬 사본을 유지하는 모든 것에는 대개 이것이 가장 큰 변화입니다.

동기화. SyncFolderItems는 Graph 메시지 델타 쿼리에, SyncFolderHierarchy는 메일 폴더 델타 쿼리에 대응합니다. 메시지 델타는 한 번에 폴더 하나씩 작동하므로, 사서함 전체를 동기화하려면 폴더 트리를 추적하고 폴더마다 델타 링크를 따로 저장해야 합니다. 필터링은 제한적이며(받은 날짜로만 가능), 결과에는 필터와 맞지 않더라도 삭제, 폴더 밖으로의 이동, 읽음 상태 변경이 포함됩니다.

알림. EWS의 스트리밍과 푸시 구독은 Graph 변경 알림이 되며, 직접 운영하는 웹훅이나 Azure Event Hubs 또는 Event Grid로 전달됩니다. 웹훅은 Microsoft 쪽에서 접근할 수 있어야 하므로, 방화벽 뒤에서 연결을 열어 두던 스크립트에게는 아키텍처의 변화입니다. 메일, 일정, 연락처 구독은 최대 10,080분(7일이 조금 안 됨), 알림에 데이터가 포함되면 1,440분까지만 유지되므로 무언가가 구독을 갱신해야 합니다. 사서함 하나에는 모든 애플리케이션을 합쳐 활성 구독이 최대 1,000개까지 허용됩니다.

잘 버티는 패턴은 이렇습니다. 알림은 힌트로 취급하고, 델타 쿼리를 실행해 무엇이 바뀌었는지 확인하며, 놓친 알림 때문에 잃었을 변경을 잡기 위해 타이머로도 델타 쿼리를 실행합니다.

데이터, ID, 처리량

저장된 ID. CRM이나 티켓 시스템이 이메일과 레코드를 연결하려고 EWS 항목 ID를 저장했다면 그 연결을 변환해야 합니다. Graph에는 바로 이 용도의 translateExchangeIds 함수가 있습니다. 변환은 별도의 마이그레이션 단계로 계획하십시오.
조회. ResolveNames는 People API에, GetUserAvailability는 getSchedule에, 부재 중 설정은 사서함 설정에 대응합니다. 가까운 대응 기능이지 똑같은 기능은 아닙니다.
제한(throttling). Graph는 앱과 사서함 쌍마다 10분당 10,000건의 요청, 동시 요청 4건, 5분당 150MB의 업로드로 제한합니다. 한 사서함에 수십 개의 병렬 EWS 스레드를 돌리던 대량 작업은 이 수치에 맞춰 다시 설계해야 합니다.

빈틈, 그리고 앞으로도 오지 않을 것

Microsoft는 아직 Graph에 없는 EWS 기능의 로드맵을 공개합니다. 보관 사서함, 공용 폴더 사서함, 그룹 사서함의 완전한 충실도의 가져오기와 내보내기, 현재 위치 보관에 대한 접근, Exchange Admin API를 통한 폴더 권한, MIME으로 초안이 아닌 메시지 만들기 등이 들어 있습니다. 대부분의 목표 시점은 2026년 4분기입니다. 몇 가지는 이미 끝난 3분기가 목표였으니, 그것을 전제로 설계하기 전에 실제로 무엇이 출시되었는지 확인하십시오. Microsoft 자신의 경고는 이렇습니다. 로드맵에 없는 기능이라면 EWS가 꺼지기 전에 Graph 대응 기능이 나오리라고 "계획하지 마십시오".

Graph에 영영 오지 않는 것으로 확정된 기능이 세 가지 있습니다.

일반 공용 폴더 접근(폴더와 항목의 생성, 읽기, 업데이트, 삭제).
일반 Microsoft 365 그룹 사서함 접근. Graph는 그 대신 그룹 대화, 스레드, 게시물을 다룹니다.
검색 사서함 접근. Microsoft는 그 대신 Purview eDiscovery를 안내합니다.

도구가 이 중 하나에 의존한다면 코드를 옮기는 것으로는 부족합니다. 데이터나 워크플로를 먼저 다른 곳으로 옮겨야 하며, 이는 다시 작성하는 것보다 오래 걸립니다.

6개월 계획

오늘부터 2027년 4월 1일까지는 6개월이 조금 안 됩니다. 현실적인 순서는 다음과 같습니다.

2026년 10월: 현재 상태 파악. EWSEnabled와 허용 목록을 확인합니다. 90일 치 사용 현황 보고서를 내보냅니다. Microsoft가 채운 목록을 검토해 있어서는 안 될 것을 빼고, 알고 있는 드문 작업을 추가합니다. 테넌트가 아직 Null이라면 Microsoft가 False로 바꾼 뒤에 무엇이 깨지는지 알게 되기를 기다리지 말고, 직접 목록을 설정하고 True로 바꾸는 것을 고려하십시오.

2026년 11월: 분류. 모든 애플리케이션 ID에 담당자와 답(폐기, 업데이트, 재작성, 재설계)을 지정합니다. 코드를 검색합니다. 공용 폴더, 그룹 사서함, 검색 사서함에 닿는 것은 모두 표시하고 지금 재설계를 시작합니다. 범위를 제한한 권한으로 Graph 앱 등록을 만듭니다.

2026년 12월부터 2027년 1월까지: 구축. 업무에서 가장 먼저 아쉬워할 연동부터 시작합니다. 동기화와 알림 배관은 한 번 만들어 재사용합니다. 저장된 ID를 변환합니다.

2027년 2월: 나란히 운영. EWS가 아직 작동하는 동안 구버전과 신버전을 같은 사서함에 대해 돌리고 결과를 비교합니다. 하나씩 검수가 끝나면 그 ID를 허용 목록에서 뺍니다. 그것이 곧 테스트입니다. 24시간을 기다린 뒤 다른 것이 멈추지 않았는지 확인하십시오.

2027년 3월: EWS를 직접 끄기. 4월 1일보다 충분히 앞서 EWSEnabled를 False로 설정합니다. 놓친 것이 있다면 아직 EWS를 다시 켤 수 있을 때 실패합니다. 4월 1일 이후에는 그 선택지가 사라집니다. 분기와 연간 작업도 그 전에 의도적으로 시험 실행하십시오. 1분기 마감 때 실행되는 작업은 EWS가 사라진 뒤에 처음으로 실행됩니다.

도움이 필요하시면

어려운 경우는 원래 개발자가 떠난 연동입니다. 저희의 레거시 시스템 유지보수 서비스는 바로 그런 경우를 위한 것입니다. 기존 코드를 읽고, EWS 부분을 Microsoft Graph로 다시 작성하고(권한, 동기화, 알림, ID 마이그레이션), 숫자가 맞을 때까지 구버전과 신버전을 나란히 돌립니다. 그 대신 귀사 팀 안에서 일할 엔지니어가 필요하다면 인력 증강 서비스를 참고하십시오.

사용 현황 보고서가 아무도 알아보지 못하는 애플리케이션 ID로 가득하다면 office@c9group.dev로 연락 주십시오.