지난 포스팅에서 RDBMS가 데이터의 안정성과 일관성을 중요하게 생각한다고 배웠습니다.
오늘은 그 중심에 있는 핵심 메커니즘, 바로
트랜잭션(Transaction)
과 그것이 지켜야 할 4가지 약속인
ACID 원칙
에 대해 알아보겠습니다.
트랜잭션은 단순히 여러 개의 SQL 쿼리를 묶는 것을 넘어, 데이터베이스의 '신뢰'를 보장하는 매우 중요한 개념입니다.
우리가 은행을 믿고 돈을 맡길 수 있는 이유와도 같습니다.
왜 트랜잭션이 필요하고, ACID라는 약속이 어떻게 우리의 데이터를 안전하게 지켜주는지 그 원리를 파헤쳐 보겠습니다.
를 의미합니다.
이 작업 단위는 하나 이상의 쿼리(데이터 추가, 수정, 삭제 등)로 구성될 수 있습니다.
트랜잭션의 가장 중요한 특징은 바로
모두 아니면 전무(All or Nothing)
라는 원칙입니다.
즉, 트랜잭션 안에 포함된 모든 작업이 전부 성공적으로 완료되어야만 그 결과를 데이터베이스에 최종적으로 반영(COMMIT)하고, 단 하나의 작업이라도 실패하면 모든 작업을 없었던 일로 되돌립니다(ROLLBACK).
가장 고전적이고 이해하기 쉬운 예는
계좌 이체
입니다.
A의 계좌에서 B의 계좌로 1만 원을 보내는 작업은 두 단계로 이루어집니다.
A의 계좌에서 1만 원을 차감한다.
B의 계좌에 1만 원을 추가한다.
만약 1번 작업만 성공하고, 시스템 오류로 2번 작업이 실패하면 어떻게 될까요?
A의 돈은 사라졌지만 B에게는 도착하지 않은, 돈이 공중분해되는 상황이 발생합니다.
트랜잭션은 이 두 작업을 하나의 덩어리로 묶어, 두 작업이 모두 성공해야만 결과를 저장하고, 하나라도 실패하면 1번 작업마저 취소하여 데이터의 모순을 막아줍니다.
는 원칙입니다.
마치 여러 사람이 동시에 같은 문서를 편집하더라도, 각자의 작업이 다른 사람에게 방해받지 않는 것과 같습니다.
만약 고립성이 보장되지 않는다면, A 사용자가 아직 완료하지 않은 변경사항을 B 사용자가 읽어 잘못된 결정을 내리는 등의 문제가 발생할 수 있습니다.
예를 들어, 항공사의 마지막 남은 한 좌석을 두 명의 사용자가 거의 동시에 예약하려고 할 때, 고립성은 이 두 요청을 순서대로 처리하는 것처럼 격리하여 오직 한 명만 예약에 성공하도록 보장해 줍니다.