# COMTNSYSLOG 7일 삭제정책 분리 분석노트 (#38)

> 문화품앗이 개인정보보호 기능개선 사업 (SFR-004 / DBR-001 / SER-002)
> 개발항목 #38 — 담당: Fork C | 작성일: 2026-07-21
> 목적: 기존 시스템로그(COMTNSYSLOG) 7일 삭제정책이 신규 개인정보 접속기록
>       (`PERSONAL_DATA_ACCESS_LOG`, 730일 보관)에 **오적용되지 않도록** 분리 상태를 진단·보강한다.

---

## 1. 기존 7일 삭제정책 실측 (파일:라인)

| 계층 | 위치 | 내용 |
|------|------|------|
| SQL(삭제문) | `src/main/resources/egovframework/sqlmap/com/sym/log/lgm/EgovSysLog_SQL_Mysql.xml:159~165` | `DELETE FROM COMTNSYSLOG WHERE OCCRRNC_DE < DATE_FORMAT(ADDDATE(SYSDATE(), -7), '%Y%m%d')` |
| DAO | `src/main/java/egovframework/com/sym/log/lgm/service/impl/SysLogDAO.java:47~50` | `logInsertSysLogSummary()` 내부에서 **요약 INSERT 직후 삭제 DELETE를 한 메서드로 묶어 호출** |
| Service | `.../service/impl/EgovSysLogServiceImpl.java:60~64` | `logInsertSysLogSummary()` 위임 |
| Scheduling | `.../service/EgovSysLogScheduling.java:36~38` | `sysLogSummary()` → 서비스 호출 |
| 스케줄 설정 | `src/main/resources/egovframework/spring/com/context-scheduling-sym-log-lgm.xml:6~28` | Quartz `MethodInvokingJobDetailFactoryBean`+`SimpleTriggerBean`(1시간 주기). **단, `SchedulerFactoryBean`(L22~28)은 주석 처리 → 현재 비활성** |
| 타 DB 동일본 | `EgovSysLog_SQL_{Oracle,Altibase,Cubrid,Tibero}.xml`의 동일 `SysLogDAO.logDeleteSysLogSummary` | MySQL과 동일 구조 |

**대상:** `COMTNSYSLOG` 단일 테이블. 삭제 기준 컬럼 `OCCRRNC_DE`(발생일자, `YYYYMMDD` 문자열). 보관 7일.
**주기:** 정의상 매 1시간(요약 배치에 종속) — 요약 INSERT가 실행될 때마다 7일 경과분 삭제.
**현재 활성 여부:** **비활성.** 트리거를 물고 있는 `SchedulerFactoryBean`이 주석 처리되어 스케줄러에 등록되지 않음(`context-scheduling-sym-log-lgm.xml:22~28`).

## 2. 개인정보 접속기록 오적용 위험 판정

**판정: 직접 오적용 위험 낮음(구조적 분리됨). 단, 결합 설계로 인한 잠재적 혼동 리스크 있음.**

- 삭제문이 테이블명 `COMTNSYSLOG`에 하드코딩되어 있어 `PERSONAL_DATA_ACCESS_LOG`를 물리적으로 건드릴 수 없다. namespace도 `SysLogDAO`로 분리되어 있다.
- 신규 접속기록의 유일한 삭제 경로는 **파티션 DROP 방식 730일 파기 배치(#37, Fork A 담당)**로 별도 설계되어, 개별 DELETE 및 7일 정책과 경로가 완전히 다르다.
- **다만 잠재 리스크 2가지:**
  1. **결합(coupling) 리스크** — 7일 DELETE가 `logInsertSysLogSummary()`(요약 INSERT)에 **묶여 있어**, 향후 이 메서드를 재사용·확장하는 개발자가 삭제 부작용을 인지하지 못할 수 있다. 요약과 파기는 관심사가 다르므로 분리가 바람직.
  2. **오해 리스크** — 신규 접속기록 보관/파기를 구현하며 기존 `SysLogDAO`/`EgovSysLog_SQL_*.xml`에 접속기록용 statement를 추가하면 두 로그 체계가 한 namespace에 섞여 7일 정책이 잘못 상속될 수 있다.

## 3. 분리 보강 권고

1. **namespace 절대 분리(필수):** 개인정보 접속기록 관련 SQL은 **절대** `SysLogDAO`/`EgovSysLog_SQL_*.xml`에 추가하지 않는다. 신규 `PrivacyAccessLog*`/전용 sqlmap namespace로만 관리한다. (Fork A #30/#37 산출물이 이미 별도 DDL/파일로 분리됨 — 이 원칙 유지.)
2. **`PERSONAL_DATA_ACCESS_LOG`에 UPDATE/DELETE statement 미정의(필수):** 애플리케이션 계층에 개별 DELETE를 만들지 않는다(위·변조 방지 + 보관정책 일원화). 유일 삭제 경로 = 파티션 DROP 파기 배치(#37).
3. **방어 주석 추가(권고):** `EgovSysLog_SQL_Mysql.xml`의 `logDeleteSysLogSummary` 및 `SysLogDAO.logInsertSysLogSummary()`에 "이 7일 삭제정책은 COMTNSYSLOG 전용이며 PERSONAL_DATA_ACCESS_LOG(730일)에 적용 금지" 주석을 남겨 혼동 차단. (본 노트는 진단 중심이라 소스 미수정 — 방어 주석은 후속 반영 권고.)
4. **요약/파기 분리(선택·개선):** 7일 삭제를 요약 INSERT 메서드에서 떼어 별도 메서드로 분리하면 결합 리스크 해소. 단 기존 동작 변경이므로 운영 영향 검토 후 진행.
5. **활성화 시 주의(운영):** 현재 시스템로그 요약/삭제 스케줄러가 비활성 상태다. 향후 활성화(`SchedulerFactoryBean` 주석 해제) 시 7일 삭제가 함께 켜지므로, 접속기록 파기 배치(#37)와 **주기·대상이 독립적으로 동작하는지** 재확인한다.

## 4. 결론

기존 7일 삭제정책은 `COMTNSYSLOG` 전용으로 물리·논리적으로 분리되어 있어 신규 접속기록에 직접 오적용될 위험은 낮으며, 현재 스케줄러 자체가 비활성이다. 다만 삭제가 요약 배치에 결합된 구조라 향후 혼동을 막기 위해 **① 접속기록 SQL의 namespace 절대 분리, ② 접속기록 DELETE statement 미정의, ③ 방어 주석**을 유지·반영할 것을 권고한다. 이 원칙은 Fork A의 #30(DDL)/#37(파티션 파기 배치) 산출물이 별도 파일·namespace로 이미 준수하고 있다.