From d8d97c510a6c1bffcb5f97cefea85c1bf028ed73 Mon Sep 17 00:00:00 2001 From: hyorispace <97094709+hyoribogo@users.noreply.github.com> Date: Tue, 17 Jun 2025 13:22:25 +0900 Subject: [PATCH] =?UTF-8?q?docs:=2013,=2014=EC=9E=A5=20=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../README.md" | 106 ++++++++++++++++++ .../README.md" | 49 ++++++++ 2 files changed, 155 insertions(+) create mode 100644 "\352\271\200\355\232\250\353\246\254/13. \353\240\214\353\215\224\353\247\201 \355\214\250\355\204\264/README.md" create mode 100644 "\352\271\200\355\232\250\353\246\254/14. \353\246\254\354\225\241\355\212\270 \354\225\240\355\224\214\353\246\254\354\274\200\354\235\264\354\205\230 \352\265\254\354\241\260/README.md" diff --git "a/\352\271\200\355\232\250\353\246\254/13. \353\240\214\353\215\224\353\247\201 \355\214\250\355\204\264/README.md" "b/\352\271\200\355\232\250\353\246\254/13. \353\240\214\353\215\224\353\247\201 \355\214\250\355\204\264/README.md" new file mode 100644 index 0000000..12760e5 --- /dev/null +++ "b/\352\271\200\355\232\250\353\246\254/13. \353\240\214\353\215\224\353\247\201 \355\214\250\355\204\264/README.md" @@ -0,0 +1,106 @@ +- 콘텐츠를 어디에서 어떻게 렌더링 할 것인가? +- 웹 서버, 빌드 서버, 엣지 네트워크 또는 클라이언트, 어디에서 콘텐츠를 렌더링 할 것인가? +- 콘텐츠를 한 번에, 부분적으로, 또는 점진적으로 어떻게 렌더링 할 것인가? + +## 핵심 웹 지표 + +- TTFB: 클라이언트가 페이지 콘텐츠의 첫 번째 바이트를 받는 데 걸리는 시간 +- FCP: 페이지 이동 후 브라우저가 콘텐츠의 첫 부분을 렌더링하는 데 걸리는 시간 +- TTI: 페이지 로드 시작부터 사용자 입력에 빠르게 응답할 수 있을 때까지 걸리는 시간 +- LCP: 페이지의 주요 콘텐츠를 로드하고 렌더링하는 데 걸리는 시간 +- CLS: 예상치 못한 레이아웃 변경을 방지하기 위한 시각적 안정성 측정 +- FID: 사용자가 페이지와 상호작용한 시점부터 이벤트 핸들러가 실행될수 있는 시점까지의 시간 + +## 클라이언트 사이드 렌더링 + +전체 웹 애플리케이션이 처음 요청 시에 모두 로드된다. + +페이지 렌더링의 경우 클라이언트에서 뷰를 갈아끼운다. + +장점: 페이지 간 라우팅이 빨라 사용자 경험에 좋다. + +단점: 큰 자바스크립트 번들로 인해 FCP와 TTI를 증가시킨다. + +## 서버 사이드 렌더링 + +모든 요청마다 HTML을 생성한다. + +사용자 쿠키 정보나 요청 데이터를 기반으로 하는 개인 맞춤형 데이터를 포함하는 페이지에 적합하다. + +즉, 사용자에게 민감한 데이터를 서버에서 처리할 수 있다. + +SSR의 핵심 원칙은 HTML을 서버에서 렌더링하고 클라이언트에서 다시 하이드레이션하는 데 필요한 자바스크립트를 함께 제공하는 것이다. + +장점: FCP, CLS에 좋다. + +단점: 소스코드를 작성할 때 항상 서버를 고려해야 한다. + +### 서버 사이드 렌더링은 만능이 아니다 - 리액트 딥다이브 + +- 우선순위에 따라 SPA가 더 효율적일 수 있다. +- 가장 뛰어난 SPA는 가장 뛰어난 MPA보다 낫다. + - 예를 들어 Gmail 같은 경우가 있다. 이미지 최적화, 코드 스플리팅 등 최적화 기법을 사용했기 때문이다. +- 하지만 평균적인 SPA는 평균적인 MPA보다 느리다. + - 최적화 기법이 어렵다. + +## 정적 렌더링 + +전체 페이지의 HTML을 빌드 시점에 미리 생성하며, 다음 빌드 때까지 변경되지 않는다. + +정적인 HTML 콘텐츠는 CDN이나 엣지 네트워크에 쉽게 캐싱될 수 있다. + +ex) 회사 소개, 문의하기, 블로그 페이지 등 + +## 점진적 정적 생성 + +정적 렌더링과 SSR을 결합한 방식 + +동적 페이지는 사용자 요청 시에 on-demand 방식으로 렌더링 한다. 특정 시간 간격마다 캐시를 자동으로 무효화하고 페이지를 다시 생성할 수 있다. + +재검증이 백그라운드에서 진행되는 동안 사용자는 캐시된 버전을 보게 된다. 이때 애플리케이션 전체 재빌드가 필요하지 않는다. + +https://nextjs.org/docs/app/guides/incremental-static-regeneration + +## 스트리밍 SSR + +SSR이나 정적 렌더링을 사용하면 자바스크립트 용량을 줄여 페이지가 상호작용 가능해지는 시간인 TTI를 FCP에 더 가깝게 만들 수 있다. 여기에 스트리밍 방식으로 콘텐츠를 전송하면 TTI와 FCP를 더욱 단축할 수 있다. + +청크 (chunk) 단위로 순차적으로 클라이언트에 전송한다. HTML 청크가 도착하는 즉시 브라우저는 이를 렌더링한다. + +리액트의 `renderToNodeStream` 함수를 사용해 애플리케이션을 청크로 나누어 전송한다. 이렇게 수신된 DOM 노드에 `hydrate` 메서드를 호출하면 해당 이벤트 핸들러가 연결되어 UI에 상호작용할 수 있게 된다. + +## 엣지 SSR + +CDN의 모든 지역에서 서버 렌더링을 가능하게 하고, 콜드 부트 시간을 거의 0에 가깝게 줄여준다. + +활용 사례로는 사용자별 지역 특화 리스트 페이지가 있다. 필요한 부분만 엣지 렌더링을 하도록 선택할 수 있다 + +## 하이브리드 렌더링 + +여러 렌더링 방식을 결합한 방식. + +즉, Next.js처럼 CSR, SSR, SSG, ISR, Edge SSR 등을 필요에 따라 혼합 적용하는 경우를 말한다. + +| **값** | **의미** | **렌더링 전략** | +| --- | --- | --- | +| 'auto' *(기본값)* | Next.js가 자동으로 판단 | 데이터 fetch 방식에 따라 SSG/SSR 자동 결정 | +| 'force-dynamic' | 강제로 SSR로 처리 | 매 요청마다 서버에서 렌더링 | +| 'force-static' | 강제로 정적 처리 | 빌드 시 SSG, fetch 시 캐시 필수 | +| 'error' | 정적 생성이 불가능하면 오류 발생 | 예외 처리용 | + +## 점진적 하이드레이션 + +각 노드를 시간에 따라 하이드레이션하여 필요한 최소한의 자바스크립트만 요청하는 방식 + +상대적으로 덜 중요한 부분의 하이드레이션을 지연시킨다. 서버에서 렌더링된 DOM 트리가 파괴되고 즉시 다시 생성되는 문제를 방지할 수 있다. + +## 아일랜드 아키텍처 + +정적인 HTML 위에 독립적으로 전달될 수 있는 상호작용 아일랜드를 통해 자바스크립트의 전송량을 줄이는 패러다임을 의미 + +### 점진적 하이드레이션과의 차이 + +- 점진적 하이드레이션: 하향식 구조로 되어있다. 페이지가 개별 컴포넌트의 스케줄링 및 하이드레이션을 제어한다. +- 아일랜드 아키텍처: 각 컴포넌트가 자체적으로 하이드레이션 스트립트를 가지고 있으며, 이 스크립트는 페이지의 다른 스크립트와 독립적으로 비동기 실행된다. + +단점: 소셜 미디어 애플리케이션과 같이 상호작용을 위주로 한 페이지에 적합하지 않다. \ No newline at end of file diff --git "a/\352\271\200\355\232\250\353\246\254/14. \353\246\254\354\225\241\355\212\270 \354\225\240\355\224\214\353\246\254\354\274\200\354\235\264\354\205\230 \352\265\254\354\241\260/README.md" "b/\352\271\200\355\232\250\353\246\254/14. \353\246\254\354\225\241\355\212\270 \354\225\240\355\224\214\353\246\254\354\274\200\354\235\264\354\205\230 \352\265\254\354\241\260/README.md" new file mode 100644 index 0000000..94cdb57 --- /dev/null +++ "b/\352\271\200\355\232\250\353\246\254/14. \353\246\254\354\225\241\355\212\270 \354\225\240\355\224\214\353\246\254\354\274\200\354\235\264\354\205\230 \352\265\254\354\241\260/README.md" @@ -0,0 +1,49 @@ +### 모듈, 기능 또는 경로별 그룹화 + +``` +common/ + Avatar.ts +product/ + index.js + price.js +checkout/ + index.js +``` + +장점: 모듈에 변경사항이 있을 때 관련된 모든 파일이 같은 폴더에 모여 있어 변경사항이 특정 코드 영역으로 제한된다. + +단점: 공통 컴포넌트를 주기적으로 파악해야만 중복을 피할 수 있다. + +### 파일 유형별 그룹화 + +``` +css/ + global.css +lib/ + date.js +pages/ + product.js +``` + +장점: 여러 프로젝트에서 동일하게 사용할 수 있다. 공통 컴포넌트의 스타일을 변경하면 전체에 적용된다. + +단점: 특정 모듈의 로직을 변경하려면 여러 폴더에 있는 파일을 찾아가 수정해야 한다. + +### 도메인 및 공통 컴포넌트 기반의 혼합 그룹화 + +``` +components/ + User/ + profile.js +domain/ + product/ + product.js +``` + +파일 유형별 그룹화와 기능별 그룹화의 장점을 모두 활용 + +저도 취준 + 회사생활 하면서 계속 고민한 게 폴더 구조였어요.. 저 같은 경우에는 도메인 중심 구조를 선호하는 편이에요! 회사에서는 정석 구조인 레이어드 구조를 사용하고 있습니다. + +[테오 FSD](https://velog.io/@teo/fsd) (몇 달 전부터 FSD 아키텍처에 대한 글을 많이 봤지만, 전 볼 때마다 생소하고 적용하기 어려울 것 같더라구요 ㅠ 다른 분들은 사용해보신 적이 있으신가요 ?) + +다른 분들의 꿀팁들을 스터디 때 쓰윽 흡수해야겠습니다 😋 \ No newline at end of file