CSS 테마가 아닌 인프라 수준의 화이트라벨

대부분의 SaaS에서 "화이트라벨"이란 로고를 바꾸고 색상을 조정하는 수준입니다. URL 바에는 여전히 원래 플랫폼 도메인이 보입니다.

크로노젠의 화이트라벨은 다릅니다.

고객은 brand.co.kr을 방문합니다
브라우저 주소창에 cronozen.com은 나타나지 않습니다
인증 쿠키는 해당 도메인에만 존재합니다
SEO는 고객 도메인으로 독립 축적됩니다
GA4 측정 ID도 고객별로 분리됩니다

고객의 사용자는 크로노젠이 뒤에 있다는 것을 알 수 없습니다. Shopify 위에서 운영되는 쇼핑몰처럼, 겉은 브랜드이고 속은 플랫폼입니다.

아키텍처: 3계층 프록시 구조

화이트라벨 도메인은 3개 계층을 거쳐 작동합니다.

1계층: DNS + CloudFlare

고객 도메인의 DNS를 CloudFlare로 향하게 설정합니다.

brand.co.kr → CloudFlare DNS → CloudFlare Worker

CloudFlare는 WAF(웹 방화벽), DDoS 방어, SSL 인증서를 자동 처리합니다. 고객이 별도로 보안을 설정할 필요가 없습니다.

2계층: CloudFlare Worker (프록시)

CloudFlare Worker가 요청을 크로노젠 서버로 전달합니다.

brand.co.kr/dashboard
  → Worker가 rewrite
  → cronozen.com/brand-slug/dashboard

이 과정에서 Worker는 추가 작업도 수행합니다.

GA4 ID 교체: 크로노젠 GA4 → 고객 GA4 측정 ID로 교체
OG 메타 태그 재작성: 공유 시 고객 브랜드로 표시
캐노니컬 URL: brand.co.kr로 설정 (SEO 독립)
noindex 제거: 크로노젠 내부 경로의 noindex를 제거

3계층: 크로노젠 서버 (프록시 코어)

크로노젠 서버의 프록시 미들웨어가 최종 처리합니다.

요청 수신
  → JWT 쿠키에서 인증 정보 추출
  → 도메인으로 센터(테넌트) 식별
  → scoped Prisma 주입 (center_id 자동 필터)
  → API 핸들러 실행
  → 해당 센터 데이터만 응답

12단계 처리 파이프라인을 거치며, 정적 자산 바이패스, 인증 도메인 처리, 라우트 권한 검증, URL rewrite까지 자동으로 이루어집니다.

인증: 호스트 전용 쿠키

화이트라벨에서 가장 까다로운 부분은 인증입니다.

문제

일반적인 SSO 구조에서는 쿠키가 메인 도메인에 설정됩니다. 하지만 화이트라벨에서는 brand.co.kr에 쿠키가 있어야 합니다.

크로노젠의 해결 방식

크로노젠은 중앙 인증 서버(auth.cronozen.com)를 사용하되, 쿠키는 고객 도메인에만 설정합니다.

사용자가 brand.co.kr에서 로그인 클릭
auth.cronozen.com으로 리다이렉트 (client_id=brand)
인증 완료 후 brand.co.kr/callback으로 돌아옴
JWT + 리프레시 토큰을 brand.co.kr 도메인 쿠키에 저장

결과적으로:

brand.co.kr의 쿠키는 brand.co.kr에서만 전송됩니다
다른 화이트라벨 도메인의 쿠키와 완전히 격리됩니다
크로노젠 메인 도메인의 쿠키와도 격리됩니다

고객별 독립 인증 클라이언트가 설정되어 있어, 각 브랜드의 인증 흐름이 완전히 분리됩니다.

도메인 설정: Opt-in Rewrite 정책

공개 랜딩 페이지만 rewrite

화이트라벨 도메인에서 모든 페이지를 rewrite하지 않습니다. 명시적으로 등록된 공개 페이지만 고객 도메인으로 서빙됩니다.

rewrite 대상 (공개 랜딩):
  /, /pricing, /marketplace, /about ...

rewrite 제외 (내부 기능):
  /my, /admin, /settings, /onboarding ...

이 방식의 장점:

새 내부 페이지가 실수로 고객 도메인에 노출되지 않음
공개 랜딩만 점진적으로 추가 가능
내부 기능은 항상 크로노젠 도메인에서만 접근

도메인 추가 시 수정 포인트

새 화이트라벨 고객을 추가할 때 변경하는 곳은 3곳뿐입니다.

도메인 설정 파일: 도메인 → 센터 매핑, 테마, 기능 플래그
인증 클라이언트: 도메인별 독립 OAuth 클라이언트
CloudFlare Worker: 프록시 규칙 추가

데이터베이스 스키마 변경이나 코드 배포 없이 새 브랜드를 추가할 수 있습니다.

SEO: 플랫폼과 브랜드의 분리

화이트라벨 SEO에서 가장 중요한 원칙은 SEO 자산의 분리입니다.

Shopify 모델

Shopify는 shopify.com에 플랫폼 SEO를, 각 가맹점 도메인에 상점 SEO를 독립적으로 축적합니다. 크로노젠도 같은 구조입니다.

cronozen.com → 플랫폼 소개, 개발자 문서, 블로그
brand.co.kr → 고객 브랜드의 서비스 페이지

구체적 SEO 처리

항목	크로노젠 내부 경로	화이트라벨 도메인
canonical URL	cronozen.com/...	brand.co.kr/...
robots	noindex (내부 인프라)	index (고객 브랜드)
sitemap	cronozen.com/sitemap.xml	brand.co.kr/sitemap.xml
GA4	크로노젠 측정 ID	고객별 측정 ID
OG 태그	크로노젠 브랜딩	고객 브랜딩

크로노젠 내부 경로(예: /partner-slug)는 noindex로 설정되어 검색 엔진에 노출되지 않습니다. 검색 결과에는 오직 고객 도메인만 나타납니다.

리다이렉트 전략: 전환기 관리

화이트라벨을 처음 도입하거나 도메인을 변경할 때는 리다이렉트 전환기가 필요합니다.

예시 시나리오

파트너 "A 케어센터"가 도메인을 이전하는 경우:

canonical (정식): acare.co.kr
301 redirect:     old-acare.com → acare.co.kr
noindex (내부):   cronozen.com/acare-slug

acare.co.kr이 정식 도메인으로, 모든 SEO가 여기에 축적됩니다
기존 도메인은 전환기 동안 301 리다이렉트로 유지합니다
크로노젠 내부 경로는 noindex로 검색에서 제외합니다

이 구조 덕분에 도메인 변경 시에도 SEO 자산이 손실되지 않습니다.

멀티테넌트 데이터 격리

화이트라벨의 핵심은 도메인이 곧 테넌트라는 것입니다.

요청 → 테넌트 매핑

brand.co.kr에서 요청
  → 미들웨어: 도메인으로 center_id 결정
  → scoped Prisma: 모든 쿼리에 WHERE center_id = N 자동 주입
  → 다른 센터의 데이터는 물리적으로 접근 불가

200개 이상의 테이블에서 모든 쿼리가 center_id로 필터링됩니다. 코드 레벨에서 다른 테넌트의 데이터에 접근하는 것이 구조적으로 불가능합니다.

보안 감사에서 basePrisma 사용처 213개를 전수 조사한 결과 DANGER 0건을 확인했습니다.

파트너 관리 기능

화이트라벨 파트너에게는 파트너 관리 콘솔이 제공됩니다.

파트너가 할 수 있는 것

자신의 센터 목록 조회 및 관리
대시보드 통계 (회원 수, 활성도, 매출)
감사 로그 조회
멤버 관리
설정 변경 (브랜딩, 기능 플래그)

파트너 권한 체계

PARTNER_ADMIN: 파트너 조직의 최고 관리자
PARTNER_OPERATOR: 일상 운영 담당자

파트너는 자신이 소유한 센터만 관리할 수 있습니다. 다른 파트너의 센터나 크로노젠 플랫폼 설정에는 접근할 수 없습니다.

셋업 과정: 2시간이면 충분

새 화이트라벨 브랜드를 런칭하는 데 필요한 시간은 약 2시간입니다.

단계별 체크리스트

DB 설정 (15분): 센터 생성, 테넌트 매핑, 화이트라벨 계약 등록
앱 설정 (15분): 도메인 설정 파일에 브랜드 추가, 인증 클라이언트 등록
CloudFlare 설정 (30분): DNS 레코드, Worker 프록시 규칙, SSL 인증서
테스트 (30분): 도메인 접속, 로그인, 데이터 격리, SEO 메타 확인
SEO 설정 (15분): 사이트맵, GA4, 캐노니컬 URL, robots.txt
최종 확인 (15분): 모바일 테스트, 공유 미리보기, 성능 확인

코드 변경이나 별도 배포 없이 설정만으로 완료됩니다.

왜 이 구조가 중요한가

화이트라벨은 단순 기능이 아니라 비즈니스 모델입니다.

파트너는 자신의 브랜드로 고객에게 서비스를 제공합니다
크로노젠은 인프라와 기능 업데이트를 담당합니다
파트너의 고객은 안정적인 서비스를 자신의 브랜드로 경험합니다

이 구조가 CSS 테마 수준이면 브랜드 격리, 인증 격리, SEO 격리, 데이터 격리 모두 불가능합니다.

인프라 수준의 화이트라벨이기 때문에 파트너가 진짜 자신의 서비스처럼 운영할 수 있습니다.

CSS 테마가 아닌 인프라 수준의 화이트라벨

대부분의 SaaS에서 "화이트라벨"이란 로고를 바꾸고 색상을 조정하는 수준입니다. URL 바에는 여전히 원래 플랫폼 도메인이 보입니다.

크로노젠의 화이트라벨은 다릅니다.

고객은 brand.co.kr을 방문합니다
브라우저 주소창에 cronozen.com은 나타나지 않습니다
인증 쿠키는 해당 도메인에만 존재합니다
SEO는 고객 도메인으로 독립 축적됩니다
GA4 측정 ID도 고객별로 분리됩니다

고객의 사용자는 크로노젠이 뒤에 있다는 것을 알 수 없습니다. Shopify 위에서 운영되는 쇼핑몰처럼, 겉은 브랜드이고 속은 플랫폼입니다.

아키텍처: 3계층 프록시 구조

화이트라벨 도메인은 3개 계층을 거쳐 작동합니다.

1계층: DNS + CloudFlare

고객 도메인의 DNS를 CloudFlare로 향하게 설정합니다.

brand.co.kr → CloudFlare DNS → CloudFlare Worker

CloudFlare는 WAF(웹 방화벽), DDoS 방어, SSL 인증서를 자동 처리합니다. 고객이 별도로 보안을 설정할 필요가 없습니다.

2계층: CloudFlare Worker (프록시)

CloudFlare Worker가 요청을 크로노젠 서버로 전달합니다.

brand.co.kr/dashboard
  → Worker가 rewrite
  → cronozen.com/brand-slug/dashboard

이 과정에서 Worker는 추가 작업도 수행합니다.

GA4 ID 교체: 크로노젠 GA4 → 고객 GA4 측정 ID로 교체
OG 메타 태그 재작성: 공유 시 고객 브랜드로 표시
캐노니컬 URL: brand.co.kr로 설정 (SEO 독립)
noindex 제거: 크로노젠 내부 경로의 noindex를 제거

3계층: 크로노젠 서버 (프록시 코어)

크로노젠 서버의 프록시 미들웨어가 최종 처리합니다.

요청 수신
  → JWT 쿠키에서 인증 정보 추출
  → 도메인으로 센터(테넌트) 식별
  → scoped Prisma 주입 (center_id 자동 필터)
  → API 핸들러 실행
  → 해당 센터 데이터만 응답

12단계 처리 파이프라인을 거치며, 정적 자산 바이패스, 인증 도메인 처리, 라우트 권한 검증, URL rewrite까지 자동으로 이루어집니다.

인증: 호스트 전용 쿠키

화이트라벨에서 가장 까다로운 부분은 인증입니다.

문제

일반적인 SSO 구조에서는 쿠키가 메인 도메인에 설정됩니다. 하지만 화이트라벨에서는 brand.co.kr에 쿠키가 있어야 합니다.

크로노젠의 해결 방식

크로노젠은 중앙 인증 서버(auth.cronozen.com)를 사용하되, 쿠키는 고객 도메인에만 설정합니다.

사용자가 brand.co.kr에서 로그인 클릭
auth.cronozen.com으로 리다이렉트 (client_id=brand)
인증 완료 후 brand.co.kr/callback으로 돌아옴
JWT + 리프레시 토큰을 brand.co.kr 도메인 쿠키에 저장

결과적으로:

brand.co.kr의 쿠키는 brand.co.kr에서만 전송됩니다
다른 화이트라벨 도메인의 쿠키와 완전히 격리됩니다
크로노젠 메인 도메인의 쿠키와도 격리됩니다

고객별 독립 인증 클라이언트가 설정되어 있어, 각 브랜드의 인증 흐름이 완전히 분리됩니다.

도메인 설정: Opt-in Rewrite 정책

공개 랜딩 페이지만 rewrite

화이트라벨 도메인에서 모든 페이지를 rewrite하지 않습니다. 명시적으로 등록된 공개 페이지만 고객 도메인으로 서빙됩니다.

rewrite 대상 (공개 랜딩):
  /, /pricing, /marketplace, /about ...

rewrite 제외 (내부 기능):
  /my, /admin, /settings, /onboarding ...

이 방식의 장점:

새 내부 페이지가 실수로 고객 도메인에 노출되지 않음
공개 랜딩만 점진적으로 추가 가능
내부 기능은 항상 크로노젠 도메인에서만 접근

도메인 추가 시 수정 포인트

새 화이트라벨 고객을 추가할 때 변경하는 곳은 3곳뿐입니다.

도메인 설정 파일: 도메인 → 센터 매핑, 테마, 기능 플래그
인증 클라이언트: 도메인별 독립 OAuth 클라이언트
CloudFlare Worker: 프록시 규칙 추가

데이터베이스 스키마 변경이나 코드 배포 없이 새 브랜드를 추가할 수 있습니다.

SEO: 플랫폼과 브랜드의 분리

화이트라벨 SEO에서 가장 중요한 원칙은 SEO 자산의 분리입니다.

Shopify 모델

Shopify는 shopify.com에 플랫폼 SEO를, 각 가맹점 도메인에 상점 SEO를 독립적으로 축적합니다. 크로노젠도 같은 구조입니다.

cronozen.com → 플랫폼 소개, 개발자 문서, 블로그
brand.co.kr → 고객 브랜드의 서비스 페이지

구체적 SEO 처리

항목	크로노젠 내부 경로	화이트라벨 도메인
canonical URL	cronozen.com/...	brand.co.kr/...
robots	noindex (내부 인프라)	index (고객 브랜드)
sitemap	cronozen.com/sitemap.xml	brand.co.kr/sitemap.xml
GA4	크로노젠 측정 ID	고객별 측정 ID
OG 태그	크로노젠 브랜딩	고객 브랜딩

크로노젠 내부 경로(예: /partner-slug)는 noindex로 설정되어 검색 엔진에 노출되지 않습니다. 검색 결과에는 오직 고객 도메인만 나타납니다.

리다이렉트 전략: 전환기 관리

화이트라벨을 처음 도입하거나 도메인을 변경할 때는 리다이렉트 전환기가 필요합니다.

예시 시나리오

파트너 "A 케어센터"가 도메인을 이전하는 경우:

canonical (정식): acare.co.kr
301 redirect:     old-acare.com → acare.co.kr
noindex (내부):   cronozen.com/acare-slug

acare.co.kr이 정식 도메인으로, 모든 SEO가 여기에 축적됩니다
기존 도메인은 전환기 동안 301 리다이렉트로 유지합니다
크로노젠 내부 경로는 noindex로 검색에서 제외합니다

이 구조 덕분에 도메인 변경 시에도 SEO 자산이 손실되지 않습니다.

멀티테넌트 데이터 격리

화이트라벨의 핵심은 도메인이 곧 테넌트라는 것입니다.

요청 → 테넌트 매핑

brand.co.kr에서 요청
  → 미들웨어: 도메인으로 center_id 결정
  → scoped Prisma: 모든 쿼리에 WHERE center_id = N 자동 주입
  → 다른 센터의 데이터는 물리적으로 접근 불가

200개 이상의 테이블에서 모든 쿼리가 center_id로 필터링됩니다. 코드 레벨에서 다른 테넌트의 데이터에 접근하는 것이 구조적으로 불가능합니다.

보안 감사에서 basePrisma 사용처 213개를 전수 조사한 결과 DANGER 0건을 확인했습니다.

파트너 관리 기능

화이트라벨 파트너에게는 파트너 관리 콘솔이 제공됩니다.

파트너가 할 수 있는 것

자신의 센터 목록 조회 및 관리
대시보드 통계 (회원 수, 활성도, 매출)
감사 로그 조회
멤버 관리
설정 변경 (브랜딩, 기능 플래그)

파트너 권한 체계

PARTNER_ADMIN: 파트너 조직의 최고 관리자
PARTNER_OPERATOR: 일상 운영 담당자

파트너는 자신이 소유한 센터만 관리할 수 있습니다. 다른 파트너의 센터나 크로노젠 플랫폼 설정에는 접근할 수 없습니다.

셋업 과정: 2시간이면 충분

새 화이트라벨 브랜드를 런칭하는 데 필요한 시간은 약 2시간입니다.

단계별 체크리스트

DB 설정 (15분): 센터 생성, 테넌트 매핑, 화이트라벨 계약 등록
앱 설정 (15분): 도메인 설정 파일에 브랜드 추가, 인증 클라이언트 등록
CloudFlare 설정 (30분): DNS 레코드, Worker 프록시 규칙, SSL 인증서
테스트 (30분): 도메인 접속, 로그인, 데이터 격리, SEO 메타 확인
SEO 설정 (15분): 사이트맵, GA4, 캐노니컬 URL, robots.txt
최종 확인 (15분): 모바일 테스트, 공유 미리보기, 성능 확인

코드 변경이나 별도 배포 없이 설정만으로 완료됩니다.

왜 이 구조가 중요한가

화이트라벨은 단순 기능이 아니라 비즈니스 모델입니다.

파트너는 자신의 브랜드로 고객에게 서비스를 제공합니다
크로노젠은 인프라와 기능 업데이트를 담당합니다
파트너의 고객은 안정적인 서비스를 자신의 브랜드로 경험합니다

이 구조가 CSS 테마 수준이면 브랜드 격리, 인증 격리, SEO 격리, 데이터 격리 모두 불가능합니다.

인프라 수준의 화이트라벨이기 때문에 파트너가 진짜 자신의 서비스처럼 운영할 수 있습니다.

화이트라벨 커스텀 도메인: 크로노젠 위에서 내 브랜드로 운영하기

CSS 테마가 아닌 인프라 수준의 화이트라벨

아키텍처: 3계층 프록시 구조

1계층: DNS + CloudFlare

2계층: CloudFlare Worker (프록시)

3계층: 크로노젠 서버 (프록시 코어)

인증: 호스트 전용 쿠키

문제

크로노젠의 해결 방식

도메인 설정: Opt-in Rewrite 정책

공개 랜딩 페이지만 rewrite

도메인 추가 시 수정 포인트

SEO: 플랫폼과 브랜드의 분리

Shopify 모델

구체적 SEO 처리

리다이렉트 전략: 전환기 관리

예시 시나리오

멀티테넌트 데이터 격리

요청 → 테넌트 매핑

파트너 관리 기능

파트너가 할 수 있는 것

파트너 권한 체계

셋업 과정: 2시간이면 충분

단계별 체크리스트

왜 이 구조가 중요한가

크로노젠을 직접 체험해 보세요

함께 보면 좋은 관련 콘텐츠

더 알아보기

무료 데모 신청

도입 문의하기

로딩 중...

화이트라벨 커스텀 도메인: 크로노젠 위에서 내 브랜드로 운영하기

CSS 테마가 아닌 인프라 수준의 화이트라벨

아키텍처: 3계층 프록시 구조

1계층: DNS + CloudFlare

2계층: CloudFlare Worker (프록시)

3계층: 크로노젠 서버 (프록시 코어)

인증: 호스트 전용 쿠키

문제

크로노젠의 해결 방식

도메인 설정: Opt-in Rewrite 정책

공개 랜딩 페이지만 rewrite

도메인 추가 시 수정 포인트

SEO: 플랫폼과 브랜드의 분리

Shopify 모델

구체적 SEO 처리

리다이렉트 전략: 전환기 관리

예시 시나리오

멀티테넌트 데이터 격리

요청 → 테넌트 매핑

파트너 관리 기능

파트너가 할 수 있는 것

파트너 권한 체계

셋업 과정: 2시간이면 충분

단계별 체크리스트

왜 이 구조가 중요한가

크로노젠을 직접 체험해 보세요

함께 보면 좋은 관련 콘텐츠

더 알아보기

무료 데모 신청

도입 문의하기