바이브코딩으로 블로그 구축하다 터진 대형 사고 5가지와 수습 기록

지금 확인할 것

• 사이트가 통째로 안 열리면 사고 1과 아래 표부터 본다. 서버·DNS·캐시 중 어디인지 먼저 갈린다.
• 글이나 이미지만 404면 사고 2·3으로 바로 간다. 슬러그와 파일 서빙 문제다.
• 백업 위치를 모르면 사고 1부터 읽는다. 남은 자료에 따라 복구 경로가 달라진다.

워드프레스 오류 해결 과정에서 내가 먼저 봐야 했던 것은 결제 상태, 글 주소, 실제 이미지 응답이었다. 이 글은 블로그를 만들고 운영하며 겪은 다섯 사고를 모은 기록이다.

이 글을 읽으면 사이트가 통째로 안 열릴 때, 글이나 이미지만 404가 뜰 때 어디부터 확인할지 알 수 있다. 사고 5개마다 증상, 원인, 내가 AI에게 물은 말, 복구, 재발 방지를 같은 순서로 정리했다. 위 상자에 나온 DNS와 캐시가 무엇인지는 사고 1과 마지막 정리에서 설명한다.

워드프레스 오류 해결을 사고 기록으로 쓴 이유

증상과 원인이 짝지어진 기록이 있으면, 같은 화면을 만난 사람이 자기 상황에 맞는 줄을 바로 찾을 수 있다.

클로드 코드(말로 요청하면 코드를 대신 써 주는 AI 도구)로 워드프레스 블로그 2개를 만들었고, 그 과정이 위키에 날짜별로 남아 있다. 전체 과정은 바이브코딩으로 워드프레스 블로그 만들기 허브에 있고, 이 글은 사고만 모았다.

다섯 사고를 증상 기준으로 정리하면 다음과 같다. 지금 보고 있는 화면과 같은 줄을 찾아 해당 사고로 가면 된다.

사고	독자가 보게 될 화면	원인	복구
1. 서버 삭제	접속 불가, 모르는 서버 기본 페이지	무료 체험 만료 방치	복구 서버의 DB·파일로 이전
2. 글 404	새 글 주소만 404	슬러그 관련 문제로 추정	영문 슬러그, 즉시
3. WebP 미적용	화면 정상, 이미지만 느림	서버가 원본을 내보냄	서빙 규칙 수정 후 응답 확인
4. 유지보수 화면	“예약한 유지보수” 안내 한 줄	업데이트 중 임시 파일	당시에는 업데이트 후 자동 정상화
5. 푸터 링크 소실	약관·개인정보 링크 사라짐	홈 교체 때 위젯이 비워짐	위젯 재생성

사고 1. 체험 만료로 서버가 삭제되고, 복구본을 옮긴 사고

증상. 2026년 8월 17일 사이트 점검 중 HTTPS 연결이 안 되는 것을 발견했다. HTTP에서는 내 블로그 대신 nginx 기본 페이지가 나왔다.

원인. 전날 Cloudways 무료 체험이 끝나며 서버가 삭제된 것으로 기록돼 있다. 기존 IP가 다른 사람에게 재할당됐다는 설명은 당시 응답을 보고 내린 추정이다. 정확한 장애 시작 시각은 남아 있지 않아 ‘2~3일 중단’이라는 기존 표현은 정정했다.

AI에게 무엇을 물었나. 호스팅을 비교하며 지금 구성에 블로그 세 개를 올릴 수 있는지 물었다. 그 점검에서 접속 장애를 발견했다. 상시 감시로 바로 알아낸 것은 아니었다.

복구. 호스팅사 백업은 있었지만 disaster recovery limit 오류가 났다. 새로 만들기로 결정한 직후 Cloudways 복구가 진행됐다. 다만 복구 서버의 도메인 연결은 정상으로 돌아오지 않아 그 서버를 이전 자료를 꺼내는 용도로 썼다.

그곳에서 DB 덤프 112KB와 캐시를 제외한 wp-content 압축 파일 27MB를 받아 Vultr 서울로 옮겼다. 새 서버의 DB 연결 설정과 호스팅 전용 캐시 구성을 정리하고 DNS·HTTPS를 연결했다. 이후 기록에는 글 6편, 테마·플러그인, 공개 URL, 사이트맵과 REST API 인증 확인이 남아 있다.

원고를 옵시디언에 두었기 때문에 다시 발행할 대안은 있었다. 하지만 실제 복원은 그 원고만으로 한 것이 아니다. 복구된 서버의 DB와 파일을 이용했다. 모든 DB 행을 전후 대조한 자료는 없어 전체 데이터의 무손실까지 보증하지 않는다.

재발 방지. 만료일을 기록하고 서버 자동 백업을 켰다. 원고 사본과 전체 사이트 백업의 역할도 구분했다. 남은 자료별 복구 판단과 실제 이전 확인 결과에 타임라인, 이전 후 502 오류까지 적었다.

사고 2. 한글 슬러그를 바꾼 뒤 글 404가 사라진 사고

사이트는 멀쩡한데 새로 쓴 글만 안 열린다면 주소부터 보면 된다. 두 번째 사고에서 글 2편의 주소가 404였다.

증상. 발행은 성공이라고 나왔는데 링크를 누르면 “페이지를 찾을 수 없습니다”가 떴다. 관리자 화면에는 글이 그대로 있었다.

seoin.dev 404 페이지 실제 화면 (2026-08-29)

원인으로 의심한 것. 슬러그는 도메인 뒤에 붙는 글 주소다. 당시 글 두 편의 한글 슬러그를 영문으로 바꾸자 정상 응답을 확인했다. 다만 어느 단계에서 주소가 잘리거나 연결이 실패했는지 밝힌 기록은 없다. 한글 주소가 원래 불가능하다는 결론으로 넓힐 수는 없다.

AI에게 무엇을 물었나. 404가 난 주소 2개를 붙여 넣고 “이 글 왜 404야”라고 물었다. 슬러그를 영문으로 바꿔 보자는 답이 왔고, 바꾸자마자 페이지가 정상으로 열렸다. 제목과 본문은 한글 그대로 뒀다.

복구. 발행 스크립트가 제목의 영문과 숫자만 뽑아 영문 슬러그를 만들도록 바꿨다. 파이프라인은 마크다운 한 파일이 글이 되기까지에서 다룬다.

재발 방지. 슬러그는 처음부터 영문으로 정한다. 공식 문서의 Pretty Permalinks 404 항목은 고유주소 설정을 다시 저장하라고 먼저 권한다. 내 경우에는 영문으로 바꾼 뒤 정상화한 것까지 확인했다. 이미 공개한 주소를 변경한다면 기존 주소에서 새 주소로 이동하는 리디렉션과 내부 링크도 함께 확인해야 한다.

사고 3. WebP 대신 1.9MB PNG가 나간 사고

이미지 최적화 플러그인이 켜져 있다는 것과 실제로 가벼운 이미지가 나간다는 것은 다른 문제다. 세 번째는 화면만 봐서는 안 보이는 사고였다.

증상. WebP(같은 이미지를 더 작은 용량으로 저장하는 형식) 변환 플러그인은 켜져 있었다. 그런데 대표 이미지 하나가 1.9MB짜리 원본 PNG 그대로 방문자에게 내려가고 있었다.

원인. Converter for Media 플러그인은 변환한 WebP를 uploads-webpc 폴더에 따로 만들어 둔다. 원본 이미지 주소로 요청이 오면 서버가 그 폴더의 WebP로 바꿔 내보내야 하는데, 그 규칙이 웹서버에 없었다. 플러그인은 할 일을 다 했고, 서버가 그 결과를 안 쓴 것이다.

AI에게 무엇을 물었나. “WebP 변환이 실제로 적용되는지 확인해 줘”라고 물었다. 클로드 코드가 서버에 직접 접속해 변환된 파일과 실제 응답을 대조했다. 관리자 설정 화면만 봤으면 못 찾았을 문제다.

복구. 브라우저가 WebP를 받을 수 있다고 알려 오면 WebP 폴더의 파일을 먼저 내보내라는 규칙을 웹서버 설정에 넣었다. 설정 변경은 운영자가 적용 범위를 확인하고, 웹서버 문법 검사 후 반영해야 한다. 당시 확인에서 같은 주소는 89KB WebP를 응답했고, WebP를 받지 않는 요청에는 원본 PNG를 응답했다.

재발 방지. 플러그인이 켜져 있다는 것과 실제로 WebP가 나간다는 것을 따로 확인한다. 브라우저 개발자 도구(웹페이지가 무엇을 주고받는지 보여 주는 브라우저 내장 화면)의 네트워크 탭에서 이미지 응답 형식을 보면 된다. 플러그인 구성은 플러그인은 4개면 충분했다에 있다.

같은 방식으로 서버가 저장해 둔 페이지를 내보내고 있는지도 확인할 수 있다. 아래는 그 확인 결과다.

서버에서 실제 실행한 캐시 확인 (2026-08-29)

사고 4. 자동 업데이트 중 유지보수 화면이 뜬 사고

아무것도 안 했는데 사이트가 유지보수 중이라고 나오면, 대개 몇십 초 뒤 저절로 돌아온다. 네 번째 사고를 읽으면 언제까지 기다리고 언제 손을 대야 하는지 알 수 있다.

증상. 방문자에게 “예약한 유지보수로 인해 잠시 사용할 수 없습니다”라는 안내 한 줄만 뜬다. 해킹이나 삭제와는 다르다. 업데이트가 진행 중이거나 중간에 멈춘 상태다.

내 경우는 2026년 8월 28일 아침이었다. 플러그인 자동 업데이트를 켜 둔 지 이틀 뒤, 목차 플러그인과 SEO 플러그인이 동시에 새 버전으로 올라가던 몇십 초 동안 이 화면이 떴다. 확인해 보니 임시 파일은 이미 지워져 있었고 사이트는 정상이었다.

2026년 8월 28일, 플러그인 자동 업데이트 중 실제로 뜬 화면

원인. 자동 업데이트가 시작되면 사이트 최상위 폴더에 .maintenance 파일이 생긴다. 업데이트가 정상으로 끝나면 파일이 저절로 지워진다. 안내 표시 여부는 파일 존재만으로 결정되지 않는다. 워드프레스 코어는 파일 안의 업데이트 시작 시각도 확인한다.

워드프레스 공식 FAQ에 적힌 동작이다. 아래는 그 문서 화면이다.

출처: WordPress.org Documentation, FAQ Troubleshooting (2026-08-28)

나는 8월 26일에 플러그인·테마 자동 업데이트를 전부 켰으니, 이 화면은 언제든 뜰 수 있는 구조다.

복구. 내 사례는 업데이트가 끝나며 자동으로 정상화됐다. 직접 파일을 삭제해 고친 사고는 아니다. 화면이 계속된다면 업데이트 상태와 오류 기록부터 확인한다. 코어의 유지보수 판단 코드에는 10분이 지난 시작 시각을 무시하는 조건이 있다. ‘1~2분이 지났으니 업데이트가 멈췄다’고 판단할 근거는 없다.

업데이트가 진행 중이지 않고 잔여 .maintenance 파일 때문에 막힌 것을 확인했다면, 현재 자료를 보존한 뒤 그 파일을 정리하고 실패한 업데이트를 다시 확인한다. 사이트 전체 폴더를 지우는 작업이 아니다.

서버 접근 방법은 워드프레스 설치 편의 SSH 설명을 참고할 수 있다. AI에게 요청할 때도 현재 업데이트 상태를 먼저 확인하도록 한다.

재발 방지. 그렇다고 자동 업데이트를 끄지는 않는다. 보안 패치를 놓치는 비용이 더 크다. 대신 유지보수 화면이 5분 넘게 이어지면 파일을 확인하는 규칙을 뒀다.

사고 5. 홈 개편으로 푸터 링크가 사라진 사고

디자인을 바꾼 뒤에는 화면이 예뻐졌는지만 보지 말고 링크가 살아 있는지 확인해야 한다. 다섯 번째 사고에서 필수 페이지로 가는 길이 통째로 끊겼다.

증상. 8월 26일 두 번째 블로그의 홈 레이아웃을 새로 만들었다. 이틀 뒤 일일 SEO 점검 스크립트가 이용약관과 개인정보처리방침을 고아 페이지라고 경고했다. 고아 페이지는 사이트 안 어느 페이지에서도 링크되지 않아 방문자가 찾아갈 길이 없는 페이지다.

원인. 홈 레이아웃을 교체하면서 푸터(모든 페이지 맨 아래 영역) 위젯이 비워졌다. 위젯은 푸터나 사이드바에 끼워 넣는 링크·글 상자 단위다. 페이지 자체는 살아 있었고 푸터 링크만 없어졌다.

첫 번째 블로그도 같은 날 공개한 문의 페이지가 고아 상태였다. 8월 18일에도 푸터 링크를 한 번 정리했으니, 푸터는 손댈 때마다 깨지는 자리였다.

AI에게 무엇을 물었나. 이번엔 내가 묻기 전에 일일 SEO 점검 스크립트가 먼저 잡았다. 스크립트의 고아 페이지 항목 덕분이다.

복구. 푸터에 개인정보처리방침·이용약관·소개 블록 위젯을 다시 만들었다. 첫 번째 블로그엔 ‘문의’ 링크를 추가했다. 두 사이트 모두 실제 화면에서 링크가 보이는지 확인했다.

재발 방지. 디자인 개편 후 체크리스트에 “푸터 링크 3종 확인”을 넣었다. 점검 루틴은 SEO 설정 순서에서 이어진다.

AI가 만들어 준 것과 내가 알아야 했던 것의 차이

자동 발행과 설치가 끝나도 운영 중 확인할 일은 남는다. 아래는 이번 사고에서 실제로 확인해야 했던 항목이다.

항목	AI가 만들어 준 것	내가 알아야 했던 것	사고
백업 위치	서버 세팅, 발행 스크립트	백업이 어디 있고 언제까지 복구되는지	1
DNS	도메인 연결 절차	내 도메인이 어느 IP를 가리키는지	1
슬러그	자동 발행	주소가 어떤 규칙으로 생기는지	2
캐시·서빙	플러그인, nginx 설정	브라우저가 실제로 무엇을 받는지	3
업데이트	자동 업데이트 ON	업데이트 중 임시 파일이 생기는 것	4
레이아웃	홈 디자인 mu-plugin	위젯을 바꾸면 푸터가 비는 것	5

표에 나온 캐시는 같은 페이지를 미리 저장해 두고 빠르게 내보내는 기능이다. 8월 26일에 이 페이지 캐시를 켠 뒤로는 디자인이나 기능 파일(CSS, PHP)을 직접 고쳐도 캐시를 비워야 화면에 반영된다.

백업은 워드프레스 공식 백업 문서 기준이 명확하다. 데이터베이스와 파일을 둘 다 받아야 복구된다. DB와 파일이 함께 든 백업 사본을 여러 시점과 저장 위치로 나누고, 복원 가능한지도 확인한다.

출처: WordPress Developer Resources, Backups (2026-08-28)

나는 서버 설정 파일(mu-plugins, 추가 CSS, nginx 설정)도 파일이 바뀐 이력을 저장해 두는 도구인 git에 스냅샷으로 남긴다. 글은 사고 1에서 말한 옵시디언, 설정은 git, 서버는 자동 백업이다.

설치를 맡겼더라도 백업이 남아 있는지, 방문자에게 무엇이 보이는지는 내가 확인해야 했다.

바이브코딩으로 블로그를 만드는 건 된다. 다만 백업 위치, DNS, 캐시, 슬러그 규칙 네 가지는 직접 알아 둬야 한다. 이 항목들이 점검의 출발점이 된다. 복구 시간은 원인과 남은 백업, 지원 상황에 따라 달라진다.

자주 묻는 질문

워드프레스 유지보수 화면이 안 사라진다면?

업데이트 진행 상태와 오류 기록부터 확인한다. 경과 시간만 보고 멈췄다고 단정하지 않는다. 진행 중인 업데이트가 없고 잔여 .maintenance 파일이 원인으로 확인됐을 때 정리한 뒤, 업데이트와 공개 화면을 다시 확인한다.

이미지만 404가 뜬다면?

미디어 라이브러리에 그 파일이 남아 있는지부터 본다. 파일이 있으면 캐시를 비우고, 없으면 다시 올려 대표 이미지를 재지정한다. 나도 같은 날 대표 이미지를 새 버전으로 바꾸고 옛 항목을 지웠다가 404를 만났다. 두 항목이 같은 파일명을 쓰고 있어서 옛 항목을 지울 때 새 파일까지 같이 지워진 것이다. 같은 이름의 미디어가 둘 있으면 지우기 전에 어느 쪽 파일이 남는지 확인하는 편이 안전하다.

서버가 갑자기 안 열린다면?

호스팅 결제·체험판 상태부터 본다. 그다음 도메인이 가리키는 IP, 서버 안의 웹서버 상태 순서로 확인한다. 내 경우에는 체험 만료를 발견한 뒤에도 백업 복구와 DNS·HTTPS 전환이 필요했다.

워드프레스 백업은 어디에 두나?

데이터베이스와 파일이 함께 든 백업을 서버 밖에도 보관한다. 내 원고 저장소와 설정 git은 보조 사본이다. 이 둘이 DB와 파일을 포함한 전체 백업을 대신하지는 않는다.

정리

• 만료일, 글 주소, 실제 이미지 응답, 업데이트 상태, 푸터 연결을 각각 확인했다
• 가장 큰 사고는 체험 만료 뒤 서버 삭제였다. 복구 서버의 DB와 파일을 꺼내 이전했다
• 직접 알아 둘 것은 백업 위치, DNS, 캐시, 슬러그 규칙 넷이다
• 오늘 5분 과제는 호스팅 화면에서 백업 여부와 마지막 백업 날짜를 확인하는 것이다

블로그를 만들다 겪은 다른 사고가 있으면 댓글로 알려 주세요. 다음 글에 보태겠다.

검증 기준

• 마지막 업데이트일: 2026-09-07
• 확인 환경: 8월 사고 기록과 공개 글을 대조했다. 서버 복구 경위·중단 시간·404 원인의 확정 범위를 정정하고, 유지보수 안내는 공식 코어 코드와 대조했다. 사고를 새로 재현하거나 전체 복원 시험을 한 것은 아니다.
• 주요 근거: WordPress 문제 해결 · WordPress 백업 안내 · 유지보수 판단 코드