WordPress 블로그와 Astro 블로그를 같은 운영 화면에서 관리하기 위해 Blog Studio에 Astro 연결 경로를 추가했습니다. 첫 버전은 AI가 글을 자동으로 공개하는 방식이 아니라, 사람이 Markdown 원고를 작성하고 GitHub PR에서 검토한 뒤 병합하는 방식입니다.
무엇을 연결했나요?
Astro 워크스페이스에는 GitHub 저장소와 배포 브랜치, 원고 폴더, Cloudflare Pages 프로젝트를 연결합니다. 연결 검사는 저장소의 Astro 패키지와 콘텐츠 스키마를 읽고, Pages가 같은 저장소와 브랜치를 배포하는지 확인합니다.
현재 지원하는 구조는 이 Lab에서 사용하는 표준 콘텐츠 계약입니다. 다른 Astro 블로그의 필드와 폴더 구조를 자동으로 변환하지는 않습니다. 토큰은 Blog Studio 서버에서 암호화해 저장하고 화면에 다시 표시하지 않습니다.
같은 화면 아래에서 발행 경로는 어떻게 나눴나요?
공통으로 묶은 것은 워크스페이스 선택, 원고 관리, 연결 정보와 상태 표시입니다. 서버는 FastAPI, 저장소는 SQLite를 사용합니다. 발행 동작까지 하나로 합치면 WordPress의 글 상태와 GitHub의 PR 상태를 혼동할 수 있어, 제공자에 따라 별도 경로로 처리했습니다.
그림 1. 실제 코드 기준으로 정리한 구조도입니다. Astro의 Cloudflare 토큰은 배포 결과를 읽는 데만 사용하며, 빌드는 GitHub와 Pages의 Git 연동이 실행합니다. 이미지를 누르면 크게 볼 수 있습니다.
- WordPress: 기존 생성·검사 파이프라인에서 WordPress REST API와 발행 도우미로 글을 보냅니다.
- Astro: Markdown 원고를 원고별 GitHub 브랜치에 저장하고 검토용 PR을 만듭니다. 사람이 병합한 뒤 Pages가 정적 사이트를 빌드합니다.
- 상태 확인: Blog Studio는 PR의 병합 커밋과 Pages 배포 커밋을 비교합니다. 빌드 성공과 실제 글이 열리는지는 별도로 확인합니다.
초안에서 공개까지 어떤 단계를 거치나요?
- Blog Studio에 제목, 설명, 날짜, 분류와 Markdown 본문을 저장합니다. 이때는 GitHub나 공개 사이트가 바뀌지 않습니다.
- 초안을 수정하고 검토용 PR 생성을 요청합니다. 원고별 브랜치에 Markdown 파일을 추가하고 PR을 만듭니다.
- GitHub에서 내용과 빌드 결과를 확인하고 병합합니다. PR의 원고에는
draft: false가 기록되므로 병합은 공개 여부를 결정하는 단계입니다. - Blog Studio가 병합 커밋과 Pages production 빌드의 커밋이 일치하는지 확인합니다. 마지막으로 실제 글 주소와 본문을 브라우저에서 확인합니다.
PR이 생겼다는 것과 배포가 성공했다는 것은 다른 상태입니다. Pages 빌드가 성공해도 잘못된 주소나 콘텐츠 필터 때문에 글이 보이지 않을 수 있어, 공개 페이지 확인을 별도로 남겼습니다.
실제로 어디까지 확인했나요?
이 글을 Blog Studio에 저장한 뒤 검토용 PR을 만들고, Markdown 파일 한 개만 추가되는지와 빌드 결과를 확인한 후 직접 병합했습니다. 아래는 그 원고의 실제 운영 화면입니다.
그림 2. 2026년 9월 20일 운영 화면의 발행 기록 부분을 캡처했습니다. ‘공개 페이지 확인 필요’는 실패라는 뜻이 아니라, 빌드 성공만으로 공개를 단정하지 않겠다는 표시입니다. 연결 계정과 토큰 입력 영역은 캡처 범위에서 제외했습니다.
실제 글 주소의 응답, 홈과 글 목록, RSS와 사이트맵 반영을 확인했습니다. 375px과 1280px 화면에서는 가로 넘침과 콘솔 오류가 없었고, 목차를 누르면 해당 제목으로 이동했습니다. PR 미리보기는 Cloudflare Access 로그인으로 보호되어 있어, 이 검증에서는 공개된 production 페이지를 직접 확인했습니다.
첫 시도에서 문제가 전혀 없었던 것은 아닙니다. 글은 이미 공개됐는데 관리 화면의 배포 조회가 cloudflare_http_400으로 실패했습니다. 한 번에 배포 100개를 요청하던 코드를 20개씩 최대 5페이지 조회하도록 바꾸고, 이 오류를 재현하는 테스트를 추가한 뒤 운영 화면에서 성공 표시를 다시 확인했습니다.
실패하면 어떻게 다시 시도하나요?
응답이 끊기면 같은 원고의 브랜치와 파일, PR을 다시 조회합니다. 이미 만든 파일이나 PR을 그대로 재사용해 같은 요청이 두 개의 글로 이어지는 상황을 줄입니다. 원격에서 수정된 파일은 덮어쓰지 않습니다.
PR 요청 중 서버가 재시작된 경우에는 실행 잠금이 만료된 뒤 같은 요청을 다시 확인할 수 있습니다. 기존 글 주소와 충돌해 원격 쓰기를 시작하지 못한 경우에는 초안으로 돌아가 주소를 고칩니다.
아직 직접 해야 하는 일은 무엇인가요?
첫 버전에서는 원고 작성과 PR 검토·병합을 사람이 담당합니다. AI 원고 생성, 기존 GitHub 글 가져오기, 이미지 업로드, 사용자 정의 Astro 필드 매핑은 후속 작업입니다. 미래 날짜의 글도 날짜가 됐다는 이유만으로 자동 재빌드되지는 않습니다.
이 글은 Blog Studio에서 Astro로 이어지는 발행 경로를 실제로 확인하기 위한 구축 기록입니다. 검증 범위와 남은 기능을 구분하면서, 먼저 직접 사용할 수 있는 작은 CMS 흐름을 완성하는 데 초점을 맞췄습니다.
연결 토큰을 추가하면 비용도 늘어나나요?
이번 연결에서 Cloudflare 토큰은 Pages 프로젝트와 배포 결과를 읽을 권한만 부여했습니다. 토큰을 추가하는 작업은 유료 플랜이나 유료 실행 서비스를 켜는 작업이 아니며, 현재 사용하는 관리 API 조회에는 별도의 호출당 요금이 붙지 않습니다. 대신 API 요청 횟수 제한이 있습니다.
Lab은 서버 함수를 실행하지 않는 Astro 정적 사이트입니다. Cloudflare 공식 문서에 따르면 Functions를 호출하지 않는 정적 파일 요청은 무료이며, Free 플랜의 빌드는 월 500회 한도가 있습니다. PR 미리보기나 후속 수정도 빌드를 만들 수 있으므로 ‘글 500편’과 같은 뜻은 아닙니다. Pages 요금과 빌드 한도를 함께 확인해야 합니다.
이 설명은 이번 연결로 늘어나는 비용에 관한 것입니다. 기존 도메인·홈랩 서버·구독형 CLI 비용, GitHub Actions 사용량, 추후 Workers·유료 이미지 처리·유료 AI API를 추가할 때의 비용은 별도입니다. 이번 작업에서 그런 유료 기능이나 플랜을 추가하지 않았습니다. 기준일은 2026년 9월 20일입니다.
참고자료
이 기록은 Blog Studio 프로젝트의 일부입니다.
프로젝트 전체 기록 보기 →