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

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

@@ -1,17 +1,63 @@
 # Baron SSO 조직도 관리 개선 제안
 
+## 문서 요약
+
+이 문서는 Baron SSO를 단순 로그인 시스템이 아니라 여러 자회사의 조직도, 직원 상태, 서비스 접근 권한을 통합 관리하는 기준 시스템으로 확장하기 위한 제안서다.
+
+주요 내용은 다음과 같다.
+
+- 여러 자회사별 조직도를 회사 단위로 분리하여 관리한다.
+- 조직도는 부서/팀에 고정하지 않고 본부, 부문, 부서, 팀, 셀 등 유연한 조직 단위 계층으로 관리한다.
+- 조직 변경은 권한이 있는 담당자만 요청할 수 있고, 승인 후 각 회사 DB에 제한적으로 반영한다.
+- 각 회사 DB 컬럼 구조가 다르므로 회사별 조직 매핑 정책과 DB 반영 어댑터를 둔다.
+- 회원가입은 각 회사 인사 DB의 발령상태와 재직상태를 기준으로 허용 여부를 판단한다.
+- SSO 로그인 가능 여부와 실제 업무 시스템 접근 가능 여부를 분리하여 관리한다.
+- 직원 사진은 원본을 각 회사에 두고 SSO는 표준 썸네일과 메타데이터만 관리하는 방안을 권장한다.
+- 완성된 조직도는 링크, 임베드, 이미지 형태로 인트라넷이나 모바일 페이지에 표시할 수 있게 한다.
+- 모든 조직 변경, 권한 변경, 로그인, 사진 조회, 외부 표시 이력은 감사 로그로 남긴다.
+
+## 목차
+
+1. [제안 목적](#1-제안-목적)
+2. [기본 방향](#2-기본-방향)
+3. [단계별 추진안](#3-단계별-추진안)
+   - [현재 사용자 기준 정리](#31-현재-사용자-기준-정리)
+   - [조직도 기준 데이터 정의](#32-조직도-기준-데이터-정의)
+   - [조직도 원천 시스템 결정](#33-조직도-원천-시스템-결정)
+   - [회사별 조직도 관리 화면 설계](#34-회사별-조직도-관리-화면-설계)
+   - [조직도 UI 오픈소스 적용 방안](#35-조직도-ui-오픈소스-적용-방안)
+   - [조직도 공유 및 외부 표시 방안](#36-조직도-공유-및-외부-표시-방안)
+   - [직원 사진 관리 및 표시 방안](#37-직원-사진-관리-및-표시-방안)
+   - [조직도 변경 권한 정책 정의](#38-조직도-변경-권한-정책-정의)
+   - [조직도 동기화 및 DB 반영 방식 설계](#39-조직도-동기화-및-db-반영-방식-설계)
+   - [회원가입 정책 정의](#310-회원가입-정책-정의)
+   - [SSO 로그인 및 서비스별 접근 권한 정책 정의](#311-sso-로그인-및-서비스별-접근-권한-정책-정의)
+   - [서비스별 접근 권한 관리자 기능](#312-서비스별-접근-권한-관리자-기능)
+   - [관리자 화면 구성](#313-관리자-화면-구성)
+   - [감사 로그와 이력 관리](#314-감사-로그와-이력-관리)
+4. [우선순위](#4-우선순위)
+5. [후속 진행 작업](#5-후속-진행-작업)
+6. [기대 효과](#6-기대-효과)
+7. [참고 오픈소스 후보](#7-참고-오픈소스-후보)
+
 ## 1. 제안 목적
 
-Baron SSO에 접근하는 사내 직원을 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다.
+Baron SSO에 접근하는 사내 직원을 회사별 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다.
 
-이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, SSO 접근 권한의 기준 데이터를 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다.
+이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, 여러 자회사의 조직도와 인사정보를 SSO 접근 관리 기준으로 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다.
+
+또한 각 회사의 인사담당자 또는 조직관리 담당자가 회사별 조직도를 시각적으로 관리하고, 승인된 조직 변경 사항을 각 회사 DB의 조직 귀속 정보에 제한적으로 반영하는 방안까지 함께 검토한다.
 
 ## 2. 기본 방향
 
 - Baron SSO 접근 사용자를 조직도 기준으로 식별한다.
+- 여러 자회사를 회사 단위로 구분하고, 각 회사별 조직도를 독립적으로 관리한다.
+- 조직도는 본부, 부문, 부서, 팀, 셀 등 회사별 조직 단위의 계층 구조로 시각화하고, 권한이 있는 담당자만 수정할 수 있게 한다.
 - 재직상태, 부서, 직책, 권한 그룹을 기준으로 로그인 가능 여부와 서비스 접근 범위를 관리한다.
-- 조직도 원천 데이터는 하나의 기준 시스템에서 가져오는 것을 원칙으로 한다.
-- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화 방식으로 확장한다.
+- 조직도 원천 데이터는 회사별 인사정보 또는 조직관리 DB를 기준으로 하되, SSO에서는 접근 통제에 필요한 조직 정보를 통합 관리한다.
+- 조직도 변경 사항은 검증과 승인 절차를 거친 뒤 각 회사 DB에 반영한다.
+- 각 회사 DB 반영 대상은 개인정보 전체가 아니라 조직단위코드, 상위조직코드, 직책코드, 소속상태 같은 조직 귀속 정보로 제한한다.
+- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 회사별 API 또는 배치 동기화 방식으로 확장한다.
 - 모든 권한 변경과 로그인 이력은 감사 로그로 남긴다.
 
 ## 3. 단계별 추진안
@@ -31,6 +77,13 @@ Baron SSO에 접근하는 사내 직원을 조직도 기준으로 관리하고,
 - 재직상태
 - SSO 권한
 - 최종 로그인일
+- 소속 회사
+- 부서코드
+- 팀코드
+- 조직단위코드
+- 상위조직코드
+- 사진 보유 여부
+- 사진 갱신일
 
 이 단계에서는 퇴사자, 휴직자, 부서 미지정자, 중복 계정, 공용 계정을 식별한다.
 
@@ -44,24 +97,60 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
 
 - 회사
 - 본부
+- 부문
 - 부서
+- 부서코드
 - 팀
-- 상위부서
-- 부서장
+- 팀코드
+- 셀
+- 셀코드
+- 조직단위코드
+- 조직단위유형
+- 상위조직코드
+- 조직장
 - 사번
 - 이름
 - 이메일
 - 직급
 - 직책
+- 직책코드
 - 재직상태
+- 발령상태
+- 입사일
+- 퇴사일
+- 사진 파일 식별자
+- 사진 버전
+- 사진 갱신일
 
 이때 권한 제어에 필요한 항목과 단순 조회용 항목을 분리한다.
 
-예를 들어 `부서`, `직책`, `재직상태`는 권한 판단에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다.
+예를 들어 `회사`, `조직단위코드`, `상위조직코드`, `직책코드`, `재직상태`, `발령상태`는 권한 판단과 각 회사 DB 반영에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다.
+
+조직도는 부서/팀으로 고정하지 않고, 회사별 조직 레벨을 설정할 수 있게 한다.
+
+예시는 다음과 같다.
+
+```text
+회사 -> 본부 -> 부문 -> 부서 -> 팀 -> 셀
+회사 -> 사업부 -> 부서 -> 파트
+회사 -> 센터 -> 그룹 -> 팀
+```
+
+이를 위해 조직 단위는 공통적으로 다음 구조를 가진다.
+
+| 항목 | 설명 |
+| --- | --- |
+| 조직단위코드 | 회사 내에서 조직 단위를 식별하는 코드 |
+| 조직단위명 | 화면에 표시할 조직명 |
+| 조직단위유형 | 본부, 부문, 부서, 팀, 셀, 파트 등 |
+| 상위조직코드 | 계층 구조를 만들기 위한 상위 조직 코드 |
+| 회사코드 | 조직 단위가 속한 회사 |
+| 조직장 사용자 ID | 해당 조직 단위의 책임자 |
+| 사용 여부 | 폐지된 조직인지 여부 |
 
 ### 3.3 조직도 원천 시스템 결정
 
-조직도와 직원 정보의 원천 시스템을 결정한다.
+조직도와 직원 정보의 원천 시스템을 회사별로 결정한다.
 
 후보는 다음과 같다.
 
@@ -71,23 +160,207 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
 - AD/LDAP
 - 별도 조직도 관리 시스템
 
-핵심 원칙은 조직도 원본을 하나만 두는 것이다.
+핵심 원칙은 각 회사별 조직도 원본을 명확히 정하는 것이다.
 
-Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천 시스템의 조직/직원 정보를 받아와 동기화하는 방식이 안정적이다.
+Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하다. 따라서 SSO에서는 접근 통제에 필요한 조직 정보를 관리하고, 실제 회사별 인사정보 변경은 정해진 항목에 한해 각 회사 DB와 연동하는 방식이 안정적이다.
 
 원천 시스템 연동이 당장 어렵다면 초기에는 관리자 업로드 방식으로 시작할 수 있다.
 
-### 3.4 조직도 동기화 방식 설계
+### 3.4 회사별 조직도 관리 화면 설계
+
+조직도는 회사별로 분리하여 조회하고 관리한다.
+
+화면은 회사별 조직 단위의 계층 구조를 한눈에 볼 수 있도록 트리 또는 조직도 형태로 제공한다.
+
+주요 기능은 다음과 같다.
+
+- 회사별 조직도 조회
+- 조직 단위 생성, 수정, 이동
+- 조직 단위 유형 관리
+- 상위 조직 변경
+- 직원의 소속 조직 이동
+- 변경 전/후 비교
+- 변경사항 임시 저장
+- 승인 후 각 회사 DB 반영
+- 반영 성공/실패 결과 확인
+
+이 화면은 단순 조직도 조회 화면이 아니라 `회사별 조직 귀속 정보 관리 화면`으로 정의한다.
+
+### 3.5 조직도 UI 오픈소스 적용 방안
+
+조직도 화면은 직접 처음부터 구현하기보다 검증된 오픈소스 라이브러리를 활용하는 방안을 우선 검토한다.
+
+후보는 다음과 같다.
+
+| 후보 | 특징 | 적용 방향 |
+| --- | --- | --- |
+| `d3-org-chart` | D3 기반 조직도 라이브러리이며 확대/축소, 노드 추가/삭제, 검색, 내보내기, React/Vue/Angular 연동 예제가 있다. | 회사별 조직도 조회 화면과 임베드용 조직도에 우선 검토한다. |
+| `OrgChart` | jQuery 기반 조직도 플러그인이며 드래그 앤 드롭으로 구조 변경, JSON 저장, 이미지/PDF 내보내기, 모바일 터치를 지원한다. | 조직 담당자가 조직 단위 이동을 직관적으로 수행하는 편집 화면에 우선 검토한다. |
+| `React Flow` | React 기반 노드 편집 UI 라이브러리이며 노드 이동, 연결선, 미니맵, 컨트롤 등 편집 도구 구성에 강하다. | 기존 프론트엔드가 React 계열이거나 조직도 외 추가 워크플로우 편집이 필요할 때 검토한다. |
+| `Treant.js` | SVG 기반 트리 다이어그램 라이브러리이며 단순 조직도 표현에 적합하다. | 수정 기능보다 가벼운 조회 전용 화면이 필요할 때 검토한다. |
+
+권장 적용안은 다음과 같다.
+
+- 조회/공유용 조직도는 `d3-org-chart`를 우선 검토한다.
+- 조직 담당자 편집 화면은 `OrgChart` 또는 `React Flow`를 비교 검토한다.
+- 드래그 앤 드롭으로 조직 단위 이동을 처리하더라도 즉시 DB에 반영하지 않고 변경 요청으로 저장한다.
+- 노드 이동, 조직 단위 생성, 직원 소속 이동은 모두 변경 전/후 비교 화면을 거친다.
+- 최종 반영은 승인 후 회사별 DB 반영 어댑터를 통해 수행한다.
+
+### 3.6 조직도 공유 및 외부 표시 방안
+
+각 회사의 완성된 조직도는 Baron SSO 내부에서만 보는 것이 아니라 각 회사 인트라넷, 모바일 페이지, 그룹웨어 등에서도 표시할 수 있게 한다.
+
+제공 방식은 다음 세 가지를 제안한다.
+
+| 방식 | 설명 | 활용 예 |
+| --- | --- | --- |
+| 링크 공유 | 회사별 조직도 조회 URL을 발급한다. | 각 회사 인트라넷 메뉴에서 조직도 링크로 연결 |
+| 임베드 위젯 | `iframe` 또는 스크립트 형태로 조직도를 외부 페이지에 삽입한다. | 인트라넷 메인, 모바일 웹, 그룹웨어 조직도 메뉴에 표시 |
+| 이미지 내보내기 | 현재 조직도를 PNG/SVG/PDF 형태로 생성한다. | 공지, 보고자료, 모바일 이미지 조회, 변경 전/후 기록 |
+
+공유 URL 예시는 다음과 같다.
+
+```text
+https://sso.example.com/org-chart/companies/{companyCode}
+https://sso.example.com/org-chart/companies/{companyCode}/embed
+https://sso.example.com/org-chart/companies/{companyCode}/export.png
+```
+
+외부 표시 시 보안 조건은 다음과 같다.
+
+- 조직도 공개 범위는 회사별로 설정한다.
+- 사내망 또는 SSO 인증 사용자에게만 노출한다.
+- 임베드 토큰을 발급하여 허용된 인트라넷 도메인에서만 표시한다.
+- 모바일 페이지에서는 개인정보 노출을 줄이고 조직 단위 중심으로 표시한다.
+- 외부 표시용 조직도는 조회 전용으로 제공하고 변경 기능은 Baron SSO 관리자 화면에서만 허용한다.
+- 이미지 내보내기 파일에는 생성일, 회사코드, 조직도 버전 정보를 포함한다.
+
+조직도 변경 이후 외부 표시 갱신 흐름은 다음과 같다.
+
+```text
+조직도 변경 승인
+-> 각 회사 DB 반영
+-> Baron SSO 조직도 버전 갱신
+-> 인트라넷/모바일 임베드 화면 자동 갱신
+-> 필요 시 PNG/SVG/PDF 이미지 재생성
+```
+
+### 3.7 직원 사진 관리 및 표시 방안
+
+조직도와 SSO 로그인 화면에서 직원 사진을 표시하려면 사진 파일의 원천, 저장 방식, 노출 범위를 별도 정책으로 정의해야 한다.
+
+사진은 개인을 식별할 수 있는 정보이므로 Baron SSO가 각 회사의 원본 사진 저장소를 대체하는 구조는 권장하지 않는다.
+
+검토 가능한 방식은 다음과 같다.
+
+| 방식 | 장점 | 단점 |
+| --- | --- | --- |
+| SSO 서버로 사진 파일을 가져와 통일 관리 | 조직도, 모바일, 인트라넷에서 빠르고 일관되게 표시 가능 | SSO가 개인정보성 파일을 보관하므로 보안, 삭제, 접근통제 부담 증가 |
+| 각 회사가 사진 파일을 보관하고 SSO는 파일명만 관리 | 원본 사진 관리 책임이 각 회사에 남음 | 회사별 경로/권한/파일명 규칙 차이로 표시 실패 가능성이 높고, 모바일/외부 임베드 연동이 복잡함 |
+| 원본은 각 회사가 보관하고 SSO는 표준 썸네일과 메타데이터만 관리 | 원본 책임은 각 회사에 두면서 SSO 화면에서는 안정적으로 표시 가능 | 사진 동기화 배치/API와 캐시 무효화 정책이 필요함 |
+
+권장안은 `원본은 각 회사 보관, SSO는 표준 썸네일과 메타데이터 관리` 방식이다.
+
+권장 구조는 다음과 같다.
+
+```text
+각 회사 인사/사진 저장소
+-> 사진 원본 또는 변경 이벤트 제공
+-> Baron SSO 사진 동기화
+-> 표준 썸네일 생성
+-> SSO 보안 저장소에 저장
+-> 조직도/로그인/인트라넷 임베드 화면에서 표시
+```
+
+SSO에서 관리할 사진 정보는 다음으로 제한한다.
+
+- 회사코드
+- 사번 또는 사용자 식별자
+- 사진 파일 식별자
+- 사진 버전
+- 사진 해시값
+- 사진 갱신일
+- 기본 이미지 사용 여부
+- 사진 공개 범위
+
+사진 파일명은 회사 간 중복을 피하기 위해 공통 규칙을 사용한다.
+
+```text
+{companyCode}_{employeeNo}_{photoVersion}.jpg
+```
+
+단, 화면이나 API에서는 실제 파일명을 직접 노출하지 않고 SSO의 사진 조회 URL을 사용한다.
+
+```text
+https://sso.example.com/photos/users/{userId}
+https://sso.example.com/photos/users/{userId}?size=thumbnail
+```
+
+운영 정책은 다음과 같다.
+
+- 원본 사진은 각 회사 인사 시스템 또는 사진 저장소를 기준으로 한다.
+- SSO는 조직도 표시용 표준 크기 썸네일만 보관한다.
+- 사진이 없는 직원은 기본 이미지를 표시한다.
+- 퇴사자 또는 접근 제한 대상자의 사진은 정책에 따라 비공개 또는 기본 이미지로 대체한다.
+- 사진 변경 시 사진 버전을 올려 캐시를 무효화한다.
+- 외부 임베드 조직도에서는 권한이 허용된 사용자에게만 사진을 표시한다.
+- 사진 다운로드는 기본 차단하고, 필요한 경우 관리자 권한과 감사 로그를 요구한다.
+
+개인정보 보호 관점에서 사진 원본을 SSO에 장기 보관하는 방식은 피하고, 표시 목적에 필요한 최소 크기와 최소 정보만 관리하는 것이 적절하다.
+
+### 3.8 조직도 변경 권한 정책 정의
+
+조직도의 변경은 각 회사에서 정해진 인원만 가능해야 한다.
+
+권한은 조회 권한과 변경 권한을 분리하고, 회사별로 적용 범위를 제한한다.
+
+권한 역할 예시는 다음과 같다.
+
+```text
+전체 관리자
+- 전체 자회사 조직도 조회/관리
+- 회사별 담당자 지정
+- 변경 이력 조회
+
+회사 관리자
+- 소속 회사 조직도 조회
+- 소속 회사 조직 단위 생성, 수정, 이동 요청
+- 소속 회사 직원 소속 조직 이동 요청
+
+승인자
+- 조직 변경 요청 승인/반려
+- 승인 후 각 회사 DB 반영 승인
+
+조회자
+- 조직도 조회만 가능
+- 변경 불가
+```
+
+권한 제한 원칙은 다음과 같다.
+
+- A회사 담당자는 A회사 조직도만 수정할 수 있다.
+- B회사 조직도는 B회사 담당자 또는 전체 관리자만 수정할 수 있다.
+- 개인 고유정보는 조직도 화면에서 직접 수정하지 않는다.
+- 조직 귀속 정보만 변경 대상으로 허용한다.
+- 승인 전에는 각 회사 DB에 반영하지 않는다.
+- 모든 변경 전/후 이력과 작업자를 기록한다.
+
+### 3.9 조직도 동기화 및 DB 반영 방식 설계
 
 초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다.
 
 권장 흐름은 다음과 같다.
 
 ```text
-인사/조직도 시스템
--> 직원/부서 정보 동기화
--> Baron SSO 사용자/조직 테이블 반영
--> SSO 로그인 시 재직상태와 권한 확인
+각 회사 인사/조직도 DB
+-> Baron SSO 조직도 관리 화면
+-> 조직 변경 임시 저장
+-> 유효성 검증
+-> 승인
+-> 각 회사 DB의 조직 귀속 정보 반영
+-> 반영 결과 기록
+-> SSO 권한/접근 정책 갱신
 ```
 
 동기화 주기는 다음 기준으로 제안한다.
@@ -96,7 +369,123 @@ Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천
 - 안정화 이후: 수시 배치 또는 API 연동
 - 보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영
 
-### 3.5 접근 권한 정책 정의
+각 회사 DB에 반영할 수 있는 항목은 다음과 같이 제한한다.
+
+- 조직단위코드
+- 상위조직코드
+- 조직단위유형
+- 부서코드
+- 팀코드
+- 셀코드
+- 직책코드
+- 소속상태
+
+기존 회사 DB가 부서코드와 팀코드 중심으로 구성되어 있다면 `조직단위코드`를 회사별 기존 코드 체계에 매핑한다.
+
+각 회사 DB에 반영하지 않는 항목은 다음과 같다.
+
+- 이름
+- 주민등록번호 등 고유식별정보
+- 연락처
+- 주소
+- 급여 정보
+- 기타 민감 개인정보
+
+회사별 DB 구조가 다를 수 있으므로 회사별 연동 어댑터를 두는 방식을 권장한다.
+
+```text
+Baron SSO 조직 변경 요청
+-> 공통 변경 모델
+-> A회사 DB 반영 어댑터
+-> B회사 DB 반영 어댑터
+-> C회사 DB 반영 어댑터
+```
+
+이 구조를 사용하면 회사별 DB 테이블 구조가 다르더라도 SSO 쪽에서는 공통 변경 요청 모델을 유지할 수 있다.
+
+다만 각 회사의 인사 DB는 일반적으로 소속부서코드, 소속팀코드처럼 2개 내지 3개의 컬럼으로 조직 소속을 관리하는 경우가 많다.
+
+반면 Baron SSO 조직도는 본부, 부문, 부서, 팀, 셀처럼 더 깊은 계층을 표현할 수 있어야 하므로, SSO의 조직도 계층을 각 회사 DB 컬럼에 그대로 1:1 반영하는 방식은 적절하지 않다.
+
+따라서 회사별 `조직 매핑 정책`을 별도로 둔다.
+
+```text
+Baron SSO 조직도 계층
+-> 회사별 조직 매핑 정책
+-> 회사별 DB 컬럼 반영 값 산출
+-> 회사별 DB 반영 어댑터 실행
+```
+
+회사별 조직 매핑 정책 예시는 다음과 같다.
+
+| 회사 | SSO 조직도 예시 | 회사 DB 컬럼 구조 | 반영 방식 |
+| --- | --- | --- | --- |
+| A회사 | 본부 -> 부서 -> 팀 -> 셀 | `dept_code`, `team_code` | 부서는 `dept_code`, 말단 팀 또는 셀은 `team_code`에 반영 |
+| B회사 | 사업부 -> 부서 -> 파트 | `org_code` | 사용자의 최종 소속 조직코드만 `org_code`에 반영 |
+| C회사 | 본부 -> 부문 -> 부서 -> 팀 | `hq_code`, `dept_code`, `team_code` | 본부/부서/팀을 각각 매핑하고 부문은 SSO 내부 계층으로만 관리 |
+
+검토해야 할 항목은 다음과 같다.
+
+- 각 회사 인사 DB의 조직 관련 컬럼 수
+- 각 컬럼이 의미하는 조직 레벨
+- 회사 DB에 반드시 반영해야 하는 조직 레벨
+- SSO 내부에서만 관리해도 되는 조직 레벨
+- 말단 조직 기준 반영 여부
+- 상위 조직 변경 시 하위 직원 코드 변경 필요 여부
+- 기존 코드 체계와 신규 조직단위코드의 매핑 방식
+- 컬럼 수가 부족한 회사의 처리 방식
+
+해결 방안은 다음과 같이 제안한다.
+
+- SSO 내부에는 유연한 조직 계층을 보관한다.
+- 각 회사 DB에는 해당 회사가 가진 컬럼 구조에 맞춰 필요한 값만 반영한다.
+- 회사별로 `조직단위코드 -> 회사 DB 컬럼` 매핑 테이블을 둔다.
+- DB 컬럼으로 표현할 수 없는 상위조직, 셀, 파트 등의 계층은 SSO 내부 조직도에서만 관리한다.
+- 각 회사 DB에 반영되는 값은 변경 전 미리보기 화면에서 확인하게 한다.
+- 매핑되지 않은 조직 단위로 직원 이동 시 승인 전 오류 또는 경고를 표시한다.
+
+예를 들어 셀 단위가 추가되었지만 A회사 DB에 `cell_code` 컬럼이 없다면, 셀 정보는 SSO 조직도에서만 관리하고 실제 A회사 DB에는 상위 팀의 `team_code`만 반영할 수 있다.
+
+### 3.10 회원가입 정책 정의
+
+Baron SSO 회원가입은 각 회사 인사 DB에 존재하는 직원인지 확인한 뒤 허용해야 한다.
+
+특히 발령상태에 따라 가입 가능 여부를 정책으로 명확히 정의한다.
+
+회원가입 정책 예시는 다음과 같다.
+
+| 인사 DB 상태 | 회원가입 가능 여부 | 설명 |
+| --- | --- | --- |
+| 발령완료 | 가능 | 정상 소속, 조직단위코드가 확정된 직원 |
+| 발령대기 | 조건부 가능 또는 불가 | 입사 예정자, 소속 조직 미확정자는 제한 가입 또는 가입 대기 처리 |
+| 입사예정 | 조건부 가능 | 교육, 온보딩 시스템만 접근이 필요한 경우 제한 가입 가능 |
+| 휴직 | 원칙적 불가 또는 관리자 승인 | 기존 계정이 있는 경우 로그인 정책에서 별도 통제 |
+| 퇴사 | 불가 | 신규 가입 불가 |
+| 인사 DB 미존재 | 불가 | 사번/이메일이 확인되지 않는 사용자 |
+
+권장 가입 흐름은 다음과 같다.
+
+```text
+회원가입 요청
+-> 회사 선택
+-> 사번/이메일/휴대폰 등 본인 확인
+-> 각 회사 인사 DB 상태 조회
+-> 발령상태/재직상태 검증
+-> 가입 가능 여부 결정
+-> 기본 접근 권한 부여
+-> 가입 이력 기록
+```
+
+가입 시 기본 원칙은 다음과 같다.
+
+- 각 회사 인사 DB에 존재하는 직원만 가입할 수 있다.
+- 발령완료 직원은 정상 가입을 허용한다.
+- 발령대기 또는 입사예정자는 제한 가입 또는 가입 대기 상태로 관리한다.
+- 퇴사자는 신규 가입을 차단한다.
+- 조직단위코드가 없는 사용자는 기본 시스템 접근을 제한한다.
+- 가입 후 부여되는 기본 권한은 회사, 재직상태, 발령상태, 소속 조직 기준으로 결정한다.
+
+### 3.11 SSO 로그인 및 서비스별 접근 권한 정책 정의
 
 조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다.
 
@@ -115,24 +504,105 @@ Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천
 
 관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다.
 
-### 3.6 관리자 화면 구성
+로그인 가능 여부와 서비스별 접근 가능 여부는 분리해서 판단한다.
 
-초기 관리자 화면은 복잡한 조직도 편집 기능보다 SSO 접근 통제에 필요한 조회와 상태 확인 중심으로 구성한다.
+예를 들어 SSO 로그인은 허용하되, 실제 접근 가능한 시스템은 직원 상태와 권한 정책에 따라 다르게 제한할 수 있다.
+
+상태별 정책 예시는 다음과 같다.
+
+| 직원 상태 | SSO 로그인 | 시스템 A | 시스템 B | 시스템 C | 설명 |
+| --- | --- | --- | --- | --- | --- |
+| 재직 | 가능 | 가능 | 가능 | 가능 | 기본적으로 모든 업무 시스템 접근 가능 |
+| 휴직 | 가능 또는 제한 | 가능 | 가능 | 불가 | 급여/인사 확인 등 일부 시스템만 허용 가능 |
+| 퇴사 1년 이내 | 불가 또는 제한 | 불가 | 불가 | 가능 | 퇴직정산, 증명서 발급 등 특수 시스템만 허용 가능 |
+| 퇴사 1년 초과 | 불가 | 불가 | 불가 | 불가 | 모든 접근 차단 |
+| 발령대기 | 가능 또는 대기 | 가능 | 불가 | 불가 | 온보딩 또는 교육 시스템만 허용 가능 |
+
+서비스별 접근 제한은 다음 기준을 조합해 판단한다.
+
+- 회사
+- 재직상태
+- 발령상태
+- 조직단위코드
+- 상위조직코드
+- 조직단위유형
+- 부서코드
+- 팀코드
+- 직책코드
+- 권한 그룹
+- 개별 사용자 예외 권한
+- 접근 허용 기간
+
+권한 판단 흐름은 다음과 같다.
+
+```text
+SSO 로그인 요청
+-> 사용자 식별
+-> 각 회사 인사 DB 또는 SSO 동기화 정보에서 현재 상태 확인
+-> SSO 로그인 가능 여부 판단
+-> 대상 시스템 접근 정책 조회
+-> 상태/회사/소속 조직/권한 그룹/예외 권한 평가
+-> 접근 허용 또는 차단
+-> 접근 이력 기록
+```
+
+재직자라 하더라도 모든 시스템에 자동 접근시키지 않고, 시스템별 접근 권한을 별도로 관리할 수 있어야 한다.
+
+예를 들어 재직자 중에서도 특정 부서만 회계 시스템에 접근하거나, 특정 직책 이상만 관리자 시스템에 접근하도록 제한할 수 있다.
+
+### 3.12 서비스별 접근 권한 관리자 기능
+
+서비스별 접근 정책을 관리할 수 있는 관리자 페이지를 제공한다.
+
+주요 기능은 다음과 같다.
+
+- SSO 연동 시스템 목록 관리
+- 시스템별 접근 가능 회사 설정
+- 시스템별 접근 가능 재직상태 설정
+- 시스템별 접근 가능 발령상태 설정
+- 시스템별 접근 가능 조직 단위 설정
+- 시스템별 접근 가능 직책/권한 그룹 설정
+- 사용자별 예외 허용/차단 설정
+- 예외 권한 만료일 설정
+- 접근 정책 변경 전/후 비교
+- 정책 변경 승인/반려
+- 시스템별 접근 가능 사용자 목록 조회
+- 사용자별 접근 가능 시스템 목록 조회
+
+관리자 화면에서는 `기본 정책`과 `예외 정책`을 구분해서 보여주는 것이 좋다.
+
+기본 정책은 회사/상태/조직/직책 기준으로 자동 적용하고, 예외 정책은 특정 사용자에게 기간을 정해 수동 부여한다.
+
+### 3.13 관리자 화면 구성
+
+초기 관리자 화면은 SSO 접근 통제에 필요한 조회와 상태 확인을 기본으로 구성하고, 이후 회사별 조직도 편집 기능을 확장한다.
 
 우선 구현 대상은 다음과 같다.
 
+- 회사별 조직도 조회
+- 회사별 조직도 변경 요청
 - 직원 목록 조회
 - 부서별 사용자 조회
 - 사용자 상세 정보 확인
 - 재직상태별 필터
+- 발령상태별 필터
 - SSO 접근 가능/불가 상태 표시
+- 사용자별 접근 가능 시스템 표시
+- 시스템별 접근 가능 사용자 표시
+- 직원 사진 동기화 상태 조회
+- 직원 사진 표시/비공개 상태 관리
 - 권한 그룹 매핑
+- 서비스별 접근 정책 관리
+- 사용자별 예외 접근 권한 관리
+- 회사별 조직도 담당자 지정
+- 조직 변경 승인/반려
+- 각 회사 DB 반영 결과 조회
 - 조직도 동기화 이력 조회
 - 수동 예외 권한 등록
 
 팀장 보고 시에는 단순한 `조직도 화면`이 아니라 `SSO 접근 통제 화면`으로 설명하는 것이 적절하다.
 
-### 3.7 감사 로그와 이력 관리
+### 3.14 감사 로그와 이력 관리
 
 SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨야 한다.
 
@@ -140,10 +610,25 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨
 
 - 로그인 성공 이력
 - 로그인 실패 이력
+- 회원가입 요청 이력
+- 회원가입 승인/차단 이력
+- 상태 기준 로그인 차단 이력
+- 서비스별 접근 허용/차단 이력
 - 퇴사자 로그인 시도 이력
 - 조직 정보 변경 이력
 - 권한 변경 이력
+- 서비스별 접근 정책 변경 이력
+- 사용자별 예외 권한 변경 이력
 - 관리자 수동 변경 이력
+- 조직도 변경 요청 이력
+- 조직도 변경 승인/반려 이력
+- 각 회사 DB 반영 요청 이력
+- 각 회사 DB 반영 성공/실패 이력
+- 조직도 링크/임베드 접근 이력
+- 조직도 이미지 내보내기 이력
+- 직원 사진 동기화 이력
+- 직원 사진 조회 이력
+- 직원 사진 비공개/기본 이미지 전환 이력
 - 동기화 성공/실패 이력
 
 감사 로그는 보안 사고 대응, 내부 감사, 권한 변경 원인 추적에 활용할 수 있다.
@@ -153,28 +638,67 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨
 가장 먼저 진행해야 할 작업은 다음 세 가지다.
 
 1. 현재 SSO 사용자 목록 정리
-2. 재직상태 기준 로그인 허용/차단 정책 확정
-3. 조직도 원천 데이터 결정
+2. 회원가입 가능 상태와 차단 상태 정책 확정
+3. 재직상태 기준 로그인 허용/차단 정책 확정
+4. 회사별 조직도 원천 데이터 결정
+5. 회사별 조직도 변경 담당자와 승인자 지정
+6. 각 회사 DB에 반영 가능한 조직 귀속 항목 확정
+7. 서비스별 접근 권한 정책 기준 확정
+8. 직원 사진 원천과 SSO 표시 방식 확정
+9. 회사별 조직도 계층과 DB 컬럼 매핑 정책 확정
 
-이 세 가지가 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리 작업을 순차적으로 진행할 수 있다.
+이 항목들이 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리, 각 회사 DB 반영 기능을 순차적으로 진행할 수 있다.
 
 ## 5. 후속 진행 작업
 
 후속 작업은 다음 순서로 진행하는 것을 제안한다.
 
 1. 현재 SSO 사용자 현황 추출
-2. 조직도 기준 항목 정의
-3. 인사/조직도 원천 시스템 확인
+2. 회사별 조직도 기준 항목 정의
+3. 회사별 인사/조직도 원천 시스템 확인
 4. 사용자-조직 매핑 테이블 설계
-5. 퇴사자/휴직자 로그인 차단 정책 적용
-6. 관리자 조회 화면 추가
-7. 조직도 동기화 배치 또는 API 구현
-8. 권한 변경 및 로그인 감사 로그 보강
+5. 회원가입 가능 상태 정책 정의
+6. 로그인 가능 상태 정책 정의
+7. 서비스별 접근 권한 정책 정의
+8. 회사별 조직도 변경 권한 정책 정의
+9. 조직도 변경 승인 절차 정의
+10. 각 회사 DB 반영 가능 항목 확정
+11. 회사별 조직 계층과 DB 컬럼 매핑 정책 정의
+12. 조직도 UI 오픈소스 후보 기술 검토
+13. 조직도 링크/임베드/이미지 제공 방식 확정
+14. 직원 사진 원천/동기화/표시 정책 확정
+15. 퇴사자/휴직자 로그인 차단 정책 적용
+16. 서비스별 접근 정책 관리자 화면 추가
+17. 관리자 조회 화면 추가
+18. 회사별 조직도 관리 화면 추가
+19. 조직도 동기화 배치 또는 API 구현
+20. 직원 사진 썸네일 동기화 구현
+21. 각 회사 DB 반영 어댑터 구현
+22. 권한 변경 및 로그인 감사 로그 보강
 
 ## 6. 기대 효과
 
 - 퇴사자 또는 휴직자의 SSO 접근을 빠르게 차단할 수 있다.
+- 발령상태와 재직상태에 따라 회원가입 가능 여부를 명확히 통제할 수 있다.
+- 로그인 가능 여부와 실제 시스템 접근 가능 여부를 분리해서 관리할 수 있다.
+- 재직자라도 시스템별 접근 권한을 세밀하게 제한할 수 있다.
+- 휴직자, 퇴사자, 발령대기자에게 필요한 시스템만 제한적으로 허용할 수 있다.
 - 부서 이동이나 조직 변경에 따른 권한 정리를 체계화할 수 있다.
+- 여러 자회사의 조직도를 회사별로 분리하여 관리할 수 있다.
+- 권한이 있는 담당자만 조직도 변경을 요청하거나 승인할 수 있다.
+- 각 회사 DB에는 필요한 조직 귀속 정보만 제한적으로 반영할 수 있다.
+- 회사별 DB 컬럼 수가 달라도 조직 매핑 정책으로 반영 방식을 다르게 적용할 수 있다.
+- 완성된 조직도를 각 회사 인트라넷이나 모바일 페이지에서 쉽게 표시할 수 있다.
+- 보고자료나 공지용 조직도 이미지를 별도 수작업 없이 생성할 수 있다.
+- 각 회사 직원 사진을 표준 썸네일 형태로 일관되게 표시할 수 있다.
+- 사진 원본은 각 회사에 유지하면서 SSO는 표시 목적의 최소 정보만 관리할 수 있다.
 - 관리자 권한 부여 기준을 명확히 할 수 있다.
 - SSO 접근 이력과 권한 변경 이력을 감사 관점에서 추적할 수 있다.
 - 향후 자동 권한 관리와 서비스별 접근 제어로 확장할 수 있다.
+
+## 7. 참고 오픈소스 후보
+
+- `d3-org-chart`: https://github.com/bumbeishvili/org-chart
+- `OrgChart`: https://github.com/dabeng/OrgChart
+- `React Flow`: https://github.com/xyflow/xyflow
+- `Treant.js`: https://github.com/fperucic/treant-js