안녕하세요, 델바입니다. 최근에 Next.js에서 렌더링과 캐싱의 새로운 기반이 될 캐시 컴포넌트를 소개했습니다. 이번 시리즈에서는 실용적인 예시를 통해 모델을 배우게 될 거예요.00:01

우리가 논의할 패턴과 모범 사례는 Cloud Code, Cursor, OpenCode와 같은 도구에서 코딩 에이전트 기술로 설치하여 사용할 수 있다는 점을 알아두시면 좋습니다.00:13

해당 기능은 Next.js 프로젝트에서 캐시 컴포넌트 플래그가 활성화될 때 자동으로 작동합니다.00:24

이건 이 비디오를 보지 않아도 생산적인 활동을 할 수 있다는 뜻이에요. 하지만 캐시의 작동 원리, 왜 필요한지, 그리고 일반적인 사용 사례들을 이해하고 싶다면 계속 보시면 될 거예요.00:31

퍼블릭 페이지부터 시작할게요. 퍼블릭 페이지는 모든 사용자에게 동일한 콘텐츠를 보여줍니다. 대표적인 예로는 랜딩 페이지, 마케팅 페이지, 그리고 제품 페이지가 있습니다.00:42

데이터가 공유되기 때문에 이런 페이지들은 미리 렌더링해 놓은 것을 재사용할 수 있습니다. 덕분에 페이지 로딩 속도가 빨라지고 서버 비용도 절감됩니다.00:54

예시로, 상품 목록 페이지를 만들어 보겠습니다. 먼저 정적 헤더를 만들고, 외부 데이터를 비동기적으로 가져와 상품 목록을 추가하며, 응답을 차단하지 않고 렌더링하는 방법을 알아보겠습니다.01:04

마침내, 전체 페이지를 요청 시간 렌더링으로 전환하지 않고 사용자별 프로모션을 추가할 것입니다. 소스 코드는 아래 설명에서 확인하실 수 있습니다. 그럼 간단한 헤더부터 시작해 봅시다.01:17

이것01:29

해당 컴포넌트는 요청 간에 변하는 외부 데이터, 요청 헤더, 라우트 파라미터, 현재 시간 또는 임의의 값과 같은 입력에 의존하지 않아야 합니다.01:32

결과는 항상 동일하고 미리 결정할 수 있습니다. 이런 종류의 컴포넌트를 정적 컴포넌트라고 부릅니다.01:49

요청을 기다릴 필요가 없기 때문에, Next.js는 빌드 시점에 페이지를 안전하게 미리 렌더링할 수 있습니다. Next Build를 실행해서 확인할 수 있습니다.01:58

제품 라우트가 명시적인 설정 없이도 정적 라우트로 매핑된다는 점을 알아두세요.02:12

자, 이제 제품 목록을 가져와서 렌더링해 보겠습니다. 헤더와 달리 제품 목록은 외부 데이터에 의존합니다.02:19

이 데이터는 시간이 지남에 따라 변동될 수 있으므로, 생성된 결과물이 더 이상 안정성을 보장하지 않습니다.02:30

이렇게 하면 동적인 컴포넌트가 됩니다. 지침이 없다면, 프레임워크는 모든 사용자 요청 시 새 데이터를 가져오고 싶다고 가정해야 합니다.02:37

하지만 이 컴포넌트가 요청 시 렌더링된다면, 데이터를 가져오는 과정 때문에 전체 라우트 응답이 지연될 수 있습니다.02:46

페이지를 새로 고침하면 이런 현상이 발생합니다. 헤더는 즉시 렌더링되지만, prodicus가 데이터를 가져오는 작업이 완료되기 전까지는 브라우저로 전송할 수 없습니다.02:53

이러한 성능 저하를 방지하기 위해, Next.js는 데이터를 기다리는 첫 번째 시도 시 경고를 보여줄 것입니다. 데이터 로딩이 suspense 없이 발생했으므로, 이제 어떻게 하면 응답을 차단 해제할지 결정해야 합니다.03:03

컴포넌트를 캐싱해서 안정화시키거나, 아니면 페이지 나머지 부분과 함께 미리 렌더링하거나, 스트리밍 방식으로 구현해서 비동기적으로 처리하고 페이지 나머지 부분이 기다리지 않도록 할 수 있습니다.03:17

저희 경우에는 제품 카탈로그가 모든 사용자에게 공유되므로, 캐싱이 적절한 선택입니다.03:29

useCache 지시문을 사용해서 함수를 캐시 가능하도록 표시할 수 있습니다. 그러면 캐시 컴포넌트가 되고요. 처음 실행될 때는 반환하는 값이 캐시되고 재사용됩니다.03:35

캐시 컴포넌트의 입력값이 요청이 도착하기 전에 준비되었다면, 정적 컴포넌트와 똑같이 미리 렌더링할 수 있습니다. 다시 새로고침하면 캐시 컴포넌트가 응답을 차단하지 않기 때문에 페이지가 즉시 로드되는 것을 확인할 수 있습니다.03:48

하지만 페이지는 영원히 고정되지는 않죠. 언젠가는 심플한 페이지조차도 동적인 콘텐츠가 필요하게 됩니다. 예를 들어보자, 홍보 배너를 추가해볼게요.04:03

다시 한번 말씀드리지만, 처음부터 동적으로 시작합니다. 이전과 마찬가지로, 차단 동작을 발생시키면 Next.js 경고가 발생합니다. 지난번에는 데이터를 공유하여 캐시할 수 있었습니다.04:15

이번 프로모션은 사용자 위치나 A-B 테스트와 같이 요청에 따라 달라지는 입력값에 따라 결정되기 때문에, 캐싱으로 문제를 해결할 수 없어요.04:29

사전 렌더링이 불가능할 경우, 응답을 차단 해제하는 방법은 스트리밍입니다.04:40

컴포넌트를 suspense 바운더리로 감싸고 폴백을 제공하면 스트리밍을 활성화할 수 있습니다. 폴백 컴포넌트는 즉시 렌더링되어 페이지의 나머지 부분을 차단하지 않습니다.04:45

이메일 컴포넌트는 동기 작업이 완료되면 렌더링됩니다.04:57

이 변경 사항을 통해 Next.js는 미리 렌더링할 수 있는 작업과 요청 시 작업을 분리할 수 있으며, 라우트는 부분적으로 미리 렌더링됩니다.05:02

다시 한번 NextBeaut를 실행해서 확인할 수 있습니다.05:12

페이지 빌드 시간 동안 헤더, 제품 목록, 프로모션 대체 콘텐츠를 포함한 대부분의 부분이 렌더링되고 캐시되어 콘텐츠 전송 네트워크로 푸시됩니다.05:22

요청 시점에는 미리 렌더링된 부분을 사용자에게 가까운 CDN 노드에서 즉시 제공합니다.05:31

동시에, 사용자 맞춤형 프로모션은 서버에서 렌더링되어 클라이언트로 스트리밍되고, 대체 슬롯으로 교체됩니다.05:39

한 번만 더 페이지를 새로고침하면, 대부분의 페이지는 즉시 로드되고, 동적인 부분들은 사용 가능해지는 대로 스트리밍 방식으로 나타나는 것을 확인할 수 있습니다.05:47

자, 오늘은 여기까지입니다. 주로 정적인 페이지를 만들고, 그 안에 동적인 콘텐츠를 조금씩 추가하는 방법을 배웠어요.05:58

정적인 페이지에서 시작해서, 동기화 작업을 추가했고, 미리 렌더링할 수 있는 내용을 캐싱하여 차단되는 문제를 해결했습니다.06:05

그리고 저희는 불가능했던 부분들을 스트리밍으로 보여드렸습니다. 앞으로의 영상에서는 이 내용을 바탕으로 미리 렌더링된 페이지나 캐시된 데이터를 어떻게 다시 검증할지, 동일한 페이지의 다양한 버전을 라우팅하여 제작하고, 개인화된 사용자 데이터를 활용한 개인 페이지를 어떻게 만들지 다룰 예정입니다.06:13

시청해주셔서 감사합니다.06:32