2026년 3월 초, 이란의 드론이 중동에 위치한 3개의 AWS 시설을 공격했습니다. UAE의 2개 시설은 직격탄을 맞았습니다. 바레인의 1개 시설은 인근 폭발로 인한 피해를 입었습니다. 화재, 구조적 손상, 소화 활동으로 인한 수해, 전력 중단. 모든 것이 한꺼번에 일어났습니다.
AWS는 고객들에게 데이터를 백업하고, 다른 리전으로 워크로드 이전을 고려하며, 바레인과 UAE로의 트래픽을 우회하라고 권고했습니다. 지구상에서 가장 큰 클라우드 제공업체인 AWS가 명백한 언어로 "여기서 가동 시간을 보장할 수 없습니다"라고 말한 것입니다.
이것은 하이퍼스케일 클라우드 제공업체에 대한 최초의 확인된 군사 공격입니다. 마지막이 되지는 않을 것입니다.
클라우드에는 주소가 있다
스트리밍 업계는 10년간 "클라우드"가 그저 작동하는 추상적이고 무한히 복원력 있는 레이어인 것처럼 행세해 왔습니다. 하지만 그렇지 않습니다. 클라우드는 물리적인 서버 위에서, 물리적인 건물 안에서, 물리적인 전원 장치로 운영됩니다. 그리고 그 건물들에는 드론의 내비게이션 시스템에 입력할 수 있는 좌표가 있습니다.
뱅킹 앱, 결제 서비스, 배달 플랫폼, 엔터프라이즈 소프트웨어: 드론이 명중했을 때 걸프 지역 전체에서 이 모든 것이 다운되었습니다. me-central-1이나 me-south-1에서 오리진 서버나 패키징 파이프라인을 운영하던 스트리밍 서비스도 예외가 아니었습니다.
HLS 오리진이 단일 AWS 리전에 있다면, 스트림의 복원력은 해당 데이터센터의 콘크리트 벽과 정확히 같은 수준입니다. 이것은 더 이상 비유가 아닙니다.
스트리밍이 특히 취약한 이유
웹사이트가 30분간 다운되는 것은 고통스럽습니다. 라이브 스트림이 30초간 다운되는 것은 재앙입니다. 시청자는 떠나고, 이벤트의 나머지 부분에 돌아오지 않습니다. 광고 수익은 증발합니다. 계약상 위약금이 발동됩니다.
스트리밍에는 일반적인 클라우드 복원력 조언이 다루지 않는 고유한 취약점이 있습니다:
매니페스트 연속성. CDN이 스트리밍 중에 장애가 발생하면, 플레이어는 ABR 세션을 중단하지 않고 다른 곳에서 다음 세그먼트를 가져와야 합니다. 매니페스트가 멀티 CDN 전송을 위해 설계되지 않았다면, 페일오버는 모든 시청자에게 플레이어 전체 재시작을 의미합니다.
오리진 실드 의존성. 대부분의 아키텍처는 패키저와 CDN 엣지 사이에 단일 오리진 실드를 사용합니다. 해당 실드가 오프라인이 되는 리전에 있으면, 엣지 노드는 가져올 곳이 없어집니다. 캐시는 결국 만료되고 서비스는 중단됩니다.
DRM 라이선스 서버. Widevine과 PlayReady 라이선스 취득은 스트림 시작 시와 키 로테이션 간격에 발생합니다. 라이선스 서버가 하나의 리전에서 운영되고 해당 리전이 다운되면, 새로운 시청자는 재생을 시작할 수 없습니다. 기존 시청자는 다음 키 로테이션 시 연결이 끊깁니다.
광고 삽입 인프라. SSAI 결정 서버, 광고 추적 비콘, 컴패니언 광고 API: 이 모든 것에는 자체 인프라 의존성이 있습니다. 스트림 자체는 기술적으로 유지될 수 있지만, 광고 파이프라인이 붕괴되면 수익화된 스트림이 무료 콘텐츠로 변합니다.
대처 방법
좋은 소식: 이 모든 것은 해결 가능합니다. 나쁜 소식: 대부분의 스트리밍 운영자는 이 중 어느 것도 테스트해 본 적이 없습니다.
1. 실제 의존성 체인을 파악하라
무엇이든 수정하기 전에 문제를 파악해야 합니다. 대부분의 스트리밍 엔지니어는 자신의 아키텍처에 대한 대략적인 멘탈 모델을 가지고 있지만, 모든 오리진, 모든 CDN, 모든 DRM 엔드포인트, 모든 광고 서버, 모든 DNS 의존성을 실제로 매핑한 적은 없습니다.
스트림 URL을 적절한 분석 도구에 통과시키세요. 전체 매니페스트 트리를 확인하세요. 각 세그먼트가 실제로 어디서 제공되는지 확인하세요. 어떤 CDN이 주요 역할을 하는지 파악하세요. 이중화가 실제인지, 아니면 프레젠테이션 슬라이드의 항목에 불과한지 확인하세요.
지금 iReplay.TV Stream Analyser에서 스트림 복원력을 테스트하세요 →
분석 도구는 세그먼트를 제공하는 CDN, 매니페스트 뒤의 오리진 체인, 세그먼트 길이(페일오버 시간에 직접 영향), 스트림이 리전 장애를 견딜 수 있는지 여부를 보여줍니다. 5분간의 분석으로 라이브 이벤트 중 단일 장애점을 발견하는 사태를 방지할 수 있습니다.
2. 진정한 멀티 CDN을 구현하라(체크박스용 멀티 CDN이 아닌)
2개의 CDN 계약을 보유한 것은 멀티 CDN 전략이 아닙니다. 진정한 멀티 CDN 설정이란:
- 매니페스트에 여러 CDN 엔드포인트로 해석될 수 있는 세그먼트 URL이 포함되어 있을 것
- 플레이어 또는 매니페스트 조작 레이어가 재생을 중단하지 않고 세션 중 CDN을 전환할 수 있을 것
- 화이트보드가 아닌 실제 부하에서 페일오버를 테스트했을 것
- 모든 트래픽이 갑자기 생존한 CDN으로 전환될 때 오리진이 썬더링 허드를 처리할 수 있을 것
대부분의 스트리밍 운영자는 첫 번째 실제 장애 시, 자신들의 "멀티 CDN"이 실제로는 수동 DNS 전환과 30분 TTL을 가진 2개의 CDN에 불과하다는 것을 알게 됩니다. 그것은 복원력이 아닙니다. 그것은 희망적 관측입니다.
3. 오리진과 패키징을 분산시켜라
라이브 패키저가 단일 클라우드 리전에서 실행된다면, 그것은 단일 장애점입니다. 끝. 지리적으로 분리된 최소 2개 리전에서 이중화 패키징을 운영하세요. 운영 복잡성을 감수할 수 있다면 별도의 클라우드 제공업체를 사용하세요.
VOD의 경우, 자동 페일오버가 포함된 크로스 리전으로 오리진 스토리지가 복제되어 있는지 확인하세요. S3 크로스 리전 복제는 당연한 AWS의 답변이지만, 2026년 3월 이후 더 현명한 질문은: 백업 오리진이 AWS에 있어야 하는가?입니다.
4. DRM과 광고 인프라를 감사하라
DRM 라이선스 서버와 SSAI 결정 엔진은 대부분의 스트리밍 아키텍처에서 숨겨진 단일 장애점입니다. 종종 하나의 리전에서, 하나의 제공업체에 의해 호스팅되며, "한 번도 다운된 적 없다" 외에는 페일오버 계획이 없습니다.
드론이 그 건물에 명중할 때까지는.
Widevine/PlayReady 프록시가 어디서 실행되는지 확인하세요. SSAI 결정 서버가 어디에 있는지 확인하세요. 광고 비콘이 리전 장애를 견딜 수 있는지 확인하세요. 스트림 분석 도구가 이러한 의존성의 일부를 발견하는 데 도움이 될 수 있습니다.
5. 완전한 가동 시간이 아닌 성능 저하 모드를 설계하라
인프라 복원력은 스트림을 살려두는 것입니다. 하지만 현실 세계의 복원력은 스트림을 살려둘 수 없을 때의 계획을 갖는 것이기도 합니다. 최고의 뉴스와 스포츠 앱은 CDN이 다운되었을 때 단순히 화면이 꺼지지 않습니다. 우아하게 성능을 저하시킵니다.
숏폼 콘텐츠의 오프라인 재생. 짧은 뉴스 클립, 하이라이트, 사전 녹화된 뉴스 속보: 이들은 디바이스에 사전 다운로드하여 연결이 저하되거나 백엔드 인프라가 장애를 일으킬 때 로컬에서 제공할 수 있습니다. HLS는 Apple 플랫폼에서 기본적으로 오프라인 재생을 지원하며, 대부분의 최신 플레이어는 Android에서도 이를 처리합니다. 뉴스나 숏폼 콘텐츠를 전달하는 앱이라면 최신 클립 배치를 디바이스에 캐싱하지 않을 이유가 없습니다. 바레인의 데이터센터가 다운되어도 사용자에게는 볼 콘텐츠가 있습니다. 핵심은 정상 운영 중에 오프라인 캐시를 적극적으로 갱신하여 콘텐츠의 신선도를 유지하는 것입니다.
대안적 전달 채널로서의 푸시 알림. 스트리밍 인프라가 부분적으로 다운된 경우, 푸시 알림이 긴급 방송 시스템이 됩니다. 잘 설계된 알림 전략은 사용자를 작동 중인 미러로 리디렉션하거나, 텍스트 기반 뉴스 요약을 전달하거나, 단순히 장애를 인정하고 기대치를 설정할 수 있습니다. 푸시 인프라(APNs, FCM)는 Apple과 Google의 자체 시스템에서 운영되며, 스트리밍 백엔드와 완전히 독립적입니다. CDN이 장애를 일으켜도 알림 파이프라인이 작동한다면, 시청자가 조용히 경쟁사로 이탈하는 대신 정보를 제공하고 참여를 유지할 수 있습니다.
오디오 전용 폴백. 4 Mbps의 풀 비디오 스트림은 스트레스 상황에서 유지하기 위해 많은 인프라가 필요합니다. 64 kbps의 오디오 전용 스트림은 전송 비용이 약 60배 저렴하고 대역폭과 서버 용량의 극히 일부로 운영할 수 있습니다. 특히 뉴스 콘텐츠의 경우 오디오 전용은 완벽하게 허용 가능한 성능 저하 모드입니다. 많은 시청자가 이미 출퇴근이나 멀티태스킹 중에 뉴스 스트림을 듣고 있습니다. ABR 래더에 명시적인 오디오 전용 렌디션을 구축하면 비디오 전달이 손상되어도 서비스가 계속 작동합니다. 또한 패킷 손실에 더 강한 프로토콜이나 최후의 수단으로 일반 팟캐스트 인프라를 통한 전달의 문을 열어줍니다.
문제가 있습니다: 놀라울 정도로 많은 스트림이 여전히 레거시 MPEG-2 Transport Stream 패키징에서 운영되고 있으며, 오디오와 비디오가 다중화되어 있습니다. 오디오만 요청할 방법이 없습니다. 우아하게 성능을 저하시킬 방법도 없습니다. 플레이어는 전체 다중화 세그먼트를 다운로드하거나 아무것도 다운로드하지 않습니다. 독립형 오디오 렌디션 없이 MPEG-2 TS에서 아직 스트림이 운영되고 있다면, 사용 가능한 가장 저렴한 복원력 수단을 놓치고 있는 것입니다. fMP4/CMAF로 전환하고 마스터 플레이리스트에 별도의 오디오 전용 변형을 포함하는 것이 해결책입니다. iReplay.TV Stream Analyser는 스트림에 오디오 전용 렌디션이 있는지, 아니면 아직 TS 전용 영역에 머물러 있는지 몇 초 만에 알려줍니다.
이것들은 위안상이 아닙니다. "앱이 고장났다"와 "앱은 아직 작동한다, 다만 지금은 다른 방식으로"의 차이입니다. 사용자는 일시적인 성능 저하를 용서합니다. 침묵은 용서하지 않습니다.
새로운 현실
이란 분쟁은 스트리밍 업계가 아직 준비되지 않은 대화를 강제했습니다. 클라우드 인프라는 무적이 아닙니다. 지리적 다각화는 선택 사항이 아닙니다. 그리고 "우리에게는 일어나지 않을 것"은 복원력 전략이 아닙니다.
IRGC는 미국 기술 기업을 정당한 군사 목표로 명시적으로 지명했습니다. Google, Microsoft, Oracle 모두 같은 지역에서 데이터센터를 운영하고 있습니다. 다음 공격은 다른 제공업체, 다른 리전, 또는 해저 케이블 육양점을 타격할 수 있습니다. 걸프 지역으로의 광섬유 경로는 제한적이며, 취약성이 줄어들고 있지 않습니다.
스트림이 중동의 인프라에 의존하거나, 글로벌 아키텍처에 단일 클라우드 제공업체에 대한 숨겨진 의존성이 있다면, 지금이 확인할 때입니다. 다음 공격 때가 아닙니다.