18장 제품 구조
Leysys의 제품은 공통 서비스·공통 모듈·업무 모듈의 세 층으로 이루어집니다. 같은 업무 모듈을 플랫폼 안의 모듈로도, 플랫폼에 속한 단독 프로덕트로도 팝니다. 이 장은 그 구조와 용어, 그리고 같은 단어가 가리키는 서로 다른 계약을 설명합니다.
왜 필요한가
Leysys는 투표나 CRM 같은 업무 기능 하나를 두 방식으로 함께 팝니다. 하나는 업무 플랫폼 Leyve·Arenity 안의 기능이고, 다른 하나는 LeyVote·ArenVote 같은 플랫폼의 단독 프로덕트나 Zution·Laiel 같은 단독 브랜드입니다.
구조와 용어를 정하기 전에는 문서·가격표·코드마다 「상품·모듈·프로덕트·플랫폼」의 뜻이 달랐습니다.
- 결제·연동·디자인의 공통 기반을 「공통 플랫폼」이라고 불렀습니다. 고객이 쓰는 플랫폼과 이름이 같았습니다.
- 가격표의 「Core(CRM)」는 두 가지를 뜻했습니다. 모든 기능이 함께 쓰는 고객 정보와, 리드에서 고객으로 이어지는 영업 관리입니다.
- 필수 항목이 조직 기본료와 Core 둘이어서, 두 항목이 언제나 함께 청구됐습니다.
한 단어에 뜻이 여럿이면 사람도 문맥을 놓치고, 문서에 적힌 대로 일하는 에이전트는 더 쉽게 틀립니다. 같은 성격의 요금을 두 항목으로 매기거나, 바꾸지 말아야 할 식별자를 고칩니다. 그래서 2026-09-25 KST에 오너가 구조와 용어를 한 번에 확정했습니다.
모델: 세 층
text
공통 서비스 계정 · 조직·권한 · 결제·구독 · 알림·파일 · 전자문서 발행·발송 · 메시징
모든 플랫폼과 브랜드가 함께 씀. 따로 팔지 않고 외부 실사용료만 받음
공통 모듈 고객 정보 · 구성원 명부 · 유닛 정보
여러 업무 모듈이 함께 쓰는 기준 데이터. 업무 상태를 갖지 않음
업무 모듈 투표 · 관리비관리 · 임대차관리 · 시설관리 · 재무회계 · CRM · …
자기 업무와 상태를 끝까지 소유. 고객이 골라서 켬- 공통 서비스(common service)는 여러 플랫폼과 브랜드가 함께 쓰는 기반입니다.
- 공통 모듈(common module)은 여러 업무 모듈이 함께 쓰는 기준 데이터입니다.
- 업무 모듈(business module)은 자기 업무의 규칙과 상태를 소유하는 독립 기능입니다.
- 모듈(module)은 업무 모듈과 공통 모듈을 함께 이르는 말입니다.
플랫폼 안의 기능을 「모듈」이라고 부르는 이유는 여러 모듈이 함께 쓰는 모듈이 있기 때문입니다. 투표만 따로 팔려 해도 투표할 사람의 명부가 함께 있어야 합니다.
의존은 아래 층으로만 향합니다. 업무 모듈이 필수로 참조할 수 있는 것은 공통 모듈과 공통 서비스뿐입니다. 다른 업무 모듈은 선택 기능으로만 잇습니다. 공통 모듈은 업무 상태를 갖지 않습니다. 「투표했는가」나 「관리비를 냈는가」는 투표 모듈과 관리비관리 모듈의 상태입니다.
모델: 파는 단위
| 용어 | 뜻 | 예 |
|---|---|---|
| 플랫폼 | 한 고객이 한 계정으로 업무 모듈을 더해 쓰는 곳 | Leyve, Arenity |
| Core(코어) | 월 가격표의 필수 기본 항목. 공통 모듈과 공통 서비스 이용이 들어 있고 조직마다 월로 받음 | Leyve 코어, LeyCERP 코어, Arenity 코어 |
| 회의 개설비 | 회의당 가격표의 필수 기본 항목. 회의를 열 때마다 한 번 받음 | LeyVote 회의 개설비, ArenVote 회의 개설비 |
| 프로덕트 | 플랫폼에서 업무 모듈 하나를 떼어, 필요한 공통 모듈과 함께 단독으로 파는 단위. 플랫폼에 속하고, 등급에 보조 업무 모듈을 더할 수 있음 | LeyVote · LeyCERP · LeyERP · LeyCRM(Leyve), ArenVote(Arenity) |
| 단독 브랜드 | 프로덕트를 자체 이름·사이트·가입으로 파는 것 | LeyVote, Zution, Laiel |
| 추천 구성(preset) | 모듈 몇 개를 묶어 붙인 판매 이름. 가격은 들어 있는 모듈 가격의 합 | Leyve Property, Arenity Meeting |
text
플랫폼 = Core + 모듈 1 + 모듈 2 + … 프로덕트 = 필수 기본 항목 + 모듈 하나 (+ 등급의 보조 모듈, 플랫폼 소속)
Leyve = Leyve Core + 업무 모듈 … LeyVote = 회의 개설비 + 투표
(구성원 명부는 프로퍼티 단계, 그 프로퍼티의 회의들이 함께 씀)
LeyCERP = LeyCERP Core + 관리비관리
(관리비관리는 필수, 스탠다드에 고객관계관리, 프리미엄에 재무회계)
LeyERP(범용 ERP) · LeyCRM … (가격표 미작성)
Arenity = Arenity Core + 업무 모듈 … ArenVote = 회의 개설비 + 투표
(구성원 명부는 프로퍼티 단계, 그 프로퍼티의 회의들이 함께 씀)
플랫폼 밖 단독 브랜드 (별도 가입) Zution = Core(고객 정보) + CRM가격표마다 필수 기본 항목이 하나 있고, 모든 계약에 들어가며 고객이 뺄 수 없습니다. 월 가격표(Leyve · LeyCERP · Arenity)는 Core(코어)이고 조직마다 월로 받습니다. 회의당 가격표(LeyVote · ArenVote)는 회의 개설비이고 회의를 열 때마다 한 번 받습니다. 「기본료」는 달마다 받는 요금으로 읽혀서 이름으로 쓰지 않고, 조직 기본료도 따로 두지 않습니다(2026-10-22 KST 오너 결정). 코어와 모듈은 현장마다가 아니라 조직마다 받고, 단지마다 따로 내려면 그 단지가 새 계약 주체가 됩니다. 업무 모듈을 여러 개 켜도 필수 기본 항목은 판매 단위마다 한 번만 받습니다. 문자·알림톡·발행 건수 같은 외부 실사용료는 필수 기본 항목과 별도로 실비를 받습니다. CRM의 영업 관리는 Core가 아니라 선택 업무 모듈인 CRM에 속합니다.
플랫폼은 여러 모듈을 붙여 쓰는 곳이고, 프로덕트는 플랫폼에서 업무 모듈 하나를 떼어 낸 것입니다. 프로덕트의 등급에는 보조 업무 모듈을 더할 수 있지만, 프로덕트의 중심은 떼어 낸 모듈 하나입니다. 관리비관리를 떼어 낸 LeyCERP는 베이직 · 스탠다드 · 프리미엄 가운데 프리미엄에 재무회계를 넣습니다. 관리비관리는 Core처럼 늘 들어가고, 스탠다드부터 고객관계관리가 더해집니다. C는 관리비를 뜻하는 Charge입니다. 범용 ERP는 LeyERP입니다. 둘 다 고객에게 ERP라고 소개할 수 있어서, 안에서 둘을 구분하려고 이름을 나눴습니다. 둘이 함께 쓰는 재무회계는 모듈 하나를 두 가격표에서 팝니다(2026-10-21 KST 오너 결정).
모델: 데이터 구조
제품이 다루는 데이터의 위아래입니다.
text
조직
└ 워크스페이스 권한 · 업무 공간
└ 프로퍼티 관리 대상(단지 · 건물). 관리비관리에서는 워크스페이스 하나에 하나
├ 유닛 프로퍼티 안에서 공유
├ 구성원 프로퍼티 안에서 공유(세대 · 입주자 · 조합원)
└ 회의 프로퍼티 하나에 여러 개. 그 프로퍼티의 유닛 · 구성원을 함께 씀
└ 유권자 그 회의가 구성원 가운데 고른 사람
직원 조직 · 워크스페이스에 속함
자산 소유 · 거래 대상. 단계가 아니라 프로퍼티 하나나 유닛 하나를 가리킴프로퍼티 안에서는 유닛과 구성원을 함께 씁니다. 한 프로퍼티의 회의가 여럿이어도 같은 유닛과 같은 구성원을 씁니다. 워크스페이스와 프로퍼티는 지금 1:1이고, 관리비관리에서는 규칙입니다. 프로퍼티 정보도 워크스페이스 행에 함께 저장합니다. 그래도 둘은 다른 개념입니다. 워크스페이스는 권한의 경계이고, 프로퍼티는 관리 대상 데이터입니다. 다른 부동산 모듈이 워크스페이스 하나에 프로퍼티 여럿을 둘지는 아직 정하지 않았습니다.
이 단계를 처음에는 「부동산」이라고 불렀습니다. 2026-10-22 KST에 오너가 「프로퍼티」(Property, 코드 property)로 바꿨습니다. 코드 키 · Leyve 화면 · 공간 정보 표준이 이미 이 이름을 쓰고, 업계 용어 프로퍼티 매니지먼트와도 맞기 때문입니다. 「부동산」은 이제 업종 · 분류 이름(코드 자리 6xx 부동산 운영 · 7xx 부동산 거래)으로만 씁니다.
요금을 붙이는 귀속 범위는 이 위아래와 다를 수 있습니다. 프로퍼티와 회의는 데이터로는 위아래이지만, 요금을 붙일 때는 둘 다 「자원」입니다(2026-10-22 KST 오너 정리).
자산(Asset, 코드 asset)은 이 위아래와 따로 둡니다. 소유하거나 사고파는 대상이고, 자산 레코드 하나가 프로퍼티 하나(소유자가 하나인 건물 전체)나 유닛 하나(집합건물의 호실 단위 소유)를 가리킵니다. 같은 「자산관리」라는 말이 운영에도, 매매에도, 회계에도 쓰였기 때문에 세 이름으로 나눕니다(2026-10-22 KST 오너 결정).
| 이름 | 영문 | 다루는 것 | 모듈 |
|---|---|---|---|
| 프로퍼티 관리 | Property Management (PM) | 운영: 관리비 · 임대차 · 시설 | 관리비관리, 임대차관리, 시설관리 |
| 자산 관리 | Asset Management (AM) | 소유 · 투자: 매물 · 거래, 분양 | 매물 · 거래, 분양관리(출시 전) |
| 고정자산 관리 | Fixed Asset Management | 회계: 설비 · 비품 | 고정자산관리(LEY-MOD-014) |
유닛은 「에셋」으로 바꾸지 않습니다. 세대 · 호실은 프로퍼티 관리에서 공간이고, 자산은 프로퍼티 전체일 수도 있으며, 유닛은 가격표 · 콘솔 · 문서가 이미 쓰는 이름입니다. 외래어 표기는 「애셋」이 아니라 「에셋」이고, 화면에는 「자산」, 코드에는 asset을 씁니다. 매물 · 거래와 분양관리는 출시 전이라 제품 코드는 아직 바꾸지 않았습니다.
이름은 「워크스페이스」 · 「회의」로 둡니다. 「프로젝트」는 끝이 있는 일이나, 클라우드 서비스에서 자원과 청구를 담는 그릇으로 읽힙니다. 부동산 개발에서는 부동산보다 위의 사업을 뜻하기도 합니다. 「현장」은 부동산 제품에는 맞지만, 범용 ERP · CRM · 인사의 워크스페이스(부서 · 법인 · 팀)에는 맞지 않습니다. 가격은 조직 단위로 세지만, 청구서는 조직 하나로 받거나 워크스페이스마다 나눠 받을 수 있습니다.
실제 예: 투표 하나를 네 곳에서 팔기
투표의 모듈 키는 vote 하나입니다. 개발은 한 벌로 하고, 파는 곳마다 가격표가 가격과 과금 방식을 정합니다.
| 판매 위치 | 표기 | 명부 | 가입 |
|---|---|---|---|
| Leyve 플랫폼의 모듈 | 전자투표 | 프로퍼티의 세대·유닛 정보(Leyve 코어) | Leyve 계정 |
| Leyve의 프로덕트 | LeyVote | 프로퍼티 단계의 구성원 명부 | LeyVote 가입 |
| Arenity 플랫폼의 모듈 | 전자투표 | 구성원 명부(Arenity 코어) | Arenity 계정 |
| Arenity의 프로덕트 | ArenVote | 프로퍼티 단계의 구성원 명부 | 판매 접점을 만들 때 정함 |
- 플랫폼에서 쓸 때는 그 플랫폼의 공통 모듈을 씁니다. Leyve의 투표는 Leyve의 세대·유닛 정보를 명부로 쓰고 세대 요금을 다시 받지 않습니다.
- 프로덕트는 플랫폼 접두에 붙여 씁니다(LeyVote, ArenVote). 플랫폼 안의 모듈은 모듈 이름만 씁니다(전자투표, 관리비관리). 모듈은 프로덕트를 이루는 부품이어서 프로덕트 이름을 붙이지 않습니다(2026-10-21 KST 오너 결정). 저장소·도메인·코드 키는 소문자입니다(
vote,leyvote,arenvote,leyvote-console-proto). - 투표 프로덕트가 둘인 까닭은 유입입니다. 관리사무소 · 변호사사무소 · 재건축 등 양쪽 플랫폼에서 고객이 옵니다. 두 가격표는 같은 내용에서 출발하고, 가격은 가격표마다 따로 정합니다(2026-10-21 KST 오너 결정).
- 같은 사람도 브랜드마다 따로 가입합니다. 계정 기능의 코드는 공통 서비스 한 벌을 함께 쓰지만, 가입과 계정의 경계는 브랜드마다 둡니다. LeyVote 고객이 Leyve로 옮기려면 계정을 이관합니다.
마지막 항목은 이 구조 결정에서 검토 권장안과 다르게 정해진 유일한 항목입니다. 권장안은 공통 계정 하나에 브랜드별 가입 화면을 두는 것이었고, 오너는 브랜드마다 계정을 따로 두기로 정했습니다. 결정 기록은 이런 차이도 함께 남깁니다(3장).
코드 번호
가격표의 판매 항목에는 {계열}-{종류}-{번호} 코드가 붙습니다. 계열은 소속 플랫폼(LEY, ARN)이거나 공통 가격표(MSG, WEB)이고, 종류는 Core(BAS) · 모듈(MOD) · 부가 서비스(ADD) · 사용량(USG) · 용역(SVC)입니다. 추천 구성은 PST입니다. 프로덕트에는 자기 코드가 없습니다. 프로덕트는 가격표 하나와 그 번호 자리로 나타납니다.
번호의 백의 자리는 업무 영역입니다. 0xx는 플랫폼이고, 1~5xx는 재무 · 구매와 공급망 · 고객과 영업 · 인사 · 자산과 시설 순서입니다. 이 순서는 글로벌 ERP 제품이 업무를 나누는 방식을 따랐고, 모든 계열에서 뜻이 같습니다. 6~8xx는 계열마다 다른 업종이고(Leyve는 부동산 운영 · 부동산 거래 · 호스피털리티), 9xx는 투표입니다. 한 영역에 프로덕트 자리가 둘이어서 아직 출시하지 않은 프로덕트도 자리를 먼저 잡아 둡니다. LeyCERP는 600번대, LeyVote와 ArenVote는 900번대를 쓰고, 두 투표 프로덕트는 끝 번호가 같습니다.
옮기거나 없앤 번호는 다시 쓰지 않습니다. 같은 업무 모듈은 가격표가 달라도 모듈 키 하나로 이어서, 코드가 달라도 같은 모듈임을 알 수 있습니다(2026-10-21 KST 오너 결정).
같은 단어, 다른 계약
판매 용어를 정했다고 해서 기술 이름이 같은 뜻이 되지는 않습니다. 다음 이름은 겉모양이 비슷해도 다른 계약입니다.
| 판매 용어 | 비슷한 기술 이름 | 기술 이름의 뜻 |
|---|---|---|
| Core | Billing Core, Document Core, Platform Core | 계산·문서·인증 등 내부 구현 경계. 판매 항목이 아님 |
| 플랫폼 | client-platform, shared-platform | 실행 환경(web·iOS)과 공유 실행 기반(server·gateway) |
| 업무 모듈 | 코드·DB의 Product, ProductActivation | 기존 catalog·활성화 계약에 남은 이름 |
| 프로덕트 | 결제 catalog의 product_key | 그 catalog가 정한 안정 식별자. 가격을 가진 판매 항목 |
| 플랫폼·프로덕트·단독 브랜드 | 저장소·호스트 이름의 product | route namespace. 모듈 키나 product_key와 자동으로 같지 않음 |
이 구분에서 두 규칙이 나옵니다.
- 문서 어휘를 맞춘다는 이유로 코드·DB의 문자열을 일괄 치환하지 않습니다. field·enum·API 변경은 그 런타임을 소유한 저장소가 계약을 확인한 뒤 이행합니다. 2026-10-21 KST 오너 결정으로 프로덕트 코드 키를 프로덕트 이름에 맞출 때(
leyvote→arenvote등)도 소유 저장소가 자기 PR에서 이 순서로 바꿉니다. - 업무 모듈과 저장소·서비스가 1:1이어야 한다는 규칙은 없습니다. 한 저장소가 여러 모듈을 구현하거나, 한 모듈이 여러 배포 단위를 쓸 수 있습니다. 모듈마다 저장소를 자동으로 만들지 않습니다(19장).
경계와 예외
- 이 장에는 금액이 없습니다. 금액은 플랫폼과 브랜드마다 있는 가격표가 소유합니다. 계산 방식은 23장과 가격 규칙이 다룹니다.
- 추천 구성과 등급 이름은 모듈 묶음에 붙인 이름일 뿐입니다. 계산기는 이 이름을 모르고 모듈 단위로 셉니다.
- PMS처럼 여러 모듈을 가리키는 업계 용어는 설명에만 씁니다. 판매 이름으로는 추천 구성 이름을 씁니다. LeyCERP의 C(Charge)와 ERP, LeyERP의 ERP처럼 프로덕트 이름에 든 약어는 오너가 정한 프로덕트 이름입니다.
- 구조와 용어는 확정됐고 가격표에는 반영했습니다. 코드에는
Product나organization-base같은 이전 이름이 남아 있을 수 있습니다. - 공통 서비스 목록에 있다고 해서 그 기능을 하나의 API가 모두 제공하거나 운영 준비가 끝났다는 뜻은 아닙니다. 실제 제공 상태는 23장에서 구분합니다.
정리
- 제품은 공통 서비스 → 공통 모듈 → 업무 모듈의 세 층이고, 의존은 아래로만 향합니다.
- 가격표마다 필수 Core가 하나 있고, 조직 기본료는 따로 없습니다. 부과 단위는 가격표의 판매 단위입니다.
- 업무 모듈은 모듈 키 하나로 만들어 플랫폼 모듈과 플랫폼 소속 프로덕트로 함께 팝니다. 가격은 판매처마다 정합니다.
- 프로덕트 이름은 플랫폼을 따릅니다(Leyve → LeyVote · LeyCERP · LeyERP · LeyCRM, Arenity → ArenVote).
- 프로덕트는 플랫폼에서 업무 모듈 하나를 떼어 낸 것이고, 등급에 보조 업무 모듈을 더할 수 있습니다.
- 모듈 이름에는 프로덕트 이름을 붙이지 않습니다. SKU 번호의 백의 자리는 업무 영역이고, 프로덕트에는 자기 SKU가 없습니다.
- 판매 용어와 기술 이름은 같은 단어라도 다른 계약입니다. 문서 정리만으로 코드 식별자를 바꾸지 않습니다.
정본
- 제품 구조와 용어 — 세 층, 파는 단위, 규칙 S1–S7, 현재 플랫폼과 브랜드
- 문서 소유권과 아키텍처 경계 — 같은 단어의 계약 구분
- 가격 규칙 — Core와 모듈의 계산 규칙
- 과금 구조 — 대상 · 과금 지표 · 요율, 필수 기본 항목, 지금 받는 요금, 별도 청구 비용, 청구서 단위
- Leysys Docs 결정 기록
PRODUCT-STRUCTURE-2026-09-25— 오너가 답한 질문과 검토한 선택지 - Leysys Docs 결정 기록
PRODUCT-STRUCTURE-CORE-EVERY-PRICE-LIST-2026-10-04— Core를 단독 브랜드 가격표까지 넓힌 개정 - Leysys Docs 결정 기록
PRODUCT-FAMILY-NAMING-2026-10-21— 프로덕트를 플랫폼 아래에 두고 LeyVote · ArenVote로 나눈 개정, 관리비 프로덕트 LeyCERP와 등급의 보조 모듈을 정한 추가 결정, 모듈 이름 · 전자서명과 간편인증 · SKU 코드 체계를 정한 추가 결정, Arenity 모듈을 「문서 서명」으로 바꾼 다음 날 결정, 회의 개설비와 데이터 구조를 정한 다음 날 결정, 세팅비 · 인건비 · 이름 · 청구서 단위를 정한 다음 날 결정, 직접 입력 · 프로퍼티 · 자산을 정한 다음 날 결정