# HMM 백오피스 사용자·그룹·역할·토큰 관리 전환 (#702) > 상태: Implementing > 추적: Redmine #702 / Git 브랜치: `hmm-backoffice` > 대상: `hmm-backoffice.cloud-handson.com`, HMMAIPOC / `ADMIN` ## 목적 기존 KB/VPD 데모의 `CB_*` 사용자·그룹·역할·Bearer 토큰 모델을 HMM HR 데모의 실제 기준 테이블로 바꾼다. 직원과 조직 정보는 이미 적재된 HMM 테이블을 재사용하고, 접근 제어에만 필요한 테이블은 `HMM_ACCESS_*` 접두어로 추가한다. ## 기준 테이블과 소유권 | 관리 기능 | 기준 테이블 | 처리 방식 | | --- | --- | --- | | 사용자 | `HMM_HR_EMPLOYEES` | 기존 직원 ID·사번·성명·소속팀·재직 상태를 직접 사용 | | 조직 참조 | `HMM_ORG_TEAMS` | 직원 생성 시 소속팀 검증에 사용 | | 접근 그룹 | `HMM_ACCESS_GROUPS`, `HMM_ACCESS_GROUP_MEMBERS` | HR 조직과 독립적인 논리 접근 그룹을 새로 관리 | | 역할 | `HMM_ACCESS_ROLES`, `HMM_EMPLOYEE_ACCESS_ROLES`, `HMM_GROUP_ACCESS_ROLES` | 직원 직접 역할과 그룹 상속 역할을 분리 | | 토큰 | `HMM_ACCESS_BEARER_TOKENS` | 원문은 발급 화면에서 한 번만 표시하고 SHA-256 해시만 저장 | | 감사 | `HMM_ACCESS_AUDIT` | 사용자·그룹·역할·토큰 변경 이력 저장 | | 지식 문서 | `HMM_KNOWLEDGE_DOCUMENTS` | 파일명·원문·BLOB·Abstract·생성일자를 저장 | | 지식 청크 | `HMM_KNOWLEDGE_CHUNKS`, `HMM_KNOWLEDGE_TAGS` | 문서별 청크와 정규화된 Tag·벡터를 저장 | `HMM_ORG_TEAMS`는 인사 조직 원장이므로 접근 그룹과 혼합하지 않는다. 이로써 한 직원이 여러 업무 접근 그룹에 속하면서도 인사 소속팀은 하나로 유지된다. ## 데이터 흐름 ``` HMM_HR_EMPLOYEES ──< HMM_EMPLOYEE_ACCESS_ROLES >── HMM_ACCESS_ROLES │ └──< HMM_ACCESS_GROUP_MEMBERS >── HMM_ACCESS_GROUPS │ └──< HMM_GROUP_ACCESS_ROLES >── HMM_ACCESS_ROLES HMM_HR_EMPLOYEES ──< HMM_ACCESS_BEARER_TOKENS HMM_ACCESS_AUDIT records every backoffice change HMM_KNOWLEDGE_DOCUMENTS ──< HMM_KNOWLEDGE_CHUNKS ──< HMM_KNOWLEDGE_TAGS ``` ## 화면 및 호환성 - `/users`는 `HMM_HR_EMPLOYEES`를 사용자 목록으로 표시한다. 활성/비활성은 `employment_status`의 `ACTIVE`/`INACTIVE`에 매핑한다. - `/groups`는 `HMM_ACCESS_GROUPS`를 관리한다. HR 팀 이동 기능으로 오해되지 않도록 논리 접근 그룹임을 화면에 명시한다. - `/roles`는 HMM 접근 역할만 관리한다. - `/tokens`는 HMM 직원에게 토큰을 발급·회수한다. KB 이해당사자 원장은 참조하지 않는다. - `/objects`, `/permissions`, `/masking-rules`, `/probe`, MCP 화면은 삭제하지 않는다. 기존 CB 화면 계약은 `CB_PROTECTED_*`, `CB_PERMISSION*`, `CB_VECTOR_*` 호환 뷰로 유지하고, 실제 데이터는 `HMM_ACCESS_*` 및 `HMM_KNOWLEDGE_*`에 저장한다. - 애플리케이션 시작 시 `HmmKnowledgeSchemaInitializer`가 HMM 지식 테이블·시퀀스·인덱스를 멱등적으로 준비하고 `CB_VECTOR_*` 조회 호환 뷰를 갱신한다. 기존 물리 `CB_VECTOR_*` 테이블이 존재하는 환경은 덮어쓰지 않는다. ## 브랜치·배포 기준 - Smilegate 기준은 `main`이며, HMM 백오피스의 구현·배포·검증은 `hmm-backoffice` 브랜치만 사용한다. - HMM 배포 전에 현재 브랜치명을 확인하고, `main` 또는 `hmm-ai-agent` 브랜치에서는 HMM 백오피스 JAR를 배포하지 않는다. - 메뉴 전수 점검은 로그인 세션으로 원래 메뉴 URL 전체를 순회한다. HTTP 200만으로 통과시키지 않고 화면 내 `ORA-`, `데이터 처리 오류`, `Whitelabel Error Page`도 함께 검사한다. ## 보안·검증 - 토큰 원문, DB 비밀번호, Wallet은 테이블·Git·로그에 저장하지 않는다. - DDL은 재실행 가능해야 하며 기존 HR 행을 수정하거나 삭제하지 않는다. - 배포 전 전체 자동 테스트를 통과시키고, 배포 후 사용자·접근 그룹·역할·토큰뿐 아니라 보호 객체, 권한, 마스킹, 접근 검증, 지식자료, MCP, 운영 메뉴를 로그인 세션으로 전수 확인한다. ## 롤백 애플리케이션은 이전 JAR로 되돌릴 수 있다. 새 `HMM_ACCESS_*` 테이블은 운영 데이터가 생긴 뒤에는 삭제하지 않으며, 문제 발생 시 화면 매퍼만 이전 버전으로 복구한다.