포크 순차 일관성은 차단된다

**1. 서론** 클라우드 기반 협업 서비스에서는 클라이언트가 직접 서로 통신하지 않고, 중앙 서버를 통해 공유 데이터를 읽고 쓸 수 있다. 서버가 정직하면 클라이언트는 높은 가용성을 기대한다. 특히, 편집 작업이 지연 없이 진행되길 원하기 때문에 **무대기성(wait‑freedom)** 이 필수적이다. 동시에, 여러 클라이언트가 동시에 읽고 쓰는 상황에서도 일관된 데이터 뷰를 제공해야 하며, 이를 위해 **순차 일관성(sequential consistency)** 을 목표로 한다. 그러나 서버가 비잔틴 행동을 할 경우, 강한 일관성 보장은 불가능하고 대신 **포크 일관성(fork consistency)** 계열을 사용한다. 포크 일관성은 서버가 두 클라이언트에게 서로 다른 히스토리를 보여주더라도, 한 번이라도 히스토리가 갈라지면 이후에는 서로의 업데이트를 다시 보지 못하도록 보장한다. 기존 연구는 **fork‑linearizability** 가 무대기성을 지원하지 못한다는 부정 결과를 제시했으며, 더 약한 **fork‑sequential consistency** 가 가능할지에 대한 의문이 남아 있었다. **2. 시스템 모델 및 정의** - **구성 요소**: n명의 클라이언트 C₁…Cₙ, 하나의 서버 S, 비동기 FIFO 신뢰 채널. 클라이언트 간 직접 통신은 금지된다. - **오류 모델**: 클라이언트는 크래시만 허용하고, 서버는 비잔틴(임의 행동) 가능. - **객체**: 단일 작성자·다중 독자(SWMR) 레지스터 X₁, X₂,…, 각 레지스터에 쓰여지는 값은 고유하도록 설계한다. - **연산**: readᵢ(X) → v, writeᵢ(X, v) → OK. - **순차 일관성**(Def 1): 실행 히스토리를 완전한 연산들의 순열 π 로 재배열하되, 각 클라이언트 내부의 실시간 순서는 보존하고, 레지스터의 순차 사양을 만족해야 함. - **무대기성**(Def 2): 올바른 클라이언트가 수행한 모든 연산이 반드시 완료된다. - **포크 순차 일관성**(Def 3): 각 클라이언트 Cᵢ마다 자신만의 뷰 πᵢ가 존재한다. 모든 뷰는 실시간 순서를 보존하고, 레지스터 사양을 만족한다. 핵심은 **no‑join** 속성으로, 두 클라이언트가 동일 연산 o 를 포함한다면 그 연산 이전의 순서는 두 뷰에서 동일해야 한다. **3. 목표 정의** ‘wait‑free fork‑sequentially‑consistent Byzantine emulation’(Def 4)은 두 조건을 요구한다. (1) 서버가 정상이면 모든 실행이 순차 일관성을 유지하고 무대기성을 보장한다. (2) 서버가 비정상이더라도 모든 실행이 포크 순차 일관성을 만족한다. **4. 불가능성 정리** **Theorem 1**: n ≥ 2인 경우, 위 정의를 만족하는 프로토콜은 존재하지 않는다. **증명 개요** 세 가지 실행을 구성한다. - **실행 α**: 서버 정상. C₂가 X₂에 연속적으로 v₁, v₂,…를 쓰고, 매번 X₁을 읽는다. C₁은 X₁에 값 u 를 쓰지만, 메시지가 지연된다. C₂는 계속 ⊥ 를 읽다가 어느 시점에 X₁에서 u 를 읽는다(첫 번째 비⊥ 읽기 r_z²). 이 시점까지 C₂는 w₁, w₂,…, w_{z‑1}₂ 를 수행했다. - **실행 β**: α와 동일하게 진행되지만, r_z‑2² 이후 C₂가 중단한다. 이후 C₁은 X₂를 반복 읽어 v_{z‑2} 를 얻는다. 서버는 정상이며, 무대기성에 의해 모든 연산이 완료된다. - **실행 γ**: 서버가 비정상. 서버는 C₁에게는 β와 동일하게, C₂에게는 α와 동일하게 동작한다. 즉, C₁은 w₁ 이후에 X₂에서 v_{z‑2} 를 읽고, C₂는 X₁에서 u 를 읽는다. γ는 각 클라이언트에게는 각각 일관된 히스토리(π₁, π₂)를 제공하지만, **no‑join** 속성을 위배한다. 구체적으로 π₂에서는 w₁이 r_{z‑1}₂ 뒤, r_z² 앞에 위치해야 한다. 그러면 w₁ 이전에 존재하는 연산은 π₁에서도 동일해야 하는데, 여기에는 w_{z‑1}₂ 와 w_{z‑2}₂ 가 포함된다. 그러나 π₁에서 w_{z‑1}₂ 가 r_l¹ (v_{z‑2} 를 읽는 연산) 앞에 있어야 하는데, 이는 레지스터 X₂의 순차 사양을 깨뜨린다(읽은 값이 아직 쓰여지지 않은 값이 되므로). 따라서 γ는 포크 순차 일관성을 만족하지 못한다. 이 모순은 가정한 프로토콜이 존재한다는 전제와 충돌하므로, 요구 조건을 동시에 만족하는 프로토콜은 불가능함을 증명한다. **5. 결론 및 의의** - 포크‑linearizability가 무대기성을 지원하지 못한다는 기존 결과를 일반화하여, 더 약한 포크‑sequential consistency 역시 같은 한계에 봉착함을 보여준다. - 실시간 협업 시스템에서 “서버가 정상일 때는 무대기성을 보장하고, 비정상일 때는 포크 일관성을 유지한다”는 목표는 근본적으로 불가능하다. - 따라서 설계자는 무대기성을 포기하거나, 추가적인 신뢰 메커니즘(예: 다중 서버, 검증 가능한 로그, 클라이언트 간 직접 검증) 등을 도입해야 한다. **6. 참고문헌** 주요 참고문헌으로는 Lamport의 순차 일관성 논문, Herlihy의 무대기성 연구, 그리고 Cachin 등(2007)의 fork‑linearizability 논문 등이 인용된다.