시리즈: gcloud CLI 자동화 운영 플레이북 (총 11편) | 10편
gcloud 교육 커리큘럼 설계: 2일/5일 과정과 실습 과제로 팀 표준을 정착시키는 법
gcloud 교육을 “명령어 목록 나열”로 하면 2주 뒤 아무도 기억 못 해요. 이 글에서는 2일 압축 온보딩과 5일 플랫폼 표준 정착 과정, 그리고 실습 과제 패키지 5종까지 여러분 팀에서 바로 가져다 커스터마이즈해서 쓸 수 있는 형태로 정리해 드릴게요.
Summary
- 2일 커리큘럼은 “로컬 표준 확립 + 대표 운영 시나리오”로 온보딩 속도에 집중해요
- 5일 커리큘럼은 GKE, Storage/BigQuery, 키리스 CI까지 포함해서 플랫폼 표준을 정착시켜요
- 실습 과제 5종(onboarding.sh ~ security-baseline.md)은 제출물 기반이라 학습 결과를 측정할 수 있어요
- 교육 성패는 “명령 암기”가 아니라 “진단 루틴”과 “표준 절차” 주입에 달려 있어요
이 글의 대상
- 팀 온보딩 프로그램을 설계하거나 운영하는 플랫폼/SRE 리더
- gcloud 교육을 체계적으로 준비해야 하는 교육 담당자
- 새 팀원이 합류할 때마다 반복되는 셋업 비용을 줄이고 싶은 엔지니어링 매니저
목차
- 교육 설계 원칙: 왜 “명령 목록”이 아니라 “진단 루틴”인가
- 2일 커리큘럼: 온보딩 압축형
- 5일 커리큘럼: 플랫폼 표준 정착형
- 실습 과제 패키지: 제출물별 학습 목표와 평가 기준
- 커리큘럼 운영 팁: 실패를 줄이는 실전 노하우
- 교육 후 정착까지: 체크리스트와 후속 조치
교육 설계 원칙: 왜 “명령 목록”이 아니라 “진단 루틴”인가
gcloud 교육에서 가장 흔한 실수는 명령어를 나열하는 거예요. gcloud compute instances create는 이렇게, gcloud run deploy는 저렇게… 이렇게 가르치면 교육 당일은 “아, 이런 게 있구나” 하고 끝나는데, 일주일 뒤에 진짜 문제가 터지면 아무 도움이 안 돼요.
좋은 gcloud 교육은 “진단 루틴”을 몸에 익히게 하는 거예요. 뭔가 안 될 때 제일 먼저 뭘 확인하는지, 그 다음엔 뭘 보는지. 이 순서가 자동화되면 온보딩 효율이 완전히 달라져요.
진단 루틴 4단계 (교육 전체의 뼈대)
# 1단계: 지금 누구로 로그인돼 있지?
gcloud auth list
# 2단계: 어떤 프로젝트/리전을 보고 있지?
gcloud config list
# 3단계: 필요한 API가 켜져 있지?
gcloud services list --enabled --filter="name:compute"
# 4단계: 설치/환경에 문제가 있나?
gcloud info
이 4줄이 gcloud 트러블슈팅의 80%를 커버해요. 교육에서 이걸 반복적으로 쓰게 만드는 게 핵심이에요.
교육 설계의 3대 원칙
| 원칙 | 설명 | 반영 방법 |
|---|---|---|
| 진단 먼저 | 명령을 가르치기 전에 “안 될 때 확인하는 순서”를 먼저 잡아요 | 모든 실습 시작 전 진단 4줄 실행 |
| 표준 절차 고정 | 같은 작업을 모든 팀원이 같은 순서로 하게 해요 | configuration 분리, 인증 분리를 규칙화 |
| 제출물 기반 | 따라하기만 하면 남는 게 없어요. 직접 만들어야 배워요 | 과제 5종을 제출물로 평가 |
2일 커리큘럼: 온보딩 압축형
2일 과정은 “빨리 실무에 투입해야 하는 신규 입사자”를 위한 압축형이에요. 목표는 단 하나: 첫 주부터 혼자서 기본 작업을 할 수 있게 만드는 것.
Day 1: 로컬 표준 확립 (8시간)
Day 1의 핵심은 “내 로컬 환경을 팀 표준에 맞추는 것”이에요. 설치부터 인증까지, 여기서 삐끗하면 이후 모든 실습이 멈춰요.
| 시간 | 주제 | 핵심 활동 | 학습 목표 |
|---|---|---|---|
| 09:00~10:00 | 설치·버전·컴포넌트 점검 | OS별 설치, gcloud --version, gcloud components list |
팀 표준 버전으로 통일 |
| 10:00~11:30 | gcloud init과 configuration 분리 |
프로젝트별 configuration 생성, activate, config list |
default는 건드리지 않는 습관 |
| 11:30~12:00 | 진단 루틴 반복 연습 | 의도적으로 잘못된 프로젝트/계정을 설정하고 진단 | 문제 발생 시 자체 해결 능력 |
| 13:00~14:30 | 인증 3종: 사용자/SA/ADC | auth login, activate-service-account, application-default login |
gcloud 인증 ≠ ADC 인증 이해 |
| 14:30~16:00 | ADC 트러블슈팅 실습 | 환경변수 혼선 재현, 해결 | GOOGLE_APPLICATION_CREDENTIALS 우선순위 체득 |
| 16:00~17:30 | 프로젝트/API enable/IAM 바인딩 | services enable, projects add-iam-policy-binding |
최소 권한 부여 절차 |
| 17:30~18:00 | Day 1 정리 + 과제 안내 | onboarding.sh 과제 설명 |
자동화 스크립트 작성 준비 |
Day 1 실습: ADC 혼선 재현하기
이 실습이 Day 1에서 제일 중요해요. “CLI는 되는데 코드가 안 되는” 상황을 직접 만들어보는 거예요.
# 1. gcloud 로그인 (CLI용)
gcloud auth login
# 2. 테스트 코드 실행 → 실패 (ADC가 없으니까)
python test_storage.py
# ERROR: Could not automatically determine credentials
# 3. ADC 설정 (코드 테스트용)
gcloud auth application-default login
# 4. 다시 실행 → 성공
python test_storage.py
# SUCCESS
# 5. 함정: 환경변수가 남아있으면?
export GOOGLE_APPLICATION_CREDENTIALS="/old/key.json"
python test_storage.py
# ERROR: 엉뚱한 계정으로 인증 시도 → 실패
# 6. 해결: 환경변수 정리
unset GOOGLE_APPLICATION_CREDENTIALS
이 과정을 직접 겪으면 “아, gcloud 로그인이랑 ADC는 다른 거구나”가 몸에 새겨져요.
Day 2: 대표 운영 시나리오 (8시간)
Day 2는 “실제로 현업에서 쓰는 작업”을 중심으로 돌아가요. 네트워킹, 배포, 스크립팅을 한 번씩 다 돌려보는 거예요.
| 시간 | 주제 | 핵심 활동 | 학습 목표 |
|---|---|---|---|
| 09:00~10:30 | VPC/방화벽 + IAP SSH | 커스텀 VPC 생성, 방화벽 규칙 추가, IAP SSH 접속 | 외부 IP 없는 VM 접속 패턴 |
| 10:30~12:00 | Cloud Run 배포 | --no-traffic 배포 → 태그 URL 검증 → 트래픽 분할 |
무중단 롤아웃/롤백 절차 |
| 13:00~14:30 | 스크립팅 기본 | --quiet, --format=json, 종료 코드 제어 |
“사람이 읽는 CLI”에서 “시스템이 실행하는 CLI”로 전환 |
| 14:30~16:00 | 간단한 배치 과제 | 여러 리소스 일괄 조회/생성 스크립트 작성 | 반복 작업 자동화 감각 |
| 16:00~17:00 | 트러블슈팅 종합 실습 | 5가지 고장 시나리오 해결 | 진단 루틴 숙련도 향상 |
| 17:00~18:00 | Day 2 정리 + 과제 설명 | deploy-cloudrun.sh 과제 안내 |
배포 자동화 스크립트 작성 준비 |
Day 2 실습: Cloud Run 무중단 롤아웃
# 1. 첫 번째 배포 (트래픽 100%)
gcloud run deploy my-service \
--image=gcr.io/PROJECT_ID/my-app:v1 \
--region=asia-northeast3
# 2. 새 버전 배포 (트래픽 0%)
gcloud run deploy my-service \
--image=gcr.io/PROJECT_ID/my-app:v2 \
--region=asia-northeast3 \
--no-traffic \
--tag=canary
# 3. 태그 URL로 검증
# canary---my-service-xxxxx.a.run.app 으로 접속해서 확인
# 4. 트래픽 10%로 열기
gcloud run services update-traffic my-service \
--region=asia-northeast3 \
--to-tags=canary=10
# 5. 문제 없으면 100%로
gcloud run services update-traffic my-service \
--region=asia-northeast3 \
--to-latest
# 6. 문제 생기면? 즉시 롤백
gcloud run services update-traffic my-service \
--region=asia-northeast3 \
--to-revisions=my-service-v1=100
5일 커리큘럼: 플랫폼 표준 정착형
5일 과정은 “팀 전체가 gcloud를 표준 도구로 쓰게 만드는” 본격 교육이에요. 2일 과정을 포함하되, GKE, 데이터 서비스, 키리스 CI, 보안까지 범위를 넓혀요.
5일 전체 일정 맵
| 일차 | 주제 | 핵심 키워드 | 과제 |
|---|---|---|---|
| Day 1 | 로컬 표준 확립 | 설치, 인증, configuration, ADC | onboarding.sh |
| Day 2 | 대표 운영 시나리오 | VPC, Cloud Run, 스크립팅 | deploy-cloudrun.sh |
| Day 3 | GKE 노드풀 운영 + 이미지/배포 표준 | GKE, 노드풀, 이미지 빌드 | project-bootstrap/ |
| Day 4 | Storage/BigQuery 비용 가드레일 + Pub/Sub 통합 테스트 | 데이터 서비스, 비용 통제 | bq-guardrails.md |
| Day 5 | 키리스 CI + Secret Manager + 보안 기준선 | WIF, KMS, 감사 로그 | security-baseline.md |
Day 3: GKE 노드풀 운영과 이미지/배포 표준
GKE를 CLI로 다루는 건 “클러스터”보다 “노드풀”이 핵심이에요. 노드풀이 비용과 성능의 실질적인 운영 단위거든요.
# 클러스터 생성 (Autopilot이 아닌 Standard 예시)
gcloud container clusters create my-cluster \
--zone=asia-northeast3-a \
--num-nodes=3 \
--machine-type=e2-standard-4
# 노드풀 추가 (워크로드 특성별 분리)
gcloud container node-pools create gpu-pool \
--cluster=my-cluster \
--zone=asia-northeast3-a \
--machine-type=n1-standard-8 \
--accelerator=type=nvidia-tesla-t4,count=1 \
--num-nodes=1
# 노드풀 크기 조정
gcloud container clusters resize my-cluster \
--zone=asia-northeast3-a \
--node-pool=gpu-pool \
--num-nodes=3 --quiet
# 노드풀 목록/상태 확인
gcloud container node-pools list \
--cluster=my-cluster \
--zone=asia-northeast3-a \
--format="table(name,config.machineType,initialNodeCount,status)"
이미지 표준화도 Day 3에서 다뤄요. 커스텀 이미지를 만들어 팀 전체가 동일한 베이스로 작업하게 하는 거예요.
# 현재 VM에서 이미지 생성
gcloud compute images create team-base-image \
--source-disk=template-vm \
--source-disk-zone=asia-northeast3-a \
--labels=team=platform,version=v1
# 이미지 목록 확인
gcloud compute images list \
--filter="labels.team=platform" \
--format="table(name,creationTimestamp,status)"
Day 4: Storage/BigQuery 비용 가드레일 + Pub/Sub 통합 테스트
데이터 서비스에서 가장 중요한 건 “비용 폭탄 방지”예요. 특히 BigQuery는 드라이런 없이 반복 쿼리를 돌리면 순식간에 비용이 불어나요.
BigQuery 비용 가드레일 실습
# 드라이런으로 스캔량 확인 (비용 예측)
bq query --use_legacy_sql=false --dry_run=true \
'SELECT * FROM `project.dataset.huge_table` WHERE date > "2026-01-01"'
# 결과: 예상 스캔 바이트 표시
# 최대 바이트 제한 걸고 실행
bq query --use_legacy_sql=false \
--maximum_bytes_billed=1000000000 \
'SELECT * FROM `project.dataset.huge_table` WHERE date > "2026-01-01"'
# 제한 초과 시 쿼리가 실행되지 않음 → 비용 안전
# 파티션 테이블 확인 (스캔량을 줄이는 근본 해결)
bq show --format=prettyjson project:dataset.huge_table | grep -A5 "timePartitioning"
Pub/Sub 에뮬레이터 실습
운영 환경에 영향을 주지 않고 통합 테스트를 돌리는 방법이에요.
# 에뮬레이터 설치 및 시작
gcloud components install pubsub-emulator
gcloud beta emulators pubsub-emulator start --project=test-project
# 환경변수 설정 (다른 터미널에서)
$(gcloud beta emulators pubsub-emulator env-init)
# 이 상태에서 테스트 코드 실행 → 로컬 에뮬레이터로 연결
python test_pubsub.py
Day 5: 키리스 CI + Secret Manager + 보안 기준선
5일 과정의 하이라이트예요. “키 파일 없이 CI를 돌리는 법”을 배우고, 보안 기준선을 세우는 거예요.
키리스(WIF) CI 인증 흐름
# 1. Workload Identity Pool 생성
gcloud iam workload-identity-pools create "github-pool" \
--project=PROJECT_ID \
--location="global" \
--display-name="GitHub Actions Pool"
# 2. Provider 설정 (GitHub OIDC)
gcloud iam workload-identity-pools providers create-oidc "github-provider" \
--project=PROJECT_ID \
--location="global" \
--workload-identity-pool="github-pool" \
--display-name="GitHub Provider" \
--attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
--issuer-uri="https://token.actions.githubusercontent.com"
# 3. 서비스계정에 바인딩
gcloud iam service-accounts add-iam-policy-binding \
"ci-sa@PROJECT_ID.iam.gserviceaccount.com" \
--project=PROJECT_ID \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/github-pool/attribute.repository/ORG/REPO"
이렇게 설정하면 GitHub Actions에서 키 파일 없이 GCP에 인증할 수 있어요. 키가 없으니 유출도 없고, 토큰이 자동 만료되니 관리 부담도 없어요.
Secret Manager 주입
# 시크릿 생성
echo -n "my-db-password" | gcloud secrets create db-password \
--replication-policy="automatic" \
--data-file=-
# 시크릿 조회 (런타임 주입용)
gcloud secrets versions access latest --secret="db-password"
# Cloud Build에서 사용 (cloudbuild.yaml)
# availableSecrets 필드로 빌드 시점에 주입
KMS Data Access 로그 활성화
# 감사 로그 정책 확인
gcloud projects get-iam-policy PROJECT_ID \
--format=json > policy.json
# Data Access 로그가 KMS에 대해 활성화되어 있는지 확인
# 필요시 auditConfigs에 cloudkms.googleapis.com 추가
“누가 언제 복호화했는지”를 추적하려면 Data Access 로그를 반드시 켜야 해요. 기본이 비활성화일 수 있으니까 명시적으로 활성화하는 거예요.
실습 과제 패키지: 제출물별 학습 목표와 평가 기준
교육의 성패는 결국 “뭘 만들어봤는가”에 달려 있어요. 5개 과제를 제출물로 만들면 학습 결과가 눈에 보여요.
과제 1: onboarding.sh
| 항목 | 내용 |
|---|---|
| 학습 목표 | 설치 검증 + configuration 생성 + 필수 API enable 자동화 |
| 제출물 | 실행 가능한 셸 스크립트 1개 |
| 핵심 요구사항 | gcloud 버전 확인 → configuration 생성/활성화 → 프로젝트 설정 → 필수 API enable |
| 평가 기준 | 스크립트가 idempotent(여러 번 실행해도 같은 결과)인가, 에러 처리가 있는가 |
#!/bin/bash
# onboarding.sh 예시 골격
set -euo pipefail
CONFIG_NAME="${1:-my-project-dev}"
PROJECT_ID="${2:-my-project-id}"
REGION="${3:-asia-northeast3}"
echo "=== gcloud 버전 확인 ==="
gcloud --version
echo "=== Configuration 생성 ==="
gcloud config configurations create "$CONFIG_NAME" 2>/dev/null || \
echo "Configuration '$CONFIG_NAME' 이미 존재 — 건너뜀"
gcloud config configurations activate "$CONFIG_NAME"
gcloud config set project "$PROJECT_ID"
gcloud config set compute/region "$REGION"
gcloud config set compute/zone "${REGION}-a"
echo "=== 필수 API 활성화 ==="
APIS=(
"compute.googleapis.com"
"run.googleapis.com"
"container.googleapis.com"
"cloudbuild.googleapis.com"
)
for api in "${APIS[@]}"; do
gcloud services enable "$api" --project="$PROJECT_ID" --quiet
echo " ✓ $api"
done
echo "=== 최종 검증 ==="
gcloud config list
gcloud auth list
gcloud services list --enabled --filter="name:(${APIS[*]// / OR name:})"
echo "=== 온보딩 완료 ==="
과제 2: project-bootstrap/
| 항목 | 내용 |
|---|---|
| 학습 목표 | 프로젝트 생성 또는 템플릿화, 라벨/태그 규약, IAM 바인딩 자동화 |
| 제출물 | 폴더 1개(스크립트 + 설정 파일) |
| 핵심 요구사항 | 프로젝트 생성 → 라벨 적용 → IAM 그룹 바인딩 → 결과 검증 |
| 평가 기준 | 네이밍 규칙 문서화, 최소권한 원칙 반영, 재실행 안전성 |
과제 3: deploy-cloudrun.sh
| 항목 | 내용 |
|---|---|
| 학습 목표 | 무중단 롤아웃(0%→10%→100%)과 롤백 절차 자동화 |
| 제출물 | 실행 가능한 배포 스크립트 + 롤백 스크립트 |
| 핵심 요구사항 | --no-traffic 배포 → 태그 URL 검증 → 점진 트래픽 이동 → 롤백 |
| 평가 기준 | 각 단계에서 검증(health check)이 포함되어 있는가, 실패 시 자동 롤백 로직이 있는가 |
과제 4: bq-guardrails.md
| 항목 | 내용 |
|---|---|
| 학습 목표 | BigQuery 반복 쿼리의 비용 가드레일 설계 |
| 제출물 | 체크리스트 문서 1개 |
| 핵심 요구사항 | 드라이런 절차, --maximum_bytes_billed 상한선 기준, 파티션/클러스터링 규칙 |
| 평가 기준 | 팀에서 바로 적용할 수 있는 수준인가, 비용 임계값이 명확한가 |
체크리스트 예시 항목
| 항목 | 기준 | 확인 방법 |
|---|---|---|
| 드라이런 필수 | 1GB 초과 스캔 쿼리는 반드시 드라이런 선행 | --dry_run=true 결과 확인 |
| 최대 바이트 제한 | 개발: 10GB, 스테이징: 50GB, 프로덕션: 100GB | --maximum_bytes_billed 설정 |
| 파티션 설계 | 시계열 데이터는 일자 파티셔닝 필수 | bq show --format=prettyjson |
| 클러스터링 | 자주 필터하는 컬럼 기준으로 클러스터링 적용 | 테이블 스키마 확인 |
과제 5: security-baseline.md
| 항목 | 내용 |
|---|---|
| 학습 목표 | 키리스 운영 원칙, 감사 로그 활성화 범위 설계 |
| 제출물 | 보안 기준선 문서 1개 |
| 핵심 요구사항 | 키 생성 금지 정책, WIF 적용 원칙, 감사 로그 활성화 범위 |
| 평가 기준 | 조직정책 반영 여부, 예외 처리 프로세스가 명확한가 |
보안 기준선 필수 포함 항목
## 필수 포함 섹션
### 1. 서비스계정 키 정책
- 기본: 키 생성 금지 (iam.disableServiceAccountKeyCreation)
- 예외: 승인 프로세스 정의
- 기존 키: 회전 주기/폐기 계획
### 2. 키리스 인증 표준
- 로컬 개발: 사용자 로그인 + ADC
- CI/CD: WIF(OIDC) 기반 단기 토큰
- 운영 자동화: impersonation
### 3. 감사 로그
- KMS Data Access 로그: 활성화 필수
- 보관 정책: 싱크 대상/보관 기간
- 알림 규칙: 비정상 접근 패턴
커리큘럼 운영 팁: 실패를 줄이는 실전 노하우
교육 전 준비: 환경 사전 점검
교육 당일에 설치 문제로 1~2시간 날리는 건 정말 흔해요. 사전 점검이 필수예요.
| 점검 항목 | 확인 방법 | 흔한 문제 |
|---|---|---|
| gcloud 설치 완료 | gcloud --version |
PATH 미반영, 재시작 필요 |
| Python 호환성 | gcloud info 확인 |
시스템 Python 버전 충돌 |
| 네트워크 접근 | gcloud auth login 시도 |
프록시/방화벽 차단 |
| 프로젝트 권한 | gcloud projects list |
IAM 미부여, 빌링 미연결 |
교육 중: “의도적 실패” 시나리오 5개
이건 진짜 꿀팁이에요. 일부러 실패하게 만들어서 진단 루틴을 쓰게 하는 거예요.
- 잘못된 프로젝트로 작업 시도: configuration 전환 없이 다른 프로젝트 리소스에 접근
- API 미활성화 상태에서 명령 실행: “API not enabled” 에러 →
services enable로 해결 - ADC 없이 코드 실행: “Could not determine credentials” →
application-default login - 만료된 인증으로 작업: 세션 만료 재현 →
auth login재실행 - 잘못된 리전/존 설정: 다른 존의 리소스 접근 시도 →
config set수정
교육 후: 진단 루틴 정착 확인
# 교육 수료 체크 명령 (수강자가 직접 실행)
echo "=== 진단 루틴 체크 ==="
gcloud auth list --format="value(account)" | head -1
gcloud config get-value project
gcloud config configurations list --format="table(name,is_active,properties.core.project)"
echo "=== 체크 완료 ==="
교육 후 정착까지: 체크리스트와 후속 조치
교육이 끝나고 나서가 진짜 시작이에요. 배운 걸 실무에 정착시키려면 후속 조치가 있어야 해요.
교육 후 1주: 정착 체크리스트
| 항목 | 확인 기준 | 담당 |
|---|---|---|
| configuration 분리 | 최소 2개(dev/prod) configuration 생성 완료 | 수강자 |
| ADC 설정 | 로컬 코드 테스트에서 ADC로 인증 성공 | 수강자 |
| 진단 루틴 | 문제 발생 시 4단계 루틴으로 자체 해결 1건 이상 | 수강자 |
| 과제 제출 | 과제 5종 중 최소 3종 제출 | 교육 담당 |
교육 후 1개월: 표준 준수 확인
| 항목 | 확인 방법 | 기대 수준 |
|---|---|---|
| 키 파일 미사용 | 로컬에 JSON 키 파일 없음 | 100% |
| configuration 활용 | 프로젝트 전환 시 configuration 사용 | 90% 이상 |
| 스크립트화 | 반복 작업을 스크립트로 작성 | 1건 이상 |
핵심 정리
1. gcloud 교육은 "명령 암기"가 아니라 "진단 루틴(auth list → config list → services list → info)"을 몸에 익히게 하는 거예요
2. 2일 커리큘럼은 온보딩 속도에, 5일 커리큘럼은 플랫폼 표준 정착에 초점을 맞춰요
3. 실습 과제 5종을 제출물로 만들면 교육 성과가 눈에 보이고, idempotent한 스크립트 작성 습관도 함께 잡혀요
4. 교육의 진짜 효과는 "교육 후 1주~1개월"의 정착 과정에서 결정되니까, 후속 체크리스트가 반드시 필요해요
FAQ
Q. 2일 과정과 5일 과정 중 어떤 걸 선택해야 하나요?
A. 빠른 실무 투입이 목표라면 2일, 팀 전체의 표준을 세우려면 5일이에요. 신규 입사자 개별 온보딩은 2일로 충분하고, 팀이나 조직 단위로 gcloud 표준을 정착시키려면 5일을 권장해요. 5일 과정은 GKE, 데이터 서비스, 키리스 CI까지 다루니까 플랫폼 엔지니어링 팀에 특히 적합해요.
Q. 교육 참가자에게 필요한 사전 지식은 뭔가요?
A. 리눅스 기본 명령어(cd, ls, cat)와 터미널 사용에 익숙하면 돼요. 클라우드 경험이 전혀 없어도 괜찮지만, 최소한 “프로젝트가 뭔지”, “API가 뭔지” 정도의 개념은 30분 사전 세션으로 잡아주는 게 좋아요.
Q. 교육용 GCP 프로젝트는 어떻게 준비하나요?
A. 교육 전용 프로젝트를 별도로 만들고, 교육 참가자에게 Editor 수준의 권한을 주는 게 가장 안전해요. 교육이 끝나면 리소스를 정리하고 프로젝트를 초기화하면 돼요. 비용이 걱정되면 예산 알림을 걸어두면 좋아요.
Q. onboarding.sh 과제에서 “idempotent”하게 만들라는 게 무슨 뜻이에요?
A. 스크립트를 10번 실행해도 1번 실행한 것과 같은 결과가 나와야 한다는 뜻이에요. 예를 들어 configuration을 만드는 부분에서 “이미 존재하면 건너뛰기” 로직이 있어야 하고, API enable도 이미 활성화된 걸 다시 enable해도 에러가 나지 않게 해야 해요.
Q. ADC 트러블슈팅 실습에서 테스트 코드는 어떻게 준비하나요?
A. 가장 간단한 건 Cloud Storage 버킷 목록을 조회하는 Python 코드예요. google-cloud-storage 패키지 하나만 설치하면 되고, 5줄이면 충분해요. 중요한 건 코드가 ADC를 통해 인증한다는 걸 체험하는 거라서, 복잡한 코드는 필요 없어요.
Q. 5일 과정 Day 5의 WIF 설정이 너무 복잡한데, 꼭 실습해야 하나요?
A. 전체 설정을 하나하나 실습하기보다는 “흐름을 이해”하는 데 초점을 맞추면 돼요. 강사가 미리 Pool/Provider를 세팅해두고, 수강자는 서비스계정 바인딩과 GitHub Actions에서 인증하는 부분만 직접 해보는 것도 좋은 방법이에요.
Q. BigQuery 비용 가드레일에서 --maximum_bytes_billed 값은 어떻게 정하나요?
A. 팀의 평균 쿼리 스캔량을 기준으로 잡으면 돼요. 보통 개발 환경은 10GB, 스테이징은 50GB, 프로덕션은 100GB 정도로 시작해요. 처음에는 넉넉하게 잡고, 실제 사용 패턴을 보면서 조정하는 게 현실적이에요.
Q. 교육 과제 제출은 어떤 형태로 받는 게 좋나요?
A. Git 저장소에 PR로 제출하는 게 가장 좋아요. 코드 리뷰도 되고, 버전 관리도 되고, 팀 내에서 “우리 팀의 표준 스크립트”로 발전할 수도 있거든요. 최소한 스크립트는 Git, 문서는 Confluence나 Notion 같은 공유 도구에 올리게 하면 돼요.
Q. 교육 후 정착이 잘 안 되는 가장 큰 이유는 뭔가요?
A. “교육에서 배운 것”과 “실무에서 쓰는 것” 사이에 갭이 있기 때문이에요. 교육에서 만든 onboarding.sh를 실제 팀 온보딩에 적용하고, deploy-cloudrun.sh를 실제 배포 파이프라인에 넣는 식으로 연결해야 해요. 교육 과제를 “실무 산출물”로 만드는 게 정착의 핵심이에요.
Q. 소규모 팀(3~5명)도 이 커리큘럼이 필요한가요?
A. 규모가 작을수록 표준의 효과가 빨리 나타나요. 3명이 각자 다른 방식으로 gcloud를 쓰면, 누가 빠져도 인수인계가 안 돼요. 2일 과정만이라도 돌리면 “우리 팀은 이렇게 한다”는 기준이 생겨서 장기적으로 시간을 엄청 아낄 수 있어요.
참고 자료 (References)
데이터 출처
| 출처 | 설명 | 링크 |
|---|---|---|
| Google Cloud SDK 설치 가이드 | 설치, 업데이트, 버전 관리 공식 문서 | docs.google.com/sdk/docs/install-sdk |
| gcloud 인증 가이드 | CLI 인증 방식 및 ADC 관리 | docs.google.com/sdk/docs/authorizing |
| ADC 개요 | Application Default Credentials 작동 방식 | docs.google.com/docs/authentication/application-default-credentials |
| configurations 관리 | gcloud 구성 분리 및 전환 | docs.google.com/sdk/docs/configurations |
| SA 키 관리 베스트프랙티스 | 서비스계정 키 최소화 권고 | cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys |
| WIF 베스트프랙티스 | Workload Identity Federation 설정 | cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation |
| Scripting gcloud | 비대화형 실행, 출력 포맷, 종료 코드 | docs.google.com/sdk/docs/scripting-gcloud |
| Cloud Run 점진적 롤아웃 | 트래픽 분할/롤백 블로그 | cloud.google.com/blog/products/serverless/cloud-run-now-supports-gradual-rollouts-and-rollbacks |
| KMS 감사 로깅 | KMS Data Access 로그 | docs.google.com/kms/docs/audit-logging |
| SCC 데이터 내보내기 | Security Command Center findings 내보내기 | docs.google.com/security-command-center/docs/how-to-export-data |
핵심 인용
“After you install the gcloud CLI, initialize it to authorize access to Google Cloud and set up a default configuration.” — Google Cloud CLI 설치 가이드
“The gcloud CLI provides support for managing Application Default Credentials (ADC) with the gcloud auth application-default command group.” — gcloud 인증 가이드
다음 편 예고
[11편] 결론: CLI는 도구가 아니라 운영 시스템이다
- 잘 쓰는 팀과 못 쓰는 팀의 차이가 “표준의 유무”라는 걸 종합 정리해요
- 인증 분리 + 키리스 + configuration 강제가 어떻게 사고를 구조적으로 줄이는지 살펴봐요
- 이해관계자별(플랫폼/SRE, 보안, 개발팀, 교육 담당자) 실행 제언으로 시리즈를 마무리해요