프로젝트 초안 작성-(1)(우리 지금 만나)

왜 해당 프로젝트를 시작했나요?

• 개인주의가 많아진 현대사회에서, 각자의 취미생활을 공유할 수 있는 그룹을 찾기위한 소모임 개최 및 참여형 애플리케이션이 필요해졌고.
• (사용자가 다양한 활동(운동, 공부, 식사, 취미 등)을 함께할 사람들과 소모임을 쉽게 구성할 수 있도록 도와주는 웹 기반 플랫폼)
• 현대 사회에서는 개인의 관심사나 취미를 공유할 수 있는 소모임을 찾는 것이 중요한 요소로 부상하고 있지만, 현실적으로 관심사나 위치가 비슷한 사람들과 함께 모일 수 있는 플랫폼은 제한적입니다.
• 따라서 이 서비스는 다양한 활동을 매개로 사람들을 연결하여, 이들이 손쉽게 모임을 만들고 참여할 수 있는 환경을 제공하는 데 목적을 만들기 위해 프로젝트를 시작하게 되었습니다. 

 

즉 간단하게 말하면 서로 관심사가 맞는 혹은 하고 싶은 모임을 만들어 뜻 맞는 사람들끼리 사교활동을 하는 것이 목적인 프로젝트입니다. (혹은 교육)

 

여기에 들어갈 기능들이 무엇이있나요?

 

필수 기능

• 회원 가입 및 로그인
• 프로필 설정 : 사용자 관심사, 지역 등 프로필 정도 설정 및 수정
• 소모임 생성 : 사용자가 주제를 설정하고 소모임을 직접 생성할 수 있는 기능
• 소모임 참여 : 사용자가 소모임에 신청 및 참여할 수 있는 기능
• 참여 신청 수락
• 메세지 
• 알람봇을 통해 유저의 이벤트에 대해 전달함.
• 강제퇴장

핵심 기능

• 소모임 검색(인덱싱)
  • 인덱싱 : 검색 시 성능을 향상하기 위해 소모임의 주요 검색 필드(제목, 주제, 지역 등)에 대해 데이터베이스 인덱스를 적용.
  • 동시성 제어 : 여러 사용자가 동시에 검색할 때, 캐시를 사용하여 데이터베이스 접근을 줄여 동시성 문제를 해결
• 소모임 관리
  • 캐싱 : 자주 접근하는 소모임 정보(멤버 리스트, 게시글 목록 등)는 캐시에 저장하여 빠르게 조회 가능하도록 설정.
• 소모임 매칭(인덱싱, 캐싱(?))
  • 캐싱 : 소모임 매칭 작업에서 추천 소모임 목록을 캐시에 저장하여 매칭 속도를 개선.
  • 인덱싱 : 매칭 알고리즘에서 사용하는 주요 필드(사용자의 관심사, 지역 등)를 인덱싱하여 매칭 결과를 빠르게 제공.
  • 매칭 요청이 다수 발생할 경우 큐 기반 처리를 통해 동시성을 관리하고, 여러 매칭 작업이 동시에 일어나더라도 서버 부하를 줄이며 안정적으로 처리할 수 있음.

 

사실상 핵심 기능중 소모임 매칭은 추가 기능 구현이라 나중에 설명할 예정입니다.

 

추가 기능으로 들어갈 것은(예정)

• 광고(수익 창출)
• 광고 제거(구독제: 수익 창출)
• 매칭 시스템(일대일 또는 다대다)(1순위)
• 날씨에 따라 추천되는 모임(노출도)
• 클래스(수업을 원하는 유저가 제안서를 업로드하면 튜터가 수업받고 싶은 유저를 선택해 매칭되는 방식)

광고는 수익 창출을 위한 것과 광고 기능을 적용하기 위해 들어가게 될 기능이고, 광고제거를 통해 수익창출과 동시에 결제 기능을 도입하고자 하는 뜻을 담고 있습니다. 그리고 매칭 시스템을 통해 서로가 원하는 모임을 성사시키게끔 사용자가 일일이 모임을 찾을 필요없이 매칭 시스템을 통해 즉석 모임을 갖게하여 사용자의 편의성을 높일수가 있습니다. 또한 일반 모임뿐만 아니라 클래스를 통해 해당 교육듣고 싶은 분야가 있다면 매칭 시스템을 통해 멘토, 멘티를 구성할 수 있는 서비스를 갖출 예정입니다.

 

현 프로젝스 상황은 

 

 

해당 그림처럼 사용자가 원하는 모임을 순전히 카테고리를 통해 찾아야만 한다는 불편함이 있다.

 

그러기에 매칭 서비스를 통해 사용자의 불편함을 없애주고 하는게 현 진행 하고 있는 프로젝트의 1 순위인 것이다.

 

현 프로젝트에는 어떤 데이터가 필요하나요?

• 사용자
  • 이름
  • 관심사
  • 지역
  • MBTI
  • 나이
  • 레벨(ex.당근 온도), 레벨 x
• 소모임
  • 제목
  • 멤버
  • 주제(활동)
  • 지역
  • 모집인원
  • 모임장소
  • 점수(활동점수)
  • 일정
  • 후기(사진 첨부)
• 참여기록
  • 참여상태 : 승인/반려
  • 참여날짜

 

MVP 구현하게 될 부분

1. 로그인/회원가입(+소셜 로그인)
   1. Spring Security로 사용자 인증 및 보안 처리
   2. OAuth 2.0으로 구글/카카오/네이버 소셜 로그인
   3. JWT 토큰을 이용한 사용자 인증 및 세션 관리
2. 메인 페이지
   1. 모임 리스트(정렬 기준) : 사용자의 관심사 또는 지역 기반으로 소모임을 정렬
   2. 즐겨찾는 모임 : 사용자가 즐겨찾기에 추가한 모임 리스트
   3. 요즘 뜨는 모임 : 인기 있는 소모임을 추천
   4. 모임 검색창
   5. 1:1 퀵 : 매칭 관심사 기반으로 소모임을 추천받는 기능(필수 구현 완료 후 구현예정)
3. 마이 페이지
   1. 프로필 조회
   2. 프로필 수정
   3. 회원 탈퇴
   4. 가입된 모임 조회
4. 모임 세부 페이지
   1. 모임 이름
   2. 모임 소개
   3. 모임 대표 이미지
   4. 멤버 (관리) : 모임에 참여한 멤버 리스트 (관리자는 멤버 강퇴 가능함)
   5. 게시글(댓글)
   6. (선택 사항) 다른 모임 추천(맨 하단) : 비슷한 주제의 소모임 추천
   7. (선택 사항) 단일 이벤트 or 원데이 클래스 소개 > 채팅 고려하기

 

와이어 프레임

유저

로그인 화면을 통해 회원가입과 로그인을 진행이 가능합니다.(소셜 로그인도 가능)

그리고 마이 페이지를 통해 프로필 수정과 회원탈퇴가 가능하다(프로필 수정에서는 mbti, 사는 지역, 나이, 관심사, 프로필 이미지 정도 수정이 가능하다.) 내 모임에서는 내가 가입된 모임이 어떤것이 있는지 확인이 가능합니다.

 

유저->모임

내가 모임을 만들어 원하는 모임을 만들 수 있습니다. (관심사 작성란을 추가해야 된다.) 나의 모임에 대한 평가(점수)입니다. events작성을 통해 약속을 생성합니다.

수정

수정을 통해 모임에 대한 프로필 이미지, 이름, 해당 모임에 참여하고 싶은 유저를 참여해주거나 거절이 가능합니다.

삭제

모임을 삭제하면 그룹에 속해 있던 유저들은 전부 모임에서 강제 탈퇴가 됩니다.

 

유저->모임->이벤트

이벤트를 통해 약속 즉 요즘말로 번개를 만들수가 있습니다. 일정을 잡고 만남을 가질수가 있습니다.(전체 채팅 기능이 필요해 보입니다.)

이벤트에 대해 댓글을 남길수가 있습니다.

 

ERD  구조

 

엔티티에 대한 설명

USERS (사용자)

사용자 정보를 저장하는 테이블입니다.

주요 속성:

user_id: 사용자 고유 ID.

nickname: 닉네임.

user_email: 이메일.

image: 프로필 이미지 (BLOB 타입).

interest, mbti: 사용자 성향이나 관심사를 나타내는 ENUM 타입.

이 테이블은 USERS_GROUPS, ATTACHMENTS, COMMENTS 등과 연관되어 있습니다.

 

GROUPS (소모임)

소모임 정보를 저장하는 테이블로, 특정 주제나 관심사 기반의 그룹을 표현합니다.

주요 속성:

group_id: 소모임 고유 ID.

title: 소모임 제목.

group_image: 소모임 이미지 (BLOB 타입).

group_max_count: 최대 멤버 수.

USERS_GROUPS 및 EVENTS 테이블과 연관되어 있습니다.

 

USERS_GROUPS (사용자-소모임 매핑)

사용자와 소모임 간의 관계를 저장하는 연결 테이블입니다.

주요 속성:

user_id: 사용자 ID.

group_id: 소모임 ID.

role: 소모임 내 역할 (예: 관리자, 일반 사용자 등).

black_list: 블랙리스트 여부 (BOOLEAN).

다대다 관계를 표현하며, 사용자와 소모임 간의 참여 상태, 역할 등을 관리합니다.

 

EVENTS (모임/이벤트)

소모임에서 열리는 모임이나 이벤트 정보를 저장하는 테이블입니다.

주요 속성:

event_id: 모임 고유 ID.

title: 모임 이름.

content: 모임 설명.

schedule: 모임 일시 (DATETIME).

소모임(GROUPS) 및 사용자(USERS)와 연관되어 있으며, 각 모임 이벤트는 여러 참가자(PARTICIPANTS)와 연결됩니다.

 

PARTICIPANTS (일정 참가자)

모임 이벤트에 참여하는 사용자 정보를 저장하는 테이블입니다.

주요 속성:

event_id: 모임 ID.

user_id: 참가자 ID.

created_at: 참가 시간.

각 이벤트와 관련된 참가자 목록을 관리합니다.

 

ATTACHMENTS (첨부파일)

사용자와 소모임에 대한 첨부 파일 정보를 저장하는 테이블입니다.

주요 속성

attachment_id: 첨부파일 고유

ID.origin_name: 원본 파일명.

file_size: 파일 크기.

path, extension: 파일 경로 및 확장자.

 

COMMENTS (댓글)

특정 사용자나 소모임에 대한 댓글 정보를 저장하는 테이블입니다.

주요 속성:

comment_id: 댓글 고유 ID.

content: 댓글 내용.

created_at: 작성 시간.

 

서로 어떤 연관관계를 갖고 있나요?

USERS ↔ USERS_GROUPS: 사용자는 여러 소모임에 참여할 수 있고, 하나의 소모임은 여러 사용자를 가질 수 있습니다. 이 관계는 다대다 관계로, USERS_GROUPS 테이블이 이를 중개합니다.

GROUPS ↔ EVENTS: 소모임에서 여러 모임이나 이벤트가 열릴 수 있습니다. 이는 일대다 관계로, 하나의 소모임이 여러 이벤트를 주최할 수 있습니다.

EVENTS ↔ PARTICIPANTS: 모임에 여러 사용자가 참여할 수 있는 다대다 관계로, PARTICIPANTS 테이블을 통해 이를 관리합니다.

USERS ↔ ATTACHMENTS: 사용자는 여러 첨부파일을 업로드할 수 있으며, 이를 일대다 관계로 표현합니다.

USERS ↔ COMMENTS: 사용자는 여러 댓글을 작성할 수 있습니다. 이는 일대다 관계로, 사용자의 활동 내역을 관리합니다.

 

여기서 조금 더 추가 설명을 하면?

BLOB 타입: USERS, GROUPS 테이블에 이미지 필드가 BLOB 타입으로 저장되고 있습니다. 이는 사용자의 프로필 이미지나 소모임 이미지를 파일 형태로 저장하기 위한 필드입니다.

ENUM 타입: 사용자 성향 (mbti, interest), 소모임 주최자 역할 (host), 사용자 역할 (role) 등은 ENUM 타입으로 정의되어, 유효한 값들만 선택될 수 있도록 제한하고 있습니다.

DATETIME 타입: EVENTS 테이블의 schedule 필드는 모임 일정에 대한 정보를 저장하며, PARTICIPANTS 테이블의 created_at 필드는 사용자가 모임에 참여한 시점을 기록합니다.

 

초안 짜는데 어떤점이 힘들었고 그것을 극복하기 위해 어떤 방법을 사용했나요?

아무래도 아무것도 없는 백지 상태에서 바텀-탑 방식으로 프로젝트를 진행해야 하기에 다소 생각해야 할 거리가 많다는게 힘든점이 될 수 가 있겠습니다. 처음에는 주제를 선정하기 위해 각자 가져온 주제를 설명하여  어떤 주제를 선정해야 할지 서로 고민중에 있었습니다. 거기서 저희가 선별해야 하는 기준은 1. 우리 수준에서 개발 가능한 수준. 2. 너무 넓지 않은 스코프, 3. 조금은 차별성을 가진 프로젝트 이렇게 선별 기준을 정하여 빠르게 정하였습니다. 또한 와이어 프레임이나 ERD를 작성하게 될 때는 나중에 개발하게 될 때는 사용자에 대한 부분과 개발자의 대한 부분을 고려하여 작성해야 하기 때문에 상당히 난항을 겪에 되었습니다. 그러나 팀원들과의 논리적으로 시간이 맞지 않으니 레벨을 추가 하는 부분 보다는 추가 기능에 집중하는 방안을 정하거나( 개발자 시각), 사용자가 초대 수락을 통해 모임을 들어와 모임을 만들때 일정을 정하면 좋으니 일정에 대한 부분을 추가하는등(사용자 시작)을 통해 점진적으로 부족한 부분을 채워나갔습니다.