도입: GCP의 시작점, 프로젝트가 모든 것의 기준선이다
Google Cloud를 처음 켜는 순간부터 마지막 리소스를 삭제하는 순간까지, 모든 행위는 프로젝트라는 단위 위에서 이루어집니다. IAM 권한도 프로젝트를 기준으로 적용되고, 비용 청구서도 프로젝트 단위로 집계되며, API 활성화 여부도 프로젝트마다 독립적으로 관리됩니다. 이 글에서는 GCP의 뼈대가 되는 계층 구조, 결제 모델, 그리고 모든 것을 움직이는 gcloud CLI까지 — 시험과 실무에서 자주 마주치는 핵심 개념을 하나씩 짚어봅니다.
---
조직 → 폴더 → 프로젝트 계층의 의미
Google Cloud의 리소스 계층 구조는 크게 세 단계로 구성됩니다: 조직(Organization), 폴더(Folder), 프로젝트(Project). 이 구조는 단순한 분류 체계가 아니라 정책 상속과 접근 제어의 경계를 만드는 설계 기반입니다.
조직은 회사 전체에 해당합니다. Google Workspace나 Cloud Identity 도메인에 연결되며, 조직 수준의 Organization Policy나 IAM 역할은 아래 모든 폴더와 프로젝트에 자동으로 상속됩니다. 예를 들어 정책으로 만 허용하면, 어떤 팀도 다른 리전에 리소스를 만들 수 없습니다. 개발자가 실수로 다른 리전에 VM을 생성하려 해도 API 수준에서 즉시 거부됩니다.
폴더는 사업부·팀·환경(dev/staging/prod)을 표현하는 논리 그룹입니다. 최대 10단계 중첩이 가능하며, 특정 폴더에 IAM 역할을 부여하면 그 아래 모든 프로젝트에 동일 권한이 상속됩니다. 프로젝트는 GCP에서 리소스·IAM·결제의 기본 격리 단위입니다. 시험에서 "팀별 격리 + 비용 추적"이 나오면 레이블이 아닌 프로젝트 분리가 정답입니다.
| 계층 | 대응 개념 | 주요 역할 | |------|-----------|----------| | 조직(Organization) | 회사 전체 | 정책 루트, 전사 IAM 기준점 | | 폴더(Folder) | 사업부 / 팀 / 환경 | 중간 정책 상속, 프로젝트 그룹화 | | 프로젝트(Project) | 개별 서비스 단위 | 리소스·IAM·결제 기본 격리 경계 | | 리소스(Resource) | VM, GCS 버킷 등 | 실제 인프라 개체 |
---
결제 계정과 청구 모델 이해하기
프로젝트는 반드시 하나의 결제 계정(Billing Account)에 연결되어야 실제로 리소스를 사용할 수 있습니다. 하나의 결제 계정에 여러 프로젝트를 연결할 수 있어, 여러 팀의 비용을 하나의 청구서로 통합 관리하는 구조가 가능합니다.
결제 계정에는 두 가지 종류가 있습니다. Self-serve 계정은 신용카드나 은행 계좌로 자동 결제되며 개인 개발자나 스타트업이 주로 사용하고, Invoiced 계정은 월말 청구서 발행 후 30일 이내 납부 방식으로 대기업이나 공공기관이 선택합니다.
결제 계정과 프로젝트 IAM은 완전히 독립적으로 작동합니다. 재무팀에 를 결제 계정 수준에서 부여하면 청구서만 읽을 수 있을 뿐, 어떤 프로젝트 리소스에도 접근 권한이 주어지지 않습니다. 이것이 최소 권한 원칙의 실제 적용 사례입니다.
| 결제 역할 | 주요 권한 | 시험 키워드 | |-----------|-----------|------------| | billing.viewer | 청구서·비용 보고서 읽기 전용 | 재무팀 조회 전용 | | billing.user | 프로젝트를 결제 계정에 연결 | 개발자 프로젝트 연결 | | billing.admin | 결제 계정 완전 관리 | 결제 수단 추가·제거 | | billing.costsManager | 예산·비용 관리 | 예산 설정 전담 |
---
비용 가시성: 예산·알림·결제 내보내기
비용은 사용한 뒤 알게 되는 것이 아니라 미리 설계된 알림 체계로 관리해야 합니다. Google Cloud는 이를 위해 Cloud Billing Budget, Billing Export, Looker Studio를 제공합니다.
Cloud Billing Budget은 월 예산 금액을 설정하고, 실제 지출이 50%, 80%, 90%, 100%에 도달할 때 이메일 또는 Pub/Sub 메시지를 발송합니다. 중요한 점은 Cloud Billing Budget 자체는 서비스를 자동으로 중단하지 않는다는 것입니다. 예산 초과 시 VM을 자동 중지하려면 Pub/Sub + Cloud Functions 조합을 직접 구현해야 합니다.
Cloud Billing Export는 결제 데이터를 BigQuery 데이터셋에 자동 적재합니다. Standard 내보내기는 프로젝트·SKU 수준, Detailed Usage 내보내기는 리소스 수준까지 세부 과금 내역을 제공합니다. 데이터에는 프로젝트 ID, 서비스, SKU, 레이블이 포함되어 SQL로 부서별 비용을 집계할 수 있습니다. 단, 최대 24시간 지연이 있어 실시간 모니터링에는 적합하지 않습니다.
| 도구 | 용도 | 한계 | |------|------|------| | Cloud Billing 콘솔 | 시각적 확인, 간편 조회 | SQL 분석·장기 보존 불가 | | Cloud Billing Budget | 임계값 알림, 예산 관리 | 자동 리소스 중단 불가 | | BigQuery Billing Export | SQL 분석, 장기 보존 | 최대 24시간 지연 | | Looker Studio | 대시보드 시각화 | BigQuery 데이터 전제 |
Looker Studio는 BigQuery와 네이티브로 연동되어 별도 ETL 없이 비용 대시보드를 바로 구성할 수 있습니다. 레이블 기반 SQL 분석과 시각화가 모두 필요한 시나리오라면 Billing Export → BigQuery → Looker Studio 파이프라인이 표준 아키텍처입니다.
---
gcloud, gsutil, bq, kubectl: 네 가지 CLI의 역할 분담
Google Cloud SDK는 역할이 분리된 네 가지 도구로 구성됩니다. 각자의 영역이 명확하므로 구분해서 익혀두면 시험과 실무 모두에서 혼동을 줄일 수 있습니다.
gcloud는 GCP 대부분 서비스를 제어하는 주력 도구입니다. Compute Engine VM 생성, GKE 클러스터 관리, IAM 역할 부여, 네트워크 설정까지 — gcloud 하나로 거의 모든 인프라를 다룰 수 있습니다. gsutil은 Cloud Storage 전용 CLI로 버킷 생성, 파일 업로드·다운로드, ACL 설정에 사용합니다. bq는 BigQuery 전용 CLI로 데이터셋 생성, SQL 쿼리 실행, 데이터 로드를 담당합니다. kubectl은 Kubernetes(GKE) 클러스터를 제어하며, 로 kubeconfig를 설정한 뒤 사용합니다.
| CLI 도구 | 주요 대상 | 대표 명령 | |----------|-----------|----------| | gcloud | GCP 대부분 서비스 (Compute, IAM, GKE 등) | gcloud compute instances create | | gsutil | Cloud Storage 버킷·객체 | gsutil cp, gsutil mb | | bq | BigQuery 데이터셋·테이블·쿼리 | bq query, bq load | | kubectl | Kubernetes (GKE) 클러스터·워크로드 | kubectl apply, kubectl get pods |
---
gcloud 구성과 컨텍스트 전환
gcloud는 Configuration이라는 개념으로 여러 계정·프로젝트·리전 조합을 저장하고 빠르게 전환합니다. 마치 브라우저 프로필처럼, dev 환경과 prod 환경을 별도 Configuration으로 저장해두고 명령 하나로 전환할 수 있습니다.
주요 gcloud 명령 패턴을 네 가지 범주로 정리하면 다음과 같습니다.
| 범주 | 명령 | 설명 | |------|------|------| | 인증 | gcloud auth login | Google 계정으로 로그인 | | 인증 | gcloud auth list | 인증된 계정 목록 조회 | | 구성 | gcloud config set project PROJECT_ID | 활성 프로젝트 변경 | | 구성 | gcloud config configurations create NAME | 새 Configuration 생성 | | 구성 | gcloud config configurations activate NAME | Configuration 전환 | | 프로젝트 | gcloud projects list | 접근 가능한 프로젝트 목록 |
플래그를 명령에 직접 붙이면 활성 Configuration을 바꾸지 않고 특정 프로젝트에만 일회성으로 명령을 실행할 수 있습니다. gcloud 명령 구조는 패턴을 따르므로, 이 패턴을 이해하면 외우지 않아도 명령을 유추할 수 있습니다.
서비스 계정 키 없이 애플리케이션이 GCP API를 호출하게 하려면 Application Default Credentials(ADC)를 설정합니다. 으로 로컬 개발 환경에서 ADC를 설정하면 Google Cloud SDK 라이브러리가 자동으로 인증 정보를 찾아 사용합니다.
---
시험에서 자주 헷갈리는 권한·설정 함정
GCP 시험에서 결제와 프로젝트 관련 문제는 비슷해 보이는 선택지가 많습니다. 핵심 함정을 정리합니다.
Organization Policy vs IAM 역할: Organization Policy는 리소스 생성 자체를 API 수준에서 차단하는 기술적 통제입니다. 리전 제한이나 서비스 비활성화처럼 "무조건 막아야 한다"는 요구에는 Organization Policy, "특정 사람만 허용"이면 IAM 역할입니다.
Cloud Monitoring vs Cloud Billing Budget: Cloud Monitoring은 CPU·메모리·응답 시간 같은 인프라 성능 메트릭 알림입니다. 비용·예산 임계값 알림은 반드시 Cloud Billing Budget을 사용해야 합니다.
레이블 vs 프로젝트 분리: 레이블은 단일 프로젝트 내에서 비용을 분류하는 태깅 도구입니다. "팀 간 리소스 격리"가 요구사항이면 레이블이 아닌 프로젝트 분리가 정답입니다.
| 헷갈리는 쌍 | A 선택 시점 | B 선택 시점 | |------------|------------|------------| | Organization Policy vs IAM | 기술적 통제, 리소스 생성 차단 | 역할 기반 접근 제어 | | Billing Budget vs Cloud Monitoring | 비용·예산 임계값 알림 | 인프라 성능 알림 | | 레이블 vs 프로젝트 분리 | 단일 프로젝트 내 비용 분류 | IAM 경계 포함 완전 격리 | | BigQuery Export vs 콘솔 | SQL 분석·장기 보존 | 간편 시각적 확인 |
Billing Account 역할 범위도 주의가 필요합니다. 를 결제 계정 수준에서 부여하면 프로젝트 리소스에는 전혀 접근할 수 없고, Cloud Billing Budget은 기본적으로 알림만 발송합니다. 자동 리소스 중단이 필요하면 Pub/Sub + Cloud Functions로 직접 구현해야 합니다.
---
정리: 신규 프로젝트 부트스트랩 체크리스트
지금까지 다룬 내용을 실무 관점의 체크리스트로 정리합니다. 새 프로젝트를 GCP에 생성할 때 이 순서를 따르면 설정 누락을 방지할 수 있습니다.
| 단계 | 작업 | 관련 명령 / 서비스 | |------|------|------------------| | 1 | 조직·폴더 계층 확인 | Google Cloud Console > Resource Manager | | 2 | 프로젝트 생성 | gcloud projects create PROJECT_ID --folder=FOLDER_ID | | 3 | 결제 계정 연결 | gcloud billing projects link PROJECT_ID --billing-account=ACCOUNT_ID | | 4 | 필요한 API 활성화 | gcloud services enable compute.googleapis.com | | 5 | IAM 역할 최소 부여 | gcloud projects add-iam-policy-binding ... | | 6 | 예산 알림 설정 | Cloud Billing > 예산 및 알림 | | 7 | BigQuery Billing Export 활성화 | Cloud Billing > Billing Export | | 8 | gcloud Configuration 저장 | gcloud config configurations create NAME |
BigQuery Billing Export는 가능한 한 초기에 활성화하는 것을 권장합니다. 활성화 이전 데이터는 소급 적용이 되지 않으므로, 나중에 설정하면 초기 비용 내역을 SQL로 분석할 수 없습니다.
Organization Policy는 프로젝트 생성 전에 상위 폴더나 조직 수준에서 미리 설정해두는 것이 효율적입니다. 폴더 수준에서 리전 제한 정책을 설정하면 이후 생성되는 모든 프로젝트에 자동으로 적용됩니다. 프로젝트가 모든 GCP 여정의 시작점입니다. 계층 구조를 올바르게 설계하고, 결제 가시성을 초기부터 확보하고, gcloud를 익숙하게 다룰 수 있다면 나머지 서비스 학습은 훨씬 수월해집니다.