왜 필요한가
공개 사이트에 일관된 글이 많이 필요하지만 HTML 페이지 전체를 복사하면 공통 수정이 느리고 빠뜨리기 쉽습니다. 대부분 같은 내용을 읽는데 요청마다 서버를 실행하면 운영 일도 늘어납니다. 페이지를 반복 가능하게 준비하고, 필요한 상호작용만 별도로 더하는 발행 절차가 필요한 이유입니다.
어떻게 해결하는가
- 글 세 개와 공통 틀 하나로 시작합니다. 각 본문에 제목, 요약, 언어, 고정 식별자를 함께 둡니다. 그 데이터로 목록과 개별 글 주소를 만듭니다. 공통 헤더를 한 번 수정했을 때 모든 출력 페이지에 반영되는지 확인합니다. 페이지 수를 늘리기 전에 반복되는 작업을 한곳에서 관리할 수 있어야 합니다.
- 실제 발행 과정을 시험합니다. 문단을 수정하고 빌드한 뒤 출력물을 미리 봅니다. 깊은 주소로 직접 들어가 새로고침하고 이미지, 언어 링크, 없는 페이지도 확인합니다. 개발 서버에서 파일을 읽을 수 있다는 사실만으로 실제 호스팅 경로가 맞는다고 판단하면 안 됩니다. 마지막에 배포할 결과물을 기준으로 검사합니다.
- 발행 이후에 필요한 행동을 나눕니다. 메뉴나 로컬 필터는 브라우저 JavaScript로 동작할 수 있습니다. 개인별 저장 목록은 인증된 저장 경로나 적절한 서버 기능이 필요합니다. 미리 만든 공개 파일만으로 독자마다 다른 비공개 계정 상태를 보관할 수는 없습니다. 정적 본문과 개인 데이터의 책임을 분리합니다.
- 같은 샘플로 작성 비용을 비교합니다. Astro는 정적 콘텐츠에 필요한 대화형 영역을 더할 수 있고, Hugo는 콘텐츠와 템플릿에서 페이지를 생성하며, Jekyll은 Markdown·레이아웃과 Ruby 기반 작업 흐름을 사용합니다. 편집자의 기술, 다국어 요구와 빌드 환경을 확인합니다. 호스트의 지원 경로와 확장 기능은 실제 조건을 확인해야 합니다.
- 최신성과 복구도 정합니다. 정적 출력의 내용 변경에는 보통 새 빌드가 필요합니다. 원본 이력과 정상 동작한 결과물, 또는 되돌릴 수 있는 공개 절차를 남깁니다. 빌드 실패가 작동 중인 사이트를 불완전한 파일로 대체하지 않도록 발행을 멈추게 합니다. 누가 문제를 확인하고 다시 발행할지도 정합니다.
문서화한 절차로 새 글 하나를 추가하고, 로컬에서 검토한 뒤 운영용 출력의 예상 주소로 읽을 수 있는지 확인하면 좋은 완료 기준이 됩니다. JavaScript를 꺼도 핵심 본문을 읽을 수 있는지 시험합니다. 글 중심 화면의 읽기와 대화형 기능의 성공은 별도 항목입니다. 검색·저장 등 추가 기능도 각자의 결과를 확인해야 합니다.
Markdown↓ build
HTMLCSSJS
이 선택에 관한 이야기
세 언어가 댓글을 공유합니다. 작성하려면 GitHub 로그인이 필요합니다.