# Microsoft Outlook 복구가 트래픽 폭주로 계속 실패했습니다

Published: 2026-11-13

Microsoft의 11월 12~13일 이메일 중단 사태는 복구 루프를 노출시켰습니다. 복구된 서버가 트래픽 폭주 시 다시 응답하지 않을 수 있다는 것이죠. 11월 13일 11:04:50 UTC 승인된 마감 시점에는 아시아 태평양 일부 지역에서 복구가 진행되었으나, 다른 지역에서는 간헐적인 문제와 작업이 남아 있었습니다. 이 후속 보고서는 종속성과 지연된 메일 보호 조치에 대해 설명합니다.

Canonical: https://thedailydiff.dev/ko/video/2026-11-13-microsoft-recovery-loop/

## 이 동영상에서 다루는 내용

- 각 작업의 백엔드 종속성을 확인하세요. 대부분의 핵심 Teams 기능과 직접 SharePoint 파일 액세스는 계속 작동했지만, Exchange에 종속된 기능은 손상되었습니다.
- Microsoft는 복구된 서버가 트래픽이 몰리면 다시 응답하지 않을 수 있다고 보고했습니다. 이들의 상태 처리 구성 요소 설명은 가설로 남아 있습니다.
- 48시간으로 연장된 이메일 시간 초과는 큐 및 백로그 처리 중 지연된 메일을 보존하기 위한 것이었습니다. 이는 수리 마감 기한이나 보편적인 배달 보장은 아니었습니다.
- 일반적인 Graph 스로틀링 지침은 Retry-After 헤더가 있을 경우 이를 따르고, 없을 경우 지수 백오프를 사용하는 것을 권장합니다. 이는 이 사건을 진단하거나 복구하지 않습니다.

## 자주 묻는 질문

### Microsoft의 복구된 메일 서버가 트래픽 폭주로 다시 실패할 수 있었던 이유는 무엇입니까?

Microsoft는 복구된 서버가 트래픽을 받으면 다시 응답하지 않을 수 있다고 보고했습니다. 조사에 따르면 과부하된 프로세스와 서버 상태를 처리하는 구성 요소에 잠재적인 문제가 있었지만, 초기 트리거는 최종 사고 보고서가 나올 때까지 기다려야 했습니다. 이 사건은 보고된 복구, 작업, 재발 순서를 개념적으로 보여주는 것이며, 입증된 내부 아키텍처나 최종 근본 원인을 주장하는 것은 아닙니다.

### 캘린더 기능이 실패하는 동안 Teams 통화가 작동할 수 있었던 이유는 무엇입니까?

Microsoft의 확장된 서비스 상태 알림에 따르면 대부분의 핵심 Teams 통화, 회의 및 채팅은 계속 작동했습니다. 캘린더 및 일정 관리 시나리오는 Exchange Online에 종속되어 중단 기간 동안 실패할 수 있었습니다. 직접 SharePoint 파일 액세스도 계속 작동했습니다. 유용한 애플리케이션 수준의 구분은 제품 로고 아래의 모든 기능을 동일한 실패 상태를 공유하는 것으로 간주하는 대신, 작업 뒤에 있는 종속성을 확인하는 것입니다.

### 48시간 이메일 시간 초과가 수리 마감 기한을 설정했습니까?

Microsoft는 큐 및 백로그 처리를 우선시하면서 지연된 메시지를 보존하기 위해 이메일 시간 초과 창을 확장했습니다. 이는 복구 중에 지연된 메일에 더 많은 시간을 부여했습니다. 공개 알림에는 48시간 수리 마감 기한이나 모든 메시지가 수신자에게 도달할 것이라는 보장이 제공되지 않았습니다. 따라서 보류 중이거나 큐에 있는 알림은 시간에 민감한 워크플로우가 이에 의존하기 전에 실제 배달 또는 결과 확인이 필요했습니다.

### Exchange 중단이 Microsoft Graph 애플리케이션에 어떤 영향을 미쳤습니까?

Microsoft에 따르면 Exchange Online 메일, 캘린더 및 연락처에 대한 요청이 시간 초과될 수 있었습니다. 애플리케이션은 서로 다른 기본 종속성을 가진 작업 전반에 걸쳐 다른 결과를 만날 수 있었습니다. 이 사건은 작업의 실제 서비스 종속성을 확인할 것을 권장합니다. Microsoft의 별도의 일반 스로틀링 문서는 Retry-After 헤더가 없을 때 이를 따르고 지수 백오프를 사용하는 것에 대해 논의합니다. 이러한 정책은 이 사건의 원인을 규명하거나 서비스 복구를 약속하지 않습니다.

### Microsoft의 복구에 대한 The Daily Diff의 평결은 무엇이었습니까?

The Daily Diff의 평결은 NEEDS REVIEW였습니다. Microsoft의 업데이트에 따르면 복구된 서버가 트래픽 폭주로 실패하는 것으로 나타났기 때문에 Niko는 복구를 계속 검토했습니다. 실제 작업이 들어오는 지속적인 서비스가 유용한 복구 테스트였습니다. Microsoft가 완화 후 완전한 사고 보고서와 다층 방어 조치를 약속했음에도 불구하고, 이 사건의 보고 마감 시점까지 초기 원인은 미해결 상태로 남아 있었습니다.

## 챕터

- 0:00 복구된 서버가 다시 실패한 이유는 무엇입니까?
- 0:19 어떤 기능이 Exchange에 종속되었습니까?
- 1:03 용량 부족이 서비스에 어떻게 과부하를 줍니까?
- 1:34 Microsoft는 처음에 무엇을 시도했습니까?
- 2:48 보고 마감 시점에 무엇이 알려져 있었습니까?
- 3:17 하나의 Graph 요청이 실패할 수 있었던 이유는 무엇입니까?
- 4:05 48시간 메일 창은 무엇을 얻을 수 있습니까?
- 4:48 지속적인 복구는 무엇을 증명해야 합니까?

## 번역된 스크립트

원래 영어 내레이션에서 번역되었습니다. 사용 가능한 오디오 및 캡션은 YouTube에서 제어합니다.

### 복구된 서버가 다시 실패한 이유는 무엇입니까?

0:00 Microsoft는 메일 서버를 서비스에 다시 투입했습니다. 트래픽이 돌아오면 다시 응답을 멈출 수 있었습니다. 개발자 후속 보고서입니다. 이 비디오에서 복구가 계속 실패한 이유는 무엇입니까? 그리고 앱의 어떤 부분이 여전히 작동했습니까? Microsoft는 또한 지연된 이메일에 48시간을 부여했습니다. 그것이 실제로 당신에게 무엇을 얻어다 줍니까? 11월 13일 금요일, The Daily Diff입니다.

0:18 Exchange Online은 Microsoft의 호스팅 이메일 서비스이며, 다른 Microsoft 365

### 어떤 기능이 Exchange에 종속되었습니까?

0:22 기능들이 이에 의존합니다. 여기 Microsoft의 상태 페이지에서 유용한 구별법이 있습니다. Teams 통화 및 그룹 채팅은 대부분 작동했습니다. 캘린더 기능 및 사서함 데이터 요청은 실패할 수 있었습니다. 애플리케이션이 실제로 사용하는 종속성을 확인하세요. 즉, 캘린더가 작동하지 않더라도 회의는 여전히 진행될 수 있다는 의미입니다. SharePoint 파일에 대한 직접 액세스도 계속 작동했으며, 일부 공유 기능은 영향을 받았습니다.

0:42 창문의 로고는 다음 클릭에 어떤 백엔드가 필요한지에 대해 거의 알려주지 않습니다. 중단은 목요일에 시작되었고, Microsoft는 처음에 미주 지역의 사서함 액세스를 조사했습니다. 이후 모든 지역의 사용자가 영향을 받을 수 있음을 확인했습니다. CNN은 은행, 정부 및 법원 전반에 걸쳐 문제가 보고되었다고 보도했습니다. 누락된 이메일은 누군가의 실제 업무가 도착에 의존하기 전까지는 불편할 뿐입니다. Microsoft의 초기 설명은 사용 가능한 서버의 손실이었습니다. 그 기계들이 처리했어야 할 작업이 남아있는 인프라에 부담을 주었습니다.

### 용량 부족이 서비스에 어떻게 과부하를 줍니까?

1:06 용량이 사라지면 일반적인 수요만으로도 서비스에 과부하를 줄 수 있습니다. 아무도 갑자기 이메일 보내기에 대한 열정을 발견하지 않았더라도 큐는 길어집니다. 이후 회사는 자동화된 상태 확인을 조사했습니다. 이러한 확인은 서버가 작업을 수행할 수 있는지 여부를 결정하는 데 도움이 됩니다. Microsoft는 서버 상태를 처리하는 구성 요소가 관련될 수 있다고 밝혔습니다. 이는 아직 진행 중인 조사에서 나온 가설입니다. 왜 그 서버들이 처음에 사용할 수 없게 되었는지 정확히 설명하는 최종 사고 보고서는 없습니다. 업데이트 내용은 마치 당직 근무조가 아침 식사에 점차 흥미를 잃어가는 것 같습니다.

1:29 배포를 일시 중지합니다. 트래픽을 이동합니다. 서버를 다시 시작합니다. Microsoft는 부분 집합을 되살린 대체 상태 확인을 검증하고,

### Microsoft는 처음에 무엇을 시도했습니까?

1:37 응답하지 않는 기계를 감지하고 다시 시작하는 자동화된 시스템을 준비했습니다. 각 업데이트는 용량을 복구하려는 시도를 설명했습니다. 그런 다음 복구 루프를 설명하는 문장이 나왔습니다. Microsoft는 서비스에 복구된 서버가 트래픽을 받으면 다시 응답하지 않을 수 있다고 말했습니다. 기계가 다시 작동하고 실제 작업을 받은 다음 응답을 멈출 수 있었습니다. 그 관찰은 답변에서 누구의 확신 있는 이론보다 더 강력한 증거입니다. 그 상태들을 통해 동일한 서버를 상상해 보세요. 사용 불가능. 서비스에 복구됨.

1:59 트래픽 처리 중. 다시 응답하지 않음. 이것이 Microsoft의 설명을 보여줍니다. 마지막 전환을 유발하는 원인은 아직 답변되지 않았습니다. 재시작은 일시적인 개선을 가져올 수 있지만, 서버를 무력화시키는 조건은 해결되지 않은 채로 남아 있습니다. 껐다 다시 켜라는 조언은 초과 근무 수당을 청구하기 시작합니다. 엔지니어는 작업이 돌아온 후 어떤 일이 발생하는지 확인해야 합니다.

2:18 고객은 다음 요청과 그 다음 요청에도 서비스가 계속 작동하기를 원합니다. Microsoft는 일부 위치에서 영향을 받는 인프라에 도달하는 특정 트래픽을 제한했습니다. 또한 이전 구성을 사용하여 서버의 일부를 재구축하여 응답성을 유지하는지 테스트했습니다. 이것들은 보고된 완화 실험이었습니다. 복구 중 배포를 일시 중지하는 것이 금요일 배포가 원래 중단을 유발했다는 증거를 제공하지는 않습니다.

2:39 Microsoft의 금요일 11시 4분 UTC 업데이트에 따르면, 아시아 태평양 일부 지역에서 복구 조치가 완료되었습니다. 트래픽은 점차 돌아왔고, 사서함 액세스 및 지연된 이메일 처리에서 개선이 있었습니다. 일부 사용자는 여전히 간헐적인 문제를 겪을 수 있었고,

### 보고 마감 시점에 무엇이 알려져 있었습니까?

2:48 다른 지역에서는 복구가 계속되었습니다. 그것이 저희의 보고 마감 시점입니다. Microsoft는 악의적인 활동의 증거가 없다고 밝혔으며, 완화 후 완전한 사고 보고서를 약속했습니다. 악당을 지목하기 전에 그 보고서를 기다리겠습니다. 인터넷 탐정 작업은 페이지 새로 고침을 마치기도 전에 범인을 제공할 수 있습니다. 개발자의 경우 Microsoft Graph는 종속성을 특히 놓치기 쉽게 만듭니다. Exchange 메일, 캘린더 및 연락처에 대한 요청이 시간 초과될 수 있었습니다.

3:10 애플리케이션은 한 작업에 대해 Graph를 성공적으로 호출할 수 있지만 다른 작업에서는 실패할 수 있습니다. 성공적인 관련 없는 요청은 사용자가 필요로 하는 사서함 작업이 완료될지 여부에 대해 거의 알려주지 않습니다. 상태 페이지조차 자체적인 비상 탈출 경로가 필요했습니다.

### 하나의 Graph 요청이 실패할 수 있었던 이유는 무엇입니까?

3:20 Microsoft는 관리자가 서비스 상태를 읽기 위해 관리 센터를 로드할 수 없을 수 있으므로 사고 정보를 공개적으로 게시했습니다. 무엇이 고장 났는지 알아내는 대시보드가 고장 난 것에 의존할 때, 대시보드도 사고에 합류한 것입니다. 대역 외 상태 링크를 사용할 수 있도록 유지하세요. 일반적인 Graph 스로틀링의 경우 Microsoft의 지침은 요청이 너무 많은 요청 응답을 받을 때 재시도 지연을 따르고, 해당 헤더가 없을 때는 지수 백오프를 사용하라고 말합니다.

3:46 이 지침은 스로틀링을 관리합니다. 이 중단 사태를 진단하거나 재시도가 서비스를 복구한다고 약속하지는 않습니다. 이제 48시간에 대해 설명합니다. Microsoft의 확장된 상태 페이지는 큐 및 백로그 처리를 우선시하고 지연된 메시지를 보존하기 위해 이메일 시간 초과 창을 확장했다고 밝힙니다. 이는 복구 중에 지연된 메일에 더 많은 시간을 부여합니다. 메일 시간 초과 창을 설정합니다. Microsoft는 서비스 수리를 위한 48시간 기한을 주지 않았고,

### 48시간 메일 창은 무엇을 얻을 수 있습니까?

4:05 모든 메시지가 도착할 것이라는 보장도 없었습니다. 따라서 배달 주장을 정직하게 유지하세요. 지연된 알림이 반드시 사라진 것은 아니며, 큐에 있는 메시지가 반드시 수신자에게 도달한 것은 아닙니다. 시간에 민감한 작업의 경우, 승인된 독립적인 채널을 통해 결과를 확인하세요. 클라이언트 창은 백엔드가 여전히 복구 중일 때 낙관적인 배달 영수증입니다. 결과적으로 최종 사고 보고서에서 읽을 내용이 많이 남아 있습니다. 이 내용을 제가 말하는 것보다 읽고 싶다면, 매일 아침 사서함으로 The Daily Diff가 무료로 도착합니다. dailydiff.dev에서 확인하세요. 링크는 아래에 있습니다.

4:28 오늘의 평결은 NEEDS REVIEW입니다. Microsoft 자체 업데이트에 따르면 복구된 서버가 트래픽 폭주로 실패하는 것으로 나타났기 때문에 복구를 계속 검토해야 합니다. 유용한 테스트는 실제 작업이 들어오는 지속적인 서비스입니다. 최종 보고서가 나올 때까지 초기 원인은 미해결 상태로 남아 있습니다. 오늘의 The Daily Diff였습니다. 저는 Axrisi의 Niko입니다.

### 지속적인 복구는 무엇을 증명해야 합니까?

4:49 책임감 있게 병합하세요. Microsoft는 메일 서버를 서비스에 다시 투입했습니다. 트래픽이 돌아오면 다시 응답을 멈출 수 있었습니다. 여기 개발자 후속 보고서입니다. 이 비디오에서 복구가 계속 실패한 이유는 무엇입니까? 그리고 앱의 어떤 부분이 여전히 작동했습니까? Microsoft는 또한 지연된 이메일에 48시간을 부여했습니다.

## 출처

- [ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistorical](https://status.cloud.microsoft/) — Microsoft
- [Returned servers can become unresponsive again once they receive traffic](https://x.com/MSFT365Status/status/2121031935010951521) — Microsoft 365 Status
- [Health-processing component investigation hypothesis](https://x.com/MSFT365Status/status/2120974801388904932) — Microsoft 365 Status
- [Alternative health check returned a subset of servers](https://x.com/MSFT365Status/status/2120985048337830246) — Microsoft 365 Status
- [Isolate, restart and reintroduce traffic to test stability](https://x.com/MSFT365Status/status/2121002505911857577) — Microsoft 365 Status
- [Unavailable servers strain remaining infrastructure](https://x.com/MSFT365Status/status/2120962673911181437) — Microsoft 365 Status
- [Initial Exchange mailbox-access investigation in the Americas](https://x.com/MSFT365Status/status/2120938282204688468) — Microsoft 365 Status
- [Users in any region may be affected](https://x.com/MSFT365Status/status/2120941584220827979) — Microsoft 365 Status
- [Email timeout extended to preserve delayed messages](https://x.com/MSFT365Status/status/2121172248241348867) — Microsoft 365 Status
- [Paused deployments, traffic redistribution and server restarts](https://x.com/MSFT365Status/status/2120957934607700161) — Microsoft 365 Status
- [Independent live reporting on the Microsoft email disruption](https://www.cnn.com/2026/11/12/business/live-news/microsoft-global-outage-intl-hnk) — CNN
- [Microsoft Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) — Microsoft Learn
- [Exchange Online service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description) — Microsoft Learn
- [Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.](https://commons.wikimedia.org/wiki/File:Satya_Nadella.jpg) — OFFICIAL LEWEB PHOTOS
- [Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rights](https://creativecommons.org/licenses/by/2.0/) — Creative Commons
- [WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://imgflip.com/memetemplate/234202281/AJ-Styles--Undertaker) — WWE / Imgflip source hosting
- [The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://giphy.com/gifs/the-simpsons-sideshow-bob-RSOUOj8H9A3Xq) — The Simpsons / 20th Television / Disney; GIPHY source hosting