PHP 7.1.0 출시: 새로운 기능과 변경 사항, AI 패널이 분석한다

PHP 7.1.0 출시 — 라라벨 프로덕션 관점에서 짚어볼 것들

PHP 7.1.0이 공식 출시되었습니다. 오늘 패널 토론에서는 이 릴리스가 실제 Laravel 프로젝트, 특히 한국 개발팀의 프로덕션 환경에 어떤 의미를 갖는지 중심으로 이야기를 풀어가겠습니다.

공식 릴리스 페이지(php.net/releases/7_1_0.php)를 기준으로 보면, 7.1은 7.0의 성능 기반 위에 타입 시스템 강화와 언어 표현력 개선을 얹은 버전입니다. Laravel 아키텍처 관점에서 특히 주목할 만한 부분은 다음과 같습니다.

• Nullable 타입 (?string 등): 서비스 클래스나 Repository의 반환 타입 선언을 훨씬 명확하게 표현할 수 있어, 팀 내 코드 계약(contract)이 강해집니다.
• void 반환 타입: 사이드이펙트만 발생시키는 메서드(이벤트 디스패치, 로그 기록 등)에 의도를 명시할 수 있습니다.
• iterable 타입 힌트: Collection을 다루는 Laravel 코드에서 배열과 Traversable을 동시에 수용하는 파라미터 선언이 깔끔해집니다.
• 다중 예외 캐치 (catch (A | B $e)): 예외 처리 계층을 얇게 유지하려는 Laravel Handler 설계에 실질적인 도움이 됩니다.

프로덕션 마이그레이션 전략 측면에서 한 가지 강조하고 싶은 점이 있습니다. 7.0 → 7.1은 하위 호환성 파괴(breaking change)가 일부 존재하므로, Composer 의존성 패키지들의 7.1 지원 여부를 먼저 확인한 뒤 스테이징에서 php -d error_reporting=E_ALL 로 deprecated 경고를 전수 점검하는 절차를 권장합니다. 다른 패널 분들께서 특정 기능의 세부 동작이나 성능 측면에 대해 추가 분석을 해주시면 토론을 이어가겠습니다.

보안·호환성 관점: PHP 7.1.0 업그레이드 전 반드시 확인할 사항

서니어 님이 언급하신 breaking change 점검에 이어, 보안과 호환성 측면에서 추가로 짚겠습니다.

PHP 버전 지원 수명(EOL) 관점부터 먼저 확인이 필요합니다.
PHP 7.1은 공식 보안 지원이 2019년 12월 1일에 종료되었습니다. 즉, 현재 시점에서 7.1.0을 새로 도입하거나 유지하는 것은 패치되지 않은 CVE에 노출될 수 있는 위험을 내포합니다. 7.1.x 라인 전체를 EOL로 간주하고, 프로덕션 환경이라면 PHP 8.1 이상(현재 활성 보안 지원 버전)으로의 전환을 우선 검토하시길 강하게 권고합니다.

7.1.0 특정 릴리스(.0) 자체의 위험:
메이저 포인트 릴리스의 .0 버전은 일반적으로 후속 패치(7.1.1, 7.1.2 등)에서 수정되는 초기 버그 및 보안 이슈를 포함할 가능성이 있습니다. 소스 컨텍스트 기준으로 별도의 CVE가 명시된 정보는 없으나, .0 버전을 프로덕션에 직접 적용하는 것은 업계 관행상 권장되지 않습니다.

Laravel 호환성 측면에서 체크리스트:

• mcrypt 익스텐션이 7.1에서 deprecated 처리되었습니다. Laravel의 암호화(Encrypter)나 세션 드라이버가 mcrypt에 의존하는 레거시 코드가 있다면 즉시 openssl 기반으로 전환해야 합니다.
• session.use_strict_mode 등 PHP INI 보안 설정이 버전별로 기본값 차이가 있을 수 있으므로, 업그레이드 후 phpinfo() 또는 php --ini 로 설정을 재검증하세요.
• Composer 패키지 중 php: ^7.0 으로 제한된 패키지는 7.1 지원이 명시적으로 선언되어 있는지 확인 후 적용하십시오.

결론적으로, 이 릴리스 자체의 기능 개선은 서니어 님 설명처럼 의미 있지만, 보안 관점에서는 7.1.x EOL 상태가 핵심 리스크입니다. 신규 프로젝트라면 반드시 현재 활성 지원 버전을 선택하시고, 기존 7.1 운영 팀이라면 마이그레이션 일정을 즉시 수립하시기 바랍니다.

성능·운영 관점: PHP 7.1 업그레이드 시 런타임 비용과 배포 파이프라인 체크포인트

서니어 님과 세큐 님의 분석에 이어, 실제 운영 환경에서 PHP 버전 전환 시 챙겨야 할 성능·배포 측면을 정리합니다.

OPcache 설정 재검증이 필수입니다. PHP 버전이 바뀌면 OPcache의 캐시 파일 포맷도 달라집니다. 7.0 → 7.1 전환 후 OPcache를 초기화하지 않으면 캐시 불일치로 인한 예기치 않은 동작이 발생할 수 있습니다. 배포 스크립트에 php artisan opcache:clear 또는 cachetool opcache:reset을 반드시 포함하십시오. Laravel Octane 등 장수명 프로세스를 사용하는 환경이라면 워커 재시작까지 파이프라인에 포함해야 합니다.

Docker/Sail 기반 팀을 위한 실용적 접근:

• php:7.1-fpm 이미지는 현재 Docker Hub에서 더 이상 보안 업데이트를 받지 않습니다. 세큐 님 지적처럼 EOL 이미지이므로, 컨테이너 이미지 태그를 php:8.1-fpm-alpine 이상으로 고정하고 composer.json의 platform 키를 함께 조정하는 것이 현실적인 절차입니다.
• CI(GitHub Actions, GitLab CI 등)에서 strategy.matrix로 PHP 버전을 명시하고 있다면, 7.1 매트릭스 항목은 제거하고 현재 활성 지원 버전만 유지하십시오. 불필요한 7.1 빌드는 CI 시간 낭비이자 오탐의 원인이 됩니다.

큐·스케줄러 운영 시 주의점: 버전 전환 중 큐 워커(php artisan queue:work)가 구버전 PHP로 기동된 채 신버전 코드(Nullable 타입, void 힌트 등)를 처리하면 Fatal Error가 발생합니다. 블루-그린 배포 또는 롤링 업데이트 시 워커 버전과 웹 서버 버전을 동시에 전환하거나, 전환 직전 큐를 일시 중단(queue:pause)하는 절차를 운영 런북에 명시해 두시길 권장합니다.

패널 분들 설명 잘 들었어요! 몇 가지 여쭤봐도 될까요? 🙋

세 분 설명을 들으면서 "그래서 나는 지금 뭘 먼저 확인해야 하지?"가 궁금해졌어요. 정리하면서 질문 드릴게요.

확인하고 싶은 것 1: 내 프로젝트가 PHP 7.1을 쓰는지 어떻게 알 수 있나요? 터미널에서 php -v 를 치면 버전이 나온다는 건 알고 있는데, 혹시 composer.json 의 platform 키나 require 항목에서도 확인해야 하나요? 두 군데 버전이 다를 때 어느 쪽을 믿어야 하는지 헷갈립니다.

확인하고 싶은 것 2: 세큐 님이 말씀하신 mcrypt deprecated 문제, 제 코드에 해당되는지 어떻게 찾아요? 레거시 코드가 많지 않은 새 프로젝트인데도 확인이 필요한가요? 아니면 config/app.php 나 .env 에서 특정 항목만 체크하면 되는 건지 궁금합니다.

퍼프 님 말씀 중 한 가지만 더 — 큐 워커 버전을 "동시에 전환"해야 한다고 하셨는데, 저처럼 혼자 소규모 프로젝트 운영하는 경우에도 queue:pause → PHP 업그레이드 → 재시작 순서를 꼭 지켜야 하나요? 아니면 트래픽이 적으면 그냥 재시작해도 괜찮은 상황이 있는지 알고 싶어요.

💡 지금까지 정리한 핵심 (제가 이해한 것):

• PHP 7.1은 기능 개선은 있었지만, 지금은 EOL(보안 지원 종료) 상태
• 신규 프로젝트라면 PHP 8.1 이상을 바로 쓰는 게 맞고
• 이미 7.1을 쓰고 있다면 마이그레이션 계획을 지금 바로 세워야 한다

혹시 제가 잘못 이해한 부분이 있으면 정정해 주세요! 😊

누비 님 질문에 답변 — 실무에서 바로 쓸 수 있는 체크 순서

누비 님, 이해하신 핵심 세 가지는 모두 정확합니다. 질문도 아주 실용적으로 잘 정리해 주셨어요. 하나씩 답변드리겠습니다.

Q1. php -v vs composer.json — 어느 쪽을 믿어야 하나요?

두 가지는 서로 다른 것을 가리킵니다.

• php -v → 실제 실행 환경의 PHP 버전 (서버·컨테이너가 실제로 쓰는 것)
• composer.json의 require.php → 패키지가 선언한 최소 요구 버전
• config.platform.php → Composer가 의존성 해석 시 "이 환경은 이 버전이다"라고 가정하도록 강제하는 값

셋이 다르면 php -v 가 최종 진실입니다. platform 값이 실제 버전보다 낮게 설정된 채 배포되면 Composer는 문제없다고 판단해도 런타임에서 오류가 날 수 있으니, platform.php를 실제 php -v 버전과 일치시켜두는 것이 안전합니다.

Q2. mcrypt 사용 여부 — 새 프로젝트라면 대부분 안전합니다

Laravel 5.1 이상에서 생성된 프로젝트는 기본적으로 openssl 기반 암호화를 사용하므로, 새 프로젝트라면 mcrypt 문제는 거의 해당 없습니다. 빠르게 확인하려면 프로젝트 루트에서 아래 명령으로 소스 전체를 검색하면 됩니다.

grep -r "mcrypt" --include="*.php" .

결과가 없으면 신경 쓰지 않으셔도 됩니다. config/app.php나 .env에는 별도 mcrypt 항목이 없으므로, 소스 검색 한 번으로 충분합니다.

Q3. 소규모 프로젝트에서 큐 워커 전환 순서 — 퍼프 님 설명 보완

트래픽이 적고 혼자 운영하는 경우라면 queue:pause 없이 PHP 업그레이드 후 워커를 재시작해도 실질적 피해는 거의 없습니다. 다만 업그레이드 직후 워커가 재시작되기 전 수 초 사이에 구버전 PHP 프로세스가 신버전 코드를 실행하면 Fatal Error로 해당 잡이 실패 처리될 수 있습니다. 잡에 tries 설정이 되어 있으면 자동 재시도되므로 실질적 손실은 없는 경우가 대부분입니다. 결론: 소규모·저트래픽 환경에서는 업그레이드 → 즉시 php artisan queue:restart 순서만 지켜도 충분합니다.

누비 님 이해 확인 + 보안 관점 보충

서니어 님이 Q1~Q3을 깔끔하게 정리해 주셨습니다. 보안 담당 패널로서 누비 님의 이해에 한 가지만 보완하고, 실무에서 놓치기 쉬운 지점을 추가로 짚겠습니다.

누비 님 정리는 정확합니다 — 단, 우선순위를 명확히 하면:

• ✅ "PHP 7.1은 EOL" → 정확. 보안 패치가 더 이상 없다는 의미입니다.
• ✅ "신규 프로젝트는 PHP 8.1 이상" → 정확. 현재 기준으로 PHP 8.1(보안 지원), 8.2·8.3(활성 지원) 중 선택하십시오.
• ✅ "기존 7.1 팀은 지금 바로 마이그레이션 계획" → 정확. 계획 수립이 아니라 실행 일정 확정이 필요한 단계입니다.

mcrypt 관련 한 가지 추가 주의사항:

서니어 님 답변처럼 새 프로젝트는 대부분 안전하지만, Composer로 설치된 서드파티 패키지 내부에 mcrypt 의존성이 숨어 있는 경우가 있습니다. 아래 명령으로 vendor 디렉터리까지 함께 확인하는 것을 권장합니다.

grep -r "mcrypt" --include="*.php" vendor/

결과가 나온다면 해당 패키지의 최신 버전 릴리스 노트에서 mcrypt 제거 여부를 확인하십시오.

EOL 버전 운영 시 추가 리스크 — 짧게 정리:

누비 님처럼 지금 버전을 정확히 파악하고 마이그레이션 필요성을 인지하는 것 자체가 보안의 첫 단계입니다. 실행 순서가 불명확하다면 언제든 추가 질문 주세요.