diff --git a/바론SSO조직도 관련 검토,md b/바론SSO조직도 관련 검토,md
new file mode 100644
index 0000000..ec0423f
--- /dev/null
+++ b/바론SSO조직도 관련 검토,md	
@@ -0,0 +1,180 @@
+# Baron SSO 조직도 관리 개선 제안
+
+## 1. 제안 목적
+
+Baron SSO에 접근하는 사내 직원을 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다.
+
+이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, SSO 접근 권한의 기준 데이터를 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다.
+
+## 2. 기본 방향
+
+- Baron SSO 접근 사용자를 조직도 기준으로 식별한다.
+- 재직상태, 부서, 직책, 권한 그룹을 기준으로 로그인 가능 여부와 서비스 접근 범위를 관리한다.
+- 조직도 원천 데이터는 하나의 기준 시스템에서 가져오는 것을 원칙으로 한다.
+- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화 방식으로 확장한다.
+- 모든 권한 변경과 로그인 이력은 감사 로그로 남긴다.
+
+## 3. 단계별 추진안
+
+### 3.1 현재 사용자 기준 정리
+
+먼저 현재 Baron SSO에 접근 가능한 사용자 목록을 정리한다.
+
+관리 대상 항목은 다음과 같다.
+
+- 사번
+- 이름
+- 이메일
+- 부서
+- 직급
+- 직책
+- 재직상태
+- SSO 권한
+- 최종 로그인일
+
+이 단계에서는 퇴사자, 휴직자, 부서 미지정자, 중복 계정, 공용 계정을 식별한다.
+
+산출물은 `현재 SSO 사용자 현황표`로 관리한다.
+
+### 3.2 조직도 기준 데이터 정의
+
+Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
+
+최소 관리 항목은 다음과 같다.
+
+- 회사
+- 본부
+- 부서
+- 팀
+- 상위부서
+- 부서장
+- 사번
+- 이름
+- 이메일
+- 직급
+- 직책
+- 재직상태
+
+이때 권한 제어에 필요한 항목과 단순 조회용 항목을 분리한다.
+
+예를 들어 `부서`, `직책`, `재직상태`는 권한 판단에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다.
+
+### 3.3 조직도 원천 시스템 결정
+
+조직도와 직원 정보의 원천 시스템을 결정한다.
+
+후보는 다음과 같다.
+
+- 인사 시스템
+- 그룹웨어
+- ERP
+- AD/LDAP
+- 별도 조직도 관리 시스템
+
+핵심 원칙은 조직도 원본을 하나만 두는 것이다.
+
+Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천 시스템의 조직/직원 정보를 받아와 동기화하는 방식이 안정적이다.
+
+원천 시스템 연동이 당장 어렵다면 초기에는 관리자 업로드 방식으로 시작할 수 있다.
+
+### 3.4 조직도 동기화 방식 설계
+
+초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다.
+
+권장 흐름은 다음과 같다.
+
+```text
+인사/조직도 시스템
+-> 직원/부서 정보 동기화
+-> Baron SSO 사용자/조직 테이블 반영
+-> SSO 로그인 시 재직상태와 권한 확인
+```
+
+동기화 주기는 다음 기준으로 제안한다.
+
+- 초기: 1일 1회 배치
+- 안정화 이후: 수시 배치 또는 API 연동
+- 보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영
+
+### 3.5 접근 권한 정책 정의
+
+조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다.
+
+기본 정책 예시는 다음과 같다.
+
+```text
+재직자: SSO 로그인 가능
+퇴사자: 로그인 즉시 차단
+휴직자: 기본 차단 또는 별도 예외 승인
+부서 미지정자: 제한 권한 부여
+특정 부서: 특정 서비스 접근 허용
+관리자 권한: 직책 또는 별도 승인 기준으로 부여
+```
+
+관리자 권한은 부서 정보만으로 자동 부여하지 않는 것이 안전하다.
+
+관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다.
+
+### 3.6 관리자 화면 구성
+
+초기 관리자 화면은 복잡한 조직도 편집 기능보다 SSO 접근 통제에 필요한 조회와 상태 확인 중심으로 구성한다.
+
+우선 구현 대상은 다음과 같다.
+
+- 직원 목록 조회
+- 부서별 사용자 조회
+- 사용자 상세 정보 확인
+- 재직상태별 필터
+- SSO 접근 가능/불가 상태 표시
+- 권한 그룹 매핑
+- 조직도 동기화 이력 조회
+- 수동 예외 권한 등록
+
+팀장 보고 시에는 단순한 `조직도 화면`이 아니라 `SSO 접근 통제 화면`으로 설명하는 것이 적절하다.
+
+### 3.7 감사 로그와 이력 관리
+
+SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨야 한다.
+
+필수 로그 항목은 다음과 같다.
+
+- 로그인 성공 이력
+- 로그인 실패 이력
+- 퇴사자 로그인 시도 이력
+- 조직 정보 변경 이력
+- 권한 변경 이력
+- 관리자 수동 변경 이력
+- 동기화 성공/실패 이력
+
+감사 로그는 보안 사고 대응, 내부 감사, 권한 변경 원인 추적에 활용할 수 있다.
+
+## 4. 우선순위
+
+가장 먼저 진행해야 할 작업은 다음 세 가지다.
+
+1. 현재 SSO 사용자 목록 정리
+2. 재직상태 기준 로그인 허용/차단 정책 확정
+3. 조직도 원천 데이터 결정
+
+이 세 가지가 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리 작업을 순차적으로 진행할 수 있다.
+
+## 5. 후속 진행 작업
+
+후속 작업은 다음 순서로 진행하는 것을 제안한다.
+
+1. 현재 SSO 사용자 현황 추출
+2. 조직도 기준 항목 정의
+3. 인사/조직도 원천 시스템 확인
+4. 사용자-조직 매핑 테이블 설계
+5. 퇴사자/휴직자 로그인 차단 정책 적용
+6. 관리자 조회 화면 추가
+7. 조직도 동기화 배치 또는 API 구현
+8. 권한 변경 및 로그인 감사 로그 보강
+
+## 6. 기대 효과
+
+- 퇴사자 또는 휴직자의 SSO 접근을 빠르게 차단할 수 있다.
+- 부서 이동이나 조직 변경에 따른 권한 정리를 체계화할 수 있다.
+- 관리자 권한 부여 기준을 명확히 할 수 있다.
+- SSO 접근 이력과 권한 변경 이력을 감사 관점에서 추적할 수 있다.
+- 향후 자동 권한 관리와 서비스별 접근 제어로 확장할 수 있다.