137 lines
5.0 KiB
Markdown
137 lines
5.0 KiB
Markdown
# 장헌 레거시 전환 작업 규칙
|
|
|
|
## 목적
|
|
|
|
이 문서는 장헌 레거시 전환 작업을 진행할 때의 공통 규칙을 정리한 문서다.
|
|
|
|
이번 프로젝트는 범위가 크고, 문서/설정/코드/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`로 유지한다.
|