데이터 모델링 — ERD의 네 요소, 정규화, 그리고 반정규화를 언제 하는가

테이블을 어떻게 나눌지는 코드를 짜기 전에 정해지고, 한 번 정해지면 되돌리는 비용이 코드와 비교가 안 된다. 이 글은 그 결정을 내리는 절차 — 요구사항을 개체-관계 모델로 옮기고, 정규화로 이상현상을 걷어내고, 필요할 때만 반정규화를 꺼내는 순서를 다룬다. 스키마를 처음 설계하거나, 이미 돌아가는 스키마가 왜 자꾸 값이 어긋나는지 찾는 사람에게 필요한 내용이다.

그 앞 단계 — 저장소 자체를 무엇으로 고르는가 — 는 시리즈 1편 관계형 데이터베이스와 NoSQL이 맡는다. 이 글은 저장소가 정해진 다음의 이야기이고, 시리즈 전체가 쓰는 용어 정의도 1편에 있다.

모델링은 무엇을 정하는 일인가

데이터 모델링은 현실의 요구사항(비즈니스)으로부터 데이터의 실체를 나타내는 일이다. 정의만 보면 문서 작업처럼 들리지만, 실제로 얻는 것은 셋이다.

세 행을 관통하는 것은 「무엇을 저장할까」가 아니라 **「이 조직이 다루는 것이 무엇인가를 한 벌의 정의로 합의한다」**는 성격이다. 그래서 모델이 없으면 같은 개념이 팀마다 다른 이름과 다른 타입으로 저장되고, 그 상태는 뒤에서 다룰 데이터 표준 문제로 그대로 이어진다.

개체-관계 모델의 네 요소와 ERD

네 요소

ERD는 네 가지로 이뤄진다.

주의할 것은 엔터티가 「사물」만이 아니라 행위의 집합도 된다는 점이다. 「대출」·「반납」·「결제」는 명사로 보이지 않아 자주 누락되는데, 이력을 남겨야 하는 순간 반드시 엔터티가 된다.

카디널리티와 선택성

관계를 선으로만 그리면 모델은 절반만 정해진다. **몇 개가 대응하는가(카디널리티)**와 **없어도 되는가(선택성, Optionality)**는 서로 독립된 축이고, 둘을 함께 지정해야 표기가 하나로 확정된다. 까마귀발(Crow's Foot) 표기는 이 두 축을 교차시켜 네 가지를 만든다.

카디널리티는 표기에서 끝나지 않고 물리 스키마의 형태를 직접 결정한다.

세 행 중 실무에서 사고가 나는 곳은 마지막 행이다. M:M은 표기법에는 있지만 저장 구조에는 없다.

도서관을 예로 들어 관계를 문장으로 읽으면 이렇게 된다.

• 작가는 도서를 집필할 수도 있고, 하지 않을 수도 있다 → 작가 쪽은 선택(optional)이다.
• 도서는 반드시 집필한 작가가 존재해야 한다 → 도서 쪽은 필수(mandatory)다.
• 한 도서를 집필하는 작가는 한 명이다 → 1:M이다.

모델이 SQL을 결정한다

위 세 문장 중 「집필한 도서가 없는 작가도 있을 수 있다」는 조건이 곧 조인 방식을 바꾼다. 선택성은 ERD 위의 기호가 아니라 쿼리의 결과 집합이다.

-- 집필한 도서가 있는 작가만 (INNER JOIN)
SELECT 작가.작가명, 도서.도서명
FROM 작가, 도서
WHERE 작가.작가ID = 도서.작가ID;

-- 모든 작가 (집필 이력 없는 작가 포함) → OUTER JOIN 이 필수
SELECT 작가.작가명, 도서.도서명
FROM 작가 LEFT OUTER JOIN 도서
ON 작가.작가ID = 도서.작가ID;

두 쿼리는 문법이 아니라 요구사항이 다르다. 「작가 목록을 보여 준다」는 화면에 첫 번째 쿼리를 쓰면 신인 작가가 통째로 사라지는데, 데이터도 코드도 정상이라 원인을 찾는 데 시간이 걸린다. 선택성을 모델 단계에서 적어 두면 이 결정이 리뷰 대상이 되고, 적어 두지 않으면 쿼리를 쓰는 사람의 그때그때 판단이 된다.

정규화 — 이상현상을 없애는 절차

정규화가 막는 것

정규화의 목적은 논리적 데이터 모델의 일관성을 유지하고, 중복을 제거한 안정적인 자료구조를 얻는 것이다.

필요성은 반대편에서 더 분명하다. 정규화되지 않은 엔터티는 입력·삭제·수정 시 오류가 발생할 개연성(Anomaly)이 있고, 변경 이상이 일어나면 신뢰할 수 없는 값이 채워져 일관성과 무결성을 해친다. 이상현상은 셋이다.

셋의 공통 원인은 하나다 — 독립적으로 존재해야 할 두 사실이 한 행에 묶여 있다. 과목이라는 사실과 등록이라는 사실이 같은 행에 있으면, 등록을 넣어야 과목이 생기고 등록을 지우면 과목이 사라진다. 정규형은 그 묶임을 단계별로 푸는 절차다.

정규형 단계별 비교

1NF 다음부터의 화살표 라벨을 이어 읽으면 정규화가 무엇을 하는 절차인지 한 줄로 나온다 — 종속성을 한 종류씩 제거하는 것이다. 단계가 올라갈수록 제거 대상이 좁아지고, 그만큼 실무에서 마주치는 빈도도 떨어진다.

실무 기준선은 여기서 나온다. 대부분의 OLTP 설계는 3NF까지를 목표로 하고, 후보키가 복잡한 예외 상황에서만 BCNF를 검토한다. 4NF·5NF는 이론적 완결성의 영역이라 실무에서 명시적으로 적용하는 일은 드물다.

잘못된 모델을 되돌리는 비용

「여러 명의 공동작가가 존재할 수 있다」는 요구를 뒤늦게 발견했다고 하자. 1:M으로 잡아둔 모델을 M:M으로 바꾸는 순간 아래가 전부 따라온다.

조회 SQL이 어디에 몇 개나 있는지는 모델을 바꾸기로 결정한 뒤에야 세어진다.

이것이 모델링을 「설계 문서 작업」이 아니라 리스크 관리로 봐야 하는 이유다. 코드는 리팩터링으로 되돌릴 수 있지만, 운영 중인 데이터 구조는 되돌리는 비용이 비대칭적으로 크다. 마이그레이션 도중 정합성이 깨지면 복구가 불가능한 경우도 있다.

반정규화를 언제 하는가

정규화는 중복 제거를 얻고 조인 비용을 지불한다. 반정규화는 그 거래를 반대로 하는 것이다 — 조인을 줄이는 대신 중복을 되살린다. 어느 쪽도 공짜가 아니므로, 판단은 「무엇을 지불할 것인가」로 내린다.

앞 세 행의 오른쪽 열은 같은 형태다 — 읽기를 싸게 만든 대가를 쓰기 쪽이 지불한다. 그래서 반정규화의 성패는 「얼마나 빨라졌나」가 아니라 「그 대가를 누가 어떻게 감당하기로 했나」에서 갈린다. 아래 3원칙을 순서대로 적용한다.

1. 먼저 정규화한다. 반정규화는 정규화된 모델이 있어야 되돌릴 수 있다.
2. 측정한 뒤에 한다. 실행계획·응답시간 데이터 없이 「느릴 것 같아서」 하는 반정규화는 부채다.
3. 동기화 책임을 명시한다. 트리거·애플리케이션·배치 중 무엇이 중복 값을 맞출지 문서에 남긴다.

중복 컬럼을 만든 사람은 그 순간 동기화 코드를 함께 쓰지만, 나중에 원본 컬럼을 수정하는 사람은 사본이 있다는 사실을 모른다. 값 불일치는 그렇게 생긴다.

NoSQL 데이터 모델링

NoSQL은 유연한 구조를 가지는 DBMS이기 때문에, 기존의 개체-관계 모델링을 그대로 적용하면 최종 물리 모델과 일치하기 어렵다. 그래서 NoSQL에서의 데이터 모델링은 애플리케이션(개발 관점)으로 접근해야 한다.

RDBMS 모델링과 갈라지는 지점은 2단계다. RDBMS에서는 모델을 먼저 세우고 쿼리가 그 위에서 작성되지만, NoSQL에서는 필요한 쿼리를 먼저 뽑고 그 쿼리가 모델을 정한다. 순서가 뒤집히므로, 나중에 새로운 조회 패턴이 생기면 모델을 다시 만들어야 하는 경우가 나온다.

디자인 패턴 3종

세 패턴의 대가 열을 나란히 읽으면 공통점이 보인다 — DBMS가 하던 일이 애플리케이션으로 넘어온다. 정합성 유지(역정규화), 스키마 해석(통합), 인덱스 갱신(인덱스 테이블)이 각각 그렇다. 앞 절의 RDBMS 반정규화가 「선택적으로 넘기는 것」이라면, NoSQL 모델링에서는 그것이 기본값이다.

단점의 두 번째 항목이 앞의 모델링 정의와 정확히 맞부딪힌다. 모델링이 주는 것 중 하나가 「조직이 필요로 하는 본질적 데이터의 정의」였는데, 쿼리에서 출발한 모델은 그 정의를 담지 않는다. 모델을 봐도 업무가 읽히지 않는다는 뜻이고, 그래서 NoSQL을 쓰더라도 개념 모델은 따로 유지하는 편이 낫다.

데이터 표준

데이터 표준은 데이터의 명칭·정의·형식·규칙에 대한 원칙을 수립해 전사적으로 적용하는 것이다. 표준이 없을 때 나타나는 증상은 구체적이다.

세 번째 행의 70%는 분석 인력이 모델링 부재의 비용을 뒤늦게 대신 치르고 있다는 뜻이다. 표준화는 네 단계로 진행한다.

마지막 단계가 없으면 앞의 셋은 공표된 문서로 남는다. 준수 검사가 표준을 살아 있게 한다.

세 번째와 네 번째 행이 비대칭인 것이 핵심이다. 한글명 하나에 뜻이 둘이면 금지, 뜻 하나에 한글명이 둘이면 허용이다. 앞은 이름에서 뜻을 복원할 수 없게 만들지만, 뒤는 물리명이 같으므로 복원에 지장이 없다.

표준 용어집은 용어명 / 물리용어명 / 도메인명 / 도메인물리명 / 인포타입명 / 용어정의 로 관리한다.

표준화의 진짜 효과는 「이름이 예뻐지는 것」이 아니다. 접미어(도메인)만 보고 타입과 길이를 알 수 있게 만드는 것이다. _AMT면 숫자10, _DTM이면 날짜 — 이 규칙이 서면 신규 테이블 설계 리뷰 시간이 급격히 줄고, 시스템 간 인터페이스 매핑 오류가 사라진다.

정리

모델링의 각 단계는 「무엇을 얻고 무엇을 지불하는가」로 요약된다. 「판단 기준」 열은 이 글의 정리다.

앞 세 행을 관통하는 질문은 하나다 — 되돌리는 비용이 얼마인가. 정규화는 되돌릴 수 있고(반정규화가 그것이다), 반정규화는 정규화된 모델이 남아 있을 때만 되돌릴 수 있으며, 운영 중인 데이터 구조 변경은 앞에서 본 6단계를 전부 치른다. 그래서 모델링에 쓰는 시간은 설계 품질의 문제이기 전에 나중에 지불할 금액을 지금 깎는 일이다.

모델이 정해지면 그 위에서 SQL이 돈다. 같은 데이터인데 어떤 쿼리만 느린 이유 — 파싱, 인덱스, 실행계획, 조인 — 와 언제 SQL 대신 모델을 손대야 하는지는 다음 편 SQL 실행과 인덱스가 받는다.