프론트엔드
IT 로드맵의 프론트엔드 구역이다.
브라우저 · HTML · CSS · JavaScript · 렌더링
크기의 단위 — 설계는 백엔드와 같고, 실행과 짓기가 다르다
변수에서 쿠버네티스까지 크기 순으로 세우면 단위가 셋 나온다 — 실행 · 설계 · 짓기. 세 단위 그림은 백엔드의 크기의 단위에 있다. 거기서는 백엔드 코드로만 설명한다.
설계 단위는 백엔드와 같다. Next.js에도 함수와 클래스가 다 있어서, 변수 → 함수 → 클래스 → 책장 칸(세그먼트) → 책장(슬라이스) → 도서관(앱) → 도서관 단지(세 앱)가 그대로 선다.
다른 것은 나머지 둘이다.
| 단위 | 백엔드 | 프론트엔드 |
|---|---|---|
| 실행 | 바이트코드 → JIT → 기계어 → CPU | 자바스크립트 → 브라우저 엔진의 JIT → 기계어 → CPU. 그리고 화면 그리기가 한 겹 더 있다 — HTML → DOM → 배치 계산(레이아웃) → 칠하기(페인트) |
| 짓기 | 우리 땅(서버)에 도서관을 세워 두고 손님이 찾아온다. 이미지 → 컨테이너 → Pod → 노드 → 클러스터 | 조립식 가구를 택배로 보내 손님 집(브라우저)에서 조립한다. 빌드(번들) → 정적 파일 → 파일을 내려주는 곳(CDN · 웹 서버) → 방문자 브라우저 |
그래서 프론트의 짓기 단위는 「몇 채를 세우나」가 아니라 「택배 상자를 얼마나 작게 싸서, 얼마나 가까운 창고에서 보내나」가 질문이 된다. 번들 크기, 코드 쪼개기, CDN이 여기에 든다.
예외는 SSR이다. 서버에서 화면을 그려 보내면 그 서버는 백엔드처럼 컨테이너로 세운다. 우리 앱은 정적 생성(static export)이라 서버에서 그리는 단계가 없다. 우리 정적 파일을 실제로 어디서 내려주는지는 아직 확인하지 않았다.
아키텍처 — 프론트엔드는 두 번 고른다
프론트엔드 아키텍처를 공부하다 보니 이름들이 한 줄에 서 있지 않았다. 고르는 것이 두 가지였다.
- 책 배치 — 파일과 폴더를 어떻게 나누고, 어느 폴더가 어느 폴더를 불러도 되나
- 값 길 — 값이 어디에 있고, 바뀌면 화면까지 어떤 길로 흘러가나
두 축은 따로 논다. 폴더를 FSD로 나누든 Bulletproof React로 나누든, 그 안에서 값은 Redux로 흘려도 되고 컴포넌트 안 state로 둬도 된다.
책 배치는 도서관 단지 · 도서관 · 책장, 세 가지 크기로 본다
백엔드와 같은 틀이다. 도서관으로 치면 도서관을 몇 채 지을지, 도서관 한 채를 몇 구역으로 나누고 책장을 어느 구역에 둘지, 책장 하나의 칸을 어떻게 나눌지가 따로다.
| 크기 | 개발에서 | 묻는 것 | 선택지 | 우리 |
|---|---|---|---|---|
| 도서관 단지 | 시스템 | 앱을 몇 개로 나누나 | 앱 하나 · 마이크로 프론트엔드 | 세 채 (client · admin · business) |
| 도서관 한 채 | 앱 하나 | 구역을 몇 개 두고, 누가 누구를 부르나 | 종류별 폴더 · FSD · Bulletproof React | Bulletproof React 쪽 |
| 책장 | 기능 폴더 하나 | 책장 칸(ui · api · model 같은 칸)을 어떻게 나누나 |
FSD와 Bulletproof React가 각자 정해 둔 칸 |
FSD와 Bulletproof React는 도서관 크기에서 고른다. 둘 다 도서관을 구역으로 나누고(맨 아래 shared가 공용 구역), 기능 구역 안에 기능마다 책장을 하나씩 둔다. 규칙도 같다 — 위 구역의 책은 아래 구역의 책만 펴 보고, 같은 구역 책장끼리는 서로 안 펴 본다. 다른 것은 구역 수다. 도서관은 한 앱에 한 채뿐이라 하나만 고른다.
도서관 — FSD와 Bulletproof React 중 하나를 고른다
| FSD | Bulletproof React | |
|---|---|---|
| 구역 수 | 여섯 (app · pages · widgets · features · entities · shared) | 셋 (app · features · shared) |
| 규칙 | 아래 구역만 부를 수 있다 | 같다. 기능끼리는 서로 안 부르고 app에서 조립한다 |
| 검사 도구 | Steiger — 폴더 배치가 설계도대로인지 본다 | ESLint — import 한 줄씩 본다 |
| 우리 앱과의 거리 | 폴더를 다 옮겨야 한다 | 지금 구조(app → components → lib)와 거의 같다 |
값 길 — 넷 중 하나가 아니라 값마다 고른다
| MVC | MVVM | Flux | Redux | |
|---|---|---|---|---|
| 핵심 | Model이 View에 알린다 | View와 ViewModel을 양방향으로 묶는다 | 전표 → Dispatcher 하나 → Store 여럿 | 전표 → Store 하나 → reducer |
| React에서는 | 컴포넌트가 View와 Controller를 합쳐서 원래 모양이 안 나온다 | React는 한 방향으로만 흘러서 맞지 않는다 | Redux가 이어받아 직접은 거의 안 쓴다 | 지금도 쓴다 |
React 앱에서 실제로 남는 선택지는 셋이고, 값마다 따로 고르며 섞어 써도 된다. Redux FAQ도 컴포넌트 안 state를 같이 써도 괜찮다고 적는다.
| 선택지 | 언제 |
|---|---|
| React 기본 (컴포넌트 안 state) | 화면 하나 안에서만 쓰는 값 |
| 작은 공용 저장소 | 여러 컴포넌트가 같이 보는 값 몇 개. 우리 ReviewActions.js(useSyncExternalStore)가 이것이다 |
| Redux | 앱 전체가 같이 보는 값이 많을 때 |
우리 앱은 지금 어디에 있나
| 고르는 것 | 몇 개 고르나 | 우리 앱 지금 |
|---|---|---|
| 책 배치 | FSD · Bulletproof React 중 하나 | Bulletproof React 쪽에 가깝다 |
| 값 길 | 값마다 따로, 섞어 쓴다 | React 기본 + 작은 저장소 하나. Redux는 없다 |
아직 안 본 것 — 하나씩 정리해 간다
아래는 공부하면서 이름만 짚은 것이다. 원본을 열어 확인하지 않았다. 하나씩 글로 정리하면서 확인하고, 정리하면 위 표로 올린다.
| 축 | 이름 | 한 줄 | 앞에서 본 것과의 관계 |
|---|---|---|---|
| 값 길 | TanStack Query / SWR | 서버에서 받은 값만 따로 맡는다 | 위의 넷은 「서버에서 온 값」을 따로 나누지 않는다. 다음에 볼 것 |
| 값 길 | Elm Architecture | 상태 → 화면 → 메시지 → update → 새 상태 | Redux가 아이디어를 가져온 곳 |
| 값 길 | MVP | Presenter가 View에게 다 시킨다 | MVC 형제 |
| 값 길 | MVI | 사용자 의도 → 새 상태, 한 방향 | Redux와 같은 생각 |
| 값 길 | MobX | 값이 바뀌면 보는 화면이 알아서 바뀐다 | MVVM에 가깝다 |
| 값 길 | Zustand | 작은 저장소 하나, 규칙이 가볍다 | ReviewActions.js를 라이브러리로 만든 모양 |
| 값 길 | Jotai / Recoil | 값을 잘게 쪼개 하나하나를 저장소로 둔다 | Redux의 반대 방향 |
| 값 길 | XState | 상태 기계 — 정해진 상태와 그 사이의 이동만 허락한다 | 상태가 꼬이는 걸 막는 다른 방식 |
| 책 배치 · 도서관 | 종류별 폴더 | components/ · hooks/ · utils/ |
FSD · Bulletproof가 벗어나려던 출발점 |
| 책 배치 · 책장 | Atomic Design | 원자 → 분자 → 유기체, 화면 부품의 크기로 나눈다 | shared/ui 안을 나누는 법이라 같이 쓴다 |
| 책 배치 · 책장 | 클린 아키텍처 / 헥사고날 | 도메인을 가운데, 화면 · API를 바깥에 둔다 | 백엔드에서 온 생각. 프론트에서는 드물다 |
| 다른 축 | CSR · SSR · 정적 생성 | 화면을 어디서 그리나 | 우리는 정적 생성(static export) |
| 책 배치 · 단지 | 마이크로 프론트엔드 | 앱을 쪼개 따로 배포한다 | 우리는 이미 세 앱(client · admin · business) |
같이 읽는 글
[Javascript] Feature-Sliced Design: 프론트엔드에도 계층 구조가 있는가
백엔드, 그러니까 화면 뒤에서 데이터를 저장하고 업무 규칙을 처리하는 서버 쪽 프로그램에는 3계층 구조가 있다. Controller → Service → Repository 순서로만 부르고, 거꾸로는 부르지 않는다. 더 나아가면 헥사고날 아키텍처가 있다. 업무 규칙을 가운데 두고 ...
책 배치 · 구역 여섯, 아래 구역만 부른다
[Javascript] Bulletproof React: 층을 셋으로 줄이면 FSD에 비해 무엇을 얻고 무엇을 잃는가
FSD 글(화면 코드를 층으로 나누는 구조 FSD를 공부한 글)의 결론은 가설 하나였다. 「폴더는 지금 표준대로 두고, 『아래는 위를 못 부른다』는 방향 규칙만 가져온다.」 그리고 확인하지 못한 것 셋을 남겼는데, 그중 하나가 「무엇으로 막나」였다. 자바는 private이나 같은 ...
책 배치 · 구역 셋, 기능끼리는 app에서 조립한다
[Javascript] MVC: 프론트엔드에서 MVC는 어디로 갔는가
FSD 글에서 프론트엔드 구조 후보 넷을 놓고 FSD를 골랐다. FSD는 화면 코드를 층으로 나누고 「위층 파일만 아래층 파일을 불러 쓸 수 있다」는 방향 규칙을 거는 구조다. 그때 MVC는 「화면과 로직을 나누나에 답할 뿐, 누가 누구를 부르나에는 답이 없다」는 한 줄로 넘겼다....
값 길 · Model이 View에 알린다
[Javascript] MVVM: 화면과 값을 묶어 두면 무엇이 편해지고 무엇이 어려워지는가
MVC, Flux, Redux를 공부하고 나서 이런 질문이 남았다. 「MVVC인가? 그런 것도 있지 않아?」 이름을 정확히 기억하지 못했는데, 말하려던 건 MVVM(Model-View-ViewModel)이었다. 끝 글자가 C가 아니라 M이다.
값 길 · 화면과 값을 양방향으로 묶는다
[Javascript] Flux: 값을 바꾸는 문을 하나로 줄이면 무엇이 달라지는가
MVC 글은 Flux라는 이름을 꺼낸 데서 끝났다. 큰 MVC 앱에서는 값 하나를 바꾸면 그 값에 기대는 다른 값이 줄줄이 바뀌고, 결국 「누가 이걸 바꿨지?」를 찾을 수 없게 됐다. Facebook은 그 답으로 Flux를 내놓았다. 그 글에는 「Flux가 실제로 어떤 모양인지는 ...
값 길 · 값을 바꾸는 문을 Dispatcher 하나로 줄인다
[Javascript] Redux: Flux에서 무엇을 덜어 냈고, 왜 이전 상태를 고치지 않는가
Flux 글에서 「값을 바꾸고 싶으면 전표(Action)를 내고, 고치는 건 값을 가진 Store가 한다」를 공부했다. 그다음에 궁금했던 건 두 가지였다. Flux와 Redux는 같이 나온 건가, 다른 때 나온 건가. 그리고 Redux는 Flux와 무엇이 다른가.
값 길 · Store를 하나로, 이전 상태는 고치지 않는다