/ 가이드 / 레거시 PHP 유지보수 사례
운영 사례 · 유지보수

개발사가 떠난 뒤 — 수백 단지 규모 레거시 PHP 플랫폼을 운영하며 배운 것

수백 개 단지가 매일 쓰는 PHP·MariaDB 관리 플랫폼을 직접 운영하며 겪은 배포 함정, 인증서 만료, 문자 발송 승인 문제와 그 해결 방법을 정리했습니다. 오래된 PHP 사이트를 이어받아야 하는 분을 위한 글입니다.

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

핵심 요약

레거시 PHP 운영에서 서비스를 멈추게 하는 것은 대개 화려한 버그가 아니라 배포 후 캐시(OPcache), SSL·도메인 만료, 문자 발송 발신번호 승인 같은 운영 절차입니다. 코드를 잘 짜는 것만큼, 이 절차들을 자동화하고 만료를 미리 아는 것이 안정 운영의 핵심입니다.

레거시를 이어받는다는 것

오래된 PHP 사이트는 “돌아가고는 있지만 아무도 손대기 무서운” 상태인 경우가 많습니다. 저는 수백 개 단지가 매일 접속하는 PHP·MariaDB 기반 관리 플랫폼을 직접 운영하면서, 실제로 서비스를 위협하는 것이 무엇인지 반복해서 확인했습니다. 아래는 그중 특히 값진 교훈입니다.

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

PHP 파일을 고쳐 올렸는데 화면이 그대로인 사고가 있습니다. PHP-FPM의 OPcache가 이전 코드를 메모리에 들고 있기 때문입니다. 배포 후 systemctl reload php-fpm과 웹서버 reload를 반드시 함께 해야 하고, 이 과정을 배포 자동화(CI/CD)에 넣어 사람이 잊지 않게 만드는 것이 안전합니다.

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

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

3. 문자·알림은 승인이 먼저 — 발신번호

대량 문자 발송 기능을 붙여도, 통신사 발신번호 승인이 나기 전에는 실제로 나가지 않습니다. 인프라를 다 만들고 마지막에 승인이 막혀 일정이 밀리는 일이 흔합니다. 발송이 서비스 흐름에 들어간다면 승인 신청을 가장 먼저 걸어 둬야 합니다.

4. 협업 커밋은 골라 담는다

여러 명이 같은 저장소에 커밋하면, 운영에 올릴 것과 아직 검증 안 된 것이 섞입니다. 검증된 커밋만 골라 반영(cherry-pick)하는 규칙을 두면 운영 브랜치를 깨끗하게 유지할 수 있습니다.

인수 점검 때 꼭 확인하는 것

  • 서버·DB·도메인·인증서·문자 계정의 소유권이 우리에게 있는가
  • 배포 절차와 캐시 reload가 문서로 있는가
  • 백업이 실제로 복구되는가
  • 비밀키·접속정보가 코드에 노출돼 있지 않은가

자주 묻는 질문

다른 회사가 만든 PHP 사이트도 맡을 수 있나요?

PHP·그누보드·카페24·WordPress·MariaDB 기반이면 인수 점검 후 유지보수가 가능합니다. 먼저 소스와 계정 권한을 확보하고 상태를 점검합니다.

오래된 사이트라 새로 만드는 게 낫지 않나요?

경우에 따라 다릅니다. 잘 돌아가는 부분은 유지하고 위험한 부분만 고치는 편이 비용·리스크가 낮을 때가 많습니다. 점검 후 판단을 함께 드립니다.

긴급 장애도 대응하나요?

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

같은 문제를 겪고 있다면

AEO 자동화, 웹·앱 유지보수, 보안 점검을 월정액으로 운영합니다. 상황만 알려주시면 범위와 비용을 먼저 정리해 드립니다.

의뢰하기