데이터 베이스/설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴

Ch07. 동적 설계 EAV - 기존 방식의 한계와 새로운 접근법

webmaster 2026. 7. 27. 21:38

상속 관계 설계의 한계

상속 관계 설계는 엔티티 간의 계층 구조를 표현하는 좋은 방법이다. 하지만 다음과 같은 상황에서는 상속 관계만으로 해결하기 어려운 문제가 발생한다.

 

문제 상황 - 끊임없이 늘어나는 상품 속성

쇼핑몰에서 다양한 카테고리의 상품을 판매한다고 가정해보자. 처음에는 의류, 전자제품, 도서 3가지 카테고리만 있었다. 참고로 각 카테고리는 서로 다른 고유의 속성을 가진다고 가정하겠다.

 

이 구조는 처음에는 잘 작동한다. 하지만 시간이 지나면서 문제가 발생하기 시작한다.

 

첫 번째 문제 - 카테고리 폭발

  • 사업이 성장하면서 카테고리가 점점 늘어난다.
  • 가구, 식품, 스포츠용품, 화장품, 주방용품, 반려동물용품, 자동차용품 ...
  • 6개월 후에는 50개의 카테고리가 생겼다.
  • 1년 후에는 200개의 카테고리가 되었다.

카테고리가 늘어날 때마다 새로운 서브타입 테이블을 만들어야 한다. 200개의 카테고리라면 200개의 서브타입 테이블이 필요하다. 이것은 관리가 거의 불가능하다.

 

두 번째 문제 - 동적 속성 변경

  • 카테고리별로 필요한 속성이 계속 변경된다.
  • 의류에 "세탁 방법", "원산지", "시즌" 속성이 추가되어야 한다.
  • 전자제품에 "에너지 효율 등급", "KC 인증번호"가 추가되어야 한다.
  • 운영팀에서 매주 새로운 속성 추가를 요청한다.

속성이 추가될 때마다 "ALTER TABLE"로 컬럼을 추가해야 한다. 운영 중인 시스템에서 테이블 구조를 자주 변경하는 것은 위험하고 번거롭다.

 

세 번째 문제 - 예측 불가능한 속성

  • 어떤 카테고리에는 완전히 예상치 못한 속성이 필요하다.
  • 와인: 빈티지, 포도 품종, 와이너리, 알코올 도수, 음용 온도, 디캔팅 시간 ...
  • 캠핑 용품: 수용 인원, 방수 등급, 무게, 설치 시간, 시즌 적합성 ...
  • 악기: 조율 방식, 음역대, 재질, 제조 국가, 연주 난이도...

각 카테고리마다 전혀 다른 종류와 개수의 속성이 필요하다. 이런 속성들을 미리 예측해서 테이블 구조로 설계하는 것은 거의 불가능하다.

 

네 번째 문제 - 셀러마다 다른 속성

  • 오픈마켓처럼 여러 셀러가 상품을 등록하는 경우를 생각해보자.
  • 셀러 A는 휴대폰을 팔면서 "화면 크기", "배터리 용량", "카메라 화소"를 입력하고 싶다.
  • 셀러 B는 같은 휴대폰이지만 "5G 지원여부", "듀얼심 여부", "방수 등급"을 입력하고 싶다.
  • 셀러 C는 "색상 옵션", "저장 용량 옵션", "번들 구성"을 입력하고 싶다

같은 카테고리라도 셀러마다 다른 속성을 입력하고 싶어한다. 모든 셀러의 요구사항을 테이블 컬럼으로 미리 정의해두는 것은 현실적으로 불가능하다.

상속 관계가 적합한 경우 vs 적합하지 않은 경우

상속 관계가 적합한 경우

  • 서브타입의 종류가 명확하고 제한적이다 (예: 결제수단 - 카드/계좌이체/가상계좌)
  • 각 서브타입의 속성이 안정적이고 자주 변경되지 않는다
  • 서브타입별 속성에 대한 제약조건(NOT NULL, 타입검증 등)이 중요하다
  • 서브타입별로 복잡한 조인이나 조회가 자주 필요하다

상속 관계가 적합하지 않은 경우

  • 서브타입(카테고리)이 계속 늘어날 수 있다
  • 속성이 동적으로 추가, 수정, 삭제되어야 한다
  • 카테고리별로 필요한 속성을 미리 예측하기 어렵다
  • 사용자(셀러, 관리자 등)가 직접 속성을 정의해야 한다
  • 유연성이 데이터 무결성보다 더 중요하다