시간이 얼마 남지 않았습니다: PHP 8.2 지원 종료 대비하기

주요 내용

• PHP 8.2는 2026년 12월 31일에 지원이 종료됩니다. 해당 날짜 이후에는 PHP 프로젝트에서 이 버전에 대한 보안 패치를 더 이상 제공하지 않습니다.
• 지원 종료(EOL)된 PHP는 단순한 보안 위험에 그치지 않고, PCI DSS, HIPAA 및 SOC 2 규정에 따른 준수 문제도 야기할 수 있습니다.
• PHP 8.3, 8.4 또는 8.5로 업그레이드하는 것이 올바른 해결책이지만, 종속성 문제로 인해 일정이 대부분의 팀이 예상하는 것보다 더 길어지고 있습니다.
• 마감 기한까지 업그레이드를 완료할 수 없는 경우, TuxCare의 PHP ‘Endless Lifecycle Support’ 서비스를 이용하면 마이그레이션 기간 동안 8.2 버전에 대한 패치 지원을 계속 받을 수 있습니다.

현재 프로덕션 환경에서 PHP 8.2를 사용 중이라면, 생각보다 시간이 훨씬 더 촉박해지고 있습니다. PHP 8.2는 이미 활성 지원 기간이 종료되어 보안 패치만 제공되는 단계에 접어들었으며, 2026년 12월 31일이 최종 지원 종료일입니다. 이 날짜는 실제 업그레이드 작업이 무엇을 수반하는지 구체적으로 파악하기 전까지는 충분히 여유 있어 보일 수 있습니다. 스테이징 환경 구축, 종속성 검토, 프레임워크 호환성 확인, 수백 또는 수천 개의 경로에 걸친 회귀 테스트 등이 포함되기 때문입니다. 그러다 보면 달력상 예상했던 것보다 시간이 훨씬 촉박하다는 사실을 깨닫게 됩니다.

이 글에서는 PHP 8.2의 지원 종료(EOL) 일정, 해당 날짜 이후에 실제로 어떤 일이 벌어지는지, 그리고 개발팀이 현실적으로 선택할 수 있는 세 가지 방안에 대해 다룹니다. 혹시 “그냥 업그레이드하면 돼요, 문제없어요”라는 답변을 기대하고 이 글을 읽으셨다면 미리 말씀드리지만, 이 글은 그런 내용을 다루지 않습니다. 업그레이드는 겉보기만큼 간단하지 않은 경우가 대부분입니다.

PHP: 버전 및 출시 일정 설명

PHP(Hypertext Preprocessor)는 4년 주기의 고정된 지원 주기를 따릅니다. 즉, 2년간의 적극적인 지원 기간이 지나면, 이후 2년 동안은 중대한 보안 패치만 제공됩니다. 그 후에는 EOL(지원 종료) 단계에 접어들며, 프로젝트 팀은 해당 브랜치를 종료하고 다음 단계로 넘어갑니다. 이 4년 주기는 2024년 기준 3년에서 연장된 것으로, 이제 모든 EOL 날짜는 해당 연도의 12월 31일로 정해졌습니다.

PHP 8.2는 2022년 12월 8일에 출시되었습니다. 2024년 말에 정식 지원이 종료되었으며, 현재는 보안 패치만 제공되는 마지막 단계에 접어들었습니다. 각 브랜치의 공식 릴리스 일정과 지원 현황은 php.net에서 확인할 수 있습니다.

PHP 8.1은 최근 지원 종료(EOL) 시점을 맞이했기 때문에, 참고용으로만 아래에 포함했습니다. 2026년 기준 PHP 8.1과 현재 지원 중인 8.x 계열의 현황은 다음과 같습니다:

PHP 8.1은 이미 지원 종료(EOL) 상태입니다. 따라서 현재 이 버전에 대한 CVE 취약점이 공개되더라도, 여전히 이 버전을 실행 중인 호스트에 대해서는 공식 패치가 제공되지 않을 것입니다. PHP 8.2의 지원 기간은 일반적인 기업용 업그레이드 주기와 거의 비슷합니다. 즉, 지연할 여유가 별로 없다는 뜻입니다.

알고 계셨나요?W3Techs 사용 통계에 따르면, 서버 측 언어가 확인된 전체 웹사이트 중 71.2%가 PHP를 사용하고 있습니다. PHP 8을 실행하는 사이트 중에서 8.2 버전이 32.8%로 가장 널리 사용되는 하위 버전이며, 29.1%인 8.3 버전과 9.9%인 8.4 버전을 앞지르고 있습니다. 이미 지원 종료(EOL)된 PHP 8.1과 8.0은 여전히 전체 PHP 8 사이트의 26.6%에서 실행되고 있습니다. 실제 운영 환경에서의 버전 업그레이드는 릴리스 블로그에서 발표되는 속도보다 훨씬 더 느리게 이루어집니다.

PHP 8.2의 지원 종료(EOL) 이후에는 어떻게 되나요?

2026년 12월 31일 이후, PHP 프로젝트는 8.2 브랜치를 종료하고 이에 대한 모든 지원을 중단합니다. 공식 패치도, 공식 수정 사항도, PHP 프로젝트 측의 예외 조치도 없을 것입니다. 이는 여러분의 인프라에 네 가지 측면에서 영향을 미치게 됩니다.

1. 보안 패치 배포 중단

가장 명백한 결과이자, 가장 심각한 결과를 초래하는 부분입니다. 8.2 버전이 지원 종료(EOL)에 이르면, CVE(취약점)가 심각(critical), 높음(high), 낮음(low) 등급 중 어느 것이든 PHP 프로젝트 측에서 수정 패치를 제공하지 않게 됩니다. 2027년 1월 2일에 공개된 원격 코드 실행 취약점은 8.3, 8.4, 8.5 버전에서는 패치되겠지만, 8.2 버전에서는 해결되지 않은 채 남게 됩니다.

이는 단순한 가설이 아닙니다. 특정 코드 페이지 구성 하에서 Windows 기반 PHP-CGI에 영향을 미치는 인자 주입(argument-injection) 취약점인 CVE-2024-4577이 2024년 6월에 공개되었습니다. 이 취약점은 8.1.29, 8.2.20, 8.3.8 버전에서 수정되었습니다. PHP 8.0 및 7.x를 포함한 이전 EOL(지원 종료) 브랜치들은 공개 권고문을 통해 취약한 것으로 보고되었으나, 이미 지원이 종료된 상태였기 때문에 PHP 프로젝트 측에서 공식적인 수정 패치를 제공받지 못했습니다. 그 결과 며칠 만에 대규모 악용 사례가 발생했습니다. 연구원들은 이 단일 취약점을 통해 암호화폐 채굴 프로그램, 웹 셸, DDoS 인프라를 배포하는 수천 개의 공격 IP를 추적했습니다.

이후의 PHP CVE에서도 같은 양상이 이어졌습니다. 예를 들어, CVE-2025-14177과 CVE-2025-14180은 PHP 8.1부터 8.5까지를 포함한 지원 대상 브랜치에서 수정되었습니다. 브랜치가 EOL(지원 종료) 시점을 넘기면 해당 공식 패치 제공은 중단됩니다.

이러한 패턴은 이미 잘 알려져 있습니다. 공격자들은 지원되는 브랜치에 배포된 패치를 리버스 엔지니어링하여, 이를 로드맵으로 삼아 패치가 적용되지 않은 브랜치를 악용합니다. 심각도가 높은 버그의 경우, 공개와 실제 악용 사이의 시간 차이는 며칠, 때로는 몇 시간에 불과합니다. TuxCare가 PHP 7의 CVE-2023-0568에 대해 수행한 분석은 이러한 패턴이 얼마나 반복적으로 나타나는지를 보여주는 좋은 사례입니다.

PHP는 꾸준한 CVE 활동 양상을 보이고 있습니다. NVD에서 제공한 Stack.watch 데이터에 따르면, 2024년에는 18건, 2025년에는 15건의 취약점이 공개되었으며, 2026년은 아직 몇 달이 남았음에도 이미 11건이 보고되었습니다. 2026년 5월, PHP 8.2.31은 단일 릴리스에서 8개의 취약점을 패치했습니다. 8.2 버전이 지원 종료(EOL)되면, 지원되는 브랜치에 대해서는 보안 릴리스가 계속 제공되지만 8.2 버전은 더 이상 보안 릴리스를 받지 못하게 됩니다.

또한, 벤더가 지원하는 PHP 확장 지원을 통해 자동 패치 솔루션이 어떻게 보안을 유지하는지 살펴볼 수도 있습니다.

2. 규정 준수 및 감사 위험 증가

대부분의 보안 프레임워크(PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001 등)는 조직이 타당성을 입증할 수 있는 취약점 관리 프로세스를 유지하고 사용 가능한 보안 패치를 적용할 것을 요구합니다. 지원 종료(EOL) 소프트웨어는 그 특성상 이러한 요구 사항을 충족하기 어렵게 만듭니다. 실제 상황에서는 다음과 같은 문제가 발생합니다:

• PCI DSS: 요구사항 6.2에 따르면, 해당 보안 패치는 출시 후 1개월 이내에 적용해야 합니다. 런타임이 EOL(제품 수명 주기 종료) 상태라 적용할 공식 패치가 없는 경우, 보완 통제 조치를 문서화하지 않으면 지속적으로 규정 미준수 상태에 놓일 수 있습니다.
• SOC 2: 감사인은 종종 수명 종료(EOL) 구성 요소를 통제 취약점으로 지적합니다. 기한이 명시된 서면 시정 계획서를 제출해야 합니다.
• HIPAA: PHI를 처리하는 시스템에서 EOL 소프트웨어를 실행할 경우, 보안 규칙에 따라 귀사의 보안 조치가 여전히 합리적이고 적절한지 여부에 대한 의문이 제기될 수 있습니다.
• 사이버 보험: 보험사들은 수명 종료(EOL) 부품으로 인한 사고에 대해 면책 조항을 추가하거나 보험료를 인상하고 있습니다. 이러한 현상은 갱신 시기에 더욱 흔해지고 있습니다.

가장 답답한 점은, 다른 모든 구성 요소가 문제없음에도 불구하고 PHP 런타임 하나만 EOL(지원 종료) 상태라면, 그 때문에 전체 감사에서 불합격 판정을 받을 수 있다는 것입니다.

3. 생태계 변화의 가속화

8.2 버전이 지원 종료(EOL)되는 순간, 생태계는 조용히 등을 돌리기 시작합니다. 프레임워크들은 테스트 매트릭스에서 이 버전을 제외합니다. Composer 패키지들은 최소 지원 버전을 8.3으로 상향 조정합니다. 호스팅 업체들은 관리형 스택에서 이 버전을 단계적으로 퇴출시킵니다. CI 실행 도구들은 더 이상 기본 설정에 이 버전을 포함하지 않습니다.

이런 현상은 한꺼번에 일어나지 않습니다. 바로 그 점이 이 문제를 더욱 교묘하게 만듭니다. 수개월에 걸쳐 쌓여가는 수백 가지의 사소한 호환성 문제들이 원인이죠. 의존하고 있는 라이브러리에 보안 패치가 출시되지만, 8.3 이상 버전에서만 적용됩니다. ORM 업데이트는 8.2 버전에는 없는 기능을 전제로 합니다. 새로운 모니터링 에이전트는 8.2 빌드를 아예 지원하지 않습니다. 이런 문제들은 처음에는 치명적이지 않습니다. 6개월이 지나면, 고정된 버전과 임시 해결책들이 뒤엉킨 상태를 유지하게 되고, 실제 업그레이드는 더 쉬워지기는커녕 오히려 더 어려워집니다.

4. 숨겨진 운영상의 저항

이 부분은 종종 과소평가되곤 합니다. 지원 종료(EOL)된 PHP를 계속 사용한다는 것은 팀이 기능 개발이 아닌 다른 업무에 엔지니어링 리소스를 낭비하게 된다는 것을 의미합니다. 예를 들어, 수정 사항을 수동으로 이전 버전으로 적용하거나, 종속성 버전을 고정하거나, 보안 취약점을 보완하기 위해 맞춤형 보안 미들웨어를 작성하거나, 감사관의 질문에 답변하거나, 기업 고객 후보들에게 런타임 환경이 지원 종료 상태인 이유를 설명하는 등의 업무가 이에 해당합니다.

이를 1년 단위로 환산해 보면, “나중에 업그레이드하자”는 태도가 티켓이나 스프린트에서는 명확히 드러나지 않지만, 작업 속도(velocity)에는 분명히 반영되는 실질적인 비용을 초래합니다.

PHP 8.2 지원 종료 후의 선택지

현실적으로 고려할 수 있는 세 가지 방법이 있습니다. 어떤 방법이 적합한지는 사용 중인 기술 스택, 팀 규모, 그리고 실제 마이그레이션 일정에 대해 얼마나 솔직하게 접근할 의향이 있는지에 따라 달라집니다.

옵션 1: PHP 8.3 이상으로 업그레이드

기본 권장 사항이며, 실제로 적용이 가능하다면 가장 현명한 선택입니다. PHP 8.3, 8.4 또는 8.5로 업그레이드하면 공식 보안 지원이 재개되고 실질적인 개선 사항이 제공됩니다. 8.3에서는 타입 지정 클래스 상수가, 8.4에서는 속성 훅과 비대칭 가시성이 도입되었으며, 전반적인 성능과 런타임 효율성도 향상됩니다.

하지만 그 문장에서 ‘업그레이드’라는 단어는 상당히 많은 작업을 의미합니다. 실제 운영 환경에서 PHP 버전을 올리는 것은 대개 다음을 의미합니다:

• 8.3 이상 버전과의 호환성을 확인하기 위해 모든 Composer 종속성을 검토 중입니다.
• 사용 중단 경고 처리 – 여기에는 PHP 8.2에 도입되어 PHP 9.0에서는 치명적인 오류로 전환될 예정인 동적 속성(dynamic properties)의 사용 중단도 포함됩니다.
• CI 매트릭스, Docker 기본 이미지 및 배포 매니페스트를 업데이트 중입니다.
• 모든 엔드포인트에 대해 전체 회귀 테스트를 실행 중입니다.
• Laravel, Symfony, WordPress, Drupal, Magento 등 각 프레임워크마다 고유한 버전 제약 사항과 플러그인 호환성 문제를 고려하여 프레임워크 업그레이드를 조정합니다.

Rector와 같은 도구는 리팩토링 작업의 일부를 자동화할 수는 있지만, 의존성 호환성 문제를 해결해 주지는 못합니다. 단지 PHP 특유의 구문 변경을 빠르게 처리해 줄 뿐입니다.

현장의 목소리: PHP 런타임 변경은 거의 항상 쉬운 부분입니다. 실제로 업그레이드 일정을 지연시키는 주범은 2022년 이후로 손도 대지 않은 채 방치되어 이제는 다른 모든 작업을 가로막고 있는 타사 패키지입니다. 대부분의 팀이 몇 주씩 허비하게 만드는 것은 PHP 자체가 아니라 바로 '의존성 지옥'입니다.

결정적인 순간:

• 코드베이스의 테스트가 충분히 이루어졌고, 의존성 라이브러리가 비교적 최신 버전이며, 여력이 있다면 지금 바로 업그레이드하여 PHP 8.4 또는 8.5를 지원하도록 하세요.
• 만약 일정이 현실적으로 2026년 12월을 넘기게 된다면, 업그레이드를 시작하되, 마이그레이션 도중에 보안 취약 상태에 놓이지 않도록 연장 지원 서비스를 병행하십시오.

옵션 2: PHP 8.2에 대한 연장 지원

이는 실용적인 절충안이자, 많은 팀이 대안을 모색할 때 간과하기 쉬운 방안입니다. 공급업체가 지원하는 연장 지원 서비스를 이용하면, 공식 지원 종료일 이후에도 즉시 런타임 환경을 업그레이드할 필요 없이 PHP 8.2에 대한 새로운 CVE 패치를 지속적으로 적용받을 수 있습니다. 보안 패치는 계속 제공되고, 애플리케이션은 정상적으로 가동되며, 팀은 정해진 일정 대신 엔지니어링 현실에 기반한 계획에 따라 마이그레이션을 진행할 수 있습니다.

바로 이러한 공백을 메우기 위해 TuxCare의 ‘PHP 무한 수명주기 지원(Endless Lifecycle Support)’ 서비스가 마련되었습니다. 이 서비스는 지원 종료(EOL)된 PHP 버전에 대해 지속적인 보안 패치를 제공하며, 애플리케이션 코드를 수정할 필요 없이 바로 적용할 수 있는 대체 버전 형태로 제공됩니다. 현재 공개된 TuxCare 문서에 따르면, OS 및 배포판에 따라 PHP 5.1.6부터 8.3까지의 버전이 지원 대상에 포함됩니다.

또한 ELS for PHP 웹사이트에서 다운로드할 수 있는 데이터시트가 마련되어 있는데, 여기에는 업그레이드가 항상 즉각적인 해결책이 될 수는 없는 이유와 확장 지원이 귀사의 환경에 어떻게 적용되는지에 대한 내용이 담겨 있습니다. 평가를 진행하기 전에 한 번 읽어보시면 도움이 될 것입니다.

다음과 같은 경우 이 경로를 선택하세요:

• 현실적으로 귀하의 마이그레이션은 2026년 12월 31일 이전에는 완료되지 않을 것입니다.
• 귀사는 지속적인 패치 적용 및 그 기록을 남길 의무가 있습니다.
• 보안상의 긴급성과 엔지니어링 역량 계획을 분리하고자 합니다.
• 여러 개의 PHP 버전을 동시에 사용 중이며, 모든 버전에서 일관된 커버리지를 확보해야 합니다.

전문가 팁: 실무에서 효과가 좋은 패턴이 하나 있습니다. 바로 '확장 지원(ELS)'과 병행하여 업그레이드를 진행하는 것입니다. 기한에 쫓기는 압박감을 없애기 위해 확장 지원을 구매한 다음, 합리적인 일정에 따라 업그레이드를 실행하세요. 1년치 확장 지원 비용은 서둘러 진행한 마이그레이션 과정에서 발생하는 버그로 인한 비용보다 일반적으로 훨씬 적습니다.

옵션 3: PHP에서 다른 플랫폼으로 마이그레이션

가장 과감한 선택지이지만, 단순히 지원 종료(EOL) 압박 때문에 내리는 결정은 거의 옳지 않습니다. 일부 팀은 강제 업그레이드 기능을 활용해 서비스를 Go, Node.js, Python 또는 Rust로 재구현하기도 하는데, 대개는 다른 이유로 이미 교체 대상이었던 구성 요소들입니다.

이 방법은 PHP 코드가 이미 유지보수 부담이 되어 팀이 폐기하고자 하는 경우, 서비스 규모가 작고 입력 및 출력이 명확하게 정의되어 있으며, 여러 분기에 걸친 마이그레이션을 수행할 수 있는 실질적인 기술 역량이 확보된 경우에 효과적입니다.

EOL(지원 종료)만이 유일한 동기라면 효과가 없습니다. 마감 기한의 압박으로 진행되는 리라이팅은 출시가 지연되기 쉬우며, 기존 코드가 수년간 문제없이 처리해 온 예외적인 경우들을 놓치기 쉽고, 처음 발견하는 데 오랜 시간이 걸렸던 버그들이 다시 발생하기도 합니다. 만약 PHP 업그레이드가 너무 부담스러워 전면적인 리라이팅을 고려하고 있다면, 이를 실행에 옮기기 전에 신중히 검토해 볼 필요가 있습니다.

업그레이드가 항상 정답은 아닌 이유

업그레이드는 교과서적인 해답입니다. 하지만 현실에서는 상황이 더 복잡합니다. 확장 지원이 종종 더 타당한 기술적 결정인 이유는 다음과 같은 세 가지입니다:

대개 의존성 문제가 진짜 걸림돌이 됩니다

PHP 런타임 자체 때문에 업그레이드가 지연되는 경우는 거의 없습니다. 문제는 지난 2년 동안 업데이트되지 않은 소수의 라이브러리, 아직 8.3 버전을 공식적으로 지원하지 않는 프레임워크, 그리고 더 이상 관리 주체가 없는 사내 패키지들 때문입니다. 이러한 복잡한 상황을 뚫고 강제로 업그레이드를 진행하려면, 호환되지 않는 종속성을 동결해야 하는데 이는 보안 강화라는 본래 목적을 무색하게 만들거나, 아니면 하나씩 업데이트해야 하는데 이 경우 패키지당 수 주간의 수정 및 테스트 작업이 소요될 수 있습니다.

서두른 마이그레이션은 비용이 많이 든다

엄격한 마감 기한을 두고 진행된 마이그레이션은 버그를 낳습니다. 예외적인 상황을 놓치기 일쑤고, 테스트 범위도 대충 처리하기 마련입니다. 강제로 런타임 업그레이드를 겪어본 사람이라면 누구나 이런 패턴을 잘 알고 있습니다. 기능이 미묘하게 퇴보하고, 성능 특성이 예기치 않게 변하며, 그 대가는 다음 분기에 당직 순번을 맡은 사람들이 치르게 됩니다.

비용 산출을 해보면, 연장 지원 비용을 고려하더라도 차근차근 계획된 마이그레이션이 더 유리할 때가 있습니다. 엔지니어링 인력 투입 시간 절감, 사고 예방, 그리고 보다 원활한 서비스 출시 등은 초기 비용 비교에서는 항상 드러나지 않는 다양한 이점을 가져다줍니다.

어떤 코드베이스는 지금 당장 업그레이드할 가치가 전혀 없습니다

모든 레거시 PHP 애플리케이션이 대규모 마이그레이션 작업을 감수할 만큼의 미래가 있는 것은 아닙니다. 18개월 내에 교체될 예정인 애플리케이션도 있고, 고정된 업무량을 처리하는 내부 도구로서 새로운 기능 추가 계획이 없는 경우도 있습니다. 또한 고객 기반이 점차 줄어들고 있는 유지보수 단계의 제품도 있습니다.

해당 시스템의 경우, 업그레이드 대신 패치를 적용하는 것은 타당한 기술적 판단입니다. 내년에 서비스가 종료될 애플리케이션의 런타임을 업그레이드하는 데 두 분기나 시간을 투자하는 것은 비효율적인 선택입니다. 연장 지원은 서비스가 종료될 때까지 보안을 유지해 줍니다.

업그레이드 없이 PHP 8.2 보안 유지 – TuxCare와 함께

PHP 8.2의 지원 종료일은 2026년 12월 31일입니다. 이 날짜가 지나면 PHP 프로젝트는 더 이상 패치를 배포하지 않으며, 해당 버전을 계속 실행 중인 모든 호스트에 대해 새로운 CVE 취약점이 누적되기 시작합니다. 업그레이드는 깔끔하게, 그리고 합리적인 일정에 맞춰 진행할 수 있을 때 올바른 해결책입니다. 하지만 종속성이 준비되지 않았거나, 기한이 너무 촉박하거나, 코드베이스상 투자 대비 효과가 충분하지 않아 업그레이드가 불가능한 경우, 확장 지원은 부적절한 마이그레이션을 강요하지 않으면서도 보안을 유지할 수 있는 대안입니다.

TuxCare의 PHP ‘무한 라이프사이클 지원’은 지원 종료(EOL)된 PHP 버전에 대해 필요한 기간 동안 지속적인 보안 패치를 제공함으로써 이러한 격차를 해소하며, 애플리케이션 코드를 수정할 필요가 없습니다. 귀사의 환경에 이 서비스가 어떻게 적용될 수 있는지 확인해 보고 싶으시다면 TuxCare 보안 전문가에게 문의해 주십시오. 우리의 목표는 기존 시스템을 대체하는 것이 아니라, 귀사가 업그레이드 일정을 주도적으로 관리할 수 있도록 돕는 것입니다.

요약

기사 이름

시간이 얼마 남지 않았습니다: PHP 8.2 지원 종료 대비하기

설명

PHP 8.2는 아직 지원 종료 시점이 도래하지 않았지만, 머지않아 종료될 예정입니다. 지원 종료 전까지의 일정, 관련 위험 요소, 그리고 대비 방법을 확인해 보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고