개인 기술 블로그를 운영하다 보면 꽤 자주 이상한 상황을 만납니다. 실제로 업데이트 빈도를 낮추는 것은 쓸 내용이 없어서가 아니라 글을 발행하는 과정 자체가 너무 무거워서인 경우가 많습니다.

WordPress는 저도 익숙하게 써 봤고, 나쁜 선택이라고 생각하지 않습니다. 오히려 지금도 매우 성숙한 플랫폼입니다. 관리 화면, 테마, 플러그인, 빠른 구축이 필요하다면 여전히 편합니다. 특히 기업 사이트, 뉴스 사이트, 여러 사람이 함께 편집하는 콘텐츠 환경에서는 WordPress가 강합니다.

하지만 개인적으로는 시간이 갈수록 장기적인 글쓰기 공간으로 쓰고 싶지 않았습니다. 이유는 단순했습니다. 독립 개발자인 저에게는 점점 **“글을 쓰면서 동시에 온라인 애플리케이션 하나를 운영하는 느낌”**이 됐기 때문입니다. 콘텐츠만 수정하고 싶은데 캐시, 플러그인, 백업, 업그레이드, 호환성까지 자연스럽게 따라옵니다. 관리자 페이지 자체가 계속 안정적인지도 신경 써야 합니다.

그래서 이 블로그는 결국 지금 구조로 정착했습니다. 프런트는 Astro, 콘텐츠는 Markdown, content collection으로 구조를 강제하고, 배포는 GitHub Actions가 담당합니다. 서버는 빌드가 끝난 정적 결과물만 제공합니다. 제가 원한 것은 단순했습니다. “글쓰기”와 “런타임 시스템 유지보수”를 분리하는 것입니다.

WordPress가 낡아서가 아니라, 그 런타임까지 계속 관리하고 싶지 않았다

이 글은 WordPress를 깎아내리려는 비교가 아닙니다. 문제는 오래됐다는 것이 아니라 많은 요소가 기본적으로 한 시스템 안에 묶여 있다는 점입니다.

WordPress 공식 Hardening WordPress 문서를 보면 보안은 위험을 없애는 것이 아니라 줄이는 일이라고 분명히 말합니다. 파일 권한, 플러그인 출처, 백업, 호스팅 환경을 함께 관리해야 합니다. Updating WordPress도 마찬가지입니다. 업데이트는 버튼 하나로 끝나는 추상적인 작업이 아니라 wp-admin, wp-includes, 플러그인, FTP, .maintenance 등 여러 요소와 연결됩니다.

저는 오히려 이런 문서가 WordPress의 성숙함을 보여준다고 봅니다. 복잡성을 숨기지 않기 때문입니다. 다만 동시에 한 가지 사실도 분명해집니다. 이 경로를 선택하면 글쓰기는 자연스럽게 **“실행 중인 CMS를 운영하는 일”**과 묶입니다.

많은 팀에는 전혀 문제가 없습니다. 온라인 편집 화면, 권한, 리뷰 흐름, 플러그인 생태계가 실제 요구사항이기 때문입니다. 하지만 혼자 기술 글을 오래 쓸 때는 다른 질문이 중요해집니다. 글이 3개일 때가 아니라 30개, 50개, 100개가 됐을 때도 이 방식이 편한가 하는 문제입니다.

사이트를 처음 만들 때는 보통 홈 디자인, 테마, 페이지 속도를 먼저 봅니다. 그런데 오래 운영하면 업데이트를 계속하게 만드는 결정적인 요소는 프런트가 아니라 뒤쪽 발행 흐름이 얼마나 적은 마찰로 유지되는지라는 걸 알게 됩니다.

속도보다 더 컸던 변화는 콘텐츠가 다시 내 손에 돌아온 것

Astro 이야기에서 가장 먼저 나오는 장점은 정적 사이트가 빠르고, 배포가 가볍고, 서버 부담이 낮다는 점입니다. 모두 맞습니다. 하지만 제가 결국 구조를 바꾼 이유는 성능보다 글이 repository 안의 일반 파일이 됐기 때문입니다.

현재 이 블로그의 각 언어 버전은 Markdown 파일로 관리됩니다. 제목을 바꾸고, description을 수정하고, 구조를 손보고, 내부 링크를 추가하면 Git이 변경 내역을 그대로 남깁니다. 문제가 생기면 특정 commit으로 돌아가면 됩니다. 관리자 페이지의 버전 기록을 찾거나 데이터베이스를 직접 만질 필요가 없습니다.

더 중요한 것은 마이그레이션이 덜 무서워진다는 점입니다. 나중에 테마를 바꾸고, 프런트를 다시 만들고, 글 표시 방식을 전부 바꾸더라도 콘텐츠 자체는 평범한 파일로 남습니다. 특정 관리자 시스템에 묶이지 않습니다. 독립 개발자에게는 이 부분이 특히 중요합니다. 관리하는 대상은 편집 조직이 아니라 시간이 지나며 계속 쌓이는 기술 자산이기 때문입니다.

또 하나는 오래 써 봐야 체감하기 쉬운 차이입니다. 콘텐츠가 파일이 되면 글쓰기가 개발 습관과 자연스럽게 연결됩니다. 로컬에서 쓰고, 로컬에서 미리 보고, 수정한 뒤 build합니다. “글은 다 썼고 이제 관리자 화면으로 이동해서 다른 절차를 해야 한다”는 단절이 없습니다.

작은 차이처럼 보이지만 지속적으로 업데이트할 때는 꽤 큽니다. 발행 과정이 평소 개발 작업과 같은 감각으로 이어지면 “나중에 올려야지” 하고 미루는 일이 줄어듭니다.

콘텐츠 모델을 고정하면 업데이트 비용이 크게 줄어든다

기술 블로그에서 무서운 건 디자인이 단순한 것이 아니라 콘텐츠 구조가 서서히 무너지는 것이라고 생각합니다.

글 몇 개일 때는 티가 나지 않습니다. 하지만 쌓이기 시작하면 어떤 글은 description이 있고 어떤 글은 없고, 태그 규칙이 제각각이며, 언어별 path가 어긋나고, 카테고리를 바꿨는데 오래된 글은 따라오지 않는 문제가 생깁니다. 그때부터 사이트를 업데이트하는 대신 과거의 불일치를 계속 수리하게 됩니다.

그래서 저는 콘텐츠 모델을 프로젝트 안에서 고정하고 build 단계에서 검증합니다. Astro 공식 Content collections 문서가 schema와 type safety를 중요한 기능으로 다루는 이유를 실제로 써 보면서 이해하게 됐습니다. 이 기능의 가치는 “더 규칙적으로 보인다”가 아니라 나중에 해야 할 재작업을 줄여 준다는 데 있습니다.

가장 편한 점은 “가능하면 규칙을 지켜 주세요”라고 알려주는 수준이 아니라는 겁니다. 잘못 쓰면 build가 통과하지 않습니다. 언어, path, title, 날짜, category, tags, topic 같은 필드를 처음부터 제약합니다. 처음에는 제한처럼 보이지만 시간이 지나면 오히려 자유로워집니다. SEO, 다국어 페이지, 주제별 집계도 이 규칙 위에서 훨씬 안정적으로 동작합니다.

WordPress에서도 물론 구조화된 콘텐츠를 만들 수 있습니다. 다만 그 규칙이 주로 관리자 시스템의 기능으로 존재한다면, 지금 구조에서는 규칙 자체가 repository 안에 있습니다. 전자가 더 유연할 수 있고, 후자는 더 결정적입니다. 장기간 기술 글을 운영하는 제 경우에는 후자가 더 잘 맞았습니다.

발행이 한 번의 push로 줄어들면 심리적 비용도 줄어든다

콘텐츠 발행에서 작은 마찰을 과소평가하기 쉽습니다.

글을 다 쓴 뒤 관리자 화면으로 이동하고, 공개 버튼을 누르고, 캐시를 비우고, 플러그인을 확인하고, 백업을 생각하고, 마지막으로 실제 사이트가 괜찮은지 확인해야 한다면 시간이 갈수록 업데이트를 미루게 됩니다. 콘텐츠가 없어서가 아니라 과정이 귀찮기 때문입니다.

지금 흐름은 훨씬 짧습니다. 로컬에서 Markdown을 작성하고 build로 확인한 뒤 push합니다. 이후는 GitHub Actions가 처리합니다. GitHub 공식 Events that trigger workflows에는 push, schedule, workflow_dispatch 같은 트리거가 기본 기능으로 정리돼 있습니다. 특별한 편법이 아니라 일반적인 엔지니어링 배포 방식입니다.

이 블로그에서는 scaffold로 언어별 글의 뼈대를 만들고, 로컬 build가 frontmatter와 content schema를 먼저 검증합니다. GitHub Actions는 정적 산출물을 만들고 서버에 업로드한 뒤 release를 전환하고, Nginx는 현재 release를 서비스합니다.

가장 좋은 점은 버튼 몇 개가 줄었다는 사실보다 발행이 감정적으로 부담스러운 작업이 아니게 됐다는 것입니다. 글을 다 쓰면 push하면 됩니다. “이제 운영 모드로 전환해야 한다”는 느낌이 없습니다.

저에게 가장 체감되는 변화도 이 부분입니다. 예전에는 “나중에 시간이 날 때 뒤의 작업까지 같이 처리해야지”라고 생각하기 쉬웠습니다. 지금은 후속 과정이 표준화되어 있어서 업데이트 빈도를 유지하기가 훨씬 쉽습니다.

서버가 다시 서버 역할만 하게 됐다

WordPress를 오래 쓰면서 불편했던 또 하나의 이유는 서버가 너무 많은 역할을 맡는다는 점이었습니다.

콘텐츠 관리자이면서 런타임이고, 플러그인 실행 환경이며, 캐시의 현장이자 장애를 디버깅하는 장소가 됩니다. 글 하나를 바꾸려 했는데 PHP, 데이터베이스, 플러그인 호환성, 관리자 로그인 면, 업그레이드 후 연쇄 문제까지 생각해야 할 수 있습니다.

지금 블로그에서 서버의 역할은 훨씬 단순합니다. build는 로컬이나 CI에서 끝내고, 운영 서버는 정적 결과물을 받고 여러 release를 유지하며 current를 전환한 뒤 HTTPS와 파일 서빙을 안정적으로 처리합니다. 화려한 변화는 아니지만 유지보수 부담은 크게 줄었습니다. 운영 서버는 자주 들어가서 “고쳐야 하는 애플리케이션”보다 안정적인 배포 대상으로 바뀌었습니다.

이 구조는 SEO 작업에도 간접적으로 도움이 됩니다. 관심이 런타임 문제에서 콘텐츠 자체로 돌아오기 때문입니다. 주제 허브, 내부 링크, 대표 글, 업데이트 주기를 개선하는 데 시간을 더 쓸 수 있습니다.

지금 이 구조가 더 미래지향적으로 느껴지는 이유는 AI를 자연스럽게 연결할 수 있기 때문이다

WordPress를 Astro로 바꾸는 것만으로는 특별히 새로운 이야기는 아닙니다. 제가 지금 구조를 계속 확장하기 좋다고 느끼는 이유는 AI를 콘텐츠 파이프라인 전체에 자연스럽게 넣을 수 있기 때문입니다. 편집기 안의 “문장 다듬기” 버튼 하나에 머물지 않습니다.

이 프로젝트에서는 AI skill이 Markdown 문서나 Notion 페이지를 읽고, 원재료를 블로그 글에 맞는 문장으로 다시 구성하고, 여러 언어 버전을 만들 수 있습니다. 발행 전에는 비밀번호, 사설 경로, IP, 토큰 같은 민감 정보를 걸러내는 과정도 넣을 수 있습니다. 이후 title, description, slug, category, tags를 만들고 build, commit, push, 배포 검증으로 이어집니다.

이 점이 Git-first 블로그와 전통적인 WordPress의 체감 차이를 크게 만듭니다. WordPress의 중심 경험은 온라인 관리자 화면에서 콘텐츠를 관리하는 데 있습니다. 지금 구조는 콘텐츠를 코드이자 자산이며 자동화 가능한 입력물로 봅니다. 독립 개발자 입장에서는 시간이 갈수록 이 모델이 더 편해집니다. 템플릿, SEO 검사, 민감 정보 필터링, 다국어 게시, 자동 배포 같은 기능이 원래부터 파일 흐름과 Git 흐름에 잘 맞기 때문입니다.

AI가 따로 붙인 장난감처럼 느껴지지 않고 기존 파이프라인의 한 단계로 자연스럽게 들어갑니다. 저는 이 차이가 단순한 페이지 속도 차이보다 더 크다고 봅니다.

결국 중요한 것은 무엇이 더 최신이냐가 아니라 앞으로 몇 년 동안 어떻게 쓸 것인가다

사이트에서 비개발자가 직접 온라인으로 글을 쓰고, 권한과 리뷰 흐름이 중요하며, 회원 기능이나 폼, 쇼핑몰, 마케팅 페이지를 빠르게 조합해야 한다면 WordPress가 더 쉬울 수 있습니다. 굳이 반대로 주장할 이유가 없습니다.

하지만 지금 이 사이트처럼 개인 기술 글을 오래 쌓고, 검색 유입을 중요하게 보고, 글을 버전 관리하고 rollback할 수 있어야 하며, 다국어 유지보수 비용을 낮추고, 앞으로 AI를 실제 게시 흐름에 연결하고 싶다면 저는 여전히 Astro + Markdown + GitHub Actions 구조를 선택합니다.

오래 지속할 수 있는 사이트를 결정하는 것은 테마가 얼마나 화려한지가 아니라 업데이트 흐름이 얼마나 가볍고, 안정적이고, 이미 익숙한 작업 방식과 닮아 있는지인 경우가 많습니다.

저는 이제 “오늘 한 편을 올리기 쉬운가”보다 **“반년 뒤에도 계속 업데이트하고 싶을까”**를 더 중요하게 봅니다. 그 기준에서는 지금 구조가 전통적인 WordPress보다 제 작업 방식에 더 잘 맞습니다.