230 lines
12 KiB
Markdown
230 lines
12 KiB
Markdown
# 장헌 레거시 리눅스 이관 방식 비교
|
|
|
|
## 작성 목적
|
|
|
|
장헌 레거시 서비스의 리눅스 전환 방향을 간단명료하게 설명하기 위함.
|
|
|
|
비교 대상은 아래 두 가지다.
|
|
|
|
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 전환을 별도 단계로 추진 |
|
|
|
|
|