현재 블로그가 만들어지기 까지의 상황에 대해서 이야기 해보려 합니다. 아마 이 방법으로 구현할 사람이 많아질 것이라고 예상됩니다.
우선, 본론으로 들어가기 전에 블로그를 왜 직접 만드냐라고(velog, tistory 등이 있음에도 불구하고) 물어보실 수 있을 것 같습니다.
블로그 만든 이유
만들 수 있어서 만들었습니다.
그냥 만들었긴 했는데 아무 생각 없이 만들지는 않았습니다. 몇 번, 블로그가 만들어지고 지워졌었는데 이제 이걸로 정착할 것 같습니다. 현재는 Docusaurus라는 라이브러리를 통해서 구현하였습니다. 블로그를 엎었었던 이유가 여러가지 있는데 이는 아래의 블로그 구현 기준을 통해 설명하겠습니다.
블로그 구현 기준
SEO
첫번째로, SEO 입니다. 기존에 Create React App을 이용해서 구현하였다가 크롤링봇들의 행동 양식(?)을 파악한 후 Single Page Application이 가지는 불리함들이 눈에 계속 밟혀 엎어버렸습니다. (물론, 똑똑한 크롤링 봇은 idle 상태를 통해 해당 페이지의 최종 렌더링 상태를 얻어올 수는 있을 것입니다...) Docusaurus는 md 파일들로 새로운 html 문서를 미리 만들어놓기 때문에 크롤링 봇들이 가장 단순하게 받아들일 수 있는 상태로 만들어줍니다. 이는 단순하게 크롤링할 수 있는 최상의 조건이므로 Docusaurus를 사용하게 되었습니다.
컨텐츠 에디터
두번째로, wysiwyg입니다. 에디터를 이용해서 컨텐츠를 생산해야하는데 여러가지 에디터 라이브러리 중 뭐를 쓸 가에 대해서 많은 고민을 하였습니다. 그러다가 든 생각이 굳이 에디터 라이브러리를 포함해야할까?이었습니다. github의 좋은 에디터가 있는데에도 불구하고 (심지어 이미지 업로드까지 됩니다!) 에디터 라이브러리를 도입할 필요가 없다고 판단하였습니다. 물론, github 에디터도 외부 시스템이기 때문에 기술 부채이기는 마찬가지이지만 이런 기술 부채는 떠앉고도 된다고 판단하였습니다. 달러가 기축 통화이듯이 github도 에디터계의 달러라고 생각하였기 때문입니다.
디자인
세번째로, 디자인입니다. 저는 디자이너가 아님에도 불구하고 블로그의 디자인에 대해 너무 많은 고민을 했었습니다. 폰트, 컨텐츠 배치, 색감 등 여러가지 선택사항들을 두고 고민하면서 하나하나 구현하다보니 배보다 배꼽이 커지게 되는 격이라고 생각하였습니다. 물론, 프론트 개발에서 주체적으로 디자인을 결정해서 개발하는 것도 중요한 일이지만, 단순 블로그 개발에 어쩌면 컨텐츠가 중요한 서비스에서 디자인 고민으로 블로그 시작이 지체되는 것을 더 이상 기다릴 수 없었습니다. 그러던 중 Docusaurus라는 라이브러리를 접하게 되었고 이거다!하면서 바로 공식문서를 정독하고 하루만에 구축하게 되었습니다.
기술 스택
Docusaurus
다큐사우루스는 페이스북 팀에서 만든 정적 사이트 생성 도구입니다. 정적 사이트는 사용자한테 전달될 컨텐츠를 미리 html 형식의 파일 등으로 제작이 되어있고 그것을 serving 하여서 보여주는 사이트입니다. 매일 매일 바뀌는 정보가 아니라면 문서, 블로그와 같은 사이트들은 정적 사이트로 제작되어도 다른 문제는 발생하지 않습니다. 다큐사우르스의 특징중에 하나로 react와 md(x)를 이용하여 페이지를 추가할 수 있다는 것입니다. 이는 css, js를 이용한 html을 써야하는 페이지이면 react를 사용하면 되고 정형화된 패턴의 글을 작성할 것이라면 마크다운 형식으로 파일을 작성하면 됩니다. 현재 블로그는 react를 이용하여 about 페이지를 작성하였고 나머지 블로그 글들은 mdx 형태로 작성하였고 빌드 되는 과정을 거쳐서 html로 배포됩니다.
React
요즘 프론트 프레임워크의 대명사인 React를 이용하였습니다. 현재 react로 구현된 페이지는 about 페이지 밖에 없습니다. 추후에 블로그 리스트에서 태그 카테고리를 한눈에 볼 수 있도록 추가할 예정입니다. 이는 다큐사우르스의 custom 테마 만들기를 이용하여 진행할 예정입니다.
utterances
다큐사우르스는 기본적으로 정적 사이트 생성 도구입니다. 그래서 댓글과 같이 가변적으로 받아야 하는 정보들을 표시하려면 API 서버를 구축하여 데이터를 받아와야합니다. API 서버 구축하는데에 시간적, 공간적 비용을 들이기 싫어서 utterances를 이용하기로 결정하였습니다. utternaces는 github의 issue 시스템을 이용해서 댓글 서비스를 구현하는 라이브러리입니다. github repo에서 셋팅 후 script 태그로 불러오기만 하면 되서 설정도 간편하고 도입하기 쉽습니다. 기본적으로 개발 블로그라 github 계정으로만 사용해도 괜찮다고 생각하였습니다.
이런식으로 댓글 서비스를 이용할 수 있습니다. 많이 달아주세요~
Google Analytics
사용자 유입, 어느 글을 많이 읽는지 확인해보기 위해서 도입하였습니다. 워낙 많이들 사용하니 설명은 생략하겠습니다.
Google Adsense
저는 자본주의의 노예입니다...
그래도 기본적으로 메인에서는 광고는 안 보이게 설정할 예정입니다.
22.01.10 기준 아직 승인을 안 해줘서 광고는 안 보이는 상태입니다.
Github Actions
자동화 배포로 Github Actions을 사용하였습니다. 배포 순서는 다음과 같습니다.
- main 브랜치에 push
- npm run build (docusaurus build)
- 호스팅 서버로 build 산출물들 이동
- 정적 호스팅 서버에서 serving
여기서 1번, 2번, 3번을 github actions을 통해서 자동화하였습니다.
별도의 구축 없이 github repo actions 탭에서 배포 현황을 확인 가능합니다.
AWS
위 4번 정적 호스팅 서버 인프라는 AWS를 사용하였습니다. 정확히는 S3와 CloudFront를 이용하였습니다. S3는 정적 파일들을 저장하기에 최적화된 인프라 서비스입니다. 그래서 파일을 전송하는데에는 최적화되어 있지는 않은데 그것을 도와주는 역할로 CloudFront를 이용합니다. 그리고 jaejun.me 도메인을 사용하기 위해 route 53도 이용하였습니다. AWS 인프라와 관련된 사항들은 다음에 더 자세히 설명하겠습니다.
개선점
GA와 Adsense와 관련된 다큐사우루스 플러그인들을 install 해서 사용했었습니다. 내부 코드를 보니 그렇게 어렵게 구현되지 않아서 custom 해서 사용할 예정입니다.
블로그 태그들을 리스트에서 한 눈에 보이기 쉽게 만들 예정입니다.
크롬의 Lighthouse를 사이트를 이용해서 측정하였을 때,
PWA 부문 제외 평균 90점을 넘긴 것을 확인하였습니다.
(PWA를 보완해야되겠군요...)
마무리
새해 목표로 블로그 글 한주에 1개씩 쓰기로 마음을 먹었습니다. 이전까지는 개발 능력 향상에만 집중하였었는데 문서화 작업이 여러모로 도움이 된다는 것을 깨닫고 하나씩 작성해 나갈 것입니다. 1년 뒤에 다시 이 글을 보았을 때, 목표 달성이 되었기를 바라겠습니다.