ACID

원자성은 트랜잭션이 전부 실행되거나 전혀 실행되지 않아야 함을 보장하는 특성이다. 이는 트랜잭션을 구성하는 여러 작업이 하나의 원자처럼 더 이상 분할될 수 없는 단위로 취급됨을 의미한다. 데이터베이스 시스템은 트랜잭션 내의 모든 작업이 성공적으로 완료될 때만 변경 사항을 영구적으로 적용(커밋)한다. 만약 트랜잭션 실행 중 어떤 이유로든 오류가 발생하면, 시스템은 트랜잭션 시작 이전의 상태로 모든 변경 사항을 되돌린다(롤백).

이 특성은 데이터의 무결성을 유지하는 데 핵심적이다. 예를 들어, 은행 계좌 이체 트랜잭션은 출금과 입금이라는 두 작업으로 구성된다. 원자성이 보장되지 않는다면, 출금 작업만 성공하고 입금 작업이 실패하는 상황이 발생할 수 있다. 이는 자금이 사라지는 심각한 문제를 초래한다. 원자성은 이러한 부분적 성공을 방지하여, 두 작업이 모두 성공하거나 모두 실패하도록 한다.

구현 측면에서, 데이터베이스 관리 시스템(DBMS)은 주로 트랜잭션 로그와 복구 메커니즘을 통해 원자성을 보장한다. 시스템은 트랜잭션의 시작과 모든 변경 사항을 로그에 기록한다. 트랜잭션이 완료되기 전에 시스템 장애가 발생하면, 재시작 시 이 로그를 사용하여 완료되지 않은 트랜잭션의 변경 사항을 모두 취소한다. 이를 통해 장애 발생 시점에 진행 중이던 트랜잭션의 영향을 완전히 제거한다.

일관성은 트랜잭션이 데이터베이스의 사전 정의된 규칙, 즉 무결성 제약 조건을 위반하지 않고 하나의 유효한 상태에서 다른 유효한 상태로만 전이되도록 보장하는 속성이다. 이 규칙에는 기본키, 외래키, 고유 제약 조건, 체크 제약 조건과 같은 제약 조건과 비즈니스 로직에 따른 데이터 값의 유효성 규칙 등이 포함된다. 트랜잭션의 실행 전후로 데이터베이스 상태가 항상 이러한 모든 규칙을 준수해야 한다. 일관성은 트랜잭션의 올바른 프로그래밍에 크게 의존한다. 개발자가 트랜잭션 내부의 로직을 잘못 작성하여 제약 조건을 위반하는 변경을 시도하면, 데이터베이스 시스템은 그 트랜잭션을 롤백하여 일관성을 유지한다.

예를 들어, 은행 계좌 데이터베이스에서 '잔액은 0 이상이어야 한다'는 체크 제약 조건이 존재한다고 가정한다. A 계좌에서 B 계좌로 10,000원을 이체하는 트랜잭션은 A 계좌의 잔액을 감소시키고 B 계좌의 잔액을 증가시킨다. 만약 A 계좌의 잔액이 5,000원 밖에 없는데 10,000원을 인출하는 로직이 트랜잭션에 포함되어 있다면, 이 트랜잭션은 실행을 완료할 수 없다. 시스템은 제약 조건 위반을 감지하고 트랜잭션을 중단시켜, A 계좌의 잔액이 음수가 되는 불일치 상태가 발생하지 않도록 한다.

다음 표는 일관성 유지를 위한 일반적인 데이터베이스 제약 조건의 예를 보여준다.

따라서 일관성은 원자성, 고립성, 지속성과 함께 작동하여 트랜잭션이 데이터에 대한 신뢰할 수 있고 논리적으로 올바른 변경만을 수행하도록 한다. 데이터베이스 시스템은 제약 조건을 정의하고 이를 자동으로 검사함으로써 애플리케이션 레벨에서의 오류를 방지하고 데이터의 논리적 정확성을 유지하는 데 기여한다.

고립성은 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션이 다른 트랜잭션의 중간 상태나 미완료된 변경 사항을 인지하지 못하도록 격리하는 속성이다. 이를 통해 동시성 제어를 달성하고, 데이터의 일관성을 유지한다. 고립성이 보장되지 않으면 더티 리드, 반복 불가능한 읽기, 팬텀 리드 등의 문제가 발생할 수 있다.

데이터베이스 시스템은 일반적으로 트랜잭션 격리 수준을 설정하여 고립성의 강도를 조절한다. ANSI/ISO SQL 표준은 다음과 같은 네 가지 주요 격리 수준을 정의한다.

가장 낮은 수준인 READ UNCOMMITTED는 다른 트랜잭션이 아직 커밋하지 않은 데이터를 읽을 수 있어 고립성이 거의 보장되지 않는다. 반면 가장 높은 수준인 SERIALIZABLE은 트랜잭션들을 순차적으로 실행한 것과 동일한 결과를 보장하지만, 동시성과 성능이 크게 저하될 수 있다. 대부분의 시스템은 READ COMMITTED나 REPEATABLE READ를 기본값으로 사용하여 성능과 일관성 사이의 균형을 찾는다.

고립성을 구현하는 주요 메커니즘은 락킹과 MVCC이다. 락킹은 데이터에 대한 접근을 제어하는 방식으로, 공유 락과 배타 락을 사용한다. MVCC는 데이터의 여러 버전을 유지하여 읽기 작업이 쓰기 작업을 블록하지 않도록 함으로써 동시성을 높이는 기법이다. 데이터베이스는 이러한 기술들을 조합하여 선택한 격리 수준을 충족시킨다.

트랜잭션이 성공적으로 완료(커밋)되면, 그 트랜잭션에 의해 변경된 데이터는 영구적으로 저장되어야 한다. 시스템 장애(예: 정전, 하드웨어 고장, 운영체제 크래시)가 발생하더라도, 커밋된 결과는 손실되지 않고 유지되어야 한다. 이는 데이터베이스 시스템이 지속성을 보장하기 위해 변경 사항을 비휘발성 저장 장치(주로 디스크)에 안전하게 기록함을 의미한다.

지속성을 구현하는 가장 일반적인 메커니즘은 Write-Ahead Logging (WAL)이다. 이 방식에서는 실제 데이터 파일을 변경하기 전에, 모든 변경 내용을 먼저 트랜잭션 로그라는 안전한 저장소에 순차적으로 기록한다. 트랜잭션이 커밋되면, 해당 로그 레코드가 디스크에 강제로 기록(flush)된다. 이후에 시스템 장애가 발생하면, 데이터베이스는 재시작 시 이 로그를 사용하여 커밋된 트랜잭션을 재실행(Redo)하고 완료되지 않은 트랜잭션을 취소(Undo)함으로써 데이터의 일관성과 지속성을 복구한다.

지속성은 신뢰성을 보장하는 핵심 요소이다. 온라인 뱅킹 시스템에서 송금 트랜잭션이 '완료'되었다고 사용자에게 표시된 후, 시스템 장애로 인해 그 기록이 사라진다면 심각한 문제가 발생한다. 지속성은 한 번 커밋된 작업이 시스템 실패에 관계없이 영원히 보존됨을 보증하여, 사용자와 응용 프로그램이 데이터베이스 상태를 신뢰할 수 있는 기반을 제공한다.

로깅은 ACID 트랜잭션의 원자성과 지속성을 보장하기 위한 핵심적인 구현 기법이다. 데이터베이스 시스템은 모든 데이터 변경 연산을 순차적으로 기록한 트랜잭션 로그를 유지한다. 이 로그에는 트랜잭션의 시작, 데이터 수정 전의 값(UNDO 정보), 수정 후의 값(REDO 정보), 그리고 트랜잭션의 커밋 또는 중단 여부가 포함된다.

시스템 장애가 발생했을 때, 데이터베이스는 이 로그를 이용해 복구를 수행한다. 복구 과정은 주로 두 단계로 이루어진다. 먼저 REDO 단계에서는 커밋된 트랜잭션의 모든 변경 사항을 로그 기록을 바탕으로 재적용하여 지속성을 보장한다. 이후 UNDO 단계에서는 장애 발생 시점에 완료되지 않았던(커밋되지 않은) 트랜잭션들의 변경 사항을 로그에 기록된 이전 값으로 되돌려 원자성을 보장한다[3].

로그 기반 복구의 주요 방식으로는 즉시 갱신 방식과 지연 갱신 방식이 있다. 즉시 갱신 방식에서는 트랜잭션 실행 중 데이터 변경이 실제 데이터베이스에 즉시 반영될 수 있지만, 반드시 로그에 먼저 기록(WAL, Write-Ahead Logging)해야 한다. 지연 갱신 방식에서는 모든 변경 사항이 로그에만 기록되고, 트랜잭션이 커밋된 후에야 실제 데이터베이스에 일괄 반영된다.

이러한 로깅 메커니즘은 체크포인팅과 결합되어 효율성을 높인다. 체크포인트는 주기적으로 메모리의 모든 변경 사항을 디스크의 데이터 파일에 동기화하는 지점으로, 복구 시 전체 로그가 아닌 최근 체크포인트 이후의 로그만 검사하면 되도록 해 복구 시간을 단축한다.

락킹은 데이터베이스 시스템에서 트랜잭션의 고립성을 보장하고 동시에 실행되는 여러 트랜잭션이 동일한 데이터를 충돌 없이 접근하도록 제어하는 핵심 메커니즘이다. 기본적으로 특정 데이터 항목에 대한 배타적 접근 권한을 트랜잭션에 부여함으로써, 다른 트랜잭션이 해당 데이터를 동시에 수정하거나 일관성 없는 상태로 읽는 것을 방지한다.

락은 주로 공유락과 배타락 두 가지 모드로 구분된다. 공유락은 데이터를 읽기만 하는 트랜잭션이 획득하며, 여러 트랜잭션이 동시에 공유락을 보유할 수 있다. 반면, 배타락은 데이터를 쓰거나 수정하는 트랜잭션이 필요로 하며, 배타락이 설정된 동안에는 다른 어떤 트랜잭션도 공유락이나 배타락을 획득할 수 없다. 이는 "쓰기 작업은 읽기 작업을 차단하고, 쓰기 작업은 다른 쓰기 작업을 차단한다"는 규칙으로 요약된다.

락의 범위와 관리 방식에 따라 여러 구현 전략이 존재한다. 주요 락킹 프로토콜은 다음과 같다.

락킹은 성능에 직접적인 영향을 미친다. 과도한 락 사용 또는 락을 오래 유지하면 동시성이 저하되어 대기 시간이 길어지고 처리량이 감소할 수 있다. 또한, 두 개 이상의 트랜잭션이 서로 상대방이 보유한 락을 기다리는 데드락 상태에 빠질 위험이 항상 존재한다. 데이터베이스 시스템은 데드락 감지 알고리즘을 실행하거나, 타임아웃을 설정하거나, 락을 획득하는 순서를 표준화하는 등의 방법으로 이 문제를 해결한다.

트랜잭션 관리자는 데이터베이스 관리 시스템의 핵심 구성 요소로서, ACID 속성을 보장하기 위해 트랜잭션의 시작, 실행, 완료, 복구 과정을 총괄 조정하는 소프트웨어 모듈이다. 이 관리자는 사용자나 응용 프로그램으로부터의 트랜잭션 요청을 받아, 해당 트랜잭션이 시스템 내에서 올바르게 처리되도록 중재한다. 주요 역할은 트랜잭션의 생명주기를 관리하고, 필요한 경우 락킹 및 로깅 메커니즘과 협력하여 고립성과 지속성을 구현하는 것이다.

구체적인 기능으로는 트랜잭션의 상태를 추적하는 것이 있다. 일반적으로 트랜잭션은 활동 중(Active), 부분 완료(Partially Committed), 완료(Committed), 실패(Failed), 중단(Aborted) 등의 상태를 거친다. 트랜잭션 관리자는 이러한 상태 전이를 모니터링하고 제어한다. 예를 들어, 트랜잭션 실행 중 오류가 발생하면 관리자는 트랜잭션을 '중단' 상태로 변경하고, 롤백 작업을 지시하여 원자성을 유지한다. 모든 작업이 성공적으로 수행되면 '완료' 상태로 변경하고, 커밋을 통해 변경 사항을 영구적으로 저장하도록 조치한다.

또한, 트랜잭션 관리자는 동시성 제어를 담당하여 여러 트랜잭션이 동시에 실행될 때 발생할 수 있는 문제를 방지한다. 이를 위해 락킹 프로토콜이나 타임스탬프 순서 프로토콜 등의 기법을 활용한다. 데드락이 발생하면 관리자는 탐지 알고리즘을 실행하고, 한 개 이상의 트랜잭션을 중단시켜 교착 상태를 해결한다.

요컨대, 트랜잭션 관리자는 데이터베이스 시스템이 복잡한 작업 중에도 신뢰성과 정확성을 유지할 수 있도록 뒷받침하는 조정자 역할을 한다.

관계형 데이터베이스는 ACID 속성을 구현하는 데 있어 가장 전형적이고 성숙된 시스템이다. 대부분의 상용 RDBMS는 트랜잭션의 원자성, 일관성, 고립성, 지속성을 보장하기 위한 완전한 메커니즘을 내장하고 있다. 이는 SQL 언어와 함께 관계형 모델의 핵심적인 특징으로 자리 잡았다.

주요 RDBMS 제품들은 다음과 같은 방식으로 ACID를 준수한다.

이러한 시스템들은 일반적으로 트랜잭션 로그를 먼저 기록하는 방식으로 지속성을 보장한다. 데이터 변경 사항은 메모리의 버퍼에 먼저 쓰여지지만, 그에 대한 로그는 비휘발성 저장장치에 먼저 안전하게 기록된다. 이로 인해 시스템 장애가 발생하더라도 로그를 재생하여 트랜잭션을 복구할 수 있다. 또한 락과 MVCC를 조합하여 사용자가 설정한 격리 수준에 따라 고립성을 제공한다.

NoSQL 데이터베이스는 기존 관계형 데이터베이스와는 다른 데이터 모델을 사용하며, 대규모 분산 환경에서의 확장성과 유연성을 주요 목표로 삼는다. 이로 인해 모든 NoSQL 데이터베이스가 완전한 ACID 트랜잭션을 지원하지는 않는다. 대신 일관성과 가용성, 분할 내성 사이의 균형을 맞추는 CAP 정리에 기반하여 설계되는 경우가 많다.

주요 NoSQL 데이터베이스 유형별 ACID 지원 수준은 다음과 같이 구분할 수 있다.

전반적으로 NoSQL 데이터베이스는 특정 사용 사례에 최적화되어 있으며, 강한 ACID 보장 대신 결과적 일관성이나 제한된 보장 수준을 제공하는 것이 일반적이다. 그러나 MongoDB, FaunaDB 등과 같이 완전한 ACID 트랜잭션을 지원하는 제품도 등장하고 있어, 기존의 경계가 점차 희미해지는 추세이다.