프론트엔드 개발 블로그 시작하기
프론트엔드 개발자로서 본인이 만든 개발 블로그 하나쯤은 있어야 한다는 생각에 이 블로그를 시작하게 되었습니다. 블로그의 첫 번째 목표는 현업에서 여러 가지 이유로 도입하지 않게 된 SSR 프레임워크를 사용하는 것이었습니다.
Next.js 시도
먼저, Next.js를 시도해보았습니다. 하지만 Next.js를 AWS에 직접 배포할 수 있는 안정적인 방법을 찾지 못했습니다. 그래서 Remix로 방향을 바꾸었습니다.
Remix 시도와 Vercel 배포
Remix를 AWS에 배포하는 데 성공했지만, AWS에서 발생할 요금이 걱정되었습니다. AWS에서는 요금 제한을 걸 수 없기 때문에 안전장치가 없었습니다. 이에 따라 Vercel로 배포하기로 결정했습니다. Vercel을 사용하면서 Remix를 사용할 이유가 없었기에 다시 Next.js로 돌아왔습니다.
UI 라이브러리 선택
다음으로는 UI 라이브러리를 선택하는 과정이었습니다. Next.js를 사용하기 때문에 서버 컴포넌트에서도 잘 동작하는 UI 라이브러리를 찾고 싶었습니다. 그러나 UI 컴포넌트에서 useState, useEffect hook을 안 쓸 수 없기 때문에 이는 불가능한 요구사항임을 깨달았습니다. 이 과정에서 NextUI, shadcn/ui 등을 시도해보았고, 결국 회사에서 새로운 프로젝트에 사용하기로 한 Mantine을 선택하게 되었습니다.
Mantine 선택 이유
Mantine은 CSS modules를 사용하는 것이 큰 장점이라고 생각합니다. CSS 프레임워크에서는 아무리 여러 방법을 사용하더라도 Native CSS의 속도를 따라올 수 없습니다. Mantine은 CSS modules과 함께 PostCSS와 data-* attribute를 사용하여 개발자 경험이 좋습니다. 또한, 테마 custom이 가능하여 디자인을 조정하기 쉽고, 반응형 디자인을 지원하여 다양한 디바이스에서 일관된 사용자 경험을 제공할 수 있습니다. 이와 같은 이유로 Mantine을 선택하였습니다.
Monorepo 시도와 포기
또한, Monorepo도 시도해보았습니다. 회사에서 사용하는 Monorepo 툴인 NX가 너무 좋아 보여 도입했었습니다. 페이지가 늘어나고 Projects 페이지 내용이 많아지면 빌드 시간이 오래 걸릴 것으로 예상하여 시도했지만, 다른 라이브러리들을 사용해보면서 Config에 너무 많은 에너지를 쏟게 되어 오버엔지니어링이라는 생각에 Monorepo를 제거했습니다.
콘텐츠 관리 시스템 선택 과정
노션(Notion)에 글을 작성한 후 API로 가져오는 방식을 사용해보았지만, Notion API가 너무 느리고 Markdown으로 변환하는 데 어려움이 있었습니다.
그래서 Supabase에 Markdown 파일을 업로드하고 가져오는 방식을 시도했습니다. 그러나 이 방법에서는 excerpt와 태그를 관리하는 것이 어려웠습니다. 별도의 테이블을 만들고 업로드 페이지를 구축하려 했으나, 퇴근 후 Supabase를 공부하고 구현하려니 일정이 늦어졌습니다.
그렇게 계속 미루다가 AFFiNE을 알게 되었습니다. AFFiNE은 공식 블로그도 API로 내용을 가져와 Markdown으로 변환하여 구현하고 있습니다. 아직 정식 릴리즈는 되지 않았지만, 개인 블로그로 사용하기에는 충분하다고 생각합니다.