Description 회의 개요
날짜: 2025.12.03 (수)
회의 안건
React Query 프리패치 위치(레이아웃 vs 페이지) 결정
App Router에서 페이지 / 레이아웃 / 클라이언트 컴포넌트 역할 정리
SSR·SEO·동적 메타데이터(generateMetadata) 처리 방식 합의프리패치 사용 여부 및 기준 정리
회의 내용 요약
프리패치는 “개별 레이아웃”에서 처리
프리패치가 필요한 페이지는 전용 레이아웃을 두고, 그 레이아웃에서 React Query 프리패치 + 하이드레이션을 수행하기로 정리.
페이지/컴포넌트 역할 분리 컨벤션 확정
page.tsx는 기본적으로 서버 컴포넌트 로 두고, 실제 폼·인터랙션은 별도 클라이언트 컴포넌트(use client)로 분리하는 방향 유지. (로그인/회원가입 등 포함)
모든 페이지에 프리패치를 쓰지는 않음
SSR만으로도 SEO는 충분히 확보 가능하고, 프리패치는 “초기 쿼리 캐시 + 동적 메타데이터를 같이 다루고 싶을 때”에만 사용하기로 정리.
동적 메타데이터는 generateMetadata에서 직접 API 호출
상세 페이지 등은 generateMetadata에서 API를 직접 호출해 타이틀/디스크립션을 만들고, 이 부분에는 React Query를 쓰지 않는 것으로 합의.
팀 컨벤션:
프리패치용 컴포넌트가 page.tsx를 덮어쓰지 않도록, 프리패치를 레이아웃으로 빼서 “페이지 파일은 실제 페이지”라는 이름과 역할을 지키는 쪽으로 정리.
날짜·시간 선택 UI – 모달 + 라이브러리 활용 쪽으로 가닥
모바일 친화 레퍼런스(하단 드로어형)를 검토했으나, PC·QHD 환경에서 화면 하단 드로어는 사용성이 떨어질 수 있다는 우려.
최종적으로: 정중앙 모달 형태의 날짜·시간 선택 UI 로 진행하기로 방향을 잡음.
완전 커스텀 캘린더 구현은 공수 부담이 크므로, MUI Date/DateTime Picker 등 검증된 라이브러리 활용 을 전제로 디자인을 조정하기로 함.
인풋 높이·에러 메시지·토스트 색상
검색/친구 추가용 인풋은 별도 작은 사이즈를 사용하고, 에러 발생 시 하단에 에러 텍스트가 생기면서 일정 수준의 레이아웃 시프트는 허용 .
친구 검색 모달: “사용자를 찾을 수 없음” 메시지는 모달 안에서 처리하고, 사용자가 같은 모달 내에서 재시도 가능하도록 설계.
회의 내용 레이아웃 vs 페이지: 프리패치 위치 결정
외부 블로그·질문 사례를 참고하면서, 페이지별 개별 레이아웃에서 프리패치를 수행하는 패턴 을 검토.
App Router에서 레이아웃은 페이지보다 먼저 실행되므로, 레이아웃에서 프리패치를 하면:
페이지 진입 전에 필요한 데이터를 미리 가져올 수 있고
하위 페이지에서는 바로 useQuery를 사용할 수 있는 장점이 있다는 점을 재확인.
결론:
루트 레이아웃은 글로벌 Provider / 공통 UI 정도만 담당.
프리패치가 필요한 라우트 에 한해 개별 레이아웃을 두고, 그 레이아웃에서 프리패치 + 메타데이터 설정을 처리하기로 합의.
페이지 / 클라이언트 컴포넌트 역할 정리 (로그인 예시)
로그인 페이지를 예로 들어 구조를 다시 정리:
app/login/page.tsx
서버 컴포넌트로 두고, generateMetadata 등 메타데이터 설정을 담당.
실제 폼 렌더링은 별도 컴포넌트에 위임.
app/login/_components/LoginForm.tsx
use client 선언.useState, useForm, useQuery 등 클라이언트 로직을 모두 이곳에 배치.
이렇게 하면:
메타데이터는 서버에서 처리할 수 있고
Form은 클라이언트에서 자유롭게 상태를 다룰 수 있어 역할 분리가 명확 해진다는 데 의견 일치.
개별 레이아웃 도입 범위와 구조
구조 논의: RootLayout → Route별 Layout → Page 계층에서 어디까지 중첩할지 논의.
결론:
루트 레이아웃: Provider·공통 레이아웃(헤더/푸터 등) 역할.
각 라우트용 레이아웃: 필요한 경우 한 단계까지만 중첩해서 프리패치를 수행.
그 아래에 또 다른 레이아웃을 중첩하는 패턴은 이번 프로젝트에서는 사용하지 않기로 함.
이유:
레이아웃이 깊게 중첩되면 데이터 흐름·하이드레이션 구조를 이해하기 어려워지고
현재 프로젝트 요구사항에서는 루트 + 1단계 레이아웃이면 충분하다고 판단.
React Query 프리패치와 SSR·SEO 개념 재정리
멘토 설명 및 문서 내용을 바탕으로 다음 내용을 다시 정리:
React Query의 프리패치 + 하이드레이션 패턴은 사실상 “React Query 스타일의 SSR”을 구현하기 위한 도구.
서버에서 쿼리 클라이언트를 생성 → 데이터를 프리패치 → 직렬화해 HTML과 함께 내려보내고 → 클라이언트에서 하이드레이션 하면서 캐시를 이어받는 방식.
결국 캐시는 클라이언트 쪽에만 살아 있고 , SSR은 “초기 응답 시점”에만 작동한다는 점을 다시 확인.
상세 페이지·동적 메타데이터 정책
상세 페이지를 예로, 어떤 경우 프리패치를 쓸지 논의:
상세 페이지는 개별 모임 정보가 검색 대상이 될 수 있어 **SEO·미리보기(메타 태그)**가 중요.
하지만 SEO 관점에서는 “SSR이면 충분”하고,
프리패치를 하지 않아도 서버에서 API를 직접 호출해 메타데이터를 구성할 수 있다.
합의 사항:
동적 메타데이터 (예: 모임 제목/설명)는 generateMetadata에서 API를 직접 호출해서 구성.이 함수 안에서는 React Query를 사용하지 않고, 그냥 서버에서 fetch 호출로 처리.
프리패치는 “초기 렌더에서 쿼리 캐시를 미리 만들어두고 싶을 때”만 선택적으로 사용.
팀 컨벤션 및 멘토링 질문
용어·구조 컨벤션:
“페이지는 페이지답게 두자”는 의견에 따라,
프리패치용 파일을 억지로 페이지 역할까지 맡기지 않고
필요한 경우 레이아웃으로 분리 해서 맡기는 방향으로 정리.
프리패치 적용 기준(어떤 페이지에 쓸지)에 대해서는:
상세 페이지 등 데이터 볼륨·SEO 중요도·초기 로딩 체감 을 기준으로 케이스 바이 케이스로 결정.
날짜·시간 선택 UI 논의
모바일 레퍼런스(하단 드로어형)
모바일에서는 매우 직관적이고 예쁘지만, PC·QHD/4K 모니터에서는 화면 하단에 작게 떠 사용성이 떨어질 우려 제기.
구현 난이도 이슈
완전 커스텀 캘린더 + 시간 선택 UI를 0부터 구현하면, 과거 경험상 캘린더만 1주일 이상 소요 된 사례가 있어 공수 부담이 큼.
날짜와 시간, 분 단위, 과거 시간 비활성화, 범위 선택 등까지 고려하면 로직 복잡도가 크게 증가.
대안 검토
모달 방식 : 중앙 정렬 모달로 띄우면 모바일·PC 모두에서 거리가 적당하고, 시선도 중앙에 모일 수 있어 실용적.MUI Date/DateTime Picker :
날짜·시간·분, AM/PM까지 지원하는 컴포넌트가 이미 존재.
모바일 버전의 탭(Date/Time) 구조가 현재 서비스에 가장 적합해 보인다는 의견.
MUI가 다소 무겁다는 단점은 있지만, 전체 프로젝트 스케일을 고려하면 “한 개 컴포넌트 추가” 수준은 수용 가능하다는 판단.
시간 단위
시/분을 모두 선택 가능하도록 하되, UX를 고려해 최소 30분 단위 또는 10분 단위 등으로 제한하는 방안을 논의.
과거 시간 비활성화는 추가 기능 으로 보고, 초기에는 선택 가능하되
제출 시점에 현재 시각과 비교해 브라우저/서버에서 검증하는 방식도 고려.
결론(방향성)
모달 형태의 날짜·시간 선택 UI 를 사용.디자인은 MUI DateTime Picker 모바일 버전(날짜/시간 탭) 레퍼런스를 기반으로 잡되, 색·톤앤매너는 서비스에 맞게 커스터마이징.
구현 시 완전 커스텀 대신 라이브러리 기반 + 최소한의 스타일·행동 커스터마이징 방향으로 진행.
인풋·에러 메시지·토스트 UX
검색/친구 추가 인풋
작은 인풋 컴포넌트는 별도 스타일로 두고, 에러 발생 시 아래에 빨간 에러 텍스트를 노출.
에러가 생길 때 높이가 달라지는 레이아웃 시프트는 용인 하기로 함.
친구 검색 모달 UX
잘못된 닉네임/ID로 검색 시
모달을 닫지 않고, 모달 내부에서 “사용자를 찾을 수 없습니다” 메시지를 보여주고
같은 모달 내에서 재입력·재검색이 가능하도록 설계.
You can’t perform that action at this time.
