개발자가 알아야 할 데이터베이스 핵심 총정리

영상 [연속재생] 개발자가 알아야 할 데이터베이스 핵심 총정리 | 3시간 몰아보기의 전체 내용을 주제/소주제별로 빠짐없이 정리한 요약입니다.

1. 데드락(Deadlock) vs 라이브락(Livelock) [00:00]

• 데드락 (Deadlock): 두 개 이상의 프로세스/트랜잭션이 서로가 점유하고 있는 자원의 락을 얻기 위해 무한 대기 상태에 빠지는 현상 [01:13].
  • 상태/자원: WAITING/BLOCKED 상태, CPU 사용률이 거의 0%에 가까움 [02:32].
  • 해결법: 자원 접근 순서 일관화(A→B 순서 고정), DBMS의 자동 데드락 감지 및 롤백 [04:31], [06:15].
• 라이브락 (Livelock): 프로세스가 서로 양보하거나 상태를 계속 변경 및 재시도하여 러닝 상태는 유지되지만 작업의 진척이 전혀 없는 현상 [01:40].
  • 상태/자원: RUNNING 상태 지속, 지속적인 재시도로 인해 CPU 사용률 급증 [02:48].
  • 해결법: 순서를 정하기 어려운 분산/네트워크 환경에서는 Random Backoff(랜덤 대기 후 재시도) 기법 및 재시도 횟수 제한 적용 [05:59], [06:43].

2. 비관적 락(Pessimistic Lock) vs 낙관적 락(Optimistic Lock) [08:44]

• 동시성 충돌 발생 원인: 락 없이 읽기/쓰기를 수행하면 나중 트랜잭션이 이전 수정사항을 덮어쓰는 Lost Update(갱신 손실) 발생 [09:29].
• 비관적 락 (Pessimistic Lock): 충돌이 반드시 일어난다고 가정.
  • 방식: DB 수준에서 SELECT ... FOR UPDATE로 데이터 선점 (물리적 잠금) [11:37].
  • 장단점: 정합성이 완벽히 보장되나, 블로킹으로 인한 대기 발생 및 성능 저하 가능 [10:48], [12:15].
  • 사용 처: 금전 거래, 재고 차감, 좌석 예매 등 충돌이 빈번하고 정합성이 매우 중요할 때 [12:42].
• 낙관적 락 (Optimistic Lock): 충돌이 거의 나지 않을 것이라 가정.
  • 방식: 애플리케이션 레벨에서 version 컬럼을 체크하여 조건부 UPDATE 수행 (UPDATE ... WHERE id=? AND version=?) [11:57].
  • 장단점: DB 물리 락이 없어 성능상 유리하나, 충돌 발생 시 실패 처리 및 재시도 로직 구현 필요 [12:15].
  • 사용 처: 게시글 수정 등 읽기 대비 수정 비율이 낮고 충돌이 드문 경우 [13:08].

3. WHERE절 없는 UPDATE 쿼리의 위험성 (실무 장애 사례) [14:21]

• 사태 발생 원인: 실수로 WHERE 조건 없이 운영 DB 전체 테이블에 UPDATE 쿼리 실행 [14:59].
• 기술적 이유:
  • 인덱스를 타면 조건에 맞는 행만 락(Row-level Lock)이 걸림 [15:59].
  • WHERE절이 없으면 인덱스를 활용하지 못해 Full Table Scan 발생 [16:17].
  • 전체 행을 스캔하며 락을 쥐게 되어 사실상 Table-level Lock과 동일하게 동작 [16:26].
• 결과: 다른 모든 트랜잭션이 대기 상태에 빠지고 커넥션 풀 고갈/타임아웃으로 유저 접속 대거 튕김 [17:11].
• 안전 대책:
  1. 직접 UPDATE/DELETE 금지 및 실행 계획(EXPLAIN) 사전 확인 [17:43].
  2. 실행 전 SELECT로 영향 범위(Row 수) 선조회 [17:51].
  3. 대량 변경 시 Batch/LIMIT 단위를 나누어 짧은 트랜잭션으로 처리 [17:59].

4. 트랜잭션 격리 수준 (Transaction Isolation Level) [18:48]

동시성과 일관성 사이의 균형을 맞추기 위한 가시성 제어 단계.

• 이상 현상 (Anomalies):
  1. Dirty Read: 커밋되지 않은(롤백될 수도 있는) 타 트랜잭션의 변경 데이터를 읽음 [20:08].
  2. Non-Repeatable Read: 한 트랜잭션 내 동일 조회 시 중간에 타 트랜잭션의 UPDATE/COMMIT으로 결과값이 달라짐 [21:08].
  3. Phantom Read: 범위 조회 시 중간에 타 트랜잭션의 INSERT/COMMIT으로 새로운 행이 유령처럼 나타남 [21:21].
• 4가지 격리 수준:
  1. Read Uncommitted: 커밋 안 된 데이터도 읽음. Dirty Read 발생. 실무 미사용 [21:46].
  2. Read Committed: 커밋된 데이터만 읽음. Dirty Read 방지, Non-Repeatable Read 발생 (Oracle, PostgreSQL 기본) [23:03].
  3. Repeatable Read: 트랜잭션 시작 시점 스냅샷 참조. Non-Repeatable Read 방지 (MySQL InnoDB 기본, InnoDB는 Next-Key Lock으로 Phantom Read도 대부분 방지) [24:36], [26:30].
  4. Serializable: 읽기 작업도 공유 락 획득. 모든 이상 현상 차단하나 동시성 급감 및 성능 병목 [26:43].
• MVCC (Multi-Version Concurrency Control): DB가 락 없이 격리성을 구현하기 위해 언두(Undo) 영역에 변경 전 과거 버전을 보관해 시작 시점 기준 가시성을 보장 [28:18].

5. 트랜잭션 ACID 원칙 [31:02]

• A (Atomicity, 원자성): All or Nothing. 모든 작업이 완수되거나 모두 롤백됨. (구현: Undo Log로 복구) [32:50].
• C (Consistency, 일관성): 데이터는 항상 무결성 제약 조건(PK, FK, NOT NULL 등)을 준수함 [33:30].
• I (Isolation, 격리성/고립성): 트랜잭션 간 상호 간섭 금지. (구현: Lock, MVCC, 격리 수준) [34:21].
• D (Durable, 지속성): 커밋 완료된 데이터는 영구 보존됨. (구현: Redo Log / WAL) [34:58].

6. Redo Log vs Undo Log [36:56]

• WAL (Write-Ahead Logging): 데이터 파일 디스크 수정(Random I/O) 전, 로그 파일에 먼저 순차적(Sequential I/O)으로 기록하는 메커니즘 [39:10].
• Redo Log (다시 하기):
  • 목적: 지속성(Durability) 보장 [38:02].
  • 내용: 변경 후 데이터 기록 [42:47].
  • 역할: 장애 발생 시 체크포인트 이후 변경 사항을 재실행(Replay)하여 복구 [41:02].
• Undo Log (되돌리기):
  • 목적: 원자성(Atomicity) 및 격리성(Isolation/MVCC) 보장 [38:43].
  • 내용: 변경 전 데이터 기록 [42:47].
  • 역할: 트랜잭션 실패/롤백 시 이전 상태로 복원하고 MVCC 읽기 가시성 제공 [38:57].

7. 정규화(Normalization) vs 반정규화(De-normalization) [44:04]

• 정규화의 목적: 중복 데이터 제거 및 이상 현상(Anomaly: 갱신, 삽입, 삭제) 방지 [45:52], [47:07].
  • 단점: 테이블이 분할되면서 조인(Join) 비용 증가로 인한 읽기 성능 저하 가능 [48:10].
• 반정규화의 목적: 조인 줄이기를 통한 읽기 성능 향상 및 이력 보존(주문 시점 단가/주소 보존 등) [48:31], [49:50].
• 원칙: 반드시 정규화를 완료한 후, 성능 검증 및 비즈니스 요건에 따라 전략적으로 반정규화 수행 [51:15].

8. 제1, 2, 3 정규화 (1NF ~ 3NF) [52:41]

• 함수 종속성 (Functional Dependency): $X \to Y$ ($X$를 알면 $Y$가 하나로 결정될 때 $X$=결정자, $Y$=종속자) [55:53].
• 제1정규화 (1NF): 컬럼의 모든 값이 원자값(Atomic Value)이어야 함 (다중값/리스트 제거) [54:02].
• 제2정규화 (2NF): 복합키(Composite PK) 사용 시 부분 함수 종속성 제거 (PK의 일부분에만 종속된 속성을 별도 테이블로 분리) [57:24].
• 제3정규화 (3NF): 이행적 함수 종속성 제거 (PK가 아닌 일반 컬럼 간의 종속 관계 $A \to B \to C$ 분리) [58:52].

9. ORM vs Stored Procedure (SP) [01:01:33]

• ORM (Object-Relational Mapping):
  • 장점: 객체지향적 개발, 높은 생산성, DB 종속성 제거 [01:04:26].
  • 단점: N+1 문제, 대용량 집계/통계 쿼리 구현의 난이도 및 성능 한계 [01:04:45], [01:05:50].
• Stored Procedure (SP):
  • 장점: DB 내부 처리로 네트워크 왕복 비용 절감, 대량 배치 및 복잡한 집계에 유리 [01:04:51], [01:08:56].
  • 단점: 디버깅/형상관리 어려움, 특정 DBMS 벤더에 락인(Lock-in), DB 스케일아웃의 한계 [01:05:08], [01:06:10].
• 결론: 기본 비즈니스 CRUD는 ORM, 대용량 배치 및 복잡 집계는 SP/Native SQL을 사용하는 하이브리드 전략 추천 [01:09:34].

10. 파티셔닝(Partitioning) vs 샤딩(Sharding) [01:10:40]

• 파티셔닝 (Partitioning):
  • 개념: 단일 DB 인스턴스 내에서 대용량 테이블을 논리적/물리적 저장 단위로 분할 (Range, List, Hash 등) [01:12:04], [01:12:46].
  • 특징: DB 엔진이 투명하게 관리하며, 스케일업 환경 최적화 [01:12:37], [01:14:53].
• 샤딩 (Sharding):
  • 개념: 데이터를 여러 개의 독립된 물리 DB 인스턴스(Shard)로 분산 저장 [01:14:05].
  • 특징: 스케일아웃 수평 확장 전략. 애플리케이션/미들웨어 레벨에서 샤드 키 라우팅 필요 [01:14:18], [01:15:16].
  • 제약: 샤드 간 조인(Join) 불가, 데이터 재분배(Resharding) 부담 [01:17:24], [01:23:19].

11. 리플리케이션(Replication) vs 샤딩(Sharding) [01:18:03]

• 리플리케이션 (Replication):
  • 목적: 읽기(Read) 부하 분산 및 고가용성(HA) 확보 [01:18:58].
  • 방식: Primary(Write) 노드 1대 + Replica(Read) 노드 N대로 전체 데이터를 복제 [01:19:36].
  • 한계: Primary 노드의 쓰기(Write) 병목은 해결 불가 [01:20:46].
• 샤딩 (Sharding):
  • 목적: 쓰기(Write) 처리량 및 저장 용량 한계 극복 [01:21:33], [01:22:33].
• 도입 순서: 서버 스펙업 → 쿼리/인덱스 튜닝 → 캐싱/리플리케이션 → 파티셔닝 → 최후의 수단으로 샤딩 검토 [01:24:56].

12. 강한 일관성(Strong Consistency) vs 최종 일관성(Eventual Consistency) [01:27:48]

• 강한 일관성 (Strong Consistency):
  • 쓰기 완료 후 모든 읽기는 즉시 최신 데이터 보장 [01:29:13].
  • 동기화 대기 시간으로 인한 레이턴시 증가 및 가용성(Availability) 저하 (CAP 중 CP선택) [01:29:30], [01:31:41].
  • 적용: 금융, 결제, 재고 [01:30:51].
• 최종 일관성 (Eventual Consistency):
  • 일시적 불일치를 허용하되, 일정 시간 후 결국 동기화됨 [01:29:45].
  • 대기 없이 빠른 응답 및 높은 가용성 제공 (CAP 중 AP선택) [01:30:00], [01:32:00].
  • 적용: SNS 좋아요/피드, 조회수, 캐싱 [01:31:11].

13. SQL vs NoSQL [01:35:07]

• SQL (RDB): ACID 트랜잭션, 고정 스키마, 복잡한 조인 지원, 스케일업 중심 [01:35:55]. (예: PostgreSQL, MySQL, Oracle)
• NoSQL: BASE (Basically Available, Soft-state, Eventual consistency), 동적 스키마, 수평 확장(스케일아웃) 용이 [01:36:55]. (예: MongoDB, Redis, DynamoDB)
• 최신 트렌드: 경계 모호화 (RDB의 JSON/Vector/분산 확장에 대한 지원 vs NoSQL의 ACID 트랜잭션 지원) → 도메인별 최적 DB를 혼용하는 Polyglor Persistence 전략 선호 [01:38:10], [01:14:04].

14. CQRS (Command Query Responsibility Segregation) 패턴 [01:42:31]

• 개념: 상태 변경(Command: CUD) 작업 모델과 조회(Query: R) 작업 모델의 책임을 분리하는 아키텍처 패턴 [01:43:43].
• 필요성: MSA 환경에서 파편화된 DB 간 조인 불가의 문제 해결 및 쓰기/읽기 개별 스케일링 [01:43:05], [01:45:05].
• 구현:
  • Write DB (RDB 등) → CDC/Kafka 등 메시지 큐 → Read DB (NoSQL/Elasticsearch 등에 반정규화 저장) [01:45:16], [01:45:26].
  • 데이터 동기화는 최종 일관성(Eventual Consistency) 모델을 따름 [01:46:41].

15. 원본 데이터 - 보조 저장소 패턴 (Source of Truth & Auxiliary Store) [01:49:48]

• 핵심 원칙:
  • Source of Truth (RDB): 정합성/트랜잭션을 책임지는 원본 데이터 [01:53:34].
  • 보조 저장소 (Auxiliary Store): 특정 워크로드(검색, 랭킹, 캐시 등)에 특화된 저장소 [01:54:08].
  • 보조 저장소 데이터가 소멸되어도 원본 DB에서 100% 재구성(Rebuild) 가능해야 함 [01:54:38].
• 2단계 패치 패턴 (Two-Stage Fetch) [01:57:02]:
  1. 보조 저장소(Elasticsearch, Redis)에서 조건에 맞는 PK(ID) 목록만 빠르게 조회 [01:57:02].
  2. 추려낸 PK 목록을 가지고 원본 RDB에서 인덱스 PK 조회를 통해 상세 데이터 로드 [01:57:12].
• 주의사항: 두 저장소 간 Dual Write 데이터 불일치 이슈 방지를 위해 CDC, Outbox Pattern 등을 적용해 최종 일관성 유지 [02:00:58], [02:01:25].

16. DB 커넥션 풀(Connection Pool) 적정 사이즈 공식 [02:02:53]

• 오해: 커넥션 수를 무조건 늘리면 처리량이 늘어난다? (X) → 컨텍스트 스위칭, 락 경합, 캐시 미스로 인해 어느 시점 이후에는 오히려 처리량 저하 [02:10:33], [02:21:32].
• PostgreSQL / HikariCP 추천 적정 공식 [02:12:08]:
  $$\text{Pool Size} = (\text{DB 서버의 물리 CPU Core 수} \times 2) + \text{Spindle Count}$$
  *(단, SSD/NVMe 환경에서는 Spindle Count = 0 적용 $\to$ $\text{물리 Core} \times 2$*가 출발 기준점) [02:14:23], [02:20:26].
• 다중 WAS 인스턴스 할당 주의:
  • 계산된 전체 풀 한계가 16개이고 WAS가 4대라면, WAS당 커넥션 풀은 $\mathbf{16 \div 4 = 4}$개 수준으로 분배해야 함 (WAS별로 16개씩 지정하면 DB 전체 맥스 커넥션 초과 위험) [02:27:29].
• 진단 원칙: 처리량이 부족할 때는 커넥션 수 증설보다 쿼리 실행 시간 단축(인덱스/튜닝)이 우선 [02:24:26].

17. 실무 직무 갈등 해결기 (개발자 vs DBA) [02:40:28]

• 갈등의 본질: 기술 문제가 아닌 우선순위와 책임 범위(Risk/Accountability)의 차이 (개발자: 생산성/신기술 vs DBA: 가용성/안정성) [02:41:51], [02:44:43].
• 해결 방안:
  1. 트레이드오프 가시화: 비용, 속도, 자원 경합, 장애 책임 표 작성 [02:48:25].
  2. 물리적 인스턴스 분리: 동일 기술을 쓰더라도 운영 DB와 별도 인스턴스로 분리해 자원/장애 격리 [02:50:42].
  3. PoC 및 단계적 도입: 소규모 PoC 실행 후 지표(응답시간/자원사용률) 모니터링을 거쳐 확정 [02:52:22].

18. AI 시대의 DB 자격증(SQLP, DAP 등)의 가치 [02:55:28]

• 핵심 명제: AI가 코딩/쿼리를 대신 작성해 줄수록 결과물의 정합성/성능/실행계획을 검증하고 제대로 지시(Prompting)할 수 있는 인간의 본질적 DB 지식 가치가 상승함 [02:58:13], [02:59:28].
• 자격증 자체는 기본기와 성실함의 증명이며, 데이터 모델링·인덱스·실행 계획·트랜잭션 구조 등 DB 본질을 이해하는 역량이 AI 시대의 차별화 요소가 됨 [02:57:02], [03:02:22].