혼자 운영하는 사이트에 대시보드부터 필요할까?

처음에는 편집 화면이 필요하지 않았다

사이트를 만들면 자연스럽게 ‘관리자 페이지도 있어야 하지 않을까?’라는 생각이 듭니다. 하지만 작성자가 한 명이고 글이 아직 많지 않다면 관리자 화면은 발행을 돕는 도구가 아니라 별도로 관리할 제품이 되기 쉽습니다.

로그인과 권한, 이미지 업로드, 미리보기, 데이터 백업과 보안까지 함께 운영해야 하기 때문입니다.

첫 버전은 Markdown과 Git

라기라기에서는 글 한 편을 Markdown 파일 하나로 저장합니다. 제목, 설명, 발행일, 검증 상태와 출처는 앞부분의 frontmatter에 적고, 본문은 평범한 Markdown으로 씁니다.

코드와 글은 GitHub에 버전 기록으로 남기고, 공개할 때는 로컬에서 Astro 빌드를 확인한 뒤 Wrangler로 Cloudflare Pages에 직접 배포합니다. 소스 이력과 배포 동작을 분리해 무엇이 언제 바뀌었는지 남기면서, 실제로 내보낼 시점은 직접 결정합니다.

이 선택의 단점

• Git과 파일 편집이 낯설면 처음에 배워야 합니다.
• 휴대전화에서 급하게 글을 고치기에는 불편합니다.
• 여러 사람이 승인 과정을 거쳐 쓰기 어렵습니다.
• 이미지가 많아지면 파일명과 용량을 직접 관리해야 합니다.

단순하다는 말은 누구에게나 편하다는 뜻이 아닙니다. 그때의 운영 조건에 맞는다는 뜻입니다.

조건이 바뀐 지점

실제 글쓰기 방식을 생각해보니 Mac이 없는 순간에도 기록을 시작하고 이어 써야 했습니다. 휴대전화나 다른 컴퓨터에서 수정하려면 Git과 로컬 파일이 작성 자체의 마찰이 됩니다. 이는 예상 기능이 아니라 실제 사용 조건이었습니다.

그래서 ‘대시보드를 만들 것인가’보다 ‘어떤 부분만 도구로 바꿀 것인가’를 다시 물었습니다.

공개 사이트와 입력 도구를 분리했다

공개 사이트는 여전히 Git에 있는 Markdown을 읽어 정적 HTML을 만듭니다. 새로 만든 ragiragi studio는 다음 역할만 맡습니다.

1. D1에 초안을 자동 저장합니다.
2. 리치 편집과 Markdown 원문, 공개 미리보기를 오갑니다.
3. 이미지는 비공개 R2에 보관합니다.
4. 발행 직전에 공개 사이트와 같은 스키마로 다시 검증합니다.
5. 검증된 Markdown과 사용한 이미지만 GitHub에 기록합니다.

입력 도구가 고장 나도 공개 사이트는 영향을 받지 않고, Studio 내부 형식을 바꾸더라도 최종 Markdown 계약은 남습니다. 로그인 화면만 붙이는 것으로 끝내지 않고 Cloudflare Access와 Worker의 JWT 검증을 함께 통과해야 열도록 경계도 분리했습니다.

지금의 결론

처음부터 대시보드를 만드는 것도, 끝까지 파일 편집만 고집하는 것도 답은 아니었습니다. 가장 단순한 방식으로 시작하고 실제 마찰이 확인됐을 때 그 부분만 도구로 바꾸는 편이 맞았습니다. 이제 확인할 것은 Studio의 기능 수가 아니라, 장소와 기기 때문에 놓치던 기록이 실제로 줄어드는지입니다.