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

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

@@ -20,6 +20,20 @@
 | 운영 루트 | `D:\APM_Setup\htdocs` |
 | 주요 의존성 | `mysql_*`, short open tag, Windows 절대경로, 업로드/로그 파일 경로 |
 
+## 이번 전환 작업의 범위 특성
+
+이번 작업은 `단일 서비스 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 전환 + 리눅스 이관 동시 진행 |
@@ -53,6 +67,18 @@
 | 5 | Docker에서 웹/DB 동시 기동 |
 | 6 | 로그인, 메인 화면, 첨부, 이미지, 템플릿 렌더링 확인 |
 
+### 방식 A에서 추가로 고려해야 하는 검증 범위
+
+| 구분 | 확인 내용 |
+| --- | --- |
+| 서비스별 진입 확인 | `intranet`, `factory_mng`, `person_mng`, `projt_mng`, `account` 각 서비스의 로그인/메인 진입 여부 |
+| 공통 템플릿 확인 | `Smarty`, `Smarty2.6` 기반 화면 렌더링 오류 여부 |
+| 저장소 확인 | `*_file`, `erpphoto`, `log`, `temp` 경로의 읽기/쓰기 여부 |
+| 이미지/첨부 확인 | 사진, 첨부, 다운로드, 업로드 동작 여부 |
+| 서비스 간 공통 영향 | 공통 설정 수정이 다른 서비스에 부작용을 주지 않는지 확인 |
+
+즉, 전환 직후의 확인 작업량은 단일 서비스 이관보다 훨씬 크며, 실제 안정화 시간도 서비스 수에 비례해 증가할 가능성이 높다.
+
 ### 방식 A 예상 소요시간
 
 아래 시간은 두 기준으로 나눠 본다.
@@ -69,6 +95,7 @@
 | 합계 | 약 1일 ~ 3일 | 약 3일 ~ 7일 |
 
 위 시간은 `운영본 압축`, `DB dump`, `필수 저장소`가 확보됐다는 전제의 대략치다.
+단, 이번 건은 다중 서비스 동시 전환이므로 실제 확인 대상이 늘어나면 `현업 총 소요시간`은 `5일 ~ 10일` 이상으로 늘어날 가능성도 있다.
 
 ## 방식 B 상세: PHP 8.x 전환 + 리눅스 이관 동시 진행
 
@@ -93,6 +120,15 @@
 | 7 | Windows 경로, 파일 권한, 업로드 로직 전면 점검 |
 | 8 | PHP 8 기준 테스트와 기능 회귀 검증 |
 
+### 방식 B에서 특히 더 커지는 부담
+
+| 구분 | 설명 |
+| --- | --- |
+| 서비스 수 | 여러 서비스가 동시에 바뀌므로 수정 영향 범위가 넓다 |
+| 공통 라이브러리 영향 | 공통 함수/공통 템플릿 수정이 다수 서비스에 동시 영향 |
+| 회귀 테스트 범위 | 서비스별 로그인, 조회, 등록, 첨부, 출력까지 모두 다시 확인해야 함 |
+| 안정화 기간 | 한 서비스 수정 후 다른 서비스에서 새 오류가 다시 나올 수 있음 |
+
 ### PHP 8.x 전환 시 예상되는 대표 수정 포인트
 
 | 구분 | 예상 이슈 |
@@ -119,6 +155,7 @@
 | 합계 | 약 7일 ~ 21일 | 약 14일 ~ 42일 이상 |
 
 레거시 크기와 미확인 모듈 수를 고려하면, 실제로는 이보다 더 길어질 가능성도 있다.
+특히 여러 서비스가 동시 전환되는 범위라는 점을 감안하면, 기능 확인과 안정화 단계가 길어져 `현업 총 소요시간`은 추가로 더 늘어날 수 있다.
 
 ## PHP 8 전환 방향 검토
 
@@ -172,8 +209,8 @@
 | --- | --- |
 | 단기 목표 | 방식 A 채택 |
 | 중기 목표 | 방식 A 성공 후 방식 B 별도 계획 수립 |
-| 보고 메시지 | 먼저 운영 재현으로 서비스 연속성을 확보하고, 이후 PHP 8 전환을 별도 단계로 추진 |
+| 보고 메시지 | 먼저 다중 서비스 운영 재현으로 서비스 연속성을 확보하고, 이후 PHP 8 전환을 별도 단계로 추진 |
 
 ## 팀장 보고용 한줄 요약
 
-현재 장헌 레거시의 리눅스 이관은 `PHP 5.2 운영 재현`과 `PHP 8 전환`을 분리해서 보는 것이 가장 안전하며, 먼저 리눅스에서 현재 운영을 재현한 뒤 PHP 8 전환을 2차 과제로 진행하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.
+현재 장헌 레거시의 리눅스 이관은 여러 서비스가 동시에 얽힌 통합 전환 작업이므로, 먼저 `PHP 5.2 운영 재현`으로 전체 서비스 연속성을 확보하고, 이후 충분한 안정화와 서비스별 검증을 거쳐 PHP 8 전환을 2차 과제로 분리하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.