팀 프로젝트를 시작하기 전에 설계 문서를 작성했는데, 단순히 기술을 나열하기거나 '사용해보고 싶은 기술'이라는 이유로 선택하기보다 여러 스택을 비교해보며 왜 이 구조가 서비스에 가장 적합한가를 끊임없이 고민했습니다. 기술은 결국 문제를 해결하기 위한 수단이라는 점을 다시 한 번 깨달았고, 앞으로도 모든 선택에 근거를 가지고 기술을 선택하는 개발자가 되고 싶다는 목표를 가지게 되었습니다.
0. 서비스 소개
개발하고 있는 서비스 튜닝은 조직 기반의 소셜 매칭 커뮤니티 플랫폼으로, 동일한 소속(학교, 회사, 부트캠프 등)을 기반으로 AI가 관심사가 비슷한 사람과 자연스럽고 신뢰할 수 있는 인연을 만들어주는 서비스입니다.
동일한 소속을 바탕으로 신뢰를 기반으로 한 자연스러운 만남을 유도하며, 단순한 매칭을 넘어서 뉴스 리포트 형태의 피드 콘텐츠로 매칭 결과를 콘텐츠화합니다. 기존 매칭 서비스의 진입장벽과 신뢰성 부족 문제를 해결하고, 소속 기반의 진정성 있는 관계 형성을 목표로 합니다.
1. Next.js 15.3.0
1-1. 서비스 주요 기능별 기술 설계
| 기능명 | 렌더링 방식 |
| 카카오 로그인 | CSR + API |
| 온보딩 (키워드 선택) | CSR |
| 메인 페이지 | CSR |
| 1:1 매칭 | CSR |
| 1:N 매칭 | CSR |
| 1:1 채팅방 | CSR (실시간) |
| 1:N 채팅방 | CSR (실시간) |
| 기사 리포트 (피드) | SSR |
| 채팅방 목록 | CSR |
| 프로필 수정 | CSR |
| 마이페이지 | CSR |
| 알림창 (기기 알림 포함) | CSR + Service Worker |
| 취향 선택 수정 | CSR |
👩🏻💻 사용하는 기술 설명
- SSR 적용 대상: 검색이 필요한 콘텐츠 (기사 리포트 피드) → SEO 최적화가 필요하기 때문에
- CSR 적용 대상: 사용자 상호작용 / 실시간성 / 입력 처리 중심 기능 (채팅, 매칭, 온보딩 등)
- 실시간 처리: WebSocket 기반의 이벤트 처리
- 알림: FCM + Service Worker로 브라우저 푸시 알림 연동
1-2. 선정 이유
- Tuning 서비스는 조직 기반 소셜 매칭 커뮤니티 플랫폼으로, 매칭된 사람들의 정보를 기사 형태로 보여주는 ‘매칭 리포트’를 중심으로 동적 피드 콘텐츠를 제공하는 서비스입니다. 기사는 사용자 반응과 키워드를 기반으로 생성되며, 검색 노출이 중요하기 때문에 더 많은 사용자 유입을 확보하려면 SSR 기반의 SEO 최적화가 필수적입니다.
- CSR 방식의 React는 초기 HTML이 비어있어 SEO에 매우 불리하지만, react-helmet을 사용해 페이지별 메타태그를 설정하거나, react-snap을 통해서 정적 프리렌더링을 구현함으로써 어느 정도 보완이 가능합니다.
(react-helmet으로 페이지별 SEO 메타태그 설정하기 / react-snap으로 pre-rendered 리액트 앱 만들기) - 하지만 이러한 방식은 모든 페이지에 일관된 SEO 최적화를 적용하기 어렵고, 빌드 시간이 늘어나며 복잡한 라우팅 구조나 사용자 인증 흐름과 호환이 떨어진다는 문제가 있습니다. 반면 Next.js는 SSR을 기본적으로 지원하며, 초기 HTML에 콘텐츠가 포함되어 검색엔진에 자연스럽게 노출됩니다. 특히 동적 피드 기반 콘텐츠에서는 훨씬 효율적인 SEO 대응이 가능해 유입 트래픽 확보에 아주 큰 장점이 됩니다.
1-3. 기술적 근거
1) 중첩 라우팅 구조에 적합한 App Router
회원가입 → 피드 → 채팅방 등 페이지 흐름이 복잡하고, 화면마다 별도의 상태 공유 및 접근 제어가 필요합니다. Next.js는 디렉토리 기반의 자동 라우팅 + layout.tsx 구조로 중첩 레이아웃을 체계적으로 분리할 수 있어 유지보수가 용이합니다.
2) 서버 컴포넌트를 통한 번들링 최적화
리포트 콘텐츠는 초기 로딩 성능이 중요합니다. Next.js는 서버 컴포넌트를 도입하기 때문에 클라이언트 번들 사이즈를 최소화하고, 특정 무거운 컴포넌트는 서버에서만 렌더링하면 성능 최적화에 유리합니다.
3) `middleware.ts`를 활용한 접근 제어
튜닝은 로그인한 사용자만 접근이 가능하고, 조직 기반 권한 구분이 있는 서비스 구조입니다. Next.js의 middleware.ts를 활용하면 로그인 상태나 사용자 정보에 따라서 페이지 단위로 서버 측에서 동적 리다이렉트 및 접근 제어를 처리할 수 있어 보안성과 확장성 모두 확보가 가능합니다.
1-4. Vite에서도 SSR을 구현할 수 있는데, Next.js를 사용해야 하는 이유는?
1) NextJS / Vite (with SSR) 비교하기
| 항목 | Next.js | Vite |
| 렌더링 방식 | CSR / SSR / SSG / ISR | CSR (SSR 직접 구성 필요) |
| 라우팅 구조 | 파일 기반 자동 라우팅, App Router 지원 | 라우팅 수동 설정 (React Router) |
| 페이지 단위 구성 | layout.tsx, 중첩 레이아웃, SEO 자동화 | 직접 구조 설계 필요 |
| SEO 친화성 | SSR 기반 SEO 최적화 편리 | SSR 구성 시 가능하지만 설정 복잡 |
| 서버 컴포넌트 지원 | React 18 서버 컴포넌트 공식 지원 | 공식 지원 없음 |
| 빌드 성능 / HMR 속도 | 보통 (Vercel 기준 최적화) | 매우 빠름 (ESM 기반 번들링) |
| 사용자 제어 수준 | 중간 (Next의 구조에 맞춰야 함) | 매우 높음 (자유롭게 설정 가능) |
| 복잡한 서비스 구성 | 권장 (로그인, 접근 제어, SEO 등 포함된 서비스) | SSR, 인증, SEO 등 모든 기능 수동 구현 필요 |
| 학습 곡선 | 낮음 (공식 문서/예제 풍부) | 높음 (구현 책임이 개발자에게 있음) |
2) Tuning 서비스에서 Next.js가 더 적합한 이유
| 항목 | 이유 |
| 다중 페이지 & 중첩 레이아웃 | 온보딩 → 피드 → 채팅방 / 마이페이지 등 사용자 흐름이 복잡한 구조에서, App Router를 활용한 중첩 레이아웃 관리가 효율적 |
| SEO 최적화 | 검색에 노출되어야 하는 매칭 리포트 등 주요 콘텐츠가 많아 SSR / SSG 기반의 SEO 최적화가 필수적 → Next.js는 이를 기본으로 지원함 |
| 폴더 구조 기반 구성 | 자동 라우팅과 레이아웃 분리가 가능해 협업과 유지보수가 편리함 |
| 서버 컴포넌트 지원 | 무거운 로직은 서버에서 처리하고, 클라이언트 번들 사이즈를 줄일 수 있어서 초기 로딩 성능 향상 가능 |
튜닝처럼 사용자 인증, SEO, SSR / CSR 혼합, 중첩 라우팅이 중요한 서비스에는 `Next.js`가 훨씬 더 안정적인 선택으로 보입니다. `Vite`는 빠르다는 장점이 있지만 SSR / 라우팅 / 보안 등 주요 기능을 직접 구현해야 하는 것에서 오는 러닝커브의 문제로 오히려 개발 부담이 느껴진다는 판단 하에 `Next.js`를 선정하게 되었습니다.
1-5. SSR 대신 SSG로 사용하는건 어떨까?
1) SSR vs SSG
| 항목 | SSR (Server Side Rendering) | SSG (Static Site Generator) |
| 렌더링 시점 | 사용자가 요청할 때마다 서버에서 HTML 생성 | 빌드 시 HTML 미리 생성 |
| 장점 | 항상 최신 데이터 반영 가능, 로그인 상태 기반 콘텐츠 처리 | 빠른 로딩 속도, CDN 캐싱 가능, 서버 부하 없음 |
| 단점 | 요청마다 렌더링 → 서버 부담 증가, 느릴 수 있음 | 빌드 시간 증가, 실시간 데이터 반영 어려움 |
| 적합한 페이지 | 유저 맞춤 데이터, 실시간 업데이트가 필요한 페이지 | 자주 바뀌지 않는 콘텐츠, 퍼블릭 공유용 페이지 |
2) Tuning 서비스에 SSG 적용이 적절한지?
| 페이지/기능 | SSG 가능 여부 | 이유 |
| 메인 피드 페이지 (리포트 리스트) | ❌ | 로그인 후 접근 가능, 실시간 반영이 필요함 → SSR 적합 |
| 리포트 상세 페이지 | ❌ | 로그인 기반 접근 + 매칭 직후 즉시 노출 필요 → SSR 적합 |
| 마이페이지 | ❌ | 로그인 사용자 맞춤 데이터 포함 → SSR 적합 |
→ 튜닝 서비스는 로그인 기반 실시간 콘텐츠가 중심이므로 우리 서비스에서는 `SSR`을 사용하는 것이 적합합니다.
1-6. SSR을 사용하는 가장 큰 이유 중 하나가 SEO 최적화인데, 로그인하지 않으면 내용을 볼 수 없는 페이지라면 검색 노출이 무슨 의미가 있을까?
우리 서비스는 조직 내부 매칭 서비스이고, 개인정보 유출 문제로 인해서 모든 페이지는 로그인 이후 열람이 가능합니다. 따라서 SEO 최적화를 해도 로그인으로 유도하는 플로우 자체가 번거롭고 트래픽에 좋지 않은 영향을 줄 수 있다고 하더라도 기획 상 수정은 어려울 것으로 생각합니다. 이러한 상황에서 SSR을 써서 얻을 수 있는 장점에 대해서 정리해보았습니다.
그럼에도 SSR을 쓰는 이유는?
1. 검색 엔진이 페이지 존재 여부는 파악할 수 있게 하기 위해서
- 게시글 전체 내용은 비공개더라도 페이지의 존재나 제목, 메타데이터는 노출할 수 있습니다.
- 사용자는 클릭했고 로그인 페이지로 리다이렉트되면 서비스 자체를 알릴 기회가 됩니다.
2. SNS 공유 / 오픈그래프 메타 태그용
- 카카오톡 / 디스코드 등에 공유하면 OG 태그를 읽어서 미리보기를 생성할 수 있습니다.
→ SSR이 없거나 비어있으면 잘못된 미리보기가 만들어져서 트래픽 유도와 클릭률에 영향을 줄 수 있습니다.
3. 부분 공개 전략
facebook, linkedIn 등 일부 서비스도 제목 + 썸네일만 SSR로 보여주고 본문은 로그인을 유도하는 방식을 사용합니다. SEO + 사용자 경험을 동시에 잡는데 도움이 되는 방식입니다.
1-7. Next.js 버전 선정 - 15.3.0
Next.js 버전 비교
| 항목 | Next.js 14 | Next.js 15.3.0 |
| React 지원 | React 18 | React 19 |
| Turbopack | 실험적 지원 | 개발 환경에서 안정화, 빌드 환경에서 알파 지원 |
| 비동기 요청 API | X | 도입됨 (cookies, headers 등 async 처리 가능) |
| 초기 렌더링 캐싱 | 기본 캐시됨 | 기본값은 no-store (캐시 x → 최신 데이터만 보여주는 방법) |
| 클라이언트 관측 도구 | 제한적 | instrumentation-client.js 도입 → 사용자 추적이나 UX 분석 도구 삽입 용이 |
| 캐싱 기본값 | 기본으로 캐시됨 (force-cache) | 기본으로 캐시되지 않음, no-store이 기본값 |
왜 15.3.0이 우리 서비스에 더 적합한가?
1. 리포트 피드의 실시간 반영과 캐싱 제어를 위한 최적의 버전
- Tuning은 매칭 직후 생성되는 리포트를 SSR로 즉시 보여주는 구조
→ 15.3.0은 초기 렌더링 캐싱 정책이 기본적으로 `no-store`이기 때문에 서버에서 최신 상태의 콘텐츠를 바로 렌더링하는 데 유리합니다.
2. 서비스 초기 운영에 필수인 빠른 빌드 및 개발 속도 확보
- `Turbopack`이 개발 서버에서 안정적으로 작동해 HMR 속도와 번들링 시간이 대폭 줄어듭니다.
→ 튜닝처럼 빠른 기획-피드백-반영 사이클이 필요한 서비스에 생산성 극대화 할 수 있습니다.
HMR (Hot Module Replacement): 코드 수정 시, 브라우저에서 새로고침 하지 않고도 변경된 부분만 빠르게 반영하는 속도
번들링 시간: 프로젝트의 모든 코드를 하나의 실행 가능한 파일로 합쳐서 배포가 가능한 형태로 만드는 데 걸리는 시간 (npm run build)
3. 클라이언트 단 사용 흐름 관찰을 위한 `instrumentation` 지원
- 채팅/매칭 등 다양한 유저 인터랙션이 있는 구조에서 `instrumentation-client.js`를 통해 클라이언트 측 이벤트를 추적하고 분석이 가능합니다. 따라서 사용자 행동 기반 기능 개선과 오류 추적이 용이합니다.
instrumentation-client.js: 클라이언트에서 발생하는 사용자 이벤트(클릭, 페이지 이동, 오류 등)를 추적할 수 있도록 도와주는 공식 추적 도구
1-8. React 19
React 18 vs React 19 비교하기
| 항목 | React 18 | React 19 |
| 지원 방식 | 안정화 LTS 버전 | 2025년 릴리즈, 최신 안정 버전 |
| 서버 컴포넌트 (RSC) | Experimental (Next.js 13+에서만 부분 지원) | 공식 안정화, 서버-클라이언트 경계 명확 |
| use 키워드 | Experimental | 공식 도입, Suspense와 함께 사용 가능 |
| 폼 핸들링 | 수동 상태 관리 (useState 위주) | Form Actions, useFormStatus 등 공식 지원 |
| useOptimistic | 없음 | 비동기 optimistic UI 공식 지원 |
| Strict Mode 개선 | 기본 제공 | 개선 및 use 효과 구간 명확화 |
| Transition | 지원 (useTransition) | 유지 |
| 렌더링 방식 | Client 중심 + Partial SSR | Server-first 구조 정착 (Next.js 15) |
React 19 주요 특징
1. 서버 컴포넌트(Server Components) 안정화
- React 18에서는 실험적 기능이었던 서버 컴포넌트(RSC)가 React 19에서 공식적으로 안정화되었습니다.
- 서버에서만 실행되는 로직을 클라이언트 번들에서 분리할 수 있어 초기 로딩 속도 개선 및 번들 크기 감소에 효과적입니다.
2. 폼 처리 기능 대폭 개선
- `useFormStatus`, `useFormState`, `formAction` 등의 기능이 새롭게 추가됩니다.
- 기존에는 `useState`, `onChange`, `onSubmit` 등 수동 처리로 관리하던 폼을 더 직관적으로 서버 액션 기반으로 구성할 수 있습니다.
- 특히 로그인, 온보딩, 키워드 수정 등 폼 기반 인터랙션이 많은 서비스에 적합합니다.
3. 비동기 상태에 대한 Optimistic UI 공식 지원
- `useOptimistic` 훅을 통해 서버 응답 전 optimistic UI를 안전하게 처리할 수 있습니다.
- 채팅 전송, 매칭 수락 등 사용자 반응이 빠르게 보여야 하는 UI에 유용합니다.
4. use 키워드의 공식 도입
- `const data = use(fetchData())`처럼 비동기 요청을 컴포넌트 내에서 직접 처리 가능합니다.
- Suspense와 함께 사용하면 로딩 상태를 더욱 세밀하게 제어할 수 있어 UX 개선에 효과적입니다.
'👩🏻💻 Develop > Document' 카테고리의 다른 글
| [설계 문서] Turbopack, Webpack 선정 이유 (0) | 2025.10.08 |
|---|---|
| [설계 문서] Axios 1.8.4 선정 이유 (0) | 2025.10.07 |
| [설계 문서] Zustand? Tanstack Query? 전역 상태 관리 라이브러리 선정하기 (0) | 2025.10.05 |
| [설계 문서] 서비스에 최적화된 TailwindCSS 4.0 선택하기 (0) | 2025.10.01 |
| [설계 문서] TypeScript를 선택한 이유 (vs JavaScript) (0) | 2025.09.29 |