TinaCMS로 블로그 컨텐츠 Editor 환경 세팅

배경

먼저 이 블로그를 만들게 된 계기를 간단히 이야기하겠다. 이전에 회사에서 도메인을 구매할 일이 있었는데, 가격이 싼 도메인을 찾다 보니 내 이름의 도메인이 굉장히 싸더라. (기억이 잘 안 나지만 연 8000원 꼴이었던 것 같다.)

충동적으로 일단 샀다. 내 이름만으로 구성된 간결한 도메인이 얼마나 매력적인지.. 도메인을 샀으니 뭔가 쓰긴 해야겠다만, 별도로 서버 운영을 하고 싶지는 않았다. 그 간 개인 서버 운영으로 부담을 겪으신 분들을 여럿 보았기에… 그렇다고 잘 관리해서 수익화를 목표로 한다던가 그런 용도에도 관심이 없었다. 취미로 돈을 벌게 되면 더 이상 취미가 아니게 되는 법이다.

그런 사고 방식에 의해 개인 블로그를 호스팅하되 단 한 푼도 쓰지 않겠다는 방향으로 세팅을 하게 되었다. Cloudflare Pages로 정적 호스팅을 하였고, 여타 다른 무료 테마나 CMS를 쓰기는 싫어 클로드를 활용해 Astro 기반의 웹페이지를 개발하였다. mdx 파일에 게시물을 작성하도록 하여, 컨텐츠 관리를 AI와 내가 같이 편하게 할 수 있을 것이라 기대하였다.

처음에는 Claude에게 모든 게시물 초안 작성을 맡기고, 퇴고는 mdx 파일을 직접 수정할 계획이었기에 CMS 도입을 고려하지 않았다. 그러나 블로그 호스팅 이후 실제로 여러가지 주제를 클로드에게 주고 초안 작성을 시켜보았으나, 하나같이 내 마음에 들지 않더라.

클로드의 열받는 초안을 파일 위에서 수정해보았으나, 글 전체를 부분 부분 수정하는 것이 오히려 더욱 머리가 아파, 차라리 처음부터 쓰는 것이 낫다고 생각한 적이 많다. 그러면 ide 위 md 파일에 글을 작성하는 것보단, 여타 블로그 서비스처럼 CMS 환경이 필요하다. 그리고 퇴고를 거칠 때도 아무래도 md 파일을 읽는 것보단 실제로 최종적으로 랜더링된 글을 직접 읽어보는 것이 가장 좋다.

그래서 CMS를 도입하는 것으로 하였고 선정 당시 요구사항은 다음과 같았다.

CMS 요구사항

  1. 여전히 서버 비용을 내고 싶지는 않았다. 로컬 환경에서 충분히 사용 가능해야한다.
  2. Live Preview Editor가 지원되면 좋겠다. mdx 파일을 직접 수정할 때 겪었던 큰 불편함은 항상 랜더링 이후에 글을 다시 수정하거나, 에셋을 조정해야하는 부분이었다.
  3. 이미 기존에 개발된 웹페이지 / 테마 / 레이아웃 등에 큰 영향을 미치지 않았으면 한다. 이미 CMS가 기존 소스코드 및 Astro, MDX 스택들과 큰 문제 없이 호환이 되어야 한다.
  4. AI가 파일을 마음대로 변경하여 수정 중인 작업이 날라가지 않았으면 한다.

TinaCMS를 채택

missing
실제 Editor 환경

여러 스택을 검토/실사용 해본 후 TinaCMS를 채택하였다.

TinaCMS는 우선 1, 2, 3번 요건을 모두 충족하였다. 이미 있는 블로그에 적용이 쉬웠고, Live Visual Editor도 완벽하지는 않지만 레이아웃을 그대로 보여주는 점이 좋았다. Visual Editor에서 보여주는 Preview는 Astro preview Build 결과를 iframe으로 그대로 보여주어, 실제 퍼블리시한 결과와 다를 일이 거의 없다. 특정 CMS는 렌더 방식이 락인되어서 CMS에선 문제가 없으나 퍼블리시 이후에 깨지는 경우나 그 역인 경우가 있다. 이런 이유로 기존 블로그에 빠르게 적용할 수 있기에 TinaCMS를 선택하였다.

컨텐츠의 포맷 / 관리 방식이 CMS에 락인이 걸리지 않는 점도 장점이었다. AI도 컨텐츠를 관리하고 수정할 것을 생각하면 CMS의 존재와 무관하게 바로 컨텐츠 파일과 스크립트 파일을 만질 수 있는 것이 효율적이다.

4번 요건을 만족하기 위해 content-per-branch 기능을 쓸 수 있기를 기대하였으나, Content 저장소를 Github로 두면서 Pro Plan 이상을 사용해야 했다. 로컬환경에서 같은 기능을 직접 쓰려면, branch 별로 CMS Server를 띄우거나, worktree 디렉토리 생성 경로를 조작할 필요가 있었으므로 배보다 배꼽이 커지는 일이라 생각했다.

Preview에 대해 HMR 기능을 꺼서 컨텐츠 파일 변경에 의한 CMS 서버 재시작을 방지하고, AI를 위한 collection pool을 두고 AI가 컨텐츠 작성 및 수정 시엔 해당 pool로 copy 이후에 조작하는 것을 가이드라인으로 남겨 해당 문제는 일단 타협했다. 잘 지켜질련지는 모르겠다만..