ACID와 BASE, 데이터 일관성과 가용성 사이의 설계 선택

거래의 정확성을 보장하는 ACID

데이터베이스 설계에서 트랜잭션 처리 방식은 데이터의 신뢰성과 서비스 동작을 좌우한다. 관계형 데이터베이스 관리 시스템(RDBMS)에서 널리 쓰이는 ACID는 트랜잭션이 안정적으로 완료되기 위해 갖춰야 할 속성을 묶은 개념이다.

Atomicity(원자성): 모두 처리하거나 전혀 처리하지 않는다

트랜잭션은 더 나눌 수 없는 최소 작업 단위로 취급된다. 내부 작업은 전부 성공해야 하며, 하나라도 실패하면 실행 전 상태로 돌아간다. 은행 송금이라면 출금과 입금이 함께 성공하거나 함께 실패해야 한다.

Consistency(일관성): 제약조건을 지킨 상태로 전환한다

트랜잭션 전후의 데이터베이스는 일관된 상태여야 한다. 무결성 제약조건도 항상 만족해야 하며, 실패한 트랜잭션은 Redo(재실행)와 Undo(취소) 연산으로 일관된 상태를 복구한다. 예를 들어 은행 계좌 잔액은 항상 0원 이상이어야 한다는 규칙을 지켜야 한다.

Isolation(격리성): 진행 중인 변경을 다른 작업에 노출하지 않는다

동시에 여러 트랜잭션이 실행되더라도 각 작업은 독립적으로 수행된다. 다른 트랜잭션은 아직 끝나지 않은 중간 상태를 볼 수 없으며, 이 특성은 주로 잠금(Locking) 메커니즘으로 구현한다. 사용자 A가 데이터를 수정하는 동안 사용자 B가 불완전한 값을 읽지 못하도록 하는 방식이다.

Durability(지속성): 완료된 결과는 장애 뒤에도 남는다

성공한 트랜잭션의 결과는 영구적으로 저장돼야 한다. 시스템 장애나 정전이 발생하더라도 완료된 데이터가 사라져서는 안 되며, 로그 파일과 백업이 이를 뒷받침한다.

⤢✕

분산 환경에서 가용성을 우선하는 BASE

BASE는 NoSQL 데이터베이스와 대규모 분산 시스템에서 주로 사용하는 접근이다. 즉시 일관성을 보장하는 대신, 서비스 가용성과 확장성을 높이는 데 초점을 둔다.

Basically Available(기본적 가용성)

시스템은 성공 또는 실패 형태로 항상 응답을 반환한다. 일부 노드에 장애가 발생해도 전체 서비스는 계속 동작하며, 여러 스토리지에 데이터 복사본을 저장해 가용성을 확보한다. Amazon Dynamo DB는 여러 지역에 데이터를 복제해 높은 가용성을 제공하는 사례다.

Soft-state(소프트 상태)

데이터베이스 상태는 시간에 따라 달라질 수 있다. 특정 시점에는 일관성이 보장되지 않을 수 있고, 외부 입력이 없더라도 시스템 상태가 바뀔 수 있다. 소셜 미디어의 좋아요 수가 잠시 일치하지 않는 상황이 이에 해당한다.

Eventually Consistent(최종적 일관성)

모든 복제본이 즉시 같은 값을 갖지는 않더라도, 시간이 충분히 지나면 결국 일관된 상태에 도달한다. DNS 변경사항이 전 세계에 전파되는 동안에는 차이가 생길 수 있지만, 이후에는 모든 서버가 같은 정보를 갖게 되는 방식이다.

⤢✕

일관성·가용성·확장성의 우선순위가 선택을 가른다

ACID는 강한 일관성을 우선하므로 가용성이 일부 희생될 수 있다. 반대로 BASE는 높은 가용성을 택하는 대신 일시적인 일관성 불일치를 허용한다.

확장 방식도 다르다. ACID는 수직적 확장(Scale-up)에 적합하지만 분산 환경에서는 확장에 제약이 있을 수 있다. BASE는 수평적 확장(Scale-out)에 최적화돼 대규모 분산 시스템에 잘 맞는다.

특성	ACID	BASE
일관성	강한 일관성	최종적 일관성
가용성	제한적 가용성	높은 가용성
확장성	제한적	높은 확장성
트랜잭션	완전한 트랜잭션 지원	제한적 트랜잭션 또는 미지원
적합한 데이터베이스	MySQL, PostgreSQL, Oracle	MongoDB, Cassandra, DynamoDB
적합한 사용 사례	은행 시스템, ERP	소셜 미디어, 로그 분석

금융 거래나 예약 시스템처럼 정확성이 우선인 애플리케이션은 ACID에 적합하다. 소셜 미디어, 콘텐츠 관리, 로그 분석처럼 가용성과 성능이 중요한 애플리케이션은 BASE 방식에 더 잘 맞는다. 다만 BASE는 일관성 관리와 충돌 해결을 위한 복잡한 로직을 요구할 수 있다.

송금과 소셜 미디어에서 달라지는 요구사항

A 계좌에서 B 계좌로 10만원을 이체하는 은행 송금은 ACID 특성이 필요한 전형적인 사례다. 출금과 입금은 모두 성공하거나 모두 실패해야 한다. 모든 계좌 잔액은 0원 이상이어야 하고, 총 잔액 합계는 변하지 않아야 한다. 이체 도중 다른 사용자가 불완전한 상태를 확인할 수 없으며, 이체가 끝난 뒤 장애가 발생해도 거래 기록은 보존돼야 한다.

Instagram과 같은 소셜 미디어 플랫폼은 BASE 접근에 적합하다. 일부 서버에 장애가 생겨도 서비스는 계속 이용할 수 있고, 좋아요 수나 댓글 수는 잠시 정확하지 않을 수 있다. 시간이 지나면 모든 사용자가 동일한 좋아요 수와 댓글을 보게 된다.

데이터 성격에 따라 함께 적용하는 방식

한 애플리케이션 안에서도 모든 데이터를 같은 방식으로 처리할 필요는 없다. 중요한 금융 거래는 ACID를 준수하는 데이터베이스에 저장하고, 사용자 활동 로그와 분석 데이터는 BASE 방식의 데이터베이스에 저장할 수 있다. Command Query Responsibility Segregation(CQRS) 패턴에서는 쓰기 작업에 ACID를, 읽기 작업에 BASE를 적용한다.

⤢✕

데이터 일관성의 중요도, 서비스 가용성 요구사항, 확장성 필요성, 비즈니스 도메인 특성, 장애 복구 요구사항을 함께 검토해야 한다. ACID와 BASE는 어느 한쪽이 다른 쪽을 대체하는 관계가 아니라, 서로 다른 우선순위를 다루는 보완적 패러다임이다.