ERD와 UML 클래스 다이어그램: 데이터 모델과 도메인 모델을 함께 설계하는 법

저장 구조와 객체 설계는 같은 질문에 답하지 않는다

ERD(Entity-Relationship Diagram)는 엔터티, 속성, 관계, 식별자를 통해 데이터 구조와 제약을 표현한다. 논리·물리 스키마 설계, 정규화, 참조 무결성 구현이 이 모델의 중심이다.

UML 클래스 다이어그램은 클래스와 속성뿐 아니라 연관, 상속, 집합·합성, 가시성, 메서드까지 담는다. 도메인 모델의 책임을 나누고 재사용성과 확장성을 설계하며, 객체가 런타임에 협력하는 맥락도 반영한다.

둘은 경쟁 관계가 아니다. 하나는 데이터를 어떤 형태로 저장하고 보호할지, 다른 하나는 도메인 개념과 행위를 어떻게 코드에 담을지 결정한다.

관계를 표현하는 방식이 설계 결과를 가른다

ERD는 1:1, 1:N, N:M 관계와 식별·비식별 관계, 필수·선택 여부를 명시한다. 이 결과는 외래키와 인덱스 설계의 기반이 되며, 유니크·체크·디폴트 같은 데이터 무결성 제약으로 이어진다.

UML 클래스 다이어그램에서는 연관, 집합·합성, 다중성, 탐색 가능성을 표현한다. 불변식은 OCL 등으로 기술할 수 있지만, 이것이 데이터베이스 제약으로 바로 연결되지는 않는다.

ERD는 데이터 중심의 정적 모델이다. 트랜잭션, 락, 격리수준은 별도 설계 산출물로 관리한다. 반면 UML은 속성과 메서드를 함께 다루고 상속과 다형성을 내장하므로, 서비스 경계나 애그리게이트 같은 DDD 개념과 결합하기 쉽다.

산출물은 영속 계층과 애플리케이션 계층으로 이어진다

ERD에서는 스키마 DDL, 마이그레이션 스크립트, 인덱싱 전략을 도출한다. 쿼리 최적화와 데이터 거버넌스, 데이터 라인리지 관리와도 직접 연결된다.

UML 클래스 다이어그램은 코드 스켈레톤, ORM 엔티티 클래스, API 계약 명세로 이어질 수 있다. 테스트 픽스처나 시퀀스 다이어그램과 함께 사용하면 도메인 행위와 인터페이스의 연결도 추적할 수 있다.

관점	ERD	UML 클래스 다이어그램
성능	정규화·인덱스·조인 경로 최적화 설계를 지원하며 쿼리 플랜 예측 가능성을 높인다.	객체 그래프 관점의 최적화에 유리하며 N+1 위험과 레이지/이ager 로딩 전략의 설계 기반이 된다.
확장성	스키마 진화 전략과 파티셔닝·샤딩을 사전에 설계하기 쉽다.	타입 계층 확장과 인터페이스 분리로 서비스 확장에 유리하다.
일관성	키·외래키·체크 제약으로 강한 데이터 무결성을 보장한다.	도메인 규칙 캡슐화로 논리 일관성을 유지하지만 DB 제약이 없으면 운영 리스크가 남는다.
안정성	테이블·뷰·ETL 기준으로 변경 영향 범위를 추적하기 쉽다.	코드 리팩터링과 의존성 관리에 유리하지만 영속 계층이 동기화되지 않으면 불안정성이 생길 수 있다.
운영 편의	백업·복구, 마이그레이션, 데이터 라인리지 관리에 직접 기여한다.	코드 생성, 테스트 자동화, API 계약 관리에 유리하다.

설계 상황에 따라 모델의 출발점을 정한다

신규 서비스에서는 UML로 도메인 개념과 경계를 먼저 명세하고, ERD에서 정규화·카디널리티·제약을 확정할 수 있다. UML→ORM 클래스→ERD→DDL의 연결을 유지하는 것이 핵심이다.

레거시 데이터베이스를 현대화할 때는 ERD로 현재 스키마, 의존 뷰, 인덱스를 역공학한 뒤 UML에서 비즈니스 개념과 바운디드 컨텍스트를 다시 정의한다. 비교 뷰와 CDC 기반 동기화 뒤 테이블을 교체하는 점진 이행도 가능하다.

마이크로서비스를 나눌 때 UML은 컨텍스트 경계와 어그리게이트를 설계하는 데 쓰인다. ERD에서는 서비스별 소유 스키마를 만들고 외부 키를 제거하며 이벤트 기반 참조를 도입한다. 계약 안정성을 위해 스키마 레지스트리와 버전 전략을 운영한다.

데이터 거버넌스에서는 ERD가 데이터 카탈로그와 데이터 계보 관리의 중심이 된다. UML은 비즈니스 용어집과 정책을 연결하고 사용자 교육 자료로 활용할 수 있다.

요구사항의 우선순위에서 모델을 고른다

⤢✕

데이터 무결성과 쿼리 성능이 우선이면 ERD부터 구체화한다. 도메인의 복잡도와 행위 모델링이 핵심이라면 UML 클래스 다이어그램을 먼저 잡는다. 어느 한쪽이 명확한 우선순위를 갖지 않는 경우에는 공통 용어와 간단한 속성 목록으로 합의 범위를 먼저 좁힐 수 있다.

카디널리티와 다중성이 상충하는 요구사항은 모델 표기만으로 해결되지 않는다. 워크숍에서 원천 규칙을 합의하고 ERD 제약과 UML OCL을 함께 갱신해야 한다.

UML의 개념을 ERD의 구조로 옮길 때 결정할 것들

클래스에서 테이블을 도출할 때는 실체 클래스만 엔터티로 만들고, 값 객체는 임베디드로 둘지 별도 테이블로 둘지 선택한다. 속성은 타입, 널 가능성, 디폴트를 정제한 뒤 후보키를 찾고 식별자를 확정한다.

연관은 관계와 외래키로 변환한다. 다중성을 1:1, 1:N, N:M으로 해석하며, N:M은 조인 테이블로 분해한다.

상속 매핑은 데이터 구조와 조회 비용의 절충이다.

싱글 테이블은 단순하고 빠르지만 스파스 컬럼이 늘어나는 단점이 있다.
조인 전략은 정규화와 무결성에 유리하지만 조인 비용이 증가한다.
클래스별 테이블은 독립성이 높지만 UNION과 중복 컬럼 부담이 따른다.

참조 무결성, 유니크, 체크 제약을 정하고 CRUD·조회 패턴을 근거로 인덱스를 설계한다. 이후 대표 쿼리 플랜, 트랜잭션·락 시나리오, 이행 마이그레이션 시뮬레이션으로 모델을 검증한다.

가능한 데이터 규칙은 DB 제약에 두고, 예외적인 도메인 규칙은 애플리케이션에서 보강한다. 유지보수성과 일관성 사이의 균형이 필요하다. ORM은 스키마 우선의 코드 생성 또는 코드 우선의 마이그레이션 자동화 중 하나를 택하되, 산출물 간 일관성을 유지해야 한다.

스키마 진화에는 추가→이중쓰기→전환→삭제의 뒤호환 변경 전략을 적용할 수 있다. 다운타임은 줄일 수 있지만 복잡성은 증가한다. 테이블·컬럼의 명명 규칙을 표준화하고 스키마 버전을 태깅하면 라인리지를 확보할 수 있다.

제약과 인덱스 설계가 만드는 운영상 변화

스키마 제약을 강화하면 참조 오류와 중복 삽입이 30~~50% 감소할 것으로 추정된다. 주요 쿼리의 80/20 규칙을 기준으로 인덱스를 설계하면 P95 응답시간은 20~~35% 개선 가능하다.

요구사항→UML→ERD→DDL→코드의 추적성을 갖추면 변경 리드타임을 단축할 수 있다. 데이터 카탈로그와 라인리지의 정합성도 높아져 감사 대응 비용 절감으로 이어진다.

예시 계산 근거(보수적 가정)

월 100건 데이터 결함→ERD 제약 적용 후 50건으로 감소 시 감소율 = (100-50)/100=50%.
P95 400ms→인덱스 개선 후 280ms 달성 시 개선율 = (400-280)/400=30%.

ERD와 UML 클래스 다이어그램은 추상화 수준과 목적이 다른 상호보완적 도구다. 행위와 도메인 복잡도가 중심인 요구에는 UML을, 데이터 무결성·성능·운영성이 중심인 요구에는 ERD를 우선 적용한다. 매핑 절차와 진화 전략을 표준화해야 산출물의 일관성과 운영 안정성을 함께 확보할 수 있다.