[GCP] AWS와 GCP의 차이점

hyoin·2025년 12월 21일

AWS를 미리 해본 만큼, GCP에도 빠르게 적응할 수 있으리라고 생각했는데, 막상 해보니 처음 보는 용어가 많더군요... 지금 GCP에서 할인이나 크레딧을 뿌리고 있어서 저같은 학생 개발자한테는 꽤 좋은 선택지가 된다고 생각합니다.

1. GCP의 기본 개념: 프로젝트와 API

프로젝트란? (AWS Account와의 차이)

GCP에서 프로젝트는 모든 클라우드 리소스를 담는 기본 단위입니다. AWS의 Account와 비슷해 보이지만, 실제로는 더 세밀한 격리 단위라고 볼 수 있습니다.

핵심 차이점:

AWS는 Account가 청구의 최상위 단위이고, 그 안에서 리소스를 자유롭게 생성합니다
GCP는 프로젝트 단위로 청구, 권한, API, 리소스가 완전히 독립적으로 관리됩니다
하나의 조직 안에 여러 프로젝트를 만들어 개발/스테이징/프로덕션 환경을 분리하는 것이 일반적입니다

API 활성화가 필수인 이유

GCP의 가장 큰 특징 중 하나: 사용하고 싶은 서비스가 있으면 해당 API를 먼저 활성화해야 합니다.

AWS는 대부분의 서비스가 기본적으로 활성화되어 있어서, EC2든 S3든 바로 콘솔에 들어가서 사용할 수 있습니다. 하지만 GCP는 프로젝트 단위로 필요한 API만 켜서 사용하도록 설계되어 있습니다.

왜 이렇게 할까?

보안: 사용하지 않는 서비스는 아예 접근 불가능
비용 관리: 실수로 불필요한 리소스를 생성하는 것을 방지
명확성: 프로젝트에서 어떤 서비스를 사용하는지 한눈에 파악 가능

주요 API 종류

프로젝트를 시작할 때 자주 활성화하는 API들:

컴퓨팅 리소스:

Compute Engine API: VM 인스턴스 생성
Kubernetes Engine API: GKE 클러스터 관리
Cloud Run API: 서버리스 컨테이너 실행

네트워킹:

VPC API: 네트워크 리소스 관리

스토리지:

Cloud Storage API: 객체 스토리지 사용

기타:

Cloud Logging API, Cloud Monitoring API 등

구글 API vs GCP API

처음 GCP를 접하면 헷갈리는 부분이 있습니다. "구글 API"와 "GCP API"는 다릅니다.

구글 API: Gmail, Google Maps, YouTube 같은 구글 소비자 서비스용 API
GCP API: 클라우드 인프라를 위한 API (Compute Engine, Cloud Storage 등)

구글 API도 GCP 프로젝트에서 활성화할 수 있지만, 클라우드 컴퓨팅과는 별개의 영역입니다. 예를 들어 애플리케이션에서 Google Maps를 사용하고 싶다면 Maps API를 활성화하지만, 이것이 VM을 띄우는 것과는 무관합니다.

2. 리소스 계층 구조와 IAM

조직 → 폴더 → 프로젝트 → 리소스 구조

GCP의 리소스는 계층 구조를 가집니다:

조직 (Organization)
  └── 폴더 (Folder) - 선택사항
      └── 프로젝트 (Project)
          └── 리소스 (VM, 스토리지 등)

이 구조의 핵심은 정책 상속입니다. 상위 레벨에서 설정한 IAM 정책이나 조직 정책이 하위로 자동으로 상속됩니다.

AWS Organizations와 비교

AWS도 Organizations를 통해 Account를 계층적으로 관리할 수 있지만, 사용 방식이 다릅니다:

AWS:

Account가 비용/권한의 기본 경계
OU(Organizational Unit)로 그룹핑
SCP(Service Control Policy)로 제어

GCP:

프로젝트가 비용/권한/리소스의 기본 경계
폴더로 프로젝트를 그룹핑
IAM 정책이 계층 상속

IAM 모델의 차이점

GCP IAM의 핵심 철학은 "누가(Who) → 어떤 리소스에(Resource) → 어떤 역할을(Role) 갖는가" 를 리소스 쪽에 붙여서 관리하는 것입니다.

AWS IAM:

사용자/역할에 정책을 직접 연결 (Identity-based)
"이 사용자는 이런 권한을 가진다"는 접근

GCP IAM:

리소스에 바인딩을 설정 (Resource-based)
"이 리소스는 이 사용자가 이렇게 접근할 수 있다"는 접근
두 방식 모두 지원하지만, 리소스 중심 사고가 기본

3. 네트워킹: VPC부터 다시 이해하기

GCP VPC는 글로벌, 서브넷은 리전

이것이 AWS에서 GCP로 넘어올 때 (개인적으로) 가장 헷갈리는 부분입니다.

AWS:

VPC는 리전 단위 (예: us-east-1 VPC)
서브넷은 가용영역(AZ) 단위
다른 리전에 VPC를 만들려면 완전히 새로운 VPC 생성

GCP:

VPC는 글로벌 리소스 (전 세계에 하나의 VPC)
서브넷은 리전 단위
하나의 VPC 안에서 us-central1, asia-northeast3 등 여러 리전의 서브넷을 가질 수 있음

AWS VPC와의 핵심 차이

시작점의 차이:

AWS: VPC와 서브넷을 먼저 만들어야 인스턴스 배포 가능
GCP: 기본 VPC가 이미 존재하며, 바로 리소스 생성 가능

IP 범위:

AWS: VPC 생성 시 CIDR 블록 지정 필수
GCP: 서브넷별로 IP 범위 지정, VPC 레벨에서는 명시하지 않음

연결성:

AWS: Internet Gateway, NAT Gateway를 명시적으로 구성
GCP: 기본적으로 라우팅이 단순화되어 있고, Cloud NAT 사용

방화벽 규칙 (Security Group과 다른 점)

AWS Security Group에 익숙하다면, GCP Firewall Rules는 약간 다르게 느껴질 것입니다.

AWS Security Group:

인스턴스(ENI)에 직접 연결
Stateful: 응답 트래픽 자동 허용

GCP Firewall Rules:

VPC 레벨에서 관리
네트워크 태그 기반으로 타겟 지정
Stateful이 기본이지만, 명시적으로 규칙 작성
Ingress/Egress 규칙 분리

VM에 웹 서버를 띄운다면,

AWS: Security Group을 만들어 인스턴스에 붙이고, 80/443 포트 열기
GCP: VM에 "web-server" 태그 지정, Firewall Rule에서 "web-server" 태그를 가진 인스턴스에 80/443 허용

Private Google Access란?

GCP만의 독특한 기능으로, 외부 IP 없이 구글 서비스에 접근할 수 있게 해줍니다.

AWS의 VPC Endpoint와 비슷한 개념이지만:

AWS: S3, DynamoDB 등 서비스별로 Endpoint 생성 필요
GCP: Private Google Access를 서브넷에서 활성화하면, Cloud Storage, BigQuery 등 대부분의 구글 서비스에 자동 접근

외부 IP가 없는 VM에서 Cloud Storage에 파일을 업로드해야 한다면, Private Google Access만 켜면 바로 가능합니다. 추가 구성이 거의 없습니다.

4. 컴퓨팅 서비스

Compute Engine (EC2와 비교)

Compute Engine은 GCP의 IaaS VM 서비스로, AWS EC2와 동일한 역할입니다.

커스텀 머신 타입

AWS와의 가장 큰 차이는 머신 타입의 유연성입니다.

AWS EC2:

정해진 인스턴스 타입 선택 (t3.medium, c5.large 등)
vCPU와 메모리 비율이 고정

GCP Compute Engine:

미리 정의된 머신 타입도 있지만
커스텀 머신 타입: vCPU 개수와 메모리를 독립적으로 조절 가능
예: vCPU 4개 + 메모리 10GB 같은 조합 가능

컨테이너 실행 옵션

GCP는 컨테이너 실행에 있어 AWS보다 더 다양하고 유연한 옵션을 제공하고 있습니다.

Cloud Run

Cloud Run은 GCP의 주력 서비스 중 하나로, AWS Fargate와 Lambda의 중간 지점입니다.

특징:

컨테이너를 서버리스로 실행
HTTP/gRPC 엔드포인트 자동 생성
요청이 올 때만 실행되어 과금 (0→1, 1→0 자동 스케일)
인프라 관리 전혀 필요 없음

AWS 대비:

Fargate보다 설정이 훨씬 간단 (VPC, subnet, security group 등 불필요)
Lambda보다 유연 (최대 실행 시간, 메모리 제한이 덜 엄격)

예시:

# Docker 이미지만 있으면 한 줄로 배포
gcloud run deploy my-service --image gcr.io/my-project/my-image --platform managed

GKE (Google Kubernetes Engine)

GKE는 AWS EKS에 해당하는 관리형 쿠버네티스입니다.

GKE의 두 가지 모드:

Autopilot 모드
- 노드 관리 완전 자동화
- Pod 단위로만 과금
- 운영 부담 최소화
- AWS에는 동급 서비스가 없음 (Fargate for EKS와 비슷하지만 더 강력)
Standard 모드
- 노드 풀 직접 관리
- EKS와 유사한 경험
- 세밀한 제어 가능

Cloud Functions (Lambda와 비교)

Cloud Functions는 AWS Lambda와 거의 동일한 서버리스 함수 서비스입니다.

유사점:

이벤트 기반 실행
자동 스케일
사용한 만큼 과금

차이점:

GCP는 2세대 Cloud Functions에서 더 긴 실행 시간 지원
Cloud Run과의 통합이 자연스러움 (실제로 2세대는 Cloud Run 기반)

선택 기준:

단순 함수 로직 → Cloud Functions
HTTP API나 더 긴 실행 시간 필요 → Cloud Run

5. 스토리지와 데이터베이스

Cloud Storage (S3와 비교)

Cloud Storage는 GCP의 객체 스토리지로, AWS S3와 거의 동일한 역할입니다.

유사점:

무제한 용량
버킷(Bucket) 개념
스토리지 클래스 (Standard, Nearline, Coldline, Archive)
버전 관리, 라이프사이클 정책

차이점:

버킷 네이밍:
- AWS S3: 리전 내에서 고유
- GCP: 전역적으로 고유 (전 세계에서 유일한 이름)
리전 복제:
- AWS: Cross-Region Replication 설정 필요
- GCP: Multi-region, Dual-region 등 다양한 위치 옵션
접근 제어:
- AWS: IAM + Bucket Policy + ACL
- GCP: IAM 중심 (더 단순)

이외의 차이점

기본 설정 차이

Public IP 할당

AWS: 대부분의 경우 자동 할당 (VPC 설정에 따라)
GCP: 명시적으로 "외부 IP" 옵션을 선택해야 함

처음 VM을 만들 때 외부 접속이 안 된다면, 외부 IP를 할당했는지 확인해 봐야겠습니다.

디스크 삭제

AWS: 인스턴스 종료 시 루트 볼륨 자동 삭제 (기본값)
GCP: 인스턴스 삭제 후에도 디스크 유지 (기본값)

GCP에서 테스트용 VM을 만들고 삭제했는데, 디스크는 남아서 계속 과금되는 경우가 있을 것 같습니다... 인스턴스 삭제 시 "디스크도 삭제" 옵션을 체크하거나, 나중에 수동으로 삭제해야겠습니다.

방화벽 기본값

AWS: Security Group이 기본적으로 모든 트래픽 차단
GCP: 기본 VPC에는 일부 방화벽 규칙이 미리 설정되어 있음 (SSH, RDP, ICMP 등)

비용 모델 차이

초 단위 과금

AWS: 대부분 시간 단위 (일부 서비스는 초 단위)
GCP: 모든 컴퓨팅 리소스가 초 단위 과금 (최소 1분)

짧은 시간 동안만 리소스를 사용한다면 GCP가 유리한 것 같습니다.

네트워크 비용

AWS: 같은 리전 내 AZ 간 트래픽도 과금
GCP: 같은 리전 내 zone 간 트래픽은 무료

출처

GCP Resource Manager 공식 문서
GCP VPC 공식 문서

hyoin

배워야 할 게 많은 개발자... 하지만 공부를 포기하지 않지!!

이전 포스트

[Arduino] 스텝모터 라이브러리 비교: Stepper vs AccelStepper

다음 포스트