영역	기술	선정 이유 요약
언어	TypeScript v5.9.3	화면/기능이 많아 데이터 구조가 복잡해지는 Devths에서 타입을 통해 필드 누락·타입 착각을 개발 단계에서 차단하고, 리팩토링과 협업 안정성을 높이기 위해 채택
라이브러리	React v19.2	캘린더/게시판/채팅처럼 상태 변화와 인터랙션이 많은 UI를 컴포넌트 단위로 분리해 관리하고, 상태 기반 UI 업데이트로 복잡도를 낮추기 위해 채택
프레임워크	Next.js 16	페이지 수가 많고(공통 레이아웃 반복), 로그인 전/후 분기와 에러 페이지가 중요한 구조에서 라우팅·레이아웃·에러 처리·SSR/SSG를 프레임워크 수준에서 표준화하기 위해 채택
전역 상태	Zustand v5.0.9	토스트/전역 모달/탭·필터 같은 UI 전역 상태가 많아 prop drilling을 줄이고, 필요한 상태만 선택 구독해 리렌더링 범위를 통제하기 위해 채택
서버 상태	TanStack Query v5.90.16	목록/검색/필터/무한 스크롤이 많고, 변경 후 갱신(invalidate) 흐름이 복잡해지는 Devths에서 캐싱·동기화·페이지네이션 패턴을 표준화하기 위해 채택
스타일링	Tailwind CSS v4.1	반복 UI와 상태별 스타일(선택/에러/비활성 등)이 많은 구조에서 JSX에서 빠르게 수정하고, config로 디자인 기준을 고정해 일관성을 유지하기 위해 채택
UI 컴포넌트	shadcn/ui	모달/드롭다운/탭 등 상호작용 UI를 프로젝트가 코드로 소유해 요구사항에 맞게 수정하고, 접근성 패턴을 기반으로 공통 UI를 표준화하기 위해 채택
캘린더 UI	FullCalendar v6.1.20	달력 특유의 뷰 전환·이벤트 배치·예외 케이스를 검증된 라이브러리로 커버하고, Devths 요구에 맞춘 커스텀 렌더링/상호작용 구현에 집중하기 위해 채택
패키지 관리	pnpm v10.27.0	의존성이 커질수록 설치 속도/디스크/CI 안정성이 중요해지는 팀 프로젝트에서 공용 저장소 기반 설치 효율과 lockfile 재현성을 확보하기 위해 채택
번들러/빌드	Turbopack	Next.js 기본 통합 흐름을 유지하면서 설정 부담을 줄이고, 규모 확장 시 개발 서버 체감 속도를 확보하는 선택지로 채택
유효성 검사	Zod v4.3.4	입력 화면과 규칙이 많은 구조에서 검증 정책을 스키마로 고정·재사용하고, TypeScript 타입 추론으로 검증 규칙과 타입 불일치 리스크를 줄이기 위해 채택
폼 처리	React Hook Form v7.70.0	회원가입/작성/수정 등 폼이 많은 프로젝트에서 폼 상태·제출·에러 처리를 표준화하고, Zod 검증 결과를 UI에 일관되게 연결하기 위해 채택
API 통신	Axios v1.13.2	OAuth 이후 공통 헤더/토큰 주입, 공통 에러 처리, 업로드 패턴 등을 인터셉터와 인스턴스로 중앙화해 네트워크 정책을 일관되게 운영하기 위해 채택
단위/컴포넌트 테스트	Vitest v4.0.16	UI 로직/검증/상태 전환 테스트를 빠르게 반복 실행하고, TS/React 테스트 생태계와 결합해 테스트 환경 운영 부담을 줄이기 위해 채택
컴포넌트 테스트 라이브러리	React Testing Library v16.3.1	구현이 아니라 사용자 관점(DOM 상호작용)으로 테스트를 작성해 리팩토링 내구성을 높이고, 접근성 기반 조회로 테스트 표준을 만들기 위해 채택
E2E 테스트	Playwright v1.57.0	랜딩→로그인→메인 진입 같은 핵심 사용자 시나리오를 실제 브라우저에서 검증하고, 자동 대기/트레이스 등으로 E2E 운영 안정성을 확보하기 위해 채택
실시간	STOMP + WebSocket	채팅/알림에서 필요한 재연결·폴백·룸 단위 메시징·ACK 패턴을 기본 제공해, 실환경 예외 처리 부담을 줄이고 안정적인 실시간 UX를 만들기 위해 채택

Devths는 취업 준비 사용자를 대상으로 일정(캘린더/To-Do) 관리, 게시판 기반 정보 탐색·작성·공유, 개인/그룹 채팅, AI 커리어 챗봇을 통한 자료 분석·상담, 알림, 프로필/팔로우 기능을 통해 취업 준비 과정을 한 곳에서 관리하고 실행할 수 있도록 도와주는 서비스이다.

(1) 캘린더

• 일정 조회/등록/수정/삭제 (월, 주 뷰)
• AI 자동 일정 삽입: 채용 공고 업로드 → AI로 추출 → 일정 초안 생성 → 사용자 확인 후 캘린더에 저장

(2) 게시판

• 글 목록/상세/작성/수정/삭제
• 댓글/좋아요/검색(필터)

(3) 챗봇/AI

• 이력서/포트폴리오/채용공고 등 입력 기반 답변 생성
• 면접 모드 (질문 생성/피드백)
• 대화 이력 관리 및 컨텍스트 기반 응답 제공

(4) 채팅

• 채팅방 목록/생성/참여/나가기
• 실시간 메시지 전송/수신, 읽음 처리
• 메시지 히스토리 로딩(무한스크롤) 및 파일/이미지 첨부

💡

Devths는 페이지가 많고(캘린더/게시판/채팅/챗봇/프로필/설정 등), 데이터 형태가 다양하며, 실시간 기능(채팅)과 AI 기반 비동기 처리(공고 업로드 → 추출 → 초안 생성)가 섞여 있는 서비스임

• 그래서 프론트엔드 기술 스택은 서비스 요구사항을 안정적으로 구현하고, 유지보수와 확장에 강한 조합인지 더 중요하다고 생각함

(1) 기능 적합성

• Devths는 단순 CRUD만 있는 서비스가 아니라, 캘린더/무한스크롤/실시간/파일업로드/AI 처리 흐름처럼 UI 요구가 복잡함
• 판단 기준
  • 실시간 이벤트(읽음/전송/입장 등) 처리를 안정적으로 붙일 수 있는가?
  • 비동기 데이터(조회/저장/재시도/캐싱) 처리가 표준화 가능한가?
  • 라우팅/레이아웃 구현이 쉬운가?

(2) 유지보수성

• 화면과 API가 늘수록 어디서 뭐가 바뀌는지 추적 비용이 발생함
• 판단 기준
  • 타입/인터페이스로 데이터 구조가 고정되는가? (필드 누락/타입 착각 방지)
  • 컴포넌트/상태/데이터 계층이 역할별로 분리되는가?
  • 폴더 구조/코딩 규칙을 일관되게 유지할 수 있는가?

(3) 성능

• 채팅(메시지 리스트), 게시판(목록), 캘린더(월/주 렌더링)는 렌더링 비용이 커서 성능 최적화가 체감됨
• 판단 기준
  • 무한스크롤/가상화로 긴 리스트 렌더링을 최적화할 수 있는가?
  • 데이터 캐싱/프리패치로 화면 전환 체감 속도를 개선할 수 있는가?
  • 번들 분리, 이미지 최적화, SSR/SSG 등 렌더링 전략을 적용하기 쉬운가?

(4) 안정성/예측 가능성

• 채팅, 알림, AI 결과 반영처럼 상태 변화가 많으면 버그가 늘어남
• 판단 기준
  • 전역 상태가 어떤 기준으로 저장/변경되는지 명확한가?
  • 서버 상태(비동기 데이터)와 클라이언트 상태(UI 상태)가 섞이지 않게 분리 가능한가?
  • 에러 처리/로딩 처리/재시도 정책을 일관되게 적용할 수 있는가?

• 정적 타입
  • 변수/함수/객체의 타입을 미리 정해두고, 코드 실행 전 컴파일 단계에서 타입 오류를 잡아줘서 런타임 에러를 줄여줌
• 강력한 IDE 지원
  • 타입 정보 덕분에 자동완성, 오타 감지, 함수 파라미터 안내, 안전한 리팩토링(변수명 변경 등)이 훨씬 정확해짐
• 코드 가독성과 협업에 유리
• 대규모 프로젝트에 강함

💡

Devths는 페이지/기능이 많고, 기능 간에 주고받는 데이터가 복잡해지는 서비스라서 TypeScript가 특히 효과적이라고 판단함

(1) API 응답/요청 데이터 구조가 많고 복잡함

• 유저(User), 게시글(Post), 댓글(Comment), 채팅 메시지(Message), 알림(Notification), 캘린더 이벤트(CalendarEvent) 등
• 각 데이터는 필드가 많고, 화면마다 필요한 필드도 다름
  • TypeScript로 타입을 정의해두면 필드 누락/오타/타입 착각을 컴파일 단계에서 차단 가능

(2) 폼 입력/검증과의 궁합이 좋음

• 로그인/회원가입, 프로필 수정, 게시글 작성, 파일 업로드 등 폼이 많음
  • 폼 데이터 타입을 명확히 해두면, 유효성 검증과 결합할 때 클라이언트에서 안정적으로 데이터 정리 가능

(3) 실시간 기능(채팅)에서 이벤트/페이로드 안정성이 중요함

• 채팅은 이벤트가 다양하고(전송/읽음/입장/나감 등) 페이로드 구조가 조금만 달라도 버그가 나기 쉬움

(4) 화면 수가 많아질수록 변경 영향이 커짐

• TypeScript는 어디가 깨졌는지 바로 표시해줘서 수정 범위를 빠르게 찾을 수 있음

(5) 협업관점에서 유용

• 타입이 곧 문서가 되기 때문에, 팀원들이 코드를 볼때 이 함수는 어떤 데이터를 받아서 어떤 형태로 돌려주는지를 빠르게 이해 가능
  • 커뮤니케이션 비용이 줄고 유지보수가 쉬워짐

• 흐름
  1. 서버(API)에서 일정 목록을 받음
  2. 프론트에서 그 데이터를 화면(UI) 컴포넌트에 넣어 렌더링함 (FullCalendar)
  3. 클릭/수정/삭제 같은 이벤트가 계속 발생함
• 문제
  • 데이터 구조가 틀리면 화면이 조용히 깨짐
    • 예를 들면 startAt을 start로 잘못 쓰면:
    • 화면에 일정이 안 뜨거나
    • 일정 시간대가 이상해지거나
    • 런타임에서 undefined 에러가 나거나

⇒ TypeScript 타입을 잡아둬서 코드 실행 전에 실수를 막음

• 흐름
  1. 사용자가 채팅방에 입장 → 서버와 실시간 연결(Socket.IO)
  2. 메세지 전송 시 클라이언트가 서버로 이벤트 emit
  3. 서버가 저장 후, 같은 방 사용자들에게 새 메시지 이벤트 broadcast
  4. 클라이언트는 수신한 메시지를 상태에 추가하고 화면에 렌더링
  5. 읽음 처리/입장,퇴장/파일 첨부 같은 이벤트가 추가로 계속 발생
• 문제
  • 실시간 기능은 ‘이벤트 이름 + 페이로드 구조’가 많아서, 조금만 틀려도 버그 발생 쉬움

⇒ TypeScript로 메시지 타입/룸 타입/소켓 이벤트 타입을 고정해서 보내는 데이터/받는 데이터를 코드 실행 전에 검증하고 실시간 버그를 줄임

항목	JavaScript	TypeScript
타입 검사 시점	실행 중 (런타임)	컴파일 단계
타입 안전성	낮음	높음
런타임 에러	발생 가능성 높음	사전 방지 가능
자동완성 / IDE 지원	제한적	매우 강력
리팩토링 안정성	규모 커질수록 위험	변경 영향 즉시 확인 가능
협업 효율	주석, 문서 의존	타입 자체가 문서 역할
대규모 프로젝트 적합성	낮음	높음

• 타입 검사 시점과 안정성

  • JS는 타입 검사가 코드 실행 중(런타임)에만 이루어지기 때문에, 잘못된 값이나 구조가 있어도 실제로 실행해 보기 전까지는 오류를 알기 어려움. 그 결과 런타임 에러가 발생할 가능성이 상대적으로 높음

    ↔️ TS는 컴파일 단계에서 타입을 검사해 잘못된 사용을 미리 차단하므로, 실행 중에 발생하는 오류를 사전에 방지할 수 있음

• IDE 지원 및 개발 효율

  • JS는 객체 구조나 함수의 입출력을 IDE가 정확히 알기 어려워 자동완성이 제한적인 경우가 많음

    ↔️ TS는 타입 정보를 기반으로 IDE가 정확한 자동완성과 오류 안내를 제공해 개발 효율을 크게 높여줌.

• 리팩토링 안정성

  • JS는 리팩토링 과정에서 프로젝트 규모가 커질수록 변경 영향 범위를 파악하기 어려워 위험이 커짐

    ↔️ TS는 타입 오류를 통해 수정이 필요한 지점을 즉시 알려줘 비교적 안전하게 구조 변경을 진행할 수 있음

• 협업 및 코드 가독성

  • JS는 협업할 때 주석이나 별도의 문서에 의존하는 경우가 많음

    ↔️ TS는 타입 정의 자체가 코드의 설명서 역할을 하여 다른 개발자가 코드를 이해하기 훨씬 수월함

• TypeScript v5.9.3
  • 2025년 10월 1일에 GitHub를 통해 릴리즈됨
• 특별하게 5.9.3 버전을 선택한 이유
  • Next.js, React 등 주요 프론트엔드 라이브러리 생태계에서 TypeScript 5.x 라인이 안정적으로 사용되고 있어, 프레임워크 및 라이브러리 간 충돌 위험이 낮다고 판단함
  • TypeScript는 동일 메이저 버전(5.x)을 유지하는 범위 내에서, 버그 수정과 안정성 개선이 반영된 패치 버전(v5.9.3)을 선택함
  • v5.9.3은 기존 문법과 타입 시스템의 동작을 변경하지 않으면서, 컴파일 안정성과 IDE 연동 품질 개선이 반영된 버전으로 평가됨

• Devths는 캘린더, 게시판, 채팅, AI챗봇처럼 화면과 기능이 많고, 기능 간에 주고받는 데이터가 복잡한 서비스임
• 따라서 TypeScript를 적용해
  • API 계약(요청/응답)과 도메인 모델(User/Post/Message/Event 등)을 타입으로 고정하고,
  • 폼 입력/검증 로직을 타입 기반으로 안정화하며,
  • 실시간 채팅의 이벤트/페이로드를 타입으로 강제해 오타, 누락, 형식 불일치로 인한 버그를 컴파일 단계에서 차단함
• 결과적으로 TypeScript는 Devths에서 런타임 오류를 줄이고, 변경에 강한 구조를 만들며, 협업 속도와 유지보수성을 높이는 기술로서 채택 가치가 큼

---

• 컴포넌트 기반 UI 개발
  • 화면을 Header/버튼/카드/리스트 같은 재사용 가능한 컴포넌트로 나눠 조립하듯 개발할 수 있어, 기능이 많고 화면이 많은 서비스에서 유지보수가 쉬움
• 컴포넌트 재사용을 통한 생산성
  • 버튼/모달/입력폼 같은 공통 UI를 한 번 만들어두면 여러 페이지에서 재사용 가능해서 개발 속도와 일관성이 높아짐
• 상태 기반 렌더링
  • 사용자 입력, API 응답, 실시간 메시지처럼 계속 변하는 데이터를 state로 관리하고, 그 변화가 곧 화면 업데이트로 연결됨
• 풍부한 생태계
  • 라우팅(React Router), 데이터 패칭(React Query), 폼(React Hook Form), 상태관리(Zustand) 등과 조합이 쉬워 기능 확장 빠름

💡

Devths는 페이지/인터랙션이 많고 데이터가 계속 바뀌는 서비스라서, React 컴포넌트/상태 기반 UI 방식이 맞음

(1) 기능별 화면이 많아도 컴포넌트로 쪼개서 관리 가능

• Devths는 캘린더, 게시판, 챗봇, 채팅처럼 도메인이 다른 화면이 여러 개 있음
• React는 화면을 작은 부품으로 쪼개서 재사용/조립하는 구조라서 유지보수에 강함
• 컴포넌트는 2-2에 작성

⇒ 이렇게 나누면 기능이 늘어나도 컴포넌트 단위로 수정하면 돼서 코드 덜 망가짐

(2) 상태가 바뀌면 화면이 자동으로 따라오는 구조가 필요함

• Devths는 상태 변화가 많은 서비스
  • 캘린더: 일정 추가/수정/삭제 → 즉시 화면 반영
  • 게시판: 무한스크롤로 글 계속 추가 → 리스트 UI 갱신
  • 챗봇: 답변 스트리밍/대화 누적 → 메시지 UI가 계속 늘어남
  • 채팅: 실시간 수신 메시지 → 화면에 바로 추가 + 스크롤 처리

⇒ Zustand만 잘하면 DOM을 직접 만지지 않아도 UI가 자동 갱신됨

(3) 성능 최적화 포인트가 많은 화면에 유리함

• Devths는 리스트가 긴 UI가 여러 개임
  • 게시판 글 목록 (무한 스크롤)
  • 채팅 메시지
  • 캘린더 이벤트
• React는 리스트를 컴포넌트로 관리하면서
  • 가상 스크롤(react-window)
  • 메모이제이션(useMemo, memo)
  • 키 기반 렌더링 최적화

⇒ 같은 방식으로 프론트 성능을 단계적으로 개선하기 좋음

• 캘린더
  • 월/주 뷰 전환
  • 일정 (날짜 클릭시 전체 → 일) 뷰 전환
  • 채용공고 OCR
    • 텍스트/이미지 업로드
    • 결과 초안 확인/수정 후 저장
    • 실패 시 재시도/수동 입력 전환
• 게시판
  • 무한 스크롤
  • 검색/필터/정렬 변경
  • 게시글 카드 클릭 → 상세 진입
  • 좋아요 토글 (즉시 UI 반영)
  • 댓글 작성/수정 삭제
  • 좋아요/공유
  • 게시글 작성(폼 입력 → 제목/본문/태그)
  • 이미지/파일 첨부
• 챗봇/AI
  • 채팅 목록/대화 시작 페이지
  • AI가 생성한 답변 보기
  • 면접모드 토글
  • 메시지 입력/전송
  • 답변 스트리밍
  • 대화 이력 스크롤/로드
• 채팅
  • 방 선택 → 방 진입
  • 새 방 만들기
  • 검색
  • 메시지 전송/수신
  • 과거 메시지 로딩
  • 읽음 처리. 입/퇴장 표시
  • 파일/이미지 첨부

• 캘린더
  • CalendarToolbar
    • 캘린더 상단 컨트롤 영역(월/주 뷰 전환, 이전/다음, 오늘 버튼, 채용 공고로 일정 만들기 버튼)
  • EventModal
    • 일정 생성/수정/삭제를 위한 폼 모달
    • 제목/시간/종일/장소/메모 입력 + 유효성 검증 + 저장/삭제 API 호출 연결
  • EventCard
    • 일정 리스트/상세에서 일정 한 개를 보여주는 카드(UI)
    • 제목/시간/장소/태그/색상 표시, 클릭 시 상세/수정 모달 오픈 트리거
  • OcrUploadModal
    • 채용공고(PDF/이미지) 업로드 모달
    • 파일 선택 → 업로드 요청 → “처리 중(대기)” 상태 표시 → 결과(draft) 도착 시 검토 화면으로 연결
• 게시판
  • PostList
    • 게시글 목록을 렌더링하는 리스트 컴포넌트
    • 무한스크롤 트리거, 로딩/에러/빈 상태 처리
  • PostCard
    • 목록에서 게시글 1개를 보여주는 카드(UI)
    • 제목/요약/작성자/작성일/좋아요/댓글 수/공유 수, 클릭 시 상세 이동
  • CommentList
    • 댓글 목록 + 댓글 작성 입력을 포함한 영역
    • 댓글 추가/수정/삭제 후 리스트 즉시 갱신, 낙관적 업데이트
  • LikeButton
    • 좋아요 토글 버튼(활성/비활성 UI)
    • 클릭 시 좋아요 API 호출 + 즉시 UI 반영(낙관적 업데이트) + 실패 시 롤백 처리
  • SearchFilter
    • 검색어 입력 + 정렬(최신순) 컨트롤
    • 변경 시 목록 쿼리 파라미터 갱신 → PostList 재조회 트리거
• 채팅
  • RoomList
    • 사용자가 참여한 채팅방 목록(최근 메시지, 안읽음 뱃지 포함)
    • 방 선택/검색/정렬, 선택 시 해당 방으로 라우팅 또는 상태 변경
  • MessageList
    • 특정 방의 메시지 목록을 렌더링(스크롤 영역)
    • 새 메시지 수신 시 상단 추가 + 자동 스크롤, 하단 스크롤 시 과거 메시지 로딩(무한스크롤)
  • MessageBubble
    • 메시지 1개의 말풍선 UI(내 메시지/상대 메시지 구분)
    • 시간/프로필/읽음 상태 표시
  • ChatInput
    • 메시지 입력창 + 전송 버튼 + 첨부 버튼
    • 엔터 전송, 전송 중 비활성화
• 공통
  • Header
    • 상단 네비게이션 바(로고/페이지 타이틀/알림/프로필 메뉴)
  • Modal
    • 공통 모달 UI(오버레이, ESC/바깥 클릭 닫기, 포커스 트랩 등)
  • Toast
    • 성공/실패/경고 알림을 짧게 보여주는 컴포넌트
    • “일정이 저장됐어요”, “업로드 실패, 다시 시도해주세요”
  • Avatar
    • 사용자 프로필 이미지 표시(없으면 이니셜/기본 아이콘)
    • 크기/모양 옵션 제공, 클릭 시 프로필 메뉴 트리거

항목	React	Vanilla JS	Vue
UI 구성 방식	컴포넌트 기반	DOM 직접 조작	컴포넌트 기반
상태 관리	상태(State) 중심	직접 상태 관리 필요	상태 중심
UI 복잡도 대응	높음	복잡해질수록 어려움	높음
생태계/확장성	매우 풍부	제한적	풍부
대규모 프로젝트 적합성	높음	낮음	높음

• UI 구조 및 복잡도 관리

  • Vanilla JS는 DOM을 직접 조작하는 방식이기 때문에, 화면 상태가 많아질수록 DOM 조작 코드와 상태 관리 로직이 서로 얽혀 구조가 빠르게 복잡해짐. → 화면 수와 기능이 증가할수록 유지보수 비용이 커질 가능성이 높음

    ↔️ React는 컴포넌트 기반 구조와 상태 중심(State) UI 모델을 제공하여, 화면과 로직을 기능 단위로 관리할 수 있어 UI 복잡도가 높은 서비스에 더 적합함

• 상태 관리 방식과 UI 업데이트 흐름

  • Vanilla JS는 상태 관리와 UI 업데이트 흐름을 개발자가 직접 설계해야 하므로, 무한 스크롤, 모달 열림/닫힘, 실시간 데이터 반영과 같은 요구사항이 많아질수록 구현 방식이 화면마다 달라질 위험이 있음

    ↔️ React는 상태 변화에 따라 UI가 자동으로 갱신되는 선언형 방식으로, 상태와 UI 간의 관계를 명확하게 유지할 수 있음

• 프레임워크, 생태계 연계성

  • Vue 역시 컴포넌트 기반 구조와 상태 중심 UI를 제공하는 강력한 프레임워크이지만, devths는 Next.js 기반 구조와의 궁합, React 생태계(상태 관리, 서버 상태 관리, UI 라이브러리 등)를 폭넓게 활용할 필요가 있는 프로젝트임

    ↔️ React는 Next.js를 비롯한 프레임워크 및 라이브러리 생태계와의 연계성이 높아,장기적인 확장성과 기술 스택 일관성 측면에서 유리하다고 판단함

• 대규모 프로젝트 및 팀 협업 적합성

  • 대규모 프로젝트 관점에서, Vanilla JS는 프로젝트 규모가 커질수록 구조 관리가 어려워지는 반면, React와 Vue는 컴포넌트 기반 설계를 통해 대규모 UI를 체계적으로 관리할 수 있음

    ↔️ 이 중 React는 커뮤니티와 레퍼런스, 확장 생태계가 매우 풍부하여 팀 프로젝트 환경에서 문제 해결과 기술 확장이 상대적으로 수월함

• React 19.2
  • 2025년 10월 1일에 릴리즈된 안정(stable) 버전
• 18 버전이랑 달라진 점
  • 비동기 작업 처리 방식이 훨씬 단순해짐: Action 중심
    • 18: 버튼마다 로딩/실패/완료 관리를 직접 챙겨야 했음
    • 19: 폼/버튼에서) Action 함수를 중심으로 React가 pending(진행 중) 상태와 Action 결과(state)를 다룰 수 있는 표준 훅/흐름을 제공해서, 로딩 표시·버튼 비활성화·결과 메시지 연결이 훨씬 단순해짐 (<form action>, useActionState, useFormStatus)
• Devths에서 Action이 특히 도움되는 곳
  • OCR 업로드: 업로드 → 분석 중 → 결과 받기/실패
  • 일정 저장: 저장 중 → 완료/실패
  • 게시글 작성: 등록 중 → 완료/실패
  • 채팅 전송: 전송 중 → 완료/실패
  • 챗봇 질문: 답변 생성 중 → 완료/실패

⇒ 로딩 표시, 버튼 비활성화, 에러/성공 메시지 같은 것을 일관되게 만들기 쉬워짐

• Devths는 캘린더(OCR 기반 일정 자동 생성), 게시판(무한 스크롤/좋아요/댓글), 챗봇(AI 응답 스트리밍), 채팅(실시간 송수신/읽음/첨부)처럼 상태 변화와 인터랙션이 많은 기능이 핵심인 서비스임
• 따라서 컴포넌트 기반으로 UI를 분리하고, 상태 변화에 따라 화면이 자동으로 갱신되는 React의 방식이 서비스 구조에 가장 적합하다고 판단함
• 또한 Devths에서 필요한 다양한 기능(라우팅, 서버 상태 관리, 폼 처리, 상태관리, UI 컴포넌트)을 생태계 도구들과 자연스럽게 결합할 수 있어 확장성과 유지보수성이 높음
• 특히 React 19.2는 Action 중심 비동기 처리 패턴을 통해 업로드/저장/전송처럼 반복되는 요청 UI를 일관된 형태로 구현하기 쉬워, 프로젝트 전반의 코드 중복과 버그 가능성을 줄일 수 있음

---

• React 기반 풀스택 프레임워크
  • React UI 개발에 더해, 라우팅/빌드/배포/최적화 같은 앱 운영에 필요한 것들을 프레임워크가 표준으로 제공함
• 파일 기반 라우팅 + 레이아웃 시스템 (App Router)
  • 폴더 구조가 URL 구조가 되고, layout.tsx로 공통 레이아웃을 분리 가능
  • 페이지 수가 많고 공통 레이아웃이 반복되는 서비스에서 구조가 갈끔하게 유지됨
• 렌더링 전략 선택 가능 (CSR/SSG/SSR)
  • 페이지 성격에 따라 섞어서 구성 가능
• 성능 최적화 기본 제공
  • 코드 스플리팅, 프리패칭, 이미지 최적화 등 기본 최적화 기능이 내장되어 초기 성능을 끌어올리기 쉬움
• 에러/로딩/Not Found 처리 패턴 제공
  • loading.tsx, error.tsx, not-found.tsx 같은 파일로 상태 UI를 표준 방식으로 관리 가능
  • 화면이 많아져도 UX를 일관되게 유지하기 좋음

💡

Devths는 랜딩 페이지는 SSG, 로그인 이후 앱 영역(캘린더/게시판/챗봇/채팅)은 CSR로 운영하는 구조이기 때문에, Next.js가 제공하는 페이지 성격별 렌더링 전략 + 앱 구조 표준화가 특히 유리함

(1) 랜딩은 SSG로 빠르게 제공해야 함

• 랜딩은 서비스 소개/시작하기 목적이라 콘텐츠가 비교적 고정적이며, 첫 진입 속도가 중요함
  • Next.js는 페이지 단위로 SSG를 적용해 정적 HTML을 미리 생성할 수 있어 초기 로딩을 빠르게 만들기 좋음

(2) 로그인 이후 페이지는 CSR

• 캘린더/게시판/채팅/챗봇은 사용자별 데이터와 실시간 인터랙션이 핵심이라, 화면이 계속 변하고 상태 관리가 중요함
  • Next.js는 CSR 기반의 React 앱을 그대로 구성할 수 있고, 라우팅/레이아웃/코드 스플리팅 같은 앱 구조를 프레임워크 규칙으로 유지할 수 있음

(3) 화면이 많을수록 ‘라우팅/레이아웃 표준’이 중요해짐

• Devths는 도메인이 여러 개(캘린더/게시판/챗봇/채팅)라 공통 레이아웃과 접근 제어(로그인 전/후)가 반복됨
  • Next.js(App Router)는 layout, loading, error 같은 표준 파일로 공통 UI와 상태 UI를 구조적으로 관리할 수 있어 확장 시 규칙이 흔들리지 않음

(1) SSG (Static Site Generation)

💡

빌드 시점에 페이지 HTML을 미리 만들어두고, 사용자가 요청하면 그 정적 HTML을 그대로 빠르게 제공하는 방식

• 빌드/배포 시점에 서버가 HTML을 미리 생성해두고, 사용자는 만들어진 정적 HTML을 그대로 받는 방식
• 사용자는 요청하자마자 완성된 화면을 빠르게 보게 됨
• 장점
  • 미리 만들어둔 HTML을 바로 제공하므로 첫 로딩이 매우 빠르고, 서버 부담/비용이 낮음
    • HTML이 완성된 상태라 SEO/공유 미리보기(OF)에도 유리해 랜딩/소개 페이지에 적합함
• 단점
  • 빌드 이후 내용이 바뀌면 즉시 반영되지 않아서, 변경 사항을 반영하려면 재빌드/재배포(또는 ISR 같은 보완 전략)가 필요함

Devths

• SSG가 필요한 페이지/컴포넌트

• 페이지: 랜딩 페이지

(2) CSR (Client-Side Rendering)

💡

서버는 보통

빈 HTML(껍데기) + JS 파일

을 주고,

브라우저가 그

JS를 다운로드/실행해서 화면을 렌더링

하는 방식

• 서버는 빈 HTML + JS를 내려주고, 브라우저가 JS를 실행해 화면을 렌더링하는 방식
• 사용자는 JS 로딩 후 데이터(API)를 받아 화면이 완성됨
• 장점
  • 사용자별 데이터/실시간 인터랙션이 많은 페이지에 유리함
  • 상태 변화에 따라 UI를 자주 갱신해야하는 앱에서 구조가 단순하고 유연하게 구현 가능함
• 단점
  • 초기 로딩 시 JS 다운로드, 실행이 필요해서 첫 화면이 늦게 뜰 수 있고, SEO(검색 노출) 측면에서 불리할 수 있음

CSR이 필요한 페이지/컴포넌트

• 페이지: 캘린더, 게시판, 챗봇, 채팅, 프로필
• 컴포넌트
  • 캘린더
    • FullCalendar(월/주/일 전환, 클릭, 드래그)
    • EventModal(폼 입력/저장)
    • OcrUploadModal(업로드→처리중→결과 반영)
  • 게시판
    • PostList(무한스크롤)
    • LikeButton(즉시 토글/낙관적 업데이트)
    • CommentList(추가/수정/삭제)
    • WriteForm(입력/첨부)
  • 챗봇/AI
    • ChatThread(대화 누적)
    • StreamingAnswer(스트리밍 출력)
  • 채팅

    • RoomList(안읽음 뱃지 갱신)

    • MessageList(실시간 수신 + 과거 로딩)

    • ChatInput(전송/첨부)

      ➡️ 공통 특징: 사용자 입력/서버 요청/실시간 이벤트로 상태가 계속 바뀜

(3) SSR (Server-Side Rendering)

💡

요청이 들어올 때마다 서버가 HTML을 먼저 렌더링해서 내려주는 방식

• 요청이 들어올 때마다 서버가 HTML을 먼저 렌더링해서 내려주는 방식
• 사용자는 완성된 화면을 더 빨리 보게 됨
• 장점
  • 첫 화면이 빠르게 보일 수 있고, 서버가 요청 시점의 최신 데이터로 HTML을 만들어서 전달할 수 있어서 초기 UX와 최신성이 중요한 페이지에 유리함
• 단점
  • 요청마다 서버가 렌더링/데이터 패칭을 해야해서 서버 부하와 비용이 증가할 수 있고, 캐싱/인증/에러 처리 등 구현 복잡도가 올라갈 수 있음

Devths는 랜딩을 제외하면 로그인 후 사용자별 데이터 + 실시간 인터랙션이 핵심이라, SSR의 장점(공개 페이지 SEO, 첫 화면 완성)이 크게 필요하지 않음 → 대신 서버 부하, 인증/캐시/에러 처리 복잡도만 늘 수 있어서 맞지 않음

(4) ISR (Incremental Static Regeneration)

💡

처음엔 SSG처럼 정적 HTML로 빠르게 제공하되, 설정한 시간(또는 조건)마다 서버가 백그라운드에서 페이지를 다시 생성해 최신 내용으로 갱신하는 방식

• SSG처럼 HTML을 미리 만들어두되, 설정한 주기마다 서버가 페이지를 다시 생성해서 정적 페이지를 업데이트하는 방식
• 사용자는 대부분 정적 HTML을 빠르게 받고, 일정 시간이 지나면 내용이 자동으로 최신으로 갱신됨
• 장점
  • SSG의 빠른 로딩/낮은 서버 부담을 유지하면서도, 공지/배너/랭킹처럼 가끔 바뀌는 콘텐츠를 자동으로 업데이트할 수 있어 성능과 최신성을 균형있게 가져갈 수 있음
• 단점
  • 즉시 최신은 아니고, 주기 전까지는 이전 내용이 보일 수 있음.
  • 또한 재생성 타이밍/캐시 정책을 잘못 잡으면 데이터 갱신이 예상과 다르게 느껴질 수 있음

Devths의 핵심 페이지들은 로그인 기반 개인화 + 실시간/즉시 반영 데이터라서, 공개 정적 페이지를 주기적으로 갱신하는 ISR의 강점을 거의 못 씀 → 대신 갱신 지연/중복 구현이 생길 수 있음

(1) App Router

• /app 폴더 기반으로 라우팅되는 Next.js의 최신 라우터
• layout.tsx로 공통 레이아웃을 폴더 단위로 기본 제공하고, loading.tsx / error.tsx / not-found.tsx로 상태 UI를 표준 파일로 분리할 수 있음
• Route Group으로 URL은 유지하면서 폴더 구조만 목적별로 분리 가능
  • (marketing) : 랜딩(SSG)
  • (app) : 로그인 이후 모든 페이지(CSR)
• 장점
  • Devths처럼 공통 레이아웃(헤더/사이드바)이 많은 서비스에서 구조가 깔끔해짐
  • 랜딩(SSG)과 로그인 후 앱(CSR) 영역을 폴더 구조로 명확히 나눠 팀 규칙을 유지하기 쉬움
  • 로딩/에러 UI를 표준 방식으로 관리할 수 있어 페이지가 늘어나도 UX가 일관됨
• 단점
  • 기본 개념(서버/클라이언트 컴포넌트 분리, use client, 폴더 규칙 등)이 Pages Router보다 낯설어서 초기 학습 비용이 더 큼
  • 잘못 설계하면 클라이언트로만 쓸 건데도 use client 범위가 커져 장점이 약해질 수 있음

Devths는 랜딩 SSG + 로그인 후 CSR 앱 구조라서, App Router의 레이아웃/라우팅 표준화 + 마케팅/앱 영역 분리(Route Group) 장점을 그대로 활용하기 좋음 → 화면 수가 늘어도 구조 규칙이 흔들리지 않음

(2) Page Router

• /pages 폴더 기반의 전통적인 Next.js 라우터
• 파일이 곧 URL이며, 데이터 패칭은 getStaticProps/getServerSideProps 같은 페이지 함수 중심으로 구성됨
• 장점
  • 개념이 단순해서 Next.js를 처음 쓰는 팀에게 진입장벽이 낮음
  • “페이지 단위로 SSR/SSG”가 직관적이라 빠르게 구현하기 쉬움
• 단점
  • Devths처럼 공통 레이아웃이 많고 페이지가 많은 서비스에서 레이아웃/상태 UI(로딩/에러) 패턴을 일관되게 유지하려면 팀이 규칙을 더 많이 직접 정해야 함
  • 랜딩(SSG)과 앱(CSR)을 구조적으로 분리하더라도, App Router만큼 “폴더 단위 레이아웃/상태 UI 표준”이 강하지 않아 규모가 커질수록 관리 난이도가 올라갈 수 있음

Devths에서도 Pages Router로 구현은 가능하지만, 화면이 늘어날수록 레이아웃/에러/로딩 규칙을 팀이 직접 관리해야 하는 비중이 커짐

→ 장기적으로는 구조 일관성 유지 비용이 더 들 수 있음

항목	Next.js	Vite + React
라우팅	파일 기반 라우팅 내장	직접 구성 필요
SSR/SSG	기본 지원	직접 구성
레이아웃 관리	layout 구조 제공	직접 설계
에러 페이지 처리	내장(error/not-found)	직접 구현
프로젝트 확장성	높음	설계에 따라 편차

• 라우팅/페이지 구조 관리

  • Vite + React는 기본적으로 라우팅이 내장되어 있지 않아, React Router 등 외부 라우터를 붙이고(중첩 라우팅, 인증 가드, 리다이렉트 규칙 포함) 프로젝트에서 직접 설계해야 함.

  • 페이지 수가 늘어날수록 라우팅 규칙 + 폴더 구조 + 레이아웃 적용 방식이 팀 컨벤션에 의존하게 되어 구조가 흔들릴 가능성이 커짐

    ↔️ 반면 Next.js는 파일 기반 라우팅이 내장되어 있어, 폴더 구조가 곧 URL 구조로 연결되고 라우팅 규칙이 자연스럽게 표준화됨. 따라서 페이지가 많아져도 구조를 일관되게 유지하기에 유리함

• SSR/SSG 도입 비용과 운영 확장성

  • Vite + React는 기본이 SPA 중심이므로 SSR/SSG가 필요해질 경우(랜딩 페이지의 초기 로딩, 공유/검색 노출 등) 별도 프레임워크/구성(예: SSR 서버 구성, 라우팅/빌드 파이프라인 재설계)을 추가해야 할 수 있음

  • → 변경 비용 발생

    ↔️ 반면 Next.js는 SSR/SSG를 프레임워크가 기본 제공하므로, 화면 특성에 따라 렌더링 방식을 선택하기 쉽고, 향후 요구사항 변화(랜딩 최적화 등)에 대응하는 비용이 상대적으로 낮음

• 공통 레이아웃 관리 방식

  • Vite + React에서는 Header/Footer 같은 공통 레이아웃을 적용하려면 라우터 중첩 구조나 레이아웃 컴포넌트 적용 규칙을 프로젝트에서 직접 설계해야 함.

  • 화면이 많아질수록 어떤 페이지에 어떤 레이아웃이 적용되는지가 복잡해짐

    ↔️ 반면 Next.js(App Router)는 layout 구조가 프레임워크 레벨에서 제공되기 때문에 공통 레이아웃을 표준 방식으로 적용할 수 있고, 페이지 증가 시에도 레이아웃 관리가 안정적으로 유지됨

• 에러 페이지 및 라우팅 정책의 표준화

  • Vite + React는 404/500 처리, 에러 바운더리 구성, 라우팅 실패 처리 등을 프로젝트에서 직접 설계해야 하므로, 화면별 처리 방식이 달라지거나 누락될 위험이 있음.

  • 특히 인증 흐름(로그인 전/후 분기), 잘못된 경로 접근, 서버 오류 대응 같은 정책성 라우팅이 많아질수록 관리 비용이 증가함

    ↔️ 반면 Next.js는 not-found.tsx, error.tsx 등 에러 처리 구조가 내장되어 있어, 에러 대응을 라우팅 정책의 일부로 표준화하기 쉽고 운영 품질을 일정하게 유지하기 유리함

• 프로젝트 확장 시 누적 비용(설계 부담)

  • Vite + React는 시작이 가볍지만, 서비스가 커질수록 라우팅/SSR/레이아웃/에러 처리 같은 앱의 골격을 팀이 계속 책임져야 함.

  • 이 누적 비용이 커지면 개발 속도가 떨어지고, 구조가 복잡해지며, 유지보수 리스크가 증가할 가능성이 있음.

    ↔️ 반면 Next.js는 이러한 골격을 프레임워크가 표준화해 제공하므로, 팀은 Devths의 핵심 기능(캘린더/게시판/채팅/알림 등) 구현에 더 집중할 수 있고, 결과적으로 확장성과 유지보수 측면에서 유리한 선택이 됨

• Next.js 16
  • 2025년 10월 21일 릴리즈
• 특별하게 16 버전을 선택한 이유
  • 15버전과 다른 점
    • Turbopack 개발뿐 아니라 프로덕션 빌드까지 안정 + 기본 번들러가 됨
      • 15: Turbopack은 dev 안정화 중심
      • 16: dev + build까지 안정화되어 빌드/리프레시 성능 개선 기대
    • 라우팅/프리패치(페이지 전환) 최적화 강화
      • Next(App Router)는 페이지 이동할 때 공통 레이아웃(헤더/사이드바 등)은 재사용하고, 변경되는 페이지 영역만 새로 로드해 전환을 더 빠르게 느끼게 함
      • 그리고 미리 가져오기(프리패치)도 필요한 범위만 점진적으로 가져와서 불필요한 다운로드를 줄이고 네트워크 낭비를 감소시킴
        • 15버전에서는 공통 레이아웃이 중복 다운로드될 수 있었음
• Devths에서 16버전이 더 나은 이유
  • 랜딩(SSG) + 로그인 후 (CSR) 구조에서, 페이지 전환이 잦은 앱 영역에서 공통 레이아웃 재사용 + 프리패치 최적화가 체감 성능을 올려줌
    • 헤더/푸터가 고정된 화면을 여러 페이지가 공유하는 서비스일수록 중복 다운로드를 줄이는 개선 효과가 큼
  • 화면/컴포넌트 수가 많아질수록 개발 중 수정이 잦은데, Turbopack이 dev뿐 아니라 build까지 안정화되면서 로컬 개발 반영 속도와 배포 빌드 속도 측면에서 개발 효율이 좋아짐

• Devths는 랜딩은 SSG, 로그인 이후 영역은 CSR로 운영되는 구조이며, 캘린더/게시판/챗봇/채팅처럼 페이지 수와 공통 레이아웃(헤더/푸터)이 많은 서비스임
• 라우팅, 레이아웃, 로딩/에러 UI 같은 앱의 골격을 프레임워크 차원에서 표준화해주는 Next.js(App Router)가 구조를 안정적으로 유지하는 데 적합함
• 또한 Next.js 16은 Turbopack의 빌드 안정화와 라우팅/프리패치 최적화 강화로, 개발, 배포 과정의 효율과 페이지 전환 체감을 개선할 수 있어 Devths의 SSG + CSR 전략과 잘 맞음

---

• 가볍고 단순한 전역 상태 관리
  • Redux처럼 보일러플레이트가 많지 않고, 필요한 상태만 빠르게 전역으로 올려 관리할 수 있음
• Hooks 기반 API로 사용이 직관적
  • useStore() 형태로 컴포넌트에서 바로 상태를 읽고/변경할 수 있어 React 개발 흐름과 잘맞음
• 선택 구독(Selector)로 불필요한 리렌더링 감소
  • 컴포넌트가 필요한 상태만 선택애서 구독할 수 있어, 상태가 자주 바뀌는 화면(채팅/알림 등)에서도 성능 관리가 쉬움
• 상태와 액션을 한 파일에 응집
  • 상태(state)와 상태 변경 함수(action)를 가까이 두고 관리할 수 있어 어디서 상태가 바뀌는지 추적이 쉬움
• 미들웨어 지원
  • persist(로컬 저장), devtools(디버깅), subscribeWithSelector 등 확장 기능을 붙여 요구사항에 맞게 구성 가능

💡

• Devths는 캘린더·게시판·채팅·챗봇처럼 기능이 많고, 페이지를 넘나들며 공유해야 하는 상태가 많음.
  • React의 useState만으로도 상태 관리는 가능하지만, 전역으로 공유되는 상태를 페이지/컴포넌트마다 props로 전달하면 구조가 복잡해지고 유지보수가 어려워짐.
  • 따라서 Devths에서는 Zustand로 앱 전체에서 공유되는 상태를 한 곳에서 일관되게 관리할 필요가 있음.

(1) 로그인/유저 정보처럼 앱 전역에서 참조되는 상태가 존재함

• 헤더(프로필 표시), 게시판(작성자 정보), 채팅(발신자/권한), 챗봇(개인화) 등 여러 화면에서 동일한 유저 정보가 필요함

  → me, isLoggedIn 같은 값을 전역으로 두면 중복 조회/props 전달을 줄이고 UI 일관성을 유지할 수 있음

(2) 전역 UI 상태(모달/토스트/로딩)를 일관되게 제어해야 함

• 예: 채용공고 업로드 후 OCR 처리 시 “대기 모달”, 처리 실패 시 “에러 토스트”, 완료 시 “결과 검토 모달” 등

  → 전역 UI 상태를 Zustand로 관리하면 어느 페이지에서든 동일한 UX 패턴으로 열고 닫을 수 있음

(3) 채팅처럼 상태 변화가 잦은 기능에서 성능/구조 관리가 중요함

• 채팅 메시지/읽지 않은 수/연결 상태는 매우 자주 바뀌며, 잘못 관리하면 화면 전체가 불필요하게 리렌더링될 수 있음

  → Zustand의 Selector(선택 구독) 를 활용하면 필요한 컴포넌트만 상태를 구독하게 만들어 성능을 안정적으로 유지할 수 있음

(4) 기능이 확장될수록 “상태 변경 위치”를 추적하기 어려워짐

• 일정 추가, 좋아요 토글, 채팅 수신 등 상태 변경이 여기저기서 발생하면 원인 추적이 어려움

  → Zustand는 상태와 액션을 한 스토어에 응집시켜 변경 경로를 단순화하고 디버깅을 쉽게 함

(5) 미들웨어로 Devths 요구사항을 빠르게 충족 가능함

• persist: 로그인 상태/사용자 설정을 로컬에 저장해 새로고침에도 유지

• devtools: 상태 변화 추적(버그 재현/원인 파악)

• subscribeWithSelector: 특정 상태 변화에만 반응(예: unreadCount 변할 때만 뱃지 업데이트)

  → “추가 구현” 없이도 핵심 UX를 빠르게 안정화할 수 있음

(1) Zustand에 올릴 상태

• 인증/유저

  • isLoggedIn (로그인 여부)
  • me (내 유저 정보: id, name, avatarUrl 등)

• 전역 UI 상태 (페이지가 달라도 동일 UX)

  • 전역 모달 상태
  • 토스트
  • 공통 다이얼로그: 확인/취소 모달 상태
  • 레이아웃 상태

  ⇒ 페이지 상관없이 뜨는 UI는 한 곳에서 제어하는 게 깔끔함

• 채팅 (실시간 UI 중심)

  • activeRoomId (현재 보고 있는 방)
  • socketStatus (connected / reconnecting / disconnected)

  ⇒ 실시간 UI는 빠르게 상태 반영이 중요하고, 여러 컴포넌트(방 목록/채팅창)에서 동시에 씀

• 사용자 설정

  • 캘린더 뷰 설정(월/주 기본값), 필터(태그/카테고리) 기본값

  ⇒ 새로고침/재접속에도 유지되면 UX가 좋아서 persist랑 궁합 좋음

(2) 로컬(useState)로 두는 게 좋은 상태 (한 화면/한 컴포넌트 전용)

• 폼 입력값
  • 로그인/회원가입 폼 값
  • 글 작성 폼 값(제목/본문/태그 입력 중)
  • 프로필 수정 폼 값

항목	Zustand	Jotai	Recoil	Redux Toolkit	React Context
설정 복잡도	매우 낮음	낮음	보통	비교적 높음	낮음(단, 구조 설계는 필요)
보일러플레이트	적음	적음	보통	많음	없음
전역 상태 관리 적합성	높음(UI 상태에 특히 강함)	높음(상태를 잘게 쪼개기 좋음)	높음(파생/의존 상태에 강점)	매우 높음(표준화·규모에 강함)	중간(간단한 전역 공유에 적합)
리렌더링 제어	우수(선택 구독)	우수(atom 단위)	우수(의존성 기반)	우수(셀렉터/메모화 등 조합)	까다로움(Provider 값 변경 시 영향 큼)
Devths 적합도	UI 전역 상태에 최적	UI 상태/간단 전역도 가능, atom 관리 규칙 필요	상태 관계가 복잡할 때 유리, 구조가 커지면 설계 부담	규모 대비 다소 무거울 수 있음(규칙·코드량 증가)	상태 많아지면 리렌더링/구조 관리가 어려움

• UI 전역 상태의 표준화(Prop Drilling 방지)

  • Redux Toolkit은 전역 상태를 체계적으로 관리할 수 있지만, 액션/슬라이스/디스패치 등 전역 상태 운영을 위한 구조를 먼저 잡아야 해서 UI 상태(토스트, 모달, 탭) 중심의 요구에서는 초기 코드량과 운영 규칙이 빠르게 늘어날 수 있음.

  • 화면이 많아질수록 상태 추가 자체의 부담이 커지고, 단순 UI 상태에도 패턴을 과하게 적용할 가능성이 있음

    ↔️ 반면 Zustand는 스토어 하나에 상태와 업데이트 함수를 함께 두는 방식으로 UI 전역 상태를 빠르게 표준화할 수 있어, Devths처럼 토스트/전역 모달/탭 활성/필터 열림 등 “공유 UI 상태”가 많은 서비스에서 구현 방식이 흔들리지 않도록 만들기 유리함.

• 리렌더링/성능 관리의 실용성

  • React Context는 도입이 간단하지만, Provider의 value가 바뀌면 하위 컴포넌트가 넓게 영향을 받기 쉬워(구조에 따라) 상태가 많아질수록 리렌더링 범위를 예측·통제하기가 어려워질 수 있음.

  • 특히 전역 UI 상태가 자주 바뀌는 경우(토스트 큐, 모달 열림/닫힘, 탭 전환) 성능 이슈로 이어질 가능성이 있음

    ↔️ 반면 Zustand는 “필요한 상태만 선택해서 구독”하는 방식이 기본이라, 실제로 사용 중인 값이 바뀔 때만 리렌더링되도록 구성하기 쉽고, UI 상호작용이 많은 Devths에서 체감 성능과 구현 난이도 사이의 균형이 좋음

• 팀 개발/유지보수 관점의 누적 비용

  • Recoil/Jotai는 atom 단위로 상태를 쪼개기 쉬워 유연하지만, 프로젝트가 커질수록 atom 설계/명명/의존 관계(파생 상태 포함)에 대한 팀 규칙이 필요해지고, 관리 기준이 약하면 상태가 분산되어 어디에 뭐가 있는지 추적 비용이 커질 수 있음

    ↔️ 반면 Zustand는 ‘UI 전역 상태는 이 스토어(또는 몇 개 스토어)에서 관리한다’처럼 책임 범위를 명확히 잡기 쉬워, 화면 수가 늘어도 상태 위치와 변경 지점을 찾는 비용이 상대적으로 낮고, Devths의 UI 전역 상태 운영에 더 적합하다고 판단함

• v5.0.9
  • 2025년 11월 30일에 릴리즈
• 이유
  • React 18+를 최소로 맞춰 현대 React/Next 환경에 맞는 운영을 전제로 함
  • 가장 최신 패치(5.0.9) 를 고정해서, 동일 메이저 내 버그 수정/개선분을 최대한 반영
  • 매우 작은 번들 크기(경량)로 전역 상태를 붙일 수 있음
  • persist/shallow 등 자주 쓰는 유틸/미들웨어 쪽 버그/개선이 패치로 누적됨

💡

Devths는 캘린더·게시판·채팅·챗봇처럼 기능이 많고, 화면을 넘나들며 공유해야 하는 상태(인증/유저, 전역 UI, 채팅 연결 상태 등)가 반복적으로 발생한다. 이 상태들을 useState + props 전달로만 관리하면 prop drilling이 늘고, 상태 변경 지점을 추적하기 어려워지며, 화면이 많아질수록 유지보수 비용이 급격히 증가한다.

따라서 Devths에서는 Zustand를 전역 상태 관리 도구로 채택하여

• 인증/유저 정보를 앱 전반에서 일관되게 참조하고,
• 모달/토스트/로딩 같은 전역 UI 상태를 표준화하며,
• 채팅처럼 상태 변화가 잦은 기능에서 Selector 기반 구독으로 불필요한 리렌더링을 줄여 성능을 안정화함

또한 persist, devtools, subscribeWithSelector 같은 미들웨어를 활용해 새로고침 상태 유지, 디버깅, 특정 상태 변화 트리거를 빠르게 구성할 수 있어, Devths의 요구사항을 효율적으로 충족할 수 있음

⇒ 결론적으로 Zustand는 Devths에서 공유 상태를 단순하고 일관되게 관리하면서도, 성능과 유지보수성을 함께 확보할 수 있는 전역 상태 관리 라이브러리로 적합함

• 서버 상태(Server State) 전용 관리
  • 서버에서 가져오는 데이터(목록/상세/검색 결과)를 전역 상태로 직접 들고 있지 않아도, Query가 캐시 + 동기화를 담당해줌
• 캐싱(Caching) + 자동 재조회(Refetch)
  • 같은 데이터를 여러 곳에서 써도 중복 호출을 줄이고, 언제 다시 가져올지 전략을 세울 수 있음(예: staleTime)
• Mutation(변경) 이후 캐시 무효화(invalidate) 패턴 제공
  • 글 작성/수정/삭제, 일정 추가/수정 같은 변경 이후에 관련 목록을 똑똑하게 stale 처리하고 재조회 가능
• 무한 스크롤(useInfiniteQuery) 지원
  • 게시판/댓글/채팅 히스토리처럼 페이지가 길어지는 UI에 표준 패턴 제공 (v5에서는 maxPages로 저장 페이지 수 제한 가능)
• 로딩/에러/재시도 등 비동기 상태 처리 표준화
  • isPending, isError 같은 상태로 UI를 일관되게 구성 가능
• v5의 API 단순화(객체 시그니처 중심)
  • v5는 API를 더 단순/직관적으로 정리하는 방향으로 개선됨

💡

• Devths는 서버에서 가져오는 데이터가 많고, 목록/상세/무한스크롤/검색/수정 후 갱신 같은 패턴이 반복됨.
  • 이를 useEffect + fetch로 화면마다 직접 구현하면 캐싱/동기화/로딩·에러 처리 로직이 분산되어 유지보수 비용이 빠르게 증가함
  • TanStack Query를 사용하면 서버 상태를 표준 방식으로 관리해 코드 중복과 버그를 줄일 수 있음

(1) 게시판: 글 목록(무한스크롤), 상세, 댓글, 좋아요 토글 후 목록/상세 동기화

(2) 캘린더: 월/주 단위 일정 조회 + CRUD 이후 즉시 갱신

(3) 캘린더 AI(OCR): 업로드 → 처리 상태(job) 확인 → 결과 초안(draft) 조회/확정(비동기 흐름)

(4) 채팅: 실시간 수신은 Socket.IO로 처리하되, 과거 메시지 히스토리 로딩은 서버 상태로 관리가 편함

(1) 캘린더 (일정 목록/CRUD)

• useQuery: “현재 월/주” 기준 일정 조회 (queryKey에 year-month 또는 range 포함)
• useMutation: 일정 추가/수정/삭제
• 성공 시 queryClient.invalidateQueries({ queryKey: ['calendarEvents', range] })로 목록 갱신

(2) 게시판 (목록/무한스크롤)

• useInfiniteQuery: 글 목록 무한스크롤
• v5의 maxPages로 “캐시에 저장할 페이지 수”를 제한해 성능을 안정화
• 글 작성/삭제 후 목록 invalidate로 최신화

(3) OCR 기반 자동 일정 삽입

• useMutation: 파일 업로드 요청
• useQuery: job 상태 조회(필요 시 polling) → 완료되면 draft 조회
• 확정 저장 성공 시 캘린더 목록 invalidate

(4) 채팅 (히스토리 로딩 + 실시간 결합)

• 히스토리(과거 메시지)는 useInfiniteQuery로 페이지 단위 로딩
• 실시간 새 메시지는 Socket.IO로 받고, 필요하면 Query 캐시에 합쳐서(append) 화면에 반영
  • “실시간 수신”과 “서버 히스토리” 역할 분리가 명확해짐

항목	TanStack Query	SWR	RTK Query
핵심 개념	서버 데이터 캐싱/동기화에 특화된 표준 도구	간단한 fetch + 캐시(경량)	Redux 기반으로 API를 스토어 중심으로 통합
무한 스크롤/페이지네이션	기본 패턴이 탄탄하여 구현 부담이 낮음	구현 가능하나 프로젝트 설계 의존도가 높아질 수 있음	가능하나 Redux 구조를 함께 고려해야 함
변경 후 갱신	invalidate 중심으로 갱신 흐름을 정석대로 관리 가능	갱신 가능하나 컨벤션 의존이 커질 수 있음	통합 관리가 가능하나 설정/구성이 상대적으로 큼
도입 무게	서버 상태에 집중하여 React 프로젝트에 자연스럽게 도입 가능	가장 가볍고 단순	Redux 포함 전제로 규모가 커질 수 있음
Devths 적합도	목록/필터/무한 스크롤/낙관적 UI가 많은 구조에 특히 적합	단순 조회 위주의 작은 규모에 적합	팀이 Redux 표준을 이미 사용하는 경우 후보

• 서버 데이터 관리의 표준화(캐싱/동기화 중심)

  • SWR은 “간단한 fetch + 캐시”에 강점이 있지만, 프로젝트가 커질수록(쿼리 키 설계, refetch 조건, 갱신 규칙 등) 팀 컨벤션에 의존하는 부분이 늘어날 수 있음.

  • 이 경우 화면별로 데이터 갱신 방식이 달라지거나 누락될 위험이 커짐

    ↔️ 반면 TanStack Query는 서버 데이터 캐싱/동기화를 목적으로 설계된 도구라 queryKey 기반 캐시, 자동 refetch 옵션, staleTime/cacheTime 같은 정책을 일관된 방식으로 적용하기 쉬워 “서버 상태 관리 방식”을 프로젝트 표준으로 고정하기 유리함

• 무한 스크롤/페이지네이션 구현 부담 감소

  • SWR도 무한 스크롤이 가능하지만, 페이지 파라미터 관리·중복 요청 방지·다음 페이지 병합 등 설계를 프로젝트에서 더 직접 책임져야 하는 경우가 많음

  • 데이터 패턴이 다양해질수록(게시글/알림/채팅방/검색 결과) 구현 방식이 화면마다 달라질 가능성이 있음

    ↔️ 반면 TanStack Query는 useInfiniteQuery 같은 패턴이 정교하게 제공되어, 목록과 다음 페이지 로딩 요구가 많은 서비스에서 구현을 표준화하기 쉽고 개발 비용을 낮출 수 있음

• 변경 작업 이후 갱신 흐름을 정석대로 관리

  • SWR은 갱신이 가능하지만, 어떤 변경 후 어떤 데이터를 다시 최신화할지를 화면/팀 규칙으로 맞춰야 하는 비중이 커질 수 있음

  • 좋아요/댓글/일정 CRUD처럼 변경 지점이 많아지면 누락이 발생하기 쉬움

    ↔️ 반면 TanStack Query는 useMutation + invalidateQueries(또는 cache update) 흐름이 표준이라, 변경 이후 관련 목록/상세를 일관된 방식으로 갱신해 데이터 정합성을 유지하기 유리함

• 도입 무게와 역할 분리(서버 상태에만 집중)

  • RTK Query는 Redux 기반으로 스토어 중심의 통합 관리가 장점이지만, 그 전제로 Redux 구조(슬라이스/스토어 구성)를 함께 가져가야 하므로 프로젝트 규모 대비 도입 무게가 커질 수 있음

  • 특히 서버 상태와 UI 전역 상태를 분리해서 가져가려는 구조에서는 불필요하게 커질 가능성이 있음

    ↔️ 반면 TanStack Query는 서버 상태에만 집중해서 React에 자연스럽게 붙일 수 있어, UI 전역 상태(Zustand)와 역할을 분리하기 쉽고 전체 아키텍처를 단순하게 유지하는 데 유리함

• v 5.90.16
  • 2025년 12 30일 릴리즈
• 이유
  • v5는 API를 단순화/정리하는 방향으로 개선되어, 신규 프로젝트에서 표준 패턴을 잡기 좋음
  • invalidate / infinite query 등 Devths에 필요한 핵심 기능을 공식 패턴으로 제공
    • invalidate
      • 게시판
        • 글 작성/삭제/수정 성공 → posts 목록 invalidate
        • 댓글 작성/삭제 성공 → comments invalidate
      • 캘린더
        • 일정 CRUD 성공 → calendarEvents(해당 월/주) invalidate
      • OCR 일정 생성
        • “확정 저장” 성공 → calendarEvents invalidate
  • ****동일 메이저 라인에서 안정적으로 사용 가능

• devths는 서버 데이터(목록/검색/필터/무한 스크롤)의 비중이 크고, 데이터 변경 이후 관련 화면을 최신 상태로 동기화해야 하는 요구가 많음
• 이에 따라 서버 상태를 표준화하여 관리할 수 있는 TanStack Query를 도입하는 것이 유지보수성과 성능 측면에서 가장 적합하다고 판단함

---

구분	Build-time 스타일링	Runtime 스타일링
CSS 생성 시점	빌드 시점에 CSS를 미리 생성	실행(브라우저 런타임) 중에 JS로 스타일 생성/주입
대표 예시	Tailwind CSS, CSS Modules, SCSS	styled-components, emotion(기본), 기타 CSS-in-JS
동작 방식	사용한 클래스/스타일을 분석해 필요한 CSS만 번들에 포함	컴포넌트 렌더링 시 스타일 문자열을 만들고 <style>에 inject
성능 특성	런타임 작업이 적어 예측 가능하고 빠른 편	런타임에 스타일 계산/주입 비용이 생길 수 있음
번들/CSS 크기	“쓴 것만 남기기” 최적화가 쉬워 CSS가 작아지기 쉬움	JS 번들에 스타일 로직이 포함될 수 있어 번들 복잡도 증가 가능
동적 스타일 표현	조건부 클래스 조합으로 가능하지만, “완전 동적”은 상대적으로 불편할 수 있음	props/상태 기반으로 동적 스타일 표현이 매우 쉬움
유지보수/일관성	규칙(토큰/유틸) 기반이라 UI 일관성 유지에 유리	팀 규칙이 없으면 스타일이 퍼질 수 있어 컨벤션 관리가 중요
Devths 적합도	화면/컴포넌트 많고 반복 UI가 많을 때 유리(리스트/채팅/모달 등)	강한 테마/동적 스타일이 핵심일 때 유리(규칙 없으면 복잡도↑)

• 유틸리티 클래스(Utility-first) 기반
  • p-4, text-sm, flex, gap-2 같은 클래스를 조합해 UI를 구성하는 방식이라, CSS 파일을 따로 크게 만들지 않고도 빠르게 화면을 구현할 수 있음
• 일관된 디자인 시스템 유지
  • spacing/색상/폰트 크기 등이 규칙화된 토큰 기반으로 관리되어, 페이지가 많아져도 UI 스타일이 들쭉날쭉해지지 않음
• 반응형/상태 스타일링이 직관적
  • sm:, md: 같은 반응형 프리픽스와 hover:, focus: 같은 상태 클래스 조합으로 다양한 UI 상태를 한 줄에서 관리 가능
• 생산성 향상
  • 컴포넌트 개발 시 “CSS 작성 ↔ 클래스 적용” 왕복이 줄어들어 개발 속도가 빠르고, 디자인 변경도 클래스 수정만으로 대응 가능
• 번들 최적화(사용한 클래스만 빌드)
  • 사용하지 않는 CSS는 빌드 단계에서 제거되어(최적화) 스타일 시트 용량을 줄일 수 있음

💡

• Devths는 캘린더/게시판/채팅/AI 등 화면 수가 많고 공통 UI(버튼, 모달, 입력폼, 카드, 리스트)가 반복되는 서비스임
  • Tailwind CSS를 적용하면 반복 UI를 빠르게 구현하면서도 디자인 규칙을 일관되게 유지할 수 있음

(1) 페이지 수가 많아 “스타일 일관성”이 중요함

• 화면마다 다른 CSS 방식으로 작성하면 폰트/간격/색상이 조금씩 달라지기 쉬움

  → Tailwind의 규칙화된 유틸리티로 기본 톤을 통일 가능

(2) 공통 컴포넌트(모달/버튼/입력폼) 개발 속도가 빨라짐

• Devths는 OCR 처리 모달, 글 작성 폼, 채팅 입력창 등 공통 UI가 많음

  → Tailwind로 빠르게 프로토타이핑하고, 컴포넌트 단위로 재사용하기 좋음

(3) 반응형 UI 구현이 간단함

• 캘린더/채팅은 데스크탑과 모바일 레이아웃이 달라질 수 있음

  → md:flex, sm:hidden 같은 방식으로 페이지마다 반응형 처리가 쉬움

항목	Tailwind CSS	styled-components	CSS Modules(Sass 포함)
개발 방식	유틸리티 클래스 조합	컴포넌트에 CSS-in-JS 작성	파일 단위로 클래스 작성
UI 변경 속도	JSX에서 즉시 수정 가능	스타일 정의 파일로 이동 필요	스타일 파일 수정 필요
상태별 스타일링	hover:, focus:, data-* 등 패턴화 쉬움	조건부 스타일 분기 구현	클래스 조합/분기 필요
디자인 일관성	config 기반으로 강제 쉬움	테마로 가능(설계 필요)	컨벤션 의존도가 큼
유지보수 포인트	클래스가 길어질 수 있어 관리 규칙 필요	파일/스타일 분리로 규모 커질수록 관리 복잡	파일 증가/네이밍 관리 부담

• UI 변경 속도 및 반복 UI 생산성

  • styled-components / CSS Modules는 스타일을 별도 파일(또는 CSS-in-JS 영역)에서 관리하는 비중이 커서, 버튼/탭/배지/카드/모달처럼 UI가 많이 반복되는 서비스에서는 “마크업 수정 ↔ 스타일 파일 이동” 흐름이 자주 발생함. 이 경우 화면 단위 작업량이 누적될수록 수정 비용이 커질 수 있음

    ↔️ 반면 Tailwind CSS는 JSX 안에서 유틸리티 클래스를 조합해 즉시 스타일을 적용·수정할 수 있어, 화면 수가 많고 UI 컴포넌트가 반복되는 Devths에서 개발 속도와 반복 작업 효율을 확보하기 유리함

• 상태별 스타일링의 표준화

  • CSS Modules / styled-components도 상태별 스타일링이 가능하지만, 조건 분기(클래스 조합, props 기반 분기)가 화면마다 다르게 구현되면 스타일 규칙이 분산되고 누락될 위험이 있음

  • 특히 활성/비활성/에러/선택/hover/focus 같은 상태가 많은 UI에서는 분기 로직이 늘어나 관리 포인트가 증가할 수 있음

    ↔️ 반면 Tailwind CSS는 hover:, focus:, disabled:, data-* 등 상태 표현을 클래스 레벨에서 패턴화하기 쉬워, 상태별 UI 규칙을 일관된 방식으로 적용·확장하는 데 유리함

• 디자인 일관성 유지 방식

  • CSS Modules는 네이밍/구조가 팀 컨벤션에 크게 의존하고, styled-components는 테마 설계를 통해 통일할 수 있지만 초기 설계와 팀 합의가 필요하다. 프로젝트가 커질수록 어떤 값이 표준인지가 흐려질 가능성이 있음

    ↔️ 반면 Tailwind CSS는 config(색상, 간격, 폰트, 브레이크포인트 등)를 기준으로 스타일을 강제하기 쉬워, 여러 화면을 병렬로 개발하더라도 톤앤매너를 유지하는 데 적합함

• 유지보수 리스크의 형태

  • Tailwind CSS는 클래스가 길어질 수 있어 규칙(예: 공통 컴포넌트화, 클래스 정리 기준)이 필요하다는 관리 포인트가 존재함

    ↔️ 다만 Devths처럼 UI가 많고 요구사항 변경이 잦은 환경에서는 파일 증가/네이밍 관리/CSS 분기 로직 증가가 누적되는 방식보다, 클래스 조합 중심으로 빠르게 수정 가능한 Tailwind의 유지보수 형태가 더 적합하다고 판단됨

• 공통 버튼
  • primary/secondary/disabled를 클래스 조합으로 통일
• 전역 모달
  • OCR 처리 대기 모달, 결과 검토 모달 등 레이어 UI를 같은 스타일 규칙으로 구성
• 리스트 UI
  • 게시글 목록, 채팅 메시지 목록처럼 반복되는 UI를 spacing 규칙(gap, py, border)으로 깔끔하게 유지

• v4.1
  • 2025년 4월 1일에 릴리즈
• Tailwind CSS는 메이저 버전이 바뀔 때 설정/빌드 방식이 달라질 수 있으므로, 최신 안정 버전인 4.1을 기준으로 잡으면 문서와 동일한 흐름으로 적용하기 쉬움
• 동일 메이저(4.x) 안에서 패치 업데이트로 버그 수정과 안정성 개선을 받는 방식이 유지보수에 유리하므로, 프로젝트 기본 버전은 4.1로 고정하는 것이 합리적이라고 판단

• devths는 반복 UI와 상태 변화가 많은 화면이 많기 때문에, 스타일을 빠르게 조합하고 수정할 수 있으며 표현 방식이 통일되기 쉬운 Tailwind CSS가 적합하다고 판단함.

• 필요한 컴포넌트만 설치해서 가져오는 방식

  • 라이브러리를 통째로 의존하는 게 아니라, 필요한 UI만 프로젝트에 추가해서 사용함

    → 불필요한 번들 증가를 줄이고 프로젝트 요구사항에 맞게 커스터마이징하기 쉬움

• 컴포넌트 코드가 프로젝트 내부에 존재

  • 외부 라이브러리 컴포넌트를 그대로 쓰는 것이 아니라, 생성된 컴포넌트 코드가 우리 레포 안에 들어옴

    → 디자인/동작을 우리 서비스에 맞게 수정하기 쉽고, 유지보수도 투명함

• Radix UI 기반의 접근성(A11y)

  • Dialog, Dropdown, Tabs 같은 복잡한 UI를 접근성 고려된 패턴으로 구성할 수 있음

    → 모달/드롭다운/탭 등 인터랙션이 많은 서비스에서 안정적

• Tailwind CSS와 궁합이 좋음

  • 기본 스타일링이 Tailwind 기반이라, Devths의 스타일링 전략(Tailwind)과 일관되게 통합 가능

• 일관된 UI 품질

  • 버튼/입력/모달/토스트 등 공통 UI를 표준 컴포넌트로 재사용해서 화면이 많아져도 디자인 일관성을 유지하기 쉬움

💡

Devths는 캘린더/게시판/채팅/AI 기능 전반에서 공통 UI 컴포넌트가 반복적으로 등장함

⇒ shadcn/ui를 사용하면 공통 UI를 빠르게 구성하면서도, 컴포넌트 코드가 프로젝트 내부에 있어 Devths 요구사항에 맞게 커스터마이징이 가능

(1) 공통 UI가 매우 많음

• 예: 버튼, 입력폼, 드롭다운, 탭, 모달(Dialog), 토스트, 카드, 배지

• OCR 처리 대기 모달 / 결과 검토 모달 같은 레이어 UI가 자주 등장

  → shadcn/ui로 기본 퀄리티를 빠르게 확보

(2) 디자인 일관성과 개발 속도를 동시에 잡을 수 있음

• 페이지가 늘수록 각자 만든 버튼/모달이 생기면 UI가 흔들림

  → 표준 컴포넌트를 기준으로 통일하면 품질이 안정적

(3) 커스터마이징이 쉬움

• Devths는 서비스 톤(색/여백/타이포)과 UX(모달 단계, 폼 검증 메시지 등)가 중요

  → 컴포넌트 코드가 내부에 있으니 요구사항에 맞게 수정 가능

• 캘린더
  • 일정 추가/수정: Dialog + Input + Select + Button
  • OCR 업로드/처리 대기/결과 검토: Dialog/Sheet + Progress(로딩 UI) + Toast
• 게시판
  • 글 목록 카드: Card
  • 검색/필터: Input, DropdownMenu, Tabs
  • 댓글 영역: Textarea, Button, Separator
• 채팅
  • 방 목록/메시지 패널 레이아웃: Sheet(모바일), ScrollArea
  • 메시지 입력: Textarea/Input + Button
  • 시스템 알림/에러 안내: Toast

항목	shadcn/ui	MUI (Material UI)	Ant Design
사용 방식	컴포넌트 코드를 프로젝트에 추가하여 소유	패키지 설치 후 컴포넌트 사용	패키지 설치 후 컴포넌트 사용
커스터마이징	코드 수정으로 직접 커스터마이징 가능	테마/오버라이드 중심(규칙 학습 필요)	테마 중심(디자인 시스템 성격 강함)
디자인 일관성	프로젝트 규칙 중심으로 설계 가능	라이브러리 기본 디자인 체계가 존재	라이브러리 기본 디자인 체계가 강함
업데이트 영향	필요 시에만 반영(선택적)	업데이트에 따른 영향 가능	업데이트에 따른 영향 가능
적합한 상황	서비스 고유 UI가 많고 코드 소유를 선호할 때	표준 UI로 빠르게 구축할 때	대시보드/관리자 성격 UI에 유리

• 서비스 고유 UI 반영(커스터마이징 비용)

  • MUI / Ant Design은 기본 디자인 시스템이 강해서, 서비스만의 톤앤매너(간격/폰트/버튼 형태/모달 동작)를 맞추려면 테마 설정·오버라이드 규칙을 깊게 이해해야 하고, 커스텀 범위가 커질수록 라이브러리 방식에 맞춰 수정하는 비용이 누적될 수 있음

    ↔️ 반면 shadcn/ui는 컴포넌트 코드를 프로젝트에 직접 가져와 코드 자체를 수정하는 구조라, Devths처럼 화면이 많고 UI 디테일이 자주 바뀌는 프로젝트에서 요구사항을 빠르게 반영하고 일관된 스타일 규칙을 유지하기 유리함

• 코드 소유권과 업데이트 리스크 통제

  • MUI / Ant Design은 패키지에 의존하는 방식이라, 버전 업데이트 시 내부 변경에 따라 스타일/동작이 영향을 받을 수 있고(특히 커스텀 오버라이드가 많을수록) 회귀 이슈 대응 비용이 커질 수 있음

    ↔️ 반면 shadcn/ui는 필요한 컴포넌트만 프로젝트에 추가하고, 업데이트도 필요할 때만 선택적으로 반영할 수 있어, 업데이트 영향 범위를 팀이 통제하기 쉬움

• 접근성(ARIA/키보드 포커스) 품질 확보

  • 모달/드롭다운/탭/툴팁 같은 컴포넌트는 키보드 포커스 이동, aria 속성, 스크린리더 대응 등 접근성 요구를 제대로 맞추지 않으면 품질 편차가 생기기 쉬움

    ↔️ shadcn/ui는 Radix UI 기반 패턴을 활용하므로, Devths에서 반복적으로 필요한 상호작용 UI를 접근성 기준에 맞춰 표준화된 품질로 가져가기 유리함

• Tailwind 기반 스타일링과의 정합성

  • Devths는 Tailwind를 스타일링 전략으로 채택했기 때문에, 컴포넌트 레벨에서도 Tailwind 유틸리티로 스타일을 통일하는 것이 유지보수에 유리함

    ↔️ shadcn/ui는 Tailwind 중심으로 구성/확장하는 흐름과 잘 맞아, 전역 디자인 규칙(config) + 컴포넌트 구현을 같은 방식으로 운영하기 쉬움

• devths는 다수의 화면과 반복되는 상호작용 UI가 존재하며, 전역 모달/탭/드롭다운 등 접근성까지 고려해야 하는 컴포넌트의 비중이 높음
• shadcn/ui는 컴포넌트 코드를 프로젝트가 직접 소유하여 요구사항에 맞게 수정, 확장할 수 있으므로, devths의 UI 표준화와 유지보수성 확보를 위해 적합한 선택으로 판단함

• 월/주/일 뷰 등 캘린더 UI를 완성도 높게 제공
  • 기본으로 Month/Week/Day 뷰를 지원하고, 일정(이벤트)을 캘린더 형태로 시각화하는 기능이 잘 갖춰져 있음
• 강력한 인터랙션 지원
  • 날짜 클릭, 일정 클릭, 드래그&드롭 이동, 리사이즈(시간 늘리기) 등 캘린더에서 기대하는 UX를 표준 기능으로 제공
• 이벤트 데이터 렌더링/커스터마이징이 유연함
  • 이벤트 색상, 표시 형태, 툴팁/팝오버, 커스텀 렌더링 등 UI 요구사항에 맞게 커스터마이징 가능
• 플러그인 구조
  • 필요한 뷰/기능만 추가해 사용할 수 있어, 요구사항에 맞게 구성하기 좋음
  • 예: dayGrid, timeGrid, interaction 등
• React 연동 지원
  • React용 패키지를 제공해 컴포넌트 형태로 캘린더를 붙일 수 있고, 이벤트 핸들러를 React 상태/로직과 연결하기 쉬움

💡

Devths의 캘린더는 단순 일정 표시가 아니라 일정 CRUD + 사용자 인터랙션 + AI(OCR) 기반 일정 자동 삽입까지 포함하는 핵심 기능임

• FullCalendar는 완성된 캘린더 UI + 강력한 인터랙션을 기본 제공하므로, 직접 캘린더를 구현하는 비용을 줄이고 핵심 기능 개발(OCR/AI, 일정 관리 로직)에 집중할 수 있음

(1) 월/주 뷰가 필수인 서비스 요구사항에 적합

• 채용 일정/마감/면접 일정은 월/주 단위로 보는 니즈가 큼

  → FullCalendar는 이 뷰를 기본 지원

(2) 일정 편집 UX(클릭/드래그/리사이즈)가 중요

• 일정 클릭 → 상세/수정 모달
• 드래그로 날짜 이동, 리사이즈로 시간 조정 같은 UX를 제공하면 캘린더 사용성이 크게 올라감

(3) OCR로 생성된 “초안 일정”을 자연스럽게 반영 가능

• OCR 결과로 생성된 이벤트를 캘린더에 즉시 미리 보여주고(초안 표시),
• 사용자 확인 후 저장하는 흐름에 맞춰 이벤트 렌더링/업데이트를 유연하게 처리 가능

• 이벤트 타입 고정(TypeScript)
  • 서버에서 받은 이벤트를 CalendarEvent 타입으로 고정하고, FullCalendar가 요구하는 형태로 변환 함수로 매핑
• 핵심 인터랙션 연결
  • 날짜 클릭: 일정 추가 모달 오픈
  • 이벤트 클릭: 일정 상세/수정 모달 오픈
  • 드래그/리사이즈: 일정 수정 API 호출 → 성공 시 일정 목록 갱신
• OCR 자동 삽입
  • 업로드 → 처리중 모달 → 결과 초안 생성 → 캘린더에 임시 표시 → 사용자 확정 시 저장

항목	FullCalendar	react-big-calendar	직접 구현
구현 범위	달력 UI 기능 폭이 넓고, 뷰/이벤트 배치/상호작용 지원이 체계적	기본 달력 구현은 가능하나, 복잡한 표현 규칙이 많을수록 커스텀 부담 증가	완전 자유이나 날짜 계산/배치/겹침/접근성/성능을 모두 직접 구현해야 함
커스터마이징	이벤트 표시 방식 커스텀에 강함	커스텀 가능하나 요구사항이 많으면 설계 난이도 증가	자유도 최고(대신 유지보수 비용 최고)
리스크/일정	검증된 라이브러리 기반으로 달력 특유 예외 케이스 리스크 감소	단순 요구에는 적합, 복잡 요구에는 추가 비용 발생 가능	개발 기간/버그/성능 리스크가 큼
Devths 적합도	규칙이 많은 캘린더 UI”에 적합	단순 달력 수준이면 후보	과제/기간 제한 상황에서는 비추천

• 구현 범위와 기본 기능 커버리지

  • react-big-calendar는 기본적인 달력 화면 구성은 가능하지만, 월/주 전환 + 일정 배치 + 클릭 상호작용 + 다양한 표현 규칙처럼 요구사항이 늘어날수록 추가 구현 범위가 빠르게 커질 수 있음

  • 직접 구현은 자유도는 높지만, 날짜 그리드 구성/월·주 계산/이벤트 배치/겹침 처리 같은 달력 핵심 로직까지 전부 직접 책임져야 해서 개발 난이도와 일정 부담이 매우 큼

    ↔️ 반면 FullCalendar는 달력 UI에서 반복적으로 필요한 뷰 전환, 이벤트 배치, 상호작용 처리가 체계적으로 제공되어, Devths는 달력 엔진을 새로 만들기보다 서비스 요구사항에 집중하기 유리함

• 커스터마이징 비용과 확장성

  • Devths 캘린더는 단순히 일정 목록 표시가 아니라, 점/선 표현, 태그·단계·회사 같은 부가 정보 표시, 필터 UX 등 커스터마이징 요소가 늘어날 가능성이 큼

  • react-big-calendar에서도 커스텀은 가능하지만, 요구사항이 복잡해질수록 설계 난이도와 유지보수 비용이 증가할 수 있음

  • 직접 구현은 원하는 건 다 할 수 있지만, 그만큼 구현·테스트·유지보수 책임이 전부 프로젝트에 남음

    ↔️ FullCalendar는 이벤트 렌더링 커스터마이징을 전제로 한 구조가 탄탄해, 표현 규칙이 많은 캘린더에서 변경 대응 비용을 낮추는 데 유리함.

• 리스크와 일정(달력 특유 예외 케이스)

  • 달력은 생각보다 예외 케이스가 많음(월 경계, 주차 계산, 타임존/종일 일정, 기간 일정의 시작·끝 처리, 이벤트 겹침 등).

  • 직접 구현은 이런 예외 케이스를 모두 직접 해결해야 하므로 버그/성능/일정 리스크가 가장 큼.

  • react-big-calendar는 단순 요구엔 적합하지만, 복잡한 규칙이 추가될수록 추가 구현 + 예외 케이스 처리가 누적될 수 있음.

    ↔️ FullCalendar는 검증된 라이브러리 기반으로 달력 핵심 예외 케이스를 기본적으로 흡수해, 기간 제한 환경에서 안정적인 선택이 됨

• Devths 요구사항 적합성

  • Devths는 규칙이 많은 캘린더 UI가 중심 기능 중 하나이므로, 단순 달력 수준에 최적화된 선택보다 표현력/확장성/안정성이 중요함.

    ↔️ 따라서 Devths에서는 FullCalendar를 채택하여 달력의 핵심 엔진은 검증된 도구에 맡기고, 서비스 고유 요구사항(필터링, 커스텀 렌더링, 상세 카드/모달 플로우)에 개발 역량을 집중하는 구성이 합리적임.

• v6.1.20
  • 2025년 12월 23일에 릴리즈됨
• 이유
  • 안정적인(Stable) 버전 라인을 기준으로 선정하여, 과제/서비스 개발에서 발생할 수 있는 예기치 못한 변경(베타 기능/불안정성) 리스크를 줄임
  • React 환경에서 사용 가능한 구성(React 컴포넌트 제공)을 기반으로 Next.js 프로젝트에 적용이 용이함

• Devths 캘린더는 Google Calendar API를 통해 일정 데이터를 관리하되, 화면 요구사항(월/주 전환, 일정 점/선 표현, 상세 카드/모달 연동, 필터 UX 등)은 프론트에서 구현해야 함
• FullCalendar는 달력 UI의 기본 구조와 이벤트 배치/상호작용 기능을 제공하여 요구사항 충족에 적합하며, 개발 효율 및 유지보수 측면에서도 유리함

---

• 빠르고 디스크 효율적인 패키지 매니저
  • npm/yarn처럼 node_modules를 설치하지만, 설치 속도와 디스크 사용량 최적화에 강점이 있음.
• 버전 고정(재현 가능한 설치) 지원
  • Corepack을 쓰면 프로젝트 package.json의 packageManager 필드로 pnpm 버전을 고정해서, 팀원/CI 환경이 달라도 같은 버전으로 설치되게 만들 수 있음.
• 워크스페이스(모노레포) 구성에 적합
  • pnpm-workspace.yaml 기반으로 여러 패키지를 한 레포에서 관리하기 쉬움.
• 설정/규칙을 한 곳에서 관리 가능
  • 설정은 CLI / 환경변수 / pnpm-workspace.yaml / .npmrc에서 가져오며, 팀 공통 규칙을 정하기 좋음.

💡

Devths는 프론트(Next/React/TS) + 테스트/린트/빌드 도구 + 다양한 라이브러리로 의존성이 많아질 가능성이 크고, 팀 협업 환경에서는 설치 결과가 매번 같아야 안정적임.

(1) 팀 협업에서 설치 환경을 통일해야 함

• 팀원마다 pnpm 버전이 다르면 설치 결과/락파일 처리 방식이 달라져 충돌이 날 수 있음

  → Corepack으로 pnpm 버전을 프로젝트에 고정하면 환경 차이를 줄일 수 있음.

(2) 워크스페이스로 확장 가능

• 이후 apps/web, packages/ui, packages/shared 같은 구조로 커질 때 pnpm-workspace.yaml 기반 관리가 편함.

(3) CI(빌드/테스트)에서 설치 시간을 줄이기 유리

• pnpm은 캐시/스토어 기반 설치 전략을 제공해서 반복 설치 상황(로컬/CI)에서 효율을 기대할 수 있음.

• Corepack으로 pnpm 활성화 & 버전 고정

  • Corepack 활성화: corepack enable pnpm

  • 프로젝트에서 pnpm 버전 고정: corepack use [email protected]

    → package.json에 packageManager가 기록되어 팀 전체가 같은 버전을 쓰기 쉬움.

• 기본 명령어

  • 의존성 설치: pnpm install
  • 패키지 추가: pnpm add <pkg> (개발 의존성은 D)
  • 스크립트 실행: pnpm dev, pnpm build, pnpm lint (package.json scripts 기준)

항목	pnpm	npm	Yarn
설치/용량 효율	전역 저장소(공용) 활용으로 중복 설치 낭비를 줄이는 방향	프로젝트별 설치 중심(중복이 생기기 쉬움)	설정/버전에 따라 전략이 다름(프로젝트 표준에 의존)
의존성 “엄격함”	선언한 의존성 중심으로 더 엄격한 구조 지향 → 숨은 의존성 실수 방지에 유리	비교적 관대한 편이라 실수가 늦게 드러날 수 있음	PnP 등 선택지로 엄격하게 만들 수 있으나 팀 합의/학습이 필요할 수 있음
팀/CI 재현성	lockfile 기반 재현에 초점	lockfile 기반이지만 환경 차이 관리가 과제가 될 수 있음	lockfile 기반, 다만 조직/레포 표준에 따라 편차

• 설치/용량 효율

  • npm/Yarn은 프로젝트별 node_modules 구조 특성상 같은 패키지를 여러 번 내려받아 저장하는 상황이 반복되기 쉬워, 의존성이 늘어날수록 설치 시간과 디스크 사용량이 누적될 가능성이 큼

    ↔️ 반면 pnpm은 공용 저장소(content-addressable store)에 패키지를 한 번 저장하고 프로젝트에서는 링크로 연결하는 방식이라, 팀 프로젝트에서 반복 설치 비용이 줄어들고 로컬·CI 환경 모두에서 효율이 좋아질 수 있음

• 의존성 오류를 빨리 드러내는 구조

  • npm/Yarn(일반적인 node_modules 구성)에서는 간접적으로 설치된 패키지가 우연히 접근 가능한 경우가 있어, 실제로는 선언되지 않은 의존성에 기대는 코드가 늦게 발견될 수 있음

    ↔️ 반면 pnpm은 선언한 의존성 중심으로 접근이 가능한 더 엄격한 설치 구조를 지향하므로, 숨은 의존성/모듈 해석 문제를 개발 초기에 드러내는 데 유리함

• CI/배포 재현성

  • npm/Yarn도 lockfile을 제공하지만, 팀이 사용하는 버전/환경 차이에 따라 설치 결과를 동일하게 유지하기 위해 추가 관리가 필요한 경우가 있음

    ↔️ 반면 pnpm은 lockfile 기반 재현성에 초점을 두고, 설치 구조가 비교적 일관되게 유지되는 편이라 CI에서 결과를 고정하기에 유리하며, 배포/과제 환경에서 예측 불가능한 의존성 이슈를 줄이는 데 도움이 됨

• v10.27.0
  • 2025년 12월 30일에 릴리즈
• 이유
  • pnpm은 메이저 버전 내에서 패치 버전을 최신으로 유지하는 방식이 일반적으로 안정적이며(버그 수정/개선 반영), v10.27.0은 pnpm 공식 릴리즈로 제공되는 버전임
  • 따라서 Devths에서는 메이저 버전(10.x)은 유지하되, 최신 안정 패치(v10.27.0) 를 기준으로 사용하여 설치/CI/운영 과정에서의 안정성을 확보하는 전략을 채택함

• Devths는 프론트엔드 의존성이 커질 가능성이 높은 프로젝트이므로, 설치 효율(속도/용량)과 팀 단위 재현성(버전 고정/CI 안정성)을 동시에 확보하는 것이 중요함
• 이에 따라 패키지 관리 도구로 pnpm(프로젝트 버전 고정 포함)을 채택하는 것이 적절하다고 판단함

💡

Devths는 Next.js 16을 쓰는 전제로, 번들러는 별도 설치가 아니라 Next.js에 내장된 Turbopack을 사용한다고 쓰면 자연스러움

• Next.js 내장 번들러(기본값)
  • Next.js 16에서 Turbopack이 기본 번들러가 되어, 별도 플래그 없이도 개발/빌드에서 사용됨
• 개발 경험(DX) 최적화: 빠른 dev 서버/갱신
  • 빠른 개발 서버 시작, 코드 변경 시 빠른 리프레시(개발 워크플로우 개선)를 목표로 설계됨
• 프로덕션 빌드까지 지원 범위 확대
  • Next.js 15.5부터 next build 지원이 베타로 들어가고, Next.js 16에서는 dev/build 모두 “기본” 흐름으로 정리됨
• Webpack loader 설정에 덜 의존
  • Next.js의 기본 기능 범위(CSS/JS 컴파일 등)는 Turbopack에서 로더 설정 없이도 동작하도록 안내됨

• (1) 화면/기능이 많아 개발 중 수정·검증 사이클이 매우 자주 발생

  • 캘린더(월/주 뷰 전환), 게시판(무한스크롤), 채팅(실시간 UI), OCR 업로드/모달 등은 개발 중 변경이 잦음

    → Turbopack은 개발 워크플로우 속도 개선을 핵심 목표로 하고, Next 16.1에서도 Turbopack/툴링 개선을 강조함

• (2) Next.js 16의 표준(기본) 번들러를 따라가면 팀 규칙이 단순해짐

  • 따로 -turbopack 플래그를 관리하지 않아도 되고, Next.js 업그레이드 가이드에서도 “기본으로 사용”을 전제로 설명됨

기본 사용(Next.js 16)

• pnpm dev → 내부적으로 next dev 실행 시 Turbopack이 기본 적용
• pnpm build → next build도 기본으로 Turbopack 사용

항목	Turbopack (Next.js 기본)	Webpack (Next.js에서 --webpack)	Vite (일반적으로 Vite + React)
Next.js 통합	Next에 내장, 기본 번들러	Next에서 선택적으로 사용	Next 프레임워크 대체(별도 라우팅/SSR 구성 필요)
설정 난이도	공통 케이스 “무설정”에 가까움	필요한 설정/플러그인 조합이 늘 수 있음	빠르게 시작 가능하지만 앱 구조 커지면 조합 설계 부담
개발 체감 속도 목표	대규모 앱에서 빠른 dev 경험을 목표로 설계	표준/성숙, 다만 dev 속도는 프로젝트에 따라 부담	dev 서버 빠른 편(단, Next 기능은 직접 붙여야 함)
호환성/확장	Next 공통 사용은 잘 지원, 다만 일부는 “webpack 대비 갭” 존재(예: webpack 플러그인)	webpack 생태계(로더/플러그인) 활용 폭이 큼	번들러 자체 생태계는 풍부하지만 Next의 SSR/라우팅은 별도 설계
추천 상황	Next.js 표준 흐름(설정 적게, 빠른 dev)	webpack 플러그인/특수 로더가 꼭 필요할 때	Next가 아니라 SPA 중심으로 가볍게 구성할 때

• Next.js 표준 흐름 유지(통합성)

  • Webpack(Next에서 --webpack)은 특정 로더/플러그인 요구가 생기면 커스텀 설정이 늘어날 수 있고, 설정이 늘어날수록 Next 기본 최적화/업데이트 흐름과 충돌하거나 유지보수 포인트가 증가할 가능성이 있음

    ↔️ 반면 Turbopack(Next.js 기본)은 Next에 내장된 기본 번들러로 동작하므로, 프레임워크가 의도한 개발·빌드 파이프라인을 그대로 따르기 쉬워 통합 관점의 리스크(설정 충돌/추가 관리)를 줄이는 데 유리함

• 개발 생산성(개발 체감 속도) 중심의 선택

  • Webpack은 표준적이지만, 프로젝트 규모가 커질수록 개발 서버 체감 속도(재빌드/핫리로드)가 부담이 될 수 있으며, 속도 이슈가 발생하면 최적화 작업이 별도 과제가 될 수 있음

    ↔️ Turbopack은 대규모 앱에서 빠른 개발 경험을 목표로 설계된 Next 기본 선택지이므로, 초기부터 설정 비용 없이 개발 생산성을 확보하는 방향에 더 적합함

• 프로젝트 확장 시 누적 비용(설계·운영 부담) 최소화

  • Vite(일반적으로 Vite + React)는 dev 서버가 빠르고 시작이 가볍지만, Next의 라우팅/SSR/SSG/서버 기능을 프레임워크 차원에서 제공하지 않기 때문에, 같은 목적을 달성하려면 별도 조합 설계(라우팅, SSR 전략, 에러 처리, 배포 구조 등)가 필요해질 수 있음

    ↔️ Devths는 Next.js 기반으로 기능 확장이 예상되는 구조이므로, 번들러도 Next 내장 기본값(Turbopack)을 채택해 프레임워크 제공 기능 + 번들러를 한 흐름으로 묶는 것이 확장/유지보수 관점에서 합리적임

• devths는 Next.js 기반으로 화면과 기능이 확장되는 구조이므로, Next.js에 기본으로 통합된 Turbopack을 사용해 개발 경험을 표준화하는 것이 적절함

---

• 스키마 기반 유효성 검사

  • 이 데이터는 이런 형태여야 한다를 스키마(schema) 로 정의하고, 입력값/응답값이 그 규칙을 만족하는지 검사함

• TypeScript와 강하게 연결됨 (타입 추론)

  • z.object({...})로 스키마를 만들면, 그 스키마에서 타입을 자동으로 뽑아(z.infer) 프론트 전반에서 재사용 가능

    → “검증 규칙”과 “타입”이 따로 놀지 않음(동기화됨)

• 런타임 검증 가능

  • TypeScript는 컴파일 단계에서만 체크하지만, Zod는 실제 실행 중(런타임)에 들어온 값을 검사해서 서버 응답/외부 입력의 이상값을 막을 수 있음

• 에러 메시지 구조화

  • 어떤 필드가 왜 실패했는지 에러 정보를 구조적으로 얻을 수 있어, 폼 에러 UI에 연결하기 좋음

• safeParse로 안전하게 처리

  • 예외를 던지는 대신 성공/실패를 객체로 반환해, 실패 케이스를 안정적으로 분기 처리하기 쉬움

💡

Devths는 폼 입력 + 파일 업로드 + AI/OCR 결과 + 실시간/목록 데이터처럼 외부에서 들어오는 데이터가 많아서, 클라이언트에서 데이터 형태를 확실히 고정해두는 게 중요함.

(1) 폼이 많아 입력값 검증이 반복됨

• 로그인/회원가입, 프로필 수정, 게시글 작성, 파일 업로드 등

  → Zod로 스키마를 공통화하면 폼마다 검증 규칙을 중복으로 구현하지 않고 일관된 기준을 적용할 수 있음

(2) 서버 응답이 항상 ‘정상’이라고 가정하면 위험함

• 게시글 목록, 댓글, 캘린더 이벤트, 채팅방 목록 등은 API 응답 구조가 조금만 바뀌어도 화면이 깨질 수 있음

  → Zod로 응답을 런타임에서 검증하면 조용히 깨지는 버그를 줄이고, 문제가 생기면 빠르게 감지 가능

(3) OCR/AI 결과는 특히 불확실한 입력

• 날짜/시간/장소가 누락되거나 형식이 애매한 값이 들어올 수 있음

  → Zod로 ‘최소한 이 필드는 있어야 한다/없으면 보정 UI로 유도’ 같은 규칙을 만들기 좋음

항목	Zod	Yup	Joi
TypeScript 궁합	스키마에서 타입 추론 중심이라 TS와 결합이 자연스러움	TS 사용은 가능하지만 타입 추론이 Zod만큼 자연스럽게 스키마=타입으로 이어지진 않는 편	주로 런타임 검증 중심이며 프론트 TS 타입 흐름과 일체화는 추가 작업이 필요할 수 있음
규칙 관리 방식	검증 규칙을 스키마로 고정하고 재사용하기 좋음	스키마 기반이지만 프로젝트마다 타입·검증 동기화 전략을 따로 잡는 경우가 있음	강력한 검증 기능이 있지만 프론트 폼 중심 운영에서는 다소 무겁게 느껴질 수 있음
Devths 적합 포인트	폼/입력 규칙이 많고, TS 기반으로 구조를 표준화하고 싶을 때 유리	기존 Yup 기반 레거시/팀 경험이 많다면 후보	검증 스펙이 매우 복잡하고 런타임 검증을 강하게 가져가야 할 때 후보

• TypeScript와의 결합(스키마=타입 흐름)

  • Yup은 TypeScript 사용이 가능하지만, 스키마를 작성한다고 해서 그게 곧바로 프론트 타입의 근거로 자연스럽게 이어지지 않는 경우가 있어, 타입과 검증 규칙이 따로 놀 가능성이 있음

    ↔️ 반면 Zod는 스키마에서 타입을 추론하는 흐름이 중심이라, 검증 규칙(스키마)과 TypeScript 타입을 한 덩어리로 관리하기 쉽고, 필드 누락/nullable 착각/타입 불일치 같은 실수 비용을 줄이는 데 유리함

• 규칙의 표준화 및 재사용(정책을 코드로 고정)

  • Yup도 스키마 기반이지만, 프로젝트에서 타입·검증을 어떻게 동기화할지를 별도 전략으로 잡아야 하는 경우가 있어, 화면이 늘어나면 규칙 관리가 팀 컨벤션에 더 의존할 수 있음

    ↔️ Zod는 스키마를 만들면 그 자체가 타입과 검증의 기준이 되기 쉬워, 회원가입/게시글/댓글/일정/검색/파일 업로드처럼 입력 규칙이 반복되는 Devths에서 규칙을 일관된 방식으로 재사용하기 좋음

• 프론트 폼 운영 적합성

  • Joi는 런타임 검증 기능이 강력하지만, 프론트 폼 중심으로 사용하기엔 상대적으로 무겁게 느껴질 수 있고, TypeScript 타입 흐름과 완전히 일체화하려면 추가 작업이 들어갈 수 있음

    ↔️ Zod는 프론트에서 입력값 검증 + 타입 정합성 유지 목적에 맞게 가볍고 직관적으로 적용 가능해, Devths처럼 폼이 많은 서비스에서 운영 부담이 낮음

• Zod v4.3.4
  • 2026년 1월 2일 릴리즈
• 이유
  • v4 라인은 현재 문서/생태계 흐름을 기준으로 잡기 좋고, 최신 패치 버전을 채택하면 버그 수정 및 안정성 개선을 포함할 가능성이 높아 유지보수에 유리함
  • 운영 전략은 다른 라이브러리와 동일하게 메이저(v4)는 유지, 패치/마이너는 정기 반영함

• Devths는 입력/폼이 많고 검증 규칙이 세밀해질 가능성이 큰 서비스이므로, 검증 규칙을 스키마로 표준화하고 TypeScript 타입까지 함께 정리할 수 있는 Zod를 채택하는 것이 유지보수성과 안정성 측면에서 합리적이라고 판단함

• 폼(Form) 상태 관리를 간단하게
  • 입력값(value), 에러(errors), 제출(submit), 로딩 상태 등을 폼 단위로 한 번에 관리할 수 있음
  • register, handleSubmit, formState 같은 기본 API로 흐름이 단순함
• 리렌더링이 적어서 성능에 유리
  • 입력할 때마다 전체 컴포넌트가 계속 리렌더되는 방식이 아니라, 폼 상태를 효율적으로 다뤄서 입력 필드가 많아도 성능이 비교적 안정적임
• 검증(Validation) 연결이 쉬움
  • 기본 검증(required/minLength 등)도 가능하고,
  • Zod 같은 스키마 검증도 resolver로 쉽게 연결 가능 → 한 곳에서 규칙 관리 가능
• 에러 메시지/UI 연결이 깔끔함
  • errors.email?.message처럼 필드별 에러를 구조적으로 접근할 수 있어, 입력폼 UI(에러 텍스트/빨간 테두리) 붙이기 쉬움
• 복잡한 폼 기능 지원
  • 동적 필드(추가/삭제) useFieldArray
  • 특정 값 감시 watch
  • 커스텀

💡

Devths는 입력 폼이 많은 서비스라서, 폼 처리 방식이 표준화되지 않으면 페이지마다 구현 방식이 달라지고 버그가 늘어나기 쉬움.

• React Hook Form을 도입하면 폼 입력 → 검증 → 에러 표시 → 제출 흐름을 공통 패턴으로 통일할 수 있음

(1) 폼이 많은 서비스 구조

• 로그인/회원가입
• 프로필 수정(닉네임/비밀번호/이미지)
• 게시글 작성/수정(제목/본문/태그/첨부)
• 캘린더 일정 추가/수정(시간/장소/메모)
• OCR 결과 일정 초안(draft) 검토/보정 입력

→ 폼이 많을수록 “검증/에러 UI/제출 로직”을 매번 직접 짜면 중복이 커짐

→ RHF로 공통 흐름을 잡으면 유지보수 비용이 줄어듦

(2) Zod와 조합해서 ‘검증 규칙’을 한 곳에 모을 수 있음

• Devths는 이미 Zod를 쓰는 방향이므로,

• RHF + Zod resolver 조합이면 타입/검증/에러메시지가 한 덩어리로 관리됨

  → 폼마다 검증 규칙이 들쭉날쭉해지는 문제를 줄임

(3) OCR/AI 결과처럼 불완전한 입력을 보정하는 UX에 적합

• OCR이 날짜/시간을 못 뽑는 경우, 사용자가 직접 채워 넣는 폼이 필요함

  → RHF로 부분 입력 + 즉시 검증 + 저장 플로우를 안정적으로 만들기 좋음

항목	React Hook Form	Formik	React 단독(useState로 직접 구현)
폼 상태 관리 방식	필요한 상태를 선택적으로 구독하는 패턴에 강점	폼 상태를 한 덩어리로 다루는 방식이 흔함	화면마다 제각각 구현될 가능성이 큼
렌더링/성능 관점	큰 폼/입력 많을 때 리렌더링 제어에 유리	규모 커지면 최적화가 추가로 필요해질 수 있음	최적화/패턴화 모두 직접 책임
검증 도구 결합	Zod 등 스키마 검증과 결합 패턴이 널리 쓰임	Yup 조합이 흔하지만 구성에 따라 다름	검증/에러 매핑 로직을 직접 다 만들어야 함
Devths 적합도	입력 화면/규칙이 많은 서비스에 적합	팀이 Formik 표준을 이미 쓰면 후보	장기적으로 유지보수 비용이 커지기 쉬움

• 폼 상태 관리의 표준화(구현 방식 흔들림 방지)

  • **React 단독(useState)**은 화면마다 입력값/에러/터치 여부/제출 상태를 각각 직접 구현해야 해서, 페이지가 늘어날수록 구현 방식이 제각각이 되고 누락(예: 에러 표시, 제출 중 비활성, 초기화)이 발생하기 쉬움

    ↔️ 반면 React Hook Form은 폼 상태 관리 흐름(등록, 제출, 에러 관리)을 라이브러리 레벨에서 표준화하므로, Devths처럼 입력 화면이 많은 구조에서 일관된 구현 패턴을 유지하기 유리함

• 렌더링/성능 관점

  • Formik은 폼 상태를 한 덩어리로 다루는 방식이 흔해, 폼이 커지거나 입력이 많아질수록 리렌더링 최적화가 추가로 필요해질 수 있음

    ↔️ React Hook Form은 필요한 상태만 선택적으로 구독하는 패턴에 강점이 있어, 큰 폼/입력 수가 많은 화면에서 불필요한 리렌더링을 줄이는 설계에 유리함

• 검증 도구 결합의 명확성

  • **React 단독(useState)**은 검증 로직과 에러 메시지 매핑을 화면마다 직접 만들어야 하므로, 규칙이 많아질수록 중복과 불일치가 늘어날 가능성이 큼

  • Formik은 Yup 조합이 흔하지만, 프로젝트 구성에 따라 검증 흐름이 달라질 수 있어 팀 컨벤션 의존이 커질 수 있음

    ↔️ React Hook Form은 Zod 같은 스키마 검증과 결합하는 실무 패턴이 널리 정착되어 있어, ‘폼 입력 → 스키마 검증 → 에러 매핑’ 흐름을 안정적으로 고정하기 좋음

• v7.70.0
  • 2026년 1월 4일에 릴리즈됨
• 이유
  • GitHub 릴리즈 기준으로 v7.70.0이 안정 릴리즈로 배포되어 있음
  • 폼 라이브러리는 앱 전역에 영향이 크므로(모든 입력 화면에 걸림), 메이저를 자주 흔들기보다 메이저 라인은 고정하고 패치 업데이트로 안정성(버그 수정)을 받는 전략이 운영 관점에서 보수적으로 안전하다고 판단했음

• Devths는 입력 화면이 많고 입력 규칙이 복잡해질 가능성이 높다. 따라서 폼 구현을 화면마다 분산시키기보다, React Hook Form을 도입해 폼 상태/제출/에러 처리를 표준화하고, Zod와 결합하여 검증 규칙을 일관되게 유지하는 구성이 적합하다고 판단했음

---

• 브라우저와 Node.js 환경에서 HTTP 요청을 쉽게 보내기 위한 라이브러리로, 요청/응답 설정을 객체(config)로 관리하고 공통 로직을 인터셉터로 표준화할 수 있음

• baseURL, headers, params, timeout, withCredentials 등 네트워크 옵션을 한 곳에서 선언적으로 관리할 수 있음
• 모든 요청 전에 토큰/세션을 자동 첨부하거나, 모든 응답에서 401/500 같은 공통 에러 처리를 한 번에 적용할 수 있음
• 화면 이동/탭 전환/검색어 변경처럼 이전 요청은 버려야 하는 상황에서 요청 취소 흐름을 설계할 수 있음
• 이미지/파일 첨부 기능에서 multipart 업로드를 구성하기 쉬움

• Google OAuth 이후 API 호출마다 토큰/세션 정보를 공통으로 붙여야 하므로, 인터셉터 기반으로 자동 주입 + 공통 에러 처리를 표준화하는 것이 유지보수에 유리하다고 판단함
• 게시글/채팅/프로필 등에서 첨부를 다루게 되면 multipart 업로드가 핵심이 되므로 Axios의 업로드 구성 방식이 적합하다고 판단함
• 페이지가 많아질수록 로딩/에러/재시도/취소 같은 네트워크 UX가 흔들리기 쉬운데, Axios는 설정(config)과 인터셉터로 정책을 한 곳에 모으기 좋음

항목	Axios	fetch(내장)
공통 헤더/토큰 주입	인터셉터로 표준화 가능	직접 래퍼 함수를 만들어야 함
요청 옵션 관리	config 객체로 일관되게 관리	옵션을 호출마다 구성(컨벤션 필요)
요청 취소	취소 흐름 지원	AbortController를 직접 설계해야 함
파일 업로드	multipart 예시/패턴이 명확	FormData 구성은 가능하지만 패턴 표준화는 직접 필요
팀 일관성	인스턴스 1개로 정책 고정이 쉬움	팀 컨벤션에 따라 편차 발생 가능

• 공통 헤더/토큰 주입의 표준화

  • **fetch(내장)**은 요청마다 헤더를 붙이거나, 별도의 래퍼 함수를 만들어 “토큰 주입 규칙”을 팀이 직접 강제해야 하므로, 화면/기능이 늘어날수록 누락(예: 특정 API만 토큰 빠짐) 가능성이 증가함

    ↔️ 반면 Axios는 인터셉터 기반으로 인증 토큰, 세션 헤더, 공통 헤더 정책을 한 곳에서 처리할 수 있어, Devths처럼 인증/권한이 여러 API에 걸친 구조에서 정책을 표준화하기 유리함

• 요청 옵션 관리의 일관성

  • **fetch(내장)**은 각 호출마다 옵션을 구성하는 방식이어서, timeout/credentials/baseURL/에러 처리 등 공통 규칙을 팀 컨벤션으로 유지해야 하고 구현 편차가 생기기 쉬움

    ↔️ Axios는 인스턴스의 config로 baseURL, timeout, 공통 헤더, withCredentials 같은 정책을 고정할 수 있어, 프로젝트 전반에서 동일한 요청 규칙을 유지하기 쉬움

• 요청 취소(Abort) 흐름의 운영 난이도

  • **fetch(내장)**은 AbortController를 화면마다 설계해야 하므로, 검색/자동완성/무한스크롤처럼 이전 요청 취소가 필요한 화면이 늘어나면 코드 중복과 누락 위험이 커질 수 있음

    ↔️ Axios는 취소 흐름을 라이브러리 수준에서 지원하며, 공통 요청 유틸과 결합해 취소 정책을 패턴화하기 유리함

• 파일 업로드 패턴의 표준화

  • **fetch(내장)**도 FormData로 업로드는 가능하지만, 멀티파트 요청 구성/에러 처리/진행 상태/공통 헤더 정책을 팀이 직접 표준화해야 함

    ↔️ Axios는 multipart 업로드에 대한 실무 패턴과 레퍼런스가 많고, 인스턴스/인터셉터와 결합해 업로드 정책(예: 공통 에러 처리, 인증 헤더)을 일관되게 적용하기 용이함

• 팀 일관성(운영 정책 고정)

  • **fetch(내장)**은 각자 fetch를 어떻게 감쌀지에 따라 코드 스타일과 에러 처리 방식이 달라질 수 있어, 규모가 커질수록 편차가 누적될 수 있음

    ↔️ Axios는 인스턴스 1개로 요청/응답 정책을 중앙화할 수 있어, Devths처럼 화면/기능이 많은 프로젝트에서 팀 단위 일관성 확보에 유리함

• v1.13.2
  • 2025년 11월 4일에 릴리즈됨
• 이유
  • 최신 안정(stable) 배포 버전을 기준으로 선택하여, 버그 수정 및 안정성 개선을 반영할 수 있음
  • 운영 전략은 메이저는 유지하고, 패치/마이너 업데이트는 정기 반영하는 방식이 합리적이라고 생각함
    • 의존성 충돌 리스크는 낮추고, 안정성 패치는 따라가기 위함

• devths는 인증 기반 API 호출이 많고 파일 업로드 및 공통 에러 처리 요구가 커질 가능성이 높으므로, 인터셉터와 config 중심으로 네트워크 정책을 표준화할 수 있는 Axios를 API 통신 스택으로 선택함

---

• Vitest는 JavaScript/TypeScript 환경에서 단위 테스트 및 컴포넌트 테스트를 실행하기 위한 테스트러너임
• Node.js에서 테스트를 수행하며, DOM이 필요한 경우 jsdom과 같은 가상 브라우저 환경을 통해 UI 테스트를 지원함

• 테스트 실행 속도가 빠른 편으로, 개발 과정에서 반복 실행(수정-검증)을 수행하기에 적합함
• TypeScript 프로젝트에 자연스럽게 적용 가능하며, 타입 기반 코드 구조와의 결합이 용이함
• describe, it, expect 등 일반적인 테스트 작성 방식과 유사한 API를 제공하여 도입 난이도가 낮음
• mock, spy 기능을 통해 외부 의존성(API 함수, 유틸 함수 등)을 분리한 상태에서 로직 검증이 가능함
• React Testing Library와 함께 사용하여 컴포넌트 렌더링 및 사용자 상호작용 수준의 테스트를 구성할 수 있음

• devths는 화면 수가 많고 입력 규칙, 상태 변화, 조건부 렌더링이 반복적으로 등장하는 구조이므로, 단위/컴포넌트 테스트의 적용 가치가 높다고 판단함.
• 품질 편차와 회귀 위험을 줄일 수 있다고 판단함
  • 입력 검증 로직(닉네임 규칙, 길이 제한, 날짜 범위, 파일 제한 등)은 변경 가능성이 높고 누락 시 오류로 연결되기 쉬워 자동화 검증이 필요함
  • 로딩/에러/성공 상태에 따른 UI 분기, 인증 상태에 따른 화면 분기 등은 기능 추가 과정에서 쉽게 깨질 수 있어 테스트로 고정하는 편이 안정적임
  • 모달/탭/필터 등 UI 상태 전환 로직이 많아, 사용자 인터랙션에 따른 기대 동작을 테스트로 명확히 정의할 필요가 있음

항목	Vitest	Jest	Node 내장 test 러너
프론트 단위/컴포넌트 테스트 적합성	프론트 생태계 친화적 구성에 유리	널리 사용되나 설정이 늘어날 수 있음	기본 기능 위주로 UI 테스트 구성은 추가 설계 필요
TypeScript 적용	상대적으로 적용 부담이 낮은 편	가능하나 프로젝트 구성에 따라 설정 증가 가능	가능하나 관련 생태계 조합이 제한적
개발 중 반복 실행(속도/경험)	빠른 실행을 목표로 설계	케이스에 따라 실행 비용 증가 가능	단순하나 편의 기능은 제한적
mocking/spy	기본 제공(vi 기반)	기본 제공(jest 기반)	외부 도구 또는 직접 구성 필요
Devths 적합도	UI 로직/검증/상태 테스트에 적합	후보 가능(팀 경험에 따라)	단순 로직엔 가능하나 UI 중심에는 비효율적

• 프론트 단위/컴포넌트 테스트 구성의 표준화

  • Jest는 널리 사용되지만, 프로젝트 구성(ESM, Next.js, TS, JSX)과 맞추는 과정에서 설정이 늘어나고 테스트 환경(트랜스파일/런타임) 이슈를 팀이 계속 관리해야 할 가능성이 있음

    ↔️ Vitest는 프론트 생태계 친화적인 구성이 강점이라, Devths처럼 컴포넌트/훅/유틸 테스트 비중이 큰 프로젝트에서 테스트 환경을 비교적 단순하게 유지하기 유리함

• TypeScript 적용 부담과 유지보수 비용

  • Jest는 TypeScript 적용이 가능하지만, 변환 파이프라인(ts-jest, babel-jest 등)과 설정이 프로젝트 상황에 따라 복잡해질 수 있어 유지보수 비용이 커질 수 있음

    ↔️ Vitest는 TypeScript/ESM 기반 개발 흐름과의 결합이 비교적 자연스러워, 테스트 인프라를 “설정 중심”이 아니라 “코드 중심”으로 운영하기 유리함

• 개발 중 반복 실행 경험(속도/피드백 루프)

  • Jest는 케이스에 따라 실행 비용이 증가할 수 있어, 개발 중 테스트를 자주 돌리는 흐름에서 체감 속도가 떨어질 수 있음

    ↔️ Vitest는 빠른 반복 실행 경험을 목표로 설계되어, 기능 추가/리팩토링 과정에서 테스트를 자주 실행하는 Devths 개발 방식과 잘 맞음

• mocking/spy 도구의 일관성

  • Node 내장 test 러너는 기본 기능 위주라 mocking/spy, UI 테스트를 안정적으로 운영하려면 외부 도구 조합과 팀 내 규칙 설계가 추가로 필요함

    ↔️ Vitest는 vi 기반 mocking/spy를 기본 제공하므로, 테스트 코드 작성 방식과 도구 사용법을 팀 단위로 표준화하기 쉬움

• Devths 성격(UI 로직/검증/상태 테스트)과의 적합성

  • Node 내장 test 러너는 단순 로직 테스트에는 사용할 수 있으나, UI 중심 테스트를 운영하려면 추가 설계가 필요해 비효율이 커질 수 있음

    ↔️ Vitest는 UI 로직/검증/상태 테스트에 적합한 생태계 조합(React Testing Library 등)과 함께 쓰기 좋아, Devths의 단위/컴포넌트 테스트 도구로 선택하는 근거가 됨

• v4.0.16
  • 2025년 12월 16일에 릴리즈됨
• 이유
  • Vitest의 4.x 메이저 라인에서 최신 안정(Stable) 패치 버전을 사용하면, 동일한 메이저 버전 내에서 버그 수정/안정성 개선을 반영하면서도 큰 구조 변경(브레이킹 체인지) 위험을 상대적으로 낮출 수 있음

• Devths는 입력 검증, 조건부 UI, 상태 전환과 같은 프론트엔드 로직이 반복적으로 발생하는 구조이며, 이 영역은 회귀 위험이 높음
• Vitest는 단위/컴포넌트 테스트를 빠르게 반복 실행할 수 있고 TypeScript 및 React 테스트 구성과의 결합이 용이하므로, 컴포넌트 단위 테스트 도구로 채택하였음

• Promise 기반 HTTP 클라이언트
  • 브라우저/Node 환경에서 API 요청을 간단하게 보낼 수 있고, async/await로 흐름을 깔끔하게 작성 가능
• 인스턴스(instance) 기반 공통 설정
  • baseURL, timeout, 공통 헤더 등 프로젝트 표준 설정을 한 번에 묶어 재사용할 수 있어 API 코드가 정돈됨
• Interceptor(요청/응답 가로채기) 지원
  • 요청 전에 토큰 붙이기, 응답 에러를 공통 처리(로그인 만료, 토스트) 같은 “공통 로직”을 중앙에서 처리 가능
• 요청 옵션이 풍부함
  • params(쿼리), headers, timeout, responseType, 업로드(FormData) 등 실무에서 자주 필요한 옵션이 정리돼 있음

💡

Devths는 캘린더 / 게시판 / 채팅 / 챗봇 / OCR 업로드처럼 API 호출이 다양한 서비스라서, 화면마다 fetch를 제각각 쓰면 요청 방식과 에러 처리가 분산돼 유지보수가 어려워짐.

• Axios를 사용하면 API 호출 패턴을 표준화하고, 공통 처리를(토큰/에러/타임아웃) 한 곳에서 관리할 수 있음.

• (1) 공통 헤더/인증 처리 표준화

  • 로그인 이후 요청에 인증 정보가 필요하면, 인터셉터로 “자동 첨부” 패턴을 만들기 쉬움

• (2) 에러 처리 일관성

  • 401(인증 만료), 403(권한), 500(서버 오류) 등을 화면마다 따로 처리하면 UX가 들쭉날쭉해짐

    → Axios 인터셉터로 공통 에러 UX(토스트/리다이렉트)를 한 번에 묶기 좋음

• (3) 파일 업로드(OCR) 같은 요청이 존재

  • 채용공고 이미지/PDF 업로드는 multipart/form-data 처리가 필요하고, Axios가 이 흐름과 잘 맞음

(1) Axios 인스턴스 만들기 (공통 설정)

• baseURL: 백엔드 API 주소
• timeout: 너무 오래 걸리면 사용자 경험이 나빠지니 제한
• 공통 헤더 등

(2) Interceptor로 인증/에러 공통 처리

• 요청 인터셉터: 토큰(또는 세션 헤더) 자동 첨부
• 응답 인터셉터: 401이면 로그인 페이지로 유도, 토스트 등 공통 처리

항목	React Testing Library	React Test Renderer	Cypress/Playwright 컴포넌트 테스트
테스트 관점	사용자 관점(DOM 상호작용 중심)	컴포넌트 트리/스냅샷 중심으로 흐르기 쉬움	실제 브라우저에 가까운 환경에서 검증 가능
강점	접근성 기반 조회, 리팩토링 내구성, 팀 표준화 용이	단순 구조 검증/스냅샷에 빠르게 적용 가능	렌더링/스타일/브라우저 동작까지 더 현실적으로 확인
주의점	역할/라벨 설계(접근성)가 안 되어 있으면 테스트가 어렵게 느껴질 수 있음	스냅샷 남발 시 의미 없는 변경에도 테스트가 자주 깨질 수 있음	설정/실행 비용이 상대적으로 크고, 단위 테스트로는 과할 수 있음
추천 상황	대부분의 컴포넌트/단위 테스트 기본값	아주 단순한 렌더 구조 확인, 제한적 사용	UI 브라우저 특성/레이아웃/통합에 가까운 검증이 필요할 때

• 사용자 관점 테스트 적합성

  • React Test Renderer는 컴포넌트 트리/스냅샷 중심으로 테스트가 흐르기 쉬워, ‘사용자가 실제로 버튼을 누르고 화면이 바뀌는지’ 같은 핵심 시나리오 검증이 약해질 수 있음

    ↔️ 반면 React Testing Library는 DOM 상호작용(클릭/입력/화면에 보이는 텍스트)을 기준으로 테스트를 작성하게 유도하므로, Devths처럼 인터랙션이 많은 UI에서 테스트 목적이 명확해지고 유지보수성이 높아짐

• 리팩토링 내구성과 유지보수 비용

  • React Test Renderer의 스냅샷은 마크업 구조 변화에 민감해, 기능은 동일한데도 구조가 조금만 바뀌면 테스트가 자주 깨지는 문제가 발생할 수 있음

    ↔️ 반면 React Testing Library는 역할(role), 라벨(label), 텍스트 등 사용자에게 보이는 기준으로 조회하는 패턴이 강해, 내부 구현을 리팩토링해도 테스트가 상대적으로 덜 깨져 장기 유지보수 비용을 낮추는 데 유리함

• 테스트 범위 대비 실행/운영 효율

  • Cypress/Playwright의 컴포넌트 테스트는 실제 브라우저에 가까운 환경에서 검증할 수 있지만, 설정·실행 비용이 상대적으로 크고 단위 테스트로는 과한 수준이 될 수 있음(테스트 스위트가 커질수록 부담 누적)

    ↔️ 반면 React Testing Library는 대부분의 컴포넌트/단위 테스트를 효율적으로 커버하는 표준 조합으로 쓰기 좋아, Devths의 컴포넌트/로직 테스트 기본값으로 두기 적합함

• 팀 표준화 및 접근성(UX) 품질 관점

  • 단순 렌더 구조 검증에 치우치면, 접근성 속성(라벨/role)이나 사용자 흐름 중심의 품질 기준이 테스트에 반영되기 어려울 수 있음

    ↔️ 반면 React Testing Library는 접근성 기반 조회(getByRole 등) 사용이 자연스러워, 컴포넌트 개발 시 접근성·사용성 기준을 함께 맞추는 방향으로 팀 표준화를 만들기 용이함

• v16.3.1
  • 2025년 12월 15일에 릴리즈 됨
• 이유
  • 테스트 인프라의 핵심 의존성이므로, 동일 메이저 라인(16.x)에서 패치 버전까지 포함한 안정 버전을 사용해 버그 수정/안정성 개선 사항을 반영함
  • Devths는 React 19.x 및 Next.js 기반으로 개발되므로, 최신 React 환경에서의 동작 호환성과 타입 정의 일관성을 우선 고려함
  • 또한 Vitest/Jest 등 주요 테스트 러너 조합에서 널리 사용되는 버전 라인을 선택함으로써, 도입 및 운영 과정에서 발생할 수 있는 호환성 이슈와 예기치 않은 변경 리스크를 최소화함

• Devths는 상호작용과 상태 변화가 많은 화면이 중심이므로, 구현 방식이 아니라 사용자 경험(동작/표시/검증 규칙)을 기준으로 테스트를 구성하는 것이 유지보수에 유리함
• 따라서 컴포넌트/단위 테스트의 기본 도구로 React Testing Library를 채택하는 구성이 적합하다고 판단함

---

• 진짜 브라우저로 사용자 행동을 그대로 테스트
  • 클릭/입력/스크롤/페이지 이동처럼 사용자가 하는 행동을 자동으로 실행해서, “로그인부터 글 작성까지” 같은 시나리오를 통으로 검증할 수 있음
• 크로스 브라우저 지원
  • Chromium / Firefox / WebKit(사파리 계열) 환경을 한 번에 테스트할 수 있어, 특정 브라우저에서만 깨지는 문제를 잡기 좋음
• 자동 대기(auto-wait)로 플래키 테스트 감소
  • 요소가 준비될 때까지 기다렸다가 동작하는 방식이라(버튼이 뜨기 전에 클릭해서 실패하는 문제 등) E2E 안정성이 좋아짐
• 디버깅 도구가 강함(Trace/리포트/스크린샷/비디오)
  • 실패했을 때 왜 실패했는지를 추적하기 위해 Trace Viewer, HTML 리포트, 스크린샷/비디오 등을 남길 수 있음

💡

Devths는 기능이 많고 흐름이 길어서(캘린더/게시판/채팅/AI), 단위 테스트만으로는 “전체 동작”이 깨졌는지 놓치기 쉬움.

• Playwright E2E로 핵심 유저 시나리오를 통째로 자동 검증하면 배포 전 회귀(Regression) 버그를 줄일 수 있음.

(1) 로그인/인증 흐름 검증

• 로그인 성공/실패, 로그인 후 보호 페이지 접근 가능 여부(가드) 같은 흐름은 E2E에서 잡는 게 가장 확실함

(2) 게시판 핵심 시나리오

• 글 목록 진입 → 검색/필터 → 상세 진입 → 댓글 작성/삭제 → 좋아요 토글 같은 연속 흐름”검증

(3) 캘린더 + OCR 일정 자동 삽입

• 파일 업로드 → 처리 대기 모달 → 결과 초안 확인 → 저장 후 캘린더에 반영

  이런 비동기 + 모달 흐름은 E2E로 실제 사용자 관점에서 확인하는 게 효과적임

(4) 채팅(실시간)

• 최소한 “메시지 전송 UI가 깨지지 않는다”, “연결 끊김 시 안내가 뜬다” 같은 핵심 UX를 시나리오로 고정 가능

• 테스트 단위
  • auth.spec.ts: 로그인/로그아웃/보호 라우트
  • board.spec.ts: 글 목록/상세/댓글/좋아요
  • calendar.spec.ts: 일정 CRUD + 월/주 뷰 전환
  • ocr.spec.ts: 공고 업로드 → 처리 → 초안 → 저장
  • chat.spec.ts: 메시지 입력/전송(가능하면 테스트용 서버/목업 환경에서)
• 실패 디버깅
  • CI에서 실패하면 Trace Viewer로 클릭/네트워크/DOM 스냅샷을 타임라인으로 보는 방식이 가장 강력함

항목	Playwright	Cypress	Selenium(WebDriver)	Puppeteer
브라우저 엔진 범위	Chromium/Firefox/WebKit 지원 (Playwright)	주로 Chromium 계열 중심, WebKit은 별도/제한적(실험적 지원 맥락) (pptr.dev)	다양한 브라우저 지원(표준 기반) (Selenium)	Chrome/Firefox 자동화 중심
테스트 러너/병렬/리포트	공식 Test 러너 내장, 운영 기능 포함 (Playwright)	러너 제공(생태계 강함)	러너는 별도 조합 필요(프레임워크 선택)	러너라기보다 “브라우저 자동화 라이브러리” 성격
안정성(타이밍 이슈 대응)	locator/auto-wait 흐름 제공 (Playwright)	자체 대기/재시도 패턴 제공	대기/동기화 설계를 직접 잘 해야 함 (Selenium)	대기/동기화는 사용자가 직접 설계하는 비중 큼
Next.js와의 궁합	브라우저 기반 E2E에 적합(라우팅/SSR/쿠키 흐름 검증)	가능	가능(구성 부담 상대적으로 큼)	가능(하지만 E2E 운영 기능은 직접 구성 필요)

• 브라우저 커버리지와 크로스 브라우저 검증

  • Cypress는 주로 Chromium 계열 중심으로 운영되는 경우가 많아, Firefox/WebKit까지 같은 수준으로 폭넓게 검증하려면 제약이 생길 수 있음

    ↔️ 반면 Playwright는 Chromium/Firefox/WebKit을 공식적으로 지원하므로, Devths처럼 로그인(OAuth), 쿠키/세션, 라우팅 등 브라우저별 차이가 이슈가 될 수 있는 흐름을 한 도구에서 일관되게 확인하기 유리함

• E2E 운영 기능의 내장 여부(테스트 러너/리포트/병렬)

  • **Selenium(WebDriver)**은 다양한 브라우저를 표준 기반으로 지원하지만, 테스트 러너·병렬 실행·리포트 같은 운영 기능은 별도로 조합해야 하는 경우가 많아 초기 구성과 유지보수 부담이 커질 수 있음

    ↔️ 반면 Playwright는 공식 테스트 러너를 포함하고 병렬 실행/리포트 등 운영 기능을 기본 제공하므로, 팀 과제/프로젝트 환경에서 도입 후 바로 돌릴 수 있는 형태로 표준화하기 용이함

• 안정성(타이밍 이슈)과 유지보수 비용

  • Selenium이나 Puppeteer는 대기/동기화(요소가 뜨는 시점, 네트워크 완료 시점)를 사용자가 더 직접 설계해야 해서, 화면이 복잡해질수록 타이밍 이슈로 테스트가 불안정해질 가능성이 있음

    ↔️ 반면 Playwright는 locator 기반 auto-wait 흐름을 제공하여, DOM 렌더링/네비게이션/비동기 요청이 섞인 환경에서도 테스트 플래키(가끔 실패) 리스크를 줄이는 데 유리함

• Next.js 기반 서비스 흐름과의 적합성

  • Puppeteer는 브라우저 자동화 라이브러리 성격이 강해 E2E 운영(러너, 리포트, 병렬, 재시도 정책 등)은 직접 구성해야 하는 비중이 큼

    ↔️ 반면 Playwright는 브라우저 기반 E2E에 필요한 운영 기능을 갖춘 상태에서 Next.js의 라우팅/SSR/쿠키·세션/OAuth 리다이렉트 같은 흐름을 검증하기 적합하므로, Devths의 핵심 사용자 시나리오(랜딩→로그인→메인 진입 등)를 안정적으로 자동화하기에 적절함

• v1.57.0
  • 2025년 11월 25일에 릴리즈됨
• 이유
  • 공식 릴리즈 노트 기준으로 v1.57 라인이 제공되며(버그 수정/기능 개선 포함), 메이저 라인에서 최신 버전을 기준으로 문서/가이드와 동일한 흐름으로 운영하기 쉬움
  • E2E는 브라우저 실행 환경에 영향을 크게 받기 때문에, 동일 메이저 라인에서 최신 안정 버전을 기준으로 두고 패치 업데이트를 따라가는 전략이 일반적으로 운영 리스크를 낮춤

• devths의 핵심 플로우를 실제 브라우저에서 검증하기 위해 playwright를 E2E 테스트 도구로 선택함

---

• WebSocket = 연결
  • HTTP처럼 요청할 때마다 끊기는 게 아니라, 한 번 연결하면 계속 유지해서 서버와 클라이언트가 양방향으로 바로 메시지를 주고받을 수 있음
• STOMP = 메시지 주고 받는 규칙(프로토콜)
  • WebSocket 위에서 SEND(전송) / SUBSCRIBE (구독) 같은 표준 규칙으로 메시지를 다룸
  • Spring은 STOMP기반으로 destination(주소) 라우팅을 지원해서 채팅방/알람 같은 구조를 만들기 쉬움
• Pub/Sub 모델이라 채팅방에 딱 맞음

• 1:1 + 그룹채팅을 room(방) 하나로 통일 가능
  • 1:1도 참여자 2명인 방으로 보면 로직이 통일돼서 구현/유지보수가 쉬움
• 읽음 처리를 실시간 이벤트로 처리하기 좋음
  • 읽음은 상태 변화라서, STOMP 메시지로 READ 이벤트를 보내고 같은 방 토픽으로 뿌리면 UI 반영이 깔끔함
• 과거 대화는 REST로 가져오고, 실시간 수신/읽음만 WebSocket(STOMP)로 처리하면 안정적임

• Spring에서 STOMP/WebSocket이 표준 경로
  • Spring 공식 생태계가 STOMP 기반 메시징을 기본 흐름으로 지원함
  • 관련 레퍼런스/운영 패턴이 많아서 팀 기준으로 설명/유지보수가 쉬움
• STOMP는 표준 프로토콜 → 구조가 더 규칙적
  • 주소 기반이라 방/유저/알림 라우팅 규칙을 문서로 정리하기 쉬움
  • 나중에 메시지 브로커 연동 확장도 자연스러움
• Socket.io는 주력 생태계가 다름
  • Socket.io는 Node에서 강력한 편의 기능(룸/ACK/재연결 등)을 제공하지만, Spring 단독 서버에서 쓰면 주류 패턴이 아니기에 설명/유지보수 관점에서 이점이 줄어듦

• 정체
  • Socket.IO: 실시간 통신을 쉽게 해주는 라이브러리/프레임워크
  • STOMP: WebSocket 위에서 메시지를 주고받는 표준 프로토콜
• 통신 방식
  • Socket.IO: emit/on 이벤트 이름 기반
  • STOMP: SEND / SUBSCRIBE destiantion(주소) 기반 (Pub/Sub)
• 채팅방 처리
  • Socket.IO: room 기능 내장
  • STOMP: topic 구독으로 방을 표현(주소 설계로 구현)
• Socket.IO: Node 생태계에서 강함
• STOMP: Spring에서 표준 경로로 많이 씀

(1) destination 규칙

• 메시지 수신(구독): /topic/rooms/{roomId}/messages
• 읽음 수신(구독): /topic/rooms/{roomId}/reads
• 메시지 전송: /app/rooms/{roomId}/messages
• 읽음 전송: /app/rooms/{roomId}/reads

(2) 서버(Spring) 흐름(개념)

• 클라이언트가 /topic/... 를 subscribe
• 클라이언트가 /app/... 로 send
• 서버는 받은 메시지를 처리하고 /topic/... 으로 publish

(3) 클라이언트(프론트) 흐름(개념)

• STOMP client로 WebSocket 연결
• 방 진입 시 subscribe("/topic/rooms/{roomId}/messages")
• 메시지 보낼 때 send("/app/rooms/{roomId}/messages", payload)
• 읽음 처리 시 send("/app/rooms/{roomId}/reads", payload)
  • 상대는 /topic/rooms/{roomId}/reads 구독으로 즉시 반영

---

방식	장점	단점	Devths 적합도
STOMP + WebSocket	Spring 표준 패턴, pub/sub로 방/읽음 모델링 쉬움, 라우팅 규칙이 명확	구독/발행 개념에 익숙해져야 함	최적
Socket.IO	이벤트/룸/ACK/재연결 등 구현이 편함(특히 Node에서)	Spring 단독 서버에선 주류 경로가 아님(레퍼런스/운영 패턴 약해질 수 있음)	가능하지만 우선순위↓
순수 WebSocket	가볍고 자유도 높음	destination/구독/권한/라우팅을 직접 설계해야 해서 금방 복잡해짐	규모 커지면 부담
SSE	서버→클라 단방향 푸시가 간단	클라→서버 실시간 전송에 부적합(채팅엔 불리)	❌

• Devths는 Spring 기반이고 1:1/그룹 채팅 + 읽음 처리가 핵심이라, WebSocket(연결)+ STOMP(메시징 규칙) 조합이 가장 표준적이고 설계가 깔끔함
• 특히 채팅을 room 단위로 통일하고, 읽음을 lastRead(마지막으로 읽은 위치)로 처리하면 복잡도를 크게 줄이면서 UX를 만족시킬 수 있음