한국어
인증 커스텀 도메인이란 무엇이며, 왜 여러 도메인이 중요한가요?
인증 커스텀 도메인과 다중 도메인이 전환율, 보안, 브랜드 향상을 돕는 방법과 Logto가 DNS 문제 없이 이를 관리하도록 도와주는 방식을 알아보세요.
Ran
Product & Design
Product & Design
인증 커스텀 도메인과 다중 도메인이 전환율, 보안, 브랜드 향상을 돕는 방법과 Logto가 DNS 문제 없이 이를 관리하도록 도와주는 방식을 알아보세요.
제품을 너무 빨리 출시해 본 적이 있다면, 이런 이야기가 익숙할 거예요.
당신의 앱은 example.com 에서 평화롭게 있습니다. 마케팅 캠페인은 잘 돌아가고, 사용자들은 회원가입을 하고, 모든 것이 깔끔해 보입니다. 그러던 어느 날 새로운 사용자가 로그인 버튼을 클릭합니다.
익숙한 URL, 예를 들어 auth.example.com 대신, 브라우저는 마치 테스트 환경 같은 주소로 이동합니다: my-tenant-123.app.logto
기술적으로는 아무 문제 없습니다. 페이지는 안전하고, 로그인도 잘 동작합니다.
하지만 사용자의 첫 반응은 이렇죠:
“잠깐, 지금 어디로 이동된 거지?”
딱 1초간의 의심, 바로 이때 이탈이 발생합니다.
대부분의 대기업이 다음과 같은 도메인을 쓰는 데는 이유가 있습니다:
login.company.comauth.company.comaccounts.company.com이들은 재미로 이러는 것이 아닙니다. 로그인 도메인은 제품 경험의 일부이기 때문이죠.
이번 글에서는 아래 내용을 다룹니다:
간단하게 설명하겠습니다.
모든 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.comauth.us.example.com실제 인증 용도로도 이게 바람직합니다:
example.com)은 보통 메인 사이트로 예약되어 있습니다.domains.logto.app 으로 CNAME을 필요로 합니다.A, MX, TXT 등 포함)를 제어해야 하고, 멀티 테넌트 SaaS 구조에서는 현실적이지 않습니다.Apex-flattening 레코드(ALIAS/ANAME)은 결국 우리가 소유하지 않은 IP로 해석되기에, Logto의 인증서 관리에 사용할 수 없습니다. 즉, 호스팅되는 로그인 페이지는 반드시 서브도메인에 있어야 합니다. 해당 서브도메인을 CNAME으로 Logto에 연결하면, 도메인 인증, SSL 발급 및 갱신, 가용성까지 Logto가 자동으로 처리합니다 — 루트 도메인은 메인 사이트 서비스용으로 계속 쓸 수 있습니다.
아주 흔한 오해:
“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 하나 추가하면 끝이다” 만 생각하면 다른 부분이 반드시 망가집니다.
아래처럼 사용자의 브라우저가 시작된다고 상상해보세요:
브라우저 주소창
https://example.com 에서 로그인 을 클릭합니다.https://auth.example.com/sign-in 으로 리디렉션됩니다.인가 서버 & discovery 문서
https://auth.example.com/oidc/.well-known/openid-configuration리다이렉트 URI (OIDC/OAuth 콜백)
https://app.example.com/callback 같은 곳으로 리디렉션합니다.소셜 로그인/엔터프라이즈 SSO 단계
auth.example.com 에서 사용자가 Google, Microsoft Entra ID, Okta 등으로 이동할 수도 있습니다.이메일의 매직링크·비밀번호 재설정 링크
각 단계마다 도메인이 정말 중요합니다. 커스텀 로그인 도메인을 도입한다면, 전체 체인에 걸쳐 일관되게 전달되도록 해야 합니다.
즉, 유의미한 커스텀 도메인 설계란, DNS 트릭이 아니라, 일관성 있는 아이덴티티 설계라는 뜻이죠.
많은 팀에게는 auth.example.com 과 같은 단일 커스텀 도메인이 충분할 수 있습니다. 하지만 제품, 지역, 고객군이 성장하다보면 미리 구조를 준비하지 않으면 점점 한계를 느끼게 됩니다.
아래는 여러 팀이 인증 경험에 도메인을 매핑하는 방식 예시입니다:
| 시나리오 | 예시 도메인 | 효과 |
|---|---|---|
| 단일 브랜드 로그인 | auth.example.com, account.example.com | 브랜드 도메인 유지, 기본 {{tenant-id}}.app.logto 는 테스트에 계속 사용 가능. |
| 지역별 경험 | auth.us.example.com, auth.eu.example.com, auth.apac.example.com | 한 테넌트 내에서 지역별 콘텐츠/동의 플로우/컴플라이언스 고지 현지화. |
| 환경별 분리 | auth.staging.example.com, auth.example.com | QA, 미리보기 트래픽 분리 가능, 테넌트·커넥터 복제 없이 가능. |
| 조직별 화이트라벨 로그인 | auth.customer-a.com, auth.customer-b.com | 기업 고객에게 전용 로그인 도메인 제공, 사용자·조직·SSO 통합 관리. |
| 브랜드·제품군별 | auth.shop.example.com, auth.app.example.com, auth.studio.example.com | 각 브랜드·제품에 맞는 로그인 경험 제공, 아이덴티티 인프라 분산 없이 운영. |
| 다중 TLD | auth.foo.com, auth.foo.co.uk, auth.foo.dev | 국가별/목적별 사이트 지원, 영역별 설정 복제 없이 운영. |
| 인프라/라우팅 중심 | auth.edge.example.com, auth.api.example.com | CDN/에지 라우팅 등과 정렬, Logto가 여러 호스트 뒤에서 ID 관리 백엔드로 존재. |
Logto는 아래와 같은 기능을 바로 제공합니다. 이제 DNS나 PKI 전문가가 될 필요 없습니다.
auth.example.com 추가해도 기본 {{tenant-id}}.app.logto 는 유지. 내부툴, 점진적 롤아웃용으로 활용하면서 실제 사용자는 브랜드 도메인에 진입.endpoint 를 자동 지정하며, 소셜/엔터프라이즈 SSO 커넥터는 각 도메인에 해당하는 유효한 redirect URI, ACS URL 목록을 자동 제공 — 직접 URL 관리 필요 없음.여기까지 읽었다면 아래 두 부류 중 하나일 가능성이 높습니다.
여러 커스텀 도메인을 당장 테스트할 수 있습니다:
endpoint 값을 업데이트합니다.이렇게 로그인 환경을 정돈하고, 신뢰와 전환에 미치는 효과를 곧장 테스트할 수 있습니다.
지금 막 시작하려 한다면:
auth.example.com 을 대외용 로그인 도메인으로 설정하세요.{{tenant-id}}.app.logto 도메인도 계속 활용할 수 있습니다.이렇게 하면 “테스트 환경 같은 로그인 URL” 문제를 완전히 피할 수 있고, 성장기에 도메인 마이그레이션으로 인해 고생할 필요가 없어집니다.
DNS 레코드 추가와 문제해결 등 단계별 가이드가 필요하다면, 공식 문서의 전체 가이드를 참고하세요: Logto Cloud의 커스텀 도메인