대학교를 들어가고 나서부터 밴드생활을 시작하고
군대를 다녀와서 연합밴드를 하다보니 항상 합주실 예약은 번거롭고 시간이 많이드는 문제였다
예약 할수 있는 합주실은 많지만 내가 원하는 시간에 비어있는 합주실은 찾기 힘들었고,
원하는 시간에 비어있는 합주실을 찾기위해서는 각 합주실의 방마다 들어갔다 나오기를 반복하며 합주실의 빈시간을 찾아야했다.
그러다보니 운이 좋을때는 한번에 빈 합주실 방을 찾을 수 있었지만
대부분의 사람이 선호하는 합주실은 비슷하기 때문에 운이 없는날은 합주실 예약을 위해서만 30분을 소요할 정도 였다.
그래서 나는 항상 생각했다,
'이 많은 합주실들에 예약가능시간과, 비어있는 시간을 한번에 알수 있으면 얼마나 편할까?'
'내가 합주실 시간을 한번에 볼수 있는 서비스를 만들어볼까?'
그것이 밴드룸의 시작이었다.
종이 스케치에서 첫 MVP까지
처음 한 일은 거창하지 않았다. 노트에 리스트–필터–결과 3단 구성으로 화면을 그렸고, 엑셀에 서울권 합주실을 이름/지역/주소/링크로 모았다. 바로 프로토타입을 만들고 싶었고, 사용 시나리오를 하나로 못 박았다.
“사용자는 지역과 날짜를 고른다 → 지금 비어 있는 방이 먼저 보인다 → 바로 예약 링크로 간다.”
스택은 내가 빨리 다룰 수 있는 걸 골랐다. React로 화면을, FastAPI로 API를, 서버리스 Postgres로 데이터를.
속도와 현실 사이에서
개발을 시작하고 처음 맞닥뜨린 가장 큰 문제는 속도였다.
합주실 정보는 내 DB가 아니라 각 사이트에 흩어져 있었고, 결국 크롤링으로 가져와야 했다. 그런데 이 과정이 생각보다 시간이 많이 걸렸다. 아무리 유용한 정보를 제공해도, 한국 사용자 특성상 응답이 느리면 UX는 급격히 무너진다. 불편함을 호소하며 이탈하는 건 순식간이다.
그래서 그동안 배운 걸 총동원했다. 대기열, 스레드/비동기 처리, 오브젝트 풀링 같은 최적화 기법을 적용했고, 초기에는 파이썬으로 시작했던 수집 로직 일부를 JS 런타임 기반으로 바꿔 병렬 처리 효율을 높였다. 0.1초라도 줄이기 위해 API 호출·파싱·정규화 단계마다 병목을 찾아 깎아냈다.
UI/UX 결정 — 지도가 ‘보조’일 때 더 편하다
UI는 내가 합주할 때의 실사용 경험을 반영했다.
- 데스크톱: 좌측에 지도, 우측에 결과 목록. 스튜디오를 선택하면 지도 마커가 하이라이트되어 위치 감각을 빠르게 잡을 수 있다.
- 모바일: 화면이 좁기 때문에 지도를 메인에서 접고 목록에 집중했다. 필요할 때만 바텀시트 지도를 띄우는 2단 뷰를 실험 중이다.
- 필터는 지역/날짜/시간대/가격/장비로 최소화했고, 정렬 기본값은 **“가까운 시간부터”**로 했다.
테스트에서 확인한 사실 한 가지: 사용자는 **“지금 가능한 곳”**을 5~10초 내에 보고 싶어 한다. 복잡한 검색보다 결정 시간을 줄이는 것이 핵심이었다.
링크 전략 — 지금은 ‘딥링크’, 목표는 ‘원스톱’
초기 목표는 결제를 붙이는 것이 아니라, 사용자가 빨리 결정하도록 돕는 것이었다. 그래서 현재는 각 합주실의 **공식 예약/상세 페이지로 바로 연결(딥링크)**한다. 이탈이 아니라 결정의 완성을 지원하는 셈이다. 장기적으로는 자체 예약·정산을 붙일 계획이지만, 지금은 신뢰와 트래픽을 먼저 쌓는 것이 옳다고 판단했다.
만들면서 배운 것들
- 사용자는 **“어디가 비어있나”**를 즉시 알고 싶다. 검색보다 결정 시간을 줄여야 한다.
- 데이터의 핵심은 화려한 크롤링이 아니라 표준화 계층이었다. Slot 모델이 MVP의 심장이다.
- 모바일에서 지도는 메인 기능이 아니다. 보조 탐색 도구로 두었을 때 만족도가 높았다.
이게 밴드룸이 만들어지기까지의 첫 번째 이야기다.
다음 글에서는 이 구조를 어떻게 더 빠르게 만들었는지, GA4로 오프라인(포스터/QR) 유입을 어떻게 측정하는지, 그리고 유저·사장님 인터뷰가 로드맵을 어떻게 바꿨는지를 이야기해보겠다.
거창한 시작은 아니었다. 그저 합주를 사랑하는 사람이 **“빈 방 찾는 시간”**을 덜어주고 싶다는 마음이었다. 그리고 그 마음이, 지금 작동하고 있다.