프런트엔드 호스팅의 갈림길은 대개 청구서가 움직이기 시작한 뒤에 드러난다. 사이트가 늘고 트래픽이 오르면 대역폭과 빌드 횟수가 새로운 변수가 된다. Cloudflare Pages 는 무료의 경계를 다른 곳에 두었다. 사이트와 좌석과 요청과 대역폭은 옆으로 밀어 두고, 할당 표가 실제로 지켜보는 것은 빌드 횟수와 프로젝트 수와 파일 하나의 크기다.

빌드와 배포를 같은 네트워크에 올린다

Cloudflare 는 Pages 를 팀이 앱을 빠르게 만들고 함께 손보고 시험하고 배포까지 진행하는 서버리스 플랫폼으로 소개한다. 제품 페이지의 한 줄 요약은 더 직접적이다. 전체 스택 앱은 빌드가 끝나면 곧바로 Cloudflare 의 세계 네트워크에 올라간다. 배포는 자사 네트워크가 맡고, 제품 페이지에 따르면 이 서비스는 인터넷 트래픽의 이십 퍼센트를 받치는 계통 위에서 돈다. 기업 수준의 신뢰성과 안전성과 속도는 기본 설정이며 HTTP/3 와 QUIC 과 이미지 압축과 SSL 이 처음부터 쓸 수 있는 범위에 든다. 공개까지 가는 길은 셋이다. 코드 보관 플랫폼을 연결하거나, Direct Upload 로 완성된 산출물을 그대로 올리거나, 명령줄 도구로 손에서 보낸다. 정적 사이트와 전체 스택 앱은 같은 배포 모형을 공유하고, Pages Functions 가 서버 쪽 코드를 돌린다.

빌드 설정은 기본 목록에 맡긴다

코드 보관 플랫폼을 연결하면 밀어 올릴 때마다 빌드와 배포가 한 번씩 돌아간다. Cloudflare 는 흔한 틀을 위해 기본 목록을 준비해 두었고, React, Gatsby, Next.js 의 정적 내보내기, Nuxt, Qwik, Remix, Svelte, SvelteKit, Vue, Angular, Docusaurus, Hugo, Jekyll, Eleventy, VitePress, Zola 가 이름을 올린다. 기본 항목마다 빌드 명령과 산출물 자리가 붙는다. 성공 여부는 종료 값이 정한다. 영이 아닌 값을 돌려주면 실패로 표시되고, 영이면 성공으로 보아 산출물을 올린다. 표준 오류 쪽에 기록이 남아도 이 판단은 바뀌지 않는다. 뿌리 자리는 기본으로 저장소 뿌리가 되고, 하나 안에 여러 프로젝트를 담은 저장소일 때만 직접 지정한다. 산출물 자리는 빌드 명령이 만들며, 대부분의 틀은 관례대로 public 아래에 떨어진다.

코드 보관을 거치지 않는다면 Direct Upload 가 이미 만든 산출물을 묶어 올린다. 빌드 절차를 자사 플랫폼이나 손의 기계에 두는 상황에 맞는다. 명령줄 방식은 한 번에 폴더 하나를 올리고 공식 상한은 파일 이만 개다. 화면에 압축 묶음이나 폴더 하나를 끌어다 놓는 방식은 천 개까지 받는다. 둘 다 파일 하나는 25 MiB 에서 막힌다. 함수 폴더는 명령줄과 함께 올려야 하고, 따로 선 worker 스크립트는 두 방식 모두 알아본다.

할당 표가 실제로 지켜보는 것

무료의 경계는 공식 표에 줄마다 적혀 있다. 동시 빌드는 이해하기 쉽다. 무료는 한 번에 하나만 돌고, Professional 은 다섯, Business 는 스물이다. 동시 수는 계정마다 세고, 한 번의 빌드가 이십 분을 넘기면 중단된다. 월 빌드 횟수는 차례로 오백, 오천, 이만이다. 사용자 도메인은 프로젝트마다 백, 이백오십, 오백이다. 파일 수에서는 무료가 사이트 하나에 이만 개까지 놓을 수 있고 위 단계는 십만 개까지 넓어진다. 프로젝트 설정에서 해당 환경 변수를 켜 두어야 한다. 자원 파일 하나는 25 MiB 가 상한이다. 미리보기 배포와 협업 사용자는 둘 다 무제한이고, 계정 단위 프로젝트 수는 백에서 멈추며, 공식은 이 한도는 관례대로 올리지 않는다고 적는다.

요청 층은 작은 파일 두 개가 받는다

정적 자원의 응답 머리와 넘김 규칙은 순수한 텍스트 파일 두 개가 맡는다. 둘 다 자원으로 공개되지 않고 산출물 자리 안에서 플랫폼이 읽을 뿐이다. 응답 머리 파일은 규칙이 백 개까지이고, 한 줄은 빈칸과 이름과 값을 합쳐 이천 자에서 막힌다. 한 요청이 여러 규칙에 걸리면 각 규칙이 밝힌 머리를 모두 이어받는다. 넘김 파일은 한 줄에 선언 하나만 쓰고 순서가 결과를 좌우한다. 같은 출발 경로에 선언이 여러 개 있으면 위에 있는 것이 먼저 효력을 내고, 정적 규칙은 동적 규칙보다 앞에 놓아야 한다. 용량은 정적 넘김이 이천, 동적 넘김이 백으로 합쳐 이천백이며, 선언 하나는 천 자에서 막힌다. 두 파일이 같은 요청에 걸리면 넘김이 응답 머리보다 먼저 돈다.

미리보기, 되돌리기, 배포 갈고리

저장소에 새 병합 요청을 하나 열 때마다 그 변경을 위한 별도 미리보기 링크가 생기고, 내용은 가지에 쌓이는 뒤의 제출에 맞춰 계속 갱신된다. 새 가지를 만들 때마다 프로젝트 하위 도메인 앞에 무작위로 만든 해시가 붙어 새 미리보기 주소가 된다. 플랫폼은 또 가지 이름의 별명을 만들어 그 별명이 가지의 제출을 따라 앞으로 굴러가게 한다. 운영 도메인과 프로젝트에 붙인 사용자 도메인은 미리보기 배포의 영향을 받지 않는다. 이런 임시 사본이 검색 결과에 영향을 주지 않도록 공식은 모든 미리보기 배포에 검색 체계가 줍지 않게 하는 표시를 기본으로 붙인다. 되돌리기의 대상은 빌드에 성공한 운영 배포라면 어느 것이든 되고, 되돌린 뒤에도 더 새로운 판으로 다시 옮길 수 있으며 미리보기 배포는 되돌리기 대상이 되지 않는다. 도메인 연결은 두 갈래다. 뿌리 도메인은 먼저 사이트를 Cloudflare 에 붙이고 이름 서버를 바꿔 플랫폼이 기록을 만들게 한다. 하위 도메인은 지금 분석 사업자에게 CNAME 기록 하나를 더해 프로젝트의 하위 도메인을 가리키면 된다.

배포 갈고리는 시작 지점을 제출에서 다른 곳으로 옮긴다. 갈고리마다 고유 주소가 있고 HTTP POST 를 한 번 받으면 빌드가 한 번 돈다. 설정할 때 넣는 것은 갈고리 이름과 빌드할 가지 둘뿐이다. 공식은 주소를 부르기만 하면 누구나 빌드를 걸 수 있다고 경고하며, 기밀로 다루고 쓰인 흔적이 의심되면 지우고 다시 만들라고 한다. 이 방식은 내용을 외부 관리 체계에서 유지하면서 사이트도 그에 맞춰 새로워지길 바라는 상황에 맞는다. 자체 지속 통합 흐름에 끼워 넣거나 정한 시각에 다시 빌드하게 할 수도 있다.

Cloudflare Pages 는 프런트엔드 호스팅을 셋으로 나눴다. 빌드는 기본 목록 안에서 끝나고, 배포는 자사 세계 네트워크에 오르고, 할당은 공개된 표에 적힌다. 눈여겨볼 점은 무료 판이 열어 둔 항목이 많다는 것이다. 사이트와 좌석과 요청과 대역폭은 옆으로 밀리고, 실제로 따져야 할 것은 월 빌드 횟수와 프로젝트 수와 파일 하나의 크기다. 트래픽의 오르내림이 크고 대역폭 비용을 가늠하기 어려운 정적 사이트와 전체 스택 앱에는 이 조합이 청구서의 불확실성을 아주 낮게 눌러 준다.