PHP 버전 업그레이드는 누가 PHP를 관리하느냐에 따라 갈립니다. 호스팅 업체가 관리하면 업체에 적용 여부를 확인하고 요청하는 것이 KISA 보호나라와 과기정통부의 안내이고, 서버를 직접 운영하면 직접 올리되 테스트를 먼저 거쳐야 합니다.
KISA는 패치가 호환성 문제로 서비스 장애를 일으킬 수 있다며 사전 영향도 검토와 테스트 뒤 적용을 권고합니다. 2026년 11월 4일 KISA 수칙과 php.net 마이그레이션 가이드를 읽고, 직접 할 일과 맡길 일을 나눴습니다.
1. PHP 버전 업그레이드, 직접 해도 되나요?
서버를 직접 운영한다면 됩니다. 다만 웹호스팅을 쓴다면 PHP가 업체 서버에서 돌아가므로, 직접 하기보다 업체에 묻는 것이 먼저입니다.
과기정통부 보도자료(2026년 10월 22일)는 호스팅 업체를 이용하는 소상공인은 그 업체에 보안 업데이트 적용 여부를 확인하면 된다고 적었습니다. KISA 수칙도 호스팅 업체나 장비 제조사가 PHP를 관리하면 그 업체에 조치 적용 여부를 확인하고 요청하라고 합니다.
판단 기준은 두 가지입니다. PHP를 누가 관리하는지, 그리고 내 홈페이지가 새 버전에서도 제대로 도는지 미리 시험해 볼 수 있는지입니다.
2. 패치와 버전 전환은 다른 일입니다
같은 줄 안에서 끝자리만 올리는 것과 8.2에서 8.3처럼 줄을 바꾸는 것은 무게가 다릅니다. 8.3.30을 8.3.36으로 올리는 것은 보안 수정판을 까는 패치이고, 8.2~8.5를 쓴다면 PHP2Shell 대응은 이쪽입니다.
8.1 이하에서 지원 버전으로, 또는 8.2에서 8.3 이상으로 옮기는 것은 버전 전환입니다. KISA는 8.1 이하는 지원 버전으로 전환하고, 2026년 12월 31일 보안 지원이 끝날 예정인 8.2도 8.3 이상으로 전환하라고 권장합니다.
버전 전환은 예전 코드가 그대로 돌지 않을 수 있어 준비가 더 필요합니다. 내 버전이 어디에 있는지 모르면 버전 확인부터 합니다.
3. 올리기 전에 테스트가 필요한 이유
php.net 마이그레이션 가이드는 새 버전마다 첫머리에 같은 취지의 문장을 둡니다. 8.4 가이드는 이렇게 적었습니다.
This new minor version brings with it a number of new features and a few incompatibilities that should be tested for before switching PHP versions in production environments.
새 기능과 함께 몇 가지 호환되지 않는 변경이 있으니, 실제 운영 중인 서버에서 바꾸기 전에 시험하라는 뜻입니다. KISA도 패치 적용이 호환성·안정성 문제로 서비스 장애를 일으킬 수 있으니 사전 영향도 검토와 테스트 뒤 적용하라고 권고했습니다.
4. 직접 할 때의 순서
KISA 수칙 2번이 적은 업데이트 순서는 이렇습니다. 인터넷에 공개된 서버부터 우선 조치하라고 했습니다.
- 해결 버전(8.5.12, 8.4.27, 8.3.36, 8.2.35 이상)으로 업데이트합니다
- PHP를 돌리는 웹 서비스(PHP-FPM, Apache mod_php 등)를 모두 재시작합니다. 컨테이너는 새 이미지로 다시 배포합니다
- 웹 서비스가 실제로 쓰는 PHP 버전이 바뀌었는지 확인합니다
재시작을 빼먹으면 메모리에 남은 이전 버전이 계속 돌아 여전히 취약하다고 KISA는 적었습니다. 테스트를 하려면 되돌릴 방법이 있어야 하므로, 시작 전에 파일과 DB 백업을 받아 두는 것이 안전합니다.
5. 맡길 때 받아 둘 것
호스팅 업체나 외주 업체에 맡길 때는 「해 주세요」로 끝내지 말고 결과를 받아 둡니다. 확인할 내용은 KISA 수칙에서 그대로 가져올 수 있습니다.
버전 번호가 그대로라면 리눅스 배포판 패키지에 패치만 들어간 경우일 수 있습니다. 이때는 패키지 변경 이력에 두 CVE가 반영됐는지 업체에 확인합니다. 8.1 이하라면 언제 지원 버전으로 옮길지 계획도 함께 받습니다.
6. 직접 할지 맡길지 고르는 기준
서버에 접속해 PHP를 설치하고 재시작해 본 경험이 있고, 시험해 볼 서버가 따로 있다면 직접 해도 됩니다. 그렇지 않다면 무리해서 운영 서버를 건드리기보다 관리하는 업체에 맡기는 편이 낫습니다.
어느 쪽이든 업데이트 뒤 웹 서비스가 실제로 쓰는 버전이 해결 버전 이상인지 확인하는 단계는 빼지 않습니다. KISA는 명령어로 보이는 버전과 웹 서비스가 쓰는 버전이 다를 수 있다고 적었습니다.
이 블로그를 운영하는 AiApp에서는 엠바스 외주로 기존 PHP 홈페이지의 점검과 버전 업그레이드, AiApp으로 옮기는 일을 맡길 수 있습니다. 상담은 견적 페이지에서 받습니다.
근본적으로는 AiApp으로 만든 사이트는 PHP로 돌아가지 않아 PHP2Shell 같은 PHP 취약점의 패치 대상이 아니고, 서버와 실행 환경의 보안 업데이트는 AiApp이 합니다.
정리하면 업그레이드는 이렇게 고릅니다.
- 호스팅 업체가 PHP를 관리하면 업체에 적용 여부를 확인하고 요청합니다
- 끝자리 패치와 버전 전환은 다릅니다. 전환은 마이그레이션 가이드를 보고 시험부터 합니다
- 직접 하면 업데이트, 모든 PHP 서비스 재시작, 실제 버전 확인 순서입니다
- 맡기면 바뀐 버전, 재시작과 CVE 반영, 테스트 결과를 받아 둡니다
PHP2Shell 대응 전체 순서는 PHP2Shell 조치 방법, 확인부터 패치까지에 있습니다. 옮길 버전을 고르려면 php 버전별 기능 차이, 8.2 지원 종료 전에를, 지금 버전을 알아보려면 php 버전 확인 방법, 3가지로 정리를 보세요.
참고자료 (모두 2026년 11월 4일 확인)
- KISA 보호나라 보안공지 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」(2026-10-22) — boho.or.kr
- 과학기술정보통신부 보도자료(2026-10-22) 「웹사이트 개발 언어 ‘PHP’ 보안 취약점 관련 긴급 보안 최신화 및 기술적 조치 당부」 — msit.go.kr
- PHP 매뉴얼 「Migrating from PHP 8.3.x to PHP 8.4.x」 — php.net/manual/en/migration84.php
- PHP 「Supported Versions」 — php.net/supported-versions.php
- AiApp 운영팀 확인(2026년 11월) — AiApp 사이트의 PHP 사용 여부와 서버 보안 업데이트
#PHP업그레이드 #PHP버전 #PHP2Shell #홈페이지유지보수 #홈페이지보안
