[회의록]

[yoorli]

회의 개요

• 날짜: 2025.11.25(화)
• 회의 안건
  • MSW 폴더 구조 및 핸들러 위치 정의
  • Providers, hooks, API 모듈 폴더 구조 정리
  • React Query(쿼리 키, 프리패치) 패턴 논의
  • TypeScript 타입 관리 방식 논의
  • 백엔드 API 기능 우선순위 정리
• 추가 참고 자료
  • 프로젝트 수행 계획서

---

회의 내용 요약

1. MSW 구조

   • src/mocks 아래에 endpoints/ 폴더를 두고 엔드포인트별 핸들러 관리
   • browser, handlers, index 등 설정 파일은 src/mocks 아래에 배치

2. Providers / hooks / stores 구조

   • Providers 인덱스 파일은 index.ts로 export
   • 상위 Providers 컴포넌트에서 모든 Provider 조합
   • hooks, stores도 폴더 내 index.ts에서 export하는 패턴으로 통일

3. React Query 설계

   • src/hooks/**에서 React Query 훅 관리
   • src/lib/query-client.ts에서 QueryClient 및 React Query 설정 관리
   • src/lib/query-key/**에서 도메인별 쿼리 키 정의

4. 타입 관리

   • src/types/ 폴더를 만들어 엔드포인트별 타입 파일 관리
   • 필요 시 global.d.ts를 통해 전역 타입 선언

5. 기능 우선순위

   • 로그인/회원가입 → 회원 정보 → 모임 CRUD → 모임 참여/조회
   • 채팅(모임 단톡, 1:1), 친구 CRD는 추가 기능으로 후순위

6. 추가 기능 후보

   • 채팅이 어려울 경우 지도 기반 기능을 대안/보완 기능으로 검토

7. 이미지 관리

   1. SVG 스프라이트는 추후 재논의
   2. public 경로에 저장되는 이미지는 WebP 형식의 이미지만 저장

8. R&R

   기능	유형	담당
   로그인, 회원가입	인가/인증	율리
   회원 정보 조회, 수정	마이페이지	환욱
   모임 생성, 조회, 수정, 삭제	모임	소망
   모임 참여 신청, 참여 중인 모임 조회	모임 참여	민서
   친구 추가, 조회, 삭제	친구	치영

---

회의 내용

MSW 폴더 구조 정리

• 기존에 MSW 관련 파일(핸들러, 브라우저, 엔트리 등)이 API 폴더와 섞여 있어 헷갈릴 수 있다는 의견

• API 라우트(api/)와 MSW 목 핸들러가 섞이면 실제 백엔드 라우트와 혼동될 수 있음

• 결론

  • mocks 폴더 안에 endpoints/ 디렉터리를 두고, 엔드포인트별 핸들러 파일 관리

Providers 구조

• 현재 구조

  • 레이아웃과 같은 위치에 Providers 역할의 컴포넌트가 있고, 하위에 개별 Provider 파일들이 존재
  • 인덱스 파일을 tsx가 아닌 ts로 두고, 단순 export 전용 파일로 사용

• 최상위 Providers 컴포넌트(예: ProvidersParent)에서 모든 Provider를 합쳐 children을 감싸고, 레이아웃에서는 이 컴포넌트만 사용하는 구조가 더 이해하기 쉽다는 의견

• 결론

  • Provider 관련 인덱스 파일은 index.ts를 export 전용으로 사용
  • 실제 Provider 조합은 상위 Providers 컴포넌트(하나의 파일)에서 처리
  • 레이아웃에서는 한 줄 import로 모든 Provider를 감싸도록 정리

hooks 및 store

• hooks, store 등도 동일한 패턴으로 관리하자는 의견

  • 예:
    • hooks/useSample1.ts, hooks/useSample2.ts
    • hooks/index.ts에서 useSample1, useSample2를 모두 export
    • 상위 폴더 최상단 index.ts에서 다시 한 번 모아서 export

• 결론

  • hooks, store 등은 모두 index.ts re-export 패턴으로 통일
  • 파일이 하나뿐이어도 향후 확장 시 수정 비용 감소를 생각해 패턴 통일

React Query API 모듈 구성 방식

• 초기 설계

  • 엔드포인트별 파일 하나에 아래 내용을 모두 포함:
    1. 순수 호출 API 함수 (fetcher, axios 호출 등)
    2. useQuery / useInfiniteQuery 등 클라이언트 훅
    3. 서버에서 사용할 prefetch 함수
  • 공통적으로 사용하는 쿼리 키는 별도 객체(queryKeys)로 관리하고, 이를 가져다 쓰는 구조

• 쿼리 키 관리

  • src/lib/query-key/query-key-product/index.ts 등에서 도메인별 쿼리 키를 객체 형태로 정리

• api/ 폴더에 React Query 훅과 프리패치 로직을 넣으면:

  • Next.js 기준 app/api 라우트와 의미가 섞일 수 있음
  • 일반적으로 api/에는 axios 인스턴스, 서버 라우팅 코드 등을 두는 경우가 많음

• 다른 프로젝트 예시

  • api/axiosInstance.ts에서 인스턴스를 정의
  • 실제 useGetXXX, usePostYYY 등의 훅은 hooks/ 또는 features/xxx/api 등에서 관리

• 결론

  • React Query 관련 로직(훅, 프리패치 등)은 hooks/ 폴더로 이동
  • api/ 폴더는 공통 HTTP 클라이언트에만 사용
  • 기존에 API 폴더에 넣어두었던 React Query 관련 코드는 마이그레이션

Prefetch 패턴: HydrationBoundary / 훅 내부 프리패치

• 기존 패턴

  • 페이지에서:
    1. 서버에서 prefetchQuery 실행
    2. HydrationBoundary로 감싸고 dehydratedState 전달
    3. 하위 컴포넌트에서 useQuery 사용

• 대안 패턴

  • useGetIssues 같은 커스텀 훅 내부에서:
    • useQuery + useEffect를 사용해 프리패치까지 훅 내부에 포함
    • 페이지 컴포넌트는 해당 훅만 호출하면 프리패치 + 쿼리를 동시에 처리

• 결론

  • React Query 프리패치는 커스텀 훅 내부에서 처리하는 패턴으로 마이그레이션

TypeScript 타입 관리 방식

• 엔드포인트별로 타입을 분리해 관리하는 것이 유지보수에 유리하다는 의견

• 컴포넌트/페이지용 타입

  • 각 컴포넌트/페이지 내부에서 interface Props 등으로 정의하는 패턴 유지

• 폴더 구조

  • src/types/ 폴더 생성
    • 예: src/types/product.ts, src/types/user.ts 등 엔드포인트/도메인 기준으로 분리
    • API 응답 타입은 여기서 관리
  • 전역 타입
    • 필요 시 types/global.d.ts 파일을 루트 혹은 types 폴더 하위에 두어 전역 선언

• 결론

  • 엔드포인트별 타입 파일을 types 폴더로 분리
  • 컴포넌트/페이지용 타입은 로컬에서 정의
  • 구체적인 타입 파일 구성 및 네이밍은 추후 정리 후 공유

SVG 스프라이트 방식 논의

• SVG 스프라이트: 아이콘들을 하나의 SVG 파일에 모아놓고 필요할 때마다 꺼내 쓰는 방식

  • 스프라이트는 아이콘을 한 파일에 몰아 넣고 한 번만 요청
  • 한 번 받아오면 브라우저 캐시에 들어가 이후 페이지 전환에서도 다시 요청하지 않아도 되는 경우가 많음
  • 예: public/sprite.svg 에 스프라이트 파일을 두고 사용

• 캐시/배포 관리가 까다롭고 일부 브라우저에서 제약이 있을 수 있음

• 타입/자동완성/디버깅이 불편함

• 결론

  • SVG 사용 전략은 추후 별도 연구 후 적용(아이콘/일러스트 등 활용 방안 포함)

추가 기능 아이디어 (지도, 알림 연계)

• 채팅 기능이 도입되지 않거나 일정상 어려울 경우, 지도 기반 기능을 추가 기능 대안으로 검토

• 아이디어

  • 알림 영역 옆에 “지도 전환” 버튼 배치
  • 버튼 클릭 시 메인 화면이 지도 뷰로 전환
  • 모임 위치, 참여 현황 등을 지도에 시각화하는 방향으로 활용

BE API 기능 우선순위 및 도메인 정리

• 핵심 도메인/기능

  • 인증/인가
  • 회원 관리
  • 모임 관리
  • 채팅
  • 친구 관리

• BE API 기능 우선순위 (초안)

  1. 로그인, 회원가입
  2. 회원 정보 조회/수정 (MyPage)
  3. 모임 생성, 조회, 수정, 삭제 (CRUD)
  4. 모임 참여 신청, 참여 중인 모임 조회
  5. 채팅 (모임 인스턴스 단톡, 친구 1:1 채팅)
  6. 친구 추가, 조회, 삭제 (CRD)

• 결론

  • MVP 기준으로 ①~④를 최우선으로 구현
  • ⑤~⑥(채팅, 친구 기능)는 일정에 따라 추가 기능으로 점진적 도입

---

후속 액션

• MSW, Providers, hooks, React Query, 타입, 테스트 구조를 반영한 폴더 구조 및 코드 예시 정리
• SVG 활용 방식 확정
• 디자인/기획 확정본(Figma 등)을 기준으로 API 명세와 타입을 최종 정렬
• 기능 우선순위(로그인/회원가입 → 모임 → 채팅/친구)를 기준으로 개발 계획 재정리