diff --git a/notes/johngreen/2026-05-08-부서관리-버그-정리.md b/notes/johngreen/2026-05-08-부서관리-버그-정리.md
new file mode 100644
index 00000000..1da98640
--- /dev/null
+++ b/notes/johngreen/2026-05-08-부서관리-버그-정리.md
@@ -0,0 +1,365 @@
+# 부서관리 페이지 버그 정리 — 시나리오 중심
+
+작성일: 2026-05-08
+목적: 사용자/개발자가 "어떤 일이 벌어지는지" 바로 이해할 수 있게 정리
+
+---
+
+## 🔴 진짜 위험한 것 — 즉시 수정
+
+### 1. 다른 회사 사용자 정보가 그냥 보입니다 🚨
+
+**어디서**: `DepartmentController.java:234` `searchUsers`
+
+**무슨 일이 벌어지나**:
+- 부서원 추가 시 사용자 검색 API 가 있음
+- 그런데 이 API 는 "당신이 어느 회사 사람인지" 검사를 안 함
+- 즉, A 회사 직원이 URL 에 B 회사 코드만 박으면 → B 회사 직원 명단을 그대로 받아옴
+
+**왜 심각한가**:
+- 멀티테넌시 (회사간 격리) 의 핵심 원칙이 깨짐
+- 다른 모든 부서 API 는 회사 격리 검사를 하는데 이거 하나만 빠짐
+- 또한 일반 USER 도 admin 검사 없이 호출 가능
+
+**고치는 법**:
+- 컨트롤러에 `if (!isSuperAdmin(...) && !userCompanyCode.equals(companyCode)) return 403;` 추가
+- admin role 체크도 추가
+
+---
+
+### 2. 사용자의 "주 부서" 가 통째로 사라질 수 있습니다 🚨
+
+**어디서**: `DepartmentService.java:356-370` `setPrimaryDept`
+
+**무슨 일이 벌어지나**:
+1. 김철수 씨가 영업부 소속 (영업부 = 주 부서)
+2. 누군가 "김철수를 마케팅부의 주 부서로 설정" API 를 호출 (그런데 김철수는 마케팅부 소속이 아님)
+3. 코드는 "일단 김철수의 모든 주 부서 표시 해제" 부터 실행 → 영업부 주 부서 표시 사라짐
+4. 그 다음 "마케팅부를 주 부서로 설정" 시도 → 김철수가 마케팅부 소속이 아니므로 0 row 변경 (조용히 실패)
+5. 결과: 김철수는 어디에도 주 부서가 없는 사용자가 됨
+
+**왜 심각한가**:
+- 데이터 무결성 (모든 사용자는 주 부서 1개) 이 깨진 채 commit
+- 에러도 안 남
+- 결재 흐름 등에서 주 부서 기준 로직이 망가짐
+
+**고치는 법**:
+- API 진입 시 `selectExistingMember(userId, deptCode)` 로 멤버십 검증
+- 멤버 아니면 400 반환
+- `setUserPrimaryDept` 가 0 row affected 면 예외 던져서 트랜잭션 롤백
+
+---
+
+### 3. 다른 회사의 부서를 부모로 지정할 수 있습니다 🚨
+
+**어디서**: `DepartmentService.java:107` (생성), `:251` `verifyParentCycle` (수정)
+
+**무슨 일이 벌어지나**:
+- 부서 생성/수정 시 `parent_dept_code` 를 받음
+- 이 코드가 (a) 실제 존재하는지, (b) 같은 회사인지, (c) 삭제된 건 아닌지 **전혀 검사 안 함**
+- 사이클 검사 (`verifyParentCycle`) 는 있지만 "부모가 같은 회사인지" 검증은 빠져있음
+
+**왜 심각한가**:
+- SUPER_ADMIN 또는 컨트롤러 우회 경로로 다른 회사 부서를 부모로 지정 가능
+- 회사간 데이터가 트리로 엮여 멀티테넌시 침해
+
+**고치는 법**:
+- create/update 양쪽에서 parent 부서 조회 → company_code 일치 검증 + deleted_at IS NULL 검증
+
+---
+
+## 🟠 사용자가 자주 마주칠 버그
+
+### 4. 회사를 바꿔도 우측 상세 패널에 이전 회사 부서가 그대로 남습니다
+
+**어디서**: `page.tsx:658` 회사 Select 의 `onValueChange`
+
+**시나리오**:
+1. 회사 A 의 "영업부" 클릭 → 우측에 영업부 정보
+2. 좌측 상단에서 회사 B 로 변경
+3. 좌측 트리는 회사 B 부서로 갱신됨
+4. **그런데 우측 상세 패널은 여전히 영업부 (회사 A) 정보 표시**
+5. 사용자가 모르고 저장 버튼 누르면 회사 코드 mismatch 로 이상한 일이 벌어짐
+
+**고치는 법**:
+- 회사 변경 시 `handleClearDetail()` 호출하여 상세 패널 초기화
+
+---
+
+### 5. 부서 정렬 변경 (한 칸 위/아래) 이 부분 실패할 수 있습니다
+
+**어디서**: `page.tsx:403` `handleMove`
+
+**시나리오**:
+1. 형제 부서 5개 정렬 변경 시 코드는 5번의 PUT 요청을 동시에 보냄 (`Promise.all`)
+2. 그 중 1개가 실패하면 → 4개는 이미 DB 에 반영됨
+3. 코드는 toast 만 띄우고 화면 새로고침은 **안 함** (catch 블록에 `loadDepartments()` 없음)
+4. 화면은 이전 정렬, DB 는 부분 업데이트된 상태로 영구 불일치
+
+**고치는 법**:
+- catch 블록에서도 `loadDepartments()` 호출하여 DB 상태로 동기화
+- 더 좋은 방법: 백엔드에 "정렬 일괄 업데이트" API 만들어 트랜잭션 보장
+
+---
+
+### 6. 검색하면 트리가 망가집니다
+
+**어디서**: `page.tsx:231-246` `filteredDepts` + `childrenOf`
+
+**시나리오**:
+- "인사" 검색 → "인사팀" 부서가 매칭됨
+- 그런데 인사팀의 부모인 "경영지원본부" 는 매칭 안 됨
+- `childrenOf(null)` 은 매칭된 루트만 보여주는데 인사팀의 부모가 없으니 트리에 안 나타남
+- **결과: 검색 결과가 있어도 트리에 아무것도 안 보일 수 있음**
+
+**고치는 법**:
+- 매칭된 노드의 부모 체인을 자동으로 결과에 포함
+- 또는 검색 모드에서는 트리가 아닌 평면 리스트로 표시
+
+---
+
+### 7. `update` 가 삭제된 부서도 변경합니다 (silent corruption)
+
+**어디서**: `department.xml:160-179` `updateDepartment`
+
+**무슨 일이 벌어지나**:
+1. 사용자가 휴지통의 "옛 부서" 를 수정하려 시도
+2. 컨트롤러는 `getDepartmentIncludingDeleted` 로 검증 후 service 호출
+3. SQL UPDATE 는 `WHERE DEPT_CODE = ?` 만 있어 삭제 여부 무관하게 update 실행
+4. service 가 다음 줄에서 `selectDepartmentByCode` (DELETED_AT IS NULL) 로 재조회 → null
+5. controller 가 404 반환
+
+**결과**: 사용자는 "404 부서를 찾을 수 없음" 메시지를 보지만 **DB 는 이미 update 된 상태**. 데이터 손상.
+
+**고치는 법**:
+- SQL UPDATE WHERE 절에 `AND DELETED_AT IS NULL` 추가
+- 0 row 면 service 가 null 반환 → 404 일관됨
+
+---
+
+### 8. 부서명을 바꿀 때 중복 검사를 안 합니다
+
+**어디서**: `DepartmentService.java:131-170` `updateDepartment`
+
+**시나리오**:
+- 새 부서 생성 시에는 "이미 같은 이름 있어요" 체크함
+- 그런데 **부서명 수정 시에는 체크 없음**
+- 결과: 기존 "영업1팀" 을 "영업팀" 으로 수정 → 이미 있는 "영업팀" 과 동일 이름 두 부서 공존 가능
+
+**같은 문제 — 복구 시에도**: `restoreDepartment` 에서도 동일. 삭제했던 부서를 살릴 때 같은 이름의 active 부서가 있어도 충돌 검사 없음.
+
+**고치는 법**:
+- update/restore 양쪽에 `selectDuplicateDeptName` 호출 추가
+- 더 좋은 방법: DB 에 partial UNIQUE 인덱스 (`(company_code, lower(trim(dept_name))) WHERE deleted_at IS NULL`) 추가
+
+---
+
+### 9. 일반 회사 관리자가 글로벌 부서를 삭제할 수 있습니다
+
+**어디서**: `DepartmentController.java:135` `deleteDepartment`
+
+**시나리오**:
+- 시스템 공통 부서 (company_code='*') 가 있음 (예: 시스템 관리자, 공통 부서 등)
+- 어느 회사 admin 이든 이 글로벌 부서의 dept_code 를 알면 DELETE 호출 가능
+- 코드의 권한 검사: `isAdmin(role)` 통과 + `canAccessDept` (글로벌이라 통과) → 삭제 진행
+
+**고치는 법**:
+- 글로벌 부서 (`company_code = '*'`) 의 write 작업은 `isSuperAdmin` 만 허용
+
+---
+
+### 10. 사용자가 입력한 부서코드가 조용히 무시됩니다 -> 사용자가 부서코드를 입력하게 하지말고 시스템이 동적으로 생성할수있게변경 입력값은 받지않게 수정
+
+**어디서**: `DepartmentService.java:85-99` `createDepartment`
+
+**시나리오**:
+1. 사용자가 부서코드란에 "SALES-A" 입력 (대시 포함)
+2. 백엔드 정규식은 `^[A-Za-z0-9_]+$` 만 허용 → 불일치
+3. 코드는 예외를 던지지 않고 자동으로 `DEPT_47` 같은 코드 생성
+4. 응답은 201 성공, 하지만 `dept_code` 가 `DEPT_47` (사용자가 입력한 값과 다름)
+5. 사용자는 "SALES-A" 로 만들어졌다고 착각
+
+**고치는 법**:
+- 정규식 불일치 시 400 + "부서 코드는 영문/숫자/언더스코어만 가능합니다" 메시지
+
+---
+
+### 11. 새 부서의 "시작일" 이 항상 오늘로 강제 저장됩니다
+
+**어디서**: `page.tsx:113` `emptyDraft`, `page.tsx:957` 일괄등록
+
+**시나리오**:
+- UI 에 시작일/종료일 입력란은 V2 로 미뤄져 hidden 처리됨 (`{false && ...}`)
+- 그런데 `emptyDraft` 는 `start_date: new Date().toISOString().slice(0,10)` 으로 항상 today 입력
+- 결과: 사용자는 시작일 입력란을 본 적도 없는데 모든 신규 부서에 today 가 강제 저장됨
+- 일괄등록도 동일 — 100개 import 하면 100개 모두 import 한 날짜가 시작일
+
+**고치는 법**:
+- `emptyDraft` 의 `start_date` 기본값을 빈 문자열로 변경
+- 또는 컬럼이 hidden 인 상태에서는 payload 에 포함하지 않음
+
+---
+
+## 🟡 알아두면 좋은 문제
+
+### 12. 부서원 목록이 다른 부서 것으로 잠깐 보일 수 있습니다
+
+**어디서**: `page.tsx:219-228` 멤버 fetch useEffect
+
+**상황**: 네트워크 느린 환경에서 부서 A 클릭 → 멤버 로딩 중 → 부서 B 클릭 → A 의 응답이 늦게 도착하여 B 의 패널에 A 의 멤버 표시. fetch 취소 로직 (AbortController) 없음.
+
+**고치는 법**: useEffect 에 cancellation flag 추가
+
+---
+
+### 13. 삭제 다이얼로그를 열어둔 채 다른 부서를 선택하면 잘못된 부서가 삭제됩니다
+
+**어디서**: `page.tsx:503` `handleDelete`
+
+**상황**:
+1. 영업부 선택 → 메인 패널의 "삭제" 버튼 클릭 → 다이얼로그 열림
+2. 다이얼로그 뒤로 트리에서 다른 부서 (예: 인사부) 클릭 → `selectedCode` = 인사부
+3. 다이얼로그의 "삭제" 확정 → 코드는 최신 `selectedCode` 사용 → **인사부가 삭제됨**
+
+shadcn Dialog 는 보통 포커스 트랩이 있지만 dismiss 가능한 설정이면 위험.
+
+**고치는 법**: 다이얼로그 열 때 dept_code 를 캡처해서 클로저로 전달
+
+---
+
+### 14. X 버튼 누르면 미저장 변경이 경고 없이 사라집니다
+
+**어디서**: `page.tsx:299` `handleClearDetail`
+
+**상황**: 부서 정보 수정 중 우측 상단 X 버튼 클릭 → 즉시 폼 초기화. `isDirty` 상태는 계산되지만 사용 안 함.
+
+**고치는 법**: `if (isDirty && !confirm("변경사항이 있습니다. 폐기하시겠습니까?")) return;`
+
+---
+
+### 15. 변경이력 기능이 화면만 있고 실제로는 동작 안 합니다
+
+**어디서**: `page.tsx:997-1027`
+
+**상황**: "변경이력" 버튼 클릭 → 다이얼로그 열림 → 항상 "데이터를 불러오는 중이거나, 등록된 이력이 없습니다." 표시. 실제 API 호출 코드 없음.
+
+**고치는 법**: 백엔드 audit log API 와 연동. 기능 미구현 명시.
+
+---
+
+### 16. 부서원 추가/제거 UI 가 없습니다
+
+**어디서**: `page.tsx:1469` `MembersPanel`
+
+**상황**:
+- 부서원 정보 탭에서 멤버 목록만 표시
+- 추가/제거 버튼 없음
+- 백엔드 API (`addDepartmentMember`, `removeDepartmentMember`, `searchUsers`) 는 존재하지만 UI 미연결
+
+**고치는 법**: 멤버 추가 모달 + 행별 제거 버튼 구현
+
+---
+
+### 17. 일괄등록 실패 사유가 안 보입니다
+
+**어디서**: `page.tsx:957-985`
+
+**상황**: 100개 import → "성공 95건 / 실패 5건" 토스트만. 어떤 부서코드가 왜 실패했는지 알 수 없어 재시도 불가.
+
+**고치는 법**: 실패 항목을 모달이나 다운로드 가능한 결과 화면으로 표시
+
+---
+
+## 🟢 사소한 문제 (정리/보강)
+
+### 18. 동시에 부서 생성하면 실패할 수 있음
+
+**어디서**: `DepartmentService.java:96` `selectNextDeptNumber`
+
+`MAX(번호) + 1` 이 비원자적이라 두 사람이 동시에 부서 생성 시 같은 번호 → 두 번째 INSERT 가 PK 위반으로 5xx 에러. catch 로 잡지도 않아 사용자에게 raw 500 노출.
+
+### 19. 부서 코드/이름의 앞뒤 공백이 그대로 저장됨
+
+**어디서**: `DepartmentService.java:107`+ `nullIfBlank`
+
+`nullIfBlank` 는 "완전히 빈 문자열만 null 로" 처리. ` " DEPT_3 "` 같은 공백 포함 코드는 그대로 저장됨. → `nullIfBlank` 자체를 trim+blank→null 한 번에 처리하도록 수정.
+
+### 20. 검색 후 "전체 펼치기" 누르면 검색 해제 시 부분 펼침 상태로 남음
+
+**어디서**: `page.tsx:249` `expandAll`
+
+`filteredDepts` 만 펼치므로 검색 결과만 expanded. 검색 해제 후 트리가 일부만 펼쳐진 상태로 보임.
+
+### 21. 컨트롤러에 dead code 있음
+
+**어디서**: `DepartmentController.java:271-272`
+
+```java
+Object userIdObj = body.get("user_id");
+if (userIdObj == null) userIdObj = body.get("user_id"); // 같은 키 두 번
+```
+
+camelCase fallback 의도였는데 오타로 같은 snake_case. → `body.get("userId")` 로 수정.
+
+### 22. Picker 에 "최상위로 이동" 옵션이 UI 에 없음
+
+**어디서**: `page.tsx:920` `DepartmentPicker.onSelect`
+
+`handleConfirmMoveTo(null)` 코드 경로는 있지만 picker UI 에서 "부모 없음 (최상위)" 선택지가 없어 트리거 불가.
+
+### 23. SQL 의 LIKE 와일드카드 미이스케이프
+
+**어디서**: `DepartmentService.java:283` `searchUsers`
+
+`%` + 사용자입력 + `%`. 사용자가 `_` 만 입력하면 모든 사용자 매칭. 데이터 누출은 아니지만 enumeration 가능.
+
+### 24. dead SQL 쿼리 잔존
+
+**어디서**: `department.xml:192-195` `deleteUserDeptByDeptCode`
+
+주석에 "Slice 2.1 이후 사용 안 함" 명시되어 있지만 쿼리 그대로 남아있음.
+
+### 25. 부서원 목록 INNER JOIN
+
+**어디서**: `department.xml:213` `selectDeptMembers`
+
+USER_INFO 에서 사용자가 삭제되면 USER_DEPT row 가 남아있어도 멤버에 안 나타남. `member_count` 와 실제 표시되는 멤버 수가 불일치 가능.
+
+---
+
+## 📋 수정 권장 순서
+
+### Phase 1 — 보안/데이터 손상 (최우선)
+- #1 searchUsers 회사/role 가드
+- #2 setPrimaryDept 멤버십 검증
+- #3 parent_dept_code 회사 격리 검증
+- #9 글로벌 부서 write 권한 강화
+
+### Phase 2 — 데이터 무결성
+- #7 update SQL 의 DELETED_AT 누락 수정
+- #8 update/restore 부서명 중복 검증
+- #4 회사 변경 시 상세 패널 초기화
+- #5 handleMove 실패 처리
+
+### Phase 3 — 사용자 경험
+- #6 검색 트리 broken 수정
+- #10 dept_code silent fallback 제거
+- #11 start_date 강제 저장 제거
+- #12 ~ #14 race/실수 방지
+
+### Phase 4 — 기능 완성
+- #15 변경이력 API 연동
+- #16 부서원 추가/제거 UI
+- #17 일괄등록 실패 상세
+
+### Phase 5 — 정리
+- #18 ~ #25 race/공백/dead code/검색 정밀화
+
+---
+
+## 도메인별 상세 리포트
+
+- 프론트엔드 React: `2026-05-08-부서관리-버그헌팅-frontend.md`
+- 백엔드 Java: `2026-05-08-부서관리-버그헌팅-backend.md`
+- SQL/Mapper: `2026-05-08-부서관리-버그헌팅-sql.md`
+- UX 시나리오: `2026-05-08-부서관리-버그헌팅-ux.md`
diff --git a/notes/johngreen/2026-05-08-부서관리-버그헌팅-backend.md b/notes/johngreen/2026-05-08-부서관리-버그헌팅-backend.md
new file mode 100644
index 00000000..3ca845c0
--- /dev/null
+++ b/notes/johngreen/2026-05-08-부서관리-버그헌팅-backend.md
@@ -0,0 +1,134 @@
+# 부서관리 백엔드 버그 헌팅 (2026-05-08)
+
+대상:
+- `backend-spring/src/main/java/com/erp/controller/DepartmentController.java`
+- `backend-spring/src/main/java/com/erp/service/DepartmentService.java`
+- `backend-spring/src/main/resources/mapper/department.xml` (참고)
+
+---
+
+## 1. createDepartment dept_code silent fallback ❌ HIGH
+
+`DepartmentService.java:85-99` — 사용자가 명시한 `dept_code` 가 정규식 `^[A-Za-z0-9_]+$` 위반 시 예외 없이 자동 코드 생성으로 폴백. 사용자는 201 응답을 받지만 응답의 `dept_code` 가 요청과 다름 (silent override). `IllegalArgumentException("부서 코드 형식이 올바르지 않습니다")` 던지는 게 맞음.
+
+## 2. createDepartment parent_dept_code 검증 누락 ❌ CRITICAL — cross-tenant
+
+`DepartmentService.java:107`, `DepartmentController.java:80-82` — parent 가 (a) 존재, (b) 같은 회사, (c) deleted 아님 검증 전혀 없음. SUPER_ADMIN 또는 controller 우회 경로로 cross-tenant 부모 지정 가능. FK 가 같은 DB 내 다른 회사 부서를 참조 가능.
+
+## 3. updateDepartment 부서명 중복 검증 누락 ❌ HIGH
+
+`DepartmentService.java:131-170` — create 는 `selectDuplicateDeptName` 체크하지만 update 에는 없음. UNIQUE 제약도 mapper 에 없음. 회사 내 동일 이름의 active 부서 두 개 공존 가능.
+
+## 4. verifyParentCycle 회사 격리 미검증 ❌ HIGH
+
+`DepartmentService.java:251-271` — cycle 만 체크. newParent.company_code 와 deptCode.company_code 비교 없음. update 흐름에서 #2 와 동일 결함 재현.
+
+## 5. selectNextDeptNumber race condition ❌ MEDIUM
+
+`DepartmentService.java:96-99`, `department.xml:108-111` — `MAX(...)+1` 비원자적. 두 요청 동시 진입 시 같은 `next_number` 읽음 → 두 번째 INSERT PK 위반으로 500. 컨트롤러 catch 절은 `DuplicateDeptNameException`/`IllegalArgumentException` 만 잡으므로 raw `DataIntegrityViolationException` 누출.
+
+## 6. delete-restore trap (활성 자식만 체크) ⚠️ MEDIUM
+
+`DepartmentService.java:181-202` (`include_deleted=false` 로 자식 카운트) — 활성 자식 0이면 부모 soft-delete OK. 자식 단독 복구 시도 시 `restoreDepartment` 가 부모 deleted 검사로 차단(`PARENT_DELETED`) → 부모 먼저 복구 필요. 영구 trap 은 아니지만 UX 혼선.
+
+## 7. restoreDepartment 부서명 충돌 미검증 ❌ HIGH
+
+`DepartmentService.java:210-239` — 시나리오: A 부서 삭제 → 같은 이름 B 부서 생성 (create 는 active 만 검사하므로 통과) → A 부서 복구 → 동일 이름 active 두 부서 공존. 100% 재현 가능.
+
+## 8. restoreDepartment 부모 1단계 검증 ✅
+
+`DepartmentService.java:220-228` — 시스템 invariant 상 부모 active 면 조부모도 active 보장됨 → 1단계로 충분. 외부 직접 SQL 조작 시나리오는 막지 못하지만 OK.
+
+## 9. addDeptMember dead code ❌ LOW
+
+`DepartmentController.java:271-272`:
+```java
+Object userIdObj = body.get("user_id");
+if (userIdObj == null) userIdObj = body.get("user_id"); // 동일 키
+```
+camelCase fallback 의도였던 것이 작성 실수로 같은 snake_case 가 됨. → `body.get("userId")` 로 수정.
+
+## 10. setPrimaryDept 멤버십 미검증 → DATA CORRUPTION ❌ CRITICAL
+
+`DepartmentService.java:356-370` — 시나리오:
+1. 사용자가 deptA 소속 (IS_PRIMARY=TRUE)
+2. 클라이언트가 사용자가 소속되지 않은 deptB 로 PUT 호출
+3. `clearUserPrimaryDept` → 사용자의 모든 USER_DEPT 행 IS_PRIMARY=FALSE (deptA primary 제거)
+4. `setUserPrimaryDept` (WHERE USER_ID=? AND DEPT_CODE=deptB) → 0 rows affected
+5. 결과: 어떤 부서도 primary 가 아닌 상태로 남음 (invariant 깨짐)
+
+Service 진입 시 `selectExistingMember` 선검증 + 0 row affected 시 예외/롤백 필수.
+
+## 11. canAccessDept — 글로벌 부서(`*`) read 허용 ⚠️ MEDIUM
+
+`DepartmentController.java:361-367` — `userCompanyCode.equals(deptCompanyCode) || "*".equals(deptCompanyCode)`. 일반 USER 도 글로벌 부서 GET 가능 (의도된 듯). 단 read/write 분리 필요.
+
+## 12. deleteDepartment — COMPANY_ADMIN 의 글로벌 부서 삭제 ❌ HIGH
+
+`DepartmentController.java:135-165` — 임의 테넌트 COMPANY_ADMIN 이 글로벌 부서 (`'*'`) 를 DELETE 호출 → `isAdmin(role)` 통과 + `canAccessDept` 통과 (글로벌 매칭) → 삭제 진행. 글로벌 자원 write 는 SUPER_ADMIN 전용 가드 필요.
+
+## 13. trimString 일관성 ❌ MEDIUM
+
+`DepartmentService.java:62, 85, 133` — `trimString` 은 dept_name, requestedCode 에만 적용. parent_dept_code, dept_type, short_name, address1/2, zipcode 등은 `nullIfBlank` 만 거치는데 이건 빈 문자열만 null 로 바꿈 — 선행/후행 공백 보존됨. `parent_dept_code=" DEPT_3 "` 입력 시 DB 에 공백 포함 코드 저장. → `nullIfBlank` 자체를 trim+blank→null 한 번에 처리하도록 수정.
+
+## 14. removeDeptMember 트랜잭션 race ⚠️ LOW
+
+`DepartmentService.java:324-354` — 메서드 전체 `@Transactional` 이라 데이터 일관성 OK. 단 `selectFirstUserDept` 후 다른 트랜잭션이 그 row 도 삭제하는 race 시 `setUserPrimaryDept` 0 row affected, 예외 없음 → primary 부재 commit. 권장: row count 0 이면 재조회 또는 단일 SQL `UPDATE ... WHERE USER_ID=? AND DEPT_CODE=(SELECT ...)` 합치기.
+
+## 15. SUPER_ADMIN 식별 — `company_code = '*'` 의미 충돌 ⚠️ MEDIUM
+
+`DepartmentController.java:353-355` — `isSuperAdmin(companyCodeOrRole)` 가 `*` 또는 `SUPER_ADMIN` 둘 다 true. 일반 user 의 `company_code` 가 우연히 `*` 로 저장되면 super 권한 부여. provisioning 레이어에서 `company_code='*'` 차단 필수. 권장: role 만으로 super 판별, company_code 와 분리.
+
+---
+
+## 추가 발견
+
+### A. createDepartment 중복명 race ❌ HIGH
+`selectDuplicateDeptName` → INSERT 사이 동시 요청 race. DB UNIQUE 제약 없으면 중복 이름 공존 가능. (`department.xml` 에서 unique 제약 없음.)
+
+### B. searchUsers SQL LIKE wildcard ⚠️ MEDIUM
+`DepartmentService.java:283-288` — `params.put("search", "%" + search + "%")`. 사용자 입력의 `%`/`_` 가 와일드카드. `_` 단독 검색 시 모든 사용자 매칭. 데이터 누출은 아니나 enumeration 가능.
+
+### C. searchUsers 컨트롤러 권한 검증 누락 ❌ CRITICAL — TENANT BREACH
+`DepartmentController.java:234-245` — `userCompanyCode` 가드 **없음**. 임의 사용자가 다른 회사 코드를 path 에 넣으면 그 회사 사용자 목록 검색 가능. 다른 모든 메서드엔 가드 있는데 여기만 누락.
+
+### D. searchUsers role 검증 누락 ❌ MEDIUM
+admin 검사 없음. 일반 USER 가 회사 내 모든 사용자 (이름/아이디) 자유 검색 → 사용자 enumeration.
+
+### E. getDeptMembers — soft-deleted 부서 멤버 노출 ⚠️ LOW/MEDIUM
+`getDepartmentIncludingDeleted` 로 검증만 하고 deleted 부서 members 그대로 반환. 의도된 사양인지 확인 필요.
+
+### F. ClassCastException 위험 ⚠️ LOW
+`DepartmentService.java:81` — `(String) company.get("company_name")`. 컬럼 타입 변경 시 CCE. `Objects.toString(...)` 권장.
+
+### G. setPrimaryDept 비원자성 ⚠️ LOW
+`DepartmentService.java:356-370` — clear + set 두 SQL. 단일 UPDATE 합치기 가능: `UPDATE USER_DEPT SET IS_PRIMARY = (DEPT_CODE = #{dept_code}) WHERE USER_ID = #{user_id}`.
+
+### H. nextNumber unboxing NPE ⚠️ LOW
+`DepartmentService.java:97` — `((Number) codeResult.get("next_number")).longValue()`. 항상 non-null 보장이지만 NPE 가드 권장.
+
+### I. 로그 PII 평문 ⚠️ LOW
+`DepartmentService.java:124, 200, 237, 321, 348, 352, 369` — userId 평문 로깅. PIPA/GDPR 환경 고려.
+
+### J. selectNextDeptNumber 회사 격리 ✅
+DB-per-tenant 아키텍처상 OK. 글로벌 `*` 회사도 같은 시퀀스 공유.
+
+---
+
+## 우선순위 정리
+
+| 등급 | 항목 |
+|---|---|
+| **CRITICAL** | #2 parent cross-tenant 무검증 / #10 setPrimaryDept data corruption / **C** searchUsers tenant breach |
+| **HIGH** | #1 dept_code silent fallback / #3 update 중복명 / #4 verifyParentCycle 회사 / #7 restore 중복명 / #12 글로벌 삭제 / **A** create race / **D** searchUsers role |
+| **MEDIUM** | #5 nextNumber race / #6 delete-restore trap / #11 글로벌 write 정책 / #13 trim 일관성 / #15 `*` 의미 / **B** LIKE wildcard / **E** deleted member 노출 |
+| **LOW** | #9 dead code / #14 removeMember race / **F-I** |
+
+## 즉시 수정 권장
+
+1. `searchUsers` 컨트롤러 권한/회사 가드 추가
+2. `setPrimaryDept` 선검증 + 0 rows 시 예외
+3. `create/updateDepartment` parent 회사 격리·존재·미삭제 검증
+4. `update/restoreDepartment` 에 `selectDuplicateDeptName` 추가
+5. 글로벌 부서 (`*`) write 작업 SUPER_ADMIN 전용 가드
+6. `dept_code` 형식 위반 시 silent fallback 대신 400
diff --git a/notes/johngreen/2026-05-08-부서관리-버그헌팅-frontend.md b/notes/johngreen/2026-05-08-부서관리-버그헌팅-frontend.md
new file mode 100644
index 00000000..de6ac22e
--- /dev/null
+++ b/notes/johngreen/2026-05-08-부서관리-버그헌팅-frontend.md
@@ -0,0 +1,328 @@
+# 부서관리 페이지 프론트엔드 버그 헌팅 리포트
+
+**대상**: `frontend/app/(main)/admin/userMng/deptMngList/page.tsx` (1504줄)
+**분석일**: 2026-05-08
+**분석자**: Debugger (oh-my-claudecode)
+
+---
+
+## 가설별 판정
+
+---
+
+### 1. State 동기화 / race condition — ⚠️ 잠재 위험
+
+**판정**: ⚠️ 잠재 위험 (rapid 클릭 시 stale 덮어쓰기)
+
+`loadDepartments` (line 199)는 `useCallback`으로 메모이즈되어 있지만, 연속 호출 시 race condition 방지 로직이 없다. 예를 들어 사용자가 회사 셀렉트를 빠르게 두 번 변경하면:
+
+- 호출 A (회사1) → 호출 B (회사2) 순으로 시작
+- B가 먼저 응답 → `setDepartments(회사2 데이터)`
+- A가 나중에 응답 → `setDepartments(회사1 데이터)` 로 덮어씀
+
+```
+page.tsx:199-212 — loadDepartments: AbortController / 취소 플래그 없음
+page.tsx:214-216 — useEffect([loadDepartments]) 가 즉시 재실행됨
+```
+
+현실적으로 API 응답 속도가 유사하면 발생 가능성은 낮지만, 느린 네트워크에서 재현 가능.
+
+---
+
+### 2. Dirty tracking — ⚠️ 잠재 위험
+
+**판정**: ⚠️ 잠재 위험 (false dirty 발생 조건 존재)
+
+`isDirty` (line 553-555)는 `JSON.stringify` 순서 의존성 문제보다, **타입 변환** 문제가 더 현실적이다.
+
+```
+page.tsx:553-555
+const isDirty = originalDraft
+ ? JSON.stringify(originalDraft) !== JSON.stringify(draft)
+ : isNewMode && ...
+```
+
+**구체적 시나리오**: `sort_order` 는 `number` 타입인데, `BasicInfoForm`의 `` 에서 `Number(e.target.value) || 0` 로 변환한다 (line 1398). 그런데 백엔드가 `sort_order: "10"` (string)으로 내려주면 `originalDraft.sort_order`가 string, `draft.sort_order`가 number가 되어 stringify 비교 시 `"10" !== 10` → **값이 동일해도 isDirty=true**.
+
+또한 `JSON.stringify`는 객체 키 삽입 순서에 따라 직렬화하므로, 두 객체의 키 순서가 다르면 내용이 같아도 불일치가 발생할 수 있다. `emptyDraft` 스프레드 후 override하는 패턴(line 267-288)에서 키 순서는 보통 일정하지만, 런타임에서 `(dept as any)` 캐스팅을 통해 추가 키가 혼입되면 오탐 가능.
+
+---
+
+### 3. Draft 데이터 손실 — ✅ 진짜 버그
+
+**판정**: ✅ 진짜 버그 (경고 없이 draft 폐기됨)
+
+다음 세 가지 시나리오 모두에서 `isDirty` 체크 없이 즉시 draft를 덮어쓴다.
+
+**시나리오 A — 트리 노드 클릭**
+`handleSelectDepartment` (line 263)는 `isDirty` 체크 없이 곧바로 `setDraft(loaded)` / `setOriginalDraft(loaded)` 실행. 사용자가 신규 부서명을 절반쯤 입력하다 트리의 다른 노드를 클릭하면 입력 내용이 경고 없이 사라진다.
+
+**시나리오 B — 회사 셀렉트 변경**
+`selectedCompanyCode` 변경 시 `loadDepartments`만 재호출되고 (line 214-216), `setDraft`/`setOriginalDraft`/`setSelectedCode`/`setIsNewMode` 초기화 로직이 없다 (가설 9와 연동). 작성 중인 신규 draft가 다른 회사로 전환 후에도 우측 패널에 그대로 남아있다가 저장하면 **잘못된 회사에 저장** 되는 위험까지 존재.
+
+**시나리오 C — 검색 입력**
+검색은 `filteredDepts` 필터링만 하므로 draft 자체는 건드리지 않는다. 이 시나리오는 오탐.
+
+재현:
+1. "+ 추가" 클릭 → 부서명 입력 시작
+2. 트리에서 다른 부서 클릭 OR 회사 셀렉트 변경
+3. 입력 내용 소실, 토스트/확인창 없음
+
+---
+
+### 4. emptyDraft start_date 기본값 — ✅ 진짜 버그
+
+**판정**: ✅ 진짜 버그 (사용자 의도 없는 today 저장)
+
+```
+page.tsx:113
+start_date: new Date().toISOString().slice(0, 10),
+```
+
+`emptyDraft()`는 매 호출 시 그 시점의 날짜를 `start_date`에 박는다. UI에서 시작일 행은 `{false && ...}` 로 숨겨져 있어 (line 1372) 사용자가 이 값을 인지하거나 수정할 수 없다. 결과:
+
+- 신규 부서 생성 시 → `start_date = 오늘` 로 항상 DB에 저장됨
+- 일괄등록 시 → `emptyDraft(selectedCompanyCode)` 스프레드로 동일 문제 (line 968)
+- 사용자가 명시적으로 시작일을 지정한 적이 없음에도 not-null 값이 저장됨
+
+기대 동작: `start_date: ""` 또는 `null` 로 초기화, UI가 숨겨져 있는 동안에는 서버에 null 전송.
+
+---
+
+### 5. handleMove — ✅ 진짜 버그 (부분 업데이트)
+
+**판정**: ✅ 진짜 버그
+
+```
+page.tsx:403-411
+const results = await Promise.all(
+ reordered.map((s, i) =>
+ departmentAPI.updateDepartment(s.dept_code, toUpdatePayload(s, { sort_order: (i+1)*10 }))
+ )
+);
+```
+
+`Promise.all`로 형제 부서 전체를 동시 PUT 호출한다. 일부 요청 실패 시:
+
+- `results.find((r) => !r.success)` 로 첫 번째 실패를 감지하고 toast를 띄우지만 (line 412-413)
+- 이미 성공한 요청의 `sort_order` 변경은 DB에 반영됨
+- `loadDepartments()` 재호출도 catch 블록에서는 실행되지 않음 (line 414)
+
+결과: 형제 5개 중 3번째가 실패하면 1, 2번 sort_order는 변경, 3, 4, 5번은 미변경인 불일치 상태가 DB에 영구 잔존. 게다가 실패 후 화면은 재로드 없이 이전 상태를 유지하므로 **UI와 DB가 불일치**.
+
+---
+
+### 6. 검색 + 트리 broken tree — ✅ 진짜 버그
+
+**판정**: ✅ 진짜 버그 (자식만 매칭 시 트리에서 사라짐)
+
+```
+page.tsx:231-239 — filteredDepts: 이름/코드 단순 includes 필터
+page.tsx:241-246 — childrenOf: filteredDepts 기준으로 자식 조회
+page.tsx:1064 — DeptTree 내부: sub = allDepts.filter(...) ← allDepts는 filteredDepts
+```
+
+**시나리오**: 부서 구조가 `경영지원본부 > 인사팀 > 채용파트` 일 때 "채용"으로 검색하면:
+
+- `filteredDepts` = [`채용파트`] (부모 2개는 미포함)
+- `childrenOf(null)` = `filteredDepts`에서 `parent_dept_code === null` 인 것 → 없음
+- 트리에 아무것도 표시 안 됨
+
+반대 시나리오: "경영"으로 검색하면 `filteredDepts` = [`경영지원본부`], `childrenOf(null)` = [`경영지원본부`] → 렌더됨. `DeptTree` 내부의 `sub = allDepts.filter(d => d.parent_dept_code === dept.dept_code)` 에서 `allDepts`는 `filteredDepts`이므로 `인사팀`, `채용파트`는 없음. 펼쳐도 자식 없음으로 표시.
+
+검색 키워드가 있을 때는 트리 구조가 무너져 매칭 결과를 찾을 수 없는 케이스가 다수 발생.
+
+---
+
+### 7. handleSave new mode — ⚠️ 잠재 위험
+
+**판정**: ⚠️ 잠재 위험
+
+```
+page.tsx:477
+const res = await departmentAPI.createDepartment(selectedCompanyCode, payload);
+```
+
+`selectedCompanyCode`는 클로저로 캡처된 현재 state값이다. 사용자가:
+
+1. 회사 A 선택 → "+ 추가" 클릭 → 신규 입력 시작
+2. 회사 셀렉트를 회사 B로 변경 (draft는 그대로 우측에 남아있음 — 가설 9)
+3. "저장" 클릭
+
+→ `draft.company_code`는 A이지만, `createDepartment(selectedCompanyCode=B, ...)` 로 **회사 B에 부서가 생성됨**. `payload`에 `company_code` 필드는 없으므로 서버가 URL path의 company_code를 사용하면 B 소속이 됨.
+
+`draft.company_code`와 `selectedCompanyCode`가 분리된 것 자체가 근본 원인.
+
+---
+
+### 8. Bulk register — ✅ 진짜 버그 + ⚠️ 잠재 위험
+
+**판정**: ✅ start_date 강제 삽입 (진짜 버그) + ⚠️ 직렬 성능 (잠재 위험)
+
+**start_date 강제 삽입** (진짜 버그):
+```
+page.tsx:968
+...emptyDraft(selectedCompanyCode), ← start_date=today 강제 포함
+dept_code,
+dept_name,
+```
+가설 4와 동일. 일괄등록된 모든 부서에 `start_date=오늘` 이 박힌다.
+
+**직렬 호출 성능** (잠재 위험):
+```
+page.tsx:959-979
+for (const line of lines) {
+ await departmentAPI.createDepartment(...) // 직렬
+}
+```
+100건 입력 시 API 평균 300ms 가정 → 30초 소요. `setBulkUploading(true)` 후 대기하지만 타임아웃 처리가 없어 네트워크 불량 환경에서 UI가 장시간 블로킹됨. `Promise.allSettled` 병렬화로 해결 가능하나 현재는 누락.
+
+---
+
+### 9. 회사 변경 시 selected/draft 초기화 누락 — ✅ 진짜 버그
+
+**판정**: ✅ 진짜 버그
+
+```
+page.tsx:214-216
+useEffect(() => {
+ loadDepartments(); // 트리는 재로드
+}, [loadDepartments]);
+// selectedCode, draft, isNewMode 초기화 없음
+```
+
+`selectedCompanyCode`가 바뀌면 `loadDepartments`가 새 회사 부서 목록을 로드하지만, 우측 패널의 `selectedCode`, `draft`, `isNewMode`, `originalDraft`는 이전 회사 값 그대로 남는다.
+
+재현:
+1. 회사 A에서 `DEPT001` 선택 → 우측에 상세 표시
+2. 회사 셀렉트를 회사 B로 변경
+3. 우측 패널에 여전히 회사 A의 `DEPT001` 정보 표시
+4. "저장" 클릭 시 회사 B context에서 `DEPT001` PUT 요청 발생
+
+트리가 회사 B 부서를 보여주는 동안 상세 패널은 회사 A 데이터를 편집하는 모순 상태.
+
+---
+
+### 10. dept_code 입력 검증 부재 — ⚠️ 잠재 위험
+
+**판정**: ⚠️ 잠재 위험 (UX 혼란, 서버 silent override)
+
+```
+page.tsx:1257-1263
+ update("dept_code", e.target.value)}
+ placeholder="저장 시 자동 부여 (DEPT_n)"
+ readOnly={!!draft.dept_code} ← 신규 시 draft.dept_code=""이므로 편집 가능
+/>
+```
+
+신규 입력 시 `draft.dept_code`가 빈 문자열이므로 `readOnly={false}` 상태로 사용자가 임의 입력 가능. 그러나 프론트에는 `^[A-Za-z0-9_]+$` 패턴 검증이 없다. 백엔드가 패턴 불일치 시 자동 코드로 폴백한다면 사용자가 입력한 코드와 실제 저장된 코드가 달라지는 silent override 발생.
+
+부수 문제: 신규 모드에서 사용자가 `dept_code`에 값을 직접 입력하면 `readOnly={!!draft.dept_code}`에 의해 즉시 readonly가 되어 수정이 불가능해진다 (onBlur 없이 onChange로 바로 잠김).
+
+---
+
+### 11. members 탭 effect — ✅ 진짜 버그
+
+**판정**: ✅ 진짜 버그 (stale data 가능)
+
+```
+page.tsx:219-228
+useEffect(() => {
+ if (activeTab !== "members" || !selectedCode || isNewMode) {
+ setMembers([]);
+ return;
+ }
+ (async () => {
+ const res = await departmentAPI.getDepartmentMembers(selectedCode);
+ if (res.success && (res as any).data) setMembers((res as any).data);
+ })();
+}, [activeTab, selectedCode, isNewMode]);
+```
+
+AbortController가 없다. 재현 시나리오:
+
+1. 부서 A 선택 → "부서원 정보" 탭 클릭 → API 호출 시작 (느린 네트워크)
+2. 트리에서 부서 B 클릭 → selectedCode 변경 → effect 재실행 → B 멤버 API 호출
+3. B 응답 먼저 도착 → `setMembers(B 멤버)`
+4. A 응답 나중 도착 → `setMembers(A 멤버)` 로 덮어씀
+5. 화면에는 부서 B가 선택된 상태이지만 A의 멤버 목록이 표시됨
+
+cleanup 함수에서 `let cancelled = true` 플래그 또는 `AbortController` 로 이전 fetch를 무효화해야 한다.
+
+---
+
+### 12. originalDraft 동일 ref 공유 — ❌ 오탐
+
+**판정**: ❌ 오탐 (현재 코드에서 실제 문제 없음)
+
+```
+page.tsx:287-288
+setDraft(loaded);
+setOriginalDraft(loaded);
+```
+
+`loaded`는 `handleSelectDepartment` 내에서 `{...emptyDraft(...), ...}` 객체 리터럴로 생성된 새 객체이므로 `setDraft`와 `setOriginalDraft`가 같은 ref를 공유해도, React의 `setDraft((prev) => ({...prev, [key]: value}))` 패턴 (line 1244)이 spread로 새 객체를 만들기 때문에 `originalDraft`를 mutate하지 않는다. 현재 코드 기준으로 실제 문제 없음.
+
+---
+
+## 추가 발견 버그
+
+### B1. DeptTree — sub 필터가 sort 없음 ⚠️
+
+```
+page.tsx:1064
+const sub = allDepts.filter((d) => d.parent_dept_code === dept.dept_code);
+```
+
+`DeptTree` 컴포넌트 내부의 `sub` 계산에는 `sort_order` 정렬이 없다. 루트 레벨은 `childrenOf(null)` (line 245)에서 sort가 적용되지만, 2단계 이하 자식들은 `allDepts.filter`로 순서 보장 없이 렌더된다. `handleMove`로 sort_order를 변경해도 2단계 이하는 화면에 반영되지 않음.
+
+### B2. handleMove — 삭제된 부서가 siblings에 포함될 수 있음 ⚠️
+
+```
+page.tsx:381-382
+.filter((d) => ... && !(d as any).deleted_at)
+```
+
+`loadDepartments`에서 `showDeleted=true`일 때 삭제된 부서도 `departments`에 포함된다. `handleMove`는 `!(d as any).deleted_at`로 필터하므로 siblings에서 제외하는 의도는 맞다. 그러나 `sort_order` normalize 결과가 삭제된 부서의 기존 sort_order와 충돌할 수 있다. 낮은 심각도.
+
+### B3. bulkOpen 취소 시 진행 중 요청 취소 불가 ✅
+
+```
+page.tsx:986
+setBulkOpen(false);
+```
+
+`bulkUploading` 중에 다이얼로그 외부 클릭(onOpenChange)으로 닫으면 `setBulkOpen(false)`로 UI는 닫히지만 `for...of` 루프는 계속 실행된다. 완료 후 `loadDepartments()`가 호출되는데 이 시점에 이미 사용자가 다른 작업을 하고 있으면 예상치 못한 트리 재로드가 발생.
+
+```
+page.tsx:929 —