호스팅사에서 ‘PHP 7.4 지원 종료’ 안내를 받고 버전을 올렸다가 사이트가 하얗게 변하는 사례를 매달 봅니다. PHP 8.x 전환 자체는 어렵지 않지만, 구형 테마·플러그인을 쓰는 사이트라면 당일 작업 순서가 결과를 좌우합니다.
올리기 전에 반드시 할 것
먼저 전체 백업을 뜨고, 가능하면 복제(스테이징) 사이트에서 먼저 올려 봅니다. 호스팅 패널에 스테이징 기능이 없다면 최소한 트래픽이 적은 시간대를 골라 진행하세요. wp-config.php에 WP_DEBUG_LOG를 켜 두면 화면에 안 보이는 오류까지 파일로 남아 원인 추적이 빨라집니다. 어떤 버전 조합이 안전한지는 PHP·MySQL 호환성 정리를 참고하세요.
당일에 실제로 깨지는 것들
- create_function 오류: 오래된 테마의 functions.php에서 흔합니다. PHP 8.0에서 완전히 제거돼 치명적 오류로 사이트가 멈춥니다.
- each() 사용 코드: 구형 플러그인의 반복문에서 자주 나오며 역시 8.0부터 즉시 오류입니다.
- 필수 인자 순서 문제: 선택 인자 뒤에 필수 인자가 오는 낡은 함수 선언이 8.0부터 오류를 냅니다.
- PHP 8.2 동적 속성 경고: 사이트가 죽지는 않지만 경고 로그가 폭증해 디스크를 채우는 경우가 있습니다.
깨졌을 때 대처 순서
흰 화면이 뜨면 당황하지 말고 호스팅 패널에서 PHP 버전을 이전으로 되돌립니다. 대부분 즉시 복구됩니다. 그다음 디버그 로그에서 오류를 낸 테마·플러그인을 특정하고, 업데이트나 대체 플러그인으로 교체한 뒤 다시 올립니다. 로그에 찍힌 파일 경로에 답이 있습니다.
플러그인 → 설치된 플러그인 화면에서 각 항목의 PHP 요구 버전을 미리 확인해 두면 당일 사고의 절반은 예방됩니다.
※ 수년간 업데이트가 끊긴 유료 테마를 쓰고 계시다면, PHP 업그레이드보다 테마 교체를 먼저 검토하는 편이 결과적으로 비용이 적게 듭니다.
버전 관리와 정기 업데이트를 매번 직접 챙기기 어려우시다면 유지보수 플랜에서 이 과정을 통째로 맡기실 수 있습니다.