Claude Code로 프레이머 블로그 옮기기

프레이머로 블로그를 만든 지 어느새 3년이 지났습니다. 사용법부터 운영 후기, 검색 노출까지 3부작으로 정리하고 회사에도 도입할 만큼 잘 쓰던 툴인데요. 얼마 전 이 블로그를 프레이머에서 Astro와 Cloudflare Pages로 옮겼습니다. 코드를 모르는 제가 Claude Code와 대화하면서 옮겼고, 글 주소는 그대로 유지했습니다.

이번 글에서는 프레이머를 쓰면서 아쉬웠던 점과 어떤 과정으로 옮겼는지, 옮기고 나서 불편해진 점과 지금 블로그가 어떤 상태인지까지 공유해 보려고 합니다.

왜 프레이머에서 옮겼나요

제가 그동안 프레이머를 쓴 이유는 디자인이 편리하고 에디터가 있어서였습니다. 코드를 몰라도 디자인한 그대로 사이트를 만들 수 있었기 때문에 비개발자인 제가 블로그를 시작할 수 있었어요. 그런데 지난 3개월 동안 회사에서 Claude Code로 일하다 보니 블로그 정도는 에디터 없이도 만들 수 있지 않을까 하는 생각이 들어서 이렇게 물어봤습니다.

“그동안 프레이머를 사용한 이유는 디자인이 편리하고 에디터가 있어서 사용했던 거지만, 이제는 클로드 코드가 있어서 간단하게 구현할 수 있을 것 같거든. SEO를 유지하면서 옮길 수 있는 방법 있을까?”

여기에 3년 동안 프레이머를 쓰면서 아쉬웠던 점들도 있었습니다.

구독료

개인 블로그에 제 도메인을 쓰려면 유료 요금제가 필요했고, CMS까지 유지하려면 Basic 요금제를 써야 했습니다. (2편에 자세히 정리해 두었어요. 지금 요금제는 달라졌을 수 있습니다.) 도메인 비용과 별도로 구독료가 나가는데, 마지막 글을 쓴 지 1년이 다 되어 가는 동안에도 구독료는 계속 나가고 있었습니다.

코드가 필요한 순간들

리멤버 도입기에도 적었듯이 프레이머는 완전한 노코드 툴이 아니라서, CMS 본문에 고급 스타일을 입히거나 데이터 추적을 위한 기능을 넣으려면 코드를 작성해야 합니다. 저처럼 코드를 모르면 그 앞에서 멈출 수밖에 없었어요.

RSS도 그중 하나였습니다. 3편에서 네이버 서치어드바이저에 사이트를 등록할 때 RSS 주소를 요구했는데, 프레이머에 문의해도 당분간 지원하지 않는다는 답을 받아서 그 단계를 건너뛰었습니다. 옮기기 직전에 확인했을 때도 제 사이트에는 RSS 주소가 없었습니다.

에디터에서는 보이지 않는 것들

옮기는 과정에서 실제로 나가는 HTML도 같이 들여다봤는데요. 아직 남아 있는 프레이머 게시본과 지금 사이트를 같은 주소로 열어 비교해 보면 이런 차이가 있습니다.

• AS-IS (프레이머)

  • 글 페이지 HTML 704KB

  • 홈의 h1 제목 3개

  • 구조화 데이터와 RSS 피드 없음

• TO-BE (지금)

  • 글 페이지 HTML 56KB

  • 홈의 h1 제목 1개

  • 구조화 데이터와 RSS 피드 있음

홈의 h1이 3개인 건 프레이머 탓이라기보다 제가 그렇게 만든 탓일 테고, 구조화 데이터도 코드를 넣으면 추가할 수 있었을 겁니다. 다만 에디터 화면만 봐서는 알아채기 어려운 부분들이었어요.

어떻게 옮겼나요

전체 작업은 10월 29일부터 11월 6일까지 9일 동안(실제로 작업한 날은 6일) 진행했고, 코드와 글을 바꾼 커밋은 이 글을 올리기 전까지 35번입니다. 다만 이사 자체는 첫날 밤에 끝났고, 나머지는 옮긴 김에 고친 시간이었습니다.

어디로 옮길까?

Claude가 Astro를 추천하길래 “추천하는 이유는? 더 좋은 프레임워크는 없어?”라고 물어보니 Next.js, Hugo, Eleventy, Jekyll과 비교한 표를 보여 줬는데요. 기술을 비교할 지식은 없으니 제 상황에서 무엇이 달라지는지 위주로 들었고, 블로그와 포트폴리오 위주라면 Astro가 맞다는 설명을 듣고 그대로 가기로 했습니다.

배포는 무료로 쓸 수 있고 GitHub에 올리면 자동으로 배포되는 Cloudflare Pages를 쓰기로 했습니다. 시각 에디터가 없다는 점이 한계로 나왔는데, Claude Code 앱 안에서 미리보기를 띄워 두고 보면서 수정하면 될 것 같아서 크게 문제 삼지 않았습니다.

정리하면 프레이머에서 하던 일은 이렇게 바뀌었습니다.

• 화면을 보면서 디자인하기 → 미리보기를 띄워 두고 말로 고치기

• CMS 에디터로 글 관리하기 → 글을 마크다운 파일로 관리하기

• Publish 버튼으로 배포하기 → GitHub에 올리면 자동으로 배포하기

디자인은 일단 그대로

디자인도 바꾸고 싶었지만 이사와 디자인 개편은 나눠서 하기로 했습니다. 둘을 같이 바꾸면 검색 순위가 흔들렸을 때 무엇 때문인지 알 수 없다는 이유였어요. 그래서 처음에는 지금 디자인을 그대로 복제하고, 글 주소와 제목, 설명, 공유 이미지도 그대로 옮겼습니다.

코드를 읽지 못하는 제가 똑같이 옮겨졌는지 확인하는 방법은 화면과 숫자뿐이었는데요. AI가 원본과 새 사이트의 글 본문을 블록마다(글 하나에 54개가 나오기도 했어요) 높이와 위치까지 비교했고, 저는 브라우저에 띄운 화면을 보면서 “인터랙션을 제외하면 대부분 비슷하게 구현된 것 같아”라고 확인한 뒤 다음 단계로 넘어갔습니다.

도메인 전환

문제가 생기면 바로 되돌릴 수 있도록 프레이머 구독을 해지하지 않은 채로 주소만 새 사이트로 돌렸습니다. DNS 설정 하나만 되돌리면 몇 분 안에 복구할 수 있습니다.

여기서부터는 낯선 단어의 연속이었는데요. Cloudflare 계정은 처음 만들었고, 네이버 서치어드바이저의 사이트맵 칸에 홈 주소를 넣고는 왜 형식 오류가 나는지 물어보기도 했습니다.

계정을 만들거나 권한을 허용하는 일은 제가 하고, 나머지는 브라우저 화면을 함께 보면서 하나씩 진행했습니다. 그렇게 밤 10시 38분에 말을 꺼내고 두 시간쯤 뒤에는 네이버 등록까지 끝낼 수 있었습니다.

옮긴 김에 업데이트한 것들

디자인 개편

이사가 끝나고 며칠 뒤 디자인을 바꿨습니다. 코드를 고치기 전에 실제 글과 썸네일로 만든 시안을 먼저 받아서, 배경 톤과 메인 문구를 고른 뒤에 적용했어요.

시안에는 지금 블로그의 문제점도 같이 적혀 있었는데요. 프레이머 시절 홈의 ‘featured articles’처럼 베이지 배경에 올린 노란 글자는 명도 대비가 약 1.3:1밖에 되지 않아서 거의 보이지 않았습니다. 그래서 노랑은 글자색으로 쓰지 않고 형광펜과 활성 탭의 배경으로만 쓰기로 했습니다.

시안이 다 마음에 들었던 건 아닙니다. 글 상세의 인용문이 둥근 상자에 노란 왼쪽 선을 둔 모양이었는데, 어딘가 AI가 만든 디자인 같아서 다시 제안해 달라고 했습니다. 그렇게 상자와 색 선을 빼고 지금처럼 글자 크기만 키운 인용문으로 바꿨어요.

적용한 뒤에는 직접 눌러 보면서 눈에 걸리는 곳을 계속 말했습니다. 이런 건 제가 말하기 전까지 AI가 먼저 짚어 주지 않더라고요.

• “글 상세를 실제로 확인하니까 중앙 정렬이 맞지 않는 것 같아.”

• “Work, Insight 페이지에 진입했을 때 상단 영역이 홈과 동일해서 페이지가 이동된 건지 인지하기 어려운 것 같아.”

• “화면마다 푸터의 위치가 다른 게 어색한 것 같아.”

RSS 구독 페이지

프레이머에서 못 했던 RSS는 옮기면서 바로 생겼는데요. 막상 헤더의 RSS 버튼을 눌러 보니 화면 가득 코드만 보였습니다. 물어보니 피드 파일은 원래 그렇게 보이는 것이고 고장 난 게 아니라고 하는데, 방문자 입장에서는 뭘 해야 할지 알 수가 없겠더라고요.

그래서 버튼을 누르면 구독 방법을 알려 주는 구독 안내 페이지가 나오도록 바꾸고, 설명도 IT에 익숙하지 않은 사람이 이해할 수 있는 말로 고쳤습니다. 이제 피드 주소를 직접 열어도 안내가 보입니다. (많은 구독 부탁드려요…🫶)

검색 노출과 글 정리, 영문 버전

그 밖에도 검색에서 빠져 있던 About 페이지를 열고, 글마다 구조화 데이터를 넣고, 설명 문구와 이미지 대체 텍스트를 다시 썼습니다. 블로그 초반에 올릴 글이 없어서 올렸던 글 2개는 내리고, 리멤버 테크 블로그에 썼던 글 3편은 옮겨 왔습니다.

글이 파일로 관리되니 여러 글을 한꺼번에 손보기도 쉬워져서 글 13개의 오타와 소제목을 한 번에 점검해서 고쳤고요. 외국인 독자에게도 블로그를 보여 주고 싶어서 영문 버전과 번역 글 3편도 추가했습니다.

옮기고 나서 불편해진 점

간격을 말로 설명해야 합니다

모바일에서 메뉴 간격을 넓혀 달라고 했더니 다른 곳의 간격이 바뀌어서 다시 말해야 했고, 넓힌 뒤에는 너무 넓어서 한 번 더 말해야 했습니다. 프레이머였다면 손으로 끌어서 바로 맞췄을 간격이에요.

속도는 직접 챙겨야 합니다

HTML이 가벼워졌으니 빨라졌겠거니 했는데, 디자인 개편 직후 PageSpeed를 재 보니 모바일 성능이 50점이었습니다. 처음 방문할 때 화면이 통째로 한 번 밀리는 문제(CLS 1.002)가 있었고, 새 사이트의 스크립트 위치 때문이었어요. 이걸 고치니 74점이 됐고, 광고가 채워지지도 않으면서 약 285KB를 쓰던 애드센스 스크립트까지 걷어내니 88점이 됐습니다. (프레이머 시절 점수를 재 두지 않아서 직접 비교는 하지 못합니다.)

챙겨야 할 곳이 늘었습니다

리멤버 도입기에서 프레이머의 장점으로 ‘올인원’을 꼽았는데요. 프레이머 안에서 끝나던 일이 지금은 이렇게 나뉘었습니다. (도메인, GA, 서치 콘솔은 프레이머를 쓸 때도 따로 관리하던 곳이라 그대로입니다.)

• GitHub: 글과 코드 보관, 변경 기록

• Cloudflare Pages: 호스팅과 배포, DNS

• Astro와 Node: 프레임워크와 실행 환경의 버전 관리

Astro를 새 버전으로 올리려면 제 컴퓨터의 Node부터 올리고 Cloudflare 설정도 바꿔야 했고, 어느 날은 배포가 15분 넘게 ‘진행 중’에서 멈춰서 다시 배포하기도 했습니다. 전환 직후에 점검해 보니 주소가 아직 프레이머로 연결되어 있어서 확인이 더 필요했던 일도 있었고요. (설정이 퍼지는 데 시간이 걸린 것으로 보입니다.)

혼자 쓰는 블로그라 감수할 수 있는 일이지만, 여러 사람이 직접 콘텐츠를 고치는 회사 사이트였다면 저는 여전히 프레이머를 먼저 떠올릴 것 같습니다.

코드를 못 읽으니 결과로 확인합니다

올리기 전에 미리보기에서 보고, 큰 변경 전후로는 페이지를 비교하고, 배포한 뒤에는 실제 사이트를 다시 확인했습니다. 배포도 제가 확인한 뒤에만 하도록 했고, 다음 세션이 이어받을 수 있게 할 일과 결정한 내용은 작업 인계 문서에 남겼어요.

지금 블로그 상태

• 글: 이 글까지 14개, 영문 번역 3편

• 비용: 호스팅과 저장소는 무료, 도메인 비용만 냅니다. (Claude 사용료는 따로 들지만 블로그만을 위해 쓰는 건 아닙니다.)

• 속도: 마지막으로 잰 11월 3일 기준 PageSpeed 모바일 성능 88점, 접근성·권장사항·SEO 100점

• 검색: 주소를 바꾸지 않고 사이트맵을 다시 제출했고, 색인이 유지되는지 지켜보는 중

• 프레이머 구독: 색인에 문제가 없는지 확인한 뒤 해지할 예정이라 아직 유지 중

아직 해야 할 일도 남아 있습니다. 삭제한 글의 주소 하나가 아직 열리고 있어서 며칠 뒤 다시 확인해야 하고, RSS에 글 전문을 넣을지도 정해야 합니다.

글 마무리

옮겨 보니 주소가 그대로인지, 화면이 의도대로인지, 방문자가 무엇을 해야 할지 알 수 있는지는 코드를 몰라도 확인할 수 있었고, 혼자 운영하는 블로그에는 그 정도로 충분했습니다. 다만 프레이머가 해주던 일을 직접 챙겨야 하니, 혼자 운영하고 글이 중심인 블로그라면 한번 고려해 볼 만한 방법 정도로 봐 주시면 좋겠습니다.

3년 전 1편을 ‘블로그를 만들면서 가장 중요한 것은 결국 콘텐츠 작성’이라는 말로 마쳤는데요. 9일 동안 블로그를 이만큼 고쳐 놓고 보니, 이 블로그를 위해 새로 쓴 글은 이 글이 딱 1년 만이네요.

긴 글 읽어주셔서 감사합니다!