MyDoc/장헌 레거시 리눅스전환 검토/장헌 레거시 전환 작업 규칙.md

장헌 레거시 전환 작업 규칙

목적

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

이번 프로젝트는 범위가 크고, 문서/설정/코드/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로 유지한다.