3 min to read

커리어 점프를 위한 PS 풀이 블로그 분관 개설 - 08.24 ~ 08.28

글 하나로 적기에는 애매해서, 여러개를 묶어 봤습니다.

Featured image

들어가며

PS 풀이 블로그 분관 개발록을 계속 쓰고 있었습니다만, 최초 배포 이후의 기록은 글 하나씩 적기에는 분량이 애매해서, 이렇게 모아서 써볼까 합니다.

08.24 : 최초 배포, 댓글 시스템 부착 완료

vercel로 원 클릭 배포를 하였습니다. 배포 자체는 어렵지 않았지만, 한국에서의 vercel.app 도메인 차단 때문에, 도메인을 algorithm.kasterra.dev로 바꿔서 사용해야 했습니다.

그리고 giscus로 댓글 을 부착하였습니다. 현재 본관 블로그에서는 utterance를 쓰고 있지만, 대댓글 시스템이 자연스럽지 않은 문제가 있고, 여러 잘 알려진 웹 서비스에서도 사용하는 것이다 보니, 이번 기회에 익숙해지는 것도 좋은 생각이라 생각해서 부착하게 되었습니다.

giscus 관련해서 이슈가 여럿 있는 것으로 보였습니다. 단순 HTML 마크업으로 장착을 하면, CSR을 통해서 URL이 변경되면 감지를 못한다던지 하는 것 등이었습니다. 다행히도 giscus 공식 react 래퍼가 있어서, 적용했을 때, 관련 이슈는 없었습니다.

이 때, giscus를 적용하면서, 이건 클라이언트 사이드 라이브러리인데, 바로 서버 컴포넌트에 적용하면 안되지 않나? 하는 생각을 시작으로, next의 서버 컴포넌트와, 클라이언트 컴포넌트를 함께 쓰는 법에 대해서 공부하게 되었고, 그 결과물이 26일에 작성된 next 글입니다.

08.26 : 폰트 수정등의 마크업 개선, URL 생성 기준 변경, giscus 설정

별관 블로그에 글을 작성하면서, safari와 chrome에서 보이는 폰트의 차이가 있다는 것을 알게 되었습니다. 폰트 폴백등의 기준이 달라서 그렇겠지 싶었지만, 폰트를 스타일시트에 명시적으로 지정을 해서 사용하는 만큼, 이왕이면 두 브라우저에서 비슷한 모습으로 보이길 바래서, 한글을 지원하는 Noto sans CJK를 적용하고, 쓰지 않는 폰트들을 정리하였습니다.

그리고 한글로 제목을 사용하니, slugify함수에 통과가 되면 아무것도 남는게 없어지기 때문에, 블로그 본관 처럼, 파일 제목을 기반하여, URL을 만들게 수정하였습니다.

라이트/다크 모드 전환이 되는 별관 블로그 특성상, giscus 혼자서 색깔 스킴이 튀어버리면 곤란했기에, giscus 래퍼에 대해서 useTheme을 이용해서 테마를 받아오고, postMessage를 이용해서 테마 변경을 요청함으로서, 테마를 바꿀 때 마다 재렌더링 되는 일 없이 테마만 바뀌도록, useMemo로 key를 설정하게 하였습니다.

실제 구현체

08.27 : 소소한 스타일시트 수정

이 날은 처음으로 글에 인라인 코드블럭 (this.key 이런거)를 적용을 했었는데, 스타일이 이쁘게 나오지 않아서, mdx 렌더 내에서 코드블럭을 렌더링 하는 스타일시트를 추가하였습니다.

08.28 : 공부로 끝난 로딩에 관한 공부

예전 로드맵 중에서 로딩과 에러 처리에 대해서 구현하는 것 또한 있었습니다. 느린 네트워크 환경에서도 아무 반응이 없는 것이 아닌, 보장할 수 있는 만큼의 UX를 보장하기 위해서 chrome devtools에서 3G로 네트워크 쓰로틀링을 걸어, 확인을 했고, 기존의 사실상 page.tsx만으로 이루어져있던 블로그 글 상세 페이지를, layout.tsx에 일임할 수 있는 부분은 일임하고, loading.tsx가 무엇인지 next 공식 문서를 통해 공부하고 내용을 작성하였습니다.

그리고, 로딩을 길게 하는 원인도 찾아냈는데, Source_Sans_3라는 폰트의 모든것이 html에 인라인으로 들어가 있어서, 100KB 단위로 CSS 파일이 컸던 것이었고, 3G 환경 등의 느린 환경에서 초기 속도가 느린것을 확인하고, 27일에 스타일링 위해서 Firacode만 사용하면 되니, 쓰지 않는 폰트들을 쳐내서 로딩 시간을 디버깅 환경 기준 7초에서 4초 정도로 개선하는데에 성공하였습니다.

다만 제목에 적혀 있듯, 이것이 단순히 공부로 끝난 이유는, pnpm run dev를 실행했을 환경 기준이었고, 실제 빌드 결과는 SSG된 HTML을 받아오기만 하면 되기 때문에, 별도의 로딩을 구현할 필요부터가 없었던 것 입니다. CSS 번들 사이즈 절약은 성공했지만, 실질적 개선 효과는 기대하던 것 보다는 약간 부족해서 아쉬웠습니다.

마무리하며

4일간의 개발록을 한 포스트안에 몰았는데도, 내용물이 짧아서인지, 그렇게까지 과하다 라는 느낌이 들지 않는군요. 아마 앞으로의 일도 생각해보면, 예전에 해봤던 것들의 연장선이라서, 이런식으로 개발기를 이어나가지 않을까 싶습니다. 끝까지 읽어주셔서 감사합니다.

완료된 것들

앞으로 할 것들