VPC부터 Cloud Run까지, gcloud로 네트워크와 컴퓨트를 검증 가능하게 운영하는 법

Q: Cloud Run의 트래픽 분할 비율은 얼마가 좋아?

정답은 없지만, 일반적으로 **5~10% -> 25% -> 50% -> 100%** 순서를 많이 써. 각 단계에서 에러율, 지연, 로그를 확인하고 문제없으면 다음 단계로 넘어가. 사용자 수가 많은 서비스일수록 초기 비율을 낮게 시작하는 게 안전해.

시리즈: gcloud CLI 자동화 운영 플레이북 (총 11편) | 6회

리소스를 만드는 건 쉬워요. 진짜 문제는 “만들었다고 믿었는데 실제로는 달랐다”에서 생기거든요. 이 글에서는 생성보다 검증을 먼저 강조하는 네트워킹/컴퓨트 플레이북을 다뤄요. VPC에서 Cloud Run까지 실무 패턴을 정리했어요.

Summary

네트워크/컴퓨트 사고 대부분은 “만들었다고 믿었는데 달랐다”에서 시작해 – 검증 명령이 생성 명령보다 중요해
VPC/방화벽은 “생성 -> 목록/describe -> 접속 테스트 -> 로그 관찰” 순서를 반드시 고정해
GCE는 외부 IP 없이 IAP SSH로 접속하는 게 보안과 운영 모두에서 유리해
Cloud Run은 --no-traffic으로 배포하고 트래픽 분할로 점진 롤아웃하는 게 안전한 배포의 기본이야

이 글의 대상

VPC/방화벽 설정을 할 때마다 “이게 진짜 적용됐나?” 불안한 개발자/운영자
GCE 인스턴스에 외부 IP를 달아놓고 있는데 보안 걱정이 되는 사람
Cloud Run 배포할 때 다운타임 없이 안전하게 롤아웃하고 싶은 DevOps 엔지니어

왜 “검증 명령”이 “생성 명령”보다 중요한가
VPC/서브넷 표준 프로비저닝
방화벽 규칙: 생성부터 검증까지
GCE: 외부 IP 없는 VM + IAP SSH
GCE 운영: 시리얼 로그, 이미지, 정리
GKE: 노드풀 기반 비용과 성능 운영
Cloud Run: –no-traffic와 트래픽 분할 배포
실패 케이스와 트러블슈팅

1. 왜 “검증 명령”이 “생성 명령”보다 중요한가

결론부터 말할게. 실무 사고는 “만드는 과정”이 아니라 “만들었다고 믿은 뒤”에 터져.

이런 상황을 생각해봐:

상황	실제 문제
VPC 생성 후 VM 접속 안 됨	방화벽 규칙이 빠졌거나 타겟 태그가 안 붙었어
방화벽 규칙 추가했는데 트래픽 안 통함	우선순위가 높은 deny 규칙이 먼저 적용돼
Cloud Run 배포했는데 이전 버전이 응답	트래픽이 새 리비전으로 전환 안 됐어
GKE 노드풀 추가했는데 파드 안 스케줄	노드 레이블/테인트 설정이 안 맞아

그래서 이 글의 모든 플레이북은 이 순서를 따라:

생성(Create) -> 목록/상세(List/Describe) -> 접속/트래픽 테스트 -> 로그 관찰

생성 명령만 치고 넘어가면 안 돼. 반드시 검증까지 해야 해.

2. VPC/서브넷 표준 프로비저닝

VPC 생성 (커스텀 모드)

# auto 모드는 리전마다 서브넷이 자동 생성돼서 통제가 어려워
# 커스텀 모드가 운영에 적합해
gcloud compute networks create prod-vpc --subnet-mode=custom

서브넷 생성

# 서울 리전
gcloud compute networks subnets create prod-subnet-kr \
  --network=prod-vpc \
  --region=asia-northeast3 \
  --range=10.10.0.0/20

# 미국 중부 리전
gcloud compute networks subnets create prod-subnet-us \
  --network=prod-vpc \
  --region=us-central1 \
  --range=10.11.0.0/20

검증 (이게 핵심이야)

# VPC 확인
gcloud compute networks describe prod-vpc \
  --format="table(name,subnetworks,autoCreateSubnetworks)"

# 서브넷 목록
gcloud compute networks subnets list \
  --filter="network:prod-vpc" \
  --format="table(name,region,ipCidrRange)"

출력 예시:

NAME             REGION           IP_CIDR_RANGE
prod-subnet-kr   asia-northeast3  10.10.0.0/20
prod-subnet-us   us-central1      10.11.0.0/20

여기서 IP 범위, 리전이 의도한 대로인지 눈으로 확인해야 해. “만들었으니까 됐겠지”는 금물이야.

3. 방화벽 규칙: 생성부터 검증까지

방화벽은 네트워크 운영에서 가장 사고가 많이 나는 영역이야. 규칙이 맞다고 생각했는데 실제로는 다른 규칙이 먼저 적용되는 경우가 흔하거든.

웹 트래픽 허용 (HTTP/HTTPS)

gcloud compute firewall-rules create allow-web-ingress \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web \
  --enable-logging

핵심 포인트:
- --target-tags=web: 이 태그가 붙은 VM에만 적용돼
- --enable-logging: 방화벽 로그를 켜면 트래픽이 허용/거부됐는지 Logging에서 확인 가능
- --priority=1000: 숫자가 낮을수록 우선 적용. 기본값은 1000

IAP SSH 허용 (외부 IP 없는 VM 접속용)

gcloud compute firewall-rules create allow-iap-ssh \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --target-service-accounts=web-sa@PROJECT.iam.gserviceaccount.com \
  --enable-logging

여기서 35.235.240.0/20은 Google IAP 서비스의 고정 IP 범위야. IAP를 통한 SSH는 반드시 이 범위에서 오거든.

방화벽 타겟 설계: 태그 vs 서비스계정

타겟 방식	장점	단점
네트워크 태그 (`--target-tags`)	설정 간단	태그를 누가 붙였는지 통제 어려움
서비스계정 (`--target-service-accounts`)	IAM으로 통제 가능	설정이 복잡

민감 영역(프로덕션 DB, 결제 서비스 등)은 서비스계정 기반을 추천해. 태그는 VM을 만드는 사람이 자유롭게 붙일 수 있어서 통제가 느슨하거든.

방화벽 규칙 검증

# 규칙 목록
gcloud compute firewall-rules list \
  --filter="network:prod-vpc" \
  --format="table(name,direction,priority,allowed[].map().firewall_rule().list():label=ALLOWED,sourceRanges,targetTags,targetServiceAccounts)"

# 특정 규칙 상세
gcloud compute firewall-rules describe allow-web-ingress

실제 트래픽 테스트

검증 명령으로 규칙이 존재하는 건 확인했어. 하지만 실제로 트래픽이 통하는지는 접속 테스트를 해봐야 해:

# VM에서 외부 접속 테스트
gcloud compute ssh my-vm --zone=asia-northeast3-a -- 'curl -s http://example.com'

# 다른 VM에서 특정 포트 접속 테스트
gcloud compute ssh test-vm --zone=asia-northeast3-a -- 'nc -zv 10.10.0.2 80'

4. GCE: 외부 IP 없는 VM + IAP SSH

외부 IP를 달지 않는 게 왜 좋은지, 먼저 비교해볼게.

외부 IP 있는 VM vs 없는 VM

항목	외부 IP 있음	외부 IP 없음 + IAP SSH
공격 면적	인터넷에 직접 노출	IAP를 통해서만 접근
방화벽 관리	소스 IP 관리 필요	IAP IP 범위(35.235.240.0/20)만 허용
접근 통제	방화벽 + SSH 키	방화벽 + IAM + SSH 키
비용	외부 IP 요금 발생	추가 비용 없음
인터넷 아웃바운드	직접 가능	Cloud NAT 필요

VM 생성 (외부 IP 없이)

gcloud compute instances create app-server-01 \
  --zone=asia-northeast3-a \
  --machine-type=e2-medium \
  --subnet=prod-subnet-kr \
  --no-address \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --tags=web \
  --service-account=web-sa@PROJECT.iam.gserviceaccount.com \
  --scopes=cloud-platform

핵심 플래그:
- --no-address: 외부 IP를 할당하지 않아
- --tags=web: 방화벽 규칙의 타겟 태그와 매칭
- --service-account: VM이 사용할 서비스계정

IAP SSH로 접속

# IAP 터널을 통한 SSH 접속
gcloud compute ssh app-server-01 \
  --zone=asia-northeast3-a \
  --tunnel-through-iap

사전 조건:
1. IAP SSH 방화벽 규칙이 있어야 해 (위에서 만든 allow-iap-ssh)
2. 접속하는 사용자에게 roles/iap.tunnelResourceAccessor 역할이 필요해
3. compute.googleapis.com API가 활성화돼 있어야 해

# IAP 접근 권한 부여
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member='user:developer@example.com' \
  --role='roles/iap.tunnelResourceAccessor'

검증

# VM 상태 확인
gcloud compute instances describe app-server-01 \
  --zone=asia-northeast3-a \
  --format="table(name,status,networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

natIP 필드가 비어있으면 외부 IP가 없는 거야. 의도한 대로!

5. GCE 운영: 시리얼 로그, 이미지, 정리

부팅 문제 진단 (시리얼 포트)

VM이 부팅에 실패하거나 SSH가 안 될 때, 시리얼 포트 출력이 유일한 단서인 경우가 많아:

gcloud compute instances get-serial-port-output app-server-01 \
  --zone=asia-northeast3-a

커스텀 이미지 생성

검증 완료된 VM을 이미지로 만들면 동일한 환경을 빠르게 복제할 수 있어:

# 이미지 생성 전 VM 종료 권장
gcloud compute instances stop app-server-01 --zone=asia-northeast3-a

# 이미지 생성
gcloud compute images create app-server-base-v1 \
  --source-disk=app-server-01 \
  --source-disk-zone=asia-northeast3-a \
  --family=app-images

# 검증
gcloud compute images describe app-server-base-v1 --format=json

이미지 생성 전에 반드시 민감 정보(키, 토큰, 임시 파일) 제거와 VM 종료를 하는 게 좋아. 실행 중 이미지를 만들 수 있지만 디스크 일관성이 보장되지 않을 수 있거든.

이미지 패밀리로 최신 이미지 자동 참조

# app-images 패밀리의 최신 이미지로 VM 생성
gcloud compute instances create new-server \
  --zone=asia-northeast3-a \
  --machine-type=e2-medium \
  --image-family=app-images

--image-family를 쓰면 해당 패밀리의 가장 최신 이미지를 자동으로 사용해. 이미지를 업데이트할 때마다 VM 생성 스크립트를 수정할 필요가 없어져서 운영이 편해져.

6. GKE: 노드풀 기반 비용과 성능 운영

GKE에서 gcloud가 특히 유용한 건 노드풀(Node Pool) 관리야. 노드풀은 비용과 성능을 조절하는 운영 단위이거든.

클러스터 생성

gcloud container clusters create prod-gke \
  --zone=asia-northeast3-a \
  --num-nodes=1 \
  --machine-type=e2-medium \
  --enable-ip-alias \
  --network=prod-vpc \
  --subnetwork=prod-subnet-kr

노드풀 추가 + 오토스케일

# 웹 서비스용 노드풀
gcloud container node-pools create web-pool \
  --cluster=prod-gke \
  --zone=asia-northeast3-a \
  --machine-type=e2-standard-2 \
  --num-nodes=1 \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=5 \
  --tags=web

# 배치 작업용 노드풀 (스팟 인스턴스로 비용 절감)
gcloud container node-pools create batch-pool \
  --cluster=prod-gke \
  --zone=asia-northeast3-a \
  --machine-type=e2-standard-4 \
  --num-nodes=0 \
  --enable-autoscaling \
  --min-nodes=0 \
  --max-nodes=10 \
  --spot

노드풀 설계 전략

워크로드 유형	머신 타입	오토스케일	비용 최적화
웹/API 서비스	e2-standard-2	1~5	일반 인스턴스
배치/ML 학습	e2-standard-4+	0~10	스팟 인스턴스
시스템 컴포넌트	e2-small	1~2 (고정)	최소 사양

검증

# 노드풀 목록
gcloud container node-pools list \
  --cluster=prod-gke \
  --zone=asia-northeast3-a \
  --format="table(name,config.machineType,initialNodeCount,autoscaling.minNodeCount,autoscaling.maxNodeCount)"

# kubectl 자격 설정 (gcloud가 kubeconfig를 세팅해줘)
gcloud container clusters get-credentials prod-gke \
  --zone=asia-northeast3-a

# 노드 확인
kubectl get nodes -o wide

노드풀 업그레이드

# 특정 노드풀 업그레이드
gcloud container node-pools upgrade web-pool \
  --cluster=prod-gke \
  --zone=asia-northeast3-a

# 업그레이드 전 현재 버전 확인
gcloud container node-pools describe web-pool \
  --cluster=prod-gke \
  --zone=asia-northeast3-a \
  --format="value(version)"

7. Cloud Run: –no-traffic와 트래픽 분할 배포

Cloud Run은 gcloud로 무중단 배포를 구현하기 가장 좋은 서비스야. 리비전 + 트래픽 분할 모델 덕분이지.

핵심 배포 절차 (4단계)

1) 새 리비전 배포 (트래픽 0%)
2) 태그 URL로 검증
3) 트래픽 점진 반영 (10% -> 50% -> 100%)
4) 문제 시 즉시 롤백

Step 1: 새 리비전 배포 (트래픽 미전환)

gcloud run deploy myservice \
  --image=gcr.io/PROJECT/myapp:v2-canary \
  --platform=managed \
  --region=asia-northeast3 \
  --no-traffic \
  --tag=canary \
  --allow-unauthenticated

핵심 플래그:
- --no-traffic: 새 리비전에 트래픽을 보내지 않아. 기존 리비전이 계속 100% 서빙해
- --tag=canary: 이 리비전에 canary라는 태그를 붙여. 태그 전용 URL이 생겨

Step 2: 태그 URL로 검증

--tag=canary를 붙이면 이런 URL이 생겨:

https://canary---myservice-xxxxx-an.a.run.app

이 URL로 새 리비전을 실제 트래픽 없이 테스트할 수 있어:

# 태그 URL로 기능 테스트
curl https://canary---myservice-xxxxx-an.a.run.app/health

# 현재 트래픽 상태 확인
gcloud run services describe myservice \
  --platform=managed \
  --region=asia-northeast3 \
  --format="yaml(status.traffic)"

Step 3: 트래픽 점진 반영

검증이 끝나면 트래픽을 점진적으로 넘겨:

# 10% 트래픽을 canary로
gcloud run services update-traffic myservice \
  --to-tags=canary=10 \
  --platform=managed \
  --region=asia-northeast3

에러율/지연을 모니터링한 뒤:

# 50%로 확대
gcloud run services update-traffic myservice \
  --to-tags=canary=50 \
  --platform=managed \
  --region=asia-northeast3

문제없으면:

# 100%로 전환
gcloud run services update-traffic myservice \
  --to-tags=canary=100 \
  --platform=managed \
  --region=asia-northeast3

Step 4: 문제 시 즉시 롤백

배포 후 문제가 발견되면? 이전 리비전으로 즉시 돌려:

# 이전 리비전의 이름 확인
gcloud run revisions list \
  --service=myservice \
  --platform=managed \
  --region=asia-northeast3 \
  --format="table(REVISION,ACTIVE,SERVICE_URL)"

# 이전 리비전으로 100% 트래픽 전환 (롤백)
gcloud run services update-traffic myservice \
  --to-revisions=myservice-00001-abc=100 \
  --platform=managed \
  --region=asia-northeast3

롤백은 몇 초면 완료돼. 새 컨테이너를 빌드하거나 배포할 필요 없이, 트래픽 라우팅만 바꾸는 거니까.

트래픽 분할 상태 확인

gcloud run services describe myservice \
  --platform=managed \
  --region=asia-northeast3 \
  --format="yaml(status.traffic)"

출력 예시:

status:
  traffic:
  - latestRevision: false
    percent: 90
    revisionName: myservice-00001-abc
  - latestRevision: true
    percent: 10
    revisionName: myservice-00002-def
    tag: canary
    url: https://canary---myservice-xxxxx-an.a.run.app

8. 실패 케이스와 트러블슈팅

실패 1: 방화벽 규칙 있는데 트래픽 안 통함

증상: allow-web-ingress 규칙을 만들었는데 80포트 접속이 안 돼.

진단 순서:

# 1. 규칙이 실제로 존재하는지
gcloud compute firewall-rules describe allow-web-ingress

# 2. VM에 타겟 태그가 붙어있는지
gcloud compute instances describe my-vm --zone=asia-northeast3-a \
  --format="value(tags.items)"

# 3. 더 높은 우선순위의 deny 규칙이 있는지
gcloud compute firewall-rules list \
  --filter="network:prod-vpc" \
  --sort-by=priority \
  --format="table(name,direction,priority,action,allowed,denied)"

흔한 원인:
- VM에 --tags=web이 안 붙어있음
- 우선순위가 더 높은(숫자가 더 낮은) deny 규칙이 존재
- VM이 다른 네트워크/서브넷에 있음

실패 2: IAP SSH 접속 실패

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.

진단 순서:

# 1. IAP 방화벽 규칙 확인
gcloud compute firewall-rules list \
  --filter="network:prod-vpc AND sourceRanges:35.235.240.0/20"

# 2. IAP 접근 권한 확인
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[]" \
  --filter="bindings.role:roles/iap.tunnelResourceAccessor" \
  --format="table(bindings.members)"

# 3. VM 상태 확인
gcloud compute instances describe app-server-01 \
  --zone=asia-northeast3-a \
  --format="value(status)"

흔한 원인:
- roles/iap.tunnelResourceAccessor 역할이 없음
- 방화벽에서 35.235.240.0/20 범위를 허용하지 않음
- VM이 TERMINATED 상태

실패 3: Cloud Run 배포 후 이전 버전이 응답

증상: gcloud run deploy를 했는데 여전히 이전 버전이 응답해.

원인: --no-traffic 플래그를 쓰지 않았는데도 트래픽이 안 넘어갔다면, 기존 트래픽 분할 설정이 특정 리비전에 고정돼 있을 수 있어.

# 현재 트래픽 분할 상태 확인
gcloud run services describe myservice \
  --platform=managed \
  --region=asia-northeast3 \
  --format="yaml(status.traffic)"

# latest로 100% 전환
gcloud run services update-traffic myservice \
  --to-latest \
  --platform=managed \
  --region=asia-northeast3

실패 4: GKE kubectl 인증 만료

error: You must be logged in to the server (Unauthorized)

해결:

# 자격 갱신
gcloud container clusters get-credentials prod-gke \
  --zone=asia-northeast3-a

# gcloud 인증 상태 확인
gcloud auth list

GKE 인증 플러그인이 설치돼 있는지도 확인해:

gcloud components list | grep gke-gcloud-auth-plugin

실패 5: VPC 서브넷 IP 범위 겹침

ERROR: (gcloud.compute.networks.subnets.create)
The resource 'projects/xxx/regions/xxx/subnetworks/xxx' already has a range that overlaps.

원인: 같은 VPC 내에서 서브넷 IP 범위가 겹쳐.

예방: 서브넷을 만들기 전에 기존 범위를 확인하는 습관을 들여:

gcloud compute networks subnets list \
  --filter="network:prod-vpc" \
  --format="table(name,region,ipCidrRange)"

핵심 정리

1. 네트워크/컴퓨트 운영은 "생성 -> 목록/describe -> 접속 테스트 -> 로그 관찰" 순서를 고정해
2. 방화벽 규칙은 우선순위, 타겟(태그/서비스계정), 소스 범위를 반드시 검증해야 사고를 막아
3. GCE는 외부 IP 없이 IAP SSH로 접속하면 보안과 비용 모두 유리해
4. Cloud Run은 --no-traffic + 태그 URL 검증 + 트래픽 점진 분할이 안전한 배포의 기본이야

FAQ

Q. VPC를 auto 모드로 만들면 안 돼?

A. 테스트/학습 목적이면 auto 모드도 괜찮아. 하지만 운영 환경에서는 custom 모드를 추천해. auto 모드는 모든 리전에 서브넷이 자동 생성되는데, 불필요한 리전의 서브넷은 리소스 관리와 보안 관점에서 좋지 않거든.

Q. 방화벽 규칙에 –enable-logging을 항상 켜야 해?

A. 프로덕션에서는 켜는 게 좋아. 트래픽 문제를 진단할 때 로그가 유일한 단서인 경우가 많거든. 다만 로깅은 추가 비용이 발생하니까, 트래픽이 매우 많은 규칙은 비용을 고려해서 결정해.

Q. IAP SSH는 느리지 않아?

A. 약간의 지연은 있어. IAP 터널을 통하니까. 하지만 일반적인 운영 작업에서 체감될 정도는 아니야. 파일 전송처럼 대역폭이 필요한 작업은 gcloud compute scp --tunnel-through-iap를 쓸 수 있는데, 대량 데이터는 Cloud Storage 경유를 추천해.

Q. Cloud Run에서 –no-traffic 없이 배포하면 어떻게 돼?

A. 기본적으로 새 리비전이 바로 100% 트래픽을 받아. 검증 없이 모든 사용자가 새 버전을 쓰게 되는 거지. 작은 변경이면 괜찮을 수 있지만, 중요한 변경은 반드시 --no-traffic을 써서 검증 후 전환하는 게 안전해.

Q. GKE 노드풀을 업그레이드하면 파드가 중단돼?

A. GKE는 노드를 하나씩 교체하는 rolling update 방식으로 업그레이드해. PodDisruptionBudget을 설정해두면 동시에 중단되는 파드 수를 제한할 수 있어. 서비스 중단 없이 업그레이드하려면 PDB 설정이 중요해.

Q. Cloud Run의 트래픽 분할 비율은 얼마가 좋아?

A. 정답은 없지만, 일반적으로 5~10% -> 25% -> 50% -> 100% 순서를 많이 써. 각 단계에서 에러율, 지연, 로그를 확인하고 문제없으면 다음 단계로 넘어가. 사용자 수가 많은 서비스일수록 초기 비율을 낮게 시작하는 게 안전해.

Q. VPC 방화벽 규칙 이름을 바꿀 수 있어?

A. 안 돼. 방화벽 규칙 이름은 생성 후 변경 불가야. 이름을 바꾸려면 새 규칙을 만들고 기존 규칙을 삭제해야 해. 그래서 처음에 네이밍 규칙을 잘 정하는 게 중요해. 예: allow-[대상]-[프로토콜]-[포트] -> allow-web-tcp-443.

Q. GCE VM에 외부 IP가 없으면 소프트웨어 설치(apt install 등)는 어떻게 해?

A. Cloud NAT를 설정하면 외부 IP 없이도 인터넷 아웃바운드가 가능해. 또는 Private Google Access를 활성화하면 Google API/서비스에는 외부 IP 없이 접근할 수 있어. 패키지 저장소가 Google 외부에 있다면 Cloud NAT가 필요해.

Q. 방화벽 규칙에서 source-ranges를 0.0.0.0/0으로 열면 위험하지 않아?

A. 웹 서비스(HTTP/HTTPS)처럼 공개 접근이 필요한 경우는 괜찮아. 하지만 SSH(22), RDP(3389) 같은 관리 포트는 절대 0.0.0.0/0으로 열면 안 돼. 이럴 때 IAP를 쓰는 거야. IAP는 35.235.240.0/20 범위만 허용하니까 훨씬 안전하지.

Q. Cloud Run 롤백은 얼마나 빨라?

A. 트래픽 라우팅만 변경하는 거라서 보통 몇 초 이내에 완료돼. 새로 컨테이너를 빌드하거나 배포하는 게 아니라 기존 리비전으로 트래픽을 돌리는 거니까. 이게 Cloud Run의 가장 큰 장점 중 하나야.

참고 자료 (References)

데이터 출처

출처	설명	링크
Google Cloud 공식 문서	VPC 방화벽 규칙 사용	방화벽 규칙
Google Cloud 공식 문서	IAP로 SSH 접속	IAP SSH
Google Cloud 공식 문서	GCE 인스턴스 생성	instances create
Google Cloud 공식 문서	커스텀 이미지 생성	커스텀 이미지
Google Cloud 공식 문서	GKE 클러스터 생성	clusters create
Google Cloud 공식 문서	GKE 노드풀 관리	노드풀 관리
Google Cloud 공식 블로그	Cloud Run 점진적 롤아웃/롤백	점진적 롤아웃
Google Cloud 공식 문서	Cloud Run 트래픽 마이그레이션	트래픽 마이그레이션
Google Cloud 블로그	방화벽 규칙 설계 3가지 방법	방화벽 설계

핵심 인용

“Verify your firewall rules before they go into production. For any significant changes, test the rules to make sure they work as intended.” — Google Cloud VPC 방화벽 규칙 문서

다음 편 예고

[7편] 데이터 서비스 플레이북: Storage, BigQuery, Pub/Sub 반복 작업 표준화
- Cloud Storage에서 gcloud storage와 gsutil을 언제 어떻게 구분해서 쓰는지 알아봐요
- BigQuery 비용 폭탄을 막는 드라이런 + 최대 바이트 제한 가드레일 설정법
- Pub/Sub 에뮬레이터로 운영 영향 없는 통합 테스트 환경을 만드는 방법

'AI' 카테고리의 다른 글

CLI 보안 완성하기: 키리스 운영·KMS 감사·SCC 탐지 데이터 내보내기 실전 가이드 — gcloud CLI 자동화 운영 플레이북 8/11 (0)	2026.03.12
데이터 서비스 CLI 실전 운영: Storage·BigQuery·Pub/Sub 비용과 안전 가드레일 — gcloud CLI 자동화 운영 플레이북 7/11 (1)	2026.03.12
프로젝트부터 IAM까지, gcloud로 조직 운영을 자동화하는 6단계 프로비저닝 — gcloud CLI 자동화 운영 플레이북 5/11 (0)	2026.03.12
gcloud configurations로 프로젝트와 환경을 실수 없이 전환하는 법 — gcloud CLI 자동화 운영 플레이북 4/11 (0)	2026.03.12
gcloud 인증 체계 완전 정복: 사용자, 서비스계정, ADC 분리로 온보딩 장애를 없애는 법 — gcloud CLI 자동화 운영 플레이북 3/11 (0)	2026.03.12