3줄 요약

velog 기반 블로그, jekyll 제네레이터 기반 블로그 운영에 한계를 느꼈다.
AI 의 도움을 받아서 커스텀 블로그를 만들었다.
원하던 기능을 다 구현해서 상당히 만족스럽다.

블로그 마이그레이션

블로그를 이번에 새로운 시스템으로 변경했다.

처음 velog 로 개발용 블로그를 시작한 이후, jekyll 기반 블로그로 바꾼 후 나름대로 1년 정도 잘 써왔다.
하지만, jekyll 블로그 운영에 불편함을 느끼고 AI 와 함께 직접 구축하기로 마음을 먹었다.

Velog 의 문제점

제일 처음 사용했던 Velog 의 문제점이라면? 솔직히 큰 문제는 없었다.
민트색 베이스의 스타일도 그렇고, 다른 사람들의 아티클도 쉽게 볼 수 있는 게 마음에 들었다.

하지만, 가장 큰 문제가 있었다. velog 서버의 상태에 영향을 받았다.
예를 들어, 내가 자신있게 이력서에 블로그 링크, 회고 링크 를 걸어서 멘션 했다고 해보자.
면접관이 이력서를 보고 클릭하려고 할 때 503(Service Unavailable) 이 떠있다면...?

놀랍게도 이는 사실이다..

그리고, 프로바이더를 사용하는 이상 나에게 부족한 부분들이 존재했다.

단순 게시글 및 카테고리나 아니라 다른 영역의 글들을 올리고 분류하고 싶었다. (가벼운 지식, 비개발 내용)
테마 변경 및 커스터마이징을 하고 싶다.
블로그 전체 대시보드, 통계 내역을 보고 싶다.

이런 문제점들을 기반으로 회사에 들어간 후 내 커스텀 블로그를 만들어나갔다.

Jekyll 의 한계

Jekyll 을 사용한 이유는 명확했다.

내가 큰 노력을 들이지 않고도, 고수준의 디자인 및 시스템을 사용할 수 있다는 것이었다.
추가로, 내가 원한다면 디자인 및 기능들도 커스터마이징 할 수 있었다.
(깃허브 기반 + Github Pages 를 통해 내가 산 도메인을 직접 연결할 수 있는 게 큰 장점이었다.)

물론, 'Github Pages 도 다운될 수 있지 않나?' 라고 하면 할말은 없다.
단지 그때 당시 Velog 가 다운이 되는 일이 좀 있었고, 나는 github 정도면 좀 더 안전하겠지? 라고 생각했다.
+ 오픈소스이기에 마음만 먹으면 Github Pages 말고도 빌드 및 배포를 할 수 있는것도 장점

나름대로 잘 꾸며가고 만족했다.
하지만, 어느순간 한계점이 느껴지는 부분들이 있었다.

커스터마이징이 생각보다 쉽지않다.

게시글, 메인 페이지, 섹션, 헤더 등 모든 css 및 스타일등이 chirpy 의 테마에 의존되어 있었다.
이런 요소를 수정하고 싶으면, chirpy github 의 특정 요소를 참고해서 수정해야 했다.
(layout.html, post.html, header.html ...)

근데, 내 저장소에는 이런 요소들이 다 저장이 되어있지 않는다.
(커스터마이징을 하지 않으면, 기존 starter 의 요소를 참고)

사실, 전혀 문제가 되지 않는 방식이다. 오히려 더 똑똑한 방법이기도 하고.
기본 테마를 따를건데 굳이 파일을 깃허브에 저장할 필요는 없다.

하지만, LLM 의 시대에서 이 방법은 매우 비효율적인 방법이 되어버렸다.

로컬에 관련 파일이 없다.

파일이 없는데, 수정하라고 하니 오동작을 내뱉게 된다.
인터넷 조회를 해도, 의도대로 가져오지 못하는 경우가 많다.

개개인의 세팅이 너무 다르다.

내가 원하는 기능이 구현되어 있나? 싶어서 찾아보면 자신만의 블로그마다 세팅하는게 너무 다양했다.

예를 들어, 영어 언어를 선택한 사용자라면 영어 게시글이 존재하면 보여주고 싶은 기능을 제공하려고 할 때

2개 정도의 확장 플러그인 깃허브 저장소를 참고해서 내가 선택해야 했다.
그리고, 이를 사용하는 가이드들도 매우 부실했다.

jekyll 은 커스텀 블로그 제네레이터다.
-> chirpy 는 jekyll 의 테마이다.
-> 그 테마의 확장 프로그램중 하나이다.
-> 소개하는 내용들마다 설정 방법들이 다르다. ☠️

물론, 위 내용들은 내가 jekyll + chirpy 테마를 잘 이해하지 못하고 사용해서 발생한 문제들일 수 있다.

백오피스 성 기능이 존재하지 않는다.

Velog 에는 사용자의 편의성을 향상시켜주는 백오피스성 기능들이 있었다.

게시글 작성 : 오른쪽 미리보기 제공, 썸네일 설정 및 소개글 작성
카테고리 관리
썸네일 선택

하지만, jekyll 은 내가 직접 에디터를 통해 마크다운의 frontmatter 를 수정해서 관리를 해야했다.
-> 많은 불편함과 관리의 어려움이 발생

이런점들을 github action 을 통해 일정 부분 해결하려고 했다.

LLM 을 통한 frontmatter 초안 작성
LLM 을 통한 썸네일 생성
LLM 을 통한 번역 및 게시글 발행 준비

그리고, 코드가 아닌데 에디터 및 파일들로만 관리하는게 큰 귀차니즘으로 다가왔다.

=> 결국, 관리의 분산 및 한계가 느껴지게 되었다.

커스텀 블로그 구축

LLM 의 발전속도가 너무나 빠르기에 프론트엔트를 전혀 몰라도
'원하는 기능들을 구현해주지 않을까?' 라는 생각과 함께 진행했다.

그리고, 결과는 90% 정도로 대만족인 것 같다.
10% 정도는 Spec 을 제공해줬음에도, 한번에 바로 완벽히 구현하지 못한 부분들이 있어서 뺐다.
(이벤트, 스타일, 디테일한 부분들)

일단 세팅은 가장 대중적인 스택으로 구성했다. Next.js + Vercel 조합으로 갔다.
AI 가 학습이 잘 되어있을거 같기도 하고, 차후 유지보수도 용이할 거 같다고 생각했다.

그리고, vercel 이 당장 무료로 제공해주는 옵션들이 나쁘지 않았다.

트래픽도 100GB 까지 허용
배포도 Github 연동에 Slack Integration
서버리스로 관리 불필요
그리고, 로그나 대시보드 정보 나름 자세히 제공
Preview 기능 제공 (github action 은 pages 를 한개만 제공해서 우회 방법을 사용해야 했다..)

vercel 을 사용할거니, next.js 가 좋다고 생각했고 (vercel 이 자동 감지)
API Route 나 이미지 최적화, 자유로운 랜더링등을 고려해 next.js 로 최종 결정했다.

구현의 흐름은 디자인은 차차 개선하기로 하고
PRD 형태로 기존 스타일의 마이그레이션 + 내가 원하는 기능들을 PLAN 모드로 설계한 후
Claude Code 로 명세 기반으로 작업을 시켰다.

토큰 Limit 땜에 쉬엄쉬엄 진행한 결과, 2일만에 얼추 내가 원하는 기능은 다 구현했고
틈틈히, 세세한 디테일들을 요청해서 개선해나갔다. 5일 정도 걸린듯??

Plan 을 요약하면

기존 스타일 및 기능
백오피스 기능
내가 원하는 대로 커스터마이징

의 기능들로 구성했다.

특히, 백오피스 기능을 많이 집중했다.

기존 스타일 및 기능

기존 기능들 자체는 마음에 들었던 터라 그대로 만들어달라고 했다.

왼쪽 Section
다크모드
사용자가 선택한 언어에 따른 언어별 포스트 제공
아카이브 / 카테고리 / 태그

백오피스

로컬에서 블로그 관리를 위한 기능들을 구현했다.

통계 및 SEO 관리를 위한 기능들
LLM 을 통해, 썸네일 생성 + 번역 + 리뷰
게시글 작성 및 수정 기능
옵시디언에서 Import, Export

기존에 github action 으로 하던, 번역 및 썸네일 생성을 백오피스에서 간편히 할 수 있게 했다.
그리고, gh CLI 를 통해 작성한 내역을 바로 커밋하거나 PR 을 생성해 배포를 할 수 있다.

커스터마이징

왼쪽 Section 에서 아티클, 서재, 노트, 활동은 기존 Jekyll 에는 없는 내가 추가한 요소들이다.
내가 필요하다고 느껴서 추가한 것들이다.

아티클 : 인상깊게 본 유투브, 테크 블로그 내용을 정리하기 위한 장소
서재 : 책, 영화, 음악, 삶의 경험에 대해 가볍게 작성하기 위한 장소 - 비개발 영역
노트 : 블로그에 올리는 내용은 깔끔해야만 한다는 강박감 해소 + Lean Learning 을 따르기 위한 장소
활동 : 장소와 추억을 기록하기 위한 장소 - 비개발 영역

검색에도 이런 요소들이 모두 검색되게 통합 검색 기반으로 구현했다.
나중에는 시맨틱 검색이나 유사도 검색도 시도를 해봐야겠다.

결론

아직까지, 제대로 안 돌아가는 부분들도 있을 수 있다.
계속해서 개선해나가는 부분들도 있고.

하지만, 원하는대로 기능을 구현할 수 있다는게 정말 엄청난 것 같다.
실행 비용이 줄어들었다는게 정말 체감이 된다.

예전에, 내가 만약 이걸 시도하려고 했다면?

typescript 및 next.js 에 대한 학습
사용해야 하는 라이브러리 탐색 및 기초 학습
구현 중 혹여나 에러 뜨면, 구글 검색 및 컴파일 노가다
스타일 일일히 조금씩 수정 및 세팅

으로 한 달이 넘게 걸렸을 수도 있다
나중에는 상상도 할 수 없이 또 발전이 되어있겠지...?

자신이 블로그 관리에 애정이 있거나, LLM 의 발전속도를 체감해보고 싶다면 이런 가벼운 프로젝트를 진행해봐도 좋을 것 같다.

마이그레이션 팁

팁이라면

자신이 원하는 블로그 테마부터 샘플링 (EX: 기존 블로그 스샷 및 주소 or 참고할 블로그 주소)
기반으로 기초 구조 구축 (페이크 데이터로 확인)
완료되면 이전 데이터들 형식에 맞게 마이그레이션
추가적인 기능 구현

마이그레이션 안 한 채로, 너무 많은걸 구현하면 마이그레이션 할 때 길을 잃을수도 있고
마이그레이션을 너무 빨리 하면, 매번 코드 변경에 전파가 될 수도 있다.

디자인은 다 끝나면 언제든 원큐에 끝날 수 있다고 생각한다.
처음부터 너무 이쁘게, 세세하게 만들어야한다고 스트레스를 받지는 말자.

마치며

그리고, 시도를 해보는게 가장 큰 성과이다! 자신감을 가지고 렛츠고