나만의 Next.js Blog 프로젝트 구상

목차

0. 프로젝트 설계

1. 블로그 프로젝트를 구상한 이유, 목표

2. 사용할 주 기술

• Sass(SCSS) vs styled-components
• Node.js + React vs Next.js

3. 폴더 구조

---

0. 블로그에 필요한 기능을 나름대로 설계해보았다.

설계를 하면서 느낀 것이지만, 블로그는 참 정적이다 api 요청할 일이 별로 없다.

게시물(작성, 조회, 검색, 좋아요, 수정, 삭제), 댓글(작성, 조회, 수정, 삭제)

 

---

1. 블로그 프로젝트가 만들고 싶은 이유, 목표 (2023.09.09~)

기존에 만들었던 사이트들은 페이지가 독립적인 정보를 지니고 있으며 상호작용이 거의 없었다.

A페이지에서 수행하는 작업은 오로지 A데이터를 전달하면 될 뿐이고,

B페이지는 단지 B데이터를 필요로 한다. A-1,A-2는 B페이지에 영향을 끼치는 케이스가 필요로 했다.

 

따라서 좀 더 복잡한 구조의 상호작용과 이에 따른 데이터 이동을 구현하고 싶은데

서버사이드 렌더링에 대해서도 알고 싶어졌다.

클라이언트 사이드 렌더링은 인터렉션에 뛰어나나 초기에 애플리케이션을 로드하는 시간을 필요로 한다.

코드 스플리팅을 통해서 초기 로딩 속도를 끌어올리는 것이 프론트에서 중요하다고 생각하지만,

서버사이드 렌더링으로 프로젝트를 구현해보고 둘의 차이를 알 필요가 있다고 느꼈다. 

그런 의미에서 Next.js 한 번 부딪혀보자.

 

Next.13의 기능 학습과 서버사이드 렌더링의 흐름에 대한 이해를 강화하기 위한 프로젝트. 
유튜브, 네이버, 티스토리 등의 서비스를 관찰하며 API를 설계하고 기능을 구현. 
회원기능, 게시판, 계층형 카테고리, 계층형 댓글, 권한별 분기, 활동 관리 등.

 

코딩 스타일 목표

• sendbird 코드 스타일을 참고하여 직관적인 폴더와 컴포넌트 구조를 만들기 위해 노력
• 그때그때 필요한 작업을 생각하는 대신, 체계적인 설계 후 기능 구현 노력 (UI>인터렉션>server>DB 각 과정에 필요한 작업을 글로 정리한 뒤에 코딩하는 습관 들이기)
• 전역상태관리의 사용을 최소한으로 하고 서버 컴포넌트와 클라이언트 컴포넌트의 경계를 구분하여 컴포넌트 간의 결합도 최대한 낮추기
• 하나의 함수는 하나의 기능, 하나의 기능 컴포넌트는 하나의 기능만 수행
• Github issue 주도 커밋으로 구현할 기능, 발생한 문제 관리
• 시범적으로 도입해볼 라이브러리나, 테스트 기능은 branch로 작업한 뒤에 merge 또는 폐기
• 웹보안 XSS, query injection attack 방어에 신경쓰기

 

구현할 기능

회원 기능

관리자, 유저, 게스트로 나뉘어 각 클라이언트 별로 접근 가능한 컴포넌트가 구분되어 있다.

API 요청을 보낼 권한이 없는 경우에는 잘못된 접근 처리를 하도록 한다.

 

• 관리자: 모든 추가, 수정, 삭제 권한
• 유저: 자신이 작성한 게시물 또는 댓글 수정, 삭제 권한
• 게스트: 댓글 작성만 가능

사이드 네비게이션

블로그 프로필과 카테고리를 포함하는 메인 카테고리, 게시물을 포함하는 서브카테고리로 분류하는 역할을 한다.

 

• 블로그 프로필: 블로그의 머리와 관리자 권한으로 블로그 편집 페이지로 이동
• 메인 카테고리: 서브카테고리를 포함한다.
• 서브 카테고리: 게시물을 포함한다.

네비게이션 헤드

좌측에는 블로그 메뉴, 중앙에는 블로그 이름, 우측에는 게시물 검색과 계정 활동을 관리한다.

 

• 블로그 메뉴: 블로그의 기능이나 게시물을 확인할 수 있는 모달 메뉴
• 블로그 이름: 블로그의 h1을 담당하여 블로그 메인으로 이동
• 검색: 게시물을 제목 또는 카테고리명으로 검색하는 활동을 수행한다.
• 유저 프로필: 로그인, 로그아웃, 계정 관리, 좋아요 및 댓글 활동 관리 등

게시물

게시물 카드에는 게시물의 정보를 한 눈에 볼 수 있도록 한다.

게시물에는 회원 권한에 따라 댓글과 좋아요 기능을 구분한다.

 

• 게시물 카드: 게시물 대표 이미지, 게시물 카테고리, 좋아요 및 댓글 수
• 게시물 상세: 에디터로 작성한 게시물 내용을 적절하게 출력하도록 한다.
• 댓글: 권한별로 댓글의 작성, 수정, 삭제 분기를 다르게 한다.

관리 페이지

블로그 편집기능과 로그인 한 유저가 한 댓글 활동, 좋아요 활동을 모아서 관리할 수 있도록 한다.

유저의 정보를 수정할 수 있도록 한다.

 

• 블로그 편집: 카테고리 추가, 수정, 삭제
• 활동 관리: 좋아요한 게시물을 모아볼 수 있는 기능 및 댓글을 작성한 게시물을 모아볼 수 있는 기능
• 계정 관리: 유저 닉네임, 프로필 이미지 수정

---

2. 사용할 기술

2-1. styled-components vs SCSS

styled-components의 장점

• JavaScript 변수를 활용한 조건부 스타일링이 매우 쉽다.
• 스타일 오염을 일으킬 걱정을 하지 않아도 된다.
• mixin 방식보다 스타일링 확장이 쉽고 간편하다.
• css 파일을 별도로 생성하지 않아도 된다.
• css의 depth가 깊어질 걱정을 하지 않아도 된다.

...등등 당장에 생각나는 장점만 고려해도 충분히 쓰고 싶을 만큼 장점은 많다. 

 

styled-components의 단점

• Next.js에서 SSR을 할 때 head에 스타일을 삽입하는 세팅이 필요하다.
  (styed-components는 기본적으로 use client 에서 동작한다.)
• 그래서 styled-components를 모르는 사람과 협업할 때 배울 것이 더 많다. 
• 상호작용을 할 때 동적인 스타일이 버벅임을 보이는 일이 많다.
  (특히 themeProvider를 설정하고 theme을 바꿀 때 화면이 깜빡거리거나 원본 형태로 일순간이나마 되돌아 간 화면을 보는 것은 좋지 않은 경험이었다.)
• 협업 시 스타일 컴포넌트인지 일반 컴포넌트인지 구분이 쉽지 않을 수 있다.
• 스크립트가 길어진다.

---

결론적으로 SCSS를 쓸 것이므로 styled-components와 비교하면서 보자 

sass의 단점 vs styled-components (이하 S-C)

• S-C는 JavaScript 변수를 활용한 조건부 스타일링이 매우 쉽다. => 확실히 S-C에 비하면 쉽지 않다. inline은 때때로 코드를 쉽사리 길게 만든다.
• S-C는 스타일 오염을 일으킬 걱정을 하지 않아도 된다. => 문제 없다. 상쇄된다. style.module.scss를 이용하면 된다.
• S-C는 mixin 방식보다 스타일링 확장이 쉽고 간편하다. => 문제 없다. mixin도 전혀 어렵지 않고 충분히 간편하다.
• S-C는  css 파일을 별도로 생성하지 않아도 된다. => 조금 아쉬운 부분이다. 하지만, 폴더구조를 통해 index파일과 SCSS 파일을 함께 관리하면 되고, 생산성에 있어서는 오히려 scss가 더 빠르다. 파일이 분리되어 있는 만큼 IDE에서 화면 분할을 하는 것이 빠른 스타일링에 있어서 훨씬 유리하다.
• S-C는 css의 depth가 깊어질 걱정을 하지 않아도 된다. => 아쉬운 부분이다. SCSS는 때에 따라서 누가 누군지 분간이 안 될 만큼 depth가 깊어질 때도 있다. 이럴 때에는 컴포넌트를 분리하는 방법을 이용하면 되는데, 불필요하게 컴포넌트를 복잡하게 만드는 것이 오히려 기능 구현에 어려움을 가져올 때도 많다. 주객이 전도된다.

sass의 장점 vs S-C

• 별도의 세팅이 필요없이 바로 작업을 시작할 수 있다.
• S-C에 비해서 css를 숙달할 수 있다. 결국 프론트 개발의 근본은 css라고 생각한다.
• css-in-js보다 상호작용을 할 때 스타일 적용이 부드럽고 매우 빠르다.
• 배우기 쉽다. 협업 시 css만 써 본 사람이라 할지라도, scss를 한 번 써보면 여태 왜 안 썼나 하며 혀를 내두를 것이다.
• 번들링 사이즈가 줄어든다.

S-C를 쓰는 것보다 SCSS를 썻을 때 장점이 더 많다고 생각했다.

 

오염 걱정을 하지 않아도 되고, 빠르고, 성능에 유리하며, (생산성도 관점에 따라서 유불리가 다르지만 유리할 때가 많은 듯 하다)

결국엔 css 경험치를 잘 쌓으려면 css를 많이 써봐야한다.

 

2-2. Node.js + React vs Next.js

Next.js 장점

• 블로그의 포스트가 검색이 잘 되는게 좋다.
• React보다 훨씬 쉽고 간편한 라우팅
• React + Node.js보다 훨씬 쉽고 간편한 Api 생성
• 내장 fetch 데이터 캐싱 기능 (프로젝트 전반에 걸쳐 중복된 요청에 대해서는 한 번만 요청을 한다.)
• 이미지 최적화에 있어서 유용한 기능들이 탑재되어 있다. (개인적으로는 이게 제일 매력적이다.)
• 협업 시 일관된 코드를 경험할 수 있다. (장점이자 단점이지만 협업에서는 굳어진 규칙이 훨씬 유리하다고 생각한다.)
• 정적 페이지와 동적페이지를 구분할 수 있다. (초기 렌더링 속도에 한 몫 한다. 불필요한 컴포넌트 리렌더링을 안해도 된다.)
• 번들링 된 파일의 크기가 작다.

아직은 Next.js로 프로젝트를 제대로 구성해본 적이 없지만 지금까지 확인한 기능들만 해도 비교할 수 없을 만큼 뛰어나다.

 

Next.js 단점

• 페이지 전환 시 화면 깜빡임 (개인적으로 빠른 네트워크 환경에서 전혀 신경 안 쓰인다.)
• 프론트와 백의 모호한 경계 (폴더 구조로 SSR기능을 구현하고, 파일의 'use client'로 CSR을 구현하는데에서 발생하는 문제로 인해 작업 바운더리가 겹치는 부분이 많지 않을까)
• 편리한 기능들로 인한 능력 퇴화 (도구로부터 얻을 수 있는 편리함은 양날의 검이다. 불편함 속에서 얻을 수 있는 값진 경험들을 배제시킨다.)

써봐야 알 것 같다.

개인 프로젝트로 진행한다고 가정하면 장점이 많다. 그냥 우월하다.

---

3. 폴더 구조

작업에 앞서 이번엔 폴더 구조를 정해놓고 가야겠다고 생각하여 여기저기서 찾아보았다.

폴더구조 사이트 보러가기

app

- 라우팅과 서버 데이터를 클라이언트 컴포넌트에 props로 내려주는 기능을 담당하도록 한다.

- layout과 page만이 들어가고, 그 안에 containers에서 구현한 컴포넌트를 가져다 쓰도록 한다.

 

components

- 여기저기서 쓰일 컴포넌트들이 들어간다. (button 같은 것들)

 

constants

- 상수를 모아놓는다.

 

containers

- 독립된 기능을 다루는 컴포넌트들이 들어간다.

- 당연히 이 안에는 components의 컴포넌트들이 포함될 수 있다.

 

hooks 

- 너무 길어지거나 중복되는 훅은 커스텀 훅으로 관리하여 코드 품질을 높인다.

 

styles

- mixin: FlexBox와 같이 자주 쓰이는 스타일을 모아놓고 가져다 쓸 수 있도록 한다.

- animations: 애니메이션 효과를 별도로 모아놓고 가져다 쓴다.

- zIndex: z-index는 모아서 관리 안하면 위아래도 없는 ui를 만날 수 있다. 

- variabels: 컬러나 사이즈는 반드시 변수로 선언하여 가져다 쓰도록 하여 리팩토링할 때 스타일 생산성을 높인다.

 

예시)

다른 곳에서는 xs md lg 뭐 이렇게 적어놓는데 그거 기억하려다 머리 쥐날 것 같아서 직접 숫자로 관리하도록 하였다.

그럼 13px을 전부 130px로 바꾸고 싶은 경우엔 어떡할까?

--ft-13 과 중복되는 문자는 이 프로젝트 어디에도 존재할 리가 없다.

vscode의 ctrl + shift + h 단축키로  --ft-13을 전부 로 바꿔주면 되는데... 문제가 있으려나

 

types 

- 타입스크립트로 작업할 것이기 때문에 중복되는 타입을 모아서 관리한다. (솔직히 한 파일에서만 쓰일 타입도 강박적으로 모아야 하는 가에 대해 의문이 들 때도 있어서 개인적으로는 전부 다 모아놓지는 않는다. 하나의 파일에서만 쓰이는 타입이라면 파일 자체로 모듈화를 수행한다고 생각한다.)

 

utils 

- 여기저기서 쓰일 수 있는 함수는 별도로 모아놓고 가져다 쓴다.