다크모드
Organization·Workspace 로그인과 관리
계정·권한 용어의 정본은 IAM·권한 용어 정본을 참조하세요.
로그인 운영 점검
- 로그인 첫 선택은 Workspace / Organization입니다. 서비스 주소로 바로 접근하거나 일반 로그아웃을 마치면 Workspace 로그인이 기본으로 열립니다.
- 워크스페이스 로그인은
워크스페이스 코드 + 로그인 ID + 패스워드를 사용합니다. 한 사용자는 Organization의 실제 직원이 아니어도 접근 허가된 여러 Workspace를 가질 수 있습니다. - 조직 로그인은
이메일 + 패스워드또는조직 코드 + 로그인 ID + 패스워드중 하나를 선택합니다. - 이메일 한 개에 여러 Organization Membership이 있으면 인증 후 Organization 선택 화면이 열립니다. 선택은 로그인 방법이 아니라 현재 업무 범위입니다.
- Organization ID와 Workspace ID는 화면에서 코드와 ID를 따로 입력하지만, 시스템 조회명은
{login_id}@{code}입니다. 사용자가@가 포함된 문자열을 직접 입력하지 않습니다. - Organization Code는
org-+ 소문자 Crockford Base32 10자, Workspace Code는ws-+ 소문자 Crockford Base32 10자입니다. 코드는 공개 식별자이며 패스워드가 아닙니다. - Platform Administrator는 고객 로그인 화면에서 선택하지 않습니다. 슈퍼관리자 토글 없이 별도 운영자 포털과 인증 영역을 사용합니다.
- 계정 상태가 활성인데도 실패하면 로그인 시각과 계정 종류만 전달하고, 패스워드 초기화는 본인 확인 후 별도 절차로 진행합니다.
현재 Prototype 연결 상태
| 흐름 | 상태 |
|---|---|
| Workspace/Organization 화면·canonical route·선택 화면 | ✅ 구현 |
| Organization 이메일 로그인과 복수 Organization 선택 | ✅ Supabase IAM 연결 |
| 워크스페이스 코드 + 로그인 ID | ✅ Prototype IAM 연결 |
| 조직 코드 + 로그인 ID | ✅ Prototype IAM 연결 |
| Principal·Affiliation·Membership·Role·Session 감사 | ✅ Supabase Prototype 구현 |
| Platform Administrator 별도 운영자 인증 | ❌ 고객 콘솔에 미노출, 별도 제품에서 구현 |
현재 Prototype은 Supabase Auth를 패스워드 검증 수단으로 사용하지만, 로그인 ID와 권한은 Auth 이메일이나 화면 선택값에서 만들지 않습니다. 서버의 Principal, Organization Affiliation, Organization/Workspace Membership, Role Assignment를 확인한 뒤 로그인 문맥이 기록된 세션을 생성합니다. 실서비스 전환 대상은 AWS + RDS MariaDB이며 Supabase RLS 자체가 제품 계약은 아닙니다.
Leyve 계약·결제 주체는 Organization, 실제 업무·장부 단위는 Workspace입니다. 기존 업무 화면과 데이터에서 보이는 Company는 Organization, Office는 Workspace에 대응합니다. 나머지 관리 화면의 용어 전환은 단계적으로 진행합니다.
Organization을 만들면 Workspace 0이 ${조직명} 본점 이름의 기본 업무공간으로 함께 생성됩니다. Workspace 0은 데모가 아니라 본사 회계·인사처럼 실제 업무에 쓰는 장부 범위입니다. 이후 만드는 현장·지점은 Workspace 1부터 차례로 번호를 받습니다.
표준 절차
- 최고관리자는 왼쪽 메뉴 맨 아래
조직관리 → Organization → Workspace·권한에서 Workspace를 조회·생성합니다. 일반 직원에게는조직관리가 표시되지 않습니다.- 생성 시트는 다음 번호를
Office 1처럼 표시합니다. Office 번호와 Office 등록코드는 생성 후 바뀌지 않으며 삭제된 번호를 다시 사용하지 않습니다. 이름·주소처럼 바뀔 수 있는 정보만 이후 정정합니다. - Office 이름·에디션·주소·유닛 수를 입력하고 Company가 계약한 상품 중 사용할 상품을 확인합니다.
- 프로퍼티 에디션은 이름과 법정동이 포함된 주소를 입력한 뒤 공공데이터에서 찾기를 누를 수 있습니다. 후보를 선택하면 도로명주소, 호실 수, 전유·공용면적 스냅샷이 Office와 함께 저장됩니다.
- data.go.kr 키는 Leyve가 한 번 연결하며 Company나 Office마다 입력하지 않습니다. 조회할 수 없으면 Office를 생성한 뒤 프로퍼티 설정에서 다시 조회하거나 직접 입력합니다.
- 생성한 계약 관리자는 해당 Office의
Office 관리자권한을 자동으로 받습니다. 관리자 이름을 별도로 입력하지 않습니다. - Office 0에는 가입만으로 상품이 자동 배정되지 않습니다. 본점에서 실제 사용할 상품만 별도로 배정하며, 프로퍼티 유닛 수 기반 과금에는 포함하지 않습니다.
- 생성 시트는 다음 번호를
- Organization 사용자는 이메일 또는 Organization 코드 + 로그인 ID로 로그인합니다. 활성 Organization이 1개면 바로 진입하고, 여러 개면 회사명·사업자등록번호를 확인해 Organization을 선택합니다.
- Workspace 사용자는 Workspace 코드 + 로그인 ID로 로그인합니다. Organization Membership이 없어도 되지만 Organization Affiliation과 활성 Workspace Membership이 필요합니다.
- 상단
Workspace 전환을 열고 이름·번호·코드·주소를 확인한 뒤 선택 행을 누르고전환해 업무 범위를 확정합니다. Organization을 바꾸려면 하단의 Organization 전환을 사용합니다. - 상단 전환 목록에는 Workspace만 표시됩니다. 계약·결제·Workspace·권한 같은 전사 관리는 가상 Company 범위를 선택하지 않고 왼쪽 메뉴 맨 아래
조직관리에서 수행합니다.
계정 책임 경계
- Organization 사용자는 이메일 또는 Organization ID로 로그인하며 계약·결제, Workspace 생성, 상품 및 사용자 권한을 관리합니다.
- Workspace 사용자는
Workspace 코드 + 로그인 ID + 패스워드로 로그인합니다. 현장직·협력업체처럼 Organization의 실제 직원이 아닌 사람도 포함하며, 한 사람에게 여러 Workspace 역할을 부여할 수 있습니다. - Organization Affiliation은 조직별 프로필·관리·좌석·수명주기를 담지만 접근권을 만들지 않습니다. 실제 접근은 Organization/Workspace Membership과 Role이 결정합니다.
- 사용 중지는 해당 Affiliation/Membership 접근을 차단하되 다른 Organization의 같은 Principal까지 잠그지 않습니다.
- 역할은 Workspace마다 독립적으로 부여합니다.
Workspace 관리자,경리·회계,운영 담당,조회 전용중 필요한 최소 역할만 사용합니다.
로그인 후 상태
| 계정 | 상태 | 화면 동작 |
|---|---|---|
| Organization 사용자 | Organization 1개 | 해당 Organization으로 바로 진입 |
| Organization 사용자 | Organization 여러 개 | 회사명·사업자등록번호로 검색·선택 후 진입 |
| Organization 사용자 | 활성 Organization 없음 | 지원팀에 Organization 권한을 문의하도록 안내 |
| Workspace 사용자 | Workspace 1개 | 해당 Workspace로 바로 진입 |
| Workspace 사용자 | Workspace 여러 개 | 검색 가능한 선택 화면에서 확정 후 진입 |
| Workspace 사용자 | 배정 Workspace 없음 | 관리자에게 Workspace·역할 배정을 요청하도록 안내 |
| 공통 | 초대 대기·계정 중지 | 관리자에게 확정·재개를 요청하고 업무 진입 차단 |
| 공통 | 로딩·오류 | 진행 상태와 재시도 동작을 분리 표시 |
브라우저를 새로 열거나 로그인 토큰이 갱신되면 Leyve는 저장된 화면 상태를 그대로 신뢰하지 않고 현재 서버 계정의 활성 Organization·Workspace·상품 권한을 다시 확인해야 합니다. 이전 선택이 유효하면 이어서 사용하고, 권한이 철회됐거나 유효한 선택이 없으면 Organization 또는 Workspace 선택 화면으로 돌아갑니다.
Organization 이메일로 여러 Organization에 접근할 수 있는 경우, 선택한 Organization은 iam-context를 통해 현재 서버 세션에 바인딩됩니다. 이 선택은 새로운 권한을 만들지 않으며, 해당 Principal에게 이미 활성 Membership이 있는지 서버가 다시 확인합니다.
Organization 목록의 개수는 전체 관리자 수가 아니라 현재 Principal의 활성 Organization Membership 수입니다. 한 Organization에 여러 관리자가 있어도 선택 목록에는 해당 Organization이 한 번만 나타나야 합니다.
변경 이력
조직관리 → Organization → 조직 계정에서 직원 초대·활성·중지, 역할 부여·변경·회수, Organization·Workspace 전환 이력을 확인합니다. 로그인 성공은 Supabase Prototype의 append-only authorization_audit_events에 세션·Principal·Organization/Workspace·결정 사유·hash chain 정보로 기록됩니다. 운영 제품은 별도 보안 계정과 외부 tamper-evident 저장소까지 사용해야 합니다.
Office 생성 결과, 최초 상품 권한, 선택한 공공데이터 스냅샷은 서버의 한 트랜잭션으로 함께 저장됩니다. 100개 이상 Office 검색은 현재 클라이언트 방식이며 운영 제품에서는 서버 검색·페이지네이션·가상 스크롤을 적용합니다.
여러 Workspace를 아우르는 계약·결제·권한 관리는 조직관리에서 수행합니다. 상단 Workspace 전환 목록에 Organization을 Workspace처럼 섞지 않습니다.