장헌 레거시 리눅스 이관 방식 비교 메모
작성 목적
2026-07-22 오전 회의 기준으로, 장헌 레거시 서비스의 리눅스 전환 방향을 팀장에게 간단명료하게 설명하기 위한 비교 메모다.
비교 대상은 아래 두 가지다.
현재 운영 재현 우선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 유지에는 분명한 한계가 있음 |
| 리눅스 호환성만의 문제 |
PHP 8이어서 리눅스와 잘 맞는 것이 아니라, 코드가 최신 PHP에 맞게 수정되어야 함 |
| 즉시 운영 재현 목표와의 적합성 |
낮음 |
즉, 리눅스 이관 = PHP 8 필수는 아니다.
정확히는 PHP 8 전환은 별도 대형 개편 과제에 가깝다.
권장 판단
| 항목 |
권장안 |
| 단기 목표 |
방식 A 채택 |
| 중기 목표 |
방식 A 성공 후 방식 B 별도 계획 수립 |
| 보고 메시지 |
먼저 운영 재현으로 서비스 연속성을 확보하고, 이후 PHP 8 전환을 별도 단계로 추진 |
팀장 보고용 한줄 요약
현재 장헌 레거시의 리눅스 이관은 PHP 5.2 운영 재현과 PHP 8 전환을 분리해서 보는 것이 가장 안전하며, 먼저 리눅스에서 현재 운영을 재현한 뒤 PHP 8 전환을 2차 과제로 진행하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.
