home..

썸타임 (Sometime) - 지역 대학생 소개팅 앱

(635 Words, 4 Minutes)

썸타임 (Sometime)

Tech Stack: React Native, NestJS, PostgreSQL, Redis, AWS, Naver Cloud

서비스: 썸타임

Overview

교내 창업 동아리에서 시작하여 런칭 3개월 만에 초기창업패키지 딥테크에 선정된 지역 기반 대학생 소개팅 앱입니다.

기존 소개팅 앱들은 30대 직장인 중심, 수도권 중심이었습니다. 지역 대학생을 위한 서비스가 없다는 문제에서 썸타임은 시작되었습니다.

My Role

초기 멤버 / Product Engineer

기획부터 개발, 운영, CS, 마케팅까지 서비스의 전 과정을 경험했습니다.

개발

백엔드 핵심 기능 개발 (인증, 결제, 매칭 알고리즘)
React Native 앱 개발 및 스토어 배포
어드민 시스템 및 내부 자동화 도구 구축

서비스 기획 & 운영

유저 설문 설계 및 분석을 통한 기능 우선순위 결정
CS 직접 응대 — 데이터만으로 보이지 않는 유저 불만 포착
인앱 커뮤니티에 개발 리포트 공유하며 유저와의 소통 채널 운영

마케팅 & 비즈니스

다른 학교 축제 부스 운영 및 길거리 서비스 홍보
사업계획서 작성, 초기창업패키지 딥테크 선정, 지원사업 집행
지역 확장 의사결정 (매출 데이터 분석 → 대전 집중 전략으로 전환)

Key Achievements

런칭 3개월 만에 초기창업패키지 딥테크 선정
서비스 출시 1년 차 매출 1억 달성
누적 사용자 7,000명 확보
App Store & Play Store 정식 출시

Problem Solving

Case 1: 환불 요청의 근본 원인 찾기

상황

CS 채널과 인앱 커뮤니티에 환불 관련 문의가 부쩍 늘어났습니다. 운영팀에서는 “환불 프로세스를 체계적으로 자동화해달라”고 요청했습니다.

접근

바로 개발에 착수하는 대신, 먼저 환불을 요청한 유저들의 행동 데이터를 분석했습니다.

매칭 후 대화가 거의 이어지지 않는 케이스가 환불 요청의 대부분
유저 설문에서 “상대방에게 무슨 말을 해야 할지 몰라서”가 가장 큰 원인

해결

복잡한 환불 자동화 시스템 대신:

환불 기능은 구글폼 연동 정도로 최소화
개발 리소스를 대화 가이드 기능에 집중

결과

실제로 환불 기능 도입 후 신청 건수는 예상보다 훨씬 적었습니다. 만약 처음 요청대로 복잡한 환불 시스템을 구축했다면, 거의 사용되지 않는 기능에 많은 리소스를 낭비할 뻔했습니다.

교훈

“고객이 요청한 것”과 “고객이 진짜 필요로 하는 것”을 구분하는 것이 핵심이다.

Case 2: 매칭 알고리즘 개선 - 데이터 기반 피드백 루프

상황

초기에는 구글폼으로 직접 매칭을 진행했습니다. 수백 건의 소개팅을 주선하면서 “대화 스타일”과 “가치관의 유사성”이 매칭 성공의 핵심 변수라는 것을 발견했지만, 이 노하우는 운영팀의 머릿속에만 있었습니다.

접근

운영팀과의 피드백 루프를 구축했습니다.

운영팀: “이 커플은 실제로 잘 됐는데, 왜 알고리즘 점수가 낮아요?”

함께 데이터를 분석해보니, 기존 알고리즘이 “취미 일치도”에 과도한 가중치를 두고 있었습니다. 실제 성공 커플들은 취미보다 “대화 선호 스타일”이 비슷한 경우가 많았습니다.

해결

피드백을 반영해 가중치 조정
소개팅 주선자 페르소나가 부여된 에이전트 도입
단순 매칭이 아닌 매칭 사유를 설명하는 기능 추가

"둘 다 깊은 대화를 선호하고, 주말에 조용히 보내는 걸 좋아해요"

결과

유저들이 매칭 결과를 더 신뢰하게 되었고, 첫 대화를 시작하는 비율이 눈에 띄게 높아졌습니다.

교훈

현장의 직관은 가설을 만들고, 데이터가 검증한다. “왜 이것을 추천하는가”를 설명하면 신뢰도가 높아진다.

Technical Highlights

백엔드 핵심 기능

대학교 이메일 인증 — Redis expire 기능을 활용한 시간 제한 인증
PASS 본인인증 로그인 — NHN KCP 및 PortOne 연동, React Native 네이티브 모듈 통합
실시간 알림 — 결제 및 회원가입 승인 요청 시 Slack 자동 알림

어드민 & 자동화

회원가입 승인 시스템 및 관리자 페이지
PR 자동 코드리뷰 시스템
RAG 기반 Slack 봇 (별도 프로젝트로 분리)

앱 빌드 & QA

Android 네이티브 빌드 이슈 해결 (C/C++ 오류 디버깅, Gradle 최적화)
iOS 앱 심사 대응 및 출시 초기 버그 QA

Journey

Phase 1: 축제 버전 (1주일)

마감 일주일을 앞두고 시작한 첫 프로젝트.

결과: 축제 2일간 640명 유저 확보
수익 검증: 2,000원 부가기능에 30%가 결제
기술 스택: Next.js, Supabase

Phase 2: 자체 솔루션 구축 & 사업 확장

시장성을 확인하고 Supabase 의존성을 벗어나 React Native + NestJS로 전환.

한밭대 → 대전권 전체로 확장
초기창업패키지 딥테크 선정
사업계획서 작성, 지원사업 집행에 직접 참여
“지역만 넓히면 매출이 늘 것”이라 예상했지만, 전체 매출의 80%가 대전에서 발생 → 데이터 기반으로 대전 집중 전략으로 전환

Phase 3: 위기와 재정비

인원이 늘어났지만 속도가 선형 증가하지 않았습니다. 커뮤니케이션 비용이 늘어나고 방향성이 흔들렸습니다.

재정 상황과 개발 속도 문제로 팀을 재정비하고, 서비스의 본질에 집중했습니다. 2~3시간씩 방향성 회의를 꾸준히 하며, 무엇을 하지 않을지를 결정하는 것이 무엇을 할지 결정하는 것만큼 중요하다는 것을 배웠습니다.

What I Learned

비즈니스 가치와 기술적 완성도의 균형

스타트업에서 기획부터 운영까지 경험하며, 초기 성장의 속도와 장기적인 코드 품질 사이의 트레이드오프를 체득했습니다.

팀 스케일링의 어려움

인원이 늘어난다고 개발 속도가 선형적으로 증가하지 않습니다. 같은 방향을 바라보게 하는 것 자체가 일입니다.

서비스의 본질

서비스의 진짜 주인은 유저입니다. 개발 리소스를 쏟아서 만든 기능을 유저가 사용하지 않는다면, 지금 집중해야 할 곳에 집중하지 못하고 있다는 뜻입니다.

데이터로 말하기

“이게 더 좋을 것 같다”는 직감은 가설일 뿐입니다. 지역 확장 전략, 매칭 알고리즘 개선 모두 데이터로 검증한 뒤에야 팀 전체가 납득하고 움직였습니다.

개발 밖으로 나가기

부스를 운영하고, 명함을 배포하고, CS에 응대하면서 코드만으로는 볼 수 없는 유저의 목소리를 직접 들었습니다. 이 경험이 기능 우선순위를 정하는 데 가장 큰 도움이 되었습니다.

← Back to Projects