DB 설계 A to Z 1강 — 설계란 무엇인가

시리즈 전체 구성

Part 1. 기초: 설계의 틀

• 1강. 설계란 무엇인가
• 2강. 요구사항 분석
• 3강. 개념 모델링 (ER 모델)
• 4강. ERD 표기법
• 5강. 키의 종류

Part 2. 논리 설계

• 6강. ER → 관계형 변환
• 7강. 이상현상과 함수 종속성
• 8강. 정규화 1NF ~ BCNF
• 9강. 4NF, 5NF
• 10강. 반정규화
• 11강. 식별/비식별 관계, 슈퍼타입/서브타입

Part 3. 물리 설계

• 12강. 데이터 타입 설계
• 13강. 제약조건 설계
• 14강. 키 생성 전략
• 15강. 인덱스 설계
• 16강. 파티셔닝 설계

Part 4. 심화 모델링

• 17강. 계층 구조 모델링
• 18강. 이력·시간 모델링
• 19강. 유연한 구조: 다형 관계, EAV, JSON
• 20강. 차원 모델링
• 21강. 멀티테넌시 설계

Part 5. 시니어 레벨

• 22강. 스키마 진화
• 23강. 도메인 경계와 DB 분리
• 24강. 설계 리뷰 방법론
• 25강. 종합 실습

이 시리즈는 관계형 데이터베이스 설계를 기초 → 논리 → 물리 → 심화 모델링 → 시니어 레벨 판단의 순서로 정리한 강의 노트입니다. Part 1 "기초: 설계의 틀"의 첫 강인 이번 편에서는 설계가 무엇을 결정하는 일인지부터 봅니다.

예제 도메인

전 강의에서 아래 업무를 반복해서 사용합니다.

여러 입점 셀러가 참여하는 마켓플레이스를 운영하는 쇼핑몰이다. 고객이 넣은 주문 한 건은 여러 주문항목으로 나뉘고, 주문항목마다 픽킹 → 포장 → 출고 세 처리단계를 거친다. 각 처리단계의 계획일과 실적일을 관리한다. 출고는 쇼핑몰이 아니라 셀러가 직접 한다(셀러 직접 출고). 그래서 처리단계를 수행하는 출고 담당자도 셀러가 보유한다. 같은 상품을 여러 셀러가 번갈아 공급한다(위탁 판매). 경영진은 주문과 처리단계의 처리율(계획 대비 완료) KPI 대시보드를 본다.

주문번호·항목번호는 지면에서 표와 도식의 폭을 유지하기 위해 O2401·L101 같은 짧은 가상 체계를 쓴다. 실제 서비스는 보통 더 긴 번호 체계를 쓴다.

1. DB 설계의 정의

DB 설계는 현실 세계의 업무를 데이터 구조로 옮기는 과정입니다. 핵심은 "테이블을 만드는 것"이 아니라 다음 세 가지를 결정하는 것입니다.

1. 무엇을 저장할 것인가 (엔티티, 속성)
2. 어떻게 연결할 것인가 (관계, 제약)
3. 어떤 형태로 물리적으로 저장할 것인가 (타입, 인덱스, 파티션)

설계를 코드부터 시작하면 1번과 2번이 3번(특정 DBMS 문법)에 묻혀버립니다. 그래서 설계는 단계를 나눠 진행합니다.

2. 설계 5단계

단계가 내려갈수록 되돌리는 비용이 커집니다. 개념 설계에서 "주문항목과 처리단계는 N:M"이라는 판단을 틀리면, 물리 설계 이후에는 테이블 구조 변경과 데이터 이관이 필요해집니다.

3. 예제로 단계 따라가기

① 요구사항

"각 주문항목은 여러 처리단계(픽킹, 포장, 출고)를 거친다. 각 처리단계의 계획일과 실적일을 관리한다. 한 처리단계는 여러 주문항목에 적용된다."

② 개념 설계

[주문항목] ──< 수행 >── [처리단계]
             (계획일, 실적일)

주문항목과 처리단계는 N:M이고, 계획일·실적일은 어느 한쪽이 아니라 관계 자체의 속성입니다. 이걸 이 단계에서 알아채는 게 핵심입니다.

③ 논리 설계

④ 물리 설계 (PostgreSQL)

CREATE TABLE order_item (
    item_no   VARCHAR(20) PRIMARY KEY,
    order_no  VARCHAR(10) NOT NULL,
    item_name VARCHAR(100)
);
 
CREATE TABLE stage (
    stage_code VARCHAR(10) PRIMARY KEY,
    stage_name VARCHAR(50) NOT NULL
);
 
CREATE TABLE item_stage (
    item_no     VARCHAR(20) REFERENCES order_item(item_no),
    stage_code  VARCHAR(10) REFERENCES stage(stage_code),
    plan_date   DATE NOT NULL,
    actual_date DATE,
    PRIMARY KEY (item_no, stage_code)
);
 
-- 물리 설계 판단: "주문 단위 처리 현황 조회"가 주요 쿼리라면
CREATE INDEX idx_item_order ON order_item (order_no);

같은 논리 설계라도 물리 설계는 DBMS마다 달라집니다.

InnoDB에서는 (item_no, stage_code) PK가 곧 데이터 저장 순서이므로, 주문항목 단위 조회는 빠르지만 처리단계 단위 조회에는 별도 인덱스가 필요합니다. 이것이 물리 설계가 따로 존재하는 이유입니다.

4. ANSI/SPARC 3층 스키마

대시보드용 외부 스키마 예시:

CREATE VIEW v_order_progress AS
SELECT i.order_no,
       COUNT(*)              AS total_tasks,
       COUNT(st.actual_date) AS done_tasks,
       ROUND(100.0 * COUNT(st.actual_date) / COUNT(*), 1) AS progress_pct
FROM order_item i
JOIN item_stage st ON st.item_no = i.item_no
GROUP BY i.order_no;

5. 데이터 독립성

물리적 독립성은 DBMS가 대부분 보장하지만, 논리적 독립성은 설계자가 의도적으로 만들어야 합니다. 애플리케이션이 모든 테이블을 직접 조회하면 테이블 구조 변경이 곧 코드 변경이 됩니다. (22강에서 다시 다룹니다.)

6. 좋은 설계의 기준

이 기준들은 서로 충돌합니다. 비중복성을 극대화하면 조인이 늘고, 성능을 위해 반정규화하면 무결성 유지 비용이 생깁니다. 설계 실력은 이 충돌을 근거를 갖고 타협하는 능력입니다.

1강 정리

1. 설계는 요구사항 → 개념 → 논리 → 물리 → 구현 순이며, 아래로 갈수록 DBMS 종속적이고 되돌리기 비싸다.
2. 개념 설계의 핵심은 "속성이 어디에 속하는가"의 판단이다.
3. 3층 스키마의 목적은 데이터 독립성이다.
4. 좋은 설계의 기준들은 서로 충돌하며, 설계는 근거 있는 타협이다.