백오피스 화면설계 심화 (7)

백오피스 상품 옵션 관리 화면 설계

1. 상품 옵션 관리의 개념부터 정리

- 상품 옵션은 상품을 더 잘게 쪼개는 수단이다.

상품이 하나라도,
판매 단위는 여러 개가 될 수 있다.

1.1 대표적인 옵션 사례

• 패션
  • 티셔츠
    → 색상(화이트/블랙)
    → 사이즈(S/M/L)
• 식음료
  • 햄버거 세트
    → 단품 / 세트
    → 감자 변경 / 음료 변경
• 서비스
  • 숙박
    → 룸 타입
    → 조식 포함 여부

이때 중요한 질문이 생긴다.

“이건 상품이 여러 개인 건가요?”
→ 아니다. 상품은 하나고, 옵션이 여러 개다.

 

2. 상품 옵션 관리의 기본 원칙

2.1 기본값은 “옵션 없음”

모든 상품의 기본 상태는 다음이다.

• 상품 1개
• 옵션 없음
• 단일 가격 / 단일 재고

옵션은 필요할 때만 추가한다.

 

2.2 옵션은 상품 상세에서 만드는 것이 아니다

실무에서 많이 실수하는 지점이 있다.

❌ 상품 상세 페이지에서 옵션을 직접 생성
⭕ 옵션 관리 메뉴를 별도로 두고, 상품에서 “가져다 쓰는 구조”

이게 일반적이고, 안정적인 구조다.

 

상품 상세 페이지에서 옵션을 만드는 것이 아니라 옵션 관리가 따로 있고
옵션 a 옵션 b 같은 유형이 있고 상품 등록할 때 옵션을 쓸 거면 어떤 걸 쓸 거야라고 해서
설정해서 가져오는 거죠.

 

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

3.1 구조적 이유

옵션은 특정 상품만의 속성이 아니다.

• 상품에서도 쓰인다
• 주문에서도 쓰인다
• 재고 관리에서도 쓰인다
• 경우에 따라 회원 혜택/등급과도 연결된다

👉 상품에 종속되면 재사용이 불가능해진다.

데이터 관점에서도 이 기능이 꼭 상품만 쓰이는 게 아니라 다른 회원도 필요하고 주문도 필요할 것 같은데
상품에 묶여 있다 보게 되면 다른 거 적용했을 때 문제가 생길 수 있으니까
별도로 공통으로 만들어 놓는 거죠. 한 번만 쓸 수 있게

 

3.2 데이터 관점에서의 이유

옵션을 상품 하위에 묶어버리면:

• 다른 상품에서 재사용 불가
• 주문 데이터와 연결 시 구조 복잡
• 확장 시 리팩토링 비용 증가

그래서 옵션은:

공통 데이터로 분리해서, 한 번 정의하고 여러 곳에서 사용하는 게 맞다.

 

 

개발은 한 번 만들어지면 지속성이 있고 변경하기 어렵죠.
그러니까 설계서를 바탕으로 해서 짤 때 명확하게 한 번 원칙을 정하고
그 이후부터는 이제 변경할 수가 없는 구조가 더 많죠.

그래서 정보 구조 만드실 때나 반스럽게 만드실 때 고려 사항이긴 한데 이걸 데이터적으로 몰라도 할 수 있어요.
근데 알면 더 좋겠지만 가능한 하나의 기능은 독립적으로 만든다라고 하는 원칙을 적용하실 수 있으면은
정보 구조나 화면 설계를 하실 때 좀 더 유리한 방식으로 개발 친화적으로 하실 수 있을 것 같아요.

 

4. 일반적인 옵션 관리 구조

4.1 옵션 관리 메뉴

옵션 관리 메뉴에서는 다음을 정의한다.

• 옵션 그룹 (예: 색상, 사이즈)
• 옵션 값 (화이트, 블랙 / S, M, L)
• 옵션 유형 (단일 / 조합)

이렇게 만들어 둔 옵션들이
목록 형태로 관리된다.

 

4.2 상품 등록 시 옵션 연결

상품 등록/수정 시에는:

• “이 상품에 옵션을 사용할 건가?”
• “어떤 옵션 그룹을 사용할 건가?”

를 선택해서 불러오는 방식이다.

즉,

• 옵션 생성 ❌ (상품 화면에서)
• 옵션 선택 ⭕️ (옵션 관리에서 만든 것 중)

 

5. 옵션 재고 관리

옵션을 사용하면
재고 단위도 옵션 기준으로 쪼개진다.

예:

• 티셔츠 (옵션 없음)
  • 재고 100

vs

• 티셔츠 (색상 + 사이즈)
  • 화이트 S: 10
  • 화이트 M: 20
  • 블랙 S: 15
  • 블랙 M: 5

그래서 옵션 관리에는 보통:

• 옵션별 재고
• 옵션별 사용 여부

같은 설정이 함께 따라온다.

 

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

현업에서는 옵션을
필요 이상으로 복잡하게 만들지 않는다.

일반적인 패턴은 다음 정도다.

• 패션
  • 색상
  • 사이즈
• 신발
  • 사이즈(수치)
• 식음료
  • 단품 / 세트

옵션을:

• 색상 × 사이즈 × 재질 × 원산지
  처럼 과도하게 만드는 경우는 드물다.

👉 관리 난이도가 급격히 올라가기 때문이다.

 

7. “옵션이 없을 때 바로 추가하고 싶다” 문제

상품 등록 중에 이런 상황이 생긴다.

“아, 이 옵션이 필요한데 목록에 없네?”

이때 선택지는 두 가지다.

7.1 상품 화면에서 바로 추가

• 편해 보이지만 ❌
• 상품과 옵션의 경계가 무너진다
• 구조가 깨진다

 

7.2 옵션 관리 메뉴로 이동

• 옵션 관리 전용 화면에서 추가
• 다시 상품 화면으로 돌아와 선택

👉 이 방식이 구조적으로 옳다.

옵션은 공통 데이터이기 때문에
전용 메뉴에서만 생성하는 것이 맞다.

 

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

이 부분이 기획자에게 중요한 인사이트다.

하나의 기능은
가능하면 독립적으로 만든다.

옵션은:

• 상품에서 쓰이고
• 주문에서 쓰이고
• 재고에서 쓰이고
• 통계에서도 쓰일 수 있다

그래서:

• 상품에 묶지 않는다
• 옵션 관리라는 독립된 기능으로 만든다.

 

9. 개발 관점에서의 난이도

옵션 관리는
개발 입장에서 매우 까다로운 영역이다.

이유는 간단하다.

• 데이터 구조 복잡
• 이후 변경 비용 큼
• 한 번 잘못 만들면 되돌리기 어려움

그래서 기획 단계에서:

• “이 기능이 중복되는 것 같은데?”
• “이건 합쳐야 하지 않을까?”

라는 감각을 느끼는 게 중요하다.

 

10. 기획자가 알아야 할 현실적인 포인트

• 데이터 구조를 몰라도 설계는 가능하다
• 하지만 원칙을 알면 훨씬 유리하다

특히 이 원칙은 중요하다.

“하나의 기능은 최대한 독립적으로 설계한다.”

이 원칙만 지켜도:

• 정보 구조가 정돈되고
• 화면 설계가 개발 친화적으로 바뀌고
• 개발팀과의 커뮤니케이션이 쉬워진다

 

 

정리하자면

상품 옵션은
상품의 하위 기능이 아니라 여러 영역에서 재사용되는 공통 기능이다.

 

이 관점으로 옵션 관리를 설계하면
중급 이상 기획자 티가 난다.