데이터 무결성을 지키는 보이지 않는 방패 트랜잭션과 ACID

우리가 매일 사용하는 수많은 디지털 서비스의 이면에는 보이지 않는 데이터의 흐름이 존재합니다. 친구에게 메시지를 보내고, 인터넷 쇼핑몰에서 물건을 구매하며, 은행 앱으로 송금하는 이 모든 행위는 데이터베이스라는 거대한 저장소의 상태를 변경하는 과정입니다. 그런데 만약 친구에게 10,000원을 송금하는 도중, 내 계좌에서는 돈이 빠져나갔는데 친구의 계좌에는 입금되기 직전 시스템이 멈춘다면 어떻게 될까요? 내 돈 10,000원은 공중으로 증발해 버린 셈이 됩니다. 이러한 데이터의 불일치와 손실은 서비스의 신뢰도를 뿌리부터 뒤흔드는 치명적인 문제입니다. 바로 이런 끔찍한 상황을 방지하기 위해 존재하는 핵심적인 개념이 바로 '데이터베이스 트랜잭션(Database Transaction)'입니다.

트랜잭션은 단순히 여러 개의 데이터베이스 명령어를 하나로 묶은 것이라는 사전적 정의를 넘어섭니다. 그것은 데이터의 정합성과 무결성을 보장하기 위한 논리적인 작업 단위이자, 데이터베이스 시스템이 세상에 제공하는 가장 중요한 약속 중 하나입니다. 위에서 언급한 송금 과정을 예로 들어봅시다. 이 과정은 사실 두 개의 작업으로 이루어져 있습니다.

1. 내 계좌(A)의 잔액에서 10,000원을 차감한다. (UPDATE accounts SET balance = balance - 10000 WHERE user_id = 'A')
2. 친구 계좌(B)의 잔액에 10,000원을 추가한다. (UPDATE accounts SET balance = balance + 10000 WHERE user_id = 'B')

트랜잭션은 이 두 개의 작업을 하나의 '분리할 수 없는 덩어리'로 취급합니다. 즉, 두 작업이 모두 성공적으로 완료되거나, 만약 중간에 하나라도 실패하면 이전에 실행했던 모든 작업을 원래대로 되돌려 놓습니다. 1번 작업만 성공하고 시스템이 멈추는 중간 상태란 존재할 수 없게 만드는 것입니다. 이것이 바로 트랜잭션의 핵심 역할이며, 이러한 특성을 보장하기 위해 모든 관계형 데이터베이스 관리 시스템(RDBMS)은 ACID라는 네 가지 중요한 원칙을 철저하게 따릅니다. 이 글에서는 데이터베이스의 심장과도 같은 트랜잭션의 개념을 깊이 있게 파고들고, 그 신뢰성을 보증하는 네 개의 기둥인 ACID 원칙(원자성, 일관성, 고립성, 지속성)이 각각 무엇을 의미하며 실제 시스템에서 어떻게 동작하는지 상세하게 알아보겠습니다.

트랜잭션의 생명주기: 탄생부터 소멸까지

트랜잭션은 데이터베이스 내에서 명확한 시작과 끝을 가집니다. 개발자는 특정 작업의 시작을 선언하고, 관련된 모든 데이터 조작을 수행한 뒤, 최종적으로 이 작업들의 결과를 영구적으로 반영할 것인지(Commit), 아니면 모두 없었던 일로 할 것인지(Rollback)를 결정합니다. 이 과정에서 트랜잭션은 여러 상태를 거치게 됩니다. 이를 이해하는 것은 트랜잭션의 동작 방식을 파악하는 데 매우 중요합니다.

• 활성 (Active): 트랜잭션이 시작되어 실행 중인 상태입니다. BEGIN TRANSACTION과 같은 명령어로 시작되며, 내부의 SQL 쿼리들이 하나씩 실행되는 동안 이 상태에 머무릅니다.
• 부분 완료 (Partially Committed): 트랜잭션의 마지막 명령어까지 모두 실행되었지만, 아직 그 변경 사항이 데이터베이스에 영구적으로 저장되지는 않은 상태입니다. 시스템은 이제 이 변경 사항들을 디스크에 안전하게 기록할 준비를 합니다.
• 실패 (Failed): 트랜잭션이 실행되는 도중 오류(SQL 문법 오류, 제약 조건 위반, 시스템 장애 등)가 발생하여 더 이상 정상적인 진행이 불가능한 상태입니다. 이 상태에 빠진 트랜잭션은 반드시 철회(Rollback)되어야 합니다.
• 철회 (Aborted): 트랜잭션이 실패했거나, 개발자가 명시적으로 ROLLBACK 명령을 실행하여 트랜잭션 시작 이전의 상태로 모든 변경 사항을 되돌린 상태입니다. 트랜잭션은 이 상태를 거쳐 최종적으로 종료됩니다.
• 완료 (Committed): 트랜잭션의 모든 작업이 성공적으로 완료되어 개발자가 COMMIT 명령을 실행한 상태입니다. 이 시점에 트랜잭션의 변경 사항은 데이터베이스에 영구적으로 반영되며, 시스템 장애가 발생하더라도 이 결과는 사라지지 않습니다.

이러한 상태 변화를 그림으로 표현하면 다음과 같습니다.

       +----------+      SQL 실행      +---------------------+
시작 -->|  활성    |------------------>|      부분 완료      |--+
       | (Active) |<--+               | (Partially Commit)  |  |
       +----------+   |               +---------------------+  | COMMIT
             |        |                                        |
      오류   |        | ROLLBACK                               V
             V        |                                  +-----------+
       +----------+   |                                  |   완료    |
       |  실패    |---+--------------------------------->| (Commit)  |
       | (Failed) |                                      +-----------+
       +----------+
             |
             | ROLLBACK
             V
       +----------+
       |  철회    |
       | (Aborted)|
       +----------+

개발자는 SQL에서 START TRANSACTION 또는 BEGIN으로 트랜잭션의 시작을 알리고, COMMIT으로 성공적인 완료를, ROLLBACK으로 작업 취소를 명시적으로 선언합니다. 이 명령어들은 데이터베이스에게 작업의 논리적 범위를 알려주는 중요한 신호입니다.

-- 트랜잭션 시작
START TRANSACTION;

-- 1. 사용자 A의 잔액 10,000원 차감
UPDATE accounts SET balance = balance - 10000 WHERE user_id = 'userA';

-- 2. 사용자 B의 잔액 10,000원 추가
UPDATE accounts SET balance = balance + 10000 WHERE user_id = 'userB';

-- 모든 작업이 성공했으므로, 변경사항을 영구 반영
COMMIT; 

-- 만약 중간에 오류가 발생했다면?
START TRANSACTION;

UPDATE accounts SET balance = balance - 10000 WHERE user_id = 'userA';

-- 여기서 시스템 장애 발생! 또는 잔액 부족으로 업데이트 실패!

-- 데이터베이스는 자동으로 이 트랜잭션을 롤백하거나, 
-- 개발자가 에러 핸들링을 통해 명시적으로 롤백
ROLLBACK;

이제 이러한 트랜잭션이 어떻게 신뢰성을 보장하는지, 그 핵심 원칙인 ACID에 대해 하나씩 깊이 있게 살펴보겠습니다.

ACID 제1원칙: 원자성 (Atomicity) - 전부 아니면 전무

원자성(Atomicity)은 트랜잭션에 포함된 모든 작업들이 마치 하나의 원자처럼 분리할 수 없는 단위로 취급되어야 한다는 원칙입니다. 즉, 트랜잭션 내의 모든 연산이 전부 성공적으로 실행되거나, 단 하나라도 실패할 경우 모든 연산이 실행되기 이전의 상태로 완전히 되돌아가야 함을 의미합니다. 'All or Nothing'이라는 말로 가장 잘 요약될 수 있습니다.

앞서 들었던 은행 송금 예시가 원자성을 설명하는 가장 대표적인 사례입니다. A의 계좌에서 돈을 빼는 작업과 B의 계좌에 돈을 넣는 작업은 논리적으로 하나의 묶음입니다. 만약 A의 계좌에서 돈을 빼는 데는 성공했지만, B의 계좌에 돈을 넣기 직전 정전이 발생했다고 가정해봅시다. 원자성이 없다면 A의 돈은 사라지고 B는 돈을 받지 못하는, 데이터베이스의 일관성이 깨진 상태로 남게 됩니다. 하지만 원자성 원칙 덕분에 데이터베이스 시스템은 이 트랜잭션이 완전히 성공하지 못했음을 인지하고, A의 계좌에서 돈을 빼는 작업 자체를 취소(Rollback)하여 시스템이 재시작되었을 때 모든 것을 원래 상태로 복구합니다.

원자성은 어떻게 보장되는가: 복구 시스템과 로그

데이터베이스 관리 시스템(DBMS)은 원자성을 보장하기 위해 정교한 내부 메커니즘을 사용합니다. 그 중심에는 트랜잭션 로그(Transaction Log) 또는 WAL(Write-Ahead Logging)이라는 기술이 있습니다.

1. 로그 우선 기록 (Write-Ahead): 데이터베이스는 디스크에 있는 실제 데이터를 변경하기 전에, 앞으로 '어떤 변경을 할 것이다'라는 내용을 먼저 로그 파일에 기록합니다. 이 로그에는 트랜잭션의 시작, 데이터의 변경 전 값(Undo Log)과 변경 후 값(Redo Log), 그리고 트랜잭션의 종료(Commit 또는 Abort) 정보가 순차적으로 기록됩니다.
2. 데이터 변경: 로그가 안전하게 디스크에 기록된 후에야, 실제 데이터(테이블)의 변경이 메모리(버퍼 캐시)에서 이루어집니다. 이 변경된 데이터는 즉시 디스크에 써지지 않을 수도 있습니다. 성능 향상을 위해 여러 변경 사항을 모아서 나중에 한꺼번에 쓰기 때문입니다.
3. 장애 발생과 복구: 만약 데이터 변경 작업 중 시스템이 갑자기 다운되면, 재부팅 시 DBMS는 가장 먼저 트랜잭션 로그를 확인합니다.
   • 로그에 트랜잭션의 'Commit' 기록이 있다면, 시스템은 이 트랜잭션이 성공적으로 완료되어야 함을 인지합니다. 만약 디스크의 실제 데이터에 변경 사항이 아직 반영되지 않았다면, 로그에 기록된 변경 후 값(Redo Log)을 사용하여 데이터 변경을 재실행(Redo)하여 트랜잭션을 완료시킵니다.
   • 로그에 트랜잭션의 'Commit' 기록이 없다면(시작 기록만 있거나 아무 기록도 없다면), 이 트랜잭션은 실패한 것으로 간주합니다. 시스템은 로그에 기록된 변경 전 값(Undo Log)을 사용하여 지금까지 이루어진 모든 변경 사항을 거꾸로 되돌려(Undo), 트랜잭션이 시작되기 전의 완벽한 상태로 복원합니다.

이처럼 로그를 통해 모든 변경 작업을 추적하고, 장애 발생 시 이를 기반으로 복구하는 메커니즘이 있기 때문에 DBMS는 '전부 아니면 전무'라는 원자성의 약속을 지킬 수 있는 것입니다. 개발자는 그저 BEGIN, COMMIT, ROLLBACK을 사용할 뿐이지만, 그 이면에서는 이처럼 복잡하고 견고한 시스템이 데이터의 무결성을 위해 쉴 새 없이 움직이고 있습니다.

ACID 제2원칙: 일관성 (Consistency) - 데이터는 언제나 유효해야 한다

일관성(Consistency)은 트랜잭션이 성공적으로 완료된 후에도 데이터베이스가 항상 유효하고 정의된 규칙들을 만족하는 상태를 유지해야 한다는 원칙입니다. 원자성이 '프로세스'의 성공 여부에 초점을 맞춘다면, 일관성은 '데이터' 자체의 정합성에 초점을 맞춥니다. 즉, 트랜잭션은 데이터베이스를 하나의 '일관된 상태'에서 또 다른 '일관된 상태'로 전환시켜야 할 책임이 있습니다.

여기서 말하는 '일관된 상태'란 무엇일까요? 이는 데이터베이스에 설정된 여러 제약 조건(Constraints)이나 비즈니스 규칙을 만족하는 상태를 의미합니다.

• 도메인 제약조건: 특정 컬럼에 입력될 수 있는 값의 종류나 범위를 제한합니다. (예: `나이` 컬럼에는 양수만 입력 가능, `성별` 컬럼에는 '남' 또는 '여'만 입력 가능)
• 개체 무결성 제약조건 (Entity Integrity): 모든 테이블은 기본 키(Primary Key)를 가져야 하며, 이 기본 키는 절대 NULL 값을 가질 수 없고 중복될 수 없습니다. 이는 각 데이터 행(row)을 고유하게 식별하기 위한 최소한의 장치입니다.
• 참조 무결성 제약조건 (Referential Integrity): 외래 키(Foreign Key) 값은 반드시 참조하는 테이블의 기본 키 값 중 하나이거나 NULL이어야 합니다. 예를 들어, '주문' 테이블의 '고객ID'는 반드시 '고객' 테이블에 실제로 존재하는 '고객ID'여야 합니다. 존재하지 않는 유령 고객의 주문을 막는 것입니다.
• 애플리케이션 수준의 비즈니스 규칙: 데이터베이스 스키마에 직접 정의되진 않았지만, 애플리케이션 로직 상 반드시 지켜져야 하는 규칙들입니다. (예: '계좌 잔고는 마이너스가 될 수 없다', 'VIP 고객의 등급은 SILVER 이하로 강등될 수 없다')

다시 은행 송금 예시로 돌아가 봅시다. 만약 '계좌 잔고는 0원 이상이어야 한다'는 `CHECK (balance >= 0)` 제약 조건이 데이터베이스에 설정되어 있다고 가정해 보겠습니다. A의 잔고가 5,000원인데 10,000원을 송금하려는 트랜잭션이 실행되면, `UPDATE accounts SET balance = balance - 10000 WHERE user_id = 'A'` 쿼리는 잔고를 -5,000원으로 만들려고 시도합니다. 이때, DBMS는 이 작업이 일관성 규칙(CHECK 제약 조건)을 위반한다는 사실을 즉시 감지하고 트랜잭션 전체를 실패 처리하며 롤백시킵니다. 따라서 데이터베이스는 결코 '잔고가 마이너스인' 비일관적인 상태에 도달하지 않습니다.

일관성은 누가 책임지는가: DBMS와 애플리케이션의 협력

일관성을 보장하는 책임은 데이터베이스 시스템과 애플리케이션 개발자에게 나뉘어 있습니다.

1. DBMS의 역할: `PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE`, `NOT NULL`, `CHECK` 와 같은 데이터베이스에 내장된 제약 조건들을 강제하는 것입니다. 트랜잭션 내의 어떤 DML(INSERT, UPDATE, DELETE) 문이 이러한 제약 조건을 위반하려고 하면, DBMS는 해당 문장의 실행을 막고 오류를 발생시켜 트랜잭션을 중단시킵니다. 이는 일관성을 지키는 가장 강력하고 기본적인 방어선입니다.
2. 애플리케이션 개발자의 역할: 데이터베이스 스키마만으로는 표현하기 어려운 복잡한 비즈니스 규칙을 트랜잭션 로직 내에 올바르게 구현해야 합니다. 예를 들어, '쇼핑몰의 재고는 주문 수량보다 많거나 같아야 한다'는 규칙은 개발자가 직접 `SELECT`를 통해 재고를 확인하고, 충분할 경우에만 `UPDATE`를 통해 재고를 차감하는 로직을 트랜잭션 안에 포함시켜야 합니다. 만약 이 로직에 허점이 있다면, 데이터는 비일관적인 상태(재고가 마이너스가 되는 등)에 빠질 수 있습니다.

결론적으로, 일관성은 트랜잭션의 성공적인 완료를 위한 궁극적인 목표와 같습니다. 원자성, 고립성, 지속성은 이 일관성을 깨뜨리지 않고 안전하게 데이터 상태를 전환하기 위한 기술적인 수단이라고 볼 수 있습니다.

ACID 제3원칙: 고립성 (Isolation) - 각자의 세상에서 실행되는 것처럼

고립성(Isolation), 또는 격리성이란 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션은 마치 데이터베이스에 자기 혼자만 접근하는 것처럼 다른 트랜잭션의 중간 작업 결과에 영향을 받거나 주어서는 안 된다는 원칙입니다. 현대의 데이터베이스는 수많은 사용자와 애플리케이션이 동시에 접근하여 데이터를 읽고 쓰는 다중 사용자 환경입니다. 만약 이러한 동시 접근에 대한 제어가 없다면 데이터는 순식간에 엉망이 될 것입니다. 고립성은 바로 이 동시성(Concurrency) 문제를 해결하기 위한 핵심 원칙입니다.

예를 들어, 쇼핑몰의 인기 상품 재고가 단 1개 남았다고 가정해 봅시다. 동시에 두 명의 사용자(A와 B)가 이 상품을 구매하려고 시도합니다.

1. 트랜잭션 A가 재고를 확인합니다. (재고: 1)
2. 동시에 트랜잭션 B도 재고를 확인합니다. (재고: 1)
3. 트랜잭션 A는 재고가 있으므로 주문을 생성하고 재고를 0으로 줄입니다.
4. 트랜잭션 B도 자신이 확인할 당시 재고가 있었으므로 주문을 생성하고 재고를 0으로 줄이려고 시도합니다.

만약 고립성이 제대로 지켜지지 않는다면, 재고는 1개뿐인데 2개의 주문이 생성되고 재고는 -1이 되는 말도 안 되는 상황이 발생할 수 있습니다. (이를 'Lost Update' 문제라고 합니다.) 고립성은 트랜잭션 A가 재고를 확인하고 변경하는 모든 과정이 끝날 때까지 트랜잭션 B가 재고 데이터에 접근하는 것을 막거나, 혹은 트랜잭션 A의 작업이 완료되기 전의 중간 상태를 보지 못하게 함으로써 이러한 문제를 방지합니다. 즉, 트랜잭션 B는 트랜잭션 A가 완전히 끝나고 난 후의 데이터(재고: 0)를 보게 되므로, 주문을 실패 처리할 수 있습니다.

고립성을 해치는 주범들: 동시성 이상 현상

고립성이 완벽하게 지켜지지 않을 때 발생할 수 있는 주요 문제들은 다음과 같습니다.

• Dirty Read (더티 리드): 한 트랜잭션이 아직 완료(Commit)되지 않은 다른 트랜잭션의 수정 데이터를 읽는 현상입니다. 만약 수정하던 트랜잭션이 나중에 롤백(Rollback)된다면, 데이터를 읽었던 트랜잭션은 결국 존재하지 않는 '더러운' 데이터를 기반으로 작업을 수행한 셈이 되어 데이터 불일치를 유발합니다.
• Non-Repeatable Read (반복 불가능 읽기): 한 트랜잭션 내에서 같은 데이터를 두 번 이상 읽었을 때, 그 사이에 다른 트랜잭션이 해당 데이터를 수정하고 커밋해버려서 첫 번째 읽기와 두 번째 읽기의 결과가 다르게 나타나는 현상입니다. 데이터의 일관된 조회를 방해합니다.
• Phantom Read (유령 읽기): 한 트랜잭션이 특정 범위의 데이터를 조회했는데, 그 사이에 다른 트랜잭션이 그 범위에 해당하는 새로운 데이터를 추가하거나 삭제하고 커밋하여, 나중에 다시 같은 범위로 조회했을 때 이전에 없던 데이터가 보이거나(유령처럼 나타남) 있던 데이터가 사라지는 현상입니다.

고립성을 지키는 방법: 잠금(Locking)과 격리 수준(Isolation Level)

DBMS는 이러한 동시성 문제를 해결하고 고립성을 보장하기 위해 주로 잠금(Locking)이라는 메커니즘을 사용합니다. 어떤 트랜잭션이 특정 데이터에 접근하려고 할 때, 그 데이터에 '자물쇠'를 걸어 다른 트랜잭션의 동시 접근을 제어하는 방식입니다.

• 공유 잠금 (Shared Lock / Read Lock): 데이터를 읽을 때 사용하는 잠금입니다. 여러 트랜잭션이 동시에 공유 잠금을 획득하고 데이터를 읽는 것은 가능하지만, 공유 잠금이 걸려있는 동안에는 다른 트랜잭션이 해당 데이터를 수정하기 위한 배타적 잠금을 얻을 수 없습니다.
• 배타적 잠금 (Exclusive Lock / Write Lock): 데이터를 수정(INSERT, UPDATE, DELETE)할 때 사용하는 잠금입니다. 한 트랜잭션이 배타적 잠금을 획득하면, 다른 어떤 트랜잭션도 해당 데이터에 대해 공유 잠금이나 배타적 잠금을 획득할 수 없습니다. 즉, 읽기와 쓰기 모두가 차단됩니다.

하지만 잠금을 너무 광범위하게, 혹은 너무 오래 유지하면 다른 트랜잭션들이 계속 대기해야 하므로 시스템 전체의 성능(동시 처리 능력)이 저하됩니다. 이 때문에 데이터베이스 표준에서는 고립성의 수준을 몇 단계로 나누어, 개발자가 데이터 정합성의 중요도와 시스템 성능 사이에서 균형을 맞출 수 있도록 선택지를 제공합니다. 이것이 바로 트랜잭션 격리 수준(Transaction Isolation Level)입니다.

격리 수준은 낮을수록 동시성은 높아지지만 데이터 정합성에 문제가 생길 가능성이 커지고, 높을수록 정합성은 보장되지만 동시성이 낮아져 성능이 저하될 수 있습니다. 다음은 표준 SQL에서 정의하는 4가지 격리 수준입니다.

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	설명
READ UNCOMMITTED	발생	발생	발생	가장 낮은 격리 수준. 커밋되지 않은 다른 트랜잭션의 변경 내용까지 읽을 수 있습니다. 데이터 정합성 문제가 많아 거의 사용되지 않습니다.
READ COMMITTED	방지	발생	발생	커밋된 데이터만 읽을 수 있습니다. Dirty Read 문제를 해결합니다. 하지만 한 트랜잭션 내에서 같은 데이터를 여러 번 읽을 때 결과가 다를 수 있습니다. 대부분의 상용 데이터베이스에서 기본값으로 사용됩니다.
REPEATABLE READ	방지	방지	발생	트랜잭션이 시작된 시점의 데이터 버전을 기준으로 읽기를 수행하여, 트랜잭션이 끝날 때까지 다른 트랜잭션의 수정 사항이 보이지 않습니다. Non-Repeatable Read를 해결하지만, 새로운 데이터 추가로 인한 Phantom Read는 발생할 수 있습니다. MySQL의 InnoDB 스토리지 엔진의 기본값입니다.
SERIALIZABLE	방지	방지	방지	가장 높은 격리 수준. 트랜잭션을 마치 순서대로 하나씩 실행하는 것처럼 동작하게 만듭니다. 모든 동시성 이상 현상을 방지하지만, 잠금의 범위가 넓어져 동시 처리 성능이 크게 저하될 수 있습니다. 완벽한 데이터 정합성이 요구될 때 사용됩니다.

최근에는 잠금의 단점을 보완하기 위해 MVCC(Multi-Version Concurrency Control)라는 기술을 사용하는 DBMS(PostgreSQL, Oracle, InnoDB 등)가 많아졌습니다. MVCC는 데이터를 수정할 때마다 새로운 버전의 복사본을 만들고, 각 트랜잭션은 자신이 시작된 시점의 데이터 버전을 참조하여 읽기 작업을 수행합니다. 이 방식은 읽기 작업이 쓰기 작업을 차단하지 않고, 쓰기 작업 또한 읽기 작업을 차단하지 않기 때문에 동시성 성능을 크게 향상시킬 수 있습니다.

ACID 제4원칙: 지속성 (Durability) - 한번 저장된 것은 영원하다

지속성(Durability)은 성공적으로 완료(Commit)된 트랜잭션의 결과는 시스템에 영구적으로 저장되어야 하며, 이후에 어떤 종류의 시스템 장애(예: 정전, OS 충돌, DBMS 프로세스 비정상 종료)가 발생하더라도 그 결과가 절대 사라지지 않아야 한다는 원칙입니다.

ATM에서 현금을 인출하고 명세표까지 받았다면, 그 거래는 완벽하게 끝난 것입니다. 잠시 후 은행 전산 시스템 전체가 다운되더라도, 시스템이 복구되었을 때 내 계좌의 잔액은 인출이 반영된 상태여야만 합니다. 만약 시스템이 다운되었다는 이유로 인출 기록이 사라진다면 금융 시스템에 대한 신뢰는 존재할 수 없을 것입니다. 지속성은 바로 이 '신뢰'를 보증하는 마지막 퍼즐 조각입니다.

지속성은 어떻게 보장되는가: 로그와 복구 시스템의 재등장

지속성을 보장하는 핵심 기술 역시 원자성에서 등장했던 트랜잭션 로그(WAL)와 복구 시스템(Recovery System)입니다. 그 동작 원리는 다음과 같습니다.

1. 메모리에서의 작업: 데이터베이스에 대한 모든 변경 작업은 성능상의 이유로 일단 주기억장치(RAM)에 있는 '버퍼 캐시'라는 공간에서 먼저 이루어집니다. 디스크 I/O는 매우 느린 작업이기 때문에 매번 변경이 있을 때마다 디스크에 직접 쓰는 것은 비효율적입니다.
2. COMMIT 시점의 로그 플러시: 사용자가 트랜잭션을 COMMIT하면, DBMS는 즉시 해당 트랜잭션과 관련된 모든 로그(데이터의 변경 전후 값 포함)를 메모리 상의 '로그 버퍼'에서 비휘발성 저장 장치인 디스크(SSD/HDD)로 안전하게 내려씁니다(Flush). 이 작업이 완료되어야만 DBMS는 사용자에게 '커밋 성공' 응답을 보냅니다.
3. 데이터 파일의 지연 쓰기: 실제 데이터가 담긴 데이터 파일(테이블, 인덱스 등)은 아직 디스크에 기록되지 않았을 수 있습니다. 이는 '체크포인트(Checkpoint)'라는 특정 시점에 모아서 기록하거나, 버퍼 캐시 공간이 필요할 때 내려쓰는 등 DBMS의 내부 정책에 따라 비동기적으로 처리됩니다.
4. 장애 발생과 복구: 만약 데이터 파일이 디스크에 미처 기록되기 전에 시스템 장애가 발생하면 어떻게 될까요?
   • 시스템이 재부팅되면, DBMS의 복구 관리자는 트랜잭션 로그를 처음부터 끝까지 훑어봅니다.
   • 로그에 'Commit' 기록이 있는 트랜잭션인데, 만약 해당 변경 사항이 데이터 파일에 아직 반영되지 않았다면, 로그에 기록된 정보를 바탕으로 변경 작업을 다시 실행(Redo)하여 데이터 파일에 적용합니다. 이를 통해 커밋된 트랜잭션의 결과가 유실되는 것을 막습니다.
   • 로그에 'Commit' 기록이 없는 트랜잭션(실패했거나 진행 중이었던 트랜잭션)의 변경 사항이 데이터 파일에 일부 기록되었을 수도 있습니다. 이 경우, 로그의 변경 전 정보를 바탕으로 원래대로 되돌리는 작업(Undo)을 수행합니다. 이는 원자성을 보장하는 과정이기도 합니다.

결론적으로, 트랜잭션이 커밋되었다는 것은 그 트랜잭션의 결과가 로그 파일에 안전하게 기록되었음을 의미하며, 이 로그 파일이 존재하는 한 어떠한 시스템 장애가 발생하더라도 데이터를 복구하여 지속성을 보장할 수 있는 것입니다. 이것이 데이터베이스가 일반적인 파일 시스템과 근본적으로 다른, 신뢰성의 핵심입니다.

ACID를 넘어서: 성능과의 트레이드오프와 BASE

ACID 원칙은 데이터의 무결성과 신뢰성을 보장하는 매우 강력한 모델이지만, 세상의 모든 시스템에 완벽한 해답이 되는 것은 아닙니다. 특히 ACID를 엄격하게 준수하는 것, 그중에서도 높은 수준의 고립성(Serializable)을 유지하는 것은 시스템의 성능과 확장성에 상당한 부담을 줄 수 있습니다. 수많은 트랜잭션이 동시에 하나의 데이터를 변경하려고 할 때, 잠금으로 인한 대기 시간은 전체 시스템의 처리량을 급격히 떨어뜨릴 수 있습니다.

이러한 배경에서, 특히 대규모 분산 시스템과 빅데이터 시대를 맞이하여 NoSQL 데이터베이스 진영을 중심으로 ACID의 대안으로 BASE라는 철학이 등장했습니다.

• Basically Available (기본적인 가용성): 시스템은 일부 노드에 장애가 발생하더라도 부분적인 서비스 중단은 있을지언정, 전체 시스템이 멈추는 일은 없어야 한다는 원칙입니다. 즉, 가용성을 최우선으로 합니다.
• Soft State (소프트 상태): 시스템의 상태는 외부의 입력이 없어도 시간이 지남에 따라 변할 수 있다는 개념입니다. 이는 데이터가 '최종적으로' 일관된 상태로 수렴해가는 과정에 있음을 의미합니다.
• Eventually Consistent (결과적 일관성): 시스템에 새로운 데이터 변경이 발생하지 않는다면, 시간이 흐름에 따라 모든 노드의 데이터는 결국 동일한 상태로 수렴(일치)하게 된다는 원칙입니다. ACID처럼 즉각적인 일관성을 보장하는 대신, '언젠가는' 일관성이 맞춰질 것을 보장합니다.

ACID가 비관적(Pessimistic) 제어 방식으로 충돌을 미리 막는 데 집중한다면, BASE는 낙관적(Optimistic) 제어 방식으로 일단 작업을 허용하고 나중에 일관성을 맞추는 데 집중합니다.

어떤 모델이 더 우월하다고 말할 수는 없습니다. 이것은 전적으로 서비스의 요구사항에 달려 있습니다.

• ACID가 적합한 경우: 은행 시스템, 결제/주문 시스템, 재고 관리 시스템 등 데이터의 일관성이 단 1초, 단 1건이라도 틀리면 치명적인 비즈니스 손실로 이어지는 경우.
• BASE가 적합한 경우: 소셜 미디어의 '좋아요' 수, 게시물 피드, 상품 추천 목록, 로그 데이터 분석 등 데이터의 일시적인 불일치가 허용되며, 그보다 대규모 트래픽을 빠르고 끊김 없이 처리하는 것이 더 중요한 경우.

결론: 개발자에게 트랜잭션과 ACID란 무엇인가

데이터베이스 트랜잭션과 ACID 원칙은 단순히 데이터베이스 이론의 한 챕터가 아닙니다. 그것은 데이터 기반의 안정적인 소프트웨어를 구축하고자 하는 모든 개발자가 반드시 이해하고 존중해야 할 기본 철학이자 약속입니다. 우리가 작성하는 코드 한 줄 한 줄이 데이터베이스의 상태를 어떻게 변화시키는지, 그 변화의 범위와 결과를 명확히 인지하고 트랜잭션으로 묶어주는 것은 버그를 줄이고 데이터 무결성을 지키는 가장 확실한 방법입니다.

원자성(Atomicity)을 통해 우리는 작업의 실패를 두려워하지 않고 과감하게 로직을 실행할 수 있는 '안전망'을 얻습니다. 일관성(Consistency)을 통해 우리의 데이터가 언제나 비즈니스 규칙에 맞는 올바른 상태로 유지될 것이라는 믿음을 가집니다. 고립성(Isolation)을 통해 수많은 사용자가 동시에 시스템을 사용하더라도 데이터가 서로 엉키지 않을 것이라는 확신을 얻습니다. 그리고 지속성(Durability)을 통해 우리의 노력이 시스템의 장애로 인해 허무하게 사라지지 않을 것이라는 최종적인 보증을 받습니다.

애플리케이션의 복잡성이 증가하고 다루는 데이터의 규모가 커질수록, 트랜잭션을 올바르게 설계하고 사용하는 능력은 개발자의 핵심 역량이 됩니다. 단순히 프레임워크가 제공하는 @Transactional 어노테이션을 사용하는 것을 넘어, 그 이면에서 어떤 격리 수준으로, 어떤 전파 옵션으로 동작하는지, 그리고 그것이 우리 시스템의 성능과 데이터 정합성에 어떤 영향을 미칠지 고민하는 깊이 있는 이해가 필요합니다. 이 글이 데이터의 신뢰성을 책임지는 보이지 않는 방패, 트랜잭션과 ACID를 이해하는 데 튼튼한 디딤돌이 되었기를 바랍니다.