---

본 프로젝트 FITCHECK는 이미지 중심의 패션 SNS로 인터랙션 웹 애플리케이션입니다.

기술 스택은 단순한 구현 편의성이 아닌, 실제 서비스 환경에서의 성능, 확장성, 운영 안정성을 최우선 기준으로 선정했습니다.

• 고용량 이미지 데이터
  • 피드 및 프로필에서 이미지 노출 비중이 매우 높음
• 잦은 사용자 인터랙션
  • 좋아요, 댓글, 북마크, 투표 등 상태 변경에 따른 리렌더링 빈도 높음
• 권한별 UX 차등
  • 비로그인 사용자에게는 콘텐츠 일부 공개
  • 핵심 기능은 로그인 세션 기반으로 제공

따라서 본 프로젝트는 사용자 체감 성능과 인터랙션 안정성을 핵심 판단 기준으로 삼았습니다.

---

사용자 체감 성능 & 인터랙션 안정성 정의

사용자 체감 성능과 인터랙션 안정성은 단순한 페이지 로딩 시간만으로 판단하기 어렵습니다. 이미지 비중이 높고 상태 변경이 잦은 서비스에서는 “언제 보이기 시작했는지”와 “얼마나 즉각적으로 반응하는지”가 핵심 기준이 된다고 생각합니다. 이러한 체감 요소는 Web Vitals 지표를 통해 정량적으로 측정합니다.

사용자 체감 성능 (Perceived Performance)

지표	정의	예시	근거
LCP (Largest Contentful Paint)	화면에서 가장 큰 콘텐츠가 완전히 렌더링 되는 시점	홈 피드 진입 후 메인 이미지가 완전히 로딩되어 선명하게 보이는 순간	사용자가 실질적으로 느끼는 로딩 속도 - next/image를 통한 자동 리사이징 및 WebP 변환 - 일반 <img> 대비 LCP 단축
FCP (First Contentful Paint)	화면에서 가장 첫번째 콘텐츠가 렌더링 되는 시점	페이지 접속 후 흰 화면에서 로고·텍스트·스켈레톤 등 첫 콘텐츠가 나타나는 순간	사용자가 "로딩이 시작되었다"는 시각적 신호를 주는 지표 - Next.js의 Server-Side Rendering을 통해 빈 화면 노출 최소화
CLS (Cumulative Layout Shift)	화면이 얼마나 불안정한지를 측정하는 지표	게시물을 보다가 이미지 로딩으로 좋아요 버튼 위치가 갑자기 밀리는 현상	화면에서 레이아웃이 밀리는 정도 - 이미지 비율 사전 확보- Placeholder 적용을 통한 레이아웃 안정성 확보
TTI (Time to Interactive)	클릭이나 입력 같은 유저의 인터랙션이 즉각적으로 반영되는 시점	화면은 이미 보이지만, 좋아요 버튼이 실제로 클릭 가능해지는 시점	- 인터랙션 요소 우선 하이드레이션

인터랙션 안정성 (Interaction Stability)

INP (Interaction to Next Paint)

사용자가 인터랙션을 수행했을 때 브라우저가 그 결과로 다음 UI를 그려내는데까지 걸리는 시간

• TanStack Query v5의 낙관적 업데이트 적용 -> 낙관적 업데이트란? 사용자의 동작 결과를 서버에서 성공을 했다는 가정하에 즉시 UI를 반영해주는 것을 의미함. 만약, 서버에서 실패시 원래 UI로 돌려버림.
• 서버 응답 이전에 UI 즉시 반영하여 INP 최소화

---

성능 측정 및 검증 도구

• Lighthouse
  • Web Vitals 기반 초기 로딩 성능 점수 비교
• React Profiler
  • Zustand 적용 후 렌더링 범위 및 성능 시각적 검증

---

분류	기술	버전
Framework	Next.js (App Router)	^16.x
Language	TypeScript	^5.x
Server State	TanStack Query	^5.x
Client State	Zustand	^4.x
Form	React Hook Form	^7.x
Validation	Zod	^3.x
Styling	Tailwind CSS	^3.x

---

FITCHECK는 단순 SPA가 아니라 외부 유입 → 콘텐츠 소비 → 인터랙션 전환 흐름이 중요한 서비스입니다.

Next.js는 다음 요구사항을 구조적으로 만족합니다.

• 서버 렌더링 기반 초기 화면 제공
• 콘텐츠 단위 페이지의 의미 있는 HTML 제공
• SEO 및 공유(OG) 대응
• 이미지 중심 서비스에 최적화된 기본 성능 구조

---

Next.js App Router의 기본 전제는 모든 컴포넌트는 Server Component로 시작한다는 점입니다. 이는 "클라이언트에서 꼭 필요한 경우에만 JS를 내려보낸다."는 명확한 방향성을 가지며, 본 프로젝트의 화면 구성 방식과 잘 맞습니다.

• 클라이언트 JS 번들 크기 감소
• 초기 로딩 속도 개선
• 민감한 로직을 클라이언트에 노출하지 않음

이 구조에서 use client는 “이 컴포넌트가 왜 클라이언트여야 하는지”를 명시하는 선언입니다.

---

FITCHECK는 단순 SPA가 아니라 콘텐츠 노출 구조와 앱형 인터랙션이 공존하는 서비스입니다. 렌더링 방식과 프레임워크 선택에 따라 성능, 확장성, 마케팅 효율이 크게 달라질 수 있어 Next.js와 React + Vite를 주요 후보로 비교했습니다.

항목	Next.js (콘텐츠·확장성 중심)	React + Vite (개발 효율 중심)
기본 렌더링	Server-first	Client-only
비로그인 피드	SEO 기반 유입 가능	체험용 화면에 한정
OG/공유	자동 HTML/메타 생성	별도 서버 작업 필요
데이터 보안	Server Component로 로직 은닉	로직 전부 클라이언트 노출
장기 확장	콘텐츠·마케팅 친화적	내부 UX 중심

본 프로젝트는 로그인 이전에도 콘텐츠가 노출되고 이를 통해 유입과 전환이 이루어지는 구조의 서비스입니다. 이러한 특성상 초기 HTML 기반 콘텐츠 제공, SEO 대응, 공유 최적화가 필수적이며, 모든 렌더링을 클라이언트에 의존하는 React+Vite 구조는 장기적으로 한계를 가질 수 있다고 생각했습니다. Next.js는 이러한 요구사항을 기본적으로 충족하며 콘텐츠 중심 서비스로 확장 가능한 구조를 제공합니다.

React+Vite는 모든 컴포넌트를 기본적으로 클라이언트 컴포넌트로 취급합니다. 이로 인해 상태나 이벤트가 없는 정적 UI 까지도 클라이언트 번들에 포함되며 서비스 규모가 커질수록 번들 크기 증가와 성능 관리 부담이 발생할 수 있습니다. 반면 Nest.js(App Router)는 Server Component를 기본값으로 사용하고 클라이언트 로직이 필요한 경우에만 use client를 명시하도록 합니다. 이 구조는 불필요한 클라이언트 로직 확장을 사전에 억제하고 렌더링 책임을 서버와 클라이언트로 명확히 분리할 수 있게 합니다. 본 프로젝트는 데이터 조회 중심 화면과 사용자 인터랙션 UI가 명확히 구분되는 서비스이므로, 정적 UI는 Server Component, 사용자 인터랙션은 Client Component로 분리하여 성능 안정성과 유지보수 측면에서 합리적인 구조라고 생각했습니다.

---

본 프로젝트는 홈 게시물, 검색 피드, 투표 기능, 프로필 등 이미지가 서비스 경험의 중심이 되는 구조를 갖고 있습니다. 이러한 서비스에서는 단순히 이미지를 표시하는 것을 넘어 어떻게 전달하고 언제 로딩하며 어떤 크기로 제공하는지가 곧 성능과 사용자 경험을 좌우합니다. Next.js의 next/image는 단순한 이미지 컴포넌트가 아니라 이미지 전달 전반을 프레임워크 차원에서 최적화하는 도구입니다.

이를 통해

• 디바이스 및 뷰포트에 맞는 이미지 자동 제공
• Webp / AVIF 기반의 자동 포맷 변환
• Lazy loading 기본 적용으로 불필요한 네트워크 요청 최소화
• 이미지 영역 선확보를 통한 레이아웃 안정성 보장

이와 같은 최적화가 별도의 추가 설정 없이 기본값으로 적용됩니다. 특히, 동일한 이미지가 피드 게시물, 상세 게시물, 프로필 등 여러 크기와 맥락에서 반복 사용되는 구조에서 일관된 성능을 유지하면서도 관리 비용을 최소화할 수 있습니다.

React + Vite 환경에서도 이미지 최적화는 구현할 수 있으나 리사이징, 포맷 변환, lazy loading 등의 로직이 컴포넌트별 혹은 유틸 단위로 분산되기 쉽습니다.

---

구분	JavaScript (Dynamic)	TypeScript (Static)
컴파일 방식	인터프리터(실행 시 해석)	트랜스파일(컴파일 후 JS로 변환)
에러 감지 시점	브라우저 실행 중 (Runtime)	컴파일 시점에서 에러 감지
데이터 구조 정의	암묵적 (주석에 의존)	명시적 (Interface / Type 정의)
개발 도구 지원	제한적 (직접 확인 필요)	강력한 자동 완성 및 가이드
유지보수	코드가 길어질수록 관리 어려움	코드 안정성이 높고 유지보수 용이
실행 환경	모든 브라우저에서 실행 가능	JS로 변환 후 실행 가능

1. 복잡한 데이터 구조의 문서화 : FITCHECK의 중첩된 객체구조는 육안으로 파악하기 어렵습니다. TypeScript를 통해 데이터 형식을 코드로 문서화함으로써 동일한 데이터 구조를 정확하게 사용할 수 있습니다.
2. 데이터 무결성 및 신뢰도 확보 : 상태 변경 빈도가 높은 서비스 특성상 잘못된 상태 업데이트는 치명적인 런타임 오류로 이어집니다. 컴파일 단계에서 타입 체크를 강제함으로써 프론트엔드와 서버 간 데이터 규격을 일치시키고 데이터 신뢰도를 확보할 수 있습니다.
3. 대규모 리팩터링의 안정성 : 기능이 추가되거나 서버 응답 형식이 바뀔 때, TypeScript는 수정이 필요한 모든 곳을 에러로 알려줍니다. 이는 유지보수 비용을 획기적으로 낮추며 대규모 프로젝트에서도 기능을 확장할 수 있는 기반이 될 것입니다.

---

TanStack Query는 서버 상태를 클라이언트 애플리케이션에서 효율적으로 다룰 수 있도록 도와주는 라이브러리입니다. 쉽게 말해, 서버에서 받아오는 데이터를 관리하고, 로딩, 에러처리, 캐싱, 리패치 등의 과정을 간단하게 처리해주는 도구입니다.

1. 지능형 캐싱

   데이터를 한 번 가져오면 메모리에 저장해둡니다. 사용자가 다른 페이지에 갔다가 다시 돌아와도 서버에 또 물어보지 않고 저장된 데이터를 즉시 보여줍니다. 화면이 깜빡이지 않고 아주 빠르게 느껴지는 이유입니다.

2. 상태 자동 관리

• isLoading : 데이터를 가져오는 중인지?
• isError: 서버가 죽었거나 에러가 났는지?
• data : 성공적으로 가져온 데이터가 무엇인지? 이 값들을 실시간으로 제공해주므로 코드가 매우 단순해집니다.

3. 데이터 관리

   데이터가 상한 데이터인지 스스로 판단합니다. 데이터가 오래되었다고 생각하면 사용자가 모르는 사이에 백그라운드에서 데이터를 다시 가져와 화면을 최신 상태로 갈아 끼워줍니다.

Cache Strategy — Next.js Cache vs TanStack Query Cache

FITCHECK은 서버의 데이터 무결성과 클라이언트의 즉각적인 응답성을 동시에 확보하기 위해 Next.js와 TanStack Query의 캐시를 상호 보완적으로 배치하는 전략을 생각해봤습니다.

구분	Next.js Server Cache	TanStack Query (Client)
위치	서버 메모리 / 파일 시스템	사용자 브라우저 메모리
목적	외부 API/DB 재호출 방지	UX 중심 데이터 동기화
관리	revalidateTag 기반 (서버 중심)	staleTime, gcTime (클라이언트 중심)
데이터	공통 피드, 초기 진입 데이터	개인화 데이터, 상호작용 결과

왜 두 캐시를 병행하는가?

1. 인터랙션 안정성 (낙관적 업데이트)

   투표나 좋아요처럼 빈번한 인터랙션이 발생하는 본 프로젝트에서 서버 액션만 사용하면 네트워크 지연이 UI에 그대로 노출됩니다. TanStack Query를 통해 낙관적 업데이트를 적용함으로써 서버 응답 전에 UI를 즉각적으로 반영하고 실패 시에만 롤백하는 구조를 만들 수 있습니다.

2. 복잡한 비동기 데이터 로직의 표준화

   Next.js는 서버 단의 데이터 전달에 강점이 있지만 무한 스크롤 같은 동적인 데이터 병합과 메모리 제어에는 한계가 있습니다. useInfiniteQuery를 사용하여 페이지 누적과 캐시 삭제를 선언적으로 관리함으로써 성능 최적화와 코드 가독성을 높일 수 있습니다.

• 서버 캐시 : 첫 진입 시 사용자가 즉시 콘텐츠를 볼 수 있도록 빠른 LCP를 보장합니다.
• 클라이언트 캐시 : 페이지 이동이나 탭 전환 후 복귀 시, 서버 요청 없이 기존 데이터를 즉시 보여주고 백그라운드에서만 최신화를 진행하여 깜빡임 없는 화면 전환을 제공할 수 있습니다.

---

Zustand는 Next.js 안에서 서버와 전혀 상관없는 클라이언트 UI 상태를 관리하는 도구입니다.

구분	Redux	Zustand
복잡도	Action, Reducer, Store 등 구조 복잡	단일 Store 중심의 직관적 구조
보일러플레이트	매우 많음 (코드 비대화)	거의 없음 (필요한 기능만 간결하게)
번들 크기	무거움 (대규모 프레임워크)	매우 가벼움 (초경량 라이브러리)
학습 곡선	높음 (개념 이해에 시간 소요)	매우 낮음 (Hooks 기반으로 직관적)

1. UI 상태 관리에 최적화된 가벼움

   본 프로젝트의 클라이언트 상태는 서버 데이터에 비해 구조가 단순합니다. Redux의 무거운 아키텍처를 도입하여 코드 복잡도를 높이기 보다, 필요한 상태만 Hook 형태로 즉시 생성하고 구독할 수 있는 Zustand가 개발 효율성 측면에서 압도적이라고 판단했습니다.

2. 유연한 상태 구독과 성능 최적화

   Redux는 전체 상태 트리 구조를 가지므로 성능 최적화를 위해 신경 쓸 부분이 많습니다. 반면 Zustand는 Selector 기능을 통해 특정 상태값만 선택적으로 구독하는 것이 기본입니다. 이 덕분에 관련 없는 상태가 변하더라도 해당 컴포넌트는 리렌더링 되지 않아서 성능 관리가 중요한 모바일 웹 환경에서 최적화 할 수 있습니다.

---

React에서 폼 상태를 최소한의 리렌더링으로 관리하기 위한 폼 전용 라이브러리

• 비제어 컴포넌트를 통한 성능 최적화 : 기존 React의 useState 방식은 글자 하나를 입력할 때 마다 전체 컴포넌트가 리렌더링 되어 필드가 많아질수록 타이핑 지연이 발생합니다. React Hook Form은 비제어 컴포넌트 방식을 활용해 입력 중 발생하는 불필요한 리렌더링을 차단하며 대규모 폼에서도 사용자에게 끊김 없는 입력을 제공할 수 있습니다.
• 구독 기반의 상태 업데이트 : 특정 필드의 값만 감시하거나 변경하는 기능이 매우 효율적으로 설계되어 있습니다. 화면 전체를 새로 그리지 않고도 특정 입력값에 따른 동적인 UI 변화를 구현할 수 있어 성능 관리와 복잡한 UI 구현을 해결할 수 있습니다.

Typescript 기반 스키마 선언 및 런타임 데이터 검증 라이브러리

• 기존의 수동 타입 정의 방식은 비즈니스 로직과 타입 선언이 동기화되지 않아 런타임 에러의 주요 원인이 되었습니다. Zod를 통해 하나의 스키마에서 타입 추론과 데이터 검증을 동시에 수행함으로써 정적 타입 시스템과 실제 데이터 사이의 간극을 완벽히 제거했습니다. 이는 API 응답이나 사용자 입력 등 외부 데이터가 유입되는 지점에서 강력한 방어막 역할을 수행합니다.

• 명령형 조건문으로 흩어져 있던 검증 로직을 단일 스키마 정의로 통합했습니다. 메서드 체이닝 기반의 선언적 구조를 활용하여 데이터 규격을 코드 자체로 문서화했으며 비즈니스 규칙 변경 시 해당 스키마만 수정하면 타입과 검증로직이 즉시 동기화되는 높은 유지보수성을 확보했습니다.

본 프로젝트에서는 입력 폼과 사용자 인터랙션이 빈번한 서비스로 클라이언트에서는 React Hook Form을 사용해 폼 상태를 가볍게 관리하고, Zod를 통해 입력 데이터의 구조와 검증 규칙을 명확히 정의할 수 있습니다.

Next.js 환경에서는 동일한 Zod 스키마를 서버에서도 재사용함으로써 클라이언트 UX와 서버 데이터 무결성을 동시에 확보할 수 있습니다.

---

• Tailwind css는 빌드 타임에 정적 CSS 파일을 생성하므로 모든 스타일 로직이 서버 컴포넌트 환경과 충돌 없이 동작합니다. 이는 Next.js의 서버 사이드 렌더링 및 정적 재생성 과정에서 스타일 계산을 위한 추가 오버헤드를 발생시키지 않아 초기응답속도를 최적화 할 수 있습니다.
• 스타일 시트가 브라우저 실행 시점에 동적으로 생성되지 않기 떄문에 자바스크립트 메인 스레드의 부담을 줄입니다. 특히 이미지 콘텐츠가 중심인 FITCHECK 서비스에서 스타일 연산 비용을 제거함으로써 사용자의 기기 사양에 관계없이 부드러운 레이아웃 랜더링과 시각적 안정성을 제공합니다.
• 빠른 UI 반복 주기를 사진 프로젝트에서 디자인 일관성을 유지하고 불필요한 중복 CSS 생성을 방지하여 전체 번들 크기를 효율적으로 관리하게 합니다.

---

• 상태 변화에 따라 스타일을 동적으로 생성하는 과정에서 JS CPU 점유율이 상승합니다. 상호작용이 잦고 많은 데이터를 렌더링해야 하는 FITCHECK 인터페이스 특성상 이러한 런타임 스타일 연산은 사용자 경험의 미세한 버벅임을 초래할 수 있다고 판단했습니다.
• 서버에서 생성된 HTML과 클라이언트 스타일 시트를 동기화 하는 과정에서 추가적인 비용이 발생합니다. 기술적 복잡도를 낮추고 데이터 로딩 속도를 극대화하기 위해 정적 스타일링 방식을 선택했습니다.

---

✅ 핵심 기술별 버전 선택 근거

Next.js (App Router) ^16.x를 선택한 이유

구분	Next.js 15	Next.js 16
기본 번들러	Webpack	Turbopack (기본)
React 버전	React 18	React 19
렌더링 최적화	개발자 수동 최적화	React Compiler 자동 최적화
Prefetch 전략	페이지 단위	Incremental Prefetching

1. 번들러 관점: Webpack -> Turbopack

Next.js 15까지는 Webpack을 기본 번들러로 사용했습니다. Webpack은 안정적이지만 모듈 그래프 전체를 기준으로 빌드를 수행하기 때문에 개발 단계에서 코드 변경 시 빌드 속도가 점진적으로 느려지는 한계가 있었습니다. 반면, Next.js 16버전에서의 Turbopack은 Rust 기반의 병렬 처리 구조를 통해 개발 환경에서 빠른 빌드 속도를 제공합니다. 기존 Webpack이 Javascript로 작성되어 단일 스레드 처리 방식이었던 반면, Turbopack은 멀티 스레드 병렬 처리를 통해 컴파일과 번들링을 동시에 수행할 수 있어 속도면에서 차이를 보인다는 장점이 있습니다.

2. 렌더링 최적화 관점 : 수동 최적화 -> React Compiler

Next.js 15까지는 성능 최적화를 위해 useMemo, useCallback, React.memo 등을 개발자가 직접 설계해야 했습니다. 이는 코드 복잡도 증가, 과도한 메모이제이션 또는 누락으로 인한 성능 불안정성 이라는 문제가 있었습니다. Next.js 16은 React 19기반 React Compiler를 기본 지원하며, 컴파일 단계에서 자동으로 불필요한 리렌더링을 제거합니다. 이로 인해 상태 변경 시 필요한 컴포넌트만 재렌더링 됩니다.

3. 네트워크 관점 : 페이지 단위 prefetch -> Incremental Prefetching

Next.js 15의 prefetch는 페이지 단위로 동작하여 사용자가 실제로 진입하지 않더라고 해당 페이지 전체 리소스를 미리 다운로드하는 구조였습니다. Next.js 16의 Incremental Prefetching은 컴포넌트 단위를 기준으로 필요한 단위만 점진적으로 prefetch합니다. 이 방식은 네트워크 사용량 감소되며 클릭 직전 필요한 리소스만 준비됩니다. 페이지 전환 체감 속도를 안정적이게 해줍니다.

---

TypeScript ^5.x 선택 이유

구분	TypeScript 4.x	TypeScript 5.x
컴파일 성능	보통	더 빠름
타입 체크 속도	파일 수 증가 시 느려짐	대규모 프로젝트에서도 안정적
타입 추론 정확도	제한적	더 정교함
타입 단언(as) 사용	자주 필요	사용 빈도 감소
제네릭 추론	경우에 따라 불완전	개선됨
조건부 타입 처리	복잡할수록 불안정	정확도 향상
IDE 반응 속도	프로젝트 커질수록 저하	자동완성·에러 표시 개선

TypeScript 4.x에서도 기본적인 타입 안정성은 확보할 수 있습니다. 그러나 프로젝트 규모가 커질수록 파일 수 증가에 따른 타입 체크 속도 저하, 복잡한 제네릭 및 조건부 타입 사용 시 타입 추론 한계, 이를 보완하기 위한 잦은 as 타입 단언 사용의 문제가 발생합니다. 이러한 문제는 개발 과정에서 생산성을 떨어뜨릴 뿐 아니라, 타입 시스템에 대한 신뢰도를 낮추는 요인이 됩니다.

TypeScript 5.x는 이러한 문제를 개선하는 데 초점을 맞춘 버전입니다. 컴파일 성능과 타입 추론 정확도가 전반적으로 향상되어, 코드베이스가 커지더라도 타입 체크 속도와 IDE 반응성이 안정적으로 유지됩니다. 그 결과 타입 오류를 런타임 이전 단계에서 더 많이 사전에 발견할 수 있으며, 불필요한 타입 단언 사용이 줄어들어 코드의 신뢰성과 가독성이 함께 개선됩니다.

또한 TypeScript 5.x는 React 19와 Next.js 16의 타입 구조를 기준으로 설계되어 있습니다. 최신 프레임워크 환경에서 발생할 수 있는 타입 충돌이 줄어들고, 프레임워크 업데이트에 따른 유지보수 비용도 낮출 수 있습니다.

FITCHECK는 투표, 팔로우, 게시물 등 서로 강하게 연결된 데이터 구조를 다루는 서비스입니다. 이러한 환경에서는 타입 정확도가 곧 기능 안정성과 직결되기 때문에, 대규모 코드베이스에서도 타입 시스템의 일관성을 유지하는 것이 중요합니다.

결과적으로 TypeScript 5.x는 확장성과 유지보수성을 장기적으로 고려했을 때 가장 합리적인 선택지라고 판단했습니다.

---

TanStack Query ^5.x 선택 이유

구분	v4 (이전)	v5 (현재)
인자 전달	useQuery(key, fn, options) (혼합 가능)	useQuery({ ... }) (객체만 가능)
캐시 삭제 시간	cacheTime	gcTime
로딩 상태명	status: 'loading', isLoading	status: 'pending', isPending
성공/실패 콜백	onSuccess, onError (useQuery 내 존재)	제거됨 (useEffect나 전역 설정 권장)
Suspense	useQuery(..., { suspense: true })	useSuspenseQuery() (전용 훅)

1. API 구조 단순화 : 객체 기반 인자 전달 Tanstack Query v4에서는 key, fn, options를 혼합 전달할 수 있어 훅 사용 방식이 일관되기 어렵고 옵션 누락이나 순서오류가 발생하기 쉬웠습니다. 하지만, Tanstack Query v5에서는 모든 옵션을 객체 형태로만 전달하도록 강제하여 훅 사용 방식을 통일하고 옵션 가독성을 향상시키며 타입 추론을 안정화시킵니다.

2. 캐시 생명주기 명확화 : cacheTime -> gcTime Tanstack Query v4의 cacheTime은 언제 캐시가 삭제되는지 직관적으로 이해하기 어려운 단어였습니다. v5의 gcTime은 가비지 컬렉션 대상이 되는 시간을 명확히 드러내어 캐시 유지 시점, 메모리 해제 기준, 비활성 쿼리 관리를 더 명확하게 제어할 수 있습니다.

3. 상태 명명 개선 : loading -> pending 'loading'은 데이터가 아예 없는 상태 뿐만 아니라 다시 불러오는 상태 등 중의적으로 쓰일 수 있습니다. v5에서는 "아직 결과가 나오지 않아 대기중"이라는 의미인 pending을 사용하여 상태를 더 세분화했습니다.

4. 사이드 이펙트 분리 : 성공 및 실패 콜백 제거 v4에서는 useQuery 내부에 onSuccess, onError를 둘 수 있어 데이터 패칭과 부수효과가 섞이는 문제가 있었습니다. v5에서는 데이터는 쿼리로 가져오고 그에 따른 행동은 데이터를 사용하는 컴포넌트나 전역 설정에서 처리하라는 철학을 강제하여 코드의 일관성을 높였습니다.

5. Suspense 사용성 개선 v4에서는 옵션 설정만으로는 데이터가 무조건 존재한다는 사실을 타입스크립트에 알릴 수 없어 불필요한 예외 처리 코드가 있었지만 v5의 전용 훅은 데이터가 존재할 때만 컴포넌트가 실행됨을 타입 수준에서 보장합니다.

---

Zustand 4.x 선택 이유

구분	Zustand 3.x	Zustand 4.x
최신 React 표준	레거시 패턴 혼재	useSyncExternalStore 도입
상태 안정성	동시성 렌더링 시 데이터 불일치 위험	Tearing(화면 찢어짐) 방지
TypeScript	기본 수준의 타입 지원	정교한 타입 추론 시스템
최적화	불필요한 리렌더링 발생 가능	Selector 안정성 강화

1. React 최신 표준 준수 : React 18부터 표준이 된 useSyncExternalStore를 내부적으로 사용하여, React 19의 동시성 렌더링 환경에서도 데이터가 꼬이지 않고 항상 일관된 값을 화면에 보여줍니다.
2. 안전한 타입 시스템 : 4버전에서 강화된 타입 추론 기능은 React 19와 함께 사용하는 최신 TypeScript 환경에서 강력한 안정성을 제공하며 개발자의 실수를 컴파일 단계에서 차단합니다.
3. 성능 최적화 자동화 : Selector의 안정성이 대폭 개선되어 상태가 변할 때 필요한 컴포넌트만 정확하게 다시 그립니다. 이는 성능 관리가 중요한 대규모 프로젝트에서 별도의 최적화 작업 없이도 압도적인 퍼포먼스를 유지할 수 있게 해줍니다.

---

React Hook Form ^7.x 선택 이유

구분	React Hook Form 6.x	React Hook Form 7.x
설계 철학	기능 중심	성능·일관성 중심
렌더링 방식	상태 변화 시 리렌더 가능	불필요한 리렌더링 최소화
Controlled / Uncontrolled	혼합 사용	Uncontrolled 중심 명확화
API 일관성	일부 옵션 혼재	API 구조 정리 및 단순화
Form State 관리	의존도 높음	구독 기반 상태 관리 강화
성능 최적화	수동 최적화 필요	기본 성능 최적화 제공
TypeScript 지원	사용 가능	타입 추론 정확도 향상
대규모 Form 대응	커질수록 관리 부담	복잡한 Form에도 안정적

React Hook Form 6.x는 폼 구성에 대한 자유도가 높지만,폼이 복잡해질수록 불필요한 리렌더링과 Form State 의존 증가로 인해 성능 저하와 관리 복잡도가 함께 증가하는 구조입니다. React Hook Form 7.x는 이러한 문제를 해결하기 위해 Form 상태 관리 방식을 명확히 정리하고 성능 중심으로 재설계된 버전입니다. 입력값 변경 시 전체 Form이 리렌더링되지 않도록 설계되어, 입력 필드가 많은 화면에서도 UI 반응성이 안정적으로 유지됩니다.

Form State를 필요한 컴포넌트만 선택적으로 구독하도록 구조가 정리되어, 에러 표시, validation 상태, submit 가능 여부 등의 UI 로직을 명확히 분리할 수 있습니다. TypeScript 타입 추론이 개선되어, 필드 이름 오타나 Form 데이터 구조 오류를 컴파일 단계에서 사전에 차단할 수 있습니다.

본 프로젝트에서는 회원가입, 프로필 수정, 게시물 작성 등 폼 기반 인터랙션이 잦은 서비스에서는 입력 중 성능 안정성과 유지보수성이 매우 중요합니다. 이러한 요구사항을 종합했을 때, React Hook Form 7.x는 대규모 폼에서도 성능과 구조를 안정적으로 유지할 수 있는 가장 적합한 선택이라고 판단했습니다.

---

Zod ^3.x 선택 이유

구분	Zod 2.x	Zod 3.x
설계 방향	기본적인 스키마 검증	타입 중심 스키마 설계
TypeScript 연동	제한적	Type Inference 강화
타입 추론 정확도	부분적	정확하고 일관됨
런타임 검증	가능	정교하고 안정적
에러 구조	단순 메시지 중심	구조화된 에러 정보
커스텀 검증	가능하나 복잡	직관적인 refine/superRefine
Form 연동	가능	RHF 등과 자연스러운 연동
API 안정성	변동 가능성	안정화된 API
대규모 스키마	관리 부담	확장성과 유지보수성 개선

Zod 2.x에서도 기본적인 유효성 검증은 가능했지만, 스키마와 TypeScript 타입이 완전히 일치하지 않아 프로젝트 규모가 커질수록 타입 관리 비용과 불일치 위험이 커지는 구조였습니다.

Zod 3.x는 스키마 정의를 기준으로 런타임 검증과 TypeScript 타입 추론을 동시에 해결할 수 있도록 설계된 버전입니다. 하나의 스키마로 입력값 런타임 검증, Form 데이터 타입 추론, API 요청 및 응답 타입 일관성을 함께 관리할 수 있어, 프론트엔드 전반에서 단일 기준을 유지할 수 있습니다.

또한 React Hook Form과 결합했을 때 검증, 에러 관리, 조건별 Validation 로직이 선언적으로 정리되어 폼 규모가 커져도 구조가 복잡해지지 않습니다. 이러한 특성 덕분에 Zod 3.x는 서비스가 확장될수록 유지보수성과 데이터 일관성을 안정적으로 확보할 수 있는 선택지라고 판단했습니다.

---