[AX 보안 패치 리포트] PHP 8.3.29 → 8.5.12: 운영 중인 WordPress를 안전하게 갈아탄 기록

AX SECURITY PATCH REPORT · 2026.10.23

1. 프롤로그: 어제는 JSN, 오늘은 이 블로그였다

하루 전에는 10년 묵은 JSN 레거시를 PHP 8.5 환경으로 전면 현대화한 기록을 남겼다. 그런데 이번에는 대상과 접근법이 달랐다. JSN이 낡은 애플리케이션 자체를 다시 세우는 공사였다면, blog.soohwalee.com은 이미 운영 중인 WordPress를 손상 없이 최신 보안 런타임으로 옮기는 정밀 수술에 가까웠다.

계기는 2026년 10월 21일 공개된 PHP 보안 릴리스였다. PHP 프로젝트는 PHP 8.5.12를 보안 릴리스로 발표했고, 같은 날 공개된 권고문은 웹에서 PHP를 제공하는 환경에 영향을 주는 두 건의 인증 없는 원격 코드 실행 취약점을 설명했다. 특히 Apache 모듈 방식인 mod_php가 가장 높은 위험군으로 지목됐다.

WordPress 측도 이 문제는 WordPress 코어의 결함이 아니라 PHP 자체의 취약점이며, 사이트 소유자가 PHP를 즉시 업데이트해야 한다고 별도로 안내했다. 결론은 명확했다. 고칠 대상은 콘텐츠나 테마가 아니라, 그 아래에서 모든 요청을 실행하는 PHP 런타임이었다.

2. 첫 번째 함정: latest라고 최신은 아니었다

운영 환경은 Docker Compose 기반이었고 WordPress 이미지 설정에는 wordpress:latest가 적혀 있었다. 얼핏 보면 최신 버전을 쓰는 것 같지만, 실제 서버가 실행하던 로컬 이미지는 약 7개월 전에 받아 둔 것이었다. 컨테이너는 정상적으로 재시작되고 있었지만 이미지를 새로 가져오지 않는 한 내부 PHP는 계속 8.3.29에 머문다.

진단 결과는 다음과 같았다.

3. 버전 숫자를 바꾸기 전에 안전장치부터 만들었다

운영 서버의 업그레이드는 “새 이미지가 실행되는가”만으로 성공을 판단할 수 없다. 테마·플러그인·업로드 파일·데이터베이스가 함께 움직이고, 실패하면 사용자가 바로 영향을 받는다. 그래서 아래 순서를 바꾸지 않았다.

4. 전환: 바꾼 것은 런타임, 지킨 것은 운영 상태

검증이 끝난 뒤 이미지 태그를 움직이는 latest 대신 wordpress:php8.5-apache로 명시하고 WordPress 컨테이너만 다시 만들었다. 데이터 볼륨과 데이터베이스는 그대로 유지했기 때문에 콘텐츠·미디어·사용자·설정에는 손대지 않았다.

이 방식의 장점은 영향 범위가 분명하다는 데 있다. PHP와 Apache가 포함된 애플리케이션 런타임만 교체하고, 데이터 계층과 WordPress 애플리케이션 상태는 보존했다. 문제가 생기면 이전 이미지로 되돌릴 수 있고, 데이터 복원이 필요할 때만 검증된 백업을 사용하면 된다.

5. “켜졌다”가 아니라 “정상 동작한다”를 검증했다

컨테이너가 실행 중이라는 표시는 시작점일 뿐이다. 내부 런타임, WordPress 부트스트랩, 데이터베이스 연결, 확장 모듈, 공개 URL, 오류 로그, 관리자 화면을 순서대로 확인했다.

• PHP 8.5.12와 Apache 2.4.69가 실제 운영 컨테이너에서 실행됨을 확인
• WordPress 코어가 데이터베이스에 연결되고 버전 7.1.3으로 정상 부트스트랩됨을 확인
• mysqli, curl, mbstring, imagick, intl, zip, OPcache, GD, Sodium 등 필수 확장 모듈 확인
• 홈, REST API, 사이트맵, 대표 게시글이 외부에서 모두 HTTP 200을 반환
• 운영 로그에서 PHP Fatal error, Parse error, Uncaught 오류가 0건임을 확인
• WordPress ‘사이트 건강’ 화면에서 PHP 8.5.12, OPcache 활성화, Imagick 지원과 전체 상태 ‘양호’를 최종 확인

6. 이번 작업에서 다시 확인한 운영 원칙

① 정상 화면은 안전하다는 증거가 아니다

업데이트 전에도 블로그는 멀쩡하게 열렸다. 하지만 보안 취약점은 장애처럼 먼저 자신을 드러내지 않는다. 버전과 실행 방식을 확인해야만 보이는 위험이 있다.

② 백업은 “있다”가 아니라 “복구에 쓸 수 있다”여야 한다

파일 백업과 DB 덤프를 함께 만들고 압축 무결성, 체크섬, 이전 설정까지 남겼다. 백업의 목적은 안심이 아니라 복구 가능성을 증명하는 것이다.

③ 호환성 검사는 운영 전환보다 먼저 끝내야 한다

테마와 플러그인을 새 PHP 컨테이너에서 읽기 전용으로 검사한 덕분에, 전환 시간에는 이미 확인한 코드를 실행하기만 하면 됐다. 위험한 발견을 사용자 트래픽이 흐르는 순간까지 미루지 않았다.

④ 자동화의 가치는 속도보다 통제력에 있다

이번 작업에서 AI 에이전트는 진단, 공식 보안 공지 확인, 이미지 검증, 전수 검사, 백업 무결성 확인, 배포, 운영 검증을 하나의 흐름으로 연결했다. 빠른 실행보다 더 중요했던 것은 각 단계마다 성공 조건과 중단 조건을 명확히 둔 점이다.

JSN 현대화가 “오래된 시스템을 최신 기준으로 다시 세우는 법”에 대한 기록이었다면, 이번 blog.soohwalee.com 작업은 “살아 있는 서비스를 안전하게 최신 상태로 옮기는 법”에 대한 기록이다. 대상은 달랐지만 결론은 같았다. AI가 실행 속도를 높여도, 운영의 기준은 끝까지 검증 가능성과 복구 가능성이어야 한다.