2026년 11월 9일, 내가 운영하는 storytus.com에 접속할 수 없었다. 오라클 클라우드 서버에 Hestia를 올려 운영하는 워드프레스다. 브라우저에는 ERR_TOO_MANY_REDIRECTS가 떴다. 주소가 계속 다른 곳으로 돌고 돌아, 정작 페이지는 열리지 않는 상태였다.
이번에는 브라우저 AI인 Aside에 점검을 맡겼다. 무엇을 고쳤는지도 중요하지만, 어디까지 직접 처리했고 어디서 내 손이 필요했는지를 함께 남겨두려 한다. AI가 서버에 들어가 모든 문제를 한 번에 해결한 이야기는 아니다.
접속 문제는 플러그인보다 앞단에 있었다
나는 앞서 Gemini의 제안에 따라 Blocksy Companion 폴더 이름을 blocksy-companion에서 blocksy-companion_off로 바꿔둔 상태였다. 하지만 Aside가 확인한 접속 문제는 같은 HTTPS 주소로 301 응답이 반복되는 리디렉션 루프였다. 플러그인부터 계속 만질 일은 아니었다.
Cloudflare 로그인은 내가 했다. 이후 AI가 설정을 살펴보니 SSL 모드가 Flexible이었다. 이를 Full (Strict)로 바꾼 뒤 홈페이지와 워드프레스 로그인 페이지에서 모두 정상 응답인 200을 확인했다. 기존 무료 요금제 안에서 바꾼 설정으로, 유료 업그레이드는 하지 않았다.
내 사이트에서 확인된 원인과 해결이었다는 점은 구분하고 싶다. 같은 오류 문구가 나온다고 모든 워드프레스가 같은 이유로 막히는 것은 아니다.
파일을 바꾸기 전에 백업부터 확인했다
접속을 복구한 뒤에는 테마와 플러그인을 살폈다. 파일에서 확인한 Blocksy 테마는 2.1.42, Companion은 2.1.61이었다. 공식 helper 관련 누락 로그도 있었지만, 그 로그 하나만으로 치명적인 오류라고 결론 내리지는 않았다.
추가 변경에 앞서 AI가 Hestia 전체 백업을 요청했다. 약 497MB의 백업이 완료됐고 웹 파일과 데이터베이스가 포함됐는지 확인한 다음 작업을 진행했다. 백업 버튼을 누른 것으로 끝내지 않고, 완료 여부와 들어 있는 항목까지 본 순서가 중요했다.
워드프레스에 로그인이 필요할 때도 내가 브라우저에서 직접 로그인했다. AI는 테마를 2.1.61로 업데이트하고, 바꿔둔 플러그인 폴더 이름을 원래대로 돌린 뒤 Companion을 활성화했다. 이미 켜져 있던 Companion 자동 업데이트에 맞춰 테마 자동 업데이트도 켰다. 두 버전이 앞으로 절대 어긋나지 않는다는 보장은 아니지만, 이번에는 업데이트 설정까지 함께 맞췄다.
캐시는 이름보다 서버 환경이 먼저였다
LiteSpeed Cache에는 경고가 남아 있었다. 내 서버는 Nginx와 Apache 조합이고, LSWS나 QUIC.cloud를 통한 페이지 캐시를 쓸 수 있는 상태가 아니었다. 플러그인이 설치돼 있다는 사실과 페이지 캐시가 실제로 작동한다는 것은 다른 이야기였다.
AI는 기존 LiteSpeed Cache 설정을 백업하고 플러그인은 삭제하지 않은 채 비활성화했다. 대신 무료 WP Super Cache 3.1.5를 설치해 Simple 방식으로 설정했다. 로그인한 사용자, 쿼리 문자열이 붙은 요청, 검색, 관리자와 API 요청은 캐시 대상에서 제외했다. 캐시 유효시간은 1,800초, 정리 주기는 600초로 두고 글이 바뀌면 캐시를 비우도록 했다.
수치도 확인했다. 같은 브라우저에서 비로그인 HTML 응답을 세 번씩 받아 비교하니, 변경 전 평균 약 1,060ms에서 캐시가 준비된 뒤 평균 약 256ms로 줄었다. 다만 이것은 이미지와 스크립트까지 모두 뜨는 전체 페이지 로딩 시간이 아니다. 모든 방문자가 늘 같은 속도를 얻는다는 뜻도 아니다. 이번 조건에서 HTML 응답이 빨라진 결과로 보는 것이 맞다.
초록색 표시 뒤에 남은 일도 있었다
Rank Math의 분석용 테이블이 누락된 문제는 플러그인의 공식 내장 재생성 기능으로 처리했다. 작업 완료 기록과 테이블 크기를 확인했다. 경고가 화면에서 사라졌는지만 본 것이 아니라, 처리 결과까지 점검한 셈이다.
사이트 건강 상태는 ‘양호’로 확인됐다. 그렇다고 할 일이 전부 없어진 것은 아니다. 오래된 PHP 8.2.16과 지속성 객체 캐시 관련 권장 사항은 남았다. 이번 점검에서 치명적인 문제로 분류되지는 않았지만, 별도로 검토할 항목이다.
사이트 건강 양호와 악성 코드 점검은 달랐다
점검 도중 방문자에게 사람 인증 화면이 나오고, 이어서 Windows 실행 창에 명령을 붙여넣으라는 안내가 뜬다는 사실을 확인했다. 정상적인 사람 인증 절차로 볼 수 없는 화면이었다. AI가 추가로 읽은 Cloudflare Worker 코드에는 외부 스크립트를 사이트에 덧붙이고, Windows 방문자를 골라 보여주며 자동화 도구를 피하는 동작이 있었다.
요청한 사이트의 Worker 연결을 해제한 뒤 익명 응답에서 해당 주입 코드가 사라졌는지 확인했다. 나는 그 명령을 실행하지 않았다. 다만 누가 Worker를 추가했는지는 이 작업에서 밝히지 못했고 계정 접근 권한 점검도 남았다. 앞서 나온 양호 판정은 워드프레스의 성능과 기본 환경 진단이지, 사이트 전체가 안전하다는 보증이 아니었다. AI가 처음 통과한 점검이 놓칠 수 있는 범위까지 드러난 사례였다.
나는 MobaXterm 터미널 연결도 제안했지만, AI 도구는 접근 제약 때문에 직접 제어할 수 없었다. 따라서 이번에 서버의 PHP를 패치하지는 않았다. 실제 작업은 웹 관리 화면에서 이뤄졌고 SSH로 서버에 접속한 것은 아니다. 일부 스크린샷 촬영도 시간 초과로 실패했다. 확인한 결과와 남길 수 있었던 화면 증거가 항상 같지는 않았다.
맡기되, 접속과 되돌릴 수단은 내 손에
이번에는 원인을 좁히고 설정을 바꾼 뒤 결과를 확인하는 일을 AI가 실제로 해냈다. 반면 계정 로그인은 내가 했고, 비밀번호를 채팅으로 보내지는 않았다. 서버 접근의 한계도 있었고, PHP처럼 손대지 못한 항목도 분명히 남았다.
내가 가져갈 기준은 간단하다. 변경 전에는 백업이 끝났는지 확인하고, 변경 후에는 실제 응답과 작동 상태를 본다. 로그인과 최종 판단, 되돌릴 수단은 내가 관리한다. 이번 한 번의 결과를 모든 AI의 능력으로 넓혀 말할 수는 없다. 다만 내 사이트에서는 막힌 접속을 풀고 관리 상태를 정리하는 데 도움이 됐다. 그 정도가 이번 경험에서 확인한 범위다.
