제안
사전질문 세 가지에 대한 답과 예산 내 구현 범위를 정리했습니다.
난이도가 높은 부분
사전질문 1번에 대한 답입니다.
가장 어렵습니다. 고객이 3일을 빌려도 실제로는 배송 준비, 배송, 회수, 세탁까지 7일이 묶입니다. 이 기간을 정확히 계산하지 않으면 현장에서 옷이 없는 상황이 생깁니다. 여기에 자산이 여러 개인 상품에서 어느 자산을 언제 배정할지, 세탁 업체마다 소요가 다른 것을 어떻게 반영할지가 붙습니다.
카드는 승인 시, 계좌이체는 입금 확인 시, 현장결제는 배송 담당자가 받을 때, 쿠폰은 차감 시입니다. 그런데 재고는 결제 전에 잡아둬야 하고, 수단마다 잡아두는 시간이 달라야 합니다. 특히 현장결제가 어렵습니다. 배송이 나가기 전까지는 돈을 받지 못하는데 재고는 그 전에 확정해야 합니다. 수금 실패를 어떻게 처리할지 정해야 합니다.
옷 한 벌이 망가지면 그것을 쓰기로 한 예약이 전부 걸립니다. 대체 상품을 찾아야 하는데 무엇을 기준으로 비슷하다고 볼지가 정해져 있지 않습니다.
기술적인 난이도는 아니지만 일정에 가장 큰 영향을 줍니다. 규칙을 정하면서 만들어야 하므로 설계 단계가 길어집니다. 이번 과업에 규칙 정의가 포함된다고 하신 것이 맞다고 봅니다.
예상 기간과 견적
예산 내 구현 범위
사전질문 2번에 대한 답입니다. 전체 320 M/D 중 약 280 M/D를 이번 범위로 봅니다.
- ·기간 겹침 판정과 점유 기간 계산 (배송·회수·세탁 포함)
- ·자산 단위 관리와 배정
- ·결제 수단별 재고 임시 확보와 자동 반환
- ·동시 예약 처리
- ·날짜별 재고 현황
- ·배송 지역 확인, 상품 탐색, 상세와 기간 선택
- ·예약 작성 (복수 착용자, 배송 슬롯, 배송지·회수지)
- ·한 사람 한 벌 제한 (데이터 단계)
- ·결제 4종
- ·예약 내역, 회수 장소 변경, 교환·취소 신청
- ·이전 예약 그대로 다시
- ·쿠폰, 문의
- ·오늘 배송·회수 목록과 상태 변경
- ·완료 사진 첨부
- ·현장 수금과 당일 집계
- ·주문 목록·상세·수동 생성, 취소·환불
- ·상품·LOOK·자산 관리와 상태 이력
- ·엑셀 일괄 등록 도구
- ·배송·회수 목록, 지역·슬롯·수용량 설정
- ·반납 검수, 세탁 업체별 관리
- ·훼손 시 향후 예약 표시와 대체 상품 검색
- ·교환 승인, 고객·직원 관리, 권한, 처리 이력
- ·정산 (라이더 수금 포함)
- ·쿠폰 관리, 운영 설정, 기본 통계
- ·알림 8시점 발송 (알림톡 우선, 실패 시 문자)
- ·개인정보 암호화와 접근 로그
- ·PG·주소 검색 연동
미확정이라고 하셨습니다. 수동 배정만 넣고 규칙이 정해진 뒤에 붙이시는 편이 낫습니다. 규칙이 정해지지 않은 상태로 만들면 다시 만들게 됩니다.
미확정이라고 하셨습니다. PC 기준으로 만들고 필요한 화면만 나중에 모바일 대응하는 방식을 권합니다.
기본 통계만 넣습니다. 어떤 지표가 필요한지는 운영해보셔야 압니다.
관리자 화면에 설명을 붙이는 것까지는 포함하고, 별도 문서가 필요하시면 약 10 M/D, 150만원으로 봅니다.
유사 시스템 개발 사례
사전질문 3번에 대한 답입니다.
연습실 예약 시스템 구축 제안에서 시간 슬롯 단위 예약과 동시 예약 충돌 방지를 구현했습니다. 같은 슬롯에 두 건이 들어가지 않도록 저장 단계에서 제약을 두는 방식입니다. 시간 단위와 날짜 단위의 차이는 있으나 겹침 판정 구조는 같습니다.
컨테이너 창고 운영 시스템에서 개별 자산에 고유번호를 두고 위치와 상태 이력을 관리하는 구조를 구현했습니다. 기계 부품 관리 시스템에서는 품목별 재고와 입출고 이력을 다뤘습니다.
QR 선불주문 플랫폼에서 본사 마스터를 한 곳에서 관리하고 각 매장이 참조하는 구조를 구현했습니다. 4명 20주, 계획 대비 실적 100%로 완료 후 다년간 유지보수했습니다.
커머스 플랫폼에서 다중 PG를 연동하고 판매자별 수수료와 정산을 계층으로 처리합니다. 확정 시점의 요율과 기준을 보존해 이후 정책이 바뀌어도 과거 확정분이 재계산되지 않게 설계했습니다. QR 주문에서는 결제와 주문 원장의 정합성을 트랜잭션 기반으로 보장하고 거래 고유키 제약으로 중복을 데이터베이스 수준에서 차단했습니다.
라이더 정산 시스템 구축 제안에서 현장 수금 집계와 본사 정산을 연결하는 구조를 구현했습니다.
호텔 관리 시스템을 2016년에 구축해 약 10년간 직접 운영·유지보수하고 있습니다. 등급별 권한과 조회 범위 제한, 변경 이력 전수 기록을 갖췄습니다. POS 3종을 개발해 다수 매장에 납품하고 운영 중입니다.
정해야 할 것
| 항목 | 왜 정해야 하나 | 저희 제안 |
|---|---|---|
| 세탁 기간 | 재고에서 빼지 않으면 세탁 중인 옷이 예약됩니다 | 업체별로 설정. 실제 소요를 확인해 기본값 설정 |
| 배송 준비 기간 | 전날 준비하면 그만큼 점유가 늘어납니다 | 0일 또는 1일. 운영 방식에 따라 |
| 자산 배정 시점 | 예약 시 정할지 배송 준비 시 정할지 | 예약 시 가배정, 배송 준비 시 확정 |
| 결제 수단별 재고 확보 시간 | 같은 시간이면 계좌이체 고객이 매번 놓칩니다 | 카드 10분, 계좌이체 24시간, 설정으로 조정 |
| 현장결제 확정 시점 | 배송 전까지 돈을 못 받는데 재고는 잡아야 합니다 | 예약 접수 시 확정, 수금 실패는 사후 처리 |
| 대체 상품 기준 | 사이즈·스타일·색상 중 무엇을 맞출지 | 동일 상품·동일 사이즈만 자동 후보, 그 외는 담당자 확인 |
| 렌탈 기간 상한 | 미확정이라고 하셨습니다 | 상한을 두시는 편이 재고 회전에 낫습니다 |
| 기간별 요금 정책 | 미확정이라고 하셨습니다 | 일수별 할인이 있다면 계산 규칙 확정 필요 |
| 쿠폰 회차권 정책 | 미확정이라고 하셨습니다 | 회차 차감 시점, 취소 시 복원 여부 |
| 업무 담당 배정 | 미확정이라고 하셨습니다 | 이번엔 수동 배정, 규칙 확정 후 자동화 |
| 알림 채널 | 권장안을 달라고 하셨습니다 | 알림톡 우선, 실패 시 문자. 웹 알림은 보조 |
| 관리자 모바일 대응 | 미확정이라고 하셨습니다 | PC 기준, 필요 화면만 추후 대응 |
| 한 사람 한 벌 제한의 범위 | 기간이 겹치는 경우만인지, 같은 날이면 무조건인지 | 기간 겹침 기준. 화면이 아닌 저장 단계에서 |
확인이 필요한 사항
- ·세탁이 실제로 며칠 걸리는지 확인해야 합니다. 업체마다 다르면 업체별로 설정합니다. 이 숫자가 재고 판정에 직접 들어갑니다.
- ·보유하신 의류 자산 수량을 알려주시면 규모를 산정할 수 있습니다. 오랜 기간 누적되어 수량이 많다고 하셨습니다.
- ·같은 상품에 자산이 몇 벌씩 있는지 확인이 필요합니다. 대부분 한 벌뿐이면 대체 상품 찾기가 더 중요해집니다.
- ·배송 가능 지역과 슬롯 운영 방식을 알려주세요. 라이더 한 명이 하루에 몇 건을 처리하는지도 필요합니다.
- ·현장결제 비중이 어느 정도인지 확인하고 싶습니다. 비중이 높으면 수금 실패 처리를 더 꼼꼼히 만들어야 합니다.
- ·메신저 상담 주문이 전체의 몇 퍼센트인지 알려주세요. 비중이 높으면 수동 생성 화면을 더 편하게 만들어야 합니다.
- ·교환 정책을 확인해야 합니다. 어떤 경우에 교환이 가능하고 추가 비용이 있는지에 따라 처리가 달라집니다.
- ·PG사 선정은 제안을 받아 정하신다고 하셨습니다. 가맹 심사 기간과 수수료를 기준으로 몇 곳을 정리해 드리겠습니다.
투입 인력과 계약 사항
계정은 발주사 명의로 만듭니다.
저희 구현 오류로 확인된 결함은 횟수 제한 없이 수정합니다. 예약이 안 되거나 재고가 틀리는 문제는 영업일 24시간 이내 착수합니다.
장애 대응, 소규모 수정, 정기 점검, 백업 확인을 포함하며 연간 기준으로 구축비의 15% 수준입니다.
- ·소스코드, 디자인 원본, 서버·DB 계정 소유권은 발주사에 귀속됩니다.
- ·착수 시점부터 발주사 명의 저장소에서 작업합니다. 완료 후 넘기는 것이 아니라 처음부터 발주사가 통제합니다.
- ·유지보수 업체를 바꾸실 수 있습니다. 그것을 전제로 코드 구조와 문서를 만듭니다.
- ·특별한 기술을 쓰지 않습니다. 국내에서 흔히 쓰이는 조합만 씁니다.
- ·인수인계는 문서 전달이 아니라 함께 해보는 방식으로 진행합니다. 실제로 주문을 넣고 검수하고 정산해보시는 시간을 갖습니다.
기술 스택
고객·라이더는 모바일, 관리자는 PC로 쓰시므로 한 코드로 화면 폭에 맞춰 다르게 보여줍니다. 앱을 만들지 않는다고 하셨으니 웹으로 충분합니다.
기간 겹침 판정에 날짜 범위 조회가 많습니다. 기간 데이터를 다루는 기능이 잘 갖춰져 있어 겹침 판정을 데이터베이스 수준에서 처리할 수 있습니다. 재고 정합성을 애플리케이션에서만 판단하면 동시 요청에서 뚫립니다.
대규모 트래픽 대응은 요구하지 않는다고 하셨으므로 가볍게 시작하고 필요하면 올립니다.
- ·연락처·주소·결제 정보 암호화 저장
- ·관리자 접근 로그 기록
- ·카드 정보는 저장하지 않고 PG가 보관
- ·외부 서비스 인증 정보는 환경변수로 분리