1.react가 아닌 next 사용했을 때의 장점

여러개중에 경험한 것 위주로 말씀드려보면 서버 사이드 렌더링이 가장 큰 장점이라 생각합니다. 서버에서 미리 렌더링한 페이지를 빌드타임에 html을 생성해 초기 로딩 시간이 단축됩니다. 물론 현 시점에서는 ssr 렌더링을 프로젝트에 도입해보진 못해서 경험적인 부분은 당장은 말씀드리기 힘드나 실제 면접때까지는 경험할 수 있는 부분이라 생각합니다.

app router를 사용하니 라우팅이 너무 편리한 장점이 있었는데요. 폴더 명 안에 page.tsx파일을 만들어 주기만해도 라우팅이 바로 적용되는게 편리하다는 체감이 되었습니다.

next/image 컴포넌트를 사용하면 이미지 최적화가 되는 것도 현 시점에선 경험을 말씀드릴 순 없지만 추후 프로젝트가 끝나가면서 그냥 img태그를썼을 때와 Image 컴포넌트를 사용했을 때의 성능 비교를 할 수 있을 것 같아서 수치상으로도 명확히 설명이 가능할 것 같습니다.

그리고 api 라우트 덕분에 별도의 서버 없이 api를 구축할 수 있던 것도 장점인데 사실 이 부분은 백엔드 개발자와 직접 협업을 해본 경험이 없다보니 체감은 사실 되진 않은 것 같습니다.
물론 axios나 json서버같이 별도의 서버 없이 api 구축할 수 있다는 사실 자체는 장점으로 느껴지긴했던 것 같아요

2. 사용한 기술 스택들을 선정한 이유

TypeScript

정적 타입 검사를 제공하여 코드 작성 시 오류를 조기에 발견하고, 코드 품질 유지보수성을 높여주는게 장점이여서 채택했는데, 간단한 프로젝트에서는 협업할때 타입이 직관적으로 보이고 협업에 유리하구나 정도만 체감했다면 온전히 100% 진행한 개인 프로젝트에서는 타입스크립트 때문에 배포 에러를 너무 많이 경험해봐서, 너무 만만하게 보면 안되는 강력한만큼 문제 발생을 최소화할 수 있는 장치구나 라고 느꼈던 것 같습니다.

Zod

로그인 회원가입 유효성 검사에 사용하기 위해 채택했습니다.
이전에는 정규표현식을 커뮤니티에서 가져와서 직접 코드에 유효성 검사를 다 구현하다보니 가독성도 떨어지고 코드도 길어져서 성능 저하를 일으켰다면 zod는 사용하기도 편리하고 typescript와도 호환성이 좋아서 매우 만족했던 라이브러리였습니다.

react-hook-form

폼 핸들링을 간편하게 처리해주며 불필요한 렌더링을 최소화하여 성능 향상을 목적으로 선정하였습니다. 이전에는 폼 관련해서 렌더링에 대한 깊은 고민을 해본적이 없었는데 이 라이브러리를 적용해보면서, 입력 필드의 값이 변경되거나 검증이 필요할 때만 해당 필드와 관련된 컴포넌트만 재렌더링된다는 사실을 알게되어서 내가 놓치고 있는 부분에서의 성능도 개선이 되는구나 느꼈던 경험을 하였습니다.

Q: React Hook Form의 register 함수가 어떻게 동작하나요?
답변: register 함수는 폼 필드를 React Hook Form에 등록하는 데 사용됩니다. 이 함수는 입력 필드의 값과 검증 규칙을 연결하여 상태를 관리합니다. register 함수는 입력 필드를 DOM에서 직접 제어하고, 폼 상태와 유효성 검증 결과를 React Hook Form의 내부 상태와 동기화합니다. 등록된 필드는 getValues, setValue, reset 등의 함수로 쉽게 접근하고 조작할 수 있습니다.

Q: React Hook Form의 비제어 컴포넌트와 제어된 컴포넌트의 차이점은 무엇인가요?
답변: 비제어 컴포넌트는 React Hook Form이 입력 필드의 값을 직접 추적하지 않고, DOM에서 값을 읽어오는 방식입니다. 이 방식은 렌더링 성능을 향상시키고, 폼이 커질 때 유용합니다. 반면, 제어된 컴포넌트는 React의 상태를 사용하여 입력 값을 직접 추적하고 업데이트합니다. 제어된 컴포넌트는 더 많은 제어를 제공하지만, 비제어 컴포넌트에 비해 성능이 저하될 수 있습니다.

ShadCN/UI

그동안 styled-components만 사용하다 처음으로 샤드시엔을 사용해보았는데, 최초엔 다양한 경험을 쌓고 싶어 러닝을 위해 채택을 하였는데 실제로 사용해보니 원하는 컴포넌트를 다운받아서 import하는 형식으로 사용하는게 너무 편리했습니다.
그리고 styled-components만의 네이밍이 소규모 프로젝트만 경험해본 저에게는 오히려 구분짓기 좋아서 장점이라고 생각했었으나 샤드시엔과 테일윈드를 사용해보니 굳이 네이밍에 고민할 시간조차 사치라고 생각되었던 경험이 있습니다.

Tailwind CSS

테일윈드도 넥스트.js 세팅시에 추천하는 스타일링 기법이고 shadcn과도 호환성이 좋아서 채택해보았는데, 공식 홈페이지에서 원하는 css를 검색해서 진행하는 방식이 스타일드 컴포넌트와 다르게 네이밍 걱정 없이 그냥 가져다 쓰면 되서 오히려 더 편리했었던 기억이 있습니다.