한 셀이 죽어도, 은행은 살아있다 — Cell-Based Architecture로 보는 금융 클라우드 회복탄력성
리전 하나가 멈추자 은행 앱 절반이 침묵했다
2026년 3월, AWS의 UAE(ME-CENTRAL-1)와 Bahrain(ME-SOUTH-1) 리전에서 약 60개의 서비스가 동시에 다운됐다. 직접적 원인은 US/Israel-Iran 군사 충돌 중 데이터센터 인근에서 벌어진 드론 공격으로, Multi-AZ가 24시간 이상 오프라인이 됐다. ADCB, Emirates NBD 같은 UAE 대형 은행의 모바일·온라인뱅킹이 한 번에 멈췄고, Snowflake, Anthropic Claude까지 다운스트림으로 영향을 받았다. 한국 금융사 92%가 퍼블릭 클라우드를 쓰는 지금, 똑같은 질문이 다시 떠오른다 — "리전 하나가 죽으면 우리도 죽는가?"
다운된 AWS 서비스 수
퍼블릭 클라우드 채택률
Prime Video 가용성
"Everything fails, all the time. So plan for failure and nothing will fail." — Dr. Werner Vogels, CTO, Amazon.com
Werner Vogels의 이 한 마디는 2024년 re:Invent 키노트의 핵심 메시지였다. 그가 이번 키노트에서 시간을 가장 많이 할애한 패턴이 바로 Cell-Based Architecture다.
BEFORE: 단일 리전 모놀리스의 한계
전통적인 클라우드 배포는 리전 안에서 멀티 AZ(가용영역)로 분산하는 게 정석이다. 그런데 멀티 AZ는 하드웨어 장애나 데이터센터 화재 같은 물리적 장애는 막아도, 다음과 같은 논리적 장애는 막지 못한다.
- 잘못된 코드 배포 — 동일 코드가 모든 AZ에 배포되면 모든 AZ가 함께 죽는다
- 구성 오염(corrupted config) — 라우팅 테이블, IAM 정책, 시크릿이 잘못 갱신되면 리전 전체로 전파
- 컨트롤 플레인 단일점 — IAM·라우팅·메타데이터 같은 컨트롤 플레인은 사실상 단일 리전 의존
- 운영자 실수 — 한 사람이 마스터 데이터를 잘못 건드리면 리전 전체에 즉시 반영
2017년 S3 US-EAST-1 4시간 다운 사건이 이걸 적나라하게 보여줬다. 한 엔지니어의 잘못된 디버깅 명령 한 줄이 리전 전체의 메타데이터를 날렸고, 그 위에 올라가 있던 인터넷의 절반이 멈췄다.
| 장애 유형 | 멀티 AZ로 막을 수 있나? | 이유 |
|---|---|---|
| 하드웨어 화재 | YES | 물리적 분리 |
| 네트워크 케이블 단선 | YES | 이중화 회선 |
| 코드 배포 결함 | NO | 같은 코드 = 같은 죽음 |
| 구성 오염 | NO | 구성이 리전 단위 공유 |
| 운영자 실수 | NO | 전 리전에 즉시 반영 |
결론적으로, 멀티 AZ는 물리적 사고는 막지만 소프트웨어/인적 사고는 막지 못한다. 그래서 등장한 게 더 강력한 격리 단위 — 셀(cell)이다.
AFTER: Cell-Based Architecture의 핵심 3원칙
Cell-Based Architecture는 워크로드를 N개의 독립적이고 자기완결적인 인스턴스(cell)로 쪼갠 뒤, 각 사용자 요청을 정해진 셀로만 라우팅하는 패턴이다. 한 셀이 죽어도 다른 셀은 영향을 받지 않으므로 장애 반경(blast radius) ≈ 1/N이 된다.
원칙 1 — No Shared State (Bulkhead Pattern)
각 셀은 자기만의 컴퓨트, 데이터베이스, 캐시, 큐를 보유한다. 셀 간에는 어떤 상태도 공유하지 않는다. 한 셀의 corrupt deploy가 다른 셀의 데이터를 더럽힐 통로 자체가 존재하지 않아야 한다. 선박의 격벽(bulkhead)이 침수를 한 구획 안에 가두는 것과 같다.
원칙 2 — Thin Cell Router
사용자 요청을 어떤 셀로 보낼지 결정하는 라우터는 가능한 가장 얇은 계층(the thinnest possible layer)이어야 한다. partition_key를 받아서 cell_id를 반환하는 단순 매핑 외 어떤 비즈니스 로직도 라우터에 들어가서는 안 된다.
왜냐하면 라우터에 권한 검증, A/B 테스트, 요금 계산 같은 로직을 얹기 시작하는 순간, 라우터 자체가 SPOF가 되어 셀 격리의 의미가 무너지기 때문이다. AWS Builders' Library는 이 원칙을 거의 종교적으로 강조한다.
원칙 3 — Shuffle Sharding (셀 내부 격리)
한 셀 안에서도 사용자별로 가상 샤드를 카드 섞듯(shuffle) 배분한다. 사용자 A는 워커 [1,3,7]에, 사용자 B는 [2,4,5]에 배정되는 식이다. 두 사용자가 정확히 같은 워커 조합에 매핑될 확률은 조합 수만큼 작아지고, 그 결과 한 사용자의 toxic request가 다른 사용자에게 전파될 확률이 극단적으로 낮아진다. AWS Architecture Blog가 이를 "Massive and Magical Fault Isolation"이라 부르는 이유다.
실무 체크리스트 — 셀 도입 yaml
금융사가 신규 워크로드를 셀 기반으로 설계할 때 점검해야 할 항목을 yaml 형식으로 정리하면 다음과 같다.
cell:
partition_key = "customer_id" ✓ 자연 분할 (계정 단위)
cell_count = 8 ✓ blast radius 12.5%
shared_state = "none" ✓ 셀 간 상태 공유 금지
router:
layer = "thin_stateless" ✓ 단순 매핑 only
business_logic = "forbidden" SPOF 방지
scaling = "horizontal" ✓ 수평 확장
deploy:
strategy = "wave" ✓ 셀 단위 점진
canary_first = "cell_0" ✓ 1개 셀 검증 후 확산
isolation:
shuffle_sharding = "intra_cell" ✓ 셀 내부 격리
cross_cell_call = "forbidden" 전파 차단
partition_key를 무엇으로 잡을 것인가
파티션 키는 셀 기반 설계에서 가장 중요한 결정이다. 좋은 파티션 키는 자연스럽게 분할 가능하고, 셀 간 상호작용을 최소화하는 키다. 금융 도메인에서는 다음이 일반적이다.
- customer_id / account_id — 가장 자연스러운 분할. 한 고객의 모든 거래가 같은 셀에서 처리됨
- merchant_id — 결제 처리 서비스에서 가맹점 단위로 분할 (Stripe 방식)
- tenant_id — B2B SaaS에서 입주사 단위로 분할
반대로 나쁜 파티션 키는 hot-cell을 만든다. 예를 들어 timestamp나 country_code를 키로 쓰면 특정 시간대·특정 국가에 트래픽이 몰려 한 셀만 과부하가 걸린다.
라우터가 두꺼워지는 순간 셀 격리는 무너진다
라우팅 계층에 권한 검증, A/B 테스트, 요금 계산 같은 로직을 얹는 순간 라우터가 SPOF로 변한다. 라우터는 partition_key → cell_id 매핑만 수행하고, 모든 비즈니스 로직은 셀 내부에서 처리해야 한다. AWS Builders' Library 원칙: "The thinnest possible layer."
실제 적용 사례 — Prime Video, Stripe, 그리고 한국 금융권
AWS Prime Video — 99.999% 가용성
re:Invent 2024 ARC312 세션에서 공개된 사례. Prime Video는 Cell-Based Architecture를 적용해 99.999%(5-nines) 가용성을 달성했다. 이는 월간 다운타임 약 26초 수준으로, 동영상 스트리밍 같은 24/7 서비스에서는 사실상 한계치에 가깝다. 셀 단위 배포(Wave Deployment)를 통해 새 코드를 한 셀씩 점진 적용하므로, 잘못된 배포가 발생해도 한 셀에만 격리된다.
Stripe — 가맹점 ID 기반 셀 분할
결제 인프라의 대표주자 Stripe는 가맹점 ID를 파티션 키로 셀을 구성하는 것으로 알려져 있다. 한 가맹점의 트래픽이 비정상 폭주해도 다른 가맹점에 영향을 주지 않으며, 결제 처리의 전제 조건인 "예측 가능한 격리"를 보장한다.
한국 금융권의 현재
한국 금융사 92%가 이미 퍼블릭 클라우드를 활용한다. 그러나 대다수가 단일 CSP에 집중되어 있어 이번 AWS 장애 같은 사건이 발생하면 systemic risk가 즉시 현실화된다. 금융위는 이미 멀티클라우드 가이드를 준비 중이며, 디일렉 등 매체는 국내 CSP가 DR(재해복구) 백업 역할로 부상할 가능성을 보도하고 있다.
| 시점 | 사건 | 의미 |
|---|---|---|
| 2017.02 | S3 US-EAST-1 4시간 다운 | 리전 단위 SPOF의 위험성 폭로 |
| 2021.12 | AWS 리전 장애 재발 | Cell-Based Architecture 본격 권고 |
| 2024.12 | re:Invent — Werner Vogels 키노트 | "Everything fails" 메시지 강조 |
| 2026.03 | UAE/Bahrain 리전 ~60개 서비스 다운 (드론 공격) | ADCB, Emirates NBD, Snowflake 동시 영향 |
| 2026.04 | 국내 금융권 재점검 본격화 | 현재 단계 |
커리어 인사이트 — 셀로 쪼개는 시대의 직무
Cell-Based Architecture가 표준이 되면 금융 IT의 인력 수요도 이동한다. 인프라를 쌓는 사람이 아니라 장애를 미리 시뮬레이션하고 격리하는 사람이 필요해진다.
유망 직무
- Resilience Engineer (SRE) — 셀 단위 카오스 실험, SLO/Error Budget 운영, 셀 페일오버 자동화. Netflix Chaos Monkey, AWS FIS 같은 도구 경험이 핵심
- Cloud Architect — 파티션 키 선정, Cell Router 구현, 멀티 리전·멀티 CSP 토폴로지 설계. AWS SAA·SAP, Google PCA, Azure Solutions Architect 자격
- DR & Continuity Manager — RTO/RPO 목표 설정, 리전 페일오버 플레이북, 금감원·금융보안원 IT 안전성 보고서 작성
핵심 기술 스택
- Cell Router — partition_key 기반 라우팅 (Envoy, NGINX, AWS Route 53 ARC)
- Shuffle Sharding — AWS Route 53 Application Recovery Controller, Aerospike
- Chaos Engineering — AWS Fault Injection Simulator, Gremlin, Chaos Mesh
- SLO/SLI — Prometheus, Grafana, OpenTelemetry
- AWS Well-Architected Framework — Reliability Pillar 필독
핵심 정리
- 2026년 3월 AWS UAE/Bahrain 리전 장애 — 드론 공격으로 ~60개 서비스 다운, ADCB·Emirates NBD·Snowflake·Anthropic Claude 동시 영향. 단일 CSP 의존의 systemic risk 재확인
- Cell-Based Architecture — 워크로드를 N개의 독립 셀로 쪼개 장애 반경을 1/N로 축소. AWS Well-Architected Framework의 Reliability 핵심 패턴
- 3원칙: ① No Shared State (Bulkhead) ② Thin Cell Router (no business logic) ③ Shuffle Sharding (셀 내부 격리)
- partition_key 설계가 핵심 — customer_id/merchant_id 같은 자연 분할 키 권장, timestamp 같은 hot-key 회피
- Prime Video 99.999% 가용성 — re:Invent 2024 검증 사례. Wave Deployment로 점진 배포
- 한국 금융권: 92% 클라우드 채택 + 단일 CSP 집중 → 멀티 리전 + Cell-Based + 멀티 CSP 3중 격리가 차세대 표준
참고자료
'금융 IT' 카테고리의 다른 글
| 삼성SDS × 우리은행, 175개 AI 에이전트로 은행 업무를 재설계하다 (0) | 2026.04.10 |
|---|---|
| 초 단위 시세조종, 이제 AI가 잡아낸다 (0) | 2026.04.10 |
| 13년 망분리, 별표 7로 풀린다 (0) | 2026.04.08 |
| 크립토가 은행이 된다 (0) | 2026.04.07 |
| SWIFT가 블록체인을 택했다 (0) | 2026.04.05 |
