돌고 돌아 .mdx기반의 블로그로 온 이유

필자는 이미 세 번(공식 2번, 비공식 1번)의 블로그를 거치며 그 곳에서 블로그 글을 작성해봤습니다.

하나는 Velog, 나머지 하나는 tailwind-nextjs-starter-blog 라고 Next.js + .mdx기반의 블로그 템플릿 입니다. 그리고 비공식 블로그로 basehub가 있네요.

하지만 여러 블로그를 작성해본 후기로, 글을 작성하다 보면 묘하게 불편하다는 생각이 들었습니다.

그래서 이번엔 왜 필자가 .mdx기반의 블로그를 사용하는지 알아봅시다.

기존의 블로그 들의 문제점

한번 각각 어떤 문제점들이 있었는지 살펴봅시다.

Velog

Velog는 이미 개발 분야에 대해 많은 개발자들이 사용하는 개발 블로그 플랫폼이라 보면 됩니다.

하지만, 개발관련 글 작성에 특화되어 있다지만.. 몇 가지 단점들이 있는데요.

1. 가끔 플랫폼에 문제가 생김

일단 먼저 가장 큰 단점으로 플랫폼 자체가 연결에 문제가 생기기도 합니다.

그래서 가끔 글을 쓸까 싶어서 Velog에 들어가면 들어갈 수 없다고 하는데요.

이 문제는 제가 어떻게 할 수 없어서 참으로 답답하다는 생각이 들었습니다.

2. 직접 블로그 포스트 외에 건드려 볼 것이 없음

이 부분은 다른 분들이 봤을 때,

오히려 글에 집중할 수 있어서 좋은 것 아니냐?

싶겠지만 직접 데이터를 조회 해보면서 한눈에 이 블로그가 잘 된다는 데이터를 보고 싶다는 생각이 들었습니다.

하지만 Velog는 최근 며칠 내 조회수도 막아놓고 오로지 포스트를 들어가야 해당 누적 조회수를 확인해 볼 수 있습니다.

이 부분이 은근 짜증나더라구요.

그래서 새로 블로그를 직접 만들어보자는 생각이 들었습니다.

Next.js + tailwind 템플릿

그렇게 찾은 것은 next.js기반의 블로그 템플릿입니다.

처음엔 Gatsby라는 프레임워크도 고려할만 하지만, 익숙하면서 Gatsby와 같이 블로그 템플릿이 존재하는

Next.js가 있기 때문에, 그냥 Next.js를 사용했습니다.

그리고 Next.js를 사용하는 블로그 템플릿을 살펴보던 중, 눈에 띄는 블로그 템플릿이 있어서

해당 블로그 템플릿을 사용하기로 합니다. 그리고 velog와 다르게, 템플릿으로 존재하는 가상 데이터들을 지우고, 저만의 데이터를 채우며 점점 필자만의 블로그를 만들어 가고 있었습니다.

하지만 여기서 생각해볼만한 문제점들이 존재하게 됩니다.

1. 프론트엔드에 모든 자원들이 몰려 있음

이 말이 무슨 말이냐면.. 보통 .mdx형식으로 파일들을 저장하게 되는데, 필자의 경우, public폴더에 블로그용 사진을 올리곤 했습니다.

그렇게 사용하다보니 저장소 자체가 무거워질 수 있겠다는 생각은 했습니다. 물론 유의미하게 무거워지진 않았습니다. 보통 영상이 1초에 사진 60장을 사용하는데, 이것보단 훨씬 적으니까요.

그리고 이미지 CDN을 활용하면 굉장히 빠르게 이미지를 불러올 수 있습니다. 하지만, 저는 돈없는 학생이기 때문에, 자원들이 몰리는 현상에 대해 아무것도 못합니다..

하지만 지금은 구글 드라이브로 이미지를 저장해서 사용하여 나름 cdn처럼 사용하고 있습니다. 어떻게 사용하는지 이야기하면 분량이 너무 커질 수 있어서 링크로 대체합니다.

2. 개발로써 무언가를 해보기가 애매함

제가 사용한 템플릿에서는 pliny 라는 의존성 라이브러리를 사용 중이였는데, 이 라이브러리로 거의 글과 관련한 작업들을 node_modules에서 해결하였습니다.

그래서 .mdx를 어떻게 변환하는지, 직접 확인하고 커스텀하는 과정이 없다시피 했습니다.

사실상 블로그의 핵심인 것 같은데 말이죠.

헤드리스 CMS

그렇게 필자는 헤드리스 CMS를 한번 건드리게 됩니다.

과연 헤드리스 CMS는 무엇일까요?

일단 설명 링크를 드리자면 다음과 같습니다: https://aws.amazon.com/ko/what-is/headless-cms/

이를 간략하게 말하자면 서버(뒷단)에서 글을 작성하면 그 데이터를 프론트엔드(앞단)에 제공하는 것인데요. 결국 컨텐츠를 분산시켜 프론트엔드 자체 크기를 줄일 수 있습니다.

어떻게 보면 진정한 의미의 프론트엔드 역핧을 블로그에서 수행한다 생각합니다. 실제로도 개발하면서 그런 느낌이 들었구요.

하지만 여기에는 문제들이 있었습니다. 이는 제가 개발했던 basehub 외에도 다른 헤드리스 CMS에 공통적인 문제점이라 생각한 부분들을 추려서 이야기해보겠습니다.

1. 돈을 필요하면 써야함

헤드리스 CMS는 서버에서 글 데이터를 보내주므로, 더 많은 기능이 필요하다면 돈을 내야합니다. 물론, 개발을 혼자 하고, 혼자 쓴다면 과금은 거의 없다시피 하지만, 아무래도 제한된 개발을 한다는 느낌은 어쩔 수 없죠

2. 많은 리소스 소비

글을 쓰면, 바로 블로그 사이트에 즉시 적용되는 모습을 보여줍니다. 바로 사이트에 적용되는 것은 좋으나, 바로바로 적용이 되려면 렌더링을 계속 한다는 것인데, 이로 인해 배포판에서 확인해보면, 실시간으로 0.5초만에 렌더링해버립니다.

그래서 아래 사진처럼 기존 블로그에서 사용되는 데이터와 비교해보면 평균 10명이 오는 제 기존 블로그에 비해 단순히 헤드리스 cms로 작성 중인 글에서 리소스 소비가 큰 모습을 볼 수 있습니다.

결국 .mdx기반의 블로그를 사용하게 되다

그래서 결국 필자는 .mdx 기반의 프레임워크를 사용하기로 합니다.

Docusaurus

그 중에서 Docusaurus를 사용하게 되었는데요. 이 프레임워크는 기존의 단점들을 어느정도 커버할 수 있겠다는 생각이 들어 사용하게 되었습니다.

1. 커스텀이 어느정도 유연함

Docusaurus는 처음 터미널에 pnpm create docusaurus을 입력했을 때, 폴더 구성이 생각보다 적은 모습을 보여줍니다.

하지만, pnpm run swizzle기능을 이용하면 원하는 파일을 가져와서 해당 파일 안에 본인이 작성한 컴포넌트를 입력하여 커스텀이 가능합니다.

예를 들어, 블로그 포스트마다 댓글 기능을 남기고 싶다면, swizzle에 BlogPostItem을 추가하여 댓글을 남기는 컴포넌트 추가하면 됩니다.

...import

type Props = WrapperProps<typeof BlogPostItemType>

export default function BlogPostItemWrapper(props: Props): ReactNode {
  const location = useLocation()

  const isBlogListPage =
    location.pathname === '/blog' || location.pathname === '/blog/'

  const shouldShowComments =
    location.pathname.startsWith('/blog/') && !isBlogListPage

  return (
    <>
      <BlogPostItem {...props} />
      {shouldShowComments && <BrowserOnly>{() => <Comments />}</BrowserOnly>}
    </>
  )
}

2. 리소스가 적음

사실 상 .mdx파일을 업로드하는 것 외에는 거의 없다고 봅니다. 그 파일 업로드 하는 것도 현재 있는 .mdx 파일만 보면, 커야 17kb밖에 안됩니다.

근데 17kb가 얼마나 작은 값인지 가늠이 안가서, 이와 같은 파일들이 몇개 있어야 1gb가 될지 계산해봤는데요. 약 6만개를 작성해야 한다고 합니다. 한달에 2번 씩 약 2,500년동안 쓰면 1gb정도 차지하므로 이런 일이 생긴다면 그 때 가서 생각해봐야겠네요

마무리

이렇게 하여 다른 블로그 플랫폼에 정착하게 된 이야기를 해보았습니다. 기술 스택을 선정할 때, 최대한 인기 있어서라는 이유를 피하고자 어느정도 근거를 들어서 정착하게된 이유를 설명했는데, 다른 분들에게 좋은 도움이 되었을지 궁금하네요.

사실 블로그 플랫폼을 이용하면 제일 편하겠지만, 이렇게 한번 만들어 놓으면 나름대로 포트폴리오 2중대처럼 운영할 수 있으니까 블로그 개발기를 가능하면 연재해보는 것도 어떨까 싶긴 합니다.