/ 가이드 / PHP 레거시 배포
가이드 · 유지보수

오래된 PHP 사이트, 배포했는데 안 바뀔 때 — 안전한 운영 배포 체크리스트

PHP 사이트를 고쳐 올렸는데 화면이 그대로일 때의 원인(OPcache)과, SSL·도메인 만료, 발신번호 승인 등 레거시 PHP 운영에서 서비스를 멈추게 하는 것들을 점검 리스트로 정리했습니다.

앱몬스터 · 작성 2026-09-17

핵심 요약

PHP를 고쳐 올렸는데 안 바뀌면 대개 OPcache가 이전 코드를 메모리에 들고 있어서입니다. 배포 후 php-fpm과 웹서버를 reload 하세요. 이 과정을 배포 자동화에 넣어 사람이 잊지 않게 하는 것이 안전 운영의 핵심입니다.

1. 배포했는데 안 바뀐다 — OPcache

PHP는 성능을 위해 컴파일된 코드를 메모리(OPcache)에 캐시합니다. 파일을 바꿔 올려도 캐시가 남아 있으면 이전 코드가 계속 실행됩니다. 배포 후 아래를 실행합니다.

systemctl reload php-fpm
systemctl reload httpd   # 또는 nginx

배포 자동화(CI/CD)를 쓴다면 이 reload를 파이프라인 마지막 단계에 넣어, 사람이 잊어도 자동으로 반영되게 합니다.

2. 조용히 다가오는 만료 — SSL·도메인

SSL 인증서와 도메인은 만료 당일에야 티가 납니다. 그날 사이트 전체가 ‘안전하지 않음’으로 뜨거나 접속이 끊깁니다. 갱신 절차(DNS 검증 등)를 미리 익히고 만료일을 알림으로 관리하세요.

3. 문자·알림은 승인이 먼저

대량 문자·알림 기능을 붙여도 통신사 발신번호 승인 전에는 실제로 안 나갑니다. 인프라를 다 만들고 마지막에 승인이 막혀 일정이 밀리는 일이 흔하니, 발송이 필요하면 승인 신청을 가장 먼저 걸어 두세요.

4. 운영 배포 체크리스트

  • □ 배포 후 OPcache reload(php-fpm·웹서버) 실행/자동화
  • □ SSL·도메인 만료일 알림 등록
  • □ 문자 발신번호 승인 완료 확인
  • □ DB·업로드 파일 자동 백업 + 복구 테스트
  • □ 비밀키·접속정보가 코드/공개 저장소에 없는지
  • □ 검증되지 않은 커밋이 운영에 섞이지 않게(cherry-pick)

인수받을 때 먼저 확인할 것

다른 곳에서 만든 PHP 사이트를 이어받는다면, 코드보다 소유권이 먼저입니다. 서버·DB·도메인·인증서·문자 계정의 소유가 우리에게 있는지 확인하고, 빌드·배포 절차가 문서로 있는지 봅니다.

자주 묻는 질문

배포 자동화(CI/CD)가 없어도 되나요?

소규모면 수동 reload로도 됩니다. 다만 배포가 잦아지면 자동화로 캐시 reload 누락을 막는 게 안전합니다.

그누보드·카페24도 대응하나요?

네. PHP·그누보드·카페24·MariaDB 기반 사이트의 유지보수·장애 대응이 가능합니다.

긴급 장애도 봐주나요?

요금제에 따라 24시간 내 또는 당일 착수로 대응합니다.

함께 읽기: 레거시 PHP 운영 사례 · 웹·앱 유지보수

직접 하기 어렵다면

보안 점검·유지보수·앱 개발을 월정액으로 대행합니다. 상황만 알려주시면 범위와 비용을 먼저 정리해 드립니다.

의뢰하기