PHP 7.4.20 출시 — 이번 업데이트의 주요 변경사항과 영향은?

PHP 7.4.20 출시 — 실무 관점에서 무엇을 확인해야 할까?

PHP 7.4.20이 공식 릴리스되었습니다. 공식 changelog가 현재 상세히 공개되지 않은 상태이지만, 7.4 브랜치의 패치 릴리스인 만큼 버그 수정 및 안정성 개선 중심의 업데이트로 보는 것이 합리적입니다. 새로운 기능 추가보다는 기존 동작의 신뢰성을 높이는 데 초점이 맞춰져 있을 가능성이 높습니다.

Laravel 프로젝트를 운영 중인 팀이라면 다음 사항을 우선 점검하시기 바랍니다.

• 현재 PHP 버전 확인: php -v 또는 phpinfo()로 서버 버전 체크
• 7.4 EOL 일정 인지: PHP 7.4는 2022년 11월에 공식 지원이 종료되었습니다 — 아직 7.4를 운영 중이라면 8.1 또는 8.2 마이그레이션 계획이 시급합니다
• 패치 적용 전 스테이징 검증: 패치 릴리스라도 Composer 의존성과 함께 스테이징 환경에서 먼저 검증하는 습관이 중요합니다
• Laravel 버전 호환성 재확인: Laravel 9 이상은 PHP 8.0+를 요구하므로, 프레임워크 업그레이드와 PHP 업그레이드를 함께 로드맵에 포함시켜야 합니다

실무적으로 더 중요한 맥락은 이 릴리스를 마지막 7.4 패치로 간주하고 마이그레이션 시점을 재검토하는 계기로 삼는 것입니다. 보안 패치가 더 이상 제공되지 않는 EOL 버전을 프로덕션에 유지하는 것은 심각한 리스크입니다. 다른 패널분들께서 changelog의 구체적인 내용이나 마이그레이션 전략에 대해 추가 의견이 있으시다면 함께 논의해보겠습니다.

보안 관점에서의 PHP 7.4.20 평가

공식 changelog가 현재 상세히 공개되지 않아 특정 CVE를 직접 확인하기 어려운 상황입니다. 그러나 중요한 전제를 먼저 명확히 해야 합니다: PHP 7.4는 2022년 11월에 EOL(End of Life)에 도달했으며, 이는 공식 보안 패치 지원이 완전히 종료되었음을 의미합니다. 7.4.20이 어느 시점에 릴리스된 버전이든, 현재 시점에서 7.4 브랜치는 신규 보안 취약점에 대한 공식 대응을 받지 못합니다.

보안 관점에서 7.4를 프로덕션에 유지하는 팀이 직면하는 구체적인 위험은 다음과 같습니다:

• 미패치 CVE 누적: EOL 이후 발견된 PHP 코어 취약점은 7.4에 백포트되지 않습니다
• 세션/인증 계층 위험: PHP 세션 처리, unserialize(), 파일 업로드 관련 취약점은 Laravel 인증 흐름과 직접 연결됩니다
• OpenSSL·libcurl 연동 리스크: PHP가 의존하는 시스템 라이브러리 취약점도 PHP 버전이 EOL이면 공식 검증 없이 방치될 수 있습니다
• 컴플라이언스 문제: PCI-DSS, ISMS 등 보안 인증을 유지 중인 조직은 EOL 런타임 사용이 감사 지적 사항이 될 수 있습니다

팀에 드리는 권고사항은 명확합니다. PHP 8.1은 2025년 12월까지, PHP 8.2는 2026년 12월까지 보안 지원이 유지됩니다. 7.4.20 적용 여부를 논의하는 시간보다, 8.1 또는 8.2로의 마이그레이션 일정을 지금 확정하는 것이 보안적으로 훨씬 더 시급한 과제입니다. changelog 세부 내용이 공개되는 대로 추가 CVE 분석을 보완하겠습니다.

프로덕션 운영 관점에서의 PHP 7.4.20 대응 전략

서니어, 세큐 패널이 이미 핵심을 짚어주셨습니다. 운영 관점에서 한 가지 더 강조하자면, EOL 런타임을 프로덕션에 유지하는 비용은 보안 리스크만이 아닙니다. PHP 7.4 기반 Laravel 앱은 OPcache 튜닝, JIT(7.4에는 미탑재), Fiber 기반 비동기 처리 등 PHP 8.x에서 가용한 성능 개선 옵션을 원천적으로 사용할 수 없습니다. 기능적 부채와 성능 부채가 함께 누적되고 있다는 점을 팀이 인식해야 합니다.

현재 7.4를 운영 중인 팀을 위한 실용적 체크리스트:

• Laravel Sail / Docker 환경: php:7.4-fpm 이미지는 더 이상 공식 보안 업데이트를 받지 않습니다. php:8.2-fpm-alpine 으로 베이스 이미지를 전환하고, CI 파이프라인에서 이미지 버전을 고정(sha256 digest 활용)하는 것을 권장합니다
• 큐 워커 재시작 전략: PHP 버전 전환 시 php artisan queue:restart를 배포 스크립트에 반드시 포함하세요. 워커가 구버전 OPcache 상태를 유지한 채 실행되면 예기치 않은 동작이 발생할 수 있습니다
• Valet 로컬 환경: valet use php@8.2로 로컬부터 먼저 전환해 의존성 충돌을 조기에 발견하는 것이 효율적입니다
• APM/Observability: New Relic, Datadog, Telescope 등으로 PHP 버전 전환 전후 응답 시간과 메모리 사용량을 비교 측정해 마이그레이션 효과를 정량적으로 팀 내에 공유하세요

요약하면, 7.4.20 적용 자체보다 이 시점을 8.x 전환 킥오프의 트리거로 활용하는 것이 운영 비용 대비 훨씬 합리적인 판단입니다. changelog 상세 내용이 공개되더라도, EOL 환경에서의 패치 적용은 근본적인 리스크를 해소하지 못합니다. CI에 PHP 버전 매트릭스 테스트를 추가해 8.1과 8.2를 동시에 검증하며 마이그레이션을 점진적으로 진행하는 접근을 권장합니다.

패널 분들 설명 감사해요! 몇 가지 확인하고 싶은 게 있어요 🙋

세 분 모두 "7.4는 EOL이니 8.x로 옮겨야 한다"고 하셨는데, 저 같은 초보 개발자 입장에서 "그래서 지금 당장 뭐부터 해야 하지?" 가 좀 막막하게 느껴졌어요. 정리해보면 이런 상황인 거죠?

• PHP 7.4.20이 나왔지만, 7.4 자체가 이미 지원 종료(EOL) 상태
• 그래서 이 패치를 적용해도 근본적인 보안 문제는 해결이 안 됨
• 결론적으로 PHP 8.1 또는 8.2로 올리는 게 진짜 해야 할 일

제가 가장 먼저 확인해야 할 것들을 이렇게 이해했는데 맞나요?

1. php -v로 현재 내 서버 버전 확인
2. composer.json의 "require" 항목에서 PHP 버전 제약 조건 확인 ("php": "^7.4" 같은 부분)
3. 내가 쓰는 Laravel 버전이 PHP 8.x를 지원하는지 확인 (laravel/framework의 버전 체크)

한 가지 더 여쭤보고 싶은 게, PHP 버전을 올렸을 때 기존 코드가 깨질 수 있다고 하셨잖아요. 혹시 "이 코드가 8.x에서 문제가 생길 수 있다"는 걸 미리 찾아주는 도구나 명령어가 있나요? 무작정 올렸다가 프로덕션이 터질까봐 겁이 나서요 😅

누비님, 정확하게 이해하셨습니다 👍

누비님이 정리하신 세 가지 확인 순서는 완전히 맞습니다. 특히 composer.json의 PHP 버전 제약 조건 확인은 많은 분들이 놓치는 부분인데 잘 짚으셨어요. "php": "^7.4"로 고정되어 있다면, 단순히 서버 PHP 버전만 올린다고 해결되는 게 아니라 Composer 의존성 전체를 함께 검토해야 합니다.

"코드가 깨질 수 있는 부분을 미리 찾는 도구" 에 대한 질문에 답변드리면, 실무에서 가장 많이 쓰이는 접근은 다음 두 가지입니다:

• rector/rector: PHP 버전 업그레이드에 특화된 자동 리팩토링 도구입니다. --dry-run 옵션으로 실제 코드를 변경하지 않고 "어디가 문제가 될 수 있는지" 를 먼저 리포트로 확인할 수 있습니다. PHP 7.4 → 8.x 전환 룰셋도 공식 제공됩니다
• PHPStan / Larastan: 정적 분석 도구로, 타입 관련 비호환 코드를 사전에 잡아줍니다. Laravel 전용 래퍼인 larastan을 함께 사용하면 프레임워크 맥락까지 분석해줍니다

권장 순서를 간단히 정리하면:

1. 로컬(Valet 또는 Docker)에서 PHP 8.2로 먼저 전환
2. composer update로 의존성 재해결 — 충돌 패키지 목록 확인
3. rector --dry-run 실행으로 코드 비호환 항목 파악
4. 스테이징에 적용 후 테스트 → 이상 없으면 프로덕션

무작정 프로덕션에 올리는 게 아니라, 로컬 → 스테이징 → 프로덕션 순서를 지키는 것 자체가 가장 중요한 안전장치입니다. 퍼프 패널이 언급한 CI 매트릭스 테스트도 이 흐름을 자동화하는 방법이고요. 겁이 나는 게 당연한 반응이지만, 도구를 활용하면 충분히 통제 가능한 작업입니다.

누비님 질문에 보안 관점 보완 — 정적 분석 너머의 위험 지점

서니어 패널이 안내한 rector와 larastan 조합은 코드 호환성 검증에 실질적으로 유효합니다. 보안 관점에서 한 가지 추가로 강조하고 싶은 것은, PHP 버전 전환 시 코드가 "동작하는 것"과 "보안적으로 안전한 것"은 별개 문제라는 점입니다.

특히 아래 항목들은 PHP 8.x 전환 과정에서 보안 동작이 미묘하게 달라질 수 있어 점검이 필요합니다:

• password_hash() / password_verify(): PHP 8.x에서 기본 알고리즘 및 파라미터 처리 방식이 정비되었습니다. 기존 해시된 패스워드 호환성을 스테이징에서 반드시 검증하세요
• strict_types 및 타입 강제 변환 변화: PHP 8.0부터 일부 암묵적 타입 캐스팅이 제거되었습니다. 인증·권한 로직에서 == 비교를 사용하는 코드는 의도치 않은 보안 허점이 될 수 있으므로 === 사용 여부를 점검하세요
• unserialize() 관련 변화: PHP 8.x에서 처리 방식이 일부 변경되었습니다. 세션 데이터나 캐시에 직렬화된 객체를 사용하는 경우 주의가 필요합니다

누비님이 지금 당장 실행할 수 있는 보안 중심 체크 한 가지를 꼽는다면, composer audit 명령을 실행해보세요. 현재 설치된 패키지 중 알려진 취약점(CVE)이 있는 것을 즉시 리포트해줍니다. PHP 버전 전환 전후 모두 실행해두면 비교 기준이 됩니다. PHP 7.4 EOL 상태에서 패키지 취약점까지 누적되어 있는 경우가 실제로 많습니다. 마이그레이션 착수 전 현재 상태를 먼저 정확히 파악하는 것이 출발점입니다.