Google PCD: 지속적인 배포, 구성 및 인프라 자동화 — 학습 가이드

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

코드형 인프라(Infrastructure as Code)와 GitOps

Terraform

• 구성 및 모듈: 명확한 입력/출력을 가진 재사용 가능한 모듈로 분리하고 시맨틱 버전을 사용합니다. 공유 레포지토리나 레지스트리에 모듈을 게시하고, 예상치 못한 변경을 피하기 위해 버전을 고정합니다.
• 상태(State): 원격 상태 관리를 위해 GCS 백엔드를 사용하며, 버킷 수준 IAM, 객체 버전 관리, CMEK를 함께 사용합니다. 사람이 직접 상태 파일을 수정하지 못하도록 보호하고 상태 암호화를 보장합니다. apply 시점에 Secret Manager에서 민감 정보를 읽어오고 데이터 소스는 꼭 필요한 경우에만 사용하여 상태 파일에 민감 정보가 저장되는 것을 방지합니다.

undefined

• 계획(Plan) 및 적용(Apply): terraform plan 실행 시 -out 옵션을 사용하고, 사람 또는 자동화된 게이트(gate)에서 diff를 검토합니다. 이전에 승인된 계획만 적용합니다. 드리프트(drift) 탐지 작업에서는 -refresh-only 또는 -detailed-exitcode를 사용합니다.
• 환경 분리: 환경별로 별도의 프로젝트, 상태 버킷, 서비스 계정을 사용합니다. 복잡한 조직의 경우, 작업 공간(workspace)보다 변수 파일을 사용하는 환경별 디렉터리 구조를 선호합니다. 환경 간에 상태를 절대 공유하지 마십시오.
• 실패 모드: 동시 적용(apply)은 상태를 손상시킬 수 있으므로 CI/CD와 잠금(locking, GCS는 객체 사전 조건(precondition) 사용)을 통해 직렬화를 강제합니다. 콘솔에서의 수동 변경은 드리프트(drift)를 유발하므로 직접적인 변경을 제한하고 주기적으로 plan 작업을 실행합니다.

Kubernetes 선언적 구성

• 매니페스트(Manifest): Kubernetes 오브젝트를 선언적으로 유지하고, 프로덕션 플로우에서 kubectl 명령형 사용을 지양합니다. 이미지 다이제스트(digest)와 리소스 요청/제한을 고정합니다.
• Kustomize: base + overlay 구조를 사용하여 차트를 포크(fork)하지 않고 환경별 패치를 처리합니다. kustomization.yaml (overlay):

undefined

• Helm: 환경별로 values 파일을 사용하고, 우선순위를 문서화합니다(명령줄 값이 values 파일 값을 재정의하고, values 파일 값은 차트 기본값을 재정의함). CI에서 템플릿 및 렌더링(skaffold render 또는 helm template)을 수행하여 배포 시점의 구성이 불변(immutable)이 되도록 합니다.
• GitOps: 원하는 상태(desired state)를 Git에 저장합니다. Cloud Deploy 또는 Config Sync를 사용하여 클러스터를 Git의 상태와 일치시킵니다. PR이 감사 추적 및 정책 검사를 포함하는 변경 관리의 접점이 됩니다. Git에서 추적되지 않는 kubectl exec을 통한 수정을 지양합니다.

릴리스 안전성, 구성 및 거버넌스

피처 플래그와 런타임 구성

• 피처 플래그는 배포와 릴리스를 분리합니다. 비활성 코드를 배포하고 코호트, 백분율 또는 리전별로 활성화할 수 있습니다. 플래그 정의는 Firestore, Memorystore와 같이 지연 시간이 짧은 고가용성 시스템에 저장하고 짧은 TTL로 캐시합니다. 추적성을 위해 평가를 로깅합니다.
• 점진적 출시: 장애 반경(blast radius)을 최소화하기 위해 트래픽 분할(Cloud Run) 또는 카나리 서브셋(GKE)을 피처 플래그와 결합합니다. 상태 측정항목과 SLO 기반 자동 롤백 트리거를 사용합니다.
• 안전한 롤백: 피처 플래그를 통한 빠른 비활성화를 선호합니다. 바이너리 롤백의 경우, 마지막으로 정상이었던 릴리스를 승격하거나 이전 매니페스트 다이제스트를 다시 적용합니다.

환경 변수, 우선순위, 보안 비밀

• 우선순위는 일반적으로 런타임 플래그 > 환경 변수 > 구성 파일 > 코드 기본값 순서를 따릅니다. 이를 문서화하고 모든 서비스에 걸쳐 표준화합니다.
• ConfigMaps와 환경 변수로 구성을 주입하고, 민감한 값에는 Secret Manager 또는 Kubernetes Secrets를 사용합니다. 정기적으로 순환하고 이미지에 보안 비밀을 포함(baking)하지 마십시오.
• 보안 비밀 주입 예시:
  • Cloud Run 환경 변수:

undefined

• GKE Secret Manager CSI:

undefined

CI/CD의 품질 게이트

• 단위 테스트는 모든 커밋에서 실행되며, 빠른 피드백이 가장 중요합니다.
• 통합 테스트는 시드 데이터가 있는 임시 환경 또는 샌드박스에서 실행됩니다.
• 보안 검사: SAST, 종속 항목 스캔, 컨테이너 취약점 스캔, IaC 정책 검사(Conftest, Policy Controller). 중요한 발견 사항이 있을 경우 병합 또는 승격을 차단합니다.
• 배포 검사: Cloud Deploy의 사전 배포(predeploy) 및 사후 배포(postdeploy) 작업을 통해 준비 상태, 데이터베이스 마이그레이션 안전성, 스모크 테스트를 검증합니다.

브랜칭, 코드 리뷰, 버전 관리, 추적성

• 수명이 짧은 피처 브랜치를 사용하는 트렁크 기반 개발과 필수 PR 리뷰를 선호합니다. 감사 가능성을 위해 필수 검사와 선형 히스토리를 강제합니다.
• 버전 관리: 릴리스에는 시맨틱 버전 태그를, 불변성을 위해서는 이미지 다이제스트와 커밋 SHA를 사용합니다. 프로덕션 배포에서는 latest와 같은 변경 가능한 태그 사용을 피합니다.
• 추적성: 빌드와 릴리스에 커밋, PR, 티켓 ID를 어노테이션으로 추가합니다. 배포 이벤트를 Logging으로 보내고, 비용 및 소유권 추적을 위해 리소스에 라벨을 첨부합니다.

인프라 드리프트, 정책, 감사, 변경 제어

• 드리프트 감지: terraform plan -detailed-exitcode를 정기적으로 실행하고, 종료 코드가 0이 아닐 경우 알림을 보냅니다. 클러스터의 경우, Config Sync는 Git 상태로의 최종적 수렴을 보장합니다.
• 정책 적용: 가드레일(예: 외부 IP 제한)을 위해 Organization Policy를, KRM 제약 조건을 위해 Policy Controller를, 이미지 정책을 위해 Binary Authorization을 사용합니다.
• 감사 로그: Admin Activity 및 Data Access 로그를 활성화하고, 싱크를 통해 중앙 프로젝트로 라우팅하며 규정 준수에 맞춰 보관 기간을 설정합니다. Cloud Asset Inventory는 변경 내역과 액세스 분석 정보를 제공합니다.
• 변경 제어: 프로덕션 승격 시 수동 승인을 요구하며, 근거를 어노테이션으로 기록합니다. 변경 동결 기간(Freeze window)은 CI/CD에서 정책 검사로 구현할 수 있습니다. 비상 롤백 경로를 문서화하고 실제 연습을 통해 검증합니다.

실용적인 문제 시나리오

Acme Retail은 안전한 카나리 출시, 엄격한 정책 적용, 완전한 릴리스 추적성을 갖추고 dev 및 prod 환경의 GKE에 새로운 order-service를 배포해야 합니다. 팀은 Terraform으로 관리되는 인프라, Kustomize를 사용한 선언적 Kubernetes 구성, Cloud Build 및 Cloud Deploy를 사용한 감사 가능한 CI/CD를 표준화해야 합니다.

접근 방식:

1. 아티팩트 저장소 및 ID 설정

• 리전별 Artifact Registry 저장소 order-docker-dev와 order-docker-prod를 만듭니다. 앱 프로젝트의 Cloud Build 서비스 계정에 적절한 저장소에 대한 roles/artifactregistry.writer 역할을, GKE 런타임 노드에는 roles/artifactregistry.reader 역할을 부여합니다.
• 근거: 저장소를 분리하면 장애 반경이 줄어들고 수명 주기 정책이 단순화됩니다. 명시적인 IAM은 과도한 권한의 기본값을 방지합니다.

2. 환경 분리를 고려한 Terraform 인프라 정의

• terraform/envs/dev 및 terraform/envs/prod 디렉터리를 만듭니다. 각 구성에는 별도의 상태 버킷이 있는 GCS 백엔드, GKE 클러스터 모듈, Cloud Deploy 서비스 계정에 대한 IAM 바인딩이 포함됩니다. 환경별로 게이트가 있는 CI 작업에서 terraform init, plan -out=plan.bin, apply plan.bin을 실행합니다.
• 근거: 환경별 상태와 프로젝트는 환경 간 우발적인 영향을 방지하고, 계획 파일은 검토 및 감사 가능한 변경 제어를 지원합니다.

3. 선언적 Kubernetes 기본 구성 및 Kustomize 오버레이 작성

• Deployment, Service, HPA에 대한 Kubernetes 매니페스트를 k8s/base에 배치하고 이미지는 다이제스트로 고정합니다. k8s/overlays/dev 및 k8s/overlays/prod를 만들어 복제본 수, 리소스 요청, 구성 패치를 정의합니다. 데이터베이스 사용자 인증 정보에는 Secret Manager CSI 클래스를 사용합니다.
• 근거: 오버레이가 있는 단일 진실 공급원(Single source of truth)은 드리프트를 제거하고 구성을 DRY(Don’t Repeat Yourself)하게 유지하면서 안전한 환경별 차이를 가능하게 합니다.

4. 테스트와 패키지 단계를 분리하여 Cloud Build 구현

• cloudbuild.yaml에는 린트 및 단위 테스트, 일회용 dev 네임스페이스에 대한 통합 테스트, 컨테이너 빌드 및 환경 저장소로 푸시, SBOM 및 취약점 스캔, 출처(provenance) 생성 단계가 포함됩니다. 트리거는 테스트를 위해 main으로의 PR 시 실행되고, 패키징을 위해 병합 시 실행됩니다. 빌드는 최소 권한의 cb-deployer 서비스 계정으로 실행됩니다.
• 근거: 조기 실패는 비용이 저렴합니다. 관심사를 분리하면 관측 가능성이 향상되고 특정 단계의 재시도가 가능해집니다. 최소 권한 원칙은 공급망 위험을 줄입니다.

5. 수동 프로덕션 승인 및 카나리 전략을 포함한 Cloud Deploy 전송 파이프라인 구성

• dev 및 prod 타겟을 가진 DeliveryPipeline을 정의합니다. prod 단계는 승인이 필요하며 카나리 전략(예: 10% 후 100%)을 사용합니다. 스키마 호환성 검사 및 스모크 테스트를 위해 사전 배포(predeploy) 훅을 사용하고, 사후 배포(postdeploy) 시 SLO를 확인합니다.
• 근거: 점진적 배포는 장애 반경을 제한하고 자동화된 품질 게이트를 도입하며, 수동 승인은 프로덕션 환경에 대한 인간의 개입을 강제합니다.

6. GitOps 및 정책 적용 연결

• 필수 검토와 통과된 검사를 통해 main 브랜치를 보호합니다. Policy Controller 제약 조건을 사용하여 권한 있는 파드를 차단하고 변경 가능한 태그를 허용하지 않습니다. Binary Authorization을 활성화하여 어드미션 전에 Cloud Build 출처 및 “심각한 CVE 없음” 증명을 요구합니다.
• 근거: 코드형 정책(Policy-as-code)은 위험한 구성이 클러스터에 도달하는 것을 방지하고 일관된 적용을 제공합니다.

7. 안전한 릴리스를 위한 구성 및 피처 플래그 관리

• 보안 비밀이 아닌 런타임 구성은 ConfigMaps에 저장하고, 보안 비밀은 Secret Manager CSI를 통해 제공합니다. Firestore에서 읽는 order_new_flow 피처 플래그를 도입하여 prod에서 초기 1% 롤아웃을 진행합니다. 플래그는 짧은 TTL로 캐시되고 로깅됩니다.
• 근거: 플래그는 릴리스와 배포를 분리하여, 문제가 발생했을 때 바이너리를 롤백하지 않고도 즉시 비활성화할 수 있게 해줍니다.

8. 관측 가능성, 드리프트 감지 및 추적성 보장

• 빌드와 릴리스에 커밋 SHA, PR 번호, 변경 티켓을 어노테이션으로 추가합니다. Cloud Deploy 이벤트와 GKE 감사 로그를 중앙 Logging 프로젝트로 라우팅합니다. 야간 terraform plan 작업으로 드리프트를 감지하고 알림을 보내며, Config Sync는 KRM의 차이를 모니터링하여 Git과 일치하도록 조정합니다.
• 근거: 완전한 출처 및 감사 추적은 인시던트 대응 속도를 높이고, 지속적인 드리프트 감지는 인프라 무결성을 유지합니다.

9. 롤백 및 변경 제어 운영

• 장애 발생 시, 먼저 플래그를 통해 order_new_flow를 비활성화합니다. 필요한 경우, Cloud Deploy에서 이전의 성공적인 릴리스를 dev 및 prod로 승격합니다. 모든 prod 승격에는 릴리스 어노테이션에 티켓 참조와 온콜 SRE의 승인이 필요합니다.
• 근거: 플래그는 즉각적인 완화 조치를 제공하고, 불변의 릴리스는 예측 가능한 롤백을 가능하게 합니다. 승인 및 어노테이션은 운영 거버넌스 및 규정 준수 요구사항을 충족합니다.

← 아이덴티티 · 모든 도메인 · 관찰 가능성 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →