ACID

ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps.

— ISO/IEC SQL 데이터베이스 표준 명세서 철학

면접관들이 신입 백엔드 개발자들을 꼬투리 잡고 괴롭힐 때 가장 즐겨 쓰는 1순위 사골 질문. 하지만 정작 자기도 분산 환경에서의 2-Phase Commit 구현법을 물어보면 얼버무리기 십상이다. ~~NoSQL을 쓸 때는 'Eventually Consistent(언젠가는 맞춰짐)'라며 이 엄격한 규율들을 슬쩍 회피하며 도망가고 싶어진다.(...)~~

1. 개요

데이터베이스 관리 시스템(DBMS)에서 하나의 논리적 작업 단위인 트랜잭션(Transaction)의 신뢰성을 보장하기 위해 반드시 만족해야 하는 네 가지 핵심적인 공학적 속성. 각각 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)의 앞 글자를 따서 명명되었다. 이 규율을 완벽히 지키는 RDBMS(오라클, MySQL, PostgreSQL 등)는 금융 거래처럼 단 1원의 오차도 용납하지 않는 정밀 시스템의 중추로 활약한다.

2. ACID의 네 바퀴: 데이터 신뢰성의 사대천왕

ACID는 다음의 네 가지 기둥 위에 성립한다. 첫째, 원자성(Atomicity)은 '전부 실행되거나 아예 안 되거나(All or Nothing)'를 뜻한다. 송금 도중 서버가 꺼지면 내 돈만 빠져나가고 상대방에겐 입금이 안 되는 비극을 막기 위해, 트랜잭션 도중 하나라도 실패하면 전체 과정을 깨끗이 되돌린다(Rollback). 둘째, 일관성(Consistency)은 데이터베이스의 제약 조건(Primary Key, Foreign Key 등)을 트랜잭션 전후로 항상 완벽히 유지함을 뜻한다. 셋째, 격리성(Isolation)은 여러 사람이 동시에 계좌를 조회하고 송금할 때, 서로의 연산이 뒤엉켜 오작동하지 않도록 트랜잭션을 격리해 순차적으로 실행되는 것처럼 보장하는 기술이다.¹ 넷째, 지속성(Durability)은 성공적으로 완료된 트랜잭션 결과는 정전이나 디스크 폭사 속에서도 영구히 보존되어야 함을 말하며, 이를 위해 WAL(Write-Ahead Logging) 등의 로그를 디스크에 강제로 기록한다.

3. 격리성과 성능의 트레이드오프: Isolation Level의 갈등

개발자를 가장 고달프게 만드는 대목은 바로 격리성(Isolation)의 구현이다. 완벽한 격리성을 위해 모든 트랜잭션이 줄을 서서 한 번에 하나씩 디스크를 건드리게 하면(Serializable), 동시 요청 처리량이 0에 수렴해 서비스가 마비된다. 이 때문에 데이터베이스 업계는 격리 수준을 4단계(Read Uncommitted, Read Committed, Repeatable Read, Serializable)로 나누고 상황에 맞게 타협점을 찾도록 설계했다. 예를 들어 가장 낮은 레벨에서는 다른 트랜잭션이 아직 커밋하지 않은 데이터를 읽을 수 있는 Dirty Read가 발생하며, 중간 레벨에서는 동일한 조회를 두 번 실행했을 때 결과 건수가 달라지는 Phantom Read 등의 기상천외한 데이터 불일치 현상이 출몰해 개발자들을 디버깅의 수렁으로 인도한다.

4. 관련 밈 및 드립

4.1. 돈 복사 버그와 원자성의 실종

온라인 게임이나 금융 앱의 동시성 제어가 똑바로 이루어지지 않아 발생하는 '돈 복사 버그'의 원리. 두 개의 기기에서 동시에 출금 버튼을 광클했을 때, 서버가 출금 가능 잔액을 업데이트하기 전에 두 개의 트랜잭션이 동시에 잔액을 읽어 출금 승인을 떨어뜨리며 발생한다. 이 현상이 터지면 뉴스 기사 사회면에 회사 이름이 당당히 장식되고, 담당 백엔드 개발자와 DBA는 수사관들에게 조사를 받는 호사(?)를 누리게 된다.

4.2. Eventually Consistent (언젠가는 맞춰지겠지)

NoSQL 데이터베이스 진영이 대규모 트래픽 분산 처리를 위해 ACID를 포기하고 BASE(Basically Available, Soft state, Eventual consistency) 모델을 주장하며 내세운 마법의 주문. '지금 당장은 글 올린 게 남들에게 안 보일 수 있지만, 언젠가는 동기화돼서 보이니 신경 끄라'는 식으로 넘기는 유연함(?)을 발휘한다. RDBMS의 숨 막히는 ACID 규율에 질린 개발자들이 분산 서버를 짤 때 자조적으로 읊조리는 드립이다.(...)

5. 여담

Jim Gray의 위대한 유산: ACID 개념 정립과 트랜잭션 이론을 정교하게 다듬어 현대 데이터베이스 산업을 일구어낸 공로로 짐 그레이는 1998년 컴퓨터 공학계의 노벨상인 '튜링상(Turing Award)'을 수상했다. 그는 불행히도 2007년 캘리포니아 앞바다에서 요트를 타고 항해하다가 실종되어 전 세계 데이터베이스 엔지니어들의 애도를 받았다.
CAP 정리와의 충돌: 분산 데이터베이스 환경으로 넘어가면 ACID는 CAP 정리(Consistency, Availability, Partition tolerance)라는 거대한 자연법칙과 충돌한다. 네트워크 분할이 일어났을 때 완벽한 일관성(C)을 보장하려면 서버의 가용성(A)을 내려놓아야 하므로, 구글이나 아마존 같은 초대형 빅테크 기업들도 분산 아키텍처에서는 ACID 규율을 일부 완화해 사용한다.
디스크 쓰기의 마지막 보루, fsync: 데이터가 진짜 하드디스크에 영구 기록되었는지를 확인하기 위해 운영체제는 fsync 시스템 콜을 날린다. 하지만 이 명령은 하드웨어 성능을 크게 갉아먹기 때문에, 일부 데이터베이스는 성능 극대화를 위해 fsync 주기를 완화하는 설정을 열어두기도 한다. 물론 이 상태에서 정전이 나면 'Durability'는 신기루처럼 사라지고 데이터 파일이 깨지는 응보를 받게 된다.(...)

6. 관련 문서

격리성을 구현하기 위해 데이터베이스 엔진은 내부적으로 특정 레코드나 테이블 전체에 자물쇠를 채우는 'Locking' 메커니즘을 활발히 가동한다. 이때 서로가 가진 자물쇠를 풀기 위해 무한히 대기하는 데드락(Deadlock) 지옥이 가끔 연출되곤 한다. ↩