데이터 모델링으로 정보 시스템 구조를 설계하는 법

시스템의 구조는 데이터 모델에서 먼저 결정된다

데이터 모델링은 현실 세계의 데이터 요소와 관계를 추상화해 표현하는 과정이다. 정보 시스템 개발에서는 비즈니스 요구사항을 데이터 구조로 바꾸는 작업이기도 하다.

모델이 일관되지 않거나 중복을 통제하지 못하면 유지보수 비용, 성능, 확장성에 문제가 생긴다. 그래서 시스템 개발 초기에 데이터 모델링에 충분한 시간과 노력을 두는 편이 낫다.

비즈니스 요구를 구현 구조로 옮기는 과정

개념 모델은 업무 언어를 정리한다

개념적 데이터 모델링은 조직이 필요로 하는 데이터를 비즈니스 관점에서 정의한다. 이 단계에서는 기술 제약보다 주요 엔티티와 관계를 식별하는 데 집중하며, 사용자와 개발자가 같은 업무 구조를 이해하도록 ER 다이어그램을 활용한다.

대학 학사관리 시스템을 예로 들면 다음과 같이 관계를 표현할 수 있다.

⤢✕

논리 모델에서 속성과 규칙을 구체화한다

논리적 데이터 모델링은 개념 모델을 DBMS에 독립적인 형태로 전환한다. 엔티티 속성을 정의하고 정규화를 수행하며, 기본키와 외래키, 비즈니스 규칙, 제약조건을 모델에 반영한다. 특정 DBMS 구현에 종속되지는 않는다.

학생과 수강신청 엔티티는 다음처럼 논리 모델로 표현할 수 있다.

학생(학번(PK), 이름, 생년월일, 주소, 전화번호, 이메일, 학과코드(FK))
수강신청(수강신청번호(PK), 학번(FK), 강좌코드(FK), 신청일자, 성적)

물리 모델은 DBMS 구현 조건을 반영한다

물리적 데이터 모델링은 논리 모델을 특정 DBMS에서 구현할 수 있도록 최적화하는 단계다. 테이블, 컬럼, 인덱스, 제약조건을 실제 문법으로 정의하고 성능, 저장소, 보안을 고려한다. 데이터 타입, 크기, 기본값 같은 상세 사항도 이 단계에서 결정한다.

Oracle DBMS를 대상으로 한 SQL DDL 예시는 다음과 같다.

CREATE TABLE 학생 (
    학번 VARCHAR2(10) PRIMARY KEY,
    이름 VARCHAR2(50) NOT NULL,
    생년월일 DATE,
    주소 VARCHAR2(200),
    전화번호 VARCHAR2(15),
    이메일 VARCHAR2(100),
    학과코드 VARCHAR2(10) REFERENCES 학과(학과코드)
);

CREATE INDEX IDX_학생_이름 ON 학생(이름);

정규화와 조회 성능의 균형

ER 모델링은 엔티티, 속성, 관계를 표현하는 대표적인 방법이다. Chen 표기법, IE(Information Engineering) 표기법, Barker 표기법처럼 여러 표기법이 있으며, 비즈니스 요구사항을 시각적으로 공유하는 데 쓰인다.

정규화는 데이터 중복을 줄이고 무결성을 보장하기 위한 절차다. 제1정규형(1NF)은 모든 속성이 원자값만 갖도록 하고, 제2정규형(2NF)은 1NF에 더해 비주요 속성이 주요 속성에 완전 함수적 종속되도록 한다. 제3정규형(3NF)은 이행적 종속(Transitive Dependency)을 제거한다. 모든 결정자(Determinant)가 후보키(Candidate Key)여야 하는 BCNF(Boyce-Codd Normal Form)와 제4정규형(4NF), 제5정규형(5NF)도 있다.

다음은 주문 정보를 정규화하는 예다.

[비정규화된 테이블]
주문(주문번호, 고객ID, 고객명, 고객주소, 상품코드, 상품명, 상품가격, 주문수량, 주문일자)

[정규화 후]
고객(고객ID, 고객명, 고객주소)
상품(상품코드, 상품명, 상품가격)
주문(주문번호, 고객ID, 주문일자)
주문상세(주문번호, 상품코드, 주문수량)

역정규화는 읽기 작업이 많은 시스템에서 쿼리 성능을 높이기 위해 정규화 원칙을 의도적으로 완화하는 방법이다. 데이터 중복을 허용해 조인(Join) 연산을 줄이고, 테이블 통합, 파생 컬럼 추가, 요약 테이블 생성 같은 방식을 사용한다. 대신 데이터 무결성이 낮아질 수 있고 갱신 비용은 증가한다.

키와 관계가 모델의 유지보수성을 좌우한다

식별자에서는 자연키(Natural Key)와 인조키(Surrogate Key)를 선택해야 한다. 자연키는 주민등록번호나 사원번호처럼 업무상 의미 있는 값을 키로 쓰는 방식이다. 인조키는 일련번호나 UUID처럼 시스템이 만든 값을 사용한다. 인조키는 변경 가능성이 낮고 성능상 유리하지만 업무적 의미는 없다. 최근에는 인조키 사용 추세가 강화되고 있다.

관계는 일대일(1:1), 일대다(1:N), 다대다(M:N)를 구분해 설계한다. 다대다 관계는 관계 엔티티 또는 연결 테이블을 두어 두 개의 일대다 관계로 해소한다.

⤢✕

슈퍼타입-서브타입(Supertype-Subtype) 관계는 구현 전략도 결정해야 한다. 단일 테이블 전략(Single Table Strategy)은 모든 속성을 하나의 테이블에 합친다. 테이블 per 클래스 전략(Table per Class Strategy)은 서브타입별로 별도 테이블을 만들며, 조인 전략(Joined Strategy)은 슈퍼타입과 서브타입 테이블을 분리한 뒤 조인한다. 각 방식은 성능, 무결성, 확장성 측면에서 차이가 있다.

변경 이력을 다뤄야 한다면 이력 테이블을 별도로 관리하거나 시작일·종료일 컬럼, 타임스탬프를 활용할 수 있다. 감사(Audit) 요구사항을 충족하려면 변경자와 변경일시 같은 메타데이터도 모델에 포함해야 한다.

모델링 도구의 쓰임

ERwin은 논리 모델과 물리 모델을 함께 관리할 수 있는 데이터 모델링 도구다. MySQL Workbench는 MySQL용 무료 도구로 엔지니어링과 리버스 엔지니어링을 지원한다. Oracle SQL Developer Data Modeler는 Oracle 환경에 맞춘 무료 도구이며, PowerDesigner는 SAP의 엔터프라이즈급 데이터 모델링 제품이다.

간단한 ER 다이어그램은 Visio 또는 draw.io(diagrams.net)로도 작성할 수 있다.

업무 도메인에서 달라지는 설계 초점

전자상거래 시스템은 고객, 판매자, 상품, 카테고리, 주문, 주문상세, 리뷰, 배송 같은 엔티티를 중심으로 모델을 구성한다.

⤢✕

상품과 카테고리의 다대다 관계는 연결 테이블로 해소한다. 주문과 주문상세는 식별관계로 설계해 무결성을 확보하고, 상품 가격 이력은 별도 이력 테이블로 관리할 수 있다.

금융권 모델은 데이터 보안, 무결성, 엄격한 감사 요구사항을 강하게 반영한다. 계정계·정보계·대외계의 시스템 분리에 맞춰 데이터 모델 연계를 설계하며, 거래 내역의 불변성(Immutability)을 보장하기 위한 이력 중심 구조가 필요하다. 실시간 처리와 배치 처리를 위한 이원화된 데이터 구조도 고려 대상이다.

데이터 플랫폼과 서비스 경계에서의 모델링

빅데이터 환경에서는 대용량 처리를 위해 NoSQL 데이터베이스 모델링 방식을 적용한다. 스키마리스(Schemaless) 또는 스키마온리드(Schema-on-read) 접근을 택할 수 있으며, 정규화보다 쿼리 패턴에 맞춘 비정규화 모델을 선호한다. MongoDB, Cassandra, HBase 같은 NoSQL DB에는 그에 맞는 모델링 기법이 필요하다.

데이터 레이크와 웨어하우스는 여러 소스의 데이터를 통합하기 위한 스키마 설계가 핵심이다. Kimball 방법론 기반의 스타 스키마와 스노우플레이크 스키마를 활용하고, 사실(Fact) 테이블과 차원(Dimension) 테이블을 구조화한다. 데이터 마트(Data Mart)는 주제 중심 모델링으로 설계한다.

데이터 거버넌스 관점에서는 전사 데이터 표준과 모델링 지침을 마련하고, 메타데이터 관리로 모델의 일관성을 유지한다. 제약조건과 기본값 등을 통해 데이터 품질 요구사항을 모델에 반영하며, 마스터 데이터 관리(MDM)를 위한 모델도 설계한다.

마이크로서비스 아키텍처에서는 서비스별 독립 데이터베이스(Database per Service)를 설계한다. 서비스 간 데이터 중복을 허용하면서 이벤트 기반 일관성을 유지하고, 도메인 주도 설계(DDD)의 바운디드 컨텍스트(Bounded Context)를 기준으로 모델 경계를 나눈다. CQRS(Command Query Responsibility Segregation) 패턴에서는 읽기 모델과 쓰기 모델을 분리한다.

데이터 모델링은 한 번 끝나는 산출물이 아니다. 비즈니스 요구사항과 기술적 제약의 균형을 계속 조정하면서, 변화하는 시스템 환경에 맞춰 모델을 유지해야 한다.