MyDoc/장헌 레거시 리눅스전환 검토/장헌 레거시 리눅스 이관 방식 비교.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 절대경로, 업로드/로그 파일 경로

빠른 결론

항목	결론
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 기준으로 먼저 수정 후 이관
장점	가장 빠르게 운영 재현 가능, 원인 분리 쉬움	장기적으로 유지보수성/보안성 개선 가능
단점	기술부채를 잠시 유지함	초기 범위와 리스크가 크게 증가
장애 원인 분석	비교적 단순함	코드/런타임/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에서 추가로 고려해야 하는 검증 범위

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

즉, 전환 직후의 확인 작업량은 단일 서비스 이관보다 훨씬 크며, 실제 안정화 시간도 서비스 수에 비례해 증가할 가능성이 높다.

방식 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, 필수 저장소가 확보됐다는 전제의 대략치다. 단, 이번 건은 다중 서비스 동시 전환이므로 실제 확인 대상이 늘어나면 현업 총 소요시간은 5일 ~ 10일 이상으로 늘어날 가능성도 있다.

방식 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 기준 테스트와 기능 회귀 검증

방식 B에서 특히 더 커지는 부담

구분	설명
서비스 수	여러 서비스가 동시에 바뀌므로 수정 영향 범위가 넓다
공통 라이브러리 영향	공통 함수/공통 템플릿 수정이 다수 서비스에 동시 영향
회귀 테스트 범위	서비스별 로그인, 조회, 등록, 첨부, 출력까지 모두 다시 확인해야 함
안정화 기간	한 서비스 수정 후 다른 서비스에서 새 오류가 다시 나올 수 있음

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 전환을 별도 단계로 추진