기타 · 2026년 3월 28일

Tistory에서 Astro Self Hosting으로 블로그 이사온 이유와 후기

필자는 중학생 때부터 10년이 넘도록 티스토리에서 글을 써왔다. 처음에는 꽤 만족했다. 당시 블로그 플랫폼 중에서는 수익을 창출할 수 있었고, 비교적 자유도도 높았기 때문이다. 초대장이 있어야만 가입할 수 있을 정도로 티스토리의 인기가 높던 시절이기도 했다.

그러나 시간이 지날수록 생각이 조금씩 바뀌었다. 티스토리의 정책이 하나둘 바뀌더니, 결국 이사를 진지하게 고민할 정도로 위협적으로 느껴졌다. 이사를 가야지, 가야지 하다가 최근 ‘동영상 업로드 기능 폐지’ 정책을 보고 결국 티스토리에서 나와, Astro 기반의 정적 블로그를 만들고 Cloudflare Pages에 배포하는 방식으로 옮겼다.

이번 글은 “Astro라는 프레임워크가 얼마나 좋은가”를 설명하는 글이라기보다는, 왜 굳이 멀쩡히 돌아가던 티스토리를 떠났는지, 그리고 막상 옮겨보니 무엇이 달라졌는지 정리한 기록에 가깝다. 누군가에게는 굳이 할 필요 없는 삽질일 수도 있지만, 적어도 내 기준에서는 꽤 만족스러운 방향 전환이었다.

왜 티스토리를 떠났나

가장 큰 이유는 통제권이었다. 티스토리는 분명 플랫폼 블로그로서 장점이 많다. 로그인해서 글을 쓰고 발행하면 끝이고, 관리 화면도 익숙하다. 검색 유입도 어느 정도 기대할 수 있고, 블로그를 가볍게 운영하기에는 충분히 편하다. 문제는 그 편리함의 대가가 결국 플랫폼 의존이라는 점이었다.

블로그를 오래 운영할수록 “지금 이 페이지가 정말 내 것인가”라는 질문을 하게 된다. 티스토리는 글을 올리는 공간은 제공하지만, 그 공간의 성격과 규칙을 최종적으로 결정하는 쪽은 사용자가 아니라 플랫폼이다. 이게 처음에는 별문제가 아니다. 그런데 어느 정도 시간이 지나고, 글 수가 쌓이고, 블로그 디자인과 구조에 대한 취향이 생기면 얘기가 달라진다. 내가 바꾸고 싶은 것과 실제로 바꿀 수 있는 것 사이에 계속 벽이 느껴진다.

특히 불편했던 부분은 아래와 같았다.

강제 광고가 본문에 삽입되는 방식이 불쾌했다.
기존에 있던 동영상 업로드 기능이 제거되면서, 플랫폼 기능을 믿고 쌓아 둔 방식이 언제든 바뀔 수 있다는 걸 체감했다.
원하지 않는 요소가 페이지에 개입하는 느낌이 강했다.
스킨 커스터마이징이 가능하다고는 하지만, 결국 플랫폼 제약 안에서만 움직여야 했다.
글을 자산처럼 쌓고 있다는 느낌보다, 남의 집에 세 들어 사는 느낌이 더 컸다.
백업과 이전을 생각하면 Markdown 기반 관리가 훨씬 마음이 편했다.

강제 광고 삽입은 특히 결정적이었다. 블로그를 운영하는 사람 입장에서는 페이지의 구조와 리듬도 콘텐츠의 일부다. 본문 앞뒤로 무엇이 들어가고, 어느 지점에서 사용자의 시선이 끊기는지, 어떤 분위기로 읽히는지까지 모두 글의 경험에 영향을 준다. 그런데 그 흐름에 내가 원하지 않는 광고가 강제로 끼어드는 순간, 이 공간이 실제로는 내 통제 아래 있지 않다는 사실이 너무 선명해졌다.

동영상 업로드 기능 제거도 비슷했다. 기능 하나가 빠진 것 자체보다, 내가 플랫폼 기능을 기반으로 운영 방식을 짜 놓았더라도 그 전제가 언제든 사라질 수 있다는 점이 더 크게 와닿았다. 기존 영상까지 모조리 삭제되는 티스토리의 정책은 정말 실망스러웠다. 결국 플랫폼은 내 작업 방식을 기준으로 움직이지 않는다. 나는 그 규칙 변화에 적응해야 하는 쪽이고, 그 구조 자체가 점점 답답하게 느껴졌다.

처음에는 “이 정도는 그냥 감수하면 되지”라고 생각했다. 무료 플랫폼이니 어느 정도 제약은 받아들이는 게 맞다고도 생각했다. 그런데 블로그를 오래 가져갈수록 이 불편함이 계속 누적됐다. 특히 강제 광고 삽입이나 동영상 업로드 기능 제거처럼, 운영자가 원하지 않아도 플랫폼 정책 변화가 바로 블로그 경험에 영향을 주는 점이 결정적으로 거슬렸다. 결국 문제는 기능 하나가 아니라, 운영 방식 전체가 내 성향과 맞지 않는다는 점이었다.

왜 하필 Astro였나

티스토리를 떠나기로 마음먹은 다음에는 선택지가 꽤 많았다. Next.js처럼 더 범용적인 프레임워크를 쓸 수도 있었고, Hugo나 Jekyll 같은 정적 사이트 생성기를 고를 수도 있었다. 그런데 이번 목표는 화려한 인터랙션이 많은 웹앱을 만드는 게 아니라, 글이 중심인 빠른 블로그를 안정적으로 운영하는 것이었다. 그런 기준에서 Astro가 가장 잘 맞았다.

Astro를 고른 이유가 단순히 “요즘 많이 쓰니까”만은 아니었다. 내가 원한 조건과 Astro가 제공하는 방식이 꽤 정확하게 맞물렸다.

콘텐츠 중심 구조를 만들기 좋다.
Markdown 작성 경험이 자연스럽다.
불필요한 자바스크립트를 최대한 줄여서 페이지가 가볍다.
내가 필요한 만큼만 구조를 얹을 수 있어서 과하지 않다.

특히 좋았던 건, Astro가 콘텐츠를 다루는 태도 자체가 블로그와 잘 맞는다는 점이었다. 글을 하나의 데이터로 보고, 그 데이터를 어떻게 렌더링할지 내가 분명하게 제어할 수 있다. 티스토리에서는 에디터 안에서 글을 작성하고 결과를 플랫폼이 보여주는 방식이었다면, Astro에서는 Markdown 파일이 먼저 있고, 사이트는 그 파일을 내가 원하는 방식으로 보여주는 구조다. 이 차이가 생각보다 크다.

또 Astro는 “정적 사이트”라는 특성 덕분에 정신이 덜 산만하다. 내가 만들고 싶은 건 방대한 클라이언트 상태를 가진 앱이 아니라, 읽기 좋은 문서와 빠른 페이지였다. 그런 점에서 Astro는 필요한 것만 남기고 나머지는 최대한 덜어내는 방향에 가깝다. 블로그처럼 본문이 중심인 사이트에서는 이런 성향이 오히려 큰 장점이었다.

무엇보다 마음에 들었던 건, 블로그 엔진을 다루는 느낌보다 정적인 문서를 차곡차곡 관리하는 느낌이 강하다는 점이었다. 글은 결국 데이터고, 데이터는 내가 읽기 쉬운 형식으로 들고 있어야 마음이 편하다. 그런 면에서 Markdown + Git 조합은 티스토리보다 훨씬 예측 가능했고, 나중에 다른 플랫폼으로 이동할 때도 훨씬 덜 불안하다.

SEO 측면에서도 이 구조가 마음에 들었다. 글마다 title, description, canonical, 오픈 그래프 메타 태그를 내가 직접 통제할 수 있고, 필요하면 BlogPosting 같은 구조화 데이터도 넣을 수 있다. URL 구조를 깔끔하게 유지하기도 쉽고, 페이지 자체가 가벼워서 로딩 성능 측면에서도 유리하다. 결국 검색엔진 최적화는 꼼수보다 기본기가 더 중요한데, Astro는 그 기본기를 챙기기 좋은 바탕이었다.

src/
├── layouts/
│   └── BlogPost.astro
├── pages/
│   ├── index.astro
│   └── posts/
│       └── 2026-03-28-moving-tistory-to-astro-review.md
astro.config.mjs

왜 Cloudflare Pages였나

Astro로 정적 사이트를 만들기로 한 뒤에는, 이제 그 결과물을 어디에 올릴지만 정하면 됐다. 여기서 Cloudflare Pages를 고른 이유는 단순했다. 복잡한 서버 운영을 하고 싶지 않았고, 배포 흐름은 최대한 단순해야 했고, 처음 시작할 때 비용 부담도 거의 없어야 했다. 그 조건을 놓고 봤을 때 Cloudflare Pages가 꽤 실용적인 선택이었다.

내 기준에서 좋았던 점은 이렇다.

초기 비용이 무료라서 부담 없이 시작할 수 있다.
GitHub 저장소와 연결해서 커밋만 올리면 자동으로 배포할 수 있다.
정적 사이트 호스팅에 필요한 설정이 비교적 단순하다.
커스텀 도메인 연결과 HTTPS 적용이 번거롭지 않다.
작은 개인 블로그를 운영하기에는 부담이 적다.

개인 블로그를 옮길 때는 생각보다 “기술적으로 가능한가”보다 “계속 운영할 수 있나”가 더 중요하다. 처음 며칠은 뭘 써도 재밌다. 문제는 시간이 지나도 같은 구조를 유지할 수 있느냐다. Cloudflare Pages는 그 점에서 꽤 현실적이었다. 로컬에서 글을 쓰고, 저장소에 반영하고, 배포가 자동으로 따라오는 흐름이 단순해서 유지하기 쉬웠다.

무엇보다 초기 비용 없이 바로 시작할 수 있다는 점이 컸다. 블로그 이전은 생각보다 손이 많이 가는 작업인데, 시작부터 돈과 인프라 고민이 붙으면 진입장벽이 확 올라간다. Cloudflare Pages는 적어도 “일단 옮겨 보고 굴려 본 다음 계속 가져갈지 판단하자”라는 접근이 가능했다. 서버를 직접 관리하는 쪽으로 에너지를 쓰기보다, 콘텐츠와 블로그 구조를 다듬는 데 집중하기 좋았다.

정적 페이지 자체는 Cloudflare Pages에 올리고, 이미지와 영상 같은 미디어 파일은 Cloudflare R2를 활용하는 방식으로 운영하고 있다. 페이지 렌더링과 미디어 저장소를 분리해 두니 구조가 단순해지고, 글 본문에 들어가는 자산도 조금 더 명확하게 관리할 수 있었다.

실제로 옮기면서 좋았던 점

막상 옮기고 나서 가장 만족스러웠던 건, 글쓰기 환경 자체보다 운영 환경이 훨씬 단순해졌다는 점이었다. 이제 글 하나가 그냥 에디터 안의 Markdown 파일이다. 제목, 설명, 태그, 날짜를 frontmatter로 관리하고, 본문은 평범한 텍스트로 남는다. 플랫폼 UI 안에서 글을 작성할 때보다 훨씬 단순하고, 결과물이 어떤 형태로 남는지도 명확하다.

이 변화는 생각보다 크다. 티스토리에서는 글을 작성하는 행위가 서비스 안에서 이루어진다. 즉, 글이 플랫폼과 분리되지 않는다. 반면 지금은 글이 먼저 파일로 존재하고, 사이트는 그 파일을 렌더링하는 레이어에 가깝다. 그래서 백업도 쉽고, 수정 이력 추적도 쉽고, 필요하면 특정 시점으로 되돌리는 것도 편하다. 블로그를 “서비스에 글 쓰기”가 아니라 “문서와 소스코드를 같이 관리하기”에 가깝게 바꾼 셈이다.

배포 과정도 생각보다 명확했다. 로컬에서 작성하고, 수정하고, 커밋한 뒤 Cloudflare Pages로 배포하면 끝이다. 어디에서 무엇이 꼬였는지 추적하기 쉽고, 작업 흐름도 단순하다. 에디터, Git, 배포라는 세 단계만 명확하게 잡혀 있으니 관리가 훨씬 예측 가능해졌다.

글 작성 → git commit → git push → Cloudflare Pages 자동 빌드 → 배포 완료

디자인 자유도도 확실히 커졌다. 티스토리에서는 기존 틀을 비틀어 쓰는 느낌이었다면, Astro에서는 처음부터 내가 원하는 구조를 만들 수 있다. 레이아웃, 코드 블록 스타일, 목차, SEO 메타 태그, 오픈 그래프 이미지, 카테고리 구조, 다국어 대응 같은 것들도 전부 내가 이해하는 범위 안에서 직접 구성할 수 있다. 누가 허용해 준 범위 안에서 꾸미는 게 아니라, 내가 필요한 범위를 직접 정의하는 쪽에 더 가깝다.

이건 단순히 보기 좋은 사이트를 만드는 문제만은 아니다. 블로그 글마다 메타 정보를 정확히 붙이고, 글 타입에 맞는 구조화 데이터를 넣고, sitemap이나 RSS 같은 기본 요소를 깔끔하게 관리할 수 있다는 건 SEO 관점에서도 꽤 크다. 플랫폼 블로그에서는 제공되는 범위 안에서만 최적화를 해야 했다면, 지금은 내가 중요하다고 생각하는 지점을 직접 손볼 수 있다.

이 과정에서 Codex CLI, Claude Code, Gemini CLI의 도움도 꽤 많이 받았다. 처음 레이아웃 방향을 잡을 때는 어떤 정보 구조가 읽기 좋은지 같이 정리해 보고, CSS를 만질 때는 원하는 분위기를 설명하면서 시안을 빠르게 뽑아 보고, 세부 컴포넌트를 다듬을 때는 반복 작업을 줄이는 식으로 활용했다. 메타 태그나 구조화 데이터처럼 빠뜨리기 쉬운 부분을 점검할 때도 이런 도구들이 생각보다 유용했다.

물론 최종 결과를 그대로 복붙해서 끝낸 건 아니다. 중요한 건 내가 원하는 구조와 톤을 먼저 정하고, 그다음에 AI 도구들을 보조 인력처럼 붙여서 속도를 올리는 방식이었다. 혼자 처음부터 끝까지 다 짜는 것보다 훨씬 빠르게 여러 시안을 비교할 수 있었고, 특히 블로그처럼 디자인과 구현과 문서 구성이 한꺼번에 얽히는 작업에서는 이런 CLI 도구들의 도움을 꽤 많이 체감했다.

심리적으로도 차이가 있다. 예전에는 블로그 운영이 어느 순간부터 플랫폼의 빈칸을 메우는 작업처럼 느껴질 때가 있었다. 지금은 오히려 내가 원하는 사이트를 조금씩 다듬어 가는 프로젝트에 가깝다. 글을 쓰는 일과 사이트를 관리하는 일이 같은 저장소 안에서 연결되니, 블로그 전체를 하나의 작업물처럼 다루게 된다.

대신 편한 길은 아니다

물론 이 방식이 무조건 더 낫다고 말할 수는 없다. 티스토리는 글을 쓰는 사람에게 필요한 많은 것을 이미 제공한다. 댓글, 방문 통계, 관리자 UI, 발행 흐름 같은 것들이다. 반면 Astro self hosting으로 오면 이런 것들을 직접 선택하고, 직접 붙이고, 직접 유지해야 한다. 플랫폼이 대신해 주던 일을 스스로 감당하는 구조다.

즉, 편의성은 줄고 책임은 늘어난다.

글만 빠르게 발행하고 싶다면 플랫폼 블로그가 더 편하다.
배포나 도메인, 이미지 경로, SEO 같은 걸 신경 써야 한다.
사소한 디자인 수정도 결국 내가 해야 한다.
댓글이나 통계처럼 부가 기능도 따로 붙이거나 포기해야 한다.

이건 분명한 비용이다. 글 하나 쓰고 바로 발행하는 감각만 보면 티스토리가 더 쉽다. 에러가 나면 내가 봐야 하고, 배포가 꼬이면 내가 고쳐야 하고, 스타일이 이상하면 내가 CSS를 뜯어봐야 한다. 블로그를 정말 “글만 쓰는 공간”으로 쓰고 싶다면 이런 방식은 오히려 번거롭다.

그래도 내 경우에는 이 단점이 크게 치명적이지 않았다. 애초에 내가 원한 건 손쉬운 발행 시스템보다, 오래 굴려도 질리지 않는 내 작업 공간에 가까웠기 때문이다. 편의를 조금 잃더라도 통제권과 장기적인 안정성을 얻는 쪽이 더 중요했다.

정리

티스토리에서 Astro self hosting으로 옮긴 건, 단순히 플랫폼 하나를 바꾼 일이 아니었다. 내 글을 어디에, 어떤 방식으로 쌓을 것인가에 대한 기준을 다시 정한 일이었다. 이전에는 플랫폼이 제공하는 공간 안에서 글을 써 왔다면, 이제는 내가 관리하는 저장소와 배포 환경 위에 콘텐츠를 직접 쌓아 가고 있다.

물론 당장의 편의성만 놓고 보면 티스토리가 더 쉬운 순간도 분명 있다. 관리 화면에서 바로 글을 쓰고 발행하는 흐름은 여전히 강력하다. 하지만 그 편리함 뒤에는 플랫폼 정책을 그대로 받아들여야 한다는 조건이 붙는다. 내 경우에는 강제 광고 삽입, 동영상 업로드 기능 폐지, 그리고 계속 누적되던 제약들이 그 조건을 더 이상 감수하기 어렵게 만들었다.

지금은 훨씬 덜 답답하다. 글은 Markdown으로 관리하고, 페이지는 Cloudflare Pages에 배포하고, 이미지와 영상은 Cloudflare R2로 분리해서 운영한다. 디자인과 구조는 내가 원하는 방향으로 다듬고, 필요하면 Codex CLI, Claude Code, Gemini CLI 같은 도구의 도움을 받아 속도를 올릴 수도 있다. 무엇보다 중요한 건, 이제 이 블로그의 성격을 내가 정할 수 있다는 점이다.

아직 완전히 정착했다고 말하기는 이르다. 운영하다 보면 또 다른 귀찮음도 분명 생길 것이다. 그래도 적어도 지금 기준으로는, 티스토리로 돌아갈 이유보다 여기 남아 있을 이유가 더 많다. 블로그를 오래 가져갈 생각이라면, 그리고 플랫폼 제약이 점점 거슬리기 시작했다면, 이런 식의 정적 사이트 이전은 충분히 고려할 만한 선택지라고 생각한다.