실무 데이터 모델링: Entity 설계의 핵심 노하우

데이터 모델링의 첫 단계인 엔터티 설계의 핵심 원리와 실무 적용 방법을 단계별로 정리해보겠습니다.
이론적 지식을 넘어 현장에서 바로 활용할 수 있는 실무 노하우를 중심으로 다뤄보려고 합니다.

1단계: Entity 분류 - 우선순위 기반 설계 전략

왜 엔터티를 분류해야 할까?

데이터 모델링에서 가장 먼저 해야 할 일은 엔터티의 우선순위를 정하는 것입니다. 실무 프로젝트에서 수백 개의 엔터티가 도출되는 상황에서 모든 엔터티를 동시에 설계할 수는 없기 때문입니다. 마치 건축에서 기둥을 먼저 세우고 벽을 쌓는 것처럼, 데이터 모델링도 핵심이 되는 엔터티부터 차근차근 설계해야 합니다.

엔터티 3단계 분류법

① Key 엔터티 (핵심의 핵심)

• 정의: 데이터를 발생시키는 행위의 주체나 목적어로, 부모 엔터티를 갖지 않는 최상위 개념
• 특징: 독립적으로 존재하며, 다른 엔터티들의 기반이 되는 마스터 데이터
• 온라인 쇼핑몰 예시:
  고객 (Customer): 모든 거래의 주체
  상품 (Product): 판매하는 모든 상품 정보
  카테고리 (Category): 상품 분류의 기준
  직원 (Employee): 시스템 운영 주체

② Main 엔터티 (비즈니스의 중심)

• 정의: Key 엔터티로부터 파생되지만 비즈니스 프로세스의 중심 역할을 담당하며, 많은 하위 엔터티를 생성
• 특징: 업무의 핵심 트랜잭션을 담당하고, 데이터 발생량이 많음
• 온라인 쇼핑몰 예시:
  주문 (Order): 고객의 구매 요청
  장바구니 (Cart): 구매 전 상품 임시 보관
  결제 (Payment): 거래 완료 처리
  배송 (Shipment): 상품 전달 과정
• 카페 체인점 예시:
  매장 (Store): 각 지점 정보
  메뉴 (Menu): 판매 상품 관리
  주문서 (OrderForm): 고객 주문 접수

③ Action 엔터티 (세부 실행 단위)

• 정의: Key와 Main 엔터티에서 파생되어 구체적인 업무 행위나 이벤트를 담당
• 특징: 주로 거래 상세, 이력, 로그 데이터를 관리하며 데이터 변경이 빈번함
• 온라인 쇼핑몰 예시:
  주문상세 (OrderDetail): 주문한 개별 상품 정보
  결제이력 (PaymentHistory): 결제 처리 과정 추적
  배송추적 (DeliveryTracking): 배송 단계별 상태 변화
  상품리뷰 (ProductReview): 구매 후 고객 평가
  쿠폰사용이력 (CouponUsageHistory): 할인 적용 내역

실무에서의 핵심 엔터티 비율과 적용 전략

프로젝트 현장에서 고객사로부터 자주 받는 질문이 있습니다.
"핵심 엔터티의 비율이 보통 어느 정도 되나요?"

업계 별로, 사이트 별로 다르겠지만 다년간의 프로젝트 경험상의 황금 비율은 10~30개 정도 인 것 같습니다. 비율이 너무 높으면 세분화가 부족하고, 너무 낮으면 과도하게 복잡하게 설계했을 가능성이 있습니다.

[실무 적용 시나리오 간단 예제 : 은행 시스템]

Key 엔터티:

• 고객(Customer), 직원(Employee), 상품(Product), 지점(Branch)

Main 엔터티:

• 계좌(Account) ← 고객+상품에서 파생
• 대출(Loan) ← 고객+상품에서 파생
• 거래(Transaction) ← 계좌에서 파생

Action 엔터티:

• 거래내역(TransactionHistory) ← 거래에서 파생
• 대출상환내역(LoanRepaymentHistory) ← 대출에서 파생
• 고객상담내역(CustomerConsultationHistory) ← 고객+직원에서 파생

CRUD 매트릭스를 통한 엔터티 검증
엔터티 분류가 끝나면 CRUD 매트릭스를 활용하여 분류의 적절성을 검증합니다.

Create: 어떤 업무 기능에서 이 엔터티를 생성하는가?
Read: 어떤 화면/보고서에서 이 엔터티를 조회하는가?
Update: 어떤 업무에서 이 엔터티를 수정하는가?
Delete: 어떤 상황에서 이 엔터티를 삭제하는가?

Key 엔터티의 경우: Read 빈도가 높고, Create/Update는 상대적으로 적어야 함
Action 엔터티의 경우: Create 빈도가 높고, Update/Delete는 제한적이어야 함

https://www.youtube.com/watch?v=lRfHJm--H0Q

엔터티 분류의 부수적 효과
우선순위 선별이 주목적이지만, 분류 과정에서 얻을 수 있는 추가적인 가치들

• 엔터티의 정체성 명확화: 각 엔터티의 역할과 중요도가 명확해짐
• 설계 순서 최적화: 의존 관계를 고려한 체계적인 설계 가능
• 팀 업무 분장: 핵심 엔터티는 시니어가, Action 엔터티는 주니어가 담당
• 개발 우선순위 결정: Key → Main → Action 순으로 개발 진행
• 테스트 시나리오 구성: 핵심 엔터티 중심의 통합 테스트 설계
• 실무 팁: Main과 Action 구분이 애매하다면 너무 많은 에너지를 쏟지 말고, 중요한 것부터 먼저 하는 목적에 집중하세요. 완벽한 분류보다는 실행 가능한 우선순위가 더 중요합니다.

2단계: Entity 자격 검증 - 진짜 엔터티인가?

① 집합의 순수성 검증: 관계 vs 엔터티

데이터 모델링에서 흔히 실수하는 부분이 관계를 엔터티로 착각하는 것입니다.
특히 업무에서 사용하는 용어가 명사 형태라고 해서 무조건 엔터티는 아닙니다.

실무 사례 분석: 피보험자의 정체

잘못된 접근:

• 엔터티명: 피보험자
• 속성: 피보험자ID, 성명, 생년월일, 보험가입일...
• 올바른 분석:
  "피보험": 보험의 보장을 받는 행위 (관계)
  "자": 그 행위의 대상인 사람 (개체)

결론: 피보험자 = 보험 + 고객 간의 관계
올바른 모델링:
보험(Insurance) ←→ 보험가입(InsuranceContract) ←→ 고객(Customer)

업무 용어의 함정들
실무에서 자주 마주치는 관계를 엔터티로 오해하기 쉬운 용어들:

금융권:
예금자 → 예금 + 고객의 관계
대출자 → 대출 + 고객의 관계
투자자 → 투자상품 + 고객의 관계

병원:
환자 → 의료서비스 + 고객의 관계 (단, 병원에서는 관습적으로 환자 엔터티 사용)
처방자 → 처방전 + 의사의 관계

교육기관:
수강생 → 강의 + 학생의 관계
강사 → 강의 + 교수의 관계

엔터티 순수성 검증 체크리스트
순수한 엔터티의 조건

• 단일 개념: 하나의 명확한 의미만 담고 있는가?
• 독립적 존재: 다른 엔터티와의 관계 없이도 의미가 있는가?
• 고유한 속성: 그 엔터티만의 고유한 특성들을 가지고 있는가?

② 집합의 동질성 결정: 통합 vs 분리

역사적 관점에서의 동질성 사례
예를 들어, 삼국시대 당나라가 고구려·백제·신라를 바라본다면
"한반도" 라는 하나의 엔터티로 관리했을 가능성이 있지 않을까 상상해봅니다.
같은 언어, 비슷한 문화라는 동질성 때문입니다.

실무에서의 동질성 판단 기준

• 통합이 유리한 경우
  고객 엔터티: 개인고객, 법인고객을 하나로 통합
  공통점: 이름, 연락처, 주소 등 기본 정보 구조 유사
  구분: 고객유형 코드로 구분
  통합의 장점:
  모델 단순화로 유지보수성 향상, 업무 규칙 변경 시 코드 값만 추가하면 됨, 통합 통계나 분석 작업 용이

• 분리가 유리한 경우:
  상품 엔터티: 물리적 상품 vs 디지털 상품
  물리적 상품: 재고, 무게, 크기 등 물리적 속성 필요
  디지털 상품: 다운로드 횟수, 라이선스 등 디지털 속성 필요
  분리의 장점:
  각 유형별 최적화된 속성 관리, 보안 정책 개별 적용 가능, 성능 튜닝의 유연성

실무 적용 Tips (통합 결정 가이드라인)

• 속성 중복도: 공통 속성이 70% 이상이면 통합 고려
• 업무 프로세스: 동일한 업무 프로세스를 거치는가?
• 확장성: 미래에 새로운 유형이 추가될 가능성은?
• 성능: 통합으로 인한 테이블 크기 증가가 성능에 미치는 영향은?

3단계: 엔터티 형태 결정 - 서브타입 활용법

데이터 통합의 두 가지 패턴

집합 통합 시 유의사항: 물과 기름의 법칙

바람직하지 않은 통합 (잉크 + 물):
고객 테이블에 개인고객과 법인고객을 구분 없이 섞어놓은 경우

• 개인: 주민등록번호, 생년월일
• 법인: 사업자등록번호, 설립일
  → NULL 값이 많아지고 데이터 의미가 모호해짐

이상적인 통합 (기름 + 물 + 용기):
고객 테이블 (슈퍼타입)
├── 개인고객 (서브타입)
└── 법인고객 (서브타입)
→ 함께 있으면서도 명확하게 구분됨

서브타입 설계 전략

전자상거래 주문 엔터티
주문유형
├── 일반주문 (서브타입)
├── 예약주문 (서브타입)
└── 정기주문 (서브타입)

• 서브타입 세트명: 주문유형
• 서브타입명: '일반', '예약', '정기'

서브타입 사용 시 명확한 장점들

1. 직관적 업무 규칙 표현
   → 한눈에 고객 구성과 각 유형별 특징 파악 가능

2. 개발 효율성 극대화
   개발자가 업무 로직을 구현할 때:
   컨디션 좋은 날🤗🥰: 업무 담당자에게 확인 후 정확한 구현 👍
   컨디션 나쁜 날🥱😴: 추정으로 구현 → 나중에 버그 발생 😣
   서브타입이 명확하게 정의되어 있으면 추정의 여지를 줄이고 정확한 구현 가능

3. 유지보수성 향상
   예: 새로운 고객 유형 추가 시
   서브타입 없는 경우: 테이블 구조 변경, 기존 코드 수정
   서브타입 있는 경우: 코드 값만 추가, 해당 서브타입 속성만 추가

이유와 근거

• ERD 복잡성: 거의 모든 테이블에 공통코드 관계를 표현하면 다이어그램이 읽기 어려워짐
• 의사소통 도구: ERD는 업무 규칙을 직관적으로 전달하는 도구여야 함
• 관계의 성격: 공통코드는 값 참조이지 업무적 관계가 아님
• 올바른 접근:
  고객 테이블: 고객상태코드(VARCHAR) → 'A01', 'A02', 'A03'
  공통코드 테이블: 코드값='A01', 코드명='정상'
  → ERD에는 관계선 표시하지 않음

[실무에서 자주 발생하는 개념 모호성]

잘못된 엔터티 정의 사례들:
고객: "우리 회사를 이용하는 사람" (기준 모호)

올바른 엔터티 정의 방법:
고객: "회원 가입을 완료하고 고객번호가 부여된 자. 탈퇴 후 1년 이내 고객 포함"

미지수를 상수로 만드는 과정 (개념 정립 실무 프로세스)

• 범위 명확화: 포함/제외 기준 명시
• 예외 상황 정의: 애매한 경우의 처리 방법
• 시점 기준 설정: 언제부터 언제까지의 데이터인가?
• 상태 변화 규칙: 상태가 변할 때의 처리 방법

*실무 팁:
익숙한 단어(학생, 교사, 고객)일수록 깊이 생각하지 않고 지나칠 위험이 있습니다. 이런 단어들을 만날 때마다 "정말 우리가 생각하는 그 의미가 맞나?" 한 번 더 되짚어보는 습관이 중요합니다. 엔터티 설계는 단순히 테이블을 만드는 작업이 아닙니다. 비즈니스 규칙을 데이터 구조로 번역하는 과정입니다.

성공적인 엔터티 설계를 위한 4단계
1. 명확한 개념 정립 → 미지수를 상수로 변환
2. 체계적인 분류 → 우선순위 기반의 효율적 설계
3. 엄격한 자격 검증 → 진짜 엔터티와 가짜 엔터티 구분
4. 효과적인 형태 결정 → 서브타입을 통한 입체적 표현

기억해야 할 핵심!

각 단계에서 실무 적용 가능성과 유지보수성을 항상 염두에 두어야 합니다.
특히 서브타입을 활용한 입체적 모델링은 개발자들이 업무 규칙을 명확하게 이해할 수 있도록 도와주어, 추정에 의한 구현을 줄이고 품질 높은 시스템 구축에 기여합니다. 완벽한 모델보다는 실무에서 활용 가능하고 지속적으로 진화할 수 있는 모델이 진정 가치 있는 모델입니다.

[참고] 실습 ERD Tool https://www.smatida.com/