화이트 라벨과 커스텀 도메인
verify.didit.me 대신 verify.yourbrand.com에서 인증 플로우를 제공하세요 - 요구 사항, 두 개의 DNS 레코드, 그리고 비용까지 안내합니다.
여러분이 관리하는 서브도메인(verify.yourbrand.com)을 두 개의 CNAME 레코드로 Didit에 연결합니다. 이는 White Label의 일부이며 Customization 쓰기 권한이 필요하고, 계정에서 활성화되어 있어야 합니다. 루트 도메인과 www.는 거부됩니다.
#무엇이 바뀌는가
커스텀 도메인을 사용하면 사용자는 인증 여정 내내 여러분의 도메인에 머무릅니다. Style Editor와 결합하면 플로우에서 Didit이 눈에 띄게 남는 마지막 흔적까지 제거됩니다.

- Branding에는 사용자에게 보이는 로고와 색상이 담겨 있습니다.
- Domain은 검증된 커스텀 도메인이 verify.didit.me를 대체하는 곳입니다.
- Save changes를 누르기 전까지는 아무것도 적용되지 않으며, 워크플로우에서도 화이트 라벨을 켜야 합니다.
#요구 사항
| 요구 사항 | 세부 내용 |
|---|---|
| 서브도메인만 가능 | verify.yourbrand.com. yourbrand.com 같은 루트 도메인은 거부되며 www. 접두사도 마찬가지입니다 |
| 아직 사용 중이 아닐 것 | 해당 서브도메인이 이미 여러분의 다른 사이트나 앱을 가리키고 있으면 안 됩니다 |
| DNS 접근 권한 | DNS 제공업체에서 두 개의 레코드를 생성해야 합니다 |
| 권한 | Customization 쓰기 권한 - 읽기 전용 멤버에게는 해당 섹션이 비활성화되어 보입니다 |
| 계정에서 활성화 | 커스텀 도메인은 White Label의 일부이며 여러분 계정에서 켜져 있어야 합니다 |
| 최소 $250의 잔액 | 도메인을 추가하려면 추가하는 시점에 잔액에 250 USD의 크레딧이 있어야 합니다. 이는 일회성 관문이지 예치금이 아닙니다. 도메인이 확인되면 이후 잔액이 $250 아래로 떨어져도 계속 활성 상태입니다 |
#작동 방식
콘솔에 서브도메인을 입력하면 Didit이 추가해야 할 두 개의 DNS 레코드를 생성해 줍니다.
| 레코드 | 목적 |
|---|---|
| Verification CNAME | 도메인 소유권을 증명하며, 이를 통해 SSL 인증서가 발급됩니다 |
| CloudFront CNAME | 서브도메인을 인증 UI로 연결합니다 |
두 레코드 모두 필요합니다. 레코드가 정상적으로 해석되면 콘솔에서 소유권을 검증하고, 이후 플로우는 여러분의 도메인에서 제공되기 시작합니다.
- 도메인 추가하기
Business Console → White Label → Domain에서 서브도메인을 입력하고 Add Domain을 클릭하세요. 콘솔이 필요한 레코드를 생성해 줍니다.
- 두 DNS 레코드 모두 생성하기
표시된 그대로 DNS 제공업체에 레코드를 추가하세요. 일부만 설정하면 인증서가 발급되지 않아 도메인을 사용할 수 없습니다.
- 소유권 검증하기
레코드가 정상적으로 해석되면 콘솔에서 검증하세요. DNS 전파가 가장 오래 걸리는 부분이며, 전적으로 여러분의 제공업체 쪽 사정입니다.
검증이 완료되지 않는다면 원인은 거의 항상 DNS입니다. 잘못된 레벨에 추가된 레코드(존 이름을 자동으로 덧붙이는 제공업체 때문에 verify.yourbrand.com.yourbrand.com이 만들어지는 경우), 레코드 앞단의 프록시나 CDN이 이를 다시 쓰는 경우, 또는 단순히 전파가 아직 끝나지 않은 경우입니다. 문제를 보고하기 전에 레코드가 실제로 무엇으로 해석되는지 확인하세요.
#비용
사용자 지정 도메인은 화이트라벨의 일부이며, 완료된 검증당 $0.20로 과금됩니다. 화이트라벨 요금 위에 붙는 별도 항목이 아니고, 월정액 플랜도 도메인별 추가 요금도 없습니다. 다만 자체 도메인에서 제공되는 워크플로는 화이트라벨 워크플로이므로 화이트라벨 가격이 적용됩니다. 유일한 다른 요건은 도메인 추가 시 최소 잔액 $250이며, 그 크레딧은 이후 검증에 쓸 수 있는 귀하의 것입니다. 과금 대상 검사를 참고하세요.
#리디렉션 대신 임베드하기
커스텀 도메인은 "URL에 Didit이라고 나온다"는 문제를 해결합니다. 대신 "사용자가 내 앱을 아예 떠나지 않았으면 좋겠다"는 것이 관심사라면 답은 다릅니다. 플로우를 임베드하세요. 여러분 자신의 프런트엔드 안에 인증을 렌더링하는 웹 SDK와 in-context 옵션이 있고, 모바일에는 네이티브 SDK가 있습니다. 연동 방법을 참고하세요.
이 중 어떤 것이 여러분의 플랜에서 이용 가능한지는 가정하지 말고, 특히 이를 중심으로 프로젝트 범위를 정하고 있다면 Didit 담당자에게 확인해 볼 가치가 있습니다.
#리셀러와 멀티 브랜드 구성
자체 고객 여러 곳을 대신해 검증을 실행하고 각각 고유한 브랜딩을 원한다면, 이는 한 회사 한 브랜드와는 다른 형태입니다. Didit이 지원하는 구조는 조직 내 최종 고객별 하나의 애플리케이션이며, 각각 자체 워크플로와 브랜딩을 갖고 그에 따르는 리셀러 조건이 적용됩니다. 구축 전에 조직, 애플리케이션 및 환경을 참고하세요. 멀티 브랜드 구조를 나중에 고치는 것은 처음부터 그렇게 시작하는 것보다 훨씬 더 많은 작업입니다.
#관련 자료
- 브랜딩과 인증 경험 커스터마이징
- 전체 참고 자료: Custom domain
