저장소·호스트 네이밍 — 한눈에 보기

결론: 저장소는 surface별로 정렬되도록 surface → device → platform, DNS의 단일 endpoint label은 [device-]surface 순서로 표현합니다. 반응형은 device를 양쪽 모두에서 생략합니다.

핵심 수식

route identity = (product, surface-id, device-class?)
client repo identity = (product, surface-id, device-class?, client-platform)

client repository    = {repository-prefix}-{surface-id}[-{device-class}]-{client-platform}
prototype repository = {repository-prefix}-{prototype-scope}[-{device-class}]-proto
prod host             = [{device-class}-]{surface-id}.{product-zone}

leyve-console-web                    ↔ console.leyve.net
leyve-customer-portal-mobile-web     ↔ mobile-customer-portal.leyve.net
leyve-staff-kiosk-tablet-web         ↔ tablet-staff-kiosk.leyve.net
leyvote-portal-mobile-proto          ↔ mobile-portal.leyvote.net
leysign-app-proto                    ↔ app.leysign.net

두 이름은 같은 route tuple의 서로 다른 serializer입니다. Hostname은 (product, surface, device?)까지만 복원하며 실제 ingress owner의 web·proto suffix는 registry에서 조회합니다. 등록된 (host owner repository, environment) ↔ canonical hostname에만 유일한 역함수가 있습니다. Raw filename 사전순에서는 같은 surface가 모이고, 공식 표시 순서는 별도 surface → device → kind/platform ordinal을 사용합니다.

surface-id는 제품별 registry 집합 S(product)에 등록된 값만 사용합니다.

Leyve 표준 Surface

다음 표는 stable web client를 새로 만들 때의 기본 projection입니다. 실제 ingress owner는 environment별 registry가 결정합니다.

순서	stable client 저장소	canonical 운영 hostname
1	leyve-console-web	console.leyve.net
2	leyve-customer-portal-web	customer-portal.leyve.net
3	leyve-staff-portal-web	staff-portal.leyve.net
4	leyve-customer-kiosk-web	customer-kiosk.leyve.net
5	leyve-staff-kiosk-web	staff-kiosk.leyve.net
6	leyve-partner-center-web	partner-center.leyve.net
7	leyve-ops-center-web	ops-center.leyve.net
8	leyve-www-web	www.leyve.net

customer는 개인·개인사업자·법인사업자를 포함합니다. staff는 고객사 직원, partner는 총판·리셀러, ops는 Leysys 본사 운영자입니다. Leyve는 portal audience가 둘 이상이므로 bare portal을 쓰지 않으며 bare kiosk, center도 허용하지 않습니다.

제품별 Default Surface

• 제품에 portal audience가 정확히 하나이고 registry가 이를 기본 portal로 선언하면 audience를 생략한 portal을 허용합니다. Leyvote는 mobile-portal.leyvote.net을 사용합니다.
• Portal audience가 둘 이상이면 {audience}-portal을 사용합니다.
• 관리자와 사용자가 동일 repository·deploy·origin·release 경계를 공유하면 registry에 등록한 app surface를 사용할 수 있습니다. Leysign은 app.leysign.net을 사용합니다.
• app은 surface ID이며 platform·component suffix가 아닙니다.

Device와 환경

• 승인 device는 mobile, tablet, desktop 전체 단어뿐입니다. m, p, d, 제품명은 쓰지 않습니다.
• 독립 deployable·build·release와 지원 device 계약이 실제로 분리될 때만 device를 붙입니다.
• web이면 독립 canonical hostname도 필요합니다. Native client에는 hostname을 자동 생성하지 않습니다.
• 반응형·adaptive 앱, CSS breakpoint 차이, 주 사용 기기만 다르면 device를 생략합니다.
• mobile-portal.leyve.net은 Leyve에 default portal이 없으므로 허용하지 않습니다. 반면 mobile-portal.leyvote.net은 Leyvote registry에 등록된 단일 기본 portal이므로 canonical입니다.

환경은 repo가 아니라 zone으로 구분합니다.

production  mobile-customer-portal.leyve.net
staging     mobile-customer-portal.staging.leyve.net
dev         mobile-customer-portal.dev.leyve.net

정확한 관계는 실제 등록된 (host-bearing repository, environment) ↔ canonical hostname입니다. legacy·apex·custom domain은 canonical 이름이 아니라 alias입니다.

Platform과 Backend

승인 platform은 web, ios, android, macos, windows입니다.

대상	저장소	public hostname
stable web surface	{prefix}-{surface}[-{device}]-web	[{device}-]{surface}.{zone}
prototype	{prefix}-{prototype-scope}[-{device}]-proto	자동 생성하지 않음; registry에 등록된 web prototype만 suffix를 제외해 투영
native client	{prefix}-{surface}[-{device}]-{platform}	자동 생성하지 않음
surface BFF	{prefix}-{surface}[-{device}]-bff	same-origin /api 또는 gateway 뒤
domain backend	{prefix}-{domain}-{component}	private service discovery
공유 backend	{prefix}-server	직접 public host 없음
공통 ingress	{prefix}-gateway	registry 예약 endpoint api.{zone}

web은 정적 사이트라는 뜻이 아닙니다. SPA·SSR·SSG, 게시판, 폼, 메일 전송 또는 server route가 있어도 브라우저 UI가 주 delivery이면 -web을 유지합니다. service는 backend 업무 서비스이며 full-stack을 뜻하지 않습니다. app은 등록된 surface 위치에서만 사용하며 console-app 같은 terminal platform·component suffix로 사용하지 않습니다.

반드시 지킬 불변식

1. canonical hostname 하나에는 ingress owner가 정확히 하나만 있습니다.
2. surface ID와 생성된 [device-]surface는 단일 lowercase DNS label이며 각각 63 octet 이하입니다.
3. Surface 유효성, default portal과 unified app 허용 여부는 product registry가 소유합니다.
4. surface ID는 device 예약어와 같거나 device token으로 시작·끝날 수 없습니다.
5. Surface hostname projection에는 platform·backend component·environment·proto token을 넣지 않습니다. api 같은 예약 endpoint는 registry의 명시적 mapping만 허용합니다.
6. stable 브라우저 surface는 full-stack 구현이어도 -web을 생략하지 않습니다. Prototype은 별도 -proto suffix를 보존하며 이를 -web으로 치환하지 않습니다.
7. flat device hostname은 *.{product-zone} wildcard 인증서의 한 단계 범위에 포함됩니다. DNS·CDN alias 등록과 apex 인증서는 별도로 관리합니다.
8. rename은 DNS·인증서·CORS·cookie·인증·provider callback·rollback을 포함한 ADR로 진행합니다.

수학적 역함수, registry, TLS·origin·검색·migration 규칙은 상세 규칙에서 확인합니다.