최근 흥미로운 문제 하나를 발견했습니다. 저는 책 리뷰 전문 사이트에 워드프레스를 운영하고 있는데, 도메인에 변경 사항을 적용하기 전에는 반드시 테스트를 거쳐 모든 것이 정상적으로 작동하는지 확인하는 습관이 있습니다. 그중 하나가 바로 워드프레스 5.2부터 도입된 '사이트 건강 검사(Site Health)' 도구입니다. 이 도구는 현재 설정에서 발생한 치명적인 문제와 권장 조치 사항을 한눈에 보여줍니다.
이 기능 자체는 훌륭하지만, 5.4로 업데이트한 직후 갑자기 두 가지 '치명적인 오류'가 표시되며 도메인에 새로운 문제가 생긴 것처럼 보였습니다. 오류 내용은 "REST API에서 오류가 발생했습니다"와 "사이트에서 루프백 요청을 완료할 수 없습니다"였으며, 두 오류의 세부 정보는 모두 동일했습니다. 오류: cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received (http_request_failed). 이상하군요. 지금부터 디버깅 과정을 공유해 보겠습니다.
문제 상세 분석
'치명적인 문제'라는 표현은 다소 놀랍게 들립니다. 하지만 실제 영향을 파악하려면 잠재적 문제를 신중하게 살펴봐야 합니다. 기업들은 보안 문제로 이어질 수 있는 사안에 대해 너무 소홀했다는 비난을 받고 싶지 않아서 버그를 지나치게 엄격하게 처리하는 경향이 있기 때문입니다. 먼저 상태 보고서 화면을 살펴보겠습니다.
첫 번째 오류는 다음과 같습니다.
REST API에서 오류가 발생했습니다
REST API는 워드프레스와 다른 애플리케이션이 서버와 통신하는 방법 중 하나입니다. 대표적인 예가 블록 편집기 화면으로, 글과 페이지를 표시하고 저장할 때 이 기능에 의존합니다.
오류로 인해 REST API 요청이 실패했습니다.
오류: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)
두 번째 오류는 다음과 같습니다.
사이트에서 루프백 요청을 완료할 수 없습니다
루프백 요청은 예약된 이벤트를 실행하는 데 사용되며, 내장된 테마 및 플러그인 편집기가 코드 안정성을 검증하는 데에도 활용됩니다.
사이트로의 루프백 요청이 실패했습니다. 즉, 이 기능에 의존하는 기능들이 현재 정상적으로 작동하지 않을 수 있습니다.
오류: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)
첫 번째 오류 메시지는 REST API가 서버와 통신하는 '방법 중 하나'일 뿐이라는 점을 알려줍니다. 즉, 다른 통신 경로도 존재한다는 뜻입니다. 다만 이 오류가 실제로 각종 작업 수행 시 어떤 문제로 이어질 수 있는지는 명확하게 설명하지 않습니다.
특히 언급되는 것이 블록 편집기인데, 이는 워드프레스 5.0에서 도입된 새로운 구텐베르크(Gutenberg) 에디터입니다. 저는 이를 사용하지 않고 클래식 에디터(Classic Editor) 플러그인에 의존하고 있으므로, 애초에 이 오류는 큰 문제가 아닐 수 있습니다. 실제 기능 면에서도 언급된 기능 중 어느 것도 영향을 받지 않았습니다. 워드프레스는 여전히 모든 작업을 정상적으로 수행하고 있었습니다. 혹시 오탐(false positive)일까요?
두 번째 오류는 예약된 이벤트, 즉 백그라운드 업데이트나 야간 자동 작업 등에 관한 것입니다. 이런 작업이 설정되어 있지 않다면 역시 문제가 되지 않으며, 설정되어 있더라도 정상적으로 실행된다면 실질적인 영향은 없습니다. 오류 메시지에는 "정상적으로 작동하지 않는다"고 명시되어 있지만, 이는 결정적이고 정확한 진단이라고 보기 어렵습니다. 오히려 문제 해결을 더 어렵게 만드는 모호한 표현입니다.
문제의 원인 추적
이번에는 이 오류들이 실제 문제라고 가정해 보겠습니다. 핵심 질문은 "이 오류는 대체 어디서 비롯된 것인가?"입니다. 쉽지 않은 과정이며, 오류 메시지 자체에는 올바른 방향을 가리켜 주는 단서가 전혀 없습니다.
그래서 제가 선택한 방법은 기본값이 아닌 모든 구성 요소를 하나씩 수동으로 비활성화하고, 매번 건강 검사를 다시 실행하며 특정 요소가 원인인지 확인하는 것이었습니다. 다행히 여유롭게 테스트할 수 있는 환경이었지만, 실제 운영 환경이었다면 그 파급력은 상상하기 어렵습니다.
시간을 들여 사용 중인 모든 플러그인과 테마를 하나씩 시험해 봤지만, 어느 것도 결과에 영향을 주지 않았습니다. 워드프레스는 계속해서 같은 오류를 표시했습니다. 그래서 탐색 범위를 넓히기로 했습니다. 마침 저는 관리자 페이지에 대한 2차 접근 제어 수단으로 .htaccess 파일을 사용하고 있었는데, 여기에 기본 인증(Basic Authentication)과 몇 가지 유용한 설정이 포함되어 있었습니다. 놀랍게도 인증 부분을 제거하자 문제가 즉시 해결되었습니다. 더 이상 건강 검사 오류가 발생하지 않았습니다!
AuthType Basic
AuthName restricted
AuthUserFile /home/mastablasta/wp-admin/passwd
Require valid-user
결론적으로 워드프레스 사이트 건강 검사는 .htaccess 파일의 기본 인증 설정을 좋아하지 않는 것으로 보입니다. 이것이 검사 로직을 어떻게 방해하는지 정확한 메커니즘까지는 파악하지 못했지만, 굳이 알 필요도 없습니다. 첫째, 문제의 근본 원인을 이미 찾아냈고, 둘째, 이 오류가 제가 필요로 하는 기능에는 전혀 영향을 주지 않으므로 실질적인 문제가 아니기 때문입니다.
결론 및 정리
사이트 건강 검사의 이 문제는 내부적인 것임이 분명합니다. 워드프레스 5.4로 업데이트한 직후부터 나타나기 시작했으니까요. 물론 어딘가의 코드가 변경되었겠지만, 핵심 제품의 동작이 업데이트 직전과 갑자기 확연히 달라졌고 사이트의 다른 기능 요소들에는 큰 문제가 없다면, 원인은 해당 코어 업데이트에서 비롯되었을 가능성이 높습니다.
저는 이런 식으로 한눈에 사이트 문제를 진단할 수 있다는 아이디어 자체는 좋아합니다. 하지만 오탐과, 설령 짧았다 할지라도 오류 때문에 겪게 된 헛된 추적에는 만족하지 못합니다. 오류는 의미가 있어야 합니다. 오류가 나타나는 방식만으로 무엇이 잘못되었는지 짐작조차 할 수 없다면, 기술적 세부 정보를 보여주는 것 자체가 무의미합니다. cURL 오류 28과 .htaccess는 겉보기에 너무나 동떨어져 보이니까요.
비슷한 문제를 겪고 계시다면 사이트 구성을 먼저 살펴보고, .htaccess로 기본 인증을 사용하고 있는지 확인해 보시기 바랍니다. 아마 동일한 숨은 버그를 겪고 있을 가능성이 높습니다. 참고로 최신 워드프레스 버전에서는 이 문제가 개선된 사례도 있으니, 코어 업데이트 후 재테스트해 보는 것도 좋은 방법입니다. 여기서 마치겠습니다.