kevin/MyDoc

Fork 0

Files

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

2026-06-17 09:34:39 +09:00

32 KiB

Raw Blame History

Baron SSO 조직도 관리 개선 제안

문서 요약

이 문서는 Baron SSO를 단순 로그인 시스템이 아니라 여러 자회사의 조직도, 직원 상태, 서비스 접근 권한을 통합 관리하는 기준 시스템으로 확장하기 위한 제안서다.

주요 내용은 다음과 같다.

여러 자회사별 조직도를 회사 단위로 분리하여 관리한다.
조직도는 부서/팀에 고정하지 않고 본부, 부문, 부서, 팀, 셀 등 유연한 조직 단위 계층으로 관리한다.
조직 변경은 권한이 있는 담당자만 요청할 수 있고, 승인 후 각 회사 DB에 제한적으로 반영한다.
각 회사 DB 컬럼 구조가 다르므로 회사별 조직 매핑 정책과 DB 반영 어댑터를 둔다.
회원가입은 각 회사 인사 DB의 발령상태와 재직상태를 기준으로 허용 여부를 판단한다.
SSO 로그인 가능 여부와 실제 업무 시스템 접근 가능 여부를 분리하여 관리한다.
직원 사진은 원본을 각 회사에 두고 SSO는 표준 썸네일과 메타데이터만 관리하는 방안을 권장한다.
완성된 조직도는 링크, 임베드, 이미지 형태로 인트라넷이나 모바일 페이지에 표시할 수 있게 한다.
모든 조직 변경, 권한 변경, 로그인, 사진 조회, 외부 표시 이력은 감사 로그로 남긴다.

1. 제안 목적

Baron SSO에 접근하는 사내 직원을 회사별 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다.

이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, 여러 자회사의 조직도와 인사정보를 SSO 접근 관리 기준으로 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다.

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

2. 기본 방향

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

3. 단계별 추진안

3.1 현재 사용자 기준 정리

먼저 현재 Baron SSO에 접근 가능한 사용자 목록을 정리한다.

관리 대상 항목은 다음과 같다.

사번
이름
이메일
부서
직급
직책
재직상태
SSO 권한
최종 로그인일
소속 회사
부서코드
팀코드
조직단위코드
상위조직코드
사진 보유 여부
사진 갱신일

이 단계에서는 퇴사자, 휴직자, 부서 미지정자, 중복 계정, 공용 계정을 식별한다.

산출물은 현재 SSO 사용자 현황표로 관리한다.

3.2 조직도 기준 데이터 정의

Baron SSO에서 사용할 조직도 기준 항목을 정의한다.

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

회사
본부
부문
부서
부서코드
팀
팀코드
셀
셀코드
조직단위코드
조직단위유형
상위조직코드
조직장
사번
이름
이메일
직급
직책
직책코드
재직상태
발령상태
입사일
퇴사일
사진 파일 식별자
사진 버전
사진 갱신일

이때 권한 제어에 필요한 항목과 단순 조회용 항목을 분리한다.

예를 들어 회사, 조직단위코드, 상위조직코드, 직책코드, 재직상태, 발령상태는 권한 판단과 각 회사 DB 반영에 직접 사용할 수 있고, 직급은 감사 또는 조회 목적으로만 사용할 수 있다.

조직도는 부서/팀으로 고정하지 않고, 회사별 조직 레벨을 설정할 수 있게 한다.

예시는 다음과 같다.

회사 -> 본부 -> 부문 -> 부서 -> 팀 -> 셀
회사 -> 사업부 -> 부서 -> 파트
회사 -> 센터 -> 그룹 -> 팀

이를 위해 조직 단위는 공통적으로 다음 구조를 가진다.

항목	설명
조직단위코드	회사 내에서 조직 단위를 식별하는 코드
조직단위명	화면에 표시할 조직명
조직단위유형	본부, 부문, 부서, 팀, 셀, 파트 등
상위조직코드	계층 구조를 만들기 위한 상위 조직 코드
회사코드	조직 단위가 속한 회사
조직장 사용자 ID	해당 조직 단위의 책임자
사용 여부	폐지된 조직인지 여부

3.3 조직도 원천 시스템 결정

조직도와 직원 정보의 원천 시스템을 회사별로 결정한다.

후보는 다음과 같다.

인사 시스템
그룹웨어
ERP
AD/LDAP
별도 조직도 관리 시스템

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

Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하다. 따라서 SSO에서는 접근 통제에 필요한 조직 정보를 관리하고, 실제 회사별 인사정보 변경은 정해진 항목에 한해 각 회사 DB와 연동하는 방식이 안정적이다.

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

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 예시는 다음과 같다.

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 관리자 화면에서만 허용한다.
이미지 내보내기 파일에는 생성일, 회사코드, 조직도 버전 정보를 포함한다.

조직도 변경 이후 외부 표시 갱신 흐름은 다음과 같다.

조직도 변경 승인
-> 각 회사 DB 반영
-> Baron SSO 조직도 버전 갱신
-> 인트라넷/모바일 임베드 화면 자동 갱신
-> 필요 시 PNG/SVG/PDF 이미지 재생성

3.7 직원 사진 관리 및 표시 방안

조직도와 SSO 로그인 화면에서 직원 사진을 표시하려면 사진 파일의 원천, 저장 방식, 노출 범위를 별도 정책으로 정의해야 한다.

사진은 개인을 식별할 수 있는 정보이므로 Baron SSO가 각 회사의 원본 사진 저장소를 대체하는 구조는 권장하지 않는다.

검토 가능한 방식은 다음과 같다.

방식	장점	단점
SSO 서버로 사진 파일을 가져와 통일 관리	조직도, 모바일, 인트라넷에서 빠르고 일관되게 표시 가능	SSO가 개인정보성 파일을 보관하므로 보안, 삭제, 접근통제 부담 증가
각 회사가 사진 파일을 보관하고 SSO는 파일명만 관리	원본 사진 관리 책임이 각 회사에 남음	회사별 경로/권한/파일명 규칙 차이로 표시 실패 가능성이 높고, 모바일/외부 임베드 연동이 복잡함
원본은 각 회사가 보관하고 SSO는 표준 썸네일과 메타데이터만 관리	원본 책임은 각 회사에 두면서 SSO 화면에서는 안정적으로 표시 가능	사진 동기화 배치/API와 캐시 무효화 정책이 필요함

권장안은 원본은 각 회사 보관, SSO는 표준 썸네일과 메타데이터 관리 방식이다.

권장 구조는 다음과 같다.

각 회사 인사/사진 저장소
-> 사진 원본 또는 변경 이벤트 제공
-> Baron SSO 사진 동기화
-> 표준 썸네일 생성
-> SSO 보안 저장소에 저장
-> 조직도/로그인/인트라넷 임베드 화면에서 표시

SSO에서 관리할 사진 정보는 다음으로 제한한다.

회사코드
사번 또는 사용자 식별자
사진 파일 식별자
사진 버전
사진 해시값
사진 갱신일
기본 이미지 사용 여부
사진 공개 범위

사진 파일명은 회사 간 중복을 피하기 위해 공통 규칙을 사용한다.

{companyCode}_{employeeNo}_{photoVersion}.jpg

단, 화면이나 API에서는 실제 파일명을 직접 노출하지 않고 SSO의 사진 조회 URL을 사용한다.

https://sso.example.com/photos/users/{userId}
https://sso.example.com/photos/users/{userId}?size=thumbnail

운영 정책은 다음과 같다.

원본 사진은 각 회사 인사 시스템 또는 사진 저장소를 기준으로 한다.
SSO는 조직도 표시용 표준 크기 썸네일만 보관한다.
사진이 없는 직원은 기본 이미지를 표시한다.
퇴사자 또는 접근 제한 대상자의 사진은 정책에 따라 비공개 또는 기본 이미지로 대체한다.
사진 변경 시 사진 버전을 올려 캐시를 무효화한다.
외부 임베드 조직도에서는 권한이 허용된 사용자에게만 사진을 표시한다.
사진 다운로드는 기본 차단하고, 필요한 경우 관리자 권한과 감사 로그를 요구한다.

개인정보 보호 관점에서 사진 원본을 SSO에 장기 보관하는 방식은 피하고, 표시 목적에 필요한 최소 크기와 최소 정보만 관리하는 것이 적절하다.

3.8 조직도 변경 권한 정책 정의

조직도의 변경은 각 회사에서 정해진 인원만 가능해야 한다.

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

권한 역할 예시는 다음과 같다.

전체 관리자
- 전체 자회사 조직도 조회/관리
- 회사별 담당자 지정
- 변경 이력 조회

회사 관리자
- 소속 회사 조직도 조회
- 소속 회사 조직 단위 생성, 수정, 이동 요청
- 소속 회사 직원 소속 조직 이동 요청

승인자
- 조직 변경 요청 승인/반려
- 승인 후 각 회사 DB 반영 승인

조회자
- 조직도 조회만 가능
- 변경 불가

권한 제한 원칙은 다음과 같다.

A회사 담당자는 A회사 조직도만 수정할 수 있다.
B회사 조직도는 B회사 담당자 또는 전체 관리자만 수정할 수 있다.
개인 고유정보는 조직도 화면에서 직접 수정하지 않는다.
조직 귀속 정보만 변경 대상으로 허용한다.
승인 전에는 각 회사 DB에 반영하지 않는다.
모든 변경 전/후 이력과 작업자를 기록한다.

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

초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다.

권장 흐름은 다음과 같다.

각 회사 인사/조직도 DB
-> Baron SSO 조직도 관리 화면
-> 조직 변경 임시 저장
-> 유효성 검증
-> 승인
-> 각 회사 DB의 조직 귀속 정보 반영
-> 반영 결과 기록
-> SSO 권한/접근 정책 갱신

동기화 주기는 다음 기준으로 제안한다.

초기: 1일 1회 배치
안정화 이후: 수시 배치 또는 API 연동
보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영

각 회사 DB에 반영할 수 있는 항목은 다음과 같이 제한한다.

조직단위코드
상위조직코드
조직단위유형
부서코드
팀코드
셀코드
직책코드
소속상태

기존 회사 DB가 부서코드와 팀코드 중심으로 구성되어 있다면 조직단위코드를 회사별 기존 코드 체계에 매핑한다.

각 회사 DB에 반영하지 않는 항목은 다음과 같다.

이름
주민등록번호 등 고유식별정보
연락처
주소
급여 정보
기타 민감 개인정보

회사별 DB 구조가 다를 수 있으므로 회사별 연동 어댑터를 두는 방식을 권장한다.

Baron SSO 조직 변경 요청
-> 공통 변경 모델
-> A회사 DB 반영 어댑터
-> B회사 DB 반영 어댑터
-> C회사 DB 반영 어댑터

이 구조를 사용하면 회사별 DB 테이블 구조가 다르더라도 SSO 쪽에서는 공통 변경 요청 모델을 유지할 수 있다.

다만 각 회사의 인사 DB는 일반적으로 소속부서코드, 소속팀코드처럼 2개 내지 3개의 컬럼으로 조직 소속을 관리하는 경우가 많다.

반면 Baron SSO 조직도는 본부, 부문, 부서, 팀, 셀처럼 더 깊은 계층을 표현할 수 있어야 하므로, SSO의 조직도 계층을 각 회사 DB 컬럼에 그대로 1:1 반영하는 방식은 적절하지 않다.

따라서 회사별 조직 매핑 정책을 별도로 둔다.

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 미존재	불가	사번/이메일이 확인되지 않는 사용자

권장 가입 흐름은 다음과 같다.

회원가입 요청
-> 회사 선택
-> 사번/이메일/휴대폰 등 본인 확인
-> 각 회사 인사 DB 상태 조회
-> 발령상태/재직상태 검증
-> 가입 가능 여부 결정
-> 기본 접근 권한 부여
-> 가입 이력 기록

가입 시 기본 원칙은 다음과 같다.

각 회사 인사 DB에 존재하는 직원만 가입할 수 있다.
발령완료 직원은 정상 가입을 허용한다.
발령대기 또는 입사예정자는 제한 가입 또는 가입 대기 상태로 관리한다.
퇴사자는 신규 가입을 차단한다.
조직단위코드가 없는 사용자는 기본 시스템 접근을 제한한다.
가입 후 부여되는 기본 권한은 회사, 재직상태, 발령상태, 소속 조직 기준으로 결정한다.

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

조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다.

기본 정책 예시는 다음과 같다.

재직자: SSO 로그인 가능
퇴사자: 로그인 즉시 차단
휴직자: 기본 차단 또는 별도 예외 승인
부서 미지정자: 제한 권한 부여
특정 부서: 특정 서비스 접근 허용
관리자 권한: 직책 또는 별도 승인 기준으로 부여

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

관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다.

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

예를 들어 SSO 로그인은 허용하되, 실제 접근 가능한 시스템은 직원 상태와 권한 정책에 따라 다르게 제한할 수 있다.

상태별 정책 예시는 다음과 같다.

직원 상태	SSO 로그인	시스템 A	시스템 B	시스템 C	설명
재직	가능	가능	가능	가능	기본적으로 모든 업무 시스템 접근 가능
휴직	가능 또는 제한	가능	가능	불가	급여/인사 확인 등 일부 시스템만 허용 가능
퇴사 1년 이내	불가 또는 제한	불가	불가	가능	퇴직정산, 증명서 발급 등 특수 시스템만 허용 가능
퇴사 1년 초과	불가	불가	불가	불가	모든 접근 차단
발령대기	가능 또는 대기	가능	불가	불가	온보딩 또는 교육 시스템만 허용 가능

서비스별 접근 제한은 다음 기준을 조합해 판단한다.

회사
재직상태
발령상태
조직단위코드
상위조직코드
조직단위유형
부서코드
팀코드
직책코드
권한 그룹
개별 사용자 예외 권한
접근 허용 기간

권한 판단 흐름은 다음과 같다.

SSO 로그인 요청
-> 사용자 식별
-> 각 회사 인사 DB 또는 SSO 동기화 정보에서 현재 상태 확인
-> SSO 로그인 가능 여부 판단
-> 대상 시스템 접근 정책 조회
-> 상태/회사/소속 조직/권한 그룹/예외 권한 평가
-> 접근 허용 또는 차단
-> 접근 이력 기록

재직자라 하더라도 모든 시스템에 자동 접근시키지 않고, 시스템별 접근 권한을 별도로 관리할 수 있어야 한다.

예를 들어 재직자 중에서도 특정 부서만 회계 시스템에 접근하거나, 특정 직책 이상만 관리자 시스템에 접근하도록 제한할 수 있다.

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

서비스별 접근 정책을 관리할 수 있는 관리자 페이지를 제공한다.

주요 기능은 다음과 같다.

SSO 연동 시스템 목록 관리
시스템별 접근 가능 회사 설정
시스템별 접근 가능 재직상태 설정
시스템별 접근 가능 발령상태 설정
시스템별 접근 가능 조직 단위 설정
시스템별 접근 가능 직책/권한 그룹 설정
사용자별 예외 허용/차단 설정
예외 권한 만료일 설정
접근 정책 변경 전/후 비교
정책 변경 승인/반려
시스템별 접근 가능 사용자 목록 조회
사용자별 접근 가능 시스템 목록 조회

관리자 화면에서는 기본 정책과 예외 정책을 구분해서 보여주는 것이 좋다.

기본 정책은 회사/상태/조직/직책 기준으로 자동 적용하고, 예외 정책은 특정 사용자에게 기간을 정해 수동 부여한다.

3.13 관리자 화면 구성

초기 관리자 화면은 SSO 접근 통제에 필요한 조회와 상태 확인을 기본으로 구성하고, 이후 회사별 조직도 편집 기능을 확장한다.

우선 구현 대상은 다음과 같다.

회사별 조직도 조회
회사별 조직도 변경 요청
직원 목록 조회
부서별 사용자 조회
사용자 상세 정보 확인
재직상태별 필터
발령상태별 필터
SSO 접근 가능/불가 상태 표시
사용자별 접근 가능 시스템 표시
시스템별 접근 가능 사용자 표시
직원 사진 동기화 상태 조회
직원 사진 표시/비공개 상태 관리
권한 그룹 매핑
서비스별 접근 정책 관리
사용자별 예외 접근 권한 관리
회사별 조직도 담당자 지정
조직 변경 승인/반려
각 회사 DB 반영 결과 조회
조직도 동기화 이력 조회
수동 예외 권한 등록

팀장 보고 시에는 단순한 조직도 화면이 아니라 SSO 접근 통제 화면으로 설명하는 것이 적절하다.

3.14 감사 로그와 이력 관리

SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨야 한다.

필수 로그 항목은 다음과 같다.

로그인 성공 이력
로그인 실패 이력
회원가입 요청 이력
회원가입 승인/차단 이력
상태 기준 로그인 차단 이력
서비스별 접근 허용/차단 이력
퇴사자 로그인 시도 이력
조직 정보 변경 이력
권한 변경 이력
서비스별 접근 정책 변경 이력
사용자별 예외 권한 변경 이력
관리자 수동 변경 이력
조직도 변경 요청 이력
조직도 변경 승인/반려 이력
각 회사 DB 반영 요청 이력
각 회사 DB 반영 성공/실패 이력
조직도 링크/임베드 접근 이력
조직도 이미지 내보내기 이력
직원 사진 동기화 이력
직원 사진 조회 이력
직원 사진 비공개/기본 이미지 전환 이력
동기화 성공/실패 이력

감사 로그는 보안 사고 대응, 내부 감사, 권한 변경 원인 추적에 활용할 수 있다.

4. 우선순위

가장 먼저 진행해야 할 작업은 다음 세 가지다.

현재 SSO 사용자 목록 정리
회원가입 가능 상태와 차단 상태 정책 확정
재직상태 기준 로그인 허용/차단 정책 확정
회사별 조직도 원천 데이터 결정
회사별 조직도 변경 담당자와 승인자 지정
각 회사 DB에 반영 가능한 조직 귀속 항목 확정
서비스별 접근 권한 정책 기준 확정
직원 사진 원천과 SSO 표시 방식 확정
회사별 조직도 계층과 DB 컬럼 매핑 정책 확정

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

5. 후속 진행 작업

후속 작업은 다음 순서로 진행하는 것을 제안한다.

현재 SSO 사용자 현황 추출
회사별 조직도 기준 항목 정의
회사별 인사/조직도 원천 시스템 확인
사용자-조직 매핑 테이블 설계
회원가입 가능 상태 정책 정의
로그인 가능 상태 정책 정의
서비스별 접근 권한 정책 정의
회사별 조직도 변경 권한 정책 정의
조직도 변경 승인 절차 정의
각 회사 DB 반영 가능 항목 확정
회사별 조직 계층과 DB 컬럼 매핑 정책 정의
조직도 UI 오픈소스 후보 기술 검토
조직도 링크/임베드/이미지 제공 방식 확정
직원 사진 원천/동기화/표시 정책 확정
퇴사자/휴직자 로그인 차단 정책 적용
서비스별 접근 정책 관리자 화면 추가
관리자 조회 화면 추가
회사별 조직도 관리 화면 추가
조직도 동기화 배치 또는 API 구현
직원 사진 썸네일 동기화 구현
각 회사 DB 반영 어댑터 구현
권한 변경 및 로그인 감사 로그 보강

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

32 KiB Raw Blame History