Update 바론SSO조직도 관련 검토.md

2026-06-17 13:31:39 +09:00
parent ba48080596
commit 4f1cadf48c
1 changed files with 86 additions and 32 deletions
--- a/검토.md
+++ b/검토.md
@@ -1,4 +1,4 @@
-# Baron SSO 조직도 관리 개선 제안
+# Baron SSO 조직도 관리 개선 제안 - 기존 정책 통합 반영본

 ## 문서 요약

@@ -6,11 +6,14 @@

 주요 내용은 다음과 같다.

- 여러 자회사별 조직도를 회사 단위로 분리하여 관리한다.
+> 이 문서는 현재 Baron SSO에 이미 존재하는 `Tenant`, `UserGroup`, `Keto ReBAC`, `OrgFront`, `AdminFront`, outbox 정책을 전제로 한다.  
+> 특히 아래 항목들은 기존 정책을 대체하는 내용이 아니라, 기존 정책 위에 추가로 제안하는 개선안이다.
+
+- 여러 자회사는 `COMPANY` 테넌트로 구분하되, 실제 업무 조직은 `COMPANY_GROUP` 하위의 논리 조직 테넌트로도 관리할 수 있게 한다.
 - 조직도는 부서/팀에 고정하지 않고 본부, 부문, 부서, 팀, 셀 등 유연한 조직 단위 계층으로 관리한다.
- 본부장, 부문장, 부서장, 팀장, 셀장 같은 조직장 역할은 회사별 설정에 따라 선택적으로 관리한다.
- 조직 변경은 권한이 있는 담당자만 요청할 수 있고, 승인 후 각 회사 DB에 제한적으로 반영한다.
- 각 회사 DB 컬럼 구조가 다르므로 회사별 조직 매핑 정책과 DB 반영 어댑터를 둔다.
+- 본부장, 부문장, 부서장, 팀장, 셀장 같은 조직장 역할은 Keto의 `owners/admins/members` 관계와 회사별 표시 정책을 조합해 선택적으로 관리한다.
+- 조직 변경은 권한이 있는 담당자만 요청할 수 있고, 승인 후 Baron DB와 Keto outbox를 먼저 정합화한 뒤 각 회사 DB 또는 외부 Directory에 제한적으로 반영한다.
+- 각 회사 DB 컬럼 구조가 다르므로 회사별 조직 매핑 정책과 외부 반영 어댑터를 둔다.
 - 회원가입은 각 회사 인사 DB의 발령상태와 재직상태를 기준으로 허용 여부를 판단한다.
 - SSO 로그인 가능 여부와 실제 업무 시스템 접근 가능 여부를 분리하여 관리한다.
 - 직원 사진은 원본을 각 회사에 두고 SSO는 표준 썸네일과 메타데이터만 관리하는 방안을 권장한다.
@@ -41,6 +44,40 @@
 5. [후속 진행 작업](#5-후속-진행-작업)
 6. [기대 효과](#6-기대-효과)
 7. [참고 오픈소스 후보](#7-참고-오픈소스-후보)
+## 0. 현재 Baron SSO 정책/구현과의 정합성 요약
+
+현재 Baron SSO 소스와 문서에는 조직도 관련 기반이 이미 존재한다. 따라서 본 제안은 별도 신규 조직도 시스템을 처음부터 만드는 방향이 아니라, 
+기존 `Tenant`, `UserGroup`, `Keto ReBAC`, `OrgFront`, `AdminFront`, outbox 구조를 확장하는 방향으로 정리한다.
+
+확인된 기존 기준은 다음과 같다.
+
+- 조직 단위는 기본적으로 `Tenant`로 표현한다.
+- 법인/회사 구분은 `COMPANY`, 그룹사는 `COMPANY_GROUP`, 사내 논리 조직은 `USER_GROUP` 또는 현재 코드의 `ORGANIZATION` 타입을 사용한다.
+- 조직 계층은 `Tenant.parentId`와 Keto의 `Tenant:<child>#parents@Tenant:<parent>` 관계로 표현한다.
+- 조직 구성원은 `Tenant:<groupId>#members@User:<userId>` 관계로 표현한다.
+- 조직장/관리자는 `owners`, `admins` 관계를 사용하고, 권한 검증은 Keto ReBAC를 기준으로 한다.
+- 변경 이벤트는 즉시 외부 시스템에 직접 쓰기보다 Baron DB와 outbox에 기록한 뒤 비동기 동기화하는 구조를 우선한다.
+- `OrgFront`는 조직도 표시 계층이고, 조직도 데이터는 Backend API에서 취합해 제공한다.
+- 외부 시스템 연동은 Worksmobile 연동처럼 회사/테넌트 단위 설정과 outbox 기반 동기화 방식을 따르는 것이 기존 방향과 맞다.
+
+따라서 이 문서에서 말하는 `회사별 조직도 관리`는 모든 조직을 반드시 각 법인 하위에만 둔다는 뜻이 아니다. 법인 소속은 사용자 속성으로 유지하면서, 여러 법인 직원이 같은 논리 조직에 속할 수 있는 매트릭스 조직 구조도 허용한다. 회사별 담당자는 자신에게 부여된 `Tenant manage/view` 권한 범위 안에서 해당 조직 또는 하위 조직을 관리한다.
+### 0.1 기존 정책 대비 추가 제안 핵심
+
+아래 항목은 현재 Baron SSO 정책을 확인한 뒤, 그 정책에 반하지 않는 선에서 추가로 제안하는 개선 사항이다.
+
+| 구분 | 현재 Baron SSO 정책/구현 | 추가 제안 방향 |
+| --- | --- | --- |
+| 조직 모델 | 조직 단위를 `Tenant`, `UserGroup`, `ORGANIZATION` 개념으로 표현 | 회사별/그룹사별 조직관리 화면에서 `본부/부문/부서/팀/셀` 등 표시 정책을 명확화 |
+| 매트릭스 조직 | 법인 소속과 논리 조직을 분리할 수 있는 정책 존재 | 여러 자회사 직원이 같은 논리 조직에 속하는 경우를 공식 운영 시나리오로 반영 |
+| 조직장 | Keto `owners/admins/members` 관계로 권한 표현 가능 | `본부장/부문장/부서장/팀장/셀장` 같은 화면 표시명과 승인 역할 정책 추가 |
+| 조직 변경 | `Tenant.parentId`, Keto `parents`, outbox 기반 동기화 구조 존재 | 변경 요청, 승인/반려, 변경 전후 비교, 외부 DB 반영 미리보기 프로세스 추가 |
+| 외부 반영 | Worksmobile 동기화 구조 존재 | 각 자회사 인사 DB 컬럼 구조별 매핑 어댑터를 추가 제안 |
+| 조직도 표시 | OrgFront, public orgchart, embed picker 기반 존재 | 인트라넷/모바일용 링크, iframe, 이미지 내보내기 운영 정책 보강 |
+| 사용자 상태 | `active`, `suspended`, `temporary_leave`, `preboarding`, `archived` 등 상태 정책 존재 | 상태별 SSO 로그인 가능 여부와 서비스별 접근 가능 여부를 분리 관리 |
+| 직원 사진 | 조직도 사진 정책은 명확히 확인되지 않음 | 원본은 각 회사 보관, SSO는 표준 썸네일/메타데이터만 관리하는 정책 추가 |
+| 관리자 화면 | AdminFront에 조직/멤버/권한 관리 기능 일부 존재 | 조직 담당자 전용 승인 화면, 정책 관리 화면, 감사 이력 화면을 추가 제안 |
+
+이 표의 `추가 제안 방향`은 현재 구현을 부정하는 것이 아니라, 기존 구조를 운영 가능한 수준으로 구체화하기 위한 보강안이다.

 ## 1. 제안 목적

@@ -50,16 +87,18 @@ Baron SSO에 접근하는 사내 직원을 회사별 조직도 기준으로 관

 또한 각 회사의 인사담당자 또는 조직관리 담당자가 회사별 조직도를 시각적으로 관리하고, 승인된 조직 변경 사항을 각 회사 DB의 조직 귀속 정보에 제한적으로 반영하는 방안까지 함께 검토한다.

+단, Baron SSO가 각 회사 인사 DB의 원장을 대체하지 않는다. Baron SSO는 인증/인가와 조직 표시, 권한 판단에 필요한 read model과 관계 정보를 관리하고, 원천 인사정보와 외부 Directory 반영은 회사별 정책과 동기화 어댑터를 통해 제한적으로 처리한다.
+
 ## 2. 기본 방향

 - Baron SSO 접근 사용자를 조직도 기준으로 식별한다.
- 여러 자회사를 회사 단위로 구분하고, 각 회사별 조직도를 독립적으로 관리한다.
- 조직도는 본부, 부문, 부서, 팀, 셀 등 회사별 조직 단위의 계층 구조로 시각화하고, 권한이 있는 담당자만 수정할 수 있게 한다.
+- 여러 자회사를 회사 테넌트로 구분하되, 실제 업무 조직은 회사 하위 또는 그룹사 하위 논리 조직으로 유연하게 구성한다.
+- 조직도는 본부, 부문, 부서, 팀, 셀 등 조직 단위의 계층 구조로 시각화하고, 권한이 있는 담당자만 수정할 수 있게 한다.
 - 재직상태, 부서, 직책, 권한 그룹을 기준으로 로그인 가능 여부와 서비스 접근 범위를 관리한다.
 - 조직도 원천 데이터는 회사별 인사정보 또는 조직관리 DB를 기준으로 하되, SSO에서는 접근 통제에 필요한 조직 정보를 통합 관리한다.
- 조직도 변경 사항은 검증과 승인 절차를 거친 뒤 각 회사 DB에 반영한다.
+- 조직도 변경 사항은 검증과 승인 절차를 거친 뒤 Baron DB/Keto 관계를 먼저 갱신하고, 필요한 경우 각 회사 DB 또는 외부 Directory에 반영한다.
 - 각 회사 DB 반영 대상은 개인정보 전체가 아니라 조직단위코드, 상위조직코드, 직책코드, 소속상태 같은 조직 귀속 정보로 제한한다.
- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 회사별 API 또는 배치 동기화 방식으로 확장한다.
+- 초기에는 CSV 업로드와 기존 AdminFront 관리 기능을 보강하는 방식으로 시작하고, 이후 회사별 API 또는 배치 동기화 방식으로 확장한다.
 - 모든 권한 변경과 로그인 이력은 감사 로그로 남긴다.

 ## 3. 단계별 추진안
@@ -93,7 +132,7 @@ Baron SSO에 접근하는 사내 직원을 회사별 조직도 기준으로 관

 ### 3.2 조직도 기준 데이터 정의

-Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
+Baron SSO에서 사용할 조직도 기준 항목을 정의한다. 이 항목은 기존 `Tenant/UserGroup` 모델을 대체하는 신규 원장이 아니라, 기존 모델에 어떤 값을 매핑하고 어떤 운영 정책을 추가할지 정리하기 위한 제안이다. 기존 정책에 맞춰 조직 단위의 저장 기준은 `Tenant`이며, 표시와 운영 메타데이터는 `user_groups` 또는 `Tenant.config`로 확장하는 방향을 우선한다.

 최소 관리 항목은 다음과 같다.

@@ -138,7 +177,7 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
 회사 -> 센터 -> 그룹 -> 팀
 ```

-이를 위해 조직 단위는 공통적으로 다음 구조를 가진다.
+이를 위해 조직 단위는 공통적으로 다음 구조를 가진다. 실제 구현에서는 신규 테이블을 우선 만들기보다 기존 `Tenant.id`, `Tenant.parentId`, `Tenant.type`, `Tenant.config.orgUnitType` 및 `user_groups.unitType`과 매핑한다.

 | 항목 | 설명 |
 | --- | --- |
@@ -150,7 +189,7 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
 | 조직장 사용자 ID | 해당 조직 단위의 책임자 |
 | 사용 여부 | 폐지된 조직인지 여부 |

-조직장 역할은 조직단위유형에 따라 자동으로 해석할 수 있다.
+조직장 역할은 조직단위유형에 따라 화면 표시명을 자동 해석할 수 있다. 권한상 조직장은 별도 문자열 역할보다 Keto `owners` 또는 `admins` 관계를 기준으로 판단한다.

 예를 들어 조직단위유형이 `본부`이면 조직장은 `본부장`, `부문`이면 `부문장`, `팀`이면 `팀장`, `셀`이면 `셀장`으로 표시할 수 있다.

@@ -168,7 +207,7 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다.

 핵심 원칙은 각 회사별 조직도 원본을 명확히 정하는 것이다.

-Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하다. 따라서 SSO에서는 접근 통제에 필요한 조직 정보를 관리하고, 실제 회사별 인사정보 변경은 정해진 항목에 한해 각 회사 DB와 연동하는 방식이 안정적이다.
+Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하며, 기존 Baron 정책상 Kratos는 인증 주체, Backend DB는 read model, Keto는 권한 관계 원장으로 역할을 분리해야 한다. 따라서 SSO에서는 접근 통제에 필요한 조직 정보를 관리하고, 실제 회사별 인사정보 변경은 정해진 항목에 한해 각 회사 DB와 연동하는 방식이 안정적이다.

 원천 시스템 연동이 당장 어렵다면 초기에는 관리자 업로드 방식으로 시작할 수 있다.

@@ -190,10 +229,12 @@ Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하
 - 승인 후 각 회사 DB 반영
 - 반영 성공/실패 결과 확인

-이 화면은 단순 조직도 조회 화면이 아니라 `회사별 조직 귀속 정보 관리 화면`으로 정의한다.
+이 화면은 단순 조직도 조회 화면이 아니라 `조직 귀속 정보 관리 화면`으로 정의한다. 현재 AdminFront의 조직/테넌트 관리 화면과 OrgFront의 조회 화면을 우선 재사용하고, 부족한 변경 요청·승인·미리보기 기능을 추가하는 방향이 적절하다.

 ### 3.5 조직장 역할 관리 방안

+> 추가 제안: 현재 Keto 관계(`owners/admins/members`)로 표현 가능한 권한 구조에, 사람이 이해하기 쉬운 조직장 표시명과 승인 역할 정책을 덧붙인다.
+
 조직도에는 본부장, 부문장, 부서장, 팀장, 셀장처럼 각 조직 단위의 책임자를 표시하고 관리할 수 있어야 한다.

 다만 모든 회사와 모든 조직 단계에 반드시 조직장이 존재하는 것은 아니므로, 조직장 역할은 필수값이 아니라 회사별 설정에 따른 선택 항목으로 관리한다.
@@ -208,7 +249,7 @@ Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하
 -> 조직도/권한 정책/승인 정책에서 활용
 ```

-조직장 역할 설정 예시는 다음과 같다.
+조직장 역할 설정 예시는 다음과 같다. 이 표의 역할명은 화면 표시와 승인 정책용 명칭이며, 실제 권한 부여는 Keto `owners/admins/members` 관계로 저장한다.

 | 조직단위유형 | 표시 역할명 | 조직장 필수 여부 | 설명 |
 | --- | --- | --- | --- |
@@ -291,6 +332,8 @@ https://sso.example.com/org-chart/companies/{companyCode}/export.png

 ### 3.8 직원 사진 관리 및 표시 방안

+> 추가 제안: 현재 조직도 정책에서 명확히 드러나지 않는 직원 사진 관리 기준을 별도 운영 정책으로 추가한다.
+
 조직도와 SSO 로그인 화면에서 직원 사진을 표시하려면 사진 파일의 원천, 저장 방식, 노출 범위를 별도 정책으로 정의해야 한다.

 사진은 개인을 식별할 수 있는 정보이므로 Baron SSO가 각 회사의 원본 사진 저장소를 대체하는 구조는 권장하지 않는다.
@@ -354,11 +397,11 @@ https://sso.example.com/photos/users/{userId}?size=thumbnail

 ### 3.9 조직도 변경 권한 정책 정의

-조직도의 변경은 각 회사에서 정해진 인원만 가능해야 한다.
+조직도의 변경은 각 회사 또는 조직 테넌트에서 정해진 인원만 가능해야 한다. 기존 Baron 정책에 맞춰 변경 권한은 `Tenant view/manage` 및 Keto ReBAC 관계로 판정한다.

 권한은 조회 권한과 변경 권한을 분리하고, 회사별로 적용 범위를 제한한다.

-권한 역할 예시는 다음과 같다.
+권한 역할 예시는 다음과 같다. 실제 구현에서는 이 역할을 직접 문자열 권한으로만 만들기보다 `owners`, `admins`, `members`, `RelyingParty#access` 관계와 관리자 화면의 표시 역할로 분리한다.

 ```text
 전체 관리자
@@ -391,6 +434,8 @@ https://sso.example.com/photos/users/{userId}?size=thumbnail

 ### 3.10 조직도 동기화 및 DB 반영 방식 설계

+> 추가 제안: 현재 Baron의 outbox/Worksmobile 동기화 방향을 확장하여, 각 자회사 인사 DB에도 제한된 조직 귀속 정보만 반영할 수 있는 어댑터 구조를 제안한다.
+
 초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다.

 권장 흐름은 다음과 같다.
@@ -412,7 +457,7 @@ https://sso.example.com/photos/users/{userId}?size=thumbnail
 - 안정화 이후: 수시 배치 또는 API 연동
 - 보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영

-각 회사 DB에 반영할 수 있는 항목은 다음과 같이 제한한다.
+각 회사 DB 또는 외부 Directory에 반영할 수 있는 항목은 다음과 같이 제한한다. Baron 내부 변경과 외부 반영은 같은 요청에서 직접 동시 처리하지 않고, outbox와 동기화 작업으로 분리하는 방식을 우선한다.

 - 조직단위코드
 - 상위조직코드
@@ -434,7 +479,7 @@ https://sso.example.com/photos/users/{userId}?size=thumbnail
 - 급여 정보
 - 기타 민감 개인정보

-회사별 DB 구조가 다를 수 있으므로 회사별 연동 어댑터를 두는 방식을 권장한다.
+회사별 DB 구조가 다를 수 있으므로 회사별 연동 어댑터를 두는 방식을 권장한다. Worksmobile 연동처럼 테넌트 설정, 매핑 정책, outbox, 재시도/대사 화면을 함께 두는 방식이 기존 구조와 잘 맞는다.

 ```text
 Baron SSO 조직 변경 요청
@@ -530,6 +575,8 @@ Baron SSO 회원가입은 각 회사 인사 DB에 존재하는 직원인지 확

 ### 3.12 SSO 로그인 및 서비스별 접근 권한 정책 정의

+> 추가 제안: 기존 사용자 상태 정책과 Keto/RelyingParty 접근 제어를 연결하여, SSO 로그인 가능 여부와 서비스별 접근 가능 여부를 분리 관리한다.
+
 조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다.

 기본 정책 예시는 다음과 같다.
@@ -545,7 +592,7 @@ Baron SSO 회원가입은 각 회사 인사 DB에 존재하는 직원인지 확

 관리자 권한은 부서 정보만으로 자동 부여하지 않는 것이 안전하다.

-관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다.
+관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다. Baron SSO의 기존 방향에 맞춰 최종 접근 판단은 `RelyingParty`와 `Tenant`의 Keto 관계를 기준으로 수행한다.

 로그인 가능 여부와 서비스별 접근 가능 여부는 분리해서 판단한다.

@@ -595,6 +642,8 @@ SSO 로그인 요청

 ### 3.13 서비스별 접근 권한 관리자 기능

+> 추가 제안: 현재 ReBAC 정책을 운영자가 직접 관리할 수 있도록 서비스별 접근 정책 관리자 화면을 제안한다.
+
 서비스별 접근 정책을 관리할 수 있는 관리자 페이지를 제공한다.

 주요 기능은 다음과 같다.
@@ -681,7 +730,7 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨

 ## 4. 우선순위

-가장 먼저 진행해야 할 작업은 다음 세 가지다.
+가장 먼저 진행해야 할 작업은 다음과 같다. 특히 `추가 제안` 항목은 기존 정책 확인 후 보강 개발로 추진한다.

 1. 현재 SSO 사용자 목록 정리
 2. 회원가입 가능 상태와 차단 상태 정책 확정
@@ -692,6 +741,7 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨
 7. 서비스별 접근 권한 정책 기준 확정
 8. 직원 사진 원천과 SSO 표시 방식 확정
 9. 회사별 조직도 계층과 DB 컬럼 매핑 정책 확정
+10. 회사별 조직장 역할 사용 여부와 필수 여부 확정

 이 항목들이 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리, 각 회사 DB 반영 기능을 순차적으로 진행할 수 있다.

@@ -710,17 +760,18 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨
 9. 조직도 변경 승인 절차 정의
 10. 각 회사 DB 반영 가능 항목 확정
 11. 회사별 조직 계층과 DB 컬럼 매핑 정책 정의
-12. 조직도 UI 오픈소스 후보 기술 검토
-13. 조직도 링크/임베드/이미지 제공 방식 확정
-14. 직원 사진 원천/동기화/표시 정책 확정
-15. 퇴사자/휴직자 로그인 차단 정책 적용
-16. 서비스별 접근 정책 관리자 화면 추가
-17. 관리자 조회 화면 추가
-18. 회사별 조직도 관리 화면 추가
-19. 조직도 동기화 배치 또는 API 구현
-20. 직원 사진 썸네일 동기화 구현
-21. 각 회사 DB 반영 어댑터 구현
-22. 권한 변경 및 로그인 감사 로그 보강
+12. 회사별 조직장 역할 정책 정의
+13. 조직도 UI 오픈소스 후보 기술 검토
+14. 조직도 링크/임베드/이미지 제공 방식 확정
+15. 직원 사진 원천/동기화/표시 정책 확정
+16. 퇴사자/휴직자 로그인 차단 정책 적용
+17. 서비스별 접근 정책 관리자 화면 추가
+18. 관리자 조회 화면 추가
+19. 회사별 조직도 관리 화면 추가
+20. 조직도 동기화 배치 또는 API 구현
+21. 직원 사진 썸네일 동기화 구현
+22. 각 회사 DB 반영 어댑터 구현
+23. 권한 변경 및 로그인 감사 로그 보강

 ## 6. 기대 효과

@@ -734,6 +785,7 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨
 - 권한이 있는 담당자만 조직도 변경을 요청하거나 승인할 수 있다.
 - 각 회사 DB에는 필요한 조직 귀속 정보만 제한적으로 반영할 수 있다.
 - 회사별 DB 컬럼 수가 달라도 조직 매핑 정책으로 반영 방식을 다르게 적용할 수 있다.
+- 본부장, 부문장, 부서장, 팀장, 셀장 같은 조직장 역할을 회사별 정책에 따라 선택적으로 관리할 수 있다.
 - 완성된 조직도를 각 회사 인트라넷이나 모바일 페이지에서 쉽게 표시할 수 있다.
 - 보고자료나 공지용 조직도 이미지를 별도 수작업 없이 생성할 수 있다.
 - 각 회사 직원 사진을 표준 썸네일 형태로 일관되게 표시할 수 있다.
@@ -748,3 +800,5 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨
 - `OrgChart`: https://github.com/dabeng/OrgChart
 - `React Flow`: https://github.com/xyflow/xyflow
 - `Treant.js`: https://github.com/fperucic/treant-js
+
+