2006년 AWS가 EC2를 출시했을 때, 클라우드는 단순했습니다.
가상 서버를 빌려 쓰는 것, 그게 전부였습니다. API 몇 개만 호출하면 서버가 뜨고, 시간당 몇 센트를 내면 됐습니다. 개발자들은 흥분했습니다. 드디어 하드웨어 구매 없이, 데이터센터 없이, 몇 분 만에 서비스를 시작할 수 있게 됐으니까요.
2024년이 된 지금, AWS는 200개가 넘는 서비스를 제공합니다. Azure와 Google Cloud도 비슷합니다. EC2만 해도 수백 가지 인스턴스 타입이 있고, S3는 8가지 스토리지 클래스가 있으며, IAM 정책은 수천 줄의 JSON으로 작성됩니다. 클라우드는 더 이상 단순하지 않습니다.
이 책에서 우리는 클라우드가 무엇인지, 어떻게 작동하는지를 다뤘습니다. 컴퓨팅, 스토리지, 네트워킹의 기초부터, 서버리스, 컨테이너, 매니지드 서비스까지. 클라우드를 이해하고 사용하는 데 필요한 기본 지식이었습니다.
그리고 우리는 좀 더 깊이 들어갔습니다. 클라우드가 왜 복잡한지, 누가 책임져야 하는지, 그리고 앞으로 어디로 가는지를 다뤘습니다. 공유 책임 모델의 애매한 경계, 예측 불가능한 비용, 락인의 현실, CSP의 전략 변화, 생태계의 재편. 마케팅 슬라이드에는 나오지 않는, 실제 운영에서 마주치는 이야기들이었습니다.
그 과정에서 우리가 발견한 것은 이것입니다.
클라우드는 해결책이 아니라, 선택지입니다.
온프레미스가 모든 문제의 원인이 아니었던 것처럼, 클라우드도 모든 문제의 해결책이 아닙니다.
클라우드는 확장성, 민첩성, 글로벌 도달성에서는 탁월합니다.
스타트업이 몇 분 만에 글로벌 서비스를 시작할 수 있고, 트래픽이 급증해도 Auto Scaling으로 자동 대응할 수 있으며, 전 세계 수십 개 리전에서 낮은 지연 시간을 제공할 수 있습니다. 이것은 온프레미스로는 불가능한 일입니다.
하지만 예측 가능한 비용, 완전한 통제, 특정 규제 준수에서는 온프레미스가 더 나을 수 있습니다.
Dropbox가 S3에서 자체 스토리지로 전환해서 2년간 7,500만 달러를 절감한 것은 실패가 아닙니다. 성숙함입니다. 자신들의 워크로드 특성을 이해하고, 최적의 선택을 한 것입니다.
Dropbox의 스토리지는 예측 가능합니다. 사용자가 폭발적으로 늘지 않는 한, 용량은 꾸준히 증가합니다. 트래픽 패턴도 안정적입니다. 이런 워크로드는 클라우드의 탄력성이 필요 없습니다. 오히려 고정 비용으로 전환하는 것이 경제적입니다.
37signals의 Basecamp도 마찬가지입니다. 연간 320만 달러의 AWS 비용을 80-90만 달러로 줄였습니다. Netflix도 일부 워크로드는 자체 데이터센터(Open Connect)로 돌립니다. CDN 트래픽은 예측 가능하고 대역폭 비용이 크니, 직접 운영하는 것이 효율적입니다.
클라우드 퍼스트(Cloud First)는 끝났습니다. 이제는 클라우드 스마트(Cloud Smart)입니다.
무조건 클라우드가 아니라, 워크로드 특성에 맞는 선택입니다.
클라우드가 복잡한 것은 CSP의 잘못만이 아닙니다. 현대 애플리케이션 자체가 복잡하기 때문입니다.
10년 전에는 웹 서버, 데이터베이스, 캐시 정도면 충분했습니다. 지금은 마이크로서비스, 컨테이너 오케스트레이션, 서버리스 함수, 메시지 큐, 이벤트 스트림, AI/ML 파이프라인, 실시간 분석이 모두 함께 돌아가야 합니다.
사용자는 더 빠른 응답을 원합니다.
검색은 100ms 안에 결과를 보여줘야 하고, 추천은 실시간으로 바뀌어야 하며, 결제는 3초 안에 완료되어야 합니다. 이것을 구현하려면 CDN, 캐싱, 비동기 처리, 분산 데이터베이스가 필요합니다. 복잡도가 올라갑니다.
규제도 복잡도를 더합니다.
EU 사용자 데이터는 EU에 있어야 하고, 금융 거래 로그는 7년 보관해야 하며, 암호화 키는 고객이 관리할 수 있어야 합니다. 각 국가, 각 산업마다 다른 요구사항이 있습니다. 글로벌 서비스를 하려면 이 모든 것을 만족시켜야 합니다.
복잡도를 없앨 수는 없습니다. 다만 관리할 수 있습니다.
좋은 아키텍처는 복잡도를 적절히 분산시킵니다. 모든 로직을 하나의 거대한 모놀리식에 넣으면 이해하기 어렵고, 모든 것을 수백 개의 마이크로서비스로 쪼개면 운영하기 어렵습니다. 적절한 경계를 찾는 것이 아키텍트의 역할입니다.
명확한 책임 분담도 복잡도를 관리하는 방법입니다.
누가 배포하고, 누가 모니터링하고, 누가 장애에 대응하는지가 명확하면 복잡한 시스템도 돌아갑니다. 반대로 책임이 애매하면 간단한 시스템도 혼란스럽습니다.
자동화는 필수입니다.
수동으로 100개 서버를 관리할 수는 있지만, 1,000개는 불가능합니다. Infrastructure as Code로 인프라를 코드화하고, CI/CD로 배포를 자동화하고, 모니터링으로 문제를 조기 발견합니다. 자동화는 복잡도를 줄이지 않지만, 관리 가능하게 만듭니다.
그리고 가장 중요한 것은 불필요한 복잡도를 추가하지 않는 것입니다.
모든 애플리케이션이 마이크로서비스일 필요는 없습니다. 모든 것을 Kubernetes에서 돌릴 필요도 없습니다. 단순함이 가능하다면, 단순함을 선택하세요. 복잡도는 필요할 때만 받아들이세요.
공유 책임 모델은 이론적으로는 명확합니다.
CSP는 "클라우드의(of the cloud)" 보안을, 고객은 "클라우드에서의(in the cloud)" 보안을 책임집니다.
인프라는 CSP, 애플리케이션은 고객. 명확한 선이 그어져 있습니다.
하지만 현실에서는 경계가 흐릿합니다.
S3 버킷이 public으로 설정되어 데이터가 유출됐습니다. 이것은 누구 책임입니까? 기술적으로는 고객 실수입니다. S3 버킷을 public으로 만든 것은 고객이니까요. 하지만 AWS는 과거에 기본값을 public으로 설정했고, 경고도 충분하지 않았습니다. 100% 고객 책임이라고 하기 어렵습니다.
RDS 데이터베이스가 느려졌습니다. CPU는 50%인데 쿼리가 타임아웃됩니다. 이것은 누구 책임입니까? AWS가 제공하는 하드웨어 문제일 수 있고, 고객이 작성한 비효율적인 쿼리일 수도 있으며, 둘 다일 수도 있습니다. 디버깅하려면 AWS 지원팀과 고객의 개발팀이 협력해야 합니다.
중요한 것은 책임을 명확히 정의하고, 문서화하고, 지속적으로 검증하는 것입니다.
내부 팀 간에도, CSP와의 관계에서도 마찬가지입니다.
"누가 이 서비스를 모니터링하는가?" "장애가 나면 누가 호출받는가?" "비용이 예산을 초과하면 누가 책임지는가?" "보안 패치는 누가 적용하는가?" 이런 질문에 명확한 답이 있어야 합니다. 그리고 정기적으로 검증해야 합니다. 팀 구조가 바뀌고, 서비스가 추가되고, 책임자가 바뀌면 문서도 업데이트되어야 합니다.
공유 책임은 책임 회피가 아닙니다. 오히려 더 명확한 책임 정의가 필요합니다.
클라우드의 다음 10년은 이렇게 전개될 것입니다.
하이브리드가 표준이 됩니다.
2030년이 되면, "클라우드냐 온프레미스냐"라는 질문은 의미가 없어질 것입니다. 모든 기업이 둘 다 쓰고 있을 테니까요. 중요한 것은 각 워크로드를 어디에 배치하느냐입니다.
금융 코어 시스템은 온프레미스에, 고객 포털은 클라우드에, AI 모델 훈련은 CSP의 GPU 클러스터에, 실시간 추론은 엣지에. 이것이 당연한 구조가 됩니다.
엣지가 폭발적으로 성장합니다.
AI가 확산되면서, 실시간 추론은 엣지에서 일어날 것입니다.
자율주행차는 클라우드에 연결이 끊겨도 주행해야 합니다. 스마트 팩토리의 로봇은 100ms 지연을 견딜 수 없습니다. 원격 의료의 실시간 진단 보조는 환자 앞에서 즉시 작동해야 합니다. AR/VR 기기는 20ms 이상 지연되면 멀미를 유발합니다.
클라우드는 훈련과 데이터 집계를 담당하고, 엣지는 추론과 실시간 처리를 담당할 것입니다.
수백만 개의 엣지 디바이스가 로컬에서 판단하고, 학습 데이터와 인사이트만 클라우드로 보냅니다.
클라우드는 주기적으로 개선된 모델을 엣지로 배포합니다. 이것이 AI 시대의 아키텍처입니다.
주권 클라우드(Sovereign Cloud)가 부상합니다.
각국의 데이터 주권 요구가 강해지면서, 국가별 독립적인 클라우드 인프라가 중요해질 것입니다.
EU의 Gaia-X는 유럽 데이터를 유럽에서 처리하려는 시도입니다. 중국은 이미 자체 클라우드 생태계를 구축했습니다. 한국도 국가 클라우드 전략을 추진하고 있습니다.
글로벌 하이퍼스케일러도 각국의 규제에 맞춘 별도 리전을 운영할 것입니다.
AWS GovCloud처럼 정부 전용 리전, 금융 전용 리전, 의료 전용 리전이 늘어날 것입니다. 물리적으로는 같은 데이터센터에 있어도, 논리적으로는 완전히 분리되고, 해당 국가의 법만 적용되는 구조입니다.
AI가 클라우드를 재정의합니다.
2030년의 클라우드는 2020년의 클라우드와 완전히 다를 것입니다.
단순히 컴퓨팅 자원을 빌려주는 것이 아니라, AI 모델을 서빙하고, 에이전트를 실행하고, 지능형 워크플로우를 관리하는 플랫폼이 될 것입니다.
전통적인 VM과 컨테이너는 여전히 존재하지만, 비중은 줄어들 것입니다.
신규 워크로드의 대부분은 AI 기반이 될 것입니다.
"서버를 빌려서 코드를 돌린다"가 아니라, "AI 에이전트를 배포해서 업무를 자동화한다"가 기본이 됩니다.
클라우드는 인프라 레이어에서 인텔리전스 레이어로 진화합니다.
다음은 기술 리더와 의사결정자들에게 드리는 제안입니다. 다섯 가지입니다.
첫째, 워크로드를 이해하세요.
모든 것을 하나의 전략으로 다룰 수 없습니다. 각 워크로드의 특성을 파악해야 합니다.
얼마나 중요한가? 결제 시스템이 다운되면 회사가 멈추지만, 내부 위키가 다운되어도 업무는 계속됩니다. 데이터가 얼마나 민감한가? 의료 기록은 엄격한 규제를 받지만, 마케팅 이미지는 어디에 두든 상관없습니다.
트래픽이 얼마나 가변적인가? 이커머스는 블랙프라이데이에 100배 트래픽이 몰리지만, ERP는 항상 일정합니다. 지연 시간이 얼마나 중요한가? 자율주행은 10ms가 생명이지만, 배치 작업은 몇 초 늦어도 괜찮습니다.
이 네 가지 축으로 워크로드를 분류하면, 어디에 배치해야 할지 자연스럽게 보입니다.
Mission-critical하고 민감한 데이터를 다루는 시스템은 온프레미스나 전용 인프라로. 트래픽이 가변적이고 지연에 덜 민감한 시스템은 퍼블릭 클라우드로. 실시간 처리가 필요한 시스템은 엣지로.
워크로드 특성이 전략을 결정합니다.
둘째, 전략을 먼저 세우고 기술은 나중에 선택하세요.
기술 트렌드를 쫓지 마세요. 비즈니스 문제를 먼저 정의하세요.
우리의 고객은 무엇을 원하는가? 우리의 경쟁력은 무엇인가? 우리가 해결해야 할 가장 큰 문제는 무엇인가?
그 답이 명확해지면, 기술은 자연스럽게 따라옵니다. AI를 도입하는 것이 목표가 아닙니다. 고객 만족도를 높이는 것이 목표이고, AI는 그것을 달성하는 수단일 뿐입니다. Kubernetes를 쓰는 것이 목표가 아닙니다. 배포 속도를 높이는 것이 목표이고, Kubernetes는 그것을 가능하게 하는 도구일 뿐입니다.
"요즘 다들 쓰니까"는 기술 도입의 이유가 될 수 없습니다.
명확한 비즈니스 문제와 측정 가능한 목표가 있어야 합니다. 그래야 성공과 실패를 판단할 수 있고, 방향을 조정할 수 있습니다.
셋째, 비용을 투명하게 만드세요.
클라우드 비용은 블랙박스가 되기 쉽습니다. 매달 청구서만 보고 놀라는 것이 아니라, 사전에 예측하고 제어할 수 있어야 합니다.
각 팀, 각 프로젝트, 각 서비스의 비용을 태깅하세요.
태그가 없으면 누가 얼마를 쓰는지 알 수 없습니다. "지난달 EC2 비용이 10만 달러인데, 어느 팀이 쓴 건가요?"라는 질문에 답할 수 없으면, 최적화도 불가능합니다.
예산을 설정하고 알람을 걸어두세요.
AWS Budget, Azure Cost Management의 알람 기능을 쓰세요.
예산의 80%를 넘으면 알람, 100%를 넘으면 자동 승인 요청. 이렇게 해야 비용이 통제 불능이 되는 것을 막을 수 있습니다.
정기적으로 리소스를 리뷰하고, 쓰지 않는 것은 정리하세요.
테스트용으로 만든 인스턴스가 6개월째 돌아가고 있지 않습니까? 프로젝트가 끝난 S3 버킷이 여전히 과금되고 있지 않습니까? 매월 또는 매 분기마다 리소스 리뷰 시간을 가지세요.
Reserved Instance, Savings Plan을 적극 활용하세요.
예측 가능한 워크로드는 3년 약정으로 최대 70%까지 절감할 수 있습니다. 처음에는 온디맨드로 시작해서 사용 패턴을 파악하고, 안정화되면 예약으로 전환하세요. FinOps는 선택이 아니라 필수입니다.
넷째, 팀을 키우세요. 클라우드는 결국 사람이 운영합니다.
최신 기술을 도입해도, 그것을 이해하고 다룰 수 있는 팀이 없으면 소용없습니다.
지속적인 교육에 투자하세요. 온라인 강의, 자격증 준비, 컨퍼런스 참석을 지원하세요. AWS Certified Solutions Architect, Azure Administrator, Kubernetes CKAD 같은 자격증은 단순한 종이가 아닙니다. 그 과정에서 체계적으로 배우고, 검증된 지식을 얻습니다.
실험할 수 있는 환경을 제공하세요.
샌드박스 계정을 만들어서 자유롭게 테스트할 수 있게 하세요. 실수해도 괜찮습니다. 프로덕션이 아니니까요. 실패에서 배우는 것이 가장 빠른 학습입니다.
외부 전문가의 도움을 받는 것을 부끄러워하지 마세요.
MSP, 컨설턴트, 프리랜서. 모든 것을 내부에서 할 필요는 없습니다. 전문가는 수백 개 프로젝트의 경험이 있습니다. 그들의 실패와 성공을 빌려 쓸 수 있습니다. 특히 초기 아키텍처 설계나 마이그레이션 같은 중요한 단계에서는 전문가의 리뷰가 나중에 발생할 수 있는 큰 문제를 예방합니다.
다섯째, 락인을 관리하세요.
락인을 완전히 피할 수는 없습니다. 하지만 관리할 수는 있습니다.
핵심 비즈니스 로직은 플랫폼 독립적으로 작성하세요.
도메인 로직을 AWS Lambda에 직접 작성하지 말고, 별도 라이브러리로 분리하세요. 그러면 나중에 Azure Functions로 옮기거나 EC2에서 돌릴 때 비즈니스 로직은 그대로 재사용할 수 있습니다.
CSP 특화 서비스를 쓸 때는 마이그레이션 비용을 계산해두세요.
DynamoDB를 쓰면 얼마나 편한지가 아니라, 나중에 다른 데이터베이스로 옮기는 데 얼마나 걸릴지도 고려하세요. 편의성과 이동성은 트레이드오프입니다. 이것을 알고 선택하는 것과 모르고 선택하는 것은 다릅니다.
가능하면 오픈소스나 멀티클라우드 도구를 우선하세요.
Kubernetes, Terraform, PostgreSQL처럼 플랫폼 중립적인 도구는 이동 비용을 낮춥니다. AWS ECS보다 Kubernetes가 더 복잡하지만, 나중에 GKE나 AKS로 옮길 수 있다는 장점이 있습니다.
정기적으로 대안을 검토하세요.
실제로 옮기지 않더라도, 옮길 수 있다는 것을 아는 것이 중요합니다. 1년에 한 번, 현재 아키텍처를 다른 클라우드로 옮기려면 무엇이 필요한지, 얼마나 걸릴지, 얼마가 드는지 계산해보세요. 그것이 협상 테이블에서의 카드가 됩니다.
락인의 위험은 기술적 의존보다 협상력 상실입니다. 언제든 떠날 수 있다는 옵션이 있어야, 좋은 조건을 받을 수 있습니다.
클라우드는 마법이 아닙니다. 클라우드는 도구입니다. 좋은 도구이지만, 완벽한 도구는 아닙니다.
온프레미스 시대에도 성공한 회사가 있었고, 실패한 회사가 있었습니다. 인프라가 성공을 결정하지 않았습니다. 비즈니스 모델, 실행력, 고객 가치가 결정했습니다. 클라우드 시대에도 마찬가지입니다.
중요한 것은 기술이 아니라, 그 기술을 어떻게 사용하느냐입니다.
이 책을 통해 여러분이 얻어갈 수 있는 것은 세 가지입니다.
첫째는 클라우드에 대한 현실적인 이해입니다.
장밋빛 마케팅이 아니라, 실제 운영에서 마주치는 복잡도, 비용, 책임의 문제들. 공유 책임 모델의 애매한 경계, 예측 불가능한 비용의 원인, 락인의 현실과 대응 방법. 이것을 알고 시작하는 것과 모르고 시작하는 것은 완전히 다릅니다.
둘째는 의사결정을 위한 프레임워크입니다.
무엇을 클라우드에 올리고, 무엇을 온프레미스에 둘지. 어떻게 책임을 나누고, 어떻게 비용을 관리할지. 워크로드 분류 방법, 전략적 사고의 필요성, 균형 잡힌 기술 도입 방법 같은 프레임워크는 개별 기술이 변해도 계속 유효합니다.
셋째는 미래를 준비하는 방향성입니다.
클라우드가 어디로 가고 있는지, 우리는 무엇을 준비해야 하는지. 하이브리드와 엣지의 부상, AI의 영향, 주권 클라우드의 중요성. 5년 후, 10년 후를 내다보고 지금 무엇을 준비해야 하는지.
클라우드는 여전히 진화하고 있습니다. 10년 전의 클라우드와 지금의 클라우드가 다른 것처럼, 10년 후의 클라우드도 지금과 다를 것입니다.
비즈니스 가치를 만드는 것, 고객에게 더 나은 서비스를 제공하는 것 그리고 기술은 그것을 위한 수단일 뿐이라는 것이라는 근본 원칙은 변하지 않습니다.
이 책이 여러분의 클라우드 여정에 작은 도움이 되기 바랍니다.
복잡한 의사결정을 내릴 때, 막막한 문제를 마주했을 때, 이 책의 어느 챕터가 떠올라서 힌트를 주기 바랍니다.
클라우드는 목적지가 아니라 여정입니다. 완벽한 아키텍처는 없습니다. 다만 지금 상황에서 최선의 선택이 있을 뿐입니다. 그 선택을 현명하게 하시기 바랍니다.
읽어주셔서 감사합니다.
6개월에 걸쳐 연재한 Cloud Computing: Business Minimum을 이제 마무리합니다.
제가 쓴 초고에 있는 글을 요약 정리해서 브런치북에 올리는데 무려 6개월이 걸렸습니다.
물론 솔루션 소개 같은 기술적인 부분은 아예 다루지도 않았습니다.
기술은 너무 빨리 바뀌기도 하고 솔루션 소개에 공감하는 독자분들도 극소수일테니까요.
아이러니한 건 6개월 전에 작성한 원고를 요약을 위해 다시 보면 이미 세상이 그 때와 바뀌었다는 사실을 깨닫고 다시 한 번 놀라기도 했습니다.
출판사에서 제가 쓴 이런 기술서 (사실 기술서가 아니고 기술경영서라고 생각합니다)의 출판을 꺼려하는 이유일 것입니다.
어쨌든 A4지 기준으로 390장을 쓴 노력을 묵혀두기 아까워 지식을 공유하는 차원에서 정리한 글이 2025년 연말에 드디어 브런치북으로나마 마무리되고 나니, 한편으로는 후련하고 또 한편으로는 좀 더 나은 방식으로 전달할 수 있지 않았을까 하는 생각에 아쉬움이 들기도 합니다.
클라우드 컴퓨팅 브런치북 관심있게 읽어주셔서 감사합니다.