정규화 중심으로 배우는 DB 설계

 

 

 

데이터베이스를 설계할 때 가장 먼저 떠올려야 할 키워드는 정규화입니다. 정규화는 데이터를 중복 없이 정리해 무결성을 높이고, 변화에 유연한 구조를 만들기 위한 체계적 절차입니다. 전자상거래, 의료, 교육처럼 데이터가 빠르게 늘고 규칙이 자주 바뀌는 서비스에서 정규화는 비용을 절약하고 장애를 줄이는 안전장치가 됩니다. 데이터베이스 교재뿐 아니라 2024년 이후 공개된 최신 실무 글에서도, “정규화 수준을 올리고 역정규화를 선택적으로 적용할 것”이 성능과 품질을 동시에 얻는 핵심 전략으로 반복 강조됩니다. 검색엔진 최적화 관점에서는, 정규화 과정을 명확히 설명한 긴 글이 체류 시간을 늘리고 전문성 신호를 높여 애드센스 승인 가능성을 키우므로, 글의 구조와 표현도 중요합니다. 이번 글은 tavily로 최신 사례를 살펴본 뒤, 1NF부터 BCNF까지 핵심 개념과 실전 적용법, 그리고 성능을 위한 역정규화 균형점까지 한 번에 정리했습니다.  실무자가 참고할 수 있는 서술형 가이드를 제공하니, 데이터 모델을 점검하거나 새로 설계할 때 체크리스트처럼 활용해 보세요. 비개발자도 예시만 따라가면 쉽게 이해할 수 있도록 설명했습니다.

정규화의 필요성과 1~3NF 이해

정규화를 시작하는 이유는 세 가지입니다. 첫째, 중복된 데이터를 최소화해 저장 공간을 아끼고, 둘째, 삽입·수정·삭제 시 발생하는 이상 현상(Anomaly)을 없애며, 셋째, 비즈니스 규칙을 테이블 구조로 명확히 표현하는 것입니다. 이상 현상은 삽입, 갱신, 삭제 세 가지가 대표적이며, 모두 중복 데이터 때문에 발생합니다. 1NF는 모든 칼럼을 원자값으로 쪼개 반복 그룹을 제거합니다. 예를 들어 고객 연락처를 콤마로 묶어 저장하면 정렬, 검색, 변경이 모두 어렵습니다. 연락처를 별도 행이나 테이블로 분리하면 조회와 수정이 간결해집니다. 헬스케어 환자 기록처럼 주소, 연락처, 보험 정보가 섞인 필드를 분할하면 감사 로그 추적이 쉬워지고 개인정보 마스킹 작업도 단순해집니다. 2NF는 복합 기본 키 일부에만 의존하는 속성을 분리합니다. 수강 테이블에서 (학생 ID, 과목 ID)가 기본 키인데 과목명만 과목 ID에 의존한다면 과목 테이블로 떼어내 중복을 없애는 식입니다. “제품 ID, 창고 ID” 복합 키를 가진 재고 테이블에서도 창고 주소는 창고 ID에만 의존하므로 별도 테이블로 나누어야 합니다. 3NF는 간접 종속성을 제거합니다. 사원 ID → 부서 ID, 부서 ID → 부서장의 관계가 있다면 부서장은 부서 테이블로 이동시켜야 갱신 시 불일치가 사라집니다. 배송 시스템에서도 주문 ID → 고객 ID, 고객 ID → 등급 할인율과 같은 이행 종속을 분리하면 할인 정책 변경을 한 곳에서 적용할 수 있어 유지보수 비용이 줄어듭니다. 이 세 단계만으로도 대부분의 업무 시스템에서 무결성과 유지보수성이 크게 개선되며, 데이터 품질 지표(중복률, 오류 수정 시간)도 눈에 띄게 안정됩니다. 실무에서는 ERD를 그린 뒤 함수 종속성 목록을 적어가며 각 필드가 어느 키에 의존하는지 검증하는 체크리스트 방식이 가장 빠르게 효과를 줍니다. 이 과정을 문서화해 개발·운영팀이 공유하면, 신규 기능 설계 시 같은 실수를 반복하지 않는 학습 효과도 얻을 수 있습니다.

실무에서 만나는 BCNF와 고급 정규화

3NF를 통과했는데도 결정자가 후보 키가 아닌 함수 종속성이 남아 있다면 BCNF가 해결책입니다. 강의ID가 특정 교수 ID를 항상 결정하는 상황에서 (강의 ID, 교수 ID)를 기본 키로 두면 교수 ID가 후보 키가 아니므로 BCNF 위반입니다. 강의 테이블과 강의-교수 매핑 테이블을 분리하면 의존성이 명확해지고, 강의 배정 규칙이 바뀌어도 구조 변경이 최소화됩니다. 온라인 스토어에서도 “카테고리 ID가 항상 대표 브랜드를 결정”한다면 브랜드는 카테고리 테이블로, 상품-브랜드 매핑은 별도 테이블로 나눠야 합니다. 더 특수한 경우에는 4NF(다치 종속성 제거)와 5NF(조인 종속성 제거)가 등장합니다. 한 제품이 여러 브랜드와 여러 공급사를 동시에 가질 때처럼 독립된 다중 값이 섞이는 경우 4NF가 필요합니다. 복잡한 파트너십 계약처럼 “국가, 판매 채널, 프로모션”이 조합될 때 5NF가 요구되기도 합니다. 하지만 실무에서는 BCNF까지 만으로 충분한 경우가 대부분이며, 5NF까지 가면 테이블이 과도하게 쪼개져 JOIN 비용이 폭증할 수 있습니다. 팀 규모가 작거나 ORM 성능 튜닝 여력이 부족하다면 지나친 고급 정규화가 오히려 장애 원인이 될 수 있으니, 데이터 정확도 요구, 트랜잭션 특성, 운영 역량을 모두 고려해 깊이를 결정해야 합니다. 규칙을 바꾸지 않는 마스터 데이터는 BCNF로 단단히 묶고, 잦은 변동이 있는 거래 데이터는 3NF 수준에서 멈추는 혼합 전략이 실무에서 많이 쓰입니다. 결국 정규화 수준은 “데이터 품질 목표”와 “쿼리 비용”의 교차점에서 선택해야 하며, 이 균형을 수치로 표현하려면 무결성 이슈 발생률, 평균 쿼리 시간, 테이블 수 같은 지표를 함께 모니터링하면 좋습니다.

역정규화와 성능 튜닝 전략

실무에서 정규화는 “처음엔 촘촘히, 나중엔 필요한 곳만 완화”가 원칙입니다. OLTP 시스템에서는 3NF·BCNF 수준으로 모델링한 뒤, 읽기 비중이 매우 높은 화면에 한해 역정규화를 제한적으로 적용합니다. 예를 들어 주문 목록 조회에서 JOIN이 많아 느려진다면 자주 쓰는 요약 컬럼(상품명, 대표 이미지 URL, 최근 상태)을 캐싱 테이블로 중복 저장해 응답을 줄일 수 있습니다. 뉴스레터 구독처럼 단순 조회가 대부분인 테이블은 정규화를 유지하되, 데이터 웨어하우스 적재 시에는 요약 테이블을 별도로 만들어 분석 쿼리 비용을 낮추기도 합니다. 단, 원본 업데이트 트리거 또는 배치로 동기화 규칙을 명확히 해야 데이터 불일치를 막을 수 있습니다. 성능 최적화의 기본은 인덱스와 키 설계입니다. 외래 키에 적절한 인덱스를 두고, 과도한 범용 인덱스를 피하며, 통계 갱신을 자동화하면 JOIN 성능이 안정됩니다. 파티셔닝은 기간별 삭제·보관이 잦은 로그성 테이블에 효과적이고, 읽기 복제본은 조회 트래픽을 분산하는 데 유용합니다. 캐시 계층을 둘 때는 캐시 키를 정규화된 기본 키로 통일해 중복 캐시를 막는 것이 좋습니다. 마지막으로, 모델 변경 시에는 샘플 데이터를 넣고 EXPLAIN으로 실행 계획을 검증하며, 캐시 적중률과 락 경합을 모니터링해야 예상치 못한 병목을 막을 수 있습니다. 테스트 환경에서 부하 도구로 QPS·응답 시간 변화를 측정한 뒤 릴리스하는 습관을 들이면, 정규화와 역정규화 사이의 균형을 데이터로 확인할 수 있습니다. CI 파이프라인에 스키마 린터와 마이그레이션 자동 테스트를 넣어두면, 실수로 비정규화된 스키마가 배포되는 사고를 줄일 수 있습니다. 서비스가 성장하며 마이크로서비스로 분리될 때는 각 도메인이 자신의 데이터 주권을 유지하도록 경계를 다시 그어야 하며, 그 과정에서도 정규화 원칙은 데이터 계약을 명확히 하는 기준선이 되어 줍니다. 정규화 원칙을 지키되, 사용자 경험과 운영 비용 사이의 균형을 지속적으로 점검하는 것이 효율적인 DB 설계의 완성입니다.