제가 블로그를 만들기로 결심한 순간 부터 수많은 에러와 게으름과의 전투끝에 1년(...)의 기간동안 겪은 일들과 후기를 써봅니다.
예전부터 개인 개발 블로그가 있으면 좋겠다고 생각했었다. 내가 배운것들을 기록하고 포트폴리오로 쓸수도있으니 말이다. 사실 단순 개발 일지를 쓰는거라면 다른 블로그 플랫폼을 써도 되지만 왠지 나만의 블로그를 만들고 싶다는 욕심이 생겨 직접 개인 블로그 프로젝트를 만들기로 했다.
결론부터 말하지만 "그냥" 이다. 다른 플랫폼을 쓰는것이 아닌 내가 직접 만들고 내가 운영하는 블로그 라는게 참 특별해 보였다. 직접 블로그를 제작한다면 이 블로그 프로젝트 자체가 하나의 포트폴리오가 되는것도 덤이며 특히나 써보고싶었던 기술들을 적용해 볼수도 있었다.
막상 블로그 프로젝트를 진행하자니 알고있는게 없었다. 리액트를 다뤄본적은 있지만 next나 graphql을 써본적이 없었고 aws로 각잡고 "서비스" 라고 부를만한 배포를 위한 아키텍쳐를 구현 해본적이 없다.
프론트를 next로 선택한 이유는 SSR 구현을 신경쓸 필요가 없어서 였고 마침 배워보고 싶어서 였다. graphql을 적용한 이유역시 배우고 직접 써보고 싶어서 였으며 백엔드는 serverless 프레임워크를 이용한 lambda로 배포를 할 생각이었다. 예전에 토이프로젝트를 serverless 프레임워크로 배포를 해본적이 있었지만 이 역시 맛보기 수준이었다.
모르는것들을 배워가면서 프로젝트를 진행하기는 쉽지 않았다. 공부와 개발을 동시에 하니 기간은 길어졌고 next와 graphql의 동작방식을 이해하는것부터 내가 원하는대로 구현하는것까지 고통의 연속이었다.
리액트로 csr만 사용하다가 이번 블로그에 ssr을 적용하기 위해 선택한 프레임워크다. 정확히 말하자면 내가 사용한 방식은 ISR 이라는 방식이고 next에서는 미리 렌더링된 페이지를 생성하는 여러가지 옵션을 제공했다(SSR,SSG,ISR). 각각의 방식들이 어떤 차이점이 있는지 이해하는데 꽤나 시간이 걸렸다.
예전에 graphql 이라는 기술을 들어본적이 있다. 그때는 그냥 이런게 있구나 라고만 생각하고 넘어갔지만 직장에서 restAPI 로 개발을하다 UnderFetching과 OverFetching 문제를 자주 겪게되면서 graphql의 필요성을 느꼈고 이번에 직접 써보게 되었다. 확실히 복잡한 데이터가 필요한 페이지를 구현할때 restAPI 보단 훨씬 깔끔한 느낌이었다.
프로젝트를 처음 시작했을때는 css module 방식으로 css를 적용했었다. 중간중간 다른 블로그의 디자인은 어떻게 되어있나 참조를하다 우연히 tailwind 라는 프레임워크를 알게되었고 기왕 바닥부터 시작하는거 이것도 적용해보자 라는 생각으로 도입했는데 써보니까 정말 편하더라. 복잡한 css코드를 압축하고 압축해서 몇 단어로 구현해낸 느낌이었다.
이번 블로그 제작기에 제가 실제로 개발부터 배포까지 하며 겪었던 내용들을 담고자 합니다. 다음글 부터 실제로 개발을하며 겪은 오류들과 고민, 해결 방법 등 을 정리해서 쓰려고 합니다. 다음글 주제는 next.js 입니다.