데이터베이스 정규화와 반정규화의 차이점과 적용 기준을 설명해주세요.

정규화(Normalization)는 데이터 중복을 줄이고 무결성을 높이기 위해 테이블을 적절히 분리하는 설계 방식입니다. 반정규화(Denormalization)는 조회 성능이나 구현 단순화를 위해 의도적으로 중복을 허용하는 방식입니다.

정규화가 필요한 이유

하나의 테이블에 여러 의미의 데이터가 섞이면 중복과 이상 현상이 발생합니다.

orders
------------------------------------------------
order_id | user_id | user_name | product_id | product_name
1        | 10      | Kim       | 100        | Keyboard
2        | 10      | Kim       | 101        | Mouse

문제:

• 같은 사용자 이름이 여러 행에 반복됩니다.
• 사용자 이름이 바뀌면 여러 행을 수정해야 합니다.
• 주문이 없는 사용자는 저장하기 어렵습니다.
• 일부 주문 삭제가 사용자 정보 손실로 이어질 수 있습니다.

정규화 예

users
----------------
id | name
10 | Kim

products
----------------
id  | name
100 | Keyboard
101 | Mouse

orders
------------------------
id | user_id | product_id
1  | 10      | 100
2  | 10      | 101

사용자, 상품, 주문의 책임을 분리해 중복을 줄입니다.

주요 정규형

실무에서는 보통 3NF 수준을 기본으로 삼고, 성능 요구에 따라 조정합니다.

반정규화

반정규화는 정규화된 구조를 일부 되돌려 중복 데이터를 저장하는 것입니다.

예:

order_summary
--------------------------------------
order_id | user_name | total_price | item_count
1        | Kim       | 50000       | 3

이 데이터는 원본 테이블에서 계산할 수 있지만, 매번 조인과 집계를 수행하면 비용이 클 수 있습니다.

반정규화가 적합한 경우

• 읽기 요청이 매우 많고 조인 비용이 큰 경우
• 통계, 랭킹, 대시보드처럼 집계 결과를 자주 조회하는 경우
• 이력 데이터처럼 당시 값을 보존해야 하는 경우
• CQRS처럼 쓰기 모델과 읽기 모델을 분리하는 경우

예를 들어 주문 내역에는 현재 상품명보다 "주문 당시 상품명"을 저장하는 것이 맞을 수 있습니다.

반정규화의 위험

• 데이터 중복으로 저장 공간 증가
• 원본과 복제 데이터의 불일치 가능성
• 업데이트 로직 복잡도 증가
• 어떤 데이터가 진실의 원천인지 모호해질 수 있음

정리

기본은 정규화로 데이터 무결성과 변경 용이성을 확보하는 것입니다. 이후 실제 쿼리 패턴, 성능 병목, 조회 빈도를 근거로 필요한 부분만 반정규화해야 합니다. 반정규화는 "성능을 위한 의식적인 중복"이지, 설계를 단순히 대충 하는 것이 아닙니다.

정규화와 반정규화의 균형

정규화는 중복을 줄이고 데이터 무결성을 높이기 위해 테이블을 분리하는 과정입니다. 반정규화는 조회 성능이나 구현 단순성을 위해 의도적으로 중복을 허용하는 설계입니다.

정규화 예시
users(id, name)
orders(id, user_id, total_price)

반정규화 예시
orders(id, user_id, user_name_snapshot, total_price)

주문 시점의 사용자 이름을 보존해야 한다면 user_name_snapshot처럼 스냅샷 컬럼을 두는 것이 오히려 도메인 요구사항에 맞습니다.

적용 기준

주의할 점

반정규화는 “성능을 위해 어쩔 수 없이 하는 중복”입니다. 동기화 책임이 생기므로 어떤 이벤트에서 어떤 컬럼을 갱신할지 명확해야 합니다. 캐시, materialized view, 검색 인덱스도 넓은 의미의 반정규화로 보고 운영 비용을 함께 고려해야 합니다.