단축 링크용 맞춤 도메인: 연결부터 검증까지 완전 설정 가이드

단축 링크는 클릭이 어디에 도착할지에 대한 약속이고, 도메인은 사람이 판단하기 전에 읽을 수 있는 그 약속의 유일한 부분입니다. bit.ly/3xKqR2p 같은 문자열은 누가 부르는지 아무것도 말해 주지 않지만, go.yourbrand.com/spring-sale은 누구인지와 무엇인지를 함께 말해 줍니다. 이 격차 때문에 진지한 링크 운영은 대부분 언젠가 공용 도메인을 떠나고, 그 이동이 그토록 자주 중간에 멈추는 이유도 여기에 있습니다. 마케팅 옷을 입은 DNS 프로젝트이고, 그 실패 양상은 이 일을 요청한 사람들에게 낯설기 때문입니다.

이 가이드는 그 경로 전체를 다룹니다. 도메인 고르기, 서브도메인과 apex 도메인에 필요한 정확한 레코드, 소유권 검증과 인증서 발급이 실제로 동작하는 방식, 망가진 설정의 대부분을 차지하는 몇 가지 DNS 실수, 그리고 회수할 수 없는 포장에 인쇄하기 전에 완성된 리디렉션 사슬을 검증하는 방법입니다.

단축 링크의 도메인이 중요한 이유

인지는 클릭 이전에 일어납니다

모든 링크는 1초 남짓에 내려지는 작은 신뢰 판단입니다. 공용 단축 도메인에서는 읽는 사람에게 아무 정보도 없습니다. 그 호스트명은 수백만 명이 쓰는 서비스의 것이고, 그중 누군가는 바로 그 주에 피싱 캠페인을 돌리고 있습니다. 브랜드 호스트명은 그 짐작을 사실로 바꿔 놓습니다.

사업자들은 브랜드 링크의 클릭률 상승 수치를 발표하지만, 비교 조건이 같은 경우가 드물므로 방향을 가리키는 참고값으로만 받아들이십시오. 오래가는 것은 그 작동 원리입니다. URL이 눈에 보이되 누를 수는 없는 채널, 즉 인쇄물, QR 설명 문구, 미리보기가 제거된 SMS에서는 읽는 사람이 판단할 근거가 호스트명이 거의 전부입니다.

공용 도메인은 남의 평판을 함께 짊어집니다

이쪽이 더 날카로운 논거입니다. 공용 도메인에서는 여러분의 링크가 여러분이 통제하지 못하는 평판을 물려받습니다. 이메일 필터, 사내 프록시, 메신저의 링크 검사기, 브라우저 안전 프로그램은 모두 호스트명 단위로 판단하므로, 같은 도메인의 무관한 계정에서 밀려온 스팸 물결이 경고 중간 페이지나 조용한 차단이 되어 여러분의 캠페인에 떨어집니다.

여러분이 소유한 도메인은 이 관계를 뒤집습니다. 평판은 여러분의 것이고 여러분의 트래픽으로 쌓이며, 낯선 사람이 망가뜨릴 수 없습니다. 의무는 그 거울상입니다. 이제 그 아래 게시되는 모든 것의 결과도 여러분의 몫이므로, 다른 사람에게 링크를 재판매한다면 악용 대응과 사용자별 링크 가시성을 염두에 두어야 합니다.

이전을 가능하게 만드는 것은 소유권입니다

여러분이 통제하는 도메인은 영구 주소입니다. 플랫폼을 바꿔도 레코드 하나만 돌리면 되고, 지난 분기 포장에 실린 코드는 계속 연결됩니다. 사업자의 공용 도메인에 게시하면 인쇄된 자산 하나하나가 그 사업자의 가격 정책에 인질로 잡힙니다. 화이트라벨 모델을 밀어붙이는 논리도 이와 같습니다.

도메인 고르기

길이가 전부입니다

단축 링크는 짧기 위해 존재합니다. 호스트명의 모든 글자는 슬러그가 쓸 수 없게 된 글자이고, 사람들이 소리 내어 읽고 포스터를 보고 입력하고 SMS에 밀어 넣는 것도 바로 호스트명의 글자입니다. 쓸 만한 목표는 인쇄된 한 줄에 넉넉히 들어가는 전체 링크 길이입니다. 대략 호스트명 10~15자에 슬러그 5~12자 정도입니다.

| 형태 | 예시 | 어울리는 곳 | 맞바꿈 | | --- | --- | --- | --- | | 메인 도메인의 서브도메인 | go.yourbrand.com | 빠른 출시, 자체 채널, 이메일 | 셋 중 가장 김 | | 짧은 TLD에 줄여 쓴 브랜드 | yrbrnd.co | SMS, 인쇄물, 포장 | 새 등록이 필요하고 덜 직관적임 | | 테마 TLD에 브랜드 전체 | yourbrand.link | 캠페인 허브, QR 코드 | apex 설정, TLD 평판이 제각각 |

TLD 선택에는 현실적인 결과가 따릅니다

모든 최상위 도메인이 필터에서 똑같이 취급되지는 않습니다. 값싼 프로모션용 TLD는 스팸 밀도가 높아서, 일부 사내 메일 게이트웨이는 이를 무디게 처리합니다. 단어의 끝처럼 쓰이는 국가 코드 TLD, 즉 .co, .io, .to, .ly 같은 무리는 각자의 정책과 갱신 비용을 가진 레지스트리에 속합니다. 등록하기 전에 첫해 가격이 아니라 갱신 가격을, 등록자 자격 제한을, 그리고 여러분이 게시하는 채널이 그 접미사를 자동으로 링크로 만들어 주기는 하는지를 확인하십시오.

몇 개의 도메인을 받는지는 실질적인 한도입니다

도메인 허용량은 사업자마다 크게 다르고, 브랜드나 고객이 하나를 넘어가는 순간 바로 발목을 잡습니다. 2026년 8월 기준으로 Short.io는 무료 등급에서도 맞춤 도메인 다섯 개를 포함하고, Rebrandly는 유료 등급에 걸쳐 1개, 2개, 3개, 10개를 허용하며, BL.INK는 사용자 1명과 도메인 1개로 월 48 USD부터 시작합니다. LinkProfit은 월 49 USD인 Starter에 리디렉션 도메인 세 개를, Scale에 서른 개를 포함합니다. 고객의 링크를 관리한다면 이번 달이 아니라 1년 뒤에 필요할 도메인 수를 세어 보십시오.

인증서 적용 범위도 같은 김에 확인할 만합니다. Cutt.ly는 2026년 8월 기준으로 월 25 USD인 Single 요금제부터만 Let's Encrypt 인증서를 자동으로 제공하므로, 그 아래 등급에 연결한 맞춤 도메인은 HTTPS로 온전히 쓸 수 없습니다. 전체 기능 비교는 저희 맞춤 도메인 페이지에 있습니다.

실제로 만들게 되는 DNS 레코드

레코드 세 개면 거의 모든 설정이 끝납니다. 트래픽을 실어 나르는 레코드, 소유권을 증명하는 레코드, 인증서 검증을 위임하는 레코드입니다. 어떤 라우팅 레코드를 쓰는지는 서브도메인을 골랐는지 apex를 골랐는지에 달려 있습니다.

서브도메인을 위한 CNAME

이것이 흔한 경로이자 권장되는 방식입니다. 서브도메인이 플랫폼 소유의 호스트명을 가리키고, 플랫폼의 엣지 네트워크가 그 호스트명을 대신 응답합니다.

Type   Name   Value                   TTL    Proxy
CNAME  go     cname.linkprofit.com    300    DNS only

여기서 두 가지가 사람들을 걸려 넘어지게 합니다. 대부분의 DNS 패널은 존을 기준으로 한 상대 이름을 원하므로 go.yourbrand.com이 아니라 go를 입력해야 하지만, 일부는 완전한 형태를 요구하며, 잘못 입력하면 go.yourbrand.com.yourbrand.com이 조용히 만들어집니다. 그리고 DNS가 Cloudflare에 있다면 그 레코드는 프록시 없이 두어야 합니다. 패널에서 DNS only라고 부르는 상태이며, 이유는 아래 실수 항목에 있습니다. 사업자마다 대상 호스트명은 다르지만 형태는 같습니다. 2026년 8월 기준으로 Short.io는 cname.short.io를, Rebrandly는 registrar.dedicated.domains를 씁니다. 주요 등록기관별 단계별 화면 안내는 CNAME 설정 문서에 있습니다.

apex 도메인을 위한 A 레코드

DNS는 존의 apex에서 CNAME을 금지합니다. apex는 SOA와 NS 레코드도 함께 지녀야 하는데 CNAME은 같은 이름의 다른 레코드와 공존할 수 없기 때문입니다. 그래서 yourbrand.link 자체는 CNAME이 될 수 없습니다. 빠져나갈 길은 두 가지입니다.

첫째는 제공업체 쪽 플래트닝입니다. ALIAS, ANAME 또는 CNAME 플래트닝이라는 이름으로 제공되며, DNS 제공업체가 대상을 대신 조회해 그 주소로 응답하는 방식입니다. Cloudflare, DNSimple, Namecheap, Porkbun, DNS Made Easy, easyDNS, NS1, Bunny, Azure DNS, Google Cloud DNS가 이를 지원합니다. Route 53, GoDaddy, IONOS, Network Solutions는 자사 생태계 바깥의 대상에 대해서는 제공하지 않습니다.

둘째는 플랫폼이 발급해 주는 인그레스 IP 주소를 가리키는 A 레코드입니다. 아래 주소는 문서용으로 예약된 대역의 예시 값이므로, 실제로는 여러분의 대시보드에 표시되는 값을 쓰십시오.

Type  Name  Value              TTL
A     @     203.0.113.10       300
AAAA  @     2001:db8::10       300
CNAME www   cname.linkprofit.com  300

www 링크를 게시할 생각이 전혀 없어도 www 레코드는 추가하십시오. 사람들은 습관적으로 그것을 입력하고, 응답하지 않는 www는 리디렉션이 아니라 연결 오류를 냅니다. 어느 제공업체가 apex 레코드에 어떤 라벨을 보여 주는지를 포함한 apex의 세부 사항은 apex 도메인 문서에서 다룹니다. 사업자들은 이 주소를 공개해 두는데, 2026년 8월 기준으로 Short.io는 207.174.61.1을, Rebrandly는 52.72.49.79를 문서에 적어 두었습니다. 이 경로가 별난 방식이 아니라 표준이라는 점을 확인하는 데 쓸 만한 근거입니다.

도메인이 여러분의 것임을 증명하는 TXT 레코드

소유권 증명이 없으면 누구나 공용 플랫폼에서 go.yourbrand.com을 자기 것이라 주장할 수 있고, 여러분이 CNAME을 만든 순간 여러분에게 향하던 트래픽을 대신 받게 됩니다. 그래서 플랫폼은 토큰을 발급하고 서비스를 시작하기 전에 그것을 확인합니다.

Type  Name                 Value
TXT   _linkprofit-verify   dom_2f7a91c4be0d3856

토큰은 여러분의 도메인 레코드에 고유합니다. 호스트명이 활성화된 뒤에도 레코드는 그대로 두어도 되며, 삭제한다고 해서 동작 중인 도메인이 깨지지는 않지만 그대로 두면 재검증 과정에서 뜻밖의 일을 겪지 않습니다.

갱신 러닝머신 없는 자동 TLS

인증서는 어떻게 발급되는가

플랫폼은 자기 소유가 아닌 호스트명에 대해 유효한 인증서가 필요합니다. Let's Encrypt를 떠받치는 프로토콜인 ACME가 자동화하려고 만들어진 것이 바로 이 일입니다. 플랫폼이 go.yourbrand.com에 대한 인증서를 요청하면, 인증 기관이 챌린지를 내고, 플랫폼이 그것에 응답해 통제권을 증명합니다. 도메인 검증 인증서는 챌린지를 통과하는 순간 몇 초 만에 발급되며 비용도 들지 않습니다.

중요한 성질은 유효 기간입니다. 요즘 인증서는 설계상 수명이 짧으므로, 발급은 한 번으로 끝나는 설정 단계가 아닙니다. 도메인이 연결되어 있는 내내, 시스템 안의 모든 도메인에 대해 돌아가는 갱신 루프입니다.

챌린지를 한 번만 위임하기

그 루프를 보이지 않게 만드는 튼튼한 방법은 검증을 위임하는 것입니다. 챌린지 이름에 CNAME 하나를 만들어 플랫폼이 통제하는 위임 대상을 가리키게 해 두면, 그 뒤로 모든 갱신은 여러분의 조작 없이 플랫폼이 응답합니다.

Type   Name                 Value
CNAME  _acme-challenge.go   the delegation target shown in your dashboard

대안, 즉 갱신 주기마다 새 TXT 값을 붙여 넣는 방식은 그 달력 알림을 맡은 사람이 이직하는 날까지만 정확히 동작합니다. 사업자의 연결 절차가 주기적인 수동 검증을 요구한다면, 그것을 불편함이 아니라 이미 예정된 장애로 받아들이십시오.

건강한 연결 절차는 어떤 모습인가

눈에 보이는 상태 세 가지와 그 사이의 자동 이동을 기대해야 합니다. 레코드가 아직 관측되지 않는 동안의 DNS 대기, 레코드를 찾은 뒤의 인증서 대기, 그리고 트래픽을 처리할 수 있게 된 활성입니다. 재확인은 버튼을 눌렀을 때만이 아니라 1분 남짓의 주기로 돌아가야 하고, 화면은 뭉뚱그린 실패 대신 정확히 어느 레코드가 빠졌는지 알려 주어야 합니다. TTL이 낮은 깨끗한 존에서 처음부터 끝까지 걸리는 시간은 보통 몇 분입니다.

살아 있는 링크를 깨뜨리는 DNS 실수

레코드 프록시와 Flexible 모드의 무한 루프

Cloudflare에 호스팅된 존에서 단연 가장 흔한 장애입니다. 주황색 구름을 켜면, 이미 그 호스트명에 대해 TLS를 종료하는 플랫폼 앞에 두 번째 TLS 종료 지점이 놓입니다. 암호화가 Flexible로 설정되어 있으면 프록시는 평문 HTTP로 원본에 연결하고, 원본은 HTTPS로 리디렉션을 응답하고, 프록시가 그것을 다시 돌려주므로, 브라우저는 포기할 때까지 맴돕니다. Rebrandly도 자사 사용자를 위해 이 충돌을 문서로 안내합니다. 특정 사업자의 문제가 아니라 이 구성 자체의 성질입니다. 그러지 말아야 할 특별한 이유가 없다면 레코드를 프록시 없이 두고, 꼭 프록시를 써야 한다면 암호화를 Full strict로 설정하십시오.

남아 있는 레코드와 충돌하는 레코드

한때 다른 곳을 가리켰던 서브도메인에는 대개 A 레코드가 아직 남아 있고, 하나의 이름은 CNAME과 다른 종류의 레코드를 함께 지닐 수 없습니다. 어떤 패널은 두 번째 레코드를 분명한 오류와 함께 거부하지만, 어떤 패널은 받아들여서 간헐적인 이름 해석을 만들어 냅니다. 무언가를 추가하기 전에 정확히 그 이름의 기존 레코드를 모두 나열하고 낡은 것을 삭제하십시오. 와일드카드 레코드도 조심하십시오. 존에 * 항목이 있으면 명시적인 레코드가 없을 때 그것이 go를 대신 응답하므로, 빠진 CNAME이 마치 동작하는 것처럼 보입니다.

발급 기관을 배제하는 CAA 레코드

존이 CAA 레코드를 게시하고 있다면, 그 레코드는 어떤 인증 기관이 그 존에 대해 인증서를 발급할 수 있는지를 제한합니다. 상용 CA 한 곳으로 잠긴 존은 Let's Encrypt의 발급을 조용히 막고, 그 실패는 인증서가 끝내 나타나지 않는 형태로 드러납니다. 플랫폼이 쓰는 발급 기관을 추가하거나, 해당 호스트명에 대한 제한을 해제하십시오.

변경 직전에 걸어 둔 높은 TTL

TTL은 예전 응답이 얼마나 오래 유효한지에 대해 여러분이 리졸버에게 한 약속입니다. TTL이 86400인 레코드를 바꾸면 일부 리졸버는 이전 값을 하루 동안 그대로 씁니다. 전환을 계획했다면 적어도 하루 전에 TTL을 300으로 낮추고, 새 설정이 검증된 뒤에 다시 올리십시오.

등록기관의 파킹과 전달 설정

새로 등록한 도메인에는 파킹 페이지, URL 전달, 또는 등록기관의 기본 레코드가 이미 들어 있는 경우가 많습니다. 특히 전달 설정은 플랫폼의 버그처럼 보이는 방식으로 방해합니다. 요청이 여러분의 리디렉션 엔진에 닿기도 전에 등록기관이 먼저 응답해 버리기 때문입니다. 새 도메인은 비어 있으려니 짐작하지 말고 명시적으로 꺼 두십시오.

인쇄하기 전에 사슬을 검증하기

이름 해석과 리디렉션은 서로 다른 문제이므로 둘 다 확인하십시오.

dig +short go.yourbrand.com CNAME
dig +short go.yourbrand.com A
curl -sSI https://go.yourbrand.com/spring-sale | grep -i -E 'HTTP/|location'

curl 출력에는 리디렉션 상태 코드 하나와, 최종 목적지를 곧바로 가리키는 location 헤더 하나만 보여야 합니다. 볼 것은 두 가지입니다. 첫째는 홉 수입니다. 홉이 하나 늘 때마다 왕복이 하나 더해지고 유입 경로 데이터가 희석되므로, 목적지에 닿기 전에 추적 도메인을 거치는 사슬은 줄여야 합니다. 둘째로 목적지 URL은 UTM 파라미터까지 포함해 여러분이 설정한 그대로여야 합니다. 목적지 자체가 http에서 https로, 또는 apex에서 www로 다시 리디렉션한다면 의도하지 않은 홉이 하나 더 붙기 때문입니다.

같은 점검을 apex와 www 형태에 대해, 그리고 http와 https 양쪽으로 실행하십시오. 목적지가 기기 기반 라우팅을 한다면 모바일 사용자 에이전트로도 한 번 해 보십시오. 터미널 없이 빠르게 확인하려면 저희 링크 검사기가 사슬 전체를 펼치고 각 상태 코드를 보여 줍니다. 경쟁사나 파트너의 링크를 다시 게시하기 전에 살펴보는 가장 빠른 방법이기도 합니다. 마지막으로 여러분의 링크 하나를 직접 눌러 보고 그 이벤트가 분석에 나타나는지 확인하십시오. 이름은 해석되고 리디렉션도 되는데 아무것도 기록되지 않는 도메인은, 대개 트래픽이 여러분이 생각하는 곳과 다른 원본에 도착하고 있다는 뜻입니다.

처음부터 끝까지, 설정 순서

1. 도메인을 등록하거나 고르고, 갱신 가격과 레지스트리 제한을 확인합니다.
2. 곧 교체할 레코드의 TTL을 낮춥니다. 되도록 하루 전에 해 둡니다.
3. 링크 플랫폼에 도메인을 추가하고, 화면에 표시된 레코드를 그대로 옮겨 적습니다.
4. 라우팅 레코드를 만듭니다. 서브도메인에는 CNAME, 플래트닝이 없는 apex에는 A와 AAAA입니다.
5. 소유권 TXT 레코드와 챌린지를 위임하는 CNAME을 만듭니다.
6. DNS가 Cloudflare에 있다면 라우팅 레코드가 프록시 없이 설정되어 있는지 확인합니다.
7. 같은 이름의 낡은 레코드를 삭제하고, 그것을 가릴 수 있는 와일드카드가 있는지 확인합니다.
8. 상태가 인증서 대기를 거쳐 활성으로 넘어가기를 기다린 뒤, dig와 curl로 검증합니다.
9. apex, www, http, https를 시험하고 모바일 사용자 에이전트로도 한 번 확인합니다.
10. 대표 링크를 하나 만들어 눌러 보고, 그 클릭이 기록되는지 확인합니다.
11. TTL을 다시 올리고, 도메인 갱신을 누가 책임지는지 문서로 남깁니다.

깨끗한 존이라면 이 대부분이 15분짜리 작업입니다. 예외는 플래트닝을 제공하지 않는 업체의 apex 도메인으로 IP 경로가 필요한 경우, 그리고 몇 년치 레코드가 쌓인 존으로 추가가 아니라 삭제가 일이 되는 경우입니다.

브랜드 도메인은 링크 운영이 취할 수 있는 가장 값싼 신뢰도 향상책이고, 한 번 연결해 두면 나머지 스택은 이미 여러분이 통제하는 인프라 위에서 돌아갑니다. 여러분 자신이 아니라 고객을 위해 도메인을 설정한다면, 그 제안을 믿음직하게 만들어 주는 것이 바로 고객별 도메인입니다. 허용량이 요금제마다 어떻게 달라지는지는 맞춤 도메인에서 확인하십시오.