예약 엔진에 자체 도메인을 연결하는 방법

사이트는 완성됐습니다. 로고도 맞고, 마크업도 설정했고, 플랫폼 서브도메인에서 테스트 예약도 성공했고, 사무실 누군가는 벌써 고객 세 명에게 링크를 보냈습니다. 그다음에 당연한 질문이 나옵니다. 왜 주소에는 아직 남의 이름이 붙어 있을까? 이 가이드는 누구를 고용하지 않고 예약 엔진에 자체 도메인을 연결하는 방법을 다룹니다. 실제로 무엇을 바꾸는지, 관련된 레코드 두세 개가 무엇인지, 브라우저의 자물쇠가 왜 예상보다 늦게 나타나는지, 그리고 건드리는 순간 회사 이메일을 조용히 망가뜨리는 설정 하나까지요.
DNS를 깊이 알 필요는 없습니다. 한 가지 그림만 있으면 됩니다. 도메인 이름은 표지판이고, 여러분은 그 표지판을 새 건물 쪽으로 돌리는 중입니다. 아래 내용은 모두 이 그림의 세부 사항입니다.
도메인은 실제로 어디에 있는가
최대 세 회사가 관련될 수 있는데, 대부분의 대표는 그중 하나만 압니다. 등록 기관(registrar)은 도메인을 구입하고 매년 갱신 비용을 내는 곳입니다. DNS 호스트는 그 도메인의 레코드를 편집하는 곳으로, 보통 등록 기관과 같은 회사지만 아닐 때도 있습니다. 특히 몇 년 전 웹 디자이너가 도메인을 별도 DNS 서비스로 옮겨 둔 경우가 그렇습니다. 웹 호스트는 현재 사이트가 돌아가는 곳입니다.
이제 추가할 레코드는 DNS 호스트에 들어갑니다. 그러니 무엇보다 먼저 DNS 호스트가 어디인지 확인하세요. 등록 기관에 로그인해 도메인에 설정된 네임서버를 봅니다. 네임서버가 등록 기관 것이면 거기서 레코드를 편집합니다. 다른 곳을 가리키면 그곳에서 작업합니다. 이 확인에 몇 분만 쓰면, 아무도 읽지 않는 관리 화면에서 레코드를 고치느라 오후를 날리는 일을 막을 수 있습니다.
루트 도메인이냐 서브도메인이냐: 손대기 전에 정하세요
루트 도메인(apex, 네이키드 도메인이라고도 함)은 앞에 아무것도 없는 yourbrand.co.kr입니다. 서브도메인은 앞에 라벨이 붙은 모든 주소입니다. www.yourbrand.co.kr, booking.yourbrand.co.kr, travel.yourbrand.co.kr 같은 식이죠. 플랫폼은 둘 다 받으며, 어느 쪽을 고르느냐에 따라 추가할 레코드가 달라집니다.
이유는 오래된 규칙이라 협상할 여지가 없습니다. 루트 도메인에는 이미 도메인 자체를 정의하는 레코드가 있고, DNS는 CNAME이 다른 레코드와 이름을 공유하는 것을 허용하지 않습니다. 그래서 루트 도메인은 A 레코드로 IP 주소를 직접 가리키고, 서브도메인은 CNAME으로 다른 호스트네임을 가리킵니다.
| 루트 도메인 (yourbrand.co.kr) | 서브도메인 (booking.yourbrand.co.kr) | |
|---|---|---|
| 추가하는 레코드 | A 레코드, IP 주소를 가리킴 | CNAME, 플랫폼 호스트네임을 가리킴 |
| 고객이 입력하는 주소 | 가장 짧은 주소 | 단어 하나가 더 붙지만, 고객이 링크로 들어온다면 크게 중요하지 않음 |
| 기존 웹사이트 | 루트에서 옮겨야 하며, 아니면 예약 사이트가 대체함 | 그대로 유지 |
| 회사 이메일 | MX 레코드만 건드리지 않으면 영향 없음 | 영향 없음 |
| 이런 곳에 적합 | 웹사이트가 곧 예약 사이트인 여행사 | 유지하고 싶은 소개 사이트, 블로그, CMS가 있는 여행사 |
이미 웹사이트가 있는 여행사 대부분은 서브도메인으로 시작하는 것이 맞습니다. 의견이 갈리는 줄은 두 번째 줄입니다. 서브도메인이 덜 번듯해 보인다고 느끼는 대표도 있습니다. 일리 있는 생각이지만, 고객 대부분이 주소를 직접 치기보다 카카오톡이나 인스타그램 링크로 들어온다면 그 무게는 줄어듭니다.
추가하는 레코드와 각각의 역할
관리자 화면의 DNS 안내 단계가 여러분 도메인에 맞는 정확한 값을 보여 줍니다. 값은 그곳에서 복사하세요. 어떤 글에서도, 이 글에서도 복사하지 마세요. 아래는 각 레코드가 무슨 일을 하는지에 대한 설명이라, 그 화면을 봤을 때 이해가 되도록 돕습니다.
- 서브도메인용 CNAME. Name: 고른 라벨, 예를 들어
booking. Value: DNS 단계가 알려 주는 플랫폼 호스트네임. "이 이름은 저 이름의 별칭"이라는 뜻이므로, 플랫폼 서버가 옮겨 가도 레코드를 건드리지 않고 계속 작동합니다. - 루트 도메인용 A 레코드. Name: 대부분의 DNS 관리 화면에서 도메인 자체를 뜻하는
@. Value: DNS 단계가 알려 주는 IP 주소. "이 이름은 이 주소에 산다"는 뜻입니다. - 경우에 따라 TXT. 일부 호스팅 구성은 확인용 레코드도 요구합니다. DNS 단계가 지정한 이름 아래에 들어가는 긴 무작위 문자열입니다. 방문자에게는 아무 영향이 없습니다. 도메인을 관리하는 사람이 연결에 동의했다는 증명일 뿐입니다. 단계에 보이면 추가하고, 보이지 않으면 빠진 것은 없습니다.
실패의 대부분은 두 가지 실수에서 나옵니다. 첫째는 Name 칸에 도메인 전체를 입력하는 것입니다. 많은 관리 화면이 도메인을 자동으로 붙이기 때문에, 거기에 booking.yourbrand.co.kr을 입력하면 booking.yourbrand.co.kr.yourbrand.co.kr이 되고, 이 주소는 아무 데도 연결되지 않습니다. 라벨만 입력하세요. 둘째는 예전 레코드를 그대로 두는 것입니다. booking에 예전 프로젝트의 A 레코드가 남아 있으면 CNAME이 그 옆에 들어갈 수 없고, 어떤 관리 화면은 조용히 예전 레코드를 유지합니다. 같은 이름의 예전 레코드를 먼저 지우세요.
DNS 호스트가 레코드에 프록시 스위치를 제공한다면(Cloudflare에서는 주황색 구름으로 표시됩니다) 연결하는 동안 DNS-only로 바꾸세요. 프록시는 플랫폼 대신 방문자에게 응답하기 때문에, 다음에 설명할 확인 과정에서 플랫폼을 가려 버립니다.
자물쇠가 맨 마지막에 오는 이유
대표들이 뭔가 고장 났다고 생각하는 단계가 바로 여기입니다. 레코드는 저장됐고 도메인도 맞아 보이는데, 브라우저는 연결이 안전하지 않다고 하거나 사이트가 아예 열리지 않습니다. 고장 난 것은 없습니다. 순서가 정해져 있을 뿐입니다.
TLS 인증서, 즉 자물쇠는 인증 기관이 발급하는데, 인증 기관은 먼저 도메인이 요청에 적힌 곳을 실제로 가리키는지 확인해야 합니다. 공개 DNS에서 이름을 조회하고, 대부분의 구성에서는 도메인에 요청을 보내 플랫폼이 응답하는지까지 봅니다. 레코드가 그 기관이 쓰는 리졸버에 닿기 전까지는 확인이 실패하고, 아무리 클릭해도 바뀌지 않습니다. 레코드가 조회되기 시작하면 플랫폼이 자동으로 인증서를 요청합니다. 인증서를 사거나, 올리거나, 갱신할 필요가 없습니다.
레코드가 "조회되기"까지 걸리는 시간은 주로 그 자리에 있던 이전 레코드의 TTL, 즉 다른 서버가 이전 답을 기억해도 되는 시간에 달려 있습니다. 완전히 새 이름은 보통 금방 나타납니다. 어제까지 다른 곳을 가리키던 이름은 한동안 이전 주소로 답할 수 있습니다. 기존 레코드를 바꿀 계획이라면 하루 전에 TTL을 낮춰 두면 기다림이 짧아집니다.
그 밖에는 기다렸다가 확인하세요. 레코드를 계속 고치지 마세요. 고칠 때마다 잘못된 답을 저장해 둔 서버들에게 그 답을 계속 내보낼 이유를 하나 더 주는 셈입니다. 공개 DNS 조회 사이트에서 세상이 여러분의 이름을 어떻게 보는지 확인할 수 있고, DNS 단계의 값이 보이면 다음 차례는 인증서입니다.
잘못했을 때 치르는 대가
비싼 실수는 예약 사이트에서 일어나지 않습니다. 도메인에 딸린 나머지 모든 것에서 일어납니다.
가장 나쁜 것은 레코드 하나만 추가하면 될 때 네임서버를 바꾸는 것입니다. 네임서버를 옮기면 도메인 전체가 새 DNS 호스트로 넘어가고, 그곳에 다시 만들지 않은 레코드는 사라집니다. 회사 이메일을 전달하는 MX 레코드도 마찬가지입니다. 받은편지함이 조용해졌다는 걸 누군가 알아차리기 전에 고객 메일, 공급사 확인 메일, 항공사의 스케줄 변경 안내를 하루치 잃을 수 있습니다. 예약 사이트 연결에는 네임서버 이전이 전혀 필요 없습니다. 레코드를 추가하고 나머지는 그대로 두세요.
두 번째는 예전 웹사이트에 사람들이 쓰는 페이지가 남아 있는데 루트 도메인을 예약 사이트로 돌리는 것입니다. 구글 상위에 올라 있는 비자 안내 페이지, 명함에 인쇄된 연락처 페이지 같은 것들이죠. 그 링크들은 이제 해당 페이지가 없는 예약 사이트로 떨어집니다. 예전 사이트를 먼저 서브도메인으로 옮기거나, 예약 사이트를 서브도메인에 연결하세요.
세 번째는 신경만 쓰이게 하는 실수입니다. 자물쇠가 나타나기 전에 새 주소를 알리는 것이죠. 홍보하는 날 브라우저가 경고로 고객을 쫓아낸다면 첫인상이 좋을 리 없습니다. 레코드를 저장한 뒤가 아니라 인증서가 활성화된 뒤에 알리세요.
플랫폼 도메인은 남겨 두세요: 비상구입니다
사이트가 처음 시작된 플랫폼 서브도메인은 자체 도메인을 연결해도 사라지지 않습니다. 삭제할 수 없고, 이는 의도된 것입니다.
자체 도메인이 자리 잡는 동안 테스트하는 주소이고, 등록 기관에서 갱신을 놓치거나 누군가 실수로 DNS를 고쳤을 때도 계속 작동하는 주소입니다. 두 주소 뒤의 예약 엔진은 같기 때문에 예약, 고객, 리포트는 어느 문으로 들어왔는지 신경 쓰지 않습니다. 자체 도메인이 살아 있는지와 상관없는 곳에 이 주소를 적어 두세요.
이 주소는 새 사이트의 올바른 순서도 정해 줍니다. 하루 만에 OTA를 여는 법과 같은 순서입니다. 먼저 가입 마법사가 카드 없이 만들어 주는 서브도메인으로 오픈하고, 사이트가 보여 줄 만해지면 도메인을 연결하세요. 주소가 여러분 것이 된 뒤 사이트가 무엇을 해 주는지는 화이트라벨 여행 웹사이트가 실제로 주는 것에 정리되어 있습니다.
체크리스트: 예약 엔진에 자체 도메인 연결하기
- DNS를 누가 호스팅하는지 확인합니다. 도메인의 네임서버가 알려 줍니다.
- 루트 도메인과 서브도메인 중 고릅니다. 유지할 웹사이트가 있다면 서브도메인입니다.
- 무엇이든 바꾸기 전에 기존 레코드, 특히 MX를 모두 기록합니다. 스크린샷이면 충분합니다.
- 사용할 이름과 정확히 같은 이름의 예전 레코드를 지웁니다.
- DNS 단계의 레코드를 추가합니다. 서브도메인은 CNAME, 루트는 A, 단계에 보이면 TXT도 추가합니다. Name 칸에는 라벨만 입력합니다.
- 해당 레코드의 프록시를 DNS-only로 바꿉니다.
- 레코드가 공개적으로 조회될 때까지 기다립니다. 계속 고치지 않습니다.
- 자물쇠를 확인하고, 새 주소에서 테스트 예약을 한 다음 고객에게 알립니다.
이 목록의 대부분은 기다림입니다. 정말로 여러분을 다치게 할 수 있는 단계는 목록에 없는 그것, 네임서버 이전 하나뿐입니다.