[12/09] 프론트–백엔드 3차 회의

[yoorli]

회의 개요

• 날짜: 2025.12.09(화)
• 회의 안건
  • 프론트/백엔드 개발 진행 현황 공유
  • API 명세 변경 사항 및 확정 일정 논의
  • 모임 관련 필드(joinedCount, 태그 정책 등) 정의 정리
  • 이미지 업로드 방식 및 S3 디렉터리 구조 결정
  • 알림 기능 구현 방식(SSE vs 폴링 등) 논의
  • 모임 종료 시간(endTime) 처리 방식 협의

---

회의 내용 요약

1. 인증/인가는 완료, 유저 도메인은 이번 주 내 마무리 예정, 모임 관련 API를 토요일까지 끝내는 것이 목표
2. joinedCount 필드는 isJoined와 의미가 겹쳐 제거, 태그는 단순 텍스트/필터링 등 정책 정리 필요
3. 공통 응답 스펙의 필드는 백엔드가 내부 정리 후 다시 공유
4. 모임 생성 시 이미지 처리 방식은 “이미지 먼저 업로드하여 URL을 받은 뒤, 모임 생성 JSON에 URL을 포함해 보내는 방식”으로 정하고, S3 구조는 규모를 고려해 도메인/그룹 디렉터리 없이 단순 경로(After2안)로 가기로 함.
5. 이미지 업로드 API는 한 개 엔드포인트를 유지
6. 알림 숫자 증가를 SSE로 처리할지, 폴링/진입 시 패치로 처리할지는 재논의, SSE는 연결 유지·안정성 이슈가 있어 재검토.
7. 모임 종료 시간(endTime)은 nullable 필드로 처리.

---

회의 내용

프론트/백엔드 진행 현황 및 일정

프론트엔드

• 메인 화면, 스케줄러 화면, 모임 생성 화면, 마이페이지, 팔로잉 유저 목록 등 기본 기능에 해당하는 화면 UI가 대부분 구현된 상태
• API 명세와 실제 응답이 확정되면, 곧바로 연동 작업에 들어갈 수 있는 수준

백엔드

• 인증/인가 도메인은 이미 개발 완료.
• 유저 도메인 API는 이번 주 내 개발 완료를 목표로 진행 중이며, 구현되는 대로 프론트에 바로 알릴 예정.
• 모임 관련 남은 API는 약 7개 정도로 파악하고 있으며, API 수정·추가 및 명세 최신화를 포함해 이번 주 평일~토요일까지 모두 마감하는 목표로 설정.
• MVP 일정에 맞춰 백엔드 API도 완성될 수 있도록 진행하기로 함.

API 명세 변경 사항 및 공통 응답 스펙 논의

API 명세 변경 범위

• 유저 쪽 명세는 현재 기준으로 큰 문제 없을 것 같음.
• 모임 쪽은 아직 검토가 덜 되어 있어 내일까지 정리 후 확정된 스펙 전달

공통 응답 형식

• 백엔드에서는 공통 응답 타입을 내부에서 다시 정리한 뒤,
  • 필드명(code vs status)과 타입(숫자/문자열)을 일관되게 맞춰서 재공유

모임 필드: joinedCount 제거 및 태그 정책

joinedCount 필드

• joinedCount는 중복 필드에 가깝다는 의견에 동의, 삭제하기로 결정.

태그 정책

• 단순히 문자열 배열로만 저장할지,
• 향후 태그 기반 필터링/검색까지 고려해 구조를 설계할지 등이 아직 명확하지 않음.
• 모임 명세 정리 내에 포함해 주기로 함.

이미지 업로드 방식 및 S3 구조 결정

요구사항·전제

• 모임에는 썸네일/이미지가 필요하고,
• 프로필에도 이미지가 들어갈 예정이므로 S3에 다양한 이미지가 쌓이게 됨.

모임 생성과 이미지 업로드 순서

• 초기 구현 방향:
  • “모임 JSON을 먼저 받아 모임 ID를 생성 → 그 ID를 기준으로 디렉터리를 만들어 이미지를 저장” 구조.
  • S3에서 groups/{groupId}/... 형태로 디렉터리를 나누어, 대량 이미지(수천·수만 개)에서도 검색/관리 효율을 높이려는 목적.
• 프론트:
  • “이미지를 먼저 업로드하고, URL을 받아 모임 생성 요청(JSON)의 images 필드에 해당 URL들을 넣어서 한 번에 보내자”는 방식.
  • URL만 일관되게 주고받으면 되고, 서버 내부 구조는 상관없음
• 논의 후 결정:
  • 기능 구현 난이도와 일정(MVP) 우선 순위를 고려해,
  • 이미지 선 업로드 → URL 반환 → 모임 생성 시 URL 포함 구조로 진행.

S3 디렉터리 구조(After2 선택)

• 여러 안 비교:
  • Before: 도메인·그룹별 디렉터리를 세분화(groups/{groupId}/...)
  • After1: 도메인별 구분은 유지하되, 방식 조정
  • After2: 도메인 명 없이 단일 디렉터리에 파일만 저장(경로 단순화)
• 백엔드:
  • 도메인별·그룹별 디렉터리를 두면 관리(벌크 삭제, 정리)는 편하지만,
  • 엔드포인트를 유저/그룹별로 나누거나, 도메인 정보를 파라미터로 받아야 하는 등 오버헤드가 생김.
• 프론트:
  • 어떤 구조로 저장되든 URL 문자열만 그대로 받았다가 다시 보내면 되기 때문에, 경로 구조는 신경 쓰지 않아도 됨.
• 서비스 규모가 크지 않은 점, 일정 등을 고려해,
  • After2 (도메인/그룹 디렉터리 없이 단일 폴더에 저장) 방식으로 결정.
• After2 구조를 선택하면서,
  • 우선은 하나의 이미지 업로드 API를 사용하는 방향으로 합의.
  • 향후 필요 시 도메인 파라미터 추가나 엔드포인트 분리는 추후 리팩터링 단계에서 검토.

알림 기능 및 SSE 사용 여부

알림 동작 요구사항

• 기본 요구:
  • 알림 목록(페이지/모달)에서 알림 내역을 조회할 수 있어야 하고,
  • 홈 상단 벨 아이콘 옆 숫자 뱃지가 “새 알림 발생 시 증가”하는 모습을 보여주고 싶음.

SSE(Server-Sent Events) 논의

• SSE는 HTTP 연결(TCP)을 한 번 열어 계속 유지하는 방식이라,
  • 수신자가 접속 중이어야만 이벤트를 실시간으로 받을 수 있음.
  • 연결이 언제 끊길지 명확하지 않고, 서버·클라이언트 모두에 연결 유지 오버헤드가 존재.
• “오프라인이어도 나중에 알림 목록에서 볼 수 있는 것”은
  • SSE가 아니라 알림 리스트 API + 로그인/진입 시 패치로 충분히 구현 가능.
• 단순히 숫자 뱃지를 올리는 정도라면,
  • SSE 대신 폴링(주기적 요청)이나 화면 진입 시 fetch로도 “거의 실시간처럼” 보이게 만들 수 있음

결론

• 벨 아이콘 옆 숫자가 “가능한 한 실시간에 가깝게” 증가해야 한다는 요구 자체는 유지.
• 다만, 이를 SSE로 할지 폴링/기타 방식으로 할지는
  • 기술적 리스크와 구현 복잡도를 고려해 프론트/백엔드가 재검토 후 다시 결정

모임 종료 시간(endTime) 처리

• 디자인 시안 변경으로 “모임 종료 시간(End time)”이 UI에서 빠진 상태,
  • 일부 모임은 종료 시간을 쓸 수도 있어 백엔드 필드를 완전히 없애기보다는 nullable로 처리해 달라는 요청.
• 시작 일자/종료 일자 중 종료 일자가 없는 경우도 충분히 처리 가능하며,
• 종료 시간을 nullable 필드로 정의해 문제없이 지원할 수 있다고 확인.

---

후속 액션

1. 일정 및 진행
   • 백엔드: 유저 도메인 + 모임 관련 API(7~8개) 및 명세 최신화를 이번 주 토요일까지 완료 목표.
   • 프론트: 현재 구현된 화면들을 기준으로, 명세 확정 후 바로 API 연동 진행.
   • 공통: MVP 목표일 12월 16일(화)에 맞춰 기능을 수렴.
2. API 및 도메인 스펙
   • joinedCount는 제거하고, 태그 정책은 내일 정리된 문서로 공유.
   • 공통 응답 스펙은 백엔드에서 일괄 정리 후 타입/필드명 기준을 다시 전달.
   • 모임 상태·참여자 상태(호스트/참가자, 참석 여부) 설계 및 응답 모델을 문서로 공유.
3. 알림 구현 방향
   • 실시간성 구현 방식(SSE vs 폴링/기타)은 SSE의 장단점(연결 유지, 불안정성 등)을 감안하여 팀 내부에서 재논의 후 확정.
4. 추가 문서화/공유
   • 태그 정책, 모임 상태 모델, 이미지 업로드 방식, 응답 스펙 정리본을 내일까지 공유.
   • 이후 개발 중 발견되는 추가 쟁점은 Discussion/정기 회의에서 수시로 업데이트