MyDoc/장헌 레거시 리눅스 전환 검토.md

장헌 레거시 리눅스 전환 검토

작성 목적

장헌 레거시 서비스의 리눅스 전환 방향을 간단명료하게 정리한다.

이번 판단의 핵심은 아래 두 가지 방식 비교다.

1. 방식 A. 현재 운영 재현 우선
2. 방식 B. PHP 8.x 전환과 리눅스 이관 동시 진행

현재 확인된 운영 기준

항목	현재 운영 기준
웹서버	Apache 2.2.14
PHP	PHP 5.2.12
DB	MySQL 5.1.41 계열
템플릿	Smarty 2.6
운영 루트	D:\APM_Setup\htdocs
주요 의존성	mysql_*, short open tag, Windows 절대경로, 업로드/로그 파일 경로

빠른 결론

항목	결론
1차 권장안	방식 A. 현재 운영 재현 우선
이유	여러 서비스가 한 통합 웹루트에 얽혀 있어, 먼저 리눅스에서 현재 운영을 재현하는 것이 가장 안전함
PHP 8 전환	필요성은 인정되나, 1차 리눅스 이관과 동시 진행 시 범위와 리스크가 크게 증가
웹서버 방향	1차는 Apache 유지, 2차에서 필요 시 Nginx 검토
일정 판단	단일 서비스 이관보다 전환 후 확인/안정화 범위가 훨씬 커서 실제 현업 소요 증가 가능성이 큼

한줄 결론

현재 장헌 레거시의 리눅스 전환은 여러 서비스가 동시에 얽힌 통합 전환 작업이므로, 먼저 PHP 5.2 운영 재현으로 전체 서비스 연속성을 확보하고, 이후 충분한 안정화와 서비스별 검증을 거쳐 PHP 8 전환을 2차 과제로 분리하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.

이번 전환 작업의 성격

이번 작업은 단일 서비스 1개를 옮기는 작업이 아니다.
하나의 통합 웹루트 안에서 여러 업무 서비스가 동시에 전환되는 작업이다.

구분	내용
핵심 서비스	intranet, factory_mng, person_mng, projt_mng, account
공통 의존성	Smarty, Smarty2.6, apiLibrary
공통 저장소	factory_file, intranet_file, person_file, proj_file, projt_file, erpphoto
의미	한 서비스만 구동되면 끝나는 것이 아니라, 여러 서비스와 공통 자산이 함께 정상 동작해야 함

따라서 전환 직후에도 서비스별 진입, 공통 템플릿, 첨부/이미지, 로그/저장소 동작을 각각 확인해야 한다.

방식 비교

구분	방식 A. 현재 운영 재현 우선	방식 B. PHP 8.x 전환 + 리눅스 이관 동시 진행
목표	리눅스에서 현재 운영과 최대한 유사하게 먼저 구동	리눅스 이관과 동시에 최신 PHP 계열로 구조 전환
핵심 전략	낮은 버전 호환을 최대한 유지한 채 Docker로 재현	코드/DB/설정을 PHP 8 기준으로 먼저 수정 후 이관
장점	가장 빠르게 운영 재현 가능, 원인 분리 쉬움	장기적으로 유지보수성/보안성 개선 가능
단점	기술부채를 잠시 유지함	초기 범위와 리스크가 크게 증가
장애 분석 난이도	비교적 낮음	높음
현재 상황 적합성	매우 높음	중장기 과제로는 적합, 즉시 재현 목표에는 부담 큼

방식 A 설명

핵심 개념

방식 A는 구버전 운영 구조를 그대로 리눅스로 옮기는 것이 아니라,
운영 동작 방식은 최대한 유지하고 실행 환경만 Linux + Docker로 재구성하는 전략이다.

스택 전환 개념

구분	현재 운영	방식 A 목표
OS	Windows	Linux
웹서버	Apache 2.2.14 on APMSETUP	Apache on Docker container
PHP	PHP 5.2.12	PHP 5.2 호환성 최대 유지
DB	MySQL 5.1.41 계열	Docker 안 DB 또는 호환 DB로 재현
템플릿	Smarty 2.6	그대로 유지
웹루트	D:\APM_Setup\htdocs	예: /var/www/html
임시업로드	D:\APM_Setup\temp	예: /var/www/tmp/uploads
파일저장소	*_file, erpphoto, log	Docker volume 또는 리눅스 디렉터리로 매핑

실제 작업 내용

단계	작업 내용
1	운영 원본 소스와 저장소 반입
2	D:\APM_Setup\htdocs 기준 폴더를 app/htdocs에 재배치
3	dbcon*.inc, SmartyConfig.php, 업로드/로그 경로 치환
4	DB dump import
5	Docker에서 웹/DB 동시 기동
6	로그인, 메인 화면, 첨부, 이미지, 템플릿 렌더링 확인

전환 후 확인 범위

구분	확인 내용
서비스별 진입	intranet, factory_mng, person_mng, projt_mng, account 로그인/메인 진입
공통 템플릿	Smarty, Smarty2.6 렌더링 오류 여부
저장소	*_file, erpphoto, log, temp 읽기/쓰기 여부
업로드/다운로드	첨부, 사진, 다운로드, 업로드 동작 여부
공통 영향	공통 설정 수정이 다른 서비스에 부작용을 주지 않는지 확인

즉, A방식이라도 전환 후 안정화와 서비스별 확인량은 상당히 크다.

예상 소요시간

시간은 아래 두 기준으로 본다.

• Codex 순수 작업시간: 문서화, 설정편집, 스크립트정리, 오류분석 중심
• 현업 총 소요시간: 운영자료 확보, 담당자 확인, 실제 기동 검증, 반복 보정 포함

단계	Codex 순수 작업시간	현업 총 소요시간
원본 구조 분석 및 반입 기준 정리	2시간 ~ 4시간	0.5일 ~ 1일
경로/설정/볼륨 치환	3시간 ~ 6시간	1일 ~ 2일
DB import 절차 정리 및 기동 보정	2시간 ~ 5시간	0.5일 ~ 1일
대표 기능 기준 검증/오류 분석	4시간 ~ 10시간	1일 ~ 3일
합계	약 1일 ~ 3일	약 3일 ~ 7일

단, 이번 건은 다중 서비스 동시 전환이므로 실제 확인 대상이 늘어나면 현업 총 소요시간은 5일 ~ 10일 이상으로 늘어날 가능성도 있다.

방식 B 설명

핵심 개념

방식 B는 리눅스 이관과 동시에 PHP 8.x 기준으로 코드와 DB 호환성을 함께 정리하는 전략이다.

실제로 해야 하는 일

단계	작업 내용
1	기존 운영본 전체 분석
2	mysql_* 전부 mysqli 또는 PDO로 교체
3	split, ereg, 구식 전역 변수/호출 관행 제거
4	short open tag, magic_quotes_gpc, register_globals 의존 제거
5	Smarty 2.6 호환성 점검 또는 상향
6	DB SQL 문법, 문자셋, 예약어 충돌, strict mode 문제 수정
7	Windows 경로, 파일 권한, 업로드 로직 전면 점검
8	PHP 8 기준 테스트와 기능 회귀 검증

대표 리스크

구분	예상 이슈
DB API	mysql_connect, mysql_query, mysql_result 제거됨
문자열/정규식	split, ereg 계열 제거 또는 비권장
전역 변수 관행	register_globals 의존 코드 오동작 가능
입력 처리	magic_quotes_gpc 제거로 escaping 흐름 변경 필요
템플릿	Smarty 2.6와 최신 PHP 조합 호환성 이슈 가능
경고 수준	PHP 8에서 경고가 치명 오류로 바뀌는 구간 다수 가능
공통 영향	공통 함수/공통 템플릿 수정이 여러 서비스에 동시에 영향
안정화	한 서비스 수정 후 다른 서비스에서 새 오류가 다시 나올 수 있음

예상 소요시간

단계	Codex 순수 작업시간	현업 총 소요시간
전수 분석 및 영향도 파악	1일 ~ 2일	2일 ~ 5일
PHP 8 호환 코드 수정	3일 ~ 8일	5일 ~ 15일
DB/뷰/SQL 호환성 수정	1일 ~ 4일	2일 ~ 7일
템플릿/업로드/로그/파일 경로 수정	1일 ~ 3일	2일 ~ 5일
통합 테스트/회귀 테스트	1일 ~ 4일	3일 ~ 10일
합계	약 7일 ~ 21일	약 14일 ~ 42일 이상

레거시 크기와 미확인 모듈 수, 다중 서비스 동시 전환 특성을 고려하면 실제로는 더 길어질 가능성이 있다.

PHP 8 전환에 대한 판단

항목	판단
장기 유지보수	PHP 8 전환 방향은 타당함
보안/지원 종료	구버전 PHP 유지에는 한계가 있음
리눅스 호환성 자체	PHP 8이어서 리눅스와 잘 맞는 것이 아니라, 코드가 최신 PHP에 맞게 수정되어야 함
즉시 운영 재현 목표와의 적합성	낮음

즉, 리눅스 이관 = PHP 8 필수는 아니다.
정확히는 PHP 8 전환은 별도 대형 개편 과제에 가깝다.

A방식에서 Apache를 유지하는 이유

현재 운영은 Apache 2.2.14 + PHP 5.2.12 기반이다.
따라서 A방식은 웹서버를 제거하는 것이 아니라, 윈도우 APMSETUP의 Apache 역할을 리눅스 컨테이너 안 Apache로 옮겨 재현하는 방식이다.

항목	Apache 유지	Nginx 전환
현재 운영 유사성	높음	낮음
초기 리눅스 재현 난이도	낮음	중간 ~ 높음
장애 원인 분석 난이도	낮음	높음
구형 PHP 5.2 계열과의 궁합	상대적으로 유리	별도 FastCGI/FPM 구성 필요
rewrite/경로 처리 차이	적음	직접 재작성 가능성 큼
1차 목표 적합성	매우 높음	낮음

즉, Nginx 전환은 불가능한 것이 아니라 지금 1차 목표인 운영 재현 단계에서는 리스크를 추가하는 선택으로 보는 편이 타당하다.

최종 권장안

항목	권장안
단기 목표	방식 A 채택
중기 목표	방식 A 성공 후 방식 B 별도 계획 수립
보고 메시지	먼저 다중 서비스 운영 재현으로 서비스 연속성을 확보하고, 이후 충분한 안정화와 서비스별 검증을 거쳐 PHP 8 전환을 2차 과제로 분리