6차를 건너뛴 7차스터디 - 선형성,인과성,브로드캐스팅,합의

김태훈·2026년 3월 28일

6차 스터디는 진행했지만.. 건너뛰어버렸음.. 여러모로 바쁜 나날이라.. 하지만 이 또한 핑계지..

이번 주제는 일관성과 합의 의 관련된 주제였다.
여태까지 스터디했던 주제중에 가장 어렵고 난해했던 주제였다.

선형성

선형성이란? 무조건 최신성을 보장하는 것이다.
마치 단일 노드 데이터베이스처럼 동작하는 것이다.
클러스터 환경에서 모든 노드들이 단일 노드처럼 움직이게 하려면, 쓰기가 받아 들여졌다는 "확신"이 있어야 한다.
어떤 쓰기가 성공했다고 관측된 이후의 모든 읽기는 그 결과를 반드시 반영해야 한다.
그렇기 때문에, 네트워크 지연에 매우매우 큰 영향을 받는다.
그러니 당연히 성능이 저하될 수 밖에..

인과성

그래서 나온 것이 인과성의 개념이다.
원인과 결과의 흐름을 보장하자! 라는 컨셉이다.
즉, 모든 흐름에 대해 선형성을 보장할 필요없이, 일부에 해당하는 트랜잭션들만 인과성이 보장되게끔 하는것이다.
근데 자꾸 단일 리더 기반의 아키텍쳐라고 생각해서였는지 이해하기 정말 어려웠다.
전체 순서가 아닌 그 부분집합의 인과성을 어떻게 보장하는 것일까?
이와 관련되어서 여러 방법이 있다.

일련번호
램포트 타임스탬프
vector clock (이게 제일 좋아보인다)

(일련번호 방식)
각 노드의 로컬 시퀀스 번호만으로는 다른 노드의 이벤트와의 인과관계를 표현할 수 없다

(타임스탬프)
타임스탬프만으로 모든것을 해결할 수 있나?
무조건 A 이후에 B가 일어나면 T(A) < T(B)임을 보장하지만, 역은 보장하지 않는다.
왜냐하면? 타임스탬프로 인해서 인과성이 없는 관계라도 인과성이 있는것 처럼 보이기 때문이다.

정리하면, 아래와 같은 단점들이 있다.

동시성과 인과관계를 구분 못한다
실제로는 독립적인 이벤트도 강제로 순서화한다
타임스탬프 순서만 보고 인과관계를 역으로 알 수 없다
충돌 감지나 버전 병합에 부족하다
모든 노드가 같은 순서로 적용하게 만드는 보장은 없다 (노드 전파에 네트워크 이슈가생기면?)

(vector clock)
각 연산을 벡터화한다.
벡터 클락은 “내가 무엇을 보고 왔는지”를 더 풍부하게 들고 다닌다.
클라이언트가 A를 읽고 B를 읽고 C에 쓰기를 할 때
“나는 A의 몇 번째 버전, B의 몇 번째 버전을 보고 왔다”는 메타데이터를 같이 보낸다.
그러면 C는 그 맥락을 알고 인과적인 순서를 판단할 수 있다.

전체순서 브로드캐스트

앞서 살펴본 인과성은 문제가 있다.
"동시에 발생한 충돌하는 쓰기" 가 대표적인 문제 상황이다.

전체순서 브로드캐스트는 모든 노드가 같은 순서로 이벤트를 받게 만들어 충돌 상황에서도 동일한 결정을 하게 한다.
이 때 그 순서를 결정하는 주체가 있다.
보통의 단일 리더 아키텍쳐에서는 그 역할을 리더 노드가 하게 될 것이고, zookeper나 etcd가 해당 역할을 담당한다.
이 때, 해당 순서로 결정을 하기 위해, 다른 노드에게 브로드캐스팅으로 나의 결정에 동의하겠니? 라고 물어보고, 참여자들은 Ack를 날린다. (이때의 합의는 단순 결정에 대한 동의 측면이다.)
이 것이 합의 이다.

2PC

2PC는 합의가 필요해지는 이유이다.
2PC의 가장 큰 단점은 coordinator 의 장애, 커밋하려고 했는데, 참여자가 죽으면 무한정 대기 되어야하는 큰 병목이다.
이를 과반수와 같은 합의 정책으로 우회할 수 있다.

곁들여

MongoDB에서 multi-document transaction에 대한 2PC 성격의 분산 커밋 조율은 특히 샤딩 환경에서 여러 샤드에 걸친 트랜잭션일 때 중요하다.
비샤딩 환경에서는 2PC는 필요 없지만, multi-document transaction 자체는 여전히 의미가 있으며 commit/abort를 관리하는 내부 메커니즘도 필요하다. 이러한 Transactino도 MongoDB자체에서 기본적으로 제공해주기도 하고.