AWS SRE의 GCP 첫날: 7가지 놀라운 차이점

Source: Dev.to

Introduction

저는 여러 회사에서 10년 넘게 AWS를 사용해 대규모 프로덕션 인프라를 구축하고 운영해 왔습니다. 오랫동안 GCP 이야기를 들어왔지만, 진지하게 살펴본 적은 없었습니다—지난 주말까지는요.

개인 ML 프로젝트를 GCP에서 시작해 보면서 “얼마나 다를까?”라고 생각했습니다. 4시간 뒤, 저는 정말 감탄했습니다. 기능 자체도 좋았지만, GCP가 클라우드 인프라를 근본적으로 다르게 설계했다는 점이 인상적이었습니다.

솔직히 말씀드리자면, 지금 AWS를 되돌아보면 Perl과 Jenkins를 떠올리게 됩니다. 현대 솔루션이 제공하는 모든 기능을 가지고 있지만, 수년간 쌓인 우회 방법을 통해서만 구현됩니다. AWS는 확실히 동작합니다. 하지만 GCP는 뒤돌아보며 설계된 느낌이 듭니다.

제가 가장 놀랐던 7가지 차이점을 공유합니다.

1. Organization Structure: Finally, Hierarchies That Make Sense

In AWS:
Organizations, OUs (Organizational Units), and Control Tower는 사후에 추가된 기능—AWS가 출시된 뒤 몇 년 지나서 도입된 일종의 부가 기능입니다. 다중 계정 구조를 관리하는 것이, 원래 설계되지 않은 시스템에 조직 개념을 뒤늦게 끼워 맞추는 느낌입니다.

In GCP:
계층 구조가 자연스럽고 직관적입니다: Organization → Folders → Projects. 마치 로컬 파일 시스템을 정리하는 것과 같습니다. 팀별로 프로젝트를 묶고 싶나요? 폴더를 만들면 됩니다. dev/staging/prod를 구분하고 싶나요? 하위 폴더를 사용하세요. 어느 수준에서든 정책을 적용하고 싶나요? 바로 적용하면 됩니다.

Why it matters:
여러 프로젝트에 대한 인프라 템플릿을 만들 때, GCP의 구조는 뇌가 실제로 생각하는 방식대로 리소스를 조직하고 관리할 수 있게 해줍니다. AWS에서는 계정 모델과 끊임없이 싸워야 합니다.

2. Encryption Keys: Default Keys That Actually Work Across Projects

In AWS:
KMS 기본 키는 계정 간에 공유할 수 없습니다. 교차 계정 암호화를 원한다면 복잡한 교차 계정 IAM 정책을 가진 고객 관리 키(CMK)를 사용해야 합니다. 보안 구멍이 생기거나 스스로 잠기는 상황이 쉽게 발생합니다. 권한 모델이 난잡합니다.

In GCP:
기본 암호화 키는 조직 내 프로젝트 간에 원활하게 작동합니다. 커스텀 키가 필요하면 권한 모델이 직관적이고 유지 관리가 쉽습니다. AWS에서 요구하는 IAM 정책 체조 없이 접근 권한을 부여할 수 있습니다.

Real impact:
AWS 시절, KMS 암호화가 적용된 S3 버킷을 계정 간에 접근하려다 “Access Denied” 오류를 디버깅하느라 부끄러운 만큼 많은 시간을 보냈습니다. GCP에서는 이런 문제 자체가 사라집니다.

3. Cross‑Zone Data Transfer: FREE

In AWS:
AZ(가용 영역) 간 데이터 전송 비용은 방향당 $0.01/GB이며, 왕복 트래픽이면 실질적으로 $0.02/GB가 됩니다. 고처리량 애플리케이션에서는 금방 큰 비용이 됩니다.

In GCP:
같은 리전 내 존 간 데이터 전송은 완전히 무료입니다. 제로. 아무것도 없습니다.

Why this is huge:

• 리전 기반 Kubernetes 클러스터? 존 간 pod‑to‑pod 통신에 비용이 없습니다.
• 다중 AZ 데이터베이스? 복제 트래픽이 무료입니다.
• 고가용성 아키텍처를 구축해도 추가 비용이 들지 않습니다.

이 차이만으로도 데이터 집약적인 워크로드에서 매달 수천 달러를 절감할 수 있습니다.

4. Network Resources: Shared VPC Changes Everything

In AWS:
VPC는 개별 계정에 강하게 묶여 있습니다. 중앙 집중식 네트워크 관리를 원한다면 Transit Gateway($36/월 기본 요금 + 데이터 전송 요금), VPC 피어링, 혹은 복잡한 PrivateLink 구성을 사용해야 합니다. 각각의 접근 방식마다 트레이드‑오프가 존재합니다.

In GCP:
Shared VPC를 사용하면 네트워크 리소스를 하나의 프로젝트(예: SRE/플랫폼 프로젝트)에서 생성하고 다른 프로젝트와 공유할 수 있습니다. 애플리케이션 프로젝트의 개발자는 기본 네트워크 구성을 전혀 보지도, 관리하지도 않습니다.

The paradigm shift:

• 모든 네트워킹을 전용 “관리” 프로젝트에서 담당합니다.
• 개발자에게는 애플리케이션 프로젝트에 대한 접근 권한만 부여합니다.
• 개발자는 VPC, 서브넷, 방화벽 규칙을 건드리지 않고 배포합니다.
• 중앙 집중식 네트워크 정책 및 보안 제어가 가능합니다.

AWS에서는 이 수준의 분리를 구현하려면 훨씬 더 복잡한 아키텍처가 필요합니다.

5. Security Groups → Firewall Rules: Making Sense Again

In AWS:
Security Groups는… 괜찮습니다. 하지만 이름이 혼란스럽습니다(실제로는 “그룹”이 아니고), 인스턴스/ENI당 부착 모델은 규모가 커지면 복잡해집니다.

In GCP:
Firewall Rules라고 부릅니다. VPC 수준에서 동작합니다. 태그, 서비스 계정, IP 범위 등으로 리소스를 타깃팅할 수 있습니다. 전통적인 시스템 관리 경험이 있다면 모델이 바로 이해됩니다.

Why I prefer this:
클라우드 이전에 방화벽을 관리하던 사람으로서, GCP의 방화벽 규칙은 직관적입니다. 네트워크 수준에서 규칙을 적용하고, 태그로 특정 워크로드를 타깃팅합니다. 네트워크 보안을 자연스럽게 생각하는 방식과 일치합니다.

6. Global Load Balancer: A Feature AWS Doesn’t Really Have

In AWS:
리전 기반 로드밸런서(ALB, NLB)와 Route 53 DNS 라우팅만 제공합니다. 진정한 글로벌 로드밸런싱을 원한다면 헬스 체크, 장애 조치, 복잡한 DNS 구성을 직접 설계해야 합니다.

In GCP:
Global HTTP(S) Load Balancer는 다음을 제공합니다:

• 전 세계 어디서든 가장 가까운 정상 백엔드로 라우팅되는 단일 anycast IP.
• 전 세계 150개 이상의 엣지 위치에서 자동 SSL 종료.
• Cloud CDN와 원활한 통합.
• Cloud Armor를 통한 내장 DDoS 방어.

Real‑world impact:

도쿄 사용자가 아이오와에 호스팅된 애플리케이션에 접속한다 가정해봅시다:

• 글로벌 LB 없이: 아이오와에서 SSL 핸드셰이크(≈150 ms 지연) → 총 연결 시간 ≈450 ms.
• 글로벌 LB 사용: 도쿄에서 SSL 핸드셰이크(≈5 ms 지연) → 총 연결 시간 ≈50 ms.

글로벌 애플리케이션에 있어서는 게임 체인저입니다. Global LB + Cloud CDN 조합은 정적 콘텐츠뿐 아니라 동적 콘텐츠에도 CDN 수준의 성능을 제공합니다.

7. Terraform + CI/CD: Finally, A Clear Pattern

In AWS:

• Terraform용 IAM 역할 생성.
• S3 백엔드(state) 선택(어느 계정?).
• DynamoDB를 사용해 상태 잠금 구현.
• 다중 계정 배포를 위한 교차 계정 assume‑role 체인 설정.
• 모든 과정을 관리하는 커스텀 스크립트 작성.

솔루션은 동작하지만 조립식 느낌이 강합니다.

In GCP:

• 관리 프로젝트 생성.
• Storage API 활성화.
• Terraform 상태를 위한 GCS 버킷 생성(버전 관리와 잠금이 기본 제공).
• 서비스 계정 위임 사용.

그게 전부입니다. 더 깔끔하고 직관적이며, 특히 새로운 팀원을 온보딩할 때 이해하기 쉽습니다.

Cost Comparison

4시간 탐색 후, 평가한 서비스들의 가격을 비교했습니다. GCP가 전반적으로 더 저렴합니다:

• Compute 인스턴스: 동일 사양 대비 10–20 % 저렴.
• 스토리지: Regional GCS ($0.020/GB) vs Regional S3 ($0.023/GB).
• Cross‑zone 전송: FREE vs $0.02/GB.
• Kubernetes: GKE 컨트롤 플레인은 무료(15 000 pod 이하); EKS는 $0.10 /시간($73 /월 per cluster) 부과.

특히 다중 클러스터나 고처리량 워크로드에서는 절감 효과가 크게 나타납니다.

The Elephant in the Room: Why Are Companies Still on AWS?

GCP가 더 저렴하고 직관적이며 현대 아키텍처에 맞는 기능을 제공한다면—왜 AWS가 시장을 장악하고 있을까요?

답은 2025년에 여전히 Perl 코드베이스와 Jenkins 파이프라인을 운영하는 기업과 같은 이유입니다: 관성, 기존 투자, 조직적 모멘텀.

AWS는:

• 선점자 이점: 2006년 출시; 대부분의 기업이 GCP가 실현 가능해지기 전에 AWS 위에 기반을 두었습니다.
• 생태계 락인: 수많은 서드파티 도구, 통합, Marketplace 솔루션이 존재합니다.
• 엔터프라이즈 영업력: 15년 이상 구축된 깊은 관계망.
• 인재 풀: AWS 경험을 가진 엔지니어가 더 많습니다.
• 서비스 폭: 전체 서비스 수에서는 아직 AWS가 앞서지만 GCP도 빠르게 따라잡고 있습니다.

AWS가 나쁜 것은 아닙니다. 단지 관성 때문에 계속해서 사용되고 있을 뿐입니다.