하이퍼스케일러가 침묵하는 동안, 기업들은 스스로 답을 찾기 시작했습니다. 그리고 가장 먼저 깨달은 것은 이것입니다. 모든 워크로드가 같지는 않습니다.
과거에는 단순했습니다. 온프레미스 시대에는 모든 것이 데이터센터에 있었고, 클라우드 초기에는 "일단 다 올리자"가 전략이었습니다. 하지만 지금은 다릅니다.
어떤 애플리케이션은 회사의 생존에 직결되어 있습니다.
결제 시스템이 1시간 다운되면 수억 원의 손실이 발생하고, 고객 신뢰는 회복 불가능하게 무너집니다. 반면 어떤 애플리케이션은 하루 종일 다운되어도 사업에 큰 영향이 없습니다. 내부 위키가 접속 안 된다고 회사가 망하지는 않습니다.
어떤 데이터는 법적으로 국경 간 이전이 강하게 제한되거나 사실상 금지에 가까운 규제를 받습니다.
의료 기록, 금융 거래 내역, 개인 식별 정보. 중국의 사이버보안법처럼 중요 데이터에 대해 로컬라이제이션을 요구하거나, GDPR처럼 국경 간 이전에 엄격한 조건을 부과하는 규제들이 있습니다. 이것들이 잘못된 국가의 서버에 저장되면 수십억 원의 벌금과 형사 처벌이 기다립니다.
반면 어떤 데이터는 전 세계 어디에 있어도 상관없습니다. 제품 카탈로그, 마케팅 이미지, 공개 문서.
어떤 워크로드는 트래픽이 예측 불가능합니다.
블랙프라이데이 세일 때 평소의 100배 트래픽이 몰리고, 나머지 364일은 한산합니다. 반면 어떤 워크로드는 매일 정확히 같은 양의 리소스를 씁니다. 야간 배치 작업은 매일 밤 3시간 동안 정확히 32개 코어를 씁니다.
이 모든 것을 하나의 전략으로 다룰 수는 없습니다.
첫 번째 분류 기준은 비즈니스 영향도입니다.
Tier 1: Mission-Critical
이 워크로드가 멈추면 사업이 멈춥니다.
결제, 주문, 재고, 고객 인증. 99.95~99.999% 수준의 매우 높은 가용성이 요구됩니다(업계와 시스템에 따라 다릅니다). 다운타임은 분 단위가 아니라 초 단위로 측정됩니다.
이런 워크로드는 클라우드의 단일 리전에 두면 위험합니다.
2025년 10월 AWS us-east-1 리전에서 약 14시간 동안 장애가 발생했을 때, 140여 개 서비스가 영향을 받으며 수많은 기업의 서비스가 함께 멈췄습니다.
비용이 들더라도 멀티 리전, 멀티 클라우드, 또는 하이브리드 구성이 필요합니다.
Tier 2: Business-Important
다운되어도 사업에 영향이 거의 없습니다. 개발 환경, 테스트 서버, 내부 도구. 99%도 괜찮습니다.
연간 3-4일 다운되어도 큰 문제가 없습니다.
이런 워크로드는 비용 최적화가 최우선입니다.
스팟 인스턴스(AWS Spot Instance, Azure/Google Cloud Spot VM) 사용, 저렴한 리전 사용을 통해 성능과 가용성을 희생 대신 비용을 줄입니다.
Tier 3: Non-Critical
다운되어도 사업에 영향이 거의 없습니다.
개발 환경, 테스트 서버, 내부 도구. 99%도 괜찮습니다. 연간 3-4일 다운되어도 큰 문제가 없습니다.
이런 워크로드는 비용 최적화가 최우선입니다.
스팟 인스턴스, 프리엠티블 VM, 저렴한 리전 사용. 성능과 가용성을 희생하고 비용을 줄입니다.
두 번째 분류 기준은 데이터의 민감도입니다.
Highly Sensitive
개인 식별 정보(PII), 금융 데이터, 의료 기록, 국가 안보 정보처럼 강력한 규제를 받는 데이터입니다.
PII는 GDPR, 의료 기록은 HIPAA, 금융 데이터는 각국 금융 규제의 대상입니다. 암호화는 기본이고, 접근 로그는 여러 규제를 고려해 6~7년 이상 보관하는 것이 일반적입니다(HIPAA는 6년, 일부 금융 규제는 7년 이상을 요구합니다). 데이터 위치는 특정 국가 내로 제한됩니다.
규제 요건과 조직 역량에 따라, 일부 고민감 데이터는 여전히 온프레미스 또는 전용 하드웨어(Dedicated Hosts)가 선호될 수 있습니다. 퍼블릭 클라우드를 사용하는 경우에도 해당 규제(예: GDPR, HIPAA)에 적합한 인증을 받은 리전과 서비스만 사용 가능합니다.
최근에는 기밀 컴퓨팅(Confidential Computing) 기술로 클라우드에서도 메모리 암호화가 가능해졌지만, 여전히 규제 해석이 필요합니다.
Moderately Sensitive
내부 비즈니스 데이터, 고객 행동 분석, 계약 정보. 외부 유출되면 경쟁력을 잃지만, 법적 처벌까지는 아닙니다.
이런 데이터는 퍼블릭 클라우드에 올려도 되지만, 암호화와 접근 제어는 철저히 해야 합니다.
데이터베이스 암호화(TDE), 전송 암호화(TLS), IAM 정책을 제대로 설정하면 충분히 안전합니다.
Public
마케팅 콘텐츠, 제품 정보, 공개 API 문서. 이미 세상에 공개된 데이터이거나, 공개되어도 문제없는 데이터입니다.
이런 데이터는 어디에 두든 상관없습니다. CDN으로 전 세계에 배포하고, 가장 싼 스토리지 클래스를 씁니다. 오히려 접근성과 성능이 중요합니다.
세 번째 분류 기준은 리소스 사용의 예측 가능성입니다.
Highly Variable
이커머스 사이트의 트래픽, 소셜 미디어의 바이럴 이벤트, 게임 서버의 동시 접속자 폭증 등이며 평소의 10배, 100배 트래픽이 예고 없이 몰릴 수 있습니다.
이런 워크로드는 클라우드의 탄력적 확장이 필수입니다.
Auto Scaling, 서버리스, 컨테이너 오케스트레이션 등을 사용해서 탄력적 확장을 확보할 수 있습니다.
온프레미스로는 두 가지 선택밖에 없습니다.
피크에 맞춰 과도하게 투자하면 평상시 대부분의 자원이 놀고, 평균에 맞춰 투자하면 피크 때 서비스가 다운됩니다.
Predictable
야간 배치 작업, 정기 리포트 생성, 데이터 백업. 매일, 매주, 매월 정확히 같은 시간에 같은 양의 리소스를 씁니다.
이런 워크로드는 오히려 온프레미스나 예약 인스턴스(Reserved Instances)가 경제적일 수 있습니다.
3년 예약 인스턴스는 조건에 따라 온디맨드 대비 최대 60-70%까지 저렴할 수 있습니다.
사용률이 높고 예측 가능하면, 고정 비용으로 전환하는 것이 유리합니다.
Steady-State
기업 ERP, 이메일 서버, 파일 서버. 사용량이 거의 일정합니다. 직원 수가 급변하지 않는 한, 리소스 요구량도 안정적입니다.
이런 워크로드는 코로케이션이나 온프레미스가 가장 경제적일 수 있습니다. 5년 감가상각으로 계산하면, 퍼블릭 클라우드보다 30-50% 저렴합니다. 다만 초기 투자와 운영 인력이 필요합니다.
네 번째 분류 기준은 레이턴시(지연) 민감도입니다.
Ultra-Low Latency (<10ms)
금융 거래, 온라인 게임, 실시간 음성/영상 통신, 산업 IoT 제어 등의 분야는 지연이 10ms가 넘으면 사용자 경험이 무너지거나, 비즈니스 기회를 놓치거나, 안전사고가 발생합니다.
이런 워크로드는 엣지나 온프레미스로 내려와야 합니다.
서울에서 버지니아까지 200ms가 걸리는데, 이건 물리 법칙입니다.
AWS Outposts, Azure Stack, Google Distributed Cloud 같은 하이브리드 솔루션, 또는 Cloudflare Workers, AWS Lambda@Edge 같은 엣지 컴퓨팅이 필요합니다.
Low Latency (<100ms)
웹 애플리케이션, 모바일 앱, API 서비스가 이에 해당합니다.
100ms 이하면 사용자가 "빠르다"고 느낍니다. 100-200ms는 "괜찮다", 200ms 이상은 "느리다"입니다.
이런 워크로드는 멀티 리전 배포가 효과적입니다.
사용자와 가까운 리전에서 서비스하면, 레이턴시를 50-100ms 줄일 수 있습니다. CDN과 결합하면 정적 콘텐츠는 10-20ms까지 줄어듭니다.
Latency-Tolerant (>200ms)
배치 작업, 데이터 분석, 백업 등이 이에 해당하며 몇 초 늦어도 상관없습니다. 오히려 처리량(throughput)과 비용이 중요합니다.
이런 워크로드는 리전 선택이 자유롭습니다. 가장 저렴한 리전을 쓰면 됩니다.
데이터가 이미 특정 리전에 있다면, 데이터 전송 비용을 고려해서 같은 리전에서 처리하는 것이 경제적입니다.
이론은 간단하지만, 현실은 복잡합니다. 한 애플리케이션이 여러 축에 걸쳐 있습니다.
예를 들어 이커머스 플랫폼을 생각해 보겠습니다.
- 프론트엔드 (제품 카탈로그): Tier 2, Public 데이터, Highly Variable, Low Latency → CDN + 멀티 리전 클라우드
- 주문 시스템: Tier 1, Highly Sensitive, Highly Variable, Ultra-Low Latency → 멀티 리전 클라우드 + 엣지 캐싱, 또는 하이브리드
- 결제 처리: Tier 1, Highly Sensitive, Predictable, Ultra-Low Latency → 전용 인프라 또는 규제 인증 리전, 온프레미스 백업
- 재고 관리: Tier 1, Moderately Sensitive, Steady-State, Latency-Tolerant → 클라우드 매니지드 DB, 예약 인스턴스
- 데이터 분석: Tier 2, Moderately Sensitive, Predictable, Latency-Tolerant → 클라우드 데이터 웨어하우스, 저렴한 리전
- 백업: Tier 3, Moderately Sensitive, Predictable, Latency-Tolerant → 가장 저렴한 스토리지 클래스 (Glacier, Archive)
이렇게 분해하면, "우리 시스템을 클라우드로 옮겨야 하나요?"라는 질문 자체가 틀렸다는 것을 알게 됩니다. 올바른 질문은 "우리 시스템의 각 구성 요소를 어디에 배치해야 최적인가?"입니다.
인프라를 전략적으로 분류하고 나면, 자연스럽게 한 가지 결론에 도달합니다.
하이브리드는 타협이 아니라 필연입니다.
2010년대 중반, 클라우드는 집중화(Centralization)의 상징이었습니다.
전 세계 수백만 기업의 워크로드가 AWS 버지니아 리전 한 곳에 몰렸습니다.
"왜 굳이 여러 곳에 나눠서 복잡하게 하나? 다 AWS에 올리면 되잖아."
그런데 역설적이게도, 클라우드가 성숙할수록 분산화(Decentralization)로 돌아가고 있습니다.
업계에서는 이를 '클라우드 회귀(Repatriation)' 또는 '클라우드 송환'이라 부릅니다.
단순한 분산이 아니라, 인프라 주권을 되찾아오는 움직임입니다.
첫째, 규제가 집중을 허용하지 않습니다.
EU 데이터는 EU에, 중국 데이터는 중국에, 한국 공공 데이터는 한국에 두어야 합니다. 아무리 AWS가 편해도, 법을 어길 수는 없습니다.
둘째, AI가 엣지를 요구합니다.
자율주행차는 클라우드에 물어볼 시간이 없습니다. 스마트 팩토리의 로봇도, 원격 수술 로봇도, 드론도 마찬가지입니다. 판단은 현장에서 즉시 내려져야 합니다.
셋째, 비용이 분산을 강제합니다.
클라우드의 데이터 전송 비용(egress fee)은 터무니없이 비쌉니다.
1TB 데이터를 AWS에서 빼내는 데 90달러가 듭니다. 매일 10TB씩 처리하는 회사는 매달 27,000달러를 데이터 전송비로만 냅니다. 연간 약 32만 달러입니다. 이 돈이면 온프레미스 데이터센터를 하나 더 지을 수 있습니다.
넷째, 락인 위험이 분산을 정당화합니다.
모든 것을 AWS에 두면 편하지만, AWS가 가격을 20% 올리거나, 서비스를 단종하거나, 정책을 바꾸면 선택권이 없습니다. 다른 클라우드로 옮기는 데는 수억 원과 1-2년이 걸립니다. 분산은 협상력입니다.
엣지 컴퓨팅은 새로운 개념이 아닙니다. CDN은 20년 넘게 엣지에서 콘텐츠를 서빙해왔습니다.
하지만 최근의 엣지는 다릅니다. 단순히 캐싱하는 것이 아니라, 컴퓨팅하고 판단합니다.
Cloudflare Workers는 전 세계 330개 이상 도시의 엣지에서 JavaScript를 실행합니다.
사용자 요청을 받아 즉시 처리하고, 50ms 이내에 응답을 돌려줍니다.
API 라우팅, 인증, A/B 테스트, 개인화를 엣지에서 처리합니다. 클라우드 리전까지 왕복할 필요가 없습니다.
AWS Lambda@Edge는 전 세계 수백 개의 CloudFront 엣지 로케이션에서 함수를 실행합니다.
이미지 리사이징, URL 재작성, 헤더 조작을 엣지에서 처리하면, 오리진 서버의 부하가 90% 줄어듭니다.
Azure IoT Edge는 공장, 병원, 유통센터에 배치되어 로컬에서 데이터를 수집하고 분석합니다.
AI 모델을 엣지에 배포하면, 네트워크가 끊겨도 제조 라인은 멈추지 않습니다. 클라우드는 주기적으로 모델을 업데이트하고 인사이트를 집계하는 역할만 합니다.
Google Distributed Cloud는 아예 Google의 하드웨어를 고객 온프레미스에 설치합니다.
통신사 5G 코어, 소매점 AI 분석, 금융 거래 처리처럼 레이턴시와 규제가 동시에 중요한 워크로드를 위한 것입니다. 엣지는 더 이상 "캐시 서버"가 아닙니다. 분산된 컴퓨팅 플랫폼입니다.
클라우드 시대에 온프레미스는 "레거시", "구시대"로 치부되었습니다.
하지만 최근 온프레미스가 재평가되고 있습니다. 이른바 '클라우드 회귀(Repatriation)' 움직임의 핵심입니다.
비용 역전 현상
클라우드는 처음에는 쌉니다. 초기 투자가 없고, 쓴 만큼만 내니까요. 하지만 규모가 커지면 역전됩니다.
Dropbox는 2017년 S3에서 자체 스토리지 인프라로 전환하면서, 2년간 7,500만 달러(약 1,000억 원)를 절감했습니다. Basecamp는 클라우드 비용이 연간 약 320만 달러에 달하자, 2022년 자체 서버와 코로케이션으로 전환하며 연간 80~90만 달러 수준으로 줄여, 5년 기준 700만~1,000만 달러 절감을 예상했습니다. 37signals는 이를 "클라우드 탈출(Cloud Exit)"이라 부르며, 중소기업들에게 온프레미스 회귀를 권장하고 있습니다.
물론 모든 기업이 Dropbox나 Basecamp처럼 할 수는 없습니다. 수십 명의 인프라 엔지니어와 데이터센터 운영 노하우가 필요합니다. 하지만 일부 연구와 사례에서는, 일정 규모 이상의 고정 워크로드에 대해 온프레미스가 클라우드보다 30-50% 저렴하다는 분석도 있습니다.
예측 가능한 워크로드의 최적지
앞서 분류한 Steady-State 워크로드들 – ERP, 데이터베이스, 파일 서버 – 은 온프레미스가 적합합니다.
리소스 사용량이 일정하면, 클라우드의 탄력성은 오히려 과잉입니다. 쓰지도 않을 유연성에 프리미엄을 내는 것입니다.
예를 들어, 매일 밤 정확히 100 vCPU를 3시간 동안 쓰는 배치 작업이 있다고 해봅시다. 클라우드 온디맨드 가격으로는 연간 약 2만 달러입니다. 3년 예약 인스턴스로는 7천 달러입니다. 온프레미스 서버를 직접 구매하면? 서버 1대에 5천 달러, 5년 감가상각으로 연간 1천 달러입니다. 전기/냉각/네트워크 비용 포함해도 연간 2천 달러 정도입니다.
물론 운영 인력이 필요하지만, 어차피 다른 온프레미스 시스템을 운영하는 팀이 있다면 추가 비용은 크지 않습니다.
하이브리드의 현실적 형태
그래서 많은 기업이 도달하는 결론은 이것입니다.
- 온프레미스: Steady-State, Predictable 워크로드, Highly Sensitive 데이터
- 퍼블릭 클라우드: Highly Variable, 신규 프로젝트, AI/ML 실험
- 엣지: Ultra-Low Latency, IoT, 실시간 처리
이것이 진정한 하이브리드입니다. 어쩔 수 없는 타협이 아니라, 각 워크로드를 최적의 위치에 배치한 결과입니다.
이상적 시나리오
멀티클라우드의 비전은 매력적입니다. AWS, Azure, GCP를 동시에 쓰면서, 각 클라우드의 장점만 취합니다. AWS의 EC2, Azure의 AI 서비스, Google의 BigQuery. 한 클라우드가 다운되면 다른 클라우드로 자동 페일오버됩니다. 가격 협상력도 생깁니다.
현실적 어려움
하지만 현실은 훨씬 복잡합니다.
첫째, 운영 복잡도가 기하급수적으로 증가합니다.
IAM 정책, 네트워크 구성, 모니터링, 로깅이 모두 다릅니다. 엔지니어는 세 개의 서로 다른 콘솔, CLI, API를 배워야 합니다. 자동화 스크립트는 세 벌로 작성해야 합니다.
둘째, 데이터 이동 비용이 치명적입니다.
AWS에 있는 1TB 데이터를 Azure로 옮기는 데 90달러가 듭니다. 매일 동기화하면? 매달 2,700달러입니다. 멀티클라우드의 실시간 데이터 복제는 경제성이 나오지 않습니다.
셋째, 벤더 특화 서비스를 쓰는 순간 락인됩니다.
AWS Lambda로 서버리스를 구현하면, Azure Functions로 옮기는 것은 거의 전면 재작성입니다. BigQuery로 데이터 웨어하우스를 만들면, Redshift나 Synapse로 마이그레이션하는 데 6개월-1년이 걸립니다.
넷째, 자동 페일오버는 환상입니다.
클라우드 간 자동 페일오버를 구현하려면, 데이터 동기화, 상태 관리, DNS 전환, 애플리케이션 설정을 모두 자동화해야 합니다. 이것을 제대로 하는 기업은 극소수입니다. 대부분은 "수동 페일오버"입니다. 즉, 한 클라우드가 다운되면 팀이 긴급 소집되어 몇 시간 동안 다른 클라우드로 전환 작업을 합니다.
실용적 멀티클라우드
그래서 현실적인 멀티클라우드는 이렇습니다.
- 주 클라우드 + 보조 클라우드: 80%는 AWS에서 돌리고, 나머지 20%는 Azure나 GCP의 특화 서비스를 씁니다. Azure의 AD 통합, Google의 GKE Auto-pilot 같은 것들입니다.
- 워크로드별 분리: 프로덕션은 AWS, 개발/테스트는 Azure (더 저렴). 또는 글로벌 서비스는 AWS, 중국 서비스는 Alibaba Cloud (중국 규제).
- 지역별 분리: 유럽은 Azure (GDPR 인증), 아시아는 AWS (리전 많음), 남미는 Google Cloud (좋은 가격).
- 재해 복구 전용: 평소에는 AWS만 쓰다가, 재해 복구 백업만 Azure에 보관합니다. 실제 페일오버는 거의 일어나지 않지만, "만약의 경우"를 위한 보험입니다.
이것도 충분히 가치 있습니다. 완전한 멀티클라우드는 아니지만, 단일 클라우드 의존도는 줄입니다.
인프라를 전략적으로 분류하고, 분산 배치의 필연성을 이해했습니다. 그렇다면 클라우드 생태계 전체는 어떻게 재편되고 있을까요?
다음 화에서는 CSP, 고객, MSP, 벤더들의 역학 관계가 어떻게 변하고 있는지, 그리고 "전략 없는 기술"이 왜 위험한지를 다루겠습니다.