ERD부터 배우는 DB 설계의 모든 것

 

 

관계형 데이터베이스(RDBMS)는 50년이 넘는 시간 동안 IT 시스템의 핵심을 담당해 왔습니다. 1970년 에드거 코드(Edgar Codd)가 관계형 모델을 제안한 이후, Oracle, MySQL, PostgreSQL 같은 RDBMS는 전 세계 대부분의 비즈니스 애플리케이션에서 사용되고 있습니다. NoSQL의 등장에도 불구하고, 데이터 일관성과 무결성이 중요한 금융, 의료, 전자상거래 등의 분야에서 RDBMS는 여전히 대체 불가능한 선택입니다.

좋은 관계형 데이터베이스 설계는 시스템의 성공을 좌우합니다. 설계가 잘못되면 데이터 중복, 성능 저하, 유지보수 어려움 등의 문제가 끊임없이 발생합니다. 반대로 처음부터 체계적으로 설계된 데이터베이스는 수년이 지나도 안정적으로 작동하며, 새로운 요구사항에도 유연하게 대응할 수 있습니다. 데이터베이스 설계는 건물의 기초 공사와 같습니다. 기초가 튼튼해야 그 위에 무엇이든 올릴 수 있습니다.

이 글에서는 관계형 데이터베이스 설계의 전 과정을 마스터할 수 있도록 안내합니다. 요구사항 분석부터 개념적 설계, ERD 작성, 논리적 설계, 물리적 설계까지 단계별로 상세히 다룹니다. 각 단계에서 무엇을 해야 하는지, 어떤 점을 주의해야 하는지, 실전에서 어떻게 적용하는지를 구체적인 예시와 함께 설명하겠습니다. 이 가이드를 마치면 여러분도 전문적인 데이터베이스 설계 역량을 갖추게 될 것입니다.

요구사항 분석으로 시작하는 DB 설계

데이터베이스 설계의 첫 단계는 요구사항 분석입니다. 무엇을 저장해야 하는지, 어떤 조회가 필요한지, 데이터 간의 관계는 어떠한지를 파악하는 과정입니다. 이 단계에서 비즈니스를 충분히 이해하지 못하면 나중에 전체 설계를 다시 해야 하는 상황이 발생합니다. 기획서, 화면 설계서, 업무 프로세스 문서 등을 꼼꼼히 검토하고, 현업 담당자와 충분히 소통해야 합니다.

요구사항 분석에서 핵심은 '엔티티(Entity)'를 식별하는 것입니다. 엔티티는 데이터베이스에 저장할 대상으로, 나중에 테이블이 됩니다. 쇼핑몰을 예로 들면, 고객, 상품, 주문, 리뷰, 카테고리 등이 엔티티가 됩니다. 엔티티를 식별할 때는 "시스템에서 관리해야 할 정보는 무엇인가?"라는 질문을 던져보세요. 명사 형태로 답이 나오는 것들이 대부분 엔티티입니다.

엔티티를 식별했다면 각 엔티티의 속성(Attribute)을 정의합니다. 속성은 엔티티를 설명하는 특성으로, 나중에 테이블의 열(Column)이 됩니다. 고객 엔티티라면 이름, 이메일, 전화번호, 가입일 등이 속성이 됩니다. 속성을 정의할 때는 원자값(Atomic Value) 원칙을 기억하세요. 하나의 속성에는 하나의 값만 저장되어야 합니다. "취미: 독서, 영화, 운동"처럼 여러 값을 하나에 넣으면 안 됩니다.

다음으로 엔티티 간의 관계(Relationship)를 파악합니다. 고객과 주문의 관계는 어떠한가요? 한 명의 고객이 여러 개의 주문을 할 수 있으므로 1:N 관계입니다. 상품과 카테고리의 관계는요? 하나의 상품이 여러 카테고리에 속할 수 있고, 하나의 카테고리에 여러 상품이 있을 수 있다면 N:M 관계입니다. 관계를 정확히 파악하는 것이 좋은 설계의 핵심입니다.

개념적 설계의 결과물은 개념적 데이터 모델, 주로 ERD(Entity Relationship Diagram)의 초안입니다. 이 단계의 ERD는 비즈니스 관점에서 데이터 구조를 표현합니다. 아직 DBMS의 특성이나 성능은 고려하지 않습니다. 비개발자도 이해할 수 있는 수준으로 작성하는 것이 좋습니다. 개념적 설계가 잘 되어야 이후 단계가 수월해집니다.

엔티티와 관계로 그리는 ERD

ERD(Entity Relationship Diagram)는 데이터베이스 설계의 청사진입니다. 시스템의 엔티티가 무엇이고, 어떤 속성을 가지며, 서로 어떤 관계인지를 시각적으로 표현합니다. ERD를 보면 데이터베이스의 전체 구조를 한눈에 파악할 수 있습니다. 개발자 간 소통, 문서화, 유지보수 모두에서 ERD는 필수적인 산출물입니다.

ERD에서 엔티티는 사각형으로 표현합니다. 사각형 안에 엔티티 이름을 적고, 아래에 속성들을 나열합니다. 속성 중 기본 키(Primary Key)는 밑줄을 긋거나 별도 표시를 합니다. 예를 들어, 고객 엔티티는 사각형 안에 "고객"이라고 쓰고, 그 아래에 "고객번호(PK), 이름, 이메일, 전화번호, 가입일"을 나열합니다.

관계는 엔티티 사이를 연결하는 선으로 표현합니다. 선 위에 관계의 이름을 적고, 양 끝에 기수성(Cardinality)을 표시합니다. 기수성은 관계에 참여하는 엔티티의 개수를 나타냅니다. 1:1, 1:N, N:M 등으로 표현합니다. 까마귀 발(Crow's Foot) 표기법에서는 1은 직선, N은 갈라지는 세 개의 선으로 표시합니다. 선택적 참여는 원(○)으로, 필수 참여는 직선(|)으로 표시합니다.

실전에서 자주 마주치는 N:M 관계를 처리하는 방법을 알아봅시다. 학생과 수업의 관계는 N:M입니다. 한 학생이 여러 수업을 듣고, 한 수업에 여러 학생이 있습니다. N:M 관계는 직접 구현할 수 없으므로, 중간에 연결 테이블(Junction Table)을 만들어 두 개의 1:N 관계로 분리합니다. '수강' 테이블을 만들고, 여기에 학생번호와 수업번호를 외래 키로 저장합니다. 이제 학생-수강은 1:N, 수업-수강도 1:N이 됩니다.

ERD 작성 도구로는 MySQL Workbench, ERDCloud, draw.io, dbdiagram.io 등이 있습니다. MySQL Workbench는 ERD를 그리면 자동으로 SQL 스크립트를 생성해 주어 편리합니다. ERDCloud는 웹 기반이라 설치 없이 바로 사용할 수 있고, 팀 협업 기능도 제공합니다. 어떤 도구를 사용하든 표기법은 일관되게 유지하세요. IE(Information Engineering) 표기법과 까마귀 발 표기법이 가장 널리 사용됩니다.

논리적 설계 핵심, 정규화와 무결성

논리적 설계는 개념적 설계를 관계형 모델로 변환하는 단계입니다. ERD의 엔티티는 테이블로, 속성은 열로, 관계는 외래 키로 변환됩니다. 이 단계에서 정규화를 적용하여 데이터 중복을 제거하고, 무결성 제약조건을 정의하여 데이터 품질을 보장합니다.

정규화(Normalization)는 테이블을 분리하여 데이터 중복을 최소화하는 과정입니다. 제1 정규형(1NF)은 모든 속성이 원자값을 가지도록 합니다. 제2 정규형(2NF)은 부분 함수 종속을 제거합니다. 복합 키의 일부에만 종속되는 속성은 별도 테이블로 분리합니다. 제3 정규형(3NF)은 이행 함수 종속을 제거합니다. 기본 키가 아닌 속성이 다른 속성을 결정하면 분리합니다. 실무에서는 보통 3NF까지 적용합니다.

무결성 제약조건은 데이터의 정확성과 일관성을 보장하는 규칙입니다. 개체 무결성(Entity Integrity)은 기본 키가 NULL이거나 중복될 수 없음을 의미합니다. 참조 무결성(Referential Integrity)은 외래 키가 참조하는 값이 반드시 존재해야 함을 의미합니다. 도메인 무결성(Domain Integrity)은 열에 정의된 데이터 타입과 범위를 준수해야 함을 의미합니다.

제약조건은 SQL의 CONSTRAINT로 구현합니다. PRIMARY KEY는 기본 키를 정의합니다. FOREIGN KEY는 외래 키와 참조 관계를 정의합니다. NOT NULL은 필수 입력을 강제합니다. UNIQUE는 중복을 방지합니다. CHECK는 특정 조건을 검증합니다. DEFAULT는 기본값을 지정합니다. 이러한 제약조건을 적절히 활용하면 애플리케이션 코드에서 별도로 검증하지 않아도 데이터베이스 수준에서 무결성이 보장됩니다.

논리적 설계 단계에서 데이터 타입도 결정합니다. 숫자에는 INT, BIGINT, DECIMAL 등을 사용합니다. 문자열에는 CHAR, VARCHAR, TEXT 등을 사용합니다. 날짜와 시간에는 DATE, TIME, DATETIME, TIMESTAMP 등을 사용합니다. 데이터 타입을 적절히 선택하면 저장 공간을 절약하고 성능을 향상할 수 있습니다. 예를 들어, 고정 길이 문자열에는 VARCHAR보다 CHAR가 효율적입니다.

확장성을 고려한 데이터베이스 최적화

물리적 설계는 논리적 설계를 실제 DBMS에 구현하는 단계입니다. 이 단계에서는 성능과 확장성을 고려하여 인덱스, 파티션, 저장 구조 등을 결정합니다. 동일한 논리적 설계라도 물리적 설계에 따라 성능이 크게 달라질 수 있습니다.

인덱스(Index)는 성능 최적화의 핵심입니다. 책의 색인처럼 데이터를 빠르게 찾을 수 있게 해줍니다. WHERE 절에서 자주 사용되는 열, JOIN에서 사용되는 열, ORDER BY에서 사용되는 열에 인덱스를 생성합니다. 하지만 인덱스가 많으면 INSERT, UPDATE, DELETE 성능이 저하되므로 균형이 필요합니다. 복합 인덱스를 만들 때는 선택도(Selectivity)가 높은 열을 앞에 배치합니다.

파티셔닝(Partitioning)은 대용량 테이블을 여러 조각으로 나누는 기법입니다. 시간 기반 파티셔닝을 적용하면 특정 기간의 데이터만 빠르게 조회할 수 있습니다. 예를 들어, 주문 테이블을 월별로 파티셔닝 하면 "2024년 12월 주문"을 조회할 때 해당 파티션만 스캔합니다. 오래된 데이터를 삭제할 때도 파티션 단위로 처리하여 성능 부담을 줄일 수 있습니다.

반정규화(Denormalization)도 물리적 설계에서 고려합니다. 정규화된 설계는 데이터 무결성에 유리하지만, 조회 시 많은 JOIN이 필요할 수 있습니다. 조회 성능이 중요한 경우 의도적으로 중복을 허용하여 JOIN을 줄입니다. 예를 들어, 주문 조회 시 항상 고객명이 필요하다면 주문 테이블에 고객명을 중복 저장할 수 있습니다. 반정규화는 데이터 일관성 유지 비용과 조회 성능 향상 이점을 비교하여 결정합니다.

물리적 설계의 마지막 단계는 테이블과 인덱스를 생성하는 DDL 스크립트 작성입니다. CREATE TABLE 문으로 테이블을 생성하고, 제약조건을 정의합니다. CREATE INDEX 문으로 인덱스를 생성합니다. 이 스크립트는 버전 관리 시스템에 저장하여 변경 이력을 추적합니다. 또한 개발, 테스트, 운영 환경에 동일하게 적용할 수 있도록 관리합니다.

관계형 데이터베이스 설계는 한 번에 완성되지 않습니다. 요구사항이 변하고, 데이터가 증가하면서 설계도 진화해야 합니다. 중요한 것은 처음부터 체계적인 프로세스를 따르고, 변경에 유연하게 대응할 수 있는 구조를 만드는 것입니다. 이 가이드에서 배운 원칙들을 바탕으로 여러분만의 데이터베이스 설계 역량을 키워나가시기 바랍니다. 좋은 설계는 좋은 시스템의 시작입니다.