Hacker News 2026.04.15 23

데이터베이스 설계의 끝판왕, 제5정규형(5NF)을 제대로 이해해보자

정규화, 3NF까지만 배우고 끝내셨나요?

데이터베이스를 공부해본 분이라면 정규화(Normalization)라는 개념을 한 번쯤 들어보셨을 거예요. 보통 대학 수업이나 부트캠프에서 제1정규형(1NF), 제2정규형(2NF), 제3정규형(3NF)까지 배우고 "이 정도면 충분해"라고 넘어가는 경우가 많거든요. 운이 좋으면 BCNF(Boyce-Codd Normal Form)까지 살짝 맛보는 정도죠. 그런데 사실 정규화에는 그 위 단계가 더 있어요. 바로 제4정규형(4NF)과 제5정규형(5NF)인데요, 특히 5NF는 "더 이상 쪼갤 수 없는 완전체" 같은 존재라서, 데이터베이스 설계를 제대로 하고 싶다면 알아둘 가치가 충분해요.

최근 Database Design Book에서 5NF에 대한 깊이 있는 해설이 공개되었는데, 이 내용을 바탕으로 5NF가 뭔지, 왜 필요한지, 그리고 실무에서 어떻게 적용할 수 있는지 함께 살펴볼게요.

5NF가 뭔지 쉽게 설명해볼게요

정규화라는 건 쉽게 말해서 "데이터 중복을 없애기 위해 테이블을 잘 쪼개는 과정"이에요. 1NF부터 차근차근 올라갈수록 더 정교하게 쪼개는 건데요, 각 단계마다 제거하는 "문제"가 달라요.

3NF까지는 주로 함수 종속성(Functional Dependency)이라는 걸 다뤄요. 이게 뭐냐면, "학번을 알면 이름을 알 수 있다"처럼 하나의 값이 다른 값을 결정하는 관계를 말해요. 이런 관계가 꼬이면 데이터가 중복되거나 업데이트할 때 불일치가 생기거든요.

4NF에서는 다치 종속성(Multi-Valued Dependency)을 제거해요. 예를 들어, 한 명의 교수가 여러 과목을 가르치고 동시에 여러 연구 프로젝트를 수행한다면, 이 두 가지 독립적인 다대다 관계가 한 테이블에 섞여 있으면 문제가 생기거든요.

그리고 5NF는 여기서 한 발 더 나가요. 5NF는 조인 종속성(Join Dependency)을 다루는데요, 이건 "세 개 이상의 테이블을 조인해야만 원래 데이터를 복원할 수 있는 경우"를 말해요. 다시 말해, 테이블을 두 개로 쪼개는 것만으로는 부족하고, 세 개 이상으로 분해해야 중복 없이 깔끔하게 정리되는 상황이 있다는 거예요.

구체적인 예시로 보면 이해가 빨라요

고전적인 예시를 하나 들어볼게요. 공급업체(Supplier), 부품(Part), 프로젝트(Project) 세 가지 엔티티가 있다고 해봐요. "공급업체 A가 부품 X를 프로젝트 P에 납품한다"는 관계를 하나의 테이블로 관리하면, 얼핏 깔끔해 보여요. 그런데 여기서 이런 비즈니스 규칙이 있다고 해볼게요: "공급업체 A가 부품 X를 취급하고, 공급업체 A가 프로젝트 P에 참여하고, 부품 X가 프로젝트 P에서 쓰인다면, 반드시 공급업체 A가 부품 X를 프로젝트 P에 납품한다."

이런 규칙이 성립하면, 세 개의 이진 관계(공급업체-부품, 공급업체-프로젝트, 부품-프로젝트)로 분해해도 원래 데이터를 완벽하게 복원할 수 있어요. 이렇게 분해하면 중복이 줄어들고, 데이터 무결성도 훨씬 좋아지거든요. 이 상태가 바로 5NF예요.

반대로 이 규칙이 성립하지 않는다면, 즉 세 엔티티 사이의 관계가 독립적으로 결정되지 않는다면, 세 개로 쪼개면 정보가 손실돼요. 이 경우는 원래의 3자 관계 테이블을 유지해야 해요. 5NF의 핵심은 바로 이 판단에 있어요. "이 테이블을 더 쪼갤 수 있는가, 없는가?"를 정확히 아는 거죠.

실무에서 왜 중요한가요?

솔직히 말하면 대부분의 CRUD 애플리케이션에서 5NF까지 신경 쓸 일은 많지 않아요. 3NF나 BCNF 수준이면 충분한 경우가 대부분이거든요. 하지만 복잡한 비즈니스 도메인을 다루는 엔터프라이즈 시스템이나, 데이터 웨어하우스 설계, 혹은 마스터 데이터 관리(MDM) 같은 영역에서는 이야기가 달라져요.

특히 여러 엔티티 간의 복잡한 다대다 관계가 얽혀 있을 때, 5NF를 모르면 "왜 이 테이블에서 이상한 중복 데이터가 자꾸 생기지?" 하는 문제를 만날 수 있어요. 그리고 ORM(Object-Relational Mapping)에 너무 의존하다 보면 이런 설계 고민 자체를 건너뛰게 되는데, 데이터가 커지고 쿼리가 복잡해질수록 정규화 수준의 차이가 성능과 유지보수에 확실히 영향을 미쳐요.

비슷한 주제로 더 공부하고 싶다면

데이터베이스 정규화의 이론적 토대는 에드거 코드(Edgar F. Codd)와 로널드 페이긴(Ronald Fagin)의 연구에서 나왔어요. 최근에는 NoSQL이나 비정규화(Denormalization) 트렌드가 강하다 보니 정규화가 구식처럼 느껴질 수 있는데요, 사실 정규화를 제대로 아는 사람이 비정규화도 잘 해요. "어떤 중복을 의도적으로 허용하는지"를 정확히 알아야 하니까요. 요즘 뜨는 이벤트 소싱(Event Sourcing)이나 CQRS 패턴도 결국은 읽기용 비정규화와 쓰기용 정규화를 분리하는 거라고 볼 수 있어요.

한국 개발자에게 주는 시사점

한국 IT 업계에서는 JPA나 Django ORM 같은 도구를 많이 쓰다 보니, 테이블 설계를 코드의 모델 클래스에 맡기는 경우가 많은데요. 기본적인 정규화 이론을 제대로 알고 있으면, 모델을 설계할 때 "이 관계 테이블을 왜 이렇게 쪼개야 하는지"를 자신 있게 설명할 수 있어요. 면접에서도 "정규화를 3NF까지만 아는 사람"과 "5NF까지 이해하고 비정규화의 트레이드오프를 설명할 수 있는 사람"은 확실히 인상이 달라요.