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

## 작성 목적

`2026-07-22` 오전 회의 기준으로, 장헌 레거시 서비스의 리눅스 전환 방향을 팀장에게 간단명료하게 설명하기 위한 비교 메모다.

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

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차 과제로 진행하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.