Netlify와 Cloudflare Pages는 시작 단계에서는 비슷해 보이기 쉽다. 둘 다 저장소를 연결하고 배포를 돌리고 live URL을 바로 얻을 수 있기 때문이다. 그래서 많은 팀이 너무 빨리 고른다.

차이는 나중에 드러난다. preview가 일상적인 운영 루프에 들어오고, functions가 필요해지고, 비용이 단순한 가격표 숫자가 아니게 되는 순간부터다.

이 글은 브랜드 선호가 아니라 운영 형태를 기준으로 두 플랫폼을 비교하는 방법을 다룬다. 목표는 어떤 플랫폼이 지금 팀의 deploy loop, 비용 구조, rollback 방식에 더 잘 맞는지 판단하는 것이다.

1. 사람들이 자주 틀리는 지점은 가격표 숫자만 먼저 비교하는 것이다

많은 팀이 요금제 이름과 월 요금부터 본다. 얼핏 효율적으로 보이지만, 실제 운영 비용 구조를 놓치기 쉽다.

build minutes, bandwidth, function usage, preview usage, rollback recovery는 서로 다른 종류의 비용을 만든다. 겉으로는 더 싸 보이는 플랫폼이 운영 루프가 바뀐 뒤에는 더 비싸질 수도 있다.

2. 가장 좋은 비교는 기능표보다 운영 적합성에서 시작한다

여기가 핵심 기준이다. 호스팅 플랫폼은 generic feature list로 비교하면 안 된다. 실제로 어떤 일을 반복해서 싣게 될 플랫폼인지부터 봐야 한다.

preview 링크를 자주 쓰고, branch 기반 리뷰가 중요하고, plugin ecosystem을 넓게 활용하는 팀이라면 한쪽이 더 자연스러울 수 있다. 반대로 워크플로가 이미 Cloudflare edge 모델과 가까워서 정적 배포와 주변 edge 기능을 함께 보는 팀이라면 다른 쪽이 더 잘 맞을 수 있다.

중요한 건 “어느 서비스가 더 많은 기능을 가졌는가”가 아니다. “우리의 평소 deploy loop를 어느 쪽이 덜 마찰적으로 만들어주는가”다. 문서상으론 더 풍부해 보여도, preview 검토를 느리게 만들거나 rollback을 어색하게 만들거나, 반복 배포의 숨은 비용을 키우면 운영 기준으로는 더 나쁜 선택일 수 있다.

그래서 비용과 기능은 같이 읽어야 한다. preview 동작은 review 비용을 바꾸고, function 모델은 유지보수 비용을 바꾸고, rollback 방식은 사고 비용을 바꾼다. 좋은 비교는 이걸 하나의 운영 시스템으로 본다.

3. 먼저 비교할 다섯 축

• build와 deploy 흐름
• preview와 branch review 동작
• bandwidth와 자산 전달 구조
• functions나 동적 확장 경로
• rollback과 recovery 속도

4. 예시 하나만 봐도 선택 기준이 달라진다

예를 들어 문서 중심 팀이 매주 preview build를 많이 만든다고 하자. 이런 경우 raw edge integration보다 preview 동작과 검토 편의가 더 중요할 수 있다. 그때 더 좋은 플랫폼은 review friction과 반복 배포의 숨은 비용을 줄여주는 쪽이다.

반대로 정적 중심 사이트가 이미 Cloudflare 서비스와 가까이 묶여 있다면, edge 환경의 일관성, 자산 전달 방식, 주변 기능과의 결합이 더 중요한 기준이 될 수 있다.

5. rollback은 비용과 따로 보면 안 된다

많은 팀이 플랫폼 비용과 recovery 동작을 따로 비교한다. 하지만 rollback이 느리거나, 복구 흐름이 어색하거나, preview 이력이 불분명하면 그것도 운영 비용이다.

가격이 조금 싸도 production 실수를 되돌리는 속도가 느리면 실제로는 더 비싼 선택일 수 있다.

무엇부터 시작할까

지금 팀의 deploy loop를 한 줄로 적어라. 얼마나 자주 배포하는지, preview를 얼마나 자주 검토하는지, functions가 필요한지, rollback이 얼마나 빨라야 하는지다. 그다음 marketing page가 아니라 그 운영 루프를 기준으로 Netlify와 Cloudflare Pages를 비교해라.