ITAM/docs/plans/PLAN_ASSET_HISTORY.md

자산 이력 누적 관리 시스템 (Cumulative Asset History System) 구현 계획

본 문서는 자산의 라이프사이클(조직, 사용자, 용도, 상태 변동)을 체계적으로 추적하고 누적 관리하기 위한 기술적 설계 및 단계별 구현 계획을 담고 있습니다.

1. 목적

• 자산 정보 수정 시 중요 변경 사항을 자동으로 감지하여 이력(Log)화
• 과거부터 현재까지의 변동 사항을 타임라인 형태로 시각화하여 자산 흐름 파악
• 데이터 정합성을 위해 서버 측에서 변경 전/후 스냅샷 비교 방식 채택

2. 관리 대상 이력 (Watch Fields)

다음 항목의 변경이 발생할 경우 이력을 자동 생성합니다.

1. 조직 변동: current_dept (현 사용조직) ↔ previous_dept 업데이트 포함
2. 사용자 변동: user_current (현 사용자) ↔ previous_user 업데이트 포함
3. 용도 변경: asset_type, current_role (예: 개인PC -> 공용PC)
4. 상태 변경: hw_status (예: 운영 -> 수리, 재고 -> 폐기 등)

3. 기술 설계 (Technical Design)

A. 데이터베이스 (DB)

• 대상 테이블: asset_history
• 컬럼 구조 활용 및 보완:
  • asset_id: 대상 자산 식별자
  • event_type: 변경 유형 (DEPT_CHANGE, USER_CHANGE, ROLE_CHANGE, STATUS_CHANGE)
  • details: "상태 변경: 운영 -> 수리" 와 같이 읽기 쉬운 문자열 저장
  • cost: 관련 비용 발생 시 기록 (수리비 등)
  • log_user: 변경을 수행한 작업자
  • log_date: 변경 발생 일시

B. 백엔드 (Server-side Logic)

• 위치: server.js 의 POST /api/asset/:category/save 엔드포인트
• 동작 흐름:
  1. Snapshot: 인서트/업데이트 수행 전, 기존 DB의 데이터를 SELECT하여 메모리에 저장.
  2. Comparison: 요청된 신규 데이터와 기존 데이터를 필드별로 대조.
  3. Auto-logging: 변경점이 발견되면 asset_history 테이블에 즉시 인서트.
  4. Transaction: 모든 로그 생성이 자산 저장과 하나의 트랜잭션으로 묶여야 함.

C. 프론트엔드 (UI/UX)

• 위치: HWModal.ts 우측 modal-history-area
• 개선 사항:
  • renderHistory() 함수를 고도화하여 이벤트 타입별 아이콘/컬러 적용.
  • "이전 값 ➔ 이후 값" 형태의 직관적인 레이아웃 도입.
  • 스크롤을 통한 무제한 누적 이력 조회 지원.

4. 단계별 구현 로직

1단계: 서버 로직 고도화

• server.js에 비교 함수(compareAndLog) 구현.
• 각 자산 카테고리별 저장 로직에 비교 로직 삽입.

2단계: DB 데이터 마이그레이션 (필요시)

• 기존 자산의 current_dept 등을 previous_dept로 밀어내는 로직 점검.

3단계: UI 타임라인 렌더링 개선

• modal.css에 이력 전용 스타일(이벤트 뱃지 등) 추가.
• HWModal.ts에서 최신 로그를 실시간으로 다시 불러오는 로직 확인.

5. 검증 계획

• 자동 감지 테스트: 상태 변경 후 저장 시 우측 이력에 즉시 한 줄이 추가되는지 확인.
• 다중 변경 테스트: 조직과 사용자를 동시에 변경했을 때 두 개의 로그가 생성되는지 확인.
• 데이터 무결성: 수정을 취소하거나 저장 실패 시 로그가 남지 않는지(Transaction) 확인.