개요 - 마이그레이션의 시작

명확한 목적만 놓고 이야기하자면 현재 제 블로그는 현재 jekyll 만을 이용하여 운영하는 방식이 크게 문제는 없습니다. 그럼에도 이번에 이 블로그를 js 진영의 무언가로 옮겨보려 하는 것은 두 가지 정도의 욕심 때문입니다.

  1. 자바스크립트 프레임워크를 이용한 개발 경험을 쌓고 싶다.
  2. 깜깜이로 운영하는 부분을 이해하고 싶다.

AI는 백엔드 개발자인 나를 프론트엔드 개발을 하도록 만들었다

요즈음 면접을 보다보면 제일 많이 듣는 회사의 요구사항은 ‘개발을 잘하는 개발자가 아니라, 문제를 잘 해결하는 사람’을 원한다는 것입니다. 그리고 이 배경에는 ai의 발전이 있다고 생각합니다. 이전에는 ‘개발을 할 줄 아는’ 사람의 가치가 굉장히 높았습니다. 굳이 비유하자면 조선 시대에 한글이 보급되기 전에 한자를 읽고 쓸 줄 아는 사람의 가치가 높았던 것과 비슷하다고 생각합니다.

물론 개발을 잘하는 사람의 가치는 여전히 높습니다. 능력있는 개발자는 코드 리뷰를 통해 팀에게 정보를 공유하고 피드백을 주며, 유지 보수가 쉽고 확장성이 높은 코드를 작성할 수 있으며 이는 ai로 아직 해결하기 힘든 영역 이며 주어진 숙제일 것이라 생각합니다. 그러나 high level language의 발전으로 개발자가 구현이 아니라 문제 해결에 집중할 수 있게 됐던 것과 마찬가지로, ai의 혁명은 개발자가 이전보다 더 ‘문제 해결 자체’에 집중할 수 있게 도와주고 있다고 생각합니다.

그리고 이러한 문제 해결 능력을 함양하는 방법 중에 백엔드 보다는 프론트엔드 개발이 훨씬 유저의 경험과 직결되어 있는 경우가 잦으며, 발전을 이루었을 때 가시적인 성과를 내기가 쉽다고 생각합니다. 그래서 이번에는 블로그를 마이그레이션 해서 제대로 된 프론트 엔드 개발을 해보고 싶다는 욕심이 생겼습니다.


깜깜이 상태에서는 만들기 힘들었던 기능들

현재 제 블로그는 아무래도 jekyll에 굉장히 많은 부분을 의존하고 있습니다. jekyll은 분명히 굉장히 간단하게 정적 사이트를 생성할 수 있는 훌륭한 프로그램이지만, 그만큼 제한적인 부분도 많습니다. liquid이라는 템플릿 언어와 관련한 정보를 찾기 힘든 부분도 많고, 기능적으로도 안 되는 것이 많았지만, 무엇보다 데이터를 주고 받는 세부적인 부분을 커스터마이징하기가 어려워서 간단한 기능을 추가하기 힘들 때도 잦은 것이 문제였습니다.

대표적으로 이 블로그를 시작한 이래 아직도 해결하지 못한 문제가 있는데 그게 바로 ‘같은 날짜에 같은 카테고리에 둘 이상의 글을 쓸 경우, 이전/다음 글로 넘어가는 링크가 제대로 생성되지 않는다’라는 문제입니다. 제가 원하는 해결 방법은 날짜가 같을 경우 글 제목을 기준으로 정렬을 하고 이전/다음 글을 찾아주는 것인데, liquid에서는 문자열 간 비교를 할 수 없어서 이를 해결하기가 어려웠습니다. 그렇다고 별도의 함수로 만들자니 jekyll의 liquid는 코드를 모듈별 분리를 통한 관리를 지원하지 않아서 유지보수에 어려움도 있었습니다.

이번에 js 진영의 프레임워크를 사용하면서 혼자 하는 프로젝트에서 열려있는 33개나 되는 오픈 이슈들을 좀 정리하고, 제가 블로그를 하면서 SEO와 같은 웹 세계에 대해 이해할 수 있었던 것 같은 눈이 뜨이는 경험을 하고 싶습니다.


why next.js?

저는 여러 기술 스택들 중 선택의 기준을 다음 세가지로 정했습니다.

기술 스택 선택의 기준

  1. 타입스크립트 지원 여부
  2. 서버사이드 렌더링 지원 여부
  3. 기존의 블로그를 마이그레이션하기 쉬운 프레임워크

기준 별로 next.js 선택 이유

  1. 타입스크립트 지원: next.js는 기본적으로 타입스크립트를 지원합니다. 이는 raw javascript를 통해 개발하는 것보다 타입스크립트를 통해 개발하는 것이 더 안정적이고, 제가 더 익숙한 형태이기 때문에 유지보수에 더 유리하다 생각했습니다. 아무래도 에디터의 자동완성과 같은 기능을 사용하지 못하는 것은 많이 괴로운 일이었기 때문입니다.

  2. 서버사이드 렌더링 지원: next.js는 서버사이드 렌더링을 지원합니다. 이는 SEO에 유리하고, 블로그의 속도를 성능을 높일 수도 있습니다. vue.js나 react.js는 클라이언트 사이드 렌더링을 기본으로 한다는 이야기를 꽤나 많이 접할 수 있었고, next.js가 이를 극복하기 위해 양쪽을 동시에 지원한다는 것이 매력적이었습니다.

  3. 마이그레이션하기 쉬운 프레임워크: 아무래도 제가 기존에 블로그를 운영한 기간도 거의 5개월이 다 되어 가고, 작성한 글도 많으며 이들을 위한 디자인 구현도 많이 해 둔 상태이면서 동시에 제 정체성이다보니 이를 아예 포기하기보다 마이그레이션을 통해 기존의 것을 어느 정도는 보존하고 싶었습니다. 그것이 제가 추구하는 개발자로서 가치 영역 중 하나이기도 말입니다.


마무리

현재는 좀 낑낑대고 났더니 카테고리들과 같은 글의 메타 데이터를 수집하는 데 성공했고, 이를 정리하는 작업을 앞두고 있습니다. 그런 다음에는 이를 이용해서 글을 표시하기 위한 테마 선택 및 디자인을 구현하는 작업을 할 예정입니다. 처음에는 마냥 방법이 없어 보였는데 이제는 해결할 수 없었던 문제들을 해결할 수 있는 상황에 접근하고 있다는 생각이 들어 설레고 가능하면 새단장이 마무리 된 후에는 이 블로그를 통해 얻은 경험을 다시 한 번 정리하고 싶습니다.


참고자료


2024-05-19
다음 글: CallBack, Promise, Async, Await → 카테고리로 돌아가기 ↩