왜 이제야 직접 만드는가
글을 쓸 곳은 이미 많다. 네이버 블로그, 브런치, Medium, velog까지 선택지는 넘친다. 그런데도 직접 만들기로 한 이유는 단순하다. 콘텐츠의 원장(원본 저장소)을 내 도메인에 두고 싶어서다. 플랫폼은 언제든 정책을 바꾼다. URL이 바뀌고, 표시 방식이 바뀌고, 서비스가 닫힌다. 내 글의 정본이 남의 서버에 있으면 그 변경을 그대로 떠안는다.
정적 사이트 생성기로 만든 블로그는 다르다. 글은 마크다운 파일이고, 저장소는 내 GitHub에 있고, 배포는 정적 파일이다. 어느 한 서비스가 사라져도 파일은 남는다.
스택을 고른 기준
후보를 좁히는 기준은 세 가지였다.
| 기준 | 질문 |
|---|---|
| 콘텐츠 접근성 | 자바스크립트 없이 본문이 보이는가 |
| 이미지 처리 | 커버 이미지를 크기별로 만들어 주는가 |
| 유지 부담 | 플러그인 생태계가 살아 있는가 |
Gatsby 5는 세 가지를 모두 통과했다. 빌드 시점에 HTML이 완성되므로 크롤러와 사람에게 같은 페이지가 나가고, gatsby-plugin-image 계열이 이미지 파이프라인을 맡는다. React 생태계라 컴포넌트 재사용도 자연스럽다.
배포는 Netlify로 정했다. GitHub 비공개 저장소를 연결해 푸시마다 빌드하고, Pull Request마다 미리보기 배포를 만들어 준다. 서버를 직접 관리할 일이 없다는 점이 개인 프로젝트에선 크다.
처음에 정한 것들
- 글 주소: 날짜가 박힌 주소 대신
/blog/글-슬러그/형태를 쓴다. 글을 갱신해도 주소가 낡지 않는다. - 콘텐츠 저장: 글 하나가 디렉터리 하나다. 마크다운과 이미지를 같은 폴더에 둔다.
- 댓글: 공개 사이트가 비공개 댓글 저장소를 직접 건드리는 구조는 피한다. 서버 측 함수만 저장소에 접근한다.
이 시리즈는 그 결정들을 하나씩 구현한 기록이다. 다음 편은 댓글 구조 설계다.
지금까지 배운 것
직접 만드는 일의 비용은 세팅 시간이 아니라 판단의 양이다. 플러그인마다 유지보수 상태를 확인해야 하고, 디자인과 접근성을 내가 책임져야 한다. 그 시간이 이 블로그의 주제이기도 하다.

댓글
GitHub 계정으로 로그인해 댓글을 남길 수 있습니다. 댓글은 kese-comments 저장소 이슈로 공개 저장됩니다.