워드프레스 보안 취약점 점검 체크리스트와 대응 순서

워드프레스 보안 취약점 점검 체크리스트는 업데이트 알림만 확인하는 목록이 아닙니다. 코어·플러그인·테마의 알려진 취약점, 관리자 권한, 서버 파일, 백업과 로그를 함께 살펴야 실제 위험을 찾을 수 있습니다. 먼저 아래 세 가지부터 확인해 보세요. 출처가 불분명한 확장 기능이 있는지, 알 수 없는 관리자 계정이 추가됐는지, 오늘 복구할 수 있는 정상 백업이 있는지입니다. 하나라도 확신할 수 없다면 우선 점검 대상으로 분류해야 합니다.

이 글은 초보 운영자가 사이트를 망가뜨리지 않으면서 확인할 수 있는 순서로 구성했습니다. 파일 권한이나 서버 설정을 바꾸기 전에는 전체 백업을 만들고, 호스팅 업체가 권장하는 설정도 확인해야 합니다.

취약점과 보안 설정 미흡은 무엇이 다른가

취약점은 특정 버전의 프로그램이나 코드에 존재해 공격에 악용될 수 있는 결함을 뜻합니다. 반면 약한 비밀번호, 불필요한 관리자 계정, 복구 시험을 하지 않은 백업은 운영 설정과 절차의 문제입니다. 둘은 구분되지만 실제 사고에서는 연결될 수 있습니다. 예를 들어 오래된 플러그인의 결함으로 계정 정보가 노출되고, 재사용한 비밀번호 때문에 관리자 권한까지 탈취될 수 있습니다.

따라서 보안 플러그인의 검사 결과가 정상이라고 해서 점검이 끝나는 것은 아닙니다. 자동 스캐너가 코드와 알려진 위협을 찾는 동안 운영자는 계정의 필요성, 확장 기능의 지원 상태, 로그의 맥락과 복구 가능성을 판단해야 합니다. 보안은 위험을 완전히 없애는 작업이 아니라 침입 가능성과 사고 피해를 지속적으로 줄이는 과정입니다.

워드프레스 보안 취약점 점검 체크리스트

코어 버전과 보안 업데이트 확인

[높음] □ 확인: 관리자 화면의 ‘대시보드 → 업데이트’에서 워드프레스 버전과 대기 중인 업데이트를 확인합니다. ‘도구 → 사이트 건강’에서는 오래된 서버 소프트웨어나 HTTPS 문제 같은 개선 항목도 함께 살펴봅니다.

위험과 조치: 오래된 코어에는 이미 공개된 결함이 남아 있을 수 있습니다. 변경 이력과 호환성을 확인하고 파일·데이터베이스 백업을 만든 다음 업데이트하세요. 운영 사이트라면 복제한 스테이징 환경에서 로그인, 글 작성, 결제와 문의 기능을 먼저 시험하는 편이 안전합니다. WordPress는 코어뿐 아니라 설치된 플러그인과 테마를 최신 상태로 유지하는 것을 핵심 조치로 안내합니다. 자세한 원칙은 WordPress 공식 보안 가이드에서 확인할 수 있습니다.

플러그인과 테마의 업데이트·지원 상태 점검

[높음] □ 확인: 설치 목록에서 현재 버전, 마지막 업데이트 시점, 최신 워드프레스와의 호환성, 개발사 공지와 지원 상태를 확인합니다. 공식 저장소 또는 신뢰할 수 있는 개발사에서 받은 제품인지도 점검하세요. 단순히 업데이트 알림이 없다는 이유로 안전하다고 판단해서는 안 됩니다.

위험과 조치: 개발이 중단된 확장 기능은 새 결함이 발견돼도 수정되지 않을 수 있습니다. 이름만 보고 특정 플러그인이 취약하다고 단정하지 말고 설치 버전과 최신 보안 공지를 대조하세요. 지원 종료가 확인되면 같은 기능을 제공하는 유지 관리 제품을 검토하고, 교체 전후의 화면과 데이터를 테스트합니다.

사용하지 않는 플러그인과 테마 삭제

[높음] □ 확인: 비활성 플러그인, 테스트용 테마, 설치 경위를 모르는 압축 파일과 복제 플러그인이 남아 있는지 확인합니다. 활성화되지 않았더라도 서버에 코드가 존재하면 점검 대상입니다.

위험과 조치: 불필요한 코드는 관리해야 할 공격 표면을 늘립니다. 기능 의존성과 데이터 보존 여부를 확인한 뒤 사용하지 않는 항목을 삭제하세요. 기본 테마 하나는 문제 진단용으로 유지할 수 있지만 나머지는 필요성을 명확히 기록합니다. 출처가 불분명한 유료 제품의 복제본은 사용하지 않는 것이 좋습니다.

관리자 계정과 사용자 권한 확인

[긴급] □ 확인: ‘사용자 → 모든 사용자’에서 관리자 수, 최근 생성 계정, 알아보기 어려운 이메일 주소와 업무가 끝난 외부 작업자 계정을 확인합니다. 여러 사람이 하나의 관리자 계정을 공유하는지도 살펴보세요.

위험과 조치: 알 수 없는 관리자는 이미 권한이 탈취됐다는 신호일 수 있습니다. 즉시 삭제하기보다 계정 생성 시각과 작업 로그를 보존하고 접근을 제한한 뒤 조사하세요. 정상 사용자는 업무에 필요한 최소 역할만 부여하고, 콘텐츠 작성자에게 플러그인 설치 권한까지 주지 않습니다. 흔한 사용자명인 admin은 피하고 사람마다 별도 계정을 발급해야 책임 추적이 쉬워집니다.

고유한 비밀번호와 2단계 인증 적용

[높음] □ 확인: 워드프레스, 호스팅 제어판, 도메인 등록기관, SFTP와 데이터베이스 비밀번호가 서로 다른지 확인합니다. 관리자와 편집자 계정의 2단계 인증 적용 여부, 복구 코드의 안전한 보관 여부도 점검합니다.

위험과 조치: 다른 서비스에서 유출된 비밀번호를 재사용하면 워드프레스 자체에 결함이 없어도 로그인될 수 있습니다. 길고 예측하기 어려운 고유 비밀번호를 비밀번호 관리자로 생성하고, 가능한 모든 고권한 계정에 2단계 인증을 적용하세요. 퇴사자나 외부 업체가 알고 있던 인증 정보는 작업 종료 즉시 교체합니다.

파일과 디렉터리 권한 점검

[높음] □ 확인: 웹 서버가 코어, 플러그인, 테마 파일을 불필요하게 수정할 수 있는지 살펴봅니다. 특히 wp-config.php, wp-admin, wp-includes와 업로드 디렉터리의 소유자 및 쓰기 권한을 확인합니다.

위험과 조치: 지나치게 넓은 쓰기 권한은 침입 후 악성 코드가 여러 파일로 퍼지는 데 이용될 수 있습니다. 흔히 디렉터리 755, 파일 644가 예시로 제시되지만 모든 서버에 적용되는 절대 규칙은 아닙니다. 호스팅 구조와 PHP 실행 계정에 따라 필요한 권한이 달라지므로 웹 서버가 반드시 써야 하는 위치만 쓰기 가능하게 설정하세요. 일괄 권한 변경은 장애를 일으킬 수 있으므로 백업 후 호스팅 관리자에게 적정값을 확인합니다.

wp-config.php와 대시보드 파일 편집 보호

[보통] □ 확인: wp-config.php가 외부에서 직접 노출되지 않는지, 데이터베이스 인증 정보가 저장소나 공개 백업 파일에 포함되지 않았는지 확인합니다. 대시보드에서 플러그인·테마 PHP 파일을 편집할 필요가 있는지도 판단합니다.

위험과 조치: 관리자 계정이 탈취되면 내장 편집기가 악성 코드를 삽입하는 수단이 될 수 있습니다. wp-config.php에 define( 'DISALLOW_FILE_EDIT', true );를 설정하면 대시보드 파일 편집을 막을 수 있습니다. 그러나 이 설정은 악성 파일 업로드까지 차단하지 않으며 계정 보호와 파일 권한 점검을 대체하지 않습니다. 서버별 보호 방법은 WordPress Hardening 문서를 참고하되 변경 전 백업을 준비하세요.

백업이 실제로 복구되는지 확인

[높음] □ 확인: 데이터베이스와 wp-content, 핵심 설정 파일이 모두 백업되는지 확인합니다. 최근 정상 백업의 생성 시각, 보관 위치, 보존 기간과 암호화 여부도 기록하세요. 서버 한 곳에만 있는 백업은 서버 장애나 계정 탈취 때 함께 손상될 수 있습니다.

위험과 조치: 백업 성공 알림만으로 복구 가능성을 보장할 수 없습니다. 별도 환경에서 파일과 데이터베이스를 복원해 로그인, 이미지, 주요 양식과 주문 데이터가 정상인지 정기적으로 시험합니다. 백업은 보안 업데이트나 접근 통제를 대신하는 방어 수단이 아니라 사고 후 정상 상태로 돌아가기 위한 대비책입니다.

로그와 사이트의 이상 징후 확인

[긴급] □ 확인: 워드프레스 활동 로그, 웹 서버 접속·오류 로그, 호스팅 로그인 기록에서 실패한 로그인 반복, 낯선 관리자 생성, 플러그인 설치, 핵심 파일 변경과 예상하지 못한 해외 접속을 찾습니다. 검색 결과의 스팸 문구, 알 수 없는 팝업, 다른 주소로의 이동, 트래픽 급증도 확인하세요.

위험과 조치: 한 건의 낯선 IP만으로 침해를 확정할 수는 없지만 여러 징후가 같은 시간대에 나타나면 원본 로그를 보존해야 합니다. 서버 시간대와 운영자의 정상 작업 기록을 대조하고, 로그 보존 기간이 너무 짧다면 호스팅 업체에 연장을 문의하세요. 개인정보나 인증 정보가 포함된 로그를 공개 게시판에 그대로 올리지 않습니다.

보안 스캐너와 방화벽 결과 해석

[보통] □ 확인: 스캐너가 코어 무결성, 알려진 취약 버전, 악성 패턴과 변경 파일을 검사하는지 확인합니다. 방화벽의 차단 기록과 오탐도 함께 살펴보고 검사 도구 자체가 최신 상태인지 점검하세요.

위험과 조치: 경고를 무조건 삭제하면 정상 파일이나 사용자 업로드가 손상될 수 있습니다. 경로, 변경 시각, 원본 배포 파일과의 차이를 확인한 뒤 격리하거나 복원하세요. 보안 플러그인 하나가 모든 공격을 막아 주지는 않으며 업데이트, 최소 권한, 백업, 모니터링을 함께 운영해야 합니다.

취약점이나 침해 징후를 발견했을 때

1. 접근부터 제한합니다. 유지보수 화면이나 호스팅 기능을 이용해 피해 확산을 줄이고, 의심 계정과 세션을 차단합니다. 관리자 화면에 접속되지 않는다면 호스팅 업체에 긴급 지원을 요청합니다.
2. 현재 상태를 보존합니다. 감염됐을 가능성이 있는 파일과 데이터베이스도 조사 자료가 될 수 있으므로 별도 위치에 백업합니다. 정상 백업을 덮어쓰거나 의심 파일을 무작정 삭제하지 않습니다.
3. 인증 정보를 교체합니다. 안전한 기기에서 워드프레스, 호스팅, 도메인, SFTP, 데이터베이스의 비밀번호와 보안 키를 변경합니다. 같은 비밀번호를 쓴 다른 서비스도 함께 조치합니다.
4. 침입 경로를 찾아 제거합니다. 취약 버전, 알 수 없는 관리자, 변조 파일과 예약 작업을 조사합니다. 코어는 공식 배포본과 비교하고 플러그인·테마는 신뢰할 수 있는 원본으로 교체합니다.
5. 정상 백업으로 복구하고 재검사합니다. 복구 후에도 취약한 구성과 탈취 계정이 남으면 재침입할 수 있으므로 업데이트와 권한 정리를 마친 뒤 로그를 집중 관찰합니다.

고객 정보나 결제 데이터 노출 가능성이 있거나 여러 사이트가 동시에 변조됐거나, 관리자 계정이 계속 다시 생성된다면 직접 복구를 멈추고 호스팅 보안팀 또는 워드프레스 침해 대응 전문가에게 의뢰하는 편이 안전합니다. 규제·계약상 통지 의무가 관련될 수 있는 사업자는 내부 담당자와 필요한 절차도 확인해야 합니다.

정기 점검은 이렇게 운영하세요

주기	확인할 항목	남길 기록
매일 또는 자동 알림	사이트 접속, 변조·악성코드 경고, 백업 성공 여부	경고 시각과 대응자
매주	코어·플러그인·테마 업데이트, 관리자 변경, 주요 로그	업데이트 버전과 테스트 결과
매월	불필요한 확장 기능, 사용자 권한, 2단계 인증, 파일 변경	삭제·권한 조정 내역
분기별	백업 복구 시험, 호스팅 보안 설정, 대응 연락망	복구 시간과 실패 원인

사이트의 중요도와 변경 빈도가 높다면 점검 간격을 더 짧게 잡아야 합니다. 담당자, 완료일, 발견 사항, 조치 결과를 한 문서에 기록하면 경고가 반복되는 원인과 업데이트 후 장애를 추적하기 쉽습니다.

자주 묻는 질문

업데이트하면 사이트가 깨질까 봐 미뤄도 될까요?

장기간 미루는 것은 보안 위험을 키울 수 있습니다. 업데이트 전 전체 백업을 만들고 스테이징 환경에서 주요 기능을 시험한 뒤, 이용자가 적은 시간에 적용하세요. 문제가 생기면 즉시 되돌릴 수 있도록 복구 담당자와 절차를 정해 두는 것이 좋습니다.

비활성 플러그인도 삭제해야 하나요?

다시 사용할 명확한 계획이 없다면 삭제하는 편이 관리에 유리합니다. 비활성 상태라도 파일이 서버에 남아 있으며 오래되면 점검 대상이 늘어납니다. 삭제 전 설정이나 데이터가 함께 사라지는지는 플러그인 문서와 백업으로 확인하세요.

파일 권한을 모두 644와 755로 바꾸면 안전한가요?

그 값은 흔한 구성의 예시일 뿐 모든 환경의 정답은 아닙니다. 파일 소유자, 웹 서버 실행 방식, 공유 호스팅 정책에 따라 필요한 권한이 달라집니다. 재귀 명령을 실행하기 전에 백업하고 호스팅 업체의 권장값을 확인하세요.

보안 점검 결과가 깨끗하면 해킹되지 않은 것인가요?

한 번의 검사만으로 침해 가능성을 완전히 배제할 수 없습니다. 스캐너가 찾지 못하는 변조나 계정 악용도 있으므로 파일 무결성, 사용자 목록, 서버 로그, 외부에서 보이는 페이지를 함께 확인해야 합니다. 의심 징후가 계속되면 원본 로그를 보존하고 전문가의 조사를 받으세요.