blog.jinosoft.com을 GitHub Pages에서 Cloudflare Pages로 이전할 때는 카페24 DNS의 CNAME 대상만 변경했다. 홈페이지인 jinosoft.com도 같은 방식으로 옮기려다가 연결 조건이 다르다는 것을 확인했다.
Cloudflare Pages의 공식 연결 방식에서는 루트 도메인에 Cloudflare 네임서버가 필요하다. 반면 www·blog 같은 하위 도메인은 기존 네임서버를 유지할 수 있다. 이 차이 때문에 홈페이지는 GitHub Pages에 두고 블로그만 Cloudflare Pages로 운영하기로 했다.
아래는 2026년 10월 21일 공식 문서 확인 기준이다. 일반적인 Pages 커스텀 도메인 연결을 다루며, 별도 프록시 서버나 다른 Cloudflare 제품을 조합한 구성은 포함하지 않는다.
1. example.com과 www.example.com의 차이#
이 글에서 example.com은 루트 도메인(apex domain)을 뜻한다. www.example.com과 blog.example.com은 그 아래에 있는 하위 도메인이다. www가 붙은 주소도 DNS에서는 하위 도메인으로 취급한다.
| 사용할 주소 | 구분 | 기존 네임서버 유지 | Pages 공식 연결 방식 |
|---|---|---|---|
example.com | 루트 도메인 | 불가 | Cloudflare DNS에 영역 등록·네임서버 변경 |
www.example.com | 하위 도메인 | 가능 | 기존 DNS에서 CNAME 등록 |
blog.example.com | 하위 도메인 | 가능 | 기존 DNS에서 CNAME 등록 |
Cloudflare는 루트 도메인을 Pages 프로젝트와 **같은 계정의 Cloudflare DNS 영역(zone)**으로 등록하고, 네임서버를 Cloudflare로 설정하도록 안내한다. 하위 도메인은 외부 DNS에서 <project>.pages.dev로 CNAME을 연결하는 방식을 지원한다. Cloudflare Pages 커스텀 도메인 공식 문서
따라서 “Custom domains에서 주소를 등록하고 기존 DNS에 CNAME을 넣으면 된다”는 설명은 루트 주소인지 하위 주소인지 확인한 뒤 적용해야 한다.
2. GitHub Pages는 A 레코드로 되는데 왜 다를까?#
GitHub Pages는 루트 도메인 연결에 사용할 공식 IPv4 주소를 제공한다.
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153기존 DNS 제공자에서 루트 도메인의 A 레코드를 이 주소들로 설정할 수 있다. GitHub의 Custom domain 설정도 필요하지만, DNS 운영 업체를 GitHub나 다른 곳으로 바꿀 필요는 없다. GitHub Pages 루트 도메인 설정
Cloudflare Pages는 이와 같은 외부 DNS용 공식 고정 IP 연결 절차를 제공하지 않고, 루트 도메인에 Cloudflare DNS를 요구한다. pages.dev를 조회해서 나온 IP를 A 레코드에 복사하는 방식은 공식 설정을 대신하지 않는다. DNS가 IP를 반환하는 것과 Pages가 해당 호스트의 연결·HTTPS를 처리하는 것은 별개다.
CNAME flattening: 별칭 대상의 IP를 대신 조회해 응답#
CNAME flattening은 DNS 서버가 별칭 대상의 IP 주소까지 조회한 뒤, 별칭 대신 IP를 응답하는 기능이다. 통일된 한국어 명칭보다는 영문 용어를 사용하고 동작을 풀어 설명하는 편이 명확하다.
일반 CNAME은 별칭 대상 이름을 응답하므로 DNS 리졸버가 대상의 IP를 이어서 확인한다. Flattening은 DNS 서버가 대상의 IP까지 확인해 응답한다. 다음은 동작을 단순화한 예시다.
일반 CNAME
www.example.com 조회 → example.pages.dev라는 별칭 응답
리졸버가 example.pages.dev의 IP를 추가 확인
CNAME flattening
example.com 조회 → DNS 서버가 example.pages.dev의 IP를 확인
조회한 쪽에는 최종 IP 주소를 응답루트 도메인에는 SOA·NS 레코드가 존재하므로 다른 일반 레코드와 공존할 수 없는 표준 CNAME을 그대로 둘 수 없다. Cloudflare DNS는 flattening으로 루트의 별칭 연결을 처리한다. 이는 HTTP 리다이렉트가 아니므로 브라우저의 주소도 바뀌지 않는다. Cloudflare CNAME flattening 설명
다른 DNS 제공자의 ALIAS·ANAME도 루트 도메인을 다른 호스트 이름에 연결하려는 비슷한 목적의 기능이지만, 구현과 세부 동작이 모두 같지는 않다. 외부 DNS의 별칭 처리 기능과 Pages의 루트 도메인 지원 조건도 별개다. DNS 입력란에서 @에 별칭을 등록할 수 있다는 사실만으로 Pages의 공식 요구사항이 충족되지는 않는다.
3. 기존 네임서버를 유지하려면 www를 쓰면 될까?#
가능하다. Pages에 www.example.com을 등록하고, 기존 DNS에서 다음 CNAME을 설정하는 방식이다.
레코드 유형: CNAME
호스트: www
대상: <project>.pages.dev먼저 Pages 프로젝트 → Custom domains에서 주소를 연결하고 DNS 설정을 진행한다. CNAME만 추가하고 Pages에 도메인을 등록하지 않으면 정상 서비스되지 않을 수 있다. 실제 CNAME 값은 프로젝트 화면의 안내를 따른다. 하위 도메인 연결 절차
example.com 접속도 자동으로 이동하는 것은 아니다#
www.example.com을 연결해도 example.com에 대한 요청은 기존 DNS와 호스팅 설정을 따른다. 기존 루트 주소를 계속 사용하는 방문자가 있다면 루트 주소의 HTTPS 요청을 받아 www로 301 리다이렉트하는 서비스를 별도로 마련해야 한다.
예를 들어 다음과 같이 경로와 필요한 쿼리 문자열도 유지하도록 구성한다.
https://example.com/apps/product/?lang=ko
→ 301
https://www.example.com/apps/product/?lang=koDNS 레코드 자체는 HTTP 리다이렉트를 실행하지 않는다. 등록기관의 URL 포워딩을 검토한다면 HTTPS 지원, 301 상태 코드, 경로·쿼리 보존 여부를 확인해야 한다. HTML의 자동 이동만으로 HTTP 301을 대체했다고 판단하지 않는다.
대표 주소도 www로 바꾼다면 canonical·사이트맵·내부 링크를 함께 맞춰야 한다. 네임서버 변경을 피하려고 www를 선택하더라도, 기존 루트 주소의 처리는 별도 작업으로 남는다.
4. 루트 주소를 유지하며 Pages로 옮기려면#
example.com을 그대로 Pages에 연결하려면 DNS를 Cloudflare로 이전하는 공식 절차를 사용한다. 도메인의 구매·갱신을 담당하는 등록기관은 그대로 유지할 수 있다. 바뀌는 것은 권한 DNS 서버와 DNS 레코드 관리 위치다.
이 경우 확인할 순서는 다음과 같다.
- 새 Pages 프로젝트를 배포하고
pages.dev에서 확인한다. - 기존 DNS의 전체 레코드를 기록하고 Cloudflare DNS에 등록·대조한다.
- **DNSSEC(DNS 응답의 전자서명을 검증하는 보안 기능)**을 사용 중이라면, 네임서버 변경 전에 기존 **DS 레코드(상위 DNS에 등록된 서명 검증 정보)**와 이전 절차를 확인한다.
- 네임서버를 Cloudflare로 변경하고 루트 도메인을 Pages에 연결한다.
- 홈페이지·블로그·메일·인증용 DNS와 HTTPS를 확인한다. DNS 캐시 전환과 새 호스팅의 정상 응답을 확인할 때까지 기존 호스팅을 유지한다.
네임서버 변경은 루트 홈페이지 한 개의 레코드만 바꾸는 작업이 아니다. 블로그의 CNAME, 메일의 MX, SPF·DKIM 등 TXT 레코드도 새 DNS에서 제공되어야 한다. Cloudflare의 자동 레코드 검색 결과만 믿지 말고 기존 목록과 비교해야 한다.
DNSSEC은 DNS 조회 내용을 암호화하는 기능이 아니라, 응답이 위조·변조되지 않았는지 전자서명으로 검증하는 기술이다. DS는 Delegation Signer의 약자로, 하위 도메인의 DNSSEC 공개키를 검증하는 데 사용하는 정보를 담는다. 예를 들어 example.com의 DS 레코드는 상위인 .com DNS 영역에 등록된다.
네임서버를 옮긴 뒤에도 이전 공개키에 대한 DS 레코드가 남아 새 DNS의 공개키와 맞지 않으면, DNSSEC을 검증하는 DNS 리졸버가 조회를 실패 처리할 수 있다. 이 경우 웹 서버가 정상이어도 방문자가 사이트에 접속하지 못할 수 있으므로, 네임서버 변경 전에 기존 DS 레코드의 변경·제거 절차를 확인한다.
이 글에서는 실제 네임서버 이전은 진행하지 않았다. 현재 운영 목적에는 다음의 혼합 구성이 적합하다고 판단했다.
5. 지노소프트는 홈페이지와 블로그를 나눠 운영#
| 주소 | 호스팅 | 저장소 | DNS 관리 |
|---|---|---|---|
jinosoft.com | GitHub Pages | Public | 카페24 |
blog.jinosoft.com | Cloudflare Pages | Private | 카페24 |
홈페이지는 이미 GitHub Pages에서 정상 제공되고 있고, 소규모 공개용 정적 파일로 구성되어 있다. 기존 루트 주소와 DNS를 유지하는 편이 관리할 변경 사항이 적었다.
블로그는 Markdown 원문·캡처·변경 이력을 비공개로 관리하려는 목적이 있었다. GitHub Free에서 Private 저장소를 연결할 수 있는 Cloudflare Pages를 사용하고, 카페24에는 blog의 CNAME만 변경했다. 실제 작업은 GitHub Pages에서 Cloudflare Pages로 이전하기에 정리했다.
기존 네임서버와 루트 주소를 모두 유지해야 한다면 GitHub Pages 같은 외부 DNS 연결 지원 서비스를 선택하고, DNS까지 통합할 계획이라면 Cloudflare Pages의 루트 도메인 연결을 검토하면 된다. 서비스별 요금과 배포 방식은 GitHub Pages vs Cloudflare Pages 비교에서 확인할 수 있다.