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

결론: web은 기본 client platform이므로 저장소 이름에서 생략합니다. 저장소는 surface → device → non-default platform, DNS의 단일 endpoint label은 [device-]surface 순서로 표현합니다. 반응형은 device도 생략합니다.

정본은 Leysys Docs의 상세 규칙입니다. Leyve 등 각 플랫폼·브랜드는 이 문법을 적용하고 자체 사용자·권한·배포 현황을 제품 문서에 기록합니다.

핵심 수식

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

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

leyve-console                    ↔ console.leyve.net
leyve-customer-portal-mobile     ↔ mobile-customer-portal.leyve.net
leyve-staff-kiosk-tablet         ↔ tablet-staff-kiosk.leyve.net
leyve-console-ios                # native: public host 자동 생성 없음
leyvote-portal-mobile-proto      ↔ mobile-portal.leyvote.net
leysign-app-proto                ↔ app.leysign.net

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

surface-id는 제품별 registry 집합 S(product)에 등록된 값만 사용합니다. 수식의 product는 플랫폼, 프로덕트 또는 단독 브랜드의 route namespace입니다. 업무 모듈 키나 결제 catalog의 product_key와 자동으로 같아지지 않습니다. client-platform은 web·iOS 같은 실행 환경이고, shared-platform은 server·gateway 같은 공유 실행 기반입니다. 두 기술 용어는 제품 구조의 판매 플랫폼(Leyve·Arenity)과 구분합니다.

네이밍 구성표

웹 프런트엔드의 저장소·호스트는 아래 순서로 읽습니다. []는 선택 항목이며, surface-id는 [사용자-]유형을 포함하는 등록된 완성형 접점 이름입니다.

구분	이름 순서
호스트	[전용 기기-] → [사용자-] → 접점 유형 → .제품 도메인
웹 레포	프로젝트- → [사용자-] → 접점 유형 → [-전용 기기] → [-proto]

호스트 = [기기-][사용자-]유형.제품도메인
레포   = 프로젝트-[사용자-]유형[-기기][-proto]

mobile-customer-portal.leyve.net ↔ leyve-customer-portal-mobile-proto
customer-kiosk.leyve.net        ↔ leyve-customer-kiosk
console.leyve.net               ↔ leyve-console

위 연결은 해당 저장소가 hostname owner로 등록된 경우의 예입니다. 호스트만으로 proto 여부를 알 수 없습니다. [기기-][사용자-]유형은 하이픈으로 묶은 하나의 DNS label이며, .net은 제품 도메인의 TLD입니다. .net·.com과 prototype·stable 사이의 자동 대응 규칙은 없습니다. proto는 프로토타입 레포에만 붙이며 일반 웹 레포에서는 생략합니다.

사용자·유형은 모든 조합을 자유롭게 만드는 목록이 아닙니다. 예를 들어 console은 사용자 접두어를 생략한 등록 접점이고, native·backend·예약 endpoint는 위 웹 접점 표가 아니라 각각의 상세 문법을 따릅니다. 전용 기기는 mobile / tablet / desktop이며 반응형은 생략합니다. 화면 크기나 디자인 차이만으로 suffix를 붙이지 않고 독립 delivery 계약을 확인합니다.

접점 유형과 전용 기기

console / center / portal / kiosk는 네이밍의 접점 유형으로 나란히 둡니다. 사용자에게 제공하는 업무 범위·흐름·권한·세션을 함께 설명하는 유형이며, 기기 크기와는 별개입니다.

접점 유형	업무 범위와 사용 흐름
console	고객사 관리자·권한 있는 실무자가 조직 내부의 핵심 업무와 설정을 처리하는 workspace
center	서비스 운영자·파트너가 담당 고객·조직·계약·운영을 관리하는 backoffice
portal	해당 사용자에게 허용된 전체 셀프서비스 기능을 탐색하고 이어서 이용하는 접점
kiosk	현장·공용 단말에서 선정된 최소 기능을 짧은 유도 흐름으로 처리하는 접점

Portal의 전체 기능은 해당 audience의 권한 범위 안에서 제공하는 기능을 뜻합니다. Console·Center의 관리 권한까지 제공한다는 뜻은 아닙니다. Kiosk는 Portal과 업무 기능을 공유할 수 있지만 별도의 접점 유형입니다. customer-portal-kiosk처럼 Portal의 기기 변형으로 표현하지 않고 customer-kiosk로 씁니다.

같은 태블릿에서도 전체 셀프서비스를 제공하면 Portal, 선별한 최소 업무만 제공하면 Kiosk입니다. Kiosk는 태블릿·대형 단말 등에 배치할 수 있으며, 전용 tablet delivery를 별도로 운영할 때만 customer-kiosk-tablet로 표현합니다.

공통 업무 규칙·데이터·권한 검증은 재사용하고 각 접점은 화면 흐름과 세션 수명을 소유합니다. Kiosk는 완료·취소·timeout·사용자 교대 시 개인정보와 사용자 세션을 정리해야 합니다. 구체적인 인증·권한·초기화 구현은 제품 runtime에서 검증합니다. 접점 유형이 다르다는 이유만으로 백엔드 업무를 복제하거나 새 저장소·hostname을 자동 생성하지 않습니다. 등록 접점의 의미 매핑을 함께 확인합니다.

고객 audience 표기

고객용 저장소·호스트의 audience는 customer로 통일하고 consumer-*를 혼용하지 않습니다. customer에는 개인·개인사업자·법인사업자 고객을 포함합니다. 이는 회사의 명명 결정이며, consumer를 일반 문서·법률·기술 용어에서 금지하거나 사업자가 아닌 사람으로 한정하는 정의가 아닙니다. end user는 실제 사용 역할이므로 Console 사용자와 staff도 포함할 수 있으며, customer를 대신하는 audience token으로 쓰지 않습니다.

플랫폼 계약 고객사와 그 고객사가 서비스를 제공하는 최종 고객은 관계와 권한을 구분합니다. 제품 문서는 각 접점에서 누구를 customer라고 부르는지 기준점을 명시하고, 이름만으로 계약자와 최종 이용자에게 같은 권한을 부여하지 않습니다.

Leyve 적용 예시

다음 표는 공통 문법의 Leyve 적용 예시입니다. 제품별 접점 정의는 Leyve 적용 문서 (새 탭)가 소유합니다. Stable web client의 이름 투영을 보여주며 실제 ingress owner는 environment별 registry가 결정합니다.

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

customer는 개인·개인사업자·법인사업자를 포함합니다. staff는 고객사 직원, partner는 총판·리셀러, ops는 Leysys 본사 운영자입니다. Leyve는 portal audience가 둘 이상이므로 bare portal을 쓰지 않으며 bare kiosk도 허용하지 않습니다. 본사·파트너 공용 센터는 플랫폼마다 하나인 bare center입니다. Leyve와 그 프로덕트(LeyVote 등)는 leyve-center(center.leyve.net), Arenity와 그 프로덕트(ArenVote)는 arenity-center(center.arenity.net)입니다(2026-10-20 · 10-21 KST 오너 결정).

제품별 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입니다. 기본값 web만 이름에서 생략하고 나머지는 전체 token으로 명시합니다.

대상	저장소	public hostname
stable web surface	{prefix}-{surface}[-{device}]	[{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이면 platform suffix를 생략합니다. 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으로 시작할 수 없으며, device·client platform(web 포함)·component·proto 예약 token으로 끝날 수 없습니다.
5. Surface hostname projection에는 platform·backend component·environment·proto token을 넣지 않습니다. api 같은 예약 endpoint는 registry의 명시적 mapping만 허용합니다.
6. stable 브라우저 surface는 full-stack 구현이어도 -web을 붙이지 않습니다. Prototype은 별도 -proto suffix를 보존하며 단순히 suffix를 제거해 stable web으로 바꾸지 않습니다.
7. flat device hostname은 *.{product-zone} wildcard 인증서의 한 단계 범위에 포함됩니다. DNS·CDN alias 등록과 apex 인증서는 별도로 관리합니다.
8. 기존 *-web은 legacy 이름이며 충돌 검사를 거쳐 suffix 없는 canonical 이름으로 migration합니다.
9. -web 제거는 canonical hostname이 그대로인 repository rename입니다. GitHub·CI/CD·배포 연결과 참조를 전환하며, DNS·인증서·CORS·cookie·provider 설정은 hostname도 바뀔 때만 변경합니다.

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