백업과 복구 (WAL, REDO·UNDO, 체크포인트)
은행 시스템이 입금 처리 도중 정전으로 멈췄다고 하자. 돈은 빠져나갔는데 입금 기록이 디스크에 닿기 전이었다면, 그 돈은 어디로 사라질까. 데이터베이스가 신뢰받는 이유는 바로 이런 장애 상황에서도 데이터를 한 푼도 잃지 않고, 멈춘 지점에서 정확히 복구하는 능력에 있다. 그 능력의 핵심 엔진이 로그 기반 복구이며, 그중에서도 거의 모든 현대 데이터베이스가 쓰는 기법이 WAL(Write-Ahead Logging)이다. 본 글은 트랜잭션 장애 복구의 원리, WAL의 핵심 규칙, REDO와 UNDO의 차이, 그리고 복구 시간을 줄이는 체크포인트를 세심하게 정리한다(출처: PostgreSQL 공식 문서 — Write-Ahead Logging (WAL)). 제가 데이터베이스 시스템 수업에서 "데이터를 디스크에 쓰기 전에 로그부터 쓴다"는 WAL 규칙을 처음 들었을 때는 순서가 거꾸로인 듯 의아했는데, 그 한 줄이 어떻게 모든 장애를 복구 가능하게 만드는지 이해한 순간 데이터베이스의 신뢰성이 어디서 오는지가 손에 잡혔다.
트랜잭션과 장애 — 복구가 필요한 이유
데이터베이스 복구를 이해하려면 먼저 트랜잭션의 원자성(atomicity)과 지속성(durability)을 떠올려야 한다. 트랜잭션은 "모두 반영되거나 전혀 반영되지 않거나" 둘 중 하나여야 하고(원자성), 한 번 커밋된 결과는 어떤 장애에도 보존되어야 한다(지속성). 문제는 데이터베이스가 성능을 위해 변경 내용을 즉시 디스크에 쓰지 않고 메모리 버퍼에 모아 두었다가 나중에 한꺼번에 쓴다는 점이다. 이 때문에 메모리에만 있던 변경분이 디스크 반영 전에 장애로 날아갈 수 있다.
장애는 크게 세 가지다. 트랜잭션이 논리적 오류로 중단되는 트랜잭션 장애, 정전·OS 크래시로 메모리 내용이 전부 사라지는 시스템 장애, 그리고 디스크 자체가 물리적으로 손상되는 미디어 장애다. 트랜잭션·시스템 장애는 로그로 복구하고, 미디어 장애는 백업으로 복구한다. 복구의 목표는 두 가지로 요약된다. 커밋된 트랜잭션의 효과는 반드시 살리고(REDO), 커밋되지 않은 트랜잭션의 효과는 반드시 지운다(UNDO).
WAL — 로그를 데이터보다 먼저 쓴다
복구의 핵심 도구가 로그(log)다. 로그는 데이터의 모든 변경을 "어떤 트랜잭션이 어떤 데이터를 무엇에서 무엇으로 바꿨다"는 기록으로 남기는 순차 파일이다. 여기서 결정적인 규칙이 WAL(Write-Ahead Logging), 즉 로그 선행 기록이다. 그 핵심은 한 문장으로 요약된다: 데이터 페이지를 디스크에 쓰기 전에, 그 변경을 기술한 로그 레코드를 반드시 먼저 영구 저장소에 기록한다(출처: PostgreSQL 공식 문서 — WAL).
왜 이 순서가 모든 것을 해결할까. 만약 데이터를 먼저 쓰고 로그를 나중에 쓰는데 그 사이에 장애가 나면, 데이터는 바뀌었으나 그 사실을 기록한 로그가 없어 되돌릴 방법이 사라진다. 반대로 로그를 먼저 쓰면, 데이터 반영이 안 됐더라도 로그를 보고 다시 적용(REDO)할 수 있고, 커밋 안 된 변경이 데이터에 닿았더라도 로그의 이전 값으로 되돌릴(UNDO) 수 있다. 즉 로그만 안전하면 데이터는 언제든 로그로부터 재구성된다.
[WAL 규칙 — 정상 흐름과 장애 시나리오]
변경 발생 → ① 로그 레코드 디스크 기록 (먼저!)
→ ② 메모리 버퍼의 데이터 페이지 수정
→ ③ (나중에) 데이터 페이지 디스크 반영
★ 커밋 시점: 해당 트랜잭션의 로그가 디스크에 안착하면
데이터 페이지가 아직 메모리에만 있어도 커밋 인정
→ 디스크 쓰기 1회(로그)만으로 지속성 보장 → 빠름WAL이 성능에도 유리하다는 점이 흥미롭다. 흩어진 데이터 페이지를 매번 디스크에 무작위로 쓰는 대신, 로그는 파일 끝에 순차적으로만 추가하므로 디스크 쓰기가 훨씬 빠르다. 커밋 시 로그 한 줄만 확실히 디스크에 안착시키면 지속성이 보장되고, 실제 데이터 페이지 반영은 한가할 때 몰아서 한다. 이 덕분에 WAL은 안전성과 성능을 동시에 잡는다.
REDO와 UNDO — 복구의 두 동작
장애 후 데이터베이스가 재시작하면 로그를 읽어 복구를 수행한다. 이때 두 가지 동작이 핵심이다.
REDO(재실행)는 커밋은 되었지만 디스크 데이터 페이지에는 아직 반영되지 않았을 수 있는 변경을, 로그의 새 값(after-image)으로 다시 적용하는 것이다. 커밋된 트랜잭션의 효과를 보장하는 동작이다. UNDO(취소)는 장애 시점에 아직 커밋되지 않았던 트랜잭션의 변경을, 로그의 이전 값(before-image)으로 되돌리는 것이다. 미완성 트랜잭션의 흔적을 지우는 동작이다.
| 동작 | 대상 | 사용하는 로그 정보 | 목적 |
|---|---|---|---|
| REDO | 커밋된 트랜잭션 | 변경 후 값(after-image) | 지속성 보장 |
| UNDO | 미커밋 트랜잭션 | 변경 전 값(before-image) | 원자성 보장 |
복구 과정은 보통 세 단계로 진행된다. 먼저 로그를 분석해 어떤 트랜잭션이 커밋됐고 어떤 것이 미완인지 분류하고(분석), 마지막 체크포인트부터 로그를 따라가며 모든 변경을 다시 적용한 뒤(REDO), 미커밋 트랜잭션을 거꾸로 되돌린다(UNDO). 이 방식은 ARIES라는 표준 복구 알고리즘으로 정립되어 있으며, 상용 데이터베이스 대부분이 이 모델을 따른다.
체크포인트와 백업 — 복구를 현실적으로
WAL만 있으면 이론적으로는 데이터베이스 생성 시점부터의 모든 로그를 다시 적용해 복구할 수 있다. 하지만 그러면 복구에 며칠이 걸릴 수도 있다. 이를 해결하는 것이 체크포인트(checkpoint)다. 체크포인트는 특정 시점에 메모리의 모든 변경 데이터를 디스크에 강제로 반영하고 "이 지점까지는 디스크와 메모리가 일치한다"고 로그에 표시하는 것이다. 복구 시에는 이 체크포인트 이후의 로그만 보면 되므로 복구 범위가 극적으로 줄어든다.
미디어 장애, 즉 디스크 자체가 망가지는 경우는 로그만으로 부족하고 백업이 필요하다. 백업은 전체를 복사하는 전체 백업과 변경분만 복사하는 증분 백업으로 나뉜다. 특히 강력한 기법이 전체 백업과 그 이후의 WAL 로그(아카이브)를 함께 보관하는 시점 복구(PITR, Point-In-Time Recovery)다. 백업본을 복원한 뒤 원하는 시점까지만 로그를 재생하면, "어제 오후 3시 14분 상태"처럼 임의 시점으로 데이터베이스를 되돌릴 수 있다. 실수로 테이블을 지운 직전으로 복구하는 등 실무에서 결정적인 안전장치다.
흔한 오해 하나를 짚으면 "백업만 있으면 복구는 충분하다"는 통념인데, 백업은 마지막 백업 시점까지만 복구하므로 그 이후의 데이터는 잃는다. WAL 로그 아카이브가 함께 있어야 장애 직전까지 손실 없이 복구할 수 있다. 또 하나, "복구는 자동이니 신경 쓸 필요 없다"는 방심도 위험한데, 백업과 로그 아카이브가 실제로 복원 가능한지 주기적으로 복구 훈련을 하지 않으면 정작 장애 때 백업이 깨져 있는 경우가 흔하다. 시험에서는 WAL의 로그 선행 기록 규칙과 REDO·UNDO의 대상 구분이 단골 출제되고, 실무에서는 "백업 + WAL 아카이브 + 정기 복구 테스트"의 삼박자가 데이터 신뢰성의 토대가 된다. 솔직히 백업과 복구는 평소엔 존재감이 없다가 장애가 터진 단 한 번에 회사의 명운을 가르는, 가장 지루하지만 가장 중요한 데이터베이스 운영의 영역이다.
메타 디스크립션: 장애 상황에서도 데이터를 잃지 않는 데이터베이스 복구의 원리를, 로그를 데이터보다 먼저 쓰는 WAL 규칙과 커밋·미커밋 트랜잭션을 처리하는 REDO·UNDO, 복구 범위를 줄이는 체크포인트, 그리고 시점 복구(PITR)까지 데이터베이스 입문자 관점에서 세심하게 정리합니다.