시스템 관리자 콘솔

제품 개발 기록 · 조직·계정·권한 · 인증 · 근태·휴가 · 급여 시트 · 가져오기

tools/system-admin 화면·콘솔 REST·대상 API·저장 모델을 대조한 운영 안내입니다. 운영 콘솔 접속·비밀키 입력·조직 및 계정 생성·삭제·회신·외부 동기화는 실행 검증하지 않았습니다.

운영자와 접속 범위

시스템 관리자 콘솔은 병원 직원의 /admin/과 별개이며 독립 계정·권한·데이터베이스를 사용합니다. 일반 병원 계정의 플랫폼 역할만으로 콘솔에 로그인하는 방식으로 설명하면 안 됩니다. 초기 구성은 독립 관리 데이터베이스 준비, 장애 복구는 Root 복구를 따릅니다.

항목	범위
사용 대상	승인된 시스템 운영자. 보유 권한에 따라 메뉴와 변경 조작이 달라집니다.
시작 위치	인프라에서 제공한 시스템 관리자 주소의 로그인 화면
사전 조건	허용 네트워크, 구성된 로그인 방식, 승인된 계정과 필요한 권한
업무 데이터	대상 백엔드·조직을 선택합니다. 같은 조직 ID라도 대상 백엔드가 다르면 같은 대상으로 간주하지 않습니다.

처음 구성한 환경의 최초 운영자 계정

독립 관리 데이터베이스에 운영자 계정이 하나도 없으면 로그인 폼 대신 최초 운영자 계정 만들기가 표시됩니다. 이메일·성·이름·비밀번호·비밀번호 확인을 입력합니다. 비밀번호는 12자 이상이어야 하며 확인 값과 같아야 합니다. 생성하면 최초 계정에 Root와 전체 범위의 SUPER_ADMIN 역할을 부여하고, 역할 목록이 비어 있으면 기본 역할·권한도 같은 트랜잭션에서 준비합니다.

생성 후 로그인 화면으로 돌아오면 입력한 이메일이 채워져 있습니다. 방금 정한 비밀번호로 로그인하고 인증 앱(TOTP)을 등록합니다. 이 경로는 계정을 만들 때 직접 정한 비밀번호이므로 첫 로그인에서 비밀번호를 다시 바꾸도록 요구하지 않습니다.

삭제된 계정을 포함해 운영자 계정이 하나라도 있으면 최초 계정 만들기를 사용할 수 없고 서버도 중복 요청을 409로 거절합니다. 기존 계정의 복구는 위 Root 복구 절차를 따릅니다. 콘솔 화면을 사용할 수 없는 환경에서는 초기 구성 문서의 tools/system-admin/server/db/seeds/bootstrap-local.sql 수동 절차를 사용합니다.

1. 허용된 주소에서 로그인 방식을 확인합니다. 로컬 계정 로그인은 자격 확인 후 인증 앱 등록/코드 입력 또는 복구 코드 흐름을 사용합니다. 제공되는 SSO는 설정한 공급자를 통해 로그인합니다.
2. 인증 후 접근 심사가 대기·거절 상태라면 화면의 안내를 확인합니다. 인증 성공만으로 관리 기능을 사용할 수 있는 것은 아닙니다.
3. 승인된 계정으로 들어와 대상 백엔드와 조직을 선택합니다. 읽기 권한과 변경 권한을 구분하며 중요한 변경에서 재인증을 요구하면 그 절차를 완료해야 합니다.
4. 로그아웃하면 현재 콘솔 이용을 종료합니다. 백엔드 설정·병원 코드·배포 정책을 삭제하는 조작은 아닙니다. 인증 코드·복구 코드·연결 비밀값은 문서나 촬영 자료에 남기지 않습니다.

PR #703·#731·#752·#776·#781·#783·#800과 현재 로그인 화면·최초 계정 생성·접근 관리 소스를 대조했습니다. 운영 로그인, 최초 계정 생성, 승인, 권한 변경과 서비스 연결은 이번 작업에서 실행하지 않았습니다.

현재 메뉴와 지원 조작

메뉴·해시	지원 범위·관련 절차
조직 관리 #organizations	대상 조직 조회·정보와 정책 관리. 아래 조직 절차를 참조합니다.
근태 조회·세콤 동기화·외부 연동·CS 리포트	업무 백엔드의 권한이 허용한 조회·처리. 대상과 실제 결과를 대조합니다.
플랫폼 스태프 #platform-staff	업무 백엔드의 스태프 관리이며 콘솔 접근 계정과 구분합니다.
엔드포인트 #endpoints	설정된 백엔드의 연결 상태와 진단을 확인합니다.
앱 백엔드 #app-backends	병원 코드와 직원 앱 접속 주소의 공개 상태를 관리합니다.
앱 버전 #app-versions	설치 앱 최소 빌드와 제공할 화면 묶음을 검토·게시합니다.
시트 템플릿·공휴일	공용 기준 자료 조회·관리입니다.
접근 계정 #sysadmin-admins	콘솔 접근 신청·계정 관리입니다. 권한이 있을 때 표시됩니다.
역할 및 권한·권한 카탈로그	콘솔 권한을 관리·조회합니다.
SSO 로그인 설정 #sysadmin-sso	콘솔 로그인 공급자를 설정합니다.
접근 감사 기록 #sysadmin-access-audit	승인·역할·SSO·Root 보안 조작의 기록을 조회합니다.

app.ts의 기본 메뉴와 system-admin-access-feature.ts가 권한에 따라 추가하는 메뉴를 함께 확인해야 합니다. ‘9개 메뉴만 있음’이나 ‘접근 감사 기능 없음’이라는 설명은 현재 구현과 맞지 않습니다. 계정·권한·SSO의 모든 예외·복구 조작은 아직 화면 검증을 마치지 않았으므로 운영 실행 전 관련 runbook과 환경 승인을 확인합니다.

엔드포인트 연결과 발견 승인

현재 백엔드 목록과 내부 접속 주소의 원본은 SYSADMIN_ENDPOINTS입니다. 일반 업무 서버 계정의 비밀번호를 콘솔에 저장해 연결하는 절차를 사용하지 않습니다. 백엔드 연결 및 서명된 조회에 환경 식별자, 공개키 연결, 초기 데이터 정합화와 오류별 진단을 정리했습니다.

1. 엔드포인트에서 설정된 대상·환경·상태를 확인합니다. 상태 조회는 접근 권한을 부여하지 않습니다.
2. 연결에 실패하면 표시된 진단과 요청 정보를 확인하고 환경 식별자·내부 주소·서명 신뢰 관계를 담당자가 점검합니다. 고객 조직 데이터베이스에 콘솔 초기화 작업을 실행하지 않습니다.
3. 백엔드 설정 변경은 배포 설정에서 검토합니다. 목록 재조회·상태 확인만으로 병원 앱의 공개 주소가 게시되지 않습니다.

직원 앱 접속 주소와 버전 게시

작업	순서·결과	정본 절차
병원 코드와 접속 주소	앱 백엔드에서 대상·병원 코드·공개 주소를 검토하고 게시 상태를 확인합니다. 내부 접속 주소와 직원에게 제공하는 주소를 구분합니다.	앱 백엔드 발견
화면 묶음 원본 설정	앱 버전에서 앱·리전·버킷·버전 경로·다운로드 주소를 저장하고 연결 확인을 실행합니다. 저장·확인은 관리 권한과 재인증이 필요합니다.	앱 버전 관리
버전 선택과 게시	목록을 새로 읽고 iOS/Android의 대상 묶음·최소 설치 빌드·사유를 정해 초안을 저장합니다. 미리보기 뒤 게시해야 실제 표준 정책이 바뀝니다.	앱 시작 규약

최신 업로드와 현재 사용 버전은 별개입니다. 목록 새로고침은 업로드·자동 게시를 수행하지 않습니다. 게시 실패 시 현재 공개 버전을 다시 확인합니다. 변경 전 초안을 닫는 것과 게시를 되돌리는 것은 다르며, 이미 게시한 버전을 되돌리는 버튼 대신 검토한 새 버전을 다시 게시하는 모델입니다. 앱 배포 ZIP과 문서 가이드의 WebM·썸네일 전달은 별도 작업입니다.

조직 조회·프로비저닝

1. 조직 관리 → refresh로 연결 가능한 서버들의 조직을 모아 봅니다. 검색칸 **Filter by name, code, status...**은 이름·코드·상태·유형·엔드포인트의 부분 일치를 대소문자 없이 필터합니다. 페이지 컨트롤은 없습니다. 행을 누르면 대상 엔드포인트와 조직 정보, 역할, 관리자 목록을 읽습니다. back은 목록으로 돌아갑니다.
2. + New Organization을 누르면 Provision New Organization이 열리고 연결 상태를 검사합니다. 사용 가능한 서버가 하나면 선택하고 여러 개면 직접 고릅니다. 연결된 서버가 없으면 생성 버튼을 사용할 수 없습니다.
3. 다음 입력을 채우고 PROVISION ORGANIZATION을 누릅니다. 별도 검토 단계나 마지막 확인 창은 현재 폼에 없습니다.

입력	필수·초기값·검증
대상 엔드포인트	필수, 상태 ok만 선택 가능. 조직과 최초 계정이 이 서버 DB에 생성됨
NAME / CODE	필수. 같은 서버의 삭제되지 않은 조직 CODE 중복 거절
LEGAL NAME / 진료 분야	선택
종류 / 병상 수	기본 의원 CLINIC / 30미만 SMALL. 종류는 병원·종합병원·상급종합병원·요양·정신·치과·한방·조산원·기타도 선택. 병상 범위는 30~99/100~299/300이상
TIMEZONE / FISCAL YEAR START	기본 Asia/Seoul / 1. UI 회계월 1~12
WEEKLY LIMIT / DAILY STANDARD	기본 52/8시간. 이 시스템 API는 숫자만 검사하며 일반 조직 설정의 범위 검증과 같지 않음
PAY DAY / CUTOFF DAY	기본 25/20, UI 1~31. API에는 별도 상한 검증 없음
LAST NAME / FIRST NAME / EMAIL / EMPLOYEE NUMBER	모두 필수. 이메일 형식 검사, 기존 직원 이메일·Account 이메일 중복 거절
PASSWORD / PHONE	비밀번호 필수. 새 병원은 아직 비밀번호 설정이 없어 기본 규칙(8자 이상·대문자·소문자·숫자·특수문자)을 따르며, 라벨에 규칙이 보이고 화면·서버가 같은 함수로 검사합니다. 운영자가 정한 값이라 관리자는 첫 로그인 때 비밀번호를 바꿔야 합니다(mustChangePassword=true). 전화 선택. 이미 다른 Account의 전화면 계정 연결 전화는 비울 수 있음
Create owner account	기본 체크. Account는 항상 생성하며 이 옵션은 조직의 owner 연결 여부를 결정

4. 서버는 Account·Organization·최초 시스템 관리자 Employee·관리팀·기본 항목코드와 역할·권한 등을 생성합니다. 성공 화면에서 실제 엔드포인트·조직·관리자·권한 수·역할 목록을 확인합니다. Done은 닫기, Create Another는 모든 입력과 결과를 지우고 대상 서버를 다시 검사합니다. 폼의 Cancel/close는 아직 보내지 않은 내용을 버립니다.
5. 오류가 나면 입력을 유지한 상태로 원인을 보여 줍니다. 워크스페이스 서비스에는 초기 트랜잭션 뒤 시드 작업이 있으므로 통신 실패 직후 같은 코드로 다시 생성하기 전에 조직 목록에서 생성 여부를 확인합니다. 온보딩 이후 가져오기, 조직 관리자로 이어집니다.

모달의 설명에 남아 있는 51 Permissions / 6 Roles / mustChangePassword=true는 현재 서버 결과를 보장하지 않습니다. 공용 카탈로그와 실제 결과가 기준이며 신규 Account 방식의 관리자 Employee는 mustChangePassword 기본 false입니다. 별도의 ProvisioningRun→ImportRun 자동 연결·도입 단계 추적 화면도 확인되지 않습니다.

조직 정보·상태·정책·AI 설정

1. 상세 Edit Info에서 NAME·CODE·LEGAL NAME·종류·규모·진료 분야·웹사이트·이메일·전화·팩스·시간대·locale·currency·회계 시작월을 고칩니다. Save 성공 후 목록과 상세를 재조회하며 Cancel/X/바깥 영역은 저장하지 않고 닫습니다. 일반 선택 텍스트를 빈 값으로 만들면 UI가 요청에서 빼므로 기존 값을 지우는 동작과 다릅니다. 시스템 API는 대부분 문자열과 숫자만 검증하므로 일반 관리자 폼의 길이·이메일·설정 스키마 제한까지 적용된다고 단정하지 않습니다.
2. Organization의 status 선택을 ACTIVE/INACTIVE/SUSPENDED/TRIAL로 바꾸면 즉시 저장합니다. 별도 확인이나 저장 버튼이 없습니다. 서버는 status 필드만 바꾸며 isActive·기존 토큰까지 일괄 변경하는 삭제 동작과 다릅니다. 실패 시 선택값이 화면에 남을 수 있으므로 상세를 재조회합니다.
3. Password Policy에서 형식(숫자만/소문자+숫자/대소문자+숫자, 기본 mixed)과 길이(UI 4~20, 기본 8)를 고르고 Save합니다. 임시 비밀번호 생성 규칙이며 기존 비밀번호 일괄 초기화가 아닙니다. 관리자 앱의 고정 임시 비밀번호 선택은 이 콘솔에 없습니다.
4. Self-Editable Fields에서 프로필 사진·전화번호·주소·비상연락처·계좌정보를 고르고 Save합니다. 기본은 사진·주소·비상연락처 허용, 전화·계좌 미허용이며 직원 내정보의 편집 정책과 연결됩니다.
5. Login Methods에서 비밀번호와 SMS OTP를 선택하고 Save합니다. 기본은 비밀번호이며 아무것도 선택하지 않으면 안내로 차단합니다. 조직에서 OTP를 켜는 것과 직원의 authMethods에 phone_otp가 있는 것은 각각 필요합니다. 인증에서 실제 로그인 사용법을 확인합니다.
6. AI Assistant → AI 어시스턴트 사용(기본 꺼짐), MONTHLY TOKEN LIMIT을 입력하고 Save합니다. 상한은 월 입력+출력 토큰 합계이며 빈 값 또는 0은 요청에서 상한을 제거합니다. UI 최소 0·증분 100000입니다. 기존 AI의 다른 설정 키는 유지합니다. 사용자에게는 ai:execute 계열 권한도 필요합니다. 설정 변경과 별도로 AI 모니터링에서 조직별 사용량·대화·오류를 조사합니다.
7. 각 정책 저장은 현재 상세에서 읽은 Organization.settings 전체에 변경 키를 얹어 보냅니다. 동시 편집 충돌 감지/병합 UI가 없으므로 다른 운영자가 저장한 뒤 낡은 화면에서 저장하면 다른 키까지 덮일 수 있습니다. 성공/실패 후 최신 상세를 다시 확인합니다.
8. 조직 Delete는 조직명을 정확히 다시 입력해야 합니다. 취소하면 실행하지 않습니다. 성공 시 조직을 비활성·논리 삭제하고 소속 직원 논리 삭제/퇴직, 조직 토큰 무효화를 수행합니다. owner는 다른 미삭제 조직 소속이 없을 때만 Account와 그 토큰도 삭제/무효화합니다. 일반 관리자 삭제와 영향이 다르며 복원 UI는 없습니다.

역할·기본 데이터·조직 관리자 계정

1. 상세 Roles → Seed Defaults → 확인은 현재 기본 권한·역할을 시드/동기화합니다. 기존 모든 항목을 무조건 건너뛴다는 확인 문구와 달리 기본 역할의 권한 연결이 동기화될 수 있으므로 저장 후 역할을 확인합니다. Seed Item Codes → 확인은 기본 수당/공제 코드를 등록하며 이미 존재하는 코드는 건너뜁니다. 시드 성공은 급여 계산이나 시트 생성 성공을 뜻하지 않습니다.
2. + Add Role에서 CODE/NAME 필수, TYPE 기본 custom(system/team도 선택)을 입력합니다. 권한 코드+이름 목록에서 체크하거나 select all / clear를 누르고 Create합니다. 조직 안의 같은 코드 중복은 거절하며 생성된 역할은 활성입니다.
3. 역할 edit는 CODE를 바꾸지 못하고 NAME·TYPE·권한을 수정합니다. Save는 기본 정보와 권한 연결을 트랜잭션으로 저장합니다. 전달한 권한 전체를 교체하며 빈 목록은 권한을 모두 제거합니다. 활성 권한 코드만 연결합니다. UI에는 역할 active 필드의 독립 수정 컨트롤이 없습니다.
4. 역할 delete → confirm은 권한 연결을 제거하고 역할을 논리 삭제합니다. cancel은 취소입니다. SUPER_ADMIN 삭제는 서버가 거절합니다. 이 시스템 API에는 조직 관리자 API의 배정 직원 존재 시 삭제 차단과 같은 검사가 없습니다. 권한 카탈로그 로드 실패는 무시되므로 빈 목록을 정상 권한 없음으로 보고 저장하지 않도록 재조회해야 합니다.
5. System Admin Accounts → + Add Admin에서 LAST NAME/FIRST NAME/EMAIL/EMPLOYEE NUMBER/PASSWORD를 넣고 Create합니다. 이름·사번은 빈 값 불가, 이메일 형식·동일 조직 사번·전역 직원/Account 이메일 중복을 검사하며 비밀번호는 그 병원의 일반 비밀번호 설정(최소 길이 4~20·필수 문자, 설정이 없으면 기본 8자·네 종류)을 따릅니다. 라벨에 그 규칙이 보이고, 화면이 먼저 검사한 뒤 서버도 같은 함수로 다시 검사합니다. 전화는 선택입니다. 활성 Account와 isSystemAdmin=true Employee를 함께 만들고, 운영자가 정한 비밀번호라 mustChangePassword=true로 둬 관리자가 첫 로그인 때 직접 바꾸게 합니다.
6. 관리자 edit에서는 이름·이메일·전화·상태를 고치고 Save합니다. 사번은 수정할 수 없습니다. 상태는 UI ACTIVE/INACTIVE/SUSPENDED 중에서 선택합니다. 이 경로의 이메일/이름 변경은 Employee에 기록하고 Account 이메일/이름까지 동기화하지 않습니다. 로그인 식별자가 변경되었다고 단정하지 않습니다.
7. 같은 편집 폼의 선택 비밀번호에 그 병원 규칙에 맞는 새 값을 입력하면 연결된 Account 비밀번호를 변경하고, 관리자가 다음 로그인 때 다시 바꾸도록 mustChangePassword=true로 둡니다. 비우면 유지합니다. 미연결 레거시 직원은 마이그레이션 필요 오류가 납니다. 별도의 초기화·메일 발송 버튼은 없습니다. 기존 세션 무효화까지 이 API가 보장하지 않습니다.
8. 관리자 delete → confirm은 Employee를 논리 삭제하고 시스템 관리자 표시를 끕니다. 마지막 미삭제 시스템 관리자는 삭제할 수 없습니다(상태와 무관한 개수). 연결 Account 자체를 삭제하는 동작은 아닙니다. cancel은 아무것도 바꾸지 않습니다. 생성/수정/권한 폼의 Cancel·X·바깥 영역은 변경 확인 없이 닫히므로 저장하지 않은 입력은 재열기에서 초기화됩니다.

근태 조회와 세콤 소스

1. 근태 조회에서 ORGANIZATION을 선택하고 FROM/TO·선택 EMPLOYEE #을 넣어 SEARCH합니다. 날짜 기본은 오늘과 7일 전, 사번은 정확히 일치하는 직원을 찾습니다. 상태 필터는 서버 인자와 앱 상태에 있으나 현재 화면에는 선택 입력이 없습니다. 전 조직을 동시에 펼치는 조회가 아니라 한 조직을 고릅니다.
2. 날짜·사번·이름·상태·실제 출퇴근·정규/연장/합계 시간·메모를 확인하고 prev/next로 50건씩 이동합니다. 서버는 날짜 내림차순·사번 오름차순입니다. 수정·재계산·내보내기는 없습니다. 0건일 때는 조회 전과 같은 안내문이 나오며 실패 시 이전 표가 남을 수 있습니다. 날짜 범위는 다시 입력해 검색합니다. 시간 표시 함수는 현재 서울 시간대를 사용하므로 다른 조직 시간대 출력은 별도 검증이 필요합니다.
3. 세콤 동기화 → refresh는 source key·Gateway schema·조직·enabled·마지막 커서/실행 시각·최근 수집 수·전체 이벤트 수를 봅니다. 자동 폴링이나 실행 즉시 수집 버튼은 없습니다.
4. + Add Source에서 SOURCE KEY·GATEWAY SCHEMA NAME·ORGANIZATION을 모두 채우고 Create합니다. 문자열은 비어 있으면 안 되고 조직 UUID가 필요합니다. 조직 없음/소스키 중복은 거절됩니다. 성공하면 secom_sync_state를 enabled=true, 커서 1970-01-01, 최근 수집 0으로 생성하고 목록을 재조회합니다. puller가 구성된 환경에서 다음 주기에 읽는 것이며 생성 성공만으로 수집을 증명하지 않습니다.
5. 행 ON/OFF는 enabled를 즉시 바꿉니다. reset → 확인은 커서를 epoch로, 최근 수집 수를 0으로 되돌립니다. delete → 확인은 동기화 상태 행을 물리 삭제합니다. 이는 이미 수집된 출퇴근 데이터 삭제가 아닙니다. 확인 취소는 유지하며 소스 편집·복원 UI는 없습니다. 추가 폼 Cancel·X·바깥 클릭은 닫기입니다.

앞의 다중 엔드포인트 제한이 이 두 메뉴에 적용됩니다. 근태 원천과 수집 후 처리는 근태·휴가에서 이어집니다.

외부 연동·상태 시크릿

1. 외부 연동 → refresh에서 조직·이름·연동 유형·Open API 주소·마스킹된 키/시크릿·상태 시크릿 상태·활성 여부를 확인합니다. 현재 선택 가능한 provider는 hereby Sign입니다.
2. + Add Credential에서 ORGANIZATION·NAME(1~100자)·EXTERNAL TYPE·OPEN API URL·API KEY·API SECRET을 입력하고 Create합니다. 기본 status는 active입니다. 주소는 HTTP(S) URL이어야 하고 query/hash를 허용하지 않으며 뒤 슬래시를 정리합니다. 같은 조직·유형에 활성 자격증명이 이미 있으면 충돌합니다. 서버는 비밀값을 암호화 저장하고 목록에는 마스킹해 돌려줍니다.
3. 행 edit에서 이름·주소·상태를 바꾸고 Save합니다. 조직은 읽기 전용입니다. API KEY/SECRET을 비우면 기존 값을 유지하고 새로 입력한 값만 교체합니다. Cancel·X·바깥 클릭은 아직 저장하지 않은 변경을 버립니다. 폼을 열 때 기존 원문 키를 다시 조회하지 않습니다.
4. 행 상태 버튼은 active/inactive를 즉시 전환하고 delete → 확인은 자격증명을 inactive·논리 삭제합니다. 저장/전환/삭제 성공 시 목록을 재조회하고 오류는 폼 또는 상단에 표시합니다. 이 콘솔에는 공급자 실제 연결 테스트나 계약 발송 버튼은 없습니다.
5. 저장된 자격증명의 편집 창 STATUS SECRET → Generate/Regenerate를 누릅니다. 활성 시크릿 재발급에는 기존 값이 중단된다는 확인이 있습니다. 새 값은 서버 암호화 저장 후 이번 응답에서 한 번 원문으로 보입니다. 일반 API 키/시크릿과 별도의 상태 웹훅 인증 값입니다.
6. Copy는 원문을 클립보드에 복사하며 Copied/Copy failed를 잠시 보여 줍니다. 창을 닫거나 다시 열면 원문은 사라집니다. 공급자 관리 화면에 실제로 등록하는 작업은 별도이며 복사 성공만으로 웹훅 연결을 보장하지 않습니다.
7. Revoke → 확인은 상태 시크릿을 비우고 inactive·폐기 시각을 기록합니다. 그 시크릿을 사용한 후속 웹훅은 유효하지 않으며 취소하면 유지됩니다. 재발급 응답을 잃었을 때 기존 원문을 다시 보는 기능은 없습니다.

다중 엔드포인트에서는 현재 UI가 대상 서버를 보내지 않는 제한이 있습니다. 연동 설정 저장·상태 웹훅·계약 송신은 별도의 검증 단계입니다. 직원에게 보이는 발신 이름 설정은 조직 설정과도 구분합니다.

CS 리포트 조사·상태 변경·회신

1. CS 리포트에 들어가 기본 열림 전체(접수/확인중/처리중)를 봅니다. 모든 상태/개별 상태, 모든 유형/오류/불편·개선/기능 요청/문의로 바꾸면 즉시 조회합니다. 접수번호·요청 ID 검색은 최대 64자이며 Enter 또는 새로고침으로 실행합니다. 현재 UI에는 앱·조직·우선순위 필터나 페이지 이동이 없습니다.
2. 서버별 첫 페이지 30건을 받아 접수일 내림차순으로 합칩니다. 위 총 건수는 전체 일치 건수의 합이므로 화면 행 수와 다를 수 있습니다. 미연결 서버는 개수·이름 경고로 표시하고 연결된 서버의 결과를 계속 보여 줍니다. 이것을 전 서버의 완전한 리포트 목록이라고 해석하지 않습니다.
3. 행을 눌러 접수번호·제목·내용·접수자·조직·앱·경로·빌드·브라우저·뷰포트·시간대·네트워크·임베드·오류 지문을 읽습니다. 스크린샷은 사용자의 가림 적용 여부와 크기를 표시하며 클릭하면 새 창으로 열고 사용자 파일도 링크로 엽니다. 자동 서버 스크린샷 생성이나 가림 해제 기능은 없습니다.
4. 오류가 있으면 메시지·코드·스택을 확인합니다. 요청 ID 버튼은 복사만 하고 별도 성공 알림을 보장하지 않습니다. 클라이언트 로그 → 로그 보기는 첫 로그 첨부 내용을 대상 API가 스토리지에서 읽게 한 뒤 JSON 배열을 표시합니다. 시각·종류·메시지·추가 데이터를 확인하며 로그 첨부가 없으면 안내합니다. 로그 실패는 **로그를 불러오지 못했어요.**이며 다시 누를 수 있습니다. 스크린샷/사용자 파일과 로그의 전송 경로는 다릅니다.
5. 처리에서 상태(확인중/처리중/해결/보류/중복), 우선순위(유지/낮음/보통/높음/긴급)를 고르고 상태 변경을 누릅니다. 중복은 원본 리포트 UUID가 필수입니다. 해결/보류/중복에는 사용자에게 보이는 회신(선택, 2000자 이하)을 입력할 수 있습니다. 상태 변경 성공 뒤 상세와 목록을 다시 조회하며 처리 입력은 초기화합니다.
6. 허용 순방향은 접수→확인중/처리중/종결, 확인중→처리중/종결, 처리중→종결입니다. 같은 상태의 우선순위 변경은 허용합니다. UI에는 접수·취소로 바꾸는 선택이 없습니다. 종결→처리중 재오픈은 API에서 사유 코멘트가 필요하지만 현재 상태 변경 UI가 그 comment를 보내지 않으므로 거절됩니다. 별도로 코멘트를 먼저 등록해도 동일 요청의 사유가 되지 않습니다.
7. 코멘트에서 내부 또는 회신을 선택하고 1~4000자 내용을 입력해 등록/Enter합니다. 공백은 제출하지 않습니다. 처음 기본은 내부이며 공개 범위 선택은 같은 페이지 사용 중 유지될 수 있으므로 매번 확인합니다. 내부 메모와 접수자에게 보이는 회신을 구분합니다. 성공 후 타임라인을 재조회하고 입력을 비웁니다.
8. 종결 전이 또는 회신 코멘트는 접수자가 알림에 동의했고 직원 연결이 있을 때 앱 알림/푸시를 요청합니다. 이 작업은 실제 사람에게 전달될 수 있습니다. 저장 뒤 알림 전송이 실패하면 오류가 나도 상태/코멘트는 이미 남을 수 있어 재열기에서 먼저 확인하고 중복 등록을 피합니다. 수신 여부는 별도 검증 대상입니다.
9. 닫기/X/Esc는 미저장 확인 없이 닫습니다. 상세 재열기는 상태 선택을 확인중·우선순위 유지를 기본으로 되돌리고 로그 표시도 초기화합니다. 목록 필터는 같은 페이지에서 유지되지만 상세 모달·필터가 주소에 저장되지는 않습니다.

CS 처리 원천은 CsReport, CsReportAttachment, CsReportComment와 저장소 파일입니다. 에이전트 작성 코멘트가 표시될 수 있지만 이 화면에 AI 실행·재분석 버튼은 없습니다. 직원 측 접수/알림은 알림과 연결됩니다.

플랫폼 스태프·권한

1. 플랫폼 스태프에서 서버가 여러 개면 엔드포인트부터 고릅니다. 기본 선택은 로그인 서버(복원 정보가 없으면 첫 서버)입니다. Account는 서버마다 별개이며 한 서버의 권한을 다른 서버에 자동 배포하지 않습니다.
2. 이메일 / 이름 검색 → 검색/Enter는 일반 회원을 포함한 일치 계정을 최대 30명 가져옵니다. 스태프 목록은 검색어를 지우고 현재 platformRole이 있는 계정 전체를 조회합니다. 결과에서 이메일·이름·계정 상태·플랫폼 역할·최근 로그인을 봅니다.
3. 스태프 생성에서 이메일·비밀번호(병원에 속하지 않아 기본 규칙: 8자 이상·대문자·소문자·숫자·특수문자)·성·이름·역할을 입력하고 생성합니다. 역할 기본 SUPPORT, OPERATOR도 선택합니다. 기존 이메일은 생성 대신 검색해 권한 부여하라는 충돌 안내를 냅니다. 성공 시 활성·이메일 인증 처리된 Account와 플랫폼 역할을 만들며 조직/직원/owner는 만들지 않습니다. 닫기는 미저장 폼을 버립니다.
4. 행 역할 선택 일반 회원/SUPPORT/OPERATOR → 적용은 즉시 저장합니다. 활성 Account에만 플랫폼 역할을 부여할 수 있습니다. 일반 회원으로 해제하면 미회수 지원 grant를 함께 회수하고 개수를 안내합니다. SUPPORT↔OPERATOR 변경은 일반 회원 해제와 다릅니다.
5. OPERATOR는 시스템 범위 API와 grant 관리 권한, SUPPORT는 받은 grant로 지원 입장 권한입니다. grant 발급·회수 화면은 이 LNB에 없습니다. 지원 조직 입장은 워크스페이스 허브의 별도 동선입니다. 현재 역할 적용 API에는 마지막 OPERATOR 또는 자기 역할 하향을 막는 검사가 없으므로 다른 유효 운영자 연결과 재로그인 결과를 확인해야 합니다.

시스템 시트 템플릿·공휴일

1. 시트 템플릿 → refresh로 시스템 템플릿 name·category·active·groupId·slug·sortOrder·description·수정 시각을 봅니다. 일반 조직 템플릿은 여기서 관리하지 않으며 템플릿 생성·레이아웃/수식 편집·삭제·정렬 변경 컨트롤도 없습니다.
2. category 셀에 분류를 입력하거나 인사/급여/근태/기타 및 현재 목록의 추천값을 선택합니다. Enter 또는 다른 곳 클릭으로 저장합니다. 앞뒤 공백을 정리하며 빈 값은 null로 지우고 조직 추천 템플릿의 기타 분류로 돌아갑니다. Esc는 이전 값으로 돌리고 빠져나옵니다.
3. active를 누르면 즉시 표시를 바꾸고 서버에 저장합니다. off는 조직의 추천 템플릿 선택기에서 숨기는 것이며 기존 데이터/레이아웃 삭제가 아닙니다. 분류/활성 저장 실패는 로컬 값을 되돌리고 상단 오류를 보여 줍니다. 조직 화면에서 다시 추천 목록을 열어 반영을 확인합니다. 여러 서버에서는 앞서 적은 대상 인자 누락으로 저장이 거절될 수 있습니다.
4. 공휴일 → refresh에서 연도별 휴일 수·API 동기화분·마지막 갱신을 확인합니다. 각 행 보기는 날짜·이름 목록을 펼치고 닫기는 접습니다. 서버 조회 허용 연도는 2000~2100입니다. 멀티 서버 목록은 첫 성공 서버의 연도 현황만 표시하며 전체 서버 합계가 아닙니다.
5. **동기화 (작년·올해·내년)**는 DATA_GO_KR_SERVICE_KEY가 구성되어야 활성화됩니다. 버튼을 누르면 세 연도 특일정보를 가져와 신규·갱신·제외 건수를 표시하고 상태와 열려 있던 연도를 재조회합니다. 동기화는 신규 삽입·이름 갱신·삭제된 날짜 복원·API에서 빠진 날짜의 논리 삭제를 수행하며, 응답이 빈 연도는 기존 날짜를 지우지 않습니다. 데이터 원천은 해당 서버의 공통 NationalHoliday이며 연차 판정에 사용됩니다. 근태·연장근무 분류와 프런트 달력에는 아직 정적 휴일을 사용하는 소비처가 남아 있어 모든 화면이 같은 표를 읽는다고 보장하지 않습니다. 특정 연도 입력이나 휴일 수동 CRUD는 UI에 없습니다.
6. 동기화 실패는 상단 오류이며 목록을 재조회합니다. 설정 안내의 자동 동기화와 수동 버튼 실행 결과는 다릅니다. 서버 오류의 과거 문구에 정적 폴백이 언급되어도 현재 가이드는 동기화된 표를 정본으로 설명하므로 오류 문구만으로 대체 휴일이 있다고 추정하지 않습니다. 멀티 서버의 상세/동기화 대상 인자 누락과 부분 실패는 운영 확인 대상입니다.

저장 경계·재진입·검증 근거

일반 조직 앱의 SDK 서비스 대신 이 콘솔은 fetch('/api/...')를 사용합니다. 콘솔은 DB에 직접 연결하지 않고 서버별 계정 토큰으로 대상 tRPC를 호출합니다. 시스템 변경 API는 recordOperatorAction/recordSystemWrite 경로를 사용하며, 콘솔의 발견 레지스트리와 암호화 자격증명은 별도 로컬 저장소입니다. 모든 조회·모든 CS 동작이 하나의 중앙 감사 화면에 기록·표시된다고 보장하지 않습니다.

근거	유지보수 연결
앱 상태·모든 핸들러, 뷰	메뉴·기본값·UI에 없는 조작·대상 서버 전달
서버 로그인·라우트, IP 필터	별도 콘솔 세션과 API 세션 경계
콘솔 REST, 단일 대상 호출, 세션	서버별 요청·부분 실패·자격증명 재인증
플랫폼 API, 프로비저닝 서비스	검증·계정/조직/역할 생성·저장·삭제·감사
CS API, 전이 서비스, 스키마	첨부·상태 전이·코멘트·알림·재오픈 한계

새로고침은 토큰을 확인하고 해시 탭의 로더를 실행합니다. 유효 탭 해시와 조직의 두 부분 참조를 복원하지만 개별 모달·검색조건·작성 중 입력을 복원하지 않습니다. 뒤로/앞으로는 탭 변경 시 데이터를 다시 읽습니다. 잘못된 조직 상세 참조는 오류를 내고 목록으로 돌아갑니다. 신규 로그인 직후에는 해시를 다시 복원하는 호출이 없으므로 저장된 토큰 재진입과 똑같은 이동을 보장하지 않습니다.

목록 fan-out은 연결 성공 서버만 합칩니다. CS는 빠진 서버 경고를 표시하지만 조직·세콤·시트 템플릿 등은 응답의 부분 실패 메타데이터를 UI에서 모두 보여 주지 않습니다. 데이터 0건과 서버 미연결을 엔드포인트 상태로 교차 확인해야 합니다. 버튼마다 중복 제출 가드가 동일하지 않으며 성공 토스트가 없는 변경도 많습니다. 오류 후에는 목록/상세를 새로 조회해 실제 상태를 확인한 다음 재시도합니다.

기존 기록 정합화와 남은 화면 증거

HBSA000의 7~8월 접근 실패 기록, 재설계 기록, 법정공제 모니터 검토안, 8월 LNB 설명과 기존 앱 소개를 현재 코드와 대조했습니다. 접속 실패 기록으로 서비스의 가용 상태를 단정하지 않습니다. 9개 메뉴·API 경유·Account 운영자 로그인은 현행 구현, AI 모니터는 아래 절에서 현행 소스와 대조했으며, 법정공제 모니터·중앙 릴리스·도입 실행 기록은 별도 확인 범위입니다. 기존 앱 소개의 세 화면만 있다는 인상, 전 조직 동시 근태/상태 필터, 새 관리자 비밀번호 강제 변경 설명을 바로잡았습니다.

재사용 가능한 시스템 관리자 실제 화면 캡처는 조사한 가이드·설계 문서·이미지 경로에서 찾지 못했습니다. 다른 앱의 화면이나 시안 이미지를 이 콘솔의 증거로 넣지 않았습니다. 다음을 허용된 테스트 환경에서 번호를 붙인 실제 화면으로 확보해야 합니다.

• 단일/복수 엔드포인트 연결·부분 실패, 동일 조직 ID의 서버별 상세와 새로고침.
• 프로비저닝 입력→실제 결과 역할/권한→신규 계정 로그인, 관리자 이메일/비밀번호 변경 후 Account와 Employee 값.
• 조직 상태·정책/AI 저장 후 재열기, 조직 삭제의 다른 소속 owner 보존, 마지막 관리자·역할 삭제 거절.
• 근태·세콤·연동·시트·공휴일의 다중 서버 거절 및 단일 서버 저장/재진입, 연동 시크릿 재발급 전후 웹훅.
• CS 로그·첨부 실패, 상태 전이·중복 지정·재오픈 거절, 내부/회신의 실제 노출과 알림, 서버별 30건 초과 목록.
• 스태프 역할 해제 후 grant 접근 종료, 시트 분류·활성의 조직 추천 목록 반영, 공휴일 동기화 결과와 재실행.

이번 작업은 문서 정합화이며 위 저장·권한·수신·외부 서비스 동작 검증과 새 캡처는 미완료입니다. 확인된 코드 제한은 수정하지 않았습니다.

로그인 유지와 접속 관리

대상	시작 위치	필요한 조건
시스템 운영자 본인	로그인 화면의 「로그인 상태 유지」, 로그인된 브라우저 관리 창	독립 운영자 계정·허용 네트워크·인증 완료

로그인 상태 유지를 선택한 뒤 기존 인증 절차를 완료합니다. 브라우저 관리 창에서 현재 브라우저·인증 방식·최근 활동·만료를 확인하고, 다른 접속은 「로그아웃」, 현재 접속은 「이 브라우저 로그아웃」으로 종료합니다. 유휴 만료 전 경고가 표시되면 작업 지속 여부를 결정하고, 만료되면 로그인 화면으로 돌아갑니다. 영구 접속이나 MFA 생략으로 설명하지 않습니다. session-watch.ts, views/modals/sessions.html, server/routes/auth-session.ts와 PR #825·#841을 대조했습니다. 운영 세션을 실제로 종료하는 검증은 하지 않았습니다.

AI 사용량·대화·오류 조사

1. 「AI 모니터링」에서 접근 가능한 엔드포인트와 조직을 고릅니다. 조직을 고르면 최근 30일 요약을 불러옵니다.
2. 시작·종료일 또는 7일·30일·90일을 선택하고 「조회」합니다. 기간과 표시 시각은 선택한 조직의 시간대를 따릅니다.
3. 요약에서 조직 AI 설정과 사용량·품질 지표를 확인하고, 대화·오류 보기에서 대상 항목을 엽니다. 실패한 응답은 오류 코드·제공자 상태·요청 식별자로 조사합니다.
4. CS 리포트의 AI 대화 연결로 관련 대화를 열 수 있습니다. 읽기 권한이 없는 엔드포인트는 조회 대상에서 제한되고 조사 조회는 감사 기록에 남습니다. 잘못된 조직으로 전환하지 않았는지 확인합니다.

PR #863, tools/system-admin/src/views/tabs/ai-monitor.html, packages/api/src/services/system-admin-ai.service.ts가 근거입니다. 가상 운영 DB·조직 연결·AI 실패 대화가 준비된 환경에서 대화 내용과 권한 제한을 별도로 검증해야 합니다. 사용자 가이드에서 이 운영 페이지로 이동하도록 연결하지 않습니다.

지문 예제 자료와 근태 재계산

등록된 근무 기준 테스트 케이스에서 조직·직원·기간·시나리오를 선택하고 미리보기를 확인한 뒤 「이 계획대로 생성」합니다. 같은 seed는 동일 예제 계획을 재현하기 위한 값이며, 실제 근태 화면에도 영향을 주므로 운영 고객 자료에 시험 생성하지 않습니다.

지문 기록 목록에서 원본 코드·출처·최종 변경 시각을 확인한 뒤 「수정」합니다. 원래 선택된 코드와 시간대가 유지되는지 확인하고 사유를 남깁니다. 「수정 뒤 근태 재계산」 여부에 따라 후속 결과를 대조합니다. 삭제는 개별 「삭제」 또는 선택 삭제 후 확인하며, 기록을 남기고 연결된 자동 근태를 다시 계산합니다. 「삭제된 기록 보기」로 삭제 흔적을 확인합니다. 재계산 버튼과 삭제는 같은 동작이 아닙니다. 수동 근태 및 삭제할 수 없는 원천의 제한은 서비스 검사를 따라야 합니다.

PR #835·#838·#839·#842·#844와 views/tabs/secom-events.html을 대조했습니다. 고객 지문·근태 자료로 생성·수정·삭제를 실행하지 않았으며, 운영 콘솔 영상은 전용 가상 운영 환경이 필요합니다.

조직 목록·앱 버전·CS 이동

조직 목록은 검색·페이지 이동으로 조회합니다. 페이지를 바꾸기 전 현재 검색 조건과 엔드포인트를 확인합니다. 앱 버전도 페이지 단위로 확인하며 업로드 후보의 조회 최적화가 버전 게시 성공을 뜻하지 않습니다. PR #854·#866·#871이 관련됩니다.

CS 상세 링크는 대상 리포트를 바로 여는 용도입니다. 로그인과 조회 권한이 필요하고 상태 변경 창은 현재 상태에서 시작합니다. 「배포 대기」는 개발 처리 후 배포를 기다리는 상태이므로 사용자에게 반영 완료로 안내하지 않습니다. PR #799·#855를 대조했습니다. 회신 발송·실제 앱 버전 게시·배포 완료 검증은 이 문서 작업에서 수행하지 않았습니다.

권한 보정·문서 안내·AI 신고 연결

운영 콘솔의 시스템 역할에 추가 권한을 지정하면 기본 역할 정의와 별도의 보정 내역으로 관리됩니다. 대상 조직·역할·추가 권한을 확인하고 저장한 뒤 실제 역할의 권한 목록을 다시 읽습니다. 기본 권한 목록 동기화와 개별 조직 보정을 혼동하지 않습니다.

조직별 문서 기반 AI 안내를 켜거나 끄는 설정이 추가됐습니다. 조직의 AI 사용 여부·권한과 검색 자료 준비가 함께 필요하며 설정 저장만으로 문서 검색이 검증되지는 않습니다. AI 정보가 첨부된 불편 신고에서는 관련 대화 모니터링 화면으로 이동합니다. 직원 앱 AI는 본문을 노출하지 않는 정책을 유지합니다.

접속 지점 식별자 동기화, 계정 잠금 시 대기 안내, 접속·활성 사용자 측정 신호도 변경됐습니다. PR #904·#909·#915·#918·#990·#992·#996·#1000·#1015·#1023의 소스를 확인했습니다. 실제 운영 콘솔 로그인·권한 저장·검색·신고 대화 이동은 로컬 촬영 환경에 구성하지 않아 미검증입니다.