개발을 시작할 때 가장 많이 듣는 말 중 하나가 이거죠:
“ERD부터 잘 짜야 한다!” 😤
하지만… 도메인 지식은 머릿속에 뭉개져 있고, ERD는 어떻게 그려야 할지 감도 안 잡히는 경우가 많아요. 오늘은 도메인 지식에서 시작해서 제대로 된 ERD(Entity Relationship Diagram)로 발전시키는 방법을 차근차근 정리해볼게요!
등장 배경
과거에는 DB 설계 없이 바로 코딩부터 시작하는 경우도 많았어요. 하지만 규모가 커지고, 협업이 중요해지면서 시작 전에 구조를 제대로 설계하는 것의 중요성이 커졌습니다.
도메인 전문가(기획자, 마케터, 운영자 등)가 알고 있는 현실 세계의 룰을 데이터 모델로 변환하는 것이 핵심인데요, 그 접점이 바로 ERD입니다.
도메인 지식 → ERD: 우리가 해결하고 싶은 문제들
비즈니스 규칙이 명확하지 않다
- 도메인 지식을 구체화하지 않으면 애매한 설계가 됩니다.
데이터 중복과 정합성 문제
- 잘못된 테이블 관계는 나중에 데이터 일관성을 해칩니다.
확장성 부족
- 처음엔 괜찮지만, 나중에 요구사항이 바뀌면 설계를 갈아엎어야 해요 😱
핵심 원리
1. 도메인 개념 파악 - ‘명사’를 찾아라!
ex) "고객이 상품을 주문한다" → 고객, 상품, 주문 = 테이블 후보도메인 시나리오나 요구사항 문서를 보며 명사를 추출합니다.
이를 통해 주요 엔티티(Entity)를 뽑아내요.
2. 관계 정리 - ‘동사’를 파악하자!
ex) "고객이 상품을 주문한다" → 고객 - 주문 - 상품명사들 간에 어떤 관계(Relationship)가 있는지 정리합니다.
1:1, 1:N, N:M 관계를 정의하고, N:M은 중간 테이블로 풀어줘야 해요.
3. 속성 추가 - 테이블 구조 완성
고객 테이블: id, 이름, 이메일, 가입일
상품 테이블: id, 이름, 가격, 재고각 엔티티가 가진 속성(Attribute)을 정리합니다.
어떤 값이 고유해야 하는지 (PK), 참조를 해야 하는지 (FK), 중복되면 안 되는지 (Unique) 등을 고려해요.
사례 소개: 간단한 이커머스 ERD 설계하기
🛒 도메인 시나리오
고객은 여러 개의 주문을 한다.
각 주문에는 여러 개의 상품이 들어간다.
상품은 재고가 있어야 한다.
👀 추출한 엔티티
고객(Customer)
주문(Order)
상품(Product)
주문 상세(OrderItem)
🧱 ERD 예시
[Customer]
- id (PK)
- name
- email
[Order]
- id (PK)
- customer_id (FK)
- order_date
[Product]
- id (PK)
- name
- price
- stock
[OrderItem] ← 주문과 상품의 N:M 관계 해소용
- id (PK)
- order_id (FK)
- product_id (FK)
- quantity🧩 시각적 관계 정리:
| 테이블 | 관계 |
|---|---|
| Customer - Order | 1:N (한 명의 고객은 여러 주문 가능) |
| Order - OrderItem | 1:N (하나의 주문에 여러 아이템) |
| Product - OrderItem | 1:N (상품이 여러 주문에 포함 가능) |
주의사항 및 팁 💡
⚠️ 이것만은 주의하세요!
도메인을 충분히 이해하지 않고 ERD부터 그리면 나중에 엉망이 됩니다.
- 기획자/PM과 대화를 많이 하세요!
ERD는 완전한 정답이 없어요. 같은 도메인도 목적에 따라 설계가 달라질 수 있습니다.
- 너무 이론적으로만 접근하지 말고, 실무 시나리오에 맞춰 조율하세요.
💡 꿀팁
모델링 전, 시나리오 문장으로 먼저 관계 그리기 추천!
ERD 툴 추천: dbdiagram.io, ERDCloud, Draw.io, MySQL Workbench
협업 시엔 ERD 리뷰 회의도 꼭 해보세요!
마치며
도메인 지식에서 시작해 ERD를 설계하는 과정은 언어를 데이터 구조로 번역하는 작업이에요. 이 과정이 탄탄해야 나중에 API 설계, DB 쿼리, 기능 개발이 모두 쉬워진답니다!
여러분은 어떤 도메인을 설계하고 계신가요? 같이 ERD 그려볼까요? 😊
참고 자료 🔖
#ERD #도메인모델링 #데이터베이스설계