535. NoSQL의 BASE 특성 (Soft State와 상태 전이)
⚠️ 이 문서는 RDBMS의 엄격한 ACID(440번 문서) 원칙을 버리고, **"데이터가 0.1초 정도 틀리는 건 괜찮으니까, 일단 서버가 절대 죽지 않고 1억 명의 접속자를 모두 받아내는 게 최고야!"라는 분산 NoSQL 데이터베이스의 느슨한 철학인 'BASE'**를 다룹니다.
(※ 464번 문서에서 BASE의 기본 개념을 다루었으며, 이 문서는 Soft State와 상태 전이 관점의 심화 내용을 다룹니다.)
핵심 인사이트 (3줄 요약)
- 본질: 분산 시스템에서 데이터 일관성(Consistency)을 약간 양보하는 대신 가용성(Availability)과 성능을 극대화하려는 타협적인 데이터 관리 철학이다.
- Soft State (소프트 상태): 내 통장 잔고가 '100원'이라고 DB에 적혀있어도, 그게 100% 진짜라고 장담할 수 없는 쫀득쫀득하고 불확실한 상태를 말한다.
- Eventual Consistency: 100원이 아닐 수도 있지만, 시스템이 백그라운드에서 열심히 복제와 동기화를 돌리다 보면 **'결국(Eventual) 어느 순간에는 진짜 정답(일관성)에 도달한다'**는 낙관적인 믿음이다.
Ⅰ. 개요: 꽉 막힌 은행과 쿨한 SNS (Context & Necessity)
- 은행 (ACID): 내 통장에서 돈이 빠져나가는 순간, 전 세계의 모든 은행 서버가 "이 사람 돈 빠졌음!"이라고 100% 동의할 때까지 내 스마트폰은 무한 로딩(Lock)에 걸린다. (깐깐하지만 안전함)
- 인스타그램 (BASE): 내가 유재석의 사진에 '좋아요'를 누른다. 한국 서버는 1개가 올라가서 10,001개가 된다. 하지만 미국 서버에 있는 유재석의 스마트폰에는 아직 동기화가 안 돼서 10,000개로 보인다.
인스타그램은 에러를 내지 않는다. "유재석이 10,000개로 좀 보면 어때? 1초 뒤에 동기화되면 그때 10,001개로 뿅 하고 보여주면 되지! 멈추지 마!"
이것이 바로 분산 NoSQL(Cassandra, DynamoDB 등)이 선택한 생존 방식인 **BASE (Basically Available, Soft state, Eventual consistency)**다.
📢 섹션 요약 비유: ACID가 **'생방송 라이브'**라면, BASE는 **'녹화 방송'**과 같습니다. 라이브는 무조건 지금 일어나고 있는 완벽한 현실(일관성)을 봐야 하지만 방송 사고의 위험이 크죠. 녹화 방송은 현실과 1시간 정도 차이가 날 수 있지만(소프트 상태), 사고 없이 무조건 방송이 송출된다(가용성)는 엄청난 안정성이 있습니다.
Ⅱ. BASE의 3대 철학 분석 ★
1. Basically Available (기본적인 가용성)
- "어떤 일이 있어도 시스템은 죽지 않고 대답해야 한다."
- 미국 서버가 벼락에 맞아 죽었다? 옆에 있는 멕시코 서버가 대신 대답한다. 비록 멕시코 서버가 가진 데이터가 1시간 전의 옛날 데이터일지라도, 사용자에게 '500 Error(서버 터짐)'를 보여주는 것보다는 낫기 때문이다.
2. Soft State (소프트 상태 - 유연한 상태 전이)
- "데이터는 사용자가 건드리지 않아도 자기 혼자 바뀔 수 있다."
- 아까 인스타그램 미국 서버에서 '좋아요'가 10,000개였다. 유재석은 아무것도 안 하고 10초 뒤에 새로고침만 눌렀는데 갑자기 10,001개로 바뀌었다.
- 이것은 노드들끼리 뒤에서 몰래 통신(Gossip Protocol - 495번 문서)하며 데이터를 동기화했기 때문이다. 상태가 고정(Hard)되어 있지 않고 물렁물렁하게(Soft) 변할 수 있다는 뜻이다.
3. Eventual Consistency (결과적 일관성) ★
- "지금 당장은 한국과 미국 서버의 데이터가 달라도, 우주가 멸망하기 전에는 언젠가(Eventual) 똑같아질 것이다!"
- 이 느슨한 믿음 덕분에 개발자들은 복잡한 분산 트랜잭션 락(2PC - 462번 문서)을 버리고 엄청난 성능을 뽑아낼 수 있었다.
Ⅲ. 실무의 딜레마: 그래서 언제 똑같아지는데?
개발자 입장에서 Eventual Consistency는 무서운 폭탄이다. "저기요... 언젠가(Eventual) 일치한다는 건 알겠는데, 그게 0.1초 뒤입니까, 10분 뒤입니까?"
- 문제 발생: 회원 가입(
INSERT)을 하고, 바로 다음 줄 코드에서 회원 정보 조회(SELECT)를 날렸다. 근데 0.1초의 동기화 시간을 못 기다리고 조회가 먼저 돌아가서[없는 회원입니다]에러가 터진다! - 해결책 (Tunable Consistency):
- 쿨하게 넘어가도 되는 로직(조회수, 좋아요 수)은 그냥 둔다.
- 방금 쓴 글을 바로 읽어야 하는 핵심 로직(회원가입, 결제)에서는 **"내가 방금 쓴 데이터는 나한테 무조건 최신으로 보여줘 (Read-your-writes)"**라는 일관성 보정 쿼럼(Quorum - 496번 문서) 옵션을 걸어서 강제로 동기화를 확인하고 넘어가야 한다.
┌──────────────────────────────────────────────────────────────┐
│ Soft State와 Eventual Consistency의 상태 전이 시각화 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 시간 │ 🇰🇷 한국 노드 (원본) │ 🇺🇸 미국 노드 (복제본) │
│ ───┼─────────────────────────┼─────────────────────────│
│ T1 │ UPDATE 잔고 = 100원 │ 잔고 = 0원 (과거 데이터) │
│ T2 │ (동기화 메시지 발송 중...) 🌊 │ 조회! ──▶ "0원입니다!" 💥(불일치) │
│ T3 │ │ (여전히 0원 - Soft State 진행 중)│
│ T4 │ │ 📥 메시지 도착! 업데이트 완료. │
│ T5 │ │ 조회! ──▶ "100원입니다!" 🟢 │
│ │
│ ★ 특징: 사용자가 아무 행동을 하지 않았음에도, T2와 T5의 조회 결과가 다르다. │
│ (데이터베이스가 뒤에서 몰래 상태를 바꿈 = Soft State) │
└──────────────────────────────────────────────────────────────┘
Ⅳ. 결론
"완벽을 버려야, 무한을 얻을 수 있다." BASE 철학은 관계형 데이터베이스(RDB)가 신줏단지처럼 모시던 ACID 이론의 정반대 대척점에 서 있는 반역자다. 하지만 구글, 페이스북, 아마존 등 1초에 수천만 건의 트래픽을 감당해야 하는 거인들은 결국 이 반역자의 편에 섰다. 시스템이 무너져 내리는 완벽함(ACID)보다는, 살짝 어긋나더라도 절대 멈추지 않는 생존력(BASE)이 비즈니스에서 훨씬 더 큰 가치를 창출한다는 것을 깨달았기 때문이다. 분산 시스템 아키텍트는 이 '결과적 일관성'이 주는 0.1초의 모호함을 애플리케이션(UI/UX) 단에서 어떻게 부드럽게 감출 것인지를 가장 치열하게 고민해야 한다.
📌 관련 개념 맵
- 관련 이론: CAP 정리 (463번 문서 - BASE는 보통 AP 시스템의 특징임)
- 대척점 이론: ACID (원자성, 일관성, 고립성, 영속성 - 440번 문서)
- 상태 전이 기술: Gossip Protocol (495번 문서 - 노드 간 상태를 몰래 전파하는 기술)
- 일관성 조율 기술: Quorum (다수결 합의 - 496번 문서)
👶 어린이를 위한 3줄 비유 설명
- ACID는 친구 5명이 다 같이 모여서 완벽하게 합의가 끝나야만 정답을 말하는 깐깐하고 느린 모범생이에요.
- BASE의 Soft State는, 내가 가만히 있어도 내 짝꿍이 갑자기 내 시험지 답안을 쓱 지우고 맞는 정답으로 고쳐놓고 가는(상태가 변함) 마법 같은 상황이에요.
- Eventual Consistency는 지금 당장 5명의 답이 다 달라도, 종 치기 1초 전에는(결국엔) 짝꿍들이 다 베껴 적어서 5명 모두 똑같은 정답을 내게 될 거라는 쿨한 믿음이랍니다!