오픈마켓 그룹·권한 구조 — 셀러·바이어·조직 모델링 개념

핵심 요약

B2B 마켓플레이스·멀티셀러 커머스는 처음부터 그룹 중심으로 모델링해야 해요. 일반 B2C에 조직 정책을 나중에 얹으려 하면 재설계 비용이 급증해요.
세 가지 기본 단위: ① 그룹(정책의 단위) · ② 사용자(실행의 단위) · ③ 한도(통제의 단위).
그룹에는 셀러 그룹(공급자 측)과 바이어 그룹(구매자 측) 두 유형이 있어요. 같은 상품이라도 그룹 간 계약 조건이 달라져요.
먼저 답해야 할 질문: 그룹 계층 구조 · 다중 그룹 소속 허용 · 권한 상속 · 한도 집계 기준. 초기 설계에 1~2주 투자하는 편이 나중에 3개월 이관하는 것보다 싸요.

이런 상황이라면

B2B SaaS 솔루션을 판매하는 플랫폼을 기획 중이에요. 지금은 법인 고객마다 담당자 1명이 개별 결제하는데, 규모가 커지면서 법인 안에서 여러 사용자가 각자 주문하고 월말 일괄 정산하는 구조가 필요해졌어요.
개발자분이 물어요.
"법인 단위로 그룹을 만들고 그 안에 사용자를 붙이는 구조가 맞는 것 같은데, 구체적으로 어떻게 설계할지 몇 가지 결정이 필요해요. 한 사용자가 여러 법인에 속할 수 있어요? 법인 안에 부서 계층이 있어요? 결제 한도는 사용자별인가요 법인 전체인가요?"
이 질문들에 대한 답이 기획서에 없어요. 일반 B2C 커머스와는 전혀 다른 고민이 필요해요.

이 글은 마켓플레이스·B2B 커머스에서 그룹·사용자·한도 3단위로 모델링하는 개념을 정리해요.

1B2B와 B2C는 구조가 근본적으로 달라요

항목	B2C 쇼핑몰	B2B 마켓플레이스
구매 주체	개인 고객	기업·조직·셀러 그룹
가격	고객 공통 또는 단순 등급	그룹별 계약 조건
승인 흐름	고객 본인 결정	내부 승인자 거쳐야 할 수 있음
한도	거의 없음	월별·회차별·사용자별 한도
정산	건별 처리	그룹 집계·월말 일괄
권한 분리	고객 1인이 전체	사용자별 역할 (관리자·구매자·조회만)
식별	이메일·전화	법인등록번호·사업자번호·조직 코드

일반 B2C 스키마에 조직 필드를 나중에 붙이려 하면 가격 테이블·주문 승인·정산 집계가 전부 재설계돼요. 처음부터 그룹 중심으로 짜야 해요.

23가지 기본 단위 — 그룹·사용자·한도

그룹 — 정책의 단위

그룹은 공통 정책을 적용할 묶음이에요. 법인·부서·셀러 집합·파트너 조직 등이 여기에 해당해요.

그룹에 묶이는 정책:

가격·할인율
결제 수단 (외상·선불·카드 등)
주문 승인 흐름 여부
정산 주기 (익일·월말·구매확정 후)
세금계산서 발행 기준
배송 조건

사용자 — 실행의 단위

사용자는 실제로 주문·결제·조회를 수행하는 계정이에요. 한 그룹에 여러 사용자가 속해요.

사용자별로 다를 수 있는 것:

역할 (관리자·구매자·조회만·결제 권한)
개인 한도 (월 N만 원, 건당 상한)
승인 권한 (다른 사용자의 주문을 승인할 수 있는지)

한도 — 통제의 단위

한도는 구매 가능 금액·횟수·조건을 제어하는 정책이에요. B2B에서 사고를 막는 가장 실무적인 장치.

한도 설계 축:

집계 단위: 개인별 / 그룹별 / 회차별 / 전체 누적
기간: 일·주·월·연·계약 기간 전체
금액 기준: 결제 시점 누적 / 주문 확정 시점 / 정산 시점

한 줄 정리:

그룹은 정책의 단위
사용자는 실행의 단위
한도는 통제의 단위

3셀러 그룹 vs 바이어 그룹

마켓플레이스에는 두 종류의 그룹이 있어요.

셀러 그룹 (공급자 측)

상품을 판매하는 조직. 같은 플랫폼 안에 여러 셀러가 있고, 각 셀러별로:

정산 조건 (수수료율·정산 주기)
상품 등록 권한
주문 확인·배송 처리 권한
개별 관리자 페이지

바이어 그룹 (구매자 측)

상품을 구매하는 조직. 법인·부서·파트너 집합.

계약 단가·할인
월 구매 한도
결제 수단 (외상 가능 여부)
승인 흐름

양쪽이 모두 있는 구조 (B2B 오픈마켓): 셀러 그룹 × 바이어 그룹의 조합마다 계약 조건이 달라져요. 이 복잡도를 설계 단계에서 인지해야 해요.

4먼저 답해야 할 4가지 질문

질문 1. 그룹 계층 구조가 있는가

평면 구조: 모든 그룹이 같은 레벨. 법인 A, 법인 B, ... (각자 독립). 계층 구조: 법인 A 아래에 영업부·기획부·관리부가 있고, 각 부서가 별도 예산.

계층이 있으면 한도를 상위/하위 어디에 부여할지, 승인이 상위 부서를 거쳐야 하는지 설계가 복잡해져요. 초기에 계층을 지원하지 않더라도 스키마 확장 여지를 남겨두는 편이 나아요.

질문 2. 다중 그룹 소속 허용

단일 소속: 한 사용자는 하나의 그룹에만 속해요. 설계 단순. 다중 소속: 같은 사용자가 여러 법인·부서에 속할 수 있어요. 컨설팅 외주·프리랜서 시나리오에 필요.

다중 소속을 허용하면 "이 주문은 어느 그룹 정책을 따르는가?"를 사용자가 체크아웃 시 선택해야 해요. UX 추가 필요.

질문 3. 권한 상속

상위 그룹의 관리자는 하위 그룹의 주문을 조회·승인할 수 있는가?

상속함: 계층 구조에 맞는 자연스러운 권한 분배
상속 안 함: 그룹별 독립. 권한을 명시적으로 부여

상속을 허용하면 권한 체크 로직이 복잡해져요. 많은 팀이 초기에는 상속 없이 시작하고, 필요 시 확장해요.

질문 4. 한도 집계 기준

한도 사용량을 언제 차감하는가?

주문 시점: 주문 확정 순간 한도 차감
결제 시점: 결제 완료 시 차감
정산 시점: 월말 정산 때 집계

환불·취소 시 한도를 어떻게 복구할지도 같이 정해야 해요.

5시나리오별 설계 예시

법인 SaaS (월 사용료 일괄 정산)

그룹: 법인 단위, 평면 구조
사용자: 법인 관리자 + 일반 사용자 (역할 분리)
한도: 법인 월 예산 + 사용자별 상한
정산: 월말 일괄 세금계산서 발행

멀티셀러 오픈마켓

셀러 그룹: 각 셀러마다 1 그룹, 수수료율·정산 주기 다름
바이어 그룹: 개인 + 법인 구분
한도: 셀러 측은 없음, 법인 바이어는 한도 있음
정산: 셀러별 구매확정 후 N일 정산

B2B 도매 플랫폼

바이어 그룹: 법인 거래처, 계약 단가·결제 조건 다름
사용자: 법인 내 구매 담당자 + 승인자 계층
한도: 법인별 월 한도 + 담당자별 건당 상한 (초과 시 승인자 거침)
정산: 월말 세금계산서, 외상 N일

프랜차이즈 본사·가맹점 구조

그룹: 계층 구조 (본사 → 가맹점)
사용자: 본사 관리자 (전체 조회), 가맹점주 (자기 가맹점만)
한도: 본사는 무제한, 가맹점은 예산 한도
정산: 가맹점별 구매확정 후 본사가 정산 집계

6자주 놓치는 지점 3가지

사용자 이동 시 주문 이력 처리

직원이 법인 A에서 B로 이직하면?

주문 이력은 A에 남겨요 (감사 추적)
사용자 계정은 탈퇴 처리 후 B에 새로 생성 또는 소속만 변경

이 정책을 초기에 정해두지 않으면 이력 추적이 혼란스러워져요.

한도 초과 시 UX

한도 초과 시:

바로 차단? (고객 경험 나쁨)
승인 요청으로 전환? (승인자 알림 + 대기 플로우)
초과분만 개인 카드 결제? (결제 수단 전환)

정책을 명확히 하고 UX 메시지까지 설계해둬요.

환불 시 한도 복구 타이밍

주문 취소·환불 시 한도는 즉시 복구인가 정산 시점 복구인가? 즉시 복구하면 악의적 재주문이 가능해요. 정산 시점 복구하면 고객이 "한도가 안 살아났어요"라고 문의해요. 정책 명시 필요.

7자체 구축 vs 커머스 마켓플레이스 API

자체 구축

완전한 커스터마이징
개발 공수 매우 큼 (6개월 이상)
그룹·한도·정산 집계 로직을 전부 직접
적합: 대형 B2B 플랫폼

커머스 마켓플레이스 API

그룹·사용자·한도·정산 집계 API 제공
관리자 페이지에서 그룹·한도 편집
적합: 중소 규모 플랫폼, 신규 B2B 서비스

중소 규모에서 자체 구축하면 그룹·한도·정산 엣지 케이스가 누적되어 운영 비용이 커져요. 초기에는 커머스 API로 시작해 한계가 명확해지면 일부만 자체 구현으로 이관하는 패턴이 효율적이에요.

다음 단계

그룹·권한 구조가 잡혔다면 정산 모델을 이어서 결정해요.

바로 참고할 문서

개발 문서: B2B 마켓플레이스 이해하기 — 그룹·사용자·한도 API
도입 문의: 도입 문의