kevin/MyDoc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
MyDoc/장헌 레거시 리눅스전환 검토/장헌 B안 심화 검토.md
T

7.2 KiB
Raw Permalink Blame History

장헌 B안 심화 검토 메모

목적

이 문서는 B안 = PHP 8 전환 + 리눅스 이관을 더 심도 있게 검토하기 위한 메모다.

특히 이번 검토에서는 아래를 함께 본다.

  • PHP 8 전환 가능성
  • Smarty 2.6 업그레이드 필요성
  • 실제 장헌 압축본 안의 Smarty 자산 규모
  • 현실적인 업그레이드 순서

현재 전제

항목 현재 확인 기준
현재 PHP 5.2.12
현재 DB MySQL 5.1.41 계열
현재 템플릿 엔진 Smarty 2.6
현재 웹서버 Apache 2.2.14
현재 목표 리눅스 이관 검토와 병행한 B안 가능성 분석

공식 Smarty 자료 기준 핵심 사실

공식 Smarty 다운로드/업그레이드 문서 기준으로 아래가 확인된다.

항목 공식 기준
Smarty 2.x PHP 4 또는 5
Smarty 3.x PHP 5.2+
Smarty 4.x PHP 7.1+
Smarty 5.x PHP 7.2+
PHP 8 공식 지원 관점 Smarty 4.x부터 본격 대응으로 보는 것이 자연스러움

또한 공식 업그레이드 문서 기준으로 아래 변화가 중요하다.

업그레이드 구간 공식 문서상 핵심 변화
v3 -> v4 PHP 8 지원, ASP tags 제거, {php}/{include_php} 제거, 일부 구 API 제거
v4 -> v5 네임스페이스 도입, 더 많은 API/상수 제거, 커스텀 플러그인 점검 필요

장헌 압축본에서 확인된 Smarty 자산 규모

app/APM_Setup.zip 내부를 직접 풀지 않고 목록 기준으로 확인한 결과다.

항목 확인 내용
전체 .tpl 파일 수 약 3,141개
APM_Setup/htdocs/Smarty/ 하위 항목 수 약 3,685개
APM_Setup/htdocs/Smarty2.6/ 하위 항목 수 약 186개
Smarty/templates_c 산출물 수 약 336개
백업/파생 템플릿 흔적 매우 많음

즉, 이번 Smarty 업그레이드는 라이브러리 교체 1건이 아니라, 수천 개 템플릿과 다량의 백업/파생 자산을 가진 대형 정리 작업으로 보는 것이 맞다.

지금까지 확인된 실제 템플릿 특성

압축본 내부 템플릿 파일(.tpl)을 대상으로 빠른 스캔한 결과:

항목 현재 확인 결과
{php} 템플릿 파일에서는 미검출
{include_php} 템플릿 파일에서는 미검출
{insert} 템플릿 파일에서는 미검출
{block}/{extends} 템플릿 파일에서는 미검출
ASP 스타일 태그(<% %>) 템플릿 파일에서는 미검출

이 결과는 긍정적이다.
즉, 템플릿 문법 자체가 아주 최신 기능이나 아주 금지된 구문에 심하게 묶여 있지는 않을 가능성이 있다.

다만 아래는 별도 주의가 필요하다.

항목 내용
Smarty/templates_c 기존 컴파일 산출물이라 업그레이드 후 재생성 필요
Smarty/cache 기존 캐시 산출물이라 업그레이드 후 재생성 필요
백업 템플릿 운영본과 혼재되어 있어 업그레이드 대상 선별이 필요
Smarty2.6/libs/plugins fetch, eval, popup, regex_replace 등 구 플러그인 흔적 존재

B안에서 Smarty 업그레이드가 왜 필요한가

항목 판단
PHP 8 + Smarty 2.6 매우 위험
이유 1 Smarty 2.x는 공식 기준상 PHP 4/5 세대
이유 2 PHP 8 호환성 보장이 없다
이유 3 라이브러리 내부 구현이 현대 PHP 오류/경고 정책과 충돌할 가능성이 높다

따라서 B안에서 PHP 8을 목표로 한다면 Smarty 2.6 유지는 현실성이 낮다.

어떤 Smarty 버전을 목표로 해야 하는가

선택지 비교

선택지 장점 단점 판단
Smarty 3.x 현재 2.6에서의 개념 차이가 상대적으로 작음 PHP 8 최종 기준으로는 애매함 중간 경유점으로는 가능
Smarty 4.x 공식 문서상 PHP 8 대응 관점에서 가장 현실적 일부 구 API/기능 제거 대응 필요 B안의 1차 목표 버전으로 가장 적절
Smarty 5.x 최신 구조 네임스페이스 등 추가 변화 큼 지금 단계에서는 과도함

현실적인 권장 경로

권장 결론

B안의 Smarty 목표는 4.x가 가장 현실적이다.

이유:

  • PHP 8 지원 관점이 분명함
  • v5보다 변화량이 작음
  • 공식 업그레이드 문서상 v3 -> v4는 상대적으로 이해 가능한 변화 범위 안에 있음

권장 진행 순서

단계 권장 내용
1 운영본에서 실제 사용 템플릿 범위를 먼저 선별
2 Smarty/templates_c, cache, 백업 템플릿을 운영본 범위에서 분리
3 PHP 코드의 mysql_*, split, ereg 등 PHP 8 치명 이슈부터 정리
4 Smarty 2.6 -> 4.x 전환 브랜치 구성
5 실제 템플릿 렌더링/assign/display 흐름 점검
6 커스텀 플러그인/레거시 modifier 사용 여부 점검
7 Linux + Docker 기준에서 통합 검증

B안에서 당장 조사해야 할 세부 항목

우선순위 조사 항목 이유
높음 실제 운영본 템플릿 범위 백업/테스트 템플릿 제외 필요
높음 SmartyConfig.php 사용 방식 라이브러리 경로/컴파일/캐시 경로 치환 필요
높음 Smarty 객체 생성 코드 assign, display, 공용 wrapper 구조 파악 필요
높음 커스텀 플러그인 사용 여부 Smarty 4 전환 시 가장 흔한 장애 지점
중간 templates_c 재생성 전략 기존 산출물 폐기 후 재컴파일 필요
중간 템플릿 내부 modifier/function 사용 패턴 PHP 8/Smarty 4에서 경고·예외 가능

예상 리스크

리스크 설명
템플릿 수가 많음 운영본만 선별하지 않으면 범위가 급격히 커짐
공통 템플릿 구조 하나의 공용 템플릿 수정이 여러 서비스에 동시 영향
구 플러그인 의존 fetch, eval, popup, regex_replace 등은 추가 검토 필요
컴파일 산출물 혼재 templates_c를 실제 소스처럼 오인하면 분석이 왜곡됨
PHP 8 + DB + Smarty 동시 변경 원인 분리 난이도 높음

최종 판단

항목 판단
B안 추진 가능성 가능
단, 전제 PHP 8 전환과 함께 Smarty 2.6 업그레이드를 사실상 필수 과제로 봐야 함
Smarty 목표 버전 4.x 권장
Smarty 5 바로 전환 현재 단계에서는 비권장
권장 방식 운영본 선별 -> PHP 8 치명 이슈 제거 -> Smarty 4 전환 -> Docker/Linux 검증

한줄 결론

B안을 진지하게 추진하려면, 장헌 레거시는 PHP 8 전환만이 아니라 Smarty 2.6 -> Smarty 4.x 업그레이드까지 포함한 다중 축 개편으로 봐야 하며, 실제 템플릿 수와 공통 의존성을 고려하면 운영본 범위를 엄격히 선별한 뒤 단계적으로 전환하는 것이 가장 현실적이다.

참고 자료

Reference in New Issue View Git Blame Copy Permalink