HyolBrew 만들기 2/3
지난 글에서는 네이버와 별도로 HyolBrew를 만든 이유를 이야기했다. 나를 설명하는 글을 내 도메인에 쌓기로 했으니, 이제 블로그를 무엇으로 만들지 정해야 했다. 이 선택에서 생각보다 오래 맴돌았다.
가장 먼저 알아본 건 WordPress였다
처음에는 새 블로그가 검색 유입이나 수익으로도 이어질지 궁금했다. 그런 목적이라면 WordPress가 가장 합리적이라는 답이 많았고 나도 충분히 납득했다. 글을 발행하는 관리자 화면이 있고 SEO와 광고에 필요한 기능도 비교적 빨리 갖출 수 있다.
도메인은 어떤 걸 사야 하는지, WordPress를 집에 있는 NAS에 올려도 괜찮은지, 외부 호스팅을 쓴다면 비용은 얼마나 드는지 차례로 알아봤다. 내 NAS는 업데이트할 때를 빼면 거의 계속 켜져 있어 이미 있는 장비를 두고 굳이 외부 호스팅 비용을 내야 하나 싶었다. NAS에서 시작했다가 나중에 옮기더라도 처음부터 최종 도메인을 사용하면 주소는 그대로 유지됐다.
알아볼수록 질문은 더 생겼다. WordPress를 직접 운영하려면 PHP와 데이터베이스가 필요하고 코어와 테마, 플러그인 업데이트도 챙겨야 한다. 관리형 호스팅을 쓰면 손이 덜 가지만 비용과 제공 조건을 다시 비교해야 한다.
WordPress의 기능은 충분했다. 걸리는 건 글을 쓰려고 만든 공간에 서버 운영까지 얼마나 끌고 들어올지였다.
여기까지 알아봤을 때는 WordPress 쪽으로 마음이 기울어 있었다. 가장 중요한 조건 하나를 빼먹고 있었다.
나는 이미 Obsidian에서 글을 쓰고 있었다
평소에는 Obsidian에 메모를 남긴다. 짧게 적어둔 생각에 자료를 붙이고 관련 노트를 연결한 뒤 며칠 뒤 다시 읽으며 문장을 고친다. 일하면서 내린 판단이나 도구를 사용하며 느낀 점도 대부분 이곳에 쌓였다.
PKM이라고 부르지만 나에게 Obsidian은 정보를 모아두는 창고로 끝나지 않는다. 몇 줄 적어둔 메모에 자료를 붙이고 여러 번 고치다 보면 긴 글 한 편이 되기도 한다. 블로그를 만들면서 정작 이 습관을 조건에서 빼고 있었다.
Obsidian에서 오래 고민해 완성한 글을 WordPress 관리자 화면으로 옮긴 다음 블록과 이미지 형식을 다시 맞춰야 했다. 플러그인이나 API를 이용해 Obsidian을 원본으로 두는 방법도 있다. 대신 이미지 경로와 서식 변환, 인증, 동기화 상태를 관리하는 계층이 하나 더 생긴다. 새 블로그를 시작하면서 CMS 동기화까지 운영하고 싶지는 않았다.
블로그용 원고를 따로 관리하고 싶지도 않았다. 내가 원한 건 PKM에서 생각을 정리하고 문장을 다듬는 일이 포스팅으로 이어지는 흐름이었다. 최종본은 Obsidian에 남기고 공개하기로 정한 글만 발행용 파일로 꺼내는 구조를 원했다.
현재는 Obsidian 원고를 HyolBrew의 MDX 파일로 옮기는 수동 단계가 남아 있다. 위키링크와 이미지 경로를 정리하고 제목, 날짜, 설명 같은 발행 정보도 붙인다. 완전히 자동화된 구조는 아니지만 본문 형식은 계속 Markdown이고 블록 편집기에서 글을 다시 조립할 필요가 없다. 원고를 고치는 곳도 Obsidian으로 정해두었다.
무료 호스팅을 찾다가 방향이 달라졌다
비용을 줄일 방법을 찾다가 Cloudflare Pages와 정적 사이트 생성기를 알게 됐다. Markdown 파일로 사이트를 미리 빌드한 뒤 완성된 HTML을 배포하는 방식이다. WordPress를 위해 서버와 데이터베이스를 계속 운영할 필요가 없었고 개인 도메인 연결도 가능했다. 이미 쓰고 있던 Markdown을 Git으로 관리하고 결과물만 배포하면 된다는 점도 마음에 들었다.
요청할 때 만드는 페이지와 미리 만들어두는 페이지
WordPress와 Astro의 차이는 사용자가 글을 요청했을 때 더 선명해진다.
일반적인 WordPress 구성에서는 방문자의 요청이 웹서버로 들어오면 PHP가 WordPress 코어와 테마, 플러그인을 실행한다. MySQL이나 MariaDB에서 글과 설정을 읽어 HTML로 조립한 뒤 브라우저에 돌려준다. 캐시나 CDN을 잘 구성하면 이 과정의 상당 부분을 건너뛰지만 그 경우에도 PHP 런타임과 데이터베이스, 관리자 화면은 운영 구조 안에 남는다.
Astro를 정적 모드로 사용하면 이 작업의 시점이 앞당겨진다. 배포 전에 Markdown과 MDX를 읽어 HTML을 만들어두고 방문자에게는 이미 완성된 파일을 전달한다. HyolBrew의 글을 여는 요청 경로에는 PHP도 데이터베이스 조회도 없다.
정적 사이트에도 관리할 것은 남는다. Git 저장소와 배포 계정, npm 의존성은 여전히 관리 대상이다. 공개된 블로그의 요청 경로에서는 런타임이 줄고 WordPress 관리자 화면과 데이터베이스를 운영 스택에 둘 필요가 없어졌다. 내가 직접 책임질 범위도 그만큼 분명해졌다.
다음 후보는 Hugo와 Astro였다.
글을 빠르게 빌드하고 단순한 구조로 오래 운영한다면 Hugo도 충분해 보였다. 하지만 나는 블로그 디자인을 직접 손보고 싶었고 나중에는 비교표나 체크리스트, 간단한 계산기처럼 글을 보완하는 페이지도 만들어보고 싶었다. Codex 같은 도구와 함께 화면과 기능을 계속 수정하는 방식까지 생각한 뒤 Astro를 선택했다.
Astro에서 마음에 들었던 것
Astro는 Markdown과 MDX를 콘텐츠로 사용한다. 제목과 날짜, 설명, 태그를 프론트매터에 적고 본문은 평소처럼 Markdown으로 쓴다.
HyolBrew에서는 src/content/posts 아래의 .md와 .mdx 파일을 Content Collections로 불러온다. 이때 Zod 스키마로 발행용 프론트매터의 형태를 검사한다. 현재 사용 중인 스키마는 다음과 같다.
schema: z.object({
title: z.string(),
description: z.string(),
date: z.coerce.date(),
category: z.enum(['tech', 'gear', 'notes', 'coffee', 'matcha']),
tags: z.array(z.string()).default([]),
hero: z.string().optional(),
featured: z.boolean().default(false),
draft: z.boolean().default(false)
})날짜를 잘못 적거나 정해두지 않은 카테고리를 넣으면 빌드 단계에서 오류가 난다. 현재 빌드 명령도 astro check && astro build로 두었다. 먼저 타입과 콘텐츠 구조를 검사한 다음 정적 파일을 만든다.
글 페이지를 생성할 때는 getStaticPaths()가 공개할 글의 URL을 만들고 render(post)가 Markdown 본문과 헤딩을 HTML로 변환한다. 이때 얻은 헤딩 목록은 오른쪽 목차에 쓴다. 원고의 프론트매터도 글 목록과 태그, 관련 글, 대표 이미지 같은 화면 요소에 연결된다.
글과 화면 코드가 분리되는 점도 마음에 들었다. 콘텐츠는 Markdown으로 두고 글 목록과 본문, 카테고리, RSS 같은 화면은 컴포넌트로 만든다. 디자인을 바꿔도 원고를 다시 손댈 필요가 없다.
페이지 대부분을 정적 HTML로 만들고 JavaScript가 필요한 부분만 따로 추가하는 구조도 블로그와 잘 맞았다. Astro의 Islands architecture를 사용하면 상호작용이 필요한 컴포넌트만 브라우저에서 실행한다. HyolBrew에도 스크롤 진행률과 형광펜 애니메이션을 위한 작은 스크립트는 들어가지만 Markdown 본문을 읽는 데 전체 애플리케이션을 실행할 필요는 없다.
Astro를 택하면서 새로 맡게 된 일도 있다. 관리자 화면이 없어서 Git과 빌드, 배포 과정을 알아야 하고 문제가 생기면 직접 로그를 봐야 한다. Markdown 파일을 관리하고 변경 이력을 남기는 일은 이미 익숙했지만, 사이트를 고치는 재미에 빠져 글보다 CSS를 오래 들여다보는 날도 생긴다.
선택 기준은 발행 방식이었다
빠르게 글을 발행하고 광고와 플러그인을 활용하는 게 우선이었다면 WordPress를 선택했을 것이다. HyolBrew에서 먼저 해결하고 싶었던 건 PKM에서 오래 고민한 글을 다시 쓰지 않고 내 도메인에 꺼내놓는 일이었다. 그래서 Astro를 골랐다.
아직 Obsidian의 메모가 버튼 한 번에 발행되는 단계는 아니다. 공개할 문서를 고르고 링크와 이미지를 정리한 뒤 발행 정보와 빌드 결과를 확인한다. 이 과정까지 전부 없애고 싶지는 않아서 개인 메모가 공개 글로 바뀌는 마지막 검토는 남겨둘 생각이다.
다음 글에서는 Obsidian의 메모를 어떻게 초안으로 발전시키고 HyolBrew에 올리는지, 현재 사용 중인 발행 과정을 정리해보려고 한다.
참고한 공식 문서
