PHP 8.3 지원 종료: 주요 일정, 위험 요소 및 향후 조치

주요 내용

• PHP 8.3은 2027년 12월 31일에 지원 종료되며, 이후에는 보안 업데이트나 공식 지원을 더 이상 받지 못합니다.
• 지원 종료(EOL) 이후에도 PHP 8.3을 계속 사용하면, 애플리케이션이 패치되지 않은 취약점에 노출되고 보안 위험이 커지게 됩니다.
• 최신 PHP 버전으로 업그레이드하는 것이 가장 안전한 방법이지만, 기존 코드와 종속성 때문에 마이그레이션 속도가 느려지는 경우가 많습니다.
• TuxCare의 Endless Lifecycle Support(ELS)는 EOL 이후에도 PHP 8.3에 대한 패치를 지속적으로 제공하므로, 고객은 본인의 일정에 맞춰 업그레이드할 수 있습니다.

PHP 8.3은 2027년 12월 31일에 지원 종료(EOL)됩니다. 해당 날짜 이후에는 PHP 프로젝트에서 이 버전에 대한 보안 패치 제공을 중단합니다. 지원 종료 후 PHP 8.3과 관련된 CVE가 공개되면, 해당 버전을 여전히 실행 중인 모든 서버에서 이는 영구적이고 해결할 수 없는 취약점으로 남게 됩니다. 이는 결코 가상의 시나리오가 아닙니다. 업그레이드가 필요하다는 사실을 인지한 시점과 실제로 업그레이드를 완료하는 시점 사이의 간극이야말로 조직들이 피해를 입게 되는 지점입니다.

이 글에서는 PHP 8.3의 지원 종료(EOL)가 실제로 무엇을 의미하는지, 지원이 종료되면 운영 환경에 어떤 변화가 발생하는지, 그리고 PHP 인프라를 안전하고 규정 준수 상태로 유지하기 위해 활용할 수 있는 방안들에 대해 다룹니다.

PHP 지원 주기의 이해

2024년 3월, PHP 프로젝트는 릴리스 주기를 3년에서 4년으로 연장했습니다. 이제 각 브랜치는 2년간의 적극적인 지원을 받은 후, 2년간의 보안 지원만 제공받으며, 그 후 지원 종료 단계에 이르게 됩니다.

• 적극적인 지원: 출시 후 첫 2년 동안 PHP 프로젝트는 버그 수정, 보안 패치 및 일반 유지보수 업데이트를 제공합니다. 이는 포괄적인 지원입니다.
• 보안 전용 지원: 정기 지원이 종료된 후에도 해당 브랜치는 2년 동안 제한적인 지원을 받게 되며, 확인된 중대한 보안 취약점만 패치됩니다. 그 외에는 지원되지 않습니다.
• 지원 종료: 어떤 종류의 보안 수정도 제공되지 않습니다. 해당 버전은 상류 프로젝트에서 지원이 중단되었습니다.

이러한 라이프사이클 패턴은 웹 보안, 규정 준수 현황, 유지보수 계획에 동등한 비중으로 영향을 미칩니다. 흔히 저지르는 실수는 EOL을 미래의 문제로만 여기는 것인데, 정작 그 시점이 도래했을 때는 이미 뒤처진 상태가 되어버립니다. 이러한 역학은 전체 스택에 걸쳐 동일하게 적용되므로, 운영 체제의 수명 종료 상황에도 어떤 영향을 미치는지 이해해 두는 것이 좋습니다.

PHP 8.3 지원 종료: 주요 일정 및 고려 사항

PHP 8.3은 2023년 11월 23일에 출시되었습니다. 전체 지원 일정은 다음과 같습니다:

2025년 12월 31일을 기점으로 정식 지원이 종료되었습니다. 즉, PHP 8.3은 이미 보안 업데이트만 제공되는 단계에 접어들었습니다. 현재 이 버전을 사용 중이라면 이미 지원이 축소된 상태이며, 완전한 지원 종료(EOL)까지 남은 시간이 점점 줄어들고 있습니다.

이번 상황의 시급성은 PHP 7.4, PHP 8.2, PHP 8. 1의 지원 종료(EOL)를 맞이했던 팀들이 겪었던 상황과 유사합니다. 동인은 같지만 버전 번호만 다를 뿐이죠. 다양한 버전에 걸친 PHP 지원 종료 현황을 종합해 보면 한 가지 분명한 사실이 드러납니다. 이는 단순히 한 번만 극복하면 되는 상황이 아니라, 이를 대비한 프로세스를 구축할 가치가 있는 반복적인 운영 패턴이라는 점입니다.

계획 실행 조건: 2027년 12월 이전에 업그레이드 일정을 현실적으로 완료할 수 있다면, 지금 바로 시작해야 합니다. 레거시 시스템과의 종속성, 애플리케이션의 복잡성, 또는 리소스 제약 등으로 인해 불가능하다면, 결정을 내리기 전에 해결 방안 섹션을 읽어보시기 바랍니다.

PHP 8.3의 지원 종료(EOL)가 되면 어떻게 되나요?

지원 종료(EOL) 날짜가 지나면 PHP 프로젝트는 8.3 버전에 대한 지원을 완전히 종료합니다. 패치도, 보안 권고도, 이전 버전으로의 기능 이식도 더 이상 제공되지 않습니다. 2027년 말에 PHP 8.3에 영향을 미치는 심각한 원격 코드 실행 취약점이 발견된다면? 이는 업스트림의 도움 없이 여러분이 직접 해결해야 할 문제입니다. 실제 상황에서는 다음과 같이 전개됩니다.

수정되지 않은 취약점이 쌓여가고 있지만 해결 방안은 보이지 않는다

PHP의 취약점은 지원 종료(EOL) 이후에도 계속 발견됩니다. 연구자들은 여전히 취약점을 찾아내고 이를 공개하지만, 8.3 버전에서는 더 이상 수정되지 않습니다. 이를 완화할 수 있는 메커니즘이 없기 때문에, 시간이 지날수록 환경의 보안 위험은 점점 커집니다.

실제 운영 환경에서는 다음과 같은 양상으로 전개됩니다. 취약점 스캐너가 PHP 8.3을 지원 종료(EOL) 상태로 표시하고, 이에 패치되지 않은 CVE를 연결하기 시작합니다. 초기에는 해당 목록이 짧지만, 6개월이 지나면 목록이 늘어납니다. 1년이 지나면 일부 CVE에 대한 공개 익스플로잇 코드가 자동 스캔 도구에 통합되는데, 이로 인해 공격 방식이 표적형에서 기회주의적 형태로 전환됩니다. 광범위한 PHP 익스플로잇 스캔을 수행하는 공격자는 사용자의 특정 애플리케이션에 대해 아무것도 알 필요가 없습니다.

지원 종료(EOL) 후 1년이 지난 구형 PHP 8.3 코드베이스를 운영하는 중견 규모의 SaaS 기업은 가상의 위험 시나리오가 아닙니다. 이는 알려진 취약점이 존재하고 패치가 적용되지 않았으며, 해결책조차 없는 상태로 스캔 결과에 나타나는 서버입니다. 보안 팀은 해결할 수 없는 문제를 분류하는 데 시간을 낭비하게 됩니다. 위험 관리 목록에는 영구적으로 미해결 사항이 남아 있게 됩니다. 이것이 바로 실제 운영 비용입니다.

규정 준수 체계가 이를 감지할 것입니다

PCI DSS, SOC 2, HIPAA, ISO 27001 – 이 모든 표준은 소프트웨어를 알려진 취약점으로부터 보호할 것을 요구합니다. 지원 종료(EOL)된 PHP를 사용하는 것은 이러한 표준 대부분에서 명백하고 입증 가능한 위반 사항이며, 규정 준수 자동화 도구를 통해 별도의 점검 없이도 해당 문제가 드러나게 됩니다. 다음 보안 감사가 진행될 때, 감사관은 이에 대한 시정 계획을 요구할 것입니다.

“인식하고 있으며 해결 중입니다”라는 답변은 한시적인 해결책에 불과합니다. 규제 대상 산업에서 운영 중인 소프트웨어의 수명 종료(EOL)는 규정 준수 인증 갱신을 지연시키고, 공급업체 보안 설문조사에서 문제가 될 수 있습니다. SOC 2 또는 PCI DSS 관련 문서를 요구하는 기업 고객을 대상으로 하는 업체의 경우, 이는 거래 성사를 가로막는 요인이 될 수 있습니다.

또한 PHP 확장 지원에 관한 당사의 상세 가이드에서 공급업체들이 보안 패치 및 감사 요건을 어떻게 처리하는지 살펴보실 수 있습니다.

버그와 회귀 현상은 전적으로 여러분의 책임입니다

지원 종료(EOL) 이후에는 PHP 8.3에서 발생하는 모든 문제를 업스트림의 도움 없이 직접 디버깅해야 합니다. 활성 버전에서라면 패치되었을 법한 극단적인 상황에서 발생하는 호환성 문제라도? 수정 패치는 제공되지 않습니다. 런타임과 제대로 호환되지 않는 라이브러리로 인해 성능이 저하된다면? 직접 원인을 찾아내야 합니다.

시간이 지날수록 이러한 문제는 누적됩니다. 상류(upstream)에서는 한 줄짜리 패치로 해결될 수 있었던 문제를 디버깅하는 데 엔지니어링 시간이 소모됩니다. 코드베이스에는 임시 해결책이 쌓여갑니다. 패치가 백포트(backport) 없이 최신 버전에만 적용됨에 따라, PHP 8.3의 동작과 문서화된 PHP 동작 간의 차이는 점점 더 벌어집니다. EOL(지원 종료) 이후 18~24개월이 지나면, 이러한 유지보수 부담으로 인해 결국 마이그레이션을 진행하는 것이 초기 단계에 비해 훨씬 더 어렵고 비용이 많이 들게 됩니다.

PHP 8.3으로의 업그레이드가 겉보이는 것보다 더 복잡한 이유

지원되는 최신 버전으로 업그레이드하는 것이 올바른 선택임은 의심의 여지가 없습니다. 하지만 직접적으로 다뤄볼 필요가 있는 점은, 애초에 왜 그렇게 많은 팀이 지원 종료된 PHP 버전을 계속 사용하게 되는가 하는 것입니다. 이는 단순히 게을러서 그런 경우는 거의 없기 때문입니다. 실제로 해결해야 할 장애 요인들이 존재하기 때문입니다.

의존성 호환성

제법 규모가 있는 PHP 애플리케이션이라면 프레임워크, 라이브러리, CMS 플러그인, 내부 패키지 등 의존성 체인을 가지고 있습니다. 이 중 모든 구성 요소가 최신 PHP 버전을 지원하는 것은 아닙니다. 최신식이고 관리가 잘 되는 프레임워크에서 멀어질수록 이 문제는 더욱 심각해집니다.

자체 개발 의존성을 사용하는 Laravel 애플리케이션은 대체로 원활하게 마이그레이션될 것입니다. 반면, 2019년부터 유지보수가 중단된 프레임워크를 기반으로 한 20만 줄 규모의 맞춤형 PHP 코드베이스나, 유지보수 수준이 제각각인 40개의 플러그인이 포함된 WordPress 스택의 경우, 마이그레이션 범위를 추정하기 전에 먼저 철저한 의존성 검토를 거쳐야 합니다. 그리고 이러한 검토 과정을 통해 초기에는 눈에 띄지 않았던 장애 요인들이 확실하게 드러나게 됩니다.

또한 Laravel 보안에 관한 당사의 상세한 가이드에서 PHP 프레임워크 보안을 위한 모범 사례를 살펴보실 수 있습니다.

패턴은 늘 비슷합니다. 팀들은 초기 호환성 검사를 수행하고, 눈에 띄는 문제들을 찾아 해결한 뒤, 다시 검사를 진행하면 또 다른 문제들이 발견되며, 결국 일주일 정도면 끝날 줄 알았던 마이그레이션 작업이 3개월짜리 프로젝트라는 사실을 깨닫게 됩니다. 지원 종료(EOL)된 런타임과 구식 종속성들은 단순히 공존하는 데 그치지 않고, 서로의 위험성을 더욱 증폭시킵니다.

애플리케이션 코드 수정 필요

PHP 8.4에서는 8.3에서 문제없이 실행되던 코드가 더 이상 작동하지 않게 만드는 사용 중단 예정 기능과 동작 변경 사항이 도입되었습니다. 암시적 null 허용 매개변수, 특정 배열 함수의 동작, 그리고 일부 내부 API 인터페이스가 변경되어, 단순히 런타임 버전을 업그레이드하는 것만으로는 부족하며 명시적인 코드 수정이 필요합니다.

CI 환경에 현대적인 코드베이스, 활발한 테스트 커버리지, 정적 분석 도구가 이미 구축된 팀이라면 이 과정은 충분히 관리 가능합니다. Rector를 실행하고, 발견된 문제를 수정하며, 테스트 스위트로 검증한 뒤 배포하면 됩니다. 하지만 레거시 코드베이스에 커버리지가 낮고, 정적 분석 도구가 없으며, 소수의 엔지니어링 조직이 여러 제품 기능을 동시에 출시하려 애쓰는 팀에게는 이는 명백한 자원 갈등을 초래합니다. 제대로 테스트할 수 없는 부분은 안전하게 마이그레이션할 수 없습니다.

표시된 모든 비추천 기능을 처리한 후에도, 실제 운영 환경에서의 동작이 눈에 띄지 않게 변경되지 않았다는 확신이 필요합니다. 이러한 확신을 얻기 위해서는 테스트가 필수적입니다. 테스트 범위가 부족할 경우, 계획된 마이그레이션이 사고로 이어질 수 있습니다.

시기적 요인과 운영 리스크

프로덕션 환경에서의 PHP 버전 업그레이드는 실질적인 위험을 수반합니다. 철저한 테스트를 거친 마이그레이션조차도 실행 시 예상치 못한 문제를 일으킨 사례가 있습니다. 스테이징 환경에서는 드러나지 않았던 극단적인 사례, 트래픽이 많은 경로에서 발생하는 문제, 새로운 런타임 버전에서 다르게 동작하는 타사 통합 기능 등이 그 예입니다.

주요 기능 출시 주기를 진행 중인 40명 규모의 SaaS 팀은 이러한 위험을 쉽게 감당할 수 없습니다. 제품 수명 종료(EOL) 마감일은 스프린트 주기나 분기별 사업 계획과 맞지 않습니다. 그 결과, “다음 분기에 하자”라며 작업을 미루게 되고, 결국 마감일이 코앞으로 다가와 압박 속에서 서둘러 마이그레이션을 진행해야 하는 상황이 벌어집니다. 이는 버전 업그레이드를 수행하기에 최악의 시기입니다.

PHP 8.3 지원 종료에 대비한 주요 해결 방안

정답은 하나만 있는 것이 아닙니다. 어떤 방식이 적합한지는 코드베이스의 복잡성, 팀의 역량, 위험 감수 능력, 그리고 2027년 12월까지 남은 기간에 따라 달라집니다. 다음은 가장 시급한 것부터 장기적인 것까지 순서대로 정리한 세 가지 현실적인 대안입니다.

결정 프레임:

• 팀이 EOL 전에 전체 업그레이드를 완료할 수 있다면, 바로 해결책 #2로 넘어가십시오.
• 일정이 불확실하거나 제품 수명 주기(EOL)를 초과하는 경우, 솔루션 #1을 우선 시작하고 솔루션 #2를 병행하여 실행하십시오.
• 애플리케이션에 구조적 부채가 있어 PHP 8.4로의 마이그레이션 비용이 재구축 비용과 거의 비슷하다면, 자원을 투입하기 전에 솔루션 #3을 검토해 보십시오.

해결 방법 1: 무제한 라이프사이클 지원 이용

TuxCare의 PHP용 Endless Lifecycle Support(ELS)는 공식 지원 종료(EOL)일 이후에도 PHP 8.3용 백포트된 보안 패치를 제공합니다. 이를 통해 마감 기한의 압박 속에서 서둘러 업그레이드할 필요 없이, 고객님의 일정에 맞춰 마이그레이션을 진행하는 동안 환경을 최신 패치로 유지하고 CVE 목록을 효율적으로 관리할 수 있습니다. TuxCare의 PHP ELS는 Windows 및 Linux 시스템에서 지원이 종료된 광범위한 PHP 버전(5.2, 5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3, 그리고 8.4(이 버전 또한 지원 종료 시점에 도달할 경우)를 포함합니다.

2027년 12월 이전에 업그레이드를 완료하기 어려운 경우, 신중한 단계별 마이그레이션 작업이 필요한 복잡한 코드베이스를 보유하고 있는 경우, 또는 전환 기간 동안 타당하게 입증할 수 있는 보안 및 규정 준수 상태를 유지해야 하는 경우, 이 옵션이 적합합니다.

ELS는 영구적인 해결책은 아닙니다. 결국에는 마이그레이션을 진행해야 합니다. 하지만 ELS를 사용하면, 수정되지 않은 CVE 목록이 늘어나고 해결 방안도 없는 상태에서 패치되지 않은 PHP를 프로덕션 환경에서 계속 운영해야 하는 상황을 막을 수 있습니다.

CVE 트래커를 방문하여 지원 종료된 PHP 버전에 영향을 미치는 취약점을 확인하고, TuxCare의 ELS를 통해 패치를 제공받을 수 있는지 확인해 보세요.

해결 방법 2: PHP 8.4 또는 PHP 8.5로 업그레이드하기

PHP 8.5는 2029년 12월까지 공식 지원이 제공되는 안정적인 업그레이드 대상입니다. 버전 8.3의 바로 다음 릴리스 브랜치인 PHP 8.4는 2028년 12월까지 지원됩니다. 두 버전 모두 PHP 8.3에서는 더 이상 제공되지 않는 보안 업데이트, 버그 수정 및 유지보수 등 완전한 업스트림 지원을 제공합니다.

실천해야 할 단계:

• 실행 php -l 전체 코드베이스에서 구문 오류를 찾아내기 위해
• 가능한 경우 Rector를 사용하여 더 이상 사용되지 않는 패턴을 자동으로 수정하십시오
• 호환성 문제로 인해 발생 가능한 차단 요인을 확인하기 위해 종속성 트리를 검토하십시오
• 실제 환경에 배포하기 전에 새로운 런타임 환경에서 전체 테스트 스위트를 실행하십시오
• 가능한 한 단계적으로 이전하세요. 모든 것을 한꺼번에 옮길 필요는 없습니다.

아직 시작하지 않았다면 지금 바로 시작하세요. 성공하는 팀들은 체계적으로 진행할 수 있을 만큼 충분한 여유를 가지고 시작한 팀들입니다. 반면 실패하는 팀들은 2027년 3분기에야 시작하여, 예상치 못한 상황에 대처할 여지조차 없이 마감 기한의 압박 속에서 업무를 수행하려 애쓰는 팀들입니다.

해결책 3: 전면 재구축 또는 프레임워크 마이그레이션 검토

PHP 8.4로 업그레이드하는 데 어차피 상당한 수준의 코드 재작성이 필요하다면, PHP로의 집중적인 마이그레이션과 다른 런타임 환경으로의 광범위한 아키텍처 투자를 정직하게 비용 면에서 비교해 볼 필요가 있습니다. 이는 모든 팀에게 적합한 선택은 아니지만, PHP 버전 문제가 더 근본적인 기술적 부채의 한 증상에 불과한 애플리케이션의 경우, 지원 종료(EOL)가 결국 더 큰 규모의 프로젝트 예산을 정당화할 수 있는 결정적 계기가 될 수 있습니다.

제품 지원 종료(EOL)의 시급함 때문에, 근본적인 유지보수 부담은 그대로 둔 채 비용이 많이 드는 마이그레이션으로 내몰리지 마십시오. 이 작업에 상당한 엔지니어링 자원을 투입할 계획이라면, 단순히 시간을 벌기만 하는 것이 아니라 향후 활용 가치를 확보할 수 있도록 해야 합니다.

TuxCare와 함께 PHP 8.3 지원 종료 후에도 시스템 보안을 유지하세요

PHP 8.3의 지원 종료(EOL)는 미리 대비할 수 있는 마감일입니다. 문제가 발생하는 팀은 이 문제를 타인의 미래 문제로 치부하다가, 결국 자신들의 당면한 긴급 사안이 되어버릴 때까지 방치하는 팀들입니다.

원활한 마이그레이션을 위해 더 많은 시간이 필요하다면, TuxCare의 ‘Endless Lifecycle Support’를 통해 현실적인 일정에 맞춰 업그레이드를 진행하는 동안 PHP 8.3에 대한 패치 적용 및 감사 준비를 유지할 수 있습니다. 또한 스택의 여러 부분에서 EOL(지원 종료) 위험을 관리하고 계신다면, TuxCare의 ELS는 .NET, Node.js, Angular, React, Vue를 포함한 광범위한 언어와 라이브러리를 지원하므로, 다양한 프레임워크에서 동일한 문제를 겪고 있는 팀들에게도 도움이 됩니다.

자주 묻는 질문

요약

기사 이름

PHP 8.3 지원 종료: 주요 일정, 위험 요소 및 향후 조치

설명

PHP 8.3의 지원 종료일, 지원 일정, 잠재적 위험 요소, 그리고 PHP 8.3의 지원 종료 이후 보안을 유지하기 위해 취해야 할 조치에 대해 알아보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고