정적 웹사이트가 무너지는 이유는 프레임워크를 잘못 골라서가 아니라, 두 번째나 세 번째 글이 올라갈 때까지 기본 운영 규칙이 계속 미정인 상태로 남아 있기 때문이다. 그 시점부터 canonical이 흔들리고, 피드가 빠지고, 인증 파일이 사라지고, 이미지 경로가 갈라지고, 배포 결과가 엇나가기 시작한다.

정적 사이트를 안정적으로 굴리고 싶다면 글 수가 늘기 전에 먼저 잠가야 하는 규칙이 있다. 이 글은 그 출발점으로 쓰는 첫 운영 체크리스트다.

1. 사이트 URL을 먼저 고정한다

canonical, RSS, sitemap, 인증 파일, 검색 등록은 전부 하나의 기준 URL에 의존한다. 이 값이 고정되지 않으면 검색용 메타와 피드가 전부 흔들린다.

기준은 단순하다. 블로그마다 하나의 실서비스 URL을 정하고, 두 번째 글을 올리기 전까지 설정 파일에 박아야 한다.

2. 배포 대상도 콘텐츠 시스템의 일부로 본다

정적 사이트 운영은 HTML 생성만으로 끝나지 않는다. 어떤 저장소로 배포하는지, 어떤 브랜치를 쓰는지, build command가 무엇인지, output directory가 어디인지도 운영 시스템의 일부다. 이게 고정되지 않으면 로컬에서는 되는데 원격에서는 다른 결과가 나오는 문제가 반복된다.

그래서 이 스튜디오는 블로그마다 배포 저장소와 빌드 명령을 따로 갖는다.

3. 글쓰기 작업장과 실제 블로그 폴더를 분리한다

초안 작성, 이미지 슬롯 확인, 미리보기 검증은 studio-post에서 끝내고, 완료 후에만 블로그 폴더로 넘기는 게 맞다. 그래야 발행 중 실수가 줄고, 블로그별 구조도 유지된다.

4. 이미지 규칙은 두 번째 글 전에 끝낸다

대표 이미지, 본문 이미지, public 경로, 압축, alt, locale-safe 규칙이 없으면 글이 늘수록 예외가 생긴다. 이미지 처리 규칙은 사람이 기억하는 게 아니라 시스템이 판단하도록 만드는 쪽이 맞다.

예를 들면 001은 기본 대표 이미지, .sel이 있으면 대표 우선, 본문 이미지는 명시된 슬롯 코드만 허용, 생성 경로는 예측 가능하게 고정하는 식이다. 이 정도까지는 초반에 규칙으로 못 박아야 한다.

5. sitemap과 RSS는 빌드에 포함시킨다

검색용 파일을 수동으로 관리하면 반드시 빠진다. RSS와 sitemap은 빌드 결과물이어야 하고, 생성되지 않으면 빌드가 실패해야 한다. 그래야 검색 위생이 규칙이 된다.

실무적으로는 /rss.xml, /ko/rss.xml, /sitemap.xml 중 하나라도 빠지면 빌드를 멈추는 식이 가장 안전하다. 나중에 손으로 보완하는 방식은 결국 누락으로 이어진다.

6. 인증 파일도 발행 루프 안에 넣는다

Google, Naver 같은 인증 파일은 외부 작업처럼 느껴지지만 실제로는 발행의 일부다. 저장소에 들어 있어야 하고, 사이트와 같이 배포되어야 하며, live URL에서 바로 확인돼야 한다.

7. 리뷰는 현재 글 수정에서 끝나면 안 된다

리뷰가 현재 글만 고치고 끝나면 시스템이 강해지지 않는다. 더 나은 방식은 글을 리뷰하고, 글을 수정하고, 다음 글부터 반복될 규칙을 메모리에 남기는 것이다. 그래야 정적 사이트가 그냥 페이지 묶음이 아니라 운영 시스템이 된다.

다음 행동

지금 정적 사이트를 세팅 중이라면 사이트 URL, 배포 대상, 이미지 규칙, 피드 규칙 네 가지부터 먼저 잠가라. 이 네 개만 고정해도 첫 몇 개 글에서 생기는 대부분의 흔들림을 줄일 수 있다.

그 다음 단계는 정적 웹사이트 운영 유닛에서 이어가면 된다. 규칙은 많을수록 좋은 게 아니라, 다음 실수를 줄일 만큼만 추가하는 게 맞다.