Next.js로 대규모 전자상거래 웹사이트 재구축(사례 연구)

게시 됨: 2022-03-10

빠른 요약 ↬ 우리는 Next.js를 사용하여 보다 전통적인 통합 전자 상거래 플랫폼에서 헤드리스 플랫폼으로 전환했습니다. 다음은 Next.js로 대규모 전자상거래 사이트를 재구축하면서 배운 가장 중요한 교훈입니다.

우리 회사인 Unplatform에서는 수십 년 동안 전자 상거래 사이트를 구축해 왔습니다. 그 동안 우리는 기술 스택이 일부 사소한 JavaScript 및 CSS가 포함된 서버 렌더링 페이지에서 완전한 JavaScript 응용 프로그램으로 발전하는 것을 보았습니다.

전자 상거래 사이트에 사용한 플랫폼은 ASP.NET을 기반으로 했으며 방문자가 더 많은 상호 작용을 기대하기 시작했을 때 프런트 엔드에 React를 추가했습니다. ASP.NET과 같은 서버 웹 프레임워크의 개념을 React와 같은 클라이언트 측 웹 프레임워크와 혼합하면 상황이 더 복잡해졌지만 우리는 이 솔루션에 매우 만족했습니다. 트래픽이 가장 많은 고객과 함께 생산에 들어갈 때까지였습니다. 라이브를 시작한 순간부터 성능 문제가 발생 했습니다. 핵심 성능 평가는 전자 상거래에서 더욱 중요합니다. 이 Deloitte 연구: Milliseconds Make Millions에서 연구자들은 37개 브랜드의 모바일 사이트 데이터를 분석했습니다. 그 결과 0.1초 성능 향상이 전환율 10% 증가로 이어질 수 있음을 발견했습니다.

성능 문제를 완화하기 위해 많은 (예산 없는) 서버를 추가해야 했고 역방향 프록시에서 페이지를 적극적으로 캐시해야 했습니다. 이 때문에 사이트 기능의 일부를 비활성화해야 했습니다. 우리는 어떤 경우에는 일부 페이지를 정적으로 제공하는 정말 복잡하고 값비싼 솔루션을 갖게 되었습니다.

분명히 이것은 우리가 Next.js에 대해 알게 될 때까지 옳지 않다고 느꼈습니다 . Next.js는 정적으로 페이지를 생성할 수 있는 React 기반 웹 프레임워크이지만 여전히 서버 측 렌더링을 사용할 수 있어 전자 상거래에 이상적입니다. Vercel 또는 Netlify와 같은 CDN에서 호스팅할 수 있으므로 지연 시간 이 줄어듭니다. Vercel과 Netlify는 또한 Server Side Rendering을 위해 서버리스 기능을 사용하는데, 이는 가장 효율적인 스케일 아웃 방법입니다.

도전

Next.js로 개발하는 것은 놀라운 일이지만 분명히 몇 가지 문제가 있습니다. Next.js에 대한 개발자 경험은 경험하기만 하면 되는 것입니다. 작성한 코드 는 브라우저에서 즉시 시각화 되며 생산성은 하늘을 찌를 것입니다. 이것은 또한 생산성에 너무 집중하고 코드의 유지 관리 가능성을 무시할 수 있기 때문에 위험합니다. 시간이 지남에 따라 JavaScript의 유형이 지정되지 않은 특성으로 인해 코드베이스가 저하될 수 있습니다. 버그가 늘어나고 생산성이 떨어지기 시작합니다.

또한 런타임 측면 에서도 어려울 수 있습니다. 코드의 가장 작은 변경으로 인해 성능 및 기타 핵심 성능 저하가 발생할 수 있습니다. 또한 서버 측 렌더링을 부주의하게 사용하면 예상치 못한 서비스 비용이 발생할 수 있습니다.

이러한 도전을 극복하는 과정에서 배운 교훈을 더 자세히 살펴보겠습니다.

코드베이스 모듈화
코드 린트 및 형식 지정
TypeScript 사용
성능 계획 및 성능 측정
품질 게이트에 성능 검사 추가
자동화된 테스트 추가
의존성을 적극적으로 관리
로그 집계 서비스 사용
Next.js의 재작성 기능으로 점진적 채택 가능

점프 후 더! 아래에서 계속 읽기 ↓

교훈: 코드베이스 모듈화

Next.js와 같은 프론트엔드 프레임워크는 요즘 시작하기가 매우 쉽습니다. npx create-next-app를 실행하기만 하면 코딩을 시작할 수 있습니다. 그러나 조심하지 않고 디자인에 대해 생각하지 않고 코드를 두드리기 시작하면 큰 진흙 덩어리로 끝날 수 있습니다.

npx create-next-app 을 실행하면 다음과 같은 폴더 구조를 갖게 됩니다(대부분의 예제가 구성되는 방식이기도 합니다).

 /public logo.gif /src /lib /hooks useForm.js /api content.js /components Header.js Layout.js /pages Index.js

우리는 같은 구조를 사용하기 시작했습니다. 더 큰 구성 요소를 위해 구성 요소 폴더에 일부 하위 폴더가 있었지만 대부분의 구성 요소는 루트 구성 요소 폴더에 있었습니다. 이 접근 방식에는 아무런 문제가 없으며 소규모 프로젝트에 적합합니다. 그러나 프로젝트가 성장함에 따라 구성 요소와 사용 위치에 대해 추론하기가 더 어려워졌습니다. 더 이상 사용되지 않는 구성 요소도 발견했습니다! 또한 어떤 코드가 다른 코드에 종속되어야 하는지에 대한 명확한 지침이 없기 때문에 큰 진흙 덩어리를 조장합니다.

이 문제를 해결하기 위해 코드베이스를 리팩토링하고 기술 개념 대신 기능 모듈(NPM 모듈과 같은 종류)별로 코드를 그룹화 하기로 결정했습니다.

 /src /modules /catalog /components productblock.js /checkout /api cartservice.js /components cart.js

이 작은 예에는 체크아웃 모듈과 카탈로그 모듈이 있습니다. 이러한 방식으로 코드를 그룹화하면 검색 가능성이 높아집니다. 폴더 구조만 보면 코드베이스에 어떤 종류의 기능이 있고 어디서 찾을 수 있는지 정확히 알 수 있습니다. 또한 종속성에 대해 추론하기가 훨씬 쉽습니다 . 이전 상황에서는 구성 요소 간에 많은 종속성이 있었습니다. 카탈로그 구성 요소에도 영향을 주는 체크아웃의 변경 사항에 대한 풀 요청이 있었습니다. 이로 인해 병합 충돌 수가 증가하고 변경하기가 더 어려워졌습니다.

우리에게 가장 효과적인 솔루션은 모듈 간의 종속성을 절대 최소로 유지하고(종속성이 정말로 필요한 경우 단방향성인지 확인) 모든 것을 함께 묶는 "프로젝트" 수준을 도입하는 것입니다.

 /src /modules /common /atoms /lib /catalog /components productblock.js /checkout /api cartservice.js /components cart.js /search /project /layout /components /templates productdetail.js cart.js /pages cart.js

이 솔루션의 시각적 개요:

모듈화된 프로젝트 예시의 개요 — 모듈화된 프로젝트 예제의 개요(큰 미리보기)

프로젝트 수준에는 전자 상거래 사이트 및 페이지 템플릿의 레이아웃에 대한 코드가 포함되어 있습니다. Next.js에서 페이지 구성 요소는 규칙이며 물리적 페이지가 됩니다. 경험상 이러한 페이지는 종종 동일한 구현을 재사용해야 하며 이것이 "페이지 템플릿" 개념을 도입한 이유입니다. 페이지 템플릿은 다른 모듈의 구성 요소를 사용합니다. 예를 들어 제품 세부 정보 페이지 템플릿은 카탈로그의 구성 요소를 사용하여 제품 정보를 표시하지만 체크아웃 모듈의 장바구니에 추가 구성 요소도 사용합니다.

기능 모듈에서 재사용해야 하는 코드가 아직 남아 있기 때문에 공통 모듈도 있습니다. 일관된 모양과 느낌을 제공하는 데 사용되는 React 구성 요소인 간단한 원자가 포함되어 있습니다. 또한 특정 일반 반응 후크 또는 GraphQL 클라이언트 코드를 생각하면 인프라 코드가 포함되어 있습니다.

경고 : 공통 모듈의 코드가 안정적인지 확인하고 얽힌 코드를 방지하기 위해 여기에 코드를 추가하기 전에 항상 두 번 생각하십시오.

마이크로 프런트 엔드

더 큰 솔루션에서 또는 다른 팀과 함께 작업할 때 애플리케이션을 소위 마이크로 프론트엔드로 훨씬 더 분할하는 것이 합리적일 수 있습니다. 간단히 말해서, 이는 애플리케이션을 서로 다른 URL에서 독립적으로 호스팅되는 여러 물리적 애플리케이션으로 훨씬 더 분할하는 것을 의미합니다. 예: checkout.mydomain.com 및 catalog.mydomain.com. 그런 다음 프록시 역할을 하는 다른 애플리케이션에 의해 통합됩니다.

Next.js의 재작성 기능은 이를 위해 훌륭하며 이와 같이 사용하는 것은 소위 다중 영역에서 지원됩니다.

다중 영역의 이점은 모든 영역이 자체 종속성을 관리한다는 것입니다. 또한 코드베이스를 점진적으로 발전시키기가 더 쉽습니다. Next.js 또는 React의 새 버전이 출시되면 전체 코드베이스를 한 번에 업그레이드하지 않고 영역을 하나씩 업그레이드할 수 있습니다. 다중 팀 조직에서 이는 팀 간의 종속성을 크게 줄일 수 있습니다.

추가 읽기

"Next.js 프로젝트 구조", Yannick Wittwer, Medium
"유연하고 효율적인 방법으로 Next.js 프로젝트를 구성하는 방법에 대한 2021년 가이드" Vadorequest, Dev.to.
"마이크로 프론트엔드", 마이클 기어스

학습한 내용: 코드 린트 및 형식 지정

이것은 우리가 이전 프로젝트에서 배운 것입니다. 여러 사람과 동일한 코드베이스에서 작업하고 포맷터를 사용하지 않으면 코드가 곧 매우 일관성이 없게 됩니다. 코딩 규칙을 사용하고 검토를 하고 있더라도 곧 다른 코딩 스타일을 알아차리기 시작하여 코드에 지저분한 인상을 줍니다.

린터는 코드에 잠재적인 문제가 있는지 확인하고 포맷터는 코드가 일관된 방식으로 포맷되었는지 확인합니다. 우리는 ESLint & prettier를 사용하고 그들이 굉장하다고 생각합니다. 코딩 스타일에 대해 생각할 필요가 없으므로 개발 중 인지 부하가 줄어듭니다.

다행스럽게도 Next.js 11은 이제 기본적으로 ESLint를 지원하므로(https://nextjs.org/blog/next-11) npx next lint를 실행하여 매우 쉽게 설정할 수 있습니다. 이것은 Next.js에 대한 기본 구성과 함께 제공되기 때문에 많은 시간을 절약합니다. 예를 들어 React용 ESLint 확장으로 이미 구성되어 있습니다. 더 나아가, 애플리케이션의 핵심 성능에 잠재적으로 영향을 미칠 수 있는 코드 문제를 찾아내는 새로운 Next.js 전용 확장이 함께 제공됩니다! 이후 단락에서는 실수로 Core Web Vitals를 손상시키는 제품에 코드를 푸시하는 것을 방지하는 데 도움이 될 수 있는 품질 게이트에 대해 설명합니다. 이 확장 프로그램은 피드백을 훨씬 빠르게 제공하여 훌륭한 추가 기능을 제공합니다.

추가 읽기

"ESLint", Next.js 문서
“ESLint”, 공식 웹사이트

학습한 내용: TypeScript 사용

구성 요소가 수정되고 리팩터링됨에 따라 일부 구성 요소 소품이 더 이상 사용되지 않는 것으로 나타났습니다. 또한 어떤 경우에는 구성 요소에 전달되는 props 유형이 누락되거나 잘못되어 버그가 발생했습니다.

TypeScript는 JavaScript의 상위 집합이며 유형을 추가하여 컴파일러가 스테로이드의 린터처럼 코드를 정적으로 확인할 수 있도록 합니다.

프로젝트 초기에는 TypeScript 추가의 가치를 제대로 보지 못했습니다. 우리는 그것이 단지 불필요한 추상화라고 느꼈습니다. 그러나 동료 중 한 명이 TypeScript에 대한 좋은 경험을 갖고 있어 시도해 보라고 설득했습니다. 다행히 Next.js는 뛰어난 TypeScript 지원을 기본적으로 제공하며 TypeScript를 사용하면 이를 솔루션에 점진적으로 추가할 수 있습니다. 즉, 전체 코드베이스를 한 번에 다시 작성하거나 변환할 필요가 없지만 즉시 사용을 시작하고 나머지 코드베이스를 천천히 변환할 수 있습니다.

구성 요소를 TypeScript로 마이그레이션하기 시작하면 구성 요소와 함수에 잘못된 값이 전달되는 문제를 즉시 발견했습니다. 또한 개발자 피드백 루프가 짧아지고 브라우저에서 앱을 실행하기 전에 문제에 대한 알림을 받습니다. 우리가 찾은 또 다른 큰 이점은 코드를 리팩토링하기가 훨씬 더 쉽다는 것입니다. 간단히 말해서 TypeScript의 이점은 다음과 같습니다.

버그의 수를 줄입니다
코드를 더 쉽게 리팩토링할 수 있습니다.
코드가 더 읽기 쉬워집니다.

추가 읽기

"TypeScript", Next.js 문서
TypeScript, 공식 웹사이트

교훈: 성과 계획 및 성과 측정

Next.js는 다양한 유형의 사전 렌더링(정적 생성 및 서버 측 렌더링)을 지원합니다. 최상의 성능을 위해 빌드 시간 동안 발생하는 정적 생성을 사용하는 것이 좋지만 항상 가능한 것은 아닙니다. 재고 정보가 포함된 제품 상세 페이지를 생각해 보십시오. 이러한 종류의 정보는 자주 변경되며 매번 빌드를 실행하는 것은 확장성이 좋지 않습니다. 다행히 Next.js는 ISR(증분 정적 재생)이라는 모드도 지원합니다. 이 모드는 여전히 페이지를 정적으로 생성하지만 x초마다 백그라운드에서 새 페이지를 생성합니다. 우리는 이 모델이 더 큰 응용 프로그램에 적합하다는 것을 배웠습니다. 성능은 여전히 우수하며 서버 측 렌더링보다 적은 CPU 시간이 필요하며 빌드 시간이 단축됩니다. 페이지는 첫 번째 요청에서만 생성됩니다. 추가하는 모든 페이지에 대해 필요한 렌더링 유형을 생각해야 합니다. 먼저 정적 생성을 사용할 수 있는지 확인하십시오. 그렇지 않은 경우 증분 정적 재생으로 이동하고 그것도 가능하지 않은 경우 서버 측 렌더링을 계속 사용할 수 있습니다.

Next.js는 페이지에 getServerSideProps 및 getInitialProps 메서드가 없는 경우 렌더링 유형을 자동으로 결정합니다. 페이지가 정적으로 생성되는 대신 서버에서 렌더링될 수 있는 실수를 하기 쉽습니다. Next.js 빌드의 출력은 정확히 어떤 페이지가 어떤 유형의 렌더링을 사용하는지 보여주므로 이를 확인하십시오. 또한 생산을 모니터링하고 페이지의 성능과 관련된 CPU 시간을 추적하는 데 도움이 됩니다. 대부분의 호스팅 제공업체는 CPU 시간을 기준으로 요금을 청구하며 이는 불쾌한 놀라움을 방지하는 데 도움이 됩니다. 학습: 로그 집계 서비스 사용 단락에서 이를 모니터링하는 방법을 설명합니다.

번들 크기

좋은 성능을 얻으려면 번들 크기를 최소화하는 것이 중요합니다. Next.js에는 자동 코드 분할과 같이 즉시 사용할 수 있는 많은 기능이 있습니다. 이렇게 하면 모든 페이지에 필요한 JavaScript 및 CSS만 로드됩니다. 또한 클라이언트와 서버에 대해 서로 다른 번들을 생성합니다. 그러나 이것들을 주시하는 것이 중요합니다. 예를 들어 JavaScript 모듈을 잘못된 방식으로 가져오면 서버 JavaScript가 클라이언트 번들에서 끝날 수 있으므로 클라이언트 번들 크기가 크게 증가하고 성능이 저하될 수 있습니다. NPM 종속성을 추가하면 번들 크기에 큰 영향을 줄 수도 있습니다.

다행스럽게도 Next.js에는 번들의 어떤 부분을 차지하는 코드에 대한 통찰력을 제공하는 번들 분석기가 함께 제공됩니다.

webpack 번들 분석기는 번들에 있는 패키지의 크기를 보여줍니다. — webpack 번들 분석기는 번들에 있는 패키지의 크기를 보여줍니다(큰 미리보기).

추가 읽기

"Next.js + Webpack 번들 분석기", Vercel, GitHub
"데이터 가져오기", Next.js 문서

교훈: 품질 게이트에 성능 검사 추가

Next.js를 사용할 때의 큰 이점 중 하나는 페이지를 정적으로 생성하고 애플리케이션을 에지(CDN)에 배포할 수 있다는 것입니다. 따라서 뛰어난 성능과 Web Vitals를 얻을 수 있습니다. 우리는 Next.js와 같은 훌륭한 기술을 사용하더라도 훌륭한 등대 점수를 얻고 유지하는 것이 정말 어렵다는 것을 배웠습니다. 프로덕션에 일부 변경 사항을 배포한 후 등대 점수가 크게 떨어지는 경우가 여러 번 있었습니다. 통제권을 되찾기 위해 품질 게이트에 자동 등대 테스트를 추가했습니다. 이 Github 작업을 사용하면 자동으로 등대 테스트를 끌어오기 요청에 추가할 수 있습니다. 우리는 Vercel을 사용하고 있으며 풀 요청이 생성될 때마다 Vercel은 이를 미리보기 URL에 배포하고 Github 작업을 사용하여 이 배포에 대해 등대 테스트를 실행합니다.

Github Pull Request에 대한 등대 결과의 예(큰 미리보기)

GitHub 작업을 직접 설정하고 싶지 않거나 더 나아가고 싶다면 DebugBear와 같은 타사 성능 모니터링 서비스를 고려할 수도 있습니다. Vercel은 또한 프로덕션 배포의 핵심 Web Vitals를 측정하는 분석 기능을 제공합니다. Vercel Analytics는 실제로 방문자의 기기에서 측정값을 수집하므로 이 점수는 방문자가 실제로 경험하는 것입니다. 작성 당시 Vercel Analytics는 프로덕션 배포에서만 작동합니다.

학습한 내용: 자동화된 테스트 추가

코드베이스가 커지면 코드 변경으로 인해 기존 기능이 손상되었는지 확인하기가 더 어려워집니다. 우리의 경험에 따르면 안전망으로 종단 간 테스트의 좋은 세트를 갖는 것이 중요합니다. 작은 프로젝트가 있더라도 최소한 몇 가지 기본적인 연기 테스트가 있으면 삶이 훨씬 쉬워질 수 있습니다. 우리는 이것을 위해 Cypress를 사용해 왔으며 절대적으로 그것을 좋아합니다. Netlify 또는 Vercel을 사용하여 임시 환경에 자동으로 끌어오기 요청을 배포하고 E2E 테스트를 실행하는 조합은 매우 중요합니다.

cypress-io/GitHub-action 을 사용하여 pull 요청에 대해 cypress 테스트를 자동으로 실행합니다. 구축하는 소프트웨어 유형에 따라 Enzyme 또는 JEST를 사용하여 보다 세분화된 테스트를 수행하는 것이 중요할 수 있습니다. 절충점은 이러한 코드가 코드와 더 밀접하게 결합되어 더 많은 유지 관리가 필요하다는 것입니다.

Github Pull Request에 대한 자동화된 검사의 예(큰 미리보기)

교훈: 의존성을 적극적으로 관리하라

종속성을 관리하는 것은 시간이 많이 걸리지만 대규모 Next.js 코드베이스를 유지 관리할 때 매우 중요한 활동입니다. NPM은 패키지 추가를 너무 쉽게 만들었고 요즘에는 모든 것을 위한 패키지가 있는 것 같습니다. 돌이켜보면 많은 경우 새로운 버그를 도입하거나 성능이 저하된 경우 새롭거나 업데이트된 NPM 패키지와 관련이 있었습니다.

따라서 패키지를 설치하기 전에 항상 다음과 같이 자문해야 합니다.

패키지의 품질은 무엇입니까?
이 패키지를 추가하면 번들 크기에 어떤 의미가 있습니까?
이 패키지가 정말 필요합니까 아니면 대안이 있습니까?
패키지는 여전히 활발히 유지되고 있습니까?

번들 크기를 작게 유지하고 이러한 종속성을 유지하는 데 필요한 노력을 최소화하려면 종속성 수를 가능한 한 작게 유지하는 것이 중요합니다. 당신의 미래의 자아는 당신이 소프트웨어를 유지 관리할 때 그것에 대해 감사할 것입니다.

팁 : Import Cost VSCode 확장은 가져온 패키지의 크기를 자동으로 표시합니다.

Next.js 버전 유지

Next.js 및 React를 따라가는 것이 중요합니다. 새로운 기능에 액세스할 수 있을 뿐만 아니라 새 버전에는 버그 수정 및 잠재적 보안 문제에 대한 수정도 포함됩니다. 다행히 Next.js는 Codemods(https://nextjs.org/docs/advanced-features/codemods)를 제공하여 업그레이드를 엄청나게 쉽게 만듭니다. 이는 코드를 자동으로 업데이트하는 자동 코드 변환입니다.

종속성 업데이트

같은 이유로 Next.js와 React 버전을 실제 상태로 유지하는 것이 중요합니다. 다른 종속성을 업데이트하는 것도 중요합니다. 여기에서 Github의dependabot(https://github.com/dependabot)이 정말 도움이 될 수 있습니다. 업데이트된 종속성이 있는 풀 요청을 자동으로 생성합니다. 그러나 종속성을 업데이트하면 잠재적으로 문제가 발생할 수 있으므로 여기에서 자동화된 종단 간 테스트를 사용하면 실제로 생명의 은인이 될 수 있습니다.

학습한 내용: 로그 집계 서비스 사용

앱이 제대로 작동하는지 확인하고 문제를 선제적으로 찾기 위해서는 로그 집계 서비스를 구성하는 것이 절대적으로 필요하다는 것을 알게 되었습니다. Vercel을 사용하면 로그인하여 로그를 볼 수 있지만 실시간으로 스트리밍되며 지속되지 않습니다. 또한 경고 및 알림 구성을 지원하지 않습니다.

일부 예외는 표시되는 데 오랜 시간이 걸릴 수 있습니다. 예를 들어 특정 페이지에 대해 Stale-While-Revalidate를 구성했습니다. 어느 시점에서 우리는 페이지가 새로 고쳐지지 않고 오래된 데이터가 제공되고 있음을 발견했습니다. Vercel 로깅을 확인한 후 페이지의 백그라운드 렌더링 중에 예외가 발생했음을 발견했습니다. 로그 집계 서비스를 사용하고 예외에 대한 경고를 구성했더라면 훨씬 더 빨리 이를 발견할 수 있었을 것입니다.

로그 집계 서비스는 Vercel의 요금제 한도를 모니터링하는 데에도 유용할 수 있습니다. Vercel의 사용 페이지에서도 이에 대한 통찰력을 얻을 수 있지만 로그 집계 서비스를 사용하면 특정 임계값에 도달했을 때 알림을 추가할 수 있습니다. 특히 청구에 관해서는 예방이 치료보다 낫습니다.

Vercel은 Datadog, Logtail, Logalert, Sentry 등을 특징으로 하는 로그 집계 서비스와 즉시 사용 가능한 여러 통합을 제공합니다.

추가 읽기

"통합", Vercel

교훈: Next.js의 재작성 기능으로 점진적 채택 가능

현재 웹사이트에 심각한 문제가 없는 한 전체 웹사이트를 다시 작성하는 데 열광하는 고객은 많지 않을 것입니다. 그러나 Web Vital과 관련하여 가장 중요한 페이지만 다시 작성하는 것으로 시작할 수 있다면 어떨까요? 그것이 바로 우리가 다른 고객에게 한 일입니다. 전체 사이트를 재구축하는 대신 SEO 및 전환에 가장 중요한 페이지만 재구축합니다. 이 경우 제품 세부 정보 및 카테고리 페이지. Next.js로 다시 빌드함으로써 성능이 크게 향상되었습니다.

Next.js 재작성 기능은 이에 적합합니다. 카탈로그 페이지가 포함된 새로운 Next.js 프런트 엔드를 구축하고 이를 CDN에 배포했습니다. 다른 모든 기존 페이지는 Next.js가 기존 웹사이트에 다시 작성합니다. 이런 식으로 노력이나 위험이 적은 방식으로 Next.js 사이트의 이점을 누릴 수 있습니다.

추가 읽기

"다시 작성", Next.js 문서

무엇 향후 계획?

우리가 프로젝트의 첫 번째 버전을 출시하고 심각한 성능 테스트를 시작했을 때 우리는 그 결과에 감격했습니다. 페이지 응답 시간과 Web Vitals가 이전보다 훨씬 개선되었을 뿐만 아니라 운영 비용도 이전에 비해 매우 낮았습니다. Next.js 및 JAMStack을 사용하면 일반적으로 가장 비용 효율적인 방식으로 확장할 수 있습니다.

보다 백엔드 지향적인 아키텍처에서 Next.js와 같은 것으로 전환하는 것은 큰 단계입니다. 학습 곡선은 상당히 가파를 수 있으며, 처음에는 일부 팀 구성원이 실제로 자신의 안전 지대를 벗어났다고 느꼈습니다. 우리가 만든 작은 조정, 이 기사에서 배운 교훈이 실제로 도움이 되었습니다. 또한 Next.js를 사용한 개발 경험은 놀라운 생산성 향상을 제공합니다. 개발자 피드백 주기는 엄청나게 짧습니다!

추가 읽기

"프로덕션으로 이동", Next.js 문서