ERD (Entity Relationship Diagram)
데이터 구조를 시각적으로 표현하는 설계 언어
0. ERD란 무엇인가?
ERD는 데이터베이스의 구조를 그림으로 표현한 것이다.
테이블이 무엇이고
각 테이블이 어떻게 연결되어 있으며
누가 누구를 참조하는지
를 한눈에 보여준다.
즉,
프로그램보다 먼저 만들어지는
데이터의 설계도
라고 보면 된다.
1. ERD를 왜 배우는가?
좋은 개발자는 코드를 보기 전에
ERD를 보면 시스템을 이해할 수 있다.
왜냐하면:
- 어떤 데이터가 핵심인지
- 어디서 수정이 발생하는지
- 어떤 흐름으로 업무가 움직이는지
구조 안에 이미 답이 있기 때문이다.
2. ERD의 기본 구성 요소
2-1. Entity (엔티티)
→ 테이블
업무에서 관리해야 하는 대상.
예:
- 수주
- 출하
- 거래처
- 제품
- 사용자
2-2. Attribute (속성)
→ 컬럼
엔티티가 가지고 있는 정보.
예: 출하 테이블이라면
- 출하번호
- 수주번호
- 출하일
- 상태
2-3. Primary Key (PK)
→ 이 데이터를 유일하게 식별하는 값
예: 출하번호
2-4. Foreign Key (FK)
→ 다른 테이블의 PK를 참조하는 값
예: 출하 → 수주번호 참조
3. 관계(Relationship)
ERD의 진짜 핵심.
3-1. 1 : 1
한 건이 정확히 하나와 연결.
예: 출하 ↔ 출하상세(특수한 경우)
3-2. 1 : N
가장 흔한 구조.
수주 1건
→ 여러 출하 발생 가능.
3-3. N : M
직접 표현하면 안 되고
중간 테이블 필요.
예:
출하 ↔ 제품
→ 출하상세
4. 출고/출하/수주로 보는 ERD 예시
수주(Order)
- 수주번호(PK)
- 거래처
- 수주일
출하(Shipment)
- 출하번호(PK)
- 수주번호(FK)
- 출하일
출하상세(Shipment Item)
- 출하번호(FK)
- 제품코드(FK)
- 수량
이 구조를 보면 바로 알 수 있다.
✔ 수주 없이 출하는 존재 못 한다.
✔ 출하에는 여러 제품이 들어간다.
✔ 수량은 상세에 있어야 한다.
이게 ERD의 힘이다.
5. ERD를 보면 업무가 보이는 이유
데이터는 거짓말을 못 한다.
관계를 보면
- 어디서 시작되는지
- 어디로 흘러가는지
- 누가 기준(master)인지
가 드러난다.
6. ERD 설계의 핵심 철학 (진짜 중요한 부분)
6-1. 데이터의 "주인"을 정하라
자재 정보는 자재 테이블.
거래처 정보는 거래처 테이블.
다른 곳에 있으면 위험 신호.
6-2. 흐름과 결과를 분리하라
수주 = 요청
출하 = 실행 결과
섞이면 나중에 지옥 된다.
6-3. 변하는 값과 변하지 않는 값을 분리하라
제품명은 잘 안 변한다 → 마스터
수량/상태는 계속 변한다 → 이력/트랜잭션
7. 초보가 절대 모르는 ERD 진짜 노하우
ERD는 현재가 아니라 미래를 위해 만든다.
확장 가능해야 한다.
- 수주가 취소될 수도 있고
- 부분 출하가 될 수도 있고
- 여러 창고에서 나갈 수도 있다.
이 가능성을 구조에 담아야 한다.
좋은 ERD는 질문이 줄어든다.
"이 값 어디서 바꿔요?"
라는 질문이 나오면 설계가 애매한 것.
테이블 수가 많다고 나쁜 게 아니다.
의미가 분리되어 있으면 좋은 설계다.
8. 실무에서 ERD를 잘 만들면 생기는 일
- 개발 속도 빨라짐
- 버그 감소
- 신규 인원이 빨리 이해
- 데이터 신뢰도 상승
9. 정규화 · 트랜잭션 · ERD의 연결
정규화 → 데이터를 올바른 위치에 둔다
ERD → 그 위치를 시각화한다
트랜잭션 → 안전하게 처리한다
동시성 → 동시에 해도 보호한다
요약
ERD
- 데이터가 어떤 구조로 저장되고 서로 어떻게 연결되는지를 보여주는 설계도
- 시스템을 만들기 전에 업무 흐름을 데이터 관점에서 정의하는 작업
ERD를 사용하는 이유
- 테이블 간 관계를 명확하게 하기 위해
- 어디서 데이터가 생성되고 어디로 흘러가는지 파악하기 위해
- 개발 전에 구조적 오류를 발견하기 위해
ERD의 핵심 요소
- Entity: 관리 대상 (수주, 출하, 거래처, 제품 등)
- Attribute: 대상이 가지는 정보 (번호, 날짜, 상태 등)
- PK: 데이터를 유일하게 식별
- FK: 다른 테이블과 연결
관계를 보면 알 수 있는 것
- 수주 없이 출하는 존재할 수 없음
- 하나의 출하에는 여러 제품이 포함될 수 있음
- 수량 정보는 출하가 아니라 출하상세에 있어야 함
ERD 설계의 기본 원칙
- 데이터의 주인을 명확히 한다
- 마스터와 이력을 분리한다
- 변하지 않는 정보와 계속 변하는 값을 나눈다
실무에서 ERD가 잘 되어 있으면
- 수정 위치가 명확하다
- 책임 범위가 분명하다
- 신규 기능 추가가 쉬워진다
- 데이터 불일치가 줄어든다
주의할 점
- 현재 요구만 보고 설계하면 확장 시 구조가 무너진다
- 미래에 발생할 수 있는 업무 변화까지 고려해야 한다
정리
- ERD는 단순한 그림이 아니라 데이터의 약속이다
- 구조가 명확하면 개발, 운영, 확장이 모두 쉬워진다
- 결국 좋은 시스템은 좋은 ERD에서 시작된다
소감
ERD를 단순히 프로젝트 시작하기 전에 그리는 설계도로 보여주기 식인 줄 았았다. 하지만 업무를 진행하다보니 생각이 완전히 바뀌었다. 데이터의 위치와 흐름을 정의하는 설계도이자, 시스템의 기준을 세우는 약속에 가깝다는 느낌을 받았다. 수주와 출하 같은 업무 예시로 연결해 보니 왜 마스터와 이력을 나누고, 왜 관계를 명확히 해야 하는지도 자연스럽게 이해됐다. 결국 좋은 프로그램은 코드가 아니라 구조에서 시작된다는 말을 실감하게 된 시간이었다.