[Next.js 개발 블로그 제작 후기] 1. 착수
8min read
Background
이전 개발 블로그를 운영할 때 사용했던 서비스는 Github Pages였습니다. 많은 분들이 사용하시듯이, 정적 사이트 생성기로 Jekyll(minimal mistakes 테마)을 사용했었습니다. 블로그를 직접 제작하게 된 계기는 아래와 같습니다.
- Jekyll 빌드에 오류 생기면 트러블슈팅에 버리는 시간이 많아짐
- 스스로 요구사항을 만들고 해결할 수 있는지 점검
- 커스텀 가능한 페이지 제작
- 외부 서비스에 의존성 분리(?)
사실 1번 항목이 이 프로젝트에 박차를 가하는 데 결정적이었습니다.
부끄럽지만 블로그에 글을 작성하는 주기가 길어지다보니 그 사이에 로컬 Ruby 설정이 조금씩 바뀌었던 것인지,
로컬에서 잘 돌아가던 서버가 막상 원격 빌드에 실패해서, 도메인 주소를 입력하면 404만 뜨는 상황이었습니다.
(아마 rbenv 사용하고부터 빌드가 안되기 시작한 것 같습니다.)
이렇게 Ruby에 익숙하지 않은 문제로 버려지는 시간이 아까웠습니다. 글쓰기에도 시간이 부족한데 말이죠.
이참에 올해 다짐했던 새해 목표인 '개발블로그 직접 만들기' 프로젝트에 본격적으로 착수했습니다.
2, 3, 4는 제 생각에 덤으로 따라오는 장점이었습니다.
Options
개발 블로그를 직접 제작하는 데 옵션은 여러가지가 있었습니다. 3가지 옵션 모두 장단점이 명확했지만, 따져봤을 때 2번이 가장 현실적으로 선택할만한 대안이었습니다.
- html, css, js파일을 직접 작성해서 배포
- Next.js 14와 Contentlayer 라이브러리 적용
- 기타 다른 정적 사이트 생성기 사용 (Gatsby, Astro, 11ty)
먼저 1번은 별다른 의존성 관리가 필요하지 않아 오히려 블로그를 편하게 관리할 수 있다는 장점이 있습니다.
개발블로그가 프레임워크를 사용해서 컴포넌트 재사용성을 관리해야하는 프로젝트도 아니고, 상태관리가 필요한 것도 아니기 때문입니다.
그래도 필요한 기능들(댓글, 카테고리, 검색 등)이 생각나서 점점 기능을 확장하고 싶은 경우에는 여전히 어려움이 있을 것 같았습니다.
2번 옵션은 제가 React에 좀 더 익숙하기 때문에 블로그 유지보수가 편하다는 장점이 있었습니다.
또한 마침 회사에서 Next.js를 사용해야 하는 상황이어서 가벼운 학습 용도로도 적절했습니다. 그리고 SEO에도 좋은 대안이었습니다.
이렇듯 Next.js 프레임워크와 Vercel 배포의 조합은 아주 훌륭했지만, 문제는 Contentlayer 라이브러리였습니다.
2024-03-24 기준 Contentlayer 라이브러리는 더 업데이트 되고 있지 않고, 유지보수도 이뤄지는 것 같지 않습니다.
최근까지는 Contentlayer 라이브러리 사이트의 docs에서 몇 주 동안 500에러가 발생해서 공식문서를 읽지 못하기도 했습니다.
이런 문제들 때문에 Next.js의 편의성에도 불구하고 마지막까지 선택하기를 주저했습니다.
크게 의존하는 라이브러리 하나가 업데이트 되지 않으면 앞으로 의존성 문제가 계속 발생할 것이고(실제 개발 과정에서도 꾸준히 겪은 문제였습니다.),
오랜 시간 지나지 않아 유지보수에 걸림돌이 될 것이 분명했기 때문입니다.
물론 Contentlayer가 제공하는 기능들은 확실히 편리합니다.
그만큼 몇몇 라이브러리 사용자들은 스스로 maintainer가 되고 싶다고 이슈를 올리기도 합니다.
부디 Contentlayer가 지속 발전하는 라이브러리가 되길 바랄 뿐입니다.
3번 옵션은 일단 새로운 문법들을 학습해야해서 심리적 부담이 컸습니다.
지금 한창 사용되고 있는 기술들이라 잘 배워두면 좋겠지만, 이것들까지 학습하기에는 여유가 없긴 했습니다.
당장 빠르게 제 도메인을 404에서 벗어나게 하는것도 중요했기 때문입니다. 그래도 언젠가는 배울 예정입니다.
Getting Started
제가 작업한 내용들은 순서로 대강 아래와 같습니다. 물론 엄격하게 순서를 따른 건 아닙니다.
- Next 기본 프로젝트 초기화
- Vercel 배포
- Contentlayer 설정 적용 - 게시물의 메타데이터 선언
- 도메인 구매
- tailwindcss, mdx remark, rehype 플러그인 적용, 필요한 라이브러리 추가
- 새로운 기능 추가
- 기존 블로그에서 포스트 옮기기
- 6,7 반복
1번 과정은 사실 Next 프레임워크 개념을 학습하는 시간이 필요했을 뿐, 실제 작업 시간은 거의 걸리지 않았습니다. 실제로 시간을 많이 잡아먹은 작업은 configuration이 필요한 작업들인 3, 5, 6, 7이었습니다. 여러 훌륭한 개발자분들이 사용한 버전들이 지금과는 조금씩 달라 그분들의 작업을 그대로 따라해도 빌드가 많이 실패했었습니다. 이를테면 toSorted 함수를 섣부르게 썼다가 빌드가 뻗기도 했고, remark, rehype 패키지를 설치하면 버전 불일치로(major 버전이 새로 배포됐기 때문에..) 빌드가 실패했습니다.