거래 플랫폼은 왜 업종이 달라도 구조가 같은가 — 6층 모델

같은 질문을 반복해서 받는다

"농산물 플랫폼 만든 팀이 우리 예약 시스템을 할 수 있나요?"라는 질문을 자주 받습니다. 답을 하려다 보니, 업종이 다른 플랫폼들이 실제로 얼마나 겹치는지 정리하게 됐습니다.

결론부터 말하면 화면과 용어는 전부 다시 만들지만, 설계에서 결정해야 하는 항목은 거의 같습니다. 그 항목들을 여섯 층으로 나눠 봤습니다.

1층 — 참여자와 권한 경계

거래 플랫폼에는 최소 세 종류의 사람이 있습니다. 공급자, 수요자, 그리고 운영자. 여기에 중개·영업 역할이 붙기도 합니다.

핵심 질문은 하나입니다. "공급자는 자기 데이터만 본다"고 할 때, 그 "자기"의 경계가 어디인가. 지점이 여러 개면 지점장은 어디까지 보는가. 본사 직원 권한은 몇 단계로 나눌 것인가. 이 답이 DB 설계를 결정합니다.

2층 — 거래 원장과 상태 기계

주문·예약·발주·계약은 전부 "상태를 옮겨다니는 객체"입니다. 대기 → 확정 → 이행 → 완료, 그리고 어느 지점에서든 취소가 끼어듭니다.

결정할 것은 세 가지입니다. 상태를 몇 개로 쪼갤 것인가, 되돌릴 수 있는가, 부분 이행을 허용하는가. 특히 부분 이행(3개 중 1개만 배송, 예약 중 일부만 이용)을 허용하는 순간 뒤의 모든 계산이 복잡해집니다.

3층 — 정산: 남의 돈

가장 어렵고, 가장 늦게 발견되고, 되돌릴 수 없는 층입니다. 프로젝트가 실패할 때 대부분 여기서 무너집니다.

정산의 본질은 계산이 아니라 설명 가능성입니다. 공급자가 "이 금액이 왜 이렇게 나왔냐"고 물었을 때 근거를 대지 못하면, 그때부터 매달 엑셀로 수기 대조가 시작됩니다. 시스템이 있어도 아무도 안 믿게 됩니다.

• ▸수수료는 어느 금액에 붙는가 — 배송비 포함? 할인 전? 할인 후?
• ▸할인은 누가 부담하는가 — 플랫폼, 공급자, 프로모션 예산 중 어디서 나가는가
• ▸부분 취소 시 할인과 부대비용을 어떻게 나누는가
• ▸정산 후 환불이 발생하면 다음 달에서 차감하는가, 즉시 회수하는가
• ▸공급자 잔액이 마이너스가 되면 어떻게 하는가

4층 — 외부 연동과 장애 격리

결제·물류·세무·인증·알림은 전부 내 서버 밖에 있습니다. 그리고 남의 시스템은 반드시 느려지고 반드시 죽습니다.

설계의 본질은 "그때 우리 서비스 전체가 같이 멈추지 않게 만드는 것"입니다. 외부 API 하나가 응답하지 않을 때 요청이 쌓이면, 브라우저의 호스트당 연결 슬롯이 차면서 전혀 무관한 화면까지 함께 멈춥니다. 전역 타임아웃 상한과 트랜잭션 경계 분리가 필요한 이유입니다.

5층 — 현장 운영 도구

가장 흔한 실패는 고객 화면을 예쁘게 만들면서 운영자 화면을 대충 만드는 것입니다. 실제로 하루에 200번 눌리는 건 관리자 화면입니다.

여기가 부실하면 담당자는 결국 엑셀로 도망갑니다. 그러면 시스템에 데이터가 안 쌓이고, 통계가 틀리고, 정산이 어긋납니다. 웹 백오피스와 현장용 모바일 앱을 함께 설계해야 하는 이유입니다.

6층 — 증빙과 규제

세금계산서·현금영수증, 전자상거래법 고지, 개인정보 보관·파기, 정산 기한과 자금 별도관리. "나중에 붙이면 되지"가 통하지 않는 유일한 층입니다.

데이터를 처음부터 그 형태로 쌓아두지 않으면 소급이 불가능하기 때문입니다. 예를 들어 과세·면세가 섞인 주문에서 항목별 부가세를 분리해두지 않았다면, 나중에 전체를 다시 계산해야 합니다.

그래서 어떻게 쓰는가

새 프로젝트를 만나면 이 여섯 층에 대입해봅니다. 각 층에서 결정되지 않은 항목이 몇 개인지가 그 프로젝트의 진짜 난이도입니다.

기획서에 화면이 50개 있어도 3층과 6층이 비어 있으면 그건 아직 시작할 수 없는 프로젝트입니다. 반대로 화면이 20개뿐이어도 여섯 층이 다 채워져 있으면 일정이 예측 가능합니다.