CMS Saas 쓰지 않고 만든 이유
Strapi, Ghost, Notion, Sanity를 거치며 느낀 한계를 바탕으로, 포트폴리오 블로그와 CMS 레이어를 분리한 개인 운영 구조를 직접 만들게 된 이유를 정리했다. AX와 GEO 시대에 개인 사이트를 어떻게 설계해야 하는지에 대한 첫 번째 기록.
요즘 CMS는 정말 많습니다. Strapi도 있고, Ghost도 있고, Notion을 퍼블리싱 흐름에 얹을 수도 있고, Sanity처럼 유연한 구조를 가진 도구도 있습니다. 저도 이 블로그에 다양한 CMS들을 연결해 써봤습니다. 더 편하게 글을 쓰고 싶었기 때문입니다.
여러 도구를 써볼수록 "무엇을 써야 하지"보다 "내가 진짜 풀고 싶은 문제는 뭐지"가 더 선명해졌기 때문입니다.
저는 한동안 CMS 유목민이었습니다. Strapi를 만져보기도 했고, Ghost를 붙여보기도 했고, Notion으로 운영 흐름을 단순하게 가져가 보려 한 적도 있었고, Sanity로 다시 구조를 짜본 적도 있습니다. 각각 장점은 분명했습니다. 빠르게 시작할 수 있는 도구도 있었고, 콘텐츠 모델링이 유연한 도구도 있었고, 블로그 운영에 충분히 세련된 경험을 주는 도구도 있었습니다.
이 SikLimited 블로그도 CMS와 디자인이 마음에 들지 않아 다여섯번 리뉴얼 했습니다. 유목민처럼 정착을 못했습니다. 새로 만들기엔 귀찮음이 너무 커서 시도하지 않았다가... 결국 직접 만들었습니다. 기존 CMS 프로덕트들이 입맛에 맞는 기능들이 없었고, 커스텀하기가 어려워서가 컸습니다. 잘 사용도 안하게 되는게 컸습니다. 적어도 유지보수라도 하면서 글이라도 쓰게되겠지 마음으로..
여러 CMS를 썼는데 항상 느껴졌던 불편함은 딱 하나였습니다. 제 사이트는 블로그 하나로 설명되지 않는다는 점이었습니다.
글도 있어야 했고, 작업물도 있어야 했고, 어떤 페이지는 누구나 볼 수 있어야 했고, 어떤 페이지는 특정 링크를 받은 사람만 볼 수 있으면 좋겠다고 생각했습니다. 발행 이후에는 검색엔진 반영, SEO/GEO 최적화 도구, 메타데이터 정리, 분석, 추적, 그리고 AI 도구와 연결되는 편집 흐름까지 함께 보고 싶었습니다. (배 보다 배꼽이 커보인다!) 글을 올리는 기능만으로는 늘 아쉬웠습니다. 결국 제가 찾던 것은 CMS 제품 하나가 아니라 제 작업 방식에 맞는 운영 구조에 더 가까웠습니다.
이 생각은 AX와 GEO라는 말을 접하면서 더 또렷해졌습니다. 거창한 시대론을 말하려는 건 아닙니다. 다만 개인 사이트를 운영하다 보면 분명히 느끼게 됩니다. 이제는 사람이 읽기 전에 검색엔진과 여러 에이전트가 먼저 읽고, 요약하고, 인용하고, 판단합니다. 개인 사이트는 예쁜 페이지와 글 몇 편을 넘어, 어떻게 발견되고 어떤 구조로 이해되며 어떤 문장이 인용될지까지 함께 설계해야 하는 대상이 됐습니다.
전환점은 의외로 소박했습니다. 카카오에서 받은 Codex 이용권이 계기였습니다. 거창한 제품을 만들겠다는 마음보다, 이 정도면 제 작업 흐름을 조금은 다시 짜볼 수 있지 않을까 하는 생각이 먼저 들었습니다. 그 작은 계기로 저는 덜 불편한 도구를 찾는 대신, 제 기준으로 도구를 다시 묶어보는 쪽으로 방향을 틀었습니다.
그렇게 해서 지금은 포트폴리오 블로그 레이어와 CMS 레이어를 분리해 운영하고 있습니다. Cloudflare Workers와 D1 위에서 돌아가고, 글과 작업물을 직접 관리할 수 있는 CMS를 두고, 퍼블릭 레이어에서는 포트폴리오와 블로그가 읽히도록 구성하고 있습니다. 여기에 자동 인덱싱, Google Analytics, Umami 트래킹, MCP 서버 연결, SEO/GEO 최적화 자동화 같은 기능을 조금씩 붙여가고 있습니다.

중요한 건 기능이 많다는 사실이 아닙니다. 이 기능들이 모두 같은 문제를 향하고 있다는 점이 더 중요합니다. 저는 콘텐츠를 저장하는 도구를 만든 게 아니라, 제 이름으로 만든 결과물이 더 정확하게 발견되고 읽히고 전달되게 하는 구조를 만들고 싶었습니다.
예를 들어 어떤 작업물은 공개 포스트처럼 누구에게나 열어두고 싶지 않았습니다. 채용 과정이나 협업 제안처럼 특정 링크를 받은 사람만 볼 수 있게 하고 싶을 때가 있었습니다. 그래서 접근 링크를 발급하고, 그 링크로 들어온 흐름을 추적하는 구조도 직접 넣고 있습니다. 최근에도 라우트 구조를 바꾸면서 Umami 추적이 깨진 적이 있었는데, 그 일을 겪으면서 다시 느꼈습니다. 운영 구조를 직접 가진다는 건 자유도가 생긴다는 뜻이기도 하지만, 그 자유를 계속 맞춰가야 한다는 뜻이기도 하다는 점을요.
그래서 이 글은 "기성 CMS보다 내가 만든 것이 더 낫다"를 주장하려는 글이라기보다, 왜 결국 제 손에 맞는 구조를 직접 묶게 됐는지를 설명하는 기록에 가깝습니다. Strapi, Ghost, Notion, Sanity는 각각 충분히 좋은 도구였습니다. 다만 제 경우에는 포트폴리오, 글쓰기, 제한 공유, 검색 반영, 분석, AI 워크플로우가 계속 서로 다른 방향으로 흩어졌고, 그걸 한데 묶어볼 필요가 있었습니다.
개인 사이트를 운영하는 일은 점점 글을 올리는 문제보다, 그 글과 작업물이 어떤 경로로 움직이게 할지를 설계하는 문제에 가까워지고 있습니다. 저는 그 변화를 거창하게 해석하기보다 작게 직접 운영해보는 쪽을 택했습니다. 그 결과가 지금의 CMS입니다.
다음 글에서는 왜 이 구조를 단순한 글 저장소가 아니라 배포 시스템처럼 운영하게 되었는지, 포트폴리오 레이어와 CMS 레이어를 어떻게 나눠 생각하고 있는지 조금 더 구체적으로 적어보려 합니다.
코멘트
진짜 지독한 사람..