# 장헌 레거시 전환 작업 규칙

## 목적

이 문서는 장헌 레거시 전환 작업을 진행할 때의 공통 규칙을 정리한 문서다.

이번 프로젝트는 범위가 크고, 문서/설정/코드/DB/검증이 함께 얽혀 있으므로 아래 규칙을 기준으로 작업한다.

## 기본 원칙

| 번호 | 규칙 |
| --- | --- |
| 1 | 생각은 내부적으로 자유롭게 하되, 사용자에게 설명과 결과는 한국어로 작성한다. |
| 2 | 불확실한 내용은 추측으로 단정하지 않는다. 확인이 필요하면 그렇게 명시한다. |
| 3 | 큰 작업에 들어가기 전에는 무엇을 왜 어떻게 할지 먼저 설명한다. |
| 4 | 최종 답변 전에는 반대 관점이나 리스크를 한 번 더 점검한다. |
| 5 | 운영 재현, PHP 8 전환, Smarty 업그레이드, DB 상향은 각각 영향을 분리해서 본다. |

## 문서 작성 및 승인 규칙

### 적용 원칙

이번 프로젝트에서는 문서 작성이 작업의 일부이므로, 아래처럼 구분한다.

| 구분 | 규칙 |
| --- | --- |
| 새 문서 작성 | 무엇을 왜 쓰는지 먼저 설명하고, 승인 후 작성한다. |
| 기존 문서 수정 | 수정 이유와 변경 방향을 먼저 설명하고 진행한다. |
| 코드/설정 수정 | 수정 대상과 목적을 먼저 설명하고 진행한다. |

### 예외

아래는 즉시 작성 가능 범위로 본다.

| 구분 | 예외 허용 범위 |
| --- | --- |
| 회의 직후 정리 메모 | 사용자가 명시적으로 “정리해라”라고 지시한 경우 |
| 보고용 표/메모 | 사용자가 명시적으로 작성 승인한 경우 |
| 작업 중간 산출물 | 같은 맥락에서 이미 작성 승인을 받은 범위 안의 후속 문서 |

## 작업 전 설명 규칙

작업 전에 최소 아래를 사용자에게 설명한다.

| 항목 | 설명 내용 |
| --- | --- |
| 작업 사유 | 왜 이 작업이 필요한지 |
| 작업 대상 | 어떤 파일/문서/설정을 건드리는지 |
| 작업 방식 | 어떻게 진행할지 |
| 예상 결과 | 작업 후 무엇이 달라지는지 |
| 리스크 | 주의할 점이 있는지 |

## 추측 금지 규칙

| 항목 | 규칙 |
| --- | --- |
| 확인되지 않은 운영 사실 | 추정이라고 표시한다. |
| 버전/경로/서비스 범위 | 근거 문서나 실제 파일 기준으로 말한다. |
| 모르면 | 모른다고 말하고, 추가 확인 포인트를 제시한다. |

## 파일 생성/수정 규칙

| 항목 | 규칙 |
| --- | --- |
| 수동 편집 | `apply_patch` 사용 |
| 단순 조회 | `rg`, `sed`, `find`, `ls` 우선 사용 |
| 실제 운영 dump/압축 | Git 커밋 제외 유지 |
| 신규 파일명 | 날짜와 목적이 드러나게 작성 |
| 문서 저장 위치 | 현재 프로젝트 기준 `docs/temp/jang/` 또는 `docs/runtime/` 사용 |

## 문서 분류 규칙

| 유형 | 저장 위치 |
| --- | --- |
| 회의/보고/결정 메모 | `docs/temp/jang/` |
| 실행 절차/기술 구조/인벤토리 | `docs/runtime/` |
| 저장소 사용 안내 | 관련 디렉터리 내부 `README.md` |

## 작업 우선순위 규칙

### A안 진행 시

1. 운영 재현
2. 경로/저장소/권한 정리
3. 대표 기능 확인

### B안 진행 시

1. 운영본 범위 고정
2. PHP 8 치명 이슈 스캔
3. DB 계층 전환
4. Smarty 업그레이드 검토
5. Linux/Docker 기준 검증

## 큰 프로젝트 진행 규칙

이번 프로젝트처럼 범위가 큰 작업은 반드시 `단계별`로 나눈다.

| 단계 | 원칙 |
| --- | --- |
| 조사 단계 | 사실과 추정을 분리 |
| 설계 단계 | 대안 비교와 리스크 명시 |
| 착수 단계 | 체크리스트화 |
| 수정 단계 | 공통부부터 순차 수정 |
| 검증 단계 | 서비스별 회귀 테스트 |
| 안정화 단계 | 미해결 이슈와 우회사항 기록 |

## 다중 서비스 프로젝트 규칙

이번 건은 단일 서비스가 아니라 다중 서비스 동시 전환 성격이므로 아래를 지킨다.

| 항목 | 규칙 |
| --- | --- |
| 공통부 수정 | 다른 서비스 영향 여부를 항상 함께 본다. |
| 서비스별 검증 | `intranet`, `factory_mng`, `person_mng`, `projt_mng`, `account`를 분리해 본다. |
| 공통 저장소 | `*_file`, `erpphoto`, `log`, `temp`를 별도 추적한다. |
| 템플릿 검증 | Smarty 변경은 서비스 전체 영향으로 본다. |

## 보고 규칙

사용자에게는 아래 형식으로 짧고 분명하게 보고한다.

| 항목 | 규칙 |
| --- | --- |
| 진행 전 | 무엇을 볼지, 왜 보는지 |
| 진행 중 | 확인된 사실, 다음 작업 |
| 진행 후 | 무엇을 바꿨는지, 무엇이 남았는지 |
| 막힌 경우 | 막힌 원인과 필요한 입력/승인 |

## 현재 프로젝트에 맞춘 실무 결론

1. 큰 작업 전에는 먼저 설명한다.
2. 문서/코드 수정은 승인된 범위 안에서 진행한다.
3. 운영 사실은 근거 기반으로만 말한다.
4. 다중 서비스 영향 범위를 항상 함께 본다.
5. 최종 기준 환경은 `Linux + Docker`로 유지한다.