인증 커스텀 도메인이란 무엇이며, 왜 여러 도메인이 중요한가요?

제품을 너무 빨리 출시해 본 적이 있다면, 이런 이야기가 익숙할 거예요.

당신의 앱은 example.com 에서 평화롭게 있습니다. 마케팅 캠페인은 잘 돌아가고, 사용자들은 회원가입을 하고, 모든 것이 깔끔해 보입니다. 그러던 어느 날 새로운 사용자가 로그인 버튼을 클릭합니다.

익숙한 URL, 예를 들어 auth.example.com 대신, 브라우저는 마치 테스트 환경 같은 주소로 이동합니다: my-tenant-123.app.logto

기술적으로는 아무 문제 없습니다. 페이지는 안전하고, 로그인도 잘 동작합니다.
하지만 사용자의 첫 반응은 이렇죠:

“잠깐, 지금 어디로 이동된 거지?”

딱 1초간의 의심, 바로 이때 이탈이 발생합니다.

• 전환 관점에서 보면, 로그인·회원가입이 전환 퍼널의 가장 좁은 구간입니다. "이 도메인이 뭐지?"라는 순간이 하나라도 추가되면 마찰이 생깁니다.
• 보안 관점에서, 사용자들은 “URL을 꼭 확인하라” 고 수년 동안 교육받았습니다. 로그인 도메인이 브랜드와 일치하지 않으면, 실제 서비스보다 피싱 사이트처럼 보이게 됩니다.

대부분의 대기업이 다음과 같은 도메인을 쓰는 데는 이유가 있습니다:

• login.company.com
• auth.company.com
• accounts.company.com

이들은 재미로 이러는 것이 아닙니다. 로그인 도메인은 제품 경험의 일부이기 때문이죠.

이번 글에서는 아래 내용을 다룹니다:

• 인증 커스텀 도메인이 실제로 무엇인지
• 하나의 로그인 도메인으로 충분한 경우와 여러 개를 고려해야 할 때
• 로그인 도메인에서 흔히 발생하는 실수(그리고 "redirect URI does not match" 지옥을 피하는 방법)
• Logto의 커스텀 도메인 지원이 DNS 전문가가 되지 않고도 이를 쉽게 가능하게 하는 방식

인증 커스텀 도메인이란?#

간단하게 설명하겠습니다.

모든 Logto 테넌트는 기본 도메인({{tenant-id}}.app.logto)을 제공합니다. 그래서 사용자는 기존에: https://my-tenant-123.app.logto/sign-in 으로 이동했습니다.

인증 커스텀 도메인은 이 보이는 URL을 당신이 소유한 것으로 바꿔줍니다 — 예를 들어 auth.example.com 으로. 이제 사용자는 브랜드에 맞는 주소인: https://auth.example.com/sign-in 을 보게 되죠.

내부의 인증 서비스는 동일하지만, 사용자 경험의 첫인상은 매우 달라집니다.

왜 루트 도메인이 아닌 서브도메인을 쓸까요?#

Logto의 커스텀 도메인은 기본적으로 다음과 같은 서브도메인 용으로 설계되었습니다:

• auth.example.com
• auth.us.example.com

실제 인증 용도로도 이게 바람직합니다:

• 루트 도메인(example.com)은 보통 메인 사이트로 예약되어 있습니다.
• DNS "zone apex"(예: example.com 루트)는 CNAME을 사용할 수 없고, Logto의 호스트된 로그인 페이지는 트래픽 라우팅을 위해 domains.logto.app 으로 CNAME을 필요로 합니다.
• Logto는 Cloudflare를 통해 인증서를 관리합니다. 루트 도메인에서 TLS를 종료하려면 해당 영역 전체(기존 A, MX, TXT 등 포함)를 제어해야 하고, 멀티 테넌트 SaaS 구조에서는 현실적이지 않습니다.

Apex-flattening 레코드(ALIAS/ANAME)은 결국 우리가 소유하지 않은 IP로 해석되기에, Logto의 인증서 관리에 사용할 수 없습니다. 즉, 호스팅되는 로그인 페이지는 반드시 서브도메인에 있어야 합니다. 해당 서브도메인을 CNAME으로 Logto에 연결하면, 도메인 인증, SSL 발급 및 갱신, 가용성까지 Logto가 자동으로 처리합니다 — 루트 도메인은 메인 사이트 서비스용으로 계속 쓸 수 있습니다.

"CNAME 하나 추가하면 끝 아닌가요?"에 대한 진실#

아주 흔한 오해:

“DNS에 CNAME만 추가하면 끝 아닌가요?”

안타깝게도, 그렇지 않습니다.

보이는 로그인 도메인을 바꾸는 것은 이야기의 일부일 뿐입니다. 커스텀 인증 도메인을 도입하는 순간, 여러가지를 건드리게 됩니다:

• 로그인·회원가입 페이지 URL
  사용자가 이제 https://auth.example.com/... 에 방문합니다.

• OIDC / OAuth 리다이렉트 URI
  앱 및 커넥터의 리다이렉트/콜백 URL에서도 동일한 도메인을 반드시 사용해야 하며, 그렇지 않으면 redirect_uri_mismatch 오류가 발생합니다.

• 소셜 로그인 & 엔터프라이즈 SSO (IdP)
  구글, GitHub, Azure AD, Okta 등도 리다이렉트 URI 또는 ACS URL의 도메인을 검사합니다.

• 패스키 (WebAuthn)
  패스키는 등록된 정확한 도메인에 묶이기 때문에, 도메인을 변경하면 해당 패스키가 더 이상 동작하지 않습니다.

• SDK 설정
  Logto SDK에서 endpoint 는 테넌트 도메인을 가리켜야 합니다. 잘못된 도메인을 사용하면 앱과 인증 계층이 불일치하게 됩니다.

DNS 설정이 필요하냐고요? 당연히 필요하죠.
하지만 “CNAME 하나 추가하면 끝이다” 만 생각하면 다른 부분이 반드시 망가집니다.

빠른 사고 모델: 로그인 도메인이 스택을 따라 흐르는 방식#

아래처럼 사용자의 브라우저가 시작된다고 상상해보세요:

1. 브라우저 주소창

   • 사용자가 https://example.com 에서 로그인 을 클릭합니다.
   • https://auth.example.com/sign-in 으로 리디렉션됩니다.

2. 인가 서버 & discovery 문서

   • 앱에서는 OpenID 설정 엔드포인트를 사용합니다:
     https://auth.example.com/oidc/.well-known/openid-configuration
   • 이 정보가 앱에 요청 보낼 주소와 토큰 회수 주소를 알려줍니다.

3. 리다이렉트 URI (OIDC/OAuth 콜백)

   • 사용자가 로그인하면, Logto가 https://app.example.com/callback 같은 곳으로 리디렉션합니다.
   • IdP와 앱 양측에서 이 URL에 대해 일치해야 합니다.

4. 소셜 로그인/엔터프라이즈 SSO 단계

   • auth.example.com 에서 사용자가 Google, Microsoft Entra ID, Okta 등으로 이동할 수도 있습니다.
   • 이 제공사들 또한 커스텀 인증 도메인이 포함된 리다이렉트 URI를 검사합니다.

5. 이메일의 매직링크·비밀번호 재설정 링크

   • 이메일의 링크도 사용자 혼란을 줄이기 위해 커스텀 도메인으로 일관되게 제공되어야 합니다.

각 단계마다 도메인이 정말 중요합니다. 커스텀 로그인 도메인을 도입한다면, 전체 체인에 걸쳐 일관되게 전달되도록 해야 합니다.

즉, 유의미한 커스텀 도메인 설계란, DNS 트릭이 아니라, 일관성 있는 아이덴티티 설계라는 뜻이죠.

단일 vs. 다중 커스텀 도메인#

많은 팀에게는 auth.example.com 과 같은 단일 커스텀 도메인이 충분할 수 있습니다. 하지만 제품, 지역, 고객군이 성장하다보면 미리 구조를 준비하지 않으면 점점 한계를 느끼게 됩니다.

아래는 여러 팀이 인증 경험에 도메인을 매핑하는 방식 예시입니다:

Logto가 커스텀 도메인을 쉽게 만들어주는 방식#

Logto는 아래와 같은 기능을 바로 제공합니다. 이제 DNS나 PKI 전문가가 될 필요 없습니다.

• 하나의 테넌트, 여러 도메인 지원. 지역, 환경, 고객, 브랜드별로 로그인 도메인 개별 할당, 테넌트 복제 없이 가능. 플랜별 제한은 있겠지만, 핵심은 하나의 아이덴티티 백본과 여러 진입점 제공이 가능하단 것.
• 기본 도메인 계속 사용 가능. auth.example.com 추가해도 기본 {{tenant-id}}.app.logto 는 유지. 내부툴, 점진적 롤아웃용으로 활용하면서 실제 사용자는 브랜드 도메인에 진입.
• 커넥터 자동 조정. SDK가 올바른 endpoint 를 자동 지정하며, 소셜/엔터프라이즈 SSO 커넥터는 각 도메인에 해당하는 유효한 redirect URI, ACS URL 목록을 자동 제공 — 직접 URL 관리 필요 없음.
• SSL 자동화. CNAME만 추가하면 Logto가 DNS 인증·인증서 발급·갱신까지 모두 처리. 키 관리 무관, 만료 걱정도 없음.

여기서 어디로?#

여기까지 읽었다면 아래 두 부류 중 하나일 가능성이 높습니다.

이미 Logto를 사용중인가요?#

여러 커스텀 도메인을 당장 테스트할 수 있습니다:

• Console > Settings > Domains 로 이동. 새 지역 론칭이나, 브랜드 로그인 요청이 있는 주요 기업 고객을 위해 두번째 커스텀 도메인 추가 등 시도해보세요.
• 필요한 곳에 SDK의 endpoint 값을 업데이트합니다.
• 소셜/SSO 커넥터에서 제공하는 도메인 기반 redirect URI, ACS URL을 IdP에 등록하세요.

이렇게 로그인 환경을 정돈하고, 신뢰와 전환에 미치는 효과를 곧장 테스트할 수 있습니다.

Logto가 처음이라면?#

지금 막 시작하려 한다면:

• Logto 에 가입하고 테넌트를 만드세요.
• Console > Settings > Domains 이동. 무료 제공되는 커스텀 도메인 할당으로, 첫날부터 auth.example.com 을 대외용 로그인 도메인으로 설정하세요.
• 내부용·테스트용으로는 기본 {{tenant-id}}.app.logto 도메인도 계속 활용할 수 있습니다.

이렇게 하면 “테스트 환경 같은 로그인 URL” 문제를 완전히 피할 수 있고, 성장기에 도메인 마이그레이션으로 인해 고생할 필요가 없어집니다.

DNS 레코드 추가와 문제해결 등 단계별 가이드가 필요하다면, 공식 문서의 전체 가이드를 참고하세요: Logto Cloud의 커스텀 도메인