병행 제어·회복과 NoSQL

⚠️ 병행 제어의 필요성과 이상현상

이 섹션에서는 여러 트랜잭션이 동시에 실행될 때 발생하는 이상현상과 병행 제어의 필요성을 살펴보겠습니다.

병행 제어(Concurrency Control)는 여러 트랜잭션이 동시에 실행될 때 데이터 일관성을 유지하기 위한 기법입니다. 병행 처리가 없으면 성능이 저하되고, 병행 제어 없이 처리하면 데이터 불일치가 발생합니다.

병행 처리 시 발생할 수 있는 3가지 이상현상은 다음과 같습니다.

갱신 분실(Lost Update): 두 트랜잭션이 같은 데이터를 읽고 수정할 때, 먼저 수정한 트랜잭션의 변경이 나중 트랜잭션에 의해 덮어씌워져 사라지는 현상입니다. T1이 잔액 1000→1500으로 수정했는데, T2가 같은 원본값 1000을 읽어 1200으로 수정하면 T1의 수정이 사라집니다.

미완료 의존(Dirty Read, Uncommitted Dependency): 아직 COMMIT되지 않은 트랜잭션의 데이터를 다른 트랜잭션이 읽는 현상입니다. T1이 데이터를 수정했다가 ROLLBACK하면, 그 수정된 값을 읽었던 T2는 잘못된 데이터를 사용하게 됩니다.

불일치 분석(Inconsistent Analysis, Non-repeatable Read): 한 트랜잭션 내에서 같은 데이터를 두 번 읽었는데 결과가 다른 현상입니다. T1이 데이터를 읽는 도중 T2가 수정하면 발생합니다.

🔒 로킹 프로토콜 — 2PL과 락의 종류

이 섹션에서는 병행 제어의 핵심 기법인 로킹과 2단계 로킹(2PL) 프로토콜을 살펴보겠습니다.

로킹(Locking)은 트랜잭션이 데이터에 접근할 때 잠금(Lock)을 걸어 다른 트랜잭션의 접근을 제어하는 방식입니다.

락 종류	읽기 허용	쓰기 허용	설명
공유 락(Shared Lock, S-Lock)	O (다른 S-Lock도 허용)	X	읽기 전용 접근, 여러 트랜잭션 동시 허용
배타 락(Exclusive Lock, X-Lock)	X	X	쓰기 접근, 단독 독점, 다른 모든 락 불허

2단계 로킹(2-Phase Locking, 2PL) 프로토콜은 트랜잭션의 락 연산을 확장 단계(Growing Phase)와 수축 단계(Shrinking Phase) 두 단계로 나눕니다. 확장 단계에서는 새로운 락만 획득하고 해제하지 않습니다. 수축 단계에서는 락만 해제하고 새로운 락을 획득하지 않습니다. 2PL은 직렬성(Serializability)을 보장하지만 교착 상태(Deadlock)가 발생할 수 있습니다.

교착 상태(Deadlock): T1이 A를 잠그고 B를 기다리고, T2가 B를 잠그고 A를 기다리는 상황. 해결 방법: 탐지 후 한 트랜잭션 중단(희생자 선택), 타임아웃, 예방(락 순서 고정).

타임스탬프 기반 제어: 트랜잭션 시작 시 타임스탬프를 부여하고, 오래된 트랜잭션이 우선권을 갖습니다. 교착 상태가 발생하지 않지만 직렬 가능성을 위해 트랜잭션이 롤백될 수 있습니다.

낙관적 검증(Optimistic Concurrency Control): 충돌이 적다고 가정하고 락 없이 실행 후, 완료 시 충돌 여부를 검증합니다. 실제 충돌이 적은 환경에서 성능이 좋습니다.

🔄 데이터베이스 회복 기법

이 섹션에서는 시스템 장애 발생 시 데이터베이스를 정상 상태로 복구하는 회복 기법을 살펴보겠습니다.

UNDO는 미완료 트랜잭션의 변경을 취소하여 원래 상태로 되돌리는 연산입니다. 장애 발생 시점에 COMMIT되지 않은 트랜잭션에 적용합니다.

REDO는 이미 COMMIT된 트랜잭션의 변경을 재실행하는 연산입니다. 장애로 인해 디스크에 반영되지 못한 COMMIT 결과를 복구합니다.

회복 기법	원리	특징
로그 기반 회복	변경 전후 값을 로그에 기록	UNDO/REDO 로그 사용, 가장 일반적
체크포인트 회복	주기적으로 체크포인트 저장	회복 범위를 최근 체크포인트부터로 제한하여 빠름
그림자 페이지 회복	변경 전 페이지 사본 유지	로그 불필요, 단 페이지 전환 오버헤드

회복 절차: 장애 발생 → 로그 분석 → UNDO 목록(미완료 트랜잭션)과 REDO 목록(COMMIT 완료 트랜잭션) 구분 → UNDO 트랜잭션 롤백 → REDO 트랜잭션 재실행.

기출 함정: "UNDO는 COMMIT된 트랜잭션에 적용한다" → 틀림. UNDO는 미완료(COMMIT 안 된) 트랜잭션에 적용합니다. "REDO는 롤백을 위한 연산이다" → 틀림. REDO는 재실행입니다.

🌐 CAP 정리와 NoSQL 4분류

이 섹션에서는 분산 데이터베이스의 한계를 설명하는 CAP 정리와 NoSQL 데이터베이스의 4가지 분류를 살펴보겠습니다.

CAP 정리(CAP Theorem)는 분산 데이터베이스 시스템에서 다음 세 가지 특성 중 동시에 두 가지만 보장할 수 있다는 이론입니다.

• 일관성(Consistency): 모든 노드가 동시에 같은 데이터를 반환
• 가용성(Availability): 모든 요청에 항상 응답 (단, 최신 데이터 보장 안 함)
• 분산 허용(Partition Tolerance): 네트워크 분단이 발생해도 시스템 운영 지속

실제 분산 시스템에서 네트워크 분단(P)은 피할 수 없으므로, CA와 CP 또는 AP 중 선택하게 됩니다. CA(일관성+가용성): 단일 서버 RDBMS, CP(일관성+분산): ZooKeeper·HBase, AP(가용성+분산): Cassandra·CouchDB.

NoSQL 유형	특징	대표 제품	적합 사례
Key-Value	키-값 쌍 저장, 단순하고 빠름	Redis, DynamoDB, Riak	세션, 캐시, 순위표
Document	JSON/BSON 문서 저장, 유연한 스키마	MongoDB, CouchDB, Firestore	콘텐츠 관리, 사용자 프로필
Column	열 단위 저장, 대용량 분산 처리	HBase, Cassandra, BigTable	로그, 시계열 데이터, IoT
Graph	노드·엣지로 관계 표현	Neo4j, Amazon Neptune	SNS 친구 관계, 추천 시스템

암기법: "키도컬그(키도 컬러 그림)" — Key-Value·Document·Column·Graph 4분류. Redis=Key-Value(캐시), MongoDB=Document(JSON), HBase/Cassandra=Column(대용량), Neo4j=Graph(관계).

기출 함정: "NoSQL은 ACID를 완전히 지원한다" → 일반적으로 틀림. 대부분의 NoSQL은 BASE(Basically Available, Soft state, Eventually consistent)를 따릅니다. "MongoDB는 컬럼형 데이터베이스이다" → 틀림. MongoDB는 도큐먼트형입니다.

📌 15강 핵심 요약과 16강 예고

이 섹션에서는 15강 핵심 내용을 압축 정리합니다.

병행 이상현상: 갱신분실·미완료의존(Dirty Read)·불일치분석. 로킹: S-Lock(읽기공유)·X-Lock(쓰기독점). 2PL=확장단계+수축단계, 직렬성 보장, 교착 상태 가능.

회복: UNDO=미완료 트랜잭션 취소, REDO=COMMIT 결과 재실행. 로그기반·체크포인트·그림자페이지. CAP정리=C·A·P 중 2가지만 선택. NoSQL 4분류: "키도컬그" — Key-Value(Redis)·Document(MongoDB)·Column(HBase)·Graph(Neo4j).

다음 16강에서는 C 언어 기출 완전정복 — 포인터 계산, 구조체·공용체, 재귀함수, 비트연산자, 전처리기, 기출 코드 5대 패턴을 완벽히 정리합니다.