GKE 위에 클러스터를 직접 띄워, Clean Architecture API 서버부터 비용 최적화까지 한 번 굴려 본 학습 노트다. 원래는 단계마다 글을 따로 올렸는데, 막상 다시 보려니 흐름이 글마다 끊겨 있어 한 페이지로 다시 묶었다. 처음엔 ChatGPT의 도움으로 매니페스트와 CRUD 골격을 만들고, Autopilot에서 Standard로 전환해 스펙을 직접 조정했고, 불필요한 파드를 지워 네트워킹 비용을 줄였다. 하루 청구액이 690원 수준까지 내려가는 걸 Billing 리포트로 확인한 과정이 이 노트의 뼈대다.
실험용 클러스터 기준의 기록이라 그대로 따라 하면 되는 프로덕션 권고안은 아니다. 다만 “GKE를 처음 직접 만지며 돌리고, 비용을 줄여 나가는 순서”를 한 흐름으로 남겨둔다. 막힌 지점과 ‘이건 이렇게 하면 안 되겠다’ 싶었던 함정도 단계마다 같이 적었다.
한눈에 보기 — 4단계 흐름
| 단계 | 무엇을 | 핵심 한 줄 |
|---|---|---|
| ① API 서버 | Clean Architecture JSON CRUD | ChatGPT로 골격 → 프로젝트에 통합 → 단계별 테스트 |
| ② K8s 실행 | 매니페스트 생성·배포·검증 | 로컬에서 만든 파일을 클러스터에 적용하고 동작 확인 |
| ③ 비용 최적화 (1) | Autopilot → Standard | 작업할 때만 스펙↑, Billing 리포트로 일일 비용 관찰 |
| ④ 비용 최적화 (2) | 불필요 파드 정리 | 네트워킹 관련 파드 삭제로 비용↓ (서비스 영향 주의) |
① API 서버 — Clean Architecture 기반 JSON CRUD
첫 단계는 클러스터에 올릴 애플리케이션 자체였다. Clean Architecture 구조 위에 JSON 기반 CRUD를 얹는 것이 목표였고, 골격은 ChatGPT로 빠르게 잡은 뒤 프로젝트에 맞게 다듬었다.
- 골격 생성 — Clean Architecture의 계층(엔티티·유스케이스·인터페이스)에 맞춘 CRUD 코드를 요청해 기본 틀을 받는다.
- 통합 — 받은 코드를 실제 프로젝트 구조에 붙여 넣고, 의존성·패키지 경로를 맞춘다.
- 테스트 — 각 엔드포인트가 의도대로 동작하는지 단계별로 확인한다.
⚠️ 함정 — ChatGPT가 주는 코드는 일반 예제에 가깝다. 그대로 쓰면 프로젝트 컨벤션·에러 처리·의존성 주입이 어긋난다. ‘동작하는 예시’와 ‘내 코드베이스에 맞는 코드’는 다르다는 걸 이 단계에서 처음 체감했다.
② Kubernetes 실행 — 매니페스트 생성·배포·검증
애플리케이션이 준비됐으면 다음은 Kubernetes로 띄우는 것. 실행 가능한 매니페스트를 만들고, 클러스터에 적용한 뒤, 실제로 떠 있는지 검증하는 세 박자다.
- 생성 — Deployment·Service 등 실행에 필요한 매니페스트를 만든다.
- 적용 — 만든 파일을 클러스터에 배포한다.
- 검증 — 파드가 정상 기동했는지, 엔드포인트가 응답하는지 확인한다.
⚠️ 함정 — 자동 생성된 매니페스트가 내 환경(이미지 태그·리소스 한도·네임스페이스)과 어긋나는 경우가 많다. Kubernetes 설정 자체가 처음엔 복잡해, 한 번에 뜨길 기대하기보다 ‘틀리면 로그 보고 고친다’를 전제로 접근하는 편이 빨랐다.
③ 비용 최적화 (1) — Autopilot에서 Standard로
클러스터가 돌기 시작하니 그다음 현실은 비용이었다. GKE를 항상 풀스펙으로 켜 둘 이유가 없어서, 두 방향을 잡았다.
- 작업할 때만 스펙↑ — 테스트 환경은 최소 스펙으로 두고, 실제 작업이 필요할 때만 노드 스펙을 올린다. (빠르게 작업 가능)
- Autopilot → Standard 전환 — 노드를 직접 제어해 비용을 깎되, 전체 환경을 재구성해야 한다.
실제 조정은 비용 최적화 대상 App을 클릭 → Edit → 노드 스펙 부분만 손보는 흐름이었다.
결과는 Billing > Reports에서 확인했다. 어제 하루 동안 690원이 발생했고, 다음 날 청구액이 어떻게 달라지는지 같은 화면에서 추적했다. ‘느낌’이 아니라 일일 청구 숫자로 줄었는지 보는 게 핵심이었다.
⚠️ 함정 — Autopilot → Standard 전환 시 예상 못 한 추가 비용이 붙을 수 있다. 관리 부담을 직접 떠안는 대가로 단가를 낮추는 트레이드오프라, 전환 직후 며칠은 Billing을 더 자주 들여다봐야 했다.
④ 비용 최적화 (2) — 불필요한 파드 정리
스펙 조정 다음은 안 쓰는 리소스 청소였다. 클러스터에 남아 있던 불필요한 파드를 지우면 특히 네트워킹 관련 비용이 줄어든다.
네트워킹 가시성 도구(Hubble 등)와 연관된 파드는 켜 두는 만큼 비용으로 돌아오기 때문에, 지금 단계에서 꼭 필요하지 않은 것은 내렸다.
삭제 성공. 같은 Billing 리포트로 네트워킹 비용 라인이 내려가는지 이어서 관찰했다.
⚠️ 함정 — 무엇을 지우는지 모르고 지우면 서비스가 끊긴다. ‘안 쓰는 게 확실한 것’만 내리고, 의존 관계가 헷갈리는 파드는 먼저 트래픽·연결을 확인한 뒤 손대는 게 안전했다.
시리즈 더 보기 — 같은 클러스터의 다른 단계
이 hub는 ‘애플리케이션 → 실행 → 비용 절감’ 흐름을 묶은 것이고, 시작 배경과 GKE 연결·GitOps 배포는 아래 글에 이어진다.
네 단계 모두 실험 클러스터에서 직접 밟은 순서이고, 숫자(690원·일일 청구액)는 그때 Billing 화면에서 본 그대로다. 더 다듬을 여지는 많지만, ‘처음 GKE를 만지며 비용을 줄여 본 기록’으로 한 곳에 모아둔다.
GKE 인프라 학습 시리즈 (요약본)
- GKE 인프라 학습 시리즈 시작 (개요·계획)
- (4-1) K8S를 GKE와 연결
- GKE에 직접 띄우고 비용 줄이기 (API 서버·K8s 실행·비용 최적화) (현재 글)
- (6) GitHub Actions
- (7) ArgoCD
- 도메인 발급 및 GKE와의 연결
📚 이 시리즈는 네이버 블로그 원본 10편을 요약·정리한 것입니다. 세부 절차를 순서대로 따라 하려면 → 네이버 블로그 원본 시리즈