464. BASE 속성과 결과적 일관성 (Eventual Consistency)

⚠️ 이 문서는 "내 통장 잔고와 은행 서버의 잔고는 0.001초의 오차도 없이 무조건 똑같아야 한다"는 깐깐한 ACID(440번 문서)의 규칙을 과감히 깨버리고, **"지금 당장은 좀 틀려도 되니까, 나중에 언젠가 맞춰지기만 하면 서버가 절대 안 죽고 엄청 빠르기만 하면 돼!"라는 NoSQL의 자유분방한 철학인 'BASE'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: RDBMS가 지키는 'ACID'의 반대 개념이다. NoSQL(Cassandra, DynamoDB 등)이 대용량 분산 환경에서 살아남기 위해 채택한 느슨한 데이터 정합성 규칙이다.
  2. BASE의 의미: Basically Available(기본적으로 항상 켜져 있음), Soft state(상태가 유연하게 변할 수 있음), Eventual consistency(결국엔 일관성이 맞춰짐)의 약자다.
  3. 가치: 데이터가 100% 맞지 않더라도 서비스가 죽는 것보단 낫다는 철학(AP 시스템)으로, 수억 명의 트래픽을 처리하는 현대 글로벌 웹 서비스의 근간이 되었다.

Ⅰ. 개요: 인스타그램의 좋아요 개수 (Context & Necessity)

내가 인스타그램에서 어떤 게시물에 '좋아요'를 눌렀다.

  • 한국 서버의 '좋아요 개수'는 즉시 100개가 되었다.
  • 0.1초 뒤, 미국에 있는 친구가 내 게시물의 '좋아요 개수'를 봤다.
  • 미국 서버는 아직 데이터를 못 받아서 99개로 보인다.

만약 **ACID(RDBMS)**였다면? 미국 서버가 100개로 업데이트될 때까지 내 스마트폰 화면을 멈춰(Lock) 세우고 로딩 창을 돌렸을 것이다. 하지만 **BASE(NoSQL)**는 쿨하다. "미국 친구가 99개로 좀 보면 어때? 세상이 망하는 것도 아닌데! 그냥 멈추지 말고 빨리빨리 보여줘!"

이처럼 찰나의 순간에 생기는 데이터 불일치를 기꺼이 용인하는 것이 BASE 철학의 핵심이다.

📢 섹션 요약 비유: ACID가 **'모든 사람이 똑같은 숫자를 부를 때까지 절대 문을 안 열어주는 깐깐한 선생님'**이라면, BASE는 **'일단 다 밖으로 내보내고, 틀린 숫자를 부르는 애들은 나중에 뛰어가서 몰래 숫자를 고쳐주는 쿨한 선생님'**입니다.

Ⅱ. BASE의 3가지 핵심 속성 ★

정보처리기사나 시스템 아키텍트 면접에서 단골로 묻는 개념이다.

1. Basically Available (기본적으로 가용함)

  • "어떤 일이 있어도(서버 몇 대가 죽어도) 손님에게 에러 화면(500)을 보여주지 마라."
  • 시스템은 기본적으로 항상 응답해야 한다. 정답이 아니면 옛날 데이터라도, 혹은 "지금은 알 수 없음"이라는 대안(Fallback)이라도 보여줘야 한다.

2. Soft State (소프트 상태)

  • "데이터베이스의 상태는 외부의 개입 없이도 지 혼자 바뀔 수 있다."
  • 아까 인스타그램 미국 서버는 99개였다. 그런데 3초 뒤에 다시 새로고침 하니까 갑자기 100개로 바뀌어 있다!
  • 미국 친구가 좋아요를 누른 적이 없는데도, 백그라운드에서 한국 서버와 동기화가 일어나면서 상태가 부드럽게(Soft) 변한 것이다.

3. Eventual Consistency (결과적 일관성) ★

  • "지금 당장은 한국과 미국의 좋아요 개수가 다를 수 있지만, 결국(Eventual) 어느 순간이 되면 모든 서버의 데이터가 100개로 똑같이 맞춰질 것이다."
  • 분산 시스템의 데이터 동기화 문제를 해결하는 궁극의 타협안이다.

Ⅲ. 실무 팁: Eventual Consistency를 다루는 개발자의 자세

백엔드 개발자가 NoSQL(BASE)을 쓸 때는 ACID 시절의 고정관념을 버려야 한다.

  • 상황: 내가 회원 가입(INSERT)을 하고, 바로 내 정보 조회(SELECT) 쿼리를 날렸다.
  • 결과: [회원 정보가 없습니다] 에러가 뜬다.
  • 이유: 내가 Insert 한 마스터 서버의 데이터가, 내가 Select 한 읽기 전용 슬레이브 서버로 아직 복사(Replication)가 안 되었기 때문이다. (0.5초의 지연)

해결책: "방금 내가 쓴 데이터는 무조건 100% 읽을 수 있게 해줘!"라는 비즈니스 요구사항이 있다면, 데이터베이스 설정에서 Read-Your-Writes 일관성을 켜거나 강력한 Quorum(다수결) 읽기 모드로 옵션을 조작해야 한다. (물론 그만큼 속도는 느려진다.)

┌──────────────────────────────────────────────────────────────┐
│           ACID (RDBMS) vs BASE (NoSQL) 철학 비교 시각화              │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🛡️ ACID (완벽한 일관성) ]                                     │
│  나: "입금 완료(100원)!"                                        │
│  친구: "나 잔액 조회할래" ──▶ (대기 ⏳) ──▶ (대기 ⏳) ──▶ "100원!"  │
│  ★ 특징: 미국 서버에 100원 동기화가 끝날 때까지 친구를 무한정 기다리게 함.     │
│                                                              │
│ [ 🌊 BASE (결과적 일관성) ]                                     │
│  나: "입금 완료(100원)!"                                        │
│  친구: "나 잔액 조회할래" ──▶ "0원!" (일단 옛날 데이터라도 1초 만에 줌)    │
│            ... (3초 뒤) ...                                    │
│  친구: "다시 조회할래"   ──▶ "100원!" (결국엔 맞춰짐 - Eventual)      │
│  ★ 특징: 거짓말을 할지언정, 절대 손님을 기다리게 하지는 않는다!              │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"은행은 ACID로 짓고, SNS는 BASE로 지어라." BASE는 데이터베이스 역사상 가장 과감한 타협이다. 완벽한 일관성(Consistency)이라는 무거운 족쇄를 풀어 던진 덕분에, 아마존 DynamoDB나 카산드라(Cassandra) 같은 NoSQL들은 전 세계 트래픽을 무한대로 처리할 수 있는 날개를 달게 되었다. 아키텍트는 비즈니스의 성격을 분석하여, "결제가 꼬이는 0.01%의 확률을 감수하더라도 서버가 절대 죽지 않는 것(BASE)"이 중요한지, 아니면 "서버가 멈추는 한이 있어도 단 1원의 오차도 허용할 수 없는지(ACID)"를 결정하고 올바른 DB를 선택해야 한다.

📌 관련 개념 맵

  • 대척점 이론: ACID (원자성, 일관성, 고립성, 영속성 - 440번 문서)
  • 상위 이론: CAP 정리 (463번 문서 - BASE는 보통 AP 시스템을 선택한 결과물임)
  • 관련 데이터베이스: Cassandra, DynamoDB, MongoDB, CouchDB
  • 관련 장애 복구: Hinted Handoff, Anti-Entropy (376번 문서 - Eventual Consistency를 맞추는 실제 복구 기술)

👶 어린이를 위한 3줄 비유 설명

  1. ACID는 친구들 5명이 다 같이 모여서 "정답은 3번!"이라고 완벽하게 합의가 끝나야만 선생님께 대답하는 아주 모범적이지만 느린 조별 과제예요.
  2. BASE는 일단 목소리 큰 1명이 "3번!"이라고 빨리 대답해 버리고, 혹시 틀렸으면 나중에 "아, 사실 4번이었어요!" 하고 뻔뻔하게 고치는 쿨한 조별 과제예요.
  3. 선생님이 정답을 늦게 받아서 화내는 것보다, 일단 빨리 아무 대답이라도 듣고 싶어 하실 때 쓰는 아주 빠르고 효율적인 방법이랍니다!