CDL에서 디지털 트랜스포메이션 도메인은 전체의 약 10~15%를 차지합니다. 클라우드 전환 이유, 핵심 개념, 서비스 모델, 공유 책임이 핵심입니다.
왜 기업은 클라우드로 전환하는가
기업이 클라우드를 도입하는 이유를 이해하는 것은 CDL 시험의 출발점입니다. 마치 회사가 자체 발전기를 돌리는 대신 전력 회사에서 전기를 사 쓰는 것처럼, 클라우드는 IT 인프라를 서비스로 소비하는 방식으로 전환합니다.
비용 구조 변화: CapEx → OpEx
전통적인 IT 환경에서는 서버를 직접 구매해야 했습니다. 이를 자본 지출(CapEx, Capital Expenditure)이라고 합니다. 서버를 사면 일단 큰돈이 나가고, 수요가 줄어도 서버는 그대로 남아 있습니다. 클라우드로 전환하면 사용한 만큼만 비용을 내는 운영 지출(OpEx, Operational Expenditure) 방식으로 바뀝니다. 예를 들어, 쇼핑몰이 블랙프라이데이에만 서버를 10배로 늘렸다가 평소에는 줄이는 것이 가능합니다.
TCO(총소유비용) 절감
서버를 직접 운영하면 하드웨어 비용 외에도 전기료, 냉각 시스템, 데이터센터 임대, 네트워크 장비, 유지보수 인력 등 숨겨진 비용이 많습니다. 이를 총소유비용(TCO, Total Cost of Ownership)이라고 합니다. 클라우드는 이런 간접 비용을 대부분 Google이 흡수하므로 TCO가 크게 줄어듭니다.
글로벌 확장과 혁신 속도
예전에는 해외 시장에 진출하려면 현지에 데이터센터를 짓고 운영해야 했습니다. Google Cloud를 사용하면 전 세계에 퍼진 Google의 인프라를 그대로 활용해 몇 클릭만으로 글로벌 배포가 가능합니다. 또한 새로운 아이디어를 실험하는 데 드는 시간이 몇 달에서 몇 분으로 줄어들어 혁신 속도가 비약적으로 빨라집니다.
클라우드의 핵심 특성
클라우드를 클라우드답게 만드는 핵심 특성들이 있습니다. 시험에서는 이 용어들의 차이를 구별할 줄 알아야 합니다.
확장성(Scalability)과 탄력성(Elasticity)
확장성은 "필요할 때 리소스를 늘리거나 줄일 수 있는 능력"입니다. 탄력성은 확장성에 "자동화"가 더해진 개념으로, 수요 변화에 따라 시스템이 스스로 확장하거나 축소합니다. 마치 고무줄처럼 트래픽이 몰리면 늘어나고, 줄어들면 원래대로 돌아옵니다.
안정성(Reliability)과 가용성(Availability)
안정성은 시스템이 장애 상황에서도 계속 동작하는 능력입니다. Google Cloud는 전 세계에 여러 데이터센터를 운영하여 한 곳에 문제가 생겨도 다른 곳에서 서비스를 이어받을 수 있습니다.
민첩성(Agility)
클라우드에서는 새로운 서버를 클릭 몇 번으로 수분 내에 준비할 수 있습니다. 이렇게 빠르게 리소스를 프로비저닝하고 실험할 수 있는 능력을 민첩성이라고 합니다.
| 특성 | 핵심 의미 | 예시 | |------|----------|------| | 확장성 | 리소스 조절 능력 | 서버를 2대에서 20대로 늘리기 | | 탄력성 | 자동 확장/축소 | 트래픽 급증 시 자동으로 서버 추가 | | 안정성 | 장애에도 지속 동작 | 한 리전 장애 시 다른 리전으로 전환 | | 민첩성 | 빠른 프로비저닝 | 5분 만에 서버 20대 준비 |
클라우드 배포 모델
클라우드를 "어떤 방식으로 구축하느냐"에 따라 배포 모델이 나뉩니다. 각 모델은 서로 다른 수준의 제어권과 보안을 제공합니다.
퍼블릭 클라우드(Public Cloud)
Google Cloud, AWS, Azure처럼 클라우드 제공업체가 인프라를 소유하고 인터넷을 통해 여러 고객이 공유하는 방식입니다. 마치 아파트처럼 건물 관리는 관리자가 하고, 입주자는 각자의 공간만 씁니다. 초기 투자 없이 바로 시작할 수 있고, 사용한 만큼만 비용을 냅니다.
프라이빗 클라우드(Private Cloud)
한 조직 전용으로 운영되는 클라우드입니다. 물리적으로는 자사 데이터센터나 호스팅 제공업체에 있을 수 있지만, 해당 조직만 사용합니다. 완전한 제어권과 보안이 장점이지만, 초기 투자와 유지비가 많이 듭니다.
하이브리드 클라우드(Hybrid Cloud)
퍼블릭 클라우드와 프라이빗 클라우드를 연결해 함께 사용하는 방식입니다. 예를 들어, 민감한 고객 데이터는 자사 데이터센터(프라이빗)에 두고, 웹 서버나 개발 환경은 Google Cloud(퍼블릭)에서 운영하는 방식입니다. 유연성과 보안을 동시에 확보할 수 있습니다.
멀티 클라우드(Multi-cloud)
여러 퍼블릭 클라우드 제공업체를 동시에 사용하는 방식입니다. 예를 들어, 일부 워크로드는 Google Cloud에서, 일부는 AWS에서 운영합니다. 벤더 종속을 피하거나 각 클라우드의 장점을 활용할 때 유용합니다.
| 모델 | 소유권 | 특징 | 적합한 상황 | |------|--------|------|------------| | 퍼블릭 클라우드 | 클라우드 제공업체 | 낮은 초기 비용, 공유 인프라 | 스타트업, 빠른 확장 | | 프라이빗 클라우드 | 해당 조직 | 완전한 제어, 높은 보안 | 금융, 의료, 규제 산업 | | 하이브리드 클라우드 | 혼합 | 유연성 + 보안 | 기존 인프라 보유 + 클라우드 확장 | | 멀티 클라우드 | 여러 제공업체 | 벤더 종속 방지 | 특정 서비스 최적화 필요 |
Google Cloud 인프라: 리전과 존
Google Cloud의 물리적 인프라는 전 세계에 분산되어 있습니다. 이 구조를 이해하면 고가용성 설계의 기초가 됩니다.
리전(Region)은 독립적인 지리적 영역입니다. 예를 들어 는 서울 리전입니다. 각 리전은 물리적으로 분리되어 있어 한 리전에 재해가 발생해도 다른 리전은 영향을 받지 않습니다. 데이터 주권(특정 국가에 데이터를 보관해야 하는 규제)을 지키는 데도 중요합니다.
존(Zone)은 리전 내의 독립적인 데이터센터입니다. 서울 리전은 , , 처럼 여러 존으로 구성됩니다. 존 하나가 다운되어도 다른 존이 정상 동작합니다. 고가용성 애플리케이션은 여러 존에 걸쳐 배포합니다.
마치 국가(리전) 안에 도시(존)가 여러 개 있는 것과 같습니다. 더 큰 재해를 대비하려면 여러 리전에 배포합니다.
IaaS, PaaS, SaaS 서비스 모델
클라우드 서비스는 얼마나 많은 부분을 클라우드 제공업체가 관리하느냐에 따라 세 가지 모델로 나뉩니다. 이 차이를 이해하면 어떤 서비스를 언제 써야 하는지 자연스럽게 알게 됩니다.
마치 피자를 먹는 세 가지 방법과 같습니다. 집에서 직접 만들기(온프레미스), 재료만 배달시켜 직접 굽기(IaaS), 배달 피자 시키기(PaaS), 레스토랑에서 먹기(SaaS).
| 모델 | 고객 관리 영역 | Google 관리 영역 | Google Cloud 예시 | |------|--------------|----------------|----------------| | IaaS | OS, 미들웨어, 앱, 데이터 | 가상화, 서버, 스토리지, 네트워크 | Compute Engine | | PaaS | 애플리케이션 코드, 데이터 | OS, 런타임, 미들웨어, 인프라 전체 | App Engine, Cloud Run | | SaaS | 데이터, 접근 설정 | 나머지 모든 것 | Google Workspace |
IaaS(Infrastructure as a Service)는 가상 서버를 빌려 쓰는 방식입니다. Compute Engine이 대표적입니다. OS부터 직접 설치하고 관리해야 하므로 제어권이 가장 크지만 책임도 가장 큽니다. 기존 온프레미스 애플리케이션을 그대로 이전(Lift & Shift)할 때 자주 사용합니다.
PaaS(Platform as a Service)는 코드만 가져오면 나머지 인프라는 Google이 알아서 관리하는 방식입니다. App Engine이나 Cloud Run에 코드를 배포하면 서버 관리, OS 패치, 스케일링을 Google이 합니다. 개발자가 인프라 대신 비즈니스 로직에만 집중할 수 있습니다.
SaaS(Software as a Service)는 바로 가져다 쓰는 완성된 소프트웨어입니다. Google Workspace(Gmail, Docs, Sheets 등)가 대표적입니다. 설치도, 관리도 필요 없이 로그인만 하면 됩니다.
공유 책임 모델(Shared Responsibility Model)
클라우드에서 보안은 Google과 고객이 나눠서 책임집니다. 이것이 공유 책임 모델입니다. 아파트 비유로 설명하면, 건물 외벽과 엘리베이터 보안은 관리자(Google) 책임이고, 현관문 잠금과 귀중품 관리는 입주자(고객) 책임입니다.
Google이 항상 책임지는 영역: 데이터센터의 물리적 보안, 하드웨어 보안, 글로벌 네트워크 인프라, 기반 소프트웨어 보안
고객이 항상 책임지는 영역: 자신의 데이터, 사용자 접근 권한(IAM), 사용자 계정 및 인증 관리
서비스 모델에 따라 달라지는 영역:
IaaS를 사용하면 OS 보안, 미들웨어, 애플리케이션 보안까지 고객이 책임져야 합니다. PaaS로 올라오면 OS 보안은 Google이 담당하고 고객은 애플리케이션 코드와 데이터만 책임집니다. SaaS에서는 고객의 책임이 최소화됩니다.
| 책임 영역 | IaaS | PaaS | SaaS | |----------|------|------|------| | 데이터 | 고객 | 고객 | 고객 | | 애플리케이션 | 고객 | 고객 | Google | | OS | 고객 | Google | Google | | 가상화 | Google | Google | Google | | 물리 보안 | Google | Google | Google |
즉, IaaS → PaaS → SaaS로 갈수록 고객의 관리 부담이 줄어들고, Google의 책임이 늘어납니다.
시험 핵심 정리
"서버 구매 대신 사용한 만큼 요금 지불" -- CapEx → OpEx 전환
"하드웨어, 전기, 인력 포함 총비용" -- TCO(총소유비용)
"수요에 따라 자동으로 확장/축소" -- 탄력성(Elasticity)