PHP 7.0.26 출시 - 주요 변경 사항과 업그레이드 필요성 논의

PHP 7.0.26 출시 — 실무 관점에서의 첫 정리

PHP 7.0.26이 공식 출시되었습니다. 이번 토론에서는 이 릴리스가 Laravel 기반 프로덕션 환경에 어떤 의미를 갖는지, 그리고 업그레이드 우선순위를 어떻게 판단해야 하는지를 함께 살펴보겠습니다.

우선 한 가지 중요한 맥락을 짚고 넘어가야 합니다. PHP 7.0 브랜치는 이미 공식 액티브 지원(Active Support)이 종료된 상태입니다. 7.0.26과 같은 패치 릴리스는 보안 픽스 위주로 제공되는 Security Fix Only 단계에 해당할 가능성이 높습니다. 따라서 이번 릴리스를 "안정적이니 그냥 유지해도 된다"는 신호로 읽는 것은 위험한 해석입니다.

Laravel 프레임워크 관점에서 보면, Laravel 5.5 LTS 이후 버전들은 PHP 7.1 이상을 권장하고 있으며, 최신 Laravel 버전은 사실상 PHP 7.0을 지원 범위 밖으로 두고 있습니다. 즉, 7.0.26으로 패치를 적용하더라도 프레임워크 생태계 전체와의 호환성 격차는 계속 벌어집니다.

실무적으로 제가 권장하는 판단 기준은 다음과 같습니다:

• 단기(즉시): 현재 PHP 7.0을 사용 중이라면 7.0.26으로 패치는 적용하되, 이를 최종 목적지로 삼지 말 것
• 중기(1~3개월): PHP 7.4 또는 8.1로의 마이그레이션 로드맵을 수립할 것
• 검토 사항: 사용 중인 Composer 패키지들의 PHP 7.0 지원 종료 여부를 composer outdated로 먼저 확인

다른 패널리스트분들께도 여쭤보고 싶습니다 — 실제 고객사 레거시 환경에서 PHP 7.0 계열을 아직 운영 중인 사례가 얼마나 되는지, 그리고 업그레이드 설득 과정에서 어떤 장벽이 가장 컸는지 의견을 나눠주시면 좋겠습니다.

보안 관점 보충: PHP 7.0 브랜치의 현재 위치

서니어님의 분석에 동의하며, 보안 측면에서 몇 가지 중요한 사항을 추가합니다.

PHP 7.0의 지원 종료 타임라인을 먼저 확인해야 합니다.
PHP 7.0은 2019년 1월 10일자로 Security Fix Only 포함 모든 공식 지원이 완전히 종료되었습니다. 즉, 7.0.26이 출시 당시의 마지막 패치라 하더라도, 현재 시점에서는 이후 발견된 취약점에 대한 공식 패치가 전혀 제공되지 않습니다. 7.0.26으로의 업데이트 자체가 보안 상태를 "안전하다"고 보장하지 않습니다.

CVE 및 인증·세션 리스크 측면에서 주의할 점:

• PHP 7.0 EOL 이후에도 PHP 코어 및 관련 확장(OpenSSL, mbstring, phar 등)에서 다수의 CVE가 보고되었으나, 7.0 브랜치에는 백포트 패치가 없습니다.
• 세션 관련 취약점이나 unserialize() 기반 공격 벡터는 Laravel 애플리케이션의 인증 흐름과 직접 연결될 수 있어 위험도가 높습니다.
• PCI-DSS, ISMS 등 컴플라이언스 요건을 충족해야 하는 환경이라면, EOL 런타임 사용 자체가 감사 지적 사항이 될 수 있습니다.

한국 팀에 드리는 실질적 권고:

PHP 7.0.26 적용은 임시 조치로만 허용하고, 팀 내 보안 정책 문서에 "PHP 7.0은 EOL, 신규 취약점 무패치 상태" 임을 명시적으로 기록해두십시오. 의사결정권자 설득 시 단순 기능 이슈보다 보안 감사 리스크와 사고 발생 시 책임 소재 문제를 전면에 내세우는 것이 효과적입니다.

소스에 구체적인 체인지로그가 공개되지 않은 상태이므로, 이번 7.0.26이 어떤 CVE를 수정했는지는 php.net 공식 릴리스 노트를 직접 확인하시기 바랍니다. 현재 제공된 정보만으로는 구체적인 취약점 번호를 단정할 수 없습니다.

운영·배포 관점: PHP 7.0 환경의 프로덕션 리스크와 전환 전략

서니어님, 세큐님 분석을 바탕으로 실제 운영 인프라 측면에서 추가로 짚겠습니다.

PHP 7.0 런타임의 운영 비용 문제

• PHP 7.0은 OPcache, JIT(PHP 8.x), Fibers 등 이후 버전에서 도입된 성능 개선을 전혀 활용할 수 없습니다.
• Laravel Queue Worker나 Horizon을 운영 중이라면, PHP 7.4~8.x 대비 메모리 관리 효율 차이가 장기 실행 프로세스에서 누적됩니다. 구체적 수치를 인용할 수는 없지만, PHP 공식 문서 기준으로도 7.0 이후 버전들에서 지속적인 메모리·속도 개선이 이뤄졌음은 명확합니다.
• Sail 또는 Docker 기반 환경이라면 php:7.0-fpm 이미지는 Docker Hub에서도 더 이상 보안 업데이트가 반영되지 않는 태그입니다. 베이스 이미지 레벨의 취약점까지 함께 안고 가는 셈입니다.

CI/CD 파이프라인 관점의 실무 권고

현재 PHP 7.0을 유지 중인 팀이라면 아래 순서로 접근하는 것을 권장합니다:

1. 즉시: composer outdated 실행 후 PHP 버전 제약으로 업데이트가 막힌 패키지 목록 확인
2. 단기: CI 파이프라인에 PHP 7.4 또는 8.1 병렬 테스트 스텝 추가 — 프로덕션 전환 전에 호환성 gap을 미리 파악
3. 중기: Valet이나 Sail 로컬 환경을 먼저 상위 버전으로 전환해 개발팀의 체감 저항을 낮춘 뒤 스테이징 → 프로덕션 순으로 롤아웃

핵심 메시지

PHP 7.0.26 패치 적용 자체는 막을 이유가 없지만, 배포 파이프라인과 컨테이너 이미지 전략을 PHP 7.0 기준으로 계속 최적화하는 데 리소스를 투입하는 것은 낭비입니다. 마이그레이션 로드맵이 확정되지 않은 팀일수록, 먼저 CI에서 상위 버전 호환성 검증을 자동화해두는 것이 가장 낮은 비용으로 리스크를 줄이는 방법입니다.

정리하면서 궁금한 점들 — 처음 접하는 분들을 위해

세 분 패널리스트 분들 덕분에 큰 그림은 잡혔어요! 요약하면 "7.0.26 패치는 일단 적용하되, PHP 7.0 자체가 이미 EOL이라 빨리 올려야 한다" 는 거죠? 저 같은 주니어 입장에서 실제로 뭘 먼저 해야 할지 좀 더 구체적으로 여쭤보고 싶어요.

제가 당장 확인해야 할 게 뭔지 정리해봤어요:

• composer outdated 를 실행하면 되는 건 알겠는데, 결과 화면에서 "PHP 버전 때문에 막힌 패키지" 인지 "그냥 오래된 패키지" 인지 어떻게 구별하나요?
• 현재 프로젝트가 PHP 7.0에서 돌아가고 있는지 확인하려면 어디를 먼저 봐야 하나요? phpinfo() 말고 Laravel 프로젝트 안에서 확인하는 방법이 있을까요?

그리고 한 가지 더 — 소스 자료에 체인지로그가 없다고 하셨잖아요. 세큐님이 php.net을 직접 보라고 하셨는데, 거기서 어떤 항목을 찾아봐야 "이번에 보안 패치가 포함됐구나" 라고 알 수 있는지 초보도 이해할 수 있게 설명해주실 수 있을까요? CVE 번호 같은 게 나오는 건지, 아니면 다른 형식인지 궁금합니다.

누비님 질문에 대한 실무 답변

누비님이 정리한 요약("7.0.26은 일단 적용하되, 빨리 올려야 한다")은 정확합니다. 세 가지 질문에 순서대로 답변드릴게요.

① composer outdated 결과에서 PHP 버전 제약인지 구별하는 법

composer outdated 결과에서 버전이 올라가지 않는 패키지가 있다면, composer why-not vendor/package 명령으로 원인을 확인하세요. 출력 메시지에 requires php (^7.1.0) 처럼 PHP 버전 제약이 명시되면 PHP 업그레이드 없이는 해결이 안 되는 경우입니다. 단순히 오래된 패키지라면 버전 숫자만 표시됩니다.

② phpinfo() 말고 Laravel 프로젝트 안에서 확인하는 방법

php artisan --version   # Laravel 버전 확인php -v                  # CLI PHP 버전 확인

php -v가 가장 빠릅니다. 추가로 composer.json의 require 항목에서 "php": "^7.0" 같은 제약 조건도 함께 확인하세요. FPM(웹 서버)과 CLI PHP 버전이 다른 경우도 있으니, 서버 환경이라면 퍼프님이 언급한 php:7.0-fpm 이미지 태그도 함께 점검하는 것을 권장합니다.

③ php.net 릴리스 노트에서 보안 패치 여부 확인하는 법

php.net/releases 에서 해당 버전을 클릭하면 체인지로그가 나옵니다. 보안 관련 항목은 보통 다음 형식으로 표시됩니다:

• Fixed bug #XXXXX — 일반 버그
• Fixed potential security issue in ... — 보안 관련
• CVE-2017-XXXXX — CVE 번호가 직접 언급되는 경우

다만 세큐님이 이미 지적하셨듯, 현재 소스에 체인지로그가 제공되지 않는 상태이므로 이번 토론에서는 어떤 CVE가 포함됐는지 단정할 수 없습니다. php.net 원문을 직접 확인하는 것이 유일한 정확한 방법입니다.

php.net 체인지로그 읽는 법 — 보안 항목 식별 실전 가이드

누비님 질문 중 php.net에서 보안 패치를 어떻게 식별하는가 부분을 보안 관점에서 보충합니다.

체인지로그에서 보안 항목을 찾는 구체적 패턴:

• Fixed bug #NNNNN (CVE-YYYY-NNNNN) 형태가 가장 명확한 보안 수정 표시입니다.
• Prevent..., Avoid use-after-free..., Fix heap overflow... 같은 표현도 보안 관련 수정일 가능성이 높습니다.
• 컴포넌트별로 Core, OpenSSL, mbstring, phar, session 섹션을 우선 확인하십시오. 이 영역들은 Laravel 인증·세션·파일 처리와 직접 연결됩니다.

이번 7.0.26에 대해 명확히 짚어드립니다:

현재 제공된 소스에는 체인지로그가 포함되어 있지 않습니다. 따라서 이번 토론에서 "7.0.26이 특정 CVE를 수정했다"고 말하는 것은 사실 확인 전까지 불가능합니다. 반드시 https://www.php.net/releases/7_0_26.php 원문을 직접 확인하십시오.

그러나 더 중요한 맥락을 다시 강조합니다:

7.0.26이 어떤 보안 수정을 담고 있든, PHP 7.0은 2019년 1월 이후 완전 EOL입니다. 7.0.26 이후 발견된 취약점은 공식 패치 경로가 없습니다. 즉, 체인지로그를 읽어 "이번 패치는 안전하다"고 확인하는 행위 자체가 현시점에서는 충분한 보안 관리가 되지 않습니다. 팀 내 보안 검토 문서에 이 사실을 명시적으로 기재해두시기 바랍니다.