diff --git a/장헌 레거시 리눅스 전환 검토.md b/장헌 레거시 리눅스 전환 검토.md
new file mode 100644
index 0000000..a845bb4
--- /dev/null
+++ b/장헌 레거시 리눅스 전환 검토.md	
@@ -0,0 +1,205 @@
+# 장헌 레거시 리눅스 전환 검토
+
+## 작성 목적
+
+장헌 레거시 서비스의 리눅스 전환 방향을  간단명료하게 정리한다.
+
+이번 판단의 핵심은 아래 두 가지 방식 비교다.
+
+1. `방식 A. 현재 운영 재현 우선`
+2. `방식 B. 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 기준으로 먼저 수정 후 이관 |
+| 장점 | 가장 빠르게 운영 재현 가능, 원인 분리 쉬움 | 장기적으로 유지보수성/보안성 개선 가능 |
+| 단점 | 기술부채를 잠시 유지함 | 초기 범위와 리스크가 크게 증가 |
+| 장애 분석 난이도 | 비교적 낮음 | 높음 |
+| 현재 상황 적합성 | 매우 높음 | 중장기 과제로는 적합, 즉시 재현 목표에는 부담 큼 |
+
+## 방식 A 설명
+
+### 핵심 개념
+
+방식 A는 구버전 운영 구조를 그대로 리눅스로 옮기는 것이 아니라,  
+`운영 동작 방식은 최대한 유지하고 실행 환경만 Linux + Docker로 재구성`하는 전략이다.
+
+### 스택 전환 개념
+
+| 구분 | 현재 운영 | 방식 A 목표 |
+| --- | --- | --- |
+| OS | Windows | Linux |
+| 웹서버 | Apache 2.2.14 on APMSETUP | Apache on Docker container |
+| PHP | PHP 5.2.12 | PHP 5.2 호환성 최대 유지 |
+| DB | MySQL 5.1.41 계열 | Docker 안 DB 또는 호환 DB로 재현 |
+| 템플릿 | Smarty 2.6 | 그대로 유지 |
+| 웹루트 | `D:\APM_Setup\htdocs` | 예: `/var/www/html` |
+| 임시업로드 | `D:\APM_Setup\temp` | 예: `/var/www/tmp/uploads` |
+| 파일저장소 | `*_file`, `erpphoto`, `log` | Docker volume 또는 리눅스 디렉터리로 매핑 |
+
+### 실제 작업 내용
+
+| 단계 | 작업 내용 |
+| --- | --- |
+| 1 | 운영 원본 소스와 저장소 반입 |
+| 2 | `D:\APM_Setup\htdocs` 기준 폴더를 `app/htdocs`에 재배치 |
+| 3 | `dbcon*.inc`, `SmartyConfig.php`, 업로드/로그 경로 치환 |
+| 4 | DB dump import |
+| 5 | Docker에서 웹/DB 동시 기동 |
+| 6 | 로그인, 메인 화면, 첨부, 이미지, 템플릿 렌더링 확인 |
+
+### 전환 후 확인 범위
+
+| 구분 | 확인 내용 |
+| --- | --- |
+| 서비스별 진입 | `intranet`, `factory_mng`, `person_mng`, `projt_mng`, `account` 로그인/메인 진입 |
+| 공통 템플릿 | `Smarty`, `Smarty2.6` 렌더링 오류 여부 |
+| 저장소 | `*_file`, `erpphoto`, `log`, `temp` 읽기/쓰기 여부 |
+| 업로드/다운로드 | 첨부, 사진, 다운로드, 업로드 동작 여부 |
+| 공통 영향 | 공통 설정 수정이 다른 서비스에 부작용을 주지 않는지 확인 |
+
+즉, A방식이라도 전환 후 안정화와 서비스별 확인량은 상당히 크다.
+
+### 예상 소요시간
+
+시간은 아래 두 기준으로 본다.
+
+- `Codex 순수 작업시간`: 문서화, 설정편집, 스크립트정리, 오류분석 중심
+- `현업 총 소요시간`: 운영자료 확보, 담당자 확인, 실제 기동 검증, 반복 보정 포함
+
+| 단계 | 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일 |
+
+단, 이번 건은 다중 서비스 동시 전환이므로 실제 확인 대상이 늘어나면 `현업 총 소요시간`은 `5일 ~ 10일 이상`으로 늘어날 가능성도 있다.
+
+## 방식 B 설명
+
+### 핵심 개념
+
+방식 B는 리눅스 이관과 동시에 PHP 8.x 기준으로 코드와 DB 호환성을 함께 정리하는 전략이다.
+
+### 실제로 해야 하는 일
+
+| 단계 | 작업 내용 |
+| --- | --- |
+| 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 기준 테스트와 기능 회귀 검증 |
+
+### 대표 리스크
+
+| 구분 | 예상 이슈 |
+| --- | --- |
+| DB API | `mysql_connect`, `mysql_query`, `mysql_result` 제거됨 |
+| 문자열/정규식 | `split`, `ereg` 계열 제거 또는 비권장 |
+| 전역 변수 관행 | `register_globals` 의존 코드 오동작 가능 |
+| 입력 처리 | `magic_quotes_gpc` 제거로 escaping 흐름 변경 필요 |
+| 템플릿 | Smarty 2.6와 최신 PHP 조합 호환성 이슈 가능 |
+| 경고 수준 | PHP 8에서 경고가 치명 오류로 바뀌는 구간 다수 가능 |
+| 공통 영향 | 공통 함수/공통 템플릿 수정이 여러 서비스에 동시에 영향 |
+| 안정화 | 한 서비스 수정 후 다른 서비스에서 새 오류가 다시 나올 수 있음 |
+
+### 예상 소요시간
+
+| 단계 | 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 전환`은 불가능한 것이 아니라 `지금 1차 목표인 운영 재현 단계에서는 리스크를 추가하는 선택`으로 보는 편이 타당하다.
+
+## 최종 권장안
+
+| 항목 | 권장안 |
+| --- | --- |
+| 단기 목표 | `방식 A` 채택 |
+| 중기 목표 | 방식 A 성공 후 방식 B 별도 계획 수립 |
+| 보고 메시지 | 먼저 다중 서비스 운영 재현으로 서비스 연속성을 확보하고, 이후 충분한 안정화와 서비스별 검증을 거쳐 PHP 8 전환을 2차 과제로 분리 |
+
+