1분반-팅글(tingle)
프로젝트 개요
과제 팀명
TINGLE
지도교수
박관용 교수님
개발기간
2025년 3월 ~ 2025년 6월 (총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 2020920039 이강민(팀장)
서울시립대학교 컴퓨터과학부 2020920030 서동준
서울시립대학교 컴퓨터과학부 2020920059 조종빈
서울시립대학교 행정학과 2021120009 김고은
서론
개발 과제의 개요
개발 과제 요약
본 과제는 대학생 소속 인증 기반 매칭 플랫폼(Tingle)을 개발하는 것을 목표로 한다.기존의 불특정 다수를 대상으로 한 데이팅 애플리케이션이 지닌 신뢰도 부족 및 안전성 미흡의 문제점을 개선하고자 한다. 이를 위해 학교 이메일을 활용한 소속 인증 절차를 도입하여 사용자의 신뢰성을 확보하며,관심사 기반 매칭 시스템과 직관적이고 간결한 UI/UX를 제공함으로써 이용 편의성을 높인다. 또한 본 플랫폼은 단순한 이성 간 만남을 넘어,동아리, 스터디, 취미 교류 등 비교적 가벼운 목적의 만남을 지향한다.이를 통해 온라인 환경에서 대학생 간의 안전하고 활발한 교류를 촉진하는 것을 궁극적인 목표로 한다.
개발 과제의 배경 및 효과
◇ 기존 매칭 서비스는 허위 계정·불투명한 이용자 정보 문제로 인해 신뢰성이 낮고, 대학생 집단에 특화된 기능이 부족하다.◇ 대학생 전용 인증 시스템을 적용하면, 이용자 신원 보장 및 불법적·비건전 활동 차단이 가능하다.◇ 안전한 교류 환경 제공을 통해 대학생들의 사회적 관계망 확장을 돕는다. ◇ 궁극적으로는 기존 매칭 플랫폼이 제공하지 못한, 대학생 맞춤형 소셜 경험과 긍정적 만남 문화 형성을 달성할 수 있다.
개발 과제의 목표와 내용
◇ 대학생 인증 체계(학교 이메일, 재학 여부 검증 등)를 도입하여 신뢰성 있는 사용자 풀을 확보한다. ◇ 관심사·전공·가치관 기반 매칭 알고리즘을 통해 단순 이성 매칭을 넘어, 다양한 교류 형태를 지원한다. ◇ 사용자 피드백과 데이터 분석을 바탕으로 매칭 품질을 지속적으로 고도화한다. ◇ MVP 검증을 거쳐 장기적으로는 매칭을 넘어, 스터디·취미·커뮤니티 기능까지 확장하여 대학생 전용 플랫폼으로 발전시킨다.
개발과제의 경제적 및 사회적 파급효과
본 개발과제는 대학생 소속 인증 기반 매칭 플랫폼 Tingle을 통해, 기존 매칭 서비스의 신뢰도 및 안전성 한계를 개선하고 대학생 맞춤형 소셜 플랫폼의 가능성을 제시한다.대학생 인증을 기반으로 한 차별화된 사용자 풀을 확보함으로써, 향후 프리미엄 매칭 및 커뮤니티 확장 등 지속 가능한 서비스 성장과 경제적 가치 창출이 기대된다.또한 안전한 교류 환경을 조성하여 대학생들의 사회적 관계망 확장을 지원하고, 건전하고 긍정적인 온라인 만남 문화를 형성하는 데 기여할 수 있을 것이다.의 개요===
관련 시장에 대한 분석
경쟁제품 조사 비교
| 구분 | 주요특징 | 한계점 |
|---|---|---|
| Tinder | 글로벌 1위 데이팅 앱으로, 간편한 스와이프 UI를 제공 | 대학생 특화 기능 부족, 신뢰성 확보 어려움 |
| Glam | 국내 인기 앱으로, 추천 알고리즘 기반 매칭 기능 제공 | 소속 인증이 선택적이며, 신뢰도 낮음 |
| 시대팅 | 서울시립대학교 비공식 매칭 서비스로, 대학생 인증 기반으로 동일 소속 간 매칭 제공 | 이성 간 매칭에 한정, 주기적 매칭 기능 부재 |
Tingle의 차별점 및 특성
차별점
◇ 소속 인증: 학교 이메일을 통한 필수 인증 절차로 신뢰성 확보 ◇ 매칭 방식: 관심사 기반 + 주기적 매칭 시스템으로 지속적 교류 유도 ◇ 대상 특화성: 대학생 전용 커뮤니티로 타깃 명확
특성
◇ UX/UI: Tinder를 밴치마킹하여, 가볍고 직관적인 인터페이스로 접근성을 강화한다. ◇ 경쟁 환경: 현재 시장에는 대학생 신분 인증을 기반으로 하면서도 주기적으로 교류를 유도하는 매칭 시스템을 갖춘 서비스가 전무하다. 이에 따라 Tingle은 명확한 시장 공백(Niche Market)을 선점할 가능성이 높다고 판단된다.
본 과제는 대학생이라는 명확한 타깃과 주기적 매칭 기능을 결합한 소속 인증 기반 플랫폼 Tingle을 구축하여, 기존 서비스가 제공하지 못한 신뢰성 높은 환경 속에서 안전하고 지속적인 대학생 교류의 장을 구현하는 것을 목표로 한다.
마케팅 전략
◇ Tingle은 대학생 전용 소속 인증 기반 플랫폼이라는 특성을 강조하여, 재학생 커뮤니티 및 SNS를 중심으로 한 타깃 마케팅을 진행한다. ◇ 학교 이메일 인증과 주기적 매칭 시스템을 핵심 차별점으로 부각시켜, 신뢰성과 지속적인 교류 가능성을 효과적으로 전달한다. ◇ 초기에는 대학생 커뮤니티 내 바이럴 확산을 통해 인지도를 확보하고, 이용자 경험을 기반으로 자연스러운 사용자 확장을 유도한다.
설계
사용자 요구사항
| 번호 | 요구사항 | D or W | 우선순위(상/중/하) |
|---|---|---|---|
| F1 | 랜딩 페이지 - 프로덕트 랜딩 페이지 UI 렌더링 |
D | 중 |
| F2 | 로그인/회원가입 페이지 a. 로그인 페이지 |
D | 상 |
| b. 회원가입 페이지 - ID 중복 여부 검증 |
D | 중 | |
| F3 | 정보입력 및 대학교 인증 페이지 a. 정보 입력 페이지 |
D / W | 상 |
| F4 | 마이페이지 - 본인 프로필 조회(보유 코인, 매칭 횟수 등) |
D | 상 |
| F5 | 코인 충전 페이지 - 사용자가 보유한 코인 표시 |
D | 중 |
| F6 | 유저카드 목록 페이지 (목록 보기) - 접속했을 시, 필터링이 적용되지 않으며 등록 최신순으로 등록된 유저 카드가 보인다. |
D | 상 |
| - 카드는 스와이프 형태 또는 하단의 X/하트 등의 버튼을 통해 친구 신청 및 패스를 조작할 수 있다. | W / D | 하 | |
| - 친구 신청(X/하트) 외에, 유저를 찜할 수 있다. | W / D | 하 | |
| - 유저 카드에는 닉네임, 나이, 성별, MBTI, 학과, 학번, 관심사 및 취미, 졸업·재학 여부, AI 생성형 이미지가 보여진다. | D | 상 | |
| F7 | 유저카드 목록 페이지 (필터링) - 나이/성별/학과/졸업·재학 여부에 대한 정보를 기반으로 목록을 필터링할 수 있다. |
D | 중 |
| - 필터링 여부는 상단에 chip 형태로 볼 수 있으며, 초기화 버튼을 통해 한 번에 해제 가능하다. | W / D | 하 | |
| F8 | 나를 관심있어 하는 유저 보관함 - 유저카드 목록에서 나에게 친구 신청을 보낸 유저들의 목록을 볼 수 있다. (일부 프로필 카드 정보 + 카톡 ID 제공) |
D | 상 |
| - 관심을 보낸 친구에 대해서, 유저에게 개별적으로 카카오톡 ID를 통한 매칭을 성사시킨다. | D | 상 | |
| - 별도의 거절 없이 개별 카드는 3일의 보관 기간을 가지며, 이후에는 자동으로 삭제된다. | W | 하 | |
| - 나를 관심있어 하는 유저가 생길 때, 푸시 알림이 전송된다. | W | 하 | |
| - 아직 친구 신청을 보내진 않았지만, 몇 명의 친구가 나를 찜했는지(관심친구로 설정했는지) count를 좌측 상단에 공개한다. | W | 하 | |
| F9 | 내가 찜한 유저 보관함 - 찜한 유저들을 따로 모아둔 목록으로, 유저 카드 목록과 마찬가지로 해당 페이지 내에서 친구 신청이 가능하다. |
W | 하 |
| F6-메인 | 메인 페이지 a. 상단 상태 표시 영역 |
D | 상 |
| b. 탐색 구역 카테고리 구성 - 기본 무작위 탐색 구역 |
D | 하 | |
| c. 하단 네비게이션바 - 홈(둘러보기)/보관함/LIKE/마이페이지 탭 구성 |
D | 상 |
사용자 요구사항 만족을 위한 기능 정의 및 기능별 정량목표
본 목표는 프론트엔드·백엔드·AI의 주요 성능 및 품질 지표를 정량화하여,서비스의 안정성, 반응성, 품질 신뢰성을 객관적으로 평가할 수 있는 기준으로 활용된다.
클라이언트(Client)
| 구분 | 항목 | 목표 기준 | 비고 |
|---|---|---|---|
| Q1. 성능 지표 | INP (Interaction Next Paint) | 80% 이상 달성 | 사용자 상호작용 응답 속도 |
| LCP (Largest Contentful Paint) | 80% 이상 달성 | 주요 콘텐츠 로드 속도 | |
| CLS (Cumulative Layout Shift) | 80% 이상 달성 | 시각적 안정성 확보 | |
| Q2. 테스트 품질 | UI Test 커버리지 | 90% 이상 달성 | 주요 컴포넌트 자동화 테스트 포함 |
| Q3. 안정성 관리 | 센트리(Sentry) 기반 에러 모니터링 | 정상 구축 및 실시간 대응 가능 | 에러 발생 시 Slack/Webhook 연동 알림 |
서버(Server)
| 구분 | 항목 | 목표 기준 | 비고 |
|---|---|---|---|
| Q1. 응답 성능 | 주요 API 응답 속도 | 300~500ms 이내 | 평균 응답 시간 기준 |
| Q2. 처리 안정성 | 트래픽 처리 능력 | 50~150 RPS 수준에서 오류 없이 처리 | 부하 테스트 기준 |
| Q3. 데이터 성능 | 주요 조회 쿼리 응답 속도 | 200ms 이내 | 병목 현상 없이 처리 |
| Q4. 복구 신속성 | 서버 재시작 / DB 연결 복구 시 정상화 시간 | 30초 이내 | 자동 재연결 및 헬스체크 로직 적용 |
인공지능(AI)
| 구분 | 항목 | 목표 기준 | 비고 |
|---|---|---|---|
| Q1. 응답 성능 | 이미지 생성 요청 응답 시간 | 10초 이내 | 프롬프트 입력 후 결과 수신까지 |
| Q2. 정확도 및 품질 | 생성 이미지의 프롬프트 반영도 | 80% 이상 | 부하 테스트 기준 |
| 이미지 시각적 완성도 | 유저 만족도 80% 이상 | 샘플 기반 품질 검증 | |
| Q3. 처리 안정성 | 동시 요청 처리 성능 | 5~10건 동시 요청 시 성능 저하 없음 | 서버 스케일링 및 큐 시스템 적용 |
시스템 모듈 목표
◇ 서버 장애 복구 자동화 모듈 (Self-Recovery System) 서버 재시작이나 DB 연결 장애 발생 시, 자동으로 서비스 복구 루틴을 수행하는 스크립트를 구축한다.
- 장애 발생 시 즉시 헬스체크 수행 → 자동 복구 트리거 - “30초 이내 정상화” 지표 달성 가능 - 에러 로그는 Sentry로 자동 전송 - 지표 대응: 서버 안정성, 에러 모니터링 항목
기능 구현을 위한 세부기술 선택사항 (디자인)
◇ 스와이프 카드 인터랙션 UI (Swipe-based Matching Interface) 사용자는 카드 형태로 표시된 친구 프로필을 스와이프(좌·우) 하거나, 하단의 버튼을 눌러 손쉽게 친구 신청 또는 패스를 할 수 있다.. 이를 통해 간결하고 직관적인 상호작용을 제공하며, INP(Interaction Next Paint)와 UI 반응성을 높인다.
- UX 향상: 직관적인 카드 인터랙션으로 사용자 몰입도 상승 - 성능 지표 대응: INP 80% 이상 달성 (터치 이벤트 반응 최적화) LCP, CLS 개선 (부드러운 애니메이션 적용): - 기술 포인트: 이벤트 버블링 최소화로 지연 없는 터치 반응 UI 테스트를 통해 커버리지 90% 이상 확보
소프트웨어 설계
본 서비스는 AWS 기반 인프라로 구성되어, Route53과 CloudFront를 통해 안정적인 트래픽 처리와 빠른 콘텐츠 제공을 지원한다.백엔드는 EC2 환경에서 Django 서버로 운영되며, RDS를 통해 사용자·매칭·인증 데이터를 안정적으로 관리하고 SES를 활용해 이메일 인증을 수행한다.또한 ERD는 사용자, 프로필, 관심사, 매칭, 인증 등 핵심 도메인을 중심으로 설계되어, 대학생 소속 인증과 주기적 매칭 흐름을 효율적으로 지원하도록 구성되었다.
결과 및 평가
완료 작품 소개
서비스 소개 페이지
Tingle 서비스의 기획 배경, 주요 기능, 서비스 목적을 전반적으로 확인할 수 있는 소개용 페이지
| 번호 | 화면 명 | 화면 설명 |
|---|---|---|
| 1 | 서비스 시작 화면 | 서비스 로고와 슬로건을 노출하여 Tingle의 정체성과 목적을 전달하는 초기 진입 화면 |
| 2 | 로그인 화면 | 학교 이메일과 비밀번호를 통해 기존 사용자가 로그인하는 화면 |
| 3 | 회원가입 화면 | 이메일 중복 확인 및 비밀번호 조건 안내를 포함한 회원가입 화면 |
실행(run)
SW 와이어 프레임 별 화면 설명
| 번호 | 화면 명 | 화면 설명 |
|---|---|---|
| 1 | 서비스 시작 화면 | 서비스 로고와 슬로건을 노출하여 Tingle의 정체성과 목적을 전달하는 초기 진입 화면 |
| 2 | 로그인 화면 | 학교 이메일과 비밀번호를 통해 기존 사용자가 로그인하는 화면 |
| 3 | 회원가입 화면 | 이메일 중복 확인 및 비밀번호 조건 안내를 포함한 회원가입 화면 |
| 4 | 이메일 인증 화면 | 학교 이메일로 인증 코드를 발송하여 대학생 소속을 검증하는 단계 |
| 5 | 메인 화면 | 이성 매칭, 친구 매칭 등 탐색 유형을 선택하는 메인 진입 화면 |
| 6 | 마이페이지 | 사용자 프로필 및 기본 정보를 확인·수정할 수 있는 개인 정보 관리 화면 |
| 7 | 친구 요청 목록 화면 | 나를 좋아하는 사용자와 내가 좋아요를 보낸 사용자를 확인하는 화면 |
| 8 | 좋아요 목록 화면 | 찜을 누른 유저 프로필 탐색 및 친구 신청 전송 화면 |
| 9 | 매칭 탐색 화면 | 필터 조건을 설정해 사용자를 탐색하고 매칭 인터랙션을 수행하는 핵심 화면 |
| 10 | 매칭 필터링 화면 | 학과/성별/나이/재학 여부를 선택해 프로필·탐색 조건에 반영하는 모달 화면 |
| 11 | 매칭 목록 화면 | 서로에게 친구 신청을 한 경우, 카카오 ID 정보를 포함한 유저 프로필을 확인하는 화면 |
| 12 | 프로필 입력 화면 | 자신의 정보를 작성하는 화면 |
성과물
대외전시 포스터 및 홍보글
대학생 소속 인증 플랫폼으로서 초기 사용자 유입을 목적으로 마케팅 활동을 진행하였다. 이를 위해, 재학생 커뮤니티인 에브리타임에 홍보 게시글을 총 2회 게재하였으며, 타켓으로 한 이벤트성 홍보 포스터를 제작하였다, 또한, 서비스의 목적과 사용 방식을 보다 효과적으로 전달하기 위해 추가적으로 랜딩 페이지를 기획·제작하였다.
그 결과, 2주간의 홍보 기간 동안 단 2건의 게시글만으로 약 21명의 신규 사용자 유입을 달성하였다. 이는 제한적인 홍보 리소스 상황에서도 타겟 커뮤니티와 시기 적합한 콘텐츠 구성이 초기 사용자 확보에 효과적이었음을 보여준다.
완료 작품의 평가
평가 기준
a. 클라이언트 - 사용자 경험 품질을 높이기 위해 코어 웹 바이탈(Web vital)이 충분히 높은가? - User Interface가 유스케이스에 맞게 정상 동작하는가? - 클라이언트 단 에러 모니터링 시스템이 정상적으로 동작하는가?
b. 서버 - 서버 응답 속도는 충분히 빠른가? - 서버 부하에 따른 안정성이 유지되는가? - 데이터베이스 쿼리 성능이 병목 없이 동작하는가? - 서버 장애 복구 시 응답 복구 속도는 충분히 빠른가?
c. AI - 이미지 생성 요청 시 10초 이내에 결과가 생성되는가? - 이미지 생성 결과의 품질이 사용자 기대 수준에 부합하는가? - 동시 생성 요청 시 성능 저하 없이 안정적으로 동작하는가?
평가 내용
a. 클라이언트 - INP(Interaction Next Paint) 지표가 80% 이상을 달성했는가?
- LCP(Largest Contentful Paint) 지표가 80% 이상을 달성했는가?
- CLS(Cumulative Layout Shift) 지표가 80% 이상을 달성했는가?
- UI Test 커버리지 90% 이상을 달성했는가?
- 센트리를 활용한 에러 모니터링 시스템이 정상 구축되었는가?
b. 서버 - 서비스의 주요 API에 대해 응답 시간이 300~500ms 이내인가?
- 50~150 RPS의 수준의 트래픽이 발생할 때 오류 없이 안정적으로 처리되는가?
- 주요 조회 쿼리 실행 시 병목 없이 200ms 이내에 응답하는가?
- 서버 재시작 또는 DB 연결 복구 시 서비스가 30초 이내에 정상화되는가?
c. AI
- 이미지 생성 요청 시 10초 이내에 결과가 생성되는가?
- 생성된 이미지가 프롬프트를 정확히 반영하고, 시각적으로 완성도가 높은가?
- 5~10건의 동시 생성 요청 시에도 성능 저하 없이 처리되는가?
완료 작품의 평가
프론트엔드
Core Web Vital
본 프로젝트는 웹페이지의 사용자 경험(UX)을 정량적으로 개선하기 위해 Core Web Vitals을 주요 평가 기준으로 설정하였다. Core Web Vitals은 웹페이지의 로딩 속도(Loading Performance), 인터랙션 반응성(Interactivity), 시각적 안정성(Visual Stability)을 측정하여, 서비스 품질을 객관적으로 관리할 수 있도록 하는 사용자 중심의 성능 지표이다.
지표를 기준 이상으로 충족한 웹페이지는 일반적으로 이탈률이 감소하고, 페이지 체류 시간 및 재방문율이 향상되는 경향을 보인다. 이러한 개선은 사용자 경험 퍼널(UX Funnel) 상에서 광고 노출, 결제 전환율 등 비즈니스 지표 전반에 긍정적인 영향을 미친다. 또한, Google 검색 엔진에서의 평가 향상으로 이어져 유입 트래픽 확보 측면에서도 경쟁 우위를 확보할 수 있다.
개선 목표
웹페이지 마운트 과정에서의 렌더링 병목 현상 및 불필요한 코드 실행, 시각적 불안정성을 최소화하기 위해 다음 세 가지 축을 목표로 설정하였다. b-1. 이미지 및 리소스 로딩 병목 제거 b-2. 스크립트 실행 시간 단축 b-3. 렌더링 및 시각적 안정성 최적화
코드 개선
c-1. 코드 스플리팅(Code Splitting) 적용 초기 마운트 시점에 불필요한 모듈을 제외하고, 페이지별 코드 단위로 분리하여 로드되는 스크립트의 양을 감소시켰다. 이를 통해 초기 로딩 속도(LCP, Largest Contentful Paint)를 개선하였다.
c-2. 로그인 검증 요청 개선 페이지 진입 시 수행되던 중복 로그인 검증 요청(fallback request)을 제거하였다. 네트워크 요청 횟수 감소로 인한 TTFB(Time to First Byte) 단축 및 불필요한 서버 부하를 해소하였다.
c-3. 시맨틱 태그 준수 HTML 시맨틱 마크업을 준수하여 접근성을 강화하였다. 이는 SEO(검색엔진최적화)뿐 아니라, 장애인 및 보조기기 사용자에 대한 접근성(A11y) 개선 효과를 가져왔다.
c-4. 스켈레톤 UI(Skeleton UI) 도입 주요 이미지 및 콘텐츠 로딩 전 placeholder UI를 제공하여 CLS(Cumulative Layout Shift) 지표를 현저히 개선하였다. 사용자는 화면 요소가 갑작스럽게 이동하는 현상을 겪지 않으며, 더욱 안정적인 초기 렌더링 경험을 제공받는다.
c-5. 프레임 드롭 방지 및 60fps 유지 자바스크립트 실행 중 프레임 드롭을 유발하던 블로킹 스크립트를 비동기 처리로 전환하였다. 메인 스레드의 점유율을 최적화하여 렌더링 프레임레이트(60fps)를 안정적으로 유지하였다.
개선 결과
개선 작업 전·후 비교 결과, 페이지 최초 진입 시점의 로딩 속도와 시각적 안정성이 눈에 띄게 향상되었다. 특히 LCP와 CLS 지표가 각각 개선되며, 사용자 체감 품질과 전환 퍼널 단계에서의 이탈률이 유의미하게 감소하였다.
서버
| 평가 항목 | 목표 기준 | 측정 결과 | 판정 |
|---|---|---|---|
| 응답 속도 | 평균 300~500ms 이내 | 평균 94ms / p(95) 405ms | 적합 (우수) |
| 처리량 | 50~150 RPS 안정적 처리 | 65 RPS (최대 부하 시) | 적합 |
| DB 성능 | 쿼리 응답 200ms 이내 | 평균 0.1ms 미만 (병목 없음) | 적합 (매우 우수) |
| 복구 능력 | 장애 시 30초 이내 복구 | 약 20~24초 소요 | 적합 |
인공지능
| 평가 항목 | 목표 기준 | 측정 결과 | 판정 |
|---|---|---|---|
| 이미지 생성 응답 속도 | 10초 이내 | 10초 이내 달성 | 적합 |
| 생성 이미지의 프롬프트 반영도 | 80% 이상 | 80% 이상 일치 | 적합 |
| 이미지 시각적 완성도 | 사용자 만족도 조사 | 만족도 80% 이상 | 적합 |
| 동시 요청 처리 성능 | 5~10건 동시 요청 시 지연 여부 | 지연 및 성능 저하 없음 | 적합 |
향후 계획 =
어려웠던 내용들
● 제외 유저(최근 조회, 매칭, 본인) 필터링을 위해 UserAction, Match 등 여러 테이블을 조인 및 Set 연산으로 조합해야 했으며, 이 과정에서 쿼리 구조가 복잡해지고 최적화가 어려웠다.
● 잔액이 부족한 경우, 단순 차단이 아니라 로그를 기반으로 마지막 조회 카드를 보여주는 예외 처리를 구현했다. transaction.atomic()을 통해 코인 차감과 로그 생성을 원자적으로 묶어 동시 요청 시의 데이터 불일치를 방지했다.
● 본 프로젝트는 미팅 대상을 주 사용자로 하는 특성상, 입력 형태가 가변적이며 향후 변경 가능성이 매우 높다. 이에 따라 질문과 응답의 기본적인 구조는 일관되게 유지하되, 화면 표현 방식(presentation layer)의 변화를 유연하게 수용할 수 있도록 설계 방향을 설정하였다. 특히 프로필 입력의 전체 흐름을 하나의 Context API 내부에서 관리함으로써, 폼(form) 관련 로직과 의존성을 분리하고 각 모듈 간 결합도를 낮추었다. 이를 통해 추후 프로필 관련 기획이 변경되더라도, 해당 영역의 코드만 수정하면 되는 구조를 확보하였으며, 결과적으로 유지보수성과 확장성을 모두 고려한 설계를 구현하였다.
● 이미 조회한 사용자를 제외하고 새로운 사용자를 추천하는 과정에서, 데이터 증가에 따른 DB 성능 저하와 확장성 문제를 해결하는 데 어려움이 있었다.
● 리소스 소모가 큰 이미지 생성 작업을 사용자 경험(UX) 저하 없이 처리하기 위해 비동기 처리 시스템을 구축하는 과정에서 기술적 시행착오가 있었다.
차후 구현할 내용
● 백엔드 결제 API는 구현되었으나 프론트엔드 연동과 Toss Payments 가입 등의 절차가 남아있다. 이를 마무리해 실제 사용자가 결제부터 포인트 충전까지 원활하게 진행할 수 있는 상용 환경을 구축할 예정이다.
● 현재 동기적으로 처리되는 무거운 작업(카드 후보 선정, 과금 처리)을 비동기 큐(Queue) 시스템으로 분리하여, 사용자 요청에 대한 응답 속도를 단축하고 시스템 확장성을 확보하는 방향으로 아키텍처를 고도화할 계획이다.
● 누적되는 사용자 행동 데이터를 기반으로 매칭 정확도를 높이는 알고리즘 개선 작업을 최우선으로 진행할 예정이다.
● 충분한 데이터셋이 확보된 후, 머신러닝(ML) 모델 학습 또는 정교한 가중치 수식 적용을 통해 사용자별 취향을 반영한 맞춤형 추천 시스템을 도입할 계획이다.
개발 사업비 정산
사업 개발비 내역서
| 항목 (품명, 규격) | 수량 | 단가 | 금액/계 | 금액/현금 | 비고 |
|---|---|---|---|---|---|
| AWS 서버비 (2개월) | 1 | 2.1 | 2.1 | 2.1 | |
| 도메인 구입비 | 1 | 6.6 | 6.6 | 6.6 | |
| Cursor 구독비 (2개월) | 1 | 61.4 | 61.4 | 61.5 | |
| Cursor Token 사용 비용 (2개월) | 1 | 76.1 | 76.1 | 76.1 | |
| 도서 구입비 | 1 | 414.3 | 414.3 | 414.4 | |
| 합계 | 560.5 | 560.5 |











