트랜잭션과 ACID 특성편집자 확인

트랜잭션은 데이터베이스 시스템에서 논리적인 작업 단위를 구성하는 하나 이상의 데이터베이스 연산의 집합이다. 이 연산들은 모두 함께 성공하거나 모두 함께 실패해야 하는 '전부 아니면 전무(All or Nothing)'의 특성을 가진다. 예를 들어, 은행 계좌 이체 작업은 출금 연산과 입금 연산으로 구성되며, 이 두 연산은 하나의 트랜잭션으로 묶여서 처리된다.

트랜잭션의 주요 목적은 데이터의 무결성과 신뢰성을 보장하는 것이다. 여러 사용자가 동시에 데이터에 접근하고 변경하는 다중 사용자 환경에서, 트랜잭션은 시스템 장애나 동시 접근으로 인해 데이터가 불일치한 상태에 빠지는 것을 방지한다. 따라서 트랜잭션은 데이터베이스가 항상 정확하고 신뢰할 수 있는 상태를 유지하도록 하는 핵심 메커니즘이다.

트랜잭션은 일반적으로 특정한 시작과 끝을 가진다. 시작은 명시적(예: BEGIN TRANSACTION)이거나 암시적(예: 첫 번째 SQL 문 실행)일 수 있다. 트랜잭션의 종료는 성공적인 완료를 의미하는 COMMIT 또는 실패 및 취소를 의미하는 ROLLBACK 연산에 의해 결정된다. COMMIT이 실행되면 트랜잭션 내에서 수행된 모든 변경 사항이 영구적으로 데이터베이스에 반영된다. 반면, ROLLBACK이 실행되면 트랜잭션 시작 이후의 모든 변경 사항이 취소되고 데이터베이스는 트랜잭션 시작 전의 상태로 되돌아간다.

이 개념은 데이터베이스 관리 시스템뿐만 아니라 메시지 큐, 분산 시스템 등 다양한 컴퓨팅 분야에서도 유사하게 적용된다. 핵심은 여러 개의 개별 단계를 하나의 논리적 단위로 묶어, 그 단위 전체에 대해 성공 또는 실패를 보장함으로써 시스템의 상태를 예측 가능하고 안정적으로 만드는 데 있다.

트랜잭션은 데이터베이스 시스템에서 논리적인 작업 단위를 구성하는 기본 모듈이다. 여러 개의 데이터 조작 언어(DML) 연산, 예를 들어 INSERT, UPDATE, DELETE 문장들을 하나의 논리적 단위로 묶어서 실행의 최소 단위로 삼는다.

이러한 묶음의 핵심 역할은 데이터의 무결성과 신뢰성을 보장하는 것이다. 사용자가 송금, 주문, 재고 관리와 같은 복잡한 업무를 수행할 때, 그 과정은 여러 단계의 데이터 변경을 수반한다. 트랜잭션은 이러한 변경 작업들을 '전부 실행되거나 전혀 실행되지 않거나'의 원칙 아래 관리함으로써, 시스템 장애나 오류 발생 시 데이터가 불완전하거나 모순된 상태에 빠지는 것을 방지한다.

데이터베이스에서 트랜잭션의 역할은 크게 두 가지 측면에서 설명할 수 있다. 첫째는 복구의 단위로서의 역할이다. 시스템이 비정상적으로 종료되었을 때, 데이터베이스 관리 시스템(DBMS)은 커밋된 트랜잭션의 결과는 영구 저장하고, 커밋되지 않은 트랜잭션의 변경 사항은 모두 취소하여 데이터를 일관된 상태로 복구한다. 둘째는 동시성 제어의 단위로서의 역할이다. 다수의 사용자가 동시에 데이터베이스에 접근할 때, 각 트랜잭션을 적절히 격리시켜 서로의 작업이 간섭하지 않도록 관리함으로써 동시 실행의 효율성을 높이면서도 데이터의 정확성을 유지한다.

원자성은 트랜잭션이 전부 실행되거나 전혀 실행되지 않아야 함을 보장하는 특성이다. 이는 트랜잭션을 구성하는 여러 작업이 하나의 논리적 단위로 취급되어야 한다는 것을 의미한다. 데이터베이스 시스템은 원자성을 보장하기 위해 롤백 및 커밋 메커니즘을 구현한다.

트랜잭션 실행 중에 오류가 발생하면, 시스템은 트랜잭션이 시작되기 전의 상태로 모든 변경 사항을 되돌린다. 이 과정을 롤백이라고 한다. 반대로 모든 작업이 성공적으로 완료되면, 그 변경 사항은 영구적으로 데이터베이스에 적용되는데, 이를 커밋이라고 한다. 따라서 사용자에게는 트랜잭션이 완전히 성공하거나, 아예 발생하지 않은 것처럼 보이는 두 가지 결과만 존재한다.

원자성의 전형적인 예는 은행 계좌 이체 작업이다. A 계좌에서 B 계좌로 돈을 송금하는 트랜잭션은 A 계좌의 출금과 B 계좌의 입금이라는 두 작업으로 구성된다. 원자성이 보장되지 않는다면, A 계좌에서만 돈이 빠져나가고 B 계좌에는 입금되지 않는 중간 상태가 발생할 수 있다. 원자성은 이러한 부분적 완료를 방지하여, 두 작업이 모두 성공하거나 모두 실패하도록 한다.

이 특성은 주로 트랜잭션 관리자나 복구 관리자 같은 데이터베이스 시스템의 구성 요소에 의해 구현된다. 시스템은 트랜잭션의 진행 상황을 로그 파일에 기록하여, 장애 발생 시 완료되지 않은 트랜잭션을 식별하고 롤백하는 데 사용한다.

일관성은 트랜잭션이 데이터베이스의 사전에 정의된 규칙, 즉 무결성 제약조건을 위반하지 않고 상태를 한 일관된 상태에서 다른 일관된 상태로 변화시켜야 함을 보장하는 특성이다. 이 규칙에는 기본키, 외래키, 도메인 제약, 고유 제약, 체크 제약 등이 포함된다. 트랜잭션 실행 전후로 데이터베이스는 이러한 모든 제약 조건을 만족해야 하며, 그렇지 않을 경우 트랜잭션은 중단되고 데이터베이스는 이전 상태로 되돌아간다.

이 특성은 다른 ACID 특성들과 달리 애플리케이션 로직과 밀접한 관계를 가진다. 데이터베이스 시스템은 정의된 제약 조건의 위반을 감지하고 방지할 수 있지만, 비즈니스 규칙과 같은 더 높은 수준의 논리적 일관성은 주로 애플리케이션 코드를 통해 보장되어야 한다. 예를 들어, 은행 계좌 이체 트랜잭션에서 '출금 계좌의 잔액 >= 이체 금액'이라는 비즈니스 규칙은 데이터베이스가 자동으로 검사하지 않으므로, 애플리케이션 로직이 이를 확인하고 위반 시 트랜잭션을 롤백해야 일관성을 유지할 수 있다.

일관성 유지를 위한 주요 메커니즘은 다음과 같다.

따라서 일관성은 데이터베이스 시스템과 애플리케이션이 공동으로 책임지는 특성으로, 시스템이 제공하는 기본 제약 조건과 개발자가 구현하는 비즈니스 로직이 결합되어 완전한 데이터 정확성을 보장한다.

고립성은 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션이 다른 트랜잭션의 중간 상태나 미완료 작업으로부터 격리되어 마치 순차적으로 실행되는 것처럼 동작하도록 보장하는 특성이다. 이는 동시 실행으로 인해 발생할 수 있는 데이터의 비일관성을 방지하는 핵심 메커니즘이다. 고립성이 없다면, 한 트랜잭션이 다른 트랜잭션에 의해 아직 커밋되지 않은 데이터를 읽거나, 동일한 데이터에 대한 동시 수정으로 인해 예측 불가능한 결과가 발생할 수 있다.

고립성 위반으로 인해 발생하는 주요 문제점들은 다음과 같다.

이러한 문제들을 완전히 방지하면 동시성 성능이 크게 저하될 수 있으므로, 대부분의 데이터베이스 관리 시스템은 다양한 고립성 수준을 제공한다. 사용자는 애플리케이션의 요구사항에 따라 성능과 데이터 정확성 사이의 균형을 맞추기 위해 적절한 수준을 선택할 수 있다. 일반적인 고립성 수준은 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE 등이 있으며, SERIALIZABLE 수준이 가장 강력한 격리를 제공하지만 동시성은 가장 낮아진다.

지속성은 트랜잭션이 성공적으로 완료(COMMIT)된 후에는 그 결과가 시스템 장애가 발생하더라도 영구적으로 보존되어야 함을 보장하는 특성이다. 이는 데이터의 영구성을 의미하며, 한 번 저장된 데이터는 손실되지 않는다는 신뢰성을 제공하는 핵심 요소이다. 데이터베이스 시스템은 일반적으로 트랜잭션 로그나 리두 로그와 같은 복구 메커니즘을 통해 지속성을 구현한다.

구현 방식은 주로 WAL 기법을 따른다. 트랜잭션의 모든 변경 사항은 실제 데이터 파일에 쓰이기 전에 먼저 안정적인 저장 장치(예: 디스크)의 로그 파일에 기록된다. COMMIT 연산이 수행되면, 로그 기록이 먼저 디스크에 강제로 기록되고, 그 후에 사용자에게 성공을 알린다. 이렇게 하면 시스템이 COMMIT 직후에 정전이나 장애가 발생하더라도, 재시작 시 로그를 기반으로 완료된 트랜잭션의 변경 사항을 데이터 파일에 재적용하여 복구할 수 있다.

지속성의 보장 수준은 시스템 설정과 하드웨어 성능에 따라 달라질 수 있다. 예를 들어, 로그를 매번 디스크에 동기화하는 설정은 가장 강력한 지속성을 보장하지만 성능 저하를 초래할 수 있다. 반면, 성능을 위해 일정 주기로 로그를 모아서 기록하는 경우, 그 사이에 발생한 장애로 인해 최근 COMMIT된 트랜잭션 일부가 손실될 위험이 있다[1]. 따라서 애플리케이션의 요구사항에 따라 적절한 내구성과 성능의 균형을 맞추는 것이 중요하다.

트랜잭션은 시작부터 종료까지 여러 상태를 거치며 전이한다. 이러한 상태 전이는 트랜잭션 관리자에 의해 제어되며, 일반적인 상태는 다음과 같다.

트랜잭션은 일반적으로 활동 상태에서 시작한다. 모든 연산을 성공적으로 수행하면 부분 완료 상태가 된다. 이후 시스템은 디스크에 대한 실제 기록 작업을 수행하고, 이 작업이 성공하면 완료 상태로 전이하여 트랜잭션을 종료한다. 만약 실행 중 오류가 발생하면 실패 상태가 되며, 이후 철회 상태로 전이한다. 철회 상태에서는 트랜잭션이 수행한 모든 변경 사항을 취소(ROLLBACK)하고, 데이터베이스를 트랜잭션 시작 전의 일관된 상태로 복원한다.

COMMIT은 트랜잭션의 모든 연산이 성공적으로 완료되었음을 선언하고, 그 결과를 영구적으로 데이터베이스에 반영하는 명령어이다. 이 명령이 실행되면, 트랜잭션이 수행한 모든 데이터 변경 사항(삽입, 갱신, 삭제)이 물리적 저장 장치에 기록되어 지속성을 보장받는다. COMMIT 이후에는 해당 트랜잭션의 변경 내용을 취소할 수 없다. 일반적으로 COMMIT은 사용자가 명시적으로 실행하거나, 애플리케이션 설정에 따라 자동으로 수행될 수 있다[2]] 프레임워크는 기본적으로 자동 커밋 모드를 사용함].

반면, ROLLBACK은 트랜잭션 수행 중 오류가 발생했거나 사용자가 의도적으로 변경 사항을 취소하려 할 때 사용하는 명령어이다. ROLLBACK이 실행되면, 트랜잭션이 시작된 이후부터 COMMIT되기 전까지 데이터베이스에 가해진 모든 변경을 원래 상태로 되돌린다. 이는 트랜잭션의 원자성을 실현하는 핵심 메커니즘이다. 시스템 장애나 논리적 오류로 인해 트랜잭션을 완료할 수 없을 때, 데이터베이스 관리 시스템은 자동으로 ROLLBACK을 수행하여 데이터의 일관성을 유지한다.

COMMIT과 ROLLBACK의 작동은 내부적으로 트랜잭션 로그나 언두 로그와 같은 복구 메커니즘에 의존한다. 변경 사항은 먼저 로그 파일에 안전하게 기록된 후, 실제 데이터 파일에 적용된다. 이 로그는 ROLLBACK 실행 시 변경 전 상태로 복구하는 데 사용되며, 시스템 장애 후에도 COMMIT된 트랜잭션은 로그를 통해 재실행하여 지속성을 보장한다.

락킹은 데이터베이스 관리 시스템이 트랜잭션의 고립성을 보장하고 동시성 제어를 수행하기 위한 핵심 메커니즘이다. 여러 트랜잭션이 동시에 같은 데이터 항목에 접근하려 할 때, 락을 통해 접근 순서를 제어함으로써 데이터의 일관성을 유지한다. 기본적으로 트랜잭션이 데이터를 읽거나 변경하기 전에 해당 데이터에 대한 락을 요청하고 획득해야 한다. 락이 이미 다른 트랜잭션에 의해 점유된 경우, 요청한 트랜잭션은 락이 해제될 때까지 대기해야 한다.

락은 주로 두 가지 기본 모드로 구분된다. 공유락은 데이터를 읽기만 할 때 사용하며, 여러 트랜잭션이 동시에 같은 데이터 항목에 대한 공유락을 보유하는 것이 허용된다. 배타락은 데이터를 쓰거나 수정할 때 필요하며, 한 트랜잭션이 배타락을 보유하면 다른 트랜잭션은 그 데이터에 대한 공유락이나 배타락을 획득할 수 없다. 이 규칙은 "더티 리드"나 "갱신 분실" 같은 문제를 방지한다.

락킹 프로토콜은 락을 획득하고 해제하는 시점에 대한 규칙을 정의한다. 대표적인 2단계 락킹 프로토콜은 트랜잭션이 락을 해제하기 시작하면 새로운 락을 더 이상 획득할 수 없는 단계로 진입함을 규정한다. 이는 트랜잭션의 직렬 가능성을 보장하는 데 중요한 역할을 한다. 그러나 락킹은 교착상태를 유발할 수 있는 위험이 있다. 두 개 이상의 트랜잭션이 서로가 점유한 락을 무한정 기다리는 상황이 발생할 수 있으며, 데이터베이스 시스템은 교착상태 탐지 알고리즘이나 타임아웃 메커니즘을 통해 이를 해결한다.

고립성 수준은 여러 트랜잭션이 동시에 실행될 때, 한 트랜잭션이 다른 트랜잭션에 의해 변경 중인 데이터를 얼마나 "보게" 되는지를 정의하는 기준이다. 데이터베이스 시스템은 다양한 고립성 수준을 제공하여 개발자가 성능과 데이터 정확성 사이에서 적절한 균형을 선택할 수 있도록 한다. 각 수준은 특정한 동시성 문제를 방지하거나 허용함으로써 차이를 보인다.

주요 고립성 수준은 보통 네 가지로 구분된다. 가장 낮은 수준부터 높은 수준 순으로 나열하면 다음과 같다.

READ UNCOMMITTED는 가장 낮은 고립성 수준이다. 한 트랜잭션이 다른 트랜잭션이 아직 커밋하지 않은, 즉 중간 상태의 데이터(더티 리드)를 읽을 수 있다. 이는 데이터 불일치를 초래할 위험이 크지만, 락을 사용하지 않거나 최소화하므로 성능상의 이점이 있을 수 있다. READ COMMITTED는 대부분의 데이터베이스 시스템의 기본 설정이다. 이 수준에서는 커밋된 데이터만 읽을 수 있어 더티 리드는 방지되지만, 같은 트랜잭션 내에서 동일한 쿼리를 두 번 실행할 때 다른 트랜잭션의 커밋으로 인해 결과가 달라지는 반복 불가능 읽기가 발생할 수 있다.

REPEATABLE READ 수준에서는 한 트랜잭션이 읽은 데이터에 대해서는 다른 트랜잭션이 수정하거나 삭제하는 것을 방지하여 반복 불가능 읽기를 해결한다. 그러나 새로운 데이터 행이 추가되는 것은 막지 못하므로, 범위 쿼리를 다시 실행했을 때 새로 나타나는 행인 팬텀 리드 현상이 발생할 수 있다. 가장 높은 수준인 SERIALIZABLE은 트랜잭션들을 순차적으로 실행한 것과 동일한 결과를 보장한다. 이는 모든 동시성 문제를 방지하지만, 엄격한 락킹이나 다른 메커니즘으로 인해 처리량이 현저히 저하되고 데드락 발생 가능성이 높아진다.

적절한 고립성 수준의 선택은 애플리케이션의 요구사항에 달려 있다. 금융 거래와 같이 데이터 정확성이 최우선인 경우에는 SERIALIZABLE 수준이 필요할 수 있지만, 대부분의 온라인 트랜잭션 처리 시스템에서는 성능을 위해 READ COMMITTED나 REPEATABLE READ 수준을 사용한다. 데이터베이스별로 이러한 수준의 구현 방식(예: MVCC 사용 여부)과 세부 동작에는 차이가 있다[3].

2단계 커밋은 분산 데이터베이스 시스템이나 마이크로서비스 아키텍처에서 여러 개의 독립적인 리소스 관리자(예: 서로 다른 데이터베이스 서버)에 걸친 하나의 트랜잭션을 원자적으로 완료하거나 중단하기 위한 분산 트랜잭션 처리 프로토콜이다. 이 프로토콜은 하나의 조정자와 여러 개의 참여자로 구성되어 작동하며, 모든 참여자가 트랜잭션을 커밋할 준비가 되었는지 확인한 후에만 실제 커밋을 수행하여 원자성을 보장한다.

프로토콜은 두 단계로 진행된다. 첫 번째 단계는 준비 단계로, 조정자가 모든 참여자에게 트랜잭션 커밋 준비 요청을 보낸다. 각 참여자는 자신의 로컬 트랜잭션을 실행하고, 모든 변경 사항을 영구 저장소에 기록할 수 있는 상태가 되면 준비 완료 표시를, 그렇지 않으면 실패 표시를 조정자에게 회신한다. 두 번째 단계는 커밋 단계로, 조정자가 모든 참여자로부터 준비 완료 응답을 받으면 최종 커밋 명령을 전송한다. 만약 하나라도 실패 응답을 받거나 타임아웃이 발생하면 조정자는 모든 참여자에게 롤백 명령을 보낸다.

이 방식은 모든 노드가 일관된 결정에 도달하도록 강제하지만, 단점도 존재한다. 가장 큰 문제는 블로킹 현상으로, 조정자가 두 번째 단계에서 명령을 보내기 전에 고장 나면 참여자들은 불확정 상태에 빠져 무기한 대기할 수 있다[4]. 또한, 네트워크 통신이 많아 성능 오버헤드가 크고, 구현이 복잡하다는 한계가 있다. 그럼에도 불구하고, 전통적인 엔터프라이즈 애플리케이션 통합이나 XA 트랜잭션 표준을 지원하는 시스템에서 분산 트랜잭션의 원자성을 보장하는 핵심 메커니즘으로 널리 사용되었다.

관계형 데이터베이스 관리 시스템은 ACID 특성을 보장하기 위해 각기 다른 방식으로 트랜잭션을 구현한다. 오라클 데이터베이스는 멀티버전 동시성 제어 기법을 사용하여 읽기 작업이 쓰기 작업을 차단하지 않도록 하며, 롤백 세그먼트 또는 언두 테이블스페이스를 활용해 원자성과 일관성을 제공한다.

MySQL의 InnoDB 스토리지 엔진은 MVCC와 락을 결합한 방식을 사용한다. 기본 고립성 수준은 REPEATABLE READ이며, 넥스트 키 락을 통해 팬텀 리드를 방지한다. 반면, PostgreSQL은 또한 MVCC를 근간으로 하지만, 스냅샷 격리를 제공하여 동시성을 높이고 VACUUM 프로세스를 통해 오래된 튜플 버전을 정리한다.

마이크로소프트 SQL 서버는 락 기반의 동시성 제어 모델을 주로 사용하며, 스냅샷 격리 수준과 행 버전 관리 기능을 옵션으로 제공한다. SQLite는 기본적으로 파일 단위의 락을 사용하며, 한 번에 하나의 쓰기 트랜잭션만 허용하는 단순한 모델을 채택하여 임베디드 환경에 적합하다.

NoSQL 데이터베이스의 경우, ACID 트랜잭션 지원 수준이 다양하다. MongoDB는 단일 문서 수준에서 원자성을 보장하며, 최근 버전에서는 복수 문서에 대한 다중 문서 트랜잭션을 지원한다. Redis는 단일 스레드 실행과 MULTI/EXEC 명령어 블록을 통해 트랜잭션의 원자성을 제공한다. 많은 키-값 저장소 및 열 지향 데이터베이스는 기본적으로 제한된 트랜잭션 지원만을 제공하거나, 결과적 일관성 모델을 채택한다.

애플리케이션 설계 시 트랜잭션의 경계를 명확히 정의하는 것이 중요하다. 트랜잭션 범위가 불필요하게 길어지면 락킹 시간이 증가하여 시스템의 동시성과 성능을 저하시킬 수 있다. 반면, 너무 짧은 트랜잭션은 ACID 특성 중 일관성을 유지하기 어려울 수 있다. 개발자는 비즈니스 로직의 단위를 잘 분석하여 하나의 논리적 작업 단위를 하나의 트랜잭션으로 묶어야 한다.

고립성 수준 선택은 애플리케이션의 요구사항과 데이터 정합성 수준에 따라 결정된다. 높은 고립성 수준(예: 직렬화 가능)은 데이터의 정확성을 보장하지만 성능 저하를 초래한다. 반면, 낮은 고립성 수준(예: 커밋된 읽기)은 성능은 우수하지만 팬텀 읽기나 더티 읽기와 같은 문제가 발생할 위험이 있다. 개발자는 이러한 트레이드오프를 이해하고, 금융 거래와 같은 정확성이 중요한 작업과 조회 위주의 작업을 구분하여 적절한 수준을 적용해야 한다.

예외 처리와 트랜잭션 롤백 전략은 견고한 애플리케이션을 구축하는 핵심이다. 모든 데이터베이스 작업은 예외 발생 가능성을 염두에 두고 작성되어야 하며, 예외가 발생했을 때는 트랜잭션을 명시적으로 ROLLBACK하여 부분적 업데이트로 인한 데이터 불일치를 방지해야 한다. 많은 ORM 프레임워크나 스프링과 같은 애플리케이션 프레임워크는 선언적 트랜잭션 관리를 제공하여 이러한 보일러플레이트 코드를 줄여준다.

분산 시스템 환경에서는 트랜잭션 관리가 더욱 복잡해진다. 여러 마이크로서비스나 데이터베이스에 걸쳐 있는 작업을 하나의 트랜잭션으로 처리하려면 분산 트랜잭션 프로토콜을 사용하거나, 사가 패턴과 같은 보상 트랜잭션을 포함한 대안적 설계 패턴을 고려해야 한다. 이는 2단계 커밋의 복잡성과 성능 문제를 피하면서 최종적 일관성을 달성하는 방법이다.