← 목록으로ARCHITECTURE

Cloudflare Pages 배포와 커스텀 도메인 연결, 실제로 걸린 시간은 10분

Cloudflare Pages 배포와 커스텀 도메인 연결, 실제로 걸린 시간은 10분

이 블로그는 지금 Cloudflare Pages에서 서빙됩니다. 붙이는 데 실제로 쓴 시간은 10분 남짓인데 그중 9분은 대시보드를 클릭한 시간이고 나머지는 기다린 시간이었어요. 서버 설정은 한 줄도 없었고요.

정적 사이트라면 이 조합이 가장 게으른 선택입니다. git push 한 번이 곧 배포고 트래픽이 얼마나 오든 무료 구간에서 대역폭 제한이 없습니다. 인프라를 왜 이렇게 잡았는지는 1인 개발자를 위한 최소 인프라에 정리해 뒀습니다.

1. GitHub 저장소 연결

Cloudflare 대시보드에서 Workers & Pages → Create application → Pages → Connect to Git으로 들어가 저장소를 고릅니다. 비공개 저장소도 됩니다. 저는 개인 계정의 private 저장소를 붙였는데 별도 설정은 필요 없었어요.

Cloudflare 공식 문서의 Git 연동 안내 — Workers & Pages에서 Create application, Pages, Connect to Git 순서로 진행하라는 설명

공식 문서에도 같은 순서로 적혀 있습니다. GitHub과 GitLab 둘 다 지원하고, 연결해 두면 PR마다 프리뷰 배포까지 따라옵니다.

2. 빌드 설정은 두 칸이 전부

프레임워크를 자동 감지해 주는데 값이 맞는지만 확인하면 됩니다. 이 블로그(Astro) 기준으로는 이렇습니다.

Build command:            npm run build
Build output directory:   dist

프레임워크별로 출력 디렉터리만 다릅니다. Cloudflare가 프레임워크별 빌드 설정 표를 문서에 정리해 뒀으니 헷갈리면 거기서 확인하세요. Next.js 정적 export는 out, Vite는 dist, CRA는 build. 여기서 틀리면 빌드는 성공했는데 사이트가 404가 납니다. 빌드 로그는 성공인데 화면이 비어 있으면 이 칸부터 보세요.

Save and Deploy를 누르면 첫 배포가 돌고 프로젝트명.pages.dev 주소가 나옵니다. 여기까지 5분.

3. 커스텀 도메인 연결

여기서 순서가 중요합니다. 네임서버를 먼저 Cloudflare로 옮겨두면 이 단계가 5분 안에 끝나고 안 옮겼으면 최대 48시간이 걸립니다.

네임서버부터 옮기는 순서는 이렇습니다.

  1. Cloudflare에서 Add a Site로 도메인을 등록하고 Free 플랜을 고릅니다.
  2. Cloudflare가 알려주는 네임서버 두 개를 받아 적습니다. (xxx.ns.cloudflare.com 형태)
  3. 도메인을 산 곳(가비아, 후이즈 등)의 관리 화면에서 기존 네임서버를 지우고 이 두 개를 넣습니다.
  4. 전파를 기다립니다. 보통 1시간 안쪽인데 공식적으로는 최대 48시간이에요.

도메인 등록기관의 네임서버 설정 화면 — 1차와 2차 네임서버 입력란에 주소를 넣고 저장하는 모습

등록기관마다 화면은 다르지만 넣는 값은 똑같습니다. 1차와 2차 칸에 Cloudflare가 준 주소 두 개를 넣고 저장하면 끝입니다.

전파가 끝나면 Pages 프로젝트의 Custom domains 탭에서 도메인을 입력하면 그만입니다. CNAME 레코드는 Cloudflare가 알아서 만들고 SSL 인증서도 자동 발급됩니다. “초기화 중”이 “활성”으로 바뀌면 끝이에요.

DNS 레코드를 손으로 만질 일이 없습니다. 이게 이 조합의 실질적인 장점이고요. 네임서버가 이미 Cloudflare에 있으면 도메인 연결은 정말로 클릭 세 번입니다.

배포는 얼마나 빨리 반영되나

체감이 궁금해서 직접 재봤습니다. main에 push한 시점부터 프로덕션에 새 글이 뜨기까지 80~90초였습니다. 두 번 재서 각각 80초, 90초. 페이지 6~7장짜리 정적 사이트 기준이니 규모가 커지면 늘어나겠지만 글 하나 고치고 반영됐는지 확인하는 리듬으로는 충분히 빠릅니다.

미리 알았으면 좋았을 것들

출력 디렉터리 오타는 404로 나타납니다. 빌드 로그가 초록불이어도 안심하긴 이릅니다. 배포하고 화면이 비었으면 빌드가 아니라 경로 문제예요.

Error 1014는 도메인이 다른 계정에 묶여 있다는 뜻입니다. CNAME Cross-User Banned라는 메시지가 뜨면 같은 도메인이 다른 Cloudflare 계정에 등록돼 있는 겁니다. 그쪽에서 먼저 지워야 합니다.

SSL 오류는 대개 기다리면 풀립니다. 네임서버를 막 바꾼 직후에 자주 나옵니다. 그래도 계속되면 SSL/TLS 암호화 모드가 Full 또는 Full (Strict)인지 확인하세요.

바뀐 게 안 보이면 캐시부터 의심하세요. 시크릿 창으로 한 번 열어보는 게 제일 빠릅니다. 배포는 됐는데 내 화면만 그대로인 경우가 생각보다 흔합니다.

robots.txt가 내가 쓴 대로 안 나옵니다. 이건 저도 배포하고 나서야 알았어요. Cloudflare가 관리형 robots.txt 규칙을 내 robots.txt 앞에 자동으로 붙입니다. 열어보면 GPTBot, ClaudeBot 같은 AI 크롤러를 차단하는 규칙이 먼저 나오고 내가 쓴 내용은 그 아래에 붙어 있습니다. 검색엔진 색인에는 영향이 없지만 AI 검색에 내 글이 인용되길 원한다면 대시보드에서 이 설정을 꺼야 합니다.

절대 URL을 쓰는 설정은 도메인 확정 후 반드시 갱신하세요. 사이트맵, canonical, og:image가 전부 여기서 나옵니다. Astro라면 astro.config.mjssite 한 줄이에요.

export default defineConfig({
  site: "https://example.com",
});

플레이스홀더로 둔 채 배포하면 SEO 태그가 전부 가짜 도메인을 가리킵니다. 사람 눈에는 안 보이고 검색엔진 눈에만 보이는 종류의 실수라 한참 뒤에야 발견합니다.

정리

정적 사이트를 올릴 곳을 고민 중이라면 Cloudflare Pages는 선택지가 아니라 기본값에 가깝습니다. 붙이는 데 10분, 이후 운영 부담은 push 한 번이 전부니까요.

순서만 지키면 됩니다. 네임서버를 먼저 옮겨두기, 빌드 출력 디렉터리를 정확히 넣기, 도메인이 확정되면 절대 URL 설정 갱신하기. 실제로 시간을 잡아먹는 지점은 이 셋이 전부였습니다.

이 블로그가 왜 이런 구성으로 굴러가는지는 1인 개발자를 위한 최소 인프라에, 글을 쓰고 배포까지 자동으로 굴리는 방식은 하네스 엔지니어링에 적어 뒀습니다.