[Lap 01] 월 0원 GCP 서버리스 워드프레스 아키텍처 설계

“시스템 아키텍처에서 가장 먼저 점검해야 할 것은 불필요한 기술 부채와 매달 고정적으로 새어나가는 유지 비용입니다.”
개인 기술 블로그와 앞으로 만들 AI·퀀트 프로젝트의 기록 공간을 구축하면서 제가 가장 먼저 세운 원칙은 명확했습니다. 방문자가 있든 없든 매달 고정적으로 빠져나가는 클라우드 비용을 0원으로 통제하면서도, 트래픽이 몰릴 때는 유연하게 확장되는 구조를 직접 설계하자는 것이었습니다.
이 글에서는 많은 분이 관성적으로 선택하는 유료 웹호스팅이나 저가형 VPS 대신, 월 고정비 0원($0/month)과 자동 확장성(Auto-scaling)을 동시에 달성하기 위해 Google Cloud Platform(GCP) 서버리스와 Cloudflare를 결합해 구축한 아키텍처 설계 과정을 정리해 보려 합니다.

1. 시작하며: 왜 기성 호스팅 대신 인프라를 직접 설계했는가?

개발자이자 아키텍트로서 나만의 블로그를 구축하려 할 때 흔히 떠올리는 선택지는 티스토리, 네이버 블로그 같은 가입형 플랫폼이거나, 월 15,000원~40,000원 수준의 AWS Lightsail, 카페24 같은 워드프레스 호스팅입니다.

혹시 개인 프로젝트나 블로그를 운영하면서 “방문자가 많지도 않은데 매달 나가는 서버비가 은근히 아깝다”고 느껴보신 적 없으신가요? 기성 플랫폼이나 저가형 VPS 호스팅을 아키텍처 관점에서 뜯어보면 꽤 아쉬운 트레이드오프가 존재합니다.

시스템 설계에서나 투자에서나 제가 중요하게 생각하는 원칙 중 하나는 ‘불필요한 고정 현금 유출(Drawdown)의 통제’입니다. 아직 트래픽이 크지 않은 초기 단계부터 매월 서버비와 DB 비용으로 몇만 원씩 고정 지출이 누적된다면, 프로젝트를 길게 끌고 가는 데 적지 않은 부담이 됩니다.

반대로 방문자가 없을 때는 정확히 0원이 청구되고, 검색 유입으로 수만 명이 동시에 몰려와도 다운되지 않고 유연하게 확장되는 인프라를 만들 수 있다면 어떨까요? 이것이 바로 제가 상용 호스팅을 결제하는 대신 직접 아키텍처를 스케치한 이유입니다.

2. 전체 시스템 청사진: 월 0원 서버리스 워드프레스 아키텍처

제가 구성한 전체 아키텍처는 서로 역할을 분담하는 4개의 핵심 컴포넌트로 이루어져 있습니다.

flowchart LR
    User["웹 방문자 / 브라우저"] -->|"HTTPS (Anycast)"| CF["Cloudflare Edge (서울 ICN PoP)<br/>• SSL Full (Strict)<br/>• 정적 파일 엣지 캐싱 (HIT)<br/>• WAF: xmlrpc 차단 & wp-login 챌린지"]
    CF -->|"Origin 요청<br/>(캐시 미스 & 동적 페이지)"| CR["GCP Cloud Run (오리건 us-west1)<br/>• 커스텀 워드프레스 (PHP 8.3 + Apache)<br/>• Scale-to-Zero (min: 0, max: 2)<br/>• Direct VPC Egress"]
    CR -->|"미디어 비동기 오프로딩"| GCS["Google Cloud Storage (GCS)<br/>• 버킷: [PROJECT_ID]-wp-media<br/>• us-west1 Standard (Always Free 5GB)<br/>• WP-Stateless Keyless ADC 연동"]
    CR -->|"내부 VPC 사설 IP<br/>(예: 10.x.x.x:3306)"| DB["GCP Always Free VM (us-west1-a)<br/>• e2-micro (1GB RAM)<br/>• 2GB Swap + Low-Memory MariaDB<br/>• Secret Manager 연동"]

각 컴포넌트의 역할과 무과금 메커니즘

1. 컴퓨팅 (Google Cloud Run):
• 일반적인 상시 가동 서버와 달리, 트래픽이 없으면 메모리와 CPU를 완전히 반납하고 0개의 인스턴스로 대기(Scale-to-Zero)합니다.
• GCP는 매월 200만 회의 요청, 18만 vCPU-초, 36만 GiB-초를 영구 무료(Always Free Tier 1)로 제공합니다. 개인 기술 블로그 트래픽 수준에서는 컴퓨팅 비용이 완전히 0원입니다.
2. 데이터베이스 (Always Free e2-micro VM + MariaDB):
• 클라우드 관리형 DB인 Cloud SQL을 쓰면 가장 작은 인스턴스(db-f1-micro)조차 월 $15(약 2만 원) 안팎의 고정 비용이 발생합니다.
• 대신 저는 GCP 미국 리전에서 평생 무료로 제공하는 e2-micro(RAM 1GB, 30GB 디스크) 인스턴스를 생성하고, 저메모리 환경에 맞게 튜닝한 MariaDB를 직접 올려 DB 비용을 영구 0원으로 맞췄습니다.
• Cloud Run과는 Direct VPC Egress로 내부 사설 IP(예: 10.x.x.x:3306) 통신을 연결하여, 별도의 Serverless VPC Access 커넥터 VM 비용(월 약 $8)도 절감했습니다.
3. 미디어 영구 저장소 (Google Cloud Storage):
• Cloud Run 컨테이너의 로컬 파일시스템은 휘발성 메모리이므로, 컨테이너가 내려가면 로컬에 업로드된 이미지 파일도 함께 사라집니다(Stateless).
• 그래서 업로드된 이미지를 미국 리전 GCS 버킷(Always Free 5GB 무료)으로 즉시 오프로딩(WP-Stateless)하여 영구 보존하도록 구성했습니다.
4. 글로벌 CDN 및 엣지 보안 (Cloudflare CDN & WAF):
• 미국 오리건 리전의 물리적 거리 한계를 서울 엣지(ICN) 캐싱으로 보완하고, 악성 봇 트래픽이 Cloud Run 컨테이너를 불필요하게 깨우지 못하도록 앞단에서 차단합니다.

3. 첫 번째 시행착오: 서울 리전(asia-northeast3)의 3가지 함정 (ADR-001)

Warm-up Lap에서 살펴본 것처럼, 저 역시 처음 아키텍처를 스케치할 때는 한국 개발자라면 누구나 자연스럽게 떠올릴 법한 생각을 했습니다.

“한국 독자를 위한 블로그니까, 당연히 Cloud Run 리전을 서울(asia-northeast3)로 잡아야 속도가 제일 빠르겠지?”

여러분도 처음 클라우드 리전을 고를 때 이렇게 생각하시지 않나요? 하지만 초기 구상 아키텍처를 실제로 프로비저닝하며 GCP의 과금 체계와 기능 제약을 하나씩 따져보니, 서울 리전 배치는 3가지 치명적인 문제를 안고 있었습니다.

💡 아키텍트의 노트: ADR(Architecture Decision Record)이란?
시스템을 구축할 때 마주친 심각한 문제의 배경, 대안 간의 트레이드오프, 그리고 최종 결정을 구조화해 공식 기록으로 남기는 엔지니어링 문서입니다. 본 5부작 시리즈의 모든 문제 해결은 사전에 수립된 공식 ADR(Architecture Decision Record)에 기반합니다. (배경과 전체 6대 ADR 설정 과정은 Warm-up Lap을 참조하세요.)

함정 1: 커스텀 도메인 무료 매핑 불가 (월 $18의 강제 과금)

Cloud Run은 gcloud beta run domain-mappings 명령어를 통해 wealth-podium.com 같은 커스텀 도메인과 Google 관리형 무료 SSL 인증서를 0원에 연결해 주는 편리한 기능을 제공합니다.

그런데 GCP 공식 문서를 확인해 보니, 서울(asia-northeast3) 리전은 이 기본 도메인 매핑 기능을 지원하지 않았습니다.

서울 리전의 Cloud Run에 커스텀 도메인을 붙이려면 ‘전역 외부 애플리케이션 부하 분산기(Global External Application Load Balancer)’를 반드시 앞단에 두어야 하는데, 이 로드밸런서는 트래픽이 전혀 없어도 기본 포워딩 룰 유지비로 매달 최소 $18(약 25,000원)가 과금됩니다. ‘월 유지비 0원’이라는 설계 목표가 첫 단추부터 무너지는 셈이었습니다.

함정 2: 태평양 횡단 SQL 쿼리 지연 증폭 (Latency Amplification = 4.2초 지연)

Always Free 혜택을 받는 e2-micro VM은 GCP 정책상 미국 리전(us-west1, us-central1, us-east1)에서만 무료로 생성할 수 있습니다. 따라서 DB VM은 오리건(us-west1-a)에 위치해야 했습니다.

만약 애플리케이션 컨테이너(Cloud Run)는 서울에 두고, 데이터베이스(MariaDB)만 오리건에 둔다면 어떤 일이 벌어질까요? 한번 같이 계산해 보겠습니다.

• 서울 ↔ 오리건 간 해저 광케이블 단방향 왕복 지연(RTT)은 약 130~150ms입니다.
• 워드프레스는 정적 사이트가 아니라, 페이지 하나를 렌더링할 때 테마 설정, 플러그인 훅, 포스트 메타데이터를 조회하느라 평균 25~40회의 SQL 쿼리를 순차적(Synchronous)으로 실행합니다.

애플리케이션 서버와 DB가 태평양을 사이에 두고 30~40번 왕복 통신을 주고받는 동안, 사용자의 브라우저는 4초 넘게 흰 화면만 기다리게 됩니다. TTFB(Time to First Byte)가 4초를 넘어가는 사이트는 사용자 경험은 물론 구글 SEO 평가에서도 좋은 점수를 받기 어렵습니다.

함정 3: 리전 간 Cross-Region VPC Egress 네트워크 과금

Cloud Run과 DB VM을 Direct VPC Egress로 연결하더라도, 통신 구간이 서로 다른 리전(서울 ↔ 오리건)을 넘나들면 GCP 내부망이라 할지라도 Cross-Region Egress 트래픽 요금(GB당 약 $0.08 ~ $0.12)이 부과됩니다. 무료 인프라를 지향했는데 보이지 않는 곳에서 네트워크 비용이 새어나가게 되는 구조였습니다.

4. 아키텍처 피벗: 오리건(us-west1) 단일 리전 통합과 Cloudflare 서울 엣지 연계

이 세 가지 문제를 확인한 직후, 저는 지체 없이 아키텍처 의사결정(ADR-001)을 내리고 리전 전략을 전면 수정했습니다.

“애플리케이션과 데이터베이스는 반드시 같은 리전에 밀착 배치해야 한다. 모든 GCP 리소스를 무료 DB VM이 위치한 오리건(us-west1)으로 단일 통합한다.”

# Cloud Run 배포 리전과 Artifact Registry, GCS 버킷 리전을 모두 us-west1으로 통일
gcloud config set run/region us-west1
gcloud config set artifacts/location us-west1

이렇게 리전을 오리건 한곳으로 통일하자 모든 수치와 비용 구조가 깔끔하게 맞아떨어졌습니다.

1. 내부 DB 쿼리 레이턴시: 150ms → 0.8ms (약 180배 단축)
• Cloud Run 컨테이너와 MariaDB VM(사설 IP 예시: 10.x.x.x)이 오리건 리전의 동일 VPC 서브넷 안에서 Direct VPC Egress로 통신하게 되면서, 단일 쿼리 왕복 지연이 1ms 미만으로 줄어들었습니다. 워드프레스가 40개의 쿼리를 연속으로 실행해도 DB 조회에 걸리는 총시간은 30ms 남짓에 불과합니다.
2. 네트워크 통신 비용: $0.00 달성
• 동일 리전·동일 가용영역 내 사설 IP 통신이므로 리전 간 트래픽 과금이 100% 면제됩니다.
3. 무료 커스텀 도메인 매핑 & Google 관리형 SSL 적용
• us-west1 리전은 Cloud Run 기본 도메인 매핑(gcloud beta run domain-mappings)을 지원하므로, 월 $18짜리 로드밸런서 없이도 도메인과 SSL 인증서를 무료로 연결했습니다.
4. 한국 방문자 체감 속도는 Cloudflare 서울 엣지(ICN PoP)로 보완
• “서버가 미국 오리건에 있으면 한국에서 접속할 때 느리지 않을까?” 하고 궁금해하실 수 있습니다. 이 부분은 Cloudflare 엣지 캐싱으로 해결했습니다.
• 웹페이지 용량의 80~90%를 차지하는 이미지, 웹폰트, CSS, JS 등 정적 에셋은 한국 방문자와 가장 가까운 Cloudflare 서울 데이터센터(ICN)에 캐싱(CF-Cache-Status: HIT)되어 즉시 응답하므로, 실제 체감 로딩 속도는 0.2~0.5초 수준으로 쾌적하게 유지됩니다.

5. 마치며: 다음 글(Lap 2) 예고

첫 번째 단계에서는 매달 고정비를 발생시키는 클라우드 함정들을 피해, 월 유지비 0원이면서도 확장성과 응답 속도를 갖춘 서버리스 아키텍처의 뼈대를 잡았습니다.

• 상시 호스팅 고정비: 0원
• 관리형 DB(Cloud SQL) 및 로드밸런서 비용: 0원
• 대륙 간 DB 쿼리 지연: us-west1 단일 리전 통합 + Cloudflare 엣지 캐시로 해결

하지만 인프라의 큰 그림을 그렸다고 해서 구축이 끝난 것은 아닙니다. 단 1GB의 RAM만 제공되는 무료 e2-micro VM에 기본 설정 그대로 MariaDB를 올리면 얼마 지나지 않아 메모리 부족(OOM)으로 DB가 죽어버리기 일쑤입니다.

다음 글에서는 1GB RAM 환경에서 MariaDB가 안정적으로 돌아가도록 메모리를 튜닝한 과정과, GCP의 변경된 IAM 보안 정책을 해결하며 완성한 Cloud Build 무중단 CI/CD 파이프라인 구축기를 이어서 다루어 보겠습니다.