바이브 코딩 시대, 멀티클라우드 DR의 손익분기점이 내려왔다

멀티클라우드는 복잡도가 너무 높다는 통념은 여전히 액티브-액티브 운영에는 유효하다. 그러나 다른 클라우드에 백업과 복구 수단만 유지하는 DR 계층에서는 비용 구조가 달라졌다. 바이브 코딩은 DR을 처음 만드는 비용을 줄이고, 소프트웨어 팩토리는 만든 DR이 계속 작동하도록 유지하고 검증하는 비용을 줄인다. 이 두 비용이 DR 비용의 대부분을 차지해 왔다.

---

TL;DR

• 멀티클라우드가 어렵다는 통념은 두 클라우드에서 서비스를 동시에 운영하는 액티브-액티브 구성에는 여전히 맞다. 데이터 전송 요금, 상시 운영 인력, 사용량 분산에 따른 할인 희석은 AI로 줄지 않기 때문이다.
• 반면 다른 클라우드에 백업과 복구 수단만 두는 DR 계층은 비용의 대부분이 구축과 검증 작업이어서 손익분기점이 내려왔다. 평소 사용량은 주 클라우드에 모여 있으므로 할인 혜택도 유지된다.
• 바이브 코딩은 DR을 만드는 비용(보조 클라우드용 IaC, 복원 스크립트, 런북)을 줄이고, 소프트웨어 팩토리는 만든 DR을 인프라 변경에 맞춰 갱신하고 정기 복원 훈련으로 검증하는 반복 비용을 줄인다.
• 서비스별 RTO/RPO 목표는 사람이 정하는 성공 기준이며, 장애조치 결정권도 사람에게 남는다.
• 시작점은 서비스별 RTO/RPO 목표를 정하고, 가장 중요한 서비스 하나의 백업을 다른 클라우드에 두고, 그 백업에서 실제로 복원해 보는 것이다.

---

게임은 이미 여러 플랫폼으로 가고 있다

최근 1-2년 사이 게임 업계에서는 독점작이 다른 플랫폼으로 출시되는 일이 흔해졌다. Microsoft는 Xbox 독점이던 Forza Horizon 5를 2025년 4월 PS5로 출시했고, 이 게임은 그달 미국 판매 순위 2위에 올랐다.¹ 같은 해 Gears of War: Reloaded가 시리즈 최초로 PS5에 나왔고, Indiana Jones and the Great Circle은 2026년 5월 Switch 2로 출시됐다.² 반대 방향도 있다. Sony의 Helldivers 2는 2025년 8월 Xbox로 출시됐는데, 분석 업체 Alinea의 추정에 따르면 Xbox판의 첫 6일 판매량(약 92.6만 장)이 2024년 PS5판의 같은 기간 판매량(약 63.3만 장)보다 많았다.³

이 흐름의 주된 동기는 수익 다변화다. 개발비가 계속 오르는 상황에서 한 플랫폼의 사용자만으로는 투자를 회수하기 어렵기 때문이다. Unreal과 Unity 같은 범용 엔진이 성숙해 플랫폼별 차이를 상당 부분 흡수해 준다는 점도 오래된 배경이다.

나는 여기에 바이브 코딩, 즉 AI 코딩 에이전트에게 구현을 맡기는 개발 방식이 이식 비용을 낮추고 있다는 요인이 더해지고 있다고 본다. 다만 이것은 해석이지 확인된 사실이 아니다. 2026년 10월 기준으로 게임 이식 비용이 AI 때문에 얼마나 줄었는지를 보여 주는 정량 자료는 찾지 못했다. GDC 2026 설문에서 응답자의 36%가 업무에 생성형 AI를 쓴다고 답했고 그 용도 중 코드 보조가 47%였지만, 같은 설문에서 생성형 AI가 업계에 해롭다는 응답도 52%로 늘었다.⁴

정량 근거는 게임이 아닌 일반 소프트웨어의 코드 마이그레이션 분야에 있다. Amazon은 약 3만 개 애플리케이션을 Java 17로 업그레이드하면서 AI 도구로 4,500 개발자-년을 절감했다고 밝혔다. 이 수치는 Amazon의 자체 추정이다.⁵ Google은 Ads 시스템의 32비트 ID를 64비트로 바꾸는 마이그레이션에서 반영된 코드 변경의 80%를 AI가 작성했고, 엔지니어들은 전체 소요 시간이 약 50% 줄었다고 추산했다. 다만 대부분의 경우 사람이 모델의 변경 일부를 되돌려야 했다고 저자들은 함께 밝혔다.⁶ 플랫폼 이식은 본질적으로 “같은 동작을 다른 환경의 API와 제약에 맞춰 다시 구현하는 일"이므로, 이 연구들은 게임 이식에도 같은 방향의 변화가 일어날 수 있다는 신호로 읽을 수 있다. 레거시 코드를 바이브 코딩으로 옮기는 구체적인 방법은 레거시 현대화 시리즈에서 다뤘다.⁷

클라우드에도 같은 일이 일어날까

게임에서 여러 플랫폼 대응을 가로막던 것이 이식 비용이었다면, 클라우드에서 같은 역할을 해 온 것은 멀티클라우드의 복잡도다. 그리고 단일 클라우드에 의존하는 위험은 이론이 아니다.

정확히 1년 전인 2025년 10월 19일 밤부터 20일 오후까지(미국 태평양 시간) AWS us-east-1 리전에서 대규모 장애가 발생했다. AWS의 사후 보고서에 따르면, DynamoDB의 DNS 관리 자동화에 잠재해 있던 경쟁 상태(race condition) 때문에 리전 엔드포인트의 DNS 레코드가 비어 버렸다. 이 장애는 EC2 인스턴스 시작, Network Load Balancer, Lambda, STS, IAM 콘솔 로그인으로 연쇄 확산됐다.⁸ 2025년 6월 12일에는 Google Cloud에서 Service Control에 오류 처리와 기능 플래그 없이 배포된 코드가 전 세계로 복제된 정책 데이터를 만나 크래시 루프에 빠졌고, 장애는 약 7시간 이어졌다.⁹

두 사고에는 공통점이 있다. 장애가 한 서비스나 한 가용 영역에 머물지 않고 인증, 엔드포인트, 정책 같은 공급자 내부의 공통 의존성을 따라 퍼졌다는 점이다. 같은 클라우드 안에서 리전을 나눠 두어도 이런 공통 의존성까지 분리되지는 않는다.

한편 Flexera의 2026년 조사에서 기업의 88%가 멀티클라우드를 쓴다고 답했다.¹⁰ 그러나 이 수치는 대부분 “업무별로 서로 다른 클라우드를 쓰는 상태"를 뜻한다. 한 클라우드가 멈췄을 때 다른 클라우드에서 서비스를 복구할 수 있도록 설계한 상태와는 다르다.

멀티클라우드가 어려웠던 이유를 비용 항목별로 나눠 보자

“멀티클라우드는 개발과 운영의 복잡도가 크게 올라간다"는 통념은 하나의 비용이 아니라 여러 비용을 묶은 말이다. AI의 효과를 정확히 따지려면 이 비용을 항목별로 나눠야 하고, AI의 효과도 두 가지로 나눠야 한다.

첫째는 바이브 코딩의 효과다. 바이브 코딩은 사람이 AI 코딩 에이전트와 대화하며 하나의 작업을 완성하는 방식이다. 이 방식이 줄이는 것은 한 번 드는 구축 비용 이다. 둘째는 소프트웨어 팩토리의 효과다. 이전 글에서 설명했듯이, 소프트웨어 팩토리는 사람이 목표와 제약, 위임 범위를 정하면 여러 자동화된 개발 흐름이 요구사항 정리부터 구현, 검증, 보고까지 계속 이어서 수행하는 운영 체계다.¹¹ 이 체계가 줄이는 것은 반복해서 드는 유지·검증 비용 이다. 두 효과는 시점도 다르다. 바이브 코딩은 지금 현장에서 바로 쓰는 방식이고, 소프트웨어 팩토리는 이제 조직이 구축하기 시작할 수 있는 방향이다.

아래 표는 각 비용을 두 효과로 나눠 판정한 것이다. 이 판정은 내 컨설팅 경험에 기반한 해석이며, 측정한 결과는 아니다.

비용 항목	내용	바이브 코딩 (구축)	소프트웨어 팩토리 (유지·검증)
인프라 코드 이중 작성	클라우드마다 다른 리소스 모델로 IaC를 따로 작성하고 유지	처음 작성하는 비용이 크게 줄어든다	주 클라우드 변경을 따라가는 갱신 비용이 크게 줄어든다
설계와 검토	서비스 대응표 작성, 데이터 복제 방식 설계, 장애조치 절차 설계	크게 줄어든다	변경이 생길 때 다시 검토하는 비용이 일부 줄어든다
런북과 테스트 코드	복구 절차 문서, 복원 스크립트, 검증 테스트	초안 작성 비용이 크게 줄어든다	인프라 변경에 맞춘 갱신 비용이 크게 줄어든다
복원 훈련	정기적으로 백업에서 복원하고 실제 RTO/RPO를 측정·보고	훈련 파이프라인을 만드는 비용이 줄어든다	반복 실행과 결과 보고 비용이 크게 줄어든다
추상화 계층 유지	두 클라우드의 차이를 감추는 공통 인터페이스 유지	일부 줄어든다	일부 줄어든다
데이터 전송 비용	클라우드 간 복제에서 발생하는 egress 요금	줄지 않는다	줄지 않는다
보안·IAM 모델 차이	권한 모델, 키 관리, 감사 로그 체계를 클라우드마다 운영	설정 작성 비용이 일부 줄어든다	설정 차이 감지 비용이 일부 줄어든다. 운영 책임은 남는다
운영 인력과 온콜	두 클라우드를 이해하는 인력 확보, 장애 대응 체계	줄지 않는다	장애 감지와 1차 보고는 일부 줄어든다. 장애조치 결정권은 사람에게 남는다
사용량 할인 희석	사용량을 두 클라우드로 나누면 약정 할인과 볼륨 할인의 조건을 채우기 어려워짐	줄지 않는다	줄지 않는다

표에서 보듯이, 두 효과는 서로 다른 비용을 겨냥한다. 바이브 코딩은 코드와 문서를 처음 만드는 비용을 줄이고, 소프트웨어 팩토리는 그 코드와 문서를 계속 맞게 유지하고 실제로 작동하는지 확인하는 비용을 줄인다. 둘 다 데이터 전송 요금과 할인 조건은 줄이지 못한다.

마지막 항목은 특히 따로 짚어 둘 필요가 있다. 클라우드 공급자의 할인은 사용량을 한곳에 모을수록 유리하게 설계되어 있다. AWS의 Savings Plans와 예약 인스턴스, Google Cloud의 약정 사용 할인(Committed Use Discounts)처럼 일정 사용량을 약정하고 할인을 받는 상품이 있고, 대규모 고객은 연간 지출 약정을 조건으로 공급자와 별도 할인 계약을 맺기도 한다. 평소 운영 중인 워크로드를 두 클라우드에 나누면 각 클라우드의 사용량이 줄어들어 이런 약정을 맺기 어렵거나, 더 낮은 할인 구간에 머물게 된다. 이 비용은 코드를 아무리 잘 만들어도 줄지 않는다.

이 구분에서 결론이 나온다. 두 클라우드에서 서비스를 동시에 운영하는 액티브-액티브 구성은 남는 비용, 즉 데이터 전송, 상시 운영, 할인 희석이 비용의 대부분을 차지하므로 여전히 어렵다. 반면 다른 클라우드에 백업과 복구 수단만 두는 DR 구성은 비용의 대부분이 설계·구현 작업과 반복 검증 작업이었다. 바이브 코딩과 소프트웨어 팩토리가 각각 줄이는 바로 그 비용이다. 게다가 DR 구성에서는 평소 컴퓨팅 사용량이 주 클라우드에 그대로 모여 있으므로, 주 클라우드의 할인 혜택도 유지된다. 보조 클라우드에서 상시 발생하는 비용은 주로 백업 스토리지와 전송 요금이다. 그래서 멀티클라우드 전반이 아니라 DR 계층에서 손익분기점이 먼저 내려왔다고 보는 것이다.

멀티클라우드 DR 전략 매트릭스

AWS는 DR 전략을 백업·복원, 파일럿 라이트, 웜 스탠바이, 멀티사이트 액티브-액티브의 4단계로 나누고, RTO(서비스 중단부터 복구까지 허용되는 최대 지연)와 RPO(마지막 복구 시점부터 허용되는 최대 데이터 손실 시간)를 낮출수록 자원 비용과 운영 복잡도가 커진다고 설명한다.¹² 원문은 AWS 안의 멀티 리전 구성을 다루지만, 같은 틀을 “주 클라우드와 보조 클라우드"에 적용할 수 있다. 아래 표는 그렇게 바꿔 본 것이다. AWS 원문은 단계별 RTO/RPO 수치를 제시하지 않으므로, 표에서도 상대적인 수준으로만 적었다.

전략	보조 클라우드에 유지하는 것	RTO / RPO	상시 비용	바이브 코딩이 줄이는 구축 작업
백업·복원	데이터 백업(오브젝트 스토리지 복제, DB 스냅숏·덤프)과 보조 클라우드용 IaC 코드	가장 길다 / 백업 주기만큼	가장 낮다 (스토리지와 전송 요금)	보조 클라우드용 IaC 작성, 복원 스크립트, 복원 검증 테스트
파일럿 라이트	상시 복제되는 데이터베이스와 최소한의 네트워크·핵심 인프라. 컴퓨팅은 꺼 둠	길다 / 짧다	낮다	클라우드 간 DB 복제 구성, 컴퓨팅 기동 자동화
웜 스탠바이	축소된 용량으로 상시 가동되는 전체 서비스	짧다 / 짧다	높다	두 클라우드의 배포 파이프라인 동기화, 용량 확장 자동화
멀티사이트 액티브-액티브	주 클라우드와 같은 규모의 운영 환경	가장 짧다 / 거의 없다	가장 높다	일부만 줄어든다. 데이터 정합성과 상시 운영 비용이 남는다

이 매트릭스에서 내가 가장 주목하는 것은 첫 번째 행이다. 백업만 다른 클라우드에 두는 구성은 상시 비용이 낮으면서도, 같은 클라우드 안의 멀티 리전 구성이 막지 못하는 위험을 막는다. 앞에서 본 것처럼 공급자 내부의 공통 의존성을 따라 퍼지는 장애가 그 하나다. 계정이 정지되거나 탈취되어 같은 계정 안의 백업까지 삭제되는 사고도 마찬가지다. 이런 사고는 같은 클라우드에 백업을 아무리 많이 복제해도 막을 수 없다.

과거에 이 구성을 망설인 이유는 백업 자체가 아니라 그다음 단계였다. 백업 데이터만 다른 클라우드에 있어도 실제로 복구하려면 보조 클라우드에 네트워크, 컴퓨팅, 데이터베이스, 권한 설정을 새로 만들어야 하고, 그 절차를 미리 코드로 준비해 두어야 한다. 이 준비 작업이 바이브 코딩으로 크게 줄어드는 부분이다. 주 클라우드의 IaC를 기준으로 보조 클라우드용 IaC를 작성하는 일, 서비스 대응 관계를 정리하는 일, 복원 스크립트를 작성하는 일은 모두 코드 마이그레이션과 같은 성격의 작업이기 때문이다.

전략을 고르는 기준은 서비스별 RTO/RPO 목표다. 모든 서비스를 같은 등급으로 둘 필요는 없다. 대부분의 서비스는 백업·복원으로 시작하고, 매출이나 규제에 직결되는 일부 서비스만 파일럿 라이트나 웜 스탠바이로 올리는 것이 현실적이다. 바이브 코딩은 이 등급을 서비스별로 다르게 구현하는 비용도 낮춘다.

진짜 비용은 구축 이후에 있다: 소프트웨어 팩토리로 상시 검증하기

DR 계획의 가장 흔한 실패는 구축하지 않은 것이 아니라, 실제로 작동하는지 확인하지 않은 것이다. 백업은 있는데 복원해 본 적이 없거나, 런북은 있는데 그 사이 인프라가 바뀌어 절차가 맞지 않는 경우를 현장에서 자주 본다. 멀티클라우드 DR에서는 이 문제가 더 커진다. 주 클라우드의 변경이 보조 클라우드의 복구 코드에 자동으로 반영되지 않기 때문이다.

카오스 엔지니어링은 이 문제에 대한 답이다. AWS는 카오스 엔지니어링의 원칙으로 실제 상황에 기반한 가설 수립, 영향 범위 한정, 롤백 장치 준비, CI/CD 안에서의 지속적인 장애 주입을 제시하고, 예상하지 못한 동작이 발견되면 원인 분석을 수행하라고 권한다. AWS Fault Injection Service(FIS)는 EC2, ECS, EKS, RDS 같은 리소스에 인스턴스 종료, 강제 장애조치, 지연, 패킷 손실 같은 장애를 주입하는 관리형 서비스다.¹³ 그 글의 표현처럼 카오스 엔지니어링의 목적은 운영 시스템을 망가뜨리는 것이 아니다.

멀티클라우드 DR에 적용하면 검증 체계는 두 부분으로 나뉜다. 첫째, 주 클라우드 쪽에서는 FIS 같은 도구로 “주 환경을 사용할 수 없다"는 상황을 만들고, 감지와 장애조치 결정이 기대대로 이루어지는지 확인한다. 둘째, 보조 클라우드 쪽에서는 정기적으로 백업에서 서비스를 실제로 복원하고, 복원에 걸린 시간과 마지막으로 복구된 데이터의 시점을 측정한다. 이 측정값이 실제 RTO와 RPO다. FIS는 AWS 리소스를 대상으로 하므로 두 번째 부분은 복원 훈련 파이프라인으로 따로 구성해야 한다.

이 체계를 처음 만드는 일은 바이브 코딩으로 충분하다. 실험 시나리오, 복원 파이프라인, 결과를 목표치와 비교하는 검사는 모두 한 번 작성하면 되는 코드다. 그러나 이 체계를 계속 유효하게 유지하는 일은 성격이 다르다. 주 클라우드의 인프라는 매주 바뀌고, 그때마다 보조 클라우드의 복구 코드와 런북과 훈련 시나리오를 맞춰야 한다. 사람이 매번 에이전트에게 이 작업을 지시하는 방식으로는, 바쁜 시기에 갱신이 밀리고 DR은 다시 문서 속 계획으로 돌아간다.

이 반복 작업이 소프트웨어 팩토리가 맡을 영역이다. 예를 들어 다음과 같은 흐름을 상시 운영할 수 있다. 주 클라우드의 IaC 변경이 병합되면, 자동화된 개발 흐름이 보조 클라우드 복구 코드에 필요한 변경을 찾아 수정안을 만든다. 수정안은 정해진 검증을 통과해야 반영된다. 정해진 주기마다 복원 훈련을 실행하고, 측정한 RTO/RPO를 목표치와 비교한다. 목표를 벗어나거나 예상하지 못한 동작이 발견되면 원인과 영향, 남은 위험을 정리해 사람에게 보고한다.

이때 사람이 고정해야 하는 것이 있다. 서비스별 RTO/RPO 목표는 사람이 정하는 성공 기준이며, 팩토리가 이 기준을 스스로 바꿀 수 있어서는 안 된다. 성공 기준까지 바꿀 수 있으면 훈련을 통과했다는 판단 자체를 믿을 수 없기 때문이다. 이전 글에서 소프트웨어 팩토리에는 좋은 보고 체계가 필요하다고 쓴 것도 같은 이유다.

그래서 나는 멀티클라우드 DR에서 더 큰 변화가 구축 비용의 감소보다 상시 검증 비용의 감소에 있다고 생각한다. 구축 비용은 바이브 코딩으로 이미 낮아졌다. 검증 비용까지 소프트웨어 팩토리로 낮아지면 훈련 주기를 분기에서 주 단위로 줄일 수 있고, 계획과 실제 사이의 차이를 빨리 발견할 수 있다.

한계: 바이브 코딩과 소프트웨어 팩토리가 해결하지 않는 것

이 주장에는 분명한 한계가 있다.

첫째, 데이터 전송 비용은 그대로 남는다. 2024년에 Google, AWS, Azure가 차례로 egress 요금 면제를 발표했지만, 이 면제는 해당 클라우드를 완전히 떠날 때만 적용된다. 예를 들어 AWS는 60일 안에 모든 데이터를 옮겨야 하고, Azure는 구독을 해지해야 한다.¹⁴ 따라서 상시 운영하는 DR 복제에는 전송 요금이 계속 발생한다. 백업 대상과 주기를 정할 때 이 비용을 먼저 계산해야 한다.

둘째, 규제가 멀티클라우드를 요구하는 것은 아니다. 2025년 1월부터 적용된 EU DORA는 금융기관에 핵심 ICT 서비스의 출구 전략과 집중 위험 관리를 요구하지만, 멀티클라우드를 의무화하지는 않는다.¹⁵ 규제는 검토의 계기가 될 수 있을 뿐, 구성의 근거는 각 조직의 RTO/RPO 목표여야 한다.

셋째, 사람의 판단은 줄어들지 않는다. 서비스별 RTO/RPO 목표를 정하는 일, 장애 상황에서 보조 클라우드로 전환할지 결정하는 권한과 기준, 훈련에서 발견된 차이를 어떻게 처리할지는 여전히 조직이 정해야 한다. 바이브 코딩이 만든 복구 코드든 소프트웨어 팩토리가 갱신한 복구 코드든, 사람이 검토 기준을 정하고 훈련으로 검증해야 한다는 점은 다른 코드와 같다.

결론: DR 계층부터 손익을 다시 계산하자

이 글의 결론은 “멀티클라우드로 가자"가 아니다. 멀티클라우드가 어렵다는 통념을 하나의 덩어리로 받아들이지 말고, 비용 항목별로 나눠 다시 계산하자는 것이다. 그렇게 나눠 보면, AI가 줄이는 비용이 가장 큰 비중을 차지하는 곳이 DR 계층이다. 바이브 코딩은 DR을 만드는 비용을 낮추고, 소프트웨어 팩토리는 만든 DR을 계속 작동하게 유지하는 비용을 낮춘다. 특히 백업만 다른 클라우드에 두는 구성은 평소 사용량을 주 클라우드에 모아 할인 혜택을 유지하면서도 단일 공급자에 묶인 위험을 막는다.

게임 업계가 이식 비용이 낮아진 만큼 더 많은 플랫폼으로 나아가고 있듯이, 클라우드 아키텍처도 검증 비용이 낮아진 만큼 더 넓은 장애 범위를 대비할 수 있게 되었다. 시작점은 단순하다. 서비스별 RTO/RPO 목표를 정하고, 가장 중요한 서비스 하나의 백업을 다른 클라우드에 두고, 그 백업에서 실제로 복원해 보는 것이다. 첫 복원 훈련에서 측정한 시간이 계획과 얼마나 다른지가 다음 투자를 결정할 근거가 된다.

---