실무 현장에서 초보 개발자들이 가장 흔히 저지르는 치명적인 실수가 있습니다. 비즈니스 요구사항을 듣자마자 메모장이나 머릿속 생각에 의존해 무작정 코드부터 타이핑하고 CREATE TABLE 명령어부터 때려 넣는 행위입니다. 설계도 없이 벽돌을 대충 쌓아 올린 빌딩이 지진 한 번에 무너지듯, 정밀한 데이터 모델링(Data Modeling) 단계를 무시하고 구축된 시스템은 서비스 가동 몇 달 만에 데이터 중복, 일관성 파괴, 성능 병목이라는 대재앙을 맞이하게 됩니다.

데이터 모델링은 단순히 테이블 구조를 잡는 기술적 행위를 넘어, "복잡한 현실 세계의 비즈니스 규칙(Business Rule)을 컴퓨터가 이해할 수 있는 정교한 정보 구조로 정화하여 청사진을 그리는 일"입니다. 오늘은 데이터 아키텍트의 심장과도 같은 개념적, 논리적, 물리적 데이터 모델링의 3단계 설계 공식과, 정합성의 요체인 정규화(Normalization)의 본질을 우리 의류 쇼핑몰 프로젝트 스키마를 바탕으로 가장 쉽고 완벽하게 설명해 드리겠습니다!

1. 데이터 모델링의 3단계 진화 과정: 개념에서 물리까지

현실 세계의 비즈니스가 실제 가동되는 데이터베이스로 구축되기까지는 '개념적 모델링 (\rightarrow) 논리적 모델링 (\rightarrow) 물리적 모델링'이라는 세 번의 우아한 추상화 단계를 거치게 됩니다. 이 흐름을 한 장의 청사진으로 시각화한 흐름도를 먼저 확인해 보시죠.

① 1단계: 개념적 데이터 모델링 (Conceptual Modeling) - 비즈니스의 첫 뼈대 스케치

사용자의 요구사항을 청취한 후, 기술적인 세부 사항은 모두 잊어버리고 "비즈니스의 핵심 실체와 그들 간의 관계"만을 도출해 큰 뼈대를 잡는 최초의 단계입니다.

• 엔티티(Entity, 개체) 도출: 비즈니스 영역에서 영구히 관리해야 하는 독립적 대상(사람, 장소, 사물, 사건 등)을 찾아냅니다.
• 관계(Relationship) 설정: 이 개체들이 서로 어떤 인과관계나 연관성을 맺고 있는지 선을 연결해 정의합니다.
• ERD(Entity Relationship Diagram) 초안: 이 단계를 통해 비즈니스의 대략적인 전체 구도가 그려집니다. 이 단계에서는 데이터 타입이나 세부 컬럼명 같은 머리 아픈 세부 명세는 정의하지 않고 오직 큼직한 네모 상자(개체)와 이들을 잇는 선(관계)만으로 단순화합니다.
• 쇼핑몰 프로젝트 예시: 우리 의류 쇼핑몰 비즈니스 규칙에서 '고객', '의류상품', '주문'이라는 가장 본질적인 핵심 엔티티를 포착해 배치하는 작업이 개념적 모델링에 속합니다.

② 2단계: 논리적 데이터 모델링 (Logical Modeling) - 속성 정의와 관계의 구체화

개념적 단계에서 잡은 대략적인 뼈대 위에, 구체적인 속성(Attribute)들을 누락 없이 매핑하고 기본키(PK)와 외래키(FK)를 정밀하게 지정하는 단계입니다.

• 속성(Attribute) 매핑: 엔티티가 지녀야 할 구체적인 상세 정보들을 정의합니다. 예를 들어 '고객' 엔티티에 '이메일', '비밀번호', '고객명', '휴대폰 번호' 등을 빈틈없이 채워 넣는 식입니다.
• 식별자 지정: 각 레코드를 세상에서 단 하나로 구분해 줄 수 있는 기본키(Primary Key, PK)를 확정하고, 테이블 간의 연관관계를 수호할 외래키(Foreign Key, FK)를 정의해 참조 관계를 구체화합니다.
• 정규화(Normalization): 데이터의 정합성을 보장하고 중복(Redundancy)을 제거해 공간 효율을 극대화하는 관계형 설계의 마법 공식을 작동시킵니다.
• 표기법 활용: 실무에서는 주로 IE 표기법(Information Engineering Notation)이나 바커 표기법(Barker's Notation) 등을 사용해 관계의 형태(1:1, 1:N, M:N 관계)와 필수 여부(반드시 있어야 하는가, 없어도 되는가)를 표기합니다. 한글 명칭 위주로 작성되어 비즈니스 기획자나 클라이언트도 한눈에 알아볼 수 있는 실질적인 전체 데이터 청사진이 완성되는 고지입니다.

③ 3단계: 물리적 데이터 모델링 (Physical Modeling) - DBMS 실전 배치 설계

논리 모델링 단계의 한글 설계도를 바탕으로, 내가 사용할 특정 DBMS(예: MySQL) 엔진의 특성과 하드웨어 한계를 고려해 영문 데이터베이스 테이블 스키마를 최종 선언하는 단계입니다.

• 영문 전환: 한글로 된 엔티티명과 속성명을 실제 데이터베이스 쿼리에 작성할 수 있도록 물리적인 영문 테이블명과 컬럼명으로 치밀하게 치환합니다. (예: '고객' 엔티티 (\rightarrow) Customers 테이블, '고객ID' 속성 (\rightarrow) cust_id 컬럼)
• 데이터 타입(Data Type) 확정: 각 컬럼에 담길 데이터의 물리적 성격과 최대 자릿수 크기를 명확히 제약합니다. (예: 비밀번호는 해시 암호화 문자열이 들어가므로 VARCHAR(255), 단가는 소수점이 없는 돈이므로 INT 등)
• 제약조건(Constraints) 상세 설계: NOT NULL, DEFAULT, AUTO_INCREMENT, 외래키 ON DELETE CASCADE 등 DBMS 엔진이 트랜잭션 수호 시 가동할 물리적 세부 제약 규칙들을 남김없이 쿼리 레벨로 명세화합니다.

2. 데이터 모델링의 본질: 비즈니스 규칙(Business Rule)의 시각적 명세

"교수님, 데이터베이스 설계도는 개발자가 그냥 쿼리만 짜면 그만이지 왜 비즈니스 규칙의 표현이라고 하나요?"

아주 핵심적인 통찰입니다. ERD(설계도)는 단순한 기술 다큐멘트가 아니라, 비즈니스 아이디어가 동작하는 인과관계와 규칙을 정밀하게 그림으로 요약해 둔 비즈니스 명세서입니다.

참고도서에서 예제로 쓰인 의류 쇼핑몰 데이터베이스(shopping_db)의 논리 ERD를 가동하는 4가지 실전 비즈니스 규칙과 ERD 표현의 상관관계를 뜯어보겠습니다.

• 비즈니스 규칙 ①: "고객은 여러 번 주문할 수 있고, 가입만 하고 주문 실적이 한 번도 없는 고객도 존재한다."
  • ERD 표현: Customers 테이블과 Orders 테이블은 1:N 선택 관계(One-to-Many Optional)로 연결됩니다. Orders 테이블의 외래키인 cust_id는 반드시 Customers 테이블에 존재하는 실사용자 ID여야만 하지만, Customers 쪽에서는 주문 정보가 전혀 없어도 계정이 무결하게 유지됩니다.
• 비즈니스 규칙 ②: "장바구니의 아이템들은 고객별, 상품별, 사이즈별로 유일하게 담겨 관리된다."
  • ERD 표현: Carts 테이블은 회원 ID(mem_id 또는 cust_id), 상품 코드(prod_cd), 사이즈(prod_size)를 복합적으로 참조하며, 중복 방지를 위해 일련번호(cart_seq_no)를 기본키로 두고 관리됩니다.
• 비즈니스 규칙 ③: "하나의 주문에는 여러 종류의 상품이 다수 포함될 수 있고, 주문 내역은 반드시 하나의 주문에 강제 종속된다."
  • ERD 표현: 주문 마스터 정보를 담는 Orders 테이블과 실제 개별 구매 품목 리스트를 담는 Ord_items 테이블이 분리되며, Ord_items는 Orders(ord_no)를 외래키로 참조해 1:N 필수적 종속 관계(One-to-Many Mandatory)로 묶입니다. 부모인 Orders가 날아가면 자식인 Ord_items도 살아서 존재할 수 없습니다.
• 비즈니스 규칙 ④: "고객은 주문한 상품별로 단 한 번의 상품평만 남길 수 있다."
  • ERD 표현: 상품평 테이블인 Pro_evals(또는 Prod_evals)는 품평일련번호(eval_seq_no)를 기본키로 가지며, 어떤 주문 내역에 대해 남긴 평인지 추적하기 위해 ord_item_no를 외래키이자 고유 참조키로 매핑해 이중 작성을 차단합니다.

3. 관계형 설계의 영혼: 데이터 정규화(Normalization) 핵심 3단계

RDBMS 설계에서 가장 빛나는 기술적 금과옥조는 바로 정규화(Normalization)입니다. 정규화는 중복 데이터를 없애고 테이블 간의 종속 관계를 논리적으로 고도화하여 데이터 무결성을 지키고 데이터 삽입/수정/삭제 시 발생하는 이상 현상(Anomaly)을 원천 차단하는 수학적 설계 정화 과정입니다. 실무에서 쓰이는 핵심 3단계만 마스터해 봅시다!

① 제1정규화 (1NF) : 속성의 원자성(Atomic Value) 확보

• 원칙: 모든 컬럼의 값은 반드시 더 이상 쪼갤 수 없는 '단 하나의 원자값'만 가져야 합니다. 하나의 행에 멀티 벨류(배열 형태의 데이터 등)가 채워지면 안 됩니다.
• 쇼핑몰 위반 사례: 만약 어떤 고객이 장바구니에 옷을 담을 때, 한 행의 prod_size 컬럼에 S, M, L을 콤마(,)로 구분해 통째로 넣는다면 1NF 위반입니다.
• 해결: 행을 분리하여 S, M, L이 각각 개별 행(Row)으로 입력되게 구조화합니다.

② 제2정규화 (2NF) : 부분 함수 종속 제거 (완전 함수 종속 달성)

• 원칙: 기본키가 두 개 이상의 컬럼으로 결합된 복합키(Composite Key)인 경우, 기본키가 아닌 일반 컬럼들은 복합 기본키 전체에 완전히 종속되어야 하며, 기본키 중 일부 컬럼에만 종속(부분 함수 종속)되어서는 안 됩니다.
• 쇼핑몰 위반 사례: Ord_items 테이블의 기본키가 만약 ord_no와 prod_cd 복합키로 설정되어 있는데, 여기에 상품의 가격(price)이나 제조사 정보 컬럼이 같이 들어있다고 해봅시다. 가격 정보는 복합키 전체가 아니라 오직 prod_cd라는 일부 기본키 컬럼에만 매핑되어 종속됩니다. 이 상태로 두면 상품 가격이 바뀔 때마다 모든 주문 상세 행들을 뒤져서 수정해야 하는 이상 현상이 생깁니다.
• 해결: 부분 종속되는 컬럼(가격 등)을 따로 떼어내어 독립된 Products 테이블로 분리 독립시킵니다.

③ 제3정규화 (3NF) : 이행적 함수 종속 제거 (Transitive Dependency)

• 원칙: 일반 컬럼이 다른 일반 컬럼에 종속되는 현상, 즉 A (\rightarrow) B 이고 B (\rightarrow) C 일 때 A (\rightarrow) C 가 성립하는 인과 관계를 제거합니다. 주 식별자가 아닌 컬럼을 거쳐서 이행적으로 종속되면 안 됩니다.
• 쇼핑몰 위반 사례: Customers 테이블에 회원 이메일(cust_id), 우편번호, 도시명 컬럼이 함께 들어가 있다고 해봅시다. cust_id가 우편번호를 결정하고, 우편번호가 도시명을 결정합니다. 결과적으로 도시명은 기본키인 cust_id에 이행적으로 종속됩니다. 우편번호-도시 정보가 여러 회원에게 반복 저장되어 일관성이 깨지기 쉽습니다.
• 해결: 우편번호와 도시명 컬럼을 별도의 우편번호 마스터 테이블로 분리해 내어 일관성을 영구 수호합니다.

마치며: 설계도를 완성했으니, 이제 실전 구축의 망치를 잡읍시다!

오늘 우리는 개념적, 논리적, 물리적 데이터 모델링의 전 과정과, 데이터 무결성의 보루인 정규화의 심오한 원리, 그리고 우리 쇼핑몰 프로젝트에 녹아든 실전 비즈니스 규칙 매핑 구조를 완벽하게 정복했습니다!

"설계도 없이 건물을 지으려 드는 개발자는 삽 한 자루로 만리장성을 쌓으려는 무모한 인부와 같습니다. 데이터 모델링을 마스터한 여러분은 이제 인프라 전체를 정교하게 지휘하는 최고의 설계 기사가 된 것입니다!"

다음 포스팅인 '[DB 물리 설계] MySQL Workbench를 활용한 쇼핑몰 핵심 6개 테이블 구축 및 제약조건 수립 실습'에서는 내 로컬 PC를 강력한 데이터베이스 서버로 둔갑시키는 실전 셋업 절차에 대해서 다루겠습니다.

오늘 다룬 개념적/논리적/물리적 모델링이나 1~3정규화 규칙에 대해 헷갈리거나 어려운 점이 있다면 주저 말고 운영자 메일로 질문해주세요. 오늘도 안전하고 영리한 클라우딩 라이프 하세요. 감사합니다! 😉

출처

• 이현호. 실무 프로젝트로 완성하는 클라우드 환경에서 DB 구축과 웹 개발. 길벗캠퍼스. 2026.04. (5.2장 '의류 쇼핑 DB 구축', 134-137페이지 참조)
• 이현호. "05장. 데이터베이스 구축" 설명 오디오 가이드 스크립트 기반 데이터 모델링의 아키텍처적 의의 및 설계 3단계 흐름 비하인드 대화록 완벽 반영.
• AWS Architecture Center - Database Design and Data Modeling Best Practices 가이드 및 Relational Database Schema Design Handbook.