wp-config.php 건드리기 전 백업 안 하면 낭패

실수했을 때 대처법: FTP 접속 없이 복구하기

혹시라도 잘못 수정했다 싶으면 당황하지 말고 브라우저 호스팅 패널의 '파일 관리자'로 바로 들어간다. FTP 클라이언트를 설치할 시간조차 아까울 수 있다. wp-config.php 파일의 마지막 수정 시간을 확인하고, 방금 만든 .bak 파일 내용을 복사해서 붙여넣은 뒤 저장한다. 이 과정을 1분 안에 해결하면 방문자는 사이트 중단을 눈치채지 못한다. SSL 강제 등 보안 코드를 잘못 넣어서 '무한 리다이렉트 루프'에 빠졌을 때도, 파일 관리자로 접속해서 해당 코드 라인만 주석 처리(//) 하면 즉시 해결된다.

보안 강화를 위해 반드시 수정해야 할 4곳

복잡한 플러그인 설치 없이 텍스트 편집기로 몇 줄만 바꾸면 보안 효과는 확실해진다. 자동화 파이프라인이 주 1~5편으로 불규칙하게 글을 쓰고, 문체 검사를 통과한 글만 공개되듯, 보안 설정도 일회성이 아니라 주기적인 점검이 필요하다.

보안 키(Salts) 갱신으로 쿠키 해킹 막기

WordPress 보안 키와 salt는 인증 쿠키와 nonce의 해시·HMAC을 생성하고 검증하는 데 사용하는 비밀값이다. 이 값이 쉽게 유추되면 해커가 쿠키를 위조하여 관리자 세션을 탈취할 위험이 크다. 기본값으로 둔 채로 쓰는 것은 자물쇠에 '1234'를 다는 것과 같다. 워드프레스 공식 API 키 생성 페이지에 접속해서 뜨는 코드를 그대로 복사해 wp-config.php의 해당 칸에 붙여넣는다.

// 설치 직후 wp-config.php 에는 이렇게 자리표시자만 들어 있다.
define( 'AUTH_KEY',         'put your unique phrase here' );
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
define( 'NONCE_KEY',        'put your unique phrase here' );
define( 'AUTH_SALT',        'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
define( 'NONCE_SALT',       'put your unique phrase here' );

이 8줄을 통째로 지우고, 공식 생성기가
뱉어낸 8줄을 그대로 붙여넣는다. 값은 매번 새로 만들어지므로 남이 블로그에 적어둔 문자열을 복사해 쓰면 안 된다
— 공개된 키는 없는 키와 같다. 새로고침할 때마다 다른 값이 나오는 것이 정상이다.

이 코드를 적용하면 기존에 로그인된 사용자는 다시 로그인해야 한다. 쿠키가 무효화되기 때문이다. 보안 키를 교체하면 기존 로그인 쿠키가 무효화되므로 쿠키 유출이 의심될 때 세션을 강제로 종료하는 데 유용하지만, 다른 공격 경로까지 막지는 않는다.

디버그 모드 끄고 에러 로그 숨기기

운영 환경에서는 절대 에러 메시지가 화면에 출력되면 안 된다. PHP 경로나 데이터베이스 구조가 화면에 그대로 노출되면 공격자에게 침투 경로를 알려주는 꼴이 된다. wp-config.php 하단에 있는 디버그 상수를 모두 false로 설정한다.

모든 PHP 코드 예시에서는 곡선 따옴표가 아닌 ASCII 따옴표를 사용한다: `define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

에러를 확인해야 한다면 서버의 error.log 파일을 직접 까보는 습관을 들이는 게 좋다. 화면에 안 보인다고 해결된 게 아니다. 내부적으로 로그를 쌓으면서 조용히 문제를 해결하는 편이 낫다.

테이블 접두사 변경 — 효과와 한계

워드프레스를 설치할 때 기본 테이블 접두사는 wp_다. 새로 설치할 때는 myblog_처럼 예측하기 힘든 접두사를 쓰는 편이 낫다. 자동화된 스캐너가 테이블 이름을 찍어놓고 던지는 공격을 한 겹 걷어내 주기 때문이다.

다만 이것을 SQL 인젝션 대책으로 이해하면 안 된다. 접두사 변경은 이름을 가리는 것(security through obscurity)일 뿐이고, 인젝션을 실제로 막는 것은 워드프레스가 쿼리를 준비된 문장으로 만들어 주는 $wpdb->prepare()다. 취약한 플러그인이 사용자 입력을 그대로 쿼리에 이어 붙이면 접두사를 뭘로 바꿔놨든 뚫린다. 접두사 변경은 보조 장치이지 방어선이 아니다. 그리고 이미 운영 중인 사이트에서 테이블 이름을 일괄 변경하는 작업은 잘못하면 사이트가 통째로 날아가므로 초보자에게는 추천하지 않는다.

플러그인 없이 코드로 차단하는 공격 기법

플러그인은 편하지만, 플러그인 자체의 취약점이 새로운 해킹 루트가 되는 경우도 허다하다. 나는 가능한 코드 레벨에서 직접 차단하는 것을 선호한다. wp-config.php와 functions.php, 그리고 .htaccess 파일을 조합하면 플러그인 없이도 탄탄한 방벽을 구축할 수 있다. 자동화 LLM을 헤드리스로 부를 때 기본 설정이 1회 $0.67이었는데, 불필요한 도구를 떼어내고 모델을 가벼운 쪽으로 바꿔 $0.0285까지, 약 24배 줄인 경험처럼, 불필요한 요청을 원천 차단하면 리소스 효율도 비약적으로 올라간다.

XML-RPC 및 REST API 무차별 대공격 막기

xmlrpc.php는 원격에서 블로그를 관리하기 위한 기능이지만, DDoS 공격이나 무차별 대공격(Brute Force)에 악용되는 주요 타겟이다. xmlrpc_enabled` 필터는 인증이 필요한 XML-RPC 메서드만 끄며, XML-RPC 요청 전체를 차단하려면 웹 서버나 WAF 설정 또는 메서드별 필터가 추가로 필요하다. functions.php에 아래 코드를 추가한다.

add_filter('xmlrpc_enabled', '__return_false');

REST API 역시 불필요한 외부 호출을 막아야 한다. 다만, 내가 만든 SaaS처럼 외부 서비스와 연동이 필요한 경우 API를 완전히 막으면 서비스가 멈춘다. 이럴 땐 특정 IP나 인증된 사용자에게만 접근을 허용하는 예외 처리를 필수적으로 넣어야 한다. 허용 IP를 설정하는 경험을 통해, 보안 설정과 기능 동작의 균형을 맞추는 법을 터득했다.

파일 직접 접근 차단 (Disable File Editing)

워드프레스 관리자 화면에서 테마나 플러그인의 코드를 직접 수정할 수 있는 기능이 있다. 편하지만 해커가 관리자 권한을 탈취했을 때 악성 코드를 심는 가장 쉬운 방법이기도 하다. wp-config.php에 이 코드를 한 줄 추가하면 관리자 화면에서 더 이상 파일 편집이 불가능해진다.

define( 'DISALLOW_FILE_EDIT', true );

이 설정은 코드 수정은 무조건 FTP나 파일 관리자로 하게 만든다는 뜻이다. 귀찮아진다고 생각할 수 있지만, DISALLOW_FILE_EDIT`는 관리자 화면의 파일 편집 경로 하나를 제거하지만, 관리자 계정 탈취 후의 모든 코드 변경을 막는 설정은 아니다.

외부 API 호출과 보안 설정의 충돌 해결법

보안 코드를 넣다 보면 의도치 않게 정상적인 기능이 막히는 수가 있다. 예를 들어, SSL 강제 리다이렉트를 걸었는데 특정 결제 모듈이 비보안 콜백을 요구하면 결제가 실패한다. 이럴 때는 .htaccess 파일에서 특정 경로만 SSL 예외로 두는 세심한 설정이 필요하다. 보안이 중요하지만, 사이트가 기능을 못 하면 존재 의의가 사라진다. 문제가 생겼을 때는 즉시 방금 수정한 설정을 주석 처리하고, 접속 로그를 확인해서 어떤 요청이 막혔는지 파악해야 한다.

잘못 수정했을 때 사이트가 멈추면 복구하는 절차

아무리 조심해도 실수는 하기 마련이다. 내가 운영하는 시스템도 문법 오류가 나면 알림을 보내는 모니터링을 돌리고 있다. 문제는 화면이 하얗게 나오는 WSOD(White Screen of Death) 상황이 언제 터질지 모른다는 점이다.

화면이 하얗게 나올 때(WSOD) 원인 파악

WSOD는 대부분 PHP 메모리 부족이나 문법 오류 때문에 발생한다. wp-config.php를 수정한 직후에 이 화면이 떴다면 문법 오류부터 의심하는 게 순서다. 누락된 세미콜론(;)이나 따옴표 짝이 안 맞는지 의심해야 한다. 에러 로그를 볼 수 없다면, 해당 파일 수정 내용을 하나씩 지워가면서(혹은 주석 처리하면서) 어디서 문제가 터지는지 확인한다.

문법 오류(Syntax Error) 발생 시 수정법

브라우저 화면에 "Parse error: syntax error" 같은 메시지가 뜬다면 다행이다. 몇 번째 줄에서 무엇이 잘못됐는지 알려주기 때문이다. FTP 대신 파일 관리자로 접속해서 해당 라인으로 이동해 수정한다. 만약 수정 사항이 기억나지 않는다면, 처음에 백업해 둔 .bak 파일로 덮어씌우는 것이 정신 건강에 이롭다. 자존심 세울 때가 아니다.

백업 파일로 원복하는 마지막 단계

사이트가 죽었을 때 급하게 복구하다 보면, 오류가 난 파일을 또 백업해버리는 실수를 저지르기 쉽다. 그러면 깨끗한 원본이 사라진다. 반드시 수정 전 상태로 돌아갈 때는 덮어쓰기 말고, 기존 파일을 이름을 바꿔서(wp-config.php.error) 보관해 두고 백업 파일을 가져온다. 그래야 다시 원인을 분석할 여지가 남는다.

마무리: 안전한 보안 설정을 위한 체크리스트

지금까지 wp-config.php 수정 실수 없이 보안을 강화하는 방법을 정리했다. 코드 한 줄이 사이트의 운명을 가르기도 한다. 나는 모든 수정 후에 사람이 직접 검토하는 '수동 검수 게이트'를 두고 있다. 자동화가 아무리 편해도, 결국 최종 책임은 사람이 져야 한다. SEO 플러그인으로 변경 사항을 함께 검증하는 것도 좋지만, 기본적으로 파일을 건드리기 전 백업을 확인하는 습관이 그 어떤 도구보다 강력하다.

• 파일 수정 전 .bak 파일 생성 여부 확인
• 수정 코드의 문법(Syntax) 체크
• 사이트 접속 및 관리자 페이지 로그인 테스트
• 외부 API 연동 서비스 정상 작동 여부 확인

이 과정을 하나씩 거치면 해킹도 두렵지 않다. 너무 조급하게 하지 마라. 천천히, 그리고 확실하게 적용하는 게 빠른 길이다.