Google PCD: 테스트, 품질 엔지니어링 및 안전한 릴리스 관리 — 학습 가이드

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

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

개요

Google Cloud에서 빠르게 움직이는 팀은 엄격한 테스트와 점진적 배포를 결합하여 변경 속도를 높이면서 위험을 줄입니다. 견고한 전략은 단위 테스트부터 엔드 투 엔드 테스트, 현실적인 데이터 및 종속성 시뮬레이션, 자동화된 품질 게이트, 카나리 및 블루-그린과 같은 통제된 릴리스 패턴에 이르기까지 광범위합니다. 관측성, 소유권, 그리고 체계적인 릴리스 후 검증을 통해 전체 프로세스를 완성합니다. 이 섹션에서는 Google Cloud 서비스를 사용하여 안정성을 위한 설계를 하고, 위험을 격리하며, 환경 전반에 걸쳐 빌드를 안전하게 승격하는 방법을 자세히 설명합니다.

테스트 전략 및 데이터 관리

테스트 피라미드와 테스트 유형

• 단위 테스트: 함수, 클래스, 작은 모듈의 빠르고 격리된 검증입니다. 테스트 스위트의 대부분을 차지해야 합니다. 모든 커밋과 pull request 시 실행합니다.
• 통합 테스트: 애플리케이션과 데이터 저장소 또는 큐와 같은 구성요소 간의 상호작용을 검증합니다. 가능한 경우 Google Cloud 에뮬레이터를 사용합니다.
• 계약 테스트: 마이크로서비스에 대한 소비자 주도 계약은 호환성이 깨지는 API 변경을 방지합니다. 통합 전에 소비자가 기대하는 스키마와 시맨틱에 대해 제공자의 동작을 검증합니다. Pact 또는 유사한 도구를 사용하고, API 버전을 관리하며 스키마를 게시합니다.
• 엔드 투 엔드 테스트: 프로덕션과 유사한 구성, ID, 네트워크 정책을 사용하여 전체 시스템 경로를 실행합니다. 테스트 수를 제한하고 병렬화하며, 프로덕션 이전(pre-prod) 환경에서 실행합니다.
• 스모크 테스트: 각 배포 후 중요한 종속성, 경로, 상태 확인이 올바르게 작동하는지 확인하는 최소한의 검사입니다. 배포 후 첫 번째 검증 단계입니다.

테스트 데이터 관리, 격리, 재현성 및 환경 패리티

• 데이터 시딩: 단위 테스트를 위해 작고 결정적인 데이터 세트를, 통합/성능 테스트를 위해 더 크고 대표적인 데이터 세트를 생성합니다. 소스 제어에 체크인된 픽스처(fixture)로부터 시딩합니다.
• 격리: 테스트가 상태를 공유하지 않도록 보장합니다. 임시 데이터베이스, 격리된 GKE 네임스페이스, Cloud Storage 객체에 대한 고유한 접두사를 사용합니다. SQL의 경우 테스트별 스키마를 생성하고, Pub/Sub의 경우 임시 주제/구독을 생성합니다.
• 재현성: 종속성 버전을 고정하고, 빌드를 밀폐형(hermetic)으로 만들며, 랜덤 시드를 고정합니다. 테스트 컨테이너를 다이제스트와 함께 Artifact Registry에 저장합니다.
• 환경 패리티: 개발, QA, 스테이징, 프로덕션 전반에 걸쳐 컨테이너 이미지와 코드형 인프라(IaC)를 표준화합니다. 구성은 이미지에서 분리하고 환경별 메타데이터와 보안 비밀을 사용합니다. Compute Engine의 경우 배포별 값을 인스턴스 템플릿 메타데이터에 저장하고, 프로젝트 간 패리티를 위해 환경 메타데이터 키를 구성한 후 시작 시 이를 읽어 환경별 구성을 선택합니다.

모의(Mocking), 에뮬레이터, 페이크(Fake), 샌드박스 서비스

• 모의(Mock)/스텁(Stub): 단위 테스트 수준에서 협력 객체(collaborator)를 대체하여 로직을 격리하고 네트워크 호출을 차단합니다. 과도한 모의 사용을 피하고, 구현 세부 정보가 아닌 동작에 대해 단언(assert)합니다.
• 에뮬레이터: 통합 테스트에는 공식 에뮬레이터를 사용하는 것이 좋습니다. 예: Firestore/Datastore, Pub/Sub, Spanner, Bigtable 에뮬레이터. 클라우드 요금 없이 API 충실도를 제공하며 CI를 가속화합니다.
• 페이크(Fake): 에뮬레이터가 없는 경우, 가벼운 로컬 페이크(예: 페이크 객체 저장소) 또는 강력한 격리 및 할당량이 있는 공유 샌드박스 서비스를 실행합니다.
• 외부 종속성 시뮬레이션: 서드파티 API의 경우, 서비스 메시 또는 API 게이트웨이 뒤에서 계약 기반 페이크를 실행합니다. 타임아웃, 재시도, 카오스 주입을 구성하여 장애 처리 방식을 테스트합니다.

일반적인 실패 모드와 트레이드오프

• 엔드 투 엔드 테스트에 대한 과도한 의존은 반복(iteration) 속도를 늦춥니다. 단위 테스트와 계약 테스트에 투자하여 문제를 더 일찍 발견해야 합니다.
• 공유되고 오래 지속되는 테스트 환경은 구성 변경(drift)과 데이터 오염을 축적합니다. 임시 환경과 멱등성(idempotent)을 가진 설정/해체(setup/teardown)를 선호해야 합니다.
• 에뮬레이터가 프로덕션을 완벽하게 미러링하지 못할 수 있습니다. 프로덕션 승격 전에 실제 서비스를 사용하는 단계별 E2E 테스트를 수행해야 합니다.

실패한 단계를 분리하기 위한 간단한 Cloud Build 예시

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

단계를 분리하면 빌드 기록에서 컴파일/단위 테스트, 빌드, 통합 중 어느 단계에서 실패했는지 정확히 찾아낼 수 있습니다.

비기능 테스트 및 코드 품질

성능 테스트

• 유형: 부하(정상 상태), 스트레스(최대 부하 초과), 내구성(장시간), 용량 테스트.
• 도구: SLO 및 알림에는 Cloud Monitoring, 지연 시간 분석에는 Cloud Trace, 핫스팟(hot path) 파악에는 Cloud Profiler를 사용합니다. GKE의 경우 Cluster Autoscaler와 HPA로 스케일링하고, Pub/Sub 워커의 경우 외부 메트릭 기반 HPA가 트래픽 급증에 따른 스케일링을 처리합니다.
• 프로덕션 테스트: 다크 론칭(dark launch)과 요청 미러링을 사용하여 프로덕션 트래픽으로 새로운 백엔드를 안전하게 평가합니다. External HTTP(S) Load Balancing은 요청 미러링을 지원하고, Anthos Service Mesh는 트래픽 섀도잉(shadowing)을 지원합니다.

보안 테스트

• SAST/보안 비밀 스캐닝: CI에서 정적 분석기를 실행하고 하드코딩된 사용자 인증 정보를 거부합니다. 보안 비밀은 최소 권한 액세스 원칙에 따라 Secret Manager에 저장합니다.
• 종속성 및 이미지 스캐닝: Artifact Registry에서 Container Analysis를 활성화합니다. Binary Authorization으로 정책을 시행하여, 배포 전에 심각한 취약점이 없다는 증명(attestation)을 요구합니다.
• DAST: 인증된 스캐너로 스테이징 환경을 스캔하고, 심각한 발견 사항이 있을 경우 릴리스를 차단합니다.

접근성 및 회귀 테스트

• 접근성: 자동화된 a11y(접근성) 검사(예: Lighthouse CI)를 병합 전 논블로킹(non-blocking) 검사에 통합하고, 릴리스 전에 문제를 해결합니다.
• 회귀 스위트: 중요한 사용자 여정(journey)에 대해 선별되고 안정적인 회귀 스위트를 유지 관리합니다. 모든 배포 시 스모크 테스트를 실행하고, 릴리스 후보(release candidate)에 대해서는 전체 회귀 테스트를 실행합니다.

정적 분석, 품질 게이트, 코드 리뷰

• 정적 분석: 언어에 적합한 린터(linter)와 포매터(formatter)를 제출 전 검사(pre-submit check)로 구성합니다. Bazel 또는 유사한 도구를 사용하여 병렬 처리합니다.
• 품질 게이트: 임계값(커버리지, 복잡도, 린트 오류) 위반 시 빌드를 실패 처리합니다. 결과를 Cloud Build 로그에 게시합니다.
• 코드 리뷰: 위험한 변경에 대해서는 2인 리뷰를, 중요한 경로에 대해서는 CODEOWNERS를, 릴리스에 사용되는 태그에 대해서는 제출 전 CI(presubmit CI)를 요구합니다.
• 공급망: SBOM을 생성하고, 아티팩트에 서명하며, 출처(provenance)를 저장합니다. Binary Authorization에서 증명(attestation) 검사를 시행합니다.

점진적 배포와 안전한 릴리스

배포 전략

• 롤링: 파드나 인스턴스를 점진적으로 교체합니다. 상태 비저장(stateless) 서비스에 대한 위험이 낮으며, readiness probe 및 서지/가용성 설정과 함께 사용합니다.
• 블루/그린: 완전한 새 환경을 구성하고 검증을 실행한 다음 트래픽을 전환합니다. 로드 밸런서를 되돌려 즉시 롤백할 수 있습니다. 즉각적인 폴백이 필요할 때 이상적입니다.
• 카나리: 주요 메트릭을 관찰하면서 새 버전에 적은 비율의 트래픽을 점진적으로 이전합니다. 정상이면 프로모션을 자동화하고, 성능 저하 시 롤백합니다.
• 트래픽 분할: GKE와 Anthos Service Mesh를 사용하여 비율 또는 속성(헤더, 쿠키, user-agent)에 따라 라우팅하거나, Cloud Run 및 App Engine의 내장 분할 기능을 사용합니다.

기능 플래그 및 실험

• 기능 플래그: 배포와 릴리스를 분리합니다. 점진적 롤아웃, 킬 스위치, 실험 토글에 플래그를 사용합니다. 중앙에서 관리(예: 관리형 플래그 서비스 또는 IAM으로 보호되는 구성 저장소)합니다. 플래그 수명은 짧게 유지하고 불필요한 부분은 제거합니다.
• 다크 론칭: 비활성화된 상태로 기능을 배포하고 내부 사용자나 합성 트래픽을 통해 검증합니다.
• 섀도 트래픽: 사용자에게 영향을 주지 않고 프로덕션 요청을 새 서비스로 미러링하여 응답을 비교하고 성능 저하를 감지합니다.
• 제어된 실험: 서비스 메시 규칙으로 A/B 또는 다변량 라우팅을 구현합니다. user-agent 기반 실험의 경우 헤더 일치로 라우팅합니다.

게이트, 승인, 롤백 및 관측 가능성

• 배포 게이트: 배포 전 통합 테스트와 배포 후 스모크/상태 확인을 추가합니다. 환경 프로모션을 위해 태그 기반 트리거를 사용하여 빌드와 릴리스를 분리합니다.
• 수동 승인: 스테이징에서 프로덕션으로 전환하는 등의 주요 단계에서 사람의 승인을 요구합니다. Cloud Deploy는 대상별 수동 승인 단계를 지원합니다.
• 자동 롤백: SLO 및 알림 정책을 정의합니다. 카나리 배포가 오류율 또는 지연 시간 임계값을 위반하면 배포 API를 호출하여 자동으로 롤백합니다. 롤백은 빠르고 잘 숙달된 상태로 유지합니다.
• 릴리스 관측 가능성: 메트릭과 로그에 버전 라벨을 사용하여 릴리스를 계측합니다. Prometheus 메트릭을 Cloud Monitoring으로 내보내고 오류 패턴에 대한 로그 기반 메트릭을 생성하여 원격 측정 데이터를 비용 효율적으로 연관 분석합니다.

헤더 기반 카나리를 위한 간단한 ASM 라우팅 예시

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

테스트 안정성, 피드백 루프, 릴리스 후 원칙

플레이키 테스트(Flaky test) 관리 및 안정성

• 탐지 및 격리: 시간에 따른 테스트의 플레이키 현상을 추적하고, 알려진 플레이키 테스트는 격리하여 릴리스를 차단하지 않으면서 수정 우선순위를 높입니다.
• 타임아웃 및 재시도: 합리적인 타임아웃을 추가하고, 로직 실패가 아닌 인프라 문제로 의심되는 플레이키 현상에 대해서는 단일 재시도를 허용합니다.
• 밀폐형 빌드(Hermetic build): 단위 테스트에서 네트워크 호출을 피하고, 아티팩트를 고정하고 에뮬레이터를 사용하여 비결정성을 줄입니다.
• 병렬화: Cloud Build에서 여러 단계 또는 워커에 걸쳐 테스트를 샤딩하여 피드백 지연 시간을 최소화합니다.

피드백 루프

• CI 트리거: main 브랜치와 pull request에 대한 모든 커밋에서 단위 및 통합 테스트를 실행합니다. 별도의 Cloud Build 단계를 사용하여 빌드 기록에서 실패한 단계를 식별할 수 있도록 합니다. 배포를 제어하기 위해 모든 커밋이 아닌 Git 태그에 릴리스 트리거를 생성합니다.
• 점진적 검증: Cloud Deploy Pub/Sub 알림을 구독하고 SUCCEEDED 이벤트 발생 시 프로모션을 호출하여, 배포 성공 시 dev 환경에서 test 환경으로 자동 프로모션합니다.
• 측정항목 기반 프로모션: 카나리 배포의 경우, Cloud Monitoring 측정항목 및 SLO를 기반으로 트래픽 증가를 제어합니다.

릴리스 문서, 소유권, 릴리스 후 검증

• 문서화: 릴리스 노트, 런북, 롤백 절차를 코드와 인접하게 관리합니다. 변경 티켓에 커밋, 이미지, 환경 버전에 대한 링크를 포함하여 추적합니다.
• 소유권: 온콜(on-call) 로테이션과 구성요소 소유자를 정의하고, 민감한 영역에 대해 CODEOWNERS를 강제합니다. 프로덕션 프로모션에 대한 명확한 승인자를 지정합니다.
• 릴리스 후 검증: 스모크 테스트 스위트를 실행하고, 오류 예산이 정상 범위 내에 있는지 확인하며, 버전 태그별로 대시보드를 검증합니다. 보안 및 취약점 보고서가 정책을 준수하는지 확인합니다. 문제가 발생하면 먼저 롤백한 후 근본 원인을 분석합니다.

실제 문제 시나리오

Acme Retail의 플랫폼 팀은 GKE 기반 마이크로서비스 애플리케이션의 테스트 및 릴리스를 표준화하고 있습니다. 이 애플리케이션에는 Cloud Run에서 실행되는 상태 비저장(stateless) 웹 프런트엔드도 포함됩니다. 이 팀은 빠른 피드백을 보장하고, 위험한 빌드를 차단하며, 라이브 트래픽을 사용하여 성능을 평가하면서 새로운 기능을 안전하게 출시해야 합니다.

접근 방식

1. Cloud Build에서 빌드 및 테스트 단계 분리

• 근거: 컴파일, 단위 테스트 실행, 컨테이너 빌드, 통합 테스트 실행을 위해 별개의 단계를 사용하여 빌드 기록에서 실패 단계를 정확히 찾아내고 개발자가 실행 가능한 피드백을 신속하게 받을 수 있도록 합니다.
• 예시:

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

2. 에뮬레이터 및 임시(ephemeral) 네임스페이스에서 통합 테스트 실행

• 근거: Pub/Sub 워커 및 Firestore 기반 서비스의 경우 Pub/Sub 및 Firestore 에뮬레이터를 사용합니다. 클러스터 정책이 필요한 서비스의 경우, Workload Identity를 통해 임시 토픽 및 서비스 계정을 사용하여 빌드당 임시 GKE 네임스페이스를 생성합니다. 이를 통해 충실도를 유지하면서 격리, 속도, 저비용을 확보할 수 있습니다.

3. Artifact Registry 및 Binary Authorization으로 보안 품질 게이트 강제

• 근거: 이미지 푸시 시 취약점 스캔을 활성화하고, 심각한 CVE가 발견되면 파이프라인을 실패 처리하며, GKE에 배포하기 전에 Binary Authorization에서 증명(attestation)을 요구합니다. 이를 통해 알려진 심각한 취약점이 있는 이미지의 배포를 방지합니다.

4. Git 태그 기반 릴리스 트리거 사용

• 근거: 태그(예: vX.Y.Z)에 대한 Cloud Build 트리거는 명시적으로 태그가 지정된 커밋에 대해서만 자동 릴리스를 허용하므로, main 브랜치에 대한 모든 커밋이 프로덕션에 우발적으로 배포되는 것을 방지합니다.

5. Cloud Deploy 및 Anthos Service Mesh를 사용한 점진적 배포

• 근거: dev, test, prod 타겟을 포함하는 Cloud Deploy 파이프라인을 정의합니다. 수동 승인을 사용하여 prod로의 프로모션을 제어합니다. prod 환경에서는 ASM을 사용한 카나리 전략을 통해 SLO를 모니터링하면서 트래픽을 5%, 25%, 50%, 100%로 전환합니다. Cloud Deploy는 검증 후크(hook)를 구독하며, 실패 시 API를 통해 카나리 배포를 자동으로 중지하거나 롤백합니다.

6. 관측 가능성 및 자동화된 롤백 후크

• 근거: Prometheus 측정항목을 Cloud Monitoring으로 내보내고 오류 시그니처에 대한 로그 기반 측정항목을 생성합니다. 버전을 라벨로 붙인 측정항목에 대해 알림 정책을 구성합니다. 알림을 구독하는 Cloud Function이 Cloud Deploy API를 호출하여 출시를 일시 중지하거나 롤백합니다. 이를 통해 객관적인 상태 신호를 배포 제어와 연결합니다.

7. Cloud Run 프런트엔드를 위한 섀도 트래픽 및 A/B 검증

• 근거: 외부 HTTP(S) 부하 분산기에서 요청 미러링을 사용하여 사용자에게 영향을 주지 않고 프로덕션 요청을 새로운 Cloud Run 리비전으로 보냅니다. 그런 다음 Cloud Run의 트래픽 분할 기능을 사용하여 적은 비율의 트래픽을 전환하고 전체 전환 전에 지연 시간/오류 측정항목을 비교합니다.

8. 중요 백엔드 서비스를 위한 블루-그린 폴백

• 근거: 즉각적인 롤백이 필요한 서비스의 경우, 단일 백엔드 서비스 뒤에 블루 및 그린 배포를 유지합니다. 스모크 및 계약 테스트로 그린 배포를 검증한 다음 트래픽을 전환합니다. 이상 징후가 나타나면 즉시 되돌립니다.

9. 릴리스 후 검증 및 문서화

• 근거: 프로모션 후 자동화된 스모크 테스트를 실행하고, 릴리스 버전별로 대시보드를 검증하며, 아티팩트 다이제스트 및 출시 기록으로 릴리스 노트를 업데이트합니다. 소유권과 온콜 담당자가 인수인계를 받습니다. 오류 예산이 소진되면 먼저 롤백한 후 비난 없는(blameless) 분석을 수행합니다.

이 접근 방식은 CI에서 빠르고 신뢰할 수 있는 피드백을 제공하고, 보안 및 품질을 강제하며, 속성 기반 실험과 필요 시 즉각적인 롤백을 모두 지원하는 안전하고 관찰 가능한 출시 전략을 사용합니다.

← 성능 · 모든 도메인 · 비용 →

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

Google 찾아보기 →