몬조는 왜 AWS 위에 GCP 백업 은행을 따로 지었나 — Monzo Stand-in의 설계 철학

은행 서비스의 가용성은 마케팅 문구가 아니라 고객의 일상 그 자체다. 카드로 결제하고, 계좌 이체를 하고, 공과금을 내는 일에는 '점검을 위한 정지 시간'이라는 개념이 존재하지 않는다. 영국의 디지털 은행 몬조(Monzo)는 이 문제에 대해 흔한 다중 가용영역 구성이나 전통적 재해복구(DR)를 넘어서는 접근을 택했다. AWS 위에서 돌아가는 주(Primary) 플랫폼과는 완전히 분리된 별도의 백업 뱅킹 인프라 'Monzo Stand-in'을 구글 클라우드(GCP)에 구축한 것이다. 몬조는 이를 주력 신뢰성 수단이 아니라 '최후의 방어선'으로 규정한다.

Stand-in은 카드 결제와 현금 인출, 계좌 이체 송수신, 잔액 및 거래내역 조회, 카드 동결·해제 같은 가장 핵심적인 기능만 지원한다. 몬조 앱은 백그라운드에서 주기적으로 두 플랫폼을 확인하다가 Stand-in이 활성화되면 이 축소된 기능만 담은 단순화된 UI로 전환된다. 두 플랫폼은 각각 독립된 쿠버네티스 클러스터와 데이터베이스, 큐, 락 메커니즘 위에서 돌아가며, 여러 물리 데이터센터를 통해 결제망에 각자 연결해 거래 승인·거절을 독자적으로 판단한다.

같은 코드를 복제하지 않는 이유

주목할 점은 몬조가 주 플랫폼의 서비스를 그대로 복제해 두 번째 클라우드에 얹지 않았다는 것이다. 카드 결제 처리처럼 동일한 동작조차 Stand-in에서는 별도로 새로 구현했고, 카드 발급사 처리 코드도 각 플랫폼이 서로 다른 것을 돌린다. 몬조가 밝힌 이유는 두 가지다. 첫째, 같은 서비스를 돌리려면 양쪽 데이터를 강한 일관성으로 복제해야 하는데, 그러면 한쪽이 죽었을 때 쓰기 자체가 불가능해져 가용성이 오히려 떨어진다. 둘째이자 더 근본적인 이유는, 클라우드 사업자들이 하드웨어 장애는 대부분 해결했지만 '모든 데이터센터에서 같은 소프트웨어를 돌린다'는 위험은 그대로 남아 있다는 점이다. 장애의 원인이 클라우드 사업자 자체가 아니라 몬조 자신의 코드나 프로세스의 버그일 가능성도 그에 못지않게 높다. 데이터센터를 아무리 늘려도 같은 버그는 모든 곳에서 동시에 터진다.

결국 핵심은 '독립성'이다. Stand-in이 주 플랫폼과 공유하는 코드가 적을수록 같은 문제가 양쪽을 동시에 무너뜨릴 확률이 줄어든다. 이 독립성을 유지하는 비용은 의외로 낮다. Stand-in을 평상시 대기 상태로 돌리는 비용은 주 플랫폼의 약 1%에 불과하고, 장애 시 활성화해도 소폭만 오른다. 반면 모든 시스템을 그대로 복제하고 데이터를 전량 동기화하려 했다면 전체 플랫폼 비용이 두 배로 뛸 수도 있었다는 것이 몬조의 계산이다.

최소 상태 동기화와 'Monzo Advices'

Stand-in은 필요한 최소 상태만 보유한다. 잔액과 제한된 거래 이력, 결제에 필요한 카드·계좌 정보, 포트(pots)와 수취인 목록 정도다. 주 플랫폼에서 상태가 바뀔 때마다 발생하는 이벤트 중 일부를 'Stand-in Data Syncer'가 소비해 Stand-in 쪽 상태를 갱신한다. 이렇게 동기화된 데이터는 모두 불변(immutable)으로 취급된다. 완벽한 일관성을 보장하지는 않지만 실시간 동기화 덕분에 실제로는 거의 완전한 일관성에 가깝고, 몬조는 이 지연(lag)을 면밀히 감시하며 허용치를 넘으면 경보를 울린다. 암호화된 카드 PAN 같은 토큰화 데이터는 A·B로 구분된 서로 다른 키셋으로 암호화해 교환하는 조금 다른 경로를 탄다.

Stand-in이 켜져 있는 동안 내려진 결제 승인 같은 결정은 그 기간에만 권위를 갖는다. 어디까지나 주 플랫폼이 항상 '기록의 원장(system of record)'이며, Stand-in은 그 역할을 대신하지 않는다. Stand-in에서 만들어진 모든 효과는 'Monzo Advices'라는 이름으로 내구성 있는 큐에 기록되고, 주 플랫폼이 복구되면 이를 그대로 적용한다. 이 구조에는 감수한 위험이 있다. Stand-in의 다소 오래된 잔액 뷰로 승인한 결제가 실제로는 잔액 부족이어서 고객을 마이너스 통장 상태로 밀어넣을 수 있다는 것이다. 몬조는 주 플랫폼에 여러 통제 장치를 두어 이 가능성이 실제로는 극히 드물다고 설명한다. 또한 같은 결제가 양쪽에 이중으로 잡히는 문제는 Correlation ID로 거래를 상관지어 병합해 해결한다.

전환의 통제권과 실전 검증

Stand-in의 활성화는 양쪽 플랫폼에 각각 존재하는 Stand-in Configuration 서비스가 조율한다. 어느 플랫폼을, 어떤 구성요소를, 어떤 사용자에게 켤지를 제어하며, 주 플랫폼이 완전히 죽어도 동작한다. 현재는 엔지니어가 CLI로 수동 설정하지만, 같은 판단 기준을 자동화할 여지가 있다고 몬조는 밝힌다. 흥미로운 점은 결제 트래픽을 Stand-in으로 넘길 때 처음에는 주 플랫폼이 트래픽을 받아 Stand-in으로 프록시한다는 것이다. 얼핏 비효율적으로 보이지만, 몇 %의 고객을 혹은 어떤 고객을 넘길지 정밀하게 통제하고 빠르게 원상 복구할 수 있게 해준다. 주 플랫폼이 완전히 다운되면 데이터센터를 통해 Stand-in을 결제망에 직접 연결하는데, 이 경로는 통제력이 떨어지지만 없어서는 안 될 비상 수단이다. 두 경로 모두 실제 프로덕션에서 상시 검증된다.

이 설계가 이론에 그치지 않았음은 2024년 8월 입증됐다. 결제 처리와 앱 서비스를 포함한 대부분 시스템에 영향을 준 약 1시간짜리 대형 장애에서, 몬조는 문제 감지 직후 Stand-in을 켰다. 평소에도 소수 고객은 테스트 목적으로 Stand-in을 쓰고 있었지만, 전 고객·전 구성요소를 대상으로 활성화한 것은 이때가 처음이었다. 한국의 금융·핀테크 실무자에게 이 사례가 주는 시사점은 분명하다. 멀티 클라우드나 다중 데이터센터라는 물리적 이중화만으로는 자기 코드의 버그라는 가장 흔한 장애 원인을 막지 못한다. 몬조는 '같은 소프트웨어를 여러 곳에 돌리는 것'을 위험으로 규정하고, 기능을 최소화한 독립 구현과 이벤트 기반 최종 일관성 동기화, 그리고 원장 권위를 주 플랫폼에 고정하는 방식으로 비용 대비 실효성 있는 최후 방어선을 만들어냈다.