결론: ‘임박할 때만’ 보이게 하는 쪽이 핵심이다
네, 카페24 상품 상세에 품절 임박 수량만 노출하는 것은 가능합니다. 다만 요구를 ‘재고를 항상 숫자로 보여 준다’와 ‘남은 수량이 N개 이하일 때만 문구를 띄운다’로 나누면, 쓰는 기능과 커스텀 범위가 달라집니다.
많은 몰은 재고를 전부 공개하기보다 ‘마감 임박 · 잔여 3개’처럼 구매 유도만 하고 싶어 합니다. 이 경우 임계값(예: 5개 이하), 옵션별인지 상품 합산인지, 실시간인지 캐시인지를 먼저 정해야 구현이 흔들리지 않습니다.
품절 임박 수량을 상세에 넣는 구현 경로
첫 번째는 카페24 기본·설정으로 재고 관련 표시가 되는지 확인하는 일입니다. 몰·스킨·버전에 따라 재고 표시·품절 처리 옵션이 다르므로, ‘항상 수량’과 ‘임박만’이 기본만으로 되는지는 관리자·스킨 설정을 먼저 봅니다. 기본만으로 임계값 조건이 안 되면 다음 단계로 갑니다.
두 번째는 앱스토어의 재고·긴급성 표시 앱입니다. 문구·배지 UI를 빠르게 붙일 수 있으나, 옵션 단위 재고·멀티몰·지연 반영 지원 여부는 앱마다 다릅니다. 문서에 ‘N개 이하일 때만 노출’이 명시돼 있는지 확인하세요.
세 번째는 스킨·스크립트에서 재고 값을 읽어 임계값 이하일 때만 DOM에 문구를 넣는 방식입니다. 프로토타입은 빠르지만, 재고 데이터의 출처(페이지에 심긴 값 vs API)와 캐시·옵션 변경 시 갱신이 맞는지가 관건입니다. 프론트만으로 조작·오표시가 생기기 쉬운 구조면, 신뢰할 수 있는 재고 API·서버 응답을 쓰는 편이 안전합니다.
커스텀이 유리한 경우
옵션별 잔여만 다르게 보여 주기, ‘임박’ 기준을 상품군마다 다르게 두기, 재고는 보여 주되 정확한 숫자는 숨기고 구간만 표시하기, 별도 서버·ERP 재고와 맞추기는 기본·앱만으로 부족할 때가 많습니다. 이때 상세 UI + 재고 조회(API) + 임계값 규칙을 한 세트로 설계합니다.
검수에서 꼭 볼 시나리오
임박 직전(안 보임) → 임박(보임) → 품절(구매 불가)로 수량을 바꿔 가며 상세·옵션 전환·장바구니를 확인합니다. 동시 구매로 재고가 줄어들 때 문구가 늦게 바뀌는지도 봅니다.
- 임계값·옵션 단위·문구 형태를 문장으로 고정
- 기본·앱으로 되면 커스텀 전에 설정부터 확인
- 프론트 표시는 재고 출처·옵션 변경·캐시를 함께 설계
- 최종 기준은 ‘보이는 숫자’와 ‘실제 구매 가능 여부’가 맞는 것
제한사항과 현실적인 대안
재고는 주문이 들어오는 순간마다 변합니다. 상세 캐시·CDN·앱 갱신 주기 때문에 ‘방금 본 3개’와 결제 시점 재고가 어긋날 수 있습니다. 정확한 숫자를 항상 약속하기보다, 임박 문구 + 품절 시 구매 차단이 더 안전한 경우가 많습니다.
옵션 조합이 많으면 옵션마다 임박 표시 규칙이 복잡해집니다. 또한 재고를 과도하게 공개하면 경쟁·매크로에 노출될 수 있어, ‘N개 이하일 때만’ 또는 ‘몇 개 남음’ 수준으로 흐리게 하는 대안도 실무에서 씁니다. 1차는 대표 상품·단일 옵션만 열고, 전 SKU 확장은 2차로 미뤄도 됩니다.
- 임박 기준 수량(예: 5 이하)과 문구를 미리 확정
- 상품 합산 vs 옵션별 잔여 중 무엇을 보여줄지 선택
- 품절 전환 시 버튼·옵션 선택이 막히는지 검수
- 실시간성이 중요하면 API·갱신 주기를 견적 범위에 포함
- 숫자 대신 ‘임박’ 배지만으로도 목표면 범위를 줄일 수 있음
옴니어스가 품절 임박 표시 요청을 나누는 방식
옴니어스는 ‘재고 숫자를 상세에 띄우기’보다, 임박 조건·옵션 단위·품절 시 구매 차단이 맞는지부터 같이 정합니다. 기본·앱으로 되면 그걸 우선하고, 규칙이 상품마다 다르거나 ERP와 맞춰야 하면 커스텀 범위를 자릅니다.
임계값과 ‘옵션별인지’만 알려 주셔도 방향을 잡는 데 도움이 됩니다. 거품 없는 범위로 일한 만큼 제안드립니다.
품절 임박 질문 다음에 보면 좋은 글·페이지
상세 추가금액 FAQ, 옵션 조합이 많을 때 기본으로 버틸지, API·별도 서버 안내를 이어서 보시면 재고·상세 연동을 고르는 데 도움이 됩니다.
FAQ·서비스·진행 방식에서도 확인할 수 있고, 문의에 원하는 임박 기준만 남겨 주셔도 됩니다. 가능 여부와 제한부터 같이 정리해 드립니다.