단일 VM 환경에서 GCP 로드밸런서(ALB) 대신 Cloudflare를 선택한 이유

시작하며: 인증서 관리의 피로감과 로드밸런서의 유혹

개인 프로젝트나 초기 스타트업 단계에서는 비용 절감을 위해 하나의 가상 머신(VM)에 애플리케이션, 데이터베이스, 인메모리 캐시 등을 모두 올려서 운영하는 경우가 많습니다. 이때 가장 번거로운 작업 중 하나가 바로 Nginx 앞단에 Let's Encrypt를 연결하여 주기적으로 SSL 인증서를 갱신해 주는 일입니다.

이러한 인증서 갱신이나 Nginx 설정 관리의 피로감 때문에 클라우드 제공자가 관리해 주는 인증서(Google-managed SSL 등)를 사용하고자 Application Load Balancer(ALB) 도입을 고민하게 됩니다. 하지만 단일 VM 환경에서 단순히 인증서 관리 편의성만을 위해 ALB를 도입하는 것은 아키텍처 관점에서 매우 위험한 접근이 될 수 있습니다. 오늘은 그 이유와 가장 현실적인 대안에 대해 알아보겠습니다.

단일 VM에서 GCP ALB 도입의 치명적인 맹점

현재 운영 중인 아키텍처의 가장 큰 약점은 Nginx의 유무가 아닙니다. App, DB, Redis가 단일 VM에 몰려 있는 단일 장애점(SPOF, Single Point of Failure) 구조라는 사실입니다.

이 상태에서 앞단에 GCP 외부 애플리케이션 로드밸런서를 붙이더라도, 해당 VM 자체에 장애가 발생하거나 자원 경합으로 서버가 멈추면 서비스 전체가 마비됩니다. 로드밸런서의 핵심 이점인 고가용성과 부하 분산 효과를 전혀 얻을 수 없는 구조입니다.

또한, 비용 효율성 측면에서도 문제가 큽니다. GCP 외부 애플리케이션 로드밸런서는 데이터 처리량(Ingress/Egress)과 별개로 포워딩 룰(Forwarding rules)에 의해 시간당 고정 비용이 청구됩니다. 최초 5개 룰을 기준으로 시간당 약 $0.025가 발생하며, 트래픽 유무와 무관하게 매월 최소 약 $18 수준의 고정 비용을 지불해야 합니다. 단순히 SSL 인증서 발급을 위해 지불하기에는 매우 비효율적입니다.

인프라 구조 개선을 위한 5가지 아키텍처 방안 비교

이러한 문제점을 인식한 후, 현재 인프라 상태에서 적용할 수 있는 5가지 아키텍처 방안을 도출해보았습니다.

방안	설명
현 상태 유지	기존 Nginx를 유지하고 Certbot으로 SSL 자동 갱신
Cloudflare + 단일 VM	DNS를 Cloudflare로 이전하고 Edge 계층에서 SSL 자동 처리
단일 VM + GCP ALB	Nginx를 제거하고 GCP HTTPS LB를 붙여 Google-managed SSL 적용
Spring Boot 내장 Tomcat SSL	Nginx를 제거하고 Spring Boot 단에서 Keystore로 직접 HTTPS 처리
인프라 계층 분리 후 GCP ALB	App VM 다중화, DB/Redis 분리 후 GCP ALB 적용

최적의 선택: Cloudflare 무료 플랜 + Nginx 유지 전략

위의 5가지 방안 중 현재 트래픽 규모와 단일 VM이라는 제약 조건을 고려했을 때, 가장 영리하고 효율적인 접근은 방안 2 (Cloudflare + Nginx 유지) 입니다. Nginx를 함께 사용하는 전략입니다.

이 구조를 채택하면 다음과 같은 이점을 얻을 수 있습니다.

첫째, 도메인의 네임서버를 Cloudflare로 변경하고 프록시 모드를 켜면, 클라이언트와 Cloudflare 구간의 HTTPS 인증서 발급과 갱신이 무료로 자동 처리됩니다. 인증서 만료일에 맞춰 노심초사할 필요가 사라집니다.

둘째, 서버 내부적으로는 Cloudflare가 제공하는 Origin 인증서(최장 15년 유효)를 Nginx에 한 번만 등록해 두면 됩니다. 주기적인 인증서 갱신 작업이 완전히 사라집니다.

셋째, 거창한 '시스템 확장성'은 아니더라도 내부 구조의 '유연성(Flexibility)'을 확보할 수 있습니다. Nginx를 로컬 리버스 프록시로 유지하면 단일 VM 내에서 포트 포워딩을 제어하거나, 향후 도커 컨테이너를 여러 개 띄워 블루/그린 무중단 배포를 구성할 때 애플리케이션 코드 수정 없이 라우팅을 변경할 수 있습니다.

주의사항 1: Cloudflare 무료 WAF의 한계와 Nginx의 역할

여기서 많은 분들이 "Cloudflare를 붙였으니 Nginx를 지워버려도 되지 않을까?"라고 생각합니다. 하지만 이는 Cloudflare 무료 플랜의 맹점을 간과한 위험한 발상입니다.

Cloudflare의 무료 플랜이 제공하는 웹 방화벽(WAF)은 일부 Managed Ruleset과 기본적인 봇 방어 수준에 그칩니다. 특정 API에 대한 과도한 요청을 제어하는 세밀한 Rate Limiting(요청 빈도 제한) 기능은 Pro 플랜($25/월) 이상을 결제해야 온전히 사용할 수 있습니다.

만약 Nginx를 제거한다면, 악의적인 사용자가 무작위 대입 공격(Brute Force)을 가하거나 특정 API를 연속 호출할 때 Spring Boot 내장 Tomcat이 이를 맨몸으로 막아내야 합니다. 따라서 서버 내부의 Nginx를 제거하지 않고 limit_req_zone 지시어를 활용하여 2차 방어선을 구축하는 것이 필수적입니다. Cloudflare가 글로벌 엣지에서 1차로 악성 봇을 거르고, 통과해 들어온 과도한 비정상 요청은 서버 내부의 Nginx가 차단하는 역할 분담이 필요합니다.

주의사항 2: Cloudflare 우회 공격 원천 차단하기

이 아키텍처를 적용할 때 반드시 명심해야 할 또 다른 보안 설정이 있습니다. DNS를 Cloudflare로 연결했다고 해서 서버의 원래 공인 IP가 인터넷 공간에서 완전히 사라지는 것은 아닙니다.

만약 공격자가 널리 알려진 포트 스캐닝 도구 등을 통해 단일 VM의 공인 IP를 알아낸다면, Cloudflare의 WAF를 거치지 않고 서버로 직접 트래픽을 쏠 수 있습니다. 이를 방지하기 위해 반드시 GCP 방화벽(VPC Firewall) 규칙을 수정하여 Cloudflare의 공식 IP 대역에서 들어오는 443(HTTPS) 및 80(HTTP) 포트 요청만 허용해야 합니다. 그 외의 모든 직접적인 Public IP 접근(Ingress) 트래픽은 차단하도록 설정해야 우회 공격을 막고 진정한 의미의 인프라 보호가 완성됩니다.

마무리

시스템 아키텍처를 설계할 때는 단순히 좋아 보이는 기술을 가져다 붙이거나, 불편하다고 해서 무작정 기존 요소를 제거(Nginx 삭제)하는 것은 위험합니다. 현재 시스템의 병목 지점과 도입하려는 서비스의 요금제 한계를 정확히 파악하는 것이 중요합니다.

단일 인스턴스에 종속된 통합 환경 앞단에 비싼 클라우드 로드밸런서를 배치하는 것은 목적에 부합하지 않습니다. 비용, 성능, 그리고 방어력이라는 세 마리 토끼를 잡아야 하는 현 상황에서는 Cloudflare 무료 플랜으로 Edge 단에서 트래픽을 1차로 정리하고, Nginx를 유지하여 내부 유연성과 2차 방어선을 챙기는 것이 가장 합리적이고 안전한 선택이 될 것입니다.