골퍼스 골프 연습장 이용·예약 플랫폼

어떤 서비스인가

골프 시뮬레이터를 만들고 아카데미 지점을 운영하는 회사의 연습장 이용 플랫폼입니다. 골퍼는 앱에서 주변 연습장과 레슨 프로를 비교해 이용권과 레슨권을 사고, 타석과 레슨을 예약합니다. 매장은 파트너센터에서 타석·이용권·예약을 관리하고, 프로는 같은 앱에서 프로 모드로 전환해 레슨 일정을 운영합니다. 본사는 관리자 화면에서 매장·프로·정산을 봅니다.

기능이 많은 서비스지만, 설계의 중심은 하나였습니다. “이용권 한 장이 누구의 손을 거쳐 어떻게 소진되는가.” 골퍼가 사고, 매장이 확인하고, 프로가 승인하고, 본사가 정산하는 흐름이 이용권 하나에 다 걸려 있습니다.

무엇이 문제였나	어떻게 풀었나
연습장마다 요금·시설·프로가 달라 비교가 안 된다	지도 기반 검색에 매장 유형·회당/월 요금·평점을 한 카드에 표시
이용권 종류가 많다(회수권·기간권·레슨권·시간대별 가격)	이용권을 종류·시간대·유효기간을 가진 상품으로 정의하고, 예약 직전에 보유 이용권을 골라 쓰게 함
레슨은 골퍼·프로·매장 셋의 일정이 맞아야 성립한다	프로의 활동 매장과 요일·시간을 등록해 두고, 구매 후 프로 승인으로 확정
매장이 직영·제휴·일반으로 달라 처리 방식이 다르다	매장 유형을 데이터로 두고, 파트너센터의 사용 처리·노쇼 처리로 현장을 맞춤
프로가 여러 매장에서 활동한다	프로↔매장 활동 관계를 별도로 관리하고, 매장·프로 정산을 각각 계산

무엇을 만들었나

골퍼 앱 (iOS · Android 네이티브)

• 연습장 검색 — 지도·목록, 실내·실외·스튜디오·스크린 필터, 거리순 정렬, 즐겨찾기, 후기
• 프로·레슨 검색 — 지도·목록, 프로 프로필(자격증·스윙 영상), 레슨권 상세
• 이용권 — 회수권·기간권 구매, 보유 목록, 남은 횟수·기간, 초대코드로 이용권 공유
• 예약 — 타석·시간 칸 선택, 레슨 예약, 취소, 예약 내역
• 결제 — 카드·간편결제·가상계좌, 쿠폰
• 그 밖 — 스토리(피드·댓글), 연습 기록, 레슨 노트 받기, 알림, 온보딩 설문

프로 모드 (같은 앱에서 전환)

• 레슨 관리 — 일·주·월 스케줄, 레슨 요청 승인·거절, 자동 승인 설정
• 회원 관리 — 수강생 목록, 레슨 노트 발급(코멘트·사진·영상)
• 활동 매장 — 매장별 활동 요일·시간, 매장의 활동 제안 수락, 정산 조회

파트너센터 (매장용 웹)

• 대시보드·예약 현황판 — 오늘 예약, 이용권·레슨권 사용 처리, 노쇼 처리
• 매장 관리 — 기본 정보, 운영 시간·휴무, 타석(번호·스크린 여부·센서 브랜드·그룹), 락커
• 상품 — 타석 이용권 등록·판매 현황, 레슨 환경 설정(공간 이용료·단위 시간), 쿠폰
• 프로 — 구인 등록, 활동 제안, 활동 프로 목록
• 매출·정산 — 일·월·건별 매출, 이용권·레슨권 사용 내역, 후기 답변

관리자 (본사용 웹)

• 파트너 관리(등록·비밀번호 발급·활동 제한), 프로 인증 승인, 회원 관리
• 시뮬레이터(센서 브랜드) 설정, 쿠폰·배너·게시판·문의 답변
• 매장 정산·프로 정산(일·월·건별), 실시간 결제 현황, 대시보드

서버·인프라

• Java · Spring Boot · MyBatis · MariaDB(Aurora), JWT 인증, S3 파일 저장
• AWS Route 53 → 로드밸런서 → EC2 3대, RDS
• GitHub Actions → S3 → CodeDeploy 자동 배포, 장애 조치 매뉴얼

어떻게 설계했나

1. 이용권을 “상품”과 “보유권”으로 나눴습니다. 매장이 등록하는 이용권(종류·가격·1~4부 시간대 가격·사용 요일·유효 기간·타석 이용 시간)과, 골퍼가 산 뒤 생기는 보유권(남은 횟수·등록일·만료일·상태)은 다른 것입니다. 상품이 바뀌어도 이미 산 사람의 조건은 그대로여야 하고, 정산은 보유권 단위로 돌아갑니다. 이 둘을 처음부터 분리해 두었기 때문에 뒤에 붙은 쿠폰·공유·환불 규칙이 상품 쪽을 건드리지 않았습니다.

2. 타석 예약을 시간 칸으로 계산했습니다. 타석은 이용 시간(25분·55분)에 정비 시간 5분을 더한 칸 단위로 찹니다. 매장 영업시간·정기 휴무·임시 휴무·공휴일, 시간대별 가격이 같은 계산에 들어갑니다. 예약 한 건에는 시작 칸과 칸 수, 정비 시간을 포함한 종료 시각을 같이 저장해 “이 타석이 지금 비었는가”를 조회 한 번으로 답하게 했습니다.

3. 레슨은 프로 승인으로 확정되는 3자 거래로 두었습니다. 레슨권은 사는 순간 확정되지 않습니다. 프로가 매장과 확인한 뒤 승인해야 하고, 90분 안에 응답이 없으면 자동 취소됩니다. 프로는 자동 승인을 켤 수도 있습니다. 레슨이 가능한 곳은 프로의 활동 매장 중 활동 요일·시간이 겹치는 곳뿐이라, 프로↔매장 활동 관계를 별도 데이터로 두고 스케줄 화면에서 매장별 색으로 구분했습니다.

4. 매장 유형에 따라 “사용 처리”의 주체를 달리했습니다. 직영·제휴·일반 매장은 현장에서 이용권을 확인하는 방식이 다릅니다. 앱은 어느 매장이든 같은 화면을 쓰되, 실제 소진은 파트너센터의 사용 처리와 노쇼 처리로 끝나게 했습니다. 예약 전날 자정까지는 취소가 되고, 당일 취소와 노쇼는 이용권이 차감됩니다.

5. 환불 규칙을 데이터로 계산하게 했습니다. 7일 안에 등록하지 않은 이용권은 전액, 등록 뒤에는 위약금이 붙고, 등록 기간이나 유효 기간이 지나면 환불이 안 됩니다. 취소 수수료는 쿠폰 할인 전 금액으로 계산하고, 결제 수단 → 포인트 → 쿠폰 순서로 뺍니다. 이 규칙이 코드 곳곳에 흩어지지 않도록 이용권 상태(대기·진행 중·만료·사용 완료·결제 취소)와 등록일·만료일을 기준으로 한곳에서 판정합니다.

6. 프로와 매장을 서로 찾게 했습니다. 매장은 구인을 올리고 프로에게 활동을 제안하며, 프로는 수락·거절합니다. 프로 한 명이 여러 매장에서 활동하는 것이 전제라, 매장 정산과 프로 정산을 따로 계산하고 매장별 레슨 공간 이용료 설정에는 변경 이력을 남겼습니다.

힘들었던 점

규칙이 정해지기 전에 구조를 정해야 했습니다. 기획 단계에서 “등록 기한 14일 또는 21일”, “정산은 자동인지 수동인지”, “결제 취소는 협의 필요”처럼 확정되지 않은 규칙이 여럿이었습니다. 숫자를 기다리면 개발이 멈추기 때문에, 기한·비율·방식을 전부 설정값과 상태값으로 빼 두고 화면과 계산 로직은 먼저 만들었습니다. 규칙이 확정된 뒤 바뀐 것은 값이었지 구조가 아니었습니다.

네 사용자가 같은 데이터를 다른 눈으로 봅니다. 예약 한 건을 골퍼는 “내 예약”으로, 매장은 “오늘 타석 현황”으로, 프로는 “레슨 요청”으로, 본사는 “정산 대상”으로 봅니다. 화면을 사용자별로 따로 만들되 데이터는 하나여야 해서, 앱·파트너센터·관리자가 같은 API 계층 위에 얹히도록 설계했습니다.

앱 둘, 웹 둘, 서버 하나를 여섯 달에 맞춰야 했습니다. 네이티브 앱 2종과 웹 2종을 한 팀이 같이 만들다 보니, 한쪽이 바뀌면 나머지도 따라가야 했습니다. 서버를 먼저 세우고 API 명세를 기준점으로 삼아 각 화면을 병렬로 진행했습니다.

그 뒤

2023년 1월 계획에서 출발해 7월에 1차 산출물(앱·웹 소스, 서버, DB, API 명세)을 냈고, 11월에 납품을 마쳤습니다. 납품 시점의 테이블 명세는 7월 42개에서 50개로 늘었습니다. 배너·푸시 로그·타석기 종류·매장 게시판·레슨 설정 이력처럼 운영을 준비하며 필요해진 것들이 그 사이에 붙었습니다.

이런 곳에 맞습니다

• 이용자·제공자·매장·본사처럼 사용자가 넷 이상인 플랫폼
• 회수권·기간권·레슨권처럼 횟수와 기간으로 소진되는 상품을 예약·정산과 묶어야 하는 서비스
• 지점이 여럿이고 지점마다 운영 방식이 다른 예약 서비스
• 앱과 웹, 서버와 인프라까지 한 팀에 맡겨 일정을 맞춰야 하는 프로젝트