diff --git a/JH_ERP/장헌 레거시 리눅스 이관 방식 비교 메모./장헌 레거시 리눅스 이관 방식 비교 메모.md b/JH_ERP/장헌 레거시 리눅스 이관 방식 비교 메모./장헌 레거시 리눅스 이관 방식 비교 메모.md
new file mode 100644
index 0000000..4c7b23c
--- /dev/null
+++ b/JH_ERP/장헌 레거시 리눅스 이관 방식 비교 메모./장헌 레거시 리눅스 이관 방식 비교 메모.md	
@@ -0,0 +1,138 @@
+# 장헌 레거시 리눅스 이관 방식 비교 메모
+
+## 작성 목적
+
+`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 예상 소요시간
+
+| 단계 | 예상 소요 |
+| --- | --- |
+| 원본 정리 및 반입 | 0.5일 ~ 1일 |
+| 경로/설정/볼륨 정리 | 1일 ~ 2일 |
+| DB import 및 첫 기동 | 0.5일 ~ 1일 |
+| 대표 기능 검증/보정 | 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 예상 소요시간
+
+| 단계 | 예상 소요 |
+| --- | --- |
+| 전수 분석 및 영향도 파악 | 2일 ~ 5일 |
+| PHP 8 호환 코드 수정 | 5일 ~ 15일 |
+| DB/뷰/SQL 호환성 수정 | 2일 ~ 7일 |
+| 템플릿/업로드/로그/파일 경로 수정 | 2일 ~ 5일 |
+| 통합 테스트/회귀 테스트 | 3일 ~ 10일 |
+| 합계 | 약 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차 과제로 진행하는 것이 일정, 리스크, 장애 분석 측면에서 가장 현실적이다.