제안서에서 약속한 3대 역제안(하이브리드 동기화 · 고객사별 데이터 금고 · 디자인 무손실 전환)이 실제로 어떤 화면과 기능이 되는지 정의한 설계도입니다.
3PL 운영팀에 전화·엑셀로 묻던 모든 질문을 고객사가 직접 화면에서 해결합니다. 역제안 ①(하이브리드 동기화)이 만들어내는 체감 가치가 이 여정 전체에 깔립니다.
운영사가 보낸 초대 메일로
담당자 계정 생성
출고 대기·배송중·재고 경고를
대시보드 한 장으로
주문번호로 송장까지
단계별 추적
안전재고 미만 SKU를
모바일 푸시로 통보
포털에서 바로 요청,
운영사에 즉시 전달
| 주문번호 | 화주 | 품목 | 송장번호 | 상태 |
|---|---|---|---|---|
| PKY-2026-0819-00473 | (주)비컴리빙 | 3 | CJ 5729 1183 4402 | 배송중 |
| PKY-2026-0819-00471 | (주)비컴리빙 | 1 | CJ 5729 1183 4398 | 출고완료 |
| PKY-2026-0819-00468 | (주)비컴리빙 | 7 | - | 피킹중 |
| PKY-2026-0818-00455 | (주)비컴리빙 | 2 | CJ 5729 1180 7712 | 배송완료 |
| PKY-2026-0818-00449 | (주)비컴리빙 | 5 | - | 재고부족 보류 |
고객사 담당자가 로그인 직후 보는 첫 화면입니다. 출고 대기, 배송 중, 안전재고 미만, 반품 접수 4개 지표와 최근 주문 목록을 한 화면에 담아, 전화로 묻던 질문이 화면에서 끝나게 만듭니다.
화면은 Packiyo를 직접 호출하지 않고 캐시에서 즉시 응답합니다. Packiyo 웹훅으로 주문·재고 변경을 먼저 받아 캐시에 반영하고, 상단에 '동기화 4초 전'을 표기해 데이터 신선도를 사용자에게 명시합니다. 제안서 역제안 ①의 직접적인 결과 화면이며, 데모 Step 3에서 실제로 작동하는 모습을 보실 수 있습니다.
왼쪽에 주문·수취인·품목, 오른쪽에 집화부터 배송완료까지의 타임라인을 배치했습니다. '내 주문 어디 있어요?'라는 문의를 화면 하나로 대체하는 것이 목적입니다.
Packiyo의 원본 상태(shipped)와 택배사 추적 정보를 하나의 타임라인으로 합쳐 보여줍니다. 현재 단계는 키컬러로 강조하고 이후 단계는 회색으로 남겨 진행률이 즉시 읽히게 했습니다. 배송 완료 시점에 담당자 알림이 자동 발송됩니다.
재고 경고는 책상 앞이 아니라 이동 중에 확인됩니다. 조회 전용 기능만 모바일로 분리해 개발 범위를 늘리지 않으면서 실사용 가치를 확보했습니다.
재고 변경 웹훅을 받을 때마다 SKU별 안전재고 대비 비율을 계산하고, 설정한 임계치(기본 30%) 미만이면 푸시와 이메일을 발송합니다. 화면에서 바로 보충 요청서를 만들어 운영사에 전달할 수 있습니다.
단순 조회 문의가 포털로 넘어간 뒤, 운영자는 동기화 예외와 반품 같은 진짜 판단이 필요한 일에 집중합니다.
웹훅 수신과 보정 결과를
한눈에 확인
누락·재시도 건만
선별해 처리
재입고·재포장·폐기를
화면에서 확정
화주사와 담당자를
조직 단위로 등록
월간 물류 리포트를
고객사에 자동 발송
| 09:41:22 | webhook | order.shipped | PKY-2026-0819-00473 | 반영 |
| 09:41:05 | webhook | inventory.updated | SKU-BT-1024-BLK | 반영 |
| 09:40:58 | webhook | order.created | PKY-2026-0819-00474 | 반영 |
| 09:40:31 | polling | orders.reconcile | 누락 2건 보정 | 복구 |
| 09:39:47 | webhook | return.received | RMA-2026-0812 | 반영 |
| 09:38:12 | webhook | order.updated | PKY-2026-0818-00449 | 재시도 1회 |
운영자가 매일 아침 여는 화면입니다. 웹훅 수신 로그, API 호출 절감률, 캐시 히트율, 최대 동기화 지연을 한 화면에 모아 시스템이 정상인지 5초 안에 판단하게 합니다.
웹훅으로 받은 이벤트는 즉시 캐시에 반영하고, 웹훅이 누락된 구간은 5분 주기 폴링 잡이 비교·보정합니다. 로그에는 webhook과 polling을 구분 표기해 어떤 경로로 데이터가 들어왔는지 추적 가능합니다. 제안서 역제안 ①의 심장부이며, 데모 Step 2에서 이 과정이 그대로 재현됩니다.
왼쪽 반품 대기 목록에서 건을 선택하면 오른쪽에 원주문·품목·검수 선택지가 펼쳐집니다. 반품은 판단이 필요한 업무이므로 조회가 아닌 처리 중심으로 레이아웃을 구성했습니다.
검수 결과(재입고 / 재포장 / 폐기)를 확정하면 Packiyo Returns API로 즉시 반영되고, 재입고인 경우 재고 수량이 화주 포털에 자동으로 반영됩니다. 처리 이력은 감사 로그에 남아 분쟁 시 근거가 됩니다.
| 이름 | 계정 | 소속 화주 | 권한 | 상태 |
|---|---|---|---|---|
| 김수연 | sy.kim@becomeliving.co.kr | (주)비컴리빙 | 관리자 | 활성 |
| 박도현 | dh.park@becomeliving.co.kr | (주)비컴리빙 | 조회 전용 | 활성 |
| 이하늘 | hn.lee@graceview.kr | 그레이스뷰티 | 관리자 | 초대 발송 |
| 정민재 | mj.jung@nordsports.kr | 노드스포츠 | 조회 전용 | 활성 |
화주사를 조직 단위로 등록하고, 그 아래 담당자를 초대합니다. 권한 매트릭스에서 '타 화주 데이터' 항목 자체가 존재하지 않는다는 점을 시각적으로 보여주는 것이 이 화면의 핵심 메시지입니다.
모든 계정은 화주 코드에 종속됩니다. 관리자 권한이라 해도 소속 화주 범위를 벗어난 데이터는 조회 대상 자체가 되지 않으며, 이 규칙은 화면 로직이 아니라 데이터베이스 정책으로 강제됩니다. 제안서 역제안 ②를 사용자 화면 관점에서 증명하는 슬라이드입니다.
격리·한도·배포. 이 포털이 고객사에게 보여지는 영업 자산인 만큼, 사고 이후가 아니라 사고 이전에 확인하는 화면들로 구성했습니다.
화주 간 데이터 차단이
유효한지 정기 검증
Packiyo API 사용률과
응답 지연 추적
한도 임박 시 캐시·폴링
주기 자동 조정
테스트 통과 후에만
운영 배포 진행
장애 대응 절차를
문서로 인수인계
| TC-01 | 화주 A 계정으로 화주 B 주문 직접 조회 | BLOCKED |
| TC-07 | URL 주문번호 변조 (PKY→타사 주문) | BLOCKED |
| TC-12 | API 토큰 재사용 후 tenant_id 위조 | BLOCKED |
| TC-18 | 조회 조건 누락 쿼리 강제 실행 | BLOCKED |
| TC-23 | 관리자 권한 계정의 타사 재고 접근 | BLOCKED |
24개 격리 테스트 케이스의 실행 결과를 상시 노출합니다. '막았습니다'라는 말 대신 '이렇게 막혔습니다'를 숫자로 보여주는 화면입니다.
PostgreSQL Row Level Security 정책이 11개 테이블 전체에 적용되어 있으며, URL 변조·토큰 위조·조회 조건 누락 등 실제 공격 시나리오를 자동 테스트로 매일 재검증합니다. 코드가 아닌 DB가 방어선이므로 개발자 실수와 무관하게 차단됩니다.
| Endpoint | 24h 호출 | p95 |
|---|---|---|
| GET /orders | 1,284 | 182ms |
| GET /inventory | 946 | 141ms |
| GET /shipments | 722 | 198ms |
| POST /returns | 88 | 312ms |
| GET /products | 402 | 127ms |
Packiyo 한도 대비 실제 사용률, 엔드포인트별 호출량과 p95 응답, 캐시 히트율 추이를 함께 보여줍니다. 캐시를 걷어냈을 때의 예상 사용률(228%)을 나란히 표기해 이 설계가 왜 필요한지 화면 자체가 설명합니다.
사용률 60% 또는 동기화 지연 30초를 넘으면 Sentry 알림과 함께 캐시 TTL을 늘리고 폴링 주기를 자동으로 완화해 한도 초과를 사전에 차단합니다. 화주가 늘어도 호출량은 화주 수가 아니라 변경 건수에 비례합니다.
격리 테스트 24건을 통과해야만 운영 배포가 진행되도록 파이프라인에 게이트를 걸었습니다. 오른쪽에는 환경 변수 명세와 키 로테이션 주기를 마스킹 상태로 노출합니다.
5백만원 규모 프로젝트의 진짜 리스크는 개발이 아니라 인수인계입니다. 장애 유형별 대응 절차를 명령어 단위 런북으로 만들어 전달하고, 롤백은 이전 이미지로 1분 내 복구되도록 구성합니다.