정규화를 해야 할까?
ERD를 설계하고 난 뒤, 한참을 들여다보면서 이런 고민이 들었다. "지금 이 구조, 이대로 괜찮을까? 혹시 정규화를 더 해야 하지 않을까?"
결론부터 말하자면, 지금 이 ERD 구조는 정규화가 충분히 잘 되어 있어서, 굳이 더 건드리지 않아도 된다. 실제로 운영해도 문제없는 수준이며, 정규화는 필요가 아닌 선택사항이라는 판단이 들었다. 하지만 이 판단에 도달하기까지, 스스로 몇 가지 기준을 가지고 하나하나 따져보았다.
정규화 단계 간단 정리
정규화는 데이터베이스 설계 시, 중복을 제거하고 논리적으로 구조화된 데이터를 만들기 위해 단계적으로 적용되는 과정이다. 아래는 가장 기본적인 세 가지 정규화 단계다:
-
1NF (제1정규형): 모든 컬럼이 원자값(더 이상 나눌 수 없는 값)으로만 구성되어야 함.
-
2NF (제2정규형): 기본 키가 복합 키일 경우, 부분 종속된 컬럼을 제거. 즉, 모든 컬럼이 전체 키에 종속되어야 함.
-
3NF (제3정규형): 기본 키가 아닌 컬럼들 간의 이행적 종속 제거. 즉, 비속성 컬럼이 다른 비속성 컬럼에 종속되지 않도록 함.
이번 프로젝트 ERD는 이미 이 세 단계의 기준을 충분히 만족하고 있기 때문에, "정규화가 되어 있는 상태"라고 판단했다.
내가 스스로 확인했던 정규화 기준
1. 중복 데이터 발생 가능성?
-
사용자 이름, 관리자 이메일, 질문 내용 등은 모두 각각 별도 테이블에서 관리되고 있다.
-
중복 데이터 없음 → OK
2. 의미가 중복되는 컬럼이 있는가?
-
예) user_id와 email처럼 같은 걸 표현하는 컬럼이 동시에 존재하지 않는다.
-
의미 중복 없음 → OK
3. ENUM 컬럼이 자주 바뀔 가능성은?
-
login_type, difficulty_level, log_type 등의 ENUM 값들은 고정적인 값이기 때문에, 관리 포인트로서도 안정적이다.
-
ENUM 사용 적절 → OK
4. 논리적으로 더 나누는 게 맞는 부분은?
-
예)
-
tbl_feedback에서 feedback_text와 star_structure를 분리하면 구조적으로 더 유연해질 수 있다.
-
tbl_ai_logs의 log_type도 나중에 코드 테이블로 따로 빼면 통계 처리나 필터링이 수월할 수 있다.
-
다만 이건 어디까지나 확장성이나 통계 기능이 중요해질 때의 얘기다.
내가 참고한 정규화 가이드라인
| 상황 | 내 판단 기준 |
|---|---|
| 지금처럼 MVP 개발 중이거나 초기 운영 단계 | 현재 구조 그대로 진행하는 것이 낫다 (단순하고 빠르게 구현 가능) |
| 로그나 통계 분석을 정말 많이 하게 될 경우 | 일부 테이블 분리 및 부분 정규화 고려 |
| 사용자 그룹이 다양해질 것 같을 때 | tbl_user 구조 확장 또는 사용자 유형 분리 고려 |
지금 상태에서 내린 결론
이 ERD는 처음부터 정규화를 염두에 두고 설계했기 때문에
-
중복도 없고,
-
컬럼 간 의미 중복도 없고,
-
ENUM도 안정적이고,
-
확장할 여지도 열려 있다.
따라서 지금은 정규화를 "추가로" 하지 않아도 괜찮다는 결론이 났다.
오히려 너무 일찍 정규화를 더 해버리면, 개발 복잡도만 올라가고, 유지보수도 어려워질 수 있다. 지금처럼 기능 중심 + 데이터 흐름 중심으로 깔끔하게 연결된 상태가 더 좋다고 판단했다.
향후 로그 규모가 커지거나, 통계 기반 기능이 늘어나면 그때 일부 테이블을 분리해도 늦지 않다.
