# 데이터베이스 트랜잭션의 지속성 (Durability)

## 개요

데이터베이스 시스템에서 **지속성(Durability)**은 ACID 트랜잭션의 네 가지 핵심 속성(Availability, Consistency, Isolation, Durability) 중 하나로, 트랜잭션이 성공적으로 커밋(Commit)된 후에도 그 결과는 영구적으로 저장되어 시스템 장애가 발생하더라도 손실되지 않음을 보장하는 속성입니다. 즉, 트랜잭션이 완료되었다는 신호를 사용자에게 반환했다는 것은 해당 데이터 변경 사항이 비휘발성 저장 매체(예: 하드 디스크, SSD)에 물리적으로 기록되었음을 의미합니다.

지속성은 데이터 무결성과 신뢰성을 유지하는 데 있어 가장 중요한 요소 중 하나입니다. 만약 지속성이 보장되지 않는다면, 서버의 전원 차단이나 하드웨어 고장 시 모든 작업이 초기 상태로 돌아갈 수 있어 금융 거래, 주문 처리 등 중요한 비즈니스 로직에서 치명적인 오류를 초래할 수 있습니다.

## 지속성의 작동 원리

데이터베이스가 트랜잭션의 지속성을 보장하기 위해 사용하는 주요 메커니즘은 **로그(Log)** 기반의 접근 방식입니다. 대부분의 현대 관계형 데이터베이스管理系统(RDBMS)는 'Write-Ahead Logging(WAL, 선기록)' 프로토콜을 따릅니다.

### 1. 선기록 (Write-Ahead Logging, WAL)

WAL 원칙에 따르면, 데이터 파일(Dat File)에 변경 사항을 쓰기 전에 해당 변경 사항을 로그 파일(Log File)에 먼저 기록해야 합니다. 로그 파일은 일반적으로 순차적으로 기록되므로 디스크 I/O 성능이 매우 우수합니다.

*   **로그의 역할**: 로그 파일에는 트랜잭션의 시작, 각 데이터 변경 내용(이전 값과 현재 값), 그리고 커밋 또는 롤백 신호가 기록됩니다.
*   **커밋 과정**: 트랜잭션이 커밋되면, 데이터베이스 엔진은 해당 트랜잭션의 로그 레코드가 디스크에 물리적으로 플러시(Flush)되었음을 확인한 후 클라이언트에게 커밋 성공 신호를 보냅니다.
*   **데이터 파일 업데이트**: 실제 데이터 파일은 백그라운드 스레드나 체크포인트(Checkpoint) 시기에 비동기적으로 업데이트됩니다. 이로 인해 커밋 시점과 실제 데이터 파일 반영 시점 사이에 시간차가 발생할 수 있지만, 로그가 저장되었으므로 지속성은 보장됩니다.

### 2. 체크포인트 (Checkpoint)

체크포인트는 데이터베이스의 상태가 특정 시점에서 일관된 상태임을 기록하는 메커니즘입니다. 체크포인트가 생성되면, 그 시점 이전에 커밋된 모든 트랜잭션의 변경 사항이 데이터 파일에 반영되었음을 의미합니다. 이를 통해 시스템이 재시작될 때 복구해야 할 로그의 범위를 줄여 복구 시간을 단축할 수 있습니다.

## 지속성 보장과 성능의 트레이드오프

지속성을 완벽하게 보장하려면 매 커밋마다 디스크에 물리적으로 데이터를 기록해야 하므로, 이는 시스템의 쓰기 성능에 상당한 영향을 미칩니다. 따라서 데이터베이스는 지속성 수준을 설정할 수 있는 옵션을 제공하는 경우가 많습니다.

| 지속성 모드 | 설명 | 성능 vs 안전성 |
| :--- | :--- | :--- |
| **강한 지속성 (Strong Durability)** | 커밋 시 로그가 디스크에 물리적으로 기록될 때까지 대기합니다. 시스템 장애 시 데이터 손실이 없습니다. | 성능이 낮으나 데이터 안전성이 가장 높습니다. 금융 시스템 등에서 기본값으로 사용됩니다. |
| **느슨한 지속성 (Relaxed Durability)** | 커밋 시 로그가 OS의 캐시 버퍼에만 기록하고 즉시 디스크에 플러시하지 않습니다. | 성능이 높으나, 커밋 직후 시스템 장애 시 데이터 손실 가능성이 있습니다. |
| **비동기 복제 (Asynchronous Replication)** | 주 서버에서 로그를 복제 서버에 비동기로 전송합니다. | 분산 시스템에서 가용성을 높이지만, 주 서버 장애 시 복제되지 않은 데이터가 손실될 수 있습니다. |

## 장애 발생 시 지속성 복구

시스템이 다운된 후 재시작될 때, 데이터베이스는 **복구(Recovery)** 과정을 통해 지속성을 검증하고 보장된 트랜잭션의 변경 사항을 적용합니다. 이 과정은 일반적으로 UNDO(실행 취소)와 REDO(재실행) 두 가지 연산을 사용합니다.

1.  **REDO (재실행)**: 커밋된 트랜잭션이지만 데이터 파일에 반영되지 않은 변경 사항을 로그를 바탕으로 다시 적용합니다.
2.  **UNDO (실행 취소)**: 커밋되지 않은 트랜잭션(중단된 트랜잭션)이 데이터 파일에 일부 변경 사항을 남겼을 경우, 이를 원래 상태로 되돌립니다.

이러한 복구 프로세스는 데이터베이스가 예기치 않은 중단 후에도 일관된 상태로 재시작할 수 있도록 하여 지속성의 실질적인 구현을 가능하게 합니다.

## 관련 개념 및 참고 문서

*   **ACID 트랜잭션**: 지속성을 포함한 데이터베이스 트랜잭션의 네 가지 핵심 속성.
*   **Write-Ahead Logging (WAL)**: 지속성을 구현하기 위한 표준 로그 구조.
*   **Two-Phase Commit (2PC)**: 분산 데이터베이스 환경에서 트랜잭션의 지속성과 일관성을 보장하는 프로토콜.
*   **RAID 및 스토리지 시스템**: 물리적 디스크 장애로부터 로그와 데이터를 보호하는 하드웨어 수준의 지속성 메커니즘.

지속성은 단순한 기술적 요구사항을 넘어, 디지털 시대에 신뢰할 수 있는 정보 시스템을 구축하는 데 필수적인 기반입니다. 개발자와 데이터베이스 관리자(DBA)는 시스템의 요구 사항(성능 vs 안전성)에 따라 적절한 지속성 설정을 선택하고 모니터링해야 합니다.