1. 트랜잭션
트랜잭션에서 자주 나오는 예시
친구에게 5만 원을 계좌 이체하는 아주 익숙한 상황을 떠올려보자.
내 계좌에서 5만 원이 출금된 바로 그 순간 만약 은행 서버에 장애가 발생한다면 어떻게 될까?
내 돈은 사라졌지만 친구의 계좌에는 돈이 들어오지 않는 최악의 시나리오가 펼쳐지는가??
다행히 현실에서는 이런 일이 거의 발생하지 않는다. 트랜잭션이라는 메커니즘이 우리의 소중한 데이터를 안전하게 지켜주기 때문이다.
1-1. 트랜잭션 개요
트랜잭션(Transaction)이란 데이터베이스의 상태를 변화시키는 하나의 논리적인 작업 단위이다.
'계좌 이체'와 같은 하나의 논리적인 작업을 위해 '계좌 출금', '계좌 입금'이라는 여러 개의 SQL문이 필요할 수 있다.
이처럼 서로 밀접하게 관련된 SQL문들의 묶음을 분리할 수 없는 하나의 단위로 다루는 것이 바로 트랜잭션이다.
따라서 트랜잭션 내의 작업들은 일부만 성공하여 데이터베이스에 반영될 수 없다. 모든 작업이 성공하거나, 아니면 모든 작업이 실패하여 아무 일도 없던 것처럼 되돌려져야 한다.
1-2. 트랜잭션 핵심 명령어
데이터베이스는 '모든 작업의 성공' 또는 '아무 일도 없던 상태'를 COMMIT과 ROLLBACK이라는 명령어를 통해 제어한다.
COMMIT (커밋): 트랜잭션 내의 모든 작업이 성공적으로 완료되었음을 데이터베이스에 알리는 명령어이다. COMMIT이 실행되는 순간, 변경 사항은 영구적으로 저장된다. (이 작업이 성공적으로 끝났으니 저장 하라는 의미)
ROLLBACK (롤백): 트랜잭션 내의 작업 중 하나라도 실패했거나, 개발자가 의도적으로 작업을 취소하고 싶을 때 사용하는 명령이다. ROLLBACK이 실행되면 트랜잭션이 시작되기 이전 상태로 모든 것을 되돌린다. (이 작업을 없었던걸로 하자는 의미)
간단한 SQL 예시
START TRANSACTION;
-- 1. 내 계좌(ID: 101)에서 50000원 감소
UPDATE accounts SET balance = balance - 50000 WHERE user_id = 101;
-- 2. 친구 계좌(ID: 202)에 50000원 증가
UPDATE accounts SET balance = balance + 50000 WHERE user_id = 202;
COMMIT;
만약 위 두 쿼리가 실행되는 도중에 오류가 발생한다면, COMMIT 대신 ROLLBACK을 실행하여 모든 변경 사항을 되돌릴 수 있다.
2. ACID
ACID는 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)의 앞 글자를 딴 용어로 데이터베이스의 신뢰도를 결정하는 핵심적인 성질이다.
하나씩 알아보겠다.
2-1 원자성(Atomicity)
ALL or NOTHING
원자성(Atomicity)은 트랜잭션에 포함된 모든 작업이 전부 성공하거나, 아니면 전부 실패하여 아무 일도 없었던 것처럼 되돌려지는 것을 보장하는 성질이다.
'원자(Atom)'가 더 이상 쪼갤 수 없는 가장 작은 입자인 것처럼 트랜잭션도 더 이상 나눌 수 없는 하나의 단위로 취급된다.
- '원자(Atom)'는 현대 과학에서 더 작은 입자로 쪼개질 수 있다는 것이 밝혀졌다. 하지만 데이터베이스 이론이 정립될 당시의 상징적인 의미로, 여전히 Atomicity라는 용어를 사용함.
계좌 이체 예시:
1. '내 계좌에서 출금'과 '친구 계좌로 입금' 두 작업 중 하나만 성공하는 경우는 절대 일어나면 안된다.
2. 출금은 성공했지만 입금이 실패하면
3. 시스템은 출금 작업까지 모두 ROLLBACK하여 계좌 이체 시도 자체가 없었던 일로 만듬 (NOTHING).
COMMIT 실행 시 DB에 영구적으로 저장하는 것은 DBMS가 담당하는 부분이다.
ROLL BACK 실행 시 이전 상태로 되돌리는 것도 DBMS가 담당하는 부분이다.
개발자는 언제 COMMIT 하거나 ROLLBACK 할지를 챙겨야 한다.
예) T1 과 T2 로 구성된 트랜잭션 T: 계좌 X 에서 계좌 Y 로 100달러를 이체하는 상황
트랜잭션 T는 X에서 100을 빼고(T1), Y에 100을 더하는(T2) 작업을 하나의 묶음으로 처리한다. 이 두 작업이 모두 성공해야만 트랜잭션이 완료되어 원자성을 지킨다.
2-2 일관성(Consistency)
일관성(Consistency)은 트랜잭션이 성공적으로 완료된 후에도 데이터베이스가 항상 정의된 규칙과 제약 조건을 지키며 유효한 상태를 유지하는 것을 보장하는 성질이다.
계좌 이체 예시:
1. 모든 계좌의 잔액은 0원 이상이어야 한다 (잔액 >= 0)는 제약 조건(규칙)이 걸려 있다고 가정. 내 계좌에는 현재 3만 원이 있다면?
2. 내가 친구에게 5만 원을 계좌 이체하려 한다.. (내 잔액: 3만 원)
3. 잔액이 3만 원인 계좌에서 5만 원을 인출하려는 트랜잭션은 '잔액은 0원 이상이어야 한다'는 데이터베이스의 규칙을 위반하므로 시스템에 의해 실행이 거부되어 데이터의 일관성을 유지한다.
쉽게 말해, 트랜잭션은 데이터베이스를 '규칙이 지켜지는 상태'에서 또 다른 '규칙이 지켜지는 상태'로만 옮겨갈 수 있어야 한다.
예) 은행 시스템의 모든 잔액 합계가 항상 일정해야 한다고 가정한다.
트랜잭션 전 총 잔액은 700달러이다. 거래 후 총 잔액은 700달러로 유지되어야 한다.
만약 거래가 중간에 실패하여 한 계좌만 업데이트 된다면 데이터의 일관성이 깨지게 된다 이 경우 원자성에 의해 트랜잭션 전체가 롤백되어 데이터의 일관성을 보존한다.
T 발생 전 총계 = 500 + 200 = 700.
T 발생 후 총계 = 400 + 300 = 700.
총 잔액 700 달러로 일관성을 지킴
2-3 고립성(Isolation)
여러 트랜잭션들이 동시에 실행될 때도 혼자 실행되는 것 처럼 동작하게 만든다.
쉽게 말해, 하나의 트랜잭션이 완료(COMMIT)되기 전까지 그 트랜잭션이 수정한 중간 결과물은 다른 트랜잭션에게 보이지 않도록 격리시키는 것이다.
DBMS는 여러 종류의 Isolation level을 제공한다.
개발자는 Isolation level 중에 어떤 level로 트랜잭션을 동작시킬지 설정할 수 있다.
계좌 이체 예시:
1. 내 계좌에 10만 원이 있고 나는 친구에게 5만 원을 이체하는 중이고. 이 트랜잭션은 아직 완료(COMMIT)되지 않았다고 가정한다.
2. 이때, 다른 사람 이 내 계좌의 현재 잔액을 동시에 조회하려고 시도 한다면?.
3. 고립성 원칙에 따라 아직 완료되지 않은 내 이체 작업(중간 결과)은 다른 조회 트랜잭션으로부터 격리된다. 따라서 조회 프로그램은 내가 이체하기 전의 금액인 10만 원을 결과로 받게 되어 데이터의 혼란을 막아준다.
예) 트랜잭션 T(값 변경)와 T''(합계 계산)가 고립성 없이 동시에 실행된다고 가정해 본다.
T''는 T가 실행되기 전의 값(X=500, Y=500)으로 계산하거나, T가 완전히 끝난 후의 값(X=50000, Y=450)으로 계산해야 논리적으로 올바르다. 즉, Z의 값은 1000 또는 50450이 되어야 고립성이 유지된 것.
고립성이 깨지는 경우
하지만 고립성이 깨지면, T''가 X의 값(500)을 읽은 직후 T가 끼어들어 X와 Y값을 변경하고 완료할 수도 있다.
그 후에 T''는 이미 변경된 Y의 값(450)을 읽게 된다.
T''가 읽은 X = 500 (T가 실행되기 전의 값)
T''가 읽은 Y = 450 (T가 실행된 후의 값)
최종 계산: Z = 500 + 450 = 950
결과적으로 Z에는 950이라는, 논리적으로 맞지 않는 잘못된 값이 저장된다.
2-4 지속성(Durability)
지속성(Durability)은 성공적으로 COMMIT된 트랜잭션의 결과는 그 이후에 시스템에 장애가 발생하더라도 데이터베이스에 영구적으로 보존되는 것을 보장하는 성질이다.
여기서 '영구적으로 저장한다'는 것은 RAM과 같은 휘발성 메모리가 아닌, 하드 디스크나 SSD 같은 비휘발성 메모리에 안전하게 기록됨을 의미한다.
따라서 계좌 이체를 성공하고 '이체 완료' 메시지를 확인했다면, 그 직후 데이터베이스 서버가 정전으로 다운되더라도 걱정할 필요가 없을 것이다.. 시스템이 복구되었을 때 우리의 COMMIT된 데이터는 손실 없이 그대로 남아있게 된다.
지속성은 기본적으로 DBMS가 변경 기록(Log) 및 복구 메커니즘을 통해 보장해주는 매우 중요한 기능이다.
계좌 이체 예시
1. 내가 친구에게 5만 원을 성공적으로 이체하고, 이 트랜잭션이 COMMIT까지 완료되었다고 가정하자.
2. 바로 그 순간, 데이터베이스 서버에 정전이 발생하여 시스템이 예기치 않게 종료되거나 은행 업무 시스템이 다운 됬다.
3.지속성 원칙에 따라, 서버가 재부팅된 후에도 나의 COMMIT된 이체 내역은 데이터 손실 없이 안전하게 복구가 된다. 이처럼 한 번 확정된 결과는 어떤 장애에도 영원히 보존되는 것.
3. 마치며
이번주 Weekly Study Meetup 끝..
오늘 학습한 지식도 마찬가지 적용해야한다. 한번 머리에 넣었다고 끝이 아니라, 꾸준한 복습을 통해 COMMIT을 반복해야 비로소 내 것이 된다.
우리의 뇌는 지속성(Durability)이 약한 데이터베이스다. 꾸준히 복습해서 COMMIT을 해야 학습한 지식이 ROLLBACK 되는 것을 막을 수 있다.
참고 사이트
'데이터베이스' 카테고리의 다른 글
| DB 동시성 제어 recoverability 기본정리 (1) | 2025.07.20 |
|---|---|
| DB 동시성 제어 Schedule, Serializability 기본 정리 (0) | 2025.07.19 |
| DB JOIN 개념 간단하게 정리 (1) | 2025.06.22 |