20. 데이터 정의 언어 (DDL: Data Definition Language)

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

본질: DDL은 테이블, 인덱스, 뷰, 제약조건 등 데이터베이스를 구성하는 논리적, 물리적 객체(Object)들의 구조를 설계하고 변경하거나 소멸시키는 언어다.

가치: 데이터를 담는 그릇의 형태와 규칙(도메인 무결성, 참조 무결성 등)을 시스템 수준(데이터 딕셔너리)에 강력하게 각인시킴으로써, 쓰레기 데이터 유입을 원천 차단한다.

융합: 실행 즉시 내부 시스템 카탈로그 메타데이터를 변경하며 트랜잭션을 강제로 확정(Auto-Commit)하는 특성이 있어, 무중단 배포(CI/CD) 환경의 데이터베이스 마이그레이션 파이프라인에서 핵심 관리 대상이 된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

건물을 지을 때 설계도면 없이 콘크리트부터 들이붓는다면, 그 건물은 머지않아 붕괴할 수밖에 없다. 데이터베이스 환경에서 '데이터'라는 콘크리트가 안전하게 자리 잡기 위해 필수적인 '골조와 설계도'를 그리는 작업이 바로 DDL(Data Definition Language)의 역할이다.

엔터프라이즈 환경에서 데이터는 무작위로 축적되지 않는다. 직원의 나이는 음수가 될 수 없고(체크 제약), 사번은 중복될 수 없으며(기본키), 소속 부서는 반드시 존재하는 부서여야 한다(외래키). 애플리케이션 코드로 이 모든 규칙을 매번 검사한다면 개발 생산성은 급락하고, 코드를 우회하는 버그나 동시성 경합 속에서 데이터 오염은 필연적으로 발생한다.

따라서 이러한 무결성(Integrity) 원칙과 데이터 구조를 데이터베이스 엔진 가장 깊은 곳의 시스템 메타데이터(카탈로그)에 정의하는 과정이 필요해졌으며, CREATE, ALTER, DROP 같은 직관적인 선언형 언어가 탄생하게 되었다. DDL의 중요성은 단순히 '그릇을 만든다'는 것을 넘어, 옵티마이저가 쿼리 계획을 세우는 기준(인덱스 통계 등)을 제공하고, 저장 엔진이 디스크 블록을 효율적으로 파티셔닝하게 만드는 전체 아키텍처의 기준점 역할을 수행한다는 데 있다.

아래 다이어그램은 DDL 명령어가 데이터베이스 내부에 진입했을 때 어떤 영역을 수정하여 전체 시스템에 영향을 미치는지 보여준다. 실제 유저 데이터 공간이 아닌 다른 곳을 찌르는 것을 확인하라.

┌─── [DBA / Developer] ───┐
│ "CREATE TABLE EMP (...)"│ (DDL 명령)
└──────────┬──────────────┘
           │ 
┌──────────▼─────────────────────────────────┐
│              DBMS 코어 엔진                │
│ 1. 구문 검증 및 권한 확인                  │
│ 2. 데이터 딕셔너리(System Catalog) 잠금    │
│ 3. 메타데이터(테이블 정의, 스키마) 쓰기    │ ◀ 핵심 타겟
│ 4. 물리적 테이블스페이스 파일 할당         │
└──────────┬─────────────────────────────────┘
           │ (인프라 구성)
┌──────────▼──────────────┐ ┌────────────────┐
│ [Data Dictionary (Disk)]│ │ [User Data Area]│
│ - 테이블 이름: EMP      │ │ (아직 텅 비어있음)│
│ - 컬럼: ID(INT, PK)...  │ │                │
└─────────────────────────┘ └────────────────┘

이 그림의 핵심은 DDL의 직접적인 타겟이 유저 데이터 블록이 아니라 '데이터 딕셔너리(Data Dictionary)'라는 점이다. DDL이 실행되면 DBMS는 시스템 메타데이터 공간에 새로운 데이터 규칙을 각인시킨다. 이 딕셔너리는 이후 모든 DML(조작) 쿼리가 유효한지 검증하는 절대적인 헌법재판소 역할을 수행한다. 또한 데이터 파일 내에 새로운 객체를 위한 물리적인 공간(Extent)을 디스크로부터 할당받는 무거운 I/O 작업을 동반한다. 이러한 특성 때문에 DDL은 단순한 조회 쿼리와 달리, 실행 시 시스템 전체 또는 특정 객체에 대해 매우 배타적인 잠금(Exclusive Lock)을 요구하며, 라이브 서비스 중에 함부로 수행해서는 안 되는 고위험 작업으로 취급된다.

📢 섹션 요약 비유: 마치 법치 국가에서 헌법 조항을 새로 만들거나(CREATE) 개정(ALTER)하는 것과 같습니다. 한 번 법이 제정되면 이후 시민들의 모든 활동(DML)은 무조건 그 법률(스키마 제약조건)의 테두리 안에서만 허용됩니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

DDL의 핵심 명령어들은 객체의 생명주기(Life Cycle)를 관리한다. 테이블뿐만 아니라 뷰(View), 인덱스(Index), 파티션, 사용자 프로필, 프로시저 등 모든 객체가 DDL의 관리 대상이다.

DDL 명령어	수행 역할	내부 물리적 동작 메커니즘	파급 효과 및 위험도	비유
CREATE	스키마, 도메인, 테이블, 뷰 생성	딕셔너리 정보 등재 및 테이블스페이스 내 초기 디스크 Extent 할당	낮음 (새 객체이므로 경합 없음)	신축 건물 올리기
ALTER	기존 객체의 구조 변경 (컬럼 추가/수정 등)	메타데이터 갱신, 컬럼 타입 변경 시 전체 데이터 블록 재작성 유발	매우 높음 (테이블 배타적 Lock 발생, 서비스 중단 위험)	거주 중인 건물 리모델링
DROP	객체를 완전히 소멸	메타데이터 삭제 및 디스크 공간 OS 반환 (캐스케이딩 옵션 주의)	치명적 (의존하는 뷰/프로시저 전부 무효화 연쇄 작용)	폭파 철거 (복구 불가)
TRUNCATE	테이블 골격은 두고 안의 데이터만 초기화	개별 레코드 로그 없이 물리적 페이지 할당 해제 및 HWM(High Water Mark) 리셋	높음 (초고속 삭제이나 Undo 로그 미생성으로 롤백 불가)	덤프트럭으로 내용물 한 번에 쏟아버리기

DDL 수행 시 DBMS는 내부적으로 강제 커밋(Auto-Commit)을 수행한다. 즉 트랜잭션 도중에 DDL을 치면 이전 작업들이 확정되어 롤백이 막히는 부작용이 있다. (일부 최신 DB 제외)

다음 구조도는 가장 위험하면서도 실무에서 자주 쓰이는 ALTER TABLE 명령어가 내부적으로 어떻게 테이블에 락(Lock)을 걸고 DML 트랜잭션을 차단하는지(Blocking) 보여주는 병목 시각화 다이어그램이다.

[라이브 운영 중 ALTER TABLE 실행 시의 병목 상황]

(세션 1: App) ── SELECT / UPDATE 지속 요청 (진행 중) ───┐
                                                       │ 1. Shared Lock (테이블 사용 중)
                                                       ▼
                                            ┌──────────────────────┐
(세션 2: DBA) ── ALTER TABLE Add_Col ──────▶│ [ Target Table (A) ] │ ◀ 2. 배타적 Lock (X-Lock) 획득 대기 (Blocking)
                 (새로운 컬럼 추가)           └──────────────────────┘
                                                       ▲
(세션 3: App) ── INSERT / SELECT 신규 요청 ────────────┘ ◀ 3. 대기열에 쌓임 (장애 시작)
                 (ALTER 작업이 끝날 때까지 무한 대기)

이 다이어그램이 보여주는 병목 지점은 DDL과 DML 간의 구조적 충돌(Lock Contention)이다. ALTER TABLE과 같은 DDL은 테이블 구조를 바꿔야 하므로 그 누구도 찰나의 순간일지라도 데이터를 읽거나 쓰지 못하게 하는 '배타적 잠금(X-Lock)'을 요구한다. 그러나 세션 1처럼 기존에 실행 중인 무거운 조회 쿼리나 트랜잭션이 테이블을 물고(Shared Lock) 안 놔준다면, DBA의 ALTER 명령은 X-Lock을 얻기 위해 대기 상태(Wait)에 빠진다. 더 끔찍한 것은 이 ALTER 명령 뒤에 들어오는 세션 3의 수많은 정상적인 고객들의 조회/결제 요청들이 모두 ALTER의 락 대기열 뒤에 줄을 서게 되면서(Queueing), 불과 몇 초 만에 데이터베이스 커넥션 풀(Connection Pool)이 고갈되어 전사 서비스 장애(Hang)로 번진다는 점이다. 실무에서 DDL이 "장애 유발 스위치"로 불리는 이유가 바로 이 아키텍처적 특성 때문이다.

📢 섹션 요약 비유: 도로(테이블)가 자동차(데이터)로 꽉 차서 달리고 있는데, 차선 도색(ALTER)을 하겠다며 인부들이 갑자기 도로 한가운데를 막아서면 순식간에 수십 km의 대형 교통 체증(장애)이 발생하는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

DDL 중에서도 데이터를 삭제하는 관점의 명령어인 DROP, TRUNCATE와 DML인 DELETE의 특성 비교는 아키텍처 운영 효율성과 복구 가능성(Recovery) 관점에서 가장 치열한 분석 대상이다.

비교 분석 속성	DROP (DDL)	TRUNCATE (DDL)	DELETE (DML)	판단 포인트
처리 철학	존재 자체를 지움 (구조+데이터)	용기를 비움 (구조 유지, 데이터 초기화)	조건에 맞는 내용만 핀셋 제거	남겨야 하는 대상(틀/조건)
처리 속도	매우 빠름	매우 빠름 (디스크 할당 블록 해제)	가장 느림 (Row 단위로 하나씩 삭제)	데이터 볼륨(건수) 크기
로그 발생 (부하)	메타 딕셔너리 변경 로그만 기록	공간 반환 로그만 발생 (최소 부하)	엄청난 크기의 트랜잭션(Undo) 로그 발생	I/O 자원 소모 수준
복구(Rollback)	롤백 불가능 (자동 커밋)	롤백 불가능 (자동 커밋)	롤백 가능 (트랜잭션 미완료 시)	오작동 시의 치명률

빅데이터 시대에는 테이블의 건수가 수십억 건에 달한다. 이때 DELETE로 전체 데이터를 지우면 로그 버퍼와 테이블스페이스(디스크) 간에 미친 듯한 스와핑이 발생하여 서버가 다운된다. 이럴 때 롤백을 포기하고 테이블의 물리적인 페이징 포인터(High Water Mark)만 리셋시키는 TRUNCATE 아키텍처가 압도적인 우위를 점한다.

다음 매트릭스는 대용량 RDBMS 환경과 스키마리스(Schemaless)를 표방하는 NoSQL 환경에서의 데이터 정의 패러다임(DDL의 유무)을 구조적으로 비교한 것이다.

┌───────────────┬───────────────────────────────┬──────────────────────────────┐
│ 아키텍처 속성 │ RDBMS (Schema-on-Write)       │ NoSQL / Data Lake (Schema-on-Read)│
├───────────────┼───────────────────────────────┼──────────────────────────────┤
│ DDL의 역할    │ 절대적 필수 (없으면 데이터 거부)│ 존재하지 않거나 무의미함       │
│ 스키마 검증   │ [쓰기(Write) 시점]에 즉각 검증  │ [읽기(Read) 시점]에 파싱/해석  │
│ 데이터 진화   │ ALTER DDL 시 DB 락 경합 리스크  │ 새 속성이 생기면 그냥 넣으면 됨│
│ 무결성 책임   │ DBMS 엔진 자체가 100% 보장      │ 애플리케이션 로직이 감당해야 함│
└───────────────┴───────────────────────────────┴──────────────────────────────┘

이 매트릭스는 최근 데이터 아키텍처가 스키마 온 라이트(Schema-on-Write)에서 스키마 온 리드(Schema-on-Read)로 분화되는 원인을 보여준다. RDBMS는 DDL로 선언된 스키마에 어긋나는 데이터(예: 숫자 컬럼에 문자열 삽입)가 들어오는 순간 거부(Exception)한다. 이는 데이터 품질을 완벽히 지켜내지만, 비즈니스 요건이 자주 바뀌어 컬럼을 추가해야 할 때마다 무거운 DDL 작업의 병목을 감수해야 한다. 반면 NoSQL은 DDL 없이 애플리케이션이 JSON 문서를 밀어 넣는 대로 저장한다. 유연성과 확장성은 극대화되었으나, 나중에 데이터를 읽어올 때 '이 문서에는 왜 나이 필드가 없지?' 같은 예외 처리를 애플리케이션 단에 수십 줄씩 짜 넣어야 하는 기술 부채(Technical Debt)를 낳는다. 실무에서는 이러한 상충 관계를 이해하고 MSA 도메인의 특성에 맞춰 DB를 선택해야 한다.

📢 섹션 요약 비유: RDBMS의 DDL은 붕어빵 틀을 미리 쇠로 단단히 주조하는 것(틀에 안 맞으면 빵이 안 나옴)이고, NoSQL은 틀 없이 찰흙을 마음대로 빚어 굽는 것(유연하지만 나중에 빵 크기가 다 제각각이 됨)과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

데이터 운영 환경에서 DDL은 성능 튜닝의 핵심이자 치명적 장애의 불씨다. 특히 24시간 365일 무중단 서비스가 기본이 된 오늘날, 라이브 환경에서의 DDL 배포는 극도의 주의와 전략을 요구한다.

실무 시나리오: 초대용량 테이블 무중단 스키마 변경 (Online DDL)
- 상황: 5억 건의 데이터가 있는 결제 테이블에 새로운 식별자 컬럼(Default값 포함)을 추가(ALTER TABLE)해야 함. 전통적인 DDL 실행 시 수 시간 동안 테이블 락이 걸려 서비스가 완전 멈출 위기.
- 판단 및 전략 (PT-OSC / Online DDL): 최신 RDBMS의 'Online DDL' 기능(ALGORITHM=INPLACE)을 사용하거나, Percona Toolkit(PT-OSC) 같은 외부 아키텍처를 도입. 이는 원본 테이블과 똑같은 '그림자 테이블(Ghost Table)'을 만들어 스키마를 변경하고, 변경 도중 들어오는 데이터는 트리거를 통해 동기화한 뒤, 마지막 0.1초 순간에 테이블 이름(Rename)을 스위칭하는 기법으로 락 타임을 극소화하여 무중단 배포를 실현한다.
도입 체크리스트: 외래키(FK) 연쇄 옵션 (CASCADE)의 양면성 제어
- 부모 테이블을 DDL로 구성할 때 무결성을 위해 ON DELETE CASCADE 제약을 걸어두는 경우가 많다.
- 안티패턴: 부모(회원) 행 하나를 지우면, DBMS가 백그라운드에서 자식(주문내역 10만 건, 장바구니 5만 건)을 연쇄적으로 알아서 삭제한다. 개발자는 편하지만, DB 엔진은 엄청난 양의 연쇄 락과 트랜잭션 과부하에 빠져 데드락을 뿜어낸다.
- 기술사적 결단: 대용량 트랜잭션 시스템에서는 DDL 수준의 물리적 CASCADE 설정을 강력히 금지하고(논리적 관계만 유지), 애플리케이션이나 배치 시스템에서 청크(Chunk) 단위로 쪼개어 삭제하는 소프트 딜리트(Soft Delete) 아키텍처를 표준으로 삼아야 한다.

아래 의사결정 트리는 운영 환경에서 스키마 구조를 변경(ALTER)해야 할 때 서비스 중단 리스크를 최소화하기 위한 실무적 검토 플로우다.

[스키마 변경 (ALTER TABLE) 요구]
   ↓
(Q1. 테이블 크기가 크고 실시간 DML 트랜잭션이 활발한가?) ── 아니오 ──> [일반 ALTER TABLE 실행]
   ↓ 예
(Q2. DB 엔진이 최신 Online DDL (INPLACE/NO LOCK) 기능을 완벽히 지원하는가?)
   ├─ 예 ────> [알고리즘 명시하여 Online DDL 백그라운드 실행]
   └─ 아니오 ──> (Q3. 즉시 적용되어야 하는가?)
                   ├─ 예 ──> [PT-OSC 기반 섀도우 테이블 복제/스위칭 기법 동원]
                   └─ 아니오 ──> [정기 점검(MA) 시간대에 세션 끊고 오프라인 실행]

이 운영 플로우의 핵심은 DDL의 '잠금(Lock)' 특성을 회피하기 위한 아키텍처적 우회로 설계다. 훌륭한 엔지니어는 개발계에서 "ALTER 쿼리 1줄"로 끝났다고 운영계에서도 쉽게 끝날 것이라 착각하지 않는다. 테이블에 데이터가 쌓이고 활성 세션이 많아질수록 메타데이터를 변경하는 DDL은 시한폭탄이 된다. 따라서 실무에서는 무중단 데이터 마이그레이션(Zero-Downtime Migration) 철학에 입각하여 그림자 테이블 교체 방식과 뷰(View) 래핑 방식을 동원해 리스크를 완전히 통제해야 한다.

📢 섹션 요약 비유: 엔진이 돌아가는 비행기(운영 DB)에서 부품을 교체(DDL)하려면, 무작정 나사를 푸는 게 아니라 보조 엔진(섀도우 테이블)을 먼저 돌려놓고 순식간에 연결 호스를 바꿔치기하는 고도의 스위칭 기술이 필요한 것과 같습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

데이터 정의 언어(DDL)는 데이터 무결성과 시스템 안정성을 최하단에서 수호하는 데이터베이스 아키텍처의 설계도이자 규범이다.

도입 전 (파일/단순 구조)	DDL 적용 후 (RDBMS 아키텍처)	비즈니스 임팩트
데이터 유효성 검증 누락	도메인, 체크 제약으로 쓰레기 데이터 원천 차단	신뢰성 높은 전사 데이터 자산 확보
구조 변경 시 앱 마비 위험	뷰(View) DDL을 통한 논리적 추상화 계층 제공	앱 로직 변경 없는 데이터 구조 진화
조인 및 검색 풀스캔 지연	효율적인 인덱스(Index) 및 파티션 DDL 물리 설계	수백 배의 I/O 응답 속도 향상 달성

결론적으로 DDL은 단순히 테이블을 생성하는 명령어 집합이 아니다. 빅데이터 시대에 데이터의 생명주기를 어떻게 쪼갤 것인가(Partitioning), 검색 병목을 어떻게 해소할 것인가(Indexing), 접근 권한을 어떻게 캡슐화할 것인가(View)를 결정짓는 핵심 물리 설계 도구다. 오늘날 CI/CD 자동화 시대에서는 Flyway, Liquibase, Flyte 같은 데이터베이스 마이그레이션 버전 관리 도구를 통해 DDL의 변경 이력을 소스 코드처럼 형상 관리(Version Control)하고, 데이터 리니지(Data Lineage)를 추적하는 체계로 고도화되고 있다.

📢 섹션 요약 비유: 한 번 잘 짜여진 도시의 도로망과 상하수도 인프라(DDL)는 수십 년간 수백만 명의 시민(데이터)이 혼란 없이 쾌적하게 살아갈 수 있게 하는 근본적인 뼈대가 되는 것과 같습니다.

📌 관련 무결성 제약조건 (Knowledge Graph)

개체 무결성 (Entity Integrity) | PRIMARY KEY DDL을 통해 테이블의 식별자가 NULL을 허용하지 않고 유일함을 시스템이 강제하는 원칙
참조 무결성 (Referential Integrity) | FOREIGN KEY DDL을 통해 자식 테이블의 값이 반드시 부모 테이블에 존재하는 유효한 값임을 보장하여 고아 데이터를 막는 규칙
도메인 무결성 (Domain Integrity) | CHECK, 데이터 타입(INT, VARCHAR) DDL을 통해 컬럼에 들어갈 데이터의 형식과 유효 범위(예: 나이>0)를 강제하는 원칙
온라인 DDL (Online DDL) | 서비스 중단 없이(무잠금 또는 최소 잠금) 백그라운드에서 스키마 변경, 인덱스 생성 등을 수행하는 현대 RDBMS의 가용성 기능
데이터 사전 (Data Dictionary) | DDL 쿼리가 파싱되어 실행된 결과(스키마 정의, 제약조건, 뷰 구조)가 저장되는 DBMS의 핵심 심장부(메타데이터 저장소)

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

레고로 집을 만들 때, "여기엔 빨간색 4칸짜리 블록만 들어갈 수 있어!"라고 규칙을 정하고 틀을 만드는 마법 주문이 DDL이에요.
DDL로 단단한 지붕과 벽을 잘 만들어두면, 나중에 아무리 많은 장난감을 넣어도 집이 무너지거나 엉망이 되지 않아요.
하지만 건물이 완성되어 사람들이 살고 있을 때 갑자기 기둥을 바꾸는 주문(ALTER)을 외우면 모두가 멈춰야 하니 아주 조심해서 써야 한답니다!