[워드프레스] 6. 준비 : 워드프레스 분해용 실습 환경 세팅

(워드프레스 해부 ⑥) 준비

여기까지 오면서 계속 “로그를 보자”, “규칙표를 확인하자”고 했다. 이걸 편하게 하려면 안을 들여다보는 도구가 필요하다. 앞으로의 분해 실습에 쓸 세 가지를 세팅하자. 이 편만 따라 하면 나머지 시리즈가 훨씬 수월해진다.

• WP_DEBUG 로그 — 3편에서 켠 그것. 오류·경고를 wp-content/debug.log에 남긴다.
• Query Monitor — 관리자 바에서 페이지마다 실행된 DB 쿼리·발동된 훅·선택된 템플릿·PHP 오류를 실시간으로 보여주는 플러그인. 워드프레스 분해엔 이게 거의 X-ray다.
• WP-CLI — 명령줄로 워드프레스를 다루는 도구. 옵션·DB·사용자를 화면 없이 조회·조작한다.

직접 해보기

Query Monitor는 플러그인 → 새로 추가에서 검색해 설치·활성화하면 된다. 켜면 관리자 바에 실행 시간·쿼리 수가 뜨고, 클릭하면 상세 패널이 열린다. WP-CLI는 서버에서 이렇게 확인·사용한다.

# WP-CLI 동작 확인
$ wp --info

# 사이트 주소, 활성 테마, 플러그인 목록을 화면 없이 조회
$ wp option get siteurl
$ wp theme list --status=active
$ wp plugin list --status=active

이 셋을 조합하면 앞으로 이런 게 가능하다. “이 페이지가 왜 느리지?” → Query Monitor로 느린 쿼리 확인. “이 옵션 값이 뭐지?” → wp option get. “오류가 어디서 나지?” → debug.log. 눈으로 보이니 추측할 일이 준다.

✅ 확인 — Query Monitor를 켠 뒤 아무 페이지나 열었을 때, 상단 관리자 바에 실행 시간과 DB 쿼리 개수(예: 0.05s / 24 Q)가 뜨면 준비 완료다. 그 숫자를 클릭하면 이 시리즈에서 계속 파고들 워드프레스의 내부가 펼쳐진다.

WP_DEBUG 제대로 켜기

3편에서 봤던 WP_DEBUG부터 제대로 잡자 — 실습용으로는 상수 몇 개를 세트로 건다. 핵심은 오류를 화면에 띄우지 말고 로그로만 남기는 것이다. 방문자에게 오류 메시지가 노출되면 경로·정보가 새기 때문이다.

define( 'WP_DEBUG', true );          // 디버그 켜기
define( 'WP_DEBUG_LOG', true );      // wp-content/debug.log 에 기록
define( 'WP_DEBUG_DISPLAY', false ); // 화면엔 출력 안 함
@ini_set( 'display_errors', 0 );
define( 'SCRIPT_DEBUG', true );      // JS/CSS 원본(비압축) 로드

이제 오류·경고가 wp-content/debug.log에 쌓인다. 실습 중엔 tail -f wp-content/debug.log로 실시간으로 흐르는 로그를 켜 두면, 뭘 건드릴 때 무슨 일이 나는지 바로 보인다.

WP-CLI — 명령으로 뜯어보기

관리자 화면을 거치지 않고 명령으로 내부를 조회한다. 옵션 값, 글 목록, DB 쿼리를 바로 확인할 수 있어 실습이 빨라진다(36편).

wp option get siteurl          # 옵션 값 확인
wp post list --format=count    # 글 개수
wp db query "SELECT COUNT(*) FROM wp_postmeta"   # DB 직접 조회

세 도구가 합쳐지는 순간 — 미니 시나리오

도구 나열로 끝내지 말고, 셋이 실제로 어떻게 맞물리는지 시나리오 하나로 보자. “관리자 페이지가 유난히 느리다”고 치면 —

1. Query Monitor의 관리자 바 숫자를 본다 — 쿼리 수가 수백이면 그 자체가 단서다. Queries by Component에서 범인 플러그인을 짚는다.
2. 그 플러그인이 어떤 데이터를 쌓는지 WP-CLI로 확인한다 — wp option list --search="접두어_*".
3. 비활성화 후 잔여 오류가 있는지 debug.log를 tail로 지켜본다.

역할이 다르다 — QM은 어디가 문제인지, WP-CLI는 데이터가 어떤 상태인지, debug.log는 코드가 무슨 비명을 지르는지. 이 삼각 측량이 이 시리즈 내내 반복된다(실전 풀버전은 32편).

운영 말고, 로컬·스테이징에서

이 도구들과 실습은 로컬이나 스테이징에서 한다. Local, wp-env, Docker 같은 걸로 워드프레스를 노트북에 띄우면, 무엇을 부숴도 운영 사이트엔 영향이 없다. 테이블을 직접 수정하는 것 같은 파괴적 실습은 특히 이런 격리된 환경에서만 하자.

디버그를 다시 끄는 것도 실습의 일부

실습이 끝나면 WP_DEBUG를 반드시 다시 꺼야 한다. 운영에서 켜 두면 debug.log가 무한정 쌓여 디스크를 먹고, 실수로 WP_DEBUG_DISPLAY가 켜지면 오류 화면에 서버 경로 같은 정보가 노출된다. ‘켤 줄 알고 끌 줄 아는’ 것까지가 한 세트다.

기초 모듈은 여기서 끝. 다음 모듈부터는 본격적으로 데이터베이스를 뜯는다 — 글 하나가 DB에 어떻게 저장되고, 설정은 어디 숨어 있는지. 이번 편에서 세팅한 도구들을 계속 쓰게 된다.

자주 묻는 질문 (FAQ)

워드프레스 내부를 뜯어보려면 뭐가 필요한가요?

Query Monitor 플러그인, WP-CLI, 디버그 로그(WP_DEBUG_LOG)면 대부분의 내부 동작을 관찰할 수 있습니다.

운영 사이트에서 실습해도 되나요?

권장하지 않습니다. 로컬이나 스테이징에서 실습하고, 파괴적 작업은 읽기·관찰 위주로 하세요.