상품 도메인 구조 설계와 인덱스 최적화로 성능 개선

3월에 상품 도메인 작업을 시작했다. 회원 다음은 상품이 자연스러운 순서였다. 카테고리-상품-옵션-재고. 이 관계를 어떻게 잡느냐가 핵심이었다.

상품 구조의 복잡도

상품 하나에 옵션이 붙고, 옵션 조합마다 가격이 다를 수 있고, 재고가 옵션 단위로 관리되어야 한다. 단순해 보이는데 테이블이 생각보다 많아졌다. product, product_option, product_option_item, product_stock. 이 관계를 잘못 잡으면 나중에 전부 뒤엎어야 한다.

회사에서 비슷한 구조를 직접 보진 못했지만, 레거시 코드를 분석하면서 얻은 감각이 있었다. 어느 수준까지 정규화를 하고 어느 수준에서 실용성을 택하느냐의 감각. 과도한 정규화는 조회 쿼리를 복잡하게 만든다.

설계 결정사항

• 카테고리 계층: depth 2로 제한 (과도한 재귀 회피)
• 상품-옵션 관계: 1:N 방식으로 단순화
• 재고 단위: 옵션 아이템 기준
• 가격 관리: 옵션별 추가금액 방식

회사에서는 마침 성능 이슈 하나를 잡았다. 조회 쿼리에 인덱스가 없어서 Full scan이 돌던 것. 인덱스 하나로 응답이 확 달라지는 걸 다시 한번 확인했다. 이런 경험들이 사이드 설계에 스며든다. 처음부터 인덱스를 고려해서 테이블을 만들게 됐다.

4월엔 주문 플로우로 넘어갈 예정이었다.

상품 도메인을 설계하면서 도메인 모델링이 얼마나 중요한지를 다시 느꼈다. 테이블 구조가 잘못 잡히면 조회 쿼리가 복잡해지고, 복잡한 쿼리는 성능 문제로 이어진다. 처음에 제대로 설계하는 시간이 나중에 리팩터링 시간을 아껴준다.