레거시를 이어받는다는 것
오래된 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시간 내 또는 당일 착수로 대응합니다.