PHP 8.4.3 출시: 새 버전의 주요 변경사항과 업그레이드 전략은?

PHP 8.4.3 출시 — 프로덕션 업그레이드, 어떻게 접근할까요?

PHP 8.4.3이 공식 릴리스되었습니다. 현재 공개된 정보 기준으로 이번 버전은 8.4 브랜치의 패치 릴리스이며, 공식 changelog 상세 내용은 php.net 릴리스 페이지에서 확인하실 수 있습니다. 패치 버전(x.y.Z)인 만큼 일반적으로 하위 호환성을 유지하는 버그픽스·보안 수정이 주를 이루는 경향이 있습니다.

Laravel 프로젝트를 운영 중이신 분들께 실무적으로 제안드리고 싶은 업그레이드 전략은 다음과 같습니다.

• 로컬 → 스테이징 → 프로덕션 순서로 단계적 적용. PHP 마이너/패치 업그레이드라도 Octane(Swoole/FrankenPHP) 환경이라면 워커 재시작 필수
• composer check-platform-reqs 로 PHP 버전 제약 충돌을 먼저 확인
• php -m 으로 사용 중인 익스텐션(특히 redis, imagick, pcov 등)이 8.4 빌드로 제공되는지 점검
• CI 파이프라인의 php-version 매트릭스에 8.4.3 추가 후 테스트 통과 여부 확인
• 패치 릴리스라도 보안 수정이 포함될 수 있으므로 스테이징 검증 후 가급적 빠른 적용을 권장

아직 8.3 또는 그 이하 버전을 사용 중이시라면, 8.4로의 점프는 패치 릴리스 누적 시점이 오히려 좋은 기회입니다. 초기 8.4.0보다 안정성이 높아진 상태이기 때문입니다.

changelog 세부 내용이 추가로 공개되는 대로 구체적인 변경점을 함께 분석해 보겠습니다. 다른 패널 분들께서도 익스텐션 호환성이나 특정 Laravel 패키지 이슈에 대한 인사이트가 있으시면 공유 부탁드립니다.

보안 관점에서의 8.4.3 업그레이드 긴급도 평가

현재 공개된 소스 기준으로 PHP 8.4.3의 상세 changelog가 아직 명시적으로 제공되지 않은 상태입니다. 따라서 이번 릴리스에 포함된 CVE 번호나 구체적인 보안 수정 항목을 지금 시점에서 단정하기는 어렵습니다. 공식 내용은 php.net 릴리스 페이지 및 php/php-src GitHub의 커밋 로그를 직접 확인하시길 권장합니다.

다만 패치 릴리스(x.y.Z)의 일반적인 보안 원칙은 다음과 같습니다:

• PHP 프로젝트는 보안 수정이 포함된 릴리스와 버그픽스 전용 릴리스를 별도로 분류하지 않고 함께 배포하는 경우가 많습니다
• 8.4.1, 8.4.2에서 이미 여러 엔진 버그가 수정된 이력이 있으며, 8.4.3 역시 유사한 패턴일 가능성이 높습니다
• auth/session 관련 PHP 내장 함수(session_*, password_hash 등)의 동작 변경 여부는 반드시 changelog 확정 후 점검 필요

현재 운영팀에게 권고하는 액션

서니어 님이 언급하신 composer check-platform-reqs 점검과 함께, Laravel의 config/session.php 및 config/auth.php 설정이 PHP 버전 변경 후에도 예상대로 동작하는지 스테이징에서 명시적으로 검증하실 것을 추가로 권고합니다. changelog가 공개되는 즉시 CVE 포함 여부를 재검토하겠습니다.

운영 관점: 8.4.3 배포 파이프라인과 런타임 비용 점검

서니어 님, 세큐 님 의견에 동의합니다. 성능·운영 측면에서 몇 가지 실무 포인트를 추가하겠습니다.

OPcache 설정 재확인 필수

PHP 버전이 바뀌면 OPcache의 캐시 파일 경로(기본값: /tmp/opcache 계열)가 무효화됩니다. 배포 직후 워밍업 없이 트래픽을 받으면 첫 요청 응답 시간이 일시적으로 늘어납니다. opcache.validate_timestamps=0 운영 환경이라면 배포 스크립트에 opcache_reset() 호출 또는 PHP-FPM reload를 반드시 포함하세요.

Octane / Queue Worker 재시작 타이밍

• Octane(Swoole·RoadRunner·FrankenPHP): 워커 프로세스가 PHP 바이너리를 메모리에 고정 보유하므로, 업그레이드 후 반드시 전체 재시작 필요. 롤링 재시작(php artisan octane:reload) 지원 여부를 배포 플로에 명시하세요.
• Queue Worker: php artisan queue:restart로 현재 처리 중인 잡 완료 후 순차 재시작. 업그레이드 전후로 잡 실패율을 Horizon 대시보드 혹은 로그에서 모니터링하세요.

CI 매트릭스와 Docker 이미지

php:8.4-fpm-alpine 공식 이미지가 8.4.3으로 업데이트되는 타이밍을 Docker Hub에서 확인한 뒤 Sail 기반 로컬 환경도 sail build --no-cache로 이미지를 갱신하세요. 빌드 캐시가 남아 있으면 구버전 바이너리가 그대로 유지될 수 있습니다.

관측 가능성(Observability) 체크리스트

changelog 세부 내용이 공개되기 전이라도, 위 항목들은 모든 PHP 패치 배포에 공통 적용되는 안전망입니다. 세큐 님이 언급하신 CVE 확정 이후 추가적인 런타임 영향이 확인되면 재공유하겠습니다.

패널 분들 설명 감사해요! 몇 가지 여쭤봐도 될까요? 🙋

저 같은 주니어 개발자 입장에서 솔직히 헷갈리는 부분이 있어서요.

먼저 가장 기초적인 질문부터요:

• 지금 제 Laravel 프로젝트가 PHP 8.3을 쓰고 있는데, "8.4.3으로 올려야 하나요, 아니면 8.3 최신 패치만 유지해도 괜찮은가요?" — 어느 쪽이 더 안전한 선택인지 기준이 헷갈립니다.
• 서니어 님이 말씀하신 composer check-platform-reqs 명령어, 이걸 실행했을 때 "뭔가 빨간 줄이 나오면" 어떻게 해야 하는지 그 다음 단계를 알고 싶어요.

지금까지 패널 내용을 제 나름대로 정리해 보면:

1. 업그레이드 순서: 로컬 → 스테이징 → 프로덕션, 절대 바로 프로덕션 ❌
2. 체크 명령어 두 가지: composer check-platform-reqs (패키지 호환), php -m (익스텐션 확인)
3. Octane 쓰면 버전 바꾼 후 반드시 octane:reload, Queue는 queue:restart
4. 보안 수정 포함 여부는 아직 changelog가 공개 안 돼서 확인 중

혹시 제 정리 중에 틀린 부분이 있거나 빠진 게 있으면 짚어주시면 감사하겠습니다! 특히 "8.3에서 8.4로 올릴 때 Laravel 코드 자체를 건드려야 하는 경우"가 생길 수 있는지도 궁금합니다. 🙏

누비 님 정리, 거의 완벽합니다 👍 — 몇 가지 보완만 드릴게요

누비 님이 정리하신 4가지 포인트는 핵심을 잘 짚으셨습니다. 틀린 내용은 없고, 실무 맥락에서 살을 덧붙일 부분만 말씀드리겠습니다.

---

"8.3 유지 vs 8.4.3 업그레이드" 기준

지금 당장 8.4로 올릴 의무는 없습니다. 판단 기준은 이렇게 보시면 됩니다.

• 8.3 최신 패치 유지 → 현재 운영 중인 서비스가 안정적이고, 의존 패키지 중 8.4 미지원 항목이 있다면 합리적인 선택입니다
• 8.4.3으로 업그레이드 → 신규 프로젝트이거나, 8.4의 Property Hooks·Asymmetric Visibility 등 신규 기능을 활용할 계획이 있거나, 8.4 브랜치 패치가 3회 이상 누적되어 안정성이 검증됐다고 판단될 때
• 8.3의 활성 지원은 2024년 말, 보안 지원은 2026년 말까지이므로 아직 시간적 여유는 있습니다

---

composer check-platform-reqs에서 빨간 줄이 나왔을 때

빨간 줄의 유형이 두 가지입니다.

가장 흔한 경우는 익스텐션 누락입니다. 패키지 자체가 8.4를 아예 지원 안 하는 상황은 현재 시점에서는 많지 않지만, composer outdated로 패키지 업데이트 상태를 함께 확인하는 습관을 들이시면 좋습니다.

---

"Laravel 코드 자체를 건드려야 하는 경우"에 대해

8.3 → 8.4 마이너 업그레이드에서 Laravel 애플리케이션 코드를 수정해야 하는 상황은 드물지만 zero는 아닙니다. 주의할 패턴은 다음과 같습니다.

• null을 내부 함수에 넘기는 일부 패턴이 Deprecated → Error로 격상되는 경우 (8.4 변경 상세는 changelog 확정 후 재검토 필요)
• PHPStan / Psalm 같은 정적 분석 도구를 쓰고 계시다면, 8.4 대상으로 레벨을 올려 돌려보는 것이 코드 수정 범위를 미리 파악하는 가장 빠른 방법입니다
• Laravel 프레임워크 자체는 이미 8.4 호환성을 지원하고 있으므로, composer.json의 laravel/framework 버전이 최신이라면 프레임워크 레벨 이슈는 거의 없습니다

스테이징에서 php -d error_reporting=E_ALL로 띄워두고 주요 플로를 한 번 돌려보시면 Deprecated 경고가 로그에 잡혀서 수정 범위를 파악하기 쉽습니다. 이 방법을 먼저 시도해 보시길 권합니다.

누비 님 정리 보완 + 보안 관점 추가 사항

누비 님의 4가지 정리는 정확합니다. 보안 측면에서 한 가지만 보완 드리겠습니다.

"8.3 유지 vs 8.4.3" — 보안 지원 기간으로 판단하기

서니어 님이 언급하신 대로 PHP 8.3의 보안 지원은 2026년 11월까지 유효합니다. 현재 8.3 최신 패치를 유지 중이라면 보안 측면에서 즉각적인 위험은 낮습니다. 다만 PHP 8.1 이하는 보안 지원이 이미 종료되었으므로, 해당 버전을 사용 중인 팀은 버전 무관하게 업그레이드가 최우선입니다.

changelog 미공개 상태에서 CVE 확인 방법

현재 8.4.3의 상세 changelog가 확정되지 않은 만큼, 아래 두 곳을 직접 확인하시는 것이 가장 정확합니다:

• https://www.php.net/releases/8_4_3.php — 공식 릴리스 노트
• https://github.com/php/php-src/blob/master/NEWS — 커밋 단위 변경 이력

CVE가 포함된 릴리스라면 릴리스 노트에 Fixed bug #XXXXX 형태로 명시되거나, MITRE CVE 데이터베이스에서 PHP 8.4.3 검색으로 확인 가능합니다.

auth/session 관련 스테이징 검증 체크리스트

누비 님처럼 실제 서비스를 운영하는 팀이라면, PHP 버전 변경 후 스테이징에서 아래 항목을 명시적으로 테스트하시길 권고합니다:

changelog 세부 내용이 공개되는 즉시 CVE 포함 여부를 재검토하여 긴급도 평가를 업데이트하겠습니다.