군대에 와서 많은 프로젝트를 진행하고 있습니다. 그중 하나가 블로그 개편입니다.

Next.js

최근 친구와 프로젝트를 진행하며 Next.js를 사용해보게 됐습니다. Next.js 를 사용하면서 디렉토리 기반의 라우팅, 자동화된 Server Side Rendering(SSR), Static Site Generation(SSG), 완벽한 Typescript 지원 등, Next가 대단히 아름다운 프레임워크임을 느꼈습니다. 그래서 제 블로그에 곧바로 적용하기로 했습니다.

기존의 블로그 구조에서는 포스트 파일을 작성한 후 전처리 프로그램을 실행했습니다. 전처리 프로그램은 React의 public 디렉토리에 메타데이터를 담은 json, SPA 구현을 위한 dummy html들, 그리고 각 포스트의 정보를 담은 json들을 생성합니다. 브라우저에서 이들은 모든 자바스크립트 파일들이 로드된 후에 fetch API를 통해 로드됩니다. 그러므로 이 과정에서는 그 어떠한 SSR도 실행될 수 없었습니다. 리액트와 SSR을 접목하기가 상당히 난감했기 때문입니다.

그리고 기존 구조에서 전처리기와 블로그 프론트엔드는 같은 리포지토리에 포함되기는 했으나 서로 별개의 프로젝트로 다뤄졌고, 따라서 타입 공유가 불가능하여 타입스크립트의 이점을 활용하기 어려웠습니다.

Next.js에서는 적절한 getStaticProps 설정만 해 주면 자동으로 SSG를 수행해주므로 다양한 문제가 해결되었습니다. 포스트 전처리를 getStaticProps로 옮기는 것만으로 SSG가 가능해졌습니다. 이전처럼 별도의 전처리 프로세스를 둘 수도 있었겠지만 복잡성만 늘어나고 얻는 이점이 거의 없다고 판단했습니다.

다만 전처리 과정을 getStaticProps에 넣는 경우 빌드, 혹은 개발 서버를 실행할 때 getStaticProps가 여러 번 실행되면서 불필요한 포스트 전처리가 발생합니다. 그래서 간단한 캐싱을 구현, 중복 실행을 방지했습니다.

이로부터 SPA의 redirection 문제, 느린 로딩, 복잡한 구조, robot.txt 및 sitemap 생성 등을 비롯한 다양한 문제들이 한 번에 해결됐습니다. 특히 기존에는 robot.txt와 sitemap을 생성하는 코드를 직접 작성했지만 현재는 자동으로 생성해주는 라이브러리를 사용하고 있습니다.

Design

블로그를 개편하면서 저의 바뀐 디자인 취향에 맞게 블로그 디자인도 바뀌었습니다.

기존에는 화려한 디자인을 선호했습니다. 시각적으로도 화려한 것을 선호했지만, 기능이 많은 것을 선호했다는 의미입니다. 그러나 수많은 개발을 해보면서 쓸데없이 기능을 많이 넣는 것은 기술 부채가 될 가능성이 높다는 것을 알게 되었습니다. 그러면서 '필수적이지 않으면 뺀다' 라는 디자인 철학이 생겼습니다.

그래서 이 블로그는 메인 페이지, 포스트 페이지, about 페이지 총 세 개의 페이지만을 가지고 있으며, 타입 정의와 페이지, 컴포넌트를 포함한 모든 타입스크립트 파일을 합쳐도 9개밖에 되지 않습니다. 특히 프론트엔드 소스코드는 가장 긴 파일이 100줄을 넘지 않습니다. 포스트 목록의 썸네일도 제거했으며 카테고리 페이지도 없앴습니다.

Devcontainer

Devcontainer를 적용한 것 역시 큰 변화입니다. 기존에는 단순히 머신에서 작업을 수행하고 도커 이미지 내에서 빌드를 수행했다면 현재는 VSCode의 Devcontainer 내부에서 개발을 진행하고 있습니다. 이로부터 다양한 머신에서 일관된 개발 환경으로 개발이 가능해졌습니다.

Conclusion

새롭게 블로그를 개편해봤습니다. 이 과정에서 Next.js와 Devcontainer를 적용했고 디자인을 더 깔끔하게 바꿔봤습니다.