[GCP] CMDB 시스템 구축(1)
.png){kind=small}
GCP 콘솔에서 리소스를 들여다본 적이 있다면, 프로젝트가 늘수록 전체를 파악하기 어려워진다는 걸 느꼈을 겁니다. Compute Engine은 여기, Cloud SQL은 저기, 네트워크는 또 다른 페이지에 있죠. 리소스 40종을 한눈에 보려면 탭을 수십 개는 열어야 합니다.
그래서 직접 만들었습니다.
GCP 리소스 40종을 하나의 대시보드에서 조회하고, 변경 이력을 추적하며, AI 챗봇으로 질의할 수 있는 CMDB입니다.
1. 왜 CMDB를 직접 만들었나
GCP 콘솔의 한계
- 리소스가 서비스별로 흩어져 있다. VM은 Compute Engine, DB는 Cloud SQL, 컨테이너는 GKE. 전체를 한 번에 볼 수 있는 뷰가 없습니다.
- 프로젝트가 많아지면 파악이 안 된다. 조직 아래 프로젝트가 수십 개쯤 되면, 어떤 리소스가 어디에 있는지 찾는 것 자체가 일입니다.
- 변경 이력이 부족하다. Cloud Audit Logs가 있긴 하지만, "이 VM의 머신타입이 언제 바뀌었나"를 빠르게 확인하기는 어렵습니다.
기존 도구의 부족한 점
- GCP Asset Inventory 콘솔. 리소스 목록은 볼 수 있지만 시각화나 필터링이 제한적입니다.
- 서드파티 CMDB. ServiceNow, Device42 같은 도구는 기능이 과하거나, GCP에 특화돼 있지 않거나, 비용이 큽니다.
- Terraform State. IaC로 관리하지 않는 리소스, 그러니까 콘솔에서 직접 만든 것들은 여기서 빠집니다.
필요한 건 단순했습니다. GCP 조직 전체의 리소스를 한 화면에서 보고, 변경을 추적하고, 검색할 수 있는 도구.
2. 전체 아키텍처
┌──────────────────┐ ┌──────────────────────────┐ ┌─────────────────────┐
│ │ │ │ │ │
│ React Frontend │────▶│ Go Backend (Gin) │────▶│ GCP APIs │
│ (Port 3000) │ │ (Port 8080) │ │ │
│ │ │ │ │ · Asset Inventory │
│ · MUI 7 │ │ · OAuth2 + JWT │ │ · Cloud Monitoring │
│ · Recharts │ │ · In-Memory Cache │ │ · BigQuery Billing │
│ · Tailwind CSS │ │ · ETag (304) │ │ · Vertex AI │
│ │ │ · OpenTelemetry │ │ · Secret Manager │
└──────────────────┘ └────────────┬─────────────┘ └─────────────────────┘
│
▼
┌───────────────┐
│ PostgreSQL │
│ │
│ · 변경 이력 │
│ · DB 계정 │
│ · 메모 │
└───────────────┘
흐름 요약
- 백엔드가 Cloud Asset Inventory API로 조직 전체 리소스를 주기적으로 수집합니다.
- 이전 스냅샷과 비교해 변경 이력(CREATE/UPDATE/DELETE)을 PostgreSQL에 기록합니다.
- 수집한 리소스는 인메모리 캐시에 담아두고, ETag 기반 304 응답으로 빠르게 서빙합니다.
- 프론트엔드가 캐시된 데이터를 받아 카테고리별 대시보드로 시각화합니다.
3. 기술 스택
Backend — Go + Gin
| 언어/프레임워크 | Go 1.25 + Gin |
| 인증 | Google OAuth2 + JWT (HttpOnly Cookie) |
| 리소스 수집 | Cloud Asset Inventory API (40+ 리소스 타입) |
| 데이터베이스 | PostgreSQL (변경 이력, 계정, 메모) |
| AI | Vertex AI (Gemini) — 자연어 CMDB 질의 |
| 빌링 | BigQuery 빌링 데이터 + Cloud Billing API |
| 보안 | AES-256-GCM 암호화, Secret Manager |
| 관측성 | OpenTelemetry (OTLP → Jaeger/Tempo) |
Frontend — React 19
| 프레임워크 | React 19 (CRA + CRACO) |
| UI 라이브러리 | MUI 7 (Material UI) |
| 스타일 | Tailwind CSS 4 |
| 차트 | Recharts |
| 인증 | @react-oauth/google |
왜 이 조합인가
Go를 선택한 이유. Cloud Asset Inventory API로 조직 전체를 스캔하면 리소스가 수천 개씩 돌아옵니다. 이걸 파싱하고 비교하는 작업이 CPU와 메모리를 많이 쓰는데, Go의 goroutine과 sync.Pool이 여기에 잘 맞습니다. 단일 바이너리로 컴파일되니 Docker 이미지 크기도 ~20MB 정도로 가볍고요.
PostgreSQL을 선택한 이유. 리소스 자체는 인메모리 캐시에 두고, PostgreSQL에는 변경 이력과 메모만 저장합니다. JSONB 타입이 diff를 담기에 알맞고, Cloud SQL로 관리형 운영도 가능합니다.
인메모리 캐시 + ETag. 리소스 목록 API는 가장 자주 불리는 엔드포인트입니다. 매번 GCP API를 호출하면 느린 데다 할당량도 깎입니다. 그래서 인메모리에 JSON을 캐싱해두고, SHA256 해시 기반 ETag로 304 응답을 지원합니다.
4. 지원하는 GCP 리소스 (40+)
| 카테고리 | 리소스 타입 |
|---|---|
| Compute | Instance, Disk, Address, HealthCheck, UrlMap, MachineImage, InstanceTemplate, InstanceGroupManager |
| Network | VPC, Subnetwork, Firewall, Router, ForwardingRule, BackendService, SSL Certificate/Policy, Cloud Armor, DNS, NEG |
| Container | GKE Cluster, NodePool, Cloud Run Service |
| Database | Cloud SQL Instance, AlloyDB Cluster/Instance |
| Storage | Cloud Storage Bucket, Secret Manager, Artifact Registry |
| IAM | IAM Role, ServiceAccount, ServiceAccountKey |
| Messaging | Pub/Sub Topic, Subscription |
| AI/ML | Vertex AI MetadataStore, Dataset, PipelineJob, Model, Endpoint, BatchPredictionJob, CustomJob |
5. 주요 기능 미리보기
5-1. 카테고리별 대시보드
리소스를 Compute, Network, Database, Container 같은 카테고리로 나눠 한 화면에서 조회합니다. 메인 대시보드에서는 전체 리소스 수, 프로젝트 수, 리소스 타입 분포를 한눈에 봅니다.
카테고리를 클릭하면 서비스별 상세 대시보드로 넘어갑니다. Compute를 고르면 인스턴스, 디스크, IP 주소 같은 항목을 테이블로 확인하는 식입니다.
5-2. 리소스 변경 이력 추적
백엔드가 GCP 리소스를 주기적으로 스캔하면서 이전 스냅샷과 비교해 바뀐 항목을 잡아냅니다. 단순한 timestamp 변경은 무시하고, 실제로 의미 있는 변경, 즉 머신타입 변경이나 방화벽 규칙 추가 같은 것만 기록합니다.
// 예시: 변경 이력 레코드
{
"asset_type": "compute.googleapis.com/Instance",
"asset_id": "projects/my-project/zones/asia-northeast3-a/instances/web-server-01",
"operation": "UPDATE",
"diff": {
"machineType": {
"before": "e2-medium",
"after": "e2-standard-4"
}
},
"created_at": "2025-06-15T09:30:00Z"
}
5-3. AI 챗봇 (Vertex AI)
자연어로 CMDB에 물어볼 수 있습니다. "현재 운영 중인 VM 목록 보여줘", "이번 달 비용이 가장 높은 프로젝트는?" 같은 질문에 CMDB 데이터를 근거로 답합니다.
5-4. 빌링 분석 & 컴플라이언스
빌링. BigQuery에 쌓인 GCP 빌링 데이터를 분석해 프로젝트별·서비스별 비용을 시각화합니다.
컴플라이언스. CIS Benchmark를 기준으로 방화벽 규칙, 퍼블릭 버킷, DB 백업 설정 등을 자동 점검하고 점수를 매깁니다.
6. API 엔드포인트 구조
백엔드가 제공하는 엔드포인트는 20개가 넘습니다. 주요 그룹은 다음과 같습니다.
// 인증 GET /auth/google/login // OAuth 로그인 시작 GET /auth/google/callback // OAuth 콜백 GET /auth/me // 현재 사용자 정보 // 리소스 조회 (ETag 지원) GET /api/assets // 전체 리소스 목록 (304 지원) GET /api/history // 변경 이력 // 메트릭스 (Cloud Monitoring) GET /api/metrics/compute/:id // VM 메트릭 GET /api/metrics/sql/:name // Cloud SQL 메트릭 GET /api/metrics/gke/:name // GKE 메트릭 GET /api/metrics/run/:name // Cloud Run 메트릭 // 빌링, AI, 컴플라이언스 GET /api/billing/summary // 비용 요약 POST /api/ai/chat // AI 챗봇 GET /api/compliance/summary // CIS 체크 결과
인증된 요청만 /api/* 엔드포인트에 접근할 수 있고, JWT 토큰은 HttpOnly 쿠키로 관리합니다.
7. 배포 구조
┌──────────┐ ┌──────────────┐ ┌─────────────────┐ ┌────────────┐
│ GitHub │────▶│ Jenkins │────▶│ Artifact Registry│────▶│ Cloud Run │
│ │ │ │ │ (Docker Image) │ │ (서빙) │
└──────────┘ │ · Build │ └─────────────────┘ └────────────┘
│ · Test │
│ · Push │ ▲
└──────────────┘ │
┌─────────┐
│ ArgoCD │
│ (GitOps)│
└─────────┘
- Docker 멀티스테이지 빌드로 프론트엔드와 백엔드 모두 경량 이미지를 만듭니다.
- Jenkins가 빌드·테스트·이미지 푸시를 자동화합니다.
- ArgoCD GitOps 방식으로 Cloud Run에 배포합니다.
- 백엔드 이미지는 ~20MB, 프론트엔드 이미지는 ~50MB 정도입니다.
다음 편 예고
2편에서는 Go 백엔드의 핵심인 GCP 리소스 수집과 변경 추적을 다룹니다.
- Cloud Asset Inventory API로 40개 리소스를 한 번에 가져오는 방법
- protobuf 응답을 Go struct로 파싱하는 전략
- GCP API의 노이즈(timestamp, etag 자동 변경)를 걸러내는 스마트 변경 감지
sync.Pool과atomic.Value로 인메모리 캐시를 설계하는 법