[12/24] 프론트–디자이너-백엔드 5차 회의 - 추가 기획 논의

[yoorli]

회의 개요

• 날짜: 2025.12.24(수)
• 회의 안건
  • 에러/404 화면 및 레이아웃 배경 컬러 추가 디자인 요청
  • 모임 참여 방식(즉시 참여 / 승인 후 참여) 도입 및 관련 UX 정리
  • 모임 상태(대기 중, 마감) 뱃지·인디케이션 위치 정의
  • 모임 승인 전용 페이지(방장용) 플로우 확정 및 진입 경로 논의
  • 그룹 채팅 내 유저 목록/추방 기능 및 모임 추방 로직 연계
  • 채팅 상세 메시지 “전체 보기” 모달 방식 결정
  • 소셜 로그인(구글 중심) 시 약관 동의·닉네임 입력 화면 추가, 카카오/네이버 확장 고려
  • 알림(Noti) 응답 스키마 정리(유저/모임 객체화, redirect URL 제거)
  • 구글 OAuth 흐름(프론트 주도 vs 백엔드 주도) 방식 선택
  • 채팅(1:1 / 그룹) 전체 플로우, 데이터 저장 시점, 만료(24시간) 정책 및 기술 스택(STOMP) 논의
  • 채팅·알림·모임 관련 백엔드 일정, 데드라인(12/31) 및 휴가 일정 공유

---

회의 내용 요약

1. 에러 화면은 “예기치 못한 에러”와 “존재하지 않는 페이지(404)” 두 종류를 별도 화면으로 추가하고, 기존 “데이터 없음” 화면과는 다른 일러스트/톤으로 디자인
2. 전체 레이아웃 좌우 공백 영역에 은은한 파스텔톤 배경 컬러를 넣는 방안을 검토하며, 여러 시안을 만들어 추후 재논의
3. 모임 생성 시 “참여 방식: 즉시 참여 / 승인 후 참여”를 선택하는 UI를 추가하고, 승인제일 경우 버튼 문구(참여하기→참여 신청하기, 채팅 입장→대기 중, 모임 탈퇴→신청 취소), 참여 신청 메시지 모달, 방장용 승인 페이지까지 일괄 설계
4. 참여 승인 전용 페이지는 알림 화면에서 알림 클릭 시 진입하며, 신청 유저 리스트·메시지·수락/거절 버튼을 카드 형태로 제공. 추가로 스케줄러/상세 등 다른 진입 경로를 둘지 검토 후 다시 공유
5. 사용자가 “대기 중”인 모임은 메인 모임 목록과 상세 화면에서 모두 ‘대기 중’ 뱃지나 리본 등으로 표시하고, 위치는 카드 상단 우측(리본) 및 상세 상단/프로필 옆(기존 수정 버튼 자리 활용) 방향으로 디자인을 검토
6. 그룹 채팅에는 참여 유저 목록 버튼을 추가하고, 방장만 해당 목록에서 유저를 추방할 수 있도록 하며, 모임 상세 화면에서도 방장 전용 추방 버튼을 제공해 모임 추방과 채팅 추방을 동일 로직으로 처리(추방 시 조용히 목록/채팅에서 제거)
7. 채팅 메시지 “전체 보기”는 인라인 확장 대신 모달로 띄우는 안으로 결정, 배경 클릭 시 닫히는 패턴으로 구현
8. 구글 로그인 사용자의 경우에도 서비스 자체 이용약관 동의를 별도 화면/모달에서 받고, 같은 화면에서 소셜 유저의 닉네임을 직접 입력. 향후 카카오/네이버 버튼도 추가, 공간이 부족하면 아이콘만 사용하는 방식도 고려
9. 알림 응답 스키마는 user, group 객체를 포함하는 형태로 단순화, redirect URL은 제거한 뒤 type 기준으로 프론트에서 라우팅을 조합하는 구조로 변경
10. 구글 OAuth는 프론트 주도 방식으로 시작하되, 프론트가 인가 코드만 백엔드에 전달하고, 백엔드가 코드로 토큰·userinfo 조회 후 JWT 발급·HttpOnly 쿠키 세팅을 담당하는 구조로 합의(향후 카카오/네이버도 동일 인터페이스 활용).
11. 채팅 기능은 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을 활용할 수 있도록 객체 형태로 내려주는 방향에 동의.
• 합의된 구조(개요)
  • id (알림 ID)
  • user: { id, nickname }
  • group: { id, title } (그룹 관련 알림에 한해)
  • type
  • message (옵션, 서버에서 고정 생성)
  • createdAt, readAt

구글 OAuth 흐름: 프론트 주도 방식

• 세 가지 일반 패턴 설명
  • 프론트 완전 책임
  • 백엔드 완전 책임
  • 프론트/백엔드 반반(코드만 넘기기)
• 보안/구현 관점 정리
  • 백엔드에서 전부 처리하는 방식이 “정석”에 가깝다는 경험을 공유하되,
  • 이번 프로젝트에서는 프론트가 OAuth 플로우를 직접 경험해 보는 것도 의미가 있어, 프론트 주도 + 코드 전달 방식으로 진행해 보기로 함.
• 최종 흐름(합의)
  1. 프론트: 구글 OAuth 로그인 요청 → 인가 코드(code) 수신
  2. 프론트: 이 인가 코드를 백엔드로 전달
     • 기존 이메일 계정/소셜 계정 정책에 맞춰 회원가입 or 로그인 처리
  3. 백엔드: 코드로 구글 토큰/유저 정보 조회 → 기존 이메일 계정/소셜 계정 정책에 맞춰 회원가입 or 로그인 처리
  4. 백엔드: 우리 서비스용 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시 정도까지 마무리하는 것을 목표.
  • 알림 타입 변경, 스케줄러·알림 연동도 같은 타임라인에 맞춰 작업 예정.
• 채팅 부하/테스트
  • 테스트 시 너무 많은 메시지(수천 개 이상)를 한 번에 쏘는 것은 서버 부하/성능 이슈를 유발할 수 있으므로, 합리적인 범위에서 부하 테스트를 진행하자는 의견을 공유.

---

정리된 결론 / 후속 액션

1. 디자인/UX
   • 에러 화면(예기치 못한 에러, 404) 2종 신규 디자인.
   • 레이아웃 좌우 파스텔톤 배경 시안 다수 제작.
   • 모임 생성 화면에 “참여 방식(즉시/승인제)” 선택 UI 추가.
   • 승인제 플로우에 맞는 버튼 문구/상태(참여 신청하기, 대기 중, 신청 취소) 정의.
   • 참여 신청 메시지 모달·참여 승인 전용 페이지·대기 중/마감 뱃지·추방 UI 시안 제작.
   • 소셜 로그인용 약관/닉네임 입력 화면 및 구글/카카오/네이버 버튼 디자인.
2. 알림/스키마·OAuth(백엔드 중심)
   • 알림 응답 스키마를 user/group 객체 + type 중심 구조로 변경, redirect URL 제거.
   • 각 타입별 기본 message 텍스트 정리 후 서버에서 생성.
   • 구글 OAuth는 프론트 주도 + 코드 전달 방식으로 구현, 백엔드는 코드→토큰→userinfo→회원가입/로그인→JWT 발급까지 처리.
   • 카카오/네이버 로그인도 동일 인터페이스로 확장 가능하도록 설계.
3. 모임/채팅 도메인 연계
   • 모임 승인제: 신청/승인/대기/취소 전 플로우와 알림·승인 페이지 로직을 명세서로 정리.
   • 모임 추방 API와 채팅 추방 기능을 연동해, 한 번의 추방으로 모임·채팅 모두 처리.
   • 모임 시작 후 24시간 경과 시 그룹 채팅방 자동 삭제(배치 또는 기존 종료 배치와 연계).
4. 채팅 기능 구현(프론트·백엔드 공동)
   • 기술 스택: WebSocket + STOMP 조합으로 확정(1차).
   • 메시지 저장: 전송 시점 즉시 DB 기록 + 커서 기반 무한 스크롤로 이전 내역 조회.
   • 그룹 채팅: 입장 이후 메시지만 보이는 정책, 추방·만료(24시간) 정책 반영.
   • 1:1 채팅: 첫 메시지 전송 시 방/소켓 생성, 나가기 기능은 미제공.
5. 일정 관리
   • 백엔드: 모임·알림·스케줄러 관련 작업을 12/25~26 내로 1차 완료 목표.
   • 채팅: 12/31까지 기능 구현 완료를 목표로 진행, 중간에 위험 요소 발생 시 범위 조정 논의.
   • 전체 팀: 1/5 최종 발표까지 남은 기간 동안, 우선순위를 알림·승인제·채팅에 두고 나머지 부가 기능은 상황에 따라 조정.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• [12/09] 프론트–백엔드 3차 회의 #11
• [12/18] 프론트–디자이너-백엔드 4차 회의 #20
• [12/10] 프론트–디자이너-백엔드 3차 회의 #16
• [12/02] 프론트–백엔드 2차 회의 #5

👤 Suggested Assignees

• yoorli

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Warning

This repository contains only documentation (README.md) and references separate frontend (WeGo_FrontEnd) and backend (WeGo_BackEnd) repositories on GitHub where the actual implementation must occur. The ticket requests comprehensive feature implementations across authentication, chat, notifications, and meeting management, but without access to these separate code repositories, no implementation plan can be created for the wrong repository. To proceed, the actual WeGo_FrontEnd and WeGo_BackEnd repositories must be explored to understand their tech stacks, architectures, and existing patterns.

You can reply directly to this comment with additional context or clarifications to help CodeRabbit complete the planning task, with an @-mention to the bot.