GRAB — 팀 피드백 (그룹 3)
GRAB의 목표는 한정 수량 판매에서 초과 판매와 중복 처리를 모두 0건으로 유지하는 것입니다. WISH 등록자가 판매 시작 안내를 받고 구매로 이어가는 과정, 주문·재고·결제 상태를 안전하게 처리하는 흐름이 함께 완성되어야 합니다.
flowchart TB
P[관심 상품을 놓치지 않고, 판매자는 제한 수량을 정확히 관리하고 싶다] --> V[WISH에서 판매 시작 알림을 받고 GRAB으로 이동]
V --> M[DROP 공개 · WISH 등록 · 알림 · 주문 · 결제 · 재고 처리]
M --> D[주문·결제·재고 상태 전이와 멱등 처리]
D --> E[동시 요청 · 중복 웹훅 · 실패·만료 복구 검증]
E --> Q[부하·오류 측정과 사용자 반응으로 다음 개선 결정]
Q --> M제안 서비스 구성
기획서에는 기술 스택과 인프라가 정해져 있지 않습니다. 아래는 리뷰에서 제안한 Spring Boot·PostgreSQL 초안입니다. 재고 차감은 DB 조건부 갱신을 예로 들었고, 락 방식과 클라우드 제공자는 부하 테스트 뒤 결정해야 합니다.
flowchart TB
U[구매자] -->|WISH · DROP 조회 · 주문| API[Spring Boot 4 제안<br/>Spring MVC · 주문 API]
SELLER[판매자] -->|DROP · 옵션 · 수량 관리| API
API --> DB[(PostgreSQL 제안<br/>DROP · WISH · 재고 · 주문 · 결제)]
API -->|주문 요청| STOCK[재고 처리 제안<br/>조건부 UPDATE · 남은 수량 확인]
STOCK -->|차감 성공 때만 주문 생성| ORDER[주문 상태 관리 제안<br/>멱등 키]
STOCK --> DB
ORDER --> DB
ORDER -->|결제 요청| PG[모의 PG 어댑터 제안]
PG -->|결과 웹훅| HOOK[웹훅 처리<br/>중복 요청 멱등 처리]
HOOK --> DB
SCHED[Spring Scheduler 제안<br/>대기 주문 만료] -->|조건부 갱신 · 재고 복구| DB
API -->|판매 시작 인앱 알림| NOTICE[알림 처리 제안]
NOTICE --> WISH[(WISH 구독 정보)]
API --> WISH
REDIS[(Redis 선택 제안<br/>캐시 · 멱등 키)] -.-> APIWISH는 관심 표시일 뿐 재고를 잡아두지 않습니다. 주문·결제·재고 상태는 PostgreSQL에서 일관되게 관리하고, 웹훅이나 만료 작업이 여러 번 실행돼도 상태가 한 번만 바뀌는지 확인해야 합니다. Redis는 필요할 때만 추가하면 됩니다.
설계에서 잘 된 점
- “초과 판매가 나지 않는다”, “중복 요청이 주문·결제·재고를 두 번 처리하지 않는다”는 성공 기준이 구체적입니다. 상태 전이와 테스트를 이 기준에 맞추면 설계 타당성을 결과로 제시할 수 있습니다.
- WISH는 관심 표시일 뿐 재고 예약이나 구매 우선권은 아니라고 분명히 했습니다. 이용자가 기대할 수 있는 보장 범위도 정확히 제시했습니다.
- 결제를 개발·시연용 테스트 환경으로 제한해 4주 MVP의 범위를 통제했습니다.
우선 수정할 사항
WISH 사용자 흐름과 화면에는 판매 시작 알림이 있지만, 제외 기능 표에는 알림을 빼는 것으로 적혀 있습니다. 인앱 알림을 MVP에 넣을지, 알림 없이 WISH가 어떤 가치를 주는지 다시 정할지 결정하고 기능 범위표·시나리오·화면 목록을 함께 고치세요. 현재 기획을 살리려면 인앱 알림을 P0에 포함해야 합니다.
그다음 옵션별 재고, DROP 상태, 주문과 결제 상태를 먼저 정하세요. 예를 들어 판매예정 → 판매중 → 종료, 주문생성 → 결제대기 → 결제완료/실패/만료 → 취소처럼 상태와 허용 전이를 표나 다이어그램으로 맞추면 API와 일정이 구체화됩니다. 결제 실패·시간 초과 때 재고를 언제 돌려주는지, 같은 웹훅이 여러 번 와도 결과가 한 번만 반영되는지까지 포함하세요.
4명이 4주 동안 결제 연동, 배송, 대시보드, 알림, 동시성 실험을 모두 운영 수준으로 끝내기는 어렵습니다. 주문·재고·웹훅의 중복 처리 검증에 시간을 먼저 배정하세요. PG는 모의 어댑터로, 배송은 최소 상태만, 대시보드는 기본 수치만 구현하면 범위를 줄일 수 있습니다. 판매 시작 알림과 WISH→구매 흐름은 이 서비스가 약속한 경험이므로 화면과 API까지 이어져야 합니다.
“한정 수량을 안전하게 판매한다”는 기능만으로는 다른 서비스와 구분하기 어렵습니다. 현재 기획과 맞는 차별점으로는 판매자가 WISH 대비 주문 전환과 옵션 선호를 살펴보는 운영 지표가 있습니다. WISH가 실제 수요나 생산량을 보장하지 않으므로, 예측치 대신 판매 판단에 참고할 관측값으로 보여주세요.
참고할 실제 서비스
- Nike SNKRS Korea — 발매 알림과 한정 제품 경험을 참고할 수 있습니다. 알림 신청, 발매 시점 상태 안내, 품절 후 화면을 GRAB 흐름과 비교하세요.
- 텀블벅 크리에이터 프로젝트 시작 안내 — 공개 전 알림 신청과 창작자 운영 흐름을 참고하세요. GRAB 한정판매와 펀딩의 목적·정책 차이를 기준으로 참고할 기능과 제외할 기능을 구분하세요.
후속 검토 요청 프롬프트
최신 기획서, 상태 전이도, ERD/API, 부하·동시성 테스트 결과를 첨부하고 아래 항목을 실제 수치와 결정으로 작성해 후속 리뷰를 요청하세요.
GRAB 팀입니다. 첨부한 현재 기획서와 구현·검증 자료를 읽고, 우리 DROP 판매 흐름에 맞는 후속 피드백을 주세요.
[이번 버전에서 확정·구현한 내용]
- WISH 가입자가 받는 판매 시작 알림 방식과 발송 시점:
- 4주 MVP에 포함한 기능 / 뒤로 미룬 기능:
- DROP·주문·결제 상태와 허용 전이:
- 재고 차감 및 결제 실패·취소·만료 때 복구 규칙:
- 동시성 제어 방식과 선택 근거:
- 중복 주문·웹훅을 막는 멱등 키와 적용 범위:
- 동시 요청 수 / 응답시간(p95) / 실패율 / 초과 판매 건수:
- 장애 주입으로 확인한 시나리오와 복구 결과:
- 판매자에게 보여주는 WISH 대비 주문·옵션 지표:
[리뷰 요청]
1. DROP·주문·결제·재고 상태 전이가 서로 모순 없이 연결되는지 첨부 문서와 테스트 결과로 확인해 주세요.
2. 같은 재고를 두고 동시에 주문하거나 결제 웹훅이 중복 도착해도 성공 기준을 지키는지 판단해 주세요.
3. 부하 결과를 기준으로 현재 선택한 동시성 처리 방식의 병목과 다음 측정 항목을 제시해 주세요.
4. WISH 등록자가 기대하는 알림과 실제 화면·발송 동작 사이에 빠진 단계가 있는지 찾아 주세요.
5. 남은 개선점 3개를 영향도 순으로 고르고, 각각 다음 행동과 통과를 입증할 숫자·테스트를 제안해 주세요. 자료에 없는 결과는 추정하지 말아 주세요.