RENTALFLOW

제안

사전질문 세 가지에 대한 답과 예산 내 구현 범위를 정리했습니다.

5-1

난이도가 높은 부분

사전질문 1번에 대한 답입니다.

1. 기간 겹침 판정과 점유 기간 구성

가장 어렵습니다. 고객이 3일을 빌려도 실제로는 배송 준비, 배송, 회수, 세탁까지 7일이 묶입니다. 이 기간을 정확히 계산하지 않으면 현장에서 옷이 없는 상황이 생깁니다. 여기에 자산이 여러 개인 상품에서 어느 자산을 언제 배정할지, 세탁 업체마다 소요가 다른 것을 어떻게 반영할지가 붙습니다.

예약 가능 판정 화면에서 날짜를 바꿔 보시면 이 계산이 어떻게 이루어지는지 확인하실 수 있습니다.
2. 결제 수단 4종의 확정 시점과 재고 확보

카드는 승인 시, 계좌이체는 입금 확인 시, 현장결제는 배송 담당자가 받을 때, 쿠폰은 차감 시입니다. 그런데 재고는 결제 전에 잡아둬야 하고, 수단마다 잡아두는 시간이 달라야 합니다. 특히 현장결제가 어렵습니다. 배송이 나가기 전까지는 돈을 받지 못하는데 재고는 그 전에 확정해야 합니다. 수금 실패를 어떻게 처리할지 정해야 합니다.

3. 훼손 시 향후 예약 처리

옷 한 벌이 망가지면 그것을 쓰기로 한 예약이 전부 걸립니다. 대체 상품을 찾아야 하는데 무엇을 기준으로 비슷하다고 볼지가 정해져 있지 않습니다.

4. 업무 규칙이 문서로 없는 상태

기술적인 난이도는 아니지만 일정에 가장 큰 영향을 줍니다. 규칙을 정하면서 만들어야 하므로 설계 단계가 길어집니다. 이번 과업에 규칙 정의가 포함된다고 하신 것이 맞다고 봅니다.

5-2

예상 기간과 견적

전체 요구사항
약 320 M/D
3명 기준 약 107영업일 (150일)
제시하신 90일
약 195 M/D
가능한 범위
제안드리는 구성
기간
120일
금액
4,000만원
부가세 별도
범위
아래 5-3
90일에 맞추려면 관리자 기능을 크게 줄여야 하는데, 실제 운영자가 매일 쓰는 시스템을 원하신다고 하셔서 권하지 않습니다.
PG 가맹 심사 2~4주, 알림톡 템플릿 승인 1~2주는 개발 공수와 무관하게 흐르는 일정입니다. 착수와 동시에 신청 절차를 시작하시기를 권하며, 필요한 자료를 정리해 드리겠습니다.
5-3

예산 내 구현 범위

사전질문 2번에 대한 답입니다. 전체 320 M/D 중 약 280 M/D를 이번 범위로 봅니다.

예약과 재고
  • ·기간 겹침 판정과 점유 기간 계산 (배송·회수·세탁 포함)
  • ·자산 단위 관리와 배정
  • ·결제 수단별 재고 임시 확보와 자동 반환
  • ·동시 예약 처리
  • ·날짜별 재고 현황
고객 웹
  • ·배송 지역 확인, 상품 탐색, 상세와 기간 선택
  • ·예약 작성 (복수 착용자, 배송 슬롯, 배송지·회수지)
  • ·한 사람 한 벌 제한 (데이터 단계)
  • ·결제 4종
  • ·예약 내역, 회수 장소 변경, 교환·취소 신청
  • ·이전 예약 그대로 다시
  • ·쿠폰, 문의
라이더 웹
  • ·오늘 배송·회수 목록과 상태 변경
  • ·완료 사진 첨부
  • ·현장 수금과 당일 집계
관리자
  • ·주문 목록·상세·수동 생성, 취소·환불
  • ·상품·LOOK·자산 관리와 상태 이력
  • ·엑셀 일괄 등록 도구
  • ·배송·회수 목록, 지역·슬롯·수용량 설정
  • ·반납 검수, 세탁 업체별 관리
  • ·훼손 시 향후 예약 표시와 대체 상품 검색
  • ·교환 승인, 고객·직원 관리, 권한, 처리 이력
  • ·정산 (라이더 수금 포함)
  • ·쿠폰 관리, 운영 설정, 기본 통계
공통
  • ·알림 8시점 발송 (알림톡 우선, 실패 시 문자)
  • ·개인정보 암호화와 접근 로그
  • ·PG·주소 검색 연동
이번에 빼는 것을 제안드리는 것
업무 담당 배정 자동화

미확정이라고 하셨습니다. 수동 배정만 넣고 규칙이 정해진 뒤에 붙이시는 편이 낫습니다. 규칙이 정해지지 않은 상태로 만들면 다시 만들게 됩니다.

관리자 화면 모바일 대응

미확정이라고 하셨습니다. PC 기준으로 만들고 필요한 화면만 나중에 모바일 대응하는 방식을 권합니다.

통계 고도화

기본 통계만 넣습니다. 어떤 지표가 필요한지는 운영해보셔야 압니다.

운영 매뉴얼 제작

관리자 화면에 설명을 붙이는 것까지는 포함하고, 별도 문서가 필요하시면 약 10 M/D, 150만원으로 봅니다.

비용 내 요구 사항이 모두 충족되기 힘들면 일부를 제외하는 방향으로 협의 가능하다고 하셨습니다. 위 네 가지가 저희가 보는 우선순위 낮은 항목입니다. 미팅에서 함께 정하면 좋겠습니다.
5-4

유사 시스템 개발 사례

사전질문 3번에 대한 답입니다.

의류 렌탈 서비스를 납품한 실적은 없습니다. 먼저 밝힙니다.
기간 겹침 예약

연습실 예약 시스템 구축 제안에서 시간 슬롯 단위 예약과 동시 예약 충돌 방지를 구현했습니다. 같은 슬롯에 두 건이 들어가지 않도록 저장 단계에서 제약을 두는 방식입니다. 시간 단위와 날짜 단위의 차이는 있으나 겹침 판정 구조는 같습니다.

재고와 자산 관리

컨테이너 창고 운영 시스템에서 개별 자산에 고유번호를 두고 위치와 상태 이력을 관리하는 구조를 구현했습니다. 기계 부품 관리 시스템에서는 품목별 재고와 입출고 이력을 다뤘습니다.

다지점 운영과 마스터 관리

QR 선불주문 플랫폼에서 본사 마스터를 한 곳에서 관리하고 각 매장이 참조하는 구조를 구현했습니다. 4명 20주, 계획 대비 실적 100%로 완료 후 다년간 유지보수했습니다.

결제 수단별 처리와 정산

커머스 플랫폼에서 다중 PG를 연동하고 판매자별 수수료와 정산을 계층으로 처리합니다. 확정 시점의 요율과 기준을 보존해 이후 정책이 바뀌어도 과거 확정분이 재계산되지 않게 설계했습니다. QR 주문에서는 결제와 주문 원장의 정합성을 트랜잭션 기반으로 보장하고 거래 고유키 제약으로 중복을 데이터베이스 수준에서 차단했습니다.

현장 수금과 정산

라이더 정산 시스템 구축 제안에서 현장 수금 집계와 본사 정산을 연결하는 구조를 구현했습니다.

운영자가 매일 쓰는 관리자 시스템

호텔 관리 시스템을 2016년에 구축해 약 10년간 직접 운영·유지보수하고 있습니다. 등급별 권한과 조회 범위 제한, 변경 이력 전수 기록을 갖췄습니다. POS 3종을 개발해 다수 매장에 납품하고 운영 중입니다.

렌탈 도메인은 처음이지만 예약·재고·자산·정산은 저희가 반복해온 일입니다. 이번 데모도 그 경험으로 만들었습니다.
5-5

정해야 할 것

항목왜 정해야 하나저희 제안
세탁 기간재고에서 빼지 않으면 세탁 중인 옷이 예약됩니다업체별로 설정. 실제 소요를 확인해 기본값 설정
배송 준비 기간전날 준비하면 그만큼 점유가 늘어납니다0일 또는 1일. 운영 방식에 따라
자산 배정 시점예약 시 정할지 배송 준비 시 정할지예약 시 가배정, 배송 준비 시 확정
결제 수단별 재고 확보 시간같은 시간이면 계좌이체 고객이 매번 놓칩니다카드 10분, 계좌이체 24시간, 설정으로 조정
현장결제 확정 시점배송 전까지 돈을 못 받는데 재고는 잡아야 합니다예약 접수 시 확정, 수금 실패는 사후 처리
대체 상품 기준사이즈·스타일·색상 중 무엇을 맞출지동일 상품·동일 사이즈만 자동 후보, 그 외는 담당자 확인
렌탈 기간 상한미확정이라고 하셨습니다상한을 두시는 편이 재고 회전에 낫습니다
기간별 요금 정책미확정이라고 하셨습니다일수별 할인이 있다면 계산 규칙 확정 필요
쿠폰 회차권 정책미확정이라고 하셨습니다회차 차감 시점, 취소 시 복원 여부
업무 담당 배정미확정이라고 하셨습니다이번엔 수동 배정, 규칙 확정 후 자동화
알림 채널권장안을 달라고 하셨습니다알림톡 우선, 실패 시 문자. 웹 알림은 보조
관리자 모바일 대응미확정이라고 하셨습니다PC 기준, 필요 화면만 추후 대응
한 사람 한 벌 제한의 범위기간이 겹치는 경우만인지, 같은 날이면 무조건인지기간 겹침 기준. 화면이 아닌 저장 단계에서
5-6

확인이 필요한 사항

  • ·세탁이 실제로 며칠 걸리는지 확인해야 합니다. 업체마다 다르면 업체별로 설정합니다. 이 숫자가 재고 판정에 직접 들어갑니다.
  • ·보유하신 의류 자산 수량을 알려주시면 규모를 산정할 수 있습니다. 오랜 기간 누적되어 수량이 많다고 하셨습니다.
  • ·같은 상품에 자산이 몇 벌씩 있는지 확인이 필요합니다. 대부분 한 벌뿐이면 대체 상품 찾기가 더 중요해집니다.
  • ·배송 가능 지역과 슬롯 운영 방식을 알려주세요. 라이더 한 명이 하루에 몇 건을 처리하는지도 필요합니다.
  • ·현장결제 비중이 어느 정도인지 확인하고 싶습니다. 비중이 높으면 수금 실패 처리를 더 꼼꼼히 만들어야 합니다.
  • ·메신저 상담 주문이 전체의 몇 퍼센트인지 알려주세요. 비중이 높으면 수동 생성 화면을 더 편하게 만들어야 합니다.
  • ·교환 정책을 확인해야 합니다. 어떤 경우에 교환이 가능하고 추가 비용이 있는지에 따라 처리가 달라집니다.
  • ·PG사 선정은 제안을 받아 정하신다고 하셨습니다. 가맹 심사 기간과 수수료를 기준으로 몇 곳을 정리해 드리겠습니다.
5-7

투입 인력과 계약 사항

투입 인력
대표 (28년)아키텍처, 예약·재고 판정 로직, 결제·정산
팀장화면 설계, 프런트엔드, 발주사 소통
사원관리자 화면, 문서
인원이 적은 대신 각자가 기획부터 개발까지 하는 방식입니다. 외부 재하청이 없어 중간에 전달되며 의도가 달라지는 일이 없습니다. 업무 프로세스 정의 단계부터 참여합니다.
운영비 (개발비 별도)
서버·클라우드월 15만원 내외
도메인·SSL연 5만원 내외
PG 수수료PG사 정책에 따름
알림톡 발송료건당 8~10원 내외

계정은 발주사 명의로 만듭니다.

유지보수
무상 하자보수 · 오픈 후 3개월

저희 구현 오류로 확인된 결함은 횟수 제한 없이 수정합니다. 예약이 안 되거나 재고가 틀리는 문제는 영업일 24시간 이내 착수합니다.

월 유지보수 · 월 50만원

장애 대응, 소규모 수정, 정기 점검, 백업 확인을 포함하며 연간 기준으로 구축비의 15% 수준입니다.

인수인계와 소유권
  • ·소스코드, 디자인 원본, 서버·DB 계정 소유권은 발주사에 귀속됩니다.
  • ·착수 시점부터 발주사 명의 저장소에서 작업합니다. 완료 후 넘기는 것이 아니라 처음부터 발주사가 통제합니다.
  • ·유지보수 업체를 바꾸실 수 있습니다. 그것을 전제로 코드 구조와 문서를 만듭니다.
  • ·특별한 기술을 쓰지 않습니다. 국내에서 흔히 쓰이는 조합만 씁니다.
  • ·인수인계는 문서 전달이 아니라 함께 해보는 방식으로 진행합니다. 실제로 주문을 넣고 검수하고 정산해보시는 시간을 갖습니다.
5-8

기술 스택

화면
Next.js + TypeScript

고객·라이더는 모바일, 관리자는 PC로 쓰시므로 한 코드로 화면 폭에 맞춰 다르게 보여줍니다. 앱을 만들지 않는다고 하셨으니 웹으로 충분합니다.

서버
Node.js
데이터베이스
PostgreSQL

기간 겹침 판정에 날짜 범위 조회가 많습니다. 기간 데이터를 다루는 기능이 잘 갖춰져 있어 겹침 판정을 데이터베이스 수준에서 처리할 수 있습니다. 재고 정합성을 애플리케이션에서만 판단하면 동시 요청에서 뚫립니다.

인프라
클라우드 기본 구성

대규모 트래픽 대응은 요구하지 않는다고 하셨으므로 가볍게 시작하고 필요하면 올립니다.

보안
  • ·연락처·주소·결제 정보 암호화 저장
  • ·관리자 접근 로그 기록
  • ·카드 정보는 저장하지 않고 PG가 보관
  • ·외부 서비스 인증 정보는 환경변수로 분리
특별한 기술을 쓰지 않습니다. 유지보수 업체를 바꾸실 수 있어야 한다고 하셨으므로 국내에서 다룰 수 있는 개발자를 구하기 쉬운 조합만 씁니다.