웹앱을 위한 커스텀 도메인 설정 가이드: 명확한 DNS 레코드 단계, SSL 발급 순서, 리디렉트 규칙과 다운타임 없이 안전하게 전환하는 컷오버 계획을 제공합니다.
커스텀 도메인은 단순히 보기 좋은 URL 이상입니다. 플랫폼 하위 도메인(예: Koder.ai의 플랫폼 서브도메인 아래에 있는 앱)에서 자체 도메인으로 이동하는 순간, 브라우저와 네트워크는 이를 다른 사이트로 취급합니다. 이는 라우팅, 보안, 사용자 세션 동작에 영향을 줍니다.
커스텀 도메인으로 전환하면 즉시 바뀌는 것들:
www에 들어오게 할지 루트 도메인(apex)에 들어오게 할지 결정하고, HTTP에서 HTTPS로의 규칙을 일관되게 설정해야 합니다.old-platform.example에 설정된 로그인 쿠키는 자동으로 app.yourdomain.com에서 작동하지 않습니다.짧은 다운타임은 보통 타이밍 때문에 발생합니다. DNS가 새 호스트로 트래픽을 보내기 시작했는데 SSL 인증서가 준비되지 않아 브라우저 경고가 뜨거나, 반대로 SSL은 준비됐지만 많은 사용자가 DNS 캐시 때문에 여전히 이전 위치로 가는 상황이 생깁니다.
리디렉트는 로그인에 미묘한 문제를 일으킬 수 있습니다. 호스트명을 변경하는 리디렉트(apex → www 또는 그 반대)는 다른 호스트용으로 설정된 쿠키를 잃게 만들 수 있습니다. 인증 제공자는 콜백 URL이 여전히 이전 도메인으로 설정되어 있으면 실패할 수 있습니다.
저위험 컷오버란 중복을 계획하는 것입니다: 이전 URL을 계속 살려두고, 새 도메인을 병렬로 준비한 다음 예측 가능한 순간에 트래픽을 전환하며, 롤백은 DNS만 되돌리면 간단하게 되도록 합니다.
무언가를 변경하기 전에, 사용자가 입력할 정확한 이름과 조용히 리디렉트할 이름을 적어두세요. 많은 “왜 절반만 작동하지?” 문제는 팀이 하나의 진짜 호스트명을 합의하지 않았기 때문에 생깁니다.
먼저 큰 선택을 하세요: 루트 도메인(예: example.com, 흔히 “apex”라 부릅니다) 또는 www(예: www.example.com) 중 어느 쪽을 기본으로 할지 결정하세요. 둘 다 동작하지만 하나를 선택하고 다른 하나는 리디렉트로 처리하세요. 이 결정은 쿠키에도 영향을 줍니다: 앱이 한 일관된 호스트에서 운영될 때 세션 관리가 가장 쉽습니다.
다음으로 현재 필요한 서브도메인과 나중에 추가할 수 있는 것을 결정하세요. 일반적인 패턴은 웹앱용 app.example.com, API용 api.example.com, 이후에 admin.example.com이나 assets.example.com 등을 추가하는 것입니다. Koder.ai 같은 플랫폼에서 커스텀 도메인을 설정하면 이러한 선택은 SSL 검증 대상과 DNS에서 가리킬 항목에 그대로 반영됩니다.
많은 사람이 등록기관에서 도메인을 구매하지만 DNS는 다른 곳에서 호스팅되는 경우가 많습니다. 오늘 레코드를 어디에서 편집하는지, 누가 접근 권한이 있는지, 변경을 자동화하는 시스템이 있는지(회사 IT, 에이전시, 관리형 DNS 제공자 등) 확인하세요. 현재 레코드를 로그인해 볼 수 없다면 먼저 그 문제를 해결하세요.
또한 도메인을 이미 무엇이 사용하는지 감사하세요. 이메일은 고전적인 함정입니다: 레코드를 삭제하거나 덮어쓰면 메일 전달이 중단될 수 있습니다.
진행하기 전에 다음 결정을 문서화하세요:
www)과 리디렉트 방향마케팅팀이 이미 example.com에서 이메일을 운영하고 있다면, 앱에 필요한 항목만 추가하면서 메일 관련 레코드는 건드리지 마세요.
커스텀 도메인 이동에서 위험의 대부분은 앱 자체가 아니라 잘못된 DNS 변경 한 건입니다. 트래픽을 아무 곳으로도 보내지 않거나, 이메일을 깨뜨리거나, SSL 검증을 실패하게 만들 수 있습니다.
A 레코드는 이름을 IP 주소로 가리킵니다. 쉽게 말해: “사용자를 이 서버로 보내라.” 제공자가 고정 IP를 줄 때 루트 도메인(apex)에 자주 사용됩니다.
CNAME 레코드는 하나의 이름을 다른 이름으로 가리킵니다. 쉽게 말해: “이 이름을 저 호스트의 별칭으로 취급하라.” 플랫폼 호스트명을 가리킬 때 www.example.com에 자주 씁니다.
많은 DNS 제공자는 루트에 대해 ALIAS/ANAME을 제공합니다. 이는 CNAME처럼 동작하지만 example.com에서 쓸 수 있습니다. 제공자가 지원하면 대상이 바뀌어도 IP를 직접 건드리지 않아 편리합니다.
간단한 사고 모델:
플랫폼 소유권 확인(검증)과 SSL 인증서 검증(일부 CA가 TXT 토큰으로 검증)을 위해 TXT 레코드를 추가하는 경우가 많습니다. TXT는 또한 SPF 같은 이메일 정책에 쓰입니다. 기존 SPF TXT를 실수로 삭제하거나 교체하면 메일 전달이 깨질 수 있습니다.
TTL은 다른 시스템이 DNS 응답을 얼마 동안 캐시할지 제어합니다. 컷오버 하루 전에 변경할 레코드의 TTL을 낮추세요(보통 300~600초). 모든 게 안정되면 다시 높여 쿼리 부하를 줄입니다.
편집 전에 현재 존(zone)을 내보내거나 스크린샷을 찍으세요. 변경할 각 레코드의 이전 값, 새 값, TTL을 적어두세요. 문제가 생기면 롤백은 이전 값을 복원하는 것입니다.
이것은 도메인에 이미 MX, DKIM 같은 이메일 레코드가 있을 때 특히 중요합니다.
SSL(자물쇠 아이콘)은 브라우저와 앱 사이 트래픽을 암호화합니다. 현대 브라우저와 많은 API는 기본적으로 HTTPS를 기대합니다. HTTPS가 없으면 경고, 차단된 요청, 서비스 워커·지리정보·일부 결제 흐름 같은 기능이 작동을 멈출 수 있습니다.
인증서를 발급하려면 인증 기관이 도메인 소유를 확인해야 합니다. 일반적인 검증 방법은 HTTP 검증과 DNS TXT 검증입니다:
DNS 검증은 CDN을 쓰거나 앱이 새 도메인에서 아직 접근 불가능할 때 더 쉽습니다.
인증서가 어디서 발급되는지는 설정에 따라 다릅니다. 어떤 팀은 호스팅 스택에서 직접 발급하고, 어떤 팀은 CDN에서, 또 어떤 플랫폼은 커스텀 도메인을 지원하면서 인증서를 대신 관리해 줍니다(예: Koder.ai는 도메인 설정 중에 인증서를 관리할 수 있음). 중요한 건 누가 인증서 수명주기(갱신 포함)를 책임지는지 아는 것입니다.
인증서 발급이 항상 즉시 끝나지는 않습니다. DNS 전파, 검증 확인, 요청 제한 때문에 지연될 수 있습니다. 재시도를 계획하고 컷오버를 가능한 마지막 순간에 잡지 마세요.
실용적인 타이밍 계획:
인증서는 사용자가 접속할 모든 호스트네임을 포함해야 합니다. SAN(Subject Alternative Names) 목록을 확인하세요. 앱이 example.com과 www.example.com 둘 다에서 서비스될 예정이면 인증서는 둘 모두를 포함해야 합니다.
와일드카드(*.example.com)는 많은 서브도메인에 유용하지만 루트 도메인(example.com)은 포함하지 않습니다.
구체적 예: www.example.com만 인증서에 포함했다면 사용자가 example.com을 입력했을 때 경고가 뜹니다. 그런 경우엔 리디렉트 레이어가 이미 example.com에 대한 유효한 인증서를 가지고 있어야 합니다.
리디렉트는 간단해 보이지만 대부분의 도메인 문제는 여기서 발생합니다: 루프, 혼합 콘텐츠, 호스트를 왔다 갔다 하며 로그아웃되는 사용자 등.
하나의 정규화된 호스트를 선택하고 지키세요: www.example.com 또는 example.com(apex). 다른 진입점은 선택한 기본 호스트로 리디렉트해 쿠키·세션·SEO 신호가 일관되게 유지되도록 합니다.
안전한 기본값:
http:// → https://로의 301 리디렉트HTTP → HTTPS의 경우 사용자를 왔다 갔다 시키지 않도록 하세요. 루프를 방지하는 가장 쉬운 방법은 실제 요청이 어떤 것이었는지를 기반으로 판단하는 것입니다. 앱이 프록시나 CDN 뒤에 있다면 전달된 헤더(forwarded headers)를 존중하도록 구성하세요(예: 원래 스킴이 HTTP였음을 알려주는 헤더). 그렇지 않으면 앱이 모든 요청을 HTTP로 인식해 계속 리디렉트할 수 있습니다.
이동 중에는 이전 경로를 유지하세요. 경로를 변경하는 경우(/login을 /sign-in으로 바꾸는 등) 해당 경로에 대한 명시적 리디렉트를 추가하세요. 단순히 모든 것을 홈페이지로 리디렉트하면 북마크와 공유된 링크가 깨집니다.
처음에는 HSTS를 바로 적용하지 마세요. 너무 일찍 적용하면 나중에 검증이나 문제 해결을 위해 HTTP를 제공해야 할 때 브라우저가 요청을 거부할 수 있습니다. HTTPS가 안정되고 서브도메인 적용 범위를 확인한 후에 활성화하세요.
모두에게 영향을 주지 않고 리디렉트를 테스트하려면 임시 테스트 호스트네임을 사용하고 일부 실제 딥링크(인증 페이지 포함)를 시도해 보세요. 또한 각 리디렉트 단계와 최종 목적지를 보여주는 커맨드라인 요청을 실행해 확인하세요.
안전한 컷오버는 대부분 타이밍의 문제입니다. 새 도메인이 준비되고 테스트되어 있어야 실제 트래픽이 가기 전에 문제가 발견될 수 있으며, DNS 변경이 빨리 퍼져서 사고 시 기다리지 않도록 해야 합니다.
변경할 레코드의 DNS TTL을 미리 낮추세요. 가능하다면 하루 전에 하고, 이전 TTL 기간이 만료될 시간을 기다려 낮춘 값이 캐시에 반영되도록 합니다.
다음으로 호스트/제공자에 커스텀 도메인을 추가하고 필요한 검증 절차를 완료하세요. Koder.ai 같은 플랫폼을 사용한다면 먼저 도메인을 추가해 플랫폼이 소유권을 확인하고 라우팅을 준비하도록 합니다.
SSL을 미리 발급하세요. 인증서는 검증 방식에 따라 몇 분 이상 걸릴 수 있으므로 전환 중 지연이 생기지 않도록 합니다.
도메인을 공개하기 전에 개인 테스트를 하세요: 공개 DNS에 의존하지 않는 방법(예: 로컬 호스트 파일에 임시 항목 추가)으로 새 엔드포인트에 접속해 HTTPS와 올바른 인증서로 사이트가 로드되는지 확인합니다.
이상 징후가 있으면 즉시 중단할 수 있도록 단계별 접근을 사용하세요:
DNS 수준에서 진정한 카나리(소규모 테스트)를 못 하더라도 한 호스트네임(예: www)만 먼저 전환하고 루트를 남겨두는 방식으로 단계화할 수 있습니다.
무엇을 되돌릴지(어떤 레코드, 어떤 값) 정확히 적어두고 누가 실행할지 정하세요. 롤백은 보통 DNS를 이전 상태로 되돌리는 것입니다.
이전 구성(이전 도메인의 SSL 포함)이 여전히 유효한지 확인해 사용자가 깔끔하게 이전 상태로 돌아갈 수 있게 하세요.
도메인 변경은 단순한 DNS 변경만이 아닙니다. 많은 앱에서 “로그인 상태”는 브라우저가 특정 호스트네임에 묶는 쿠키에 달려 있습니다. 호스트명이 바뀌면 브라우저가 이전 쿠키를 보내지 않아 앱이 모든 사용자를 로그아웃된 것으로 볼 수 있습니다.
쿠키 설정이 주된 원인입니다:
app.old.com에 설정된 쿠키는 app.new.com으로 전송되지 않습니다. .example.com으로 설정된 쿠키는 app.example.com과 www.example.com에서 모두 작동할 수 있습니다./api처럼 너무 좁으면 웹 UI가 쿠키를 보지 못할 수 있습니다.Lax가 보통 무난하지만 일부 SSO나 결제 리디렉트는 None과 Secure가 필요할 수 있습니다.위험을 줄이려면 양쪽 도메인이 모두 작동하는 짧은 전환 기간을 계획하세요. 이전 호스트네임을 계속 응답하도록 두고 신중하게 리디렉트하되, 세션이 새 도메인에서 갱신될 수 있도록 하세요. 가능하다면 공용 세션 저장소를 사용해 어느 쪽 호스트에 접속하든 사용자를 인식하게 하세요.
SSO나 OAuth를 사용한다면 컷오버 전에 콜백 URL, 허용 출처, 허용된 리디렉트 URI 등을 업데이트하세요. 그렇지 않으면 인증 제공자에서는 로그인에 성공하지만 앱으로 돌아올 때 실패할 수 있습니다.
먼저 깨지기 쉬운 흐름을 테스트하세요: 회원가입(이메일 확인 포함), 로그인/로그아웃, 비밀번호 재설정, 결제 리턴, 멀티탭 세션 등.
예: www.example.com을 example.com으로 리디렉트한다면 쿠키를 .example.com으로 설정하거나 단일 호스트를 일관되게 사용해 사용자가 호스트를 왔다 갔다 하며 세션을 잃지 않도록 하세요.
대부분의 도메인 문제는 “수수께끼 같은 인터넷 문제”가 아닙니다. DNS, 인증서, 리디렉트 규칙 사이의 작은 불일치가 실제 사용자 접속 후에야 드러날 뿐입니다.
쉽게 빠지는 함정 중 하나는 루트 도메인(apex)입니다. 많은 DNS 제공자가 루트에 진짜 CNAME을 허용하지 않습니다. 루트에 CNAME을 억지로 지정하면 조용히 실패하거나 일부 네트워크에서만 문제가 생기거나 일관성 없이 해석될 수 있습니다. DNS 호스트가 지원하는 방식(A/AAAA 또는 ALIAS/ANAME 스타일 레코드)을 사용하세요.
또 다른 빈번한 다운타임 원인은 SSL이 새 엔드포인트에서 준비되기 전에 DNS를 전환하는 것입니다. 사용자가 도착했을 때 앱은 로드되지만 인증서가 없거나 일부 호스트네임만 커버하면 브라우저가 차단합니다. 실무적으로는 example.com과 www.example.com 둘 다를 인증서로 커버해 두는 것이 좋습니다. 리디렉트로 하나만 남겨둘 계획이라도 마찬가지입니다.
일반적인 실수:
www → apex, 이어서 apex → www) 또는 한 곳은 HTTP를 강제하고 다른 곳은 HTTPS를 강제함http://를 남겨 혼합 콘텐츠가 발생하고 브라우저 경고나 기능 고장 유발간단한 정상 확인: 두 호스트(www와 apex)를 HTTPS로 열고 로그인한 뒤 새로고침해 주소 표시줄이 절대 HTTP로 돌아가지 않는지 확인하세요.
플랫폼에서 작업한다면(예: Koder.ai) 커스텀 도메인이 연결되고 SSL이 발급되었는지 확인한 다음 운영 DNS를 건드리세요. 롤백 옵션을 준비해 두면 잘못된 리디렉트나 레코드 변경이 오래 지속되는 것을 막을 수 있습니다.
차분한 컷오버는 대부분 준비 작업입니다. 목표는 단순합니다: 사용자가 계속 로그인하고, 쿠키가 작동하며, 문제가 보이면 빠르게 롤백할 수 있어야 합니다.
트래픽이 아직 이전 도메인으로 가고 있을 때 이 작업을 하세요. 가능하면 하루를 두어 DNS 변경이 정착할 시간을 주세요.
www, api 등)을 문서화하고 SSL 검증 방법(DNS 또는 HTTP)을 결정하세요.www → apex(또는 반대), 하나의 정규 호스트.DNS를 전환하면 첫 한 시간을 사고 훈련처럼 대하세요. 상태 대시보드뿐 아니라 실제 사용자 흐름을 관찰하세요.
Koder.ai(또는 다른 플랫폼)가 커스텀 도메인과 SSL을 처리해 준다 해도 이 체크리스트는 중요합니다. 대부분의 문제는 앱 코드가 아니라 DNS와 리디렉트에서 옵니다.
앱이 myapp.koder.ai 같은 임시 플랫폼 주소에서 운영되고 있습니다. 작동은 하지만 고객이 example.com을 쓰게 하고 싶고, www.example.com은 apex로 리디렉트하며 모든 것을 HTTPS로 강제하고 싶습니다.
리스크를 낮춘 간단한 DNS 계획은 다음과 같습니다. 아무 것도 변경하기 전에 현재 작동 상태를 기록하세요(플랫폼이 스냅샷을 지원하면 찍어 두세요) 그리고 컷오버 하루 전 TTL을 낮추세요.
기존 플랫폼 URL을 그대로 두면서 새 레코드를 추가하세요:
example.com: 플랫폼이 제공한 호스팅 대상에 대한 A/ALIAS 레코드www.example.com: example.com을 가리키는 CNAME(또는 제공자에 따라 플랫폼 대상 가리키기)myapp.koder.ai는 그대로 유지해 항상 알 수 있는 대체 경로를 가지세요DNS가 설정되면 두 호스트네임(example.com과 www.example.com)에 대해 SSL을 요청하세요. 인증서가 발급되어 활성화될 때까지 트래픽을 전환하지 마세요. 그렇지 않으면 브라우저 경고가 발생합니다.
명확한 체크포인트가 있는 컷오버 타임라인:
example.com 테스트(홈, 정적 자산, API 호출)www → apex)이동 후 쿠키 동작을 검증하세요. 로그인하고 새로고침해 두 호스트에서 로그인 상태가 유지되는지 확인하세요. 세션이 깨지면 보통 쿠키 도메인이나 SameSite 설정이 이전 호스트를 전제로 남아 있기 때문입니다.
컷오버가 성공해도 일이 끝난 건 아닙니다. 대부분의 도메인 문제는 누군가가 사소한 변경을 하거나 인증서 갱신을 깜박이는 등 시간이 지나며 발생합니다.
지속적으로 지킬 작은 모니터링 루틴을 만드세요. 엔터프라이즈 툴이 없어도 괜찮지만 신뢰할 수 있는 몇 가지 신호는 필요합니다: 핵심 페이지(홈, 로그인, 인증된 페이지)의 가용성 체크, 인증서 만료 알림(예: 30일 및 7일 전), 오류율 추적(단순 가동 상태가 아니라 4xx/5xx 급증 관찰), 그리고 가끔씩 리디렉트 검증(HTTP가 HTTPS로 가는지, 선호하는 호스트가 최종 목적지인지).
완전히 자신이 붙으면 DNS TTL을 다시 올리세요. 낮은 TTL은 변경 중에는 유용하지만 장기적으로는 레졸버 부하를 늘리고 작은 실수의 영향을 키웁니다. 보통 팀들은 1~4시간을 표준 TTL로 선택합니다.
마지막으로 최종 상태를 문서화하세요: 존재하는 레코드(type, name, value, TTL), 지원하는 호스트네임, 정확한 리디렉트 규칙, 인증서가 발급되는 위치와 커버 범위(apex, www, 서브도메인), 그리고 누가 갱신을 담당하는지 적어 두세요.
플랫폼에서 빌드·배포하는 경우 도메인을 1급 기능으로 취급하고 스냅샷·롤백이 간단하면 향후 도메인과 리디렉트 변경을 되돌려야 할 때 스트레스가 줄어듭니다. Koder.ai에서는 커스텀 도메인이 스냅샷 및 롤백과 함께 존재해 추후 변경을 빠르게 되돌릴 수 있습니다.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.