데이터·네트워킹 리소스 배포와 IaC 자동화 실전

Cloud SQL·BigQuery·Cloud Storage 배포부터 VPC·로드 밸런서·Cloud Interconnect 구성, Marketplace 활용, Terraform·Deployment Manager IaC 자동화까지 6개 도메인을 실무 관점으로 압축 정리합니다.

배포는 끝이 아니라 운영의 시작이다

Google Cloud 인프라를 처음 구성하는 순간, 진짜 과제가 시작됩니다. 데이터베이스를 올리고, 네트워크를 연결하고, 외부 트래픽을 받는 일은 각각 독립된 작업이 아니라 서로 맞물린 하나의 흐름입니다. 데이터가 쌓이면 스토리지 클래스를 조정해야 하고, 트래픽이 늘면 로드 밸런서와 방화벽 규칙을 손봐야 합니다. 온프레미스와 연결이 필요해지면 Cloud Interconnect나 Cloud VPN 중 어느 쪽을 선택할지 판단해야 하고, 같은 환경을 여러 팀에 반복 배포해야 한다면 Terraform 파이프라인이 필요합니다.

GCP-ACE 시험의 '배포 및 구현' 도메인은 리소스를 만드는 방법이 아니라, 어떤 조건에서 어떤 서비스를 선택하는지를 묻습니다. 이 글은 데이터 솔루션 배포, 네트워킹 리소스 배포, 로드 밸런서, Marketplace, IaC, 운영 단계 변경까지 6개 도메인을 시나리오 중심으로 압축합니다.

---

 

데이터 리소스 배포: Cloud SQL, BigQuery, Cloud Storage 핵심

Cloud SQL은 MySQL, PostgreSQL, SQL Server를 완전 관리형으로 제공합니다. 고가용성(HA) 구성 시 동일 리전 내 다른 가용 영역에 스탠바이 인스턴스가 자동 생성되며, 장애 발생 시 자동 페일오버가 일어납니다. 읽기 부하 분산은 읽기 복제본(Read Replica)으로 처리하지만, 복제본은 데이터 손상도 복제하므로 데이터 보호 목적이라면 자동 백업과 Point-in-time Recovery(PITR)를 사용해야 합니다.

| Cloud SQL 기능 | 목적 | 주의 사항 | |---|---|---| | 읽기 복제본 | 읽기 부하 분산 | 데이터 손상도 복제 — 보호 수단 아님 | | HA (고가용성) | 인스턴스 장애 자동 복구 | 가용 영역 장애 대비 | | 자동 백업 + PITR | 특정 시점 복원 | 최대 7일 롤백 |

BigQuery는 서버리스 OLAP 엔진입니다. 온디맨드 요금제에서 쿼리 비용을 사전 예측하려면 플래그를 사용합니다. dry_run은 쿼리를 실제로 실행하지 않고 처리될 바이트 수만 반환하며 과금이 발생하지 않습니다. EXPLAIN은 실행 계획 분석용이므로 비용 예측 목적과 혼동하지 않아야 합니다. SQL 없이 BigQuery 데이터를 분석하려면 Connected Sheets 또는 Looker Studio와 연결합니다. Cloud Storage 파일을 직접 쿼리하려면 외부 테이블(External Table)을 생성합니다.

Cloud Storage 스토리지 클래스와 Object Lifecycle 정책은 반복 출제됩니다.

| 스토리지 클래스 | 최소 보관 | 접근 빈도 | 적합 사례 | |---|---|---|---| | Standard | 없음 | 자주 | 활성 데이터, 웹 서빙 | | Nearline | 30일 | 월 1회 미만 | 월별 백업 | | Coldline | 90일 | 분기 1회 미만 | 규정 준수 아카이브 | | Archive | 365일 | 연 1회 미만 | 장기 보존 로그 |

Object Lifecycle 규칙으로 일정 기간 경과 후 클래스를 자동 전환하거나 객체를 삭제합니다. Retention Policy는 삭제 방지 잠금 기능으로, 자동 전환·삭제 목적의 Object Lifecycle과 다릅니다. 시간 제한 외부 공유가 필요하면 Signed URL을 사용합니다.

---

 

네트워킹 리소스 배포: VPC부터 Cloud NAT, VPN, Interconnect

GCP VPC는 글로벌 리소스입니다. 하나의 VPC 안에 여러 리전의 서브넷을 배치할 수 있으며, 서브넷 기본 IP 범위는 확장(Expand)은 가능하지만 축소는 불가능합니다. 외부 IP 없는 VM이 Google API에 접근하게 하려면 서브넷에 Private Google Access를 활성화합니다.

방화벽 규칙은 네트워크 태그 또는 서비스 계정 기반으로 소스·대상 트래픽을 제어합니다. 우선순위 숫자가 낮을수록 먼저 평가됩니다. 단일 VPC 내 서비스 간 격리는 서브넷 분리 + 태그 기반 방화벽 규칙이 기존 구조를 유지하면서 격리를 구현하는 올바른 방법입니다. 여러 프로젝트 VPC 간 내부 통신이 필요하면 VPC Network Peering을 사용하지만, Peering은 비전이적(A↔B, B↔C 연결 시 A↔C는 별도 설정 필요)임을 기억합니다.

| 하이브리드 연결 | 경로 | 최대 대역폭 | 주요 특징 | |---|---|---|---| | Cloud VPN (HA) | 공용 인터넷 (IPsec) | 3Gbps/터널 | BGP 동적 라우팅 | | Dedicated Interconnect | 전용 물리 회선 | 200Gbps | SLA 99.9%+, 인터넷 미경유 | | Partner Interconnect | 파트너 경유 | 50Mbps~10Gbps | 코로케이션 없이 전용선 효과 |

Cloud NAT는 VM IP 변경과 무관하게 외부로는 고정 NAT IP를 노출합니다. 대용량 전송 + 방화벽 허용 목록 고정 IP 관리가 동시에 요구되는 시나리오에서는 Cloud Interconnect + Cloud NAT 조합이 두 요건을 충족합니다. Cloud DNS 공개 영역에서 DNS 응답 위변조 방지가 필요하면 DNSSEC을 활성화합니다.

---

 

로드 밸런서 구성과 백엔드 서비스 연결

GCP 로드 밸런서는 계층(L4/L7)과 범위(글로벌/리전)에 따라 선택 기준이 달라집니다.

| 로드 밸런서 유형 | 계층 | 범위 | 주요 특징 | |---|---|---|---| | 외부 HTTP(S) LB | L7 | 글로벌 | Anycast IP, CDN·Armor 통합, 멀티리전 장애 조치 | | 외부 네트워크 LB | L4 | 리전 | UDP/TCP 패스스루, 낮은 지연 | | 내부 HTTP(S) LB | L7 | 리전 | VPC 내부 마이크로서비스 간 HTTP 분산 | | 내부 TCP/UDP LB | L4 | 리전 | VPC 내부 TCP/UDP |

글로벌 외부 HTTP(S) 로드 밸런서는 Google-managed SSL 인증서와 연동하면 갱신이 완전 자동화됩니다. 백엔드 서비스(Backend Service)는 인스턴스 그룹 또는 네트워크 엔드포인트 그룹(NEG)을 정의하고, 헬스 체크로 비정상 인스턴스를 자동 제외합니다. 로드 밸런서에 정적 외부 IP를 예약해 두면 프런트엔드 IP가 고정되어 DNS 레코드 변경 없이 백엔드를 교체할 수 있습니다.

시험 함정: 글로벌 Anycast·CDN 통합·멀티리전 장애 조치가 필요한 상황에서 리전 네트워크 LB를 선택하면 안 됩니다. 반드시 글로벌 외부 HTTP(S) LB를 선택해야 합니다.

---

 

Marketplace로 빠르게 시작하기

Google Cloud Marketplace는 사전 구성된 솔루션을 클릭 몇 번으로 배포하는 카탈로그입니다. Cassandra, WordPress, Jenkins 같은 오픈소스 스택의 라이선스·VM·네트워크 설정이 묶음으로 제공됩니다.

| Marketplace 배포 유형 | 설명 | |---|---| | VM 이미지 솔루션 | Compute Engine VM + 사전 설치 SW, 소프트웨어 라이선스 별도 과금 가능 | | Kubernetes 앱 | GKE 클러스터에 Helm 차트 배포 | | Terraform 모듈 | IaC 방식, 코드 재사용 가능 | | SaaS 구독 | 외부 벤더 관리형 서비스 |

Marketplace 솔루션을 선택하면 프로젝트·리전·머신 유형만 입력하면 VPC·방화벽·VM이 자동 생성됩니다. 시험에서 '운영 오버헤드 최소화 + 검증된 솔루션 신속 배포' 키워드가 나오면 Marketplace가 정답입니다. 반면 세밀한 커스터마이징이나 반복 배포·코드 기반 관리가 필요하면 Terraform이 더 적합합니다.

---

 

Infrastructure as Code: Deployment Manager, Config Connector, Terraform

IaC는 인프라를 코드로 선언하고 버전 관리하는 방식입니다.

| 도구 | 언어 | 지원 범위 | 주요 사용 사례 | |---|---|---|---| | Deployment Manager | YAML / Jinja2 / Python | GCP 전용 | 레거시 GCP 환경 | | Config Connector | YAML (K8s CRD) | GCP (GKE 기반) | GKE GitOps 통합 | | Terraform | HCL | 멀티 클라우드 | 신규 프로젝트 표준 |

Deployment Manager는 옵션으로 실제 적용 전 변경 사항을 미리 확인합니다. GCP 네이티브이지만 멀티 클라우드 지원이 없고 커뮤니티 생태계가 작습니다.

Terraform은 GCP-ACE 시험에서 가장 자주 등장하는 IaC 도구입니다. 으로 변경 사항을 미리 확인하고 로 적용하며, 멱등성(같은 코드를 여러 번 실행해도 결과 동일)이 있어 반복 배포 시 안전합니다. Cloud Source Repositories에 Terraform 코드를 저장하고 Cloud Build 트리거와 연결하면 PR 병합 시 자동으로 plan/apply가 실행됩니다. Cloud Foundation Toolkit(CFT)은 조직 정책·VPC·IAM 기본값을 빠르게 적용하는 검증된 Terraform 모듈 모음입니다.

VPC, Cloud SQL, IAM 정책, Cloud Storage 버킷을 포함한 표준 환경을 여러 팀에 반복 배포해야 하는 시나리오에서는 Terraform + Cloud Build 파이프라인이 정답입니다.

---

 

운영 단계 변경: 라이프사이클, 권한, 방화벽 규칙

배포 이후 자주 발생하는 운영 변경 시나리오를 정리합니다.

Cloud Storage Object Lifecycle 정책은 기존 버킷에 언제든지 추가·수정할 수 있으며 기존 객체에도 소급 적용됩니다. 객체 단위 세밀한 권한 제어에는 ACL을 사용하지만, Uniform bucket-level access를 활성화하면 ACL이 비활성화되고 IAM만으로 통일됩니다.

Cloud SQL의 변경 데이터 캡처(CDC)는 Datastream을 연동합니다. Datastream은 바이너리 로그를 읽어 행 수준 변경 이벤트를 Pub/Sub 또는 Cloud Storage로 스트리밍합니다. 정기 백업 자동화는 Cloud Scheduler + Cloud Functions 조합으로 서버리스하게 구현합니다.

Dataproc 클러스터를 월 1~2회만 사용하는 배치 작업에 상시 운영하면 유휴 비용이 낭비됩니다. 작업이 필요할 때만 클러스터를 생성하고 완료 후 즉시 삭제하는 임시(ephemeral) 패턴이 비용 최적 방법입니다. 클러스터 축소 시 진행 중인 태스크가 강제 종료되는 문제는 Graceful Decommissioning으로 해결합니다.

| 운영 변경 항목 | 방법 | 주의 사항 | |---|---|---| | Cloud Storage 라이프사이클 추가 | gsutil lifecycle set | 기존 객체 소급 적용 | | Cloud SQL 읽기 복제본 추가 | Console / gcloud | 복제본은 데이터 보호 수단 아님 | | 방화벽 규칙 수정 | gcloud compute firewall-rules update | 우선순위 충돌 확인 필수 | | Cloud NAT 고정 IP 설정 | 수동 NAT IP 예약 후 할당 | 기본은 자동 할당 | | Dataproc 노드 안전 제거 | Graceful Decommissioning | YARN 태스크 완료 후 제거 |

---

 

정리: 데이터·네트워킹·IaC 운영 체크리스트

6개 도메인의 핵심 판단 기준을 시나리오 키워드와 함께 정리합니다.

| 시나리오 키워드 | 선택 서비스 / 패턴 | |---|---| | 다중 소스 수집 + 다중 소비자 독립 처리 | Cloud Pub/Sub | | 실시간 데이터 변환·처리 | Cloud Dataflow | | 대용량 전송 + 방화벽 고정 IP 관리 | Dedicated Interconnect + Cloud NAT | | IPsec 암호화 + 동적 라우팅 | Cloud VPN + Cloud Router (BGP) | | 멀티리전 HTTP 자동 장애 조치 | 글로벌 외부 HTTP(S) Load Balancer | | 검증된 솔루션 신속 배포 | Cloud Marketplace | | GCP 네이티브 IaC | Deployment Manager | | 멀티환경 재사용·파이프라인 자동화 IaC | Terraform + Cloud Build CI/CD | | DNS 응답 위변조 방지 | Cloud DNS DNSSEC | | 노드 제거 시 잡 손실 방지 | Dataproc Graceful Decommissioning | | 쿼리 비용 사전 확인 | BigQuery --dry_run | | 데이터 보호 vs 읽기 부하 분산 | PITR/백업 vs 읽기 복제본 |

데이터·네트워킹·IaC 도메인은 서비스 이름보다 시나리오의 제약 조건(비용, 지연, 보안, 운영 오버헤드)을 먼저 파악하는 훈련이 중요합니다. 각 서비스가 담당하는 레이어를 명확히 구분하고, Cloud SQL CDC는 Datastream → Pub/Sub → Cloud Functions 체인으로, VPC 방화벽과 Cloud NAT는 Terraform 코드로, 스토리지 라이프사이클은 Object Lifecycle 정책으로 연결하는 패턴을 익혀두면 복합 시나리오 문제에서도 자신 있게 선택할 수 있습니다.

블로그 목록으로 돌아가기