Mingling은 약속 및 모임 참여자들의 출발역을 기반으로 최적의 중간 지점을 추천하고 모임 목적에 맞는 장소를 탐색할 수 있도록 지원하는 웹서비스입니다.
1. 모임 생성
2. 모임 참여
3. 출발지 등록
4. 중간지점 결과보기
5. 장소 추천
| 항목 | 내용 |
|---|---|
| 개발 기간 | 2025.12 ~ 2026.02 |
| 역할 | 백엔드 개발 (백엔드 4인 중 1인) |
| 상태 | 실배포 운영 중 |
총 10명 팀 프로젝트
| 역할 | 인원 |
|---|---|
| PM | 1명 |
| 디자이너 | 3명 |
| 프론트엔드 개발자 | 2명 |
| 백엔드 개발자 | 4명 |
담당 업무
- 외부 API 연동: 중간 지점 추천에 필요한 외부 API 연동 및 데이터 가공
- Redis 캐싱 설계: 외부 API 호출 횟수 제한 문제를 Redis 캐싱 전략으로 해결
협업 방식
- Jira 기반 이슈 트래킹 및 스프린트 관리
- Swagger 기반 API 명세 공유로 프론트엔드와 개발자와의 명세 공유
- AngularJS 커밋 컨벤션 준수
- GitHub PR 기반 개발 프로세스 (커밋 컨벤션, 브랜치 전략)
| 분류 | 기술 |
|---|---|
| Backend | Spring Boot 4.0.1, Java 21 |
| Database | MariaDB |
| Cache | Redis |
| Documentation | Swagger |
| DevOps | Docker, Nginx, GitHub Actions |
| Cloud | 네이버 클라우드 플랫폼 |
핵심 설계 포인트
- Cache-Aside 패턴 기반 Redis 캐싱으로 외부 API 호출 최소화 및 응답 속도 개선
- 기하학적 중심 계산 -> 후보 지점 선별 -> 편차 기반 공정성 평가의 다단계 알고리즘으로 모든 사용자에게 공정하면서도 효율적인 중간 지점을 추천
문제 상황
- 중간 지점이 산출된 후 장소 추천 기능에서 외부 API를 활용하는데 API 호출 횟수 제한(1,000회/일)이 존재함
- 동일한 출발역 조합에 대해 매번 API를 호출하면 제한에 빠르게 도달하는 문제 발생
해결 방안 검토
| 방법 | 장점 | 단점 |
|---|---|---|
| 로컬 캐시 | 별도 인프라 불필요 | 서버 재시작 시 캐시 소멸 |
| Redis 캐싱 | 영속적 캐시, 빠른 응답 속도 | 별도 인프라 필요 |
- 세션 관리용으로 기도입된 Redis 환경을 공유하여 별도 인프라 구축 비용 없이 즉시 적용 가능했고 서버 재시작 시 데이터가 휘발되는 로컬 캐시는 API 쿼터 절감 효과를 지속하기 어렵다고 판단하여 Redis 채택.
해결
- 동일한 요청 파라미터에 대한 응답을 Redis에 캐싱
- 캐시 히트 시 외부 API 호출 없이 즉시 응답 반환
결과
📎 응답 시간 측정 결과: 1,200ms -> 14ms (클릭하여 펼치기)
적용 전
적용 후
⚡ 1,200ms → 14ms (약 85배 개선)
✅ 외부 API 호출 횟수 절감
✅ API 제한 초과 장애 방지
| 기능 | 설명 |
|---|---|
| 모임 생성 | 모임 생성 및 참여 링크 발급 |
| 모임 참여 | 링크를 통한 모임 참여 |
| 출발지 등록 | 참여자별 출발역 등록 |
| 중간지점 추천 | 출발역 기반 최적 중간 지점 계산 |
| 장소 추천 | 중간 지점 주변 모임 목적에 맞는 장소 탐색 |
GitHub Actions (빌드)
↓
NCP Container Registry (Docker 이미지 Push)
↓
NCP 서버 SSH 접속 -> 최신 이미지 Pull -> 앱 컨테이너 재기동
↓
Health Check 통과 후 이전 이미지 정리
