고스트 블로그를 두 달 만에 떠나 Astro로 옮긴 이유
고스트 블로그를 약 두 달 운영한 뒤 Astro로 이전했습니다. 고스트의 장단점과 이미지 관리 문제, AI를 활용한 마이그레이션 경험을 정리합니다.
약 두 달 전, 다른 사람이 운영하는 고스트(Ghost) 블로그를 우연히 본 적이 있습니다. 글과 여백만 남긴 듯한 간결한 디자인이 마음에 들었습니다. 평소 미니멀한 웹사이트를 좋아했고, 운영 중인 도메인 이름도 minml이니 잘 어울릴 것 같았습니다.
그렇게 고스트를 공부하기 시작했습니다. 서버를 준비하고 설치하는 과정은 인공지능의 도움을 받았습니다. 당시에는 직접 블로그를 구축했다는 사실도 만족스러웠고, 결과물 역시 마음에 들었습니다. 설치 직후 남긴 첫인상에서도 가장 좋았던 점은 깔끔함이었습니다. 이 글에는 그 첫인상부터 약 두 달간 운영한 뒤의 결론까지 한 흐름으로 합쳐 기록했습니다.
그런데 지금 이 블로그는 더 이상 고스트로 운영되지 않습니다. 약 두 달 동안 사용한 뒤 모든 글을 Astro로 옮겼습니다. 고스트가 형편없는 도구라서가 아닙니다. 여러 웹사이트를 운영하고 인공지능을 계속 사용하면서, 제게는 CMS를 유지하는 것보다 필요한 사이트를 직접 만드는 방식이 더 잘 맞는다는 결론을 내렸기 때문입니다.
고스트의 깔끔함은 여전히 좋았습니다
고스트를 사용하면서 가장 만족스러웠던 부분은 처음과 끝까지 디자인이었습니다. 기본 테마부터 관리자 화면과 글쓰기 화면까지 전체적으로 정돈되어 있습니다. 워드프레스처럼 플러그인과 설정 메뉴가 계속 늘어나는 느낌도 적었습니다.
글을 발행하는 과정도 어렵지 않았습니다. 관리자 화면에 접속해 제목과 본문을 작성하고 대표 이미지를 넣으면 됩니다. 블로그 운영에 필요한 기본적인 기능이 하나의 시스템 안에 준비되어 있다는 점은 분명한 장점입니다.
처음 관리자 화면을 열었을 때는 왼쪽에 필요한 메뉴만 정리되어 있고 글쓰기 화면에는 흰 여백이 넉넉한 점이 특히 마음에 들었습니다. 처음 접했는데도 어디에서 글을 쓰고 발행해야 하는지 바로 알 수 있었습니다. minimal에서 이름을 따온 minml과도 잘 어울린다고 느꼈고, 화려한 위젯보다 글에 집중하고 싶었던 당시의 목적에는 정확히 맞았습니다.
그래서 고스트를 떠났다고 해서 처음 느꼈던 장점까지 부정하고 싶지는 않습니다. 코드를 직접 다루지 않으면서 미니멀한 블로그를 운영하고 싶다면 지금도 충분히 매력적인 선택이라고 생각합니다.
가장 큰 문제는 익숙하지 않다는 것이었습니다
운영하면서 느낀 가장 큰 불편함은 고스트에 관한 정보가 많지 않다는 점이었습니다. 워드프레스는 문제가 생기면 같은 상황을 겪은 사람의 글이나 영상을 쉽게 찾을 수 있습니다. 반면 고스트는 국내 자료가 많지 않았고, 원하는 설정 하나를 바꾸려 해도 정확한 답을 찾기가 쉽지 않았습니다.
물론 인공지능에게 물어보면 상당 부분 해결할 수 있습니다. 저 역시 설치부터 설정까지 AI의 도움을 많이 받았습니다. 다만 익숙하지 않은 시스템을 계속 유지해야 한다는 부담은 남았습니다. 서버에서 무엇이 실행되고 있는지, 업데이트나 백업은 어떻게 해야 하는지, 문제가 생겼을 때 어느 부분부터 확인해야 하는지를 매번 새로 알아봐야 했습니다.
고스트만의 문제라기보다는 제가 고스트에 익숙하지 않았기 때문에 생긴 불편함에 가깝습니다. 하지만 개인 블로그 하나를 운영하기 위해 계속 새로운 운영 방식을 익혀야 한다면, 더 단순한 선택지를 찾게 되는 것도 자연스러운 일이었습니다.
이미지 한 장을 올렸는데 파일은 여러 개였습니다
이전을 준비하면서 의외였던 부분은 이미지였습니다. 글마다 대표 이미지를 한 장씩 올렸다고 생각했는데, 서버에는 같은 이미지를 여러 크기로 변환한 파일이 함께 저장되어 있었습니다.
반응형 화면에서 적절한 크기의 이미지를 제공하기 위한 구조라는 것은 이해합니다. 불필요하게 복제된 오류 파일은 아닙니다. 하지만 직접 백업하고 정리하는 입장에서는 예상보다 많은 파일이 보이니 구조가 복잡하게 느껴졌습니다.
이미 업로드한 이미지를 관리 화면에서 미디어 라이브러리처럼 찾아 다른 글에 다시 사용하는 방식도 제가 기대했던 것과 달랐습니다. 서버에는 파일이 있는데 글을 작성할 때 편하게 다시 선택하기는 어려웠습니다. 예전에 고스트 대표 이미지 크기를 조절하는 과정에서도 느꼈지만, 간단해 보이는 화면 뒤의 구조까지 제게 간단한 것은 아니었습니다.
여러 사이트를 만들면서 생각이 달라졌습니다
결정적으로 마음이 바뀐 것은 다른 웹사이트도 함께 운영하면서부터입니다. 인공지능 코딩 도구를 이용해 사이트를 만들고 수정하는 경험이 쌓이자, 블로그도 필요한 형태로 직접 만드는 편이 더 깔끔하겠다는 생각이 들었습니다.
처음에는 Next.js와 Astro를 두고 고민했습니다. 어떤 것을 선택해야 할지 Claude에게 사이트의 목적을 설명했고, 글을 중심으로 운영하는 정적 블로그에는 Astro가 잘 맞는다는 추천을 받았습니다. 복잡한 사용자 기능이나 실시간 데이터 처리가 필요한 서비스가 아니라면, 처음부터 무거운 구조를 선택할 이유가 없다는 설명도 납득됐습니다.
Astro는 글과 페이지를 미리 HTML 파일로 만들어 배포할 수 있습니다. 방문자가 페이지를 열 때마다 데이터베이스에서 내용을 꺼내 조립할 필요가 없습니다. 블로그처럼 내용이 자주 바뀌지 않는 사이트에는 이런 방식이 잘 맞았습니다.
AI가 있으니 이전이 크게 두렵지 않았습니다
예전이었다면 사용 중인 블로그를 다른 방식으로 옮기는 일은 쉽게 결정하지 못했을 것입니다. 글과 이미지가 사라질 수도 있고, 기존 주소가 달라져 검색 노출에 문제가 생길 수도 있습니다. 서버 설정을 잘못 건드려 사이트 전체가 열리지 않을 가능성도 있습니다.
이번에는 인공지능에게 하나씩 확인하면서 진행했습니다. 먼저 고스트의 글과 설정, 데이터베이스, 이미지 파일을 백업했습니다. 그다음 기존 글의 주소를 유지한 채 Astro 콘텐츠로 변환하고, 페이지와 이미지가 제대로 연결되는지 검사했습니다.
실제로 진행한 순서는 다음과 같습니다.
- 고스트 콘텐츠, 데이터베이스, 이미지와 설정을 별도로 백업했습니다.
- 글의 제목, 본문, 발행일, 작성자와 기존 주소를 Astro 콘텐츠로 옮겼습니다.
- 본문과 대표 이미지가 가리키는 파일을 로컬에 보관했습니다.
- 이전 주소가 그대로 열리는지 빌드 결과를 검사했습니다.
- 새 사이트가 정상 동작하는 것을 확인한 뒤에만 기존 서비스를 정리했습니다.
검사 결과 이전된 글 18편과 고정 페이지 3개가 확인됐습니다. 생성된 HTML 28개와 내부 경로 32개, 로컬 이미지 대상 20개도 실제 파일과 연결되는지 확인했습니다. 글 개수만 맞는지 보는 데서 끝내지 않고 주소와 이미지까지 검사한 이유는 이전 후 뒤늦게 깨진 페이지를 발견하고 싶지 않았기 때문입니다.
오히려 가장 신경 쓴 부분은 이전이 끝난 뒤였습니다. 기존 고스트 데이터와 서비스, 데이터베이스, 계정 등이 서버에 애매하게 남아 있는 것을 원하지 않았습니다. 필요한 내용은 로컬과 서버에 백업하고, 더 이상 사용하지 않는 구성은 확인한 뒤 정리했습니다.
인공지능이 모든 일을 자동으로 해결해준 것은 아닙니다. 무엇을 남기고 무엇을 지울지는 결국 제가 결정해야 했습니다. 다만 모르는 명령과 구조를 설명받고, 작업 순서를 점검할 수 있었기 때문에 이전 자체를 두려워하지 않을 수 있었습니다.
Astro로 옮긴 뒤 달라진 점
현재까지는 Astro로 옮긴 뒤 불편한 점이 없습니다. 사이트는 빠르고 디자인도 마음에 듭니다. 무엇보다 블로그의 실제 구조가 단순해졌습니다.
글은 파일로 보관되고, 사이트는 정적 파일로 만들어집니다. 이전처럼 블로그를 보여주기 위해 별도의 데이터베이스와 관리자 프로그램이 계속 실행될 필요가 없습니다. 디자인을 바꾸고 싶을 때도 테마가 허용하는 범위에 맞추기보다 원하는 구조를 직접 수정할 수 있습니다.
| 운영 항목 | 고스트를 쓸 때 | 현재 Astro 구조 |
|---|---|---|
| 글 저장 | 고스트 데이터베이스와 콘텐츠 저장소 | 프로젝트 안의 Markdown 파일 |
| 방문자에게 페이지 제공 | 실행 중인 고스트 애플리케이션 | 빌드 때 만들어진 정적 HTML |
| 글 작성 | 관리자 화면 | 로컬 콘텐츠 파일 |
| 디자인 변경 | 테마 구조 안에서 수정 | 사이트 구성 요소와 CSS 직접 수정 |
| 멤버십·뉴스레터 | 기본 기능 활용 가능 | 필요하면 별도 도구 연결 |
이는 Astro가 고스트보다 항상 우월하다는 비교가 아닙니다. 고스트는 콘텐츠 API를 이용해 헤드리스 CMS로도 사용할 수 있고, 멤버십과 뉴스레터처럼 제가 쓰지 않는 기능도 제공합니다. 반면 minml은 글 중심의 작은 개인 사이트라서 콘텐츠 파일과 정적 HTML만으로 충분했습니다.
물론 누구에게나 이 방식이 편한 것은 아닙니다. Astro에는 고스트처럼 완성된 관리자 화면이 기본으로 제공되지 않습니다. 파일을 직접 다루거나 배포 과정을 이해해야 하고, 뉴스레터나 멤버십 기능이 필요하다면 별도의 도구를 연결해야 합니다.
저는 이미 인공지능 코딩 도구로 다른 사이트를 관리하고 있었기 때문에 이 부분이 불편하지 않았습니다. 오히려 사용하지 않는 기능까지 포함된 CMS를 유지하는 것보다 필요한 것만 있는 현재 구조가 더 편합니다.
그렇다면 고스트는 누구에게 맞을까
고스트를 다시 사용할 생각은 없지만, 모든 사람에게 Astro를 권하고 싶지는 않습니다. 다음과 같은 사람이라면 고스트가 더 편할 수 있습니다.
- 미니멀한 디자인의 블로그를 빠르게 시작하고 싶은 사람
- 관리자 화면에서 바로 글을 작성하고 발행하고 싶은 사람
- 뉴스레터, 구독자 또는 멤버십 기능을 함께 사용하려는 사람
- 파일과 배포 과정을 직접 관리하고 싶지 않은 사람
반대로 웹사이트를 직접 만들어보고 싶었거나, AI 코딩 도구를 활용할 의향이 있다면 Astro 같은 정적 사이트 방식도 고려할 만합니다. 예전보다 진입장벽이 확실히 낮아졌습니다.
이제는 CMS가 꼭 필요하지 않을 수도 있습니다
티스토리, 워드프레스, 고스트처럼 이미 만들어진 플랫폼을 선택하면 빠르게 글을 시작할 수 있습니다. 저 역시 여러 플랫폼을 직접 사용했고, 각각의 장단점을 블로그 플랫폼 비교 글에 정리한 적이 있습니다.
하지만 지금 다시 블로그를 시작한다면 저는 처음부터 웹사이트를 직접 만드는 쪽을 선택할 것 같습니다. ChatGPT나 Claude 같은 도구에 원하는 모습을 설명하고, 모르는 부분을 물어보며 하나씩 만들어갈 수 있기 때문입니다.
진입장벽이 전혀 없다는 뜻은 아닙니다. 문제가 생겼을 때 내용을 읽고 판단해야 하며, 백업과 도메인 같은 기본적인 운영 책임도 직접 져야 합니다. 그럼에도 예전처럼 개발 지식이 없다는 이유만으로 시도조차 못 할 정도는 아니라고 생각합니다.
저 역시 인공지능이 없었다면 고스트를 설치하지도, Astro로 이전하지도 못했을 것입니다. 그런데 고스트를 만들게 도와준 인공지능이 결국 고스트를 떠날 수 있게 해줬습니다.
약 두 달 만에 플랫폼을 바꾸게 될 줄은 몰랐습니다. 다만 직접 사용해보고 옮겨본 덕분에 지금은 원하는 블로그의 모습이 더 분명해졌습니다. 제게 필요한 것은 기능이 많은 블로그 도구가 아니라, 빠르고 단순하며 원하는 대로 바꿀 수 있는 웹사이트였습니다.
참고한 공식 문서