이 블로그에 글이 올라가는 과정

이 블로그에는 편집 화면도, 발행 버튼도 없습니다. 글 한 편은 우리 코드 저장소 안의 텍스트 파일 폴더 하나입니다. 그 폴더가 GitHub의 sieun/dev 브랜치에 올라가면 Vercel이 사이트를 다시 빌드하고, 글이 공개됩니다. 10월 1일부터 8일까지 프로덕션 빌드 156번의 소요 시간 중앙값은 65초였습니다.

이 블로그의 글은 대부분 에이전트가 씁니다. 사람은 채팅으로 글을 요청하고, 미리보기를 읽고, 승인합니다. git 명령은 에이전트가 실행합니다. 사람은 터미널을 열 일이 없지만, 모든 페이지를 공개하는 것은 여전히 git push입니다.

글 한 편을 올리는 단계

새 글 한 편이 거치는 전체 경로와 각 단계를 누가 맡는지입니다. 여덟 단계 중 사람이 하는 일은 세 단계이고, 승인은 다른 에이전트가 맡을 수도 있습니다.

이 흐름에서 가장 많은 일을 하는 것은 draft 플래그입니다. draft: true인 파일도 페이지로 렌더링되므로, 미리보기는 실제 레이아웃을 갖춘 실제 페이지입니다. 다만 홈, 컬렉션 허브, 사이트맵, 피드에는 나오지 않고 noindex 태그가 붙습니다. 검토자는 글을 공개하는 커밋에서 이 플래그를 바꿉니다.

언어 전환도 사람이 신경 쓸 일이 없습니다. 언어별 파일이 있고 draft가 아니면 그 언어가 공개됩니다. 이 규칙 하나가 언어 메뉴, hreflang 링크, 사이트맵을 모두 결정합니다. 나중에 일본어를 추가하는 일은 ja.md를 넣는 것이 전부입니다.

폴더 안에 있는 것

이 글도 폴더 하나입니다. 필요한 것은 모두 그 안에 있습니다.

apps/blog/content/how-virev-blog-works/
├── en.md
├── ko.md
├── ja.md
├── components/
│   ├── PostingFlow.svelte
│   └── BuildTimes.svelte
└── data/
    └── builds.csv

위의 단계 그림은 이 페이지만을 위해 만든 PostingFlow.svelte입니다. 세 언어 파일이 각자 이 컴포넌트를 불러와 자기 언어의 문구를 넘깁니다. 다른 글은 이 컴포넌트를 불러오지 않고, 이것을 추가하려고 공용 템플릿을 고칠 필요도 없었습니다.

아래 차트가 두 번째 컴포넌트입니다. Vercel API에서 가져온 156행짜리 data/builds.csv를 읽습니다. 숫자는 사이트를 빌드할 때 파싱되므로, 차트는 글을 공개한 커밋에 들어 있던 데이터를 보여 줍니다.

빌드에 걸리는 시간

빌드의 절반은 61초에서 71초 사이에 끝났습니다. 가장 오래 걸린 빌드는 169초였습니다. 사이트를 매번 처음부터 다시 만들기 때문에, 빌드마다 영어 글 345편과 한국어판 14편, 일본어판 12편을 초안까지 포함해 모두 렌더링합니다.

기다리는 시간이 빌드만은 아닙니다. 블로그는 sieun/dev 브랜치를 다른 코드와 함께 쓰고, 이 브랜치에 푸시가 들어오면 무엇을 바꿨든 블로그 빌드가 시작됩니다. 측정한 한 주 동안 156번 중 113번은 가장 최근 커밋이 블로그를 건드리지 않은 푸시에서 시작됐습니다. 그 밖에 170번은 대기열에 있는 동안 취소되고, 더 새로운 빌드가 그 자리를 대신했습니다.

글도 브랜치를 기다립니다. 10월 5일에는 글 커밋 세 건이 커밋 후 1.2분에서 1.5분 만에 공개됐습니다. 10월 7일과 8일에는 글 묶음 두 개가 커밋된 뒤 4.4시간, 5.6시간 동안 푸시되지 못했습니다. 다른 변경이 검사를 통과할 때까지 공유 브랜치로의 푸시가 멈춰 있었기 때문입니다.

다른 블로그 시스템에서는 같은 글을 어떻게 올리나

직접 만든 인터랙티브 차트가 하나 들어간 글 한 편을 기준으로, 시스템마다 글을 쓰는 사람에게 무엇을 요구하는지 비교했습니다.

앞의 네 가지는 콘텐츠 관리 시스템입니다. 로그인해서 버튼을 누르면 빌드 없이 바로 공개됩니다. 어려운 부분은 직접 만든 코드입니다. WordPress.com에서는 Custom HTML 블록의 스크립트가 플러그인을 쓸 수 있는 요금제에서 호스팅 기능을 켰을 때만 실행됩니다. Ghost는 HTML 카드와 글마다 있는 코드 삽입 칸으로 직접 만든 코드를 받습니다. 그래서 차트 코드는 코드 저장소 밖, 글 안에 저장됩니다. Substack은 글 편집기에서 직접 작성한 HTML, CSS, iframe 코드를 지원하지 않습니다. Notion은 Iframely를 통해 1,900개가 넘는 사이트의 콘텐츠를 임베드하므로, 차트는 Notion이 임베드할 수 있는 사이트에 따로 있어야 합니다.

뒤의 두 가지는 글을 git 안의 파일로 관리합니다. Astro와 Next.js 모두 MDX 파일에서 컴포넌트를 불러올 수 있고, 우리 블로그는 MDX의 Svelte판인 mdsvex로 같은 일을 합니다. 차트는 저장소 안의 평범한 코드입니다. 컴파일이나 렌더링에 실패하는 컴포넌트는 빌드를 실패시키므로, 독자가 보기 전에 걸러집니다. 대가는 빌드 시간과 git을 다룰 사람입니다.

우리 블로그는 git 쪽에 속합니다. git 작업은 에이전트가 맡으니, 사람에게는 콘텐츠 관리 시스템과 같은 단계만 남습니다. 요청하고, 읽고, 승인하는 것입니다.

글 한 편에 넣을 수 있는 것

폴더에는 어떤 Svelte 컴포넌트든 넣을 수 있습니다. 그래서 사이트를 고치지 않고도 글마다 자기만의 애니메이션, 인터랙션, 레이아웃을 가질 수 있습니다. 이와 함께 모든 글이 공용 블록을 쓸 수 있습니다.

• Chart는 ECharts 차트를 그리고, 자바스크립트 없이 보는 독자, 크롤러, 스크린 리더를 위해 같은 행을 담은 HTML 표를 함께 둡니다.
• Callout, Figure, Sidenote는 덧붙이는 글, 캡션이 있는 이미지, 여백 메모를 맡습니다. 마크다운 각주는 빌드할 때 여백 메모가 됩니다.
• Embed는 한 번만 쓸 HTML 조각을 샌드박스 프레임 안에 넣습니다.
• import rows from './data/file.csv'로 컴포넌트에 CSV 파일의 행을 넘깁니다.
• 폴더 안의 style.css는 모든 선택자가 .article-<slug>로 시작하면 그 글에만 적용됩니다.

한계도 같은 설계에서 나옵니다. 단어 하나를 고쳐도 새 글과 같은 길을 갑니다. 커밋, 푸시, 전체 빌드입니다. 예약 발행은 없습니다. 날짜에 맞춰 draft를 바꿔 주는 장치가 없기 때문입니다. 새 컴포넌트도 빌드를 통과해야 독자에게 닿습니다.

문제가 생겼을 때

글이 깨지면 빌드가 실패하고, 실패한 빌드는 공개되지 않습니다. 이전 빌드가 그대로 공개된 채로 남고, 빌드 로그에 문제의 파일이 나옵니다. 10월 1일에 프로덕션 빌드 두 번이 실패했고, 독자는 그 전 빌드를 계속 봤습니다.

공개한 글을 내리거나 변경을 되돌리는 방법은 두 가지입니다.

1. sieun/dev에서 커밋을 revert하고 푸시합니다. 다음 빌드에는 그 변경이 없습니다.
2. Vercel 대시보드에서 이전 배포를 프로덕션으로 올립니다. 커밋 없이 바로 적용됩니다. 그 뒤에 커밋을 revert해서 저장소와 공개된 사이트를 맞춥니다.