728x90
반응형

워드프레스를 운영하다 보면 관리자 화면에서 글을 수정하려고 했는데 편집기가 계속 로딩되거나 저장 중 오류가 발생하고, 특정 글만 열리지 않는 문제가 생길 때가 있습니다.

사이트 전체가 안 열리는 것도 아니고 다른 글은 정상인데 특정 게시글만 500 오류가 발생하거나 관리자 편집기조차 열리지 않는다면 더 난감합니다.

이때 FTP에 접속해서 문제가 된 글 제목이나 URL과 같은 HTML 파일을 찾으려고 하는 경우가 있는데, 워드프레스는 일반적인 HTML 홈페이지와 저장구조가 다르기 때문에 아무리 찾아도 해당 글 파일은 나오지 않습니다.

먼저 알아둘 핵심

워드프레스의 테마·플러그인·이미지·PHP 파일 → FTP에 저장
워드프레스의 글·페이지·댓글·설정 → MySQL/MariaDB 데이터베이스에 저장

따라서 특정 글 본문을 직접 고치려면 보통
FTP → wp-config.php → phpMyAdmin → *_posts → post_content
순서로 접근합니다.

저도 특정 글 하나가 열리지 않는 상황이라면 처음부터 워드프레스를 재설치하기보다는 오류 로그를 확인하고 문제가 된 글의 post_content를 따로 백업한 뒤 수동으로 복구하는 방법을 먼저 선택합니다.

워드프레스 글은 FTP 어디에 저장될까?

결론부터 말하면 워드프레스 글은 FTP의 개별 HTML 파일로 저장되지 않습니다.

예를 들어 아래와 같은 워드프레스 글 주소가 있다고 가정해보겠습니다.

/category/wordpress-post-error/

FTP에서 다음과 같은 폴더를 찾아봐도 글 파일은 나오지 않습니다.

/public_html/category/wordpress-post-error.html

/public_html/category/wordpress-post-error/index.html

워드프레스는 요청받은 URL을 PHP와 데이터베이스를 이용해 동적으로 만들어 보여주는 CMS이기 때문입니다.

FTP에 저장되는 워드프레스 파일

FTP 또는 SFTP로 워드프레스가 설치된 서버에 접속하면 보통 다음 구조가 나타납니다.

public_html/
│
├─ wp-admin/
├─ wp-content/
│   ├─ plugins/
│   ├─ themes/
│   └─ uploads/
│
├─ wp-includes/
├─ wp-config.php
├─ .htaccess
└─ index.php

여기에는 워드프레스 코어, 플러그인, 테마, 업로드 이미지와 각종 서버 설정파일이 들어 있습니다.

반대로 우리가 관리자에서 작성한 글 본문, 제목, 댓글, 카테고리 연결, 각종 옵션은 대부분 데이터베이스에 저장됩니다.

FTP 사용방법을 모른다면

잡가이버의 워드프레스 FTP 접속 파일질라 로그인부터 백업·수정까지 글을 먼저 참고하면 FTP 폴더 구조를 이해하기 쉽습니다.

워드프레스 글 본문은 wp_posts에 저장

일반적인 워드프레스에서는 게시글과 페이지 정보가 다음 테이블에 저장됩니다.

wp_posts

그리고 실제 글 본문은 주로 다음 필드에 들어갑니다.

post_content
필드 내용
ID 게시글 고유번호
post_title 글 제목
post_name URL에 사용하는 슬러그
post_content 실제 글 본문과 Gutenberg 블록 코드
post_status publish·draft 등 글 상태
post_type post·page·revision 등 콘텐츠 종류

Gutenberg 블록 에디터를 사용하는 글이라면 post_content 안에서 이런 코드도 볼 수 있습니다.

<!-- wp:paragraph -->
<p>워드프레스 글 내용입니다.</p>
<!-- /wp:paragraph -->

따라서 깨진 Gutenberg 블록, 잘못된 HTML, SVG, 숏코드 등이 특정 글의 post_content 안에 들어 있고 해당 코드를 처리하는 과정에서 오류가 발생한다면 그 글 하나만 안 열리는 상황도 생길 수 있습니다.

워드프레스 글 수정 오류 원인부터 구분하기

바로 DB부터 수정하는 것보다는 현재 문제가 어느 범위인지 먼저 확인하는 것이 좋습니다.

증상 의심할 부분
특정 글 하나만 안 열림 해당 글 HTML·블록·숏코드·동적 콘텐츠
모든 글 편집이 안 됨 플러그인·REST API·보안설정·PHP 오류
wp-admin 전체 접속 불가 플러그인·테마·PHP·.htaccess
500 Internal Server Error PHP Fatal Error·메모리·플러그인
업데이트 실패 / JSON 오류 REST API·방화벽·ModSecurity·플러그인
편집 화면만 무한 로딩 JavaScript·REST API·대형 post_content

특정 글만 오류라면 글 본문부터 의심

사이트 메인과 다른 게시글, wp-admin까지 정상인데 특정 글 하나를 열 때만 500 오류나 Critical Error가 발생한다면 글 내부의 코드를 먼저 살펴볼 가치가 있습니다.

대표적으로 다음과 같은 내용이 문제가 될 수 있습니다.

  • 깨진 Gutenberg 블록 주석
  • 잘못 닫힌 HTML 태그
  • 아주 큰 SVG 코드
  • 플러그인에서 처리하는 숏코드
  • 깨진 JSON-LD
  • 외부 데이터를 호출하는 동적 블록
  • 삭제된 플러그인의 블록
  • PHP를 실행하는 특수 숏코드

사이트 전체가 안 열리면 post_content를 먼저 건드리지 않는다

반대로 사이트 전체와 관리자까지 함께 죽었다면 특정 글 DB를 수정하는 것이 우선순위가 아닙니다.

이 경우에는 최근 업데이트한 플러그인, 테마, PHP 버전, .htaccess와 서버 오류로그를 먼저 확인하세요.

FTP와 phpMyAdmin으로 특정 글 직접 수정하기

이제 특정 글의 post_content를 직접 확인하는 방법입니다.

주의

운영 중인 DB를 직접 수정하기 전에 반드시 백업하세요.
DB 직접 수정은 워드프레스 편집기를 거치지 않기 때문에 자동 리비전 생성이나 플러그인 저장 훅이 정상 실행되지 않을 수 있습니다.

1. FTP에서 wp-config.php 확인

FTP 또는 호스팅 File Manager에서 워드프레스 루트의 wp-config.php를 찾습니다.

일반적인 위치는 다음과 같습니다.

/public_html/wp-config.php

/www/wp-config.php

/htdocs/wp-config.php

wp-config.php를 열어 데이터베이스 정보를 확인합니다.

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

여기서 특히 확인할 것은 DB_NAME입니다. 여러 워드프레스를 하나의 서버에서 운영한다면 엉뚱한 DB를 수정하지 않도록 반드시 확인해야 합니다.

그리고 아래쪽에서 테이블 접두사도 확인합니다.

$table_prefix = 'wp_';

사이트에 따라 보안이나 설치환경 때문에 다음과 같이 다를 수 있습니다.

$table_prefix = 'abc123_';

그렇다면 글 테이블도 wp_posts가 아니라 abc123_posts가 됩니다.

워드프레스 .htaccess · wp-config.php 위치 및 수정방법

wp-config.php와 워드프레스 핵심 설정파일 위치가 헷갈린다면 함께 참고하기 좋습니다.

2. phpMyAdmin 접속 후 먼저 DB 전체 백업

카페24, 블루호스트, cPanel 등 호스팅 관리자에서 phpMyAdmin으로 들어갑니다.

DB를 선택한 뒤 가능하면 수정 전에 먼저 Export → SQL 방식으로 데이터베이스를 백업합니다.

추천 백업 순서

1. FTP로 wp-content와 wp-config.php 백업
2. phpMyAdmin에서 DB Export
3. 문제가 된 글의 post_content를 별도 HTML 파일로 한 번 더 저장
4. 그다음 수정

워드프레스 전체 수동 백업이 필요하다면 아래 글을 함께 참고하세요.

워드프레스 백업 - 블루호스트 카페24 FTP 접속방법

3. URL 슬러그로 글 ID 찾기

phpMyAdmin 상단의 SQL 메뉴에서 다음 쿼리를 실행합니다.

SELECT
    ID,
    post_title,
    post_name,
    post_status,
    post_type
FROM wp_posts
WHERE post_name = 'wordpress-post-error';

여기서 wp_posts는 실제 사이트의 테이블 접두사에 맞춰 변경합니다.

그리고

wordpress-post-error

부분에는 해당 글 URL 맨 마지막 슬러그를 넣습니다.

결과가 예를 들어 다음과 같다고 하겠습니다.

ID          : 28754
post_title  : 워드프레스 글 수정 오류
post_name   : wordpress-post-error
post_status : publish
post_type   : post

이제 글 ID가 28754라는 것을 확인한 것입니다.

4. post_content 원문 백업

SQL에서 다음처럼 본문만 확인할 수도 있습니다.

SELECT post_content
FROM wp_posts
WHERE ID = 28754;

하지만 실제 수정은 긴 HTML을 SQL UPDATE 문에 직접 넣기보다 phpMyAdmin의 찾아보기 → 해당 행 수정 기능을 사용하는 편이 실수를 줄이기 쉽습니다.

post_content 내용을 통째로 복사해 PC에 다음과 같이 저장해두세요.

post-28754-original.html

이 파일이 가장 중요한 비상 복구본입니다.

5. 깨진 HTML이나 블록만 수정

post_content 안에서 문제가 의심되는 부분을 제거하거나 수정합니다.

예를 들어 최근 추가한 SVG나 숏코드 이후부터 페이지가 안 열린다면 그 부분만 임시로 제거해서 먼저 확인합니다.

원인이 전혀 보이지 않는다면 글 전체를 삭제해버리기보다 원문을 백업해둔 뒤 아주 짧은 테스트 본문으로 교체해보는 방법도 있습니다.

<!-- wp:paragraph -->
<p>게시글 복구 테스트입니다.</p>
<!-- /wp:paragraph -->

이 상태에서 글이 정상적으로 열린다면 URL이나 워드프레스 자체보다는 기존 post_content 내부의 특정 블록·HTML·숏코드가 문제였을 가능성이 높습니다.

그 후 원본 HTML을 조금씩 되돌려 넣으며 문제가 되는 구간을 찾을 수 있습니다.

6. 수정 후 캐시 삭제

DB에서 글을 직접 수정했는데 화면이 그대로라면 캐시 때문에 이전 결과가 보이는 경우도 있습니다.

  • 워드프레스 캐시 플러그인 삭제
  • 서버 페이지 캐시 삭제
  • CDN 캐시 삭제
  • 브라우저 강력 새로고침
  • 시크릿 모드로 확인

SSH WP-CLI로 글을 백업하고 수정하는 방법

SSH 사용이 가능한 VPS나 서버라면 저는 phpMyAdmin에서 긴 HTML을 직접 수정하는 것보다 WP-CLI를 더 추천합니다.

WP-CLI는 워드프레스 API를 거쳐 게시글을 읽고 수정할 수 있기 때문에 작업 과정이 명확하고 백업파일을 만들기도 쉽습니다.

URL만 알고 있을 때 글 ID 확인

wp post url-to-id 'https://example.com/category/sample-post/'

정상이라면 다음처럼 글 ID가 반환됩니다.

28754

슬러그로 게시글 검색

wp post list \
--post_type=post \
--name=wordpress-post-error \
--fields=ID,post_title,post_name,post_status

현재 글 본문을 HTML 파일로 백업

wp post get 28754 --field=content > post-28754-backup.html

여기서 중요한 것은 --field=content입니다.

서버에 다음 파일이 생성됩니다.

post-28754-backup.html

FTP나 SFTP로 내려받아 VS Code, Sublime Text 같은 편집기로 열면 관리자 화면이 없어도 글 원문을 직접 확인할 수 있습니다.

수정한 HTML 파일을 다시 게시글에 적용

예를 들어 수정한 파일을 다음 이름으로 저장했다고 하겠습니다.

post-28754-fixed.html

WP-CLI에서는 파일 자체를 게시글 내용으로 사용할 수 있습니다.

wp post update 28754 post-28754-fixed.html

정상이라면 다음과 비슷한 결과가 나타납니다.

Success: Updated post 28754.

긴 HTML을 쉘 인수로 통째로 전달하는 것보다 파일을 직접 지정하는 방법이 훨씬 깔끔합니다.

시스템 편집기에서 직접 수정

SSH 환경의 기본 편집기 사용이 익숙하다면 다음 명령도 사용할 수 있습니다.

wp post edit 28754

설정된 vi, nano 등의 시스템 편집기로 글 본문을 바로 수정할 수 있습니다.

플러그인 때문에 WP-CLI도 오류가 날 때

워드프레스를 불러오는 과정에서 특정 플러그인이 Fatal Error를 내면 WP-CLI 명령 자체도 실패할 수 있습니다.

이럴 때 일반 게시글이라면 다음처럼 플러그인과 테마 로딩을 건너뛰고 본문을 가져와볼 수 있습니다.

wp post get 28754 \
--field=content \
--skip-plugins \
--skip-themes \
> post-28754-backup.html
주의

Custom Post Type이나 특정 플러그인이 등록하는 콘텐츠라면 해당 플러그인을 모두 건너뛰는 방식이 오히려 문제를 만들 수 있습니다. 일반 post·page보다 조심해서 사용하세요.

debug.log로 특정 글이 안 열리는 원인 찾기

글을 무작정 삭제하기 전에 가장 좋은 방법은 실제 서버 오류를 확인하는 것입니다.

워드프레스는 wp-config.php에서 디버그 로그를 활성화할 수 있습니다.

wp-config.php 디버그 설정

wp-config.php에서 다음 설정을 추가하거나 기존 값을 변경합니다.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

이 설정은 보통 다음 문구보다 위에 넣습니다.

/* That's all, stop editing! Happy publishing. */

문제가 된 글을 한 번 열어보기

설정 후 문제가 발생하는 URL을 다시 한 번 열어봅니다.

오류가 기록됐다면 일반적으로 다음 파일에서 확인할 수 있습니다.

/wp-content/debug.log

여기에서 다음과 같은 문구를 찾아봅니다.

PHP Fatal error
Uncaught Error
Uncaught TypeError
Allowed memory size exhausted
Call to undefined function
Maximum execution time exceeded

그리고 오류 줄에 함께 표시되는 플러그인·테마 파일 경로를 확인합니다.

예를 들어

/wp-content/plugins/example-plugin/...
/wp-content/themes/example-theme/...

처럼 나온다면 글 본문 자체보다 해당 플러그인이나 테마가 특정 콘텐츠를 렌더링하는 과정에서 죽는 문제일 수도 있습니다.

복구 후 WP_DEBUG는 다시 끄기

운영 중인 실제 사이트에서 디버그 모드를 장기간 켜놓는 것은 추천하지 않습니다.

원인을 확인한 뒤에는 다시 다음처럼 꺼두는 편이 좋습니다.

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

debug.log에 서버 경로, 플러그인 이름이나 기타 민감한 정보가 기록될 수 있으므로 필요 없는 로그파일도 정리합니다.

플러그인 문제라면 FTP로 강제 비활성화

관리자 화면이 열리지 않아 플러그인을 끌 수 없다면 FTP에서 해당 플러그인 폴더 이름을 바꾸는 방법이 있습니다.

예를 들어

/wp-content/plugins/example-plugin/

을

/wp-content/plugins/example-plugin-off/

처럼 임시 변경합니다.

이 상태에서 문제가 해결된다면 해당 플러그인과의 연관성을 의심할 수 있습니다.

phpMyAdmin과 WP-CLI 중 어느 방법이 더 좋을까?

방법 장점 추천 상황
워드프레스 편집기 가장 안전하고 편함 관리자 편집기가 정상일 때
phpMyAdmin SSH 없이 DB 직접 접근 가능 특정 글만 복구할 때
WP-CLI 백업·수정이 빠르고 명확 VPS·SSH 사용 가능할 때
MySQL 직접 접속 대형 DB에서도 빠름 고급 서버 관리자
FTP 설정파일·로그·플러그인 수정 DB 수정의 보조수단

FTP만으로는 워드프레스 게시글 본문을 직접 변경할 수 없다는 점이 중요합니다.

FTP는 DB 정보를 확인하고, 로그를 읽고, 플러그인·테마를 비활성화하거나 백업 파일을 주고받는 통로라고 생각하면 이해하기 쉽습니다.

워드프레스 글 수정 오류 최종 복구 순서

제가 특정 게시글 하나만 열리지 않는 상황을 만난다면 다음 순서로 처리합니다.

특정 글 복구 체크리스트

1. 다른 글·관리자 페이지가 정상인지 확인
↓
2. FTP에서 wp-config.php·error_log 확인
↓
3. 전체 DB와 문제가 된 post_content 백업
↓
4. URL 슬러그 또는 WP-CLI로 글 ID 확인
↓
5. post_content 원문 별도 저장
↓
6. 최근 추가한 HTML·SVG·숏코드부터 제거
↓
7. phpMyAdmin 또는 WP-CLI로 수정본 적용
↓
8. 캐시 삭제 후 해당 URL 테스트
↓
9. 해결되지 않으면 debug.log 활성화
↓
10. 오류를 낸 플러그인·테마 확인 후 수정

DB를 직접 만지기 전에 최소한 이것은 백업

  • wp-config.php
  • .htaccess
  • wp-content
  • 전체 MySQL DB
  • 수정 대상 post_content

특히 글 하나를 고치다가 문제가 생겼을 때 post_content 원본만 남아 있어도 다시 되돌리기 쉽습니다.

DB 수정 후에도 글이 계속 안 열린다면

본문을 완전히 단순한 테스트 문장으로 바꿨는데도 같은 URL에서 오류가 난다면 post_content 자체가 원인이 아닐 가능성이 높습니다.

이 경우 다음을 확인합니다.

  • 해당 카테고리나 템플릿에만 적용되는 PHP 코드
  • 특정 포스트 메타를 읽는 플러그인
  • Rank Math·목차·관련글·광고 플러그인의 콘텐츠 필터
  • 테마의 single.php 또는 관련 템플릿
  • PHP 메모리 초과
  • 서버 WAF·ModSecurity
  • CDN·페이지 캐시 오류

그래서 DB를 수정하기 전에 debug.log를 같이 확인하는 것이 시간을 가장 많이 줄여줍니다.

DB 테이블 자체가 너무 크거나 느린 경우

오래 운영한 워드프레스는 wp_posts보다 wp_postmeta, wp_options, 플러그인 로그 테이블 등이 지나치게 커져 관리자 저장이나 phpMyAdmin 조회가 느려지는 경우도 있습니다.

이 경우 글 하나만 고치는 것과 DB 전체 최적화는 분리해서 진행하는 것이 좋습니다.

워드프레스 MySQL DB 최적화 방법 - phpMyAdmin SSH WP-CLI

워드프레스 수동 복구 관련글

워드프레스 글 수정 오류 FAQ

Q. FTP에서 제가 작성한 워드프레스 글 HTML 파일은 어디에 있나요?
A. 일반 워드프레스 게시글은 개별 HTML 파일로 저장되지 않습니다. 글 본문은 일반적으로 데이터베이스의 *_posts 테이블 post_content에 저장됩니다.

Q. FTP만으로 워드프레스 게시글을 수정할 수 있나요?
A. 일반적인 글 본문은 FTP만으로 직접 수정하기 어렵습니다. FTP에서는 wp-config.php로 DB 정보를 확인하고 phpMyAdmin이나 SSH·WP-CLI를 이용해 글 본문을 수정합니다.

Q. wp_posts 테이블이 없습니다.
A. wp-config.php의 $table_prefix를 확인하세요. 접두사가 abc_라면 테이블 이름은 abc_posts가 됩니다.

Q. 특정 글 하나만 500 오류가 나는 이유는 무엇인가요?
A. 해당 글에 들어 있는 잘못된 HTML, 숏코드, Gutenberg 블록, SVG나 이를 처리하는 플러그인에서 PHP 오류가 발생할 수 있습니다. wp-content/debug.log와 서버 error_log를 같이 확인하세요.

Q. phpMyAdmin에서 post_content를 수정해도 되나요?
A. 가능하지만 먼저 원문과 DB를 백업해야 합니다. 직접 DB 수정은 워드프레스의 일반적인 저장 과정을 우회하므로 꼭 필요한 복구 상황에서 최소한으로 사용하는 것이 좋습니다.

Q. SSH가 가능하면 phpMyAdmin과 WP-CLI 중 무엇이 더 좋나요?
A. 게시글 하나의 원문을 백업하고 수정하는 작업이라면 WP-CLI가 편합니다. wp post get으로 HTML을 파일로 저장한 뒤 수정하고 wp post update에서 파일을 다시 적용할 수 있습니다.

Q. debug.log는 계속 켜놔도 되나요?
A. 운영 사이트에서는 필요한 동안만 사용하는 것이 좋습니다. 오류 확인이 끝나면 WP_DEBUG를 다시 끄고 로그파일에 민감한 정보가 남아 있지 않은지도 확인합니다.

Q. post_content를 바꿨는데도 계속 같은 오류가 납니다.
A. 테스트 문장만 넣었는데도 같은 오류라면 글 본문이 아니라 테마 템플릿, 플러그인 콘텐츠 필터, 메타데이터, PHP 메모리, 캐시 등을 확인해야 합니다.

워드프레스 관리자에서 특정 글을 수정할 수 없다고 해서 글을 포기하거나 사이트 전체를 복원할 필요는 없습니다.

워드프레스의 저장 구조만 이해하면 FTP에서 wp-config.php와 오류 로그를 확인하고, phpMyAdmin에서 *_posts의 post_content를 찾거나 WP-CLI로 원문을 HTML 파일로 빼낸 뒤 직접 수정할 수 있습니다.

다만 DB 직접 수정은 가장 마지막에 사용하는 복구수단에 가깝습니다. 먼저 백업을 남기고 debug.log를 통해 오류 원인을 확인한 뒤 문제가 된 부분만 최소한으로 수정하는 것이 안전합니다.

특히 특정 게시글 하나만 안 열리는 경우라면 사이트 전체를 롤백하기 전에 해당 글 post_content 백업 → 테스트 본문 적용 → 오류구간 확인 순서로 접근해보는 것이 가장 효율적입니다.

반응형
그리드형
저작자표시 비영리 변경금지 (새창열림)

'블로그 수익화 > 블로그 SEO' 카테고리의 다른 글

워드프레스 카테고리·태그 검색노출 차단｜Rank Math Noindex 설정방법  (0) 2026.10.09
워드프레스 네이버 애널리틱스 등록방법｜방문자·유입검색어 분석 및 오류 해결  (0) 2026.10.09
워드프레스 표 만들기 및 모바일 표 잘림 해결｜반응형 HTML·CSS 설정  (0) 2026.10.09