같은 데이터를 여러 서버에 복제했는데 장애 후 두 서버가 자신을 리더라고 주장합니다. 복제만으로 해결되지 않는 문제는 무엇이며 합의가 필요한 부분은 어디인가요?

복제는 같은 데이터를 여러 서버에 보관하는 방법이고, 합의는 장애와 지연 속에서 어떤 순서와 값을 하나의 결정으로 채택할지 정하는 프로토콜입니다. 복제본이 많다고 서로 다른 두 리더가 만든 변경 중 하나가 자동으로 정답이 되지는 않습니다.

복제만으로 부족한 이유

리더가 변경을 follower에 보내고 응답하기 전에 고립되면, 새 리더가 다른 변경을 받아 두 노드가 모두 성공했다고 보일 수 있습니다. 비동기 복제는 사본을 늘릴 뿐 리더 선출·투표·로그 충돌·확정 불변성을 정의하지 않습니다. Raft와 Paxos는 정해진 장애 모델에서 쿼럼과 논리 세대·로그 규칙으로 한 슬롯에 서로 다른 값을 확정하지 않게 합니다.

합의가 있어도 client 응답 유실 뒤 같은 명령이 재전송되거나 상태 머신이 외부 결제를 호출하는 문제는 남습니다. 요청 ID·inbox·outbox·멱등 키가 별도 경계에서 필요합니다. 일반 Raft는 악의적으로 거짓말하는 Byzantine 장애가 아니라 중단·복구·통신 장애를 다루는 모델입니다.

안전성과 진행성

안전성은 같은 슬롯에 서로 다른 값이 확정되지 않는 성질이고, 진행성은 필요한 통신이 가능할 때 언젠가 결정되는 성질입니다. 쿼럼을 잃었는데 단독 노드로 진행하면 안전성을 훼손하고, 모든 노드 응답을 요구하면 작은 장애에도 진행이 멈춥니다. 합의 로그의 commit과 각 상태 머신 apply도 다르며 외부 DB·알림은 더 바깥 효과입니다.

검증은 리더 장애, 지연 메시지, 동시 선거, client 응답 유실을 주입합니다. 성공 로그 보존, 같은 위치의 단일 확정, 재시도 외부 효과의 중복 여부를 따로 봅니다. 복제의 보관 책임과 합의의 결정 책임을 분리하는 것이 결론입니다.

복제된 상태 머신의 실행

합의로 정한 명령열을 모든 노드가 같은 순서로 적용해 같은 결과를 만드는 구성을 복제 상태 머신이라고 합니다. 명령 처리 중 각 노드가 자기 시각이나 난수를 읽으면 로그가 같아도 결과가 달라질 수 있습니다. 필요한 시각·난수 결과를 명령에 포함하거나 결정적으로 생성하고, 상태 변경과 요청 ID별 결과 기록을 같은 적용 단위로 처리해야 합니다.

예를 들어 로그 10번에 계정 포인트 100 증가가 확정됐지만 응답이 유실됐다고 하겠습니다. 클라이언트가 같은 요청 ID로 다시 보냈을 때 새 로그 위치에 재요청이 실려도 상태 머신이 이전 결과를 찾아 두 번째 증가는 하지 않아야 합니다. 합의는 서로 다른 로그 명령을 한 요청이라고 자동 인식하지 않습니다. 중복 기록을 스냅샷에서 빼거나 너무 빨리 만료시키면 재시작 후 중복 효과가 다시 생깁니다.

진행성은 단순히 과반 프로세스가 존재하는 것만으로 충분하지 않습니다. 메시지가 계속 무한 지연되거나 선거가 계속 충돌하면 결정이 늦어질 수 있습니다. 충분히 안정된 통신·리더 조건과 timeout 정책을 확인합니다. 복제 지연, 합의 커밋 지연, 상태 적용 지연을 나눠 계측해야 저장소 추가가 어느 단계의 비용을 늘리는지도 알 수 있습니다.