# 자산 이력 누적 관리 시스템 (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) 확인.