오늘 회사 아웃룩 먹통이었다면? MS 365 장애 원인·메일 복구 상황

 

MS 365 장애 한국시간 타임라인과 지연 메일 확인법

마이크로소프트 365(MS 365) 장애는 한국시간 13일(금) 새벽 1시 17분에 시작됐고, 출근 시간대에도 이어졌어요. 결론부터 말하면, 그 사이 보낸 메일은 사라졌다기보다 늦게 가고 있는 경우가 많았어요. MS가 지연된 메일을 보호하려고 처리 제한시간을 48시간으로 늘렸거든요.

 

다만 '언젠가는 온다'가 '반드시 도착한다'는 뜻은 아니에요.

중요한 메일은 도착 여부를 따로 확인해야 하고, 확인하기 전에 같은 메일을 다시 보내는 것도 피하는 편이 좋아요.

 

이런 상황에서는 '메일이 날아간 것 아니냐'는 불안과 '어차피 늦게라도 온다'는 낙관이 함께 나오기 마련이에요. 지금까지 확인된 내용으로는 둘 다 절반만 맞아요. 지연이 대부분이라는 점에서 낙관이 맞고, 제한시간 안에 전달되지 못한 메일은 전송 실패 안내가 올 수 있다는 점에서 불안도 근거가 있어요.

📋 목차

① 출근 시간에 하필 다시 멈춘 이유
② 확인된 것, 잠정인 것, 아닌 것
③ 하루 장애를 숫자로 바꾸면
④ 원인 설명이 계속 바뀐 까닭
⑤ 내 메일, 지금 해야 할 일
⑥ 자주 묻는 질문

① 출근 시간에 하필 다시 멈춘 이유

MS 공식 기록상 아웃룩(Exchange Online) 장애는 미국 시간 12일 오전, 한국시간으로 13일 새벽 1시 17분에 시작됐어요. 새벽에 일부 서버를 되살렸지만, 한국에서 업무가 시작되는 오전 9시 무렵 이 서버들이 실제 이용자 트래픽을 받자 다시 응답하지 않았어요.

 

한국 직장인에게는 출근 시간과 정면으로 겹친 셈이에요.

시각(한국시간)	일어난 일
13일 01:17	아웃룩 메일함 접속 장애 시작 (MS 인시던트 EX1550543)
13일 03:26	팀즈·코파일럿 등 메일에 기대는 서비스용 별도 공지 (MO1550821)
13일 04:06경	MS, 모든 배포와 설정 변경 중단
13일 06:00경	다른 방식의 상태 점검으로 일부 서버 복귀
13일 09:00경	복귀한 서버가 트래픽을 받자 다시 응답 불능 (출근 시간대)
13일 오후	서버 재시작·용량 추가로 일부 지역 부분 복구, 지속은 불안정
13일 저녁	초기 안정화 신호, 지연 메일 처리 제한시간 48시간으로 연장
14일 01:30대	메일 대기열이 정상 수준에 근접, MS는 "광범위한 복구와 안정" 발표

※ UTC 기록을 한국시간(+9시간)으로 환산했어요. '경'이 붙은 시각은 보도마다 수십 분 차이가 있을 수 있어요.

그럼 이 긴 장애에서 확실히 확인된 것과 아직 정해지지 않은 것은 무엇일까요?

② 확인된 것, 잠정인 것, 아닌 것

가장 먼저 궁금한 건 해킹이었는지일 텐데요, MS는 악의적인 활동이나 사이버 공격의 징후는 없다고 반복해서 밝혔어요. 다만 이번 장애는 메일만이 아니라 링크 안전 검사(세이프 링크), 데이터 유출 방지(DLP), 디펜더 같은 보안 기능에도 영향을 줄 수 있는 범위였어요. 공격이 아니어도 메일 보안 체계는 서버 장애 한 번에 흔들릴 수 있다는 점은 기억해 둘 만해요.

영향은 메일을 따라 번졌어요. 팀즈의 채팅과 회의 참여는 대체로 정상이었지만, 일정 조회나 회의 예약처럼 메일 서버에 기대는 기능에서 오류가 났어요. 어떤 서비스에서 어떤 증상이 나왔는지는 아래처럼 정리됩니다.

 

서비스	나타난 증상
아웃룩	메일함이 열리지 않음, 송수신 지연 (웹·데스크톱·모바일 모두)
팀즈	일정 조회·회의 예약·초대 오류 (채팅과 회의 참여는 대체로 정상)
코파일럿	업무 데이터에 접근하지 못하거나 응답 오류
셰어포인트	메일과 연동된 기능에 영향 (저장된 파일은 직접 열 수 있음)
플래너·투두	할 일·업무 관리 기능 일부 오류
보안·관리 도구	링크 검증 실패 가능, 일부 포털·관리자 센터 페이지 영향

챗GPT와 클로드처럼 MS 365와 연결해 쓰는 AI 서비스의 연동 기능도 일부 영향을 받았다고 각 회사가 알렸어요. AI 서비스 자체가 멈춘 게 아니라, MS 쪽 메일·문서를 불러오는 통로가 막힌 거예요.

✅ 확인됨 · 지연 메일 보호 조치

MS가 지연된 메일을 보호하려고 처리 제한시간을 48시간으로 늘렸어요. 메일이 유실됐다는 보고는 아직 확인되지 않았고, 발송 서버가 재시도하면서 복구에 따라 도착할 수 있어요.

✅ 확인됨 · 사이버 공격 징후 없음

MS는 "악의적이거나 사이버 활동의 결과라는 징후는 없다"고 밝혔어요.

⚠️ 잠정 · 원인

외신에 따르면 MS는 이전 네트워크 용량 업그레이드 과정에서 시작된 문제가 최근 네트워크 변경 이후 드러났다고 설명했어요. 최종 근본 원인은 사후 보고서가 나온 뒤에야 확정돼요.

❌ 사실이 아님 · "팀즈가 통째로 멈췄다"

팀즈의 핵심 메시지와 회의 참여는 대체로 작동했어요. 막힌 건 메일 서버와 연동된 일정·예약 쪽이에요.

그렇다면 규모는 어느 정도였을까요? 숫자로 바꿔 보면 감이 오는 대목이 있어요.

③ 하루 장애를 숫자로 바꾸면

장애 추적 사이트 다운디텍터에는 12일 미국 동부시간 오후 1시 무렵 미국 내 아웃룩 신고가 13만 건을 넘었어요. 블룸버그는 MS 서비스 전체 신고를 약 20만 건으로 전했고, AFP는 장애 시작 약 1시간 만에 74개 국가·지역에서 신고가 들어왔다고 했어요. 다만 이 숫자는 이용자가 직접 신고한 건수라서 실제 피해 계정 수와는 달라요.

MS가 약속한 월 가동률 99.9%가 허용하는 중단 시간

한 달 약 43분

이번 인시던트 기록 기간 (13일 01:17 ~ 14일 01:57)

약 24시간 40분, 허용치의 약 34배

인시던트 전체 기간을 그대로 환산한 값이에요. 개별 조직이 실제로 겪은 중단 시간은 다릅니다.

한국에서는 일부 기업이 임직원에게 긴급 공지를 보내 서비스별 영향 범위를 점검했어요. 오후에 아웃룩을 되찾은 곳도 있었고, 별도 사내 메신저를 쓰는 곳은 영향이 제한적이었다고 해요. 해외에서는 미국 연방 하원 이용자와 일본 정부 공용 IT 플랫폼 등이 영향을 받았다고 보도됐고, 한 미국 기업은 실적 발표를 12일에서 16일로 미루기도 했어요.

서버를 껐다 켜면 될 것 같은데, 왜 이렇게 오래 걸렸을까요? MS의 설명을 순서대로 보면 이유가 보여요.

④ 원인 설명이 계속 바뀐 까닭

처음에는 일부 인프라에 높은 부하가 걸렸다는 설명이었어요. 사용자가 몰려서 생긴 일처럼 들렸죠. 그런데 조사가 진행되면서 설명이 단계별로 바뀌었어요.

1단계 · 트래픽 폭증이 아니었어요

서버 여러 대가 예기치 않게 사용 불능이 되면서, 남아 있던 서버에 부하가 한꺼번에 쏠렸어요.

2단계 · 되살려도 다시 쓰러졌어요

다른 방식의 상태 점검으로 서버를 복귀시켰지만, 실제 이용자 요청이 들어오자 응답하지 않는 일이 반복됐어요. 재시작만으로는 풀리지 않았던 이유예요.

3단계 · 보안 연결 처리 과정이 과부하였어요

보안 연결을 맺는 핵심 프로세스가 과부하 상태였다는 설명이 나왔고, 장애 시작 시점과 맞는 네트워크 구성 변경을 되돌리기 시작했어요.

4단계 · 용량을 늘리며 조심스럽게 트래픽 복귀

되돌리기가 기대대로 먹히지 않아 가상머신 용량을 추가하고, 업무 시간에 들어가는 지역부터 순차적으로 트래픽을 돌려줬어요.

쉽게 말하면, 쓰러진 서버를 일으켜 세워도 한꺼번에 사람이 몰리면 다시 쓰러지는 구조였어요. 그래서 트래픽을 조금씩 돌려주며 용량을 먼저 확보해야 했고, 지역마다 복구 시점이 달랐던 것도 이 때문이에요. 이제 중요한 건 내 메일과 내 업무예요.

⑤ 내 메일, 지금 해야 할 일

 

서비스가 다시 열려도 장애 시간대에 오간 업무는 따로 챙겨야 해요. 상황별로 정리했어요.

🧭 내 상황별 해야 할 일

장애 시간에 중요한 메일을 보냈다

→ 보낸편지함과 전송 실패(반송) 안내를 확인하세요. 보낸편지함에 있다는 것만으로 상대에게 도착했다고 볼 수는 없어요.

같은 메일을 다시 보내고 싶다

→ 잠깐 참으세요. 재발송은 서버 부하를 늘리고, 지연 메일이 뒤늦게 도착하면 중복돼 혼선만 생겨요.

계약서·견적서·결재처럼 시간에 민감하다

→ 전화나 회사가 허용한 메신저로 수신 여부를 한 번 더 확인하세요.

인증번호를 회사 메일로 받는 서비스가 있다

→ 문자·인증 앱 같은 대체 수단이 있는지 확인하고, 늦게 온 번호는 만료됐을 수 있으니 새로 요청하세요.

아웃룩이 계속 열리지 않는다

→ 삭제·재설치는 소용없어요. 같은 회사 동료도 같은 증상인지, 사내 공지가 있는지부터 보세요.

"장애 때문에 확인이 필요하다"는 메일·전화가 왔다

→ 링크를 누르지 말고 회사 IT 담당자나 공식 경로로 확인하세요. 장애를 빌미로 한 피싱을 조심하라는 안내가 관리자 쪽에서 나오고 있어요.

관리자라면: 서비스 수준 협약(SLA) 크레딧 청구

MS는 Exchange Online, 팀즈, 셰어포인트에 월 99.9% 가동률을 약속하고 있어요. 월 가동률이 99.9% 미만이면 25%, 99% 미만이면 50%, 95% 미만이면 100%를 청구서에서 깎아 줘요. 인시던트 전체 기간 24시간 40분을 한 달 720시간에 그대로 대입하면 가동률은 약 96.6%로, 99%와 95% 사이 구간이에요. 실제 구간은 우리 조직 사용자가 겪은 중단 시간으로 계산돼요.

청구 방법 한눈에

① Microsoft 365 관리자 센터에서 서비스 요청 열기
② 인시던트 ID 기재: EX1550543, MO1550821 (팀즈 영향 시 TM1550488 추가)
③ 우리 사용자의 장애 시작·종료 시각, 영향 인원, 취한 조치 적기
④ 청구 기한: 2026년 12월 31일
⑤ 보상 형태: 환불이 아니라 향후 청구서 크레딧
⑥ CSP(파트너 경유) 고객은 MS가 아니라 파트너를 통해 청구

이번 일은 메일 하나가 멈추면 일정, 회의, AI 비서, 로그인 인증까지 같이 흔들린다는 걸 보여 줬어요. 개인은 중요한 상대의 연락처를 메일 말고 전화·문자로도 갖고 있어야 하고, 회사는 클라우드 서비스가 중단될 때 쓸 대체 연락망과 업무 연속성 계획(BCP)을 점검할 때예요. 마지막으로 독자분들이 가장 많이 물을 만한 질문을 모았어요.

⑥ 자주 묻는 질문

Q. 장애 중에 요청한 인증번호가 한참 뒤에 도착했어요. 써도 되나요?

A. 인증번호는 유효시간이 짧은 경우가 많아서 늦게 도착한 번호는 이미 만료됐을 가능성이 커요. 새로 요청하거나, 메일을 거치지 않는 문자·인증 앱 방식으로 로그인하는 편이 빨라요.

Q. 팀즈 회의 초대가 안 보여요. 회의 자체가 안 열리나요?

A. 회의 참여는 대체로 작동했고, 일정 조회와 예약·초대가 메일 서버 영향을 받았어요. 일정이 안 보이면 주최자에게 회의 링크를 직접 받아 들어가는 게 가장 빠르고 확실해요.

Q. 웹 버전 아웃룩으로 바꾸면 되지 않나요?

A. 이번에는 웹, 데스크톱, 모바일 연결 방식이 모두 영향을 받아서 웹으로 바꿔도 해결되지 않는 경우가 많았어요. 서버 쪽 복구를 기다리는 수밖에 없는 장애였어요.

---

핵심 정리: 장애 중 보낸 메일은 유실보다 지연이 많았고, MS는 처리 제한시간을 48시간으로 늘렸어요. 그래도 도착을 보장하는 건 아니니 중요한 메일은 직접 확인하고, 확인 전 재발송은 미루세요.

오늘 해야 할 3가지

① 보낸편지함·반송 안내 확인 ② 중요한 건은 전화로 수신 확인 ③ MS 상태 페이지에서 복구 상황 확인. 회사 관리자는 관리자 센터의 서비스 상태에서도 볼 수 있어요.

MS 365 서비스 상태 보기 →

※ 2026년 11월 14일 새벽 기준으로 마이크로소프트 공식 장애 공지(EX1550543, MO1550821, TM1550488)와 국내외 보도를 정리했어요. 최종 근본 원인과 완전 복구 시점은 MS의 후속 발표에 따라 달라질 수 있어요.

추천 콘텐츠

참고 자료

마이크로소프트 365 서비스 상태 공지(EX1550543, MO1550821, TM1550488) · 한국일보 2026.11.13 「MS 접속 장애 전 세계 확산」 · 뉴스웨이 2026.11.13 「아웃룩도 코파일럿도 먹통」 · 보안뉴스 「마이크로소프트 365 장애로 아웃룩·팀즈 세계 곳곳서 먹통」 · AP 2026.11.13 보도 · TechRadar 2026.11.13 라이브 보도 · Windows Forum, LazyAdmin(SLA 청구 안내) 정리 글