496. Quorum (정족수) 읽기/쓰기 일관성 보정

⚠️ 이 문서는 "서버 3대에 데이터를 복사해서 저장할 건데, 몇 대의 서버가 저장에 성공했다고 대답해야 진짜로 성공(Commit)했다고 쳐줄까?"라는 분산 시스템의 철학적인 고민을, 다수결의 원칙을 도입하여 성능과 일관성을 조율하는 'Quorum(정족수)' 알고리즘을 다룹니다.

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

본질: 분산 DB(Cassandra, DynamoDB)에서 데이터를 읽거나 쓸 때, "최소한 몇 대의 노드(서버)가 참여해야 유효한 작업으로 인정할 것인가"를 결정하는 투표 규칙이다.

Quorum 공식: W(쓰기 참여 수) + R(읽기 참여 수) > N(총 복제본 수) 공식을 만족하면, 읽을 때 무조건 가장 최신(방금 쓴) 데이터를 읽어올 수 있음이 수학적으로 보장된다 (강한 일관성).

가치: 개발자가 비즈니스 성격에 맞춰 "속도가 중요해!(W=1)" 혹은 "정확성이 중요해!(W=Quorum)"라고 일관성의 수준(Tunable Consistency)을 자유자재로 설정할 수 있게 해준다.

Ⅰ. 개요: 3명의 서기 (Context & Necessity)

내 데이터를 A, B, C 서버 3대에 복사(Replication - 461번 문서)해서 저장하려고 한다. ($N=3$)

강한 동기화 (W=3): 3대가 모두 "저장 완료!"라고 대답할 때까지 기다린다. 엄청 안전하지만, 1대가 고장 나면 아예 저장을 못 하고 멈춘다. (너무 느림)
약한 동기화 (W=1): 1대만 "저장 완료!"라고 대답하면 그냥 성공으로 치고 집에 간다. 속도는 짱 빠르지만, 그 1대가 1초 뒤에 벼락을 맞으면 방금 저장한 내 데이터가 영영 사라진다. (너무 위험함)

가운데서 완벽한 타협점을 찾는 것이 Quorum (다수결/정족수) 방식이다. "3대 중에서 과반수인 **2대(W=2)**만 성공했다고 대답하면 성공으로 쳐주자! 그럼 1대가 고장 나도 시스템이 멈추지 않으면서(가용성), 데이터도 2군데나 있으니 꽤 안전하잖아!"

📢 섹션 요약 비유: Quorum은 **'국회의 법안 통과'**와 같습니다. 국회의원 300명 전원이 찬성할 때까지 기다리는 건 불가능하고(W=All), 1명만 찬성한다고 통과시키면 나라가 망하죠(W=1). 그래서 "과반수(151명)가 찬성하면 통과된 걸로 치자!"라는 가장 합리적인 다수결의 원칙(Quorum)을 쓰는 것입니다.

Ⅱ. Quorum의 수학적 공식: W + R > N ★

데이터가 3대($N=3$)에 복제되어 있을 때, 항상 '최신 데이터'를 읽어오기 위한 마법의 공식이다.

1. 공식을 만족하는 경우 (강한 일관성)

$N = 3$ (총 서버 3대)
$W = 2$ (쓰기할 때 최소 2대의 성공을 요구함)
$R = 2$ (읽기할 때 최소 2대에게 물어봐서 확인받음)
$W(2) + R(2) = 4 > N(3)$ (공식 만족!)

원리: 내가 2대한테 물어보면(R=2), 그중 무조건 1대는 방금 글을 쓴 2대(W=2)와 무조건 교집합으로 겹치게 되어 있다. 따라서 "야! 내 데이터(버전 2)가 네 데이터(버전 1)보다 더 최신이야!"라고 교정(Read Repair)해 줄 수 있어서 완벽한 최신 데이터를 얻는다.

2. 공식을 못 지키는 경우 (결과적 일관성)

$N = 3$, $W = 1$, $R = 1$
$W(1) + R(1) = 2 < N(3)$ (공식 실패!)

원리: 내가 1대에 썼는데(A서버), 1초 뒤 내 친구가 와서 다른 1대(B서버)를 읽어버리면? A와 B가 안 겹치니까 친구는 내가 쓴 최신 글을 못 보고 옛날 글을 보게 된다. (하지만 0.01초의 속도 쾌감을 얻는다.)

Ⅲ. 실무 팁: Tunable Consistency (조절 가능한 일관성)

Cassandra나 DynamoDB 개발자는 쿼리를 짤 때마다 이 Quorum 수치를 조절할 수 있다.

QUORUM 모드 (실무 90%):
- W=Quorum, R=Quorum
- 속도와 안전성의 황금 밸런스. 과반수만 확인한다. 일반적인 웹 서비스에 쓴다.
ONE 모드 (속도 올인):
- W=1, R=1
- IoT 센서 데이터나 로그 수집처럼 1초에 100만 건씩 쏟아져서 1개쯤 유실되거나 옛날 거 봐도 아무 상관 없는 곳에 쓴다.
ALL 모드 (안전 올인):
- W=All, R=All
- 은행 결제 시스템처럼 단 1원의 오차도 용납할 수 없을 때 쓴다. (속도 포기)

┌──────────────────────────────────────────────────────────────┐
│           Quorum 방식의 읽기 일관성 보정 (Read Repair) 시각화           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 조건: N=3, W=2, R=2 ]                                        │
│                                                              │
│ 1️⃣ 쓰기 (W=2)                                                 │
│    (서버 1) ──▶ V2 (최신 저장 완료!)                             │
│    (서버 2) ──▶ V2 (최신 저장 완료!)                             │
│    (서버 3) ──▶ V1 (네트워크 렉 걸려서 아직 옛날 값임)               │
│                                                              │
│ 2️⃣ 읽기 (R=2)                                                 │
│    사용자 ──▶ (서버 2)와 (서버 3)을 찔러서 값을 읽어옴.               │
│    DB 엔진 ──▶ "어라? 2번은 V2인데, 3번은 V1이네? 2번이 더 최신이다!" │
│                                                              │
│ 3️⃣ 읽기 수선 (Read Repair)                                     │
│    사용자에게 V2 값을 주면서, 동시에 (서버 3)에게 몰래                  │
│    "너 옛날 값이야! V2로 업데이트해!" 라고 알려줘서 고쳐놓음. (보정 완료) │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"분산 시스템에서 만장일치는 환상이요, 다수결은 과학이다." Quorum 알고리즘은 분산 데이터베이스가 CAP 이론(463번 문서)의 가용성(A)과 일관성(C) 사이에서 자유롭게 춤을 출 수 있게 만들어준 위대한 조이스틱이다. 개발자는 비즈니스 로직에 따라 어떤 테이블은 W=1로 날려 보내고, 어떤 테이블은 W=QUORUM으로 신중하게 다루며 성능을 극한으로 최적화할 수 있다. 이 개념을 모른 채 NoSQL을 도입하는 것은, 브레이크와 엑셀의 역할을 모른 채 스포츠카를 모는 것과 같은 무모한 짓이다.

📌 관련 개념 맵

관련 시스템: Apache Cassandra, Amazon DynamoDB
상위 이론: CAP 이론 (463번 문서), Eventual Consistency (결과적 일관성 - 464번 문서)
보정 기술: Read Repair (읽는 순간 옛날 데이터를 최신으로 몰래 고쳐주는 기술)
합의 알고리즘: Paxos, Raft (쿼럼의 다수결 철학을 기반으로 함)

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

3명의 친구가 비밀번호를 외우기로 했어요. (N=3)
내가 비밀번호를 바꿀 때 최소 2명(W=2)에게 알려주고, 나중에 비밀번호를 확인할 때도 2명(R=2)한테 물어봐야 하는 게 Quorum 규칙이에요.
2명씩 뽑아서 물어보면 무조건 '비밀번호를 바꾼 1명'이 겹치게 되니까, 1명이 까먹거나 결석해도 항상 정확한 새 비밀번호를 알아낼 수 있는 똑똑한 다수결 방법이랍니다!