작은 규모의 웹 서비스에서 운영 부담을 줄이는 가장 확실한 방법은 “하나의 플랫폼으로 모으는 것”입니다. Cloudflare를 정적 배포, CDN, 동적인 요청 처리까지 한 플랫폼으로 사용할 수 있는 구조로 운영 부담을 줄일 방법을 간단히 정리합니다.
정적 배포 (Pages)
정적 사이트로 빌드해서 Cloudflare Pages에 배포합니다. 전 세계 CDN 엣지에서 캐시되므로 첫 화면 로딩이 빠릅니다. SSL/TLS 인증서도 무료로 적용할 수 있습니다.
동적 기능 (Workers)
동적 기능이 필요할 때는 별도 서버 대신 Cloudflare Workers에 배포합니다.
export default {
async fetch(request) {
return new Response('Hello from Workers');
}
};단, 이 기능은 무료 쿼터로는 한계가 있으니 동적인 트래픽을 잘 주시하고 언제든 독립 서버로 트래픽을 돌릴 준비를 하는 것이 좋습니다 - 물론 이런 상황이 온다면 이미 성공적인 서비스라는 신호일 겁니다.
독립 서버를 운영한다면 Cloudflare와 서버 구간에는 자동으로 HTTPS 연결이 되지는 않습니다. 하지만 이 부분도 Cloudflare Tunnel을 사용한다면 별도 인증서 구매나 설정도 필요 없어지니 서비스 초기에는 활용해 볼만 합니다.
데이터 및 오브젝트 저장 (D1, R2)
데이터베이스인 D1과 오브젝트 저장소인 R2의 가장 큰 특징은 데이터 전송(Egress) 비용이 무료라는 점입니다. 이를 잘 활용해서 비용이 발생하는 부분에 캐시를 두는 등으로 최적화한다면 운영 비용을 크게 줄일 수 있습니다.
아키텍처 구성
- 정적 콘텐츠: 정적 사이트 빌드 → Cloudflare Pages → CDN
- 동적 API: Cloudflare Workers → 원본 서버 대체
- DNS/보안: Cloudflare DNS + SSL/TLS
운영 부담이 줄어드는 이유
- 전 세계 CDN 캐시 자동 적용
- 자동 SSL/TLS 인증서
- 서버리스로 운영 가능
- Egress가 무료인 저장소
기타
이렇게 구성을 하면 플랫폼 종속과 함께 Cloudflare 자체가 단일 실패 지점(SPOF, Single Point of Failure)이 된다는 단점이 있습니다. 하지만 전체 스택을 AWS 같은 클라우드 인프라 플랫폼에서 운영하는 경우가 많은 요즘엔 딱히 문제라고 보기 어렵고, “서비스 초기에 운영 부담을 최소화하고 싶다”는 요구에 부합하는 아키텍처로는 아직 대체할 만한 것이 없어 보입니다.