🎯 F-lab Java 14주차 학습 커리큘럼

14주차 자료의 모든 토픽을 "데이터 타입 → HA/확장 → SQL 고급" 흐름으로 재배열한 학습 경로.
13주차가 DB 이론과 인덱스 였다면, 14주차는 DB 운영 측면 으로 확장.

데이터 타입과 인코딩 (CHAR/VARCHAR, BLOB/TEXT, Collation)

고가용성 (HA) (Clustering, Replication, PXC, Backup)

데이터 분할 (Sharding, Partitioning)

SQL 고급 기능 (Trigger, JOIN, VIEW, PROCEDURE)

📊 학습 경로 한눈에 보기

[Phase 1] 데이터 타입과 인코딩 (CHAR/VARCHAR, BLOB/TEXT, Collation)
   ↓
[Phase 2] DB Clustering — 고가용성의 시작
   ↓
[Phase 3] Replication과 백업 — Master-Slave + PXC
   ↓
[Phase 4] 데이터 분할 — Sharding과 Partitioning
   ↓
[Phase 5] DELETE/TRUNCATE/DROP과 ROLLBACK 메커니즘
   ↓
[Phase 6] SQL 고급 기능 — Trigger, JOIN, VIEW, PROCEDURE

총 6 Phase × 17 Unit — 단일 주차로 적정 분량.

🔗 1~14주차 흐름 정리

주차	주제	핵심 변화
1주차	OOP·JVM·GC·컬렉션·I/O 개론	자바 큰 그림
2주차	JVM 내부·바이트코드·G1 GC	"어떻게 돌아가나"
3주차	컬렉션·제네릭·함수형	자바 표현력
4주차	멀티스레딩·동시성·Executor	동시성 정복
5주차	Atomic + Spring IoC/DI 입문	자바 → Spring 다리
6주차	테스트 + 웹 인프라 + DB 접근 진화	Spring 실전 환경
7주차	JPA/ORM 입문 + 트랜잭션 추상화	DB 추상화 입문
8주차	프록시의 진화	AOP 메커니즘
9주차	Spring AOP 실전 + 트랜잭션 전파	AOP 실전 활용
10주차	트랜잭션 정리 + 빈 라이프사이클 + 격리 수준	트랜잭션 마무리
11주차	JPA의 정체와 영속성 컨텍스트	JPA 메커니즘 완전 이해
12주차	연관관계 + N+1 등 성능 최적화	JPA 실전 활용
13주차	DB 펀더멘털 - 모델링부터 인덱스까지	DB 본연의 영역 (이론)
14주차 (지금)	DB 운영 - 데이터 타입·HA·확장·SQL 고급	DB 운영의 영역

13주차와 14주차의 관계:

13주차 = DB 이론 (정규화·NoSQL·CAP·옵티마이저·인덱스)
14주차 = DB 운영 (확장·HA·SQL 고급 도구)
→ DB 영역의 이론 + 운영 두 축 완성

🗓️ 권장 학습 일정 (압축 5일)

Day	Phase	학습 목표
1일차	Phase 1	데이터 타입과 Collation
2일차	Phase 2 + 3	Clustering + Replication + PXC
3일차	Phase 4	Sharding + Partitioning
4일차	Phase 5 + 6 (전반)	DELETE/TRUNCATE/DROP + Trigger + JOIN
5일차	Phase 6 (후반) + 종합	VIEW + PROCEDURE + 자기 점검

여유 일정 (7일): Phase 2-3에 +1일 (HA는 그림이 필요함). Phase 6은 직접 쿼리 돌리며 학습 권장.

📚 Phase 1 — 데이터 타입과 인코딩

목표: SQL 컬럼 설계의 출발점인 데이터 타입 선택과 문자열 비교 규칙을 잡는다.

Unit 1.1 — CHAR vs VARCHAR (고정 vs 가변)

선수 지식: 6주차 Phase 6 (DB 기초)

핵심 비교 ⭐ :

	CHAR(n)	VARCHAR(n)
길이	고정 길이	가변 길이
짧은 데이터 저장 시	공백으로 채움	실제 길이만
속도	빠름 (특히 짧은 문자열)	약간 느림 (길이 계산 필요)
공간 효율	낮음	높음

예시:

-- CHAR(5)
INSERT INTO test VALUES ('Hi');  
-- 저장: 'Hi   ' (공백 3개 추가, 총 5바이트)

-- VARCHAR(5)
INSERT INTO test VALUES ('Hi');
-- 저장: 'Hi' (실제 2바이트만)

사용 가이드:

✅ CHAR 적합 — 길이가 일정한 데이터:

국가 코드: CHAR(2) ('US', 'KR')
성별: CHAR(1) ('M', 'F')
우편번호: CHAR(5)
ISO 표준 코드

✅ VARCHAR 적합 — 길이 가변:

사용자 이름: VARCHAR(50)
이메일: VARCHAR(100)
설명 텍스트: VARCHAR(255)

ILIC 적용:

운임 코드, 통화 코드 → CHAR
고객 이름, 화물 설명 → VARCHAR

자기 점검

VARCHAR가 약간 느린 이유는? (힌트: 길이 정보 추가 저장)
CHAR(255)에 'Hi'를 저장하면 디스크 사용은? (힌트: 255바이트)

Unit 1.2 — BLOB vs TEXT (이진 vs 문자)

선수 지식: Unit 1.1

핵심 비교 ⭐ :

	BLOB	TEXT
데이터 종류	이진(Binary)	문자(Text)
사용 사례	이미지, 동영상, 파일	긴 글, 댓글, 설명
대소문자	구분(Case-Sensitive)	구분 안 함(기본)
비교 방식	바이트 단위	Collation 규칙
인코딩	없음 (원본 그대로)	UTF-8/ASCII 등
문자열 함수	사용 X	LIKE/CONCAT 가능

예시:

BLOB:

CREATE TABLE files (
    id INT,
    image BLOB  -- 이미지 바이너리
);

TEXT:

CREATE TABLE posts (
    id INT,
    content TEXT  -- 게시글 본문
);

MySQL의 BLOB/TEXT 변형:

TINYBLOB / TINYTEXT (255 bytes)
BLOB / TEXT (64KB)
MEDIUMBLOB / MEDIUMTEXT (16MB)
LONGBLOB / LONGTEXT (4GB)

실무 권장:

이미지/파일은 DB에 저장하지 않는 게 좋음
→ 대신 S3 등 오브젝트 스토리지에 저장
→ DB에는 URL만

ILIC 적용:

운임 견적 PDF → S3 저장 + URL을 VARCHAR로
화물 설명 긴 텍스트 → TEXT

자기 점검

이미지를 DB에 저장하면 어떤 문제? (힌트: 크기 폭증, 백업/복구 부담)
TEXT 컬럼에 인덱스를 거는 게 가능한가? (힌트: prefix index만)

Unit 1.3 — Collation과 대소문자 구분

선수 지식: Unit 1.2

핵심 개념

Collation (정렬 규칙):

"문자열을 비교/정렬 하는 방법을 결정하는 규칙"

MySQL Collation 명명 규칙:

utf8_general_ci — UTF-8, 일반 비교, case-insensitive (대소문자 무시)
utf8_bin — UTF-8, 바이너리 비교 (대소문자 구분)
utf8mb4_unicode_ci — UTF-8 4바이트 (이모지 지원)

TEXT의 기본 동작:

기본 Collation = utf8_general_ci 등 → 대소문자 무시

예시:

SELECT * FROM users WHERE name = 'alice';
-- 'Alice', 'ALICE', 'alice' 모두 매칭 (case-insensitive 기본)

대소문자 구분이 필요할 때:

SELECT * FROM users WHERE name COLLATE utf8_bin = 'alice';
-- 'alice' 만 정확히 매칭

또는 BINARY 키워드:

SELECT * FROM users WHERE BINARY name = 'alice';

컬럼 단위로 Collation 지정:

CREATE TABLE users (
    name VARCHAR(50) COLLATE utf8_bin  -- 이 컬럼은 대소문자 구분
);

ILIC 활용:

일반 검색 (운임명 등) → 기본 (case-insensitive)
사용자 ID, 시스템 코드 → utf8_bin (구분)

자기 점검

12주차 영속성 컨텍스트에서 이메일 비교 시 대소문자 처리 어떻게 해야 할까?
한국어는 Collation 영향이 있는가? (힌트: 자모 분해 비교 등에 영향)

📚 Phase 2 — DB Clustering (고가용성의 시작)

목표: 단일 서버 한계를 넘는 첫 번째 도구인 클러스터링의 본질을 이해한다.

Unit 2.1 — Clustering의 정의와 필요성

선수 지식: 13주차 Phase 5 (Scale-Up vs Scale-Out)

핵심 문제

단일 서버의 위험:

DB 서버 1대 + DB 1개 운영
서버 다운 → 서비스 전체 중단
→ 가용성(Availability) 보장 불가

Clustering의 해결:

"여러 서버가 동일한 논리적 데이터베이스를 분산 운영"

핵심 의미:

물리적으로 N대 서버
논리적으로 1개 데이터베이스 (공유 또는 복제)
한 대가 다운돼도 나머지가 정상 동작

구조 (DB 서버 2대 시):

[Client]
    ↓
[Load Balancer]
   /        \
[DB Server 1] [DB Server 2]
   ↓               ↓
[DB Storage]  [DB Storage]
(physically separate)

이점:

고가용성 (HA) — 장애 시 서비스 지속
부하 분산 — 트래픽을 여러 서버로
점진 복구 — 운영 중에도 한 대씩 복구 가능

자기 점검

13주차 Scale-Out과 Clustering의 관계는? (힌트: Clustering은 Scale-Out의 한 형태)
Clustering이 항상 좋은가? (힌트: 비용, 복잡성)

Unit 2.2 — Active-Active vs Active-Standby ⭐

선수 지식: Unit 2.1

핵심 2가지 패턴:

Active-Active (동시 운영):

모든 서버가 동시에 활성
한 대 다운돼도 나머지가 즉시 처리
부하를 N개로 분산 → CPU/Memory 부하 ↓

장점:

즉각 장애 대응 (Failover 불필요)
부하 분산 효과
자원 효율

단점:

여러 서버가 같은 스토리지 공유 시 병목 가능
복잡한 동시성 제어
비용 ↑

Active-Standby (대기 모드):

Active 서버만 운영, Standby는 대기
Active 장애 시 → Failover로 Standby가 Active 전환

장점:

비용 ↓ (Standby는 평소 미사용)
단순한 구조
동시성 충돌 없음

단점:

Failover 시간 동안 서비스 중단
효율은 Active-Active의 절반
Standby가 Active로 전환 시 부하 처리 가능 검증 필요

비교 매트릭스:

	Active-Active	Active-Standby
자원 사용	모두 활성	절반만 활성
Failover 시간	거의 0	수 초 ~ 분
비용	높음	낮음
복잡도	높음	낮음

ILIC 시나리오:

핵심 결제 시스템 → Active-Active 권장
백오피스/관리 시스템 → Active-Standby 가능

자기 점검

ILIC가 Active-Standby로 운영 중 Active 다운 시 사용자가 느끼는 영향은?
Active-Active에서 같은 행을 두 서버가 동시 수정하면? (힌트: 충돌 해결 메커니즘 필요)

Unit 2.3 — Quorum과 클러스터 노드 수 (★ 면접 단골)

선수 지식: Unit 2.2

핵심 원리

클러스터 투표 (Quorum):

"노드 일부가 다운되었을 때 나머지가 다수(majority)를 차지하는지 판단"

과반수 룰 ⭐ :

과반수 (>50%) 이상의 노드 살아있으면 → 정상 운영
그렇지 않으면 → 자동 중단 (Fail-Safe)

왜 필요한가:

Split Brain 방지 — 네트워크 단절로 클러스터가 둘로 나뉘면 양쪽이 모두 자기를 정상이라 주장 → 데이터 불일치
한쪽만 정상으로 인정해야 일관성 유지

예시 (3노드 클러스터):

3개 노드 중 2개 살아있음 → 과반수 → 정상 운영
2개 노드 다운, 1개만 남음 → 과반수 X → 자동 중단

핵심 통찰 ⭐ :

"클러스터링은 최소 3개 노드 권장 — 1개 다운 시 2개로 정상 운영 가능"

2노드의 위험:

1개 다운 → 1개만 남음 → 과반수 X
→ 결국 1노드와 동일

홀수 노드 권장:

3, 5, 7개 → 명확한 과반수 가능
4, 6개 → 50:50 분리 가능

Quorum의 응용:

MongoDB Replica Set
Apache ZooKeeper
Kubernetes etcd
→ 모두 홀수 노드 권장

ILIC 적용:

클러스터링 도입 시 → 3노드 시작
트래픽 폭증 시 → 5노드로 확장 (4가 아닌)

자기 점검

"Split Brain"이 발생하면 어떤 사고가? (힌트: 양쪽 클러스터에 다른 쓰기 → 일관성 깨짐)
2노드 클러스터의 가용성은 1노드보다 정말 높은가? (힌트: NO — Quorum 룰 때문)

📚 Phase 3 — Replication과 백업

목표: Master-Slave 구조와 클러스터링의 차이를 명확히 잡고, PXC와 백업 전략을 본다.

Unit 3.1 — Replication (Master-Slave 복제)

선수 지식: Phase 2, 13주차 Phase 5

핵심 구조

Replication:

"Master 서버의 변경을 Slave 서버로 복제"

구조:

[Master DB] ──복제──> [Slave DB 1]
    ↓                    ↑
 (Write)              (Read only)
                         ↓
                      [Slave DB 2]

역할 분리:

Master: INSERT, UPDATE, DELETE
Slave: SELECT 전담

얻는 이점 ⭐ :

읽기 부하 분산
- Read 트래픽이 압도적으로 많은 시스템
- Slave를 추가해서 Read 처리
Master 부하 ↓
- Master는 Write만 담당
- 복잡한 SELECT 쿼리는 Slave로
백업·분석 부하 격리
- Slave에서 백업·통계 → Master 영향 없음

복제 방식:

비동기 (Asynchronous) — 기본, 약간의 지연 허용
반동기 (Semi-synchronous) — Slave 하나라도 적용 확인 후 응답
동기 (Synchronous) — 모든 Slave 적용 후 응답 (느림)

복제 지연 (Replication Lag):

비동기 시 Slave가 Master보다 약간 느림
갓 INSERT한 데이터를 Slave에서 SELECT하면 못 찾을 수 있음
→ 일관성 중요한 조회는 Master에서

Master/Slave 성능 고려:

Master와 Slave 성능 비슷 → 복제 지연 없음
Slave는 Read만이므로 동등 성능 불필요
그러나 Failover 시 Slave가 Master 역할 → 성능 차이 크면 위험

ILIC 시나리오:

운임 견적 등록 → Master
운임 검색 → Slave (Read Replica)
야간 통계 → 별도 Slave

자기 점검

복제 지연이 사용자에게 어떻게 보일까? (힌트: 등록 후 즉시 조회 시 안 보임)
Read-after-Write 일관성을 위한 해결책은? (힌트: 명시적으로 Master에서 조회)

Unit 3.2 — Replication vs Cluster (★ 면접 단골)

선수 지식: Phase 2, Unit 3.1

핵심 차이 ⭐ :

	Replication	Clustering
구조	Master → Slave (단방향)	모든 노드 동등
Write	Master만	모든 노드 가능
Read	Slave 분산	모든 노드
일관성	비동기 (지연 가능)	동기 또는 즉시
Failover	수동/반자동	자동
주 목적	읽기 성능 + 백업	고가용성 + 즉시 Failover

시각적 비교:

Replication:

[Master]  ─wirte─> Master 자신
   │
   │ 비동기 복제
   ↓
[Slave 1]  ─read 만─
[Slave 2]  ─read 만─

Clustering (Active-Active):

[Node 1] ↔ [Node 2] ↔ [Node 3]
   ↓          ↓           ↓
모두 read/write 가능 (동기 동기화)

선택 기준:

Replication 적합:

읽기 비율 압도적 (예: 90% read)
백업·분석 격리 필요
비용 절감

Clustering 적합:

즉시 Failover 필수
쓰기 부하도 분산 필요
강한 일관성

둘 다 사용 가능 (실무 표준):

핵심 클러스터(Master) + 읽기 Replica 추가

ILIC 시나리오:

운임 시스템 핵심 → Cluster
운임 검색 캐시용 → Read Replica

자기 점검

"Replication은 HA 솔루션인가?"의 답은? (힌트: 부분적, Cluster가 진짜 HA)
Failover 자동화는 어느 쪽이 강한가?

Unit 3.3 — Percona XtraDB Cluster + 백업

선수 지식: Unit 3.2

Percona XtraDB Cluster (PXC) ⭐ :

"MySQL 호환 Active-Active 클러스터링 솔루션"

왜 PXC를 선택하는가:

Replication의 한계:
1. Slave가 Read만 담당 → 성능 좋은 Master 의존
2. Master 장애 시 Slave 자동 승격 X
3. Slave 성능을 낮게 잡으면 Master 대체 어려움

PXC의 해결:

모든 노드가 Read/Write 가능
한 노드 장애 시 자동으로 다른 노드 활용
동기 복제로 강한 일관성

Galera Cluster 기반:

PXC는 Galera Cluster 기술 사용
인증 기반 동기 복제 (Certification-Based Replication)

ILIC 적용 가능성:

운임 시스템 핵심 → PXC
단, 모든 노드 동시 활성이라 비용 ↑

XtraBackup vs mysqldump (백업 도구):

	XtraBackup	mysqldump
방식	Hot Backup (서비스 중)	Logical (SQL 추출)
속도	매우 빠름	느림
결과물	바이너리 파일	SQL 텍스트
복구	빠름	느림 (재실행)
운영 영향	최소	락 발생 가능
도구	Percona 도구	MySQL 기본
적합	대용량 운영 DB	작은 DB, 마이그레이션

XtraBackup 권장:

100GB+ 데이터베이스
24/7 서비스 (다운타임 불가)

mysqldump 권장:

개발/테스트 환경
작은 DB
다른 DB로 마이그레이션 (SQL 호환성)

ILIC 시나리오:

일일 운영 백업 → XtraBackup
마이그레이션 / 임시 백업 → mysqldump

자기 점검

"Hot Backup"의 의미는? (힌트: 서비스 중단 없이 백업)
mysqldump를 운영 시간에 돌리면? (힌트: LOCK + 성능 저하)

📚 Phase 4 — 데이터 분할 (Sharding과 Partitioning)

목표: 한 테이블/한 DB가 너무 커졌을 때의 두 가지 분할 전략을 비교한다.

Unit 4.1 — Sharding (수평 분할)

선수 지식: 13주차 Phase 5 (NoSQL의 Sharding)

핵심 개념

Sharding:

"여러 DB 서버로 데이터를 분할 — 각 서버가 일부 데이터만 가짐"

구조:

[Shard 1: user_id 1~1000만]
[Shard 2: user_id 1000만~2000만]
[Shard 3: user_id 2000만~3000만]

샤드 키 (Shard Key):

데이터를 분할하는 기준 컬럼
예: user_id, region, hash(id)

샤딩 전략:

Range-based (범위):
- user_id 1~1000만 → Shard 1
- 장점: 단순
- 단점: 핫스팟 가능 (특정 범위 집중)
Hash-based (해시):
- hash(user_id) % N → Shard 번호
- 장점: 균등 분산
- 단점: 범위 검색 어려움
Geographic (지리):
- 한국 사용자 → Shard 1 (서울)
- 미국 사용자 → Shard 2 (캘리포니아)
- 장점: 지연 시간 ↓

Sharding의 어려움 ⭐ :

JOIN 어려움:
- 다른 Shard의 데이터를 JOIN 못 함
- → 애플리케이션에서 JOIN 처리
트랜잭션 분산:
- 여러 Shard 걸친 트랜잭션 어려움
- → 분산 트랜잭션 (2PC, Saga)
재샤딩 비용:
- Shard 추가 시 데이터 재분배
- 운영 중 큰 부담
샤드 키 선택의 어려움:
- 잘못 고르면 핫스팟 발생

NoSQL과의 자연스러운 궁합:

NoSQL은 JOIN 안 씀 → Sharding 친화적
→ 13주차 Phase 5의 Scale-Out 핵심

ILIC 적용 시 검토:

102 테이블이 정말 한 DB로 부족한지 먼저 검증
보통 수직 확장(Scale-Up) + Replica로 충분
Sharding은 정말 마지막 카드

자기 점검

운임 견적 1억 건이 되면 Sharding이 답인가? (힌트: 먼저 Partitioning 검토)
핫스팟 사례를 들어보라 (힌트: 인기 상품, VIP 고객)

Unit 4.2 — Partitioning (단일 DB 내 분할)

선수 지식: Unit 4.1

핵심 차이 ⭐ :

	Partitioning	Sharding
분할 단위	단일 DB 내 테이블	여러 DB 서버
위치	한 DBMS	분산 시스템
관리	DBMS 자동	애플리케이션
트랜잭션	정상	분산 어려움
복잡도	낮음	높음

Partitioning의 본질:

"한 테이블을 여러 물리적 조각으로 분할 — DBMS가 자동 라우팅"

Partition 종류:

1. Range Partitioning (범위):

CREATE TABLE sales (
    sale_date DATE,
    amount DECIMAL
)
PARTITION BY RANGE (YEAR(sale_date)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026)
);

2. List Partitioning (목록):

PARTITION BY LIST (region) (
    PARTITION p_kr VALUES IN ('SEOUL', 'BUSAN'),
    PARTITION p_us VALUES IN ('NY', 'LA')
);

3. Hash Partitioning (해시):

PARTITION BY HASH (user_id) PARTITIONS 4;
-- 4개 파티션으로 균등 분산

4. Key Partitioning:

Hash와 유사, MySQL 자체 함수 사용

Partitioning의 효과:

쿼리 성능 ↑:
- WHERE 조건이 파티션 키와 일치 → 해당 파티션만 스캔 (Partition Pruning)
- 예: WHERE sale_date = '2024-...' → p2024 파티션만 조회
관리 용이:
- 오래된 파티션 → DROP으로 빠른 삭제
- DELETE는 느리지만 DROP PARTITION은 즉시
인덱스 부담 ↓:
- 파티션별 인덱스 → 작은 트리 → 빠른 검색

ILIC 적용 가능:

일별 트랜잭션 로그 → Range Partitioning by date
지역별 운임 → List Partitioning

Partitioning 우선, Sharding은 마지막:

1억 행 → Partitioning으로 충분
100억 행, 단일 서버 한계 → Sharding 검토

자기 점검

Partitioning과 인덱스의 관계는? (힌트: 파티셔닝은 인덱스 + α 효과)
오래된 데이터 정리에 Partitioning이 효과적인 이유는? (힌트: DROP PARTITION 즉시)

📚 Phase 5 — DELETE/TRUNCATE/DROP과 ROLLBACK 메커니즘

목표: 자주 헷갈리는 데이터 삭제 명령의 차이와 ROLLBACK 가능 여부의 본질을 이해한다.

Unit 5.1 — DELETE vs TRUNCATE vs DROP (★ 면접 단골)

선수 지식: 6주차 Phase 6, 10주차 Phase 5

핵심 비교 ⭐ :

	DELETE	TRUNCATE	DROP
분류	DML	DDL	DDL
대상	특정 행	모든 행	테이블 자체
WHERE 절	가능	불가	불가
속도	느림	빠름	즉시
ROLLBACK	가능 ✅	불가 ❌	불가 ❌
AUTO_INCREMENT	유지	초기화	(테이블 사라짐)
인덱스/제약조건	유지	유지	삭제
트리거 발동	✅	❌	❌

DELETE — 안전한 삭제:

DELETE FROM users WHERE id = 5;
DELETE FROM users WHERE created_at < '2020-01-01';

-- ROLLBACK 가능
START TRANSACTION;
DELETE FROM users WHERE id = 5;
ROLLBACK;  -- 복구됨

왜 느린가:

행마다 개별 삭제
트리거 발동
UNDO LOG 작성 (롤백용)

TRUNCATE — 빠른 전체 삭제:

TRUNCATE TABLE users;
-- 모든 행 삭제 (구조는 유지)

왜 빠른가:

행 단위가 아닌 테이블 재생성 방식
UNDO LOG 안 씀 → ROLLBACK 불가

주의:

AUTO_INCREMENT 초기화 → ID 1부터 다시 시작
외래키 참조 시 실패 가능

DROP — 완전 제거:

DROP TABLE users;
-- 테이블 + 데이터 + 인덱스 + 제약조건 + 트리거 모두 삭제

복구 불가:

백업 없으면 끝
운영에서는 매우 신중하게

언제 무엇을?:

상황	명령
일부 데이터 삭제	DELETE
모든 데이터 삭제 (테이블 유지)	TRUNCATE
테이블 자체 제거	DROP
트랜잭션으로 안전하게	DELETE

ILIC 시나리오:

사용자가 운임 견적 취소 → DELETE
테스트 데이터 초기화 → TRUNCATE
더 이상 안 쓰는 임시 테이블 → DROP

자기 점검

TRUNCATE는 트랜잭션 안에서 ROLLBACK 가능한가? (힌트: NO — DDL이라 자동 커밋)
DELETE 후 AUTO_INCREMENT 값은? (힌트: 유지 — 다음 ID는 그 다음부터)

Unit 5.2 — ROLLBACK과 UNDO LOG

선수 지식: Unit 5.1, 6주차 Phase 6 (ACID)

핵심 메커니즘

ROLLBACK이 가능한 이유:

"UNDO LOG 덕분"

UNDO LOG:

트랜잭션이 변경한 이전 상태를 저장
변경 전의 값(Before Image) 기록
ROLLBACK 시 이전 상태로 복원

예시 흐름:

1. UPDATE users SET age = 30 WHERE id = 1;
   (age는 원래 25였음)

2. UNDO LOG 기록: "id=1의 age를 25로 되돌릴 것"

3. ROLLBACK 호출
   → UNDO LOG 적용
   → age = 25 복구

InnoDB의 두 로그 ⭐ :

	UNDO LOG	REDO LOG
목적	ROLLBACK 지원	복구 (Crash Recovery)
시점	트랜잭션 중	변경 즉시
내용	이전 상태 (Before)	변경 후 (After)
용도	롤백·MVCC	Durability 보장

MVCC (Multi-Version Concurrency Control):

10주차 Phase 5의 격리 수준에서 본 개념
UNDO LOG의 이전 버전 활용 → 다른 트랜잭션이 일관된 스냅샷 조회

TRUNCATE는 왜 ROLLBACK 안 되나:

DDL은 자동 커밋 (Auto-commit)
UNDO LOG 작성 안 함
빠르지만 위험

DELETE의 비용:

모든 변경에 UNDO LOG 작성
→ 100만 행 DELETE 시 UNDO LOG도 100만 건
→ 디스크 공간 + 성능 부담

ILIC 적용:

일반 비즈니스 작업 → DELETE + 트랜잭션 (안전)
대량 정리 작업 → TRUNCATE (빠름, 단 백업 후)
운영 중 절대 사용 X → DROP

자기 점검

ROLLBACK이 무한정 가능한가? (힌트: NO — UNDO LOG에 시간/공간 한계)
11주차 변경 감지(Dirty Checking)는 UNDO LOG와 같은가? (힌트: 다름 — JPA는 메모리, UNDO는 DB)

📚 Phase 6 — SQL 고급 기능

목표: Trigger·JOIN·VIEW·PROCEDURE 등 SQL의 도구함을 정리한다.

Unit 6.1 — Trigger (자동 실행 코드)

선수 지식: Phase 5

핵심 개념

Trigger:

"INSERT/UPDATE/DELETE 시 자동으로 실행되는 코드"

예시 — 학생 삭제 시 이력 보관:

CREATE TRIGGER trg_student_delete
AFTER DELETE ON students
FOR EACH ROW
BEGIN
    INSERT INTO deleted_students (id, name, deleted_at)
    VALUES (OLD.id, OLD.name, NOW());
END;

작동:

DELETE FROM students WHERE id = 5;
-- → 자동으로 deleted_students에 INSERT

트리거 종류:

시점:

BEFORE — 작업 전 실행
AFTER — 작업 후 실행

이벤트:

INSERT / UPDATE / DELETE

범위:

FOR EACH ROW — 행마다
FOR EACH STATEMENT — 명령마다 (MySQL 미지원)

활용 사례 ⭐ :

감사 로그 (Audit Trail) — 변경 이력 추적
데이터 무결성 — 복잡한 검증
자동 계산 — 합계 자동 갱신
알림 — 특정 조건 만족 시 알림 트리거

ILIC 활용 가능성:

운임 견적 변경 이력 자동 기록
사용자 정보 변경 시 감사 로그
→ 11-12주차 ILIC의 2-layer history 시스템 (Spring AOP 활용)이 트리거의 대안

Trigger의 단점 ⚠️ :

숨겨진 동작 — 코드만 봐서는 알 수 없음
디버깅 어려움 — 흐름 추적 곤란
성능 부담 — 대량 작업 시 누적
테스트 어려움 — 단위 테스트 불가

실무 권장:

간단한 감사 로그 외에는 트리거 지양
복잡한 비즈니스 로직 → 애플리케이션 레이어
Spring AOP가 더 좋은 대안 (8-9주차)

자기 점검

Trigger와 Spring AOP의 비교 — 같은 기능을 어디서 구현하는 게 좋을까?
ILIC의 변경 이력 시스템을 트리거 vs AOP 중 무엇으로 했고 왜?

Unit 6.2 — INNER JOIN vs OUTER JOIN ⭐

선수 지식: 6주차 Phase 6 (JOIN)

핵심 개념

JOIN의 본질:

"두 개 이상 테이블을 결합하여 데이터 조회"

INNER JOIN — 매칭만 포함:

SELECT u.name, o.product
FROM users u
INNER JOIN orders o ON u.id = o.user_id;

→ users와 orders 양쪽 모두에 매칭되는 행만 반환
→ 매칭 안 되는 user는 결과에서 빠짐

OUTER JOIN — 모든 행 포함:

LEFT OUTER JOIN (왼쪽 기준):

SELECT u.name, o.product
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

→ users 모든 행 포함
→ orders 없는 user는 NULL로 채워짐

RIGHT OUTER JOIN (오른쪽 기준):

FROM users u
RIGHT JOIN orders o ON u.id = o.user_id;

→ orders 모든 행 포함

FULL OUTER JOIN (양쪽 모두):

-- MySQL은 기본 미지원, UNION으로 시뮬레이션
SELECT * FROM A LEFT JOIN B ON ...
UNION
SELECT * FROM A RIGHT JOIN B ON ...;

→ 양쪽 모든 행, 매칭 안 되면 NULL

시각적 비교:

[INNER]
A ∩ B (교집합만)

[LEFT OUTER]
A 전체 + (B에서 매칭되는 부분)

[RIGHT OUTER]
B 전체 + (A에서 매칭되는 부분)

[FULL OUTER]
A ∪ B (합집합)

언제 무엇을?:

상황	JOIN 종류
양쪽 모두 있는 행만	INNER
왼쪽 모두 + 매칭	LEFT
한 쪽이 없어도 모두	OUTER
매칭 안 되는 행 찾기	LEFT + WHERE B IS NULL

ILIC 시나리오:

주문이 있는 사용자만 → INNER
모든 사용자 + 주문 (없으면 0) → LEFT
주문 안 한 사용자 찾기 → LEFT + IS NULL

JPA에서의 JOIN:

12주차 Phase 9 — JOIN, FETCH JOIN
JPQL 기본은 INNER
LEFT 명시: LEFT JOIN

자기 점검

LEFT JOIN과 LEFT OUTER JOIN은 다른가? (힌트: 같음 — OUTER는 생략 가능)
INNER JOIN으로 매칭 없는 행을 찾을 수 있나? (힌트: NO — LEFT + IS NULL 필요)

Unit 6.3 — VIEW (가상 테이블)

선수 지식: Unit 6.2

핵심 개념

VIEW:

"실제 데이터를 저장하지 않는 가상 테이블 — 쿼리 결과를 정의"

예시:

CREATE VIEW user_orders AS
SELECT users.id, users.name, orders.product
FROM users
INNER JOIN orders ON users.id = orders.user_id;

사용:

SELECT * FROM user_orders;  -- 테이블처럼!

VIEW의 활용:

복잡한 쿼리 단순화:

-- 복잡한 JOIN을 한 번 정의 후 재사용
SELECT * FROM monthly_sales_summary;

보안:

CREATE VIEW public_users AS
SELECT id, name FROM users;  -- email, password 제외

권한 분리:
- 사용자에게 테이블 직접 접근 X
- VIEW만 SELECT 권한 부여
레거시 호환:
- 테이블 구조 변경 시 VIEW로 이전 인터페이스 유지

VIEW의 한계 ⚠️ :

성능 — 단순 쿼리지만 매번 원본 쿼리 실행
수정 제약 — 복잡한 VIEW는 INSERT/UPDATE 불가
인덱스 X — VIEW 자체에 인덱스 못 검 (Materialized View 제외)

Materialized View (참고):

결과를 실제 저장하는 VIEW
빠른 조회, 그러나 데이터 갱신 필요
MySQL 미지원, PostgreSQL/Oracle 지원

ILIC 적용:

복잡한 운임 통계 쿼리 → VIEW로 캡슐화
보고서용 데이터 → VIEW

자기 점검

VIEW를 자주 쓰면 어떤 문제? (힌트: 옵티마이저 어려움, 성능)
VIEW에 INSERT가 가능한 경우는? (힌트: 단순 단일 테이블 VIEW)

Unit 6.4 — PROCEDURE (저장 프로시저)

선수 지식: Unit 6.3

핵심 개념

PROCEDURE (Stored Procedure):

"매개변수를 활용하여 정의한 작업을 DB에 저장 + 호출"

예시:

CREATE PROCEDURE add_user(
    IN p_name VARCHAR(50),
    IN p_email VARCHAR(100)
)
BEGIN
    INSERT INTO users (name, email)
    VALUES (p_name, p_email);
END;

-- 호출
CALL add_user('Alice', 'alice@example.com');

VIEW vs PROCEDURE ⭐ :

	VIEW	PROCEDURE
용도	정적 조회	동적 처리
반환	테이블 형태	결과 또는 영향만
매개변수	X	✅
INSERT/UPDATE	제한적	자유롭게
호출	`SELECT FROM view`	`CALL procedure`

프로시저의 활용:

복잡한 비즈니스 로직 — DB 안에서 처리
배치 작업 — 여러 SQL 묶음
트랜잭션 단위 작업 — DB 차원에서 관리
권한 캡슐화 — 사용자에게 직접 SQL 권한 X, 프로시저만

현대적 관점에서의 평가 ⚠️ :

과거 (1990~2000년대):

DB가 강력한 곳, 애플리케이션은 약함
비즈니스 로직을 DB에 두는 것이 자연스러움
프로시저 활발히 사용

현재:

애플리케이션 레이어가 풍부 (Java, Spring)
비즈니스 로직은 애플리케이션에 두는 것이 일반적
→ 프로시저 사용 감소

프로시저의 단점:
1. 테스트 어려움 — DB에 의존
2. 버전 관리 어려움 — Git 등으로 관리 X
3. 포팅 어려움 — DBMS마다 문법 다름
4. 디버깅 어려움
5. CI/CD 어려움

실무 권장:

"비즈니스 로직은 애플리케이션에, DB는 데이터 저장에 집중"

다만 다음은 프로시저 적합:

대량 ETL 작업
보고서용 복잡 집계
DB 어드민 작업

Trigger vs VIEW vs PROCEDURE 정리 ⭐ :

	Trigger	VIEW	PROCEDURE
호출	자동 (이벤트)	SELECT	CALL (수동)
매개변수	OLD/NEW	X	✅
용도	자동 부수 작업	가상 테이블	명시적 작업 단위

ILIC 권장:

비즈니스 로직 → Spring 서비스 레이어
단순 쿼리 단순화 → VIEW 가능
자동 감사 로그 → Trigger 또는 AOP (8-9주차)
복잡한 ETL → PROCEDURE 또는 Spring Batch

자기 점검

ILIC가 비즈니스 로직을 프로시저로 안 두는 이유는? (힌트: 테스트, 버전 관리)
프로시저를 정말 써야 할 경우는? (힌트: DB 관리, 대량 ETL)

🎓 종합 자기 점검 (14주차 졸업 시험)

데이터 타입과 인코딩

CHAR와 VARCHAR의 차이를 한 문장으로?
CHAR(255)에 'A' 저장 시 디스크 사용량은?
BLOB과 TEXT의 가장 큰 차이는?
utf8_general_ci에서 'ci'의 의미는?
MySQL에서 대소문자 구분 검색을 강제하려면?

DB Clustering

Clustering의 정의와 단일 서버 대비 이점은?
Active-Active와 Active-Standby의 차이는?
클러스터에 최소 3개 노드를 권장하는 이유는?
Split Brain의 정의와 위험성은?

Replication과 PXC

Master-Slave Replication의 구조와 이점은?
Replication과 Clustering의 결정적 차이 3가지는?
PXC가 일반 Replication보다 좋은 시나리오는?
XtraBackup이 mysqldump보다 적합한 경우는?

데이터 분할

Sharding과 Partitioning의 차이는?
Hash-based Sharding의 장단점은?
Range Partitioning이 적합한 데이터 사례는?
"Partitioning 우선, Sharding은 마지막"의 의미는?

삭제 명령과 ROLLBACK

DELETE/TRUNCATE/DROP 차이를 표로 정리하라
TRUNCATE가 ROLLBACK 안 되는 이유는?
UNDO LOG와 REDO LOG의 차이는?
AUTO_INCREMENT 값이 DELETE/TRUNCATE 후 어떻게 되는가?

SQL 고급 기능

Trigger의 활용 사례 3가지는?
Trigger의 단점 4가지와 대안(AOP)의 비교는?
INNER JOIN과 LEFT OUTER JOIN의 결과 차이를 시나리오로 설명하라
"주문 안 한 사용자 찾기" SQL을 작성하라
VIEW의 활용 사례 4가지는?
VIEW와 PROCEDURE의 결정적 차이는?
현대 실무에서 PROCEDURE 사용이 줄어든 이유 3가지는?

📌 학습 운영 팁

9-섹션 마스터 프롬프트로 깊이 파야 할 Unit

★★★ 면접·실무 단골 (반드시):

Unit 2.3 — Quorum과 클러스터 노드 수
Unit 3.2 — Replication vs Cluster
Unit 5.1 — DELETE vs TRUNCATE vs DROP
Unit 6.2 — INNER vs OUTER JOIN

★★ 매우 권장:

Unit 4.1~4.2 — Sharding과 Partitioning 차이
Unit 5.2 — UNDO LOG와 ROLLBACK
Unit 6.3 — VIEW의 활용
Unit 6.4 — PROCEDURE의 현재 위치

Phase별 진도 체크리스트

[ ] Phase 1 — 데이터 타입과 인코딩 (Unit 1.1~1.3)
[ ] Phase 2 — DB Clustering (Unit 2.1~2.3)
[ ] Phase 3 — Replication과 백업 (Unit 3.1~3.3)
[ ] Phase 4 — Sharding과 Partitioning (Unit 4.1~4.2)
[ ] Phase 5 — DELETE/TRUNCATE/DROP과 ROLLBACK (Unit 5.1~5.2)
[ ] Phase 6 — SQL 고급 기능 (Unit 6.1~6.4)
[ ] 종합 자기 점검 28문항 통과

13주차 + 14주차 = DB 영역 완결

13주차 (이론):

정규화 → NoSQL → CAP/PACELC → 옵티마이저 → 인덱스

14주차 (운영):

데이터 타입 → Clustering → Replication → Sharding/Partitioning → SQL 도구

→ 이제 DB 면접에서 마주칠 대부분의 질문에 답할 수 있다.

학습 시 주의

이번 주차는 운영 실무 색채가 강합니다. 직접 손을 더럽혀야 체화됩니다:

Phase 2-3 (Clustering/Replication):
- Docker Compose로 MySQL Replication 환경 구축
- 한 컨테이너 다운 → 동작 확인
- PXC도 Docker로 시도 (시간 여유 있다면)
Phase 4 (Partitioning):
- 직접 RANGE PARTITION 테이블 생성
- EXPLAIN으로 Partition Pruning 확인
Phase 5 (DELETE/TRUNCATE/DROP):
- 트랜잭션 안에서 각 명령 실행 후 ROLLBACK 시도
- AUTO_INCREMENT 동작 확인
Phase 6 (Trigger/VIEW/PROCEDURE):
- 직접 만들어보고, ILIC 어떤 영역에 적용 가능한지 검토

특히 ILIC와 연결해서 생각하세요:

102 테이블 중 파티셔닝 후보는?
Read Replica를 도입한다면 어떤 트래픽이 분산될까?
변경 이력 시스템을 Trigger로 했더라면 어땠을까? (AOP와의 비교)

🎯 F-lab Java 14주차 학습 커리큘럼

댓글