복구 과정의 읽는 순서 장애 직후에는 둘 다 먼저 Redo를 거치고, 마지막에 커밋 여부로 결과가 갈립니다.

복구 엔진은 처음부터 "살릴 것 / 버릴 것"을 나누지 않습니다. 로그 기준 상태를 먼저 되살린 뒤, 미완료 트랜잭션만 Undo로 걷어냅니다.

장애 발생 메모리 상태는 사라짐 디스크에 무엇이 반영됐는지는 불확실합니다.
1단계 Redo로 로그를 다시 적용 커밋 여부를 가리지 않고 기록된 변경을 먼저 맞춥니다.
2단계 Undo로 미커밋만 제거 복원된 상태 위에서 미완료 흔적만 되돌립니다.
복구 완료 커밋된 값만 남음 지속성과 원자성이 함께 맞춰집니다.
같은 Redo를 거친 뒤, Undo 대상 여부만 달라집니다.

아래 표는 같은 복구 순서 안에서 T1과 T2가 어떻게 다른 최종 상태를 갖는지 보여줍니다.

공통 규칙: Redo 먼저
트랜잭션 장애 전 변경 Redo 직후 Undo 판단 최종 상태
T1

A 값을 바꾼 작업

COMMIT 완료
A: 100 → 200

변경이 이미 확정된 상태입니다.
A = 200

로그의 after image를 다시 적용합니다.
Undo 대상 아님

커밋이 끝났으므로 되돌리지 않습니다.
A = 200 유지

커밋된 변경은 살아남습니다.
T2

B 값을 바꾼 작업

미커밋
B: 50 → 80

변경은 있었지만 아직 확정되지 않았습니다.
B = 80

Redo 단계에서는 일단 같은 방식으로 재적용합니다.
B = 50

커밋되지 않았으므로 before image로 되돌립니다.
B = 50 복귀

미완료 변경은 최종 상태에 남지 않습니다.
핵심

Redo는 "로그 기준 상태를 먼저 되살리는 단계"이고, Undo는 "그 상태에서 미커밋만 제거하는 단계"입니다. 그래서 복구의 결과는 커밋된 A=200은 남고, 미커밋 B=80은 50으로 돌아갑니다.