업종별 기능 개발 제안 · 동작 데모 포함

체육시설 업종별
기능 개발 제안서

세 업종을 따로 만들면 세 벌이 됩니다. 묶을 것과 가를 것을 먼저 나누겠습니다

신영진 | 풀스택 개발 · 시스템 운영

업종별 화면을 먼저 만들어 봤습니다

이용권 구조와 예약 방식이 어떻게 다른지, 현장에서 무엇이 문제가 되는지를 기준으로 구성했습니다

헬스클럽

회원권과 락커를 한 화면에서 봅니다. 회원권은 끝났는데 락커에 짐이 남은 상황이 현장에서 가장 잦은 분쟁이라, 만료일을 따로 관리하되 함께 보이게 했습니다

스크린골프장

타석 8개 현황과 대기열. 노쇼 15분 경과 건을 표시해 비어 있는 타석에 대기 손님을 넣을 수 있게 했습니다. 노쇼 손실을 금액으로 보여줍니다

수영장과 공통 구조

레인 정원 관리와, 세 업종을 하나로 묶는 설계

수영장

레인별 정원과 강습반 현황. 자유수영은 입장 시 레인을 지정하지 않아 한쪽으로 몰리는 문제가 실제로 생깁니다. 초과 레인을 표시해 현장 직원이 안내할 수 있게 했습니다

공통 구조

락커·타석·레인은 이름만 다르고 배정·반납 구조는 같습니다. 이용권도 기간제·횟수제·시간제 세 가지로 모든 업종이 설명됩니다

왜 공통 구조부터 잡아야 하는가

가맹점 확대가 목표라면 이 부분이 전제라고 봅니다

1세 벌이 되는 것을 막습니다업종별로 따로 만들면 회원·이용권·입퇴장 코드가 세 벌이 됩니다. 나중에 공통 기능 하나를 고칠 때 세 군데를 고쳐야 하고, 한 곳을 빠뜨리면 업종별로 동작이 달라집니다

2네 번째 업종에 대비합니다필라테스·클라이밍·테니스가 추가될 때 코드를 새로 짜지 않고 설정만 추가하면 되는 구조로 둡니다. 가맹점 확대 계획이 있으시니 이 편이 맞습니다

3자원 배정은 하나입니다락커·타석·레인 모두 "정해진 자원을 회원에게 배정하고 기간이 끝나면 반납한다"는 같은 구조입니다. 정원 개념만 업종별로 다릅니다

4이용권도 세 가지뿐입니다기간제·횟수제·시간제 조합으로 모든 업종이 설명됩니다. 차감 시점과 규칙만 설정으로 갈라냅니다

공단에서 체육시설을 다뤄본 경험이 있습니다 — 성북구도시관리공단에서 체육시설 관련 업무를 담당했고, 온라인예약(ezPay)과 속초시시설관리공단 캠핑장 예약 서비스를 구축·운영했습니다. 정원이 정해진 자원을 시간대별로 예약받고 현장에서 확인하는 구조를 실제로 다뤄봤습니다. 현장에서 무엇이 문제가 되는지를 겪어본 것이 이번 과업에 도움이 될 것으로 봅니다.

업종별로 먼저 정해야 할 규칙

기능 목록에는 한 줄이지만, 규칙이 정해지지 않으면 개발 중에 멈춥니다

업종	확정이 필요한 규칙
헬스클럽	회원권과 락커의 관계 — 회원권이 끝나면 락커를 자동 회수할지, 락커만 연장 판매할지. 정지(홀딩) 기간에 락커는 어떻게 되는지. 현장 분쟁이 가장 많은 지점이라 먼저 정해야 합니다
스크린골프장	노쇼 판정 시간과 처리 — 몇 분 경과 시 노쇼로 볼지, 이용권을 차감할지 말지, 대기 호출은 자동인지 수동인지. 시간제 중간 이탈 시 차감 방식도 함께 정해야 정산이 어긋나지 않습니다
수영장	자유수영 레인 배정 방식 — 입장 시 레인을 지정할지, 현장에서 자율 이용하되 인원만 표시할지. 강습반과 자유수영이 같은 시간대에 겹칠 때 레인 용도를 어떻게 나눌지
공통	이용권 정지·환불·양도 규칙. 업종마다 다르면 설정으로 두고, 같으면 공통 처리합니다

1주차에 이 규칙들을 문서로 확정하는 것을 제안드립니다. 착수일이 10월 5일, 납품이 11월 15일로 약 6주입니다. 개발 도중에 규칙을 바꾸면 이미 만든 부분을 되돌려야 해서 일정이 무너집니다. 준비하신 업종별 운영 프로세스 자료를 받아 첫 주에 규칙표를 만들고 확정받은 뒤 개발에 들어가겠습니다.

기존 시스템 연동

App-Kiosk-ERP가 이미 돌고 있으므로, 새 기능이 기존 흐름의 어디에 끼어드는지가 관건입니다

11주차 — 흐름 파악기존 API 명세와 접근 권한을 받아, 회원이 앱으로 예약하고 키오스크로 입장할 때 어떤 순서로 데이터가 오가는지를 먼저 그립니다. 여기서 업종 기능이 들어갈 자리를 정합니다

2이중 차감을 막습니다앱과 키오스크가 같은 이용권을 각각 차감하면 회원이 손해를 봅니다. 차감은 한 곳에서만 일어나도록 하고, 같은 요청이 두 번 와도 한 번만 반영되게 처리합니다

3ERP 정산에 맞춥니다업종별 이용권이 늘어나면 ERP가 받는 매출 항목도 늘어납니다. 기존 정산 구조를 확인하고 그에 맞춰 데이터를 보내야 마감이 어긋나지 않습니다

4현장이 멈추지 않게키오스크는 네트워크가 끊겨도 입장을 막을 수 없습니다. 단말에서 먼저 처리하고 복구 후 전송하는 구조가 이미 있다면 그대로 따르고, 없다면 함께 검토드립니다

기존 구조를 바꾸지 않는 것을 원칙으로 합니다 — 이미 가맹점이 쓰고 있는 시스템이므로, 업종 기능을 붙이면서 기존 동작이 달라지면 현재 운영 중인 헬스클럽 가맹점이 먼저 피해를 봅니다. 새 기능은 추가하되 기존 흐름은 건드리지 않는 방향으로 설계하겠습니다.

일정과 검증

10월 5일 착수 · 11월 15일 납품 기준 · 약 6주

주차	작업	산출
1주	업종별 운영 프로세스 분석, 규칙표 확정, 기존 API 명세 파악, 공통 구조 설계	기능 정의서 · 규칙 확정본
2~3주	공통 모듈(회원·이용권·자원 배정) 개발, 헬스클럽 기능	헬스클럽 모듈
3~4주	스크린골프 기능(타석·시간제/횟수제·대기·노쇼)	골프 모듈
4~5주	수영장 기능(레인 정원·강습반·자유수영권), 기존 시스템 연동 마무리	수영장 모듈
5~6주	사업장 적용, 시나리오 테스트, 오류 수정, 결과 보고서	적용 결과 보고서

검증 사업장 접근이 일정을 좌우합니다 — 착수 후 7일 이내 제공해 주신다고 하셨는데, 이것이 늦어지면 마지막 2주가 통째로 밀립니다. 실사업장 적용은 현장 상황에 맞춰야 해서 미리 준비할 수 없기 때문입니다.

가능하다면 업종별로 하나씩 개발이 끝날 때마다 바로 적용해 보는 방식을 제안드립니다. 마지막에 세 업종을 한꺼번에 검증하면 문제가 동시에 나와 수정할 시간이 없습니다.

성공적인 마무리의 기준

기능이 동작하는 것과 가맹점이 쓸 수 있는 것은 다르다고 봅니다

1현장 직원이 혼자 쓰는 것세 업종 사업장에서 개발자 도움 없이 하루 운영이 돌아가는 것. 입장·예약·차감·마감까지

2기존 가맹점이 멀쩡한 것업종 기능을 붙인 뒤에도 현재 운영 중인 헬스클럽 가맹점의 동작이 달라지지 않는 것

3숫자가 맞는 것이용권 차감과 ERP 매출이 어긋나지 않는 것. 앱·키오스크 어느 쪽으로 들어와도 기록이 하나로 남는 것

4네 번째 업종이 가능한 것다음 업종을 추가할 때 코드가 아니라 설정으로 시작할 수 있는 상태. 가맹점 확대가 목표라면 이것이 실질적인 성과입니다

확인이 필요한 부분 — ① 기존 App·Kiosk·ERP의 개발 주체와 API 문서 수준 ② 현재 운영 중인 가맹점 수와 업종 ③ 검증 사업장이 실사업장인지 테스트 환경인지 ④ 이용권 정지·환불 규칙이 업종별로 다른지 ⑤ 키오스크 단말의 오프라인 처리 지원 여부

묶을 것과 가를 것을
먼저 나누겠습니다

세 업종을 따로 만들면 세 벌이 되고, 네 번째 업종에서 또 반복됩니다.
데모는 직접 눌러보실 수 있습니다.