블로그 제작기

Intro

해당 포스팅은 블로그를 직접 만드는 과정에서 겪은 시행착오를 정리한 내용이다.

나의 블로그 포스팅을 향한 일대기는 2019년도에서 부터 시작된다.

JSP / Servlet

2019년도에 군대를 막 전역하고, 학점을 잘 챙기면서 여러가지 행사에 참여했다. 그 과정에서 기술 블로그를 제작하겠다는 꿈을 꾸고 작업에 착수한다. 그 당시에는 JSP와 Servlet을 이용한 방법을 통해서 Posting하는 것을 시도했다.

github : euidong/blog

해당 방식은 markdown file을 그대로 가져와서 rendering하여 만들었다. 하지만, jar file을 실행해야 한다. 따라서, JAVA Virtual Machine이 필요하기에 결론적으로 이를 호스팅할 machine이 필요하다. 따라서, AWS free tier를 이용해서 배포했지만, 다소 배포 관리가 귀찮고, 당시에는 frontend & backend 등 아직 개념이 제대로 스지 않았기 대문에 중간에 포스팅을 조기 종료했다.

결국 JSP + Servlet을 이용한 시도는 종료된다.

Gatsby

후에 2021년도 1월에 다시 새롭게 블로그를 쓰겠다는 포부를 갖고, 블로그 작성 방법을 찾는다. 당시에는 React를 이용해서 다수의 Application을 제작해본 경험이 있었기 때문에 이를 이용한 Blog를 만들려고 했다. 자세히 기억은 안나는데 Gatsby Showcase에 있는 source code를 이용해서 Blog를 제작했다. 하지만, Gatsby에 대해 아는게 없고, 시간을 쓸 여유가 없어서 결국에는 중도에 멈춘다. 추가적으로 Github action으로 CI/CD 구현을 수행하는 작업까지도 진행하였다. 하지만 결국 제대로 진행된 것 없이 종료되었다.

github : euidong/euidong.github.io/dev@deprecated

Tistory

2021년도 3월에 결국 직접 제작을 하는 것을 포기하고, Tistory를 이용해서 블로그에 포스팅을 시작한다. 해당 시기부터 시작해서 몇 개의 포스팅을 작성하였다. 대략 35개 정도의 포스팅을 작성했고, 최근에 이르러서 작성의 한계를 느끼며 갈아타야겠다고 생각했다.

다음은 직접 커스텀을 해야겠다고 생각했던 이유이다.

호환성이 떨어진다. => Markdown으로 변환도 가능하지만, Github와 완벽한 호환이 안된다.
가끔 모바일에서 문자가 깨진다. => 아마 MAC으로 작성하는 경우 문자가 깨지는 것 같다. 근데, 이를 매번 모바일로 켜서 확인하기에는 너무 번거롭다.
커스텀을 할 때 다른 Library를 맘대로 가져와서 쓸 수 있지만, pure js, jquery 기반으로만 가능하고, 유지보수가 쉽지 않다.
가끔 작성 결과가 너무 예측 불가능하다.
tag 관리가 불편하다.
기본 UI가 안이쁘다.

몇 가지 이유가 더 있었던 거 같은데, 아마 이정도가 문제였던 거 같다. 암튼 내가 관리하지 못하는 것으로 인한 스트레스가 있었기 때문에 이를 해결하기 위해서 완전 커스텀을 다시 결정하였다.

tistory: justlog

완전 커스텀

생 React

처음에는 생 React를 통해서 Blog를 만들어야겠다고 생각했다. 가장 일반적으로 할 수 있는 작업이고, 다른 static page generating 기능을 수행하는 react framework를 다시 공부하는 workload를 지고 싶지 않았고, 굳이 필요하지 않은 의존성을 만들고 싶지 않아서 결국 생 React로 바로 작업을 시작한다.

당시에는 Tistory에서 한계를 느꼈던 부분을 고치면서, Tistory에서 갖고 싶었던 장점을 가져가고자 했다.

호환성이 떨어지던 점은 Markdown을 이용해서 작성하고, Github viewer style(GFM, Github Flavor Markdown)을 사용하기로 한다. 따라서, 해당 블로그의 모든 글을 Github에 올려도 이미지 경로 빼고는 매우 잘 작동할 것이다. (이는 후에 이미지 호스팅 CDN을 따로 설정하면 해결됨.)
Tistory에서 장점이라고 생각했던, Category로 작성글을 묶고, Tag들로 다시 한 번 더 분류한다.
Posting을 보기 쉽게 정리되어있어야 한다.
Dark Mode를 지원해야 한다.
조회수 관리를 위해서 Google Analytics 설정을 해야한다.
구글 / 네이버 검색에 노출되어야 한다.
광고를 게시할 수 있어야 한다.
Github에 Push하는 것만으로 Posting이 게시될 수 있어야 한다. (Github Action)
Category와 Tag들은 Markdown안에 작성하지만, 이를 조회할 수 있어야 한다. 따라서, code를 build할 때 json으로 generating 할 수 있는 로직을 설계한다.
UI는 최대한 Simple 하고 깔끔하게 만드는 것을 목표로 하였다.

따라서, 모든 Button 부터 모든 UI를 직접 제작(여타 디자인 사용 x - material, ant 등)하고, Routing 설정하고, 작업을 모두 마무리한다.

여기까지는 모든 작업이 순조롭게 진행되고, 마무리가 되었다. 하지만, SEO(검색 엔진 최적화) 작업을 진행하면서, 결국 static page가 필요함을 깨닫는다. 왜냐하면, 기존의 React Router를 사용하게 되면, https://euidong.github.io/posts/dfs1 를 찾을 수가 없다. 왜냐하면, github에서는 page를 직접 접근할 때에는 배포 branch에서 해당 파일을 찾게 되는데 해당 파일이 없으면 결국 404 Not Found를 노출하게 된다. 이를 해결하기 위해서, dummy redirect로 root로 돌려보내줄 수도 있지만, 결코 좋은 방법은 아니다. 검색엔진 최적화에도 좋지 못하다. 따라서, static file을 각 각의 url마다 생성해주는 Static Page Generating이 필요하다고 느낀다. 따라서, Gatsby와 NextJS 중에서 선택을 하기로 한다.

이제 추가된 요구사항은 다음과 같다.

기존 코드를 그대로 활용할 수 있어야 한다.
Static Page Generating을 지원해야 한다.

github : euidong/euidong.github.io/dev@pure-react

다시 Gatsby

다시 돌아와 Gatsby를 시도하기로 한다. 애초에 GraphQL과 React 모두 경험이 있기 때문에 쉽게 할 수 있을 거라고 생각했다. 하지만, 생각보다 GraphQL Query의 제한점이 많아서 결국 Gatsby는 포기하기로 한다. 물론 Gatsby의 확장 도구들은 유용했지만 위에서 제시한 9번을 구현하기에 한계를 느꼈다. (내 딴에는 GraphQL로 만들고 싶었는데 사실 포기하고 JSON으로 만들었으면 가능했을 듯하다.)

NextJS

그래서 다음으로 시도한 것이 NextJS이다. NextJS는 생성 시에 내부 API를 정의하여 이를 기반으로 미리 compile을 완료한 html 파일들을 생성해두고, 제공하면서도, 그 내부에서는 SPA 처럼 동작할 수 있도록 돕는 방식이다. React를 이용한 Framework인 만큼 기존의 code를 그대로 사용할 수 있어서 쉽게 사용이 가능했다. 하지만, Gatsby와 마찬가지로 어느정도의 한계는 존재했기 때문에 결국은 react만 생성하던 방식처럼 JSON file을 generating하여 category와 tag들을 수집하였다.

그 결과 지금과 같은 형태의 블로그를 완성하였다. 현재 포스팅을 계속해서 진행할 예정이며, 광고 및 여타 설정들도 추가로 진행할 예정이다.

blog-view

github : euidong/euidong.github.io/dev

최종으로 만들어진 Blog는 다음과 같은 요구사항을 만족한다.