Brain💡 핵심 인사이트
반정규화(비정규화)는 시스템의 조회 성능(Performance)을 극대화하기 위해, 정규화를 거쳐 깨끗해진 테이블을 '의도적으로' 정규화 이전처럼 뭉치거나 중복 데이터를 허용하도록 되돌려놓는 타협의 과정입니다.
데이터 무결성(일관성)이 깨질 위험을 감수하고서라도, 빠른 속도가 비즈니스에 더 중요할 때 최후의 수단으로 선택합니다.
Ⅰ. 반정규화의 등장 배경 (정규화의 배신)
테이블을 잘게 쪼개어 이상 현상(Anomaly)을 완벽히 잡은 3NF 상태의 데이터베이스. 하지만 실무 운영 환경에서는 기막힌 딜레마가 발생합니다.
- 조회(SELECT)의 늪: 쇼핑몰 메인 화면에 "회원 이름, 배송지 주소, 최근 주문한 상품명, 멤버십 등급"을 띄우려면, 쪼개져 있는
회원,주소,주문,등급4개의 테이블을 본드로 이어 붙여야(JOIN 연산) 합니다. - 성능 저하: 이 조인(Join) 연산은 CPU와 메모리를 미친 듯이 잡아먹습니다. 10만 명이 동시에 접속하면 조인 연산 부하로 인해 웹사이트 화면이 하얗게 멈춰버립니다.
"데이터 무결성을 지키려다 회사가 망하겠다! 데이터 쓰레기(중복)가 좀 생겨도 좋으니, 조인을 없애고 한 번에 읽게 만들어라!" ➔ 이것이 반정규화의 명분입니다.
Ⅱ. 반정규화를 수행하기 위한 3대 전제 조건
아무 때나 반정규화를 하면 쓰레기 DB가 됩니다. 엄격한 절차가 필요합니다.
- 완벽한 정규화의 선행: 반정규화는 정규화를 안 한 '비정규형' 테이블과는 다릅니다. 반드시 3NF 이상의 뼈 깎는 정규화를 마친 깨끗한 논리 모델 위에서 시작해야 합니다.
- 성능 저하의 명백한 증명: "그냥 조인이 많아서 느릴 것 같다"는 감으로 하면 안 됩니다. 테스트 결과 조인 비용이 너무 크거나, 대량의 데이터 범위를 자주 탐색하여 명백한 성능 저하가 확인될 때만 시행합니다.
- 무결성 훼손에 대한 대책 마련: 중복 데이터를 욱여넣었으니 갱신 이상(Update Anomaly)이 터질 수 있습니다. 이를 막기 위해 데이터 갱신 시 배치(Batch) 프로그램을 돌리거나 앱(Application)단에서 일관성을 맞춰주는 추가 코딩(보완책)이 필수적입니다.
Ⅲ. 트레이드 오프 (Trade-off) 요약
반정규화는 절대 공짜가 아닙니다.
- 얻는 것 (Get): SELECT (조회) 속도의 미친듯한 향상, 쿼리 작성의 단순함.
- 잃는 것 (Lose): INSERT/UPDATE 속도의 저하 (중복된 데이터를 모두 찾아서 고쳐야 함), 디스크 스토리지 용량 낭비 증가, 그리고 가장 뼈아픈 데이터 정합성(무결성) 훼손의 위험성.
📢 섹션 요약 비유: 정규화가 옷, 양말, 속옷을 **'각자의 서랍에 완벽하게 1개씩 분류(무결성)'**해둔 깔끔한 옷장이라면, 반정규화는 바쁜 아침(성능 요구)을 위해 **'의도적으로 양말과 속옷을 셔츠 주머니에 미리 쑤셔 넣어둔(중복 허용) 출근용 패키지'**를 만드는 것입니다. 아침에 1초 만에 옷을 입고 나갈 순 있지만, 속옷이 바뀌었을 때 패키지를 다 뜯어서 갱신해야 하는 관리의 고통이 수반됩니다.