19장 저장소와 호스트

저장소 이름과 호스트 이름은 「어느 제품의 어떤 접점을 어떤 기기용으로 제공하는가」라는 같은 정보를 서로 다른 형식으로 적은 것입니다. 이 장은 그 문법이 왜 이런 모양인지 설명합니다. 정확한 문법과 검증 규칙은 공개 표준이 정합니다.

왜 필요한가

제품과 저장소가 늘면서 이름에 내부 별칭과 -app·-web·-pwa 같은 기술 접미사가 섞였습니다. 이름만 보고는 누구를 위한 어떤 화면인지, 어느 디자인 시스템을 쓰는지, 어느 주소로 배포되는지 알 수 없었습니다.

저장소는 사람과 AI 에이전트가 함께 만듭니다. 이름을 그때그때 고르면 같은 접점에 이름이 둘 생기거나, 다른 접점이 같은 이름을 갖습니다. 그래서 Leysys는 이름을 고르지 않고 계산합니다. 같은 입력을 넣으면 누가 계산해도 같은 이름이 나와야 합니다.

모델: 하나의 정보, 두 가지 표기

이름의 입력은 route identity라는 세 값입니다. 제품(product), 접점(surface), 그리고 전용 기기(device)입니다. 기기는 선택 항목입니다.

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

웹 저장소 = {prefix}-{surface-id}[-{device}][-proto]
호스트     = [{device}-]{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
leyvote-portal-mobile-proto   ↔ mobile-portal.leyvote.net

두 표기의 순서가 다른 데에는 이유가 있습니다.

• 저장소 이름은 왼쪽이 넓고 오른쪽이 좁습니다(제품 → 접점 → 기기 → 종류). 이름을 사전순으로 늘어놓으면 같은 접점의 저장소가 모입니다.
• DNS는 오른쪽이 상위입니다. 그래서 기기를 앞에 붙여 mobile-customer-portal처럼 씁니다. customer-portal처럼 대상과 유형을 합친 접점 ID는 등록된 한 덩어리라 뒤집지 않습니다.
• 기기와 접점을 점(.)이 아니라 하이픈으로 이어 DNS label 하나로 만듭니다. 그러면 한 도메인 구역(zone)의 접점 주소를 *.leyve.net 같은 와일드카드 인증서 한 장이 덮습니다. label 하나는 63 octet을 넘지 않습니다.

기본값은 이름에서 뺍니다. 기본 실행 환경인 web은 적지 않으므로 leyve-console-web이 아니라 leyve-console입니다. 반응형 앱은 기기를 적지 않습니다. 운영 환경도 적지 않고, staging·dev 같은 시험 환경은 저장소가 아니라 zone으로 나눕니다(console.staging.leyve.net).

호스트 문자열에서 되살릴 수 있는 것은 route identity까지입니다. 그 주소를 실제로 배포하는 저장소가 정식인지 프로토타입인지는 등록부(registry)에서 조회합니다. 한 환경의 정식 주소 하나에는 배포 주인 저장소가 정확히 하나만 있습니다.

접점 유형과 대상

접점(surface)은 사용자가 들어오는 화면의 종류입니다. 네 접점 유형을 나란히 둡니다.

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

유형은 기기 크기나 사람의 소속이 아니라 업무 범위·흐름·권한·세션으로 고릅니다. 같은 태블릿이라도 전체 셀프서비스를 제공하면 portal, 선정한 최소 업무만 제공하면 kiosk입니다. kiosk는 완료·취소·시간 초과·사용자 교대 때 세션과 개인정보를 정리해야 합니다. 업무 규칙과 권한 검증은 접점끼리 재사용하고, 화면 흐름과 세션 수명은 각 접점이 소유합니다.

대상(audience)은 누구의 업무 맥락인지를 나타내며 접점 유형 앞에 붙습니다.

대상	뜻
customer	개인·개인사업자·법인사업자 고객
staff	고객사 직원
partner	Leysys의 총판·리셀러
ops	Leysys 본사 운영자

• 고객 대상은 customer로 통일하고 consumer-*를 섞지 않습니다. 일반 단어 consumer를 금지하는 결정은 아닙니다.
• staff는 상대적인 말이라 뜻을 고정합니다. Leyve 이름에서 staff는 고객사 직원이고, Leysys 본사는 ops입니다.
• 대상을 생략한 portal은 그 제품의 portal 대상이 정확히 하나이고 바뀌지 않는 기본값으로 등록된 경우에만 씁니다. LeyVote는 투표자 portal 하나라서 mobile-portal.leyvote.net을 씁니다. Leyve는 고객과 직원 두 대상이 있어 customer-portal, staff-portal을 씁니다.

전용 기기는 mobile·tablet·desktop 세 단어만 씁니다. 독립된 저장소·빌드·배포와 그 기기만 지원한다는 제품 계약이 실제로 있을 때만 붙이고, 웹이면 독립된 주소도 있어야 합니다. CSS breakpoint 차이나 주 사용 기기만으로는 붙이지 않습니다. m·p·d 같은 축약도 쓰지 않습니다. p만 해도 phone·pad·portal·production으로 읽힐 수 있습니다.

프로토타입 표식 -proto

-proto는 프로토타입 저장소에만 붙는 끝 접미사입니다. 실행 환경이나 배포 구성 요소를 뜻하지 않습니다. 호스트를 계산할 때는 빼므로 주소만 보고 프로토타입인지 알 수 없습니다. 같은 환경에서 leyve-console과 leyve-console-proto가 같은 주소를 함께 가질 수 없습니다.

-proto를 기계적으로 떼어 정식 이름으로 바꾸지도 않습니다. 프로토타입을 끝낼 때는 그 저장소를 참고용으로 보관하고 정식 저장소를 따로 운영하거나, 명확한 이유가 있을 때만 이행 결정 기록을 남기고 이름을 바꿉니다 (21장).

접점과 디자인 시스템

디자인 시스템은 대상이 아니라 접점이 정합니다. staff-portal도 customer-portal처럼 MDS를 씁니다. 두 진영의 차이는 6장이 설명합니다.

접점	디자인 시스템
console	EDS
center	EDS
portal · kiosk · www	MDS
모바일 전용 delivery	MDS
백엔드	무관

한 페이지는 한 진영만 쓰므로, 접점 저장소는 보통 한 DS 패키지만 의존합니다. 이 구조가 혼용을 의존성 단계에서 막는 방법은 24장이 설명합니다.

백엔드 이름

접점을 없애도 결제나 CRM 같은 업무 능력은 남습니다. 그래서 접점과 업무 영역(domain)을 같은 축에 두지 않습니다.

역할	이름	공개 주소
한 접점 전용 조합 계층	leyve-console-bff	자동 생성 안 함
업무 영역 서비스	leyve-billing-service	내부
여러 영역의 공유 백엔드	leyve-server	내부
제품 공통 입구	leyve-gateway	api.leyve.net

leyve-console-api는 피합니다. 화면 전용 조합인지 업무 API인지 이름으로 알 수 없기 때문입니다. 화면 전용이면 -bff, 업무 규칙을 소유하면 {domain}-service를 씁니다.

경계와 예외

• 「프로토타입은 .net, 정식은 .com」 같은 대응은 없습니다. .net·.com은 제품 도메인의 일부이고, 환경별 zone은 등록부가 정합니다.
• 이름은 권한을 만들지 않습니다. 접점 유형과 대상은 역할 값이나 권한 판정의 입력이 아닙니다(22장).
• 접점 유형이 다르다고 백엔드 업무를 복제하거나 저장소·주소를 자동으로 만들지 않습니다. 저장소는 독립된 코드 소유와 배포 경계가 있을 때 만듭니다.
• 이 규칙 이전에 만든 프로토타입 이름은 문서 정리만으로 바꾸지 않습니다. 새 저장소가 그 이름의 대상 없는 portal·center·kiosk를 본뜨지도 않습니다.
• 이 체계는 국제 표준이 아닙니다. 업계에서 널리 쓰는 customer portal, partner center, BFF 같은 말의 뜻을 Leysys 제품의 사용자·권한·배포 경계에 맞게 고정한 내부 표준입니다.

정리

• 저장소와 호스트는 같은 route identity를 각자의 순서로 적은 두 표기입니다.
• 접점 유형(console·center·portal·kiosk), 대상(customer·staff·partner·ops), 전용 기기는 서로 다른 축입니다.
• 기본값(web·반응형·운영 환경)은 이름에서 빼고, -proto는 저장소에만 붙입니다.
• 디자인 시스템은 접점이 정합니다. 관리 접점은 EDS, 셀프서비스·현장·공개 접점은 MDS입니다.

정본

• 저장소·호스트 네이밍 — 핵심 수식과 접점 유형
• 저장소·호스트 네이밍 상세 규칙 — 역함수, 등록부, 백엔드, -proto
• 제품 구조와 용어 — 이름의 product와 판매 플랫폼의 구분
• leysys-design AGENTS.md 「레포 ↔ 호스트 네이밍」 — 접점 유형별 디자인 시스템 매핑