개발 서버에서 블로그가 열리면 컴퓨터 이전도 끝난 걸까요? 이번에 Windows에서 Mac으로 작업 환경을 옮기며 확인한 답은 아니었습니다. 내 컴퓨터에서 열리는 것, 독자에게 새 글이 보이는 것, 문제가 생겼을 때 이전 상태로 돌아가는 것은 서로 다른 확인이었습니다.
이 글은 2026년 10월 21일부터 22일까지의 실제 이관·게시 시험 기록을 정리한 글입니다. 사용자는 작업 방향과 실행 범위를 승인했고, 파일 대조와 실행·검사는 AI 에이전트 Aside가 수행했습니다. 사람이 모든 명령을 직접 실행한 경험담으로 바꾸어 쓰지 않았습니다. 인증 정보, 개인 경로와 내부 작업 식별자는 생략했습니다.
1. 로컬에서 열린다는 것은 개발 준비의 확인이다
첫 단계는 Mac에서 기존 블로그 소스와 필요한 이미지를 복원하고 개발 서버를 여는 일이었습니다. 글과 태그 페이지를 보고, 이미지 경로가 실제 파일과 맞는지 확인했습니다. 휴대전화 정도의 작은 화면에서도 본문과 그림이 가로로 넘치지 않는지 따로 봤습니다.
여기까지 확인해도 인터넷의 공개 블로그가 Mac에서 게시되는 것은 아닙니다. 로컬 주소는 내 컴퓨터의 결과이고, 공개 도메인은 별도 호스팅이 내보내는 결과이기 때문입니다. 실행 명령이 성공했다는 사실과 독자가 새 글을 읽을 수 있다는 사실을 한 문장으로 묶으면 중요한 단계가 빠집니다.
이번 이관에서도 원고 파일 수와 공개 글 수를 구분했습니다. 개발일지와 비공개 원고까지 소스 폴더에 있다고 해서 모두 공개 대상은 아닙니다. 원본을 보존하는 작업과 공개 사이트에 넣는 작업은 별개였습니다.
2. 게시 전에는 무엇을 올리는지 먼저 고정한다
공개 빌드에는 공개 대상 글과 그 글이 참조하는 자산만 넣었습니다. 로컬 도구, 비공개 개발일지, 인증 자료를 통째로 복사하지 않는 방식입니다. 검사가 끝난 뒤 파일이 바뀌었다면 같은 결과물이라고 부를 수 없으므로, 원본과 출력의 해시도 함께 대조했습니다.
이 과정에서 필요했던 질문은 세 가지였습니다.
- 이 원고는 정말 이 블로그에 공개할 글인가?
- 본문에서 참조한 이미지가 모두 있고, 공개해도 되는 자료인가?
- 실제로 올릴 결과물이 방금 확인한 결과물과 같은가?
다른 채널에 게시할 원고를 이 블로그의 공개 후보에 남겨 두지 않는 것도 이 단계의 일입니다. 게시 대상에서 빠졌다는 표시만 믿기보다, 현재 원고와 공개 출력의 차이를 확인하는 편이 분명했습니다.
3. 실제 게시와 복구는 별도로 시험했다
게시 기능은 개인정보가 없는 임시 글 한 건으로 시험했습니다. 공개 주소에서 본문이 보이는지 확인하고, 홈·글·태그·이미지·RSS·사이트맵·404를 포함한 고정 공개 경로 검사도 수행했습니다. 이후 별도로 승인된 절차를 거쳐 직전 운영 버전으로 돌아갔습니다.
첫 시험은 게시 뒤 HTML 전체 해시 검사에서 멈췄습니다. 로컬의 404 문서와 달리 공개 응답에는 Cloudflare의 스크립트가 추가돼 있었습니다. 실제 상태 코드와 제목은 맞았지만 응답 바이트가 같지는 않았습니다.
이를 게시 성공으로 덮지는 않았습니다. HTML에는 상태 코드·정확한 제목·문서 구조·필수 문구를 명시적으로 확인하는 검사를 마련했습니다. 이미지의 바이트 해시와 원본·배포 산출물의 해시 대조는 유지했습니다. 개선한 경로의 재시험에서는 정상 게시 완료와 일반 복구 절차가 각각 통과했습니다.
여기서 얻은 교훈은 해시 검사가 필요 없다는 것이 아닙니다. 그대로 같아야 하는 파일과 전달 과정에서 변환될 수 있는 응답을 구분하고, 검사 기준을 미리 정해야 한다는 것입니다.
4. 복구 검사가 통과해도 일반 주소를 다시 봐야 했다
재시험 뒤에는 더 까다로운 차이가 남았습니다. Pages 기본 주소와 새 쿼리를 붙인 사용자 도메인에서는 임시 글 경로가 404였지만, 원래의 일반 도메인 주소에서는 옛 시험 본문이 다시 나타났습니다. 홈·RSS·사이트맵에서는 그 글이 이미 빠진 상태였습니다.
2026년 10월 22일 15:19 KST의 후속 대조에서도 이 차이가 관측됐습니다. URL별·경로별·전체 도메인 캐시 제거가 접수됐어도 일반 주소의 잔류 본문이 해소되지 않았습니다. 원인을 특정 내부 캐시 계층이나 제품 결함으로 확정하지는 못했습니다.
따라서 15:19 KST의 기록에서 말할 수 있는 범위는 여기까지였습니다. Mac의 실제 게시와 이전 버전 복구 경로는 시험했지만, 당시에는 임시 글의 일반 공개 주소에서 본문이 완전히 사라졌다는 확인이 끝나지 않았습니다. 쿼리를 붙인 404 화면만으로 삭제 완료라고 보고한 표현도 후속 관측에 맞춰 바로잡아야 했습니다.
이는 새 글을 확인할 때도 적용할 기준입니다. 검사에 쓰는 주소와 독자가 링크를 눌러 여는 주소가 같은 결과를 내는지 확인해야 합니다. 상태 코드 하나나 한 번의 화면 관측만으로 전체 전달 경로를 정상이라고 결론 내릴 수는 없습니다.
다음 게시에서 사용할 확인 순서
이번 경험을 바탕으로 다음과 같이 단계를 나눴습니다.
- 원고 확인: 공개 목적지, 본문, 출처와 이미지의 공개 적합성을 확인합니다.
- 결과물 확인: 필요한 공개 파일만 빌드하고, 원본과 실제 배포할 파일을 결속합니다.
- 기준점 기록: 게시 직전의 운영 버전을 확인해 복구할 대상을 남깁니다.
- 실제 게시 확인: 일반 공개 URL에서 본문·이미지와 목록·피드를 확인합니다. 우회 주소의 결과는 별도로 표시합니다.
- 문제 발생 시 구분: 성공·실패·결과 미확정을 구분하고, 결과가 불명확한 게시를 무작정 반복하지 않습니다.
Windows 환경을 지우거나 한 번에 모든 운영을 넘기는 방식은 택하지 않았습니다. Mac이 수행하는 작업의 입력과 결과부터 책임지는 방향입니다. 이 범위의 확인을 다른 기기의 게시 통제나 완전한 무인 운영으로 확대하지 않습니다.
블로그 이전의 완료 기준은 새 컴퓨터에서 화면이 보이느냐보다 넓었습니다. 이번에 줄인 것은 단계를 섞어 말하는 일입니다. 개발 준비, 공개 게시, 복구, 일반 주소의 잔류 확인을 나누니 무엇을 해냈고 무엇이 아직 남았는지 더 분명해졌습니다.
함께 읽기
이 글은 특정 내부 캐시 원인을 확정하거나, AI의 완전 무인 운영·시간 절감·수익 효과를 입증하는 글이 아닙니다. 확인 시점 이후의 운영 상태는 달라질 수 있습니다.