등급마다 가격이 다른데, 어디까지 보여 줄까
카페24 쇼핑몰에서 ‘일반 회원과 VIP 가격이 다르게 보이게 해 주세요’, ‘도매 회원만 이 가격이 보이게 해 주세요’ 같은 요청은 자주 나옵니다. 관리자에서 회원 등급·그룹별 가격을 설정할 수는 있지만, 운영자가 막히는 지점은 설정 자체보다 **어디에, 누구에게, 어떤 금액으로 보이게 할지**입니다.
가능 여부부터 말하면, 단순 등급 할인·회원 그룹 가격은 카페24 기본 기능과 앱으로 어느 정도까지 가능합니다. 다만 상세에만 다른 가격을 보여 주고 장바구니·주문서·결제 금액이 어긋나면 CS·정산 사고로 이어집니다. 카페24에서 회원 그룹별 가격·혜택을 설계할 때는 화면 표시만이 아니라, 장바구니·주문서·결제까지 같은 규칙으로 남는지부터 잡는 편이 안전합니다.
노출 지점별로 나누어 설계하기
첫째, **누가** 볼지입니다. 비회원·일반 회원·승인된 B2B·특정 등급처럼 그룹을 문장으로 적습니다. 둘째, **어디에** 보일지입니다. 상품 리스트, 상세, 로그인 후 마이페이지, 장바구니, 주문서, 결제 직전까지 각각 요구가 다릅니다. 셋째, **무엇**이 다른지입니다. 판매가, 할인율, 포인트 적립, 배송비, 구매 가능 여부, 노출 상품 범위가 섞여 있으면 범위가 커집니다.
기본·앱으로 많이 가는 패턴은 관리자에서 회원 등급(그룹)별 가격·혜택을 설정하고, 상품 상세·리스트에 등급가를 노출하는 것입니다. 스킨·스크립트로 ‘로그인한 등급만 이 배너·문구·가격 영역을 보이게’ 하는 경우도 있습니다. 규칙이 ‘상품마다 다른 공식’, ‘주문 금액·수량에 따라 달라짐’, ‘외부 DB의 승인 상태와 맞춤’이면 API·별도 서버·커스텀 로직을 검토하게 됩니다.
화면별로 자주 정하는 것
상품 리스트·상세: 등급별 판매가, ‘회원가’ 문구, 로그인 유도. 장바구니·주문서: 실제 청구 금액, 쿠폰·적립과 겹칠 때 우선순위. 마이페이지: 내 등급·다음 등급 조건·전용 혜택 안내. 카테고리·메뉴: 특정 그룹만 보이는 상품·기획전. 각 지점에서 ‘보이기만 하는지’ ‘주문 데이터에 실리는지’를 구분해야 합니다.
구현 방식별 경계
카페24 기본: 등급·그룹 가격, 등급별 적립·할인 설정. 앱: 등급가 표시, B2B 승인·전용몰, 복수 등급 관리. 스킨/프론트: 문구·배치·조건부 표시(로그인·등급 분기). API·커스텀: 복잡한 가격 공식, 외부 승인 연동, 주문서 커스텀 필드, 전용 관리 화면. 화면만 예쁘게 바꾸는 것과 주문 금액을 바꾸는 것은 작업 범위가 다릅니다.
- 설계 3요소: 대상 그룹 · 노출 화면 · 바뀌는 항목(가격·혜택·구매 가능)
- 기본·앱: 등급가·그룹 혜택 설정 + 표시
- 스킨: 조건부 UI·문구 (금액 계산은 기본·앱 규칙 따름)
- API·커스텀: 복잡 공식·외부 승인·주문서까지 커스텀
설계·검수에서 자주 틀어지는 지점
상세에 ‘VIP 9,000원’이 보이는데 장바구니·결제는 10,000원인 경우가 대표적입니다. 원인은 스킨만 바꿨거나, 등급 설정과 쿠폰·이벤트 우선순위가 겹치거나, 비회원·다른 등급으로 세션이 바뀐 경우입니다. 오픈 전에는 **그룹별로 동일 상품을 장바구니까지** 넣어 보는 검수가 필요합니다.
쿠폰·적립·기획 할인과 등급가를 동시에 쓰면 ‘어떤 할인이 먼저 적용되는지’ CS가 헷갈립니다. 설계 단계에서 중복 적용 가능 여부·최종 금액 예시를 표로 적어 두면 개발·운영 모두 편합니다. B2B처럼 승인 전·후 가격이 바뀌는 경우, 승인 상태가 API·앱·관리자 중 어디가 기준인지도 정해야 합니다.
모바일·PC, 비회원→로그인 전환, 등급 변경 직후 캐시된 화면에서 가격이 다르게 보일 수 있습니다. ‘로그인하면 가격이 바뀝니다’ 문구만 넣고 끝내지 말고, 로그인 후 새로고침·재진입 시에도 같은지 확인합니다. 규칙이 단순하면 기본·앱으로 시작하고, 막히는 한 줄(예: 품목·수량·거래처별 단가)만 2차에 커스텀하는 편이 비용 대비 안전한 경우가 많습니다.
설계 전에 적어 두면 좋은 표
그룹 이름 · 보는 화면(리스트/상세/장바구니) · 가격/혜택 규칙 · 쿠폰과 겹칠 때 · 비회원 처리 · 승인 필요 여부. 이 표가 있으면 ‘스킨만 고치면 되나요?’와 ‘주문서까지 개발이 필요한가?’가 갈립니다.
안 될 때·비쌀 때 대안
등급별 가격 대신 등급별 **쿠폰 자동 발급**만으로 버티는 경우, **특정 카테고리만** 그룹에게 공개하는 경우, **견적·승인 후 주문**으로 1차 범위를 줄이는 경우가 있습니다. 전 상품·전 등급·전 화면을 한 번에 맞추려 하면 일정과 검수 부담이 커집니다.
- 상세 가격 ≠ 장바구니·결제 금액 (가장 흔한 CS)
- 등급가 + 쿠폰 + 이벤트 중복 적용 규칙 미정
- 승인 전 회원에게 B2B가 노출
- 스킨만 수정해 주문 데이터에는 반영 안 됨
- 등급 변경 직후 이전 가격이 캐시되어 보임
옴니어스가 그룹별 가격·혜택을 설계할 때
옴니어스는 ‘등급별로 예쁘게 보이게’만 듣고 바로 스킨 견적을 내기보다, 그룹 정의·노출 화면·장바구니까지의 규칙을 먼저 같이 적습니다. 기본·앱으로 되는 부분과 스킨·API·커스텀이 필요한 부분을 나누고, 1차는 리스트·상세·주문서까지 금액이 맞는 최소 범위로 잡는 편입니다.
자료가 없어도 ‘누가 어떤 가격을 봐야 하는지’ 예시 두세 개만 있으면 설계 방향을 잡을 수 있습니다. B2B·도매·VIP가 섞이면 승인 흐름과 함께 봐야 해서, 회원 그룹 가격 글과 별도로 B2B 흐름 주제도 이어서 검토할 수 있습니다.
회원 그룹·가격 설계 다음에 보면 좋은 글·페이지
상품 상세 추가금액·조건별 가격, 앱 vs 커스텀 구분, 제작 전 요구사항 체크리스트, 기존 몰에 기능 추가할 때 깨지기 쉬운 지점(주문서·쿠폰 충돌)을 이어서 읽어 보시면 설계에 도움이 됩니다.
서비스·진행 방식·FAQ에서 범위와 진행 흐름을 더 볼 수 있고, 문의 페이지에 ‘등급(그룹) 이름과 원하는 화면·가격 예시’만 남겨 주셔도 됩니다. 어디까지 기본·앱으로 갈지, 어디부터 커스텀을 볼지 기준으로 안내해 드립니다.