heeji.dev

TWIL 6월 4주차 회고: Next.js로 블로그 만들기 시작

2024-06-24

한 것

블로그 만들기
  • 목적
      1. 너무 빨리빨리 하려하지 말고 잘 모르는 건 짚고가기
      1. 포트폴리오 만들기
      1. Next.js 앱 라우터 익히기 (만들면서 배우기!)
  • 진행상황
    • GNB, 홈페이지, 글 목록 페이지, 글 상세 페이지, 어바웃 페이지, 다크모드 구현, meta tag 생성파일 추가
  • TODO
    • opengraph-image.tsx로 og 이미지 생성되도록하기
    • robots.tsxsitemap 추가하기
    • 디자인 작업 및 마감

    • (추가로 해볼 것들)
    • 검색기능
    • 댓글창
 
블로그 만들면서 생긴 궁금증 해결
  • 웹 렌더링 기법들, React Server Component, Next.js 12 → 13 변경점, Next.js에서 스타일링
 

고민과 어려움

블로그 글을 어디서 관리하는 게 좋을까 고민
  • 정적 데이터로 관리? repo 안에 정적으로 md, mdx를 만들어 관리할 수도 있지만, 이랬을 때 불편했던 경험이 글 조금 수정하는데 커밋해야하고 그게 로그로 다 남아서 사람들에게 보여주고 싶지 않았다. 보통 글 작성을 노션으로 하고 옮기는데 그러면 이미지를 또 repo에 올리고 파일을 수정해야하는 번거로움
  • Headless CMS 활용? 시중에 나와있는 것들을 활용하면 컨텐츠를 편집하고 내장 API로 내 프로젝트에 불러오면 되니까 니즈가 충족될 것이라 생각했다. 검색해서 나온 것이 SanityStrapi 등등. 문서 보면 특징들이 그렇게 유의미한 차이가 없다고 느꼈고 (왜냐면 나는 블로그 글만 관리할 거니까) 직접 설치해서 적용해봤는데 지금 내 상황엔 너무 과하다고 판단.
  • 노션을 CMS로 활용! 어차피 나의 블로그 글 편집기는 노션이고 검색해보니 노션 open API를 활용해 데이터를 불러올 수 있고 이를 렌더링하는데 도움을 주는 라이브러리가 있어 손쉽게 데이터를 관리하고 보여줄 수 있다고 판단함
 
다크모드 구현
  • 일단 검색했을 때 다 next-themes 라이브러리를 활용하는 글 밖에 없었음. 라이브러리 없이 못하나 싶어서 일단 직접 해보기로 함
  • 방법1: 처음에 로컬스토리지에 저장하고 클라 컴포넌트에서 얘를 반영하고 변경하는 방법을 생각했는데 이렇게 하니 첫 HTML과 JS 로드 완료 그 사이 간극 때문에 깜빡임이 발생
    • layout에서 dangerouslySetInnerHTML로 클라이언트에서 돌 수 있는 코드를 주입해서 서버에서 받아온 HTML 읽을 때, 로컬스토리지 정보 반영되도록 할 수 있음
  • 방법2: theme 정보를 쿠키로 관리한다. 쿠키는 클라와 서버 사이 통신을 가능하게 하니까 여기에 저장해놓고 layout에서 쿠키 내용 꺼내서 보게함
    • 괜찮은 방법인줄 알았는데.. 문제: 기본적으로 next 프로젝트를 build하면 static하게 만드는데 레이아웃에서 쿠키 접근이 있다보니 정적으로 생성이 안되고 on-demand로 빌드되어버림
    • next-themes 적용해보니 빌드했을 때 정적으로 잘 생성됨 → 어떤 원리로 가능한지 조사필요
 
CSR 대비 SSR의 강점이 뭘까
이해가 안됐던 부분
  • SSR하면 FCP ~ TTI 사이 간극이 생기는데 이걸 감수할 만큼의 이득이 있는가? 아니면 주로 인터랙션이 많이 일어나지 않는 곳에서 선택하는 건지
  • CSR에 비해 받아올 JS 번들 크기가 작아 초기 로딩 속도가 빠르다는데 코드 스플리팅으로는 어림도 없는지
내린 결론
  • 간극이 생기는 것은 사실이나 SSR의 주된 이점은 빠르게 사용자에게 첫 컨텐츠를 보여줄 수 있다는 것이다. 이를 통해 사용자 경험이 개선됨. 만약 인터랙션이 많아서 이 간극이 문제가 될 만큼이다 싶으면 CSR을 채택하면 될 것 같다.
 
 
React Server Component를 사용했을 때 이점?
이해가 안됐던 부분
  • RSC에서는 API 불러오는 것, DB 접근하는 것 등을 서버에 넘겨서 클라이언트 부담을 줄여주는데 그럼 이 부담이 서버로 그대로 옮겨가는 게 아닌가? 어떤 이득이 있는 건지
  • 서버/클라 컴포넌트로 나뉘어서 ‘use client’ 이런 것도 써줘야하고 복잡해진 것 같다.
내린 결론
  • 검색에 따르면 서버는 일반적으로 더 강력한 하드웨어와 최적화 환경을 갖추고 있어 클라이언트보다 데이터 패칭과 연산을 더 효율적으로 처리할 수 있다고 한다. 그리고 클라우드 비용이 많이 싸져서 그리 부담스럽진 않은 듯
  • 분리했을 때 복잡성은 있지만 유지 보수성과 확장성 측면에서 큰 이점을 제공한다는 듯
 

아쉬웠던 점과 개선 방향

  • 아쉬웠던 점은 개인적으로 플젝구현:개념공부를 8:2 정도로 가져가려고 했는데 개념공부에 큰.. 어려움을 겪어 6:4 정도의 비율이 됐다는 것. 이번주에 블로그 완성할 수 있을 줄 알았는데 한 50%밖에 안됐다. 근데 내가 어려움을 겪었던 게 “서버에서 렌더링한다”라는 개념이 잘 안 받아들여졌던 부분이 있었다. 이제 어느정도 이해를 한 상태이고 개념공부에 속도가 더 나지 않을까 생각한다.
  • 멘토님이 알려주신대로 컨퍼런스 & 아티클들을 잘 활용해서 공부해보면 좋을 것 같다!
 

다음주 계획

  • 블로그 프로젝트 완성
  • 이력서 수정 후 3군데 제출
  • 이력서 기반 면접 질문 준비