ERD와 데이터베이스 설계에서 중요한 관점 정리

ERD(Entity-Relationship Diagram)는 데이터베이스에 들어갈 엔터티(테이블 후보)와 그 관계를 시각적으로 표현한 다이어그램이다. 좋은 ERD와 데이터베이스 설계는 서비스 기능 구현뿐 아니라, 변경·확장·성능·정합성까지 좌우하므로 백엔드 개발자에게 핵심 역량이다. 이 글에서는 ERD와 DB 설계에서 어떤 관점을 중요하게 봐야 하는지 정리한다.

1. ERD란 무엇인가

ERD는 시스템에 등장하는 엔터티(개체), 엔터티 간 관계, 각 엔터티의 속성을 도식화한 것이다.

• 엔터티(Entity) — 회원, 주문, 상품, 결제 같은 주요 객체
• 속성(Attribute) — 회원의 이름·이메일, 주문의 상태·금액 등
• 관계(Relationship) — 회원–주문(1:N), 주문–주문상품(N:1), 주문상품–상품(N:1) 등

코드에 테이블을 만들기 전에, ERD로 개념 모델을 그리고 나면 누락된 개념·이상한 관계·중복 구조를 초기에 발견하기 쉽다.

2. DB 설계에서 핵심이 되는 관점

1) 비즈니스 도메인과 용어 정리

ERD를 그릴 때 가장 중요한 것은 도메인 언어를 먼저 정리하는 것이다. \"회원\", \"이용자\", \"고객\"을 섞어 쓰면 혼란이 생긴다. 도메인 전문가·기획자와 같이 용어를 정리하고, ERD의 엔터티 이름·속성 이름에 이를 반영해야 한다.

2) 정규화와 비정규화의 균형

정규화는 중복을 줄이고 데이터 이상 현상(삽입·삭제·갱신 이상)을 막기 위해 테이블을 나누는 과정이다. 3정규형 정도까지는 기본적으로 고려하는 것이 좋다. 다만 성능·조회 패턴상 필요한 경우, 비정규화(중복 허용)도 전략적으로 사용할 수 있다.

• 정규화 — 데이터 정합성·유지보수성 향상, 중복 감소
• 비정규화 — 조인 횟수·복잡도 감소, 조회 성능 향상

중요한 것은 \"왜 이 테이블을 나누었는지\", \"왜 이 값을 중복 저장하는지\"를 ERD와 문서에 남겨 두는 것이다.

3) 키 설계 (PK, FK, 후보키)

기본 키(PK)는 각 행을 유일하게 식별하는 값이며, 외래 키(FK)는 다른 테이블의 PK를 참조해 관계를 표현한다. 자연키(주민번호, 이메일 등)를 그대로 PK로 쓰기보다는, 대리키(숫자 ID)를 PK로 두고 자연키에는 유니크 제약을 두는 설계가 유지보수에 유리한 경우가 많다.

• PK — 단일 또는 복합키, 변경 불필요한 값을 사용하는 것이 좋다.
• FK — 참조 무결성을 보장하고, 삭제·수정 시 ON DELETE/UPDATE 규칙을 명확히 한다.
• 후보키 — 유니크해야 하지만 PK로 쓰지 않은 키(이메일, 사용자명 등).

4) 조회 패턴과 인덱싱

ERD와 테이블 설계는 어떤 쿼리가 자주 나올지를 함께 고려해야 한다. ERD 단계에서 화면·API 요구사항을 보고, 목록·검색·집계에 자주 쓰이는 컬럼을 예상해 인덱스를 설계한다. PK/FK 외에도, 상태+날짜, 사용자+날짜 등의 조합 인덱스가 필요한지 검토한다.

3. ERD·DB 설계를 할 때 자주 놓치는 부분

1) 상태 값과 라이프사이클

주문, 결제, 계정 등의 상태 변화를 충분히 모델링하지 않으면, 나중에 상태 분기가 코드 곳곳에 흩어지고 이해하기 어려워진다. ERD 단계에서 상태 컬럼(예: status)과 가능한 값들, 상태 전이(예: 생성 → 결제완료 → 배송중 → 완료·취소)를 정리해 두는 것이 좋다.

2) 이력·감사 로그 테이블

금액·권한·설정처럼 중요한 값은 변경 이력이 필요하다. 단순히 현재 값만 갖는 테이블 외에, 변경 전후를 기록하는 이력 테이블(예: account_history, config_history 등)을 설계 단계에서 함께 고민해야 한다.

3) 식별자·코드 값의 규칙

외부에 노출되는 ID(주문번호, 거래번호, 티켓번호 등)는 내부 PK와 별개로 코드 규칙을 두는 경우가 많다. ERD 설계 시, 내부 PK와 외부용 코드 컬럼을 구분하고, 코드 생성 규칙을 문서에 남겨야 혼란을 줄일 수 있다.

4. ERD와 실제 테이블 설계의 연결

ERD는 개념 모델이라면, 실제 DB 스키마는 이를 구체화한 논리·물리 모델이다.

• ERD → 논리 모델 — 엔터티·관계를 기준으로 테이블·컬럼·키 정의
• 논리 모델 → 물리 모델 — DBMS(MySQL, PostgreSQL 등)별 타입, 인덱스, 제약 조건 반영

이 과정에서 \"DBMS 특화 기능\"(예: PostgreSQL의 JSONB, MySQL의 InnoDB 특성 등)을 어떻게 활용할지도 함께 고민해야 한다.

5. 왜 ERD·DB 설계 역량이 필수 덕목이 되었는가

서비스가 커질수록 데이터 구조가 장기 유지보수 비용을 결정한다. 초기에 ERD·DB 설계를 대충 넘어가면, 나중에 기능 추가·리포트·이관 작업에서 제약이 많아지고, 데이터 마이그레이션 비용이 커진다.

• 정합성 — 잘못 설계된 관계·키 구조는 데이터 불일치·중복을 초래한다.
• 확장성 — 테이블·관계 구조가 확장을 염두에 두지 않으면, 새 요구사항을 반영하기 위해 대규모 스키마 변경이 필요하다.
• 성능 — 비효율적인 설계는 조인·인덱스 활용을 어렵게 해, 트래픽 증가 시 병목으로 이어진다.
• 협업 — 명확한 ERD·스키마 문서가 없으면, 새 팀원이 도메인 이해에 많은 시간을 소모한다.

한 줄 요약

ERD는 엔터티·관계·속성을 시각화해 도메인을 정리하는 도구이고, 데이터베이스 설계는 정합성·확장성·성능·협업을 좌우하는 기반이다. 도메인 언어와 상태·키·이력·조회 패턴을 충분히 고민한 ERD·DB 설계 역량은, 장기적으로 서비스 품질과 유지보수 비용을 결정하는 필수 덕목이다.