클라우드 플레어 도메인 연결하는 방법과 장점 | 아이티이지 네임서버 변경·DNS·레코드 및 주의사항

아이티이지(ITEASY)에서 산 .co.kr 도메인을 Cloudflare에 붙이는 작업은 “도메인을 Cloudflare로 이전”이 아니다. 소유·갱신은 아이티이지에 남기고, DNS 권한만 Cloudflare 네임서버로 넘기는 구조다. 아래는 도메인 주소를 가린 실제 화면을 기준으로, 등록기관 → 네임서버 → DNS 레코드 → 원본 웹서버까지 연결되는 흐름과 장점·주의사항을 정리한 글이다.

공식 Full setup 절차는 Cloudflare 네임서버 변경 안내를 따른다.

1. 한눈에 보는 연결 구조

브라우저에 연결한 도메인 주소를 입력하면 대략 다음 순서로 주소가 풀린다.

1. 최상위·국가 도메인 체계가 “이 도메인의 네임서버는 어디인가”를 확인한다.
2. 아이티이지에 등록된 네임서버가 Cloudflare 쪽이면, 권한 DNS는 Cloudflare가 답한다.
3. Cloudflare DNS 레코드(A/AAAA/CNAME 등)로 목적지(또는 프록시)를 정한다.
4. 주황색 구름(Proxied)이면 방문자는 Cloudflare를 거쳐 원본 서버에 닿는다.

역할을 비유하면 이렇게 나뉜다.

네임서버만 Cloudflare로 바꿨다고 웹 파일이 Cloudflare에 올라가지는 않는다. DNS가 “어디로 갈지”를 Cloudflare가 알려 주고, 사이트 본체는 별도 호스팅에 있어야 한다.

작업 순서는 반드시 이렇다.

1. Cloudflare에 도메인(존)을 먼저 추가하고 DNS 레코드를 점검한다.
2. Cloudflare가 준 네임서버 2개를 확인한다.
3. 그다음에야 아이티이지에서 ns1.ksdom.kr / ns2.ksdom.kr을 Cloudflare 네임서버로 교체한다.
4. 전파 후 Cloudflare 상태가 Active가 되면 웹·SSL을 점검한다.

아이티이지 네임서버부터 먼저 바꾸면, Cloudflare DNS가 비어 있는 동안 사이트·메일이 끊길 수 있다.

2. 아이티이지에서 시작하는 화면

보유도메인 목록에는 파킹(P), 포워딩(F), 웹DNS(D), 웹메일, 도메인잠금 같은 부가 기능 아이콘이 보인다. 이 기능 상당수는 아이티이지 네임서버를 쓸 때 동작한다. Cloudflare로 네임서버를 넘기면 파킹·포워딩·웹메일·웹DNS가 해제되거나 제한될 수 있다는 안내가 네임서버 변경 화면에 반복해서 나온다. 고객센터는 1600-8324(내선 4번)다.

그림 1. 아이티이지 보유도메인 — 파킹·포워딩·웹DNS·웹메일 등 부가서비스 아이콘

도메인을 체크한 뒤 선택한 도메인 정보변경에서 네임서버변경을 누른다. 기간연장·관리자정보변경·호스트 관리·소유권 이전·인증코드 요청과 같은 버튼이 같은 구역에 있다.

그림 2. 도메인 선택 후 「네임서버변경」

변경 화면에는 부가서비스 해지 안내와 확인 체크박스가 있다. 변경 전 기본값은 보통 아래와 같다.

그림 3. 변경 전 아이티이지 네임서버 — ns1·ns2.ksdom.kr

이 화면은 나중에 Cloudflare 값을 넣을 자리이므로, 지금은 Cloudflare 온보딩을 먼저 마친다.

3. Cloudflare에 도메인 추가와 DNS 점검

아이티이지처럼 Cloudflare 밖에서 산 도메인은 Cloudflare Registrar의 구매·이전이 아니라, 계정에 기존 도메인을 추가(온보딩) 하는 경로를 탄다.

좌측 메뉴에서 Domains를 연다. 하위에는 Overview, Registrations, Transfers가 있다. 외부 구매 도메인을 DNS·프록시에 붙일 때는 보통 Overview로 들어간다. Registrations는 Cloudflare에서 새로 도메인을 살 때, Transfers는 등록기관 자체를 Cloudflare로 옮길 때 쓰는 메뉴다.

그림 4. Cloudflare 좌측 Domains — Overview·Registrations·Transfers

Overview 화면 상단(또는 도메인 목록 근처)에서 Buy domain과 Add domain이 보인다. 외부에서 이미 산 도메인은 파란 Add domain을 누른다. Buy domain은 Cloudflare에서 새 도메인을 구매하는 버튼이다.

그림 5. Buy domain과 구분되는 Add domain(외부 구매 도메인 추가)

Add domain 이후 흐름은 아래에서 이어진다. 도메인 입력 → Free 등 요금제 선택 → DNS 레코드 점검 → 발급된 네임서버를 아이티이지에 반영.

Cloudflare 대시보드에서 도메인을 추가한다(Add a domain / Onboard a domain). Free 요금제로도 Full DNS·CDN·Universal SSL·기본 DDoS 방어를 쓸 수 있다. 한 도메인 설정 묶음을 Cloudflare는 Zone(존)이라 부른다.

자동 스캔 결과는 항상 완전하지 않다. 이 사례에서는 Records we found: 0이 나왔다. “도메인이 없다”는 뜻이 아니라, 기존 ksdom.kr 쪽에서 복사할 레코드를 Cloudflare가 못 찾았다는 뜻이다. DNS 퀵 스캔 안내에서도 누락 레코드를 직접 비교하라고 한다.

특히 확인할 항목:

• @(루트) A / AAAA / CNAME
• www
• 사용 중인 서브도메인
• MX, SPF, DKIM, DMARC 등 메일 관련 TXT

그림 6. Review your DNS records — Records we found: 0

레코드가 비어 있는 채로 다음으로 가면 Add records later 모달이 뜬다. “DNS가 없으면 사이트를 활성화할 수 없다. 지금 넣는 편이 낫다”는 경고다. Confirm으로 진행은 가능하지만, 네임서버만 바꾸고 레코드를 안 넣으면 루트·www·메일이 모두 끊긴다.

그림 7. DNS 없이 진행할 때 나오는 Cloudflare 경고

Proxied(주황 구름)와 DNS only(회색 구름) 차이도 이 단계에서 익혀 둔다. 웹용 A/CNAME은 보통 Proxied, 메일·SSH성 호스트는 DNS only가 일반적이다. 자세한 동작은 프록시 DNS 레코드를 보면 된다.

4. Cloudflare가 발급한 네임서버

온보딩 마지막에 계정·존마다 다른 네임서버 2개가 나온다. 이 글의 예시는 다음과 같다.

네임서버는 “이 도메인의 DNS는 누구에게 물어보라”는 안내판이다. 여기가 Cloudflare로 바뀌면 이후 A/MX/TXT는 아이티이지가 아니라 Cloudflare DNS에서 관리한다. Overview에서도 같은 주소를 다시 확인할 수 있다.

그림 8. Update your nameservers — melissa·sid 추가, ksdom 삭제

DNSSEC가 등록기관에 켜져 있으면 네임서버 교체 전에 끄는 것이 안전하다. DS가 옛 DNS를 가리킨 채로 권한 서버만 바뀌면 검증 실패로 접속이 막힐 수 있다. Active 이후 Cloudflare에서 DNSSEC를 다시 켜고, .co.kr 등록기관(아이티이지)의 DS 등록 지원 여부를 확인한다.

5. 아이티이지에 Cloudflare 네임서버 입력

다시 아이티이지 네임서버변경으로 돌아와 입력한다.

Cloudflare 네임서버는 이미 인터넷에 등록된 외부 호스트라 HOST만 넣으면 된다. 자기 도메인 아래에 만든 네임서버 호스트를 등록하는 글루 레코드용 IP 칸과는 용도가 다르다. Cloudflare NS의 IP를 검색해 넣는 것도 피한다. IP는 여러 개일 수 있고 바뀔 수 있다.

부가서비스 해지 확인에 체크한 뒤 인증코드발송을 누른다. 등록 이메일로 6자리 코드가 온다. Gmail이면 스팸함도 본다. 인증코드는 일회용·단시간 유효이지만, 스크린샷에 코드가 보이면 제3자에게 공유하지 않는 편이 안전하다(본문 삽입 이미지는 코드를 가렸다).

코드를 입력란에 넣고 Cloudflare HOST를 채운 뒤 변경하기를 누른다.

그림 11. 아이티이지 — melissa·sid 입력과 인증코드 입력란

제출 직전 아이티이지는 24~48시간 전파·접속 불안정 가능성을 알리고 계속 진행할지 묻는다. Cloudflare 쪽 안내는 보통 수분~수 시간, 최대 약 24시간이다. 캐시·ISP에 따라 체감이 달라진다.

그림 12. 네임서버 변경 계속 진행 확인(24~48시간 안내)

처리가 끝나면 체크 아이콘과 함께 변경완료가 표시된다. 네임서버 1·2에 Cloudflare HOST가 들어가 있고, Whois 조회·호스트 등록 안내가 이어진다.

그림 13. 아이티이지 「네임서버 정보변경이 처리되었습니다」

같은 계정에서 관리하는 다른 도메인도 동일한 melissa·sid 쌍을 쓸 수 있다(계정에 할당된 NS가 같다면).

그림 14. 다른 도메인의 네임서버 변경완료 화면

「변경완료」는 아이티이지 내부 접수·등록이 끝났다는 뜻이지, 전 세계 DNS 캐시가 즉시 바뀌었다는 뜻은 아니다.

6. Cloudflare에서 전파 확인

등록기관에서 바꾼 뒤 Cloudflare의 I updated my nameservers는 네임서버를 대신 바꿔 주는 버튼이 아니다. “등록기관에서 바꿨으니 다시 조회해 달라”는 재확인 요청이다.

그림 15. Cloudflare 「I updated my nameservers」

전파 중 Overview에는 Waiting for your registrar to propagate your new nameservers 문구와 Check nameservers now가 보인다. Free plan, DNS Setup: Full, Under Attack Mode Off 같은 옆쪽 정보도 함께 뜬다.

그림 16. 네임서버 전파 대기 중인 Overview

목록에 잠깐 Invalid nameservers가 뜨기도 한다. 흔한 원인은 전파 지연, 캐시, 재확인 전, 철자 오류, 옛 NS가 남아 있음, DNSSEC DS 잔존이다. 이후 Active로 바뀌면 일시적 전파 과정인 경우가 많다.

완료 시 Overview에 Your domain is now protected by Cloudflare가 뜬다. DNS 레코드·프록시 점검, SSL/TLS(Universal SSL), Free plan의 CDN·DDoS·WAF 기본값 안내가 이어진다. .co.kr는 WHOIS 구조 차이로 Registrar: Unknown이 나올 수 있다. 오류라기보다 식별 한계인 경우가 많고, 아이티이지에서 갱신·관리가 되고 NS가 Cloudflare면 연결 자체는 정상이다.

그림 19. Cloudflare 보호 완료 — Your domain is now protected by Cloudflare

외부 NS 조회 예(작업 후): melissa.ns.cloudflare.com, sid.ns.cloudflare.com. 루트 A가 104.21.x.x / 172.67.x.x처럼 보이면 대개 원본 IP가 아니라 Cloudflare 프록시 IP다. 이 값을 다시 DNS Content에 넣으면 안 된다. Content에는 호스팅이 준 원본 IP나 CNAME 대상을 넣는다.

7. DNS 레코드 종류와 의미

Cloudflare → 해당 존 → DNS → Records에서 관리한다.

주황 구름(Proxied): 방문자 → Cloudflare → 원본. CDN·WAF·SSL·원본 IP 은닉이 적용된다. 회색 구름(DNS only): Cloudflare는 주소만 알려 주고 트래픽은 원본으로 직행한다.

8. SSL/TLS와 www·루트 통일

SSL/TLS → Overview에서 암호화 모드를 본다.

자세한 설명은 SSL/TLS 암호화 모드에 있다. Always Use HTTPS와 Universal SSL도 함께 확인한다.

루트와 www가 둘 다 열리면 SEO·북마크 일관성을 위해 하나를 대표로 정하고 Redirect Rules로 301 통일하는 편이 낫다.

9. Cloudflare 연결의 장점

네임서버만 옮긴 것이 아니라, Proxied면 방문 요청이 Cloudflare 네트워크를 통과한다. Free 플랜에서도 개인·소규모 사이트에 쓸 만한 기본기가 들어 있다.

9.1. CDN과 캐시

Cloudflare를 안 쓰면 모든 방문자가 원본 서버까지 간다. Proxied면 이미지·CSS·JS·폰트 같은 정적은 가까운 엣지에서 응답할 수 있다. 첫 요청은 원본을 거쳐 캐시되고, 이후 동일 URL은 엣지에서 끝날 수 있다. 원본 전송량·CPU 부담이 줄어든다.

기본 동작에서 HTML·JSON은 보통 캐시하지 않는다. “연결만 하면 모든 페이지가 CDN 캐시된다”는 오해다. HTML까지 캐시하려면 Cache Rules가 필요하고, 로그인·장바구니·관리자·실시간 API에는 걸면 안 된다. 기본 캐시 동작을 기준으로 본다.

권장 감각은 대략 이렇다. /images/·해시 붙은 JS/CSS는 길게, /api/·관리자는 제외 또는 짧게. 파일명에 해시(app.a1b2c3.js)를 쓰면 TTL을 길게 잡아도 배포 충돌이 적다.

9.2. DDoS·WAF·봇

대량 요청이 원본에 직격하기 전에 Cloudflare가 완화하는 구조다. Free에도 기본 DDoS 보호와 Free Managed Ruleset이 있다. WAF는 URL·헤더·파라미터 패턴을 보고 SQL 인젝션·XSS·알려진 취약점 공격을 거른다. 기업용 전 규칙 세트는 아니므로, 필요하면 Pro 이상이나 커스텀 규칙을 검토한다.

Bot Fight Mode(Security → Bots)는 알려진 봇 패턴에 대응한다. API 웹훅·모니터링·SNS 미리보기 봇이 있으면 켠 뒤 반드시 테스트한다. Overview의 Block AI training bots는 학습용 수집을 줄이려는 옵션이지, 모든 봇을 완벽히 막는 스위치는 아니다.

공격이 급증하면 Under Attack Mode를 임시로 켠다. 방문자에게 추가 검증이 뜰 수 있어 상시 ON은 비권장이다.

9.3. 원본 IP 은닉과 Tunnel

Proxied면 공개 DNS에 Cloudflare IP가 나온다. 공격자가 원본에 바로 치기 어려워진다. 다만 과거 DNS 기록, DNS only 서브도메인, 메일 서버와 웹이 같은 IP, 인증서·검색 기록으로 원본이 새어 나갈 수 있다. 효과를 높이려면 원본 방화벽에서 Cloudflare IP 대역만 HTTP/HTTPS를 받거나, Cloudflare Tunnel로 인바운드 포트를 줄인다.

9.4. HTTPS·HTTP/3·압축

Universal SSL로 방문자↔Cloudflare HTTPS가 붙는다. Cloudflare↔원본은 Full / Full (strict)로 맞춰야 구간이 완성된다. HTTP/2·HTTP/3, 텍스트 압축(HTML/CSS/JS/JSON 등)도 방문자 구간에서 도움을 준다. 이미 압축된 JPEG·MP4는 추가 압축 여지가 적다.

9.5. DNS·리다이렉트·분석·장애 완충

권한 DNS가 Cloudflare면 전역 Anycast DNS 응답을 쓴다. Redirect Rules로 HTTP→HTTPS, www↔루트 통일을 엣지에서 처리할 수 있다. Analytics로 국가·상태코드·캐시 적중·차단 이벤트를 본다. Always Online은 원본 장애 시 보관본을 줄 수 있지만 Free는 갱신 주기가 길고 동적 기능을 대체하지 못한다.

9.6. Free에서 바로 얻는 것 / 유료에서 커지는 것

Free: 권한 DNS, CDN, Universal SSL, 기본 DDoS·WAF, Bot Fight Mode, HTTP/3, Redirect, 기본 분석, Workers 무료 한도, Turnstile 등.

유료 쪽에서 주로 늘어나는 것: 관리형 WAF 범위, 봇 세밀 제어, Cache Rules·이미지 최적화, Argo, 로그·분석 깊이, 규칙 한도, 지원·SLA.

연결만으로 무조건 빨라지지는 않는다. 정적 비율·해외 방문·Cache-Control이 맞을 때 효과가 크고, 동적 API만 많거나 캐시 설정이 잘못되면 체감이 작거나 부작용이 난다.

9.7. 단점과 운영 함정

• Cloudflare 설정 오류 시 원본이 멀쩡해도 접속이 막힌다.
• 캐시 때문에 CSS·이미지 배포가 늦게 보인다 → 특정 URL Purge 또는 Development Mode.
• WAF 오탐으로 정상 API·검색이 막힐 수 있다.
• 서버 로그에 CF IP만 남으면 CF-Connecting-IP로 복원해야 한다.
• 메일·SSH·비표준 포트·게임 서버는 일반 주황 프록시와 맞지 않을 수 있다(프록시 제한).
• Free 플랜 직접 지원 범위는 문서·커뮤니티 중심인 경우가 많다.

10. 아이티이지 부가서비스·메일·보안 주의

• 파킹·포워딩·웹메일·웹DNS는 아이티이지 NS 의존 → Cloudflare NS로 바꾸면 해제·제한 가능. 포워딩은 Redirect Rules나 원본 서버에서 대체.
• 도메인 메일을 쓰면 MX·SPF·DKIM·DMARC를 Cloudflare로 미리 옮긴다. 등록용 Gmail(…@gmail.com)과 …@도메인 메일은 별개다.
• DNSSEC는 이전 전 해제 → Active 후 Cloudflare에서 재설정 → 등록기관 DS 확인.
• 도메인 소유권은 여전히 아이티이지. 만료·자동갱신·잠금·2FA는 아이티이지 계정에서 관리한다.
• Zone ID·API 토큰·인증코드는 외부에 올리지 않는다.

11. 연결 후 점검 체크리스트

DNS: @·www 존재, Content가 원본을 가리키는지, 웹 레코드 Proxied, 잘못된 AAAA 없음, 서브도메인 누락 없음.

SSL: Full (strict) 목표, Always Use HTTPS, 무한 리다이렉트 없는지.

URL: 루트/www 중 대표 하나 + 301 + canonical·사이트맵 통일.

메일: 미사용이면 MX 없음도 정상. 사용 시 MX·TXT + 메일 호스트 DNS only.

계정: 아이티이지·Cloudflare 2FA, 도메인 잠금, 갱신일.

12. 핵심 용어

13. 상황별 선택

14. 마무리

앞에서 다룬 Cloudflare·아이티이지 도메인 연결의 핵심만 짧게 정리한다.

• 소유·갱신은 아이티이지, DNS·프록시는 Cloudflare — 도메인 “이전”과 혼동하지 않는다.
• 순서는 Cloudflare 존·DNS 먼저 → 발급 NS 확인 → 아이티이지에서 ksdom 제거·CF HOST만 입력(IP 비움).
• Records 0·Add records later는 경고일 뿐, 레코드 없이 Active만 기대해서는 사이트·메일이 끊긴다.
• 아이티이지 「변경완료」와 전역 전파·Cloudflare Active는 시점이다르다. Invalid nameservers는 전파 중 흔하다.
• 웹 이점(CDN·SSL·DDoS·WAF)은 주황 구름(Proxied)일 때 본격 적용된다.
• 파킹·포워딩·웹메일·DNSSEC·원본 IP를 Content에 잘못 넣는 실수를 피한다. UI·요금제 문구는 시점마다 달라질 수 있어 공식 문서와 대시보드를 기준으로 확인한다.

「아이티이지에선 네임서버만 바꾸고, Cloudflare에선 DNS와 프록시를 완성한 뒤에야 사이트가 연결된다」 — Active 확인 후 SSL·캐시·리다이렉트만 손보면 일상 운영으로 넘어가면 된다.

자주 묻는 질문

• Cloudflare에 도메인을 추가하면 소유권이 Cloudflare로 넘어가나?

  아니다. Full setup은 등록기관에 소유·갱신을 남기고 권한 네임서버만 Cloudflare로 바꾸는 방식이다. 아이티이지에서 산 .co.kr는 만료·연장·잠금도 계속 아이티이지에서 관리한다. Cloudflare Registrar로 이전하는 것은 별도 절차다.

• 아이티이지 네임서버 IP 칸에 Cloudflare IP를 넣어야 하나?

  넣지 않는 것이 맞다. melissa.ns.cloudflare.com 같은 HOST만 1·2차에 넣고 IP는 비운다. IP 칸은 자기 도메인 아래 자체 네임서버용 글루 레코드에 가깝고, Cloudflare 공개 NS에는 해당하지 않는다.

• Records we found: 0이면 어떻게 하나?

  자동 스캔이 기존 DNS를 못 찾은 상태다. 도메인 자체가 없다는 뜻이 아니다. 아이티이지나 기존 호스팅의 A·www·MX·TXT를 Cloudflare DNS에 직접 넣은 뒤 네임서버를 바꾼다. 레코드 없이 NS만 바꾸면 사이트와 메일이 끊길 수 있다.

• Invalid nameservers가 뜨면 설정이 틀린 건가?

  항상 그렇지는 않다. 아이티이지 변경 직후 전파·캐시·재확인 전에 잠깐 뜨는 경우가 많다. HOST 철자, 옛 ksdom 잔존, DNSSEC DS 잔존도 원인이다. Whois·외부 NS 조회로 melissa·sid가 보이면 Cloudflare에서 재확인하면 Active로 바뀌는 경우가 흔하다.

• 아이티이지 포워딩·웹메일은 Cloudflare 연결 후에도 쓰나?

  대개 못 쓴다. 파킹·포워딩·웹메일·웹DNS는 아이티이지 네임서버에 묶인 부가서비스라 NS를 바꾸면 해제·제한될 수 있다. 포워딩은 Redirect Rules나 원본 서버로, 메일은 MX·SPF·DKIM·DMARC를 Cloudflare에 옮긴 뒤 외부 메일 서비스를 쓴다.

• 주황색 구름과 회색 구름 차이는?

  주황(Proxied)은 방문자가 Cloudflare를 거쳐 원본에 닿아 CDN·WAF·Universal SSL·원본 IP 은닉이 적용된다. 회색(DNS only)은 주소만 알려 주고 트래픽은 원본으로 직행한다. 웹 A/CNAME은 보통 주황, 메일·비 HTTP 호스트는 회색이 일반적이다.

• 조회되는 104.21·172.67 IP를 DNS Content에 넣어도 되나?

  안 된다. 그 주소는 Cloudflare 프록시 Anycast IP다. DNS Content에는 호스팅·플랫폼이 준 원본 IPv4/IPv6 또는 CNAME 대상을 넣어야 한다. 프록시 IP를 다시 넣으면 순환·오설정이 난다.

• SSL은 어떤 모드가 좋은가?

  가능하면 Full (strict)다. 방문자와 Cloudflare, Cloudflare와 원본 모두 유효한 HTTPS를 쓴다. Flexible는 원본이 HTTP라 장기 사용을 권하지 않고, HTTPS 강제와 맞물리면 무한 리다이렉트가 날 수 있다. 원본에는 Let’s Encrypt·상용·Origin CA 등 유효 인증서가 필요하다.

• DNSSEC는 언제 켜나?

  네임서버를 바꾸기 전에 등록기관 DNSSEC·DS를 끄는 편이 안전하다. Cloudflare가 Active가 된 뒤 Cloudflare DNSSEC를 켜고, .co.kr라면 아이티이지가 DS 등록을 지원하는지 확인한 다음 진행한다. 잘못된 DS는 도메인 전체가 풀리지 않을 수 있다.

• I updated my nameservers 버튼은 무엇을 하나?

  등록기관 설정을 대신 바꾸지 않는다. 아이티이지에서 NS를 바꾼 뒤 Cloudflare에 재조회를 요청하는 버튼이다. 실제 변경은 아이티이지에서, 확인은 Cloudflare에서 이뤄진다.

• Cloudflare 밖에서 산 도메인은 어디서 추가하나?

  좌측 Domains → Overview로 들어간 뒤 파란 Add domain을 누른다. Buy domain은 Cloudflare에서 새 도메인을 구매할 때이고, Transfers는 등록기관 자체를 Cloudflare로 옮길 때다. 아이티이지처럼 외부에서 산 도메인을 DNS만 Cloudflare에 붙이려면 Add domain이 맞다.