비교 포인트

같은 데이터를 다뤄도 장애 순간에 지키는 약속은 다릅니다

두 모델 모두 신뢰할 수 있는 저장을 목표로 하지만, 정확한 현재 상태를 먼저 고정할지, 서비스 지속과 확장을 먼저 확보할지가 갈립니다.

한 줄 이해
ACID는 지금 즉시 맞는 상태를, BASE는 지금 계속 동작하고 나중에 맞춰지는 상태를 더 중시합니다.
트랜잭션 중심
ACID

RDB에서 자주 쓰이는 모델. 트랜잭션 종료 시점의 일관된 상태를 강하게 지킵니다.

분산 가용성 중심
BASE

NoSQL에서 자주 쓰이는 모델. 노드가 많고 일부가 늦어도 시스템이 계속 응답하도록 설계합니다.

무엇을 먼저 지키나
트랜잭션이 끝나면 모순 없는 상태가 바로 확정

원자성, 제약조건, 롤백으로 잘못된 중간 상태를 숨기고 같은 규칙을 강하게 유지합니다.

항상 응답 가능한 상태를 유지하고 나중에 수렴

지금 당장 모든 복제본이 같지 않아도 괜찮다고 보고, 이후 동기화로 같은 값에 가까워지게 만듭니다.

장애나 분산 지연이 생기면
대기·실패를 감수하더라도 충돌을 먼저 막음

합의가 안 되면 잠시 멈추거나 롤백해서 잘못된 커밋이 퍼지는 일을 줄입니다.

일부 노드가 늦어도 우선 서비스는 계속 열어 둠

복제 지연이나 일시적 불일치를 허용해도 쓰기와 읽기를 가능한 한 계속 받습니다.

사용자가 읽을 때 느끼는 점
방금 커밋한 값이 바로 반영되기를 기대

계좌 잔액, 주문 수량처럼 지금 틀리면 곧바로 문제가 되는 작업에 적합합니다.

잠깐 오래된 값을 보더라도 곧 최신 상태로 맞춰짐

피드, 좋아요 수, 캐시처럼 짧은 지연을 허용할 수 있는 읽기 경험에 잘 맞습니다.

왜 이런 선택을 하나
정확한 상태 전이가 핵심인 업무를 위해

여러 변경이 하나의 논리 작업으로 묶여야 하고, 실패 시 전체를 되돌리는 능력이 중요합니다.

큰 규모에서도 응답성과 확장성을 유지하기 위해

전 세계 분산 노드, 높은 쓰기량, 부분 장애 상황에서도 시스템이 계속 동작하는 쪽을 우선합니다.