MyDoc/JH_ERP/장헌 레거시 리눅스 이관 방식 비교 메모./장헌 레거시 리눅스 이관 방식 비교 메모.md

장헌 레거시 리눅스 이관 방식 비교

작성 목적

장헌 레거시 서비스의 리눅스 전환 방향을 간단명료하게 설명하기 위함.

비교 대상은 아래 두 가지다.

1. 현재 운영 재현 우선
2. 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 절대경로, 업로드/로그 파일 경로

방식 비교 요약

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

방식 A 상세: 현재 운영 재현 우선

항목	내용
목적	리눅스 환경에서 현재 운영 서비스가 뜨는지 먼저 확인
PHP 방향	PHP 5.2.12 호환성 최대 유지
DB 방향	MySQL 5.1 계열 호환 기준 유지
코드 수정 범위	최소 수정만 수행
주 수정 대상	경로, DB 호스트, 업로드/로그/캐시 경로, 권한
기대 결과	로그인 페이지 및 대표 업무 화면이 리눅스 Docker에서 구동

방식 A에서 실제로 하는 일

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

방식 A 예상 소요시간

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

• Codex 순수 작업시간: 압축/덤프/판단 대기 시간을 제외하고, 제가 문서화/설정편집/스크립트정리/오류분석을 수행하는 순수 작업시간
• 현업 총 소요시간: 운영자료 확보, 담당자 확인, 압축 반입, DB dump, 실제 기동 검증, 반복 보정까지 포함한 전체 일정

단계	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일

위 시간은 운영본 압축, DB dump, 필수 저장소가 확보됐다는 전제의 대략치다.

방식 B 상세: PHP 8.x 전환 + 리눅스 이관 동시 진행

항목	내용
목적	리눅스 이관과 동시에 최신 PHP 계열로 올림
PHP 방향	PHP 8.x 기준으로 코드 전환
DB 방향	MySQL 5.1 계열 SQL/접속 패턴을 상위 버전에 맞게 검증
코드 수정 범위	광범위
기대 결과	리눅스 이관과 기술 현대화를 동시에 수행

방식 B에서 실제로 해야 하는 일

단계	작업 내용
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 기준 테스트와 기능 회귀 검증

PHP 8.x 전환 시 예상되는 대표 수정 포인트

구분	예상 이슈
DB API	mysql_connect, mysql_query, mysql_result 제거됨
문자열/정규식	split, ereg 계열 제거 또는 비권장
전역 변수 관행	register_globals 의존 코드 오동작 가능
입력 처리	magic_quotes_gpc 제거로 문자열 escaping 흐름 변경 필요
템플릿	Smarty 2.6와 최신 PHP 조합 호환성 이슈 가능
경고 수준	PHP 8에서 경고가 치명 오류로 바뀌는 구간 다수 가능
DB 서버	구버전 MySQL 문법/콜레이션/뷰/권한 이슈 가능

방식 B 예상 소요시간

이 역시 두 기준으로 나눠 본다.

단계	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가 지금은 부담이 되는가

구분	설명
런타임 구성 변경 증가	OS, Docker, 경로, DB, 웹서버를 한 번에 바꾸게 됨
PHP 연결 방식 차이	Nginx는 보통 php-fpm 계열을 별도로 붙여야 함
레거시 경로/요청 처리 차이	URL rewrite, 업로드, PATH_INFO, 헤더 전달 차이로 추가 장애 가능
원인 분리 어려움	장애 시 Apache 차이인지, PHP 차이인지, 리눅스 차이인지 바로 분리하기 어려움

권장 판단

단계	권장안
1차 리눅스 운영 재현	Apache 유지
2차 구조 개선	필요 시 Nginx 전환 검토

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

권장 판단

항목	권장안
단기 목표	방식 A 채택
중기 목표	방식 A 성공 후 방식 B 별도 계획 수립
보고 메시지	먼저 운영 재현으로 서비스 연속성을 확보하고, 이후 PHP 8 전환을 별도 단계로 추진

팀장 보고용 한줄 요약

현재 장헌 레거시의 리눅스 이관은 PHP 5.2 운영 재현과 PHP 8 전환을 분리해서 보는 것이 가장 안전하며, 먼저 리눅스에서 현재 운영을 재현한 뒤 PHP 8 전환을 2차 과제로 진행하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.