4편까지 오면 서버는 준비가 끝났습니다. 문도 잠갔고요. 그런데 아직 주소창에 141.164.xxx.xxx를 쳐야 들어갑니다. 명함에 IP를 적을 순 없죠. 이번 편은 가비아에서 산 ddlabx.com을 이 서버로 연결하는 이야기입니다.
작업 자체는 5분입니다. 값 두 개만 넣으면 끝나요. 그런데 이 5분이 기다림 때문에 반나절로 늘어나기도 하고, “설정은 분명히 맞는데 안 들어가진다”로 사람을 미치게 만들기도 합니다. 왜 그런지까지 알고 가면 기다리는 동안 불안하지 않습니다.
DNS는 전화번호부다 — 그리고 사본이 전 세계에 있다
DNS는 이름 ↔ 주소 대응표입니다. 브라우저에 ddlabx.com을 치면 컴퓨터가 “이 이름의 IP가 뭐냐”고 물어보고, 141.164.xxx.xxx를 받아서 거기로 접속합니다. 그 대응표를 관리하는 게 네임서버이고, 저는 가비아 네임서버를 씁니다.
여기서 중요한 게 하나 있습니다. 이 전화번호부는 사본이 전 세계에 뿌려집니다. 매번 가비아에 물어보면 느리니까, 통신사 DNS 서버·공유기·내 PC·브라우저가 각자 답을 잠시 저장해 둡니다. 이 저장 기간이 TTL이고, 이게 뒤에서 나올 “전파” 문제의 정체입니다.
웹서버를 만들며 쓰게 되는 레코드는 몇 개 안 됩니다.
| 타입 | 하는 일 | 값의 형태 | 지금 필요한가 |
|---|---|---|---|
| A | 이름 → IPv4 주소 | 141.164.xxx.xxx | 필수 |
| AAAA | 이름 → IPv6 주소 | 2001:19f0:... | 선택 |
| CNAME | 이름 → 다른 이름 | ddlabx.com. | www에 쓸 수 있음 |
| MX | 메일 서버 지정 | 메일 호스트 | 메일 쓸 때만 |
| TXT | 임의 텍스트 (소유권 인증 등) | 문자열 | 서치콘솔·SPF 때 |
| NS | 이 도메인을 누가 관리하나 | 네임서버 주소 | 건드릴 일 거의 없음 |
참고 — 네임서버 변경과 DNS 레코드 설정은 다릅니다. 네임서버 변경은 “전화번호부를 누가 관리할지” 자체를 바꾸는 것(예: 가비아 → Cloudflare)이고, 레코드 설정은 “그 번호부 안의 한 줄”을 고치는 겁니다. 가비아에서 도메인을 샀고 그대로 쓸 거면 네임서버는 건드리지 말고 레코드만 넣으면 됩니다.
가비아에서 A 레코드 넣기
가비아 관리 화면은 메뉴가 깊습니다. 저는 처음에 DNS 설정 화면을 못 찾아서 한참 헤맸어요. 경로는 이렇습니다.
| 순서 | 클릭할 곳 |
|---|---|
| 1 | 가비아 로그인 → 우측 상단 My가비아 |
| 2 | 이용 중인 서비스 → 도메인 |
| 3 | 해당 도메인 우측 관리 |
| 4 | DNS 정보 → DNS 관리 |
| 5 | 도메인 옆 설정 |
| 6 | 레코드 수정 → 레코드 추가 |
이제 두 줄을 넣습니다.
| 타입 | 호스트 | 값/위치 | TTL | 무엇을 위한 것 |
|---|---|---|---|---|
| A | @ | 141.164.xxx.xxx | 300 | ddlabx.com |
| A | www | 141.164.xxx.xxx | 300 | www.ddlabx.com |
핵심 두 가지입니다.
@는 도메인 자기 자신을 뜻합니다. ddlabx.com이라고 타이핑하지 말고 @ 한 글자만 넣으세요. 가비아 공식 안내도 원도메인은 @, www 접속용은 www를 넣으라고 되어 있습니다.
www는 따로 넣어야 합니다. @만 넣으면 www.ddlabx.com은 안 됩니다. DNS는 자동으로 유추해 주지 않아요. 이 둘은 DNS 입장에서 완전히 남남입니다.
주의 — TTL을 처음엔 300(5분)으로 낮게 두세요. 값을 잘못 넣었을 때 TTL이 곧 후회의 길이가 됩니다. 86400(24시간)으로 해두고 IP에 오타를 내면, 고쳐도 하루 종일 캐시에 남은 틀린 답이 돌아다닙니다. 다 확인한 뒤에 3600으로 올리세요.
참고로 www는 A 대신 CNAME으로 ddlabx.com.을 가리키게 해도 됩니다. 차이는 이렇습니다.
| www를 A로 | www를 CNAME으로 | |
|---|---|---|
| 설정 | IP를 한 번 더 입력 | ddlabx.com.을 가리킴 (끝의 점 주의) |
| 서버 IP가 바뀌면 | 두 줄 다 고쳐야 함 | @ 한 줄만 고치면 됨 |
| 조회 | 한 번 | 두 번 (미세하게 느림) |
서버 한 대에 도메인 하나면 뭘 해도 상관없습니다. 저는 나중에 IP를 바꿀 가능성을 생각해서 www를 CNAME으로 두는 쪽을 선호하지만, A 두 줄이 더 직관적이면 그렇게 하셔도 됩니다.
기다리는 시간 — “전파”의 진실
설정을 저장하면 “최대 48시간이 걸릴 수 있습니다” 같은 안내가 뜹니다. 이 문장 때문에 다들 겁을 먹는데, 절반은 오해입니다.
새 도메인에 처음 A 레코드를 넣는 거라면 대개 몇 분이면 끝납니다. 캐시에 남아 있던 이전 값이 없으니까요. 48시간이 걸리는 건 기존에 다른 IP를 가리키고 있었고, 그 TTL이 길게 잡혀 있었을 때입니다. 즉 전파 시간은 마법이 아니라 TTL의 함수입니다.
| 상황 | 보통 걸리는 시간 | 왜 |
|---|---|---|
| 새 도메인 첫 설정 | 수 분 | 지울 캐시가 없음 |
| TTL 300인 상태에서 IP 변경 | 5분 내외 | 캐시가 5분마다 만료 |
| TTL 86400인 상태에서 IP 변경 | 최대 24시간 | 캐시가 하루 동안 유지 |
| 네임서버 자체를 변경 | 수 시간 ~ 48시간 | 상위 레지스트리 반영이 느림 |
그래서 이사 계획이 있다면 며칠 전에 TTL부터 낮춰두는 게 프로의 습관입니다. 낮춘 TTL이 퍼진 다음에 IP를 바꾸면 전환이 순식간입니다.
제대로 됐는지 확인하는 법
브라우저로 접속해 보는 건 가장 나쁜 확인 방법입니다. 브라우저 캐시, OS 캐시, 공유기 캐시가 전부 끼어들어서 뭐가 문제인지 알 수 없거든요. 도구로 확인합니다.
윈도우 PowerShell에서 — 구글 DNS에게 직접 물어봅니다. 내 PC 캐시를 건너뛰니 정확합니다.
nslookup ddlabx.com 8.8.8.8
nslookup www.ddlabx.com 8.8.8.8서버(Ubuntu)에서 — dig가 더 깔끔합니다.
sudo apt install dnsutils -y
dig ddlabx.com +short
dig www.ddlabx.com +short내 서버 IP가 딱 찍혀 나오면 DNS는 끝난 겁니다. TTL이 얼마나 남았는지까지 보려면:
dig ddlabx.comANSWER SECTION의 숫자가 남은 캐시 시간(초)입니다. 새로고침할 때마다 줄어드는 게 보입니다.
여러 나라에서 어떻게 보이는지 궁금하면 whatsmydns.net 같은 사이트에서 전 세계 DNS 서버의 응답을 한눈에 볼 수 있습니다. 전파 진행 상황을 지도로 보여줘서 기다릴 때 마음이 편합니다.
참고 — dig는 맞는 IP를 주는데 브라우저만 안 될 때가 있습니다. 내 PC 캐시입니다. 윈도우는 ipconfig /flushdns, 크롬은 주소창에 chrome://net-internals/#dns → Clear host cache. 그래도 안 되면 시크릿 창이나 휴대폰 LTE(와이파이 끄고)로 접속해 보세요. 휴대폰 LTE 테스트가 제일 빠르고 정직합니다. 집 공유기 캐시를 완전히 우회하니까요.
DNS는 됐는데 사이트가 안 뜬다면
dig는 정상인데 브라우저에서 이상하다면, 이제 문제는 DNS가 아니라 서버 쪽입니다. 여기서 3편의 습관이 나옵니다 — 추측하지 말고 확인.
| 증상 | 원인 | 확인·조치 |
|---|---|---|
| 도메인은 되는데 www가 404·연결 실패 | www A/CNAME 레코드 누락 | dig www.ddlabx.com +short |
| IP로는 되는데 도메인은 “Welcome to nginx” | 서버 블록 server_name 불일치 | 2편 설정의 server_name ddlabx.com www.ddlabx.com; |
| 워드프레스가 자꾸 IP로 되돌림 | WP 사이트 주소가 IP로 저장됨 | 설정 → 일반 → 두 주소를 도메인으로 |
| 접속 자체가 안 됨 | UFW 80 미개방 | sudo ufw status |
| 한참 뒤에 응답 없음 | Vultr 방화벽 그룹 | 대시보드의 Firewall 규칙 확인 |
| 레코드를 넣었는데 dig에 안 나옴 | 네임서버가 가비아가 아님 | dig ddlabx.com NS +short |
마지막 줄이 은근히 많습니다. 도메인은 가비아에서 샀는데 네임서버가 다른 곳으로 돼 있으면, 가비아 DNS 화면에서 아무리 레코드를 넣어도 그 번호부는 아무도 안 봅니다. dig ddlabx.com NS +short로 실제 관리 주체부터 확인하세요.
서버 블록도 다시 봅니다. 2편에서 이미 server_name에 도메인을 넣어뒀다면 손댈 게 없습니다.
sudo nginx -t
grep server_name /etc/nginx/sites-available/ddlabx자주 묻는 질문
Q. 워드프레스 주소를 도메인으로 바꾸면 로그인이 안 될까 봐 무섭습니다.
A. 순서만 지키면 안전합니다. 먼저 dig로 도메인이 서버를 가리키는 걸 확인하고, 그 다음에 워드프레스 설정 → 일반에서 워드프레스 주소와 사이트 주소를 도메인으로 바꾸세요. 순서를 뒤집으면 로그아웃된 뒤 도메인이 아직 안 붙어서 못 들어가는 상황이 생깁니다. 그때는 wp-config.php에 다음 두 줄을 임시로 넣어 강제할 수 있습니다. (3편에서 배운 대로 넣고 나서 php -l 잊지 마세요.)
define('WP_HOME','http://ddlabx.com');
define('WP_SITEURL','http://ddlabx.com');Q. Cloudflare를 쓰는 게 낫지 않나요?
A. 무료 CDN·DDoS 방어·DNS 속도 같은 장점이 분명 있습니다. 다만 이 시리즈 순서에서는 지금 붙이지 마세요. Cloudflare 프록시(주황 구름)를 켜면 방문자는 Cloudflare에 접속하게 되는데, 이 상태에서 다음 편의 Certbot 인증서 발급이 꼬입니다. 서버에서 직접 SSL을 붙여 정상 작동을 확인한 뒤에 얹는 게 순서입니다. 문제가 생겼을 때 원인을 하나씩 분리할 수 있어야 하니까요.
Q. www 있는 쪽과 없는 쪽 중 뭘 기본으로 하나요?
A. 취향입니다. 중요한 건 하나를 정하고 나머지는 리다이렉트하는 것입니다. 둘 다 동작하게 두면 검색엔진이 별개 사이트로 보고 평가가 갈립니다. 워드프레스 설정 → 일반에 적은 주소가 기준이 되고, 워드프레스가 알아서 정리해 줍니다. 저는 www 없는 쪽으로 통일했습니다.
Q. 지금 HTTP인데 그냥 HTTPS 주소로 적으면 안 되나요?
A. 안 됩니다. 인증서가 없는 상태에서 주소를 https://로 적으면 사이트에 아예 접속이 안 되고 관리자도 못 들어갑니다. 지금은 http://로 두세요. 다음 편에서 Certbot이 이 주소들을 알아서 https://로 바꿔줍니다.
Q. 도메인이 만료되면요?
A. 사이트가 통째로 사라집니다. 서버는 멀쩡한데 아무도 찾아올 수 없어요. 가비아에서 자동 갱신을 켜두고 결제 수단이 유효한지 확인하세요. 서버 요금과 도메인 요금은 별개입니다.
정리하면
- 필요한 건 A 레코드 두 줄입니다 — 호스트
@(원도메인)와www. @는 도메인 자기 자신.ddlabx.com이라고 타이핑하지 마세요.- TTL은 처음에 300으로. TTL이 곧 실수했을 때 후회하는 시간입니다. 확인 후에 3600으로 올리세요.
- “48시간 전파”는 대부분 과장입니다. 새 도메인 첫 설정은 보통 몇 분이고, 전파 시간은 이전 TTL이 결정합니다.
- 확인은 브라우저 말고
nslookup ddlabx.com 8.8.8.8또는dig ddlabx.com +short로. - 브라우저만 안 되면 캐시입니다.
ipconfig /flushdns또는 휴대폰 LTE로 테스트. - 레코드를 넣었는데 반영이 없으면
dig ddlabx.com NS +short로 네임서버가 가비아가 맞는지 확인하세요. - Cloudflare는 SSL을 붙이고 정상 작동을 확인한 다음에 얹으세요.
이제 http://ddlabx.com으로 사이트가 뜹니다. 그런데 주소창 옆에 “주의 요함”이 붙어 있죠. 다음 편에서 그걸 없앱니다. 2편에서 Nginx Full로 443을 미리 열어둔 게 드디어 값을 합니다.