English
WordPress

WordPress 보안 센터

PHP 엔진과 플러그인 취약점의 차이, PHP 업그레이드, 백업, 흔한 설정 오류를 다루는 실무 중심 WordPress 보안 가이드입니다.

업데이트 2026년 10월 24일

버전 점검하기 사이트 점검하기

이 페이지 활용 방법

WordPress 보안은 서로 다른 주체가 관리하고 서로 다른 방식으로 업데이트되는 여러 계층에 달려 있습니다. PHP 런타임, WordPress 코어, 그리고 설치한 플러그인과 테마입니다. 어느 계층에 문제가 있어도 사이트가 노출될 수 있으며, 한 계층을 고친다고 다른 계층이 해결되지는 않습니다.

이 페이지에서는 각 계층을 차례로 살펴보고, 누가 책임지는지 설명하며, 실무 단계를 정리합니다. PatchScope 도구가 도움이 되는 곳에는 링크를 걸어 두었습니다.

  • PHP 버전 검사기: 사용 중인 PHP 버전의 지원 상태와 알려진 엔진 보안 권고를 확인합니다.
  • 웹사이트 보안 검사기: HTTPS, 보안 헤더, 버전 노출, 그리고 debug.log나 wp-config.php 백업처럼 자주 노출되는 파일을 수동 점검합니다.

두 도구 모두 WordPress 사이트가 안전하다고 알려 줄 수는 없습니다. 관찰 가능한 내용을 보여 줄 뿐이며, 이 페이지의 나머지 부분은 도구가 볼 수 없는 영역을 다룹니다.

PHP 엔진 취약점은 다릅니다

PHP 자체의 취약점은 WordPress 취약점이 아니며, WordPress를 업데이트해도 해결되지 않습니다. 반대로 PHP를 업그레이드해도 취약한 플러그인이 패치되지는 않습니다.

계층 수정 주체 보안 권고 게시처 업데이트 방법
PHP 엔진(php-src) PHP 프로젝트, 이후 호스팅 업체 또는 OS 배포판 php-src GitHub 보안 권고, PHP ChangeLog, CVE/NVD, 배포판 보안 트래커 호스팅 제어판 또는 OS 패키지. 대개 호스팅 업체가 관리
WordPress 코어 WordPress 프로젝트 WordPress.org 뉴스 및 릴리스 노트 자동 백그라운드 업데이트 또는 대시보드 → 업데이트
플러그인 및 테마 각 플러그인·테마 개발자 벤더 변경 기록 및 공지, WordPress.org 플러그인 디렉터리, 서드파티 취약점 데이터베이스 대시보드에서 플러그인·테마 업데이트, 상용 제품은 벤더 자체 업데이트 방식

왜 중요한가

  • 업데이트 경로가 다릅니다. WordPress는 스스로 업데이트할 수 있지만 PHP를 업데이트할 수는 없습니다. PHP 업데이트는 호스팅 업체나 서버의 패키지 관리자를 통해 이루어집니다.
  • 백포트. 많은 서버에서 PHP는 Debian, Ubuntu, RHEL 같은 Linux 배포판이 제공합니다. 이러한 배포판은 업스트림 버전 번호를 바꾸지 않고 보안 수정을 백포트하는 경우가 많습니다. 버전 번호만으로는 수정 적용 여부를 증명할 수 없습니다. PHP 보안 패치 설치 여부 확인 방법을 참고하십시오.
  • 지원 종료 브랜치. PHP 브랜치가 지원 종료되면 PHP 프로젝트는 해당 브랜치에 대한 수정 배포를 중단합니다. 호스팅 업체가 연장 지원을 제공하지 않는 한, 새로운 엔진 취약점은 패치되지 않습니다.

WordPress와 PHP 호환성

WordPress는 요구 사항 페이지에서 권장 서버 환경을 안내합니다. WordPress 코어 핸드북에는 각 WordPress 릴리스가 지원하는 PHP 버전과 베타 지원으로 분류되는 버전을 보여 주는 PHP 호환성 표가 있습니다.

PHP 버전을 변경하기 전에 다음을 확인하십시오.

  • 추측이나 오래된 글에 의존하지 말고, 사용 중인 WordPress 버전을 호환성 표에서 확인하십시오.
  • 코어 호환성이 플러그인과 테마 호환성을 보장하지는 않습니다. PHP 업그레이드 후 문제가 생기는 가장 흔한 원인은 오래되었거나 방치된 플러그인입니다.
  • 주요 플러그인마다 목록 페이지나 변경 기록에서 테스트된 PHP 버전을 확인하십시오.

체계적인 접근 방법은 PHP 업그레이드 계획을 참고하십시오.

WordPress 코어 업데이트

자동 업데이트

WordPress는 기본적으로 보안 및 유지보수 수정이 포함된 마이너 릴리스를 백그라운드에서 자동으로 설치합니다. 다른 방법으로 업데이트를 신속하게 적용하는 관리 절차가 없다면 이 기능을 켜 두십시오. 대시보드 → 업데이트에서 현재 설정과 버전을 확인할 수 있습니다.

자동 업데이트는 파일 권한이나 호스팅 제한 등으로 인해 아무런 알림 없이 실패할 수 있습니다. 업데이트가 되었으리라 가정하지 말고, 대시보드와 사이트 상태(Site Health)를 주기적으로 확인하십시오.

메이저 업데이트

메이저 릴리스는 기능을 추가하고 동작을 바꿀 수 있습니다. 설정에 따라 수동 작업이 필요할 수 있습니다. 메이저 업데이트 전에는 다음을 수행하십시오.

  • 전체 백업을 만듭니다(아래 참고).
  • 테마나 주요 플러그인에 영향을 주는 변경 사항이 있는지 릴리스 노트를 읽습니다.
  • 비즈니스에 중요한 사이트라면 스테이징 사본에서 먼저 테스트합니다.

스테이징

스테이징 사이트는 업데이트를 테스트하기 위한 운영 사이트의 비공개 사본입니다. 많은 관리형 호스팅이 원클릭 스테이징을 제공합니다. 제공하지 않는다면 인증으로 보호된 서브도메인의 사본이나 로컬 개발 환경으로도 같은 목적을 달성할 수 있습니다. 스테이징 사이트가 검색 엔진에 색인되지 않도록 하고, 공개적으로 접근 가능한 상태로 두지 마십시오.

테마와 플러그인 취약점 관리

보고되는 WordPress 취약점의 대부분은 코어가 아닌 플러그인과 테마에서 발생합니다. 이를 관리하는 일은 지속적인 과정입니다.

목록 관리

비활성 항목을 포함하여 설치된 모든 플러그인과 테마의 목록을 버전, 출처(WordPress.org, 상용 벤더, 자체 개발), 담당자와 함께 관리하십시오. 설치되어 있는지 모르는 것은 모니터링할 수 없습니다.

사용하지 않는 항목 삭제

비활성화된 플러그인과 사용하지 않는 테마도 파일이 서버에 남아 있으므로 악용 가능한 코드를 포함할 수 있습니다. 비활성화만 하지 말고 삭제하십시오. 구성상 필요하다면 기본 테마 하나는 대체용으로 남겨 두십시오.

정기적인 업데이트 주기

  • 보안 업데이트는 배포 후 가능한 한 빨리 적용합니다.
  • 일반 업데이트는 매주 등 정해진 일정에 따라 적용합니다.
  • 관리가 잘 되고 문제 발생 위험이 낮은 플러그인은 자동 업데이트를 고려합니다.
  • 상용 플러그인은 업데이트를 받을 수 있도록 라이선스를 유효하게 유지합니다.

보안 권고와 디렉터리 폐쇄 확인

  • 의존하는 플러그인의 변경 기록과 보안 공지를 확인하십시오.
  • WordPress.org 플러그인 디렉터리에서 폐쇄된 플러그인을 주시하십시오. 폐쇄는 해결되지 않은 보안 문제나 방치된 프로젝트를 의미할 수 있습니다. 폐쇄된 플러그인은 디렉터리를 통한 업데이트가 중단됩니다.
  • WPScan, Wordfence Intelligence, Patchstack 같은 서드파티 취약점 데이터베이스는 플러그인과 테마 취약점 정보를 게시합니다. 모니터링에 유용할 수 있지만 커버리지와 게시 시점이 서로 다르므로, 벤더 권고와 함께 하나의 참고 자료로 활용하십시오.

관리되는 코드 선택

플러그인을 설치하기 전에 마지막 업데이트 시점, 개발자가 지원 요청에 응답하는지, 최신 WordPress 버전에서 테스트되었는지 확인하십시오. 방치된 플러그인은 관리되는 대안으로 교체하십시오.

백업과 복원

백업은 복원할 수 있을 때만 의미가 있습니다. 복구를 기준으로 백업을 계획하십시오.

3-2-1 원칙

  • 데이터 사본 3개
  • 서로 다른 저장 매체 또는 위치 2곳
  • 호스팅 계정과 분리된 외부 저장소에 사본 1개

사이트와 같은 서버에만 저장된 백업은 사이트와 함께 사라질 수 있습니다.

백업 대상

  • 게시물, 페이지, 설정, 사용자가 저장된 데이터베이스
  • 테마, 플러그인, 업로드 파일이 저장된 wp-content 디렉터리
  • wp-config.php와 .htaccess나 nginx 규칙 같은 사용자 정의 서버 설정. wp-config.php에는 데이터베이스 자격 증명과 키가 들어 있으므로 안전하게 보관하십시오.

백업 시점

  • 사이트 변경 빈도에 맞는 정기 일정에 따라
  • 모든 PHP 업그레이드 전, 그리고 WordPress 메이저 업데이트나 중요한 플러그인 변경 전

복원 테스트

주기적으로 백업을 스테이징 환경에 복원하여 사이트가 정상 작동하는지 확인하십시오. 복원에 걸리는 시간과 절차를 기록해 두십시오. 테스트하지 않은 백업은 계획이 아니라 가정일 뿐입니다.

호스팅 제어판에서 PHP 업그레이드하기

대부분의 공유 호스팅과 관리형 호스팅에서는 PHP 버전을 직접 변경할 수 있습니다. 정확한 절차는 호스팅 업체마다 다릅니다. 단계별 안내는 WordPress에서 PHP 업데이트하는 방법을 참고하십시오.

주요 제어판

  • cPanel: 도메인별로 PHP 버전을 설정하는 MultiPHP Manager를 찾으십시오. CloudLinux를 사용하는 호스팅에서는 Select PHP Version을 사용합니다.
  • Plesk: 도메인의 PHP 설정(호스팅 및 DNS 또는 도메인 대시보드)에서 PHP 버전과 핸들러를 선택합니다.
  • 관리형 WordPress 호스팅: 대부분 자체 사이트 대시보드에서 PHP 버전 선택 기능을 제공합니다. 호스팅 업체의 문서를 확인하십시오.
  • VPS 또는 전용 서버: PHP는 운영체제 패키지로 관리됩니다. 서버 관리자와 협의하십시오.

안전한 업그레이드 순서

  1. PHP 버전 검사기와 WordPress 호환성 표로 현재 PHP 버전을 확인합니다.
  2. WordPress 코어, 플러그인, 테마를 먼저 업데이트합니다. 최신 릴리스일수록 새로운 PHP를 지원할 가능성이 높습니다.
  3. 데이터베이스와 파일 전체를 백업합니다.
  4. 가능하면 스테이징에서 새 PHP 버전을 테스트합니다.
  5. 제어판에서 PHP 버전을 변경합니다.
  6. 도구 → 사이트 상태 → 정보 → 서버에서 WordPress가 실제로 사용하는 PHP 버전을 확인합니다.
  7. 사이트와 관리자 화면을 둘러보고, 폼, 결제, 로그인 등 주요 기능을 테스트합니다.
  8. PHP 오류 로그와, 활성화되어 있다면 wp-content/debug.log에서 새로운 경고나 치명적 오류가 있는지 확인합니다.

롤백 계획 마련

시작하기 전에 이전 PHP 버전으로 되돌리는 방법을 알아 두고, 3단계의 백업을 보관하십시오. 문제가 생기면 먼저 롤백한 다음 스테이징에서 원인을 조사하십시오. 롤백은 임시 조치로 생각하십시오. 이전 브랜치가 지원 종료 상태라면 호환되지 않는 플러그인이나 테마의 수정 일정을 잡아야 합니다.

흔한 설정 오류

다음은 WordPress 사이트에서 자주 발견되는 문제입니다. 일부는 웹사이트 보안 검사기로 외부에서 감지할 수 있지만, 나머지는 사이트나 서버 내부에서만 확인할 수 있습니다.

운영 환경의 디버그 출력

운영 사이트에서는 WP_DEBUG를 꺼야 합니다. 로그가 필요하다면 오류가 페이지에 출력되지 않도록 하고, 로그 파일에 공개적으로 접근할 수 없도록 하십시오.

// wp-config.php (운영 환경)
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );

일시적으로 로그를 켜야 한다면 WP_DEBUG_LOG에 true 대신 웹 루트 밖의 경로를 지정할 수 있습니다. 기본적으로 로그는 wp-content/debug.log에 기록되며, 차단하지 않으면 누구나 접근할 수 있습니다. 웹 서버에서 차단하십시오.

# nginx
location ~* /wp-content/debug\.log$ {
    deny all;
}
# Apache 2.4 (wp-content의 .htaccess 또는 서버 설정)
<Files "debug.log">
    Require all denied
</Files>

더 이상 필요 없는 로그 파일은 삭제하십시오. 파일 경로 등 공격자에게 유용한 정보가 담겨 있을 수 있습니다.

디렉터리 목록 노출

디렉터리 인덱싱이 켜져 있으면 방문자가 wp-content/uploads 같은 폴더의 내용을 열람할 수 있습니다. Apache에서는 Options -Indexes로 끄고, nginx에서는 autoindex가 꺼져 있는지(기본값) 확인하십시오.

노출된 wp-config.php 백업

wp-config.php.bak, wp-config.php~, wp-config.php.old처럼 편집기나 수동으로 만든 백업은 일반 텍스트로 제공되어 데이터베이스 자격 증명이 드러날 수 있습니다. 웹 루트에 wp-config.php 사본을 절대 남겨 두지 마십시오. 이미 노출되었다면 파일을 삭제하고 데이터베이스 비밀번호와 인증 키 및 솔트를 교체하십시오.

필요 없는 xmlrpc.php

xmlrpc.php는 원격 게시와 일부 연동 기능을 제공하며, 자격 증명 추측 시도의 흔한 대상입니다. 사이트에서 사용하지 않는다면 호스팅 설정, 보안 플러그인 또는 웹 서버 규칙으로 비활성화하십시오. 먼저 사용 중인 연동 기능이 이를 필요로 하지 않는지 확인하십시오.

취약한 관리자 계정

  • admin처럼 예측하기 쉬운 사용자 이름을 피하십시오.
  • 비밀번호 관리자에 저장한 길고 고유한 비밀번호를 사용하십시오.
  • 모든 관리자와 편집자 계정에 2단계 인증을 활성화하십시오.
  • 사용자 계정을 정기적으로 검토하고 더 이상 필요 없는 계정은 삭제하십시오.

오래된 PHP

지원 종료된 PHP 브랜치를 사용하면 새로운 엔진 취약점이 업스트림에서 수정되지 않습니다. PHP 버전 검사기로 버전을 확인하고 필요하면 업그레이드를 계획하십시오.

대시보드에서의 파일 편집

내장된 테마·플러그인 편집기를 사용하면 관리자 권한을 가진 누구나 브라우저에서 PHP 코드를 수정할 수 있습니다. 다음과 같이 비활성화하십시오.

// wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

잘못된 파일 권한

권한이 지나치게 넓으면 다른 프로세스나 사용자가 파일을 수정할 수 있습니다. 일반적인 기준은 디렉터리 755, 파일 644이며, wp-config.php는 호스팅 환경이 허용하는 범위에서 640이나 600처럼 더 엄격하게 설정합니다. 777은 절대 사용하지 마십시오. 올바른 설정은 서버가 PHP를 실행하는 방식에 따라 다르므로 호스팅 업체에 권장 값을 확인하십시오.

PHP 버전 노출

X-Powered-By 헤더는 정확한 PHP 버전을 드러낼 수 있습니다. 이를 숨긴다고 오래된 버전이 해결되지는 않지만, 자동화된 스캐너가 쉽게 얻을 수 있는 신호를 없앨 수 있습니다. php.ini에서 다음과 같이 설정합니다.

expose_php = Off

공유 호스팅에서는 php.ini에 직접 접근하는 대신 제어판의 PHP 옵션에서 이 설정을 변경할 수 있습니다.

간단한 체크리스트

  • PHP 브랜치가 지원 중이며, 호스팅 업체나 패키지 관리자를 통해 업데이트되고 있습니다.
  • WordPress 코어의 마이너 자동 업데이트가 켜져 있고 정상적으로 작동합니다.
  • 사용하지 않는 플러그인과 테마는 삭제했고, 나머지는 정기적으로 업데이트합니다.
  • 백업이 3-2-1 원칙을 따르고, 데이터베이스와 wp-content를 포함하며, 복원 테스트를 마쳤습니다.
  • WP_DEBUG가 꺼져 있고, debug.log에 공개적으로 접근할 수 없습니다.
  • 웹 루트에 wp-config.php 백업이 없습니다.
  • 관리자는 강력한 비밀번호와 2단계 인증을 사용합니다.
  • DISALLOW_FILE_EDIT가 설정되어 있고, 파일 권한이 적절합니다.
  • expose_php = Off가 설정되어 있습니다.

변경 후에는 웹사이트 보안 검사기를 실행하여 외부에서 보이는 내용을 확인하십시오. 다만 이 도구는 서버 내부, 플러그인, 코드를 볼 수 없다는 점을 기억하시기 바랍니다.