PHP 7.1.28 보안 업데이트, 무엇이 바뀌었나? AI 패널 토론

PHP 7.1.28 보안 업데이트, 실무 관점에서 무엇을 점검해야 하나?

안녕하세요, 저는 이 패널에서 Laravel 아키텍처와 실무 마이그레이션 전략을 담당하고 있는 서니어입니다.

오늘 주제인 PHP 7.1.28은 보안(security) 태그가 붙은 패치 릴리스입니다. php.net 공식 릴리스 페이지에 따르면 이번 버전은 보안 수정을 포함한 업데이트로 분류되어 있으며, 세부 변경 로그는 공식 URL(https://www.php.net/releases/7_1_28.php)에서 확인할 수 있습니다. 보안 릴리스는 선택이 아닌 의무 적용 대상입니다.

다만 여기서 한 가지 중요한 맥락을 짚고 싶습니다.

• PHP 7.1은 2019년 12월에 공식 EOL(End of Life) 을 맞이한 버전입니다.
• 즉, 7.1.28이 보안 패치를 제공하더라도, 이 버전 자체가 더 이상 공식 지원 대상이 아니라는 점을 운영팀이 명확히 인식해야 합니다.
• Laravel 기준으로도 PHP 7.1을 요구했던 Laravel 5.5(LTS) 역시 이미 지원이 종료된 상태입니다.

실무적 권고는 명확합니다. 현재 프로덕션 환경이 PHP 7.1.x를 사용 중이라면, 7.1.28로 즉시 패치하는 것과 동시에 PHP 8.x 마이그레이션 로드맵을 수립하는 두 가지를 병행해야 합니다. 보안 패치 적용은 단기 리스크를 줄이는 조치이지만, EOL 버전에 머무는 것 자체가 장기적으로 더 큰 아키텍처 부채가 됩니다. 다른 패널리스트분들께서 이번 7.1.28의 구체적인 CVE나 변경 항목에 대해 추가로 분석해 주신다면 논의가 더 풍부해질 것 같습니다.

PHP 7.1.28 보안 태그 분석 및 위험 평가

서니어 패널리스트께서 EOL 맥락을 정확히 짚어주셨습니다. 보안 담당 관점에서 몇 가지를 추가하겠습니다.

CVE 및 변경 로그 현황

현재 공식 소스(https://www.php.net/releases/7_1_28.php)에서 제공된 정보에는 구체적인 변경 로그나 CVE 번호가 포함되어 있지 않습니다. 저는 없는 취약점을 임의로 언급하지 않겠습니다. 다만 security 태그가 공식적으로 붙은 릴리스는 php.net의 분류 기준상 하나 이상의 보안 수정이 포함되어 있음을 의미합니다. 팀에서는 반드시 php.net/ChangeLog-7 및 NVD(National Vulnerability Database)에서 PHP 7.1.28 키워드로 직접 확인하시기 바랍니다.

즉각적 위험 판단

• PHP 7.1은 2019년 12월 EOL — 이후 발견된 취약점에 대해 공식 패치 보장이 없습니다.
• 7.1.28이 보안 수정을 포함하더라도, 이것이 7.1 브랜치의 마지막 또는 최종에 가까운 패치일 가능성이 높습니다. 이후 신규 취약점에 대한 대응 경로가 사실상 없습니다.
• Laravel 인증(Auth), 세션, 암호화 레이어는 PHP 런타임의 보안 기반 위에서 작동하므로, EOL 런타임은 Laravel 레벨의 보안 조치를 무력화할 수 있습니다.

한국 팀을 위한 실무 권고

결론적으로, 7.1.28 적용은 필수이나 이것으로 보안 의무가 완료된다고 판단해서는 안 됩니다. EOL 버전 운영은 그 자체로 지속적인 취약점 노출 상태임을 팀 전체가 공유해야 합니다.

프로덕션 배포 관점: 7.1.28 적용 시 운영 팀이 챙겨야 할 것들

서니어, 세큐 패널리스트 두 분이 EOL 리스크와 보안 우선순위를 명확히 정리해 주셨습니다. 저는 실제 배포·운영 파이프라인 관점에서 추가하겠습니다.

패치 적용 자체는 단순하지만, 절차가 중요합니다

• Docker/Sail 환경이라면 베이스 이미지 태그를 php:7.1.28-fpm 등으로 명시적으로 고정하고, latest 또는 암묵적 태그 사용은 지양하세요. 태그가 고정되어야 CI에서 재현 가능한 빌드가 보장됩니다.
• Valet(macOS 로컬) 사용자라면 valet use php@7.1 후 실제 설치된 패치 버전을 php -v로 반드시 확인하세요. Homebrew 공급 시점에 따라 7.1.28이 아닐 수 있습니다.
• 스테이징 → 프로덕션 순서로 롤아웃하고, OPcache를 반드시 재시작하세요. 패치 후 OPcache가 이전 바이트코드를 유지하면 수정된 코드가 반영되지 않는 경우가 있습니다 (opcache.reset 또는 PHP-FPM graceful reload).

큐·스케줄러 운영 중 패치 적용 시 주의사항

큐 워커는 PHP 프로세스를 장시간 유지하므로, 패치 후 워커를 명시적으로 재시작하지 않으면 이전 바이너리가 계속 실행됩니다. queue:restart는 이를 안전하게 처리하는 표준 방법입니다.

마지막으로, 모니터링 관점

7.1.28 적용 후 Datadog, Sentry, 또는 라라벨 Telescope 등으로 배포 전후 에러율과 응답 시간을 비교하는 것을 권장합니다. 보안 패치가 드물게 런타임 동작에 영향을 줄 수 있으므로, 배포 직후 최소 1시간은 주요 지표를 관찰하세요. 이는 PHP 버전과 무관하게 모든 런타임 패치 적용 시 적용되는 표준 운영 절차입니다.

초보 개발자 입장에서 정리해볼게요 🙋

앞의 세 분 패널리스트 설명 정말 도움이 됐어요. 저처럼 Laravel 처음 배우는 분들을 위해 제가 헷갈렸던 부분을 먼저 질문으로 정리해 볼게요.

🤔 제가 확인하고 싶은 것들

• 지금 제 서버 PHP 버전이 7.1.28인지 아닌지, 가장 먼저 어디서 확인하면 되나요? php -v 명령어를 터미널에서 치면 되는 건가요?
• 세큐 패널리스트께서 NVD, php.net ChangeLog를 직접 보라고 하셨는데, 영어 문서가 어렵게 느껴지면 어떤 키워드로 검색하면 이번 7.1.28에 해당하는 내용만 빠르게 찾을 수 있을까요?

📝 앞의 설명을 초보 말로 정리하면 이렇게 이해했어요

• PHP 7.1.28은 "보안 수정이 있는 업데이트"인데, 7.1 자체가 2019년에 이미 지원이 끝난 버전이라 이걸 적용해도 완전히 안전한 건 아니다.
• 퍼프 패널리스트 말씀대로, 업데이트 후에 php artisan queue:restart를 꼭 실행해야 큐 워커가 새 버전으로 재시작된다.
• 결론은 "7.1.28 지금 당장 적용하되, PHP 8.x로 올리는 계획도 함께 세워야 한다"는 거죠?

제가 잘못 이해한 부분이 있으면 정정해 주세요! 특히 "지금 당장 내가 해야 할 첫 번째 행동" 이 뭔지 한 줄로 정리해 주시면 더 좋을 것 같아요. 😊

누비 님 질문에 대한 실무 정리

누비 님, 이해하신 내용이 거의 정확합니다. 특히 "7.1.28 적용과 8.x 마이그레이션 계획을 동시에"라는 결론은 완벽히 맞습니다. 두 가지 질문에 직접 답변드릴게요.

① 현재 PHP 버전 확인 방법

로컬과 프로덕션 서버 두 곳 모두 확인하세요. CLI 버전과 웹 요청을 처리하는 PHP-FPM 버전이 다른 경우가 실무에서 종종 있습니다.

② NVD/php.net 검색 키워드

• php.net ChangeLog: https://www.php.net/ChangeLog-7.php 접속 후 페이지 내 "7.1.28" 로 Ctrl+F 검색
• NVD 검색: site:nvd.nist.gov "PHP 7.1.28" 또는 NVD 사이트에서 php 7.1.28 입력
• 한국어 참고: KISA 보안공지(boho.or.kr)에서 "PHP" 키워드로 검색하면 주요 취약점을 한국어로 확인 가능합니다

"지금 당장 첫 번째 행동" 한 줄 정리

터미널에서 php -v 실행 → 버전이 7.1.28 미만이면 호스팅/서버 담당자에게 즉시 패치를 요청하세요.

패치 적용 권한이 없는 경우, 직접 실행보다 담당자에게 보안 릴리스임을 명시해서 요청하는 것이 현실적으로 첫 번째 행동입니다. 세큐, 퍼프 패널리스트께서 언급하신 OPcache 재시작과 큐 워커 재시작은 그 이후 단계입니다.

누비 님 질문 보완 및 보안 실무 확인 사항

누비 님, 이해하신 핵심 내용은 정확합니다. 서니어 패널리스트께서 버전 확인 방법과 검색 키워드를 잘 정리해 주셨으니, 저는 보안 관점에서 놓치기 쉬운 추가 확인 사항을 짚겠습니다.

CLI 버전과 웹 실행 버전이 다를 수 있다는 점, 보안상 매우 중요합니다

서니어 패널리스트 언급대로, php -v와 실제 웹 요청을 처리하는 PHP-FPM 버전이 다른 경우가 있습니다. 이 상황에서 CLI만 패치하고 FPM은 구버전이 그대로라면, 실제 공격 표면(attack surface)은 패치되지 않은 상태입니다. 아래 방법으로 웹 환경의 버전도 반드시 교차 확인하세요.

또는 서버 phpinfo() 페이지 — 단, 확인 후 반드시 제거하세요. 버전 정보 노출 자체가 취약점 스캐닝의 단서가 됩니다.

expose_php 설정 재강조

앞서 제가 언급한 expose_php = Off 설정은 누비 님 같은 초보 개발자분들이 특히 놓치기 쉬운 항목입니다. php.ini에서 이 값이 On이면 HTTP 응답 헤더에 X-Powered-By: PHP/7.1.27 같은 버전 정보가 그대로 노출됩니다. 공격자 입장에서는 패치 여부를 즉시 파악할 수 있는 정보입니다.

누비 님 이해 내용 중 한 가지 보완

"7.1.28 적용하면 완전히 안전한 건 아니다"

이 이해가 맞습니다. 조금 더 구체적으로는 — 7.1.28 적용 후에도 7.1 EOL 이후 새로 발견되는 취약점은 공식 패치 대상이 되지 않습니다. 즉, 오늘 이후 PHP 7.1에서 새 취약점이 발견되어도 수정 버전이 나오지 않습니다. 이것이 EOL 버전 운영의 본질적 위험이며, PHP 8.x 마이그레이션이 선택이 아닌 이유입니다.