GitHub Pages에 개인 도메인을 연결하는 기본 흐름

GitHub Pages의 사용자 지정 도메인

GitHub Pages 저장소 설정에서 Custom domain에 대표 도메인을 입력하면 저장소에 CNAME 파일이 생기거나 유지됩니다. 이 파일은 GitHub Pages가 어떤 도메인으로 사이트를 제공할지 기억하는 역할을 합니다.

루트 도메인과 www 주소를 모두 사용할 경우 DNS 레코드도 함께 맞춰야 합니다. 루트 도메인은 GitHub가 안내하는 A 레코드, www는 보통 GitHub Pages 기본 도메인을 가리키는 CNAME을 사용합니다.

Cloudflare Pages를 사용할 경우 GitHub Pages용 CNAME 파일이나 GitHub Actions 배포 워크플로가 필요하지 않을 수 있습니다. GitHub는 코드 저장소 역할을 하고, Cloudflare가 빌드와 배포를 담당합니다.

이 사이트도 처음에는 GitHub Pages 기준으로 준비했지만, 최종 배포는 Cloudflare Pages로 정리했습니다. 그래서 CNAME 파일을 제거하고 Cloudflare Custom domains를 기준으로 도메인을 연결했습니다.

GitHub Pages에서는 사용자 지정 도메인을 연결한 뒤 HTTPS 인증서 발급까지 시간이 걸릴 수 있습니다. 설정 화면의 Enforce HTTPS 옵션이 활성화되는지 확인합니다.

Cloudflare Pages에서는 Cloudflare가 인증서를 발급하고 프록시/SSL 설정을 관리합니다. 어느 방식을 쓰든 최종 확인은 브라우저에서 실제 대표 도메인으로 접속해 자물쇠 표시와 리디렉션을 보는 것입니다.

간단한 문서 사이트이고 도메인 관리가 복잡하지 않다면 GitHub Pages만으로 충분합니다. 반면 도메인, DNS, 캐시, 보안 설정을 한 화면에서 다루고 싶다면 Cloudflare Pages가 더 편할 수 있습니다.

중요한 것은 심사 도메인과 실제 공개 도메인이 일치하는 것입니다. `emfls.github.io`가 아니라 `emfls.com`으로 심사받을 계획이라면 모든 SEO와 정책 링크도 `emfls.com` 기준이어야 합니다.

처음에는 GitHub Pages용 A 레코드와 CNAME 파일을 준비했지만, 최종 운영은 Cloudflare Pages로 정리했습니다. 이유는 도메인, DNS, HTTPS, 배포 상태를 Cloudflare에서 한 번에 관리하는 편이 초보자에게 더 명확했기 때문입니다.

이런 변경을 할 때는 예전 GitHub Pages용 설정을 계속 남겨두지 않는 것이 중요합니다. 배포 기준이 바뀌면 README, DNS, AdSense 등록 주소, sitemap 기준 URL도 함께 맞춰야 합니다.

스크린샷 추가 예정

GitHub Pages custom domain 화면과 Cloudflare Pages custom domain 화면을 비교하면 두 방식의 차이를 설명하기 좋습니다.

GitHub Pages와 Cloudflare Pages를 같이 써도 되나요?

코드 저장소는 GitHub, 배포는 Cloudflare Pages로 역할을 나누는 것은 좋습니다. 다만 두 서비스가 동시에 같은 도메인을 배포 대상으로 잡으면 혼란이 생깁니다.

CNAME 파일은 언제 필요한가요?

GitHub Pages에서 사용자 지정 도메인을 직접 쓸 때 필요합니다. Cloudflare Pages 배포만 쓴다면 필수는 아닙니다.

기존 emfls.github.io 주소는 어떻게 하나요?

심사 도메인을 `emfls.com`으로 정했다면 공개 링크와 SEO 설정은 `emfls.com` 기준으로 통일하는 것이 좋습니다.