잘 되던 글 저장 버튼이 반응하지 않거나, 새 플러그인을 설치한 뒤 화면이 깨졌다면 플러그인 충돌을 의심할 수 있습니다.
하지만 오류가 생겼다는 이유만으로 최근 설치한 플러그인을 바로 삭제하면 원인을 확인하기 어려워집니다.
이 글에서는 증상과 최근 변경을 기록하고, 캐시를 구분한 뒤 플러그인을 하나씩 비활성화하며 원인을 좁히는 방법을 설명합니다.
관리자에 접속할 수 있을 때 진행하는 기본 절차와, 호스팅·FTP 도움이 필요한 고급 절차를 나누어 안내합니다.
1. 먼저 오류가 생긴 상황을 짧게 기록하기
플러그인 충돌은 두 기능이 함께 작동할 때 서로 영향을 주어 문제가 생기는 경우를 말합니다.
플러그인 자체의 오류나 테마·서버 환경과의 호환 문제도 비슷하게 보일 수 있으므로, 처음부터 충돌이라고 확정하지 않습니다.
오류 화면을 닫기 전에 다음 내용을 메모합니다.
| 기록할 항목 | 적는 방법의 예시 |
|---|---|
| 처음 알아챈 시각 | 10월 5일 오전 9시 20분, 한국 시간 |
| 문제가 생긴 위치 | 글 편집 화면, 특정 공개 글 주소, 로그인 화면 |
| 한 작업 | 기존 임시글을 열고 제목을 수정한 뒤 저장 |
| 기대한 결과와 실제 결과 | 저장되어야 하는데 버튼을 눌러도 반응이 없음 |
| 화면의 오류 문구 | 보이는 문구를 그대로 적거나 개인정보를 가린 캡처 |
| 바로 전 변경 | 플러그인 A 업데이트, 플러그인 B 설치, 테마 설정 변경 |
위 내용은 기록 방법을 보여 주는 예시입니다.
실제로 문제가 생긴 주소와 작업을 자신의 상황에 맞게 적습니다.
처음 발견한 시각과 실제 발생 시각은 다를 수 있습니다.
정확히 모르면 추측하지 말고 마지막으로 정상 작동했던 시각도 함께 적어 둡니다.
같은 주소에서 같은 버튼을 눌렀을 때 문제가 다시 나타나는지도 확인합니다.
글 저장 문제는 공개 글 대신 임시글에서 확인하고, 결제·메일 발송처럼 실제 처리가 일어나는 기능은 테스트 기능이나 별도 테스트 사이트를 사용합니다.
2. 현재 활성 목록과 백업 준비하기
관리자에서 플러그인 → 설치한 플러그인으로 이동합니다.
목록 위의 활성 필터를 누르면 현재 작동 중인 일반 플러그인을 확인할 수 있습니다.
플러그인 이름 아래에 비활성화 링크가 있으면 해당 플러그인이 활성 상태라는 뜻입니다.
플러그인 이름과 설치 버전을 메모하고 원래 꺼져 있던 항목도 구분합니다.
진단이 끝난 뒤 필요하지 않은 플러그인까지 모두 켜지 않도록 원래 상태를 남겨 두는 것입니다.
백업은 날짜와 포함 범위까지 확인합니다
비활성화는 플러그인의 작동을 잠시 멈추는 작업입니다.
삭제와 다르지만 플러그인에 따라 중지할 때 처리하는 내용이 있으므로, 아무 영향도 없는 작업이라고 생각하면 안 됩니다.
호스팅 관리 화면이나 현재 사용하는 백업 도구에서 사이트 파일과 데이터베이스 백업을 준비합니다.
데이터베이스는 글과 설정 등을 저장하는 공간입니다.
백업 완료 여부, 백업 시각, 포함 범위와 복원 방법을 확인하고 파일은 서버 밖의 안전한 위치에도 보관합니다.
백업을 만드는 구체적인 예시는 워드프레스 플러그인 업데이트 전 백업하고 하나씩 업데이트하는 방법에서 확인할 수 있습니다.
이미 오류가 생긴 상태의 백업은 현재 자료를 보존하는 용도이고, 정상 상태로 돌아갈 때는 오류 전 백업이 따로 필요할 수 있습니다.
가능하면 운영 사이트를 복사한 별도 테스트 사이트에서 진단합니다.
복사본이 운영 사이트의 데이터베이스나 결제·메일·외부 연동에 연결되어 있지 않은지 먼저 확인합니다.
운영 사이트에서 진단해야 한다면 방문자가 적은 시간을 정하고, 중지할 기능과 되돌릴 방법을 확인합니다.
로그인 보호, 결제, 회원, 문의 폼처럼 중요한 플러그인은 끄는 동안 기능이 중단되거나 보호가 약해질 수 있으므로 테스트 환경이나 담당자의 도움을 우선합니다.
WP 파일 관리자를 사용한다면 WP 파일 관리자 → 백업/복원의 기존 백업 목록에서 날짜와 포함 항목을 확인할 수 있습니다.
같은 행에 Database와 Plugins가 있는지 보고, 사이트 전체 복구를 준비한다면 테마와 업로드 등 필요한 자료도 포함되어 있는지 확인합니다.
목록 맨 위의 백업도 오래된 자료일 수 있습니다.
예를 들어 10월에 점검하는데 최근 백업이 9월 16일이라면, 그 이후의 글과 설정은 해당 백업에 없을 수 있습니다.
진단 전 현재 자료를 보관할 백업과 오류 전 정상 상태의 백업을 구분하고, 목록에 있다는 이유만으로 복원 버튼을 누르지 않습니다.
파일 백업의 이름만 보고 사이트 전체가 들어 있다고 생각하지 않습니다.
WP 파일 관리자의 Others는 wp-content 안의 기타 폴더이며, 최상위 설정 파일까지 포함된다는 뜻은 아닙니다.
필요한 복구 범위에 빠지는 파일이 있는지는 호스팅이나 사용하는 백업 도구의 안내로 확인합니다.
3. 캐시 때문에 이전 화면이 보이는지 구분하기
캐시는 페이지나 파일을 저장해 두었다가 빠르게 보여 주는 기능입니다.
화면을 고쳤는데 예전 모습이 계속 보이는 문제와, 같은 작업에서 실제 오류가 반복되는 문제는 구분해야 합니다.
공개 화면 문제라면 같은 주소를 다른 브라우저나 로그아웃한 시크릿 창에서도 열어 봅니다.
시크릿 창에서도 서버 캐시는 적용될 수 있으므로, 시크릿 창에서 보인다는 이유만으로 캐시 문제를 제외하지 않습니다.
사이트에서 사용하는 캐시를 다음처럼 나누어 확인합니다.
- 브라우저 캐시: 내 브라우저에 저장된 파일입니다.
- 플러그인 캐시: 워드프레스 캐시 플러그인이 저장한 페이지입니다.
- 호스팅·CDN 캐시: 서버나 중간 전달 서비스가 저장한 페이지입니다.
WP Super Cache를 사용한다면 설정 → WP Super Cache의 단순 탭을 엽니다.
아래로 내려 캐시된 페이지 삭제 영역의 캐시 삭제 버튼을 찾습니다.
실제로 캐시 영향을 점검할 때는 캐시 삭제를 누른 뒤 같은 주소를 다시 확인합니다.
캐싱 켜기·끄기 설정을 바꾸거나 상태 업데이트를 누르는 작업과 구분합니다.
다른 캐시 도구를 사용한다면 그 도구의 안내에 따라 비우고, 호스팅·CDN 캐시도 사용 중인지 따로 확인합니다.
캐시를 비우는 방법은 워드프레스 캐시 삭제와 테스트 방법에서 확인할 수 있습니다.
이전 내용이 사라지고 같은 조건에서도 정상이라면 우선 캐시 영향을 점검합니다.
반대로 저장 오류나 화면 깨짐이 계속되면 플러그인 진단을 이어 갑니다.
캐시 삭제 직후 한 번 정상이라는 이유만으로 문제가 해결됐다고 단정하지 않습니다.
4. 최근 바뀐 플러그인부터 순서 정하기
오류가 생기기 직전에 설치·업데이트·설정을 바꾼 플러그인부터 확인합니다.
최근 변경을 기억하지 못한다면 업데이트 알림 메일이나 호스팅 작업 기록 등 남아 있는 자료를 확인합니다.
플러그인 목록의 업데이트 가능 표시는 지금 새 버전이 있다는 뜻입니다.
언제 업데이트했는지 알려 주는 이력은 아니므로, 이 표시만 보고 최근 변경 대상을 정하지 않습니다.
테마나 워드프레스 업데이트, 호스팅의 PHP 변경도 함께 기록합니다.
PHP는 서버에서 워드프레스를 실행하는 프로그램입니다.
문제가 생긴 시점에 다른 변경이 있었다면 플러그인 하나만 원인으로 생각하지 않습니다.
진단 도중에는 여러 플러그인을 추가로 업데이트하거나 테마까지 동시에 바꾸지 않습니다.
한 번에 바꾸는 항목을 하나로 줄여야 어떤 변경 뒤 결과가 달라졌는지 알 수 있습니다.
5. 플러그인 하나만 비활성화하고 같은 작업 확인하기
백업과 복구 준비가 끝났다면 플러그인 → 설치한 플러그인으로 돌아갑니다.
처음 기록한 활성 목록을 기준으로 다음 순서대로 한 개씩 확인합니다.
- 메모해 둔 최근 변경 대상 중 하나를 고릅니다.
- 해당 플러그인 이름 아래의
비활성화를 누릅니다. - 화면이 바뀐 뒤 그 플러그인에
활성화링크가 보이는지 확인합니다. - 공개 화면 문제라면 준비한 방법으로 캐시를 비우고 같은 주소를 다시 엽니다.
- 처음 기록한 것과 같은 로그인 상태·입력 내용·작업 순서로 오류를 확인합니다.
- 중지한 플러그인 이름, 확인 시각과 결과를 메모합니다.
개별 비활성화 링크를 누르는 방식에서는 여러 항목의 체크박스를 선택할 필요가 없습니다.
원인 분리 중에는 모두 선택 → 비활성화 → 적용으로 한꺼번에 끄지 않습니다.
문제가 그대로라면 다시 켠 뒤 다음 항목을 확인합니다
같은 오류가 남아 있다면 해당 플러그인의 활성화를 눌러 원래 상태로 되돌립니다.
원래 기능이 돌아왔는지 확인한 다음 다음 플러그인 한 개를 비활성화합니다.
앞에서 끈 플러그인을 계속 꺼 둔 채 다음 것을 끄면 여러 기능이 동시에 바뀝니다.
이 글의 첫 점검은 한 개만 끈 상태를 원래 상태와 비교하는 방법입니다.
한 개씩 꺼도 해결되지 않는 경우는 뒤의 추가 점검으로 넘어갑니다.
문제가 사라지면 해당 플러그인을 원인 후보로 기록합니다
문제가 사라졌다면 일단 그 플러그인이 관여할 가능성이 있습니다.
하지만 문의 폼 플러그인을 꺼서 폼 자체가 사라졌다면, 제출 오류가 해결된 것이 아니라 확인할 기능이 없어진 상태입니다.
정상 결과는 단순히 오류 문구가 없는 화면이 아닙니다.
글이 실제로 저장되는지, 버튼이 동작하는지, 폼을 사용할 수 있는지처럼 처음 기대한 작업까지 완료되어야 합니다.
6. 재활성화했을 때도 같은 오류가 생기는지 확인하기
원인 후보가 정해지면 별도 테스트 사이트에서 해당 플러그인을 다시 활성화합니다.
같은 캐시 처리와 같은 작업 조건을 유지한 채 오류가 다시 생기는지 확인합니다.
운영 사이트에 큰 장애를 일으킨 플러그인은 원인을 증명하려고 다시 켜지 않습니다.
관리자 접속 중단이나 결제 오류가 있었다면 비활성 상태를 유지하고 테스트 환경에서 재검증하거나 제작자에게 문의합니다.
다음 표처럼 비교하면 문의할 때도 설명하기 쉽습니다.
| 비교 상태 | 같은 작업의 결과 | 판단 |
|---|---|---|
| 원래 활성 상태 | 오류 발생 | 비교를 시작할 기준 |
| 후보 하나만 비활성화 | 필요한 작업이 정상 완료 | 해당 플러그인 관여 가능성 |
| 테스트 사이트에서 다시 활성화 | 같은 오류 재발 | 원인 후보를 좁히는 근거 |
| 비활성화했지만 기능 자체가 사라짐 | 원래 작업을 할 수 없음 | 해결 여부 판단 불가 |
위 표는 판단 기준이며 실제 테스트 결과를 대신하는 기록이 아닙니다.
다시 켰을 때 오류가 재발하더라도 해당 플러그인 단독 오류인지, 다른 플러그인이나 테마와의 조합 문제인지는 추가 확인이 필요합니다.
7. 하나씩 꺼도 해결되지 않을 때
일반 플러그인을 하나씩 꺼도 같은 문제가 남으면 무작정 삭제를 반복하지 않습니다.
여러 플러그인의 조합, 필수 사용 플러그인, 별도 캐시 파일, 테마나 서버 설정도 살펴볼 수 있습니다.
별도 테스트 사이트에서는 원래 활성 목록을 기록한 뒤 일반 플러그인을 모두 끄고, 원래 사용하던 것을 하나씩 켜며 같은 오류가 나타나는 시점을 확인하는 방법도 있습니다.
플러그인 간 필수 관계가 있다면 필요한 기본 플러그인부터 켜고 제작자 안내를 따릅니다.
문제가 다시 나타났을 때 마지막으로 켠 플러그인 하나만 잘못됐다고 단정하지 말고, 당시 함께 켜져 있던 항목을 기록합니다.
이 과정은 여러 기능을 중단시키므로 운영 사이트에서 처음 시도하는 기본 절차와 구분합니다.
기능이 꺼져 원래 작업을 할 수 없다면 그 상태로는 오류가 사라졌는지 판단할 수 없습니다.
필수 사용 플러그인은 일반 목록과 다릅니다
목록 위에 필수 사용이 표시된다면 그 목록도 확인합니다.
필수 사용 플러그인은 정해진 폴더에서 자동으로 실행되며 일반 플러그인처럼 개별 비활성화 링크로 끌 수 없습니다.
드롭인 항목이 있다면 별도 캐시·연결 기능 등에 쓰이는 파일도 확인 대상이 될 수 있습니다.
일반 플러그인을 껐다는 이유로 이런 파일이나 호스팅 캐시까지 모두 중지됐다고 생각하지 않습니다.
필수 사용·드롭인 파일은 역할을 모른 채 삭제하거나 이름을 바꾸지 말고 호스팅이나 설치 담당자에게 확인합니다.
기본 테마 전환은 테스트 사이트에서 따로 확인하기
플러그인만으로 원인을 좁히기 어렵다면 기본 테마로 같은 작업을 확인할 수 있습니다.
그러나 테마 전환은 메뉴·위젯·글 목록·광고 위치·테마 전용 기능 등 방문자 화면에 영향을 줄 수 있습니다.
모양 → 테마에서 현재 활성 테마와 설치된 기본 테마를 먼저 확인합니다.
테마 이름에 활성 표시가 붙은 것이 현재 사용하는 테마입니다.
테스트 사이트에서 현재 테마 이름과 설정을 기록한 뒤 설치된 기본 테마를 활성화합니다.
플러그인 상태는 그대로 유지하고 같은 작업을 확인합니다.
기본 테마에서만 정상이라면 기존 테마와의 조합을 원인 후보로 기록합니다.
실시간 미리보기로 디자인을 보는 것만으로 저장·로그인 같은 기능 오류까지 검증되지는 않습니다.
진단이 끝나면 원래 테마를 다시 활성화하고 메뉴·위젯·광고·모바일 화면도 확인합니다.
운영 사이트에서는 복구 준비 없이 기본 테마의 활성화 버튼부터 누르지 않습니다.
관리자에 접속할 수 없다면: 호스팅·FTP 고급 절차
관리자까지 오류 화면이 뜬다면 앞의 비활성화 메뉴를 사용할 수 없습니다.
이때는 오류 발생 시각, 최근 바꾼 플러그인과 오류 문구를 정리해 호스팅 고객센터에 먼저 전달합니다.
호스팅 파일 관리나 FTP로 플러그인 폴더 이름을 임시 변경해 로딩을 막는 방법도 있습니다.
FTP는 서버 파일에 접속하는 방식이며, 이 작업은 서버의 실제 파일 위치와 원상 복구 방법을 아는 사람이 진행할 고급 절차입니다.
WordPress의 일반 플러그인은 설치 위치의 wp-content/plugins 아래에 있습니다.
원인 후보가 분명한 경우 담당자가 해당 플러그인 폴더만 임시 이름으로 바꾸어 접속을 확인할 수 있습니다.
원인 후보가 불명확하면 전체 plugins 폴더를 임시 변경하는 방식도 있지만, 여러 기능이 한꺼번에 중단됩니다.
담당자는 변경 전 이름과 경로를 기록하고 파일을 삭제하지 않습니다.
관리자가 열리면 플러그인 목록에서 상태를 확인한 다음 폴더 이름을 원래대로 복구합니다.
목록을 열어 비활성 처리된 플러그인은 폴더 이름만 복구해도 자동으로 모두 활성화되지 않으므로, 원래 목록을 보고 필요한 항목을 하나씩 켜며 확인합니다.
관리자에 접속하지 못하는 상황에서 워드프레스 안의 파일 관리자 플러그인을 해결 수단으로 기대하기는 어렵습니다.
호스팅의 파일 관리 화면이나 별도 서버 접속 방법이 필요합니다.
데이터베이스 값을 직접 바꾸거나 필수 사용 폴더까지 임의로 변경하는 작업은 초보자 기본 절차에서 제외합니다.
오류 로그를 문의에 사용할 때 개인정보 가리기
오류 로그는 서버가 남긴 오류 기록입니다.
호스팅 고객센터에 문제가 생긴 시각 전후의 기록을 확인해 달라고 요청하면 원인을 찾는 데 도움이 될 수 있습니다.
공개 사이트에 오류 문구를 표시하려고 인터넷의 디버깅 코드를 바로 붙여 넣지 않습니다.
추가 로그 수집이 필요하면 테스트 환경에서 담당자에게 설정을 요청하고, 기록 파일의 접근 제한과 작업 후 정리도 함께 확인합니다.
문의에는 오류 전후의 필요한 부분만 넣고 다음 정보는 가립니다.
- 관리자 아이디, 이메일, 방문자 IP와 개인 연락처
- 주문·회원·결제 등 개인 자료
- 서버 계정명이 포함된 전체 경로
- 비밀번호, DB 접속 정보, API 키, 인증 토큰과 복구 링크
오류 시각, 오류 종류, 플러그인 폴더명과 관련 파일·줄 번호처럼 진단에 필요한 단서는 남깁니다.
플러그인 경로가 로그에 나온다는 이유만으로 그 플러그인이 단독 원인이라고 단정하지 않습니다.
공개 게시판에 로그 파일 전체나 백업 파일을 첨부하지 않습니다.
원인 후보를 찾은 뒤 대체·문의·복구 선택하기
원인 후보를 찾으면 필요 없는 기능인지, 계속 써야 하는 기능인지 먼저 판단합니다.
계속 써야 한다면 제작자의 알려진 문제와 호환 안내를 확인한 뒤 다음 중 알맞은 방법을 선택합니다.
| 상황 | 다음 행동 |
|---|---|
| 수정 버전이나 해결 설정이 안내됨 | 백업 후 테스트 사이트에서 한 항목만 적용하고 재검증 |
| 꼭 필요한 기능인데 원인이 불명확함 | 재현 순서·버전·비활성화 전후 결과·가린 오류 기록으로 문의 |
| 다른 플러그인으로 교체하기로 함 | 설정과 저장 자료의 이전 가능성을 확인하고 테스트 후 교체 |
| 장애가 커서 정상 상태로 우선 복구해야 함 | 오류 전 백업과 보존할 최근 자료를 확인해 담당자와 복구 범위 결정 |
제작자에게는 “작동하지 않습니다”만 보내지 말고 어떤 순서에서 오류가 생기는지 설명합니다.
워드프레스·PHP·테마·관련 플러그인 버전, 최근 변경과 후보를 껐을 때의 차이를 함께 적습니다.
이전 버전으로 되돌릴 때는 신뢰할 수 있는 백업이나 제작자가 제공하는 파일을 사용합니다.
보안 문제가 있는 구버전을 장기간 사용하는 방식으로 끝내지 않습니다.
업데이트가 저장 자료를 바꾼 플러그인은 파일만 되돌려 해결되지 않을 수 있으므로 지원 안내를 확인합니다.
대체 플러그인을 설치하기 전에 기존 플러그인 자료를 내보낼 수 있는지, 삭제하면 자료가 지워지는지 확인합니다.
교체한 기능이 정상 작동하고 필요한 자료를 보관한 뒤에 삭제 여부를 결정합니다.
복원이 필요하다면 워드프레스 백업 파일로 복원하기 전에 확인할 것에서 복구 시점과 범위를 먼저 확인합니다.
전체 DB 복원은 백업 이후의 글·댓글·주문 등을 되돌릴 수 있으므로, 플러그인 하나의 오류라는 이유만으로 바로 전체 복원을 실행하지 않습니다.
해결 후 실제 사용하는 기능까지 확인하기
처음 오류가 났던 작업을 같은 조건으로 다시 확인합니다.
글 저장 문제였다면 임시글을 수정해 저장한 뒤 다시 열어 변경 내용이 남아 있는지 확인합니다.
로그아웃한 공개 화면에서도 글·이미지·메뉴와 관련 기능을 확인합니다.
모바일 화면이 깨지지 않는지 살펴보고, 진단 중 끈 필수 기능과 보호 기능을 필요한 상태로 복구합니다.
결제나 메일 기능은 제공되는 테스트 방식으로 결과까지 확인합니다.
정상 화면이 한 번 열린 것만으로 완료하지 말고, 바꾼 항목과 최종 상태를 메모해 같은 문제가 생겼을 때 참고합니다.
자주 묻는 질문
비활성화와 자동 업데이트 비활성화는 같은가요?
다릅니다.비활성화는 현재 플러그인의 작동을 멈추고, 자동 업데이트 비활성화는 새 버전의 자동 적용을 중지하는 설정입니다.
후자는 현재 활성 플러그인을 끄는 기능이 아닙니다.
최근 업데이트한 플러그인은 무조건 원인인가요?
최근 변경은 우선 확인할 단서입니다.
같은 조건의 비활성화 전후 결과와 다른 변경 사항을 함께 보아야 하며, 오류 시점만으로 특정 플러그인을 잘못된 제품으로 판단하지 않습니다.
비활성화 링크가 없으면 어떻게 하나요?
이미 꺼져 있는지, 계정 권한이 부족한지, 필수 사용 플러그인이나 네트워크에서 관리하는 항목인지 확인합니다.
서버 폴더를 바로 삭제하지 말고 사이트 관리자나 호스팅에 관리 방식을 문의합니다.
테스트 사이트에서는 정상인데 운영 사이트에서만 오류가 납니다
두 환경의 플러그인·테마·PHP 버전, 캐시, 저장 자료와 외부 연동이 같은지 비교합니다.
오류가 재현되지 않았다면 원인을 확인한 것으로 마무리하지 말고 차이가 있는 조건을 문의 자료에 적습니다.
마지막 확인 목록
- 처음 알아챈 시각, 문제 주소, 오류 문구와 재현 순서를 기록했습니다.
- 파일·DB 백업의 완료 여부와 원래 활성 목록을 확인했습니다.
- 브라우저·플러그인·호스팅 캐시의 영향을 구분했습니다.
- 최근 변경부터 확인하고 한 번에 한 플러그인만 비활성화했습니다.
- 변화가 없으면 원래 상태로 되돌린 뒤 다음 항목을 확인했습니다.
- 기능이 사라진 상태를 오류 해결로 판단하지 않았습니다.
- 재활성화 검증과 테마 전환은 안전한 테스트 환경에서 진행했습니다.
- 필수 사용·드롭인 파일을 임의로 삭제하지 않았습니다.
- 문의 자료에서 개인정보와 접속 정보를 가렸습니다.
- 해결 뒤 원래 작업, 공개·모바일 화면과 필수 기능을 확인했습니다.