2025년 11월 19일·5분
DNS 및 SSL 문제를 위한 맞춤 도메인 문제 해결 체크리스트
DNS 레코드 문제, 전파 지연, SSL 발급 타이밍을 진단하는 맞춤 도메인 점검표입니다. 간단한 확인 단계로 문제 원인을 빠르게 찾으세요.
DNS 레코드 문제, 전파 지연, SSL 발급 타이밍을 진단하는 맞춤 도메인 점검표입니다. 간단한 확인 단계로 문제 원인을 빠르게 찾으세요.
“맞춤 도메인이 작동하지 않음”은 여러 실패 사례를 포괄하는 표현입니다. 브라우저는 증상만 보여줄 뿐 원인은 아닙니다. 어떤 현상이 나오는지 먼저 적어보세요.
일반적인 증상은 다음과 같습니다:
대부분의 경우 원인은 한 가지입니다:
문제 해결 전에 두 군데에 접근 권한이 있는지 확인하세요: DNS 레코드를 편집하는 장소(등록기관 또는 DNS 제공자)와 호스팅 쪽에서 도메인을 연결하는 장소. 예를 들어 Koder.ai에 배포한 앱에 맞춤 도메인을 연결한다면 도메인의 DNS 접근 권한과 앱의 호스팅/배포 설정에서 도메인 설정을 모두 확인해야 합니다.
일부 수정은 즉시 반영됩니다(오탈자 수정 등). 다른 것들은 시간이 걸립니다. DNS 변경은 반영되기까지 시간이 걸리고, SSL은 일반적으로 DNS가 올바르게 가리키고 도메인에 접근 가능해질 때까지 완료되지 않습니다. 목표는 추측을 멈추고 각 계층을 차례로 확인하는 것입니다.
대부분의 도메인 문제는 (1) 테스트 중인 호스트명, (2) DNS가 관리되는 곳, (3) 레코드가 실제로 가리키는 대상 간 불일치에서 발생합니다. 이 셋이 일치하면 보통 SSL은 마지막 단계에 해결됩니다.
도메인은 두 가지 흔한 형태가 있습니다: 루트 도메인(example.com, apex라고도 함)과 서브도메인(www.example.com, app.example.com). 관련은 있지만 서로 다른 DNS 레코드를 가질 수 있습니다. 그래서 www는 작동하는데 루트는 실패하거나 그 반대인 경우가 흔합니다.
네임서버는 DNS 존을 누가 관리하는지 결정합니다. 도메인을 한 회사에서 샀지만 네임서버가 다른 곳을 가리킨다면, 네임서버가 가리키는 곳에서 DNS를 편집해야 합니다. “수정했는데 아무것도 변하지 않음” 상황의 많은 부분은 잘못된 대시보드에서 레코드를 편집했기 때문입니다.
주요 레코드가 하는 일은 다음과 같습니다:
TTL은 “얼마나 오래 캐시할지” 타이머입니다. TTL이 낮으면 캐시가 더 빨리 갱신되고, TTL이 높으면 고친 뒤에도 오래 기다려야 할 수 있습니다. 일정 시간 동안 오래된 값을 보이는 건 정상입니다.
맞춤 도메인이 실패할 때 보통 네 가지 범주 중 하나로 분류할 수 있습니다: DNS가 해석되지 않음, DNS가 잘못된 곳을 가리킴, SSL이 준비되지 않음, 또는 일부 사용자에게만 실패(캐싱 문제).
다음 결정 트리를 사용하세요:
www는 작동하지만 루트 도메인이 그렇지 않다면 호스트에 한 호스트명만 구성했거나 상충하는 리디렉트 규칙이 있을 가능성이 큽니다.실패한 정확한 호스트명(루트 vs www)과 정확한 오류 메시지를 적어두면 더 빠르게 이동할 수 있습니다. 도메인 및 인증서를 자동화하는 호스팅 플랫폼에서는 “호스트를 찾을 수 없음”과 “인증서 보류 중”의 차이가 DNS를 고쳐야 할지 아니면 DNS가 보이게 된 뒤 SSL을 기다려야 할지 알려줍니다.
많은 도메인 실패는 단순한 불일치에서 시작합니다: 어떤 호스트명의 DNS를 설정했는데 다른 호스트명을 테스트하고 있는 경우입니다.
먼저 라이브로 만들고 싶은 정확한 호스트명을 적으세요. 루트 도메인은 example.com처럼 보이고 서브도메인은 www.example.com 또는 app.example.com처럼 보입니다. 이들은 별도의 DNS 항목이므로 “www가 작동한다”가 곧 루트도 작동한다는 뜻은 아닙니다.
다음으로 호스팅 플랫폼에서 기대하는 대상을 찾으세요. 어떤 플랫폼은 IP 주소(A나 AAAA 레코드용)를 주고, 어떤 플랫폼은 대상 호스트명(CNAME용)을 줍니다. 호스트가 도메인 설정 화면에서 제공한 값을 진실의 출처로 보세요.
변경하기 전에 현재 설정된 값을 캡처하세요. 간단히 기록하세요:
또한 올바른 DNS 존을 편집 중인지 확인하세요. 잘못된 도메인, 잘못된 환경, 잘못된 제공자 계정을 업데이트하기 쉬우니 주의하세요.
많은 문제는 단지 연결하려는 호스트명에 잘못된 레코드 유형을 사용했기 때문입니다. 먼저 두 가지 경우를 구분하세요: 루트 도메인(example.com)과 서브도메인(www.example.com). 많은 DNS 제공자는 이들에 대해 다르게 동작합니다.
A 레코드는 이름을 IPv4 주소로 가리킵니다. 일부 설정은 루트 도메인에 A 레코드를 사용합니다(일부 제공자는 apex에 CNAME을 허용하지 않음). 호스트가 IP를 제공하면 보통 A 레코드가 맞습니다.
AAAA 레코드는 IPv6 버전입니다. 잘못된 AAAA 레코드가 남아 있으면 일부 방문자는 IPv6로, 다른 방문자는 IPv4로 가서 일관성 없는 실패가 발생할 수 있습니다. 호스트가 IPv6 대상을 주지 않았다면 잘못된 AAAA 레코드를 제거하면 문제를 해결하는 경우가 많습니다.
CNAME 레코드는 서브도메인을 다른 호스트명으로 가리킵니다(주로 www에 사용). 호스트가 이름 기반 엔드포인트를 제공할 때 유용합니다.
TXT 레코드는 검증 및 챌린지(일부 SSL 확인 포함)를 위해 사용됩니다. 흔한 실수는 TXT를 잘못된 이름(루트 vs _acme-challenge vs 서브도메인)에 만들거나, 값에 추가 공백을 넣거나, 잘못된 값을 붙여넣는 것입니다.
다음과 같은 충돌을 찾아보세요. 이들이 가장 큰 문제를 만듭니다:
많은 “맞춤 도메인이 작동하지 않음” 사례는 레코드 값 문제가 아닙니다. 잘못된 제공자에서 레코드를 추가했기 때문에 발생합니다. 도메인이 Provider A의 네임서버를 사용한다면 Provider B의 대시보드에서 레코드를 바꿔도 아무 효과가 없습니다.
도메인이 실제로 어떤 네임서버를 사용하는지 확인하세요. 보통 레지스트라의 도메인 설정의 “Nameservers”에서 볼 수 있습니다. 두 번째 확인을 위해 컴퓨터에서 직접 DNS에 물어볼 수도 있습니다:
dig NS example.com
그 명령이 반환하는 네임서버가 권한 있는 네임서버입니다.
간단한 점검:
ns1..., ns2... 같은 네임서버를 제공하면, 등록기관에 그 정확한 값이 들어가 있어야 합니다.잘못된 제공자에서 레코드를 변경하면 두 개의 대시보드가 일치하지 않는 경우가 많습니다. 공개적으로는 권한 있는 네임서버만 중요합니다.
또한 등록기관에서 네임서버를 변경한 뒤 지연이 발생할 수 있습니다. 전환 창 동안 테스트 위치에 따라 결과가 일관되지 않게 보일 수 있습니다. 네임서버가 여전히 변경 중이라면 네임서버 집합이 안정될 때까지 레코드 편집을 멈추세요.
“전파(Propagation)”는 하나의 스위치가 아닙니다. ISP, 이동통신사, 공용 리졸버, 그리고 당신의 기기까지 여러 DNS 캐시 체인이 다른 속도로 업데이트됩니다. 그래서 동료에게는 작동하는데 당신에게는 실패하는 경우가 발생합니다.
TTL(수명)은 캐시가 답을 얼마나 오래 유지할지 알려줍니다. 이전 TTL이 1시간이었다면 일부 사람들은 거의 한 시간 동안 오래된 값을 계속 볼 수 있습니다. TTL을 낮추는 것은 변경하기 전에 TTL을 낮췄을 때만 도움이 됩니다.
캐싱 지연과 실제 실수를 분리하려면 몇 가지 빠른 확인을 하세요:
대부분의 검사 지점에서 레코드가 잘못되어 있다면(잘못된 IP, 누락된 www, 오래된 CNAME) 수정하세요. 대부분의 장소에서 레코드가 올바른데 한 네트워크만 오래된 값을 보이면 보통 캐시 지연입니다.
SSL 인증서가 실패하는 기본적인 이유는 인증서 발급자가 DNS가 올바르게 가리키는지 도메인을 검증할 수 없기 때문입니다.
일반적인 순서는 간단합니다:
놓치기 쉬운 일반적인 차단 요소들이 있습니다. 잘못된 A나 CNAME 대상은 검증 요청을 잘못된 서버로 보냅니다. 오래된 AAAA 레코드는 일부 방문자에게는 작동하는 A 레코드를 덮어씌워 HTTPS 실패를 유발할 수 있습니다. 필수 TXT 레코드가 없으면 플랫폼이 인증서를 발급하지 못할 수 있습니다.
증상으로 “아직 발급 중”과 “잘못 구성됨”을 구분하세요:
기다리는 동안 레코드를 계속 바꾸지 마세요. 변경할 때마다 시간이 초기화되고 서로 다른 네트워크가 다른 답을 보이는 분할된 상태가 생길 수 있습니다. 올바른 레코드를 한 번 설정한 뒤 DNS가 안정될 때까지 재확인하고 검증을 진행하세요.
Koder.ai 같은 플랫폼을 사용하는 경우 안전한 흐름은 동일합니다: DNS가 기대 대상에 가리키는지 확인하고, 잘못된 AAAA 레코드가 있으면 제거한 다음 DNS가 안정된 후 SSL에 시간을 주세요.
좋은 문제 해결은 대부분 비교입니다: 관찰한 것 vs 기대한 것. “내 폰에서는 로드된다”에 의존하지 마세요. 재현 가능한 검사를 사용하세요.
DNS 조회 도구(nslookup 또는 dig)를 사용하여 반환된 값이 의도한 값( A/AAAA는 IP, CNAME은 호스트명, TXT는 토큰)과 일치하는지 확인하세요.
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
사용할 수 있는 두 이름, 즉 루트(example.com)와 www(www.example.com)를 모두 확인하세요. 둘 중 하나는 올바른데 다른 하나가 여전히 오래된 곳을 가리키는 경우가 흔합니다.
apex와 www 모두에 대해 http://와 https://를 열어보세요. 하나의 명확한 “홈” 도메인과 하나의 깔끔한 리디렉트가 목표입니다.
www)을 선택하고 다른 쪽을 그쪽으로 리디렉트하세요.네트워크에 따라 결과가 다르다면 캐싱 또는 전파 문제일 가능성이 큽니다. 변경한 내용, 변경한 곳, 시간, 관찰한 내용을 간단히 기록해두세요.
대부분의 DNS 및 SSL 문제는 미스터리가 아닙니다. 작고 반복되는 실수들이 원인입니다. 잘못된 것을 계속 확인하거나 너무 자주 변경해 명확한 판단을 할 수 없게 만드는 경우가 많습니다.
가장 흔한 시간 낭비는 두 곳에서 DNS를 편집하는 것입니다. 네임서버를 바꾼 뒤 한곳에서는 레코드를 수정하고 다른 곳에서는 또 수정하는 일이 잦습니다. 하나의 대시보드에서는 모든 것이 맞아 보이지만 공개적으로는 반영되지 않는 경우가 생깁니다.
또 다른 실수는 제공자가 apex에 CNAME을 허용하지 않는데 CNAME을 넣으려고 하는 것입니다. 이 경우 A 레코드가 필요하거나, 제공자가 ALIAS 또는 ANAME 스타일 레코드를 제공하면 그걸 사용해야 합니다.
IPv6도 골칫거리입니다. 오래된 AAAA 레코드를 남겨두면 일부 방문자만 잘못된 서버로 가고 다른 방문자는 올바른 IPv4로 가는 현상이 생깁니다.
“혹시 몰라” 식의 레코드를 남겨두는 것도 주의하세요. 여러 A 레코드는 의도치 않은 로드밸런싱처럼 동작할 수 있고, 그중 하나가 잘못되면 문제를 일으킬 수 있습니다.
마지막 규칙: 시계를 계속 리셋하지 마세요.
작고 침착한 변경이 빈번한 수정보다 낫습니다.
새로운 앱을 런칭하고 example.com과 www.example.com을 모두 설정했습니다. 몇 분 뒤 www.example.com은 잘 로드되지만 루트 도메인은 DNS 오류가 나거나 오래된 사이트가 나오거나 HTTPS가 보류 중입니다. 이런 패턴은 흔하며 보통 원인은 사소합니다.
먼저 지루한 질문부터 시작하세요: 올바른 곳에서 DNS를 편집하고 있나요? 도메인이 한 회사에 등록되어 있지만 DNS는 다른 곳에서 호스팅되는 경우, 아무리 레코드를 바꿔도 공개적으로는 변하지 않습니다. 네임서버를 먼저 확인한 뒤 네임서버가 가리키는 제공자의 DNS 패널을 열어보세요.
다음으로 두 호스트명을 비교하세요. www는 보통 CNAME입니다. 루트 도메인은 더 까다롭습니다: 많은 제공자는 apex에 CNAME을 허용하지 않으므로 보통 IP로 가리키는 A 레코드가 필요하거나, 제공자가 ALIAS나 ANAME 스타일 레코드를 제공하면 그것을 사용해야 합니다.
실습에 도움이 되는 의사결정 경로:
example.com에 레코드가 없거나 다른 곳을 가리키면 apex 레코드를 고치세요.올바른 최종 상태는 단조롭습니다: example.com과 www.example.com이 동일한 앱으로 연결되고 하나는 정규화되어(다른 하나가 리디렉트), HTTPS가 유효한 상태입니다.
도메인 설정이 실패할 때 대부분의 수정은 몇 가지 빠른 확인에서 나옵니다. 다른 것을 바꾸기 전에 다음을 실행하세요.
DNS가 명확히 올바른 뒤에 SSL을 확인하세요. 많은 플랫폼은 도메인이 일관되게 올바른 대상에 해석된 다음에만 인증서를 발급합니다. 너무 일찍 확인하면 정상적인 지연을 실제 오류로 오해할 수 있습니다.
Koder.ai에 배포된 앱에 맞춤 도메인을 추가하는 경우 앱의 도메인 설정 화면을 기대 대상의 출처로 삼고, 권한 있는 제공자에서 DNS를 정확히 일치시킨 다음 DNS 전파 시간을 주고 SSL 상태를 재확인하세요.
DNS와 SSL 실수를 반복하지 않는 가장 빠른 방법은 각 프로젝트마다 짧은 “도메인 설정 노트”를 유지하는 것입니다. 다음 번 런칭 때 그대로 복사해서 쓸 수 있는 재사용 가능한 런북입니다.
프로젝트 문서에 보관하고 DNS를 건드리기 전에 작성하세요:
런칭 중에는 한 사람을 DNS 소유자로 지정하세요. DNS는 두 사람이 동시에 서로 다른 것을 “수정”할 때 가장 자주 깨집니다(예: 한 사람은 네임서버를 바꾸고 다른 사람은 레코드를 편집하는 경우).
호스팅 측에서는 안전한 되돌리기를 계획하세요. 플랫폼이 스냅샷이나 롤백을 지원하면 라우팅을 변경하기 전에 스냅샷을 찍어 빠르게 마지막 정상 상태로 복귀할 수 있게 하세요. Koder.ai를 사용하면 Planning Mode로 도메인 단계를 적어 순서대로 적용하고, 변경으로 프로덕션이 깨지면 롤백할 수 있습니다.
DNS가 올바른지 확인했는데도 실패가 계속되면 증거를 갖고 에스컬레이션하세요:
에스컬레이션할 때는 호스트명, 기대 레코드, 현재 리졸버 결과, 타임스탬프를 함께 제공하세요. 이렇게 하면 느린 질문‑응답을 빠른 수정으로 바꿀 수 있습니다.
대개 체인 중 한 층에서 문제가 발생한 경우입니다: DNS가 응답하지 않거나, DNS가 잘못된 대상에 가리키거나, 서버/호스트가 해당 호스트명을 인식하지 못하거나, HTTPS/SSL 발급이 아직 완료되지 않은 경우입니다. 먼저 화면에 보이는 정확한 오류와 입력한 정확한 호스트명(루트 도메인인지 또는 www인지)을 적어보세요.
example.com(루트 도메인)과 www.example.com은 별개의 호스트명이므로 각각 다른 DNS 레코드를 가집니다. www에 올바른 CNAME이 설정되어 있어도 루트 도메인에 A 레코드가 없거나 잘못되어 있거나 DNS 제공자가 지원하지 않는 설정인 경우 루트 도메인이 실패할 수 있습니다.
레지스트라에서 도메인의 네임서버를 확인하고, 당신이 편집 중인 DNS 제공자와 비교하세요. 활성 네임서버에 기재된 제공자만 권한 있는 호스트(Authoritative)입니다. 다른 곳에서 레코드를 편집해도 공개 인터넷에 반영되지 않습니다.
호스트가 IPv4 주소를 제공하면 A 레코드를 사용하세요. IPv6 주소를 제공할 때만 AAAA 레코드를 사용합니다. 호스트가 다른 호스트명(예: 배포용 엔드포인트)을 제공하면 CNAME을 사용합니다(주로 www에 사용). TXT 레코드는 검증 및 챌린지용이며, 호스트가 지정한 정확한 이름에 만들어야 합니다.
오래되었거나 잘못된 AAAA 레코드는 일부 방문자를 IPv6로 잘못된 서버에 보내고, 다른 방문자는 올바른 IPv4로 가게 하여 “나한테는 된다”라는 혼란을 만듭니다. 호스트가 IPv6 대상을 제공하지 않았다면 잘못된 AAAA 레코드를 제거하는 것이 간단한 해결책인 경우가 많습니다.
대부분 호스트 측에서 하나의 호스트명만 구성했거나(예: 오직 루트만 또는 오직 www만), 서로 충돌하는 리디렉트 규칙이 있어 HTTP와 HTTPS 또는 루트와 www 사이를 왕복하게 되기 때문입니다. 하나의 정규화된 호스트명을 선택하고 두 호스트명을 모두 구성한 다음 단일하고 깔끔한 리디렉트 경로만 남기세요.
네. DNS가 여러 곳에서 일관되게 올바르게 해석될 때까지 기다리는 것이 맞는 경우가 많습니다. SSL 발급은 도메인이 일관되게 예상 대상에 해석될 때까지 완료되지 않는 경우가 흔합니다. DNS를 자주 뒤집어 바꾸면 발급 과정이 계속 초기화될 수 있으니 주의하세요.
TTL은 응답을 캐시하는 기간입니다. 레코드를 고친 뒤에도 일부 네트워크는 TTL이 만료될 때까지 오래된 값을 제공할 수 있습니다. 두 네트워크(예: Wi‑Fi와 모바일 데이터)에서 테스트하고, 몇 분마다 레코드를 계속 바꾸지 마세요.
예상 대상과 실제 응답을 비교하는 반복 가능한 검사법을 사용하세요. dig나 nslookup으로 A/AAAA/CNAME/TXT 응답이 기대값과 일치하는지 확인하고, apex와 www에 대해 http://와 https://를 모두 테스트하세요. 한 네트워크만 다른 DNS 답을 보이면 캐싱 문제로 보세요. 모든 네트워크가 잘못된 값을 보이면 설정 오류로 봐야 합니다.
Koder.ai에서는 앱의 도메인 설정 화면을 기대 대상의 출처로 삼고, 권한 있는 DNS 제공자에서 그 값과 정확히 일치하도록 DNS를 설정하세요. DNS를 변경한 뒤에는 SSL을 다시 확인하기 전에 안정화될 시간을 주고, 라이브 프로젝트의 라우팅을 조정할 때는 스냅샷/롤백 기능을 사용해 문제가 생기면 빠르게 되돌릴 수 있도록 하세요.