배경
시대팅은 서울시립대학교 IT 동아리인 시대생에서 재학생들을 대상으로 운영하는 소개팅 서비스다. 매 학기 이벤트성으로 열리는 이 서비스는 동아리 운영비 확보와 앱 사용자 유치를 목적으로 한다. 이번 시대팅 시즌5 프로젝트는 내가 속한 TF에서 기존에 개발중이던 맛집 혼잡도 서비스가 의견 충돌로 무산된 후, 새로운 방향성을 모색하던 과정에서 채택되어 시작하게 되었다.
프로젝트 기간은 9월 30일부터 12월 9일까지였으며, 그 중 백엔드 개발은 11월 1일부터 12월 1일까지 이루어졌다. 서비스는 12월 2일부터 9일까지 운영되었으며, 신청 기간은 12월 2일부터 4일간, 결과 발표는 12월 7일부터 3일간 진행됐다.
킥오프 미팅에서 우리 팀이 설정한 목표는 기존의 자원을 활용하여 안정적이고 만족도 높은 서비스를 제공하는 것이었다. 특히 여성 참가자의 매칭률 100%를 달성하는 것과 높은 매칭 만족도를 주요 과제로 설정했다. 개인적으로는 문서화를 체계적으로 진행하고, 매칭 알고리즘을 개선하며, 대규모 트래픽을 고려한 설계를 경험하는 것을 목표로 하였다.
타깃 사용자는 시립대 학부생뿐만 아니라 대학원생과 졸업생까지로 설정하였으며, 신청 기간 동안 유저 데이터를 수집한 뒤 매칭을 진행하여 결과를 발표하는 형식으로 운영하였다. 주요 기능으로는 재학생 인증, 미팅 신청(1대1 또는 3대3 방식), 매칭, 결과 발표가 있다.
팀 구성
팀원 명단
본 프로젝트에는 총 10명(기존 TF 구성 그대로 넘어오다보니 소규모로 진행되었다)이 참여하였으며, 역할은 PM, 기획, 마케팅, 디자이너, 프론트엔드, 백엔드로 구성되었다. 협업 도구로는 Slack, Notion, Figma, Discord, 카카오톡을 사용했으며 프론트엔드와의 API 명세 공유에는 Swagger를 활용했다. 백엔드 간 협업은 Slack과 대면 작업을 적절히 섞어 진행하였다.
나는 백엔드 개발자로 이메일 인증, JWT 인증, 매칭 결과 조회, 매칭 알고리즘, 관리자 API 등의 기능을 담당했다. 그리고 인증 시스템과 매칭 알고리즘 구현에 특히 집중하였다.
시스템 아키텍처
백엔드 아키텍처
ERD
백엔드 프로젝트 구조
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
.
├── admin
│ ├── api
│ ├── dto
│ ├── exception
│ └── service
├── global
│ ├── aop
│ ├── auth
│ │ ├── api
│ │ ├── dto
│ │ ├── exception
│ │ ├── filter
│ │ ├── security
│ │ ├── service
│ │ └── util
│ ├── common
│ │ └── dto
│ ├── config
│ ├── error
│ │ └── exception
│ ├── external
│ ├── interceptor
│ └── util
├── match
│ ├── api
│ ├── dao
│ ├── dto
│ ├── entity
│ ├── exception
│ ├── repository
│ ├── service
│ └── util
├── meetingteam
│ ├── api
│ ├── dao
│ ├── dto
│ ├── entity
│ ├── exception
│ ├── repository
│ ├── service
│ └── util
├── payment
│ ├── api
│ ├── dao
│ ├── dto
│ ├── entity
│ ├── exception
│ ├── repository
│ └── service
├── user
│ ├── api
│ ├── command
│ ├── dao
│ ├── dto
│ ├── entity
│ ├── exception
│ ├── repository
│ └── service
└── verification
├── api
├── dto
├── exception
├── service
└── util
기술 스택
프론트엔드는 TypeScript+React를, 백엔드는 Kotlin+Spring Boot를 사용했다.
배포는 프론트엔드의 경우 Amazon CloudFront를, 백엔드의 경우 Amazon EC2를 기반으로 이루어졌다. CI/CD는 GitHub Actions를 통해 자동화했으며, Gradle 빌드부터 Docker 이미지 생성 및 배포까지의 과정을 효율적으로 관리했다.
백엔드 아키텍처는 EC2에 Docker 컨테이너로 Spring Boot를 실행하고, Redis를 설치해 스프링 애플리케이션과 연결하는 방식으로 구성하였다. 데이터베이스는 RDS(PostgreSQL)를 사용했으며, 이메일 전송은 Simple Email Service(SES)를 통해 처리했다.
서비스 프로세스
 |  |
주요 흐름
- 사용자 인증: 사용자가 페이지에 접속하면 액세스 토큰의 유효성을 검사하고, 필요시 리프레시 토큰을 통해 재발급 요청을 처리한다. 인증되지 않은 유저의 경우, 이메일 인증 절차를 진행한다.
- 미팅 신청: 1대1 미팅 신청은 개인 정보와 선호 사항을 입력하고 결제를 완료하면 등록된다. 3대3 미팅 신청은 팅장이 팀을 생성하고, 팅원들을 초대해 신청을 완료하는 방식이다.
- 매칭: 신청 정보는 CSV로 추출한 뒤 알고리즘으로 매칭을 진행하며, 결과는 다시 데이터베이스에 저장한다. 발표일에는 매칭 결과를 기반으로 유저가 상대방의 정보를 확인할 수 있다.
결과
프로젝트 성과
신청자 통계
- 1대1 매칭
- 신청 수: 716명 (남성 540명, 여성 176명), 매칭 수: 176건.
- 남성 매칭률: 32.59%, 여성 매칭률: 100.00%.
- 3대3 매칭
- 신청 수: 318명 (남성 80팀, 여성 26팀), 매칭 수: 26건.
- 남성 매칭률: 32.50%, 여성 매칭률: 100.00%.
수익성 및 사용자 만족도
- 수익: 1,016,000원 (1대1: 704,000원, 3대3: 312,000원).
- 만족도 (데이터 분석 기준): 선호사항 반영률 평균 96.97%, 핵심 항목 반영률 100%.
프로젝트 목표
- 매칭 알고리즘 개선
- 2단계 매칭 도입으로 만족도 상승(전 항목 반영률 +0.7%, 핵심 항목 반영률 +5%) 및 여성 매칭률 100% 달성.
- 문서화 강화: PR, README, Notion 작성.
도전과 성장
이번 프로젝트에서의 가장 큰 도전 과제는 기존 어카운트 서버를 활용할 수 없는 상황에서 인증 기능을 새롭게 개발해야 했던 점이었다. 추가로 Redis와 Amazon SES와 같은 기술을 새롭게 학습하고 적용해야 했던 것도 중요한 과제였다.
Refresh Token Rotation 도입 과정에서 발생했던 인증 관련 이슈도 기억에 남는다. 서버에 변경사항을 배포한 후 API 요청 시 인증이 풀리는 문제가 발생했는데, 이는 프론트엔드의 API 호출과 토큰 관리 로직이 변경된 백엔드의 인증 정책과 호환되지 않았기 때문이었다. 이를 위해 프론트엔드와 백엔드 모두가 다양한 해결 방법을 검토했으며, 최종적으로 프론트엔드의 API 호출 로직을 수정함으로써 문제를 해결하였다. 이 경험을 통해 기능 설계 시 클라이언트와의 상호작용을 더 면밀히 검토해야 함을 배웠다. 또한 문제 해결 과정에서 프론트엔드와 백엔드 양쪽의 관점에서 접근하는 법도 배울 수 있었다.
이번 프로젝트가 특별했던 이유는 실제 사용자들과 소통하며 서비스를 개선할 수 있었기 때문이다. 기존의 프로젝트들이 대부분 개발 단계에서 끝났던 것과 달리, 이번에는 서비스 런칭부터 운영, 피드백 수집까지의 전체적인 과정을 경험해볼 수 있었다. 또한 매칭 실패(성비 불균형), 상대의 프로필 사진 미등록 등 서비스 종료 후 받은 다양한 피드백들은 다음 시즌의 개선 방향을 설정하는 데 중요한 자료가 되었다.
시대팅 시즌5는 단순한 이벤트를 넘어 다양한 문제를 해결하며 성장할 수 있었던 값진 경험이었다. 또한 안정적인 서비스 제공과 목표 달성을 통해 유의미한 성과를 만들어냈다는 점에서 큰 보람도 느낄 수 있었다.
아쉬움
반면 아쉬움도 조금 남았는데, 제일 아쉬운 점은 시간과 인력의 부족이다. 한 달이라는 짧은 개발 기간 동안 기본 기능 구현에 집중해야 했기 때문에 코드 품질 개선이나 기술적 도전에 충분한 시간을 할애하지 못했다. 백엔드의 경우 개발자 2명이 모든 기능을 담당하다보니 각자 맡은 작업에만 집중해야 했고, 서로의 코드를 리뷰하거나 더 나은 설계를 고민할 기회가 부족했다.
기술적인 면에서의 아쉬움도 크다. 새로운 기술을 적극적으로 도입하거나 디자인 패턴과 아키텍처에 대해 충분히 고민하지 못한 점이 대표적이다. 일례로 운영기간에 백엔드에서 변경사항을 배포하면 1분가량 서비스가 중단되었는데, 이러한 일이 여러 차례 반복되자 무중단 배포 전략의 필요성을 실감하였다. 하지만 서비스가 운영되는 와중에 새로운 배포 전략으로 변경하는 것이 부담이 되어 결국 실제로 적용하지는 못했다. 서비스 오픈 전에 충분한 시간을 두고 이러한 점들을 미리 고려했다면 좋았을 것 같다. 이외에도 서비스의 안정성과 유지보수성을 높일 수 있는 테스트 코드를 작성해보지 못한 부분도 아쉬움으로 남는다.
이러한 경험은 다음 프로젝트를 준비할 때 중요한 교훈이 될 것이다. 더 넉넉한 개발 기간을 확보하고, 적절한 인력 구성을 통해 코드 리뷰와 기술적 도전을 충분히 할 수 있는 환경을 만드는 것이 필요하다고 느꼈다.