Skip to content

접근 역할 체계 ​

상태: 공통 표준 — 2026-10-03 KST 오너 확정, 2026-10-04·2026-10-11 KST 개정

적용 대상: company-wide — 조직·워크스페이스 범위를 가진 Leysys 제품·서비스의 직원 접근 역할, 조직 소유, 역할 부여, 권한 판정, 행위 주체 기록, 화면 표현

정본 분류: 이 페이지는 leysys-design의 결정 기록 ACCESS-ROLE-SYSTEM-2026-10-03을 회사 공통 표준으로 공개합니다. 규칙을 바꿀 때는 결정 기록과 이 페이지를 같은 변경에서 함께 고칩니다. 권한 없음 화면·역할 배지·문구 같은 접근 UX의 구현 정본은 leysys-design이, 각 제품의 권한 표·채택 현황·의도적 편차는 해당 제품 저장소와 제품 Docs가 소유합니다. 문서 변경은 런타임 채택을 증명하지 않습니다.

직원이 무엇을 할 수 있는지는 역할로, 조직 계정을 최종 통제하는 책임은 조직 소유로 정합니다. 조직이 계약한 기능은 모듈이, 레코드를 책임지는 사람은 담당이 정하며 역할과 섞지 않습니다.

역할 ​

값한국어English할 수 있는 일범위
admin관리자Admin사람·역할·설정·워크스페이스 관리와 모든 업무조직 · 워크스페이스
editor편집자Editor업무 데이터 생성·편집·삭제(복구할 수 있는 삭제). 사람·역할·설정은 바꾸지 않습니다.조직 · 워크스페이스
viewer조회자Viewer업무 데이터 조회. 민감한 정보는 제품이 가리고 생성·편집·삭제는 하지 않습니다.조직 · 워크스페이스
  • 위 등급은 아래 등급의 권한을 모두 가집니다. 조직과 워크스페이스는 같은 세 값을 쓰고, 표·선택·범례는 언제나 위 등급부터 나열합니다.
  • 역할 라벨은 권한 묶음의 이름이고, 허용 범위는 한 줄 설명이 맡습니다.
  • admin은 Kubernetes 등이 쓰는 표준 역할 값이라 줄임말 금지 규칙의 예외로 둡니다.

조직 소유 ​

관계한국어English하는 일범위
organization.owner조직 소유자Organization owner계약 체결·해지, 청구 역할의 부여·회수, 조직 소유자 지정·회수·이전, 조직 종료조직
  • 조직 소유는 역할이 아니라 조직 관계입니다. 소유는 조직 계정을 최종 통제하는 책임이고 역할은 접근 수준이라 종류가 다릅니다. 관계로 나누면 조직과 워크스페이스가 같은 역할 집합을 쓰고 상속에 변환 규칙이 없습니다.
  • 조직 소유자는 조직 관리자 역할을 가져야 합니다(전제 역할). 그래서 관리자는 조직 소유자의 관리자 역할을 낮추거나 회수하지 못합니다.
  • 유효 조직 소유자를 언제나 한 명 이상 둡니다(부여 규칙).
  • 조직 소유자는 접근 체계 안의 지정이며 법적 소유(지분)와는 관계가 없습니다. 조직은 운영·접근 범위이고, 계약 당사자는 명시적 당사자 참조로 연결합니다. 기본값은 조직 프로필의 당사자이며 조직 ID와 당사자 ID를 합치지 않습니다. 자세한 관계는 사용자·조직·현장과 계약·결제를 따릅니다.
  • 라벨은 언제나 「조직 소유자」입니다. 부동산·투표 업무의 소유자(구분소유자)와 겹치지 않게 하려는 것입니다.
  • 워크스페이스 소유는 없습니다. 계약은 조직 범위에서 관리하며 계약마다 당사자를 명시합니다.

범위와 상속 ​

  • 역할은 조직과 워크스페이스에만 둡니다. 플랫폼 범위 역할(슈퍼 관리자)도, 레코드·회의·사건·강좌 범위 역할도 두지 않습니다. 레코드 단위 차이는 담당·작성자·결재선 같은 관계 조건으로 표현합니다.
  • 조직 역할은 그 조직의 모든 공개 워크스페이스에 같은 값으로 적용합니다. 조직 소유자는 조직 관리자 역할을 가지므로 워크스페이스에서도 관리자입니다.
  • 유효 워크스페이스 역할은 직접 워크스페이스 역할과 상속 역할 중 높은 쪽입니다. 직접 역할은 상속 등급보다 높을 때만 둡니다.
  • 조직 역할 없이 소속만 있는 사람은 워크스페이스 역할로만 일합니다.

비공개 워크스페이스 ​

  • 비공개 워크스페이스(is_private)에는 상속이 들어가지 않습니다.
  • 직접 역할이 없는 사람에게는 없는 워크스페이스처럼 보입니다(404). 조직 관리자만 조직 관리 화면에서 존재를 보고, 사유를 남겨 관리자로 참여할 수 있습니다. 참여는 감사 기록에 남습니다.
  • 공개·비공개 전환은 조직 관리자만 하고 사유와 함께 감사 기록에 남깁니다. 비공개로 바꾸면 상속 역할이 바로 끊기고, 공개로 바꾸면 상속 등급보다 같거나 낮은 직접 역할을 정리합니다.
  • 기본값은 제품이 정합니다. 사건마다 비밀유지가 필요한 제품은 기본 비공개가 맞고, 그 밖의 제품은 기본 공개로 두고 필요한 워크스페이스만 비공개로 바꿉니다.

역할이 아닌 것 ​

개념예규칙
소속직원 · 파트너 · 협력사 · 외부업무 데이터 접근을 주지 않습니다. 본인 레코드와 조직 기본 정보만 봅니다.
계정 유형·로그인 방법조직 계정(아이디 · 조직 소유자 이메일), 워크스페이스 계정세션 범위를 좁힐 뿐 역할을 만들지 않습니다.
대상·접점 유형저장소·호스트 네이밍의 audience·surface역할 값이나 판정 입력으로 쓰지 않습니다.
조직 자격운영사(Leysys 본사) · 파트너 · 입점업체 · 고객사조직의 성격입니다. 역할과 함께 조건으로 확인합니다.
모듈 이용모듈조직이 계약한 기능입니다. 없으면 역할과 무관하게 쓸 수 없습니다.
담당담당 · 배정사람과 레코드를 잇는 관계입니다. 코드 이름은 assignee입니다.
직위·직책사원 · 팀장표시 정보이며 판정에 쓰지 않습니다. 팀장이 곧 관리자는 아닙니다.
결재선결재선 · 결재자문서마다 정해지는 경로입니다. 결재할 수 있는 근거는 결재선에 있다는 사실입니다.
이용자 관계입주민 · 조합원 · 유권자 · 의뢰인 · 수강생포털 이용자의 관계이며 직원 역할 체계 밖에 둡니다.
인증 수준본인 확인 단계민감한 동작을 막을 수만 있고 허용하지 않습니다.
인증 주체사람 계정 · 서비스 계정 · AI 에이전트접근 요청에서 인증·인가 대상으로 식별하는 주체입니다. 판정은 이 주체의 역할·추가 역할·조직 소유로 합니다.
행위 주체사람 · 조직 · 소프트웨어업무 사건을 수행한 것으로 기록하는 주체입니다. 기록된다는 사실만으로 접근을 얻지 않습니다.
사용자 그룹함께 관리할 사용자 모음역할이 아니며 지금은 두지 않습니다. 도입하면 역할 부여 대상으로만 씁니다.
  • 역할은 「부여」, 조직 소유는 「지정」, 담당은 「배정」이라고 부릅니다.
  • 같은 사람이 직원이면서 포털 이용자일 수 있습니다. 직원 역할과 이용자 관계는 서로를 근거로 생기거나 넓어지지 않습니다. 두 계정은 자동으로 잇지 않고, 본인 확인을 거친 명시적 연결로만 잇습니다.
  • 「권한」은 저장 값이나 열 이름이 아니라 판정 결과(할 수 있는지)를 말할 때만 씁니다. 역할을 보여 주는 열 제목은 「역할」입니다.

부여 규칙 ​

  • 누가 부여하는가
    • 조직 관리자는 조직 범위에서 관리자까지 다루며, 다른 조직 관리자도 부여·회수할 수 있습니다. 다만 조직 소유자의 관리자 역할은 낮추거나 회수하지 못합니다. 관리자 사이의 회수는 감사 기록으로 추적하고 조직 소유자에게 알립니다. 공개 워크스페이스에서는 모든 워크스페이스 역할을 다룹니다.
    • 워크스페이스 관리자 보호: 워크스페이스 관리자의 부여·회수는 조직 관리자만 합니다. 워크스페이스 관리자는 그 워크스페이스의 편집자·조회자만 다룹니다.
    • 조직 소유 지정과 회수는 조직 소유자만 합니다. 편집자와 조회자는 아무 역할도 다루지 않습니다.
  • 만들 때 받는 역할 — 조직을 만든 사람은 그 조직의 관리자 역할과 조직 소유 지정을 함께 받습니다. 워크스페이스 생성만으로 생성자에게 직접 역할을 부여하지 않습니다. 공개 워크스페이스는 조직 관리자 역할 상속만으로 운영할 수 있고, 현장 관리자 지정은 기존 사용자 선택 또는 새 사용자 초대의 선택 단계입니다. 비공개 워크스페이스의 업무 접근에는 직접 역할이 필요합니다. 직접 관리자 역할이 없는 조직 관리자는 먼저 사유와 감사 기록을 남겨 관리자로 참여한 뒤 업무와 역할을 관리합니다. 생성자도 이 조건을 생략하지 않습니다.
  • 자기 역할 — 자기 역할을 올리거나 바꾸지 못합니다. 스스로 나갈 수는 있지만 유효 조직 소유자가 0명이 되는 나감은 막습니다. 스스로 역할을 받는 경우는 조직 생성과 사유·감사 기록을 남기는 비공개 워크스페이스 참여뿐입니다.
  • 조직 소유
    • 유효 조직 소유자는 계정 활성, 소유 지정 활성, 검증된 이메일, 이메일이 아닌 2차 인증 등록을 모두 갖춘 사람입니다. 초대 중인 지정은 세지 않습니다.
    • 서버는 유효 조직 소유자를 언제나 한 명 이상 유지하고, 그 수를 0으로 만드는 변경을 모두 막습니다. 소유 지정 회수·나감, 관리자 역할 강등, 소속 종료, 계정 비활성화·잠금·삭제, 이메일 변경, 2차 인증 해제가 여기에 들어갑니다.
    • 소유 지정을 바꾸는 요청은 한 트랜잭션에서 조직 행을 잠근 뒤 세고 씁니다. 두 소유자가 동시에 서로를 회수해 0명이 되는 일을 막습니다.
    • 유효 조직 소유자가 한 명이면 두 명 이상을 권합니다. 지정될 사람은 조직 관리자 역할, 검증된 이메일, 2차 인증이 있어야 하고 재인증한 뒤 수락합니다. 지정을 회수하려면 그 사람에게 조직 아이디가 있어야 합니다.
    • 이전은 새 사람 지정 → 그 사람의 수락 → 기존 소유자가 지정을 내려놓는 세 단계입니다. 수락 전 지정은 세지 않으므로 기존 소유자가 먼저 나갈 수 없습니다.
    • 지정·회수·이전과 조직 종료는 이메일이 아닌 2차 인증으로 재인증합니다. 다른 소유자의 회수와 조직 종료는 모든 조직 소유자에게 알리고, 제품이 정한 유예 기간(0일이 아님) 동안 취소할 수 있게 합니다.
  • 자격 증명 — 다른 사람의 이메일·비밀번호·2차 인증·복구 경로를 바꾸거나 세션을 끊는 일은 같은 범위에서 대상보다 높은 사람만 합니다. 관리자는 편집자·조회자와 역할 없는 소속 계정을, 조직 소유자는 조직 관리자까지 다룹니다. 조직 소유자의 자격 증명은 본인만 바꿉니다.
  • 긴급 차단과 소유 복구 — 계정 탈취 같은 보안 사고에는 운영사가 세션을 끊고 계정을 잠급니다. 이때는 유효 조직 소유자가 0명이 되는 것을 허용하고 조직 소유에서 나온 동작을 멈춥니다. 새 조직 소유자는 증빙 심사, 기존 소유자 알림과 유예, 감사 기록을 거치는 운영사의 소유 복구 절차로 지정합니다.
    • 잠금은 사유(사고 대응 · 로그인 실패 · 약관 위반 정지)를 남기고 조직 관리자 · 조직 소유자 · 보안 연락처(역할이 아닌 연락처)에게 알립니다. 해제는 대상보다 높은 고객 쪽 사람이 비밀번호 재설정과 2차 인증 재확인을 거쳐 합니다.
    • 소유 복구는 유효 조직 소유자가 0명일 때만 합니다. 해당 계약 당사자의 유형에 맞는 본인·대표·위임 증빙과 기존 계약·결제·관리 관계를 확인합니다. 사업자등록이 있는 당사자는 그 증빙도 확인하되 비사업 개인에게 필수로 요구하지 않습니다. 7일 이의 기간, 기존 소유자 알림, 감사 기록, 운영사 안의 접수·승인 분리를 유지합니다. 개인 진술이나 신분 확인만으로 조직 소유를 지정하지 않으며 실제 제출 항목과 검증은 운영사 복구 절차가 소유합니다.
  • 초대 — 상태가 invited인 역할 부여 또는 조직 소유 지정입니다. 부여하거나 지정할 수 있는 사람만 초대하고, 수락 전에는 아무 접근도 주지 않으며, 기한이 지나면 종료(만료)합니다.
  • 떠날 때 — 소속이 끝나면 그 조직과 워크스페이스의 모든 역할 부여와 조직 소유 지정을 종료(회수)합니다. 계정 비활성화는 로그인만 막고, 계정 삭제는 역할 부여를 종료하고 이력에 「삭제된 계정」으로 남깁니다. 어느 경우든 유효 조직 소유자가 0명이 되면 막습니다.
  • 감사 기록 — 부여, 변경, 회수, 초대, 정지, 나감, 비공개 참여, 공개·비공개 전환, 조직 소유 지정·회수·이전, 다른 사람의 자격 증명 변경, 사고 대응 잠금, 소유 복구마다 행위 주체(유형·이름·소속), 인증 정보(인증 주체·위임 경로), 대상, 범위, 이전 → 이후 역할, 사유, 시각을 남깁니다. 법령이 남기라고 하는 개인정보 처리 기록(개인정보 열람·내보내기 등의 접속기록)도 업무 데이터가 아니라 감사 기록에 두고 관리자만 조회합니다.

권한 판정 ​

  • 기능 코드는 역할 이름을 비교하지 않고 can(principal, key, target)처럼 권한 키로 묻습니다. 역할 → 권한 키, 조직 소유 → 권한 키 대응은 제품마다 한 곳의 정적 표로 두고, 권한 표를 DB에 두거나 인증 주체별로 부여하지 않습니다. 서버 판정이 정본이고 화면은 같은 표로 숨김·비활성을 보여 주기만 합니다.
  • 인증 주체와 위임 — 판정 대상은 인증 주체입니다. 서비스·AI 에이전트 같은 소프트웨어 주체도 명시적인 역할 부여나 확인된 위임으로만 접근을 얻고, 행위 주체로 기록된다는 사실은 접근을 만들지 않습니다. 소프트웨어 주체가 다른 주체의 요청으로 실행하면 두 주체를 각각 판정하고 둘 다 가진 권한만 씁니다.
  • 권한 키 형식은 {domain}.{resource}.{action}입니다. 모든 마디는 snake_case이고 대상 다음에 동사를 둡니다. 예: crm.lead.update, access.role.grant, billing.invoice.read.
    • {domain}은 모듈 키 또는 공통 도메인(access, organization, workspace, audit, billing, messaging)입니다. 모듈 키를 코드에서 camelCase로 쓰더라도 권한 키에서는 같은 단어를 snake_case로 적습니다(memberRoster → member_roster.member.export).
    • 동사는 read · create · update · delete · export · send · approve · publish · grant · revoke 중에서 고릅니다. publish(발행)는 2026-10-18 KST에 견적 공통 계약을 위해 더했습니다. 초대는 access.role.grant, 정지·복구는 access.role.update, 회수는 access.role.revoke, 조직 소유 지정·회수는 access.ownership.grant · access.ownership.revoke입니다.
    • 목록과 상세 조회를 서로 다른 사람에게 허용해야 하는 실제 요구가 생기기 전에는 list를 두지 않습니다.
    • 범위 접두어는 붙이지 않습니다. 범위는 역할이 부여된 곳과 판정 대상이 정합니다.
    • docs:read 같은 콜론 표기는 유료 이용권 범위 문자열이며 사람 권한과 다른 개념입니다.
  • 판정 순서는 아래와 같고 기본은 거부입니다.
    1. 대상이 세션의 조직 안에 있는지 봅니다. 밖이면 404입니다.
    2. 계정, 역할 부여(조직 소유 지정), 조직, 워크스페이스, 파트너 계약이 모두 활성인지 봅니다.
    3. 조직 자격 조건(운영사·파트너 등)을 봅니다. 맞지 않으면 404입니다.
    4. 해당 모듈을 이용하는지 봅니다. 아니면 403이 아니라 모듈 안내를 보입니다.
    5. 세션 범위로 좁힌 유효 역할, 추가 역할, 조직 소유에서 나온 권한 키가 있는지 봅니다. 없으면 403입니다.
    6. 키에 붙은 관계 조건(본인, 작성자, 담당, 결재 단계)을 봅니다. 본인 근태·휴가·프로필·급여명세서는 역할이 아니라 활성 소속으로 허용합니다. 메모·활동처럼 작성자가 있는 기록은 작성자와 관리자가 고칩니다. 승인은 역할 이름에서 추론하지 않고 결재선의 결재 단계로 판정합니다.
    7. 민감한 동작은 재인증을 요구합니다. 조직 소유에서 나온 동작은 이메일이 아닌 2차 인증으로 재인증합니다.
권한 묶음관리자편집자조회자
업무 데이터 조회✓✓✓ (민감 정보 제외)
업무 데이터 생성·편집·삭제(복구할 수 있는 삭제)✓✓—
사람·역할·설정·워크스페이스 관리, 감사 기록 조회✓——
  • 워크스페이스 관리자가 다루는 사람·역할은 그 워크스페이스의 편집자·조회자뿐입니다. 제품은 자기 도메인 키를 이 등급에 배치하고 더 엄격한 규칙만 더할 수 있습니다.
  • 조직 소유에서만 나오는 권한은 계약 체결·해지, 청구 역할의 부여·회수, 조직 소유자 지정·회수·이전, 조직 종료입니다. 요금제·모듈 변경은 청구 관리자에게 맡길 수 있습니다(아래 추가 역할). 조직 소유자는 관리자 역할을 함께 가지므로 위 표의 관리자 권한과 청구 권한도 씁니다.
  • 내보내기·발송은 묶음에 넣지 않고 제품이 자원마다 권한 표에 둡니다. 개인정보가 담긴 일괄 내보내기는 관리자에게만 두고, 내보내기와 발송은 감사 기록에 남깁니다.
  • 공통 메시징은 messaging.delivery.read/send, messaging.sender.read/update를 제품 권한 표에 명시합니다. 초기 프로토타입에서는 관리자·편집자가 허용 업무의 조회/발송, 조회자는 조회만 합니다. 조직 발신수단 변경은 조직 관리자만 가능하며, 발송은 일반 편집 권한에서 추론하지 않습니다. 채널별 발신 자격과 업무 접근을 함께 확인합니다. 업무 출처·전체 조회와 메시징을 따릅니다.
  • 삭제는 셋으로 나눕니다. delete는 복구할 수 있는 삭제입니다. 확정 기록(발송된 고지서, 확정된 투표 결과, 서명이 끝난 문서 등)은 삭제하지 않고 취소·정정으로 다룹니다. 영구 삭제는 관리자가 보존 기한을 확인하고 사유를 남긴 뒤에만 합니다.

슈퍼 관리자와 운영사 ​

  • 슈퍼 관리자·플랫폼 역할, 사람별 본사 플래그, JWT·app_metadata의 역할 claim을 두지 않습니다. 서버가 요청마다 역할 부여와 소유 지정에서 읽습니다.
  • 운영사(Leysys 본사)는 운영사 자격을 가진 조직이며, 본사 직원은 그 조직에서 같은 역할을 받고 운영사 조직에도 조직 소유자를 지정합니다. 전 고객 범위는 「운영사 자격 × 역할」로 판정합니다.
  • 본사 직원이 고객 조직 안의 데이터를 볼 때는 고객 조직의 역할이 아니라 지원 접근을 씁니다. 지원 접근은 고객이 승인하는 기한 있는 예외입니다.
    • 고객 조직 관리자가 승인합니다(access.support_access.grant · revoke). 비공개 워크스페이스는 그 직접 관리자도 승인합니다.
    • 요청은 72시간에 만료되고, 접근은 기본 24시간 · 최대 7일이며 지원 사건이 닫히면 끝납니다. 연장은 새 승인으로만 합니다.
    • 기본은 조회이고 요청에 적어 승인받은 쓰기만 씁니다. 내보내기 · 발송 · 역할 변경 · 자격 증명 · 계약 · 결제 · 영구 삭제는 하지 않습니다.
    • 모든 동작은 고객 조직의 감사 기록에 「Leysys 지원」 소속으로 남고, 관리자와 조직 소유자에게 알립니다.
    • 승인 없는 예외는 장애 복구 · 보안 사고 조사 · 법적 의무뿐이며, 법이 막지 않으면 72시간 안에 알립니다.
  • 파트너는 조직 자격이며 파트너 직원은 파트너 조직에서 같은 역할을 받습니다. 영업 직무(영업 관리·영업 담당 등)는 범위·담당·직책으로 표현합니다.

추가 역할 ​

사다리, 범위, 관계 조건, 결재선으로 표현할 수 없는 반복 요구가 실제 고객에게 있을 때만 만듭니다.

  • 추가 역할은 도메인 단위의 사다리입니다. 이름은 {domain}_{tier}이고 효력은 그 도메인 안에서만 있습니다.
  • 등급의 뜻은 주 사다리와 같습니다. 조회자는 그 도메인의 조회, 편집자는 그 도메인의 데이터 작업, 관리자는 그 도메인의 설정입니다. 위 등급은 아래 등급의 권한을 모두 가집니다.
  • 한 도메인을 등록하면 세 등급을 함께 등록하고, 등급마다 할 수 있는 일이 달라야 합니다.
  • 권한을 더하기만 하며 조직 소유 지정·회수·이전, 조직 종료, 계약 체결·해지, access.* 권한 키는 담지 않습니다. 그래서 도메인 관리자도 역할을 부여하거나 회수하지 못합니다.
  • 사다리 역할 없이 추가 역할만 받을 수 있습니다. 예를 들어 청구 업무만 맡길 사람에게 업무 데이터 조회를 함께 주지 않습니다.
  • 부여자는 자기 유효 역할이 가진 권한 키 안에서만 부여하고, 계약·결제 키를 담은 추가 역할은 조직 소유자만 부여합니다.
  • 출시 전에 결정 기록에 등록하며 제품마다 도메인 둘을 넘지 않습니다.

등록된 추가 역할(2026-10-04 KST):

값라벨English할 수 있는 일
billing_viewer청구 조회자Billing viewer계약·청구서·결제 내역 조회, 청구서 내려받기
billing_editor청구 편집자Billing editor위 + 결제 수단·결제 프로필(사업자 정보·계산서 수신자) 변경, 납부 요청
billing_admin청구 관리자Billing admin위 + 요금제·모듈 이용 변경(서비스 해지 제외). 바꾸면 조직 소유자 전원에게 알립니다
  • 청구 역할은 업무 데이터 접근을 주지 않습니다. 세 역할 모두 조직 소유자만 부여·회수하고, 모듈을 빼면 데이터가 지워지는 제품은 그 변경을 조직 소유자에게 남깁니다.

상태 ​

대상값과 라벨배지
계정pending 확인 대기 · active 활성 · locked 잠김 · deactivated 비활성info · success · warning · neutral
역할 부여invited 초대 중 · active 활성 · suspended 정지 · ended 종료(end_reason: 회수 · 만료 · 나감)info · success · neutral · 이력에만 표시
조직 소유 지정invited 초대 중 · active 활성 · ended 종료(end_reason: 회수 · 이전 · 만료 · 나감)info · success · 이력에만 표시

종료된 역할 부여와 조직 소유 지정은 되살리지 않고 새로 부여·지정합니다. 「중지」 대신 「정지」를 씁니다.

로그인 방법과 세션 범위 ​

로그인 방법세션 범위쓰는 역할과 소유
이메일(현재 제품의 가입·로그인 자격 유지)활성 접근 관계가 있는 조직과 허용된 워크스페이스주체의 역할·추가 역할·검증된 조직 소유. 제품의 기존 owner-only 이메일 진입을 자동 확대하지 않습니다
조직 코드 + 아이디그 조직과 허용된 워크스페이스그 조직의 역할·추가 역할. 동일 인증 주체 연결이 검증되면 활성 조직 소유와 재인증으로 소유 명령 판정
워크스페이스 코드 + 아이디그 워크스페이스 하나, 스위처 없음그 워크스페이스의 유효 역할. 조직 화면과 조직 전용 동작은 열지 못합니다
  • 세션은 범위를 좁히기만 합니다. 서버는 범위를 클라이언트 입력이 아니라 세션과 대상에서 정합니다.
  • 조직 소유의 민감 변경 명령은 로그인 방법이 아니라, 검증된 동일 인증 주체의 활성 조직 소유 지정·조직 관리자 전제 역할· 조직 범위 세션과 최근 비이메일 2차 인증으로 판정합니다. 검증된 이메일과 비이메일 2차 인증 등록 요건은 유지합니다. 현장 코드 세션은 조직 소유가 있어도 조직 명령을 허용하지 않습니다. 세 자격 증명을 이름·이메일로 자동 연결하지 않습니다. 이번 채택의 재인증은 300초 미만이며 미래·만료·재사용 증거는 거부합니다. 주체·세션·조직·명령·nonce에 묶고 로컬 시연은 서버 인증이 아닙니다. 활성·검증된 조직 소유자의 일반 청구 조회·내려받기는 재인증 없이 허용합니다.
  • 범위 선택지는 조직 단계에서는 활성 소속이 있는 조직, 워크스페이스 단계에서는 유효 역할이 있는 워크스페이스에서 나옵니다.

화면 표현 ​

  • 역할 라벨은 관리자 · 편집자 · 조회자이고 위 등급부터 나열합니다. 역할을 고르는 곳에는 한 줄 설명을 함께 보이고 기본 선택은 조회자입니다. 선택지에는 부여 규칙이 허락하는 역할만 보이며, 직접 역할을 없애는 선택지는 맨 끝의 「역할 없음」입니다.
  • 기본 비공개 제품에서 조직 역할을 고르는 곳에는 「비공개 워크스페이스에는 적용되지 않습니다」를 함께 보입니다.
  • 조직 소유는 역할 선택지에 넣지 않습니다. 구성원 목록에서는 역할 열의 「관리자」 옆에 「조직 소유자」를 표시하고, 지정·회수·이전은 조직 설정의 「조직 소유자」 영역에서만 합니다.
  • 역할과 조직 소유는 상태가 아니므로 의미 색(위험·경고·성공·정보)을 쓰지 않고 neutral 배지 또는 텍스트로 보입니다. 의미 색은 상태에만 씁니다.
  • 상속 역할은 유효 역할과 함께 출처 「조직에서」를 보이고, 편집 control 대신 「조직 역할에서 변경」 link를 둡니다.
상황표현
그 역할로는 절대 쓸 수 없는 메뉴·동작숨깁니다. 조회자 화면에는 「조회 전용」 표시를 한 번 둡니다.
역할은 되지만 상태 때문에 막힌 동작(유효 조직 소유자를 0명으로 만드는 변경 등)비활성 + 이유
권한 없는 화면 주소로 직접 들어옴그 자리에서 403. 다른 곳으로 보내지 않습니다.
다른 조직의 대상, 조직 자격이 맞지 않는 기능메뉴를 숨기고, 주소로 들어오면 404
직접 역할 없는 비공개 워크스페이스404. 조직 관리자에게는 참여 안내(사유 입력)
이용하지 않는 모듈메뉴를 숨기고, 주소로 들어오면 모듈 안내
동작 뒤 서버 거절알림을 보이고 권한을 다시 읽습니다.
자리문구
403 제목접근 권한이 없습니다
403 본문현재 역할로는 이 화면을 볼 수 없습니다. 필요하면 관리자에게 역할 변경을 요청해 주세요.
동작 거절 알림이 작업을 할 권한이 없습니다.
모듈 안내이용하지 않는 모듈입니다 / 이 워크스페이스는 {모듈} 모듈을 이용하지 않습니다. 조직 소유자에게 문의해 주세요.
비공개 참여 안내비공개 워크스페이스입니다 / 참여하려면 사유를 남겨 주세요. 참여 기록은 감사 기록에 남습니다.
워크스페이스 세션 제한워크스페이스 계정으로는 조직 화면을 열 수 없습니다. 조직 계정으로 로그인해 주세요.

행위 주체 ​

  • 라벨 — 역할, 관계, 행위 주체를 서로 다른 형식으로 씁니다.
    • 행위 주체는 「{동사} 주체」입니다. 예: 생성 주체, 편집 주체, 삭제 주체, 승인 주체, 발송 주체, 요청 주체. 여러 종류의 사건을 한 목록에 담는 기록은 「행위 주체」입니다.
    • 주체는 사람·조직·소프트웨어(AI 에이전트·예약 작업·연동)일 수 있습니다. 「사람」은 자연인만 하는 일의 라벨에만 쓰고, 「편집자」 같은 역할 라벨을 행위 주체에 쓰지 않습니다.
    • 관계는 명사입니다. 예: 작성자, 담당자, 결재자, 조직 소유자. 결재선에 지정된 결재자와 실제 승인 주체는 다를 수 있으므로(대결) 둘을 다른 라벨로 보입니다.
    • 소프트웨어 주체는 식별된 이름으로 보입니다. 주체를 모르면 「알 수 없음」으로 보이고, 「시스템」이나 조직 소유자로 채우지 않습니다.
  • 필드 — {동사}edAt · {동사}edBy. {동사}edBy는 주체 유형(사람 · 조직 · 소프트웨어 · 알 수 없음)과 안정적인 식별자를 가진 참조이며 그때의 표시 이름을 함께 남깁니다. 화면 계약에는 {동사}edByName을 넘깁니다.
    • 요청 주체(requestedBy)와 확인된 대표·위임 관계(onBehalfOf)는 행위 주체와 따로 둡니다. 감사 기록에는 인증 주체와 위임 경로를 따로 남깁니다.
    • 여러 종류의 사건을 한 목록에 담는 감사 기록만 actor를 씁니다.
    • 행위 주체와 관계를 가리키는 식별자에 역할 값을 쓰지 않습니다. editor는 역할 값만 뜻합니다. 예: editorName → editedByName, editorAccountId → editedBy.
    • updatedAt은 레코드의 마지막 변경 시각(모든 변경), editedAt은 내용 편집 사건의 시각입니다. 둘의 구분은 행위의 뜻에 따르며, 주체가 사람인지 AI인지로 나누지 않습니다.
동작화면 동사사건 필드주체 라벨권한 키
create생성createdAt · createdBy생성 주체create
edit편집editedAt · editedBy편집 주체update
change변경(역할·설정·상태)changedAt · changedBy변경 주체update
complete완료completedAt · completedBy완료 주체update
delete삭제deletedAt · deletedBy삭제 주체delete
read조회접근 기록의 actor조회 주체read
export내보내기exportedAt · exportedBy내보내기 주체export
send발송sentAt · sentBy발송 주체send
approve승인approvedAt · approvedBy승인 주체approve
publish발행publishedAt · publishedBy발행 주체publish
cancel발행 취소cancelledAt · cancelledBy취소 주체publish
accept수락(담당자 기록)acceptedAt · acceptedBy수락 주체publish
decline거절(담당자 기록)declinedAt · declinedBy거절 주체publish
grant부여, 지정grantedAt · grantedBy부여 주체grant
revoke회수revokedAt · revokedBy회수 주체revoke
  • 발행은 고객이 볼 수 있는 고정본을 내보내는 동작입니다(예: 견적 수정본). 발송(메시지 전달)이나 승인(내부 결재)과 다릅니다. 고객이 공개 링크에서 수락 · 거절하면 직원 권한을 쓰지 않고, 주체 유형이 고객인 기록을 남깁니다.
  • 「수정」은 「편집」과 같은 일을 가리키므로 동작 라벨로 쓰지 않습니다. 「갱신」은 계약 갱신(renew)에만 씁니다.
상황기록
사람이 직접 편집·저장그 사람이 편집 주체입니다.
AI가 제안하고 사람이 검토·저장사람이 편집 주체이고, 필요하면 AI 도구 사용 정보를 덧붙입니다.
사람의 요청을 받은 AI가 직접 편집AI 에이전트가 편집 주체이고, 확인된 요청 주체를 requestedBy로 따로 남깁니다.
예약 작업이 자동으로 변경식별된 자동화 작업·서비스가 행위 주체입니다.
회사 명의로 직원·서비스가 수행실제 수행 주체를 남기고, 확인된 대표·위임 관계를 onBehalfOf로 따로 남깁니다.
편집자 역할이지만 편집한 적이 없음역할만 있고 편집 사건은 없습니다.
과거에 편집했지만 지금은 조회자지금 역할과 과거 사건의 주체를 각각 유지합니다.
계정 삭제·주체 정보 소실식별자는 남기고 「삭제된 계정」·「알 수 없음」으로 보이며, 다른 주체로 바꾸지 않습니다.
  • 행위 주체는 서버가 확인한 실행·인증·위임 정보로만 기록합니다. 모든 저장을 처리하는 백엔드 프로세스를 모든 사건의 행위 주체로 기록하지 않고, 자동화 설정을 만든 사람을 모든 실행의 요청 주체로, 소속 회사를 법적 대리인으로 추정하지 않습니다.

식별자 ​

계층기준
값모든 계층에서 같은 소문자 admin · editor · viewer. 조직과 워크스페이스가 같은 셋을 씁니다
저장범위는 표나 열이 정하고 값만 저장합니다. 조직 역할이 없으면 행이 없거나 null이며 member·none을 저장하지 않습니다. 조직 소유는 역할 값이 아닌 관계로 저장합니다
범위 참조organization.admin, workspace.editor, 조직 소유는 organization.owner. 문서·감사 payload·테스트·설정에서만 쓰고 저장 값으로 쓰지 않습니다
i18nrole.{값}, role.description.{값}, role.unassigned, roleSource.direct · roleSource.inherited, organizationOwner, ownershipStatus.*, accountStatus.*, membershipStatus.*
관계 필드대상 타입을 이름에 드러냅니다: assignee · assigneeAccountId · assigneeName, authorAccountId · authorName. 계정 ID와 표시 이름을 한 필드에 섞지 않습니다

피해야 할 것 ​

  • 기능 코드가 role === 'admin'처럼 역할 이름을 직접 비교하는 구조
  • 같은 등급을 SQL · 서버 함수 · 화면에서 따로 계산하는 구조
  • 조직 소유를 역할 값으로 저장해 조직과 워크스페이스의 역할 집합을 다르게 만드는 구조
  • 직책(팀장)·소속(본사)·대상(staff)·조직 자격(파트너)을 역할 값으로 저장하는 구조
  • 사람별 플래그나 JWT claim으로 전 고객 범위·슈퍼 관리자 권한을 주는 구조
  • 비공개 워크스페이스를 조직 관리자가 아닌, 직접 역할 없는 사람에게 드러내는 구조
  • 같은 워크스페이스의 관리자가 다른 워크스페이스 관리자를 낮추거나 회수하는 구조
  • 직원 셀프서비스를 쓰게 하려고 모든 직원에게 콘솔 조회자 역할을 주는 구조
  • 청구 업무만 맡길 사람에게 업무 데이터 조회 역할까지 주는 구조
  • 역할을 위험·경고 색 배지로 보여 상태처럼 읽히게 하는 구조
  • 권한 없는 주소에서 아무 설명 없이 다른 화면으로 보내는 구조
  • 유효 조직 소유자를 0명으로 만들 수 있는 구조(계정 비활성화·잠금·삭제, 소속 종료, 동시 요청, 초대 중 지정을 세는 계산 포함)
  • 조직 소유자가 아닌 관리자가 조직 소유자나 다른 관리자의 이메일·비밀번호·2차 인증·복구 경로를 바꾸는 구조
  • 검증된 이메일만으로 조직 소유 동작을 허용하는 구조
  • 행위 주체를 「편집자」 같은 역할 라벨이나 「편집한 사람」처럼 사람에 한정된 라벨로 보이는 구조(자연인만 하는 일 제외), 주체를 모를 때 「시스템」이나 조직 소유자로 채우는 구조
  • AI·자동화가 행위 주체로 기록된다는 이유로 접근을 주는 구조, 요청 주체가 할 수 없는 일을 소프트웨어 주체가 대신 하는 구조
  • 확정 기록을 일반 삭제로 지우는 구조, 개인정보가 담긴 일괄 내보내기를 편집자에게 기본으로 주는 구조
  • 지원을 위해 운영사 직원에게 고객 조직의 역할을 주는 구조, 기한 없는 지원 접근
  • 개인 진술이나 신분증만으로 조직 소유자를 새로 지정하는 구조

관련 문서 ​