Description 회의 개요
날짜: 2025.12.02(화)
회의 안건
OAuth 도입 범위 및 인증 정책 논의
알림(실시간 여부, 백그라운드 알림) 구조 검토
태그(회원 태그·모임 태그) 활용 방식 정리
파일/이미지 업로드 방식 및 S3 비용·용량 논의
요구사항 문서·디자인 레퍼런스 기준 합의
도메인별 역할 분담 및 API 개발 일정·우선순위 논의
통계 필드(partyCount, joinCount) 정의 확인
회의 내용 요약
기본 정책 및 질문 정리
OAuth는 여러 소셜 중 Google만 우선 도입 .
태그는 룰 베이스가 아닌 자유 입력형 태그 로 사용.
사용자 전화번호는 활용처·개인정보 이슈를 고려해 컬럼 자체를 사용하지 않기로 결정(삭제) .
모임 장소는 현 스코프에서 시/동 정도의 문자열만 저장 , 좌표값(위도/경도)은 미사용.
모임 최대 인원은 10명이 아니라 12명으로 정정.
모임 수정은 참여 인원 0명일 때만 전체 필드 수정 가능 , 1명이라도 참여하면 수정 불가.
같은 시간대 복수 모임 참여는 제한하지 않고, 사용자 자율 관리 로 두기로 함.
모임 취소 시 취소된 모임은 조회되지 않도록 하고, 백엔드는 DB에서 완전 삭제해도 무방 한 방향으로 진행.
알림 구조 및 실시간/백그라운드 여부
모임 생성·취소 등에서 참여자에게 알림을 보내려면, 클라이언트 요청 없이 서버가 먼저 푸시해야 하는 케이스 가 존재.
이 경우 일반 HTTP 요청/응답만으로는 불가능하며, SSE(Server-Sent Events) 또는 **FCM(Firebase Cloud Messaging)**과 같은 기술이 필요하다는 설명을 공유.
SSE: 사용자가 애플리케이션에 접속해 있는 동안 TCP 연결을 유지하며, 요청 없이도 서버가 이벤트를 push 할 수 있는 방식.
FCM: 앱이 실행 중이 아니어도 카카오톡처럼 푸시를 받을 수 있는 백그라운드 알림 방식.
이번 프로젝트는 모바일 앱이 아니라 **모바일 웹(앱처럼 보이는 웹)**을 목표로 하므로, 백그라운드 푸시(앱 미실행 상태 알림)는 도입하지 않기 로 정리.
일단 “브라우저 내부에서만 표시되는 알림” 수준으로 범위를 좁히고, 어떤 이벤트에서, 누구에게, 어떤 알림이 필요한지 는 프론트엔드에서 케이스를 정리해 다시 백엔드에 전달하기로 함.
태그 구조·활용 방식 정리
현재 명세상 멤버 프로필의 관심사 태그 와 모임 카드/상세의 모임 태그 두 종류가 존재.
멤버 관심사 태그는, 현 시점에서는 프로필을 채우는 바이오/성향 정보에 가깝고 서비스 로직(추천·검색)에 직접 얹는 계획은 없음 으로 정리.
정리 필요 항목
멤버 태그와 모임 태그를 완전히 분리해 취급할지
태그를 검색/필터 기능에 실제로 사용할지 여부
위 두 가지를 프론트에서 정리해, **“멤버 태그 vs 모임 태그 구분”과 “태그 필터링 기능 존재 여부”**를 명시한 문서를 백엔드에 공유하기로 함.
파일/이미지 업로드 방
모임 생성은 텍스트와 이미지가 한 번에 성공/실패하는 트랜잭션 이 자연스럽고,
모임은 참여 인원이 생기면 수정이 막히므로, 모임 이미지만 자주 바꾸는 케이스도 많지 않을 것으로 판단.
반대로 프로필 이미지는 자주 변경될 수 있어, 프로필 전용 업로드 API 분리 가 합리적이라는 의견.
결론:
모임 생성은 현재 명세대로 단일 멀티파트 엔드포인트 유지 .
프로필 이미지는 필요 시 별도 엔드포인트로 분리.
프론트 팀 내부 논의 후 선호하는 방식이 명확해지면, 그에 맞춰 엔드포인트 구조를 조정하는 것도 가능.
개발 역할 분담 및 일정·우선순위
교육 커리큘럼 상 “이번 주 안에 API 전체 개발”이라는 러프한 목표가 있지만, 실제 프로젝트 관점에서는 중요 기능부터 순차 구현하는 것이 현실적 이라는 데 공감.
프론트는 Postman 등으로 워킹 데이터/Mock 을 활용해 화면 개발을 먼저 진행할 수 있으므로, 백엔드가 이번 주 내 모든 API를 완성할 필요는 없음.
프론트에서 도메인별 담당 기능 목록 + 각 기능의 희망 완료일 을 정리해 전달하면, 백엔드는 이를 기준으로 API 개발 순서와 일정을 재조정하기로 함.
MVP 발표 일정은 2025.12.16 으로 공유, 전체 기능보다 인증·핵심 모임 플로우 등 우선순위 높은 도메인 을 먼저 맞추는 방향으로 인식.
회의 내용 상세
기본 정책 및 기존 질문 정리
이전에 전달했던 질문 리스트를 기준으로, 인증·모임 정책 관련 항목을 하나씩 다시 확인하고 답변을 확정.
OAuth는 여러 소셜 로그인을 고려할 수 있으나, 구현 범위·일정 등을 고려해 Google OAuth만 우선 도입 하는 것으로 합의.
모임 태그는 사전에 정의된 목록이 아닌, 사용자가 직접 입력하는 자유 태그 로 사용하기로 결정.
사용자 전화번호 컬럼은
서비스에서 사용할 구체적인 활용처가 없고,
개인정보 수집·보관에 따른 이슈를 줄이기 위해아예 사용하지 않고 삭제 하는 방향으로 정리.
모임 장소 데이터는
현재 버전에서는 시/동 문자열만으로도 UX가 충분하다 고 판단하여
좌표값(위도/경도) 등은 스코프에서 제외.
모임 최대 인원은 처음 10명으로 기록되었으나, 논의 과정에서 12명으로 수정 되었고, 회의 중에 이 부분을 명확히 정정.
모임 수정 정책은
“참여 인원이 0명일 때는 자유롭게 수정 가능, 1명 이상이면 수정 불가”로 규칙을 단순화하고,
이 규칙을 기준으로 백엔드/프론트 모두 UI·검증을 맞추기로 함.
중복 시간대 모임 참여는
시스템에서 강제 제한하지 않고,
사용자가 스스로 일정 관리하는 방향으로 두기로 합의.
모임 취소 시 데이터 처리:
취소된 모임은 사용자 화면에서 조회되지 않아야 한다 는 요구를 기준으로,
백엔드는 경우에 따라 DB에서 완전 삭제하는 방식 도 허용하기로 함.
알림 구조·실시간 및 백그라운드 알림
“모임 생성/취소 시 참여자에게 알림”과 같은 기능은, 단순히 요청에 대한 응답이 아니라 서버가 먼저 이벤트를 던지는 구조 가 필요.
일반 HTTP 요청/응답 패턴에서는
클라이언트가 요청을 보내야만 응답을 받을 수 있으므로,
참여자들이 아무 행동도 하지 않은 상태에서 알림을 보내는 것은 불가능.
이를 해결하려면:
SSE(Server-Sent Events) :
클라이언트가 한 번 연결하면, 서버가 연결을 끊지 않고 유지하면서 이벤트를 push.
사용자가 애플리케이션(웹 페이지)에 접속해 있는 동안에만 실시간 알림을 받을 수 있음.
FCM(Firebase Cloud Messaging) :
카카오톡처럼 앱이 실행 중이 아니어도, OS 레벨에서 푸시를 수신하는 백그라운드 알림 구현에 사용.
이번 프로젝트는
앱을 PWA로 패키징해 배포하는 형태가 아니라, “모바일 웹에서 앱처럼 보이는 UI”를 만드는 것이 목표이므로, 백그라운드 푸시(앱 미실행 상태의 알림)는 필요하지 않다 고 정리.
알림 요구사항 정의 방향:
“어떤 이벤트에서, 누구에게, 어떤 형태로 알림이 필요한지”를 프론트에서 시나리오 단위로 정리해 전달하면, 백엔드가 SSE 등 추가 기술 도입 여부를 포함해 다시 검토하기로 함.
태그 구조 및 활용 계획
회의 중, 멤버 관심사 태그와 모임 태그가 모두 명세에 정의되어 있다는 점을 재확인.
다만, **멤버 관심사 태그는 프로필을 채우는 용도(바이오·성향 표현)**에 가깝고,
현 단계에서는 추천 알고리즘이나 고급 검색 기능과 직접 연계할 계획은 없음.
태그 활용도에 대해 합의해야 할 두 가지 포인트:
멤버 태그와 모임 태그를 완전히 별개로 볼지 여부 태그를 기반으로 하는 검색·필터 기능을 실제로 제공할지 여부
예시로, “동탄” 검색 시
모임 태그의 “동탄”만 조회할지,
멤버 태그의 “동탄”까지 함께 포함할지 논의가 필요.
결론적으로,
프론트에서 태그 기반 검색/필터 UX 시나리오와 멤버·모임 태그의 역할 을 정리해 문서화하고, 백엔드에 공유하면 스키마·쿼리 설계에 반영하기로 함.
파일/이미지 업로드 방식과 S3 비용
프론트 측 경험:
“이미지 선 업로드 → URL 반환 → 최종 데이터(게시글/모임) 전송 시 URL 포함” 패턴을 많이 사용해왔다는 점을 공유.
특히 외부 이미지 호스팅(이미지BB, 클라우디너리, Dropbox 등)을 활용해 비용을 줄이는 방안도 내부적으로 고민했었음을 전달.
백엔드의 현재 설계는,
모임 생성 시 JSON + 이미지 파일을 멀티파트로 한 번에 받는 단일 엔드포인트 기준.
백엔드가 제시한 관점:
모임 생성은 텍스트와 이미지가 같은 트랜잭션으로 처리되는 것이 자연스러움 .
모임은 참여 인원이 생기면 수정이 막히기 때문에, 이미지만 나중에 자주 바뀌는 패턴이 많지 않을 것.
반대로 프로필 이미지는 자주 변경될 수 있어, 프로필 전용 업로드 API 분리 가 더 적합.
S3 비용과 용량:
가장 저렴한 정책 기준
기본 월 비용: 약 1,500~2,000원
저장 용량: 약 50GB
주로 이미지 파일을 저장하는 수준이면 50GB로 충분할 것이라는 판단 공유.
파일 최대 크기를 제한하고 FE/BE 모두에서 검증하면, 비용 리스크는 크지 않을 것으로 보았음.
결과적으로,
모임 생성은 현행 멀티파트 단일 엔드포인트를 유지 하는 쪽으로 잠정 합의.프로필 이미지 등은 추후 필요 시 별도 엔드포인트로 분리 가능.
프론트에서 팀 내부 의견을 모아 다시 제안하기로 함.
문서·디자인 기준
실제 구현 기준:
최신 요구사항과 변경 사항은 **디자인 시안(Figma)**을 기준으로 삼기로 합의.
변경 발생 시
Figma를 먼저 업데이트하고,
백엔드에 직접 공유하는 흐름으로 맞추기로 함.
문서 관리 도구:
Notion은 프로젝트 수행 계획서 정도만 사용하는 수준이고,
개발 관련 요구사항·회의 정리는 GitHub 이슈/리포지터리 중심으로 관리 .
개발 역할·일정 조율
도메인 분담:
백엔드:
한 명은 모임 도메인,
다른 한 명은 인증/인가 + 멤버 도메인 담당.
교육 커리큘럼 상 목표:
“이번 주 안에 API 전체 개발”이라는 계획이 있으나, 실제 프로젝트 운영 측면에서는 현실적인 우선순위 기반 개발 이 필요하다는 데 의견 일치.
프론트는
Postman 등으로 워킹 데이터/Mock을 사용해 화면을 먼저 개발할 수 있으므로, 백엔드가 1주일 내 전체 API를 완성하지 않아도 진행 가능.
협업 방식:
프론트에서
도메인별 담당 기능 리스트 와각 기능별 **희망 API 제공 시점(날짜)**을 정리해 공유.
백엔드는 이를 참고해
후속 액션
알림이 필요한 구체 케이스 정리
어떤 이벤트에서
어떤 사용자에게
어떤 방식으로 알림이 필요한지
태그 활용도 정리
멤버 태그 vs 모임 태그를 어떻게 구분·사용할지
태그 기반 검색/필터 기능을 제공할지 여부
도메인별 기능·일정 정리
각 도메인(인증/인가, 멤버, 모임 등)별 담당 기능 목록과
기능별 희망 API 제공 날짜 를 정리해 공유.
You can’t perform that action at this time.
