Backend
개인 NAS에서 운영하던 홈페이지의 실행 환경을 바꿨다.
이번 NAS WordPress Docker 이전의 계기는 2026년 10월에 나온 PHP 보안 공지였다.
겉으로 보기에는 홈페이지가 평소처럼 잘 열리고 있었지만, 그 뒤에서 돌아가는 PHP 실행 환경은 이미 꽤 오래된 상태였다.
PIXICLUE는 Synology NAS의 기본 웹 서비스에서 PHP 8.0으로 운영하고 있었다.
글과 사진도 쌓였고, 검색 노출과 광고도 이어지고 있어서, 기존 콘텐츠를 유지하면서 운영 환경을 손보는 것이 중요했다. 이번 글은 그 과정을 정리한 기록이다.
오래된 실행 환경을 점검하고, 앞으로도 관리하기 쉬운 구조로 바꾸기 위해 진행한 예방적 정비 작업이었다.
WordPress는 글과 화면을 만드는 과정에서 서버의 PHP를 사용한다.
WordPress 자체를 최신으로 유지하더라도, 실제 실행 기반인 PHP의 지원 상태와 보안 업데이트 여부는 별도로 확인해야 한다.
2026년 10월 21일 PHP 개발팀은 CVE-2026-109618과 CVE-2026-109619에 대한 보안 업데이트를 발표했다.
원격 코드 실행 취약점은 외부 요청을 통해 서버에서 의도하지 않은 코드가 실행될 수 있는 문제다.
PHP 8.4 계열의 수정 버전은 8.4.27이다. 자세한 내용은 PHP 공식 보안 공지에서 확인할 수 있다.
당시 사용하던 PHP 8.0은 이미 PHP 프로젝트의 공식 보안 지원이 끝난 상태였다.
이번 취약점에 대해 구버전용 최소 소스 패치도 제공되긴 했지만, 그것이 정규 지원 재개를 의미하는 것은 아니었다.
계속 운영할 홈페이지라면 지원되는 버전으로 옮기는 편이 맞겠다고 판단했다.
지원 상태는 PHP 공식 지원 버전 안내를 기준으로 확인했다.
이틀 뒤인 10월 23일에는 CVE-2026-115560과 관련된 추가 안내가 나왔다.
특정 세션 설정과 프로그램 동작이 함께 맞물릴 때 발생할 수 있는 문제로, 모든 PHP 사이트에 똑같이 적용되는 종류는 아니었다.
2026년 10월 25일 확인한 PHP 공식 추가 권고에서는 다음 정규 버그 수정 릴리스 전까지 세션 업로드 진행률 기능을 끄도록 권고하고 있었다.
이 설정은 21일 공지에서도 일부 공격 경로에 대한 완화책으로 언급됐지만, 23일 안내의 취약점 번호와 후속 대응은 구분해서 볼 필요가 있었다.
여기서 중요했던 점은 21일 발표된 두 취약점의 보안 패치를 적용하는 것과, 23일 추가 권고에 대응하는 것은 별도라는 점이었다.
PHP 버전을 한 번 올렸다고 이후 공지를 그냥 넘길 수 있는 상황은 아니었다.
기존에는 NAS 기본 웹 서비스와 WordPress 실행 환경이 강하게 연결돼 있었다.
PHP를 바꿀 때 홈페이지뿐 아니라 NAS의 다른 서비스에 미칠 영향도 함께 생각해야 했다.
앞으로도 비슷한 업데이트를 계속해야 할 텐데, WordPress 환경을 별도로 관리할 수 있으면 좋겠다고 봤다.
그래서 Docker로 WordPress와 MariaDB 실행 환경을 나눴다.
Docker는 프로그램과 실행에 필요한 환경을 컨테이너 단위로 구성하는 도구다.
이번에는 NAS 기본 PHP와 홈페이지용 PHP를 분리하고, 데이터베이스도 독립적으로 관리하는 데 사용했다.
물론 Docker를 쓴다고 해서 자동으로 안전해지는 것은 아니다.
다만 내가 관리해야 할 PHP 버전과 운영 설정의 범위를 더 명확하게 나눌 수 있고, 이후 업데이트나 복구를 준비하기 쉬운 구조를 만들 수 있다는 점이 선택 이유였다.
가장 먼저 WordPress 웹 파일과 데이터베이스를 각각 백업했다.
게시글과 페이지뿐 아니라 테마, 플러그인, 사진과 주요 설정까지 그대로 가져가는 것이 우선이었다.
새로운 환경을 준비하더라도 문제가 생기면 기존 환경과 백업으로 돌아갈 수 있게 해 두었다.
Docker에 WordPress와 MariaDB를 구성하고, WordPress에는 보안 업데이트가 적용된 PHP 8.4 계열 환경을 사용했다.
NAS 기본 PHP와 새 환경의 PHP가 섞이지 않도록 분리한 뒤, 백업한 웹 파일과 데이터베이스를 옮겼다.
이미 운영 중이던 홈페이지라 주소도 중요했다.
기존 게시글과 이미지, 테마와 플러그인을 유지하고, URL 구조도 최대한 그대로 가져갔다.
방문자가 예전 주소로 들어왔을 때 같은 글을 볼 수 있어야 했기 때문이다.
데이터를 옮긴 다음에는 기존 공개 접속 경로가 새 Docker WordPress로 연결되도록 전환했다.
이전에 사용하던 오래된 PHP 환경은 외부에서 접근하지 못하도록 분리했다.
이 단계에서 중요한 것은 단순히 첫 화면이 열리는지 보는 것이 아니었다.
운영 중인 홈페이지인 만큼, 평소 하던 관리 작업과 검색·광고 관련 요소까지 실제로 문제없이 이어지는지 확인해야 했다.
첫 화면이 정상이어도 관리자 화면이나 이미지 업로드에서 문제가 생길 수 있다.
검색엔진과 광고에 필요한 항목도 있기 때문에, 실제 운영에 사용하는 기능을 나눠 확인했다.
| 확인 범위 | 확인한 내용 |
|---|---|
| 홈페이지와 콘텐츠 | 홈페이지 접속, 기존 게시글과 페이지, 이미지와 미디어 표시 |
| 관리자 작업 | WordPress 관리자 로그인, 게시글 편집, 이미지 업로드 |
| 기존 주소 | 기존 URL 접근과 리디렉션 |
| 검색 관련 항목 | XML 사이트맵, robots.txt, SEO 메타데이터, canonical |
| 광고 관련 항목 | ads.txt와 AdSense 스크립트 |
| 서버 측 확인 | PHP 오류 로그와 테마 경고 |
실제 점검 과정에서는 PHP 버전 차이로 일부 테마 경고가 발생해 원인을 찾아 수정했다.
이후 핵심 기능이 정상 동작하는 것을 확인하고 운영을 이어갔다.
검색 관련 설정과 광고 스크립트가 유지되는지도 함께 확인했다.
이것은 검색 순위나 광고 수익이 좋아졌다는 의미가 아니라, 기존 운영 요소가 끊기지 않았는지를 확인한 것이다.
Docker로 옮긴 뒤에도 새 보안 공지를 다시 확인했다. 10월 23일의 세션 관련 권고에 따라 적용한 항목은 다음과 같다.
session.upload_progress.enabled=0이 설정은 세션을 이용한 업로드 진행률 추적을 끄는 것이다.
일반 파일 업로드 기능 전체를 막는 설정은 아니다. 기능의 역할은 PHP 업로드 진행률 문서에서도 확인할 수 있다.
설정 파일에 값을 적는 것으로 끝내지 않고, 실제 웹 요청을 처리하는 PHP와 예약 작업용 PHP에서 반영 여부를 따로 확인했다.
그다음 WordPress 관리자 화면에서 이미지를 올려 정상적으로 업로드되는지도 다시 확인했다.
추가 권고를 적용했지만 이것이 곧 모든 후속 이슈가 종료됐다는 뜻은 아니다.
이후 공식 수정 릴리스와 추가 보안 업데이트는 계속 확인할 예정이다.
운영 환경이 바뀐 만큼 정기 백업도 새 구조에 맞췄다.
WordPress 파일과 데이터베이스, 필요한 운영 설정을 함께 보존하고 최근 검증된 백업 세트를 유지하도록 구성했다.
백업 파일의 무결성을 확인하고, 별도 복원 시험도 진행했다.
백업이 만들어졌다는 것과 그 백업으로 실제로 되돌릴 수 있다는 것은 별개의 문제였다.
이번에는 복원 시험까지 마쳐야 이전 작업이 끝났다고 볼 수 있었다.
다만 같은 NAS 안에 보관하는 백업은 장비 전체의 장애에 대비하는 외부 백업을 대신할 수 없다.
별도 외부 저장소를 이용한 백업은 앞으로 보완해야 할 부분이다.
이번 NAS WordPress Docker 이전으로 PHP 8.0에 의존하던 환경에서 벗어나, 홈페이지용 PHP와 데이터베이스를 분리해 관리하게 됐다.
기존 콘텐츠와 URL은 유지했고, 주요 기능과 추가 보안 권고, 자동 백업과 복원까지 확인했다.
가장 크게 느낀 점은 홈페이지가 잘 열린다는 것과 실행 환경이 계속 지원된다는 것은 별개라는 점이었다.
앞으로는 WordPress 업데이트와 함께 PHP, 데이터베이스, 실행 환경의 지원 여부도 함께 살펴보려고 한다.
보안 공지 때문에 시작한 작업이었지만, 결과적으로는 앞으로 업데이트하고 관리할 방식을 정리하는 계기가 됐다.
오래 운영할 홈페이지라면 겉으로 보이는 화면뿐 아니라, 그 뒤에서 돌아가는 실행 환경도 가끔은 들여다봐야겠다고 느꼈다.
다른 개발 기록은 WebLab에 모아 두었다.