데이터 정규화, ERD & 변경 영향도 분석
— 코드 한 줄 없이 이해하기

00왜 이 학습이 필요한가요?

목적이 명확하지 않은 정규화는 암기해야 할 규칙에 불과합니다.

01병목 ①: 정규화 — "모든 것을 망치는 엑셀 시트 하나"

어려운 정의 대신 현실의 데이터 통증에서 출발해 봅시다.

1-0. 멀쩡해 보이는 엑셀 시트

온라인 강의 플랫폼을 만든다고 가정합시다. 처음에는 시트 하나로 모든 것을 기록합니다.

이 시트는 이미 3가지 사고(이상 현상, Anomaly)를 예약해 두었습니다.

1-1. 1NF — "셀 하나에는 값 하나만"

확인할 질문: 쉼표로 여러 값을 구겨 넣은 셀이 있는가?

표 A에서 수강 과목: "AI 기획, 데이터 분석"이 바로 그 사례입니다. "AI 기획 수강생이 몇 명인가?"를 집계하려면 텍스트를 쪼개야 하므로 관리가 복잡해집니다.

해결책: 행을 분리합니다. 한 셀에 하나의 값만 넣습니다 (김철수 행을 2개로 분리).

1-2. 2NF — "이름표 전체가 결정하는 정보만 남기기"

1NF 적용 후 각 행은 (수강생 + 과목)이라는 2 부분 조합 이름표(식별자)로 구분됩니다.

확인할 질문: 이 셀의 값을 결정할 때 이름표 두 쪽이 모두 필요한가, 아니면 한 쪽만 필요한가?

즉 2NF = "이름표 절반만으로 결정되는 컬럼은 그 절반을 따라 별도 테이블로 이동한다." 이 과정을 통해 수정 이상이 해결됩니다 (수강생 테이블에서 연락처를 한 번만 수정하면 끝).

1-3. 3NF — "옆 컬럼이 결정하는 정보는 따로 빼기"

분리된 과목 테이블을 봅시다: 과목ID, 과목명, 강사명, 강사연락처.

확인할 질문: 이 컬럼은 이름표(과목ID)가 결정하는가, 아니면 옆에 있는 다른 컬럼이 결정하는가?

• 강사연락처는 과목이 아니라 강사가 누구인가에 의해 결정됩니다.
• 과목ID → 강사명 → 강사연락처 순으로 결정되며, 이를 이행적 종속(Transitive Dependency)이라 부릅니다.
• 강사가 연락처를 바꾸면 그 강사가 가르치는 모든 과목 행을 수정해야 하는 수정 이상이 다시 발생합니다.

해결책: 강사 테이블을 새로 만들고 과목 테이블에는 강사ID만 남겨둡니다.

02병목 ②: ERD & 카디널리티 — "테이블 노선도"

기호 자체는 어렵지 않습니다. 어떤 기호를 선택해야 할지 결정하는 기준을 배우는 것이 핵심입니다.

2-1. ERD는 지하철 노선도입니다

ERD (Entity Relationship Diagram)란 쉽게 말해 "무엇이 존재하고 어떻게 연결되어 있는지 보여주는 그림"입니다.

• Entity (엔티티) = 테이블 1개 = 역 하나. 수강생, 과목, 강사.
  구분하는 법: 서비스가 독립적으로 수량을 세고 관리해야 하는 명사. "수강생 3명, 과목 5개"처럼 셀 수 있다면 엔티티입니다.
• Attribute (속성) = 컬럼 = 해당 역의 세부 정보. 이름, 연락처.
• Relationship (관계) = 선 = "수강생이 과목을 수강 신청한다."
• Cardinality (수량성) = 선 끝의 기호 = 몇 대 몇 관계인가.

2-2. 관계 수량성 결정법: 양방향으로 2번 질문하기

↑ 1개의 엑셀 시트가 4개의 정규화된 테이블로 분리되었습니다. 수강생-과목 N:M 관계가 수강신청 연결 테이블을 통해 1:N 2개로 풀린 점에 주목하세요.

2-3. 기호 읽는 법 (Crow's Foot 까마귀 발 표기법)

작은 동그라미는 "비어있어도 됨(선택)"을 의미합니다. 강사가 과목을 아직 배정받지 않아도 존재할 수 있다면 ||--o{를 씁니다. 반드시 최소 1개 이상 가져야 한다면 ||--|{를 씁니다. 이 차이가 나중에 "필수 입력 항목인가?" 규칙이 됩니다.

2-4. 외래키(FK) & 참조 무결성 — "존재하지 않는 고객의 주문은 불가능하다"

• 외래키 (Foreign Key, FK) = 다른 테이블을 가리키는 손가락. ENROLMENT.student_id는 STUDENT 테이블을 가리킵니다.
• 참조 무결성 (Referential Integrity) = 손가락이 가리키는 대상이 실제 존재해야 한다는 규칙.
• 무결성이 깨지는 경우: 수강생을 삭제했는데 수강신청 행이 그대로 남아 유령 손가락이 되는 경우.

오늘 팀이 결정해야 할 사항: "사용자가 계정을 탈퇴(삭제)할 때 관련 수강/결제 기록도 삭제할 것인가, 보존할 것인가?" — 이는 기술이 아닌 비즈니스 정책 문제입니다. 환불, 정산, 리포팅이 이 결정에 달려있으므로 기획자와 팀이 직접 결정해야 합니다.

03병목 ③: 변경 영향도 분석 — "아직 만든 것도 없는데 왜 분석하나요?"

아직 존재하지 않는 코드가 깨질 것을 상상해야 해서 어렵게 느껴집니다.

3-1. 컬럼 하나 변경이 일으키는 도미노 효과

↑ 컬럼 이름 하나 바꾸었을 뿐인데 최소 5곳이 흔들립니다. 그중 3곳은 코드가 아닌 문서와 사람입니다.

이 도미노 현상이 바로 "Task 02(용어 표준화)가 왜 중요한가?"에 대한 답입니다. 처음에 용어를 통일해 두면 이 도미노 현상 자체가 발생하지 않습니다. 용어 사전 정립은 가장 저렴하게 가입하는 보험입니다.

3-2. 변경 위험도 3단계 평가

3-3. 변경 영향도 보고서 템플릿

Task 03 산출물로 아래 표 형식을 그대로 활용할 수 있습니다.

04Codex AI 효율적인 활용 프롬프트

오늘 AI는 DB 설계자가 아니라 까칠한 검토자입니다. AI 답을 검증 없이 복사하면 왜 그것이 맞는지 배울 수 없습니다.

실습에 바로 사용하는 5가지 프롬프트

1. [Task 01] "이 회의록에서 엔티티 및 속성 후보를 도출해 줘. '독립적으로 수량을 세고 관리할 수 있는가?'를 기준 삼아 실제 엔티티인지 단순 속성인지 타당성을 평가해 줘."
2. [Task 01] "이 ERD 구조에서 N:M 관계를 모두 찾아줘. 각 N:M 관계별로 필요한 연결 테이블(Junction Table)과 관계 자체에 속해야 할 속성을 제안해 줘."
3. [Task 01] "우리 테이블 구조를 1NF, 2NF, 3NF 관점에서 각각 평가해 줘. 위반 요소가 있다면 원인이 되는 함수 종속성을 지적해 줘. 수정하지 말고 진단만 해줘."
4. [Task 02] "이 컬럼명 목록에서 의미는 같으나 표기가 다른 용어 그룹(user_name / userName / customer 등)을 묶어줘. 각 그룹별로 대표 표준 용어를 제안하고 이유를 설명해 줘."
5. [Mission 02] "이 스키마 구조에서 참조 무결성이 깨질 수 있는 시나리오 3가지와 두 사용자가 동시에 같은 데이터를 수정할 때(동시성 충돌) 발생하는 문제 3가지를 찾아줘. 서비스 맥락은 ___이야."

05최종 자가 점검 (Exit Check)

모두 체크했나요? 그렇다면 Day 4(API 설계) 준비가 완료되었습니다.

06용어 요약 사전