정규화(normalization)와 비정규화(denormalization) 사이의 트레이드오프는 무엇인가?

Question

IT Interview Practice · Accepted Answer

**정규화**는 각 사실(fact)이 정확히 한 곳에만 존재하도록 데이터를 조직하여 중복을 제거합니다. **비정규화**는 읽기를 더 빠르게 하기 위해 의도적으로 데이터를 중복시킵니다. 대부분의 스키마는 정규화된 상태로 시작하고 측정 결과가 요구하는 곳에서만 비정규화합니다.

## 정규화 (3NF까지)

각 테이블은 하나의 엔티티를 기술하고, 관련 데이터는 외래 키로 참조됩니다.

```sql
-- Normalized: a customer's city is stored once
customers(id, name, city_id)
cities(id, name)
orders(id, customer_id, total)
```

- **장점** — 갱신 이상(update anomaly) 없음(도시 이름을 한 행에서 변경), 저장 공간 절약, 외래 키를 통한 무결성.
- **단점** — 읽기에 JOIN이 필요함. 여러 엔티티를 다루는 보고서는 다섯 개의 테이블을 조인할 수도 있습니다.

## 비정규화

```sql
-- Denormalized: city copied onto every order for fast reporting
orders(id, customer_id, city_name, total)
-- + a summary table maintained by the app or triggers
order_daily_totals(day, city_name, total_sales)
```

- **장점** — 조인이 줄고, 읽기가 빨라지며, 집계 비용이 저렴합니다.
- **단점** — 중복된 데이터를 동기화해서 유지해야 하고(쓰기가 늘고 불일치 위험), 저장 공간이 더 들며, 모든 쓰기 주체가 모든 복사본을 갱신하는 것을 잊지 말아야 합니다.

## 결정하는 방법

정확성을 위해 기본은 정규화입니다. EXPLAIN이 조인이 병목임을 보여준 후에만 **특정 핫 읽기 경로**를 비정규화하세요 — 그리고 원본(source of truth)은 정규화된 상태로 유지하면서, 다시 만들 수 있는 파생 복사본(요약 테이블, 구체화된 캐시)을 유지하는 편을 선호하세요.

## 왜 중요한가

이것은 스키마 설계의 핵심 트레이드오프입니다: 과도한 정규화는 대시보드를 기어가게 만들고, 과도한 비정규화는 조정 비용이 큰 불일치 데이터를 낳습니다. 데이터를 *왜* 중복시키는지, 그리고 복사본을 어떻게 신뢰할 수 있게 유지하는지를 아는 것이 확장되는 스키마와 썩어가는 스키마를 가릅니다.

정규화 (3NF까지)

비정규화

결정하는 방법

왜 중요한가

관련 질문