블로그를 직접 만든다는 것
처음에는 프로젝트를 잘 보여주는 포트폴리오 화면을 만드는 데 집중했습니다. 결과는 정돈되어 있었지만 기술 블로그보다는 제품 소개 사이트에 가까웠습니다. 이 사이트의 목적은 결과를 홍보하는 것이 아니라, 개발 중에 내린 판단과 실패를 계속 기록하고 채용 과정에서 확인 가능한 근거로 보여주는 것입니다.
요구사항을 다시 정리했습니다.
- 첫 화면에서 최근 글을 바로 읽을 수 있어야 한다.
- 글은 날짜, 카테고리, 제목과 요약을 중심으로 탐색한다.
- 프로젝트는 글을 설명하는 근거이지 첫 화면의 주인공이 아니다.
- 브라우저에서 글과 카테고리를 만들고 수정하거나 삭제할 수 있어야 한다.
- 초안은 명시적으로 공개하기 전까지 Production에 나타나면 안 된다.
공개 페이지와 관리자의 책임 분리
독자가 보는 홈, 글, 카테고리와 프로젝트 페이지는 Astro가 미리 HTML로 만듭니다. 사용자별 데이터가 없는 블로그에 매 요청마다 서버 렌더링과 데이터베이스를 둘 이유가 없기 때문입니다.
반면 글을 관리하는 /keystatic과 GitHub OAuth API는 Vercel Function으로 실행합니다. Keystatic에서 저장한 내용은 별도 데이터베이스가 아니라 저장소의 Markdown과 YAML 파일이 됩니다. 결과적으로 브라우저 편집, Git 변경 이력, CI 검증과 자동 배포가 하나의 흐름으로 이어집니다.
직접 관리자와 데이터베이스를 만드는 안도 검토했습니다. 하지만 인증, 세션, 권한, 이미지 저장, 백업과 에디터를 모두 운영하는 것은 이 블로그가 보여주려는 역량과 거리가 있습니다. 필요한 복잡성만 남기고, 공개 콘텐츠의 소유권과 이식성은 Git으로 확보했습니다.
편리함이 검증을 건너뛰지 않게 하기
카테고리와 프로젝트 관계는 파일 slug로 저장됩니다. 관리 화면에서 참조 대상을 삭제하거나 이름을 바꾸면 글에 끊어진 값이 남을 수 있습니다. 이를 막기 위해 별도 관계 검사기를 추가했고, 로컬·GitHub Actions·Vercel이 모두 같은 npm test를 실행합니다.
새 글과 프로젝트는 기본적으로 draft: true입니다. Production 빌드는 초안 라우트를 만들지 않으며 검증 스크립트가 대표 초안 URL의 부재를 다시 확인합니다. 관리 화면과 API에는 noindex, nofollow 응답도 적용했습니다.
실제 배포에서 발견한 경계
관리자 경로를 추가하며 Astro Vercel 어댑터를 연결하자 정적 산출물 위치가 dist에서 dist/client로 달라졌습니다. 빌드는 성공했지만 기존 산출물 검사가 모두 실패했고, 실제 배포 구조를 기준으로 검증 경로를 수정했습니다.
새 주소 seongju.vercel.app을 연결한 뒤에는 모든 요청이 Vercel SSO로 이동하는 문제도 있었습니다. 애플리케이션이 아니라 Deployment Protection이 수동 alias를 보호한 것이 원인이었습니다. 공개 글은 인증 없이 읽을 수 있게 보호 범위를 바로잡고, 관리자는 Keystatic의 GitHub OAuth가 맡도록 책임을 분리했습니다.
이 블로그의 첫 번째 운영 기록은 화려한 기능보다 경계를 명확히 한 과정입니다. 앞으로도 성공한 결과만 요약하지 않고, 무엇을 기대했고 실제로 무엇이 달랐는지와 그 판단을 어떻게 검증했는지를 남길 계획입니다.