성능 데이터 모델링, 정규화와 반정규화
설계 단계에서 성능을 결정짓는 두 축, 정규화와 반정규화가 실제로 어떻게 맞물리는지 정리한다.
성능 데이터 모델링, 반정규화만의 문제가 아니다
설계 단계에서 성능을 고려하지 않은 모델은, 아무리 좋은 서버와 SQL 튜닝을 얹어도 근본적인 한계에 부딪힌다. 실무에서 성능 저하가 생기면 개발자가 짠 SQL부터 의심받는 일이 많지만, 실제로는 테이블 설계 자체가 원인인 경우가 상당하다.
성능이 떨어지는 원인은 대개 셋 중 하나다. 데이터 모델 구조 자체의 문제, 대용량 데이터로 인한 불가피한 저하, 인덱스 특성을 무시한 설계다. 이 지점에서 흔한 오해가 하나 있다. 성능 데이터 모델링을 반정규화와 동의어로 여기는 것이다. 실제로는 정규화를 통해서도 성능을 끌어올릴 수 있고, 인덱스 특성에 맞춘 칼럼 순서 조정, 테이블 수직·수평 분할도 모두 성능 데이터 모델링의 영역이다.
성능 향상을 위한 비용은 프로젝트 초반에 반영할수록 저렴하다. 문제가 터진 뒤에야 SQL 튜닝이나 하드웨어 증설로 대응하면 재작업 비용이 눈덩이처럼 불어난다.
성능을 고려한 모델링 절차
정규화, 조회 성능을 깎아 먹지 않는다
정규화는 데이터 중복을 없애고 관심사별로 데이터를 흩어놓기 때문에 기본적으로 성능에 유리하다. 다만 엔터티 수가 늘면서 조인이 잦아져 조회가 느려지는 경우도 있어, 정규화와 반정규화 사이에는 트레이드오프가 존재한다.
여기서 자주 생기는 오해가 있다. "정규화를 하면 조회 성능이 항상 떨어진다"는 생각이다. 입력·수정·삭제 성능은 정규화할수록 대체로 좋아진다. 반면 조회 성능은 조건에 따라 좋아질 수도, 나빠질 수도 있다.
| 사례 | 내용 |
|---|---|
| PK 조인은 영향이 미미하다 | 2차 정규화로 분리된 두 테이블을 PK/Unique Index로 조인해도, 사용자가 체감할 만큼 성능이 떨어지지 않는다. |
| 정규화가 오히려 빠르다 | "2010년 이후 등록"처럼 조회 범위를 좁히는 조건에서는, 정규화된 테이블이 불필요한 중복 데이터를 읽지 않아 훨씬 빠르다. |
| 반복 칼럼의 함정 | 유형기능분류코드1, 2, 3…처럼 같은 성격의 칼럼이 나열된 테이블은 인덱스를 각각 만들어야 해 관리가 어렵고, 결국 인덱스를 포기해 성능이 떨어진다. 1차 정규화로 로우 단위로 풀어내면 인덱스 하나로 해결된다. |
정규화의 근거는 함수적 종속성(Functional Dependency)이다. 어떤 속성이 다른 속성을 유일하게 결정하는 관계, 예를 들어 주민등록번호가 이름·출생지·호주를 결정하는 관계를 파악해, 그 종속 관계에 맞게 데이터를 배치하는 것이 정규화의 본질이다. 프로젝트에서 정규화는 선택이 아니라 필수다.
반정규화, 무결성과 맞바꾸는 성능
반정규화는 정규화된 엔터티·속성·관계에 대해 성능 향상과 개발·운영의 단순화를 위해 중복·통합·분리를 수행하는 기법이다. 데이터 무결성이 깨질 위험을 감수하면서까지 적용하는 이유는 명확하다. 조회 시 디스크 I/O가 과도하거나, 조인 경로가 너무 멀어 성능 저하가 뻔히 보이는 상황이기 때문이다.
반정규화를 적용하기 전에 거치는 단계
- 대상을 조사한다. 접근 빈도가 높은 테이블, 대량 데이터의 잦은 범위 조회, 통계성 프로세스, 과도한 조인이 대상이다.
- 다른 방법이 없는지 먼저 검토한다. 뷰(View), 클러스터링, 인덱스 조정, 파티셔닝, 애플리케이션 캐싱을 먼저 살핀다. 뷰는 SQL을 단순하게 만들어줄 뿐, 그 자체로 조회 성능을 올려주지는 않는다.
- 그래도 필요하면 반정규화를 적용한다. 테이블, 칼럼, 관계 단위로 적용하며, 중복뿐 아니라 추가·분할·제거의 형태로도 나타날 수 있다.
관계 반정규화는 데이터 무결성에 영향을 주지 않으면서도 성능을 개선할 수 있는 방법이다. 서로 멀리 떨어진 엔터티 사이에 조인이 자주 걸린다면, 관계를 직접 연결해 조인 단계를 줄인다.
마스터 데이터(공급자)와 이력성 데이터(전화번호, 메일주소, 위치)가 1:M 관계로 분리된 사례를 보자. 가장 최근 값을 가져오려면 서브쿼리가 중첩된 복잡한 SQL이 필요하다. 최신 값을 마스터 테이블에 반정규화해두면 SQL이 단숨에 단순해지고 성능도 오른다. 분산 데이터베이스 환경에서도 비슷한 사례가 있다. 서버 A의 부서 테이블과 서버 B의 연계 테이블이 자주 조인되어야 한다면, 부서명을 서버 B에 반정규화해두는 것만으로 서버 간 DB Link 조인 자체를 없앨 수 있다.
정규화와 반정규화는 저울의 양쪽 추와 같다. 정규화만 밀어붙이면 성능 이슈가 불거지고, 반정규화를 과하게 적용하면 무결성이 위태로워진다. 그래서 반정규화를 적용할 때는 무결성을 지킬 프로세스적 장치를 반드시 함께 마련해야 한다.
'기초 CS > 데이터베이스' 카테고리의 다른 글
| 04. 관계형 데이터베이스와 DML (0) | 2026.08.03 |
|---|---|
| 02. 속성, 관계, 식별자 (1) | 2026.08.02 |
| 01. 데이터 모델링과 엔티티 (0) | 2026.08.01 |