블로그 배포 그다음

글을 저장하고 커밋 버튼을 눌렀는데 몇 분이 지나도 사이트가 그대로라면, 그제야 블로그 배포가 글쓰기와는 완전히 다른 단계라는 걸 깨닫게 됩니다. 화면 안에서 다 완성된 것처럼 보여도, 그걸 남들이 볼 수 있게 인터넷에 올리는 과정이 따로 있고, 올렸다고 검색에 뜨는 것도 아니며, 뜬 다음에도 계속 굴러가게 관리하는 일이 남습니다. 이 글은 이 사이트를 실제로 운영하면서 이 세 단계에서 부딪힌 것들을 정리한 기록입니다. 2026년 9월 6일에 확인 지점을 표 두 개로 옮겨 적었습니다. 겪은 일 자체는 처음 쓴 그대로입니다.

---

코드를 원격 저장소에 보내면 배포가 시작되는 구조

파일만 컴퓨터 안에 있으면 아무도 볼 수 없습니다. 이 사이트는 코드를 GitHub라는 곳에 저장해두고, Vercel이라는 서비스가 그 저장소를 계속 지켜보다가 새 내용이 올라오면 자동으로 사이트를 다시 만들어 인터넷에 올리는 구조를 씁니다. 지금은 이 저장소에 블로그 말고 다른 것도 함께 들어 있어서, 블로그 폴더가 바뀐 경우에만 다시 만들도록 해뒀습니다.

정리하면 이렇습니다.

• 글을 저장하고, 변경 묶음을 내 컴퓨터에 기록합니다(커밋). 이 단계만으로 GitHub나 공개 사이트가 바뀌지는 않습니다.
• 확인을 마친 커밋을 GitHub의 배포용 브랜치로 보냅니다(푸시).
• 저장소와 연결된 서비스가 이걸 감지하고, 사이트 전체를 처음부터 다시 만듭니다(빌드).
• 다 만들어지면 자동으로 지금 보이는 주소로 바뀝니다.

이 자동화 덕분에 “새 글을 올린다”는 게 파일을 서버에 직접 옮기는 일이 아니라, 확인한 코드를 원격 저장소에 보내는 일이 됩니다. 다만 주소 이야기는 따로입니다. 서비스가 기본으로 내주는 주소 말고 우리만의 주소(이 사이트는 www.easy-welfare.com)를 쓰려면, 도메인을 사서 그 서비스에 연결해주는 작업을 한 번 더 해야 합니다. 사이트가 뜨는 것과 원하는 주소로 뜨는 것은 별개의 설정입니다.

---

로컬에서 통과했다고 인터넷에서도 통과하는 게 아니다

여기서 가장 크게 부딪힌 지점을 짚어야 합니다. 내 컴퓨터에서 문제없이 열리는 것과, 인터넷에 올라간 뒤에도 문제없이 열리는 것은 다릅니다.

이 사이트를 만들면서 실제로 배포가 다섯 번 연속 실패한 적이 있습니다. 2주 넘게 이어진 일이었는데, 원인은 원고 파일 하나가 윈도우에서 만들어지는 과정에서 인터넷 환경(리눅스 기반 서버)이 제대로 못 읽는 특수한 파일 형식으로 저장된 것이었습니다. 제 컴퓨터에서는 전혀 문제가 없어 보였기 때문에, 몇 번을 다시 고쳐 올려도 왜 계속 실패하는지 한참을 헤맸습니다.

이 경험에서 남은 교훈은 하나입니다. 로컬에서 미리보기 화면이 잘 뜬다고 안심하면 안 됩니다. 저장하고 올린 뒤에는 실제로 인터넷에 반영됐는지, 배포 서비스가 “성공”이라고 표시하는지까지 확인하는 습관이 필요합니다. 저장했다고 끝이 아니라, 저장한 게 실제로 인터넷에 도착했는지 한 번 더 보는 것이 배포의 마지막 단계입니다.

같은 것을 확인해도 보는 자리가 다릅니다.

왼쪽 칸만 보고 끝내서 2주 넘게 헤맸습니다.

---

검색에 뜨게 하려면 따로 챙겨야 하는 것들

구글은 다른 페이지의 링크를 따라 사이트를 발견할 수 있어서 별도 등록이 검색 노출의 필수조건은 아닙니다. 다만 새 사이트나 연결이 적은 글은 발견을 돕고 상태를 확인하는 작업이 필요합니다. 사이트맵 제출은 그 방법 중 하나이며 색인이나 검색 노출을 보장하지 않습니다. Google의 사이트맵 안내를 2026년 9월 26일 확인했습니다.

챙길 것은 셋인데요.

세 번째는 직접 겪었습니다. 이 사이트도 운영하면서 글 7편을 정리하며 지운 적이 있는데, 그 주소로 이미 검색에 걸려 있던 게 있어서 옛 주소를 그대로 살려두고 새 위치로 자동 연결해뒀습니다. 이 세 가지는 검색엔진의 발견과 독자의 이동을 돕습니다. 실제 색인 여부와 검색 노출은 서치콘솔에서 따로 확인합니다.

---

글이 늘어날수록 구조를 다시 짜야 한다

사이트를 처음 만들 때 정한 구조가 끝까지 가는 경우는 드뭅니다. 이 사이트도 글이 늘어나면서 주제를 나누는 탭 구성을 여러 차례 다시 짰습니다. 처음엔 맞던 분류가 글 수가 늘면 한쪽만 너무 커지고, 결국 다시 쪼개고 이름을 바꾸는 작업이 필요해집니다.

이런 개편은 한 번에 끝나지 않고 계속 반복됩니다. 그래서 지금 무엇을 했고 다음에 무엇을 할지를 문서에 남겨두는 습관이 중요해집니다. 문서에 남기지 않으면 다음에 다시 손댈 때 왜 이렇게 만들었는지, 어디까지 끝냈는지 처음부터 다시 파악해야 합니다.

그리고 글을 AI가 쓰더라도 검수는 사람의 몫으로 남습니다. 초안을 빠르게 만드는 건 AI가 도와주지만, 실제로 맞는 내용인지, 현장 감각에 맞는지 확인하는 건 결국 사람이 읽고 판단해야 하는 일입니다.

---

만드는 것보다 유지하는 게 더 오래간다

솔직히 말하면, 사이트를 처음 만드는 일보다 계속 유지하는 일이 훨씬 오래 걸리고 훨씬 지치는 일입니다. 배포는 한 번 구조를 잡아두면 그다음부턴 저장만 하면 되지만, 글은 누가 대신 계속 써주지 않습니다.

글을 계속 쓰지 않으면 사이트는 서서히 죽습니다. 검색 노출도 줄고, 찾아오는 사람도 줄어듭니다. 개인 블로그 운영에서 진짜 어려운 부분은 처음 만드는 기술적인 단계가 아니라, 만든 다음에도 계속 손을 놓지 않는 것이었습니다.

---

다음 단계

이 사이트를 왜, 어떻게 직접 만들기로 했는지는 코딩 없이 블로그를 만든 이유에서, AI에게 실제로 어떻게 지시했는지는 AI에게 어떻게 지시했는지에서 확인할 수 있습니다.

---

자주 묻는 질문

사이트 지도(사이트맵)는 꼭 구글 서치콘솔에 제출해야 하나요?

필수는 아닙니다. 페이지들이 링크로 잘 이어져 있다면 구글이 링크를 따라 발견할 수 있습니다. 사이트맵은 URL 발견을 돕지만, 제출해도 모든 글이 색인되거나 더 빨리 노출된다고 보장되지는 않습니다.

블로그 주소를 바꾸거나 글을 지우면 검색 순위가 떨어지나요?

옛 주소를 그냥 없애버리면 그 주소에 쌓여 있던 검색 노출이 사라질 수 있습니다. 옛 주소에서 새 주소로 자동 연결해주는 리다이렉트 설정을 해두면, 독자가 새 위치로 이동할 수 있고 검색엔진에도 이전 사실을 알립니다. 기존 순위나 노출이 그대로 유지된다는 보장은 없으므로 이전 뒤 색인·검색 상태를 확인합니다.

개인 블로그 운영은 얼마나 자주 글을 써야 유지되나요?

정해진 기준은 없습니다. 다만 이 글에서 확인했듯, 배포 구조를 아무리 잘 만들어도 새 글이 멈추면 사이트는 서서히 정체됩니다. 유지 관리에서 손이 가장 많이 가는 일은 배포 설정이 아니라 새 글을 쓰는 일입니다.