[프로젝트] 좋아하면숭리는 - 취미 기반 주변사람 소개팅 어플리케이션

1. 개요

주변 사람의 권유로 짧게 축제때 쓸 소개팅 어플리케이션의 서버 개발자로 참여하게 되었다.

 

바쁜 일정으로 인해 안하려고 했으나 저번에 한 프로젝트에서 채팅을 개발해본 경험이 있으므로 손쉽게 구현할 줄 알았다.

(왜 이런 생각을 가졌을까...)

'좋아하면숭리는'은 주변에 있는 사람과 취향을 기반으로 매칭이 일어나는 소개팅 어플리케이션으로,

 

나는 여기서 채팅 API를 도맡아서 개발했다.

 

 

2. 일정

2025.09.07 ~ 2025.09.25, 총 3주정도 진행된 프로젝트이다.

 

매우 짧은 기간내에 개발이 이뤄져야 했고,
결제도 붙는 서비스다 보니 구현을 대충할 수도 없던 프로젝트이다.

 

 

 

3. 팀 구성

- 기획 1명

- 디자인 1명

- 프론트엔드 2명

- 백엔드 3명

- 법률 1명

- 마케팅 1명

 

 

4. 기술 스택

Language & Framework

• Java 17
• Spring Boot 3.5.5
• Spring Data JPA
• Spring Security
• JWT

Database

• MySQL
• Redis

DevOps

• GCP
• RDS
• Route53
• Nginx
• Docker
• Firebase
• GitHub Actions

 

 

5. 아키텍처

 

초기 ERD는 다음과 같고, 알람과 결제 기능이 붙으며 관련 테이블이 추가되었다.

 

 

6. 결과 및 성과

첫째 날

믹스패널 기준으로 작성되었다. 서버 관리 내용과 차이가 있을 수 있다.

• 랜딩페이지 진입 횟수 1,606회 (중복제거 실 진입자 1,235명)
• 프로필 작성 완료 사용자 257명
• 채팅방 생성 198건, 채팅 기능 사용자 137명
• 구매 사용자 18명

 

둘째 날(전일과 합산 수치)

믹스패널 기준으로 작성되었다. 서버 관리 내용과 차이가 있을 수 있다.

• 랜딩페이지 진입 횟수 2,368회 (중복제거 실 진입자 1,725명)
• 프로필 작성 완료 사용자 297명
• 채팅방 생성 383건, 채팅 기능 사용자 220명

 

 

7. 향후 계획

일단은 디벨롭 계획은 따로 없는 것으로 보인다.

 

 

8. 후기 및 배운점

후기

짧은 시간 내에 계속해서 바꾸는 기획에 대응해야 했는데, 기존 기능의 변경은 SRP와 OCP를 지키려고 노력한덕분에 금방금방 개발해낼 수 있었다.

열정있는 PM님과 같이했다보니 개발에 대한 의욕은 계속해서 충만할 수 있어서 좋았던 거 같다.

실사용자가 있는 프로젝트를 진행해본 것도 나름의 좋은 경험이라고 생각한다. 실제 서비스 회사를 가게 되면 내 코드에 더욱 애정이 생길 것 같다.

 

 

아쉬운 점

- 데드라인 미흡

학기 중에 진행되는 사이드프로젝트이다 보니 개발에 투자할 수 있는 시간이 부족했다.

PM님의 계획과는 다르게 축제기간까지 계속 개발이 이어졌고, 푸시 알람 기능이 축제 2일차에 개발됨에 따라 초기 사용자들을 제대로 붙잡지 못한 것 같다.

 

 

배운 점

1. 실력있는 사람과의 협업 경험

저번 콕플 프로젝트는 비슷한 실력의 개발자끼리 모였다면, 이번 프로젝트는 확실한 고수분이 계셨다.

Github Actions를 사용한 CI/CD와 소셜로그인쪽을 맡아주셨는데 관련 코드를 보며 그 흐름에 대해 확실히 배울 수 있었던 것 같다.

 

 

2. 1:1 채팅 특화 구현

저번 채팅 기능을 구현할 때는 단체 채팅이 있었기에, 테이블 구조가 그에 맞게 짜여져야 했다.

이번에는 1:1 채팅만 존재했기에 메시지 테이블에 읽음 여부, 차단됨 여부 등을 관리하는 방식으로 구현해보았다.

 

 

3. React를 통합 웹앱에서의 푸시 알람 구현

문제: 어플리케이션 내 채팅 알람을 웹소켓을 통해 전송이 되었으나 어플을 끄면 채팅을 확인할 수 없다.

 

해결: Firebase의 FCM을 통해 푸시 알람을 구현했다. 사용자마다 FCM token을 발급해두고 서버에서 Firebase쪽으로 메시지를 보낼경우 Firebase에서 해당하는 단말기로 푸시 알람을 보내주는 방식이다.

 

하나하나 기능들을 구현해보며 다양한 기획에 대응할 수 있는 자신감을 쌓아가는 것 같다.

 

 

4. 인덱스의 도입

혹시나 우리 프로젝트가 너무 잘되어(?) 서버에 과부하가 올 수도 있다고 생각하고, FETCH JOIN 등으로 쿼리를 최적화했다.

또한 실시간 채팅은 조회 성능이 매우 중요하므로 인덱스를 도입해 성능을 향상시켜보았다.

 

어떤 기준으로 인덱스를 도입하고, 어떻게 도입하면 좋을지 배울 수 있었던 경험이었다.

Ex)

- 리포지토리 내부의 메서드에서 where 절에서 사용되는 필드로 인덱스값 생성

- 역방향 조회의 경우 역방향 인덱스를 생성

 

 

5. 역시나 채팅은 어렵다...

문제: 채팅의 경우 로직이 복잡해 하나의 클래스에 어디까지 역할을 부여할지, 어떤 기준으로 분리할지가 매우 어려운 것 같다.

business 패키지에서 implement 패키지 내의 클래스를 호출하는 방식으로 최대한 구현해보았지만 결국 순환 참조 문제가 생겼다.

 

해결: 이번에도 역시 이벤트와 이벤트 리스너를 통해 해결했다.

 

잘 짜여진 채팅 SDK의 코드를 보고 코드의 흐름을 이해해보는 경험을 방학이 되면 해볼 생각이다.