Google PCA: DevOps, 딜리버리 엔지니어링 및 코드형 인프라 — 학습 가이드

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Architect — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Google Cloud에서의 DevOps, Delivery Engineering, Infrastructure as Code(IaC)는 강력한 추적성, 자동화, 안전성을 바탕으로 신뢰할 수 있는 변경 사항을 지속적으로 제공하는 데 중점을 둡니다. 아키텍처는 짧은 피드백 주기, 반복 가능한 배포, 불변의 인프라, 조직과 함께 확장되는 가드레일에 최적화되어야 합니다. Google Cloud에서는 일반적으로 소스 제어 모범 사례, Cloud Build를 사용한 CI, Artifact Registry를 사용한 아티팩트 관리, Cloud Deploy를 사용한 CD, 매니페스트/Helm/Kustomize를 사용하는 GKE 기반 Kubernetes, 구성 드리프트 제어를 위한 GitOps, Terraform 또는 Google Cloud 배포 템플릿을 사용한 IaC를 결합합니다. 운영 우수성을 달성하려면 점진적 배포(blue-green, canary, 트래픽 분할, 기능 플래그), 소프트웨어 공급망 제어(스캔, 출처, 서명), 테스트 및 배포 게이트, 그리고 속도, 안전성, 감사 가능성, 소유권의 균형을 맞추는 거버넌스가 필요합니다.

CI/CD, 소스 제어, 릴리스 오케스트레이션

CI/CD 원칙
- master/main 브랜치를 항상 릴리스 가능한 상태로 유지하고, 수명이 짧은 기능 브랜치를 사용하는 트렁크 기반 개발을 실천합니다.
- 모든 변경 사항에 대해 빌드, 테스트, 스캔, 패키징을 자동화하고, 필수 승인 및 상태 확인이 포함된 코드 리뷰를 요구합니다.
- 커밋 → 빌드 → 아티팩트 다이제스트 → 환경 릴리스까지 완전한 추적성을 유지하고, commit SHA와 빌드 메타데이터를 이미지 및 배포 주석에 포함시킵니다.
- 실패 모드: 수명이 긴 브랜치, 수동 핸드오프, 불안정한 테스트, 재현 불가능한 빌드, 아티팩트 불변성 부재는 예기치 못한 문제와 롤백으로 이어집니다.
소스 제어, 브랜칭, 풀 리퀘스트, 코드 리뷰, 추적성
- 보호된 브랜치, 필수 리뷰, 커밋 서명을 사용합니다. 릴리스에 태그를 지정하고 병합 커밋에서 생성된 변경 로그를 유지합니다.
- CODEOWNERS 및 서비스 소유권 메타데이터를 적용하여 도메인 스튜어드십을 강제합니다.
- 커밋을 이슈 및 배포에 연결하고, CI/CD 로그와 메타데이터를 Cloud Logging 및 BigQuery로 내보내 감사 및 DORA 측정항목에 활용합니다.
Cloud Build
- 트리거: Git 이벤트(브랜치, 태그, PR), 수동 호출 또는 Pub/Sub을 통해 실행됩니다. 버전, 환경, 기능 플래그에 대한 대체(substitution)를 사용하여 파이프라인을 매개변수화하고 DRY 원칙을 유지합니다.
- 빌드 단계: 공식 빌더 또는 직접 정의한 컨테이너를 실행합니다. 독립적인 단계는 병렬로 실행하여 지연 시간을 줄이고, 언어 종속성에 대한 캐시를 사용하여 빌드 속도를 높입니다.
- 아티팩트: 불변의 태그와 다이제스트를 사용하여 이미지를 Artifact Registry에 푸시합니다. SBOM과 빌드 로그를 저장하고, 테스트 보고서를 빌드 아티팩트로 게시합니다.
- 안전한 빌드 ID: 최소 권한의 전용 서비스 계정으로 Cloud Build를 실행하고, 가능하면 리포지토리별 Workload Identity Federation을 사용합니다. 프라이빗 네트워크나 이그레스(egress)를 피하려면 Private Pools를 사용합니다. 서비스 계정 키를 제한하고 수명이 짧은 토큰을 선호합니다.
- 예시 (요약):
  - cloudbuild.yaml:
    - steps:
      - name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
      - name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
    - substitutions:
      - _ENV=staging
Cloud Deploy
- 릴리스 및 대상: 여러 대상(예: dev → staging → prod)에 걸친 프로모션으로 딜리버리 파이프라인을 모델링합니다. 릴리스는 불변의 아티팩트 참조와 배포 구성을 캡처합니다.
- 승인 및 프로모션: 역할 기반 제어를 통해 수동 또는 자동 승인을 요구합니다. 아티팩트와 매니페스트가 변경되지 않으므로 프로모션은 빠르고 위험이 낮은 작업이어야 합니다.
- Canary 출시 및 롤백: 점진적 노출, 상태 확인, SLO 오류 시 자동 롤백 전략을 정의합니다. 모든 프로모션, 승인자, 검증 결과를 감사용으로 기록합니다.
- 실패 모드: 환경 간 가변 아티팩트, 프로덕션 환경에서의 수동 kubectl 사용, 배포 전 검증 생략은 드리프트와 추적 불가능한 장애를 유발합니다.

코드형 인프라(IaC) 및 구성 관리

Terraform
- 모듈: 재사용 가능한 패턴(예: VPC, GKE 클러스터, 서비스 계정, IAM 바인딩)을 캡처합니다. 모듈 릴리스를 버전 관리하고 고정(pin)합니다. 내부 모듈 레지스트리를 게시합니다.
- 원격 상태(Remote state): 버전 관리, 보관 정책, CMEK를 사용하여 Cloud Storage에 저장합니다. 잠금(locking)을 활성화합니다. IAM 및 균일한 버킷 수준 액세스를 통해 액세스를 제한합니다. 상태를 백업합니다.
- 계획(Plan) 및 정책 확인: CI에서

undefined

를 실행합니다. 계획에 대한 사람의 검토를 요구합니다. 코드형 정책(OPA/Conftest, Sentinel 또는 Policy Controller)을 적용하여 위반(예: 공개 버킷, 광범위한 IAM 바인딩)을 차단합니다.

환경 승격: 환경별로 별도의 작업공간(workspace) 또는 별도의 상태/백엔드를 사용합니다. 동일한 모듈 버전과 변수를 통해 변경사항을 승격합니다. 클라우드 리소스를 절대 수동으로 편집하지 않습니다. 민감한 입력은 Secret Manager 또는 자동화에서 가져와야 하며, 절대 하드코딩해서는 안 됩니다.
실패 모드: 상태(state)에 보안 비밀 유출, 잠금 없는 동시 변경, 대역 외(out-of-band) 편집으로 인한 드리프트(drift), destroy/replace를 중단시키는 암시적 종속성.
Google Cloud 배포 템플릿 및 선언적 구성
- 선언적 도구(Terraform, Google Cloud Deployment Manager 또는 Kubernetes Configuration as Code)를 사용하여 명령형 단계의 스크립트가 아닌 원하는 상태를 정의합니다.
- 불변 인프라(Immutable infrastructure) 선호: 인스턴스 템플릿을 교체하고 MIG를 롤링합니다. 파드를 제자리에서 패치하는 대신 새로운 GKE Deployment를 롤아웃합니다. 불변 패턴은 롤백과 감사를 간단하게 만듭니다.
- Deployment Manager는 Google Cloud 리소스에 대한 Jinja/Python 템플릿을 지원하지만 Google Cloud로 제한됩니다. Terraform은 더 넓은 생태계와 정책 도구를 제공합니다. 조직의 표준화 및 기술 스택에 따라 선택합니다.
Kubernetes 매니페스트, Helm, Kustomize 및 GitOps
- 매니페스트: 환경 오버레이와 함께 기본 템플릿을 유지합니다. 환경에 따라 달라져야 하는 것(예: 복제본 수, 리소스 제한, 엔드포인트)만 매개변수화합니다.
- Helm: 차트(chart)를 사용하여 서비스를 패키징, 템플릿화 및 버전 관리합니다. 종속성을 잠급니다(lock). 이미지 다이제스트를 고정합니다(pin). 실패 모드: 과도한 템플릿화는 의도를 모호하게 하고 검토를 복잡하게 만듭니다.
- Kustomize: 오버레이(기본 + 환경별 패치)를 관리합니다. 순수 Kubernetes로 충분할 때 Helm보다 간단합니다.
- GitOps: 컨트롤러(예: Config Sync, Argo CD, Flux)가 클러스터를 Git에 있는 원하는 상태와 지속적으로 일치시킵니다. 모든 변경은 검토 및 감사 추적이 있는 PR이 됩니다. 드리프트(drift)를 자동으로 감지하고 수정합니다.

점진적 배포, 공급망, 테스트 및 검증

기능 플래그(Feature flag) 및 트래픽 관리
- 기능 플래그는 배포와 출시를 분리합니다. 점진적 노출, A/B 테스트, 비상 비활성화 스위치(kill switch)에 사용합니다. 플래그 상태가 버전 관리되고 감사 가능한지 확인합니다. 오래된 플래그는 제거합니다.
- 트래픽 분할: Cloud Run에서는 리비전 간에 백분율 기반 라우팅을 사용합니다. GKE에서는 가중치 기반 라우팅을 지원하는 서비스 메시 또는 인그레스 컨트롤러를 사용합니다. 단일 호스트 이름/TLS 하의 API의 경우, HTTP(S) Load Balancer 뒤에 경로별로 별도의 백엔드 서비스를 유지합니다. 경로 라우팅은 단일 URL과 인증서를 유지하면서 이전/새 버전을 깔끔하게 격리합니다.
- 블루-그린: 두 개의 프로덕션 준비 스택을 실행합니다. 부하 분산기, 서비스 셀렉터 또는 Cloud Run 리비전 트래픽을 통해 트래픽을 원자적으로 전환합니다. 즉시 롤백이 가능하지만 정상 상태 비용이 두 배가 됩니다.
- 카나리(Canary) 및 점진적 롤아웃: 골든 시그널과 비즈니스 KPI를 측정하면서 작은 부분부터 트래픽을 점진적으로 늘립니다. 성능 저하 시 자동 롤백을 자동화합니다.
소프트웨어 공급망 제어
- 이미지 스캔: Artifact Analysis 취약점 스캔을 활성화합니다. 심각한 취약점이나 알려진 문제가 있는 기본 이미지에 대해 빌드를 실패시킵니다. 패치 주기를 유지합니다.
- 출처(Provenance) 및 서명: Cloud Build에서 SLSA 호환 빌드 출처를 생성합니다. Cosign으로 아티팩트에 서명합니다. 배포 전에 증명(attestation)을 요구하는 Binary Authorization 정책을 적용합니다.
- 종속성 관리: 버전과 다이제스트를 고정하고, SBOM을 유지하며, 중요한 종속성을 벤더링(vendor)하고, 체크섬을 확인합니다. 실패 모드에는 전이 종속성(transitive dependency) 드리프트와 손상된 레지스트리가 포함됩니다.
테스트 피라미드, 배포 게이트 및 배포 후 검증
- 피라미드: 빠른 단위 테스트를 강조합니다. 통합 및 계약 테스트를 추가합니다. 대상이 명확한 엔드투엔드 테스트를 실행합니다. 테스트 데이터를 현실적으로 유지하고 비식별화합니다(Cloud DLP를 사용하여 PII 제거).
- 배포 게이트: 승격 전에 테스트 통과율, 취약점 상태, 정책 준수, 코드 검토에 대한 임계값을 적용합니다. 위험이 높을 때 프로덕션 배포에 대한 수동 승인을 요구합니다.
- 배포 후 검증: Cloud Monitoring, Error Reporting, Trace를 사용하여 스모크 테스트, 합성 확인(synthetic check), 카나리 분석을 실행합니다. KPI가 저하되면 자동 롤백을 트리거하고 캡처된 컨텍스트와 함께 인시던트를 엽니다.
- 운영 진단: 필요한 곳에 Cloud Logging 에이전트를 배포하고, Trace 및 Debugger를 위해 서비스를 계측합니다. 안전한 문제 해결을 위한 런북(runbook)을 유지합니다(예: 최소한의 다운타임으로 영구 디스크를 온라인으로 크기 조정하고

undefined

실행).

거버넌스, 안전성, 감사 가능성 및 소유권

안전성을 갖춘 속도
- 수명이 짧은 PR과 필수 리뷰를 사용하는 트렁크 기반 개발은 품질 저하 없이 흐름을 유지합니다.
- 일반적인 스택(GKE + Helm, Cloud Run, Dataflow)을 위한 템플릿을 갖춘 셀프서비스 파이프라인은 팀의 속도를 높이고 개별 구현에 따른 리스크를 줄입니다.
접근, ID 및 승인
- 파이프라인 단계별로 최소 권한 원칙과 Workload Identity Federation을 사용하는 전용 서비스 계정을 사용하고, 정적 키 사용을 피합니다.
- 직무 분리: 개발자는 빌드하고, 릴리스 관리자는 프로덕션 환경으로의 프로모션을 승인하며, 런타임 운영자는 런타임 구성 및 예산을 소유합니다.
감사 가능성 및 규정 준수
- Cloud Build, Cloud Deploy, Cloud Audit Logs를 BigQuery로 내보냅니다. 데이터세트 뷰와 IAM을 사용하여 범위가 지정된 감사 데이터를 감사자와 공유합니다. 정책에 따라 Cloud Storage 또는 BigQuery로 내보내 장기적으로 측정항목을 보관합니다.
- 배포 메타데이터에 아티팩트 다이제스트를 기록합니다. 각 릴리스에 대한 엔드투엔드 SBOM 및 출처(provenance)를 유지합니다.
소유권 및 SLO
- 각 서비스에는 소유자, 온콜 로테이션, SLO 및 릴리스를 제어하는 오류 예산이 있습니다. 배포 정책을 SLO 준수와 연결하여 예산이 소진되었을 때 변경 사항이 푸시되는 것을 방지합니다.
일반적인 트레이드오프와 함정
- 블루-그린 배포의 비용 vs 롤백 속도, 카나리 배포의 신뢰도 vs 전체 릴리스까지의 시간.
- GitOps의 일관성 vs 운영 유연성. 로깅 및 후속 PR을 통해 통제된 긴급 접근(break-glass)을 허용합니다.
- 과도한 템플릿 사용은 가독성을 떨어뜨립니다. 구성은 명시적이고 최소한으로 유지합니다.
- 중앙 정책은 잘못된 구성을 방지하지만, 불필요하게 팀을 막지 않도록 반복적으로 롤아웃해야 합니다.

실용적인 문제 시나리오

회사: Borealis Fintech

과제: Borealis는 새로운 결제 API를 GKE에 출시하면서, 동일한 호스트 이름과 TLS 하에서 v1 및 v2를 유지해야 합니다. 개발, 스테이징, 프로덕션 전반에 걸쳐 엔드투엔드 추적 가능성, 카나리 및 기능 플래그를 사용한 점진적 배포, 강력한 공급망 제어, 감사된 프로모션이 필요합니다. 또한 클러스터 구성에는 GitOps를, 플랫폼 리소스에는 Terraform을 사용하고자 합니다.

접근 방식: