22026년 11월 13일, IT지구방위대의 삐끗으로 아마 MS기반의 그룹웨어를 사용하는 회사는 대부분의 직원들이 강제 월루를 경험했을꺼예요. 저도 마찬가지로.... 저희 회사는 메일은 아웃룩(Outlook), 회의와 대화는 팀즈(Teams), 파일은 원드라이브(OneDrive)와 셰어포인트(SharePoint)에 두고 일합니다. 그날 이 도구들에 걸쳐 차질이 생기면서 평소 하던 업무가 줄줄이 막혔습니다.메일로 요청을 받고, 팀즈에서 내용을 맞추고, 공유 문서를 고친 뒤 다시 링크를 보내는 일은 평소라면 별생각 없이 이어집니다. 그 연결이 한꺼번에 끊기니 출근은 했는데 하던 일을 끝까지 넘기기가 어려웠습니다.
한국시간 11월 13일 새벽부터 이어진 Microsoft의 복구 작업
장애는 아웃룩이 연결되는 회사 메일 서비스 Exchange Online에서 먼저 확인됐습니다. 웹·데스크톱·모바일 등 여러 접속 경로에서 메일함 접근이 어려웠고, 메일 배달도 지연됐습니다. 팀즈에서는 Exchange Online을 사용하는 일정 조회와 회의 예약·초대에 차질이 생겼고, 셰어포인트에서는 일부 외부 파일 공유 기능이 영향을 받았습니다. 팀즈의 채팅과 기존 회의 참가 등은 대체로 이용할 수 있다고 Microsoft는 안내했습니다. 펜실베이니아대 IT 서비스 — Microsoft 장애 공지 EX1550543·MO1550821
| 한국시간(KST) | 장애 경과와 Microsoft의 조치 |
|---|---|
| 11월 13일 01:17 | 미주 지역에서 먼저 조사된 Exchange Online 메일함 접속 문제. Microsoft가 기록한 시작 시각이며, 해외 기사에서 말하는 11월 12일 16:17 UTC와 같습니다. |
| 03:26 무렵 | Microsoft가 여러 Microsoft 365 서비스의 접속 문제를 별도 장애로 기록했습니다. 메일 장애는 EX1550543, 여러 서비스에 걸친 장애는 MO1550821로 추적했습니다. |
| 04~07시 | Microsoft는 트래픽을 다른 인프라로 돌리고 장애 서버를 재시작했습니다. 배포와 설정 변경을 일시 중단했고, 서버의 핵심 프로세스가 부하를 감당하지 못해 응답을 멈추는 현상을 확인했습니다. 초기 조치로는 기대만큼 복구되지 않았습니다. |
| 16:24 | 일부 인프라의 인증·라우팅 구성 요소에 패치를 적용한 뒤 서버가 더 안정적으로 동작한다고 알렸습니다. Microsoft는 이 조치를 다른 서버로 확대했습니다. |
| 23:01 | Microsoft는 발송 대기 중인 메일이 정상 수준에 가까워졌다고 보고했습니다. 지연된 메일을 보존하기 위해 메일 전송 대기 만료 시간을 48시간으로 늘린 상태였습니다. |
| 11월 14일 00:53 무렵 | Microsoft는 남은 접속 문제를 줄이고 접속 방식별로 안정성이 유지되는지 확인하고 있다고 공지했습니다. |
초기 복구가 더뎠던 이유는 재시작한 서버가 다시 트래픽을 받는 순간 응답을 멈출 수 있었기 때문입니다. Microsoft는 일부 인프라를 떼어내 구성 요소를 재시작한 뒤, 트래픽을 조금씩 돌려보내 서버가 계속 응답하는지 확인했습니다. 서버를 켜는 작업과 실제 요청을 감당할 수 있는지 확인하는 작업이 따로 필요했던 셈입니다. 펜실베이니아대 IT 서비스 — Microsoft 장애 공지 EX1550543·MO1550821
메일 전송 대기 만료 시간을 48시간으로 늘린 조치는 복구까지 기다리는 메일을 더 오래 보존하기 위한 것이었습니다. 메일함을 다시 열 수 있게 되더라도 대기열에 남은 메일이 처리되기까지 시간이 걸릴 수 있습니다. 거래처 회신처럼 도착 여부가 중요한 메일은 화면이 열리는 시점과 상대가 실제로 받는 시점 사이에 차이가 생길 수 있습니다. 펜실베이니아대 IT 서비스 — Microsoft 장애 공지 EX1550543·MO1550821
Microsoft는 당시 악의적 활동의 증거를 발견하지 못했다고 밝혔고, 최종 원인과 재발 방지 조치는 복구가 끝난 뒤 사후 보고서에 담겠다고 안내했습니다. 펜실베이니아대 IT 서비스 — Microsoft 장애 공지 EX1550543·MO1550821
11월 14일 새벽 기준 복구 경과
11월 14일 새벽 2시 30분(KST) 기준으로 확인한 보도와 공지에서는 북미·유럽·아시아태평양의 일부 서비스가 개선됐습니다. 다만 기업용 Microsoft 365 공지에는 남은 접속 문제가 있었고, 가디언이 전한 소비자용 공지에서도 Outlook.com과 OneDrive 등 영향 서비스의 안정성을 확인하는 중이었습니다. 공개 자료에서 전체 복구 완료 시각과 최종 원인은 아직 확인되지 않았습니다. 펜실베이니아대 IT 서비스 — Microsoft 장애 공지 EX1550543·MO1550821 AP — 세계 각국의 Microsoft 365 장애 영향과 반응 가디언 — 11월 13일 장애·복구 실시간 보도
복구 소식을 볼 때는 서비스의 이름 옆에 어떤 동작이 개선됐는지 함께 읽어야 합니다. 예를 들어 아웃룩 웹에서 받은 편지함이 열리기 시작했다는 소식만으로는 늦게 도착한 메일이 모두 들어왔는지 알기 어렵습니다. 팀즈도 회의에 다시 참가할 수 있는지와 새로 보낸 초대가 상대 일정에 반영되는지는 각각 확인해야 할 항목입니다.
팀즈가 열려도 문서 검토가 밀리는 이유
팀즈 채널에 올린 파일은 팀의 셰어포인트에, 개인·그룹 채팅에 직접 올린 파일은 올린 사람의 회사 원드라이브에 저장됩니다. 채팅창이 열려도 그 안의 파일 링크나 공유 기능에서 막힐 수 있습니다. 같은 파일을 셰어포인트 문서함에서 직접 열 수 있는 경우도 있으므로, 장애를 확인할 때는 파일 열기와 링크 공유를 각각 시험해 볼 만합니다. 펜실베이니아대 IT 서비스 — Microsoft 장애 공지 EX1550543·MO1550821 Microsoft 지원 — Teams 채널과 채팅의 파일 저장 위치3
예를 들어 거래처에 수정안을 보내려면 최신 문서를 열고, 담당자에게 검토를 받고, 회신까지 전달해야 합니다. 채팅으로 검토를 부탁할 수 있어도 최신 파일이 열리지 않으면 그 자리에서 멈춥니다. 파일을 열고 편집할 수 있어도 거래처가 링크를 못 열거나 회신이 늦게 도착하면 업무는 여전히 미완료입니다.
문서 검토에서는 어느 버전까지 확인했는지도 중요합니다. 예를 들어 채팅은 열리지만 공유 파일에 접근하지 못하면, 이미 열어 둔 사본을 보며 검토 의견을 적을 수는 있습니다. 다만 그 사이 다른 사람이 공유본을 고쳤다면 사본에 남긴 의견의 전제가 달라질 수 있습니다. 접속이 돌아온 뒤 최신 공유본과 대조하면 어느 의견을 반영할지 판단하기 쉬워집니다.
다음 장애 때도 돌아가야 할 업무
관리자는 여러 직원에게 비슷한 문제가 생기면 Microsoft 365 관리 센터에서 ‘상태 → 서비스 상태’를 열어 회사 환경에 해당하는 장애와 영향을 받는 기능을 확인할 수 있습니다. 관리 센터 로그인까지 막히면 Microsoft 공개 상태 페이지에서 알려진 문제를 확인할 수 있습니다. 사내 공지에는 장애 번호와 함께 “기존 회의 참가 가능”, “새 회의 초대 실패”처럼 직접 확인한 기능을 적으면 직원들이 다음 행동을 정하기 쉽습니다. Microsoft Learn — Microsoft 365 서비스 상태 확인 방법
업무 쪽에서는 당일 기한이 걸린 일부터 정리할 수 있습니다. 가령 거래처에 회신할 시간이 임박했다면 회사가 승인한 별도 연락 경로로 지연 사실과 다음 안내 시간을 먼저 전달합니다. 이때 문서나 개인정보까지 개인 메일로 보내면 회사의 보안 규정을 벗어날 수 있으므로, 대체 연락에는 필요한 안내만 담습니다.
대체 연락 경로를 정할 때는 연락처를 어디에서 꺼낼 수 있는지도 확인할 필요가 있습니다. 거래처 대표번호가 장애가 난 메일함의 서명에만 있거나 담당자 명단을 팀즈 채널에서만 볼 수 있다면, 전화로 안내하자는 계획도 시작부터 막힙니다. 회사가 허용한 장소에서 담당자와 대체 담당자가 모두 연락처를 찾을 수 있는지 평소에 확인해 둘 수 있습니다.
복구 뒤에는 밀린 일을 확인합니다. 장애 중 보낸 메일이 실제로 도착했는지, 변경한 회의 초대가 참석자 일정에 반영됐는지, 문서를 수정했다면 공유본에 최신 내용이 남아 있는지 봅니다. 기한이 지난 건부터 확인하면 같은 메일을 두 번 보내거나 이전 버전을 다시 전달할 가능성을 줄일 수 있습니다.
복구 직후 회신을 다시 보내기 전에는 기존 메일이 발송함에 남아 있는지, 배달 실패 통지가 들어왔는지, 상대방의 회신이 이미 도착했는지 순서대로 볼 수 있습니다. 발송함 기록은 보내기를 시도한 흔적이므로 기한이 중요한 건은 상대방에게 수신 여부도 확인합니다. 공유 문서는 장애 중 작성한 사본이 있다면 최신 공유본과 대조한 뒤 필요한 변경만 반영합니다.
결론
저희 회사의 ‘강제 월급루팡’은 메일, 회의, 문서가 하나의 업무로 이어져 있다는 걸 보여줬습니다. 다음번에 대비해 팀마다 당일 처리해야 하는 업무 한 가지를 골라, 메일과 팀즈를 동시에 못 쓸 때 누가 어떤 경로로 알리고 복구 뒤에는 무엇을 확인할지 정해둘 수 있습니다. 거래처 회신 한 건만 놓고 시험해도 업무가 어디서 끊기는지 드러납니다.