Description 회의 개요
날짜: 2025.12.01(월)
회의 안건
폼 라이브러리 및 폼 설계 방식 결정(TanStack Form 도입)
HTTP 클라이언트, 에러 처리, 토큰 정책(인증/인가) 정리
OAuth 소셜 로그인 및 외부 계정(AWS·OAuth 앱) 관리 방식 합의
모임·멤버 도메인(태그, 전화번호, 장소, 인원, 수정/취소 규칙) 기획 정리
리스트/카드 UI 구조 및 태그·주소 노출 규칙 확정
회의 내용 요약
폼 라이브러리
React Hook Form 대신 TanStack Form 을 사용하며, 필드 단위 분리·재사용을 기준으로 폼을 설계
HTTP 클라이언트 / 에러 처리
HTTP 클라이언트는 axios로 통일 하고, 도메인별 ~Service 레이어를 둠
상태코드별 세부 에러 클래스를 다수 두지 않고, AxiosError + status 코드 중심으로 단순하게 관리
OAuth 및 외부 계정
Google OAuth 로그인은 도입하는 것 을 전제,계정 하나로 통합 관리
모임·멤버 도메인 기획
전화번호는 수집·표시하지 않으며 , 모임 최대 인원은 12명
참가자가 1명이라도 생기면 모든 필드 수정이 불가 하고, 참가자 0명일 때만 수정 가능
모임 취소 시 이번 프로젝트에서는 DB에서 삭제 할지 말지는 백엔드팀과 회의로 결정, 참가자에게 “모임이 삭제되었습니다” 알림만 보냄
리스트/카드 UI
카드 레이아웃은 한 화면에 여러 카드가 보이는 피드형(오른쪽안) .
카드 제목은 최대 2줄 + 말줄임표 처리 , 주소는 시/동 수준까지만 표시
태그는 자유 입력이지만 태그당 8자, 최대 9개 로 제한
카드에서는 태그를 한 줄만 노출 하고, 넘치는 태그는 … 또는 +n 형태로 축약
회의 내용
폼 라이브러리 및 폼 아키텍처
React Hook Form과 TanStack Form을 비교했으며, RHF의 Controller, watch 패턴, 타입 복잡성, 컴포넌트 분리 시 불편함을 검토
TanStack Form은 createForm 기반 구조와 필드 단위 구독 방식으로 컴포넌트 분리·재사용성에 강점이 있어, 기본 폼 라이브러리로 TanStack Form을 사용하기로 결정
닉네임 등 공통 필드 컴포넌트를 여러 화면에서 재사용하는 방향으로 설계
필드별 subscribe로 전체 리렌더 없이 동작하는지에 대해서는 별도의 PoC를 진행해 확인
HTTP 클라이언트, 에러 처리
HTTP 클라이언트 & API 구조
fetch vs axios를 비교, 기존 경험(코딩테스트 사이트, 상용 서비스 레퍼런스)을 고려해 axios를 프로젝트 전반의 HTTP 클라이언트로 사용 API 구조는 다음과 같이 정리
api/core
공통 Axios 인스턴스 정의: baseURL, 공통 header, interceptor 설정 위치
api/services/{도메인}Service
예: MeetingService, MemberService, AuthService 등
도메인별 엔드포인트 함수들을 묶어 관리
api/index
서비스 네이밍은 ~Service 접미어
에러 처리
HTTP 상태코드별 BadRequestError, ForbiddenError 등 수십 개의 커스텀 에러 클래스를 두는 패턴은 현재 서비스 규모에는 과하다고 판단
우선은 다음과 같이 진행
기본적으로 AxiosError와 HTTP status 코드만으로 에러를 구분 .
필요하다면 도메인 단에서 얇은 래퍼(ApiError 수준) 만 추가
네트워크 에러, 인증/권한 관련 공통 UX(토스트/모달)는 추후 공용 UI 설계 시 재논의
인증 및 외부 계정 관리
OAuth 기반 소셜 로그인(Google, Naver 등) 도입 여부를 논의
실 서비스 관점에서 Google 기준 OAuth 로그인은 도입하는 것 으로 정리
AWS, OAuth 앱 등록 등 외부 콘솔 계정은 여러 개인 계정으로 흩어지지 않도록 계정 하나로 통합 관리
모임·멤버 도메인 기획
태그 정책
“룰 베이스(미리 정의된 태그 세트)” vs “자유 작성 태그”를 비교, 사용성·유연성을 고려해 자유 작성 태그 방식 을 채택
전화번호 수집
기획 문서상 전화번호 관련 항목(3번)의 필요성을 재검토한 결과, 개인정보 및 규제 리스크를 고려해 전화번호를 수집·표시하지 않기로 결정
해당 기획 항목은 문서 상에서도 삭제/비활성 처리할 예정
장소(위치) 정보
모임 장소를 지도 서비스와 연동할지, 단순 문자열로 둘지 논의
지도(Naver Map 등)와 연동하는 경우:
DB에는 시/동(타운) 수준까지만 저장·표시 (예: 화성시 삼척동, 경기도 등 상위 광역 단위는 생략 가능)
정확한 필드 구조(city, town 등)와 UX는 백엔드/디자인과 추가 조율한다.
모임 최대 인원
최대 인원을 10명으로 할지, 12명으로 늘릴지 논의
12명(한 줄 3명 × 4줄) 기준이 디자인상 예쁘다는 의견이 있었음, 인원 수에 따라 줄 수가 달라지며 레이아웃이 깨질 가능성이 있음
모임 수정 규칙
호스트가 모임 정보를 어디까지, 언제까지 수정할 수 있는지 논의
최종 규칙:
참가자 0명일 때
모임의 모든 필드 수정 가능 (제목, 시간, 장소, 인원 등).
참가자 1명 이상일 때
모임 정보는 수정 불가 .
수정 버튼을 비활성화하거나 숨겨서 “보기 전용” 상태로 전환
모임 취소/삭제
“모임 취소 시 취소된 모임도 조회 가능하게 할지”에 대해 논의
일반 상용 서비스라면 취소 모임도 통계/분석을 위해 soft-delete로 남긴다는 점에 모두 동의함
다만 이번 프로젝트는 토이 프로젝트 성격이 강하므로:
호스트가 모임을 취소하는 경우, DB에서 삭제하는 방식 을 허용하기로 함
백엔드 팀과 상의 후 결정하기로 함
사용자 UX:
모임이 취소/삭제되면 참가자에게 “모임이 삭제되었습니다” 알림 을 발송
이후 모임 목록에서는 해당 모임이 더 이상 보이지 않음
리스트/카드 UI 및 태그·주소 노출
카드 레이아웃
한 줄에 카드 1개(정보량 많음, 스크롤 김) vs 여러 카드(그리드, 한눈에 많이 보임)를 비교
피드형 UI를 지향하는 컨셉에 맞춰 한 화면에 여러 카드를 보여주는 오른쪽 디자인안 을 채택
제목 노출
카드 제목은 최대 2줄 까지 노출.
2줄을 초과하면 말줄임표(…) 처리
중요한 정보가 잘리지 않도록, 실제 카피 작성과 디자인 단계에서 제목 길이를 함께 조율
태그 노출 규칙 (변경 이력 반영 최종안)
초기에는 태그 1개당 12자, 카드 내 최대 3개 등 여러 안을 검토
폴드 디바이스와 같이 폭이 매우 좁은 화면(275px 수준)에서도 태그가 한 개도 안 보이는 상황을 막기 위해, 최종적으로 다음과 같이 정리
태그 작성 규칙
사용자 입력은 자유
시스템상 태그당 최대 8글자 , 최대 9개 까지 허용
카드(리스트) 노출 규칙
태그는 한 줄만 노출
한 줄에 다 들어가지 않는 태그는:
마지막 태그 뒤를 … 혹은 “+n” 형태로 축약(표현 방식은 구현 시 확정).
상세 페이지
태그를 모두 표시하며, 줄 수 제한 없이 필요 시 자동 줄바꿈을 허용
주소 노출
카드에서 주소는 시/동 수준까지만 표기
상세 주소 전체를 카드에 노출하면 카드 높이가 불규칙해지고 레이아웃이 깨질 수 있어, 상세 정보는 상세 페이지 중심으로
후속 액션
TanStack Form 필드 단위 구독 방식 PoC
Axios 인터셉터 기반 토큰 주입 방식, 토큰 저장 위치·만료 정책 상세 설계
지도/장소 입력 UX와 DB 스키마(시/동 기준 필드) 확정
태그 축약 UI 세부 표현(… vs +n)을 Figma 시안에서 확정
모임 취소 시 알림 발송 타이밍 및 문구 정의
You can’t perform that action at this time.
