Files
MyDoc/장헌 레거시 리눅스전환 검토/0001.장헌 레거시 서버 회수 및 Linux 운영 전환 시나리오 초안.md
T

12 KiB

장헌 레거시 서버 회수 및 Linux 운영 전환 시나리오 초안

상태: 회의용 초안
목적: 레거시 서버를 회수하기 전에 신규 Linux/Docker 운영 환경으로 안전하게 전환하기 위한 범위·순서·담당·중단 및 롤백 기준을 합의한다.
원칙: 이 문서는 전환 계획이다. 운영 서버 변경·배포·레거시 서버 회수의 실행 승인은 별도로 받는다.

1. 회의에서 먼저 결정할 사항

결정 항목 회의에서 확정할 내용 결정 담당
전환 대상 7개 핵심 서비스, worker_mng, proj_new2, apiLibrary의 포함 범위와 제외 범위 업무·개발 책임자
운영 기준 소스 Gitea main의 배포 대상 커밋 SHA와 승인 기준 개발·배포 책임자
전환 일시 입력 중지 시작, 최종 동기화, 신규 서비스 공개, 레거시 회수 예정일 업무·운영 책임자
DB 기준 시점 최종 덤프 생성 시각과 신규 DB 복원 완료 확인 방법 DB 책임자
업무 파일 기준 intranet_file, factory_file, apiLibrary/log의 이관 범위·보존 기간 업무·운영 책임자
도메인 전환 신규 서버 주소, DNS/프록시 전환 담당자와 확인 절차 인프라 책임자
롤백 장애 판단 기준, 레거시 복귀 가능 기간, 데이터 처리 방법 전환 책임자

2. 전환의 전체 구조

레거시 서버                              신규 Linux 운영 서버
────────────────────────────────────────────────────────────────
PHP 원본 소스 ──> Gitea main 기준 이미지 ──> Docker 웹 컨테이너
운영 DB       ──> 최종 DB dump/복원      ──> DB 영속 저장소
업무 파일     ──> 1차 복사 + 최종 동기화  ──> /opt/jang-data/*
원본 보관본   ──> SHA-256 검증            ──> /opt/jang-archive/*
                                              ↓
                                           스테이징 검증
                                              ↓
                                           운영 공개·도메인 전환

3. 컨테이너와 실제 파일 저장 위치

파일 보관 전용 컨테이너를 새로 만들지 않는다. 운영 Linux 서버의 실제 폴더를 기존 웹 컨테이너 경로에 볼륨 마운트한다.

운영 서버 실제 디스크                         웹 컨테이너 내부
/opt/jang-data/intranet_file  ────────>  /var/www/html/intranet_file
/opt/jang-data/factory_file   ────────>  /var/www/html/factory_file
/opt/jang-data/apiLibrary-log ────────>  /var/www/html/apiLibrary/log

따라서 사용자가 웹 화면에서 업로드한 파일은 컨테이너가 아니라 운영 서버의 /opt/jang-data/... 아래에 남는다. 컨테이너 재배포·재생성 뒤에도 파일이 유지된다.

Compose 설정은 아래와 같은 형태로 관리한다. 실제 변수명과 대상 경로는 현재 docker-compose*.yml과 운영 .env를 기준으로 최종 확인한다.

services:
  web:
    volumes:
      - ${INTRANET_FILES_ROOT}:/var/www/html/intranet_file
      - ${FACTORY_FILES_ROOT}:/var/www/html/factory_file
      - ${API_LIBRARY_LOG_ROOT}:/var/www/html/apiLibrary/log

4. DB 이관 시나리오

DB dump는 기준 데이터를 옮기는 방법이다. 단, 레거시에서 사용자가 계속 입력하는 동안 만든 1차 dump만으로 운영 전환을 완료하면 마지막 입력분이 누락될 수 있다.

단계 작업 완료 확인
1차 리허설 레거시 DB dump를 신규 격리/스테이징 DB에 복원 로그인·핵심 조회·테이블 수·대표 데이터 확인
사전 검증 신규 코드와 복원 DB로 핵심 업무 흐름 검사 오류 로그·DB 연결·파일 연계 확인
전환 동결 레거시의 신규 입력·결재·파일 업로드를 중지 공지·담당자 확인
최종 dump 동결 시점의 레거시 DB를 dump dump 파일 크기·해시·생성 시각 기록
최종 복원 신규 운영 DB에 최종 dump 복원 복원 로그·핵심 테이블·계정 확인
공개 전 확인 신규 서버에서 로그인·조회·입력·결재 등 핵심 검사 업무 책임자 승인

DB dump는 비밀정보와 운영 데이터를 포함할 수 있다. Git·일반 문서·채팅에 저장하지 않고, 접근 권한이 제한된 백업 경로에서 관리한다.

5. 대용량 업무 파일 이관 시나리오

5.1 분리 보관 원칙

대상 Git main 반영 여부 운영 저장 방식
PHP·JS·CSS·템플릿 등 소스 반영 Gitea 및 Docker 이미지
intranet_file 업무 첨부·문서·PDF 반영하지 않음 /opt/jang-data/intranet_file
factory_file Excel·PDF·업무 산출물 반영하지 않음 /opt/jang-data/factory_file
apiLibrary/log 로그 반영하지 않음 /opt/jang-data/apiLibrary-log
DB dump 반영하지 않음 권한 제한 백업 경로
비밀번호·토큰·개인키 절대 반영하지 않음 별도 보안 저장소

5.2 파일 이관 순서

1차 전체 복사
       ↓
레거시 업무는 계속 사용
       ↓
전환 시간에 업로드·수정 중지
       ↓
새 파일·수정 파일만 최종 동기화
       ↓
파일 수·용량·대표 파일·권한 확인

파일 비교 기준은 상대 경로 + 파일 크기 + 최종 수정 시간을 기본으로 한다. 네트워크·용량이 허용되는 범위에서는 중요한 파일 또는 최종 이관본에 대해 SHA-256 해시를 추가 확인한다.

파일 상태 판단 조치
신규 파일 신규 서버 대상 경로에 없음 복사
수정 파일 크기 또는 최종 수정 시간이 다름 다시 복사
변화 없음 경로·크기·수정 시간이 같음 재복사하지 않음
레거시에서 삭제됨 신규에는 남아 있을 수 있음 자동 삭제 금지, 목록 검토 후 별도 결정

Windows 레거시 서버에서 Linux 운영 서버로 옮길 때는 WinSCP/SFTP 동기화 또는 SSH 기반 증분 동기화를 사용한다. 전송 전에는 반드시 예정 파일 목록을 미리 보고, 삭제 동기화는 켜지 않는다.

5.3 파일 생성 검증

운영 공개 전 다음을 확인한다.

  • 실제 화면에서 고유한 시험 첨부 파일 1개 업로드
  • 컨테이너 내부 경로와 운영 서버의 영속 경로에 같은 파일이 생성됐는지 확인
  • 다운로드 가능 여부 확인
  • 시험 파일을 화면 기능으로 삭제하고 영속 경로에서도 사라졌는지 확인
  • 웹 프로세스의 쓰기 권한 오류가 없는지 로그 확인

6. 레거시 원본 소스 보관본

모든 레거시 폴더를 한 번에 전환하지 않았으므로, 레거시 PC 회수 전 마지막 원본 소스를 읽기 전용 기준본으로 보관한다. 이는 운영 배포물이 아니라, 이후 누락된 호출·메뉴·배치가 발견될 때 비교하고 추가 전환하기 위한 근거다.

/opt/jang-archive/legacy-source/YYYYMMDD-cutover/
├─ legacy-htdocs-source-YYYYMMDD.zip
├─ legacy-htdocs-source-YYYYMMDD.zip.sha256
├─ MANIFEST.txt
└─ README.md
포함 제외 또는 별도 보관
PHP·JS·CSS·템플릿·정적 소스 intranet_file, factory_file 업무 파일
전환 후보가 될 수 있는 레거시 모듈 DB dump
원본 구조를 설명하는 문서·목록 비밀번호·토큰·개인키
로그·캐시·임시파일·개발 산출물

보관본은 웹 문서 루트·Docker 마운트 경로·Git 저장소에 두지 않는다. 운영 서버 보관본 외에도 별도 백업 저장소에 동일 파일과 SHA-256 파일을 한 부 더 보관한다. 스테이징에는 상시 보관하지 않는다.

추가 전환이 필요해질 때의 원칙은 다음과 같다.

보관본을 별도 작업 공간에 복사·해제
       ↓
현재 main과 비교
       ↓
필요한 범위만 전용 브랜치에서 PHP 8 전환·테스트
       ↓
PR 검토·병합·배포

7. 전환 당일 실행 타임라인

시점 담당 작업 중단/확인 기준
D-7 ~ D-1 개발·운영 main 배포 후보, Compose·환경 변수, 영속 경로, 접근 권한 확인 미확정 경로·비밀값은 전환 금지
D-7 ~ D-1 DB·업무 1차 DB·파일 이관 및 스테이징 검증 핵심 기능 실패 시 원인 해결
D-1 운영 롤백 연락망·담당자·도메인 전환 절차 확정 책임자 미지정 시 전환 연기
T-시작 업무 책임자 레거시 입력·결재·파일 업로드 동결 공지 동결 확인 전 최종 이관 금지
T+ DB 책임자 최종 DB dump 및 신규 DB 복원 복원 실패·검증 실패 시 중단
T+ 운영 책임자 최종 변경 파일 동기화 및 권한 확인 파일 수·대표 파일 불일치 시 중단
T+ 개발·QA 신규 Docker 기동, 핵심 업무 smoke test Fatal/Parse·로그인·파일생성 실패 시 롤백 판단
T+ 인프라 도메인·프록시를 신규 서버로 전환 전환 전 승인 필요
T+ 업무·QA 실사용자 핵심 시나리오 확인 결재·첨부·PDF·Excel 등 확인
T+1일 이후 운영 로그·오류·업무 파일 생성 상태 관찰 레거시 회수 전 안정성 확인

8. 공개 전 최소 업무 확인 목록

분야 최소 확인
인증 지정 계정 로그인·권한 경계·세션
7개 서비스 메뉴 접근·핵심 조회·필수 입력 흐름
전자결재 기안·결재선·처리 상태·결재자 표시
파일 첨부 업로드·다운로드·삭제·영속 경로 생성
문서 PDF 생성·다운로드·한글 표시
공장관리 Excel·PDF·factory_file 생성 및 조회
API apiLibrary 호출·로그 생성·오류 처리
기술 상태 PHP Fatal/Parse/Warning/Deprecated, 웹·DB 로그

상세 서비스별 Unit/characterization·통합 테스트 기준은 00-service-validation-standard.md를 따른다.

9. 롤백 원칙

레거시 서버는 신규 서버 공개 직후 바로 회수하지 않는다. 최소 관찰 기간과 롤백 기준을 회의에서 확정한다.

상황 기본 조치
로그인·DB 연결·핵심 메뉴가 동작하지 않음 신규 공개 중단 또는 레거시 경로로 복귀 검토
업로드 파일이 저장되지 않음 쓰기 중지, 영속 경로·권한 점검, 필요 시 롤백
DB 최종 복원 데이터가 기준과 다름 신규 쓰기 중지, DB 책임자 판단 전 공개 금지
일부 비핵심 기능만 실패 영향·우회 방법·수정 일정 기록 후 책임자 승인으로 제한 운영 여부 결정

롤백 뒤 신규 서버에서 생성된 데이터가 있다면, 단순히 서버만 되돌릴 수 없다. DB와 파일의 추가분을 어떻게 처리할지 DB·업무 책임자가 결정해야 한다.

10. 회의 종료 전 확정 체크리스트

  • 전환 범위와 제외 범위를 확정했다.
  • 운영 배포 기준 main 커밋 SHA와 승인자를 정했다.
  • 운영 DB·업무 파일·로그의 실제 영속 경로를 정했다.
  • 파일 1차 이관 및 최종 동기화 담당자와 방법을 정했다.
  • DB 최종 dump·복원·검증 담당자와 동결 시각을 정했다.
  • 도메인/프록시 전환 담당자와 공개 확인 절차를 정했다.
  • 롤백 기준, 레거시 보존 기간, 연락망을 정했다.
  • 레거시 최종 원본 소스 보관본과 별도 백업본의 위치를 정했다.
  • 공개 전 최소 업무 확인 항목과 업무 승인자를 정했다.

11. 회의 후 보완할 정보

아래 값은 회의에서 확정한 뒤 별도 보안 문서 또는 운영 환경 설정에만 기록한다.

  • 운영 서버 접속·배포 방식과 담당자
  • 실제 호스트 경로와 소유자/권한
  • DB dump 저장 위치와 복원 명령
  • 도메인·TLS·프록시 전환 정보
  • 백업 저장소 위치와 보존 기간
  • 전환 일시, 동결 공지 문구, 비상 연락망