핵심 요약
- 카테고리는 고객이 어디로 탐색할지 정하는 축이라 상품 수가 늘수록 중요해져요.
- 정렬은 팀이 보여주고 싶은 순서가 아니라 고객 의도에 맞는 발견 흐름이어야 해요.
- 노출 상태는 디자인 요소가 아니라 운영 상태와 재고 상태를 연결하는 장치로 봐야 해요.
1카테고리 트리는 고객 탐색 축으로 설계해요
카테고리를 만들 때 가장 흔한 실수는 팀 내부 분류를 그대로 진열에 올리는 일이에요. 상품 유형, 공급처, 담당 조직, 입고 채널 기준은 운영자에게는 편하지만 고객에게는 탐색 힌트가 되지 않아요. 고객은 "어느 팀이 등록했는가"가 아니라 "지금 무엇을 해결하려고 들어왔는가"를 기준으로 움직여요. 선물용을 찾는 고객, 첫 구매 상품을 찾는 고객, 고가 라인을 비교하는 고객은 모두 다른 길을 원해요.
그래서 카테고리 트리는 내부 재고표의 복사본이 아니라 고객의 질문 목록이어야 해요. 보통은 대분류, 중분류, 필요하면 소분류 정도까지면 충분해요. 2~3단 깊이를 넘기기 시작하면 고객은 탐색보다 길 찾기에 에너지를 써요. 반대로 너무 평평하면 상품 수가 늘 때 필터와 목록 길이만 길어져요. 좋은 트리는 상품이 늘어도 고객이 "내가 찾는 곳이 여기예요"라고 바로 판단하게 만들어요. 운영팀 내부 분류가 따로 필요하다면 진열 트리와 분리해 관리하는 편이 나아요.
2정렬은 팀이 보여주고 싶은 순서가 아니라 고객 의도에 맞춰야 해요
정렬은 작은 기능처럼 보이지만 실제로는 고객 의도를 읽는 장치예요. 처음 들어온 고객은 추천이나 인기순에서 안전한 선택을 찾고, 이미 제품군을 아는 고객은 신규순이나 가격순에서 비교를 시작해요. 즉 기본 정렬은 팀의 우선 과제가 아니라 고객의 첫 행동을 기준으로 정해야 해요. 추천, 인기, 신규, 가격 같은 기본 정렬이 반복해서 쓰이는 이유도 여기 있어요. 이름은 단순해 보여도 각각 다른 탐색 경로를 열어요.
반대로 운영팀이 자주 원하는 "재고 많이 남은 상품 우선", "이번 주 밀어야 하는 상품 우선" 같은 기준을 메인 정렬에 섞으면 목록 전체의 신뢰가 떨어져요. 고객은 정렬 이름을 믿고 클릭하는데 실제 결과가 그 기대를 어기면 이탈이 빨라져요. 재고 소진 우선, 행사 우선, 마진 우선 같은 운영 목표는 프로모션 영역이나 기획전 슬롯에 제한해서 쓰는 편이 맞아요. 메인 정렬은 고객 의도에 맞추고, 운영 우선순위는 별도 노출 영역에서 통제해야 전환과 재고 운영을 같이 잡을 수 있어요.
3노출 상태는 디자인 요소가 아니라 재고·운영 상태의 연결 장치로 봐요
진열 상태를 단순히 보이게 할지 숨길지의 문제로 보면 운영 정보가 고객에게 늦게 전달돼요. 품절, 입고 예정, 시즌 오프, 한정 수량, 판매 중단 같은 상태는 모두 고객 판단에 직접 영향을 줘요. 같은 상품이라도 재고가 충분할 때와 거의 소진됐을 때의 우선순위, 배지, 버튼 상태는 달라져야 해요. 품절인데도 일반 상품처럼 보이면 불필요한 클릭이 늘고, 반대로 입고 예정 상품을 아예 숨기면 재입고 수요를 놓쳐요.
핵심은 상태를 일관된 언어로 드러내는 거예요. 품절이면 구매 행동을 막고 재입고 알림이나 대체 상품 이동을 제안해야 해요. 시즌 오프면 검색 노출은 낮추되 기존 구매자나 후기 유입은 받을 수 있게 남겨둘 수 있어요. 한정 수량은 과장된 긴급감이 아니라 실제 재고 상황과 연결되어야 해요. 결국 노출 상태는 화면 장식이 아니라 재고 데이터와 운영 판단이 고객 경험으로 번역되는 접점이에요. 이 연결이 명확할수록 고객은 왜 지금 이 상품이 이렇게 보이는지 이해해요.
4진열 상태 변경 로그를 남겨 책임과 원인을 추적해요
운영 현장에서는 "어제까지 보였는데 오늘 사라졌어요"라는 문제가 자주 생겨요. 그런데 변경 로그가 없으면 원인을 찾는 과정이 사람 기억과 메신저 대화에 의존하게 돼요. 누가 언제 어떤 이유로 비노출 처리했는지, 품절 전환인지 담당자 실수인지, 기획전 종료인지가 기록되지 않으면 CS 대응도 늦어지고 팀 간 책임 공방도 커져요. 특히 시즌 상품이나 다채널 판매 상품은 짧은 시간 안에 상태가 여러 번 바뀌기 때문에 기록 부재의 비용이 더 커요.
진열 상태 변경 로그는 단순 감사용이 아니에요. 운영 실수를 빠르게 잡고, 특정 카테고리에서 비노출 전환이 잦은 이유를 분석하고, 권한 정책이 맞는지 되돌아보게 하는 기본 장치예요. 로그에는 변경 시점, 변경자, 변경 전후 상태, 변경 이유 정도만 있어도 충분히 강력해요. 나중에 CS 문의가 들어왔을 때 "왜 사라졌는지"를 바로 설명할 수 있고, 반복되는 사고가 있으면 프로세스를 손볼 근거도 생겨요. 진열 전략은 화면 배치에서 끝나지 않아요. 바뀐 이유를 추적할 수 있을 때 비로소 운영 가능한 전략이 돼요.