“상품을 쪼개는 기능”이 아니라 “공통 데이터 구조”를 세우는 일

백오피스 화면설계에서 상품 옵션 관리는 유난히 난이도가 높은 영역으로 분류됩니다. 이유는 단순합니다. 옵션은 화면에서 보이는 선택 UI만 설계하는 문제가 아니라, 상품의 판매 단위와 재고 단위, 그리고 주문 데이터의 구조까지 함께 쪼개버리는 기능이기 때문입니다. 그래서 옵션을 어떻게 설계하느냐에 따라 운영 방식이 달라지고, 한 번 잘못 만들면 이후에 되돌리기 어려워집니다. 결국 옵션 관리는 “기능 하나 추가”가 아니라, 시스템이 상품을 바라보는 단위를 정의하는 작업에 가깝습니다.

상품 옵션이 무엇인지 개념부터 정리하고, 왜 옵션을 상품 상세에 붙이지 않고 별도의 옵션 관리 메뉴로 분리하는지, 그리고 옵션이 재고·주문·통계까지 어떻게 연결되는지를 정리해보겠습니다.

 

상품 옵션 관리의 개념 - “상품은 하나인데 판매 단위는 여러 개”

먼저 상품 옵션이 왜 필요한지부터 정확히 짚고 넘어가야 합니다. 상품 옵션은 상품을 더 잘게 쪼개는 수단입니다. 여기서 핵심은 “상품이 여러 개로 늘어나는 것”이 아니라, 상품은 하나인데 판매 단위가 여러 개로 나뉘는 것입니다. 즉, 옵션은 상품 자체를 늘리는 기능이 아니라, 하나의 상품을 여러 선택 조합으로 ‘분기’시키는 기능입니다.

이 개념이 직관적으로 느껴지는 대표 사례들이 있습니다. 패션 상품을 생각해보시면 티셔츠라는 상품이 하나 있습니다. 하지만 실제 판매는 색상이라는 선택이 붙고, 그 다음 사이즈라는 선택이 붙습니다. 화이트/블랙이 있고, S/M/L이 있습니다. 그러면 상품이 늘어난 게 아니라 “티셔츠”라는 상품을 구매할 때 선택해야 할 변수가 생긴 것입니다.
식음료에서도 동일합니다. 햄버거 세트라는 상품이 있다고 해서 끝이 아닙니다. 단품으로 먹을지 세트로 먹을지 선택이 생기고, 세트라면 감자 변경, 음료 변경 같은 옵션이 따라붙습니다. 숙박 같은 서비스에서는 룸 타입이 옵션이 되고, 거기에 조식 포함 여부 같은 추가 선택이 붙을 수 있습니다.

여기서 현업에서 정말 자주 나오는 질문이 하나 있습니다. “그럼 이건 상품이 여러 개인 건가요?”라는 질문입니다. 이 질문에 대한 답은 분명합니다. 아닙니다. 상품은 하나고, 옵션이 여러 개입니다. 이 구분이 명확하지 않으면, 이후 화면 설계와 데이터 구조가 계속 흔들리게 됩니다.

 

상품 옵션 관리의 기본 원칙 - 기본값은 ‘옵션 없음’이고, 필요할 때만 추가한다

옵션 관리가 복잡해 보이지만, 출발점은 매우 단순합니다. 모든 상품의 기본 상태는 “옵션 없음”입니다. 즉, 상품이 1개 존재하고, 옵션은 없으며, 가격과 재고도 단일 값으로 관리되는 상태가 기본값입니다. 옵션은 처음부터 붙이는 것이 아니라, 정말 필요할 때만 추가하는 방식으로 가는 것이 일반적입니다.

이 기본값이 중요한 이유는, 옵션을 붙이는 순간 관리 단위가 쪼개지기 때문입니다. 옵션이 없을 때는 재고 100이면 끝납니다. 그런데 옵션이 붙으면 “재고 100”이라는 표현이 더 이상 의미가 없어집니다. 어떤 옵션 조합의 재고가 몇 개인지를 따로 관리해야 합니다. 그러니 옵션은 항상 “기본 상태를 깨는 예외”로 인식하고, 정말 필요한 상품에만 적용하는 것이 운영적으로도 안정적입니다.

 

옵션은 상세에서 만드는 것이 아니라 별도의 옵션 관리 메뉴에서 정의하고, 상품은 ‘가져다 쓴다’

여기서 실무에서 가장 많이 실수하는 지점이 나옵니다. 많은 기획자가 처음 옵션 설계를 접할 때, “상품 상세 페이지에서 옵션을 직접 만들면 편하지 않을까?”라고 생각합니다. 하지만 이 방식은 구조적으로 불안정해지기 쉽습니다. 그래서 일반적이고 안정적인 구조는 반대로 갑니다. 옵션을 상품 상세에서 생성하지 않고, 옵션 관리 메뉴를 별도로 두고, 상품에서 가져다 쓰는 구조가 표준에 가깝습니다.

상품 상세 페이지에서 옵션을 만드는 것이 아니라, 옵션 관리가 따로 있고 옵션 A, 옵션 B 같은 유형이 미리 정의되어 있으며, 상품 등록할 때 “옵션을 쓸 거면 어떤 걸 쓸 거야?”라고 선택해서 설정해 가져오는 방식입니다. 즉, 상품 화면이 하는 일은 “옵션을 만든다”가 아니라 “옵션을 선택한다”입니다. 이 차이를 명확히 구분해 두면, 나중에 주문과 재고가 얽힐 때 구조가 훨씬 안정적으로 유지됩니다.

 

옵션 관리 메뉴를 분리하는 이유

옵션 관리 메뉴를 분리하는 이유는 단순히 화면을 깔끔하게 하기 위해서가 아닙니다. 구조적 이유와 데이터 관점의 이유가 동시에 있습니다.

먼저 구조적으로 옵션은 특정 상품만의 속성이 아닙니다. 옵션은 상품에서도 쓰이지만, 주문에서도 쓰입니다. 재고 관리에서도 쓰이고, 경우에 따라 회원 혜택이나 등급과도 연결될 수 있습니다. 즉 옵션은 상품 화면 안에서만 의미가 있는 데이터가 아니라, 시스템 곳곳에서 재사용되는 데이터입니다. “데이터 관점에서도 이 기능이 꼭 상품만 쓰이는 게 아니라 다른 회원도 필요하고 주문도 필요할 것 같은데, 상품에 묶여 있다 보면 다른 거 적용했을 때 문제가 생길 수 있으니까 별도로 공통으로 만들어 놓는 것”이라는 관점이 바로 이 지점입니다. 옵션을 상품 하위에 묶어버리면 다른 상품에서 재사용이 어렵고, 주문 데이터와 연결될 때 구조가 복잡해지며, 확장 시 리팩토링 비용이 급격히 올라갑니다.

그리고 여기에는 개발 현실이 함께 붙습니다. 개발은 한 번 만들어지면 지속성이 있고 변경하기 어렵습니다. 설계서를 바탕으로 구현이 시작되면, 이후에는 구조 변경이 쉽지 않습니다. 그래서 기획 단계에서 “가능하면 하나의 기능은 독립적으로 만든다”라는 원칙을 적용할 수 있으면, 정보 구조나 화면 설계를 훨씬 개발 친화적으로 만들 수 있습니다. 데이터 구조를 깊게 몰라도 설계는 가능하지만, 이 원칙을 알고 적용하면 훨씬 유리해진다는 것도, 이 맥락입니다.

 

일반적인 옵션 관리 구조 - ‘옵션 그룹’, ‘옵션 값’, ‘옵션 유형’을 먼저 정의한다

옵션 관리 메뉴에서 실제로 무엇을 정의하느냐도 중요합니다. 일반적인 구조에서는 먼저 옵션 그룹을 정의합니다. 예를 들어 색상, 사이즈 같은 것이 옵션 그룹이 됩니다. 그리고 각 그룹 안에 옵션 값을 정의합니다. 색상이라면 화이트, 블랙이 값이 되고, 사이즈라면 S, M, L이 값이 됩니다.
그리고 여기서 옵션 유형이 따라옵니다. 옵션이 단일로만 선택되는 구조인지, 아니면 조합(색상×사이즈)처럼 결합되는 구조인지가 달라집니다. 이렇게 정의해 둔 옵션들이 목록 형태로 관리되고, 운영자는 필요할 때 수정하거나 추가할 수 있습니다.

그 다음 상품 등록/수정 화면에서는 “이 상품에 옵션을 사용할 건가?”를 먼저 결정하고, 옵션을 사용한다면 “어떤 옵션 그룹을 사용할 건가?”를 선택해 불러오는 방식으로 연결됩니다.  여기서 상품이 하는 것은 옵션 생성이 아니라 옵션 선택입니다. 이 구분이 유지되어야 구조가 안정적입니다.

 

옵션을 쓰면 재고도 옵션 기준으로 쪼개진다

옵션을 쓰는 순간 재고 단위가 옵션 기준으로 쪼개집니다. 옵션이 없는 티셔츠라면 재고 100으로 끝납니다. 그런데 색상과 사이즈 옵션이 붙으면, 재고는 화이트 S, 화이트 M, 블랙 S, 블랙 M처럼 조합 단위로 나뉩니다. 즉, 하나의 상품이 “여러 판매 단위”로 분해되고, 그 각각이 독립된 재고를 가지게 됩니다.
그래서 옵션 관리에는 보통 옵션별 재고와 옵션별 사용 여부 같은 설정이 함께 따라옵니다. 운영자는 “이 조합은 품절 처리해야 한다”, “이 옵션은 더 이상 사용하지 않는다” 같은 결정을 옵션 단위로 내려야 하기 때문입니다.

 

옵션을 과하게 만드는 경우에 대한 판단

현업에서는 옵션을 필요 이상으로 복잡하게 만들지 않으려 합니다. 이유는 관리 난이도가 급격히 올라가기 때문입니다. 일반적으로 가장 자주 쓰는 패턴은 패션에서는 색상과 사이즈, 신발은 사이즈 수치, 식음료는 단품/세트 정도입니다. 이론적으로는 색상×사이즈×재질×원산지처럼 계속 곱해서 옵션을 만들 수도 있지만, 실제로는 그렇게 복잡한 옵션을 만드는 경우가 드뭅니다. 옵션이 늘어날수록 조합 수가 폭발하고, 그만큼 재고 관리와 주문 처리, 운영 실수가 기하급수적으로 증가합니다. 그래서 옵션 설계에서는 “가능한 조합 수가 운영이 감당 가능한가”라는 감각이 중요해집니다.

 

상품 등록 중 “옵션이 없어서 바로 추가하고 싶다”는 문제

실무에서는 상품 등록을 하다가 이런 상황이 자주 생깁니다. “아, 이 옵션이 필요한데 목록에 없네?” 이때 선택지가 두 가지처럼 보입니다.

첫 번째는 상품 화면에서 바로 추가하는 방식입니다. 당장은 편해 보일 수 있습니다. 하지만 이 방식은 상품과 옵션의 경계를 무너뜨리고 구조를 깨뜨립니다. 옵션이 공통 데이터라는 원칙이 흔들리면, 결국 옵션이 여기저기 흩어지고 재사용이 불가능해지며, 나중에는 정리할 수 없는 형태로 누적됩니다.

두 번째는 옵션 관리 메뉴로 이동해서 전용 화면에서 옵션을 추가한 뒤, 다시 상품 화면으로 돌아와 선택하는 방식입니다. 이 방식이 구조적으로 옳습니다. 왜냐하면 옵션은 공통 데이터이기 때문에, 생성은 전용 메뉴에서만 이루어지고 상품에서는 선택만 하는 원칙이 유지되어야 하기 때문입니다. 이 방식이 “지금은 번거롭지만, 전체 구조를 지키는 방식”입니다.

 

“옵션은 공통 기능으로 만든다”는 원칙

여기서 기획자에게 가장 중요한 인사이트가 다시 한 번 반복됩니다. 하나의 기능은 가능하면 독립적으로 만든다는 원칙입니다. 옵션은 상품에서 쓰이고, 주문에서 쓰이고, 재고에서 쓰이고, 통계에서도 쓰일 수 있습니다. 그러니 옵션은 상품에 묶지 않고, 옵션 관리라는 독립 기능으로 만들어야 합니다. 이 관점이 잡히면, 옵션 관리 메뉴를 별도로 분리하는 설계가 “괜히 화면을 늘리는 것”이 아니라 “데이터의 재사용성과 시스템 확장성을 확보하는 것”이라는 의미로 보이기 시작합니다. 그래서 이 방식으로 옵션 관리를 설계하면, 회장님이 적어두신 표현처럼 “중급 이상 기획자 티가 난다”는 말이 자연스럽게 성립합니다.

 

개발 관점에서 옵션 관리가 까다로운 이유

옵션 관리는 개발 입장에서도 까다로운 영역입니다. 데이터 구조가 복잡하고, 이후 변경 비용이 크며, 한 번 잘못 만들면 되돌리기 어렵습니다. 그래서 기획 단계에서 “이 기능이 중복되는 것 같은데?”, “이건 합쳐야 하지 않을까?” 같은 감각을 느끼는 것이 중요합니다. 옵션이 여러 영역에서 쓰인다는 사실을 알고 있으면, 기능을 어디에 붙여야 하는지, 어디에서 정의해야 하는지 판단이 달라지기 때문입니다. 데이터 구조를 몰라도 설계는 가능하지만, 원칙을 알고 있으면 훨씬 유리합니다. 특히 “하나의 기능은 최대한 독립적으로 설계한다”는 원칙 하나만 지켜도 정보 구조가 정돈되고, 화면 설계가 개발 친화적으로 바뀌며, 개발팀과의 커뮤니케이션이 쉬워집니다. 결국 옵션 관리는 이 원칙을 가장 강하게 체감하게 해주는 대표 사례입니다.

정리하면, 상품 옵션은 상품의 하위 기능이 아니라 여러 영역에서 재사용되는 공통 기능입니다. 상품을 쪼개는 기능이지만, 그 영향은 상품 화면에만 머무르지 않고 주문과 재고, 운영 정책까지 이어집니다. 그래서 옵션 관리는 상품 상세에서 즉흥적으로 만드는 것이 아니라, 옵션 관리라는 독립된 기능으로 한 번 정의해 두고, 상품에서는 그것을 선택해 가져다 쓰는 구조로 설계하는 것이 안정적입니다.