정규화와 비정규화: 데이터 중복을 줄이면서도 성능을 지키는 테이블 설계

테이블이 커질수록 “중복”이 성능과 품질을 같이 흔든다

같은 고객 이름이 여러 테이블에 반복 저장되고, 한 번 수정하려다 누락이 생긴 적이 있는가.

조회는 느려지는데, 중복을 없애자니 조인이 늘어서 더 느려질 것 같아 망설여진 적이 있는가.

정규화와 비정규화는 이 딜레마를 “원칙”과 “조건”으로 정리해주는 설계 언어다.

• 중복이 만드는 문제: 갱신 누락, 불일치, 용량 증가
• 정규화가 해결하는 것과, 정규화만으로 부족해지는 순간
• 비정규화가 필요한 조건과, 함정이 되는 패턴
• 선택 기준 비교표와 YES/NO 체크리스트
• 주문 화면이 느린 사례로 보는 점검 절차

정규화와 비정규화는 “저장”이 아니라 “변경과 조회의 균형”을 다루는 기술이다

정규화: 중복을 줄이고, 데이터의 사실을 한 곳에 모으는 방식

정의: 한 사실(예: 고객의 전화번호, 상품의 기본 정보)은 한 장소에만 저장하도록 테이블을 쪼개고 관계로 연결하는 설계 방식이다.

핵심 특징: 중복 저장을 줄여 갱신 시 불일치가 줄어들고, 데이터 의미가 명확해진다.

• 수명 관점: “오래 유지되는 사실”을 분리해 두면 변경 비용이 낮아진다.
• 범위 관점: 한 사실이 여러 업무 흐름에 쓰이더라도, 원본은 한 테이블로 고정된다.
• 원리 관점: 외래키로 연결하여 “같은 값 복사” 대신 “참조”로 재사용한다.
• 저장 형태: 문자열을 포함한 값이 그대로 저장되지만, 의미 단위가 분리되어 중복 문자열이 줄어든다.

주의점: 조회 시 조인이 늘어나면서, 자주 쓰는 화면에서 지연이 생기기 쉽다. 인덱스가 부족하거나 조인 조건이 흐리면 문제가 빠르게 커진다.

주의점: “정규형을 맞추는 것”이 목표가 되면, 실제 조회 패턴과 멀어져 설계가 과하게 쪼개질 수 있다.

비정규화: 조회를 빠르게 만들기 위해, 일부 중복을 의도적으로 허용하는 방식

정의: 조회를 단순화하거나 계산을 줄이기 위해, 원래는 분리되어야 할 값을 테이블에 함께 저장하거나 요약값을 보관하는 설계 방식이다.

핵심 특징: 조인 수를 줄이거나, 자주 계산되는 값을 미리 저장해 화면 응답을 빠르게 만드는 데 유리하다.

• 수명 관점: “자주 바뀌지 않는 값”을 복제하면 갱신 부담이 상대적으로 낮다.
• 범위 관점: 특정 화면/리포트처럼 조회 경로가 고정된 곳에서 효과가 크다.
• 원리 관점: 원본 테이블의 참조 대신, 값 자체를 담아 조회 단계를 줄인다.
• 삭제/정리 관점: 중복 값이 늘어나므로, 정합성을 유지하는 정리 규칙이 반드시 필요하다.

주의점: 값이 여러 곳에 복제되면 “어디가 진짜인가”가 흐려진다. 갱신 누락이 생기면 데이터가 조용히 깨진다.

주의점: 비정규화는 성능 문제를 가리는 임시 처방이 될 수 있다. 인덱스, 쿼리, 캐시로 해결 가능한 문제인지 먼저 확인해야 한다.

두 방식은 서로 반대가 아니라, “원칙은 정규화, 조건이 맞으면 비정규화”로 함께 쓰는 경우가 많다.

 

정규화가 중복과 갱신 오류를 줄이는 흐름

 

정규화 vs 비정규화, 선택을 흔들지 않는 비교 기준

설계를 고를 때 “빠르게 할까, 깔끔하게 할까”로만 생각하면 결론이 반복적으로 뒤집힌다. 변경 빈도, 조회 패턴, 정합성 비용을 같이 놓고 판단해야 한다.

 

조회 패턴으로 결정하는 비정규화 판단 플로우

 

항목	정규화	비정규화
목표	중복 감소, 정합성 유지, 변경 비용 절감	조회 단순화, 응답 속도 개선
장점	갱신 누락/불일치 위험 감소, 데이터 의미가 선명함	조인/계산 감소, 특정 화면에서 빠른 조회
단점	조인 증가로 조회가 느려질 수 있음	중복으로 정합성 관리 비용 증가
잘 맞는 상황	변경이 잦고, 여러 업무가 같은 데이터를 공유함	조회가 압도적으로 많고, 조회 경로가 비교적 고정됨
대표 위험	과도한 분해로 복잡도 증가	갱신 누락으로 데이터 불일치 고착

표 제목: 정규화 vs 비정규화 핵심 비교

어떤 상황이면 무엇을 쓰는가: YES/NO 체크리스트

• 질문: 같은 값을 여러 테이블에 복사해 두고 자주 수정하는가. YES: 정규화 쪽으로 설계를 되돌리는 편이 안정적이다. NO: 다음 질문으로 넘어간다.
• 질문: 특정 화면/리포트가 트래픽 대부분을 차지하고, 조인 때문에 지연이 발생하는가. YES: 비정규화 후보가 된다. NO: 인덱스와 쿼리 최적화를 먼저 검토한다.
• 질문: 복제하려는 값이 “거의 안 바뀌는 값”인가. YES: 비정규화 리스크가 낮다. NO: 복제 대신 캐시/요약 테이블/머티리얼라이즈드 뷰 같은 대안을 우선 본다.
• 질문: 중복 값이 틀려도 바로 탐지할 수 있는 검증 규칙(배치 점검, 트리거, 애플리케이션 갱신 루틴)이 있는가. YES: 비정규화 운영이 가능하다. NO: 비정규화로 인한 불일치가 장기 비용으로 남기 쉽다.
• 질문: “원본 테이블”이 무엇인지 팀이 합의하고 있는가. YES: 혼선이 줄어든다. NO: 비정규화를 시작하면 진실의 근원이 분산된다.

실제 상황 1개로 보는 선택: 주문 상세 화면이 느려지는 경우

문제: 쇼핑몰 주문 상세 화면을 열 때 고객 이름, 주소, 상품명, 옵션, 배송 상태가 한 번에 보여야 하는데, 주문 건수가 늘수록 화면이 느려진다.

왜 발생: 정규화된 구조에서 주문, 주문아이템, 고객, 주소, 상품, 상품옵션을 조인하는 쿼리가 길어지고, 조건에 맞는 인덱스가 부족하면 디스크 접근과 정렬 비용이 커진다.

어떤 저장소가 적합: 원칙은 정규화를 유지하되, “주문 시점에 고정되는 값”은 주문 스냅샷으로 함께 저장하는 비정규화가 후보가 된다. 예를 들어 주문 당시의 배송지 주소 문자열, 상품 표시명 같은 값은 이후 원본이 바뀌어도 주문 기록과 분리되어야 하는 경우가 있다.

잘못 쓰면 어떤 문제: 고객 주소를 주문 테이블에 복제했는데, 주소 변경 정책이 “과거 주문도 최신 주소로 바꿔야 한다”라면 복제는 곧 불일치 위험이 된다. 또한 상품명이 바뀔 때 과거 주문 표기까지 바꿔야 하는지 기준이 없으면 데이터가 흔들린다.

확인/해결: 먼저 느린 원인이 조인 자체인지, 인덱스 부재인지, 정렬/필터 조건인지 분리해야 한다. 인덱스 추가만으로 해결되는 경우가 많고, 그 다음 단계에서 비정규화를 검토하는 편이 안정적이다.

브라우저에서 확인하는 방법: 관리자 콘솔로 병목을 찾는 순서

1. DB 관리자 페이지(예: 클라우드 DB 콘솔, phpMyAdmin, 웹 기반 SQL 편집기)를 브라우저에서 연다.
2. 문제가 되는 주문 상세 조회 쿼리를 “조건을 좁힌 버전”으로 먼저 실행해 응답 시간을 기록한다.
3. 같은 화면에서 실행 계획(EXPLAIN 또는 유사 기능)을 확인해, 어떤 테이블에서 전체 스캔이 발생하는지 본다.
4. 조인 키(예: 주문아이디, 고객아이디, 상품아이디)와 필터 조건(예: 기간, 상태)에 맞는 인덱스가 있는지 점검한다.
5. 인덱스를 추가한 뒤 동일 쿼리를 다시 실행해, 지연이 줄어드는지 비교한다.
6. 인덱스와 쿼리 조정 후에도 특정 화면만 계속 느리면, 주문 스냅샷 컬럼(주문 당시 주소/상품표시명) 같은 제한적 비정규화를 후보로 올리고, 갱신 규칙을 문서로 고정한다.

결론

정규화는 중복을 줄여 갱신 누락과 불일치를 낮추는 방향이다.

비정규화는 조회가 압도적으로 많은 지점에서, 조건을 걸어 성능을 끌어올리는 방향이다.

인덱스와 쿼리 점검으로 해결되는지 먼저 확인한 뒤, 필요한 만큼만 비정규화를 적용하는 편이 운영이 단단해진다.

• 다음에 같이 보면 좋은 주제: 인덱스가 조인 성능에 미치는 영향과 설계 기준
• 다음에 같이 보면 좋은 주제: 실행 계획(EXPLAIN) 읽는 법과 병목 찾는 순서

FAQ

정규화는 몇 정규형까지 해야 하는가

형식 자체보다 “불일치가 실제로 생길 중복이 남아 있는가”를 기준으로 보는 편이 낫다. 중복으로 인해 갱신 누락이 발생하는 지점부터 분리해도 설계 품질이 크게 오른다.

비정규화는 언제부터 위험해지는가

복제한 값이 자주 바뀌는데 갱신 규칙이 없을 때 위험이 커진다. 원본과 복제본이 동시에 존재한다는 사실만으로도 운영 비용이 생기므로, 검증과 정리 절차가 준비되지 않으면 불일치가 쌓인다.

정규화를 유지하면서 성능을 올리는 대표 방법은 무엇인가

조인 키와 필터 조건에 맞는 인덱스를 설계하고, 자주 쓰는 조회를 기준으로 쿼리를 단순화하는 방법이 먼저다. 그 다음에도 특정 화면이 느리면 캐시나 요약 테이블 같은 단계적 대안을 검토할 수 있다.