워드프레스를 운영하다 보면 어느 날 갑자기 /wp-admin에 들어갈 수 없게 됩니다. 비밀번호를 분명히 맞게 넣었는데 로그인 화면이 그대로 다시 뜨거나, 흰 화면만 나오거나, 아예 403이 뜨기도 합니다. 문제는 이 상황에서 사람들이 가장 먼저 떠올리는 해결책이 “재설치”라는 점입니다. 워드프레스는 글과 설정이 전부 데이터베이스에 있어서, 파일만 새로 덮는 재설치로는 계정 문제가 풀리지 않습니다. 오히려 잘못 손대면 멀쩡한 사이트를 날립니다.
로그인 실패는 증상이 다 비슷해 보여도 원인은 전혀 다릅니다. 인증(비밀번호) 문제, 세션·쿠키 문제, 플러그인·테마 충돌, 서버 차단은 각각 손봐야 할 곳이 다릅니다. 그래서 순서가 중요합니다. 위험도가 낮고 되돌리기 쉬운 방법부터 하나씩 배제해 나가면, 대부분은 파일 몇 개 이름 바꾸는 수준에서 끝납니다.
한눈에 · 프론트엔드 확인 → 분실 비밀번호/WP-CLI → phpMyAdmin에서 비밀번호·권한 수정 → 플러그인·테마 폴더명 변경 → .htaccess 격리와 debug.log → 임시 코드 정리와 재발 방지
로그인 실패는 네 갈래로 나뉩니다
“로그인이 안 된다”는 한 문장 안에 서로 다른 상황 네 개가 섞여 있습니다. 이걸 구분하지 않고 인터넷에서 본 SQL을 그대로 실행하면, 원인이 아닌 곳을 고치느라 시간만 씁니다. 먼저 증상을 갈래로 나누는 것이 복구의 절반입니다.
증상별로 갈래를 나누는 1분 체크
| 증상 | 화면에 보이는 것 | 유력한 원인 | 볼 곳 |
|---|---|---|---|
| 비밀번호 오류 | “ERROR: 입력한 비밀번호가 올바르지 않습니다” | 비밀번호 틀림, 계정명 착각 | 분실 비밀번호, WP-CLI, wp_users |
| 리다이렉트 루프 | 로그인 누르면 다시 로그인 화면 | siteurl/home 불일치, 쿠키, 플러그인 | wp_options, 쿠키 설정 |
| 흰 화면 / 500 | 아무것도 없거나 500 에러 | PHP 치명 오류(플러그인·테마) | debug.log, plugins 폴더 |
| 403 / 404 / 429 | 로그인 페이지 자체가 안 열림 | 보안 플러그인, .htaccess, WAF, IP 차단 | .htaccess, 차단 테이블 |
표의 오른쪽 칸이 이 글의 진행 순서와 그대로 맞물립니다. 자기 증상이 어느 줄인지만 정해 두면 필요한 섹션으로 바로 갈 수 있습니다.
프론트엔드가 뜨는지 먼저 확인해야 하는 이유
관리자 화면을 만지기 전에 홈페이지 주소(https://example.com)를 그냥 열어 보세요. 글 목록이 정상으로 보이면 PHP가 돌고 있고, DB 접속도 성공하고 있다는 뜻입니다. 이 경우 원인은 인증·쿠키·플러그인 쪽으로 좁혀집니다.
반대로 프론트엔드에서 “데이터베이스 연결 중 오류가 발생했습니다”가 나오면 로그인은 애초에 불가능합니다. 그건 로그인 문제가 아니라 DB 접속 정보나 MySQL 서비스 문제입니다. 이 상태에서 wp_users를 고치려 해도 손댈 방법이 없으니 순서를 바꿔야 합니다.
손대기 전에 준비할 것
증상이 무엇이든, 관리자 화면 밖에서 파일과 DB를 만질 통로가 없으면 아무것도 못 합니다. 준비물은 셋입니다. FTP/SFTP 또는 SSH, phpMyAdmin 같은 DB 관리 도구, 그리고 호스팅 제어판입니다. 셋 중 하나만 있어도 상당 부분 진단이 됩니다. SSH가 없고 FTP만 있어도 폴더 이름을 바꾸는 것만으로 플러그인·테마 문제는 거의 다 격리할 수 있습니다.
wp-config.php에서 확인할 항목
복구 작업의 기준점은 워드프레스 루트에 있는 wp-config.php입니다. 여기서 세 값을 미리 적어 두세요.
define( 'DB_NAME', 'wp_mysite' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', '••••••••' );
define( 'DB_HOST', 'localhost' );
$table_prefix = 'wpxy_';
여기서 가장 많이 사고가 나는 게 $table_prefix입니다. 보안 목적으로 설치 시 접두사를 바꿔 둔 사이트가 많습니다. table_prefix가 wp_가 아니면 이 글에 나오는 wp_users, wp_options, wp_usermeta는 전부 wpxy_users 처럼 바꿔서 읽어야 합니다. 접두사를 확인하지 않고 SQL을 실행하면 “Table ‘wp_mysite.wp_users’ doesn’t exist” 같은 에러가 뜹니다. wp-config.php의 다른 설정값은 wp-config.php 필수 설정 12가지, 보안과 성능 한 번에 점검하기에 따로 정리해 뒀습니다.
복구 전 DB 덤프 뜨기
DB를 직접 수정하기 전에는 덤프를 떠 두세요. SSH가 있으면 한 줄입니다.
mysqldump -u 사용자 -p DB이름 > backup.sql
ls -lh backup.sql
비밀번호를 물어보면 wp-config.php의 DB_PASSWORD를 넣습니다. 파일 크기가 몇 KB 이상으로 잡히면 정상입니다. 0바이트면 인증 실패이거나 DB 이름이 틀린 겁니다. phpMyAdmin만 있으면 상단 “내보내기” 탭에서 SQL 형식으로 저장하면 됩니다. 파일까지 함께 챙기는 방법은 워드프레스 백업, 파일과 DB 둘 다 챙기는 실전 순서를 참고하세요.
1단계: 비밀번호 재설정
준비가 됐으면 가장 위험도가 낮은 것부터 시작합니다. 파일도 DB도 건드리지 않고 끝나는 경우가 생각보다 많습니다. 로그인 화면 아래 “비밀번호를 잊어버렸나요?” 링크를 눌러 아이디나 이메일을 넣고 재설정 메일을 요청하는 것이 첫 수순입니다.
분실 비밀번호 메일이 안 오는 이유
그런데 여기서 대부분 막힙니다. 메일이 오지 않는 이유는 보통 셋 중 하나입니다.
- 호스팅이 PHP
mail()함수를 막아 둔 경우. 워드프레스는 기본적으로 이 함수로 메일을 보냅니다. 막혀 있으면 아무 일도 일어나지 않습니다. - 발신 주소가
wordpress@example.com처럼 실제 존재하지 않는 주소로 나가면서 SPF·DMARC 검사에 걸려 스팸으로 처리되는 경우. 받는 쪽 스팸함을 꼭 확인하세요. - 설정 > 일반의 관리자 이메일이 몇 년 전에 쓰던 주소로 남아 있는 경우. 메일은 정상 발송됐지만 내가 못 받습니다.
스팸함까지 확인했는데 없으면 메일 경로는 포기하고 다음으로 넘어가는 게 빠릅니다. 여기서 시간을 오래 끌 필요가 없습니다.
WP-CLI로 비밀번호 즉시 변경하기
SSH를 쓸 수 있다면 WP-CLI가 가장 빠릅니다. WP-CLI는 워드프레스를 명령줄에서 조작하는 공식 도구입니다. 먼저 계정 목록을 확인합니다.
cd /var/www/html
wp user list
wp user update admin --user_pass='새비밀번호' --allow-root
wp user list를 실행하면 ID, user_login, user_email, roles가 표로 나옵니다. 여기서 role이 administrator인 계정의 user_login을 확인하고, 그 값을 update 명령에 넣습니다. 성공하면 Success: Updated user 1. 같은 메시지가 나옵니다.

여기서 자주 나오는 에러가 둘 있습니다. 첫째는 이겁니다.
Error: This does not seem to be a WordPress installation.
Pass --path=`path/to/wordpress` or run `wp core download`.
현재 디렉터리에 wp-config.php나 wp-includes가 없다는 뜻입니다. 워드프레스 루트로 cd한 뒤 다시 실행하거나, 경로를 직접 지정하세요.
wp user list --path=/home/user/public_html --allow-root
둘째는 root 계정으로 실행했을 때입니다.
Error: YIKES! It looks like you're running this as root. You probably meant to
run this as the user that your WordPress installation exists under.
WP-CLI가 root 실행을 경고하는 겁니다. root로 실행하면 새로 생기는 파일 소유자가 root가 되어 웹서버가 못 읽는 일이 생깁니다. 원칙적으로는 sudo -u www-data wp ... 처럼 웹서버 사용자로 실행하는 게 맞고, 급할 때는 위 명령처럼 --allow-root를 붙여 넘깁니다.
2단계: phpMyAdmin에서 DB 직접 고치기
메일도 안 오고 SSH도 없다면, 사실상 표준 경로는 phpMyAdmin입니다. 호스팅 제어판에서 DB 관리 메뉴로 들어가면 대개 열 수 있습니다. 앞에서 확인한 DB 이름을 왼쪽 목록에서 선택하고 시작합니다.
user_pass를 MD5로 갱신하는 SQL
워드프레스는 비밀번호를 해시로 저장합니다. 그런데 옛날 호환성 때문에, 저장된 값이 단순 MD5 해시여도 로그인을 허용하고 로그인 성공 순간 최신 방식의 강한 해시로 조용히 다시 저장합니다. 이 성질을 이용하는 게 고전적인 복구법입니다. phpMyAdmin의 SQL 탭에 다음을 넣고 실행합니다.
UPDATE wp_users SET user_pass = MD5('새비밀번호') WHERE user_login = 'admin';
1 row affected가 나오면 성공입니다. 0 rows affected면 user_login 값이 ‘admin’이 아닌 겁니다. 먼저 계정을 확인하세요.
SELECT ID, user_login, user_email FROM wp_users;
실행 후 바로 로그인해 보고, 들어가면 즉시 프로필에서 비밀번호를 새로 설정하세요. MD5는 요즘 기준으로 약한 해시라서 오래 두면 안 됩니다.
이메일 주소만 바꿔서 우회하는 방법도 있습니다. 메일 발송 자체는 되는데 옛 주소로 가고 있던 상황이라면 이게 더 깔끔합니다.
UPDATE wp_users SET user_email = 'me@gmail.com' WHERE user_login = 'admin';
이렇게 바꾼 뒤 분실 비밀번호를 다시 요청하면 됩니다.
관리자 권한 메타값 확인하기
비밀번호는 맞는데 로그인하면 “이 페이지에 접근할 권한이 없습니다”가 뜨는 경우가 있습니다. 계정은 살아 있고 권한만 날아간 상태입니다. 권한은 wp_usermeta 테이블에 들어 있습니다.
SELECT * FROM wp_usermeta
WHERE user_id = 1 AND meta_key IN ('wp_capabilities', 'wp_user_level');
정상이라면 wp_usermeta의 wp_capabilities 값이 a:1:{s:13:"administrator";b:1;} 이고, wp_user_level은 10입니다. 값이 다르면 직접 넣습니다.
UPDATE wp_usermeta SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
WHERE user_id = 1 AND meta_key = 'wp_capabilities';
UPDATE wp_usermeta SET meta_value = '10'
WHERE user_id = 1 AND meta_key = 'wp_user_level';
a:1:{s:13:"administrator";b:1;}는 PHP 배열을 문자열로 저장한 형태입니다. s:13은 뒤 문자열 길이가 13자라는 뜻이라, “administrator”를 다른 문자로 바꿀 땐 숫자도 같이 맞춰야 합니다. 여기서도 접두사 주의는 그대로입니다. 접두사가 wpxy_라면 meta_key도 wpxy_capabilities가 됩니다.
계정이 아예 없을 때 임시 계정 만들기
관리자 계정이 목록에 하나도 없을 수도 있습니다. 이때는 FTP로 현재 테마의 functions.php 맨 위에 임시 코드를 넣습니다.
add_action( 'init', function () {
$login = 'tmpadmin';
if ( ! username_exists( $login ) ) {
$uid = wp_create_user( $login, 'Temp!Pass#2024', 'me@gmail.com' );
$user = new WP_User( $uid );
$user->set_role( 'administrator' );
}
} );
저장한 뒤 사이트 첫 화면을 한 번 열면 코드가 실행됩니다. 그다음 tmpadmin으로 로그인하세요. 로그인이 확인되는 즉시 이 코드는 반드시 지워야 합니다. 남겨 두면 계정을 삭제해도 페이지를 열 때마다 되살아나고, 비밀번호가 소스에 그대로 적힌 백도어가 됩니다.
3단계: 로그인 화면으로 되돌아가거나 흰 화면이 뜰 때
비밀번호를 확실히 새로 넣었는데도 여전히 못 들어간다면, 원인은 인증이 아닙니다. 로그인 자체는 성공했는데 그다음 단계에서 튕기는 상황입니다. 여기서부터는 URL 설정과 플러그인·테마를 봅니다.
siteurl / home 불일치로 인한 리다이렉트 루프
가장 흔한 범인이 주소 설정입니다. phpMyAdmin에서 wp_options 테이블의 siteurl / home 값 확인부터 하세요.
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');
두 값이 http://example.com 과 https://www.example.com 처럼 어긋나 있으면 로그인 후 리다이렉트가 무한히 돕니다. 프로토콜(http/https)과 www 유무를 실제 접속 주소와 똑같이 맞추세요. DB를 못 만지는 상황이면 wp-config.php에 임시로 못 박아 둘 수 있습니다.
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
이 상수를 넣으면 DB 값보다 우선합니다. 다만 이 상태에서는 관리자 화면의 주소 입력란이 회색으로 잠깁니다. 복구가 끝나면 DB를 정리하고 상수는 지우는 편이 낫습니다.
쿠키 쪽 문제라면 로그인 화면에 이렇게 나옵니다.
Error: Cookies are blocked or not supported by your browser.
You must enable cookies to use WordPress.
브라우저 쿠키 차단이거나, 도메인이 바뀌면서 예전 쿠키가 남은 경우입니다. 해당 사이트 쿠키를 삭제하고 시크릿 창에서 다시 시도해 보세요. 시크릿 창에서 되면 캐시·쿠키 문제로 확정할 수 있습니다.
플러그인·테마를 폴더명 변경으로 끄기
플러그인이 원인인지 아닌지는 폴더 이름 하나로 판별합니다. 워드프레스는 플러그인 파일을 못 찾으면 그 플러그인을 그냥 비활성 처리합니다.
cd /var/www/html
mv wp-content/plugins wp-content/plugins_off
FTP만 있으면 plugins 폴더를 우클릭해서 plugins_off로 이름만 바꾸면 됩니다. 이 상태에서 로그인이 되면 범인은 플러그인입니다. 이름을 다시 plugins로 돌린 뒤, 관리자 화면에서 하나씩 활성화하며 어느 것인지 찾습니다.
2단계 인증 플러그인이 잠근 경우처럼 짐작이 가는 게 있으면 전체를 끌 필요 없이 그 폴더만 바꿉니다.
mv wp-content/plugins/wp-2fa wp-content/plugins/wp-2fa_off
테마가 의심되면 같은 방식으로 현재 테마 폴더 이름을 바꿉니다. 그러면 워드프레스가 기본 테마(twentytwentyfour 등)로 자동 폴백합니다. 기본 테마가 아예 없으면 폴백할 데가 없어 더 나빠지니, wp-content/themes 안에 기본 테마가 남아 있는지 먼저 확인하세요.

debug.log로 흰 화면 원인 찾기
흰 화면은 PHP가 치명 오류로 죽었는데 에러를 화면에 안 뿌리는 상태입니다. 추측하지 말고 로그를 보세요. wp-config.php에서 / That's all, stop editing! / 줄 위에 넣습니다.
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
이러면 오류가 화면에 나오지 않고 wp-content/debug.log 파일에 쌓입니다. 문제 페이지를 한 번 다시 열고 로그를 확인하세요.
tail -n 50 wp-content/debug.log
PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/어떤플러그인/xxx.php on line 87 처럼 파일 경로가 찍힙니다. 그 경로가 범인입니다. 로그가 길면 grep으로 로그에서 원하는 줄만 뽑기, 실전 옵션 정리의 방식으로 grep "Fatal error" wp-content/debug.log처럼 걸러 보면 편합니다. 복구가 끝나면 디버그 상수는 반드시 false로 되돌리세요. debug.log는 URL로 직접 읽힐 수 있습니다.
4단계: 로그인 페이지 자체가 안 열릴 때
지금까지는 로그인 화면이 뜬다는 전제였습니다. wp-login.php를 열었을 때 403이나 404, 429가 뜬다면 워드프레스에 도달하기 전 서버 단계에서 막힌 겁니다. 접근 방식이 달라집니다.
403이면 .htaccess부터 격리
403 Forbidden은 보통 셋 중 하나입니다. 로그인 URL을 바꾸는 보안 플러그인, .htaccess의 IP 제한 규칙, 호스팅 WAF(웹 방화벽) 차단입니다. 가장 먼저 .htaccess를 격리해서 범위를 좁힙니다.
mv .htaccess .htaccess_off
이 상태에서 로그인 페이지가 열리면 .htaccess 안의 규칙이 원인입니다. 파일을 열어 <Files wp-login.php> 블록이나 Require ip, deny from 같은 줄을 찾으세요. 원인 줄만 지우고 되돌리거나, 워드프레스 기본 규칙으로 새로 씁니다.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
.htaccess를 지우면 고유주소가 깨져 글 페이지가 404가 됩니다. 위 기본 규칙만 넣어 두면 정상으로 돌아옵니다. .htaccess를 껐는데도 403이면 서버 WAF 쪽이라 호스팅사 문의가 빠릅니다.
IP 차단 해제하기
로그인 시도 제한 플러그인은 실패가 반복되면 IP를 잠급니다. 이 기록은 DB에 남습니다. 예를 들어 Limit Login Attempts 계열은 wp_options에 잠금 목록을 저장하고, Wordfence는 wp_wfBlocks7 같은 별도 테이블을 씁니다. 차단 기록을 지우는 것보다 해당 플러그인 폴더 이름을 바꿔 버리는 게 훨씬 간단하고 확실합니다.
로그인 URL을 바꿔 놓은 플러그인 이름이 기억나지 않을 때는 폴더 목록을 보면 대개 짐작이 됩니다.
ls wp-content/plugins
wps-hide-login, all-in-one-wp-security, wordfence 같은 이름이 보이면 그 폴더를 _off로 바꾸고 다시 /wp-login.php를 열어 보세요. 429 Too Many Requests는 서버나 CDN 단계의 속도 제한일 수 있으니, 몇 분 기다린 뒤 다른 네트워크(모바일 데이터 등)로 시도해 보는 것도 방법입니다.
복구 후 마무리와 재발 방지
들어갔다고 끝이 아닙니다. 복구 과정에서 만든 임시 장치를 그대로 두면 그게 다음 사고의 원인이 됩니다. 순서대로 정리하세요.
임시 코드·임시 계정 정리
functions.php에 넣은wp_create_user코드 삭제. 이걸 남겨 두는 게 가장 위험합니다.- 임시로 만든
tmpadmin계정은 정식 계정 복구가 끝나면 삭제. - MD5로 넣은 비밀번호는 관리자 화면 프로필에서 다시 변경.
plugins_off,.htaccess_off등 이름 바꿔 둔 것 원복. 플러그인은 하나씩 켜면서 범인을 특정.WP_DEBUG,WP_DEBUG_LOG를false로 되돌리고wp-content/debug.log삭제.
다음에 또 막히지 않게 해 둘 것
관리자 이메일을 실제로 받을 수 있는 주소로 갱신하고, SMTP 플러그인으로 메일 발송 경로를 확보해 두세요. 이것만 해 두면 다음번엔 분실 비밀번호 메일로 5분 안에 끝납니다. 관리자 계정을 하나 더 만들어 두는 것도 값싼 보험입니다. 코드나 외부 도구로 접근할 통로가 필요하면 워드프레스 애플리케이션 비밀번호 발급과 사용법 정리를 같이 보면 됩니다.
로그인 URL 변경 플러그인은 판단이 필요합니다.
| 설정 | 장점 | 위험 |
|---|---|---|
| 로그인 URL 변경 | 무작위 대입 시도 급감 | URL 잊으면 자기가 잠김. 반드시 따로 기록 |
| 로그인 시도 제한 | 반복 공격 차단 | 내 IP가 잠길 수 있음. 해제 경로 확보 필요 |
| 2단계 인증 | 비밀번호 유출에도 방어 | 기기 분실 시 복구 코드 없으면 잠김 |
| admin 아이디 유지 | 익숙함 | 아이디를 이미 아는 상태라 공격 표면 넓음 |
세 가지 모두 “편의를 버리고 안전을 얻는” 대신 “잠김 위험”을 같이 들여옵니다. 도입할 땐 복구 경로(SSH, phpMyAdmin, 복구 코드)를 반드시 함께 확보해 두세요.
자주 묻는 질문
앞 단계를 따라오다 자주 나오는 질문들입니다.
DB에서 비밀번호를 MD5로 바꿔도 안전한가요?
로그인하는 순간 워드프레스가 값을 검사해 최신 방식의 강한 해시로 다시 저장합니다. 그래서 기능적으로는 문제가 없습니다. 다만 SQL을 실행한 시점부터 실제 로그인까지는 약한 해시가 DB에 그대로 있는 상태입니다. SQL 실행 후 바로 로그인하고, 관리자 화면에서 비밀번호를 한 번 더 바꾸는 것을 권합니다.
비밀번호 재설정 메일이 계속 안 오는데 호스팅 문제인가요?
확인 순서는 스팸함 → 관리자 이메일 주소 → PHP mail() 차단 여부입니다. 세 번째는 호스팅사에 “PHP mail 함수로 발송이 되는지” 물어보면 바로 답이 나옵니다. 공유 호스팅에서 막아 둔 경우가 흔합니다. 근본 해결은 SMTP 플러그인으로 Gmail이나 메일 서비스 계정을 통해 보내도록 바꾸는 것입니다. 발송 경로가 명확해지면 스팸 처리도 크게 줄어듭니다.
플러그인 폴더 이름을 바꾸면 설정이 다 날아가나요?
플러그인 설정은 대부분 DB(wp_options)에 저장되니 폴더명만 바꿔도 값은 그대로 남습니다. 폴더 이름을 되돌리고 다시 활성화하면 예전 설정으로 돌아오는 게 보통입니다. 다만 일부 플러그인은 정상적인 비활성화 훅에서 캐시 파일이나 스케줄을 정리하는데, 폴더명 변경은 그 훅을 타지 않습니다. 캐시 플러그인이라면 원복 후 캐시를 한 번 비워 주세요.
wp-admin에 들어가면 계속 로그인 화면으로 돌아갑니다
wp_options의 siteurl과 home 값 불일치를 먼저 보세요. https로 접속하는데 DB에는 http로 적혀 있는 경우가 특히 많습니다. 그다음은 쿠키입니다. 브라우저에서 해당 도메인 쿠키를 지우고 시크릿 창으로 시도해 보고, wp-config.php에 COOKIE_DOMAIN 같은 상수가 잘못 들어 있지 않은지 확인하세요. 이래도 안 되면 plugins 폴더명을 바꿔 플러그인을 배제합니다.
워드프레스를 재설치하면 해결되나요?
코어 파일이 손상됐거나 악성 코드가 섞인 경우라면 코어 파일 교체가 도움이 됩니다. 하지만 계정, 비밀번호, 권한, siteurl은 전부 DB에 있어서 파일을 새로 덮어도 그대로입니다. 즉 이 글에서 다룬 원인 대부분은 재설치로 해결되지 않습니다. 게다가 wp-content를 잘못 덮으면 테마와 업로드 파일을 잃습니다. 재설치는 마지막 수단으로 두세요.
복구 순서 체크리스트
지금 막혀 있다면 위에서부터 순서대로 내려가면 됩니다.
- 홈페이지(프론트엔드)를 열어 본다. DB 연결 오류가 뜨면 로그인 문제가 아니라 DB 문제 → 그쪽 먼저 해결.
mysqldump -u 사용자 -p DB이름 > backup.sql로 DB 덤프. 파일 크기가 0이 아닌지 확인.- wp-config.php에서
$table_prefix확인.wp_가 아니면 이후 테이블명 전부 치환. - 분실 비밀번호 메일 요청 → 스팸함 포함 확인. 5분 내 안 오면 다음.
- SSH 있으면
wp user update admin --user_pass='새비밀번호' --allow-root. 성공 메시지 없으면 다음. - phpMyAdmin에서
UPDATE wp_users SET user_pass = MD5('새비밀번호') WHERE user_login = 'admin';→1 row affected확인. - 권한 오류면
wp_usermeta의 wp_capabilities를a:1:{s:13:"administrator";b:1;}로 수정. - 로그인 루프면
wp_options의 siteurl / home을 실제 주소와 일치시킨다. mv wp-content/plugins wp-content/plugins_off→ 로그인되면 플러그인 범인 확정.- 그래도 안 되면 테마 폴더명 변경으로 기본 테마 폴백.
- 로그인 페이지가 403이면
.htaccess를.htaccess_off로 격리. - 흰 화면이면
WP_DEBUG/WP_DEBUG_LOG를 켜고wp-content/debug.log의 Fatal error 경로 확인. - 여기까지 다 실패하면 호스팅사에 WAF·mail()·IP 차단 여부 문의.
들어간 뒤에는 임시 코드 삭제, 임시 계정 삭제, MD5 비밀번호 재변경, 디버그 상수 원복, 폴더명 원복, 관리자 이메일 갱신, SMTP 설정까지 확인하면 이번 사고는 마무리됩니다.

[…] 다시 false로 되돌리세요. 관리자 화면 자체에 못 들어가는 상황이라면 워드프레스 관리자 로그인 안 될 때, 원인별 복구 순서 정리의 순서를 같이 따라가면 […]