# 장헌 B안 실제 착수 체크리스트

## 목적

이 문서는 장헌 레거시 서비스의 `B안 = PHP 8 전환 + 리눅스 이관 + Smarty 업그레이드 검토`를 실제 작업 단계로 풀어낸 착수 체크리스트다.

이번 문서의 목적은 아래 두 가지다.

- 조사/검토 메모를 실제 실행 순서로 전환
- 큰 범위의 레거시 전환 작업에서 선행조건, 우선순위, 검증 단계를 고정

## B안의 전제

| 항목 | 현재 기준 |
| --- | --- |
| 현재 운영 PHP | 5.2.12 |
| 현재 운영 DB | MySQL 5.1.41 계열 |
| 현재 템플릿 엔진 | Smarty 2.6 |
| B안 목표 | PHP 8 계열 + Linux + Docker 기준으로 재구성 |
| Smarty 방향 | `Smarty 2.6 유지`가 아니라 `상위 버전 업그레이드`를 함께 검토 |

## 핵심 판단

| 항목 | 판단 |
| --- | --- |
| PHP 8 전환만 단독 진행 | 불충분 |
| Smarty 업그레이드 필요성 | 높음 |
| 권장 Smarty 목표 버전 | 1차는 `Smarty 4.x` |
| DB도 함께 영향 받는가 | 예 |
| 리눅스 이관과 원인 분리 가능성 | 낮음, 단계 분리가 필요 |

## 착수 전 확보물

아래 항목이 확보되어야 B안의 실제 작업이 가능하다.

| 구분 | 확보 상태 | 비고 |
| --- | --- | --- |
| 운영 DB dump | 확보 | `hanmacerp` 확보됨 |
| 운영 원본 압축 | 확보 | `app/APM_Setup.zip` 반입됨 |
| 주요 설정 파일 | 확보 | `SmartyConfig.php`, `php222.ini`, `httpd.conf` 등 |
| DB 연결 파일 | 일부 확보 | `dbcon*.inc` 추가 확인 필요 |
| 실제 운영 템플릿 | 확보 | 압축본 내부에 대량 존재 |

## 0단계: 범위 고정

### 해야 할 일

| 항목 | 내용 |
| --- | --- |
| 운영본 선별 | `old`, `new`, `test`, 날짜 백업 폴더를 운영본과 분리 |
| 서비스 범위 고정 | `intranet`, `factory_mng`, `person_mng`, `projt_mng`, `account` 우선 |
| 공통 의존성 고정 | `Smarty`, `Smarty2.6`, `apiLibrary` |
| 저장소 고정 | `*_file`, `erpphoto`, `log`, `temp` |

### 완료 기준

- B안 분석 및 수정 대상이 되는 실제 운영본 경로가 확정됨

## 1단계: PHP 8 치명 이슈 전수 스캔

### 우선 스캔 대상

| 구분 | 대표 이슈 |
| --- | --- |
| DB API | `mysql_*` |
| 문자열/정규식 | `split`, `ereg` |
| 구형 설정 의존 | `short_open_tag`, `magic_quotes_gpc`, `register_globals` |
| 구형 문법 | PHP 8에서 경고/오류가 되는 호출 방식 |
| 파일 경로 | Windows 절대경로, 상대경로 의존 |

### 완료 기준

- 치명 오류 우선순위 목록 작성
- “무조건 먼저 고쳐야 하는 항목”과 “후순위 항목” 분리

## 2단계: DB 계층 전환 설계

### 해야 할 일

| 항목 | 내용 |
| --- | --- |
| 기본 DB 연결 구조 파악 | `DB_*`, `SECURITY_DB_*`, `SPATIAL_DB_*`, `HM_DB_*` 분리 |
| `mysql_*` 제거 계획 | `mysqli` 또는 `PDO` 기준 결정 |
| 뷰/루틴/권한 문제 파악 | 덤프 및 실제 운영 뷰 오류 이슈 정리 |
| MySQL 상향 영향도 파악 | 예약어, strict mode, 문자셋, 구문 차이 확인 |

### 완료 기준

- DB 연결 계층 전환 원칙 확정
- 공통 DB 래퍼/헬퍼 작성 방향 결정

## 3단계: Smarty 업그레이드 설계

### 권장 원칙

| 항목 | 권장안 |
| --- | --- |
| 목표 버전 | `Smarty 4.x` |
| 이유 | PHP 8 대응 현실성이 높고, v5보다 변화량이 상대적으로 작음 |
| 기존 `templates_c` | 폐기 후 재생성 |
| 기존 `cache` | 폐기 후 재생성 |
| 백업/파생 템플릿 | 운영본과 분리 후 제외 |

### 조사할 항목

| 항목 | 이유 |
| --- | --- |
| 실제 사용 템플릿 범위 | 수천 개 템플릿 전체를 다 건드리지 않기 위해 |
| 커스텀 플러그인 사용 여부 | Smarty 상향 시 장애 지점이 되기 쉬움 |
| `assign`, `display`, `fetch` 흐름 | PHP 쪽 엔진 연동부 재구성 필요 |
| 금지/제거 태그 사용 여부 | `{php}`, `{include_php}`, `{insert}` 등 |

### 완료 기준

- Smarty 2.6 → 4.x 전환 위험 목록 작성
- 실제 변환 대상 템플릿 범위 축소

## 4단계: Linux/Docker 기준 구조 재설계

### 해야 할 일

| 항목 | 내용 |
| --- | --- |
| 웹루트 재구성 | `/var/www/html` 기준 배치 |
| 업로드/로그/캐시 분리 | 볼륨 구조 설계 |
| PHP 8 컨테이너 구조 | Apache 유지 또는 별도 구조 검토 |
| DB 컨테이너 구조 | 운영 dump 기반 기동 |
| 환경변수화 | 경로/호스트/계정/저장소 경로 치환 |

### 완료 기준

- Linux + Docker 기준의 B안 최종 구조도 작성

## 5단계: 코드 전환 착수

### 우선순위

| 우선순위 | 작업 영역 |
| --- | --- |
| 1 | 공통 DB 연결 계층 |
| 2 | 로그인 진입부 |
| 3 | 공통 함수/공통 include |
| 4 | Smarty 초기화부 |
| 5 | 서비스별 대표 기능 |

### 원칙

- 한 번에 전 서비스 전체를 다 바꾸지 않는다.
- 공통부 → 진입부 → 서비스별 핵심 기능 순으로 간다.
- 한 서비스에서 성공한 패턴을 다른 서비스로 확장한다.

## 6단계: 서비스별 회귀 테스트

### 최소 확인 항목

| 서비스 | 최소 확인 항목 |
| --- | --- |
| intranet | 로그인, 메인, 결재/조직/기본 게시물 진입 |
| factory_mng | 로그인, 메인, 업로드/현황 화면 |
| person_mng | 로그인, 메인, 인사/연차 관련 대표 화면 |
| projt_mng | 로그인, 대표 조회/출력 화면 |
| account | 로그인, 메인, 월별 로그/조회 화면 |

### 공통 확인 항목

| 항목 | 내용 |
| --- | --- |
| 템플릿 렌더링 | 화면 깨짐, 변수 미할당, 경고 출력 여부 |
| 저장소 | 첨부/사진/다운로드/로그 기록 여부 |
| 한글/인코딩 | 데이터 깨짐 여부 |
| 세션/쿠키 | 로그인 유지 여부 |
| 공통 수정 영향 | 한 서비스 수정이 다른 서비스에 영향 주는지 |

## 7단계: 안정화

### 해야 할 일

| 항목 | 내용 |
| --- | --- |
| 오류 반복 수정 | 서비스별 반복 장애 처리 |
| 공통 코드 정리 | 임시 패치 제거, 재사용 패턴 정리 |
| 문서화 | 실제 변경점, 우회사항, 미해결 이슈 기록 |
| 재배포 검증 | 컨테이너 재기동 후 동일 동작 확인 |

## B안 착수 우선순위 한줄 요약

1. 운영본 범위 고정
2. PHP 8 치명 이슈 스캔
3. DB 계층 전환 설계
4. Smarty 4.x 업그레이드 설계
5. Docker/Linux 구조 재설계
6. 공통부부터 순차 수정
7. 서비스별 회귀 테스트와 안정화

## 현재 기준 권장 메모

`B안`은 가능하지만, 실제로는 `PHP 8 전환 프로젝트 + Smarty 업그레이드 프로젝트 + Linux 이관 프로젝트`가 합쳐진 성격이다.  
따라서 착수 전 체크리스트와 작업 규칙을 먼저 고정하는 것이 필수다.