402. 삽입 이상 (Insertion Anomaly)

⚠️ 이 문서는 데이터베이스 테이블 설계를 잘못했을 때, **새로운 데이터를 집어넣으려고(INSERT) 해도 쓸데없는 가짜 데이터까지 억지로 같이 끼워 넣어야만 저장이 가능해지는 끔찍한 부작용인 '삽입 이상'**을 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 정규화를 하지 않아 여러 가지 주제의 데이터가 한 테이블에 뭉쳐 있을 때 발생한다. 주로 기본 키(PK)의 제약조건 때문에 원치 않는 Null 값을 강제로 넣어야 하는 상황을 말한다.

원인: 개체 무결성 제약조건에 의해 "기본 키는 절대 Null이 될 수 없다"는 규칙 때문에 발생한다.

해결책: 삽입 이상을 일으키는 억지스러운 속성들을 떼어내서 **새로운 테이블로 분리(정규화)**하면 깔끔하게 해결된다.

Ⅰ. 개요: 배보다 배꼽이 큰 데이터 (Context & Necessity)

"우리 회사에 새로운 '클라우드 부서'가 생겼어. 아직 소속된 직원은 한 명도 없지만 일단 부서부터 DB에 등록해 놔!"

초보 개발자가 만든 직원_테이블(사번, 이름, 부서명, 부서전화번호)이 있다. (기본 키는 사번이다.) 클라우드 부서를 등록하려고 INSERT 쿼리를 날려본다.

부서명: 클라우드
부서전화번호: 02-123-4567
사번: ??? (아직 직원이 없는데?)

결과: DB 엔진이 에러를 뿜는다. "사번(기본 키)이 없잖아! 기본 키는 널(Null)이 될 수 없어!" 결국 개발자는 '클라우드 부서'를 등록하기 위해 '9999'라는 가짜 유령 직원 데이터를 억지로 만들어내서 같이 Insert 해야 한다. 이것이 바로 **삽입 이상(Insertion Anomaly)**이다.

📢 섹션 요약 비유: 삽입 이상은 **'햄버거 세트만 파는 식당'**과 같습니다. 콜라(부서 정보)만 딱 하나 마시고 싶은데, 단품으로 안 파니까 억지로 먹지도 않을 햄버거(가짜 직원 데이터)까지 돈을 주고 세트로 같이 시켜야만 하는 낭비 상황입니다.

Ⅱ. 삽입 이상이 발생하는 구체적 사례 ★

시험에 가장 자주 나오는 사례를 테이블로 분석해 보자.

학번 (PK)	과목코드 (PK)	성적	과목명
1001	CS101	A	컴퓨터
1002	EN101	B	영 어

(기본 키는 학번 + 과목코드)

학교에서 **'MA101 (수학)'**이라는 새로운 과목을 개설했다. 아직 수강 신청 기간이 아니라서 이 과목을 듣는 학생은 단 한 명도 없다.

INSERT INTO 수강 (과목코드, 과목명) VALUES ('MA101', '수학');
에러 발생!: "기본 키의 일부인 학번이 비어있습니다." (개체 무결성 위반)
수학 과목을 등록하려면 수강하지도 않은 가짜 학생 번호(예: 0000)를 억지로 넣어야 한다.

Ⅲ. 해결책: 정규화를 통한 테이블 분리

삽입 이상이 생기는 근본적인 이유는 **'학생이 수강하는 정보'**와 **'과목 자체에 대한 정보'**라는 두 개의 완전히 다른 주제가 하나의 테이블에 섞여 있기 때문이다.

문제를 일으킨 부분(과목 정보)을 도려내서 새로운 테이블로 분리한다. (제2정규형 적용 - 397번 문서)

수강_테이블 [학번, 과목코드, 성적]
과목_테이블 [과목코드, 과목명]

이제 'MA101 수학' 과목을 신설하고 싶으면? 그냥 2번 과목_테이블에 딱 1줄 INSERT하면 끝난다. 1번 테이블(수강)은 건드릴 필요도 없고, 학생이 없어도 에러가 나지 않는다. 완벽하게 해결되었다.

┌──────────────────────────────────────────────────────────────┐
│           삽입 이상(Insertion Anomaly) 발생 구조 시각화               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ ❌ 정규화 전 (하나의 테이블) ]                                     │
│  [ 학번 | 과목코드 | 성적 | 과목명 ]                                │
│    ?       MA101    ?     수학   ◀── Insert 실패! (학번이 PK라서) │
│                                                              │
│ [ 🟢 정규화 후 (테이블 분리) ]                                      │
│  1. 수강: [ 학번 | 과목코드 | 성적 ]                                 │
│                                                              │
│  2. 과목: [ 과목코드 | 과목명 ]                                      │
│            MA101     수학      ◀── Insert 성공! (과목코드가 PK니까)│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"데이터의 억지스러운 결합이 이상(Anomaly)을 낳는다." 데이터베이스를 설계할 때 삽입 이상을 방치하면, DB 안에는 무수히 많은 '가짜 데이터(Dummy Data)'들이 쌓이게 된다. 이 가짜 데이터들은 나중에 총학생수를 계산할 때 통계(COUNT)를 망가뜨리는 주범이 된다. 결국 삽입 이상은 프로그램의 로직으로 해결할 문제가 아니라, 테이블의 구조(스키마) 자체를 쪼개야만 근본적으로 치유되는 구조적 질병이다.

📌 관련 개념 맵

관련 이론: 3대 이상 현상 (Anomaly) - 삽입 이상, 삭제 이상, 갱신 이상
해결 기술: 정규화 (Normalization)
원인 규칙: 개체 무결성 (Entity Integrity - PK는 Null 불가)
대칭 현상: 삭제 이상 (Deletion Anomaly - 403번 문서)

👶 어린이를 위한 3줄 비유 설명

장난감 가게에서 '로봇'과 '건전지'를 테이프로 칭칭 감아서 무조건 세트로만 팔고 있어요. (정규화 안 된 테이블)
나는 건전지만 하나 사고 싶은데, 아저씨가 "로봇도 같이 안 사면 건전지 안 팔아!"라고 해요. (삽입 이상)
결국 쓰지도 않을 비싼 로봇을 억지로 같이 사야만 건전지를 가질 수 있는 억울한 상황이랍니다!