주요 내용
- PHP 확장 지원은 지원 종료(EOL)가 지난 PHP 버전에 대한 보안 패치를 역포트하여, 강제 마이그레이션 없이도 운영 중인 애플리케이션의 보안을 유지할 수 있도록 해줍니다.
- 확장 지원은 PHP 버전이나 애플리케이션의 동작에 영향을 주지 않습니다. 사용자가 원하는 일정에 따라 마이그레이션을 진행하는 동안, 알려진 보안 취약점을 해결해 줍니다.
- 2026년 8월 기준으로, PHP 8.1 및 그 이전 모든 버전은 지원 종료(EOL) 상태이며 커뮤니티 패치를 전혀 제공받지 못합니다. PHP 8.2, 8.3, 8.4, 8.5는 여전히 지원되고 있지만, 각 버전마다 정해진 지원 종료일이 있습니다.
- 확장 지원이 제공되지 않는 EOL PHP를 실행하면, CVE에 대한 패치가 적용되지 않아 감사 및 규정 준수 위험이 커지고, 공격 표면이 확대됩니다.
프로덕션 환경에서 PHP를 실행하는 경우, 지원 종료 문제는 여러분을 익숙하면서도 곤란한 상황에 빠뜨립니다. 수년 동안 손도 대지 않은 애플리케이션을 업그레이드할 것인가, 아니면 더 이상 보안 패치를 받지 못하는 런타임을 계속 사용할 것인가. 어느 쪽도 좋은 선택은 아닙니다.
PHP 확장 지원이 세 번째 방법입니다.
이 글에서는 확장 지원이 실제로 무엇을 포함하는지(그리고 무엇을 포함하지 않는지), 이를 생략할 경우 발생할 수 있는 규정 준수 및 CVE 관련 위험, 현재 확장 지원이 필요한 PHP 버전, 업그레이드와 비교하여 어떻게 판단해야 하는지, 그리고 2026년에 주목해야 할 제공업체들에 대해 다룹니다.
PHP 확장 지원이란 무엇인가요?
PHP 확장 지원은 PHP 프로젝트 자체의 지원이 종료된 후에도 해당 PHP 버전에 대한 보안 패치를 계속 제공하는 벤더의 서비스입니다. PHP 버전의 지원 종료(EOL) 시점이 되면, PHP 프로젝트는 해당 버전에 대한 지원을 완전히 종료합니다. 더 이상 CVE 수정 사항도, 패치도, 그 어떤 지원도 제공되지 않습니다.
확장 지원은 그 가능성을 다시 열어줍니다. 공급업체는 새로 공개된 취약점을 모니터링하고, 해당 수정 사항을 EOL 런타임에 역포트하므로, 사용자는 타인의 일정에 얽매이지 않고 자신의 일정에 맞춰 마이그레이션을 계획하는 동안에도 패치된 런타임에서 애플리케이션을 계속 실행할 수 있습니다.
PHP 릴리스 라이프사이클의 작동 방식
이제 PHP 릴리스는 4년 주기의 라이프사이클을 따릅니다. 즉, 2년간의 활성 지원 기간에 이어 2년간의 보안 지원 기간이 제공됩니다. 이러한 변경 사항은 2024년 3월 PHP 릴리스 주기가 개정되면서 도입되었으며, PHP 8.1 및 이후 버전에 적용됩니다. PHP 7.4 및 8.0과 같은 이전 버전은 2년간의 활성 지원과 1년간의 보안 지원으로 구성된 기존의 3년 주기를 유지합니다.
| 라이프사이클 단계 | 기간 | 제공 내용 |
| 적극적인 지원 | 처음 2년 | 버그 수정, 성능 개선, 보안 패치 |
| 보안 지원 | 향후 2년 | 중요한 보안 수정 사항만 |
| Lifecycle 종료 | 4년 후 | 아무것도 없습니다. 어떤 종류의 패치도 없습니다. |
각 PHP 버전의 위치는 다음과 같습니다:
| PHP 버전 | 출시됨 | Lifecycle 종료 | 현황 (2026년 8월) |
| 7.4 | 2019년 11월 | 2022년 11월 28일 | EOL – 커뮤니티 패치 없음 |
| 8.0 | 2020년 11월 | 2023년 11월 26일 | EOL – 커뮤니티 패치 없음 |
| 8.1 | 2021년 11월 | 2025년 12월 31일 | EOL – 커뮤니티 패치 없음 |
| 8.2 | 2022년 12월 | 2026년 12월 31일 | 보안 전용 (EOL: 2026년 말) |
| 8.3 | 2023년 11월 | 2027년 12월 31일 | 보안 전용 |
| 8.4 | 2024년 11월 | 2028년 12월 31일 | 2026년 12월 31일까지는 전체 지원이 제공되며, 그 이후에는 보안 지원만 제공됩니다. |
| 8.5 | 2025년 11월 | 2029년 12월 31일 | 적극적인 지원 |
알고 계셨나요? PHP 프로젝트는 이제 모든 지원 종료(EOL) 시점을 해당 연도의 12월 31일로 통일하고 있습니다. PHP 8.1은 이 연장된 주기의 혜택을 최초로 적용받은 버전으로, 지원 종료일이 2024년 11월에서 2025년 12월 31일로로 변경되었습니다.
PHP 확장 지원이 실제로 제공하는 것
확장 지원의 범위는 의도적으로 좁게 설정되어 있습니다. 이 지원의 목적은 지원 종료(EOL)된 PHP 버전의 보안을 유지하는 것이지, 이를 현대화하거나 리팩토링하거나 기능을 추가하는 것이 아닙니다. 확장 지원은 커뮤니티에서 더 이상 제공하지 않는 보안 패치를, 해당 런타임에 의존하는 애플리케이션의 정상 작동을 방해하지 않는 형태로 배포할 수 있도록 제공합니다.
현실 점검: 확장 지원은 업그레이드를 영원히 미룰 수 있는 면책권이 아닙니다. 이는 긴급한 상황 없이 마이그레이션을 진행할 수 있는 시간을 벌어주는 것입니다. 이를 최종 목적지가 아닌, 이륙을 위한 활주로로 여기십시오.
이전 버전으로 역이식된 보안 패치
핵심 서비스는 백포트입니다. 아직 지원 중인 PHP 브랜치에 새로운 CVE가 등록되면, 서비스 제공업체는 지원 종료(EOL) 버전이 영향을 받는지 분석한 후, 기존 런타임의 동작을 변경하지 않고 수정 사항을 해당 버전에 적용합니다. 사용자는 PHP 7.4 또는 8.1을 계속 사용하면서도 해당 취약점은 해결됩니다.
호환성 테스트 및 서비스 중단 없는 배포
백포트된 패치라도 애플리케이션의 안정성은 반드시 유지되어야 합니다. 훌륭한 PHP 확장 지원에는 EOL(지원 종료) 버전을 대상으로 한 회귀 테스트가 포함되어 있어, 수정 사항으로 인해 동작에 변화가 발생하지 않도록 합니다. 공급업체와 플랫폼에 따라 패치는 네이티브 패키지(리눅스의 경우 RPM 또는 DEB) 형태로 제공되며, 기존 패키지 관리자를 통해 설치할 수 있고, Windows의 경우 이에 상응하는 설치 프로그램을 통해 설치됩니다.
버전 및 OS 적용 범위
각 공급업체는 특정 운영 체제에서 특정 PHP 버전 세트를 지원합니다. 예를 들어, TuxCare의 PHP용 Endless Lifecycle Support(ELS)는 는 PHP 5.2부터 8.4까지를 지원하며, 각 버전이 EOL(지원 종료)에 도달하면(현재 5.2부터 8.1까지) Windows 및 AlmaLinux, CentOS, Ubuntu, Debian, Oracle Linux를 포함한 주요 리눅스 배포판 전반에 걸쳐 ELS 보안 패치를 적용합니다. 이주 과정이 원활하지 않은 EOL 런타임에 묶여 있는 경우, 이러한 공급업체 지원 패치 적용은 애플리케이션을 최신 런타임에 맞춰 즉시 재작성하지 않고도 CVE 취약점을 해결할 수 있는 몇 안 되는 방법 중 하나입니다.
참고: PHP 5.x에서 PHP 8.x로 업그레이드할 경우, 특히 제거된 언어 기능, 더 이상 사용되지 않는 API 또는 구형 프레임워크에 의존하는 애플리케이션의 경우 상당한 코드 수정이 필요할 수 있습니다.
확장 지원 없이 EOL PHP를 실행할 경우의 보안 및 규정 준수 위험
사이트는 정상적으로 로드되고, 결제 기능도 잘 작동하며, 로그도 문제없이 보입니다. 하지만 사용 중인 버전에 대한 새로운 CVE가 발견되어도 수정되지 않은 채 방치되면 위험은 서서히 커집니다. “아직은 잘 작동하니까”라는 생각은 함정입니다.
현재는 문제없이 실행되는 EOL 런타임은, 패치되지 않은 공개적으로 기록된 취약점 목록이 가장 긴 것이기도 한데, 이는 바로 공격자들이 찾아내는 대상입니다.
패치되지 않은 CVE 및 활발히 악용되고 있는 취약점
버전이 EOL(지원 종료) 상태가 되면, 해당 버전에 영향을 미치는 새로 공개된 취약점은 PHP 프로젝트 측에서 무기한으로 패치를 제공하지 않습니다. 공격자는 더 이상 수정 패치를 받지 않는 버전을 파악할 수 있으며, 백포트된 패치를 적용받지 못한 시스템에 대해서는 공개된 익스플로잇이 계속해서 작동합니다.
The 2026년 버라이즌 DBIR 보고서에 따르면, 취약점 악용이 현재 보안 침해 사고의 주요 초기 침입 경로로 부상했으며, 전체 사례의 31%를 차지해 전년 보고서에서 기록된 20%보다 증가한 것으로 나타났습니다. 취약점 악용이 자격 증명 도용 및 피싱을 제치고 1위를 차지한 것은 이 보고서가 발간된 지 19년 만에 처음 있는 일입니다. 실제 PHP CVE 사례들이 이를 구체적으로 뒷받침합니다. 지원 종료(EOL) 이후의 PHP 7 취약점(CVE-2023-0568)에 대한 분석 자료와, CVSS 9.8 등급을 받은 CGI 인자 주입 결함인 CVE-2024-4577을 참고하십시오. 이 결함은 CISA의 ‘알려진 악용 취약점(Known Exploited Vulnerabilities)’ 목록에 등재되었으며, Windows 기반 PHP 환경에 심각한 타격을 입혔습니다. 더 광범위한 경향에 대해서는 이 PHP 취약점 개요에서 다루고 있습니다. 백포트 소스 코드가 없는 경우, 업그레이드가 일반적으로 근본적인 결함을 제거할 수 있는 유일한 신뢰할 수 있는 방법입니다.
규정 미준수
보안 및 규정 준수 프레임워크는 일반적으로 조직이 취약점을 파악하고, 위험을 관리하며, 정해진 기간 내에 보안 업데이트를 적용할 것을 요구합니다. PCI DSS 는 패치 적용 및 취약점 관리에 대한 명확한 요구 사항을 규정하고 있는 반면, HIPAA, SOC 2, 그리고 FedRAMP 는 모두 위험 분석과 통제 평가를 통해 동일한 기준에 도달합니다. 상류에서 더 이상 수정 패치를 제공받지 못하는 소프트웨어를 실행할 경우, 백포트된 패치의 출처가 문서화되어 있고 이를 입증할 증거가 없는 한 이러한 의무를 이행하기가 더 어려워집니다.
다음에 따르면 IBM의 ‘2026년 데이터 유출 비용 보고서’에 따르면에 따르면, 전 세계 데이터 유출 사고의 평균 비용은 전년 대비 12% 증가하여 사상 최고치인 499만 달러를 기록했습니다. 확장 지원 서비스를 이용하면 일관된 취약점 평가 및 패치 적용 프로세스를 입증하는 패치 기록과 수정 일정을 제공할 수 있습니다. 규제 대상 환경에서는 이와 별도로 예를 들어 검증된 암호화 모듈에 대한 와 같은 검증된 암호화 모듈에 대한 규정 준수 등—이 있지만, 특히 패치 문제와 관련해서는 패치가 실제로 존재할 때 깨끗한 기록을 작성하는 것이 훨씬 더 용이합니다.
공급망 및 의존성 위험
PHP는 거의 단독으로 실행되지 않습니다. 앱은 Composer 패키지, 확장 기능, 그리고 그 기반이 되는 OS를 활용하며, 어느 계층에서든 취약점이 발견되면 이는 사용자의 문제가 됩니다. 지원 종료(EOL)된 PHP 런타임은 종종 지원 종료된 OS 및 오래된 종속성들과 함께 존재하여 공격 표면을 더욱 확대시킵니다.
현재 어떤 PHP 버전에 대해 확장 지원이 필요한가요?
PHP 8.1 이하 버전을 사용 중이며 당장 업그레이드할 수 없는 경우, 백포트된 보안 패치를 안정적으로 확보할 수 있는 출처가 필요합니다. 해당 버전들은 2026년부터 커뮤니티 차원의 보안 패치를 전혀 제공받지 않게 되므로, 해당 버전에 영향을 미치는 새로 공개된 취약점은 PHP 프로젝트 측에서 수정하지 않을 것입니다.
PHP 7.4가 가장 시급한 사례입니다. 해당 버전은 2022년 11월에 지원 종료(EOL)가 되었으므로, 따라서 커뮤니티 패치가 제공되지 않은 지 거의 4년이 지났습니다. 이 버전에서 마이그레이션하려면 상당한 의존성, 호환성 및 테스트 작업이 수반될 수 있기 때문에 여전히 수많은 운영 환경에서 사용되고 있습니다. PHP 8.0도 마찬가지입니다도 2023년 말 지원 종료(EOL)를 맞이했으며, PHP 8.1도 2025년 말에 2025년 말에 그 대열에 합류했습니다.
PHP 8.2와 8.3은 보안 전용 모드에 있으며, 여전히 패치를 받고 있지만 지원 종료 시한이 다가오고 있습니다. PHP 8.2는 2026년 12월 31일에 지원이 종료되며, PHP 8.3은 그로부터 1년 후에 지원이 종료됩니다. 달력에 PHP 8.2의 지원 종료일을 표시해 두세요. 2026년 12월 31일 이후에는 해당 브랜치에 대해 PHP 프로젝트에서 보안 패치를 더 이상 제공하지 않습니다. 관련 위험 요소와 선택 사항에 대한 자세한 내용은 PHP 8.2 EOL 가이드 에서 자세히 다루고 있습니다.
현재 활발히 지원되고 있는 두 가지 버전은 PHP 8.4와 8.5이며, 8.4는 2026년 말에 보안 업데이트만 제공되는 단계로 전환됩니다. 확장 지원은 감사팀이나 리스크 관리팀이 요구하는 일정에 맞춰 7.4, 8.0 또는 8.1에서 업그레이드할 수 없는 팀을 위한 것입니다.
PHP 연장 지원 vs. 버전 업그레이드: 어떻게 선택할까
업그레이드는 장기적으로 볼 때 올바른 해결책입니다. 당장 업그레이드하는 것이 무모한 상황이라면, 지원 기간 연장이 단기적으로 볼 때 올바른 해결책입니다. 결정은 지원되는 버전으로 전환하기까지 얼마나 많은 마이그레이션 작업이 남아 있는지, 그리고 그 기간 동안 얼마나 큰 위험을 감수해야 하는지에 달려 있습니다.
잘 관리된 애플리케이션이라면, 의존성 및 비추천 기능 관련 작업을 최소화하면서 PHP 8.1에서 현재 지원되는 버전으로 마이그레이션할 수 있지만, 이에 소요되는 노력은 사용하는 프레임워크, 확장 기능, 테스트 커버리지에 따라 달라집니다. 수정되지 않은 코드 20만 줄과 더 이상 유지보수되지 않는 의존성을 가진 레거시 7.4 애플리케이션을 PHP 8.4로 마이그레이션하는 것은 단 몇 시간 만에 끝낼 수 있는 일이 아니라, 본격적인 프로젝트입니다. 이러한 격차를 과소평가할 경우 발생하는 대가는 실재합니다.
현장의 목소리: 단 한 번의 업그레이드만으로는 라이프사이클 리스크를 영구적으로 해결할 수 없습니다. 몇 년 전 7.4에서 8.0으로 업그레이드한 후 작업을 완료했다고 여기고 다음 단계를 전혀 계획하지 않았던 팀들은 이제 또 다른 EOL(지원 종료) 브랜치에 갇혀 있습니다. “이미 한 번 업그레이드했으니까”라는 생각은 결국 두 번이나 EOL 상황에 처하게 만드는 지름길입니다.
다음 내용을 참고하여 결정하세요:
| 시나리오 | 권장 접근 방식 |
| 8.1 버전, 최신 의존성, 소규모 코드베이스 | 지금 바로 활발히 지원 중인 버전, 가급적이면 PHP 8.4 또는 8.5로 업그레이드하세요. |
| 7.4 또는 8.0 버전, 대규모 레거시 애플리케이션, 테스트 커버리지 없음 | 지원 기간을 연장한 뒤 단계적으로 마이그레이션 |
| 감사 마감 기한이 임박했으나 마이그레이션이 완료되지 않았습니다 | 마이그레이션 기간 동안 규정 준수를 유지하기 위한 확장 지원 |
| 공급업체가 업데이트하지 않은 타사 앱 | 공급업체가 수정 프로그램을 출시할 때까지 지원 기간 연장 |
PHP 확장 지원 서비스 제공업체 상위 3곳
소수의 공급업체들이 지원 종료(EOL)된 PHP에 보안 수정 사항을 역포트하고 있습니다. 이들 업체는 지원 대상 버전, 패치 제공 방식, 그리고 고객에게 제공하는 규정 준수 문서 측면에서 차이가 있습니다. 다음은 비교해 볼 만한 세 곳의 업체입니다. 아래의 지원 범위 목록은 2026년 8월 기준 각 공급업체가 공개한 정보를 반영한 것이므로, 구매 전에 해당 공급업체에 문의하여 최신 지원 범위를 확인하시기 바랍니다.
TuxCare
TuxCare의 PHP를 위한 ‘Endless Lifecycle Support’ 단일 저장소를 통해 PHP 5.2부터 8.4까지를 포괄하며, 각 브랜치가 EOL(지원 종료)에 도달할 때마다 ELS 보안 패치가 적용됩니다. 현재 5.2부터 8.1까지 지원되며, 8.2, 8.3, 8.4는 각 버전의 EOL 날짜가 도래함에 따라 순차적으로 지원될 예정입니다. 패키지는 Windows 및 주요 Linux 배포판을 위해 공급업체에서 직접 빌드하고 보안 패치를 적용한 것으로, 출시 전 회귀 테스트를 거치며, 런타임 교체나 애플리케이션 재빌드를 강요하지 않고 기존 패키지 관리자를 통해 설치됩니다.
cPanel을 통해 여러 PHP 사이트를 관리하는 팀의 경우, TuxCare의 PHP ELS는 지원되는 cPanel 환경에서 PHP Selector와 연동되어, 명령줄을 사용할 필요 없이 관리 인터페이스에서 사이트별로 PHP 버전을 설정할 수 있게 해줍니다.
Perforce의 Zend
Zend는 수년 동안 PHP에 대한 상용 지원을 제공해 왔으며, PHP 생태계에서 오랜 역사를 가진 벤더의 지원을 바탕으로 EOL(지원 종료) 버전에 대한 장기 지원 런타임을 제공합니다. 지원 범위는 특정 버전에 집중되어 있습니다. 현재 Zend는 PHP LTS 서비스에 PHP 7.2, 7.3, 7.4 및 8.1을 포함하고 있습니다. 이는 이미 Zend 툴셋이나 Laminas를 표준으로 채택한 팀에게 신뢰할 만한 선택지입니다.
HeroDevs
HeroDevs는 Perforce 산하의 Zend와의 파트너십을 통해 PHP 장기 지원 서비스를 제공하며, ZendPHP 런타임에 자사의 ‘Never-Ending Support’ 구독 서비스, SLA 및 규정 준수 문서를 결합합니다. 지원 범위는 PHP 7.2, 7.3, 7.4, 8.0, 8.1 및 8.2를 포함하며, 주요 리눅스 배포판과 Windows용 네이티브 패키지 형태로 제공됩니다.
PHP 지원 종료(EOL)에 대비하여 보안 위험을 방지하고 규정 준수 상태를 유지하세요
EOL(지원 종료)된 PHP는 별도의 공지 없이 지원이 종료됩니다. 공격자가 해당 브랜치에서 패치되지 않은, 공개적으로 문서화된 취약점을 악용할 때까지 계속해서 트래픽을 처리합니다. 확장된 PHP 지원은 이러한 보안 공백을 메워줍니다. 즉, 애플리케이션이 의존하는 런타임 환경을 계속 사용할 수 있고, 해당 취약점에 대한 수정 사항이 역포트되어 적용되며, 강제로 마이그레이션해야 하는 상황이 아닌, 안전한 시점에 마이그레이션을 진행할 수 있습니다.
PHP 7.4, 8.0 또는 8.1을 사용 중이며 당장 업그레이드하기 어려운 경우, 마이그레이션을 계획하는 동안 백포트된 패치를 적용하여 기존 런타임의 보안을 강화하십시오. TuxCare의 Endless Lifecycle Support(ELS) 은 현재 5.2부터 8.1까지의 모든 EOL(지원 종료) 브랜치를 지원하며, 각 버전이 EOL 날짜에 도달함에 따라 8.2, 8.3, 8.4에 대해서도 동일한 지원 범위를 확대해 나갈 것을 약속합니다.
자주 묻는 질문
아닙니다. 확장 지원은 보안 패치를 기존 버전에 역포트합니다. PHP는 동일한 버전 번호를 유지하며 예상되는 동작도 그대로 유지되는 한편, 해당 취약점에 대해서는 역포트된 수정 사항이 적용됩니다. 해당 런타임에 의존하는 애플리케이션은 버전 업그레이드 없이도 계속 실행될 수 있습니다.
“PHP 확장 지원 레벨 1”은 표준 PHP 지원 등급이라기보다는 호스팅 제공업체의 청구 명칭에 가깝습니다. GoDaddy의 웹 호스팅(cPanel) 및 웹 호스팅 플러스 요금제에서 PHP 확장 지원은 CloudLinux와의 파트너십을 통해 제공되는 유료 부가 서비스로, 지원 종료(EOL)된 PHP 버전을 여전히 실행 중인 사이트에 보안 패치를 제공하며, 갱신 시 별도 항목으로 표시됩니다. 구독 중인 요금제의 정확한 적용 범위와 가격은 호스팅 업체의 설명서를 확인하시기 바랍니다.
네. PHP 7.4는 2022년 11월에 지원 종료(EOL)되었지만, TuxCare를 비롯한 여러 공급업체들은 연장된 수명 주기 지원을 통해 계속해서 보안 패치를 제공하고 있습니다. 7.4는 2022년부터 지원이 종료된 상태이므로, 아직 마이그레이션을 완료하지 못한 조직들에게 있어 여전히 가장 중요한 연장 지원 활용 사례 중 하나입니다.
패치 제공 일정은 공급업체마다 다르며, 처리 범위도 마찬가지입니다. 계약서에 서명하기 전에 다음 세 가지를 확인하세요. 공개된 심각도 기준(대부분의 공급업체는 심각도 ‘높음’ 및 ‘치명적’인 CVE, 일반적으로 CVSS 7.0 이상에 대해 대응을 약속하며, 심각도 ‘중간’인 문제는 사례별로 처리합니다), 심각도 ‘높음’인 취약점에 대한 명시된 처리 목표 기간, 그리고 SLA를 맹신하지 않고 직접 CVE별 상태를 확인할 수 있도록 공개된 CVE 추적 도구입니다.
도움이 될 수 있습니다. 감사관들은 귀사의 소프트웨어에 패치가 적용되었으며, 반복 가능한 패치 프로세스가 마련되어 있다는 증거를 원하는데, 연장 지원 서비스는 패치와 관련 기록을 모두 제공합니다. 다만, 연장 지원 서비스만으로는 PCI DSS 준수, SOC 2 적합성 또는 감사 통과를 보장하지는 않습니다. 이는 귀사의 전체 통제 환경에 달려 있습니다.
이는 현재 어떤 상황에서 시작하느냐에 따라 다릅니다. 더 이상 유지보수되지 않는 종속성을 포함하고 있는 대규모 레거시 앱의 경우, 단기적으로는 긴급 마이그레이션보다 연장 지원이 훨씬 비용이 적게 듭니다. 반면, 버전이 한두 개 뒤처진 소규모 앱의 경우, 직접 업그레이드하는 것이 비용 대비 더 효율적인 경우가 많습니다.




