Next.js의 최신 버전, Next.js 14의 출시는 프론트엔드 개발의 세계에 새로운 변화의 바람을 불러일으키고 있습니다. 이 업데이트는 개발 속도와 사용자 경험을 극적으로 개선하는 몇 가지 중요한 기능을 제공합니다. 이 글에서는 Next.js 14의 핵심 기능과 그것들이 웹 앱 개발에 어떤 영향을 미칠지에 대해 이야기 해보겠습니다. Next.js 14의 혁신: 빠르고 효율적인 개발 경험 Next.js는 웹 앱 개발을 위한 최고의 프레임워크 중 하나로 자리 잡았으며, Next.js 14는 이러한 위치를 더욱 공고히 합니다. 이 버전에서는 특히 세 가지 주요 기능이 눈에 띕니다. 1. Turbopack: 속도와 효율성의 새로운 기준 Turbopack은 로컬 서버 시작 시간을 최대 53%까지 단축하고, 코드 업데이트 시간을 94%나 줄여줍니다. 이것은 대규모 애플리케이션에 대한 실제 벤치마크 결과로, Next.js의 성능 향상을 명확히 보여줍니다. 2. Server Actions: 간결하고 효율적인 백엔드 통합 Server Actions는 백엔드 엔드포인트 구축을 간소화하고, 사용자 경험을 향상시킵니다. 이를 통해 개발자는 API 경로를 수동으로 생성할 필요 없이, React 컴포넌트 내에서 직접 서버에서 실행되는 함수를 정의할 수 있습니다. 3. 부분적 Pre-rendering: 빠른 초기 응답과 동적 콘텐츠 Next.js의 새로운 부분적 pre-rendering 기능은 초기 정적 응답과 동적 콘텐츠 스트리밍을 조화롭게 결합합니다. 이는 사용자에게 더 빠른 페이지 로딩 경험을 제공하면서 동시에 동적인 콘텐츠를 유연하게 제공합니다. 개발의 편의성: 더 쉬워진 Next.js 개발 경험 Next.js 14는 개발자들이 보다 빠르고 효율적으로 작업할 수 있도록 설계되었습니다. 이러한 편의성은 다음과 같은 형태로 나타납니다: 통합된 캐싱 및 재검증: 데이터의 유효성을 빠르게 확인하고 캐시된 콘텐츠를 최신 상태로 유지합니다. 간단한 함수 호출: 서버 작업을 위한 복잡한 설정 없이 간단한 함수 호출로 백엔드 기능을 사용할 수 있습니다. 보다 효율적인 코드 작성: 개발자들은 코드 작성 시간을 줄이고, 더 직관적인 방식으로 애플리케이션을 구성할 수 있습니다. Server Action: 프론트엔드와 백엔드의 간편한 통합 Server Action은 백엔드 기능을 프론트엔드 컴포넌트에 직접 통합함으로써 개발자들이 더욱 직관적으로 작업할 수 있도록 해줍니다. 이 기능은 Next.js가 React Canary 채널의 안정성을 기반으로 하여 새로운 기능을 채택하는 방식을 반영합니다. 양식 제출 시 서버에서 실행되는 processFormData 함수를 직접 호출합니다. 이는 기존의 복잡한 API 경로 설정 없이 서버 로직을 구현할 수 있도록 해주는 혁신적인 방식입니다. Server Action의 장점 간결성: React 컴포넌트 내에서 서버 작업을 직접 정의함으로써 코드를 간결하게 유지할 수 있습니다. 타입 안전성: TypeScript를 사용하여 클라이언트와 서버 간 완벽한 타입 안전성을 보장합니다. 효율적인 데이터 처리: 단일 네트워크 왕복으로 데이터 변경, 페이지 리렌더링 또는 리다이렉션을 처리할 수 있습니다. 재사용성: 다양한 작업을 구성하고 재사용할 수 있어 개발 과정을 효율적으로 만듭니다. Server Action은 백엔드 개발 경험이 있는 개발자들에게 친숙하면서도, 웹의 기본 사항인 Form과 FormData Web API를 기반으로 새로운 접근 방식을 제공합니다. 이러한 방식은 개발자들이 Next.js를 사용하여 보다 신속하고 효과적으로 프로젝트를 진행할 수 있게 도와줍니다. 부분적 Pre-rendering Next.js를 위해 작업 중인 부분 pre-rendering(빠른 초기 정적 응답을 갖춘 동적 콘텐츠에 대한 컴파일러 최적화)의 미리 보기를 제공하고, pre-rendering은 서버측 렌더링(SSR), 정적 사이트 생성(SSG) 및 증분적 정적 재검증(ISR)에 대한 10년 간의 연구 개발을 기반으로 구축되었습니다. React Suspense를 기반으로 구축 부분 사전 렌더링은 Suspense 경계에 따라 정의됩니다. pre-rendering이 활성화되면 이 페이지는 boundary를 기반으로 정적 셸을 생성합니다. React Suspense의 은 사전 렌더링됩니다. 그런 다음 셸의 Suspense fallback은 cookie를 읽어 카트를 결정하거나 사용자를 기반으로 배너를 표시하는 등의 동적 컴포넌트로 대체됩니다. 요청이 이루어지면 정적 HTML 셸이 즉시 제공됩니다. 는 쿠키에서 읽어 사용자 session을 확인하므로 이 컴포넌트는 정적 셸과 동일한 HTTP 요청의 일부로 스트리밍됩니다. 추가 네트워크 왕복이 필요하지 않습니다. 가장 세부적인 정적 셸을 가지려면 Suspense boundary를 추가해야 할 수도 있습니다. 그러나 현재 loading.js를 이미 사용하고 있다면 이는 암시적인 Suspense boundray이므로 정적 셸을 생성하는 데 변경이 필요하지 않습니다. 메타데이터 개선 뷰포트, 색 구성표 및 테마에 대한 중요한 페이지 콘텐츠를 서버에서 스트리밍하기 전에 먼저 브라우저에 전송해야 하는 메타데이터가 있습니다. 이러한 태그가 초기 페이지 콘텐츠와 함께 전송되도록 하면 원활한 사용자 경험에 도움이 되며, 테마 색상을 변경하거나 뷰포트 변경으로 인해 레이아웃이 이동하여 페이지가 깜박이는 것을 방지할 수 있습니다. Next.js 14에서는 blocking 및 non-blocking 메타데이터를 분리했습니다. 메타데이터 옵션의 작은 하위 집합(small subset)만 차단되며, 우리는 non-blocking 메타데이터가 부분적으로 pre-rendering된 페이지가 정적 셸을 제공하는 것을 방해하지 않도록 하고 싶습니다. 다음 메타데이터 옵션은 이제 더 이상 사용되지 않으며 향후 주요 버전의 메타데이터에서 제거(deprecated)될 예정 이라고 합니다. : 뷰포트의 초기 확대/축소 및 기타 속성을 설정합니다. : 뷰포트의 지원 모드(밝음/어두움)를 설정합니다. : 뷰포트 주변의 크롬이 렌더링해야 하는 색상을 설정합니다. Next.js 14부터 이러한 옵션을 대체하는 새로운 옵션 및 가 있습니다. 다른 모든 옵션은 동일하게 유지됩니다. 마치며 turobopack과 pre-rendering 은 기대가 되는 부분이긴 하지만, ServerActions은 심플해 보이긴 하지만 이렇게 쓰면 코드가 지저분해 질것 같은데 이게 맞나 싶은 느낌이 들기도 하네요. 아무튼 프론트엔드의 변화 속도는 정말 빠른것 같다는 생각입니다.

대세 프론트 라이브러리인 리엑트로 개발을 하기에 앞서 가급적이면 꼭 지켜야할 부분을들 정리하였습니다. 습관적으로 아래 내용들은 반드시 숙지합시다! 함수형 컴포넌트와 훅을 사용 React 함수 컴포넌트와 훅은 클래스에 비해 더 간결하고 읽기 쉬운 코드를 생성하므로 더 자주 사용해야 합니다. 상태사용 피하기 React 애플리케이션을 빌드할 때 상태를 많이 사용할수록 앱 전체에서 더 많은 데이터를 추적해야 하므로 상태를 최대한 사용하지 마십시오. 상태 사용을 최소화하는 한 가지 방법은 필요할 때만 선언하는 것입니다. 예를 들어 API에서 사용자 데이터를 가져오는 경우 개별 속성을 저장하는 대신 전체 사용자 개체를 상태에 저장합니다. 동일한 구성요소와 관련된 파일을 하나의 폴더에 정리 Navbar 구성 요소를 생성하는 경우 Navbar 구성 요소 자체, 스타일 시트, 구성 요소에 사용된 기타 JavaSript 및 자산 파일을 포함하는 navbar라는 폴더를 생성합니다. 인덱스 키를 Props Key로 사용하지 않기 아래와 같이 인덱스 키를 사용하면 때때로 작동하지만 인덱스를 키로 사용하면 특히 목록이 변경될 것으로 예상되는 경우 문제가 발생할 수 있습니다. 가능한 경우 div 대신 조각을 선택하십시오. 를 사용하면 DOM 크기가 증가합니다. 특히 태그 또는 DOM 노드가 많을수록 웹사이트에 더 많은 메모리가 필요하고 브라우저가 웹사이트를 로드하는 데 더 많은 전력을 사용하기 때문에 대규모 프로젝트에서 더욱 그렇습니다. 이로 인해 페이지 속도가 느려지고 잠재적으로 사용자 경험이 저하될 수 있습니다. 불필요한 태그를 제거하는 한 가지 예는 단일 요소를 반환할 때 태그를 사용하지 않는 것입니다. 명명 규칙 준수 구성 요소 이름을 지정할 때 항상 PascalCase를 사용하여 구성 요소가 아닌 다른 JSX 파일과 구별해야 합니다. (예: TextField, NavMenu 및 SuccessButton) handleInput() 또는 showElement()와 같은 React 구성 요소 내부에 선언된 함수에는 camelCase를 사용하십시오. 반복적인 코드 피하기 중복된 코드를 작성하고 있다는 것을 알게 되면 재사용할 수 있는 구성 요소로 변환하십시오. Props에 객체 구조화 사용 props 객체를 전달하는 대신 객체 구조화를 사용하여 props 이름을 전달하십시오. 이렇게 하면 사용할 때마다 props 객체를 참조할 필요가 없습니다. 맵을 사용하여 동적으로 배열 렌더링 map()을 사용하여 반복되는 HTML 블록을 동적으로 렌더링합니다. 예를 들어 map()을 사용하여 태그의 항목 목록을 렌더링할 수 있습니다. 각 React 구성 요소에 대한 테스트 작성 생성한 구성 요소에 대한 테스트를 작성하면 오류 가능성이 줄어듭니다. 테스트를 통해 구성 요소가 예상대로 작동하는지 확인합니다. React의 가장 일반적인 테스트 프레임워크 중 하나는 Jest이며 테스트를 실행할 수 있는 환경을 제공합니다. React Is a Powerful Tool, But You Must Follow Certain Practices React는 사용 방법 측면에서 다소 유연하지만 특정 사례를 따르면 경험을 최대한 활용하는 데 도움이 됩니다.

!01 웹 어플리케이션의 렌더링 방식은 크게 서버와 클라이언트 렌더링 방식이 있습니다. 이 방식을 살펴보기에 앞서 과거 웹 사이트의 역사에 대해 간단하게 살펴보겠습니다. Static Site 1990년 중반까지는 대부분의 사이트가 static 사이트 였습니다. 서버에 이미 잘 만들어진 html문서들이 있고 사용자가 부라우저에서 주소에 접속하면 서버에 이미 배포되어있는 HTML 문서를 받아와 보여주는 형식이죠. 이런한 방식의 문제점은 페이지에서 다른 메뉴를 클릭하면 다시 서버에서 해당페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야 합니다. (깜박, 깜박... 정말 사용성이 떨어지죠) iframe 이후 1996년 문서내에서 또 다른 문서를 담을 수 있는 태그가 도입이 되었고 이제는 페이지내에서 부분적으로 문서를 받아와서 업데이트 할 수가 있게 됩니다. (지금도 간혹 쓰이고 있는 태그입니다.) XMLHttpRequest API 그리고 1998년 우리가 많이 쓰고 있는 fetch API의 원조 가 개발이 되어 이제는 HTML문서 전체가 아니라 과 같은 포멧으로 서버에서 가법게 필요한 데이터만 받아 올 수 있게 됩니다. 그 데이터를 자바스크립트를 이용해서 동적으로 HTML요소를 생성하여 페이지에 업데이트 하는 방식이죠. AJAX, SPA 2005년 이런 방식이 공식적으로 AJAX라는 이름을 가지게 되고 구글에서도 AJAX를 이용해 GMail, Google Map과 같이 우리가 많이 쓰고 있는 웹 어플리케이션을 만들기 시작합니다. 이것이 바로 현재 널리 쓰이고 있는 입니다. 사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와 부분적으로만 업데이트 하게 되죠. 이런 방식으로 하나의 어플리케이션을 사용 하듯 웹사이트에서도 이제 사용성이 굉장히 좋아지게 됩니다. 이런 SPA트랜드 + 사용자의 PC성능이 점차 좋아져서 많은 것들을 무리 없이 처리할 수 있게 되었고 자바스크립트도 표준화가 잘 되어짐에 따라 Angular, React, Vue와 같은 프레임워크가 나와 시대로 접어듭니다. Client Side Rendering 클라이언트 사이드 렌더링이란 쉽게 얘기하면 클라이언트에서 다 처리하는걸 말하는데요, 서버에서 index.html 파일을 클라이언트에 보내주면 자바스크립트를 이용해 서버에서 데이터를 요청하고 받아온 데이터를 기반으로 동적으로 HTML을 생성하여 사용자에게 최종적인 어플리케이션을 보여 주게 됩니다. 그런데 말입니다. 이런 클라이언트 사이드 렌더링은 다음과 같은 문제점이 있습니다. 사용자가 첫 화면을 보기까지의 시간이 오래 걸릴 수 있다 썩 좋지 않는 SEO(Search Engin Optimization) Server Side Rendering 이러한 CSR의 문제점 때문에 기존 Static 사이트에서 영감을 받은 이 도입되게 됩니다. 클라이언트에서 모든 것을 처리하는 방식과는 다르게 웹사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML파일을 만들게 되고 이렇게 만들어진 HTML파일을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트에게 보내줍니다. 그럼 클라이언트에서는 잘 만들어진 HTML문서를 받아와 바로 사용자에게 보여줄 수 있게 되는거죠. 어떤것이 더 좋을까? 이런 SSR을 이용하게 되면 CSR과 비교했을때 다음과 같은 장점이 있습니다. 첫 번째 페이지 로딩이 빨라짐 모든 컨텐츠가 HTML에 담겨져 있기 때문에 효율적인 SEO 가능 그럼 이런 SSR 과연 모든것의 해결책이 될까요? 그것은 아닙니다. SSR에도 다음과 같은 큰 문제점이 존재하는데요, Static 사이트와 같은 깜박임 이슈 즉, 썩 좋지 않는 UX 서버의 과부화 (사용자가 많은 사이트 일수록) 사용자가 빠르게 웹사이트를 확인할 수 있지만 동적으로 데이터를 처리하는 자바스크립트를 다운로드 받지 못해 여기저기 클릭해도 반응이 없는 경우가 발생할 수 있습니다. TTV(Time To View), TTI(Time to interact) TTV, TTI 두가지에 대해 좀 더 살펴보겠습니다. CSR은 1. 사이트에 접속 2. 서버에게서 텅텅빈 인덱스 파일을 받아옴 3. 웹사이트에 필요한 자바스크립트를 서버에 요청 4. 서버에게서 자바스크립트 파일을 받아옴 5. 최종적으로 동적으로 HTML을 생성할 수 있는 자바스크립트를 받아와 웹사이트를 사용자가 볼수 있게 해줌과 동시에 사용자 클릭이 가능 >즉, CSR은 TTV 사용자가 웹사이트를 볼 수 있음과 동시에 TTI 클릭을 하거나 인터랙션이 가능하게 됩니다. 반대로 SSR은 1. 사이트에 접속을 하면 서버에서 잘 만들어진 인덱스 파일을 받아오고 2. 사용자는 웹사이트를 볼수 있게 됩니다. 3. 하지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았기 때문에 이 순간 사용자가 클릭을 해도 반응이 없습니다. 4. 이후 최종적으로 자바스크립트 파일을 서버에서 받아온 이후에나 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해집니다. >즉, SSR은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터렉션을 할 수 있는 공백 기간이 꽤 긴편입니다. 그래서 웹사이트의 성능을 분석할때 와 도 중요한 매트릭으로 사용할 수 있습니다. CSR을 많이 사용하는 분들이라면 우리가 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 첫번째로 사용자가 보기위한 정말 필수적인 부분만 보낼 수 있을지를 고민해야 합니다. SSR같은 경우는 사용자가 보고, 인터렉션 하는 시간의 공백을 줄이기 위해 어떻게 해야할지, 어떻게 조검더 매끄러운 UI와 UX를 제공할 수 있을지 고민해 보면 좋을것 같습니다. 마치며 요즘에는 꼭 CSR 또는 SSR만을 고집해서 사용하기 보다는 와 같은 도 있습니다. (지금 보고 계시는 블로그도 Gatsby를 사용) 뿐만아니라 React의 Next.js, Angular Universal과 같은 Angular 애플리케이션을 서버에서 실행하는 테크닉도 있으니, 어떤 방식이 좋고 나쁘고가 아닌 각각의 방식을 이해하고 필요에 의해 선택적으로 사용하면 될 것 같습니다.

Web Storage Web Storage는 HTML5에서 추가된 간단한 키와 값을 저장(key-value storage) 할 수 있는 저장소이다. 데이터의 지속성에 따라 영구저장소(LocalStorage)와 임시저장소(SessionStorage) 두가지를 지원한다. 그 동안 많이 사용해 왔던 쿠키와 거의 차이가 없어 보이지만 몇 가지 쿠키의 단점을 극복하는 개선점이 도입이 되었다. Web Storage 특징 Web Storage는 다음과 같은 특징이 있다. 키와 값은 무조건 문자열로 변환되어 저장된다. (객체를 읽고 쓰려면 JSON.stringify, JSON.parse를 사용) 브라우저별 용량제한이 다르다. (용량 제한은 대략 5MB) 도메인별 Storage는 다르며 도메인별로 용량 제한이 있다. (Protocal, host, port가 같으면 같은 스토리지를 공유) 이것 마저 용량이 부족하다면 indexedDB가 있다. (indexedDB에 대해서는 다음에 좀더 자세히 알아보도록 하고,,) localStorage와 sessionStorage Web Storage는 데이터의 지속성에 따라 두 가지 용도의 저장소를 제공한다. LocalStorage 저장한 데이터를 명시적으로 지우지 않는 이상 영구적으로 보관이 가능하다. 앞서 말한 것처럼 도메인별로 스토리지가 생성이 되고 Windows 전역 객체의 LocalStorage라는 컬렉션을 통해 저장과 조회가 이루어진다. SessionStorage SessionStorage는 데이터가 지속적으로 보관이 되지 않는다. 이는 마치 브라우저 기반 세션 쿠키와 그 성질이 비슷한데, 현재 페이지가 브라우징되고 있는 브라우저 컨텍스트 내에서만 데이터가 유지된다. 쉽게 말하자면, 탭 브라우징이나 브라우저를 하나 더 실행해서 같은 페이지를 실행했을 때, 이 두 페이지의 SessionStorage는 각각 별개의 영역으로 서로 침범하지 못한다는 의미이다. 이는 도메인만 같으면 전역적으로 공유 가능한 LocalStorage와 구분 되는 가장 큰 특징이다. Cookie 후속 요청으로 서버로 다시 보내야하는 데이터를 저장한다. 만료는 유형에 따라 다르며 만료 기간은 서버 측 또는 클라이언트 측 (일반적으로 서버 측)에서 설정할 수 있다. 쿠키는 주로 서버 측에서 읽기(클라이언트 측에서 읽을 수도 있음) 위한 것이며, Local Storage 및 Session Storage는 클라이언트 측에서만 읽을 수 있다. 크기는 4KB보다 작아야 한다. 해당 쿠키에 대해 httpOnly 플래그를 true로 설정하여 쿠키를 안전하게 만들 수 있다. 이렇게하면 쿠키에 대한 클라이언트 측 액세스가 차단된다. 각 저장소별로 데이터가 어떻게 저장되고 있는지를 보고 싶다면 디버깅모드(F12) > Application에서 확인 할 수 있다. !01 마치며... WebStorage의 보안은 서로 다른 도메인의 데이터 침범을 막고는 있지만 클라이언트, 즉 사용자를 막고 있지는 않다. 클라이언트는 얼마든지 저장된 값을 임의로 수정이 가능하다. 이것은 쿠키와 동일한 개념이다. 그렇다고 쿠키에 비해 별다른 보안 취약점을 더 가진 것은 아니다. 따라서 개발자는 사용자에 의한 이러한 임의 변경에 항상 예의 주시하고 방어 코드의 작성을 잊지 말아야 한다.