기존 insightfrom.com에는 이미 회사 소개와 블로그 콘텐츠가 있다. 이 콘텐츠를 새 시스템으로 옮기는 대신, 앞으로 작성할 기술 운영 기록만 별도의 blog.insightfrom.com에 쌓기로 했다. 기존 자산의 URL과 배포 경로를 건드리지 않으면서 새 작성 흐름을 검증하기 위해서다.
이번 결정의 기준
새 블로그가 해결해야 할 문제는 화면을 하나 더 만드는 것이 아니었다.
- 매일의 작업 로그와 오류를 나중에 다시 찾을 수 있어야 한다.
- AI가 근거 없는 내용을 채우지 않도록 원본 작업 기록을 남겨야 한다.
- 초안 생성과 공개 권한을 분리해야 한다.
- 데이터베이스나 CMS를 먼저 운영하지 않아야 한다.
- 검색엔진이 canonical URL, sitemap, RSS를 안정적으로 읽을 수 있어야 한다.
이 조건에서는 Markdown을 Git으로 관리하고 정적 HTML을 만드는 방식이 가장 단순했다.
Gitea를 원본으로 삼는다
블로그 코드는 개인 계정이 아닌 InsightFrom/blog 조직 저장소에 둔다. 조직 자산과 개인 실험을 저장소 소유자 수준에서 구분하기 위해서다.
작업 흐름은 다음과 같다.
- 실제 작업 로그를 blogFlow 입력으로 사용한다.
- blogFlow가 제목, 설명, 카테고리, 태그와 본문이 포함된 Markdown 초안을 만든다.
- 초안은 별도 브랜치와 pull request에만 올라간다.
- 사람이 사실, 재현 가능성, 민감정보와 문체를 검수한다.
- 승인된 변경만
main에 병합한다. main에 병합되면 Gitea Actions가 정적 결과물을 빌드해 Cloudflare Pages에 업로드한다.
여기서 중요한 경계는 3번과 4번이다. 자동화는 검토 대기 상태까지 만들 수 있지만 공개 여부를 결정하지 않는다.
Astro와 정적 자산을 선택한 이유
Astro의 content collection은 Markdown frontmatter를 스키마로 검사할 수 있다. 제목이나 설명이 비었거나 카테고리가 허용 목록에 없으면 빌드 단계에서 실패한다. RSS와 sitemap도 같은 콘텐츠 목록에서 생성하므로 수동 목록이 어긋날 가능성을 줄일 수 있다.
Cloudflare 쪽에는 서버 코드 없이 dist 디렉터리만 올린다. 초기에는 DB, CMS, 이미지 저장소가 없다. 이미지 수가 실제로 늘어 로컬 Git 관리가 불편해질 때 R2 도입을 다시 판단한다.
검색 노출은 배포와 별도 작업이다
페이지가 인터넷에 공개됐다는 사실만으로 Google 인덱싱이 보장되지는 않는다. 이 블로그는 처음부터 다음 항목을 빌드 결과에서 검사한다.
- 모든 공개 HTML의 고유 canonical URL
index, followrobots 메타데이터- 절대 URL을 사용하는 sitemap
- 루트
robots.txt의 sitemap 선언 - RSS feed와 게시물 구조화 데이터
- 존재하지 않는 경로의 실제 404 응답
배포 후에는 Search Console의 Domain property를 확인하고 sitemap을 제출한다. 새 글은 URL 검사에서 live test를 통과한 뒤 필요한 경우 색인 생성을 요청한다.
다음에 측정할 것
이 프로젝트의 초기 목표는 blogFlow를 판매하는 것이 아니다. 먼저 직접 운영하면서 다음 지표를 쌓는다.
- 작업 기록에서 검수 가능한 초안까지 걸린 시간
- AI 초안에서 사람이 수정한 비율과 수정 이유
- 주간 발행 수와 연속 운영 일수
- Search Console의 노출, 클릭, 색인 제외 사유
- 글을 통해 들어온 문의와 제품 페이지 이동
기능을 더 만드는 판단은 이 기록이 생긴 뒤에 한다.