쇼핑몰 카테고리 구조, 2단계와 3단계 차이 정리

# 쇼핑몰 카테고리 구조, 2단계와 3단계 차이 정리

카테고리 구조 몇 단계로 할지 고민 중인 운영자라면 지금 결정하세요

---

쇼핑몰을 새로 열거나 기존 쇼핑몰을 리뉴얼할 때, 가장 먼저 부딪히는 벽이 바로 카테고리 구조를 몇 단계로 만들 것인가입니다. 대분류만 두고 끝낼지, 중분류까지 넣을지, 아니면 소분류까지 세 단계로 쪼갤지 결정하는 순간부터 쇼핑몰의 전체 UI/UX와 데이터베이스 설계 방향이 갈라지기 때문이에요.

의외로 많은 운영자들이 이 부분을 가볍게 넘기고 상품부터 등록하기 시작합니다. 하지만 카테고리 구조는 나중에 갈아엎기가 정말 까다로운 영역입니다. 상품이 수백 개만 쌓여도 카테고리를 재설계하려면 전체 데이터 마이그레이션이 필요하고, SEO에 걸린 URL 구조까지 흔들릴 수 있거든요.

이 글에서는 2단계 구조와 3단계 구조의 실질적 차이, 그리고 그 너머에 있는 parent_id 기반 무한 계층 구조, 나아가 태그형 분류 체계까지 쇼핑몰 카테고리 설계에 필요한 모든 개념을 정리해드리겠습니다. 이 글 하나만 정독하시면 자신의 쇼핑몰 규모와 상품 특성에 맞는 카테고리 구조를 스스로 판단하고 설계할 수 있게 될 거예요. 상품 분류 체계는 결국 고객이 원하는 상품을 얼마나 빨리 찾게 해주느냐의 문제이고, 이는 곧 전환율과 직결되는 쇼핑몰 기획의 핵심 뼈대입니다.

준비물·전제조건: 카테고리 설계 전 반드시 정리해야 할 것들

카테고리 구조를 그리기 전에 취급 상품 수와 상품군의 다양성부터 파악하는 게 우선입니다. 상품이 50개 이하로 단순하다면 굳이 3단계까지 만들 필요가 없고, 반대로 수천 개의 SKU를 다루는 쇼핑몰이라면 2단계만으로는 고객이 원하는 상품을 찾는 데 너무 오래 걸립니다.

준비 단계에서 정리해야 할 항목은 다음과 같습니다.

필요한 자료 목록

전체 상품 리스트(엑셀이나 스프레드시트 형태로 정리된 것)가 있어야 하고, 각 상품이 가진 속성값(사이즈, 색상, 소재, 브랜드 등)도 함께 정리되어 있어야 합니다.

경쟁사나 벤치마킹할 쇼핑몰의 카테고리 메뉴 구조를 캡처해두는 것도 큰 도움이 됩니다. 실제 운영 중인 플랫폼들의 카테고리 트리를 참고하면 자신의 업종에서 표준적으로 통용되는 depth와 분류 기준을 파악할 수 있어요.

필요한 지식

트리 구조와 SQL의 기본 개념 정도는 알아두면 설계 단계에서 개발자와 소통이 훨씬 수월합니다. 특히 계층형 데이터를 어떻게 테이블에 저장하는지에 대한 기초 지식이 있으면, 나중에 parent_id 방식이냐 고정 depth 방식이냐를 선택할 때 판단이 빨라집니다.

체크리스트

① 판매할 상품군이 몇 개 정도의 대분류로 나뉘는가
② 각 대분류 안에 세부 분류가 필요한 상품이 있는가
③ 향후 1~2년 안에 상품 카테고리가 크게 늘어날 가능성이 있는가
④ 태그나 필터 검색 기능을 병행할 계획이 있는가

이 네 가지만 정리해도 2단계로 갈지 3단계로 갈지, 혹은 처음부터 무한 확장 구조로 설계할지 방향이 잡힙니다.

Step 1: 2단계 카테고리 구조부터 이해하기

2단계 구조는 대분류와 중분류 두 단계로만 구성되어 단순하고 UI/UX 설계가 쉽다는 것이 가장 큰 장점입니다. 예를 들어 "패션 > 남성의류"처럼 최상위 카테고리 아래 바로 실질적인 상품 그룹이 위치하는 형태예요.

이 구조가 잘 어울리는 경우는 취급 상품군이 명확하고 한정적일 때입니다. 예를 들어 특정 브랜드 하나만 취급하는 단일 브랜드 쇼핑몰이나, 상품 종류가 10~20개 카테고리 안에 다 들어가는 소규모 쇼핑몰이라면 2단계만으로도 고객이 헤매지 않고 원하는 페이지에 도달할 수 있습니다.

2단계 구조의 실무적 장점을 정리하면 다음과 같습니다.

첫째, 메뉴 UI가 단순해서 모바일 화면에서도 드롭다운 두 번이면 상품 목록에 도달합니다.

둘째, 데이터베이스 테이블 설계가 간단합니다. 카테고리 테이블에 상위 카테고리 ID 컬럼 하나만 두면 되기 때문에 개발 기간이 짧아지고 유지보수 부담도 낮습니다.

셋째, 관리자 입장에서 상품을 등록할 때 분류 실수가 적습니다. 선택지가 단순하니 담당자가 헷갈릴 여지가 줄어듭니다.

하지만 단점도 명확한데, 확장성이 낮고 유연하지 않다는 점입니다. 상품이 늘어나면서 하나의 중분류 안에 수백 개의 상품이 뒤섞이는 상황이 생길 수 있습니다. 예를 들어 "남성의류" 카테고리 안에 티셔츠, 셔츠, 니트, 아우터가 전부 섞여 있으면 고객은 결국 필터링 기능에 의존할 수밖에 없고, 이는 카테고리 메뉴 자체의 탐색 기능을 무력화시키는 결과를 낳습니다.

주의사항으로는, 2단계로 시작했다가 나중에 3단계로 확장하려면 기존 상품 데이터의 재분류 작업이 필요하다는 점을 미리 인지해야 합니다. 처음 설계할 때 "이 카테고리가 향후에도 계속 20개 이하로 유지될까?"를 스스로 질문해보고 답이 불확실하다면 처음부터 3단계나 확장 가능한 구조를 고려하는 것이 안전합니다.

Step 2: 3단계 카테고리 구조로 세분화하기

3단계 구조는 대분류, 중분류, 소분류까지 나누어 상품이 많고 다양한 쇼핑몰에서 필수적으로 요구되는 형태입니다. "패션 > 남성의류 > 티셔츠"처럼 소분류 단계까지 내려가면 고객이 카테고리 메뉴만으로도 원하는 상품군에 거의 정확하게 도달할 수 있습니다.

3단계 구조를 도입해야 하는 시점은 대체로 하나의 중분류 안에 상품 종류가 다양해지고, 그 다양성이 고객의 탐색을 방해하기 시작할 때입니다. 패션, 뷰티, 홈리빙처럼 상품 종류가 원래 많은 도메인에서는 처음부터 3단계 이상을 기본값으로 설계하는 경우가 흔합니다.

3단계 구조의 실무적 이점은 다음과 같이 정리할 수 있습니다.

첫째, 고객이 카테고리 메뉴만으로 상품 탐색의 상당 부분을 마칠 수 있어 검색창이나 필터에 대한 의존도가 낮아집니다.

둘째, 관리자 페이지에서 상품을 분류할 때 더 정교한 기준을 적용할 수 있어 재고 관리나 프로모션 타겟팅이 쉬워집니다.

셋째, SEO 관점에서도 URL 구조가 "/fashion/mens/tshirt"처럼 계층적으로 표현되면 검색엔진이 페이지의 맥락을 더 잘 이해합니다.

다만 3단계 구조에도 주의할 점이 있습니다. 소분류를 지나치게 잘게 쪼개면 오히려 메뉴가 복잡해지고, 모바일 환경에서는 3단계 드롭다운을 타고 들어가는 것 자체가 사용자에게 피로감을 줄 수 있습니다. UX 관점에서는 카테고리 레이어에 진입한 뒤 필요한 태스크 단계 수가 사용자 탐색 효율에 직접적인 영향을 주기 때문에, 예를 들어 목적 상품에 도달하기까지 총 4단계가 걸리는 구조와 2단계면 충분한 구조는 체감 난이도가 크게 다릅니다.

따라서 3단계로 설계할 때는 소분류 하나당 최소 상품 개수 기준을 미리 정해두는 것을 권장합니다. 예를 들어 소분류 안에 상품이 5개 미만이라면 굳이 별도 소분류로 만들지 말고 중분류에 통합하는 식의 원칙을 세워두면 카테고리가 불필요하게 파편화되는 것을 막을 수 있습니다. 또한 카테고리 범위가 넓고 상품 수가 많을수록 고객의 시간과 동선을 아껴주는 UX와 검색 영역의 설계가 함께 중요해진다는 점도 기억해두시면 좋습니다.

Step 3: parent_id 기반 무한 계층 구조 이해하기

parent_id를 이용한 자기참조 구조는 부모-자식 관계로 무한 단계 구성이 가능해 유연성과 확장성이 가장 높은 방식입니다. 이 방식은 카테고리 테이블 안에 자기 자신을 참조하는 컬럼(parent_id)을 두어, 한 카테고리가 다른 카테고리의 하위 항목이 되는 구조를 몇 단계든 만들 수 있게 합니다.

예를 들어 카테고리 테이블에 id, name, parent_id 세 개의 컬럼만 있어도 "패션(id:1, parent_id:null) > 남성의류(id:2, parent_id:1) > 티셔츠(id:3, parent_id:2) > 반팔티셔츠(id:4, parent_id:3)"처럼 4단계, 5단계, 그 이상도 자유롭게 확장할 수 있습니다. 고정된 depth 컬럼 없이 관계형으로 계층을 표현하기 때문에 사업이 커지고 카테고리가 세분화되어도 테이블 구조 자체를 바꿀 필요가 없다는 게 가장 큰 매력입니다.

이 방식을 선택하면 좋은 경우는 다음과 같습니다.

취급 상품군이 계속 늘어날 것으로 예상되는 쇼핑몰, 여러 브랜드나 여러 사업부를 하나의 플랫폼에서 운영하는 경우, 혹은 향후 해외 진출이나 신규 카테고리 추가 가능성이 높은 경우라면 처음부터 parent_id 방식으로 설계해두는 것이 안전합니다.

하지만 이 구조에는 분명한 단점이 있습니다. 바로 전체 경로 조회 시 재귀 또는 반복 쿼리가 필요하다는 점입니다. 예를 들어 "반팔티셔츠"라는 카테고리의 전체 경로(패션 > 남성의류 > 티셔츠 > 반팔티셔츠)를 화면에 브레드크럼(경로 표시)으로 보여주려면, 데이터베이스에서 parent_id를 계속 타고 올라가는 재귀 쿼리를 실행하거나, 애플리케이션 레벨에서 반복문으로 조회해야 합니다.

이 과정에서 카테고리 깊이가 깊어질수록 쿼리 성능이 저하될 수 있고, 개발자 입장에서는 재귀 쿼리(CTE, Recursive Common Table Expression 등)를 다뤄본 경험이 없으면 구현 난이도가 갑자기 올라갑니다. 이를 보완하기 위해 실무에서는 materialized path 방식(전체 경로를 문자열로 미리 저장해두는 방식)이나 closure table 방식(조상-자손 관계를 별도 테이블에 미리 저장) 같은 보조 기법을 함께 사용하기도 합니다.

주의사항으로는, parent_id 방식을 채택하기로 결정했다면 개발 초기 단계에서부터 전체 경로 조회 로직을 어떻게 최적화할 것인지 반드시 설계에 포함시켜야 한다는 점입니다. 이를 나중에 추가하려고 하면 이미 쌓인 카테고리 데이터 전체를 다시 점검해야 하는 상황이 생길 수 있습니다.

Step 4: 태그형 분류와 병행 운영 전략 세우기

계층 구조 없이 키워드(태그)로 분류하는 방식은 카테고리 구조와는 완전히 별개로 운영되지만 유연하고 추천·검색에 유리하다는 강점이 있습니다. 태그형 분류는 트리 구조처럼 상하 관계가 없이, 하나의 상품에 여러 개의 태그를 동시에 붙일 수 있다는 점에서 계층형 카테고리와 근본적으로 다릅니다.

예를 들어 티셔츠 하나에 "여름", "베이직", "화이트", "면소재"라는 태그를 동시에 부여하면, 고객은 카테고리 메뉴를 타고 들어오지 않아도 "여름"이라는 태그로 검색하거나 필터링해서 이 상품을 발견할 수 있습니다. 계층형 카테고리는 상품이 반드시 하나의 경로에만 속하지만, 태그는 다대다 관계로 자유롭게 부여할 수 있다는 게 결정적 차이입니다.

실무에서는 계층형 구조와 태그형 카테고리를 병행 운영하는 방식이 널리 활용됩니다. 계층형 카테고리는 상품의 기본적인 소속(어느 대분류, 중분류에 속하는가)을 정의하는 뼈대 역할을 하고, 태그는 그 위에 유연한 검색과 추천을 얹는 역할을 합니다. 실제 서비스들을 보면 패션, 뷰티, 홈리빙처럼 도메인 중심으로 최상위 카테고리를 나누는 방식과 성별·연령·스타일 같은 사용자 속성 기반으로 분류하는 방식, 그리고 테마나 기획전처럼 유연한 카테고리를 별도로 운영하는 방식이 함께 쓰이고 있습니다.

이런 병행 운영이 필요한 이유는 명확합니다. 계층형 구조만으로는 "20대 여성이 좋아할 만한 미니멀 스타일"처럼 여러 축이 겹치는 탐색 니즈를 충족시키기 어렵기 때문입니다. 반대로 태그만으로는 상품 관리자가 전체 상품군을 체계적으로 관리하기 어렵습니다. 두 방식을 병행하면 관리자는 계층형 구조로 상품을 체계적으로 등록하고, 고객은 태그 기반 필터와 추천 시스템으로 원하는 상품을 더 빠르게 발견하게 됩니다.

주의사항으로는, 태그를 무분별하게 늘리면 오히려 태그 자체가 관리 부담이 됩니다. 태그 마스터 테이블을 별도로 관리하고, 신규 태그를 등록할 때 기존 태그와 중복되거나 유사한 의미인지 검토하는 프로세스를 마련해두는 것이 좋습니다. 예를 들어 "여름"과 "썸머"가 별개의 태그로 등록되면 검색 결과가 분산되어 태그 시스템의 효율이 떨어집니다.

자주 발생하는 오류: 카테고리 설계 시 흔한 실수들

카테고리 설계에서 가장 흔한 오류는 depth를 처음부터 과도하게 깊게 만드는 것입니다. 소분류 아래에 세세분류까지 만들어 5단계, 6단계로 파고드는 경우가 있는데, 이렇게 되면 고객이 원하는 상품에 도달하기까지 클릭 횟수가 지나치게 늘어나고, 관리자 입장에서도 상품 하나를 등록할 때마다 깊은 depth를 일일이 선택해야 하는 번거로움이 생깁니다.

두 번째로 흔한 오류는 하나의 상품을 여러 카테고리에 동시에 속하게 하려다가 데이터 구조가 꼬이는 경우입니다. 예를 들어 "여성 운동화"라는 상품을 "여성의류 > 신발"과 "스포츠 > 러닝화" 두 곳에 모두 노출하고 싶을 때, 계층형 구조만으로 이를 구현하려면 상품-카테고리 관계를 다대다로 설계해야 하는데, 처음부터 일대다 구조(상품 하나에 카테고리 하나만 매핑)로 설계해두면 나중에 테이블 구조 자체를 변경해야 하는 상황이 벌어집니다.

세 번째 오류는 카테고리명과 URL 슬러그를 분리하지 않아 카테고리명을 바꿀 때마다 URL이 깨지는 경우입니다. 카테고리명은 마케팅이나 UX 필요에 따라 자주 바뀔 수 있지만, URL은 SEO 자산이므로 최대한 유지되어야 합니다. 카테고리명 컬럼과 별개로 슬러그 컬럼을 두어야 이런 문제를 방지할 수 있습니다.

네 번째는 재귀 쿼리 성능을 고려하지 않고 parent_id 방식을 도입한 뒤 카테고리 depth가 깊어지면서 페이지 로딩이 느려지는 경우입니다. 이럴 때는 앞서 언급한 materialized path나 closure table 같은 보조 구조를 검토하거나, 캐싱 레이어를 추가해서 전체 카테고리 트리를 자주 다시 계산하지 않도록 최적화해야 합니다.

활용 팁 & 베스트 프랙티스

카테고리 설계에서 가장 중요한 팁은 처음부터 완벽한 구조를 만들려 하지 말고, 확장 가능한 여지를 남겨두는 것입니다. 실무에서 검증된 몇 가지 노하우를 정리하면 다음과 같습니다.

첫째, 카테고리 트리 데이터를 설계할 때는 depth 컬럼을 별도로 두어 현재 이 카테고리가 몇 단계에 위치하는지 빠르게 조회할 수 있게 해두면 좋습니다. parent_id만으로는 특정 카테고리가 몇 번째 depth인지 알려면 재귀적으로 거슬러 올라가야 하지만, depth 컬럼을 함께 저장해두면 이 계산을 미리 해둔 값으로 즉시 조회할 수 있습니다.

둘째, 카테고리별로 정렬 순서(sort_order) 컬럼을 반드시 넣어두시기 바랍니다. 카테고리 메뉴는 알파벳 순서나 등록 순서가 아니라 매출이나 시즌 특성에 따라 관리자가 임의로 순서를 바꿀 일이 많기 때문에, 이 컬럼이 없으면 나중에 메뉴 순서를 바꿀 때마다 개발자에게 요청해야 하는 번거로움이 생깁니다.

셋째, SKU 관리와 카테고리 구조를 혼동하지 않아야 합니다. SKU(Stock Keeping Unit)는 색상, 사이즈 같은 옵션 조합별 재고 관리 단위이고, 카테고리는 상품을 탐색하기 위한 분류 체계입니다. 하나의 상품이 여러 SKU를 가질 수 있지만, 카테고리는 그 상품 자체에 매핑되는 것이 일반적입니다. 이 둘을 같은 테이블에서 관리하려고 하면 데이터 구조가 복잡해지므로 처음부터 상품 테이블, SKU 테이블, 카테고리 테이블을 분리해서 설계하는 것이 안전합니다.

넷째, 카테고리 메뉴를 설계할 때 실제 고객이 어떤 경로로 상품을 찾는지 로그 데이터를 참고하면 좋습니다. 검색 키워드 상위 항목과 실제 카테고리 클릭 경로를 비교해보면, 예상과 다르게 고객들이 특정 카테고리를 거의 이용하지 않거나, 반대로 특정 소분류에 트래픽이 몰리는 현상을 발견할 수 있습니다. 이런 데이터를 기반으로 카테고리 구조를 주기적으로 재검토하는 것이 좋은 운영 습관입니다.

응용·확장: 카테고리 구조를 더 똑똑하게 활용하는 법

카테고리 구조는 단순히 상품을 분류하는 도구를 넘어 마케팅과 검색 최적화의 기반으로 확장 활용할 수 있습니다. 잘 설계된 카테고리 트리는 그 자체로 SEO 자산이 됩니다. 각 카테고리 페이지가 고유한 URL과 메타 정보를 가지면, 검색엔진이 "여성 니트"나 "남성 운동화"처럼 구체적인 키워드로 유입되는 트래픽을 확보하는 랜딩페이지 역할을 하게 됩니다.

또한 계층형 카테고리와 태그형 분류를 병행 운영하는 구조는 추천 시스템의 기반 데이터로도 활용될 수 있습니다. 고객이 특정 태그가 붙은 상품을 자주 클릭한다면, 그 태그를 기준으로 "이런 상품은 어떠세요" 같은 연관 상품 추천 로직을 만들 수 있습니다. 이는 카테고리 구조 자체가 단순 분류를 넘어 개인화 추천의 원천 데이터가 된다는 것을 의미합니다.

기획전이나 시즌 프로모션을 운영할 때도 카테고리 구조를 응용할 수 있습니다. 정규 카테고리 트리와는 별도로 "여름 기획전", "블랙프라이데이" 같은 임시성 카테고리를 만들어 특정 기간 동안만 노출시키고, 프로모션이 끝나면 비활성화하는 방식으로 운영하면 정규 카테고리 구조를 훼손하지 않으면서도 유연하게 이벤트를 진행할 수 있습니다.

마지막으로, 다국어나 다지역 쇼핑몰을 운영할 계획이 있다면 카테고리명 컬럼을 다국어 지원 가능한 구조로 미리 설계해두는 것도 좋은 확장 전략입니다. 카테고리 ID는 고정하되, 언어별 카테고리명을 별도 테이블에서 관리하면 향후 해외 진출 시에도 카테고리 구조 자체를 다시 설계할 필요가 없습니다.

점검 체크리스트

카테고리 설계를 마무리하기 전에 아래 항목을 다시 한번 점검해보세요.

① 현재 상품 수와 향후 예상 증가량을 고려했을 때 2단계, 3단계, 혹은 무한 확장 구조 중 어떤 것이 적합한지 결정했는가
② 카테고리 테이블에 depth, sort_order, 슬러그 컬럼을 포함했는가
③ SKU 관리와 카테고리 분류 체계를 별도 테이블로 분리했는가
④ 계층형 구조와 태그형 분류를 병행 운영할지 여부를 결정했는가
⑤ parent_id 방식을 선택했다면 전체 경로 조회 성능 최적화 방안을 마련했는가
⑥ 모바일 환경에서 카테고리 메뉴 진입부터 상품 페이지 도달까지 몇 단계가 걸리는지 테스트했는가

이 여섯 가지만 점검해도 카테고리 구조에서 발생하는 대부분의 리스크를 사전에 방지할 수 있습니다.

자주 묻는 질문 FAQ

Q1. 소규모 쇼핑몰인데도 3단계 구조가 필요할까요?
상품 수가 20개 이하로 적고 앞으로도 크게 늘어날 계획이 없다면 2단계로도 충분합니다. 다만 향후 상품군이 다양해질 가능성이 조금이라도 있다면, 처음부터 3단계 테이블 구조를 잡아두고 실제로는 중분류까지만 노출하는 방식도 고려해볼 만합니다.

Q2. 카테고리 구조를 나중에 2단계에서 3단계로 바꿀 수 있나요?
가능합니다. 다만 기존 상품 데이터를 새로운 소분류 기준으로 재분류하는 작업이 필요하고, 이미 검색엔진에 노출된 URL이 있다면 리다이렉트 설정도 함께 고려해야 합니다.

Q3. parent_id 방식과 고정 depth 방식 중 어느 것을 먼저 검토해야 하나요?
카테고리가 앞으로도 계속 늘어나거나 여러 사업부·브랜드를 함께 운영할 계획이 있다면 parent_id 방식을, 반대로 카테고리 구조가 처음부터 명확하고 변경 가능성이 낮다면 고정 depth 방식을 우선 검토하는 것이 효율적입니다.

Q4. 태그형 분류는 반드시 계층형 카테고리와 함께 운영해야 하나요?
필수는 아니지만, 계층형 카테고리는 상품 관리의 뼈대 역할을, 태그는 유연한 검색과 추천의 역할을 하기 때문에 병행 운영했을 때 관리 효율과 고객 탐색 경험 모두를 개선할 수 있습니다.

Q5. 카테고리 depth는 몇 단계까지가 적당한가요?
정해진 정답은 없지만, 고객이 목적 상품에 도달하기까지 필요한 클릭 수가 너무 많아지지 않는 선에서 결정하는 것이 중요합니다. 일반적으로는 3단계 안팎에서 대부분의 상품군을 충분히 표현할 수 있습니다.

---

카테고리 구조는 쇼핑몰의 첫인상이자 고객이 상품을 찾는 가장 기본적인 통로입니다. 오늘 정리한 2단계, 3단계, parent_id 기반 무한 계층, 태그형 분류까지 각 방식의 장단점을 자신의 상품 규모와 운영 계획에 맞춰 다시 한번 점검해보시기 바랍니다. 처음부터 완벽한 구조를 만들기보다는, 확장 가능한 여지를 남겨두고 데이터 기반으로 지속적으로 개선해나가는 것이 카테고리 설계의 핵심입니다.