AWS가 멈췄다고요? 멀티클라우드가 답은 아니다
지난 며칠, 많은 사람이 "안전"이라는 환상을 잃었다.
10월 20일(현지 시각) AWS US-EAST-1 지역에서 대형 장애가 터졌다. 수많은 앱과 서비스가 줄줄이 멈췄다. 원인은 DNS 해석 실패와 특정 내부 서브시스템/데이터 계층(EC2·DynamoDB API 경로 등)에서 시작된 오류로 분석됐다. 소셜, 게임, 생산성, 심지어 일부 정부·교육 서비스까지 덩달아 흔들렸다. 하루가 다 갈 때쯤 복구됐지만, 여파는 오래갔다.
그다음 날, 내 회사에서 사용하는 Azure의 모 서비스 속도가 느려지면서 다양한 경고들이 우리 사무실을 혼란스럽게 했다. (참고: 우리는 서버 장애가 있을 때마다 디스코볼이 돌면서 댄스파티가 일어난다. 빨강 파랑 댄스댄스~) 생각해 보니 이달 초(10월 9일) Azure Front Door에서도 광역 이슈가 있었고, 관리 포털까지 영향이 번졌었다. 마이크로소프트도 트래픽 우회와 캐시 퍼지로 복구했다고 상태 이력에 남겼다. "한 곳만의 문제"로 치부하기 어려운 대목이다.
그리고 오늘 뉴스·칼럼·블로그들에는 어김없이 "멀티클라우드면 더 안전하다"는 해법이 쏟아졌다. 그럴듯하게 들리지만, 벤더 레벨의 공통 제어면(CP) 문제나 업스트림 네임서버·아이덴티티·글로벌 라우팅 이슈에는 다중 벤더 자체가 만병통치약이 아니다. (월가도 멀티클라우드를 ‘해법’으로 들지만, 같은 날 AWS 전반이 흔들린 사실은 바뀌지 않는다.)
내 요지는 간단하다. "클라우드라서 더 안전하다"는 건 오해다. 아래 이유로 다시 정리한다. (유튜브 라이브 때 수도 없이 말해 왔음)
1) SLA를 곱하면 현실이 보인다
웹 서버 1대와 DB 1대를 단순 조합한다고 가정하자. (이게 최소한의 아키텍처겠지?)
- SLA 99.9% × 99.9% = 99.8001%
→ 연간 약 17.5시간 다운 (0.1999% × 8760h) - SLA 99.9% × 99.9% × 99.9% = 99.7003%
→ 연간 약 26.3시간 다운
"서버리스니까 괜찮다"는 말? 서버리스 안에도 서버가 있다. 이름만 '리스'일 뿐, 결국 물리·가상 자원과 제어면의 신뢰도, 배포·롤아웃 방식에 종속된다. 닭 안 들어간 치킨이 아닌 이상, 장애 확률의 곱셈에서 자유롭지 않다.
2) 진짜 위험은 하드웨어가 아니라 소프트웨어 변경이다
클라우드 사업자가 내세우는 고가용성 스토리는 대체로 "AZ 하나가 날아가도 버틴다" 같은 하드웨어·시설 이야기다.
문제는 대부분의 대형 장애가 소프트웨어/제어면 변경에서 시작된다는 점이다. 릴리스가 잘못되면, 멀쩡한 하드웨어가 동시에 잘못된 설정을 받아들인다. 그러면 여러 리전/서비스가 한 번에 무너진다. 이번 AWS 사건도 "데이터 경로 + 네임 해석" 같은 공통 의존성에서 시작해 도미노가 됐다.
3) "벤더가 내 타임라인에 맞춰 배포해 주지 않는다"
클라우드의 본질적 리스크는 변경권(change control)의 상실이다.
벤더는 자기 일정에 맞춰 롤링 업데이트를 밀어붙이고, 당신은 릴리스 품질을 검증할 권한이 거의 없다. 내가 복잡한 서비스를 돌리고 있지 않았는데 클라우드 업데이트 때문에 깨졌다? 그건 "기본 기능" 수준에서 깨졌다는 이야기고 (벤더에서 테스트를 충분히 안 했다는 뜻)이다. 그런데 그 비용은 고객 서비스가 치른다.
4) 온프레미스/코로케이션의 잊힌 장점
- 업데이트 타이밍을 당신이 정한다.
새벽 3시에 고객 모르게 배포하지 않는다. - 만약 배포 중 터지면, 곧바로 롤백/핫픽스가 가능하다.
- 사람(역량)이 옆에 있다. 즉시 대응한다.
비유하자면 수술실인데 헌혈 혈액도 준비 안 하고 배부터 쨌는 꼴이다. 병원(클라우드) 인프라가 아무리 좋아도, 팀이 통제하는 대비책이 없으면 위험하다.
5) "멀티클라우드가 답?" 꼬꼬마 시절에나 멋지게 들린 이야기다
멀티클라우드는 두 가지를 간과한다.
- 데이터 중력(Data Gravity)
트랜잭션성 데이터가 크로스 클라우드로 일관되게 복제·페일오버되려면, 지연·정합성·락 전략이 지옥도가 된다. - 공통 의존성
글로벌 DNS, 아이덴티티, SaaS CI/CD, 로그/알림, CDN, 버전 컨트롤… 벤더는 달라도 공통 상위 의존성이 터지면 같이 주저앉는다.
물론 특정 워크로드(읽기 전용 캐시, 콘텐츠 배포, 비핵심 백오피스)에는 멀티 벤더가 "리스크 분산"에 도움이 된다. 그러나 핵심 트랜잭션 경로는 멀티클라우드가 복잡성·비용·장애 면적을 키우는 경우가 훨씬 많다.
그래서 어떻게 해야 "더 안전"해지나
클라우드를 버리자는 말이 아니다. 초기 출시·실험 페이즈에서 클라우드는 압도적으로 좋다. 다만 안정기에 들어간 코어 경로는 다음을 권한다.
- 단일 리전 탈출, 단일 제어면 최소화
같은 벤더 안에서도 리전/계정(구독) 분리로 블라스트 반경을 줄여라. 제어면과 데이터면을 분리 배치. (예: 관리/감사 계정 분리) - "지루한" 기술을 쓰는 용기
코어는 매니지드 신상 대신 검증된 구성요소로 단순화. 마이그레이션은 단계별로. - 변경관리 엄수
카나리/서킷 브레이커/피처 플래그/그레이스풀 디그라데이션은 필수. 벤더 변경에 맞춰 우리도 릴리스 캘린더를 두고 피크 시간 변경 금지. - 오프클라우드 백스톱
읽기 전용 정적/캐시형 페일세이프(예: 중요 공지 페이지, 주문 내역 조회 캐시)를 다른 경로로 노출할 루트를 만들어 둔다. - 실전형 게임데이
DNS·아이덴티티·스토리지·메시지 브로커 각각이 죽었을 때의 런북과 RTO/RPO를 팀이 몸으로 기억해야 한다. - 성숙기 전략: 하이브리드/온프레 재배치
코어 트랜잭션과 상태 저장 계층은 코로케이션/온프레로 내리고, 엣지·버스트·분석은 클라우드로 둔다. "클라우드는 필요할 때 쓰는 도구"가 되어야 한다.
정리: "사람이 실수하지 않는다"는 가정이야말로 위험하다
클라우드는 훌륭한 도구다. 나도 초기 제품을 낼 땐 기꺼이 쓴다.
그러나 서비스가 안정기에 접어들면, 우리는 클라우드 의존도를 낮추고 핵심을 우리 손에 다시 쥔다. 그게 진짜 안전성을 만든다.
"클라우드 = 안전"이 아니라,
"통제 가능한 변경 + 검증 가능한 설계 = 안전"이다.
제대로 대우받는 개발자 | 부족한 컴공지식 배우기 | MIT급 컴공인강
최저임금으로 고통받는 일회성 프로그래머는 그만! POCU 아카데미가 올해 연봉협상을 책임지겠습니다!