[12/18] 프론트–디자이너-백엔드 5차 회의 - 추가 기획 논의 #23
Description
회의 개요
- 날짜: 2025.12.24(수)
- 회의 안건
- 에러/404 화면 및 레이아웃 배경 컬러 추가 디자인 요청
- 모임 참여 방식(즉시 참여 / 승인 후 참여) 도입 및 관련 UX 정리
- 모임 상태(대기 중, 마감) 뱃지·인디케이션 위치 정의
- 모임 승인 전용 페이지(방장용) 플로우 확정 및 진입 경로 논의
- 그룹 채팅 내 유저 목록/추방 기능 및 모임 추방 로직 연계
- 채팅 상세 메시지 “전체 보기” 모달 방식 결정
- 소셜 로그인(구글 중심) 시 약관 동의·닉네임 입력 화면 추가, 카카오/네이버 확장 고려
- 알림(Noti) 응답 스키마 정리(유저/모임 객체화, redirect URL 제거)
- 구글 OAuth 흐름(프론트 주도 vs 백엔드 주도) 방식 선택
- 채팅(1:1 / 그룹) 전체 플로우, 데이터 저장 시점, 만료(24시간) 정책 및 기술 스택(STOMP) 논의
- 채팅·알림·모임 관련 백엔드 일정, 데드라인(12/31) 및 휴가 일정 공유
회의 내용 요약
- 에러 화면은 “예기치 못한 에러”와 “존재하지 않는 페이지(404)” 두 종류를 별도 화면으로 추가하고, 기존 “데이터 없음” 화면과는 다른 일러스트/톤으로 디자인
- 전체 레이아웃 좌우 공백 영역에 은은한 파스텔톤 배경 컬러를 넣는 방안을 검토하며, 여러 시안을 만들어 추후 재논의
- 모임 생성 시 “참여 방식: 즉시 참여 / 승인 후 참여”를 선택하는 UI를 추가하고, 승인제일 경우 버튼 문구(참여하기→참여 신청하기, 채팅 입장→대기 중, 모임 탈퇴→신청 취소), 참여 신청 메시지 모달, 방장용 승인 페이지까지 일괄 설계
- 참여 승인 전용 페이지는 알림 화면에서 알림 클릭 시 진입하며, 신청 유저 리스트·메시지·수락/거절 버튼을 카드 형태로 제공. 추가로 스케줄러/상세 등 다른 진입 경로를 둘지 검토 후 다시 공유
- 사용자가 “대기 중”인 모임은 메인 모임 목록과 상세 화면에서 모두 ‘대기 중’ 뱃지나 리본 등으로 표시하고, 위치는 카드 상단 우측(리본) 및 상세 상단/프로필 옆(기존 수정 버튼 자리 활용) 방향으로 디자인을 검토
- 그룹 채팅에는 참여 유저 목록 버튼을 추가하고, 방장만 해당 목록에서 유저를 추방할 수 있도록 하며, 모임 상세 화면에서도 방장 전용 추방 버튼을 제공해 모임 추방과 채팅 추방을 동일 로직으로 처리(추방 시 조용히 목록/채팅에서 제거)
- 채팅 메시지 “전체 보기”는 인라인 확장 대신 모달로 띄우는 안으로 결정, 배경 클릭 시 닫히는 패턴으로 구현
- 구글 로그인 사용자의 경우에도 서비스 자체 이용약관 동의를 별도 화면/모달에서 받고, 같은 화면에서 소셜 유저의 닉네임을 직접 입력. 향후 카카오/네이버 버튼도 추가, 공간이 부족하면 아이콘만 사용하는 방식도 고려
- 알림 응답 스키마는
user,group객체를 포함하는 형태로 단순화, redirect URL은 제거한 뒤type기준으로 프론트에서 라우팅을 조합하는 구조로 변경 - 구글 OAuth는 프론트 주도 방식으로 시작하되, 프론트가 인가 코드만 백엔드에 전달하고, 백엔드가 코드로 토큰·userinfo 조회 후 JWT 발급·HttpOnly 쿠키 세팅을 담당하는 구조로 합의(향후 카카오/네이버도 동일 인터페이스 활용).
- 채팅 기능은 1:1 / 그룹 채팅을 모두 지원, 메시지는 전송 시점마다 즉시 DB에 저장하는 방식, WebSocket + STOMP 조합으로 구현. 그룹 채팅은 모임 시작 시점을 기준으로 24시간 후 채팅방을 자동 삭제, 새로 들어온 사람은 ‘입장 이후 메시지’만 보도록 기획.
회의 내용 상세
에러/404 화면 및 레이아웃 배경
- 에러 화면 요구사항
- “예기치 못한 에러가 발생했을 때 다시 시도하라는 안내 화면”과 “존재하지 않는 페이지(404)에 접근했을 때 보여줄 화면” 두 종류를 별도로 디자인하기로 함.
- 기존 “데이터 없음(Empty State)” 화면과는 목적이 다르므로, 일러스트·메시지·톤을 다르게 가져가는 것이 좋다는 의견.
- 그래픽 톤
- 에러/404 일러스트는 현재 Empty 화면 일러스트와 완전히 동일하기보다는, 약간 다른 그림을 써서 상태를 명확히 구분하는 쪽으로 방향성 합의.
- 레이아웃 배경 컬러
- 현재 라이트 모드 기준으로 좌우가 완전히 흰색이라 “너무 휑한 느낌”이라는 내부 피드백.
- 페이지 양 옆에 은은한 파스텔톤(밝은 컬러) 배경을 넣는 시안을 몇 가지 만들어, 실제 서비스 톤에 맞는 컬러를 선택하기로 함.
모임 참여 방식(즉시 / 승인 후) 및 버튼 상태
- 참여 방식 옵션 추가
- 모임 생성 화면에서 “참여 방식”을 선택할 수 있는 UI가 필요.
- 옵션:
- 즉시 참여
- 승인 후 참여(승인제)
- 구체 위치는 최대 인원 아래 등으로 고려 중이며, 디자이너가 레이아웃을 제안하기로 함.
- 상세 화면 버튼 상태 변화 (승인제인 경우)
- 기본 상태(참여 전):
- 메인 버튼: “참여 신청하기”
- 신청 후(승인 대기):
- 메인 버튼: “대기 중”
- 기존 “채팅 입장” 상태로 가지 않음.
- 신청 취소
- 기존 “모임 탈퇴” 버튼 대신, 승인 대기 상태에서는 “신청 취소” 버튼으로 표기.
- 기본 상태(참여 전):
- 스케줄러(내 모임 목록)에서도 동일한 상태 체계 적용
- 캘린더/스케줄러 내 “참여 중 / 내가 생성 / 과거 참여” 화면에서도 승인제 모임은 버튼/라벨을 동일한 규칙으로 맞추기로 함.
참여 신청 메시지 모달 및 방장 알림·승인 페이지
- 참여 신청 메시지 모달
- 승인제 모임에서 “참여 신청하기” 버튼 클릭 시, 방장에게 보낼 짧은 소개/신청 메세지를 입력하는 모달을 띄움.
- 입력 필드는 한 줄 정도로 제한(간단한 자기소개/참여 이유).
- 버튼 문구는 현재 “전송하기” 등 임시 텍스트이며, 실제 문구는 디자이너가 다듬어 적용.
- 방장 알림 플로우
- 신청이 들어오면 방장 계정의 알림 리스트(종 아이콘 클릭)에서 “누구누구님이 모임 참여를 신청했습니다”와 같은 알림이 생성됨.
- 이 알림을 클릭하면 해당 모임의 “참여 승인 전용 페이지”로 이동.
- 승인 전용 페이지 구조
- 상단: 모임 제목 + 안내 문구(“참여 신청한 유저를 확인해 주세요” 등, 추후 문구 보완).
- 본문: 신청자 수, 신청자 리스트 카드 배열. 각 카드에는
- 프로필 정보(이미지, 닉네임 등)
- 신청 메시지
- 수락 / 거절 버튼
- 상단 좌측 또는 상단 영역에 “이전 페이지로 돌아가기(알림 리스트로)” 아이콘 버튼 배치.
‘대기 중’ 상태 인디케이션(목록/상세)
- 문제 의식
- 대기 중 모임은 아직 진행 중인 모임이므로, 메인 목록/검색 결과에서 계속 노출될 예정.
- 사용자가 이미 신청한 모임인지 한눈에 알 수 있는 인디케이터가 필요.
- 목록 카드(모임 리스트)
- 카드 우측 상단에 파란 리본/배지 형태로 “대기 중” 라벨을 붙이는 안이 제안됨.
- 태그/마감 인디케이터와 겹치지 않도록 위치·디자인을 조정.
- 상세 화면
- 썸네일 상단에 “대기 중” 배지를 고정해서 표시하는 안,
- 또는 기존 “모임 수정” 버튼이 있던 프로필 옆 위치를 재활용하는 안을 함께 검토.
승인 페이지 추가 진입 경로 검토
- 현재 진입 경로
- 알림 화면에서 “참여 신청 알림” 클릭 시 승인 전용 페이지로 이동.
- 추가 경로 필요성
- 방장이 알림 화면 외에서도 승인 페이지에 접근할 수 있어야 편리하다는 의견.
- 후보 경로:
- 스케줄러의 “내가 생성한 모임” 섹션 → 각 모임 카드에 “대기 인원 보기/요청자 목록 보기” 버튼 추가
- 혹은 모임 상세 페이지 내 방장 전용 버튼으로 진입
- 결론
- 구체적인 진입 위치는 다시 검토 후 최종 제안하기로 하고, 우선 알림→승인 페이지 플로우를 기준으로 설계 진행.
그룹 채팅: 유저 목록·추방 기능 및 모임 추방 연계
- 그룹 채팅 내 유저 목록 버튼
- 채팅 화면 상단 UI에 “참여 중인 유저 목록 보기” 버튼 추가.
- 이 버튼 클릭 시 현재 채팅방에 속한 유저 리스트가 노출.
- 추방 기능
- 그룹 방의 방장(모임 호스트)만 유저 목록에서 개별 유저를 추방할 수 있음.
- 추방 버튼은 유저별 액션 버튼(예: 빨간색 “추방하기” 등)으로 구현.
- 모임 추방과의 관계
- 채팅에서 추방 = 해당 모임에서 추방과 동일한 개념으로 취급.
- 따라서 모임 도메인의 “추방 API”를 재사용하고, 채팅 측에서는 추방 시 해당 유저와 채팅방의 연결을 끊는 동작만 추가.
- 추방 UX
- 추방 시 별도의 알림/메시지 없이 조용히 목록에서 사라져도 괜찮다는 의견에 공감.
- 시스템 메시지를 남길지 여부는 비용 대비 효과가 크지 않아 “조용한 제거” 쪽으로 가닥.
- 모임 상세 화면에서도 추방 제공
- 방장 전용으로 상세 화면의 참여자 목록 아래에 개별 “추방” 버튼 추가.
- 그룹 채팅의 추방 UX와 시각적으로도 최대한 통일해 사용자가 혼동하지 않도록 할 계획.
채팅 메시지 “전체 보기” 모달
- 기존 안
- 긴 메시지 우측의 “전체 보기” 클릭 시, 카카오톡 레퍼런스처럼 채팅 풍선 내에서 펼쳐 보여주는 패턴을 참고 중
- 새 제안
- 한 팀원이 “전체 보기 → 모달로 띄우는” 형태를 시도해 봤고,
- 배경을 클릭하면 닫히는 구조가 편리해 보인다는 의견 제시.
- 팀 의견 수렴
- 최종 투표에서 모달 쪽이 다수여서 모달 방식 채택으로 결론.
- 디자이너가 모달 스타일을 정리해 주고, 개발자는 모달 UI로 구현.
소셜 로그인: 약관 동의 및 닉네임 입력 화면, 추가 SNS 버튼
- 약관 동의 필요성
- 구글 계정으로 로그인하더라도, 구글 자체 약관과 별도로 “우리 서비스 이용약관 동의”를 받아야 한다는 점을 재확인.
- UX 방향
- 구글 로그인 버튼 클릭 → 구글 인증 성공 → 서비스 측 “약관 동의 + 닉네임 입력 화면”으로 이동.
- 이 화면에서
- 필수 약관 동의 체크박스(및 ‘자세히 보기’ 모달/페이지)
- 신규 소셜 사용자용 닉네임 텍스트 필드를 함께 구성하기로 함.
- 초기 논의에서 계획했던 “자동 닉네임 부여” 대신, 소셜 유저도 직접 닉네임을 입력하도록 정책을 변경.
- 추가 소셜 로그인 버튼
- 현재 가장 먼저 구글을 붙이지만, 카카오/네이버도 가능하다면 함께 도입하고자 함.
- 로그인 화면에 세 provider 버튼을 나란히 두되, 공간이 부족하면 아이콘 중심의 버튼으로 단순화하는 안도 고려.
알림 타입/응답 스키마 정리
- 기존 응답 구조
notificationId,receiverId,senderId,groupId,redirectUrl,message등 개별 ID와 URL을 모두 내려주는 형태였다.
- 프론트 요구사항
-
타입별로 라우팅을 프론트에서 유연하게 조합하고자 하며,
-
type(예: FOLLOW, GROUP_CREATED, GROUP_JOINED, GROUP_CANCELED …) -
user객체:{ id, nickname } -
group객체:{ id, title }위주로 단순한 구조를 선호.
-
-
redirectUrl은 굳이 내려받지 않고,type기반으로 클라이언트에서 경로를 구성하는 쪽이 관리에 유리하다고 판단.
-
- 백엔드 입장
- 알림 목록 UI에서는 기본적으로 “메시지 + 시간”만 보여주기 때문에 message string은 여전히 서버에서 만들어 주되, 프론트가 조합해서 쓰고 싶으면
user.nickname·group.title을 활용할 수 있도록 객체 형태로 내려주는 방향에 동의.
- 알림 목록 UI에서는 기본적으로 “메시지 + 시간”만 보여주기 때문에 message string은 여전히 서버에서 만들어 주되, 프론트가 조합해서 쓰고 싶으면
- 합의된 구조(개요)
id(알림 ID)user:{ id, nickname }group:{ id, title }(그룹 관련 알림에 한해)typemessage(옵션, 서버에서 고정 생성)createdAt,readAt
구글 OAuth 흐름: 프론트 주도 방식
- 세 가지 일반 패턴 설명
- 프론트 완전 책임
- 백엔드 완전 책임
- 프론트/백엔드 반반(코드만 넘기기)
- 보안/구현 관점 정리
- 백엔드에서 전부 처리하는 방식이 “정석”에 가깝다는 경험을 공유하되,
- 이번 프로젝트에서는 프론트가 OAuth 플로우를 직접 경험해 보는 것도 의미가 있어, 프론트 주도 + 코드 전달 방식으로 진행해 보기로 함.
- 최종 흐름(합의)
- 프론트: 구글 OAuth 로그인 요청 → 인가 코드(code) 수신
- 프론트: 이 인가 코드를 백엔드로 전달
- 기존 이메일 계정/소셜 계정 정책에 맞춰 회원가입 or 로그인 처리
- 백엔드: 코드로 구글 토큰/유저 정보 조회 → 기존 이메일 계정/소셜 계정 정책에 맞춰 회원가입 or 로그인 처리
- 백엔드: 우리 서비스용 JWT 발급 + HttpOnly 쿠키 세팅(현 구조 유지).
- 멀티 프로바이더(구글/카카오/네이버)
- 백엔드는 세 provider 모두 유사한 인터페이스로 사용 가능하도록 구현할 계획.
- 프론트는 우선 구글만 붙이고, 이후 카카오/네이버를 같은 패턴으로 확장.
채팅 기능 상세: 1:1 / 그룹, 데이터 저장, 만료 정책, 기술 스택
- 채팅 유형
- 1:1 채팅
- 그룹 채팅(모임 단위 채팅방)
- 공통 사항
- 실시간 통신: WebSocket + STOMP 조합 사용을 1차 안으로 검토.
- 메시지 저장: 사용자가 메시지를 전송(엔터)하는 시점마다 즉시 DB에 저장하는 방식으로 진행.
- 배치로 묶어서 한 번에 저장하는 방식은 사용하지 않기로 함.
- 과거 메시지 조회: 커서 기반 무한 스크롤 형태로 이전 내역을 점진적으로 불러오는 구조.
- 그룹 채팅
- 모임에 참여하면 그룹 채팅방 입장 버튼이 활성화.
- 채팅방 입장 후,
- 해당 방에 이미 참여 중인 멤버들 간에 메시지가 오가고,
- 나중에 합류한 유저에게 “입장 이전 채팅 내역을 어디까지 보여줄지” 논의:
- 카카오톡처럼 “입장 시점 이후 메시지만” 볼 수 있게 하는 안으로 정리.
- 모임과의 연계
- 모임에서 추방되면 해당 그룹 채팅에서도 자동으로 연결이 끊김(동일 API 사용).
- 채팅에서 “나가기” 버튼은 별도로 두지 않고, 모임 탈퇴와 동일 이벤트로 처리.
- 만료 정책
- 모임 시작 시점 기준으로 24시간 경과 후, 해당 채팅방을 완전히 삭제(하드 삭제) 하는 방향.
- 이미 모임이 끝난 후 채팅을 계속 유지할 필요가 없다는 기획에 따른 결정.
- 모임 종료 상태로 바꿔주는 기존 배치와 중복/부하 문제를 피할 수 있도록, 종료/삭제 처리를 어떻게 묶을지 백엔드에서 추가 검토.
- 1:1 채팅
- 진입
- 팔로우 목록/프로필 등에서 “메시지 보내기” 클릭 시 1:1 채팅 UI로 진입.
- 채팅방 생성 시점
- 단순 진입만으로는 방/소켓을 만들지 않고,
- 실제로 첫 메시지를 보낸 순간 채팅방이 생성되고 WebSocket 연결을 여는 구조를 고려.
- 나가기
- 별도 “나가기” 기능은 두지 않고, 1:1 채팅은 사실상 계속 유지되는 대화로 취급.
- 진입
일정·역할 및 테스트 관련 논의
- 마감 목표
- 최종 발표: 2026-01-05.
- 채팅이 가장 난도가 높은 기능이므로, 12/31까지 기능 개발을 완료하는 것을 1차 목표로 삼음.
- 일정이 빡빡한 만큼, 31일까지의 개발 상황을 보고 필요 시 범위 조정을 고려.
- 백엔드 진행 상황
- 모임 관련 신규 API 9개, 필드 추가/수정, 모임 종료 스케줄러 등은 내일(12/25) 오후 3~4시 정도까지 마무리하는 것을 목표.
- 알림 타입 변경, 스케줄러·알림 연동도 같은 타임라인에 맞춰 작업 예정.
- 채팅 부하/테스트
- 테스트 시 너무 많은 메시지(수천 개 이상)를 한 번에 쏘는 것은 서버 부하/성능 이슈를 유발할 수 있으므로, 합리적인 범위에서 부하 테스트를 진행하자는 의견을 공유.
정리된 결론 / 후속 액션
- 디자인/UX
- 에러 화면(예기치 못한 에러, 404) 2종 신규 디자인.
- 레이아웃 좌우 파스텔톤 배경 시안 다수 제작.
- 모임 생성 화면에 “참여 방식(즉시/승인제)” 선택 UI 추가.
- 승인제 플로우에 맞는 버튼 문구/상태(참여 신청하기, 대기 중, 신청 취소) 정의.
- 참여 신청 메시지 모달·참여 승인 전용 페이지·대기 중/마감 뱃지·추방 UI 시안 제작.
- 소셜 로그인용 약관/닉네임 입력 화면 및 구글/카카오/네이버 버튼 디자인.
- 알림/스키마·OAuth(백엔드 중심)
- 알림 응답 스키마를
user/group객체 +type중심 구조로 변경, redirect URL 제거. - 각 타입별 기본 message 텍스트 정리 후 서버에서 생성.
- 구글 OAuth는 프론트 주도 + 코드 전달 방식으로 구현, 백엔드는 코드→토큰→userinfo→회원가입/로그인→JWT 발급까지 처리.
- 카카오/네이버 로그인도 동일 인터페이스로 확장 가능하도록 설계.
- 알림 응답 스키마를
- 모임/채팅 도메인 연계
- 모임 승인제: 신청/승인/대기/취소 전 플로우와 알림·승인 페이지 로직을 명세서로 정리.
- 모임 추방 API와 채팅 추방 기능을 연동해, 한 번의 추방으로 모임·채팅 모두 처리.
- 모임 시작 후 24시간 경과 시 그룹 채팅방 자동 삭제(배치 또는 기존 종료 배치와 연계).
- 채팅 기능 구현(프론트·백엔드 공동)
- 기술 스택: WebSocket + STOMP 조합으로 확정(1차).
- 메시지 저장: 전송 시점 즉시 DB 기록 + 커서 기반 무한 스크롤로 이전 내역 조회.
- 그룹 채팅: 입장 이후 메시지만 보이는 정책, 추방·만료(24시간) 정책 반영.
- 1:1 채팅: 첫 메시지 전송 시 방/소켓 생성, 나가기 기능은 미제공.
- 일정 관리
- 백엔드: 모임·알림·스케줄러 관련 작업을 12/25~26 내로 1차 완료 목표.
- 채팅: 12/31까지 기능 구현 완료를 목표로 진행, 중간에 위험 요소 발생 시 범위 조정 논의.
- 전체 팀: 1/5 최종 발표까지 남은 기간 동안, 우선순위를 알림·승인제·채팅에 두고 나머지 부가 기능은 상황에 따라 조정.