다음 AWS 중단이 이전보다 더 큰 비용을 초래하는 이유 (그리고 대처 방법)

Source: Dev.to

When AWS US‑EAST‑1 went dark on October 20 2025, over 3,500 companies across 60 countries went down with it.
Not because their code was broken. Because their architecture was.

무슨 일인가요?

DynamoDB의 DNS 관리 시스템에서 발생한 레이스 컨디션이 연쇄 반응을 일으켜 이를 의존하고 있던 모든 것이 다운되었습니다:

• 인증 서비스
• 라우팅 레이어
• 다른 AWS 리전에서 운영 중인 기업들조차도 그들의 “멀티‑리전” 설정이 US‑EAST‑1에 숨겨진 의존성을 가지고 있음을 발견했습니다.

만약 여러분이 사고 Slack 채널을 통해 그 과정을 지켜보았다면, 100 % 가동 시간은 신화라는 것을 이미 알고 있을 겁니다. 진짜 질문은 인프라가 실패할지가 아니라, 하이퍼스케일러가 문제를 해결하는 동안 여러분의 아키텍처가 트래픽을 계속 제공할 수 있는가 입니다.

스포일러: 대부분의 아키텍처는 그렇지 않습니다.

Source: …

아무도 이야기하고 싶어 하지 않는 수학

가용성은 간단한 비율이다:

Availability = MTBF / (MTBF + MTTR)

대부분의 엔지니어링 팀은 MTBF(우리는 어떻게 실패를 방지할 수 있을까?)에 집착한다. 그것은 잘못된 질문이다.

10월 장애는 15시간 지속되었다. AWS의 SLA는 대부분의 서비스에 대해 99.99 %를 보장하는데, 이는 연간 약 52분의 다운타임을 허용한다. 단일 사고로 15시간이 넘는 다운타임이 발생한 것이다.

대기업의 경우, 계획되지 않은 다운타임은 현재 시간당 평균 200만 달러의 비용이 든다 – 서버 자체가 비싸서가 아니라, 매출이 중단되고 고객 신뢰가 약화되며, DORA(2025년 완전 시행)와 같은 규제가 설계 단계에서 복원력을 입증하지 못하는 금융기관에 벌금을 부과하기 때문이다.

실제 적용되는 “nines”

네 개의 9에서 다섯 개의 9로의 도약을 보라. 이는 운영 규율이 25 % 향상된 것이 아니라 근본적으로 다른 아키텍처를 의미한다.

이미 복잡성 지평선을 넘어섰습니다

당신의 백엔드는 원인과 결과가 선형인 제트 엔진이 아닙니다. 그것은 생물학적 시스템입니다:

• DNS 지연이 수천 개의 마이크로서비스에 걸쳐 공격적인 재시도 루프를 촉발합니다.
• 이는 데이터베이스 연결 풀을 포화시킵니다.
• 로드 밸런서는 전체 지역을 다운 상태로 표시합니다.

작은 문제가 하나 발생하면, 갑자기 모든 것이 예측할 수 없는 방식으로 붕괴됩니다.

시스템 이론가들은 이를 복잡성 지평선이라고 부릅니다: 상호 의존성이 너무 촘촘해 연쇄 실패가 완화해야 할 위험이 아니라, 계획해야 할 수학적 확실성이 되는 지점.

10월 장애를 파괴적으로 만든 세 가지 패턴

이러한 모든 패턴은 동일한 근본 원인에서 비롯됩니다: 단일 공급자의 인프라 스택에 대한 깊은 의존.

대부분의 팀이 회피하는 실제 결정

각 주요 장애가 발생할 때마다 플레이북은 동일합니다:

• 더 나은 모니터링
• 더 엄격한 런북
• 더 많은 카오스 엔지니어링

그것들은 괜찮지만, 방금 실패한 동일한 아키텍처 내에서의 최적화일 뿐입니다.

실제 결정은 구조적인 것입니다:

단일 클라우드 기반에 복원력을 계속 추가해 나갈 것인가, 아니면 코드와 인프라 사이에 오케스트레이션 레이어를 둘 것인가?

이메일에서의 유사 사례

• Then: 모든 기업은 Exchange Server 엔지니어(최소 두 명)를 고용했습니다. 하나가 떨어지면 중복성이 필요했기 때문입니다. 이메일은 해결된 문제였지만 각 조직이 개별적으로 다시 해결하고 있었으며 비용이 막대했습니다.
• Now: Google과 Microsoft가 이메일을 서비스 형태로 제공했습니다. 메일함당 비용을 지불하고 다시는 생각하지 않았습니다. Exchange Server 엔지니어가 사라진 것은 아니며, 뛰어난 엔지니어들은 스택을 올려 실제로 비즈니스를 차별화하는 문제에 집중하게 되었습니다.

클라우드 인프라가 바로 오늘 그 전환점에 있습니다.

디지털 서비스를 제공하는 모든 기업은 플랫폼‑엔지니어링 팀을 고용해 동일한 백엔드 과제—시크릿 관리, 서비스 디스커버리, mutual TLS, 지오‑라우팅, 로깅, 메트릭, 트레이싱, 옵저버빌리티—를 연결하고 있습니다. 클라우드는 빌딩 블록(Kubernetes‑as‑a‑service, 객체 스토리지, 관리형 데이터베이스)을 제공하지만, 이러한 기본 요소와 프로덕션‑레디 소프트웨어 사이의 통합 작업은? 그것은 여러분에게 달려 있습니다—매번.

산업 전반에 걸친 이러한 중복 작업이 대부분의 조직이 네 자릿수 가용성(99.99%)을 넘지 못하는 이유입니다. 엔지니어링 예산을 동일한 파이프라인을 다시 구축하는 데 모두 쓰고, 실제로 수치를 바꿀 수 있는 아키텍처에 투자하지 않기 때문입니다.

실제로 수학을 바꾸는 것

5개의 9(연간 가동 중단 시간 5.26 분)를 달성하려면 단일 클라우드 공급자에 묶여 있을 때 거의 불가능한 세 가지가 필요합니다:

1. 즉시 교차‑클라우드 장애 조치 – AWS가 다운될 경우 워크로드가 몇 초 안에 GCP 또는 Azure에서 서비스를 제공해야 합니다. “DR 환경을 구축하겠다”는 것이 아니라 다른 공급자에서 실시간 트래픽을 놓치지 않고 제공하는 것입니다. 이는 15시간 장애를 고객에게는 사건이 아닌 수준으로 만들 수 있습니다.
2. 숨겨진 단일 실패 지점 제로 – 모든 핵심 제어 평면(DNS, IAM, 서비스‑메시 제어, 구성 저장소)은 공급자 간에 복제되어야 하며, 장애가 전파되기 전에 트래픽을 우회시킬 수 있는 상태 확인이 필요합니다.
3. 통합 가시성 및 오케스트레이션 – 클라우드 전반을 한 눈에 볼 수 있는 단일 화면으로, 자동 장애 조치를 트리거하고 워크로드가 어디에서 실행되든 동일한 메트릭과 로그를 제공해야 합니다.

기본 공급자를 추상화하는 오케스트레이션 레이어를 도입할 때만 5‑9 가용성을 위한 진정한 복원력을 달성할 수 있습니다.

TL;DR

• 싱글‑클라우드 아키텍처는 취약합니다 – 2025년 10월 AWS 장애가 이를 증명했습니다.
• 4개의 9(99.99%)는 대부분 팀에게 한계입니다. 여전히 하나의 공급자 스택에 묶여 있기 때문이죠.
• 5개의 9(99.999%)를 달성하려면 크로스‑클라우드, 제로‑SPOF, 오케스트레이션된 장애 조치가 필요합니다 – 근본적으로 다른 아키텍처 접근 방식이 요구됩니다.

아직도 싱글‑클라우드 기반에 복원력을 억지로 붙이고 있다면, 다음 15시간 장애를 대비하고 있는 겁니다. 지금 바로 오케스트레이션 레이어를 구축하고, 고객이 다음 장애를 전혀 느끼지 못하도록 하세요.

실패 지점. 아이덴티티 레이어, DNS, 라우팅. 이 모든 것이 현재 불타고 있는 공급자에 의존해서는 안 됩니다. 이는 단순히 멀티‑리전 배포가 아니라, 단일 제어 평면에 은밀히 연결되는 것이 아닌 진정한 추상화 레이어가 필요합니다.

재설계 없이 이식성. 공급자를 옮기는 데 몇 달의 엔지니어링 작업이 필요하다면, 복원력이 없는 것입니다. 압박 상황에서 실제로 실행되지 않을 매우 비싼 백업 플랜을 가지고 있는 셈이죠.

이것이 Control Plane이 해결하기 위해 만들어진 문제입니다.

플랫폼은 AWS, Azure, GCP, Oracle, 그리고 온‑프레미스 인프라 전반에 걸쳐 단일 오케스트레이션 레이어를 제공합니다. 코드는 한 번 배포하면 어디서든 실행됩니다. 공급자가 다운되면 트래픽이 자동으로 전환됩니다—수동 개입도, 런북도, 새벽 3시 페이지도 필요 없습니다.

우리는 이를 non‑stick layer라고 부릅니다. 워크로드가 어느 하나의 공급자에 고정되지 않으므로, 복원력, 비용 최적화, 혹은 락‑인 회피를 위한 이동 비용이 거의 제로에 가깝게 감소합니다.

Source: …

CFO가 실제로 관심을 가질 부분

탄력성만으로는 예산 논의가 어렵습니다. “뭔가 나쁜 일이 일어났을 때 손해를 줄이기 위해 더 많은 돈을 쓰라”는 설득이 쉽지 않죠. 이해합니다.

하지만 대부분의 팀이 놓치는 점은 다음과 같습니다. 99.999% 탄력성을 제공하는 아키텍처는 비용 구조 자체를 근본적으로 바꾼다는 점입니다.

• 유휴 컴퓨팅 비용을 절감합니다. 기존 클라우드 청구는 CPU 사용률이 100 %이든 3 %이든 전체 VM에 대해 요금을 부과합니다. Control Plane은 밀리코어(vCPU의 천분의 일) 단위로 청구합니다. 워크로드가 실제로 사용하는 컴퓨팅에만 비용을 지불하게 되며, 대부분 유휴 상태인 전체 머신에 대해 비용을 내지 않게 됩니다. 고객들은 클라우드 컴퓨팅 비용을 40‑60 % 절감하는 효과를 보고 있습니다. 이는 실제 금전적 절감입니다.

• 약정 없이 예약 인스턴스 가격을 얻습니다. 3년 계약을 맺어야만 합리적인 코어당 요금을 받을 수 있는 기존 방식과 달리, Control Plane은 대부분의 공급자가 예약 인스턴스에 대해 부과하는 가격보다 낮은 온‑디맨드 요금을 제공합니다. 약정이 없고, 사용량에 따라 청구됩니다. 수학적으로도 이득이 됩니다.

• 플랫폼 엔지니어링 팀을 축소하거나 재배치할 수 있습니다. 평균적인 플랫폼 엔지니어의 총 연봉은 $180‑220 K 정도입니다. 중간 규모 기업은 보통 4‑10명의 엔지니어를 고용해 Control Plane이 기본 제공하는 백엔드 인프라를 유지합니다. 이는 연간 $700 K‑$2.2 M에 달하는 인건비를, 이미 해결된 문제를 다시 해결하는 데 쓰는 비용이며, 엔지니어들이 실제로 만들 수 있었던 기회비용을 포함하면 더 큰 손실입니다.

합산해 보면: 낮아진 컴퓨팅 비용, 락인 프리미엄 없음, 그리고 이제는 인프라가 아니라 제품에 집중할 수 있는 플랫폼 엔지니어링 팀. 탄력성은 거의 보너스 수준입니다.

실제로 다음에 해야 할 일

10월 정전은 이상 현상이 아니었습니다. 미리 보는 것이었죠. AI 워크로드가 증가하고 백엔드 복잡성이 커짐에 따라 연쇄 장애는 더욱 악화될 것입니다. 다음 정전을 앞서 대비하는 방법은 다음과 같습니다.

1. 정전은 불가피하다는 것을 받아들이고 복구 속도를 설계하세요. 경쟁 우위는 실패를 방지하는 것이 아니라 Resilience Velocity—인간 개입 없이 아키텍처가 얼마나 빨리 복구되는가에 있습니다. 더 큰 운영 팀을 늘리기보다 자동화된 페일오버에 투자하세요.

2. 아키텍처 수준에서 단일 문화 위험을 제거하세요. 멀티‑리전은 멀티‑클라우드가 아닙니다. “중복성” 전략이 한 공급자의 생태계 안에만 존재한다면 지리적으로는 다양화되었지만 위험은 다양화되지 않은 것입니다. 진정한 복원력은 워크로드가 어떤 공급자에서도 실행될 수 있고 자동으로 전환될 수 있음을 의미합니다.

3. 이미 해결된 인프라를 다시 구축하지 마세요. 플랫폼 팀이 매달 비밀 관리, 서비스 메시, 관측 도구를 유지하는 데 쓰는 시간은 고객이 비용을 지불하는 제품에 투자하지 못하는 시간입니다. 온‑프레미스 Exchange에서 관리형 서비스로 이메일을 이전한 패턴이 백엔드 인프라에도 적용되고 있습니다. 이 전환을 조기에 수행하는 기업은 더 빠르게 출시하고, 비용을 절감하며, 더 편안히 잘 수 있습니다.

4. 숨겨진 의존성을 감사하세요. 10월 이후 수십 개 기업이 “멀티‑클라우드” 설정에 us‑east‑1에 대한 인증 또는 라우팅 의존성이 숨겨져 있음을 발견했습니다. 인프라가 의존하는 모든 서비스를 매핑하고 스스로에게 물어보세요: 이 서비스가 다운되면 우리도 다운되는가?

Complexity Horizon은 극복해야 할 대상이 아니라 설계해야 할 대상입니다.

10월을 무사히 넘긴 기업들은 가장 큰 운영 팀을 가진 기업이 아니라, 공급자 정전을 무시할 수 있을 만큼 견고한 아키텍처를 가진 기업이었습니다.

---

Control Plane은 주요 클라우드 공급자 전반에 걸쳐 프로덕션 수준의 백엔드 인프라를 제공하며, 자동 크로스‑클라우드 페일오버, 부분별 컴퓨트 청구, 그리고 내장된 비밀 관리, 서비스 메시, 관측 기능을 갖추고 있습니다.

See how it works →