Microsoft 365 1월 약 10시간 장애, 북미 인프라가 드러낸 SPOF의 교훈

올해 들어 M365가 자주 멈춘다는 느낌, 착각이 아니에요

최근 Microsoft 365가 자주 멈춘다고 느끼셨나요? 영국 IT 미디어 Cloudswitched는 2025년 10월부터 2026년 4월까지 주요 M365·Azure 장애가 다섯 차례 보도됐다고 정리했습니다. 그중 1차 출처로 구체적 수치까지 확인되는 사례는 두 건이에요. 2026년 1월 22~23일 약 10시간 장애와 2월 10일 북미 관리자센터 접속 불가죠.

이 글에서는 검증된 두 사건을 분 단위로 복원하고, 두 사건을 관통하는 한 가지 구조 단일 장애점(SPOF)을 짚어봅니다. 그리고 우리 회사 인프라에서 미리 점검할 수 있는 5지점 체크까지 이어가죠.

1월 22일, 이메일이 약 10시간 흐르지 않았다

센터피스 사례부터 볼게요. 영국 IT 전문지 The Register가 2026년 1월 23일에 공개한 보도에 따르면, Microsoft는 1월 22일 오후 7시 37분(UTC)에 장애를 공식 인지했습니다. 복구가 확인된 건 그 다음 날인 1월 23일 오전 6시 30분(UTC) 무렵이었죠. 지속 시간은 약 10시간이었어요.

영향을 받은 서비스는 Outlook, Defender, Purview였습니다. 특히 이메일 경로가 결정적이었어요. 내부 메일은 느리게라도 흘러갔지만, 외부로 나가는 메일은 불가능한 상태로 기록됐습니다. 장애가 진행되는 동안 고객 응대, 계약, 일정 조정처럼 이메일에 의존하는 업무 흐름이 영향을 받았다는 뜻이죠.

The Register가 전한 Microsoft의 설명은 한 줄이었어요. "북미 인프라 일부가 트래픽을 예상대로 처리하지 못하고 있다." 복구 방법도 한 줄로 정리됐습니다. 해당 인프라를 수습하고 트래픽을 재분배해 정상화. 짧지만 이 한 줄에 이번 글의 핵심이 들어 있어요.

2월 10일, 이번엔 북미 관리자센터가 막혔다

한 달도 지나지 않아 비슷한 패턴이 반복됐습니다. BleepingComputer와 Paubox가 각각 보도한 2026년 2월 10일 장애는 북미 지역의 Microsoft 365 Admin Center 접속을 차단했어요. BleepingComputer 보도에 따르면 관리자가 콘솔에 들어가지 못하거나, 들어가더라도 지원 티켓 발행과 M365 app 접근에 영향이 있었습니다.

BleepingComputer는 Microsoft가 2월 10일 오후 1시 56분(EST)에 "모니터링과 고객 보고를 통해 이슈 복구를 확인했다"고 공지한 시점을 기록했습니다. 1차 출처 두 곳 모두 총 지속 시간을 구체적으로 밝히지 않았어요.

이 사례에서도 지리적 스코프는 동일했죠. 북미. 1차 출처로 확인된 두 사건이 모두 북미 인프라 일부 문제에서 시작된다는 점이 눈에 띕니다.

검증된 두 사건이 공통으로 가리키는 한 가지

두 사건의 공통 구조를 정리하면 이렇습니다. 북미 인프라 일부의 문제가 해당 지역 서비스를 멈췄다는 점이에요. 글로벌 서비스라도 공용 진입점이나 라우팅 경로가 특정 지역에 집중돼 있으면, 그 지역의 부분 장애가 해당 지역 사용자 전체에 영향을 미칠 수 있죠.

참고로 Cloudswitched 보도에 따르면 이 외에도 2025년 10월 Azure Front Door DNS 장애, 2026년 1월 15일 M365 Copilot 서비스 장애, 2026년 4월에 9시간 이상 이어진 대규모 장애 같은 사례가 함께 언급됐습니다. 각 사건의 세부 수치는 Cloudswitched 단일 출처에 의존하므로, 본 글에서는 아래 표에 요약만 해두고 핵심 분석은 1차 출처로 교차 검증된 1월 22~23일·2월 10일 사건에 한정했어요.

북미 인프라 일부의 문제가 해당 지역 또는 의존 서비스의 접속을 좌우한다는 건 단일 장애점(Single Point of Failure), 줄여서 SPOF의 전형입니다. 지점 한 곳에 전기 차단기가 하나뿐이라면, 그 차단기가 내려가는 순간 모든 세대가 정전되는 것과 똑같아요.

Microsoft 같은 글로벌 공룡도 이런 구조를 100% 제거하지 못합니다. 비용, 일관성, 복잡도 때문이죠. 그런데 문제는 우리 회사 인프라에는 SPOF가 훨씬 더 많이 숨어 있다는 겁니다.

우리 인프라에 숨어 있는 SPOF 5지점

SPOF는 보통 하나의 경로에 모든 트래픽이 몰리는 지점에 생깁니다. 아키텍처를 뜯어보면 의외로 쉽게 발견할 수 있죠. 자주 놓치는 5지점을 짚어볼게요.

1. DNS, 가장 자주 놓치는 지점

웹 트래픽의 시작은 DNS 조회예요. 그런데 네임서버가 한 군데만 있거나, 도메인 등록기관 계정 하나로 모든 도메인을 관리하는 경우가 의외로 많습니다. DNS가 무너지면 서비스 자체는 멀쩡해도 아무도 접속할 수 없죠. 다중 네임서버(Secondary NS) 설정과 TTL 관리는 기본 중의 기본입니다.

2. CDN, 단일 벤더 의존

Cloudflare, Akamai, AWS CloudFront 한 곳에만 의존하면 해당 CDN 장애 시 그대로 전면 마비예요. 글로벌 CDN 장애는 간헐적으로 계속 보고되고 있으니 남의 일이 아니죠. 멀티 CDN 구성 또는 오리진 직접 연결(Origin Bypass) 백업 경로를 만들어 두면 한 쪽이 죽어도 서비스는 유지됩니다.

3. 오리진 서버, 단일 리전의 위험

서비스가 커질수록 단일 리전, 단일 AZ(Availability Zone)에 오리진을 몰아두는 건 위험해집니다. Microsoft의 1월 장애가 "북미 인프라 일부" 문제였던 걸 떠올려보세요. AWS, Azure, NHN Cloud 등 주요 CSP 모두 리전 단위 장애 사례가 있거든요. Multi-AZ는 최소, 트래픽 규모가 큰 서비스는 Multi-Region까지 고려해야 합니다.

4. 데이터베이스, Failover 준비 여부

Primary DB 한 대로 운영하면서 Failover 절차가 수동이거나 문서에만 있는 경우도 흔해요. 문제 발생 시 DBA가 손으로 승격시키는 동안 서비스는 계속 멈춰 있죠. Read Replica 자동 승격 파이프라인이나 Aurora, CloudSQL 같은 관리형 Failover를 써야 복구 시간이 분 단위로 줄어듭니다.

5. 인증 시스템, SSO 의존의 역설

SSO는 편리하지만 IdP(Identity Provider)가 죽으면 전사 서비스 로그인이 전부 막힙니다. Okta, Azure AD 같은 SaaS IdP도 장애로부터 자유롭지 않죠. 관리자용 비상 접근 경로(Break-Glass Account)를 별도로 만들어두고 정기적으로 테스트하는 게 중요해요.

이번 주 안에 돌릴 수 있는 3단계 체크

SPOF 제거는 하루 이틀에 끝나는 작업이 아닙니다. 그래도 우선순위는 명확하죠. 이번 주 안에 돌려볼 만한 3단계 체크를 정리했어요.

이 점검을 처음 돌려보면 여러 지점에서 SPOF가 함께 발견되는 경우가 흔해요. DNS가 한 군데, DB Primary가 단일, SSO가 외부 SaaS 하나에 의존하는 식이죠. 장애가 터지고 나서 알게 되면 이미 늦어요. 관련 인프라 진단을 외부 전문가와 함께 진행하고 싶다면 스피디 MSP의 무료 인프라 진단을 이용해보세요.

이것만 기억하세요

자주 묻는 질문 (FAQ)