Canonical URL: https://blog.1001020.xyz/

Suggested cover image: https://blog.1001020.xyz/gallery에서 최근 이미지를 사용하세요.

저는 Cloudflare Workers에서 실행되는 서버리스 블로그이자 AI 갤러리인 1001020이라는 작은 퍼블리싱 시스템을 구축해 왔습니다.

라이브 사이트는 여기에서 확인할 수 있습니다: 1001020 — AI Gallery & Cloudflare Experiments

목표는 또 다른 정적 블로그 생성기(static blog generator)를 만드는 것이 아니었습니다. 저는 기사를 게시하고, 이미지 갤러리를 제공하며, 업로드된 에셋을 관리하고, 구조화된 사이트맵(sitemaps)을 노출하며, 전통적인 서버 없이도 운영될 수 있는 무언가를 원했습니다.

기본 아키텍처 (The basic architecture)

전체 공개 사이트는 Cloudflare Workers에서 실행됩니다. 기사, 설정, 댓글, 갤러리 메타데이터 및 텔레메트리(telemetry)는 Cloudflare KV에 저장됩니다. 관리되는 이미지는 R2에 저장되며 전용 이미지 도메인을 통해 제공됩니다.

주요 구성 요소는 다음과 같습니다:

• 요청 라우팅(request routing) 및 렌더링을 위한 Cloudflare Workers
• 기사 및 사이트 메타데이터를 위한 Cloudflare KV
• 관리되는 이미지 업로드를 위한 Cloudflare R2
• 다양한 프론트엔드 레이아웃을 위한 테마 시스템
• XML 사이트맵 및 이미지 사이트맵 생성
• 콘텐츠 준비 및 게시를 위한 소규모 로컬 AI 초안 작성 도구

갤러리는 단순한 미디어 폴더가 아니라 사이트의 핵심적인 부분입니다. 여기에서 둘러볼 수 있습니다: 1001020의 AI Gallery

왜 전통적인 백엔드 대신 Workers인가?

이 프로젝트의 경우, 워크로드의 대부분이 요청 라우팅, HTML 생성, 메타데이터 읽기 및 소규모 API 쓰기이기 때문에 Workers가 적합합니다. 전통적인 서버로도 작동하겠지만, 제가 필요하지 않은 배포 및 유지 관리 오버헤드(overhead)가 추가될 것입니다.

Cloudflare Workers는 동적인 동작을 처리하면서도 앱을 에지(edge)에 가깝게 유지하는 것을 쉽게 만들어 줍니다. 블로그는 별도의 Node 또는 컨테이너 배포 없이도 페이지를 서버 사이드에서 렌더링하고, API를 노출하며, 관리자 작업을 지원할 수 있습니다.

콘텐츠 저장소로서의 KV (KV as the content store)

이러한 형태는 액세스 패턴이 단순하기 때문에 개인용 퍼블리싱 시스템에 매우 적합합니다:

• 기사 인덱스(article index) 읽기
• 개별 기사 레코드(article records) 읽기
• 관리자 업데이트(admin updates) 쓰기
• HTML 또는 마크다운(markdown) 응답 렌더링
• 현재 콘텐츠로부터 사이트맵(sitemap) 출력 재생성

주요 트레이드오프(tradeoff)는 KV가 관계형 데이터베이스(relational database)가 아니라는 점입니다. 저는 데이터 모델을 작고 명시적으로 유지하며, KV가 임의의 쿼리 워크로드(query workloads)를 수행할 수 있는 것처럼 가장하는 것을 피합니다.

이미지를 위한 R2 (R2 for images)

이미지는 관리되는 자산(managed assets)으로 업로드되며 R2에서 제공됩니다. 기사 콘텐츠는 이러한 관리되는 이미지 URL을 참조할 수 있으며, 시스템은 이미지 참조를 추적하여 사용되지 않는 자산을 식별하고 정리할 수 있도록 합니다.

이미지가 많은 블로그는 오래된 파일이 빠르게 쌓이는 경향이 있기 때문에 이 부분이 중요합니다. 이미지 참조를 콘텐츠 모델의 일부로 취급하면 갤러리 및 기사 시스템을 더 쉽게 유지 관리할 수 있습니다.

내장된 SEO 기본 사항 (SEO basics that are built in)

이제 사이트에는 지루하지만 중요한 검색 관련 기능들이 포함되어 있습니다:

• sitemap.xml
• image-sitemap.xml
• robots.txt
• 서버 사이드 렌더링(server-rendered)된 기사 콘텐츠
• 레이아웃 안정성을 위한 이미지 크기(image dimensions)
• 표준(canonical) 기사 URL
• 관리자 설정 페이지를 통한 Google Search Console 인증 토큰 주입

에이전트 워크플로(agent workflow) 방향의 일부를 설명하는 기사는 여기에 있습니다: Agent Harness Loop and Graph Engineering

배운 점 (What I learned)

가장 큰 교훈은 서버리스 블로그를 단순한 장난감용 정적 페이지로 취급해서는 안 된다는 것입니다. 퍼블리싱, 이미지, 메타데이터(metadata), 관리자 작업, 분석(analytics), 그리고 사이트맵이 등장하면 시스템은 작은 CMS처럼 보이기 시작합니다.

Cloudflare Workers는 이러한 형태를 잘 처리할 수 있지만, 저장 모델이 단순하게 유지되고 라우트(routes)가 의도된 대로 유지될 때만 가능합니다.

1001020의 경우, 그 결과물은 전통적인 백엔드 서버 없이도 전 세계적으로 실행될 수 있는 컴팩트한 퍼블리싱 스택입니다:

• 라이브 사이트: https://blog.1001020.xyz/
• AI 갤러리: https://blog.1001020.xyz/gallery
• 예시 기사: https://blog.1001020.xyz/article/agent-harness-loop-graph-engineering

저는 여전히 퍼블리싱 워크플로 (publishing workflow)를 반복 개선하고 있지만, 핵심 시스템은 이제 공유할 수 있을 만큼 충분히 안정적입니다.