하나의 프로젝트를 시작하기에 앞서, 기획과 설계 단계에서 어떤 기술을 선택하는지가 얼마나 중요한지 이전 프로젝트들을 통해 깨달았다. 예를 들면, SEO 최적화가 중요한 프로젝트에서 SPA 기반의 React를 사용함에 따라 부가적인 기능을 구현해야 했던 경험, 그리고 단지 비슷한 유형의 프로젝트에서 많이 쓰인다는 이유로 선택했다가, 오히려 배보다 배꼽이 커진 경험도 해보았다.

앞선 글에서 언급했듯, 이 블로그는 Next.js를 학습하고 기록하는 습관을 기르기 위해 기획을 시작했다. 그럼에도 단순히 '그냥', '많이들 사용하니까'라는 이유로 기술 스택을 선정하고 싶지는 않았다. 그래서 merlog 블로그에 어떤 기술을, 어떠한 이유로 사용했는지 정리하고, 그 과정에서 느낀 점을 기록해 볼 겸 포스팅을 작성한다.

0️⃣ 프로젝트 기본 세팅

ESLint, Prettier

기본적인 코드 스타일과 포맷을 관리하기 위해 사용했다. 지금까지 진행한 대부분의 프로젝트에서 ESLint와 Prettier 기반으로 코드 관련 규칙을 설정했기 때문에, 비교적 어려움 없이 사용했다.

Commitlint

팀 프로젝트를 진행하다 보면, 미리 Commit 컨벤션을 정해두었음에도 규칙과 다르게 메시지가 작성되는 경우가 발생했다. 처음에는 .gitmessage.txt과 같은 템플릿 파일을 프로젝트에 적용했지만, 이러한 방법도 최종적으로 작성되는 Commit 메시지에는 영향을 줄 수 없었기 때문에, 한계를 느꼈다.

그러던 중 Commitlint라는 라이브러리를 통해 Commit 컨벤션을 관리하는 방법을 알게 되었고, 이번 블로그 프로젝트는 개인 프로젝트임에도 이후 팀 프로젝트에서 적용할 수 있도록 먼저 경험해보면 좋겠다는 생각으로 사용하게 되었다. 기본적으로 아래와 같은 Rule 설정을 통해 Keyword 및 설명에 대한 Commit 규칙을 정할 수 있다.

물론, Commitlint만 단독으로 사용할 경우에는 단순히 검사기의 역할만 하기 때문에, 아래에서 설명할 Git Hook 관리 도구인 Lefthook 혹은 Husky와 함께 써야 규칙을 강제할 수 있다. 개인적으로는 협업 과정에서 Commit 메시지를 직관적이고 통일성 있게 작성하는 것을 중요하다고 생각하기에, 일관된 규칙을 강제할 수 있다는 점이 흥미로웠다.

Lefthook

과거에 Husky를 통해 Git Hook을 관리했는데, 생각보다 매 Commit 단계마다 실행 시간이 길게 느껴지는 경우가 많았다. 특히, 오류가 발생하면 Commit과 수정을 반복하는 일이 잦았고, 그 과정에서 속도에 대한 아쉬움을 느꼈다.

그래서 Husky를 대체할 수 있는 라이브러리로 발견한 것이 Lefthook이었다. Node 기반의 직렬 실행을 지원하는 Husky와 달리 Go 기반의 병렬 실행을 지원한다는 특징이 있고, 물론 실행할 작업이 많아질수록 속도 측면에서 이점이 있지만, 단순한 ESLint 실행 작업만 비교하더라도 기존의 Husky보다 약 2~3초 가량 빠른 처리 속도를 확인할 수 있었다.

1️⃣ Next.js

React 기반의 풀스택 웹 프레임워크로, 이번 프로젝트에서는 SSG(Static Site Generation), SEO 최적화, 이미지 최적화, App Router 등의 기능을 주로 사용했다. Next.js를 프로젝트에 적용해보는 것은 거의 처음이나 다름없기 때문에, 여러 시행착오를 겪었다. 그럼에도 프로젝트를 구현하는 과정 내내 단순한 라우팅부터 상황에 따른 렌더링 처리, 최적화 등 굉장히 프론트엔드 개발 편의성을 높여준다는 느낌을 받았다.

위 사진은 현재 블로그의 Lighthouse 점수인데, 굉장히 높은 점수를 유지하고 있다. 아마 React로 같은 점수를 만들기 위해서는 추가적인 최적화 작업을 필요로 했을 것이다. 앞으로의 프로젝트에서도 더 경험해 봐야겠지만, 대부분의 웹 프로젝트에서 Next.js가 React 단독 사용보다 더 좋은 선택지가 될 수 있겠다는 생각이 들었다.

2️⃣ TypeScript

TypeScript는 JavaScript에 정적 타입을 추가한 언어다. 여러번의 팀 프로젝트에 TypeScript를 적용하며 정적 타입 언어가 가진 장점을 몸소 경험했다. 예를 들어, 컴포넌트에 Props 타입을 작성하는 것만으로도 컴포넌트의 구조를 직관적으로 이해할 수 있고, 타입 추론과 IDE 자동 완성 기능이 결합해 생산성과 유지보수성 향상에 도움이 되었다. 블로그 프로젝트는 팀 프로젝트도 아니고 규모도 비교적 작은 프로젝트지만, 일부 기능을 추가하거나 수정하고 다시 내가 작성한 코드를 확인하는 과정에서 확실한 이점을 느낄 수 있었다.

3️⃣ Tailwind CSS

개인적으로 지금까지의 프로젝트에서는 Emotion(CSS in JS)과 같은 컴포넌트 단위 스타일 작성 방식을 선호해왔다. Tailwind CSS는 이전에 아주 짧게 사용해본 적이 있는데, 매번 공식 문서를 찾아가며 스타일을 작성하는 과정이 굉장히 불편하고 직관적이지 않다고 느껴, 이후 프로젝트에서는 사용하지 않았다. 그러던 중 Create Next App을 이용해 이번 블로그 프로젝트를 세팅하는 과정에서 Tailwind CSS의 사용 여부를 묻는 질문을 확인하게 되었다.

Create Next App에서 직접 Tailwind CSS 사용 여부를 확인한다는 점이 굉장히 흥미로웠다. 제대로 경험해보지 못한 상태에서 내가 갖고 있는 선입견을 없앨 좋은 기회가 될 것 같아 Tailwind CSS를 사용했을 때의 이점을 찾아보기 시작했다. 우선, 반응형과 다크모드 지원, 빠른 UI 개발과 같은 장점이 있다는 것을 확인할 수 있었는데, 반응형과 다크모드 모두 이번 블로그 프로젝트에서 필요한 기능이었기에 적용해보고 싶다는 생각이 들었다.

이번 프로젝트에 Tailwind CSS를 사용해보니, 클래스만 조합해서 빠르게 UI를 구성하는 과정에서 스타일 변수명을 고민하는 시간이 크게 줄었다. 그리고 자체적으로 내장되어 있는 디자인 시스템(fontSize, colors 등)도 굉장히 편리하게 느껴졌다. 또한, 런타임에 스타일을 생성하는 CSS in JS 방식과 달리 번들 크기가 작고 사전에 빌드된 정적 파일로 스타일이 처리되는 성능적인 이점과 앞서 말했던 반응형 디자인과 다크모드 기능 모두 클래스를 통해 간단하게 처리할 수 있다는 점도 굉장히 만족스러웠다.

4️⃣ 그 외

마크다운, MDX

마크다운 방식의 글 작성은 velog에서 처음 경험했는데, 당시에 단순한 문법을 통해 읽기 좋은 글을 만들 수 있는 포맷이라는 느낌을 받았다. 이후에도 노션이나 슬랙에서 마크다운을 다룰 기회가 있었고, 블로그 특성상 글을 작성할 일이 많기 때문에 이미지나 코드블럭 등을 함께 포함해 작성하기에 이보다 좋은 선택은 없다고 생각했다.

최초에는 단순히 마크다운(.md)만을 사용해 블로그를 구현했는데, 마크다운 내에 React 컴포넌트를 포함시킬 수 있는 MDX라는 확장 포맷이 있다는 것을 알게 되었다. 마침 마크다운 내 이미지에 Next의 이미지 최적화 기능인 Next/image를 적용하고자 방법을 찾던 중이었고, 자연스럽게 MDX로 전환하는 선택을 했다.

Vercel

Next.js의 공식 호스팅 플랫폼인 Vercel은 세팅 과정도 굉장히 간단했고, GitHub 연동을 통해 설정해둔 Branch에 새로운 변경사항이 Push될 경우 자동 빌드 및 배포 처리되는 워크플로우도 만족스러웠다. 최초에 Vercel을 이용해 블로그를 호스팅하고 특정 페이지 접속하는 과정에서 예상보다 로딩이 오래 걸리는 문제가 있었는데, 처음에는 Vercel 무료 플랜의 한계일 수도 있겠다는 생각을 했다.😅

여러 문제점을 확인한 결과, 특정 페이지의 렌더링 방식이 로딩 속도에 영향을 줬다는 사실을 알 수 있었다. 해당 문제를 해결한 뒤, 이전보다 더 빠르게 로딩되는 페이지를 확인할 수 있었다. 그리고 위에서 다루지 않았지만, 마크다운 파일의 메타 데이터를 파싱해주는 gray-matter, MDX 파일의 동적 렌더링 처리를 위한 next-mdx-remote, 이미지의 blur placeholder 생성을 위한 plaiceholder 등의 라이브러리가 블로그에 추가적으로 사용되었다.

---

단순히 마크다운으로 작성된 파일을 블로그 포스팅으로 변환하는 작업이 주요 기능임에도 불구하고, 프로젝트의 처음부터 끝까지 신경 쓰다 보니 예상보다 고려할 부분이 많았다. 그리고 최근에도, 실사용 과정에서 보이지 않았던 문제나 버그가 눈에 들어올 때마다 하나씩 손을 보고 있다. 앞으로도 부족한 부분을 계속 보완하며 지금보다 더 나은 블로그를 만들어가려 한다.