Google ACE: 리소스 계층 구조, IAM 및 결제 관리 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

개요

리소스 계층 구조, ID 및 액세스 관리(IAM), 결제 관리는 Google Cloud 운영의 컨트롤 플레인을 구성합니다. 복원력 있는 설계는 명확한 계층 구조(조직, 폴더, 프로젝트)로 정책과 책임 범위를 정하는 것에서 시작합니다. 또한 그룹 중심의 관리와 워크로드를 위한 단기 수명 사용자 인증 정보를 사용하여 최소 권한 IAM을 적용하고, 예산, 내보내기, 라벨을 사용하여 비용을 귀속시키며, 조직 정책과 포괄적인 감사 로깅으로 거버넌스를 강화합니다. 운영 우수성은 상속을 표준화하고, 결제 및 로그를 중앙 집중화하며, 수명이 긴 키 대신 서비스 계정 가장(impersonation)을 사용하여 달성됩니다. 이 섹션에서는 핵심 구성 요소, 의도된 사용법, 그리고 피해야 할 일반적인 장애 모드를 자세히 설명합니다.

리소스 계층 구조 및 ID 모델

• 리소스 계층 구조

  • 조직: 루트 노드. Cloud Identity 또는 Google Workspace로 생성됩니다. 전역 정책(IAM, 조직 정책, 태그)을 소유합니다.
  • 폴더: 부서, 환경(예: dev, prod) 또는 애플리케이션을 위한 선택적 그룹화. 위임된 관리 및 정책 범위 지정에 유용합니다.
  • 프로젝트: 리소스, API, 할당량, IAM, 결제 연결을 위한 관리 경계. 대부분의 Google Cloud 리소스는 프로젝트의 하위 요소입니다.
  • 상속: IAM 정책과 조직 정책은 하향식으로 상속됩니다. 상위 수준의 거부 및 제약 조건이 우선 적용됩니다. 예외 및 비상 조치(break-glass) 필요성을 최소화하도록 배치(조직 → 폴더 → 프로젝트)를 계획하세요.

• 주 구성원(Principals)

  • Google 계정(사용자), Google 그룹스, 서비스 계정, 그리고 Workload Identity Federation을 통한 외부 ID.
  • 사용자 액세스의 경우, 수명 주기 변경 및 검토를 단순화하기 위해 Google 그룹스를 기본 바인딩 대상으로 사용해야 합니다.
  • 서비스 계정은 애플리케이션이나 서비스를 나타냅니다. 키보다는 워크로드 아이덴티티를 사용하는 것이 좋습니다.

• 워크로드 아이덴티티

  • Google Cloud 내부: GCE/GAE/Cloud Run/GKE는 메타데이터 서버를 사용하여 연결된 서비스 계정에 대한 단기 수명 토큰을 발급합니다.
  • Google Cloud 외부: Workload Identity Federation은 정적 키 없이 외부 ID(OIDC/SAML/AWS)를 서비스 계정에 매핑합니다.

• 설계 장단점 및 장애 모드

  • 폴더 구조 없이 프로젝트가 무분별하게 늘어나면 정책 중복 및 드리프트가 발생합니다.
  • 사용자에게 직접 역할을 부여하면 관리 부담(toil)이 증가합니다. 그룹 기반 바인딩을 사용하는 것이 좋습니다.
  • 광범위한 권한을 가진 Compute Engine 기본 서비스 계정을 사용하면 위험이 높아집니다. 워크로드별로 최소 권한의 서비스 계정을 생성하세요.
  • 프로젝트를 잘못된 폴더 아래에 배치하면 잘못된 정책이 상속됩니다. 태그를 사용하거나 변경 관리를 통해 신중하게 프로젝트를 이동하세요.

IAM 역할 및 정책 설계

• 역할 유형

  • 기본 역할(Viewer, Editor, Owner): 광범위한 레거시 역할. 엄격하게 통제되는 비상 조치(break-glass) 외에는 사용을 피하세요.
  • 사전 정의된 역할: 서비스별로 선별된 역할. 대부분의 사용 사례에 권장됩니다.
  • 커스텀 역할: 특정 요구에 맞게 조직 또는 프로젝트 범위에서 권한을 집계한 역할.
  • 조건부 역할: IAM Conditions(CEL)는 리소스 이름, 폴더, 태그 또는 시간과 같은 컨텍스트를 추가합니다. 강력한 역할을 제한하는 데 사용됩니다.

• 정책 원칙

  • 최소 권한: 가장 좁은 범위(리소스/프로젝트/폴더)에서 최소한의 역할만 부여합니다.
  • 직무 분리: 직무를 분리합니다(예: 네트워크 관리자 vs. 보안 관리자 vs. 결제 관리자). 단일 주 구성원에게 배포와 승인 작업을 함께 부여하지 마세요.
  • 상속 인지: 조직/폴더 수준의 바인딩은 모든 하위 리소스에 영향을 미칩니다. 적용하기 전에 의도된 영향 반경(blast radius)을 문서화하세요.

• 거부 정책

  • IAM Deny는 다른 곳에서 권한이 부여되었더라도 명시적으로 권한을 차단합니다. 가드레일로 사용하세요(예: deny iam.serviceAccountKeys.create).
  • 거부가 우선 적용됩니다. 기간이 정해진 예외 프로세스와 함께 문서화된 비상 조치(break-glass)를 마련하세요.

• 예시

  • dev에서 prod로 커스텀 역할 복사: gcloud iam roles copy ROLE_ID
    –source=projects/DEV_PROJECT
    –destination=projects/PROD_PROJECT
  • OS Login으로 그룹 기반 SSH 관리자 권한 부여: gcloud projects add-iam-policy-binding PROJECT_ID
    –member=group:ops-admins@example.com
    –role=roles/compute.osAdminLogin

• 장애 모드

  • 조직 또는 폴더 수준에서 부여된 Editor 역할이 의도치 않게 모든 프로젝트로 전파됩니다.
  • 지나치게 엄격한 조건이 있는 조건부 역할은 자동화를 조용히 중단시킬 수 있습니다. 배포 전에 Policy Troubleshooter로 테스트하세요.
  • 커스텀 역할은 새로운 권한이 추가될 때 뒤처질 수 있습니다. 주기적으로 검토하세요.

결제 및 비용 관리

• 결제 계정 및 연결

  • 유료 서비스를 사용하려면 프로젝트가 반드시 하나의 결제 계정에 연결되어야 합니다.
  • 역할: Billing Account Administrator는 계정 및 결제 수단을 관리하고, Billing Account User는 프로젝트를 연결하며, Project Billing Manager는 프로젝트의 결제 연결을 관리합니다.
  • 기업 결제 계정으로 중앙 집중화하세요. 프로젝트의 결제 연결을 업데이트하여 프로젝트를 마이그레이션합니다.

• 예산, 알림, 비용 귀속

  • 예산은 지출 한도가 아니라 알림을 생성합니다. 강제 조치가 필요한 경우 Pub/Sub 및 Cloud Functions/Cloud Run을 사용하여 프로그래밍 방식의 해결 조치를 사용하세요.
  • 일별/월별 비용 분석 및 예측을 위해 결제 데이터를 BigQuery로 내보내세요. 비용 귀속을 위해 리소스 라벨 및 태그와 결합합니다.
  • 라벨 및 태그: 키를 표준화하세요(예: cost_center, env, app). 라벨이 누락되면 비용 귀속 정확도가 떨어집니다.

• 비용 분석

  • BigQuery 내보내기를 사용하여 SQL로 SKU/서비스별 롤링 예측을 계산하세요. 세분화된 보고를 위해 리소스 메타데이터(예: GCE 라벨)와 조인합니다.
  • 다중 프로젝트 분석의 경우, 모든 프로젝트 내보내기 데이터를 집계하거나 단일 중앙 데이터 세트로 내보냅니다.

• 일반적인 함정

  • 새 프로젝트에 예산이 구성되지 않음. 프로젝트 생성 시 예산을 자동으로 생성하는 정책을 수립하세요.
  • BigQuery 내보내기가 없으면 과거 데이터에 대한 통찰력이 제한됩니다. 기록을 쌓기 위해 조기에 활성화하세요.
  • 프로젝트에 개인 신용카드를 사용하면 책임 소재가 분산됩니다. 적절한 IAM 및 결제 프로필을 사용하여 기업 결제 계정으로 통합하세요.
  • 공유 서비스 프로젝트의 비용 이상 현상은 태그 지정 및 교차 청구(cross-charging) 정책이 필요합니다.

안전한 워크로드 인증 및 액세스 패턴

• 서비스 계정 가장(impersonation)

  • 키보다 가장을 사용하는 것이 좋습니다. 호출자 ID에 roles/iam.serviceAccountTokenCreator 역할을 부여하면, 호출자는 서비스 계정 역할을 하는 단기 토큰을 얻을 수 있습니다.
  • 예시: gcloud auth print-access-token
    –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com

• 키 및 순환(rotation)

  • 사용자 관리 키는 사용하지 마십시오. 필요한 경우 Secret Manager에 저장하고, 최소 90일마다 순환하며, 사용량을 모니터링하고, VPC Service Controls 및 CMEK로 제한하십시오.
  • 키 생성을 차단하는 제약 조건 적용: constraints/iam.disableServiceAccountKeyCreation = true

• OS Login 및 SSH

  • 그룹 기반 IAM 역할(compute.osLogin, compute.osAdminLogin)과 함께 OS Login을 사용하십시오. 각 사용자는 책임 추적이 가능한 액세스를 위해 자신의 공개 SSH 키를 Google 계정에 업로드합니다. Admin Activity 및 Data Access 로그를 통해 감사합니다.
  • 이미지에 공유 SSH 키를 포함시키지 마십시오.

• Workload Identity Federation

  • 온프레미스나 다른 클라우드의 경우, ID 제휴(identity federation)를 구성하여 키 생성 없이 Google Cloud에 대한 액세스 권한을 부여하고 데이터 유출 위험을 줄이십시오.

• 장애 모드 및 완화 조치

  • 리포지토리나 CI/CD 변수에 키를 저장하면 보안 침해로 이어집니다. 가장(impersonation) 또는 제휴(federation) 방식으로 전환하십시오.
  • 광범위한 역할을 가진 기본 서비스 계정은 위험합니다. constraints/iam.allowedPolicyMemberDomains로 제한하고 기본 역할(primitive roles)을 제거하십시오.
  • 레거시 GCE 인스턴스에 범위(scope)가 누락되면 API 액세스가 차단될 수 있습니다. API별 IAM과 기본 애플리케이션 사용자 인증 정보(default application credentials)를 함께 사용하는 것이 좋습니다.

거버넌스, 조직 정책, 감사 및 문제 해결

• 조직 정책 및 제약 조건

  • 제약 조건을 사용하여 가드레일 적용: VM의 외부 IP 비허용, 리전 제한, 키 생성 방지, 허용된 서비스 제한, 균일한 버킷 수준 액세스 요구, 도메인 공유 제한.
  • 리소스 계층 구조로 대상을 지정하고, 태그를 사용하여 환경별 예외를 세부적으로 조정합니다.

• Cloud Identity 및 수명 주기

  • Cloud Identity는 사용자 디렉터리, SSO 및 관리 역할을 제공합니다. 권한을 좁게 위임하고(예: Group Admin, User Management Admin) 입사자-이동자-퇴사자 워크플로를 자동화하여 그룹 멤버십과 액세스를 업데이트합니다.
  • 민감한 환경에는 Access Approvals 및 Access Transparency를 사용합니다.

• 감사 로깅

  • 관리자 활동 및 시스템 이벤트 로그는 항상 활성화되어 있습니다. 데이터 액세스 로그는 명시적으로 활성화해야 하며 비용이 발생할 수 있습니다.
  • 폴더/조직의 집계 싱크를 보안 프로젝트로 라우팅하여 중앙 집중화합니다. CMEK와 제한된 액세스로 보호합니다.
  • Policy Denied 로그를 모니터링하여 조직 정책 충돌을 감지합니다.

• 다중 프로젝트 문제 해결 툴킷

  • Policy Troubleshooter: 유효한 IAM 및 거부 정책을 고려하여 액세스가 허용되거나 거부되는 이유를 진단합니다.
  • Cloud Asset Inventory: 조직/폴더/프로젝트 전반의 IAM 바인딩 및 정책 기록을 쿼리합니다. 예시:

undefined

• Logs Explorer: 주 구성원, 메서드, 리소스별로 필터링하여 여러 프로젝트에 걸친 작업을 추적합니다.
• 운영자 컨텍스트 전환을 위한 gcloud 구성:

undefined

• 일반적인 실패 모드: 배포를 차단하는 조직 정책 충돌, 조사에 방해가 되는 데이터 액세스 로그 누락, 잘못된 범위에 부여된 IAM. 런북과 변경 전 미리보기를 구축하여 인시던트 평균 해결 시간(MTTR)을 단축합니다.

실용적인 문제 시나리오

Aurelia Retail은 인수 후 여러 팀과 프로젝트를 통합해야 합니다. 이들은 결제를 중앙 집중화하고, 수백 개의 Compute Engine VM에 걸쳐 일관된 IAM 및 SSH 관리를 시행하며, 중단을 최소화하면서 거버넌스를 구축해야 합니다.

1. 회사 결제 계정 생성 및 프로젝트 연결

• 근거: 단일 결제 계정으로 결제 수단, 크레딧, 예산을 중앙에서 관리합니다. 프로젝트 마이그레이션 그룹에는 Billing Account User 역할을, 팀 리더에게는 Project Billing Manager 역할을 부여하여 과도한 권한 없이 프로젝트를 다시 연결할 수 있도록 합니다.
• 조치: 콘솔에서 결제 계정을 생성합니다. 각 프로젝트의 결제 연결을 업데이트합니다. 즉시 중앙 분석 프로젝트의 BigQuery로 결제 내보내기를 활성화합니다.

2. 폴더와 태그로 리소스 계층 구조 표준화

• 근거: 프로젝트를 환경 폴더(prod, nonprod) 아래에 배치하면 가드레일 상속 및 대상 예외 적용이 용이해집니다. 태그를 사용하면 폴더 트리를 복제하지 않고도 조직 정책을 세밀하게 타겟팅할 수 있습니다.
• 조치: prod 및 nonprod용 폴더를 생성하고 프로젝트를 그에 맞게 이동합니다. env=prod|nonprod 태그와 앱 식별자를 정의합니다.

3. 최소 권한 및 직무 분리를 적용한 그룹 기반 IAM 구현

• 근거: 그룹을 사용하면 수명 주기 관리와 감사가 단순화됩니다. 배포자, 보안, 네트워크 관리자 간에 역할을 분리하면 장애 발생 반경이 줄어듭니다.
• 조치: app-operators, net-admins, sec-admins, billing-managers용 Google 그룹을 생성합니다. 필요에 따라 폴더/프로젝트 범위에 사전 정의된 역할을 바인딩하고, 기본 역할은 피합니다.

4. OS Login 기반 SSH 관리 시행

• 근거: 사용자 계정에 연결된 개별 SSH 키는 추적 가능하고 취소 가능한 액세스를 제공합니다. OS Login 역할은 IAM을 통해 Linux 계정을 관리하므로 공유 키가 필요 없습니다.
• 조치: 각 프로젝트에서 OS Login 메타데이터를 활성화합니다. ops-admins 그룹에 compute.osAdminLogin 역할을 부여합니다. 예시:

undefined

5. 서비스 계정 키를 가장(impersonation)으로 대체

• 근거: 수명이 짧은 사용자 인증 정보는 키 유출 위험을 완화하고 교체를 단순화합니다. 감사 로그에는 누가 누구를 가장했는지 기록되어 추적성이 향상됩니다.
• 조치: 워크로드 서비스 계정에 대해 CI/CD 러너 ID에 roles/iam.serviceAccountTokenCreator 역할을 부여합니다. 사용자가 관리하는 키를 제거하고 조직 정책을 적용하여 새 키 생성을 차단합니다.

6. 가드레일을 위한 조직 정책 적용

• 근거: 제약 조건은 모든 프로젝트에서 위험한 구성을 방지하는 동시에, 타당한 경우 태그가 지정된 예외를 허용합니다.
• 조치: prod 환경에서 외부 IP를 허용하지 않고, 승인된 위치로 리전을 제한하며, 서비스 계정 키 생성을 비활성화하는 제약 조건을 적용합니다. 문서화된 승인이 있는 특정 프로젝트에 대해서는 태그를 사용하여 예외를 허용합니다.

7. 비용 거버넌스 구축

• 근거: 예산은 초과 지출이 발생하기 전에 소유자에게 알림을 보내고, BigQuery로 내보내기를 통해 비용 귀속 및 예측이 가능해집니다. 라벨과 태그는 리소스 지출을 비용 센터에 매핑합니다.
• 조치: 폴더 및 주요 애플리케이션별로 예산을 생성하고 Pub/Sub 알림을 설정합니다. 배포 템플릿과 CI의 정책 검증을 통해 라벨 정책을 강제합니다.

8. 감사 중앙 집중화 및 문제 해결 가속화

• 근거: 조직 전체의 로그 및 애셋 인벤토리를 집계하면 조사 및 규정 준수 보고 속도가 빨라집니다.
• 조치: CMEK로 보호되는 버킷이 있는 보안 프로젝트로 집계 싱크를 생성합니다. 중요한 서비스(Cloud Storage, BigQuery)에 대해 데이터 액세스 로그를 활성화합니다. Cloud Asset Inventory를 사용하여 정기적으로 IAM 바인딩을 스캔합니다. 운영자가 액세스 실패 시 Policy Troubleshooter를 사용하고, 관리자 활동/데이터 액세스를 추적하기 위해 Logs Explorer를 사용하도록 교육합니다.

9. 미리보기 및 단계적 출시를 통한 변경 운영화

• 근거: 적용 전에 IAM 및 정책 효과를 검증하면 서비스 중단을 줄일 수 있습니다.
• 조치: nonprod 환경에서 IAM 및 조직 정책을 먼저 테스트합니다. 가능한 경우 드라이런(dry-run) 및 정책 시뮬레이션을 사용합니다. 배포 자동화를 위해 카나리 배포 및 롤백 계획을 구현합니다.

이 접근 방식을 통해 중앙 집중식 결제 및 비용 분석, OS Login을 통한 추적 가능한 SSH 관리, 가장 권한 위임을 통한 최소 권한 IAM, 조직 정책을 통한 강력한 예방적 통제, 그리고 새로운 다중 프로젝트 환경 전반에 걸친 강력한 감사 및 문제 해결 기능을 확보할 수 있습니다.

모든 도메인 · Compute Engine 및 가상 머신 운영 →

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

Google 찾아보기 →