Typed.sh

About

새로운 Typed.sh 블로그 환경 만들기

새로운 Typed.sh 블로그를 만드는 중의 비하인드 스토리 그리고 그 이유들.

HG
HoJeong Go

24/02/2021

Thumbnail image of 새로운 Typed.sh 블로그 환경 만들기.

Typed.sh 블로그가 지난 2월 초에 예상치 못한 서버 배포 오류를 시작으로 약 한 달 동안 다운되어 있었습니다. 서버가 다운되어 글을 복구하는 유틸리티 프로그램을 작성하고 새로운 Jamstack 기반 블로그를 만들 때까지의 이야기를 담아보았습니다.

Timeline

2월 5일, 서버 배포 실패

불미스러운 사건의 발생 당일이었습니다. 그 당시에도 저는 Terraform을 사용하여 배포를 하고 있었고 운영하던 타 서비스를 종료하던 중에 기존 Typed.sh 컨테이너가 포함되어 있다는 사실을 간과하게 되었습니다. 그렇게 가차없이 그 누구도 모르는 채로 종료되는 타 서비스와 함께 Typed.sh 웹 사이트는 Oracle의 서버 상에서 영영 사라지게 되었습니다.

2월 6일, 배포 오류 발견

그리고 단지 약 한 시간 쯤 지났을 때 Discord의 한 사람으로부터 DNS가 이상한 곳으로 연결이 되어있다는 제보를 받고 즉시 확인을 시작했습니다. 처음에는 믿을 수 없었습니다. 분명히 내 손으로 Terraform 명령어를 작성한 기억도 있었습니다. 사실은 Terraform의 잘못이라기보다는 개인적인 잘못에 속하지만 그 당시에는 그 어떤 것도 손에 잡히지 않았던 것 같습니다. 그렇게 새벽에 이제 편안하게 여러 방송인의 편집자 님들의 영상미를 즐기려고 하던 계획은 파탄이 나게 되었습니다.

당일 1시, 데이터 복구

일단은 백업 데이터가 없다는 사실을 받아들이고 데이터 복구를 위해 Google Site Cache 그리고 Wayback Machine부터 뒤적거리기 시작했습니다. 가장 다행인 점은 웹 사이트의 링크가 여러 페이지들의 서로서로를 연결 짓고 있어 이러한 크롤러들에게 용이한 구조를 취하고 있었다는 점이었습니다. 각각의 페이지가 여러 리비전으로 쪼개져 있긴 하였지만 충분히 공개 API로 유저가 작성한 글을 Wayback Machine에서 가져오고 다시 마크다운의 형태로 내보내는 코드를 작성할 수 있었습니다.

그렇게 약 3시간 동안 즉시 개발을 하여 특정 작성자를 기준으로 작성된 글을 대부분 다시 수집할 수 있게 되었습니다.

2월 7일, 이후 계획들에 대한 고민

바로 다음 날에 핵심적으로 글을 올리던 사람들에게 이 소식을 알리고 이런저런 이야기를 하면서 데이터 복구까지는 가능해졌고 그렇게 어렵지 않을 것 같다고 메세지를 보냈습니다. 그리고 추후 어떻게 운영을 했으면 좋겠느냐고 의견을 물었는데 대부분 GitHub 등에서 부분적이더라도 글을 정적으로 호스트를 하는 것을 선호하시는 것을 알게 되었습니다. 아무래도 가장 큰 이유는 역시나 데이터 보존에서 나오는 것 같았습니다. Git 레포지토리에 글을 저장하는 경우에는 글을 리비전을 Blame 기능으로도 쉽게 확인이 가능하고 Bare clone까지는 아니더라도 Clone만으로도 데이터 백업과 관리가 매우 용이해집니다. 그리고 즉시 이제 컨텐츠 관리를 어떻게 해야 할까라는 고민을 시작하게 되었습니다.

Next.JS를 선택하기까지

기본적으로 블로그를 운영하는데에는 개발자 분마다 몇 가지 선호하시는 유형이 있는데 저는 3가지로 나눌 수 있다고 생각합니다.

  • Full-cycle 개발
  • Jamstack 개발
  • 호스팅되는 웹 서비스 사용

저는 이번에는 Jamstack에서 Static Site Generator인 Next.JS 그리고 파일 기반 데이터 소스를 사용하여 블로그를 구성해보았습니다. 먼저 가장 첫 번째, Full-cycle 개발을 선택하지 않은 이유는 개인적으로 그 모든 역량이 되지 않다고 생각하기 때문입니다. 자칫 이런 것을 보고 자신의 역량을 직접 제한하는 것이라고 하는 블로그 글을 꽤 많이 본 적이 있습니다. 그러나 기본적으로 기능 개발 후 데이터베이스 마이그레이션은 저에게 있어서 당연한 것인데도 불구하고 백엔드에 대한 피로감을 가장 크게 느껴지게 하는 부분이었습니다. 또한 혼자 사용하는 블로그가 아닌 만큼 더욱 업타임 등 블로그를 전반적인 서비스로서 대해야 한다고 생각했습니다.

이러한 관점에서 Next.JS는 상당히 매력적인 선택지였습니다. 가장 큰 이점은 서버 코드를 프론트엔드의 관점에서 꾸며주듯이 추가할 수 있다는 점입니다. 저는 Next.JS를 명확하게 프론트엔드 프레임워크라고 봅니다. 프론트엔드의 관점에서 충분히 볼 수 있으면서 동시에 필요하다면 즉시 서버의 코드를 곁들여 사용할 수 있는 그런 프레임워크였습니다.

2월 12일, Gatsby 튜라이

타임라인을 이어가기 위해서는 Gatsby 이야기를 한 번 해야 합니다. 한 마디로 설명하자면 Next.JS와 가장 많이 고민했고 그리고 가장 SEO 자원이 풍부한 보일러플레이트가 존재하는 곳이였습니다. SEO부터 웹 사이트 메타데이터에 대한 모든 것이 이미 갖추어져 있는 그런 장소였던 것 같습니다.

사실 저에게 있어서 Gatsby는 최악 중 최악의 프레임워크였는데 가장 큰 이유로는...

  • 그 무엇보다 느린 개발 서버
  • 간단한 기능 추가에도 과도하게 복잡했던 Plug-in 설정

이러한 것들을 뽑을 수 있을 것 같습니다.

사실 다시 말하자면 너무 느렸습니다. 개발을 하는 도중에도 몇 번이고 SSR 서버에서 이상한 디자인을 쏟아내는 것을 볼 수 있었고 문서는 추가하려던 기능의 규모에 비해 너무 복잡했습니다. 블로그는 기본적으로 글을 보여주어야 하는데 이것만으로도 플러그인 설정으로만 200 라인이 넘어가는 것을 보고는 기겁을 하여서 결국에는 몇 번 시도하다가 Next.JS로 도망치듯 빠져나왔습니다.

2월 16일, Next.JS에 정착

그렇게 드디어 Next.JS에 정착하게 되었습니다. 실제로는 Gatsby에 적응하기 위해서 온갖 짓을 다 해보았는데도 불구하고 Next.JS가 그래도 훨씬 편안한 환경에서 개발을 할 수 있도록 도와주었습니다. 개발 서버가 빠른 편이 아니었음에도 불구하고 상대적으로 많이 빠른 편이었습니다. 유일한 단점이라면 바퀴를 재발명해야 한다는 점이었습니다. 지금은 대부분의 작업이 끝난 상태이지만 시작할 때 쯔음에는 사실 어떻게 해야 하나 고민을 정말 많이 했습니다.

예를 들면...

  • 블로그 글을 GitHub 혹은 파일 시스템에서 불러오는 작업
  • 블로그 글을 MDX 혹은 마크다운으로 포맷하는 작업

Gatsby나 대부분의 Jamstack의 경우에는 이미 모두 플러그인으로 만들어져 있는 작업들입니다. 하지만 Next.JS의 경우에는 블로그의 Boilerplate라고 할 수 있는 것이 타 프레임워크에 비해 상대적으로 많이 없기도 하였고 사실은 막막했습니다. SSR 그리고 SSG로 웹 사이트를 배포하더라도 잘 작동해야 했고 구조적으로 어떤 것이 더 좋을까도 고민을 많이 했습니다.

블로그가 잘 작동하는지 테스트하는 글이기도 하고 여러모로 일단 그동안은 어떤 일을 했는지 쭈욱 써내려보았습니다. 이후 개발 상황은 Typed-sh/blog에서 계속 보실 수 있습니다. 앞으로는 같은 일이 발생하지 않았으면 좋겠습니다.

Copyright 2021 Typed.sh contributors.