장헌 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안 착수 우선순위 한줄 요약
- 운영본 범위 고정
- PHP 8 치명 이슈 스캔
- DB 계층 전환 설계
- Smarty 4.x 업그레이드 설계
- Docker/Linux 구조 재설계
- 공통부부터 순차 수정
- 서비스별 회귀 테스트와 안정화
현재 기준 권장 메모
B안은 가능하지만, 실제로는 PHP 8 전환 프로젝트 + Smarty 업그레이드 프로젝트 + Linux 이관 프로젝트가 합쳐진 성격이다.
따라서 착수 전 체크리스트와 작업 규칙을 먼저 고정하는 것이 필수다.
