WordPress

WordPress는 PHP로 작성되고 데이터베이스에 콘텐츠를 저장하는 오픈소스 콘텐츠 관리 시스템(CMS)입니다. 관리자가 브라우저에서 글과 페이지를 작성하면 서버의 PHP가 요청을 처리하고 데이터베이스에서 콘텐츠를 읽어 HTML로 응답합니다. 따라서 화면에 오류가 나타나면 PHP 실행 구간과 데이터베이스 연결 구간, 그리고 플러그인·테마·서버 설정 중 어디에서 실패했는지를 나누어 확인해야 합니다.

WordPress 오류 화면은 원인 그 자체가 아니라, 여러 구간 중 한 곳에서 발생한 실패가 표면에 드러난 결과입니다.

확인 범위

관찰 구간	확인할 내용
PHP 실행	치명적 오류, 메모리 초과, 플러그인·테마 충돌 여부
데이터베이스	wp-config.php의 접속 정보와 데이터베이스 서버 응답
플러그인·테마	비활성화 후 증상이 사라지는지 여부
서버 설정	.htaccess, mod_rewrite, .maintenance 파일 상태

공식 출처가 정리하는 대표 오류

WordPress 고급 관리 안내서는 다음과 같은 오류를 대표 사례로 설명합니다.

• 백지 화면(White Screen of Death) — PHP 또는 데이터베이스 오류로 화면에 아무것도 표시되지 않는 상태입니다. 호환되지 않는 플러그인이나 테마가 원인으로 자주 지목됩니다.
• Internal Server Error — 손상된 .htaccess, 플러그인·테마 충돌, PHP 메모리 부족 등이 원인으로 제시됩니다.
• Error Establishing a Database Connection — wp-config.php의 접속 정보 오류, 호스팅 측 문제 등이 원인으로 제시됩니다.
• 연결 시간 초과(Connection Timed Out) — 서버 용량을 초과할 때 발생하며 공유 호스팅에서 자주 나타난다고 설명합니다.
• 업그레이드 후 유지보수 모드 — 업데이트 이후 .maintenance 파일이 남아 사이트 접근이 막히는 상태입니다.

진단 접근

공식 안내서는 원인을 단정하기 전에 관찰부터 하도록 권합니다. wp-config.php에서 디버그 모드를 켜 오류 로그를 확인하고, 플러그인과 테마를 하나씩 비활성화하며 증상이 사라지는 지점을 찾는 방식을 제시합니다.

• 관리자 화면만 열리지 않으면 /wp-admin/과 로그인 화면의 응답 비교부터 진행합니다.
• 알림 이메일과 서버 오류 로그를 먼저 확인합니다.
• 디버그 모드를 활성화해 실제 오류 메시지를 확보합니다.
• 플러그인·테마를 순서대로 비활성화해 충돌 지점을 좁힙니다.

되돌리기와 금지 조건

• 설정 파일(wp-config.php, .htaccess)을 수정하기 전에 원본을 백업하고, 문제가 재현되면 백업본으로 되돌립니다.
• 운영 중인 사이트에서는 디버그 화면 표시(WP_DEBUG_DISPLAY)를 켠 채로 두지 않습니다. 오류를 화면에 노출하면 경로·설정 같은 내부 정보가 방문자에게 보일 수 있으므로, 디버그는 로그 파일(WP_DEBUG_LOG)로만 남기고 표시는 끕니다.
• [Hypothesis] 원인을 확인하지 않은 채 플러그인·테마를 일괄 삭제하거나 데이터베이스를 직접 수정하는 조치는 되돌리기 어려우므로, 비활성화·로그 확인 같은 관찰 단계를 먼저 거칩니다.
• 하나의 오류 화면만으로 서버 전체 장애나 특정 플러그인의 결함이라고 단정하지 않습니다.