목차
Elementor를 업데이트한 직후 “사이트에 치명적인 오류가 있습니다”라는 안내가 뜨고 관리자 화면까지 열리지 않는다면, 먼저 접속을 복구하고 어떤 조합에서 오류가 발생하는지 확인해야 합니다. Pro를 껐을 때 화면이 열린다는 사실만으로 정확한 원인까지 밝혀진 것은 아닙니다. 정상 작동하는 버전 조합을 찾아 편집과 방문자 기능을 함께 점검해야 복구를 마칠 수 있습니다.
실제 사례: Pro 비활성화 후 관리자 접속을 복구했습니다
콩디 코딩이 진행한 실제 작업의 완료 메시지에는 Elementor 업데이트 후 치명적인 오류가 발생했고, wp-config.php 디버깅과 Pro 비활성화를 거쳐 관리자 화면에 들어간 과정이 기록되어 있습니다. 이후 Elementor와 Pro 사이의 충돌을 확인해 호환성을 조정했으며, 고객 채팅에서도 정상화 확인이 있었습니다.
작업 기록은 두 플러그인 사이의 호환성 문제를 설명합니다. 다만 전체 오류 로그와 수정 코드가 남아 있지 않아 특정 함수, 코드 한 줄, 정확한 버전 번호까지 공개적으로 재현할 수는 없습니다. 아래 절차는 확인된 복구 흐름을 바탕으로 공식 문서를 참고해 정리한 일반 점검 방법입니다.
같은 작업에서 로그인·회원가입·계정·예약 페이지를 캐시 대상에서 제외한 기록도 있습니다. 이는 별도의 캐시 설정 작업입니다. 캐시 제외가 치명적인 오류 자체를 고쳤다고 해석하지 않습니다.
1. 변경을 멈추고 백업과 오류 발생 시점을 확보합니다
무엇을 업데이트했는지 모른 채 테마, PHP, 여러 플러그인을 동시에 바꾸면 원인을 좁히기 어렵습니다. 다음 항목부터 기록합니다.
- 마지막으로 정상 작동한 시각과 오류가 처음 나타난 시각
- 직전에 변경한 Elementor·Pro·추가 애드온의 버전
- 홈, 특정 페이지, 관리자, 편집기 중 열리지 않는 범위
- 오류 전 백업의 생성 시점과 복원 가능한 항목
작업 전 현재 파일과 데이터베이스를 함께 보관하고, 가능한 경우 복제한 테스트 사이트에서 변경합니다. 기존 백업을 복원할 때는 백업 이후의 주문·회원·예약 데이터가 사라지는지 먼저 따져야 합니다. 장애 직전 상태를 되돌리는 일과 새 데이터를 보존하는 일은 함께 계획해야 합니다.
Elementor의 공식 업데이트 안내도 백업, 릴리스 문서와 애드온 호환성 확인, 스테이징 테스트를 권합니다.
2. 복구 모드 또는 의심 플러그인 격리로 접속을 되살립니다
먼저 사이트 관리자 이메일에 WordPress 복구 모드 안내가 왔는지 확인합니다. 해당 메일의 유효한 복구 링크로 접속할 수 있다면, 표시된 오류 정보와 관련 플러그인을 확인합니다. 메일이 없거나 링크가 만료되었다고 해서 플러그인을 모두 삭제할 필요는 없습니다.
관리자에 접근할 수 없는 경우에는 호스팅 파일 관리자나 SFTP로 의심 플러그인을 일시 격리할 수 있습니다. 실제 설치 경로와 폴더를 확인한 뒤에만 진행합니다. 다음은 설명용 경로 예시이며 당시 고객 서버의 경로가 아닙니다.
wp-content/plugins/elementor-pro/
→ wp-content/plugins/elementor-pro.disabled/변경 전 이름을 기록하고, 폴더를 바꾼 뒤 관리자 접속과 동일 오류의 발생 여부를 확인합니다. Pro 의존 위젯·폼·템플릿이 표시되지 않을 수 있으므로 이 상태를 작업 완료로 보지 않습니다. 복구 후에는 정상 폴더명과 플러그인 목록을 확인하고, 호환성 조치가 끝난 다음 활성화합니다. 경로나 영향을 판단하기 어렵다면 호스팅 지원에 해당 플러그인의 일시 비활성화를 요청합니다.
복구 메일과 폴더명 변경을 이용한 접근 복원은 Elementor 치명적 오류 공식 안내에서 확인할 수 있습니다.
3. 오류가 난 시각의 로그로 원인을 좁힙니다
호스팅의 PHP 오류 로그에서 같은 시각의 항목을 먼저 확인합니다. 오류 메시지, 발생 파일과 줄 번호, 호출 흐름을 묶어서 읽습니다. “치명적인 오류”라는 화면 문구만으로는 플러그인 호환성, 메모리 부족, 파일 누락을 구분할 수 없습니다.
| 로그에 보이는 단서 | 다음 확인 | 아직 단정할 수 없는 것 |
|---|---|---|
| 존재하지 않는 함수·메서드 호출 | 호출하는 플러그인과 기능을 제공하는 플러그인의 호환 버전 | 로그에 Elementor가 등장한다는 이유만으로 Pro 단독 결함이라고 확정할 수 없습니다. |
| 메모리 한도 초과 | 실제 메모리 한도, 요청별 사용량, 특정 플러그인의 과도한 처리 | 메모리 수치만 올리면 근본 원인이 사라진다고 볼 수 없습니다. |
| 필요한 파일을 열지 못함 | 업데이트 중단, 누락 파일, 경로와 읽기 권한 | 호환성 오류와 같은 해결책을 바로 적용할 수 없습니다. |
추가 로그가 필요하면 테스트 환경에서 WordPress 디버깅을 사용합니다. WP_DEBUG는 디버깅을, WP_DEBUG_LOG는 파일 기록을 제어하고, WP_DEBUG_DISPLAY를 false로 설정하면 화면 노출을 막을 수 있습니다. 기존 상수를 중복 선언하지 말고 PHP 불리언 값에 따옴표를 붙이지 않습니다.
화면에 오류를 숨기는 것과 로그 파일의 외부 접근을 막는 것은 별개입니다. 로그는 접근이 제한된 위치에 저장하고 개인정보·경로·토큰 등을 제거한 뒤 공유합니다. 진단 후 불필요한 기록을 중단하고 보관 정책에 따라 정리합니다. WordPress는 실서비스보다 로컬·스테이징에서의 디버깅을 권합니다. 설정 방식과 주의점은 WordPress 디버깅 공식 문서를 확인하세요.
4. Elementor와 Pro를 함께 확인해 호환 조합으로 복구합니다
현재 설치된 두 플러그인의 버전과 지원하는 WordPress·PHP 환경을 확인합니다. 한쪽만 바뀐 상태라면 공식 릴리스 안내와 애드온 요구 조건을 대조하고 테스트 환경에서 조합을 검증합니다. 이 사례의 확인되지 않은 과거 버전 번호를 현재 사이트에 그대로 적용하는 방식은 적절하지 않습니다.
2026년 11월 6일 확인한 공식 문서는 서로 다른 순서를 안내합니다. 2026년 10월 갱신된 일반 업데이트 안내는 두 제품을 갱신할 때 Pro부터 권하고, 2025년 12월 갱신된 Pro 업데이트 오류 문서는 무료 Elementor부터 안내합니다. 따라서 오류 메시지와 해당 릴리스의 요구 조건을 확인해 순서를 정하고, 불명확하면 공식 지원에 확인하는 편이 정확합니다.
예를 들어 “Pro가 더 새로운 Elementor를 요구한다”는 메시지가 실제로 보이면 무료 Elementor의 요구 버전 충족 여부를 확인합니다. 공식 오류 문서는 업데이트가 막힌 경우 Pro를 잠시 비활성화하고 무료 버전을 업데이트한 뒤 Pro를 업데이트·재활성화하는 절차를 제시합니다. 이 조건부 절차를 모든 치명적 오류에 동일하게 적용하지는 않습니다.
당장 정상 조합을 확보하기 어렵다면 백업을 확보한 상태에서 이전 정상 버전으로 임시 복구하는 방법도 있습니다. 관리자에 접근할 수 있을 때의 버전 복원 기능은 Elementor 공식 롤백 문서에서 확인할 수 있습니다. 롤백을 했다면 대상 버전과 사유를 남기고, 수정 버전 테스트와 재업데이트 일정을 정합니다. 오래된 버전에 무기한 고정하는 운영은 권하지 않습니다.
5. 접속, 편집, 방문자 기능을 나누어 검증합니다
아래는 복구 후 권하는 검수 목록입니다. 이 사례에서 모든 항목을 각각 시험했다는 뜻은 아니며, 기록상 확인되는 결과는 관리자 접근 복구와 호환성 조치, 고객의 정상화 확인입니다.
- 접속: 관리자 로그인, 홈과 문제가 있던 URL에서 같은 치명적 오류가 재발하지 않는지 확인합니다.
- 편집: Elementor 편집기를 열어 테스트 페이지를 저장하고 미리보기가 반영되는지 확인합니다.
- Pro 기능: 실제 사용하는 헤더·푸터 템플릿, 팝업, 폼을 확인합니다. 폼은 제출 성공 표시와 수신 결과를 따로 봅니다.
- 방문자 흐름: 로그인 전후와 모바일 화면에서 주요 버튼, 회원가입·계정·예약 같은 기능을 확인합니다.
- 로그: 같은 동작을 다시 실행한 시각에 동일한 오류가 새로 기록되지 않는지 확인합니다.
캐시를 비운 뒤에는 로그인하지 않은 새 창에서도 확인합니다. 운영 사이트에서 결제·예약 검수가 필요하면 실제 고객 데이터와 구분되는 테스트 방식부터 정합니다. 캐시 제외가 필요한 페이지는 사이트 기능에 따라 선택하고, 로그인 상태나 개인화된 응답이 공용 캐시에 섞이지 않는지 확인합니다.
재발 방지: 다음 업데이트를 준비할 기록을 남깁니다
완료 보고에는 문제 발생 조건, 변경 전후 버전, 수정한 설정, 정상화를 확인한 기능, 남은 제약을 적습니다. 다음 업데이트 전에는 백업 복구 가능 여부와 주요 기능 목록을 다시 확인합니다. 추가 애드온이 많다면 제품별 지원 상태와 변경 기록을 함께 관리해 충돌 범위를 빠르게 좁힐 수 있게 합니다.
이번 사례에서 얻을 수 있는 핵심은 관리자 접근을 먼저 확보한 뒤, 원인을 확인하고, 호환성 조치와 기능 검증까지 이어가는 순서입니다. 접속이 돌아온 순간부터 남은 기능을 확인하는 과정이 복구의 일부입니다.
오류가 시작된 시각, 직전에 변경한 항목, 열리지 않는 화면, 백업 여부를 정리하면 진단에 도움이 됩니다. 크몽에서 콩디 코딩 워드프레스 오류 해결 서비스 보기
백업과 복구 환경을 준비하려면 워드프레스 호스팅 선택 가이드도 참고하세요.
사례는 개인정보를 제외해 재구성했습니다. 공식 문서 확인일: 2026년 11월 6일.