Organization·Workspace 로그인과 관리

계정·권한 용어의 정본은 IAM·권한 용어 정본을 참조하세요.

로그인 운영 점검

• 로그인 첫 선택은 조직 / 워크스페이스입니다. 두 항목은 연결형 내비게이션으로 보이지만 서로 다른 로그인 경로로 이동합니다. 서비스 주소로 바로 접근하거나 일반 로그아웃을 마치면 조직 로그인이 기본으로 열립니다.
• 워크스페이스 로그인은 워크스페이스 코드 + 아이디 + 패스워드를 사용합니다. 한 사용자는 조직의 실제 직원이 아니어도 접근 허가된 여러 워크스페이스를 가질 수 있습니다.
• 조직 로그인은 기본으로 조직 코드 + 아이디 + 패스워드를 받습니다. Organization 최고관리자/중간관리자/조회자는 이 방식을 사용합니다. active Organization Owner만 조직 코드 오른쪽의 이메일로 로그인 스위치를 켜 이메일 인증을 이용할 수 있습니다. 이때 조직 코드는 로그인 후 선택 안내와 함께 비활성화되고 아이디 자리가 이메일로 바뀝니다. 두 인증 방식은 같은 화면에서 전환되며 카드 하단의 계정 찾기와 계정 생성은 두 방식에서 항상 표시됩니다. 계정 찾기의 이메일 재설정은 Owner 계정만 지원하며 username self-service 복구는 제공하지 않습니다.
• 이메일 한 개에 active Owner인 Organization이 여러 개면 인증 후 조직 선택 화면이 열립니다. 선택은 로그인 방법이 아니라 현재 업무 범위입니다.
• 조직·워크스페이스 아이디는 화면에서 각 코드와 username을 따로 입력합니다. 서버는 이를 sign_in_identifier_key로 정규화하며 사용자가 composite 문자열을 직접 입력하지 않습니다.
• 조직 코드는 org- + 소문자 Crockford Base32 10자, 워크스페이스 코드는 ws- + 소문자 Crockford Base32 10자입니다. 코드는 공개 식별자이며 패스워드가 아닙니다.
• Leysys 본사 staff는 고객 로그인 화면에서 선택하지 않습니다. platform/ superadmin 고객 Role 토글 없이 별도 ops-center surface와 staff 인증 영역을 사용합니다.
• 계정 상태가 활성인데도 실패하면 로그인 시각과 계정 종류만 전달하고, 패스워드 초기화는 본인 확인 후 별도 절차로 진행합니다.

현재 Prototype 연결 상태

흐름	상태
조직/워크스페이스 화면·canonical route·선택 화면	✅ 구현
Organization Owner 이메일 로그인과 복수 조직 선택	✅ Supabase IAM 연결
워크스페이스 코드 + 아이디	✅ Prototype IAM 연결
조직 코드 + 아이디	✅ Prototype IAM 연결
Principal·Affiliation·Membership·Role·Session 감사	✅ Supabase Prototype 구현
ops-center staff 별도 인증	❌ 고객 콘솔에 미노출, 별도 surface에서 구현

현재 Prototype은 Supabase Auth를 패스워드 검증 수단으로 사용하지만, username과 권한은 Auth 이메일이나 화면 선택값에서 만들지 않습니다. 서버의 Principal, Organization Affiliation, Organization/Workspace Membership, Role Assignment를 확인한 뒤 SignIn 문맥이 기록된 세션을 생성합니다. 실서비스 전환 대상은 AWS + RDS MariaDB이며 Supabase RLS 자체가 제품 계약은 아닙니다.

Leyve 계약·결제 주체는 Organization, 실제 업무·장부 단위는 Workspace입니다. Supabase 물리 DB, RPC, Edge payload와 프런트엔드 DTO도 이 두 이름을 동일하게 사용하며 이전 scope 명칭의 alias나 fallback은 두지 않습니다.

조직을 만들면 워크스페이스 0이 ${조직명} 본점 이름의 기본 업무공간으로 함께 생성됩니다. 워크스페이스 0은 데모가 아니라 본사 회계·인사처럼 실제 업무에 쓰는 장부 범위입니다. 이후 만드는 현장·지점은 워크스페이스 1부터 차례로 번호를 받습니다.

표준 절차

1. 조직 소유자 또는 조직 최고관리자는 왼쪽 메뉴 맨 아래 조직관리 → 조직 → 워크스페이스·권한에서 워크스페이스를 조회·생성합니다. 일반 직원에게는 조직관리가 표시되지 않습니다.
   • 생성 시트는 다음 번호를 워크스페이스 1처럼 표시합니다. 워크스페이스 번호와 워크스페이스 등록코드는 생성 후 바뀌지 않으며 삭제된 번호를 다시 사용하지 않습니다. 이름·주소처럼 바뀔 수 있는 정보만 이후 정정합니다.
   • 워크스페이스 이름·에디션·주소·유닛 수를 입력하고 조직이 계약한 상품 중 사용할 상품을 확인합니다.
   • 프로퍼티 에디션은 이름과 법정동이 포함된 주소를 입력한 뒤 공공데이터에서 찾기를 누를 수 있습니다. 후보를 선택하면 도로명주소, 호실 수, 전유·공용면적 스냅샷이 워크스페이스와 함께 저장됩니다.
   • data.go.kr 키는 Leyve가 한 번 연결하며 조직이나 워크스페이스마다 입력하지 않습니다. 조회할 수 없으면 워크스페이스를 생성한 뒤 프로퍼티 설정에서 다시 조회하거나 직접 입력합니다.
   • Organization Owner/Admin Role은 생성한 Workspace에 각각 Workspace Owner/Admin으로 자동 투영됩니다. 동일 책임을 위한 직접 Workspace Role을 중복 생성하거나 최고관리자 이름을 별도로 입력하지 않습니다.
   • 워크스페이스 0에는 계정 생성만으로 상품이 자동 배정되지 않습니다. 본점에서 실제 사용할 상품만 별도로 배정하며, 프로퍼티 유닛 수 기반 과금에는 포함하지 않습니다.
2. Organization 소유자는 이메일로, 최고관리자/중간관리자/조회자는 조직 코드 + 아이디로 로그인합니다. Owner인 활성 조직이 1개면 바로 진입하고, 여러 개면 회사명·사업자등록번호를 확인해 조직을 선택합니다.
3. 워크스페이스 사용자는 워크스페이스 코드 + 아이디로 로그인합니다. Organization Membership이 없어도 되지만 Organization Affiliation과 활성 Workspace Membership이 필요합니다.
4. 상단 워크스페이스 전환을 열고 이름·번호·코드·주소를 확인한 뒤 선택 행을 누르고 전환해 업무 범위를 확정합니다. 다른 조직으로 이동하려면 하단의 다른 조직 계정으로 로그인을 눌러 현재 세션을 종료하고 다시 로그인합니다.
5. 상단 전환 목록에는 워크스페이스만 표시됩니다. 계약·결제·워크스페이스·권한 같은 전사 관리는 가상 조직 범위를 선택하지 않고 왼쪽 메뉴 맨 아래 조직관리에서 수행합니다.

계정 책임 경계

• 조직 사용자 중 소유자는 이메일, 최고관리자/중간관리자/조회자는 조직 아이디로 로그인합니다. 인증 방법은 Role key와 별도 축이지만, 제품 정책상 이메일 경로는 active Owner에게만 허용합니다.
• 워크스페이스 사용자는 워크스페이스 코드 + 아이디 + 패스워드로 로그인합니다. 현장직·협력업체처럼 조직의 실제 직원이 아닌 사람도 포함하며, 한 사람에게 여러 Workspace의 역할을 각각 하나씩 부여할 수 있습니다.
• Organization Affiliation은 조직별 프로필·관리·좌석·수명주기를 담지만 접근권을 만들지 않습니다. 실제 접근은 Organization/Workspace Membership과 Role이 결정합니다.
• 사용 중지는 해당 Affiliation/Membership 접근을 차단하되 다른 Organization의 같은 Principal까지 잠그지 않습니다.
• Organization과 Workspace 기본 역할은 모두 소유자, 최고관리자, 중간관리자, 조회자 4단계입니다. Workspace에도 별도의 워크스페이스 소유자 Role이 있습니다.
• 소유자는 소유권·Owner·종료, 최고관리자는 설정·구성원·Owner 아래 Role, 중간관리자는 일상 업무·비민감 운영 상태, 조회자는 조회만 담당합니다. Organization 소유자만 계약·결제를 관리합니다.
• 기본 Role은 테넌트 업무 권한의 상한선입니다. 조회자에게 별도 업무 권한을 추가해도 생성·수정·삭제 권한은 열리지 않습니다. 본인 신청 같은 포털 self-service는 별도의 주체 권한으로 처리합니다.
• Organization Role은 산하 Workspace에 같은 등급으로 자동 투영됩니다. Workspace 직접 Role은 투영 Role보다 엄격히 높은 경우에만 저장하며 해당 Workspace에서만 효력을 갖습니다. 같거나 낮은 중복 부여는 거부합니다.
• operator | auditor | contract_admin | accountant는 초기 Role에서 제외합니다. 고위험 승인·반출·마감과 직무별 차이는 서버 도메인 정책으로 추가 제한합니다.

로그인 후 상태

계정	상태	화면 동작
조직 사용자	조직 1개	해당 조직으로 바로 진입
조직 사용자	조직 여러 개	회사명·사업자등록번호로 검색·선택 후 진입
조직 사용자	활성 조직 없음	지원팀에 조직 권한을 문의하도록 안내
워크스페이스 사용자	워크스페이스 1개	해당 워크스페이스로 바로 진입
워크스페이스 사용자	워크스페이스 여러 개	검색 가능한 선택 화면에서 확정 후 진입
워크스페이스 사용자	배정 워크스페이스 없음	소유자 또는 최고관리자에게 워크스페이스·역할 배정을 요청하도록 안내
공통	초대 대기·계정 중지	소유자 또는 최고관리자에게 확정·재개를 요청하고 업무 진입 차단
공통	로딩·오류	진행 상태와 재시도 동작을 분리 표시

브라우저를 새로 열거나 로그인 토큰이 갱신되면 Leyve는 저장된 화면 상태를 그대로 신뢰하지 않고 현재 서버 계정의 활성 조직·워크스페이스·상품 권한을 다시 확인해야 합니다. 이전 선택이 유효하면 이어서 사용하고, 권한이 철회됐거나 유효한 선택이 없으면 조직 또는 워크스페이스 선택 화면으로 돌아갑니다.

조직 이메일로 Owner인 여러 조직에 접근할 수 있는 경우, 선택한 조직은 iam-context를 통해 현재 서버 세션에 바인딩됩니다. 이 선택은 새로운 권한을 만들지 않으며, 해당 Principal에게 active Membership과 organization.owner가 있는지 서버가 다시 확인합니다.

이메일 로그인 후 조직 목록의 개수는 전체 조직 사용자 수가 아니라 현재 Principal이 active Owner인 Organization 수입니다. 한 조직에 Owner가 여러 명이어도 선택 목록에는 해당 조직이 한 번만 나타나야 합니다.

변경 이력

조직관리 → 조직 → 조직 계정에서 이미 서버에 프로비저닝된 구성원의 역할 부여·변경·회수와 조직·워크스페이스 전환 이력을 확인합니다. 신규 구성원 초대·Auth user 생성·username 발급을 원자적으로 묶는 서버 프로비저닝은 아직 제공하지 않으므로 Supabase 환경의 생성·상태 버튼은 비활성화합니다. 로그인 성공은 Supabase Prototype의 append-only authorization_audit_events에 세션·Principal·Organization/Workspace·결정 사유·hash chain 정보로 기록됩니다. 운영 제품은 별도 보안 계정과 외부 tamper-evident 저장소까지 사용해야 합니다.

워크스페이스 생성 결과, 최초 상품 권한, 선택한 공공데이터 스냅샷은 서버의 한 트랜잭션으로 함께 저장됩니다. 100개 이상 워크스페이스 검색은 현재 클라이언트 방식이며 운영 제품에서는 서버 검색·페이지네이션·가상 스크롤을 적용합니다.

여러 워크스페이스를 아우르는 조직 정보·Workspace·권한 관리는 조직관리에서 수행합니다. 새 상품 계약·결제 변경은 그 안에서도 Owner 이메일로 로그인한 Organization 소유자에게만 허용합니다. 상단 Workspace 전환 목록에 Organization을 Workspace처럼 섞지 않습니다.