📘 트랜잭션과 ACID

트랜잭션(Transaction)과 ACID

앞에서 RDB는 무슨 일이 있어도 데이터는 정상 상태를 유지한다고 하였다.

그걸 어떻게?

바로 그 핵심이 트랜잭션(Transaction)과 ACID 원칙이다.

---

트랜잭션(Transaction)이란?

트랜잭션 : 하나의 작업 단위를 의미하며, 전부 성공하거나 전부 실패해야 하는 연산

어려워 보이지만 쉽게 설명하면 “묶음처리”인 셈이다.

예를들어 A가 B에게 10만원을 계좌이체하였을 때 아래와 같은 단계로 이루어진다.

1. A 계좌에서 10만원 출금
2. B 계좌에 10만원 입금

하지만 A 계좌에서는 돈이 빠졌는데 B 계좌에는 돈이 안 들어갔다면?
돈이 사라진거다..이건 절대 일어나서는 안되는 상황이다

그래서 트랜잭션은 둘 다 성공하면 저장 / 하나라도 실패하면 전부 취소
이런식으로 동작한다.

즉 부분 성공이라는 개념 자체를 허용하지 않는다.

---

ACID 원칙이란?

트랜잭션에 대해 배울때 무조건 한번씩 듣게되는 개념이다.

ACID = Atomicity + Consistency + Isolation + Durability

트랜잭션이 제대로 동작하기 위해 지켜야 하는 규칙

ACID 각각 4가지 특성에서 첫글자를 따와서 ACID라고 하는데 하나씩 설명해보겠다.

1️⃣ Atomicity (원자성)

아까 계좌 이체에서 설명한 부분이다.
“전부 실행되거나 전부 실행되지 않거나”
모두 성공 시에는 커밋을, 하나라도 실패 시 롤백을

즉 트랜잭션은 작업이 쪼개지지않고 원자적이여야한다는 것이다.

2️⃣ Consistency (일관성)

트랜잭션 전후 데이터는 항상 올바른 상태를 유지해야 한다.

예를 들어 잔액이 음수가 되면 안 된다던가, 존재하지 않는 계좌에 송금하면 안 된다.

이건 DB가 제약조건으로 막는다.

balance >= 0 같은 규칙이 깨지면 아예 저장이 안 된다.

즉 이상한 데이터 자체를 못 넣게 한다.

3️⃣ Isolation (격리성)

동시에 실행돼도 서로 영향을 주지 않는다는 것이다.

예를 들어 A 계좌에 100만원이 있는데, 두 사람이 동시에 출금하면?

둘 다 100만원 보고 돈 빼버릴 수 있다

그러면? 데이터가 꼬인다.

그래서 DB는 SELECT … FOR UPDATE 같은 걸로 잠금을 건다.
내가 처리하는 동안 다른 트랜잭션 못 건드린다는 것이다.

즉 각 작업을 따로 격리해서 실행한다.

4️⃣ Durability (지속성)

한 번 저장되면 절대 사라지지 않는다.

COMMIT이 끝나면 서버 꺼져도, DB 터져도 데이터는 남아 있어야 한다.
그래서 DB는 로그를 남기고 디스크에 기록한다.

즉 저장됐으면 끝까지 책임진다.


그런데 여기서 한가지 문제가 있다.

고립성 부분에서 내가 처리하는 동안 다른 트랜잭션 못 건드린다면, 데이터 많아지면 엄청 느려지지 않을까??

ㅇㅇ 맞다.

격리성을 강하게 유지할수록 다른 트랜잭션이 기다려야 하는 시간이 길어지고 결국 성능이 떨어진다.

데이터는 안전하지만 성능이 느려지는 것이다.

그래서 DB는 격리 수준(Isolation Level)이라는 개념을 통해 성능과 안정성 사이에서 균형을 맞춘다.

---

트랜잭션의 격리 수준 (Isolation Level)

여러 트랜잭션이 동시에 처리될 때, 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 여부를 결정하는 것이다.

격리 수준 4단계 구조

사진을 보면 위에서부터 READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE 총 4가지가 존재한다.
위로 올라갈 수록 속도는 빨라지지만 데이터의 일관성을 보장하지 못하고, 아래로 내려올수록 트랜잭션을 순차적으로 처리하므로 속도는 느려지지만, 데이터의 일관성을 보장할 수 있다는데 자세히 알아보자.

1️⃣ READ UNCOMMITTED

가장 낮은 수준이다. 다른 트랜잭션이 아직 COMMIT도 안 한 데이터를 읽을 수 있다.

예를 들어 DB에는 10만원이 들어있는 계좌가 있다치자.

트랜잭션 A → 금액 +5만원 (아직 COMMIT 안 함) → DB 내부 상태: 15만원
이때 트랜잭션 B가 조회하면? → 15만원을 읽는다 (아직 확정되지 않은 값)

근데 A가 나중에 ROLLBACK 하면?? → 실제 DB는 다시 10만원으로 돌아간다.
B는 존재하지도 않은 데이터를 읽어버린거다.

이걸 Dirty Read라고 한다.
이문제를 해결하려면..커밋된 데이터만 읽을 수 있게 하면 되는거다.

2️⃣ READ COMMITTED

위에서 말한 커밋된 데이터만 읽을 수 있게 설정한 것이다.

이를 통해 Dirty Read를 해결할 수 있지만, 아직 문제는 남아있다.

예를 들어 DB 초기 상태: 10만원일때
트랜잭션 B → 처음 조회 → 10만원
그 사이에 트랜잭션 A → +5만원 후 COMMIT → DB 상태: 15만원
다시 트랜잭션 B가 조회하면? → 이번에는 15만원이 나온다

즉 같은 트랜잭션 안에서 같은 쿼리를 두 번 실행했는데 값이 바뀐다..

이걸 Non-Repeatable Read라고 하는데 이문제는 또 다음 고립 수준에서 해결가능하다.

3️⃣ REPEATABLE READ

한 트랜잭션 안에서는 같은 데이터를 항상 동일하게 읽도록 보장하는 격리 수준이다.

아까 문제였던 상황을 다시 보자

DB 초기 상태: 10만원
트랜잭션 B (처음 조회) → 10만원
그 사이에 트랜잭션 A → +5만원 후 COMMIT → DB 상태: 15만원
이 상태에서 트랜잭션 B가 다시 조회하면 -> 여전히 10만원이 나온다

즉 같은 트랜잭션 안에서는 값이 변하지 않는다.

하지만 아직 문제가 하나 남았다.

예를 들어 조건 조회를 한다고 해보자
트랜잭션 B → 잔액이 10만원 이상인 계좌 조회 → 처음 결과: 1개
그 사이에 트랜잭션 A → 새로운 계좌 추가 (잔액 20만원) 후 COMMIT
다시 트랜잭션 B가 같은 조건으로 조회하면 → 결과가 2개가 된다
없던 데이터가 갑자기 나타나는 것이다..

이걸 Phantom Read라고 한다.
Non-Repeatable-Read의 한 종류로, 새로운 데이터가 생기거나, 기존의 데이터가 사라지는 문제를 말한다.

근데 이해가 안되는 부분이 생긴다.. 같은 트랜잭션이 아니니까(COMMIT 후니까) 결과가 바뀌어도 되는거 아닌가?

ㅇㅇ 맞는 말이다. 실제로 다른 트랜잭션이기 때문에 바뀌는 게 자연스럽다.

그럼 왜 이걸 문제로 보는 걸까?

핵심은 “데이터가 바뀌었냐”가 아니라 “같은 트랜잭션 안에서 조회 결과가 달라졌냐”다..

트랜잭션은 단순한 쿼리 하나가 아니라 하나의 작업 단위다.
즉 트랜잭션 B 입장에서는 첫 번째 조회 결과: 1개, 두 번째 조회 결과: 2개 → 같은 작업을 수행했는데 결과가 바뀌어버린 것이다..

즉 REPEATABLE READ는 “이미 읽은 데이터”는 보호하지만, “조건에 의해 조회되는 전체 범위”까지는 보호하지 않는다.

다른 트랜잭션을 읽는 건 정상이다. 하지만 그게 내 작업 결과를 바꾸니까 문제인 것이다.

4️⃣ SERIALIZABLE

가장 높은 수준이다. 트랜잭션을 마치 하나씩 순서대로 실행하는 것처럼 처리한다.

위와 같은 상황일때, 트랜잭션 B가 조회를 시작하면 그 동안 다른 트랜잭션(A)은 데이터를 변경하거나 추가할 수 없다. SELECT 조건 자체에 잠금을 걸어, 새로운 데이터가 끼어들 수 없게 만드는 것이다.

그래서 Phantom Read까지 모두 방지된다.
데이터가 꼬일 일이 아예 없다는 거다.
하지만 그만큼 성능이 매우 느리다..

최종적으로 정리를 하자면

• READ UNCOMMITTED → Dirty Read 발생
• READ COMMITTED → Dirty Read 해결 (하지만 값 바뀜)
• REPEATABLE READ → 값 유지 (하지만 새로운 데이터 생김)
• SERIALIZABLE → 완벽하지만 느림

---

실무에서 사용

그래서 실무에서는 어떻게 쓸까??

대부분 기본은 READ COMMITTED 또는 REPEATABLE READ이다.
성능 괜찮고 대부분 문제 없이 동작하니까.
하지만 정말 중요한 경우(금융, 결제 등)에는 SERIALIZABLE 사용한다.

격리성은 무조건 높다고 좋은 게 아니라 서비스 상황에 맞게 선택하는 것이 핵심이다.