11. 회복과 병행 - 트랜잭션, 장애와 회복, 병행 제어

 

💡 1분 핵심 요약 (TL;DR)

• ✅ 트랜잭션 — 하나의 작업을 위한 연산들의 논리적 묶음, all-or-nothing으로 실행
• ✅ ACID — 원자성·일관성·격리성·지속성, DBMS의 회복 기능과 병행 제어 기능이 이를 보장
• ✅ 회복(recovery) — 로그와 덤프를 이용해 장애 발생 전 상태로 데이터베이스를 되돌리는 기능
• ✅ 병행 제어 — 여러 트랜잭션이 동시에 실행돼도 순차 실행과 같은 정확한 결과를 보장하는 기법 (로킹 등)

 

데이터베이스는 항상 여러 사용자가 동시에 접근하고, 언제 정전이나 하드웨어 장애가 날지 모릅니다. 이런 상황에서도 데이터를 정확하고 안전하게 지키기 위한 것이 트랜잭션, 회복, 병행 제어입니다. 이번 포스팅에서는 트랜잭션의 개념과 ACID 특성부터, 장애가 났을 때 데이터베이스를 되돌리는 회복 기법, 여러 트랜잭션이 충돌 없이 동시에 실행되도록 하는 병행 제어까지 정리했습니다.

 

 

 

01 트랜잭션이란? — 하나로 묶여 실행되는 연산들

계좌이체와 상품주문 예제로 이해하기

 

📖 트랜잭션(Transaction)이란?
하나의 작업을 수행하는 데 필요한 데이터베이스 연산들을 모아놓은 논리적인 작업 단위입니다. 데이터베이스를 변경하는 INSERT·DELETE·UPDATE 문의 실행을 관리하며, 장애 발생 시 복구나 병행 제어 작업을 위한 핵심 단위이기도 합니다.

 

예) 계좌이체 트랜잭션 — 성호 계좌에서 5,000원을 인출해 은경 계좌에 5,000원을 입금하는 작업입니다. 처리 순서는 중요하지 않지만, 두 UPDATE문이 모두 정상적으로 실행되어야 합니다.

 

계좌이체 트랜잭션

① 성호 계좌에서 5,000원 인출
UPDATE 계좌
SET    잔액 = 잔액 - 5000
WHERE  계좌번호 = 100;

② 은경 계좌에 5,000원 입금
UPDATE 계좌
SET    잔액 = 잔액 + 5000
WHERE  계좌번호 = 200;

 

계좌이체 전 성호 잔액 : 10,000원 은경 잔액 : 0원

계좌이체 트랜잭션 →

계좌이체 후 성호 잔액 : 5,000원 은경 잔액 : 5,000원

 

예) 상품주문 트랜잭션도 마찬가지입니다. 새 주문 내역을 추가(INSERT)하는 연산과, 그만큼 재고량을 차감(UPDATE)하는 연산이 둘 다 정상 실행되어야 트랜잭션이 성공적으로 수행됩니다.

 

상품주문 트랜잭션

① 새로운 주문 내역 추가
INSERT
INTO 주문(주문번호, 주문고객, 주문제품, 주문수량, 주문날짜)
VALUES ('o11', 'apple', 'p01', 10, '2022-10-10');

② 주문제품의 재고량 수정
UPDATE 제품
SET    재고량 = 재고량-10
WHERE  제품번호 = 'p01';

 

상품주문 전 주문수량 : 0개 재고량 : 100개

상품주문 트랜잭션 →

상품주문 후 주문수량 : 10개 재고량 : 90개

 

 

 

02 트랜잭션의 4가지 특성 — ACID

원자성·일관성·격리성·지속성

 

✓ 원자성 (Atomicity)
트랜잭션의 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 하는 all-or-nothing 방식입니다. 수행 도중 장애가 발생하면 지금까지 실행한 연산을 모두 취소하고 트랜잭션 이전 상태로 되돌려야 하며, 이를 위해 회복 기능이 필요합니다.

 

✓ 일관성 (Consistency)
트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 합니다. 계좌이체 예제에서 이체 전후로 두 계좌의 잔액 합계는 항상 10,000원으로 동일해야 합니다. 만약 두 번째 UPDATE가 실행되지 않은 채 트랜잭션이 끝나버리면, 합계가 5,000원으로 줄어드는 모순된 데이터가 남게 됩니다.

 

✓ 격리성 (Isolation)
수행 중인 트랜잭션이 완료될 때까지 다른 트랜잭션이 중간 연산 결과에 접근할 수 없어야 합니다. 계좌이체 트랜잭션이 성호 잔액을 5,000원으로 바꾼 '중간 결과'를, 아직 완료되지 않은 계좌입금 트랜잭션이 가져다 쓰면 안 됩니다 — 여러 트랜잭션이 동시에 수행돼도 마치 순서대로 하나씩 실행된 것처럼 정확한 결과를 얻도록 제어해야 합니다.

 

✓ 지속성 (Durability)
트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 영구적이어야 합니다. 이 보장을 위해서도 장애 발생 시 회복 기능이 필요합니다.

 

 

이 4가지 특성은 결국 DBMS의 두 가지 기능이 나눠서 보장합니다.

 

트랜잭션의 특성	이를 보장하는 DBMS의 기능
원자성	회복 기능
일관성	병행 제어 기능
격리성	병행 제어 기능
지속성	회복 기능

 

 

 

03 트랜잭션의 상태와 COMMIT / ROLLBACK

활동 → 부분완료 → 완료, 혹은 실패 → 철회

 

트랜잭션은 수행되는 동안 아래 5가지 상태 중 하나를 거칩니다.

 

활동 (수행 시작)

→

부분 완료 (마지막 연산 종료)

→

완료 (commit 실행)

실패 (장애 발생)

→

철회 (rollback 실행)

※ 활동 상태의 트랜잭션은 정상적으로 부분 완료 → 완료로 이어지거나, 장애가 발생하면 실패 → 철회로 이어집니다.

 

 

상태	의미
활동(active)	트랜잭션이 수행되기 시작하여 현재 수행 중인 상태
부분 완료(partially committed)	트랜잭션의 마지막 연산이 실행을 끝낸 직후의 상태
완료(committed)	commit 연산을 실행해 최종 결과를 DB에 반영하고, 새로운 일관된 상태가 되며 트랜잭션이 종료된 상태
실패(failed)	장애가 발생하여 트랜잭션의 수행이 중단된 상태
철회(aborted)	rollback 연산을 실행해 트랜잭션 수행 전 상태로 되돌리고 종료된 상태. 상황에 따라 재수행되거나 폐기됨

 

연산	의미
COMMIT	트랜잭션의 수행이 성공적으로 완료되었음을 선언하는 연산. 실행되면 수행 결과가 DB에 반영되고 일관된 상태를 지속 유지
ROLLBACK	트랜잭션의 수행이 실패했음을 선언하는 연산. 실행되면 지금까지의 연산 결과가 취소되고 DB가 수행 전의 일관된 상태로 되돌아감

 

 

 

04 장애(failure)의 종류와 회복의 기본 개념

시스템이 제대로 동작하지 않는 세 가지 상황

 

📖 장애(failure)란?
시스템이 제대로 동작하지 않는 상태를 말합니다. 발생 위치와 원인에 따라 세 가지로 나뉩니다.

 

유형	의미	원인
트랜잭션 장애	수행 중 오류가 발생해 정상 수행을 계속할 수 없는 상태	논리적 오류, 잘못된 데이터 입력, 자원 과다 요구, 처리 대상 데이터 부재 등
시스템 장애	하드웨어 결함으로 정상 수행을 계속할 수 없는 상태	메인 메모리 정보 손실, 교착 상태 발생 등
미디어 장애	디스크 장치 결함으로 DB의 일부·전체가 손상된 상태	디스크 헤드 손상, 고장 등

 

데이터베이스는 일반적으로 비휘발성 저장 장치인 디스크에 저장되어 있습니다. 저장 장치는 장애에 대한 안전성에 따라 세 종류로 나뉩니다.

 

저장 장치	특징	예
휘발성 (소멸성)	장애가 발생하면 저장된 데이터가 손실됨	메인 메모리
비휘발성 (비소멸성)	장애가 발생해도 데이터가 손실되지 않음. 단, 저장 장치 자체가 손상되면 손실될 수 있음	디스크, 자기 테이프, CD/DVD
안정 저장 장치	비휘발성 장치에 복사본을 여러 개 만들어, 어떤 장애가 나도 데이터를 영구적으로 보존	이중화된 디스크 등

 

트랜잭션이 데이터를 처리하려면 디스크 ↔ 메인 메모리 ↔ 프로그램 변수 사이에서 데이터를 옮기는 연산이 필요합니다.

 

디스크

← input(X) output(X) →

메인 메모리 (버퍼 블록)

← read(X) write(X) →

변수

· input(X)/output(X) : 디스크 ↔ 메인 메모리 버퍼 블록 간 데이터 이동, 블록 단위로 수행  |  · read(X)/write(X) : 메인 메모리 버퍼 블록 ↔ 프로그램 변수 간 데이터 이동

 

 

 

05 회복(recovery) 기법 3가지

즉시 갱신, 지연 갱신, 검사 시점

 

📖 회복(recovery)이란?
장애가 발생했을 때 데이터베이스를 장애 발생 전의 일관된 상태로 복구시키는 것입니다. 회복 관리자(recovery manager)가 장애 발생을 탐지하고 복구 기능을 제공합니다.

 

 

회복을 위해서는 먼저 데이터베이스의 복사본이 있어야 하고, 이를 바탕으로 redo(재실행) 또는 undo(취소) 연산을 수행합니다.

 

복사본 방법	설명
덤프(dump)	데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
로그(log)	변경 연산이 실행될 때마다 변경 전·후 값을 별도 파일에 기록하는 방법

 

💡 로그 회복의 대원칙 : WAL (Write-Ahead Logging)
장애가 발생했을 때 로그를 보고 정확히 복구하려면, 실제 데이터베이스(디스크)에 변경된 값을 기록하기 전에 반드시 로그 파일(안정 저장 장치)에 변경 내역을 먼저 기록해야 합니다. 이를 쓰기 선행 로그(WAL, Write-Ahead Logging) 프로토콜이라 부르며, 즉시 갱신·지연 갱신 등 로그 기반 회복 기법이 정상 동작하기 위한 절대 원칙입니다.

 

기본 연산	설명
redo (재실행)	가장 최근 복사본을 가져온 뒤, 로그를 이용해 그 이후 실행된 모든 변경 연산을 재실행 (전반적으로 손상된 경우 주로 사용)
undo (취소)	로그를 이용해 지금까지 실행된 모든 변경 연산을 취소 (변경 중이었거나 신뢰성을 잃은 경우 주로 사용)

 

이를 바탕으로 한 대표적인 회복 기법 3가지는 다음과 같습니다.

 

✓ 즉시 갱신(immediate update) 회복 기법
트랜잭션 수행 중 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영합니다. 장애에 대비해 변경 내용을 로그 파일에도 기록해두고, 장애 발생 시점에 따라 redo나 undo를 실행해 복구합니다.

 

✓ 지연 갱신(deferred update) 회복 기법
트랜잭션 수행 중에는 변경 결과를 로그에만 기록해두고, 부분 완료된 후에 로그 내용을 이용해 데이터베이스에 한 번에 반영합니다. 수행 중 장애가 나면 로그 내용을 버리기만 하면 되므로 undo가 필요 없습니다.

 

✓ 검사 시점(checkpoint) 회복 기법
로그 기록을 이용하되, 일정 시간 간격으로 검사 시점을 만들어둡니다. 장애 발생 시 가장 최근 검사 시점 이후의 트랜잭션에만 회복 작업을 수행해, 로그 전체를 대상으로 할 때 생기는 비효율을 해결합니다.

 

 

 

06 병행 제어 — 문제점, 스케줄, 로킹 기법

여러 트랜잭션이 부딪히지 않고 동시에 실행되려면

 

📖 병행 수행(concurrency)과 병행 제어(concurrency control)
병행 수행은 여러 사용자가 DB를 동시에 공유하도록 여러 트랜잭션을 동시에 실행하는 것으로, 실제로는 트랜잭션들이 번갈아 실행되는 인터리빙(interleaving) 방식으로 진행됩니다. 병행 제어는 이 과정에서 문제가 발생하지 않고 정확한 결과를 얻도록 트랜잭션 수행을 제어하는 것입니다.

 

병행 수행 시 발생할 수 있는 대표적인 문제점 3가지입니다.

 

문제점	설명
갱신 분실 (lost update)	한 트랜잭션이 변경한 결과를 다른 트랜잭션이 덮어써서 변경 연산이 무효화되는 것
모순성 (inconsistency)	한 트랜잭션이 일관성 없는 상태의 DB에서 데이터를 가져와 연산해 모순된 결과가 발생하는 것
연쇄 복귀 (cascading rollback)	한 트랜잭션이 rollback되면, 그 트랜잭션이 변경한 데이터를 가져다 쓴 다른 트랜잭션에도 rollback이 연쇄적으로 실행돼야 하는 것
비완료 의존성 (Dirty Read)	한 트랜잭션이 아직 완료(commit)되지 않고 수행 중인 다른 트랜잭션의 중간 연산 결과를 읽어다 썼는데, 그 트랜잭션이 결국 철회(rollback)되면서 잘못된 데이터를 사용하게 되는 현상

병행 제어의 목표는 이 문제들 없이, 트랜잭션들을 순차적으로 수행한 것과 같은 결과를 얻는 것입니다.

 

트랜잭션의 연산 실행 순서를 스케줄이라 하며, 다음 세 종류로 나뉩니다.

 

스케줄	의미
직렬 스케줄	인터리빙 없이 트랜잭션별로 순차 실행. 항상 정확하지만 병행 수행은 아님
비직렬 스케줄	인터리빙으로 병행 수행. 갱신 분실·모순성·연쇄 복귀 등이 발생할 수 있어 정확성을 보장 못 함
직렬 가능 스케줄	비직렬 스케줄 중 직렬 스케줄과 동일한 정확한 결과를 내는 것. 병행하면서도 정확성을 얻을 수 있음

 

⚠️ 로킹(locking) 기법 — 가장 널리 쓰이는 병행 제어 방법
한 트랜잭션이 먼저 접근한 데이터의 연산을 끝낼 때까지 다른 트랜잭션이 접근하지 못하도록 상호 배제합니다.
· lock : 트랜잭션이 데이터에 대한 독점권을 요청하는 연산
· unlock : 독점권을 반환하는 연산

기본 로킹 규약 : read/write 연산 전에 반드시 lock을 실행해야 하고, 이미 다른 트랜잭션이 lock한 데이터는 다시 lock할 수 없으며, 모든 연산이 끝나면 unlock으로 반납해야 합니다.

로킹 단위는 전체 데이터베이스부터 릴레이션, 튜플, 속성까지 다양하게 정할 수 있는데, 단위가 커질수록 병행성은 낮아지지만 제어는 쉬워지고, 단위가 작아질수록 병행성은 높아지지만 제어는 어려워집니다.

 

📖 2단계 로킹 규약 (2PLP, 2 Phase Locking Protocol)
기본 로킹 규약만으로는 직렬 가능성이 보장되지 않아, lock·unlock 연산을 확장 단계와 축소 단계로 나누는 규약을 추가한 것입니다. 트랜잭션은 확장 단계에서는 lock 연산만, 첫 unlock 이후의 축소 단계에서는 unlock 연산만 실행할 수 있습니다 — 즉, 필요한 모든 lock을 첫 unlock 전에 미리 다 걸어둬야 합니다.

 

❌ 교착 상태(deadlock)
트랜잭션들이 서로 상대가 독점한 데이터의 unlock을 기다리며 수행을 멈춘 상태입니다. 2PLP가 직렬 가능성은 보장하지만 교착 상태까지 막아주지는 않으므로, 별도의 예방 또는 탐지·해소 조치가 필요합니다.

 

💡 실무 팁 : 트랜잭션 격리 수준(Isolation Level)
완벽한 병행 제어(직렬성 보장)는 Lock을 강하게 걸어야 해서 데이터베이스의 동시 처리 성능을 크게 떨어뜨립니다. 그래서 실제 MySQL·Oracle 같은 DBMS는 READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE의 4단계 격리 수준을 제공해, 개발자가 서비스 성격에 맞게 성능과 데이터 일관성 사이에서 타협할 수 있도록 설계되어 있습니다. 앞서 다룬 더티 리드는 격리 수준이 가장 낮은 READ UNCOMMITTED에서 발생할 수 있는 대표적인 현상입니다.

 

 

📌 핵심 정리

· 트랜잭션 : 하나의 작업을 위한 연산들의 논리적 묶음, all-or-nothing으로 실행되어야 함
· ACID : 원자성·지속성 → 회복 기능이 보장 / 일관성·격리성 → 병행 제어 기능이 보장
· 트랜잭션 상태 : 활동 → 부분완료 → 완료(COMMIT), 또는 활동 → 실패 → 철회(ROLLBACK)
· 장애 3종류 : 트랜잭션 장애, 시스템 장애, 미디어 장애
· 회복 기법 : 즉시 갱신(즉시 반영+redo/undo), 지연 갱신(로그만 기록 후 일괄 반영), 검사 시점(최근 체크포인트 이후만 복구) — 모두 WAL(쓰기 선행 로그) 원칙을 전제로 함
· 병행 수행 문제 : 갱신 분실, 모순성, 연쇄 복귀, 비완료 의존성(Dirty Read) — 직렬 가능 스케줄로 정확성을 보장해야 함
· 로킹 기법 : lock/unlock으로 상호 배제, 2PLP로 직렬 가능성 보장, 단 교착 상태는 별도로 관리 필요
· 격리 수준(Isolation Level) : READ UNCOMMITTED~SERIALIZABLE 4단계로 성능과 일관성을 실무적으로 타협

 

 

태그 : 트랜잭션이란ACID 특성 원자성 일관성COMMIT ROLLBACK트랜잭션 상태 다이어그램장애 유형 회복 기법즉시갱신 지연갱신 검사시점redo undo 연산병행 제어 갱신분실 모순성로킹 기법 2PLP교착상태 deadlockWAL Write-Ahead Logging더티리드 Dirty Read트랜잭션 격리수준 Isolation Level