게임 채팅 메시지 수정·삭제 순서 뒤바뀜 해결: 버전 번호 기반 이벤트 정렬

실시간 멀티플레이 게임에서 채팅 시스템을 구현할 때, 단순히 메시지를 보내고 브로드캐스팅하는 것까지는 비교적 수월합니다. 하지만 메시지 수정(Edit)과 삭제(Delete) 기능이 추가되는 순간 예상치 못한 동기화 문제가 터져 나오기 시작합니다.

가장 대표적인 현상이 바로 ‘삭제된 메시지의 부활’입니다. 한 유저가 채팅을 친 뒤 오타를 고치고(수정) 마음이 바뀌어 곧바로 지웠는데(삭제), 다른 유저의 화면에는 메시지가 삭제되었다가 1~2초 뒤에 수정된 메시지가 불쑥 다시 나타나는 이른바 ‘좀비 메시지’ 현상입니다.

이 글에서는 분산 서버와 불안정한 네트워크 환경에서 왜 이런 순서 역전이 일어나는지 살펴보고 단조 증가 버전 번호(Monotonic Version Number)와 조건부 갱신(Conditional Update)을 활용해 이벤트 순서 뒤바뀜을 깔끔하게 해결하는 실무 패턴을 정리합니다.

---

1. 이벤트 순서 역전은 왜 일어나는가?

문제의 핵심은 “서버가 이벤트를 발생시킨 순서”와 “클라이언트가 이벤트를 전달받는 순서”가 결코 같지 않다는 점입니다.

sequenceDiagram
    autonumber
    actor Alice as 발신자 (Alice)
    participant S as 게임 서버
    actor Bob as 수신자 (Bob)

    Alice->>S: 1. 메시지 수정 요청
    Alice->>S: 2. 메시지 삭제 요청
    Note over S: 서버 처리 순서: 수정(v2) → 삭제(v3)
    S-->>Bob: 삭제 이벤트(v3) 먼저 도착!
    Note over Bob: 화면에서 메시지 삭제 처리
    S-->>Bob: 수정 이벤트(v2) 뒤늦게 도착!
    Note over Bob: 💥 삭제된 메시지가 수정 내용으로 되살아남!

이러한 패킷 지연과 순서 역전은 다음과 같은 실무 환경에서 빈번하게 발생합니다.

• 분산 서버 및 다중 게이트웨이: 유저들이 서로 다른 게이트웨이 서버나 WebSocket 워커에 연결되어 있을 때, 메시지 브로커(Redis Pub/Sub, Kafka, RabbitMQ 등)의 파티션 처리 속도나 라우팅 경로에 따라 패킷 도착 순서가 달라집니다.
• 모바일 네트워크의 불안정성: Wi-Fi에서 LTE/5G로 핸드오버되거나 지하철 등 음영 지역을 지날 때 패킷이 일시적으로 버퍼링되었다가 한꺼번에 몰려 들어옵니다.
• 재시도(Retry) 및 재접속(Reconnection): 네트워크 단절 후 클라이언트가 누락된 이벤트를 다시 받아오는 과정에서 최신 이벤트가 먼저 전달되고 과거 이벤트가 뒤따라올 수 있습니다.

실제 서버 처리 순서	클라이언트 도착 순서	단순 수신 시 최종 클라이언트 상태	정상 상태
수정 → 삭제	삭제 → 수정	💥 삭제된 메시지가 다시 화면에 노출됨	삭제됨
수정 → 삭제	수정 → 삭제	정상적으로 삭제됨	삭제됨
삭제 → 수정	수정 → 삭제	정상적으로 삭제 상태 유지	삭제됨

따라서 클라이언트가 단순히 “방금 도착한 이벤트”를 그대로 상태에 반영하거나 이벤트 도착 시각(receivedAt)만으로 최신 여부를 가늠해서는 결코 데이터 정합성을 지킬 수 없습니다.

---

2. 해결책: 버전 번호(Logical Version) 기반의 단조 상태 제어

이 문제를 해결하는 가장 확실한 방법은 물리적인 네트워크 도착 순서에 의존하지 않고 메시지 상태 자체에 인과적 순서를 나타내는 논리적 버전 번호(version)를 부여하는 것입니다.

동작 원리

1. 메시지가 처음 생성될 때 버전 1을 갖습니다.
2. 해당 메시지의 내용이 수정되거나 삭제될 때마다 서버에서 버전을 1씩 원자적으로 증가시킵니다.
3. 클라이언트는 자신이 들고 있는 메시지의 현재 버전보다 더 높은 버전의 이벤트만 반영하고 같거나 낮은 버전은 조용히 무시(Drop)합니다.

flowchart TD
    A[이벤트 수신: incomingEvent] --> B{로컬에 해당 메시지가 있는가?}
    B -- 없음 (신규 생성) --> C[메시지 저장 및 version 기록]
    B -- 있음 --> D{incomingEvent.version > localMessage.version}
    D -- 예 (최신 이벤트) --> E[로컬 상태 갱신 및 version 최신화]
    D -- 아니오 (과거/중복 이벤트) --> F[이벤트 무시 및 버림 Drop]

이 규칙을 적용하면 이벤트 도착 순서가 어떻게 뒤바뀌더라도 최종 상태가 항상 올바르게 수렴합니다.

시점	수신 이벤트	이벤트 버전	클라이언트 현재 버전	판정 및 동작	최종 결과
T1	delete	v3	v1	$3 > 1 \rightarrow$ 반영 (메시지 삭제 및 로컬 버전=3)	삭제됨
T2	edit	v2	v3	$2 \le 3 \rightarrow$ 무시 (오래된 수정 이벤트 폐기)	삭제 상태 유지 ✅

---

3. 헷갈리기 쉬운 개념: 메시지 버전 vs 전역 시퀀스 번호

채팅 아키텍처를 설계할 때 종종 messageVersion과 채널/서버 단위의 serverSequence를 혼동하곤 합니다. 두 값은 해결하려는 목적이 완전히 다릅니다.

구분	관리 범위	증가 기준	주요 용도
messageVersion	특정 메시지 1건	해당 메시지의 수정/삭제 발생 시마다 +1	메시지 개별 엔티티의 최신 상태 판정 (순서 역전 방지)
channelSequence	채널 전체 스트림	채널 내 어떤 이벤트든 발생할 때마다 +1	재접속 시 패킷 누락 감지, 이벤트 재생(Replay)
eventId	이벤트 1건	UUID 또는 고유 ID	네트워크 중복 전달 시 멱등성(Idempotency) 보장

채널 전체 시퀀스(channelSequence)가 더 크다고 해서 특정 메시지의 최신 상태를 보장하지는 않습니다. 채널 내에 수많은 유저의 다른 메시지 이벤트들이 섞여 들어오기 때문입니다.

따라서 개별 메시지의 상태를 갱신할 때는 반드시 messageVersion을 기준으로 삼아야 합니다.

---

4. 서버 구현: 원자적 버전 발급과 Tombstone 관리

버전 번호는 반드시 서버가 단일 진실 공급원(Single Source of Truth)으로서 원자적으로 발급해야 합니다. 클라이언트가 보내온 버전을 그대로 믿어서는 안 됩니다.

데이터베이스 스키마 설계 (PostgreSQL 예시)

-- 메시지 원본 테이블
CREATE TABLE chat_messages (
    message_id   UUID PRIMARY KEY,
    channel_id   UUID NOT NULL,
    author_id    UUID NOT NULL,
    body         TEXT NOT NULL,
    version      BIGINT NOT NULL DEFAULT 1,
    deleted_at   TIMESTAMPTZ,
    updated_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- 이벤트 로그 테이블 (재접속 동기화 및 감사용)
CREATE TABLE chat_events (
    event_id         UUID PRIMARY KEY,
    channel_id       UUID NOT NULL,
    message_id       UUID NOT NULL,
    operation        VARCHAR(16) NOT NULL, -- 'create', 'edit', 'delete'
    version          BIGINT NOT NULL,
    body             TEXT,
    actor_id         UUID NOT NULL,
    channel_sequence BIGINT NOT NULL,
    created_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
    UNIQUE (message_id, version) -- 동일 메시지의 동일 버전 중복 발행 방지
);

트랜잭션 내 조건부 갱신 (Pessimistic / Optimistic Lock)

메시지 수정 시에는 비관적 잠금(SELECT ... FOR UPDATE)이나 조건부 업데이트를 사용해 동시성 충돌을 방지합니다.

BEGIN;

-- 1. 대상 메시지 조회 및 잠금
SELECT message_id, author_id, version, deleted_at
FROM chat_messages
WHERE message_id = $1
FOR UPDATE;

-- 2. 서버 비즈니스 로직: 이미 삭제된 메시지인지 권한이 있는지 검증
-- (deleted_at IS NOT NULL이면 수정 요청 거부)

-- 3. 메시지 내용 갱신 및 버전 증가
UPDATE chat_messages
SET body = $2,
    version = version + 1,
    updated_at = now()
WHERE message_id = $1
RETURNING version;

    -- 4. 반환된 version으로 chat_events 테이블에 이벤트를 기록한다.
    -- channel_sequence는 트랜잭션 안에서 채널별 시퀀스 행을 원자적으로 증가시켜 발급한다.
    -- INSERT INTO chat_events (...) VALUES (...);

COMMIT;
-- 커밋이 성공한 뒤에만 브로드캐스트한다. 재시작 안전성을 높이려면 outbox를
-- 이 트랜잭션에 기록하고 별도 발행기가 커밋된 이벤트를 전달한다.

channel_sequence는 메시지 버전과 별도로 채널별 원자 증가기가 필요하다. 예를 들어 channel_sequences(channel_id PRIMARY KEY, last_sequence BIGINT)를 두고 같은 트랜잭션에서 행을 잠그거나 INSERT ... ON CONFLICT ... DO UPDATE ... RETURNING last_sequence로 번호를 발급한 뒤 이벤트 행에 저장한다. 시퀀스 발급과 이벤트 삽입이 함께 커밋되어야 재접속 동기화에서 빈 번호나 롤백된 이벤트를 정상 이벤트처럼 보지 않는다.

왜 삭제 시 Tombstone(소프트 삭제)이 필수적인가?

메시지를 지울 때 DELETE FROM chat_messages로 데이터베이스 행을 즉시 날려버리면 심각한 부작용이 생깁니다.

1. 메시지 A 생성 (v1)
2. 메시지 A 수정 (v2)
3. 메시지 A 삭제 $\rightarrow$ DB에서 레코드 완전 삭제 (Hard Delete)
4. 지연되었던 수정(v2) 이벤트가 뒤늦게 다른 서버나 클라이언트에 도착
5. “DB/로컬에 메시지가 없네?” 하고 삭제되었어야 할 메시지를 신규 메시지로 오인해 부활시키는 사태 발생

따라서 삭제는 반드시 deleted_at 필드를 채우고 버전을 올리는 Tombstone(비석) 방식으로 처리해야 합니다. 이렇게 해야 뒤늦게 날아온 수정(v2) 이벤트가 도착해도 “이미 v3으로 삭제된 메시지”임을 인지하고 안전하게 무시할 수 있습니다.

---

5. 클라이언트 구현: 이벤트 리듀서와 멱등성 처리

클라이언트 앱(웹, 모바일, 인게임 UI)에서는 수신한 이벤트를 상태 저장소(Store/State)에 반영할 때 엄격한 버전 비교를 거쳐야 합니다.

TypeScript 이벤트 리듀서 예제

export type ChatOperation = "create" | "edit" | "delete";

export interface ChatEvent {
  eventId: string;
  messageId: string;
  channelId: string;
  operation: ChatOperation;
  version: number;
  body?: string;
  actorId: string;
  channelSequence: number;
  occurredAt: string;
}

export interface LocalChatMessage {
  messageId: string;
  body: string;
  version: number;
  isDeleted: boolean;
  updatedAt: string;
}

/**
 * 수신된 이벤트를 로컬 상태에 단조 증가 규칙으로 안전하게 반영합니다.
 */
export function reduceChatMessage(
  current: LocalChatMessage | undefined,
  event: ChatEvent
): LocalChatMessage | undefined {
  // 1. 이미 더 높거나 같은 버전의 상태를 가지고 있다면 오래된/중복 이벤트이므로 무시
  if (current && event.version <= current.version) {
    return current;
  }

  // 2. 삭제 이벤트 처리
  if (event.operation === "delete") {
    if (!current) {
      // 로컬에 메시지가 아직 없더라도 삭제 Tombstone 상태를 기록해둠
      return {
        messageId: event.messageId,
        body: "",
        version: event.version,
        isDeleted: true,
        updatedAt: event.occurredAt,
      };
    }
    return {
      ...current,
      version: event.version,
      isDeleted: true,
      updatedAt: event.occurredAt,
    };
  }

  // 3. 수정 이벤트 처리
  if (event.operation === "edit" && event.body !== undefined) {
    if (!current || current.isDeleted) {
      // 이미 삭제된 상태이거나 없는 상태에서 온 수정 이벤트는 무시하거나 보류
      return current;
    }
    return {
      ...current,
      body: event.body,
      version: event.version,
      updatedAt: event.occurredAt,
    };
  }

  // 4. 생성 이벤트 처리
  if (event.operation === "create" && event.body !== undefined) {
    return {
      messageId: event.messageId,
      body: event.body,
      version: event.version,
      isDeleted: false,
      updatedAt: event.occurredAt,
    };
  }

  return current;
}

UI 렌더링 시에는 isDeleted: true인 메시지를 목록에서 제외하거나 "삭제된 메시지입니다"라는 플레이스홀더로 표시하면 됩니다.

---

6. 심화: 버전 갭(Gap)과 누락 처리 전략

만약 클라이언트가 v1 상태에서 갑자기 v3(삭제)을 받았다면 어떻게 해야 할까요? 중간의 v2(수정)가 누락되었거나 지연 중인 상황입니다.

게임 채팅 서비스의 성격에 따라 두 가지 전략 중 하나를 선택할 수 있습니다.

graph TD
    A[이벤트 수신: version gap 감지] --> B{서비스 요구사항}
    B -- 일반적인 채팅 최종 상태만 중요 --> C[즉시 v3 반영<br/>이후 도착하는 v2는 자연스럽게 버림]
    B -- 감사/애니메이션 이력 재생 필수 --> D[v3을 버퍼에 대기 Buffer<br/>일정 시간 후에도 v2 안오면 서버 스냅샷 동기화]

1. 최신 상태 즉시 반영 (실무 권장):

   • 일반적인 인게임 채팅에서는 과거의 수정 내용(v2)을 굳이 거치지 않고 최종 상태인 삭제(v3)로 곧바로 넘어가는 것이 유저 경험상 전혀 문제되지 않습니다.
   • 따라서 갭이 발생하더라도 더 큰 버전이면 즉시 반영하고 나중에 뒤늦게 도착한 v2는 버전 규칙에 의해 버려지도록 두는 것이 가장 단순하고 견고합니다.

2. 버퍼링 및 스냅샷 동기화:

   • 메시지 변경 애니메이션을 보여줘야 하거나 모든 변경 이력이 로그로 남아야 하는 특수 시스템이라면 incomingVersion > currentVersion + 1인 이벤트를 일시 버퍼에 담아두고 짧은 타임아웃(예: 500ms) 내에 누락된 버전이 도착하지 않으면 서버에 REST API로 채널 최신 스냅샷을 재요청합니다.

---

7. 재접속(Reconnection) 시 데이터 정합성 맞추기

모바일 환경에서는 지하철 탑승이나 터널 통과 등으로 WebSocket 연결이 끊겼다가 다시 연결되는 일이 일상적입니다.

재접속 시 데이터 정합성을 맞추는 표준 흐름은 다음과 같습니다.

sequenceDiagram
    autonumber
    actor Client as 클라이언트
    participant Server as 채팅 서버
    participant Redis as 이벤트 버퍼 (Redis Stream/RingBuffer)

    Note over Client: 연결 끊김 발생 후 재접속 완료
    Client->>Server: 재접속 핸드셰이크 (channelId, lastSeenSequence = 1042)
    Server->>Redis: 1042 이후의 이벤트 조회
    alt 서버 버퍼에 누락 이벤트가 모두 남아있는 경우
        Server-->>Client: 누락된 이벤트 스트림 재생 (Seq 1043 ~ 1050)
        Note over Client: 메시지 버전 규칙에 따라 차례대로 로컬 상태 갱신
    else 단절 기간이 길어 버퍼 범위를 벗어난 경우 (Buffer Overflow)
        Server-->>Client: 전체 채널 최신 스냅샷(Snapshot) 전송
        Note over Client: 로컬 메시지 맵을 최신 스냅샷으로 일괄 교체
    end

---

8. 실무 보안 및 정합성 체크리스트

시스템을 프로덕션에 배포하기 전에 다음 항목들이 제대로 방어되고 있는지 점검해야 합니다.

• 버전 발급 권한은 서버에만 있는가?
  클라이언트가 임의로 version: 99 같은 페이로드를 전달하더라도 서버는 이를 무시하고 DB 트랜잭션 내에서 직접 계산한 버전을 사용해야 합니다.
• 권한 검증이 버전 증가보다 먼저 일어나는가?
  권한이 없는 유저가 악의적으로 수정 API를 찔렀을 때 DB 버전이 먼저 증가해 버리면 실제 작성자의 정상적인 수정 이벤트가 버전 충돌로 씹히는 취약점이 생깁니다. 권한 체크 $\rightarrow$ 버전 증가 $\rightarrow$ 이벤트 발행 순서를 엄격히 지켜야 합니다.
• 삭제된 메시지의 수정 시도를 차단했는가?
  이미 deleted_at IS NOT NULL인 메시지에 대해 수정 요청이 들어오면 서버에서 에러를 반환해야 합니다.
• 이벤트 ID 중복 제거(Deduplication)를 수행하는가?
  네트워크 재시도로 인해 동일한 이벤트가 2번 들어오더라도 상태가 망가지지 않도록 eventId 캐시 및 (message_id, version) 복합 유니크 제약을 적용합니다.

---

요약

게임 채팅의 수정·삭제 순서 뒤바뀜 문제는 네트워크 계층에서 억지로 순서를 맞추려 하기보다 데이터 모델에 논리적 버전(Version)을 부여하고 클라이언트가 단조 증가(Monotonic) 규칙으로 이벤트를 소비하게 만들 때 가장 깔끔하게 해결됩니다.

1. 메시지마다 단조 증가하는 version 번호를 서버에서 원자적으로 발급합니다.
2. 클라이언트는 event.version > local.version일 때만 상태를 갱신합니다.
3. 삭제는 레코드를 완전히 지우지 말고 Tombstone(deleted_at + 버전 증가)으로 남겨 지연된 수정 이벤트의 부활을 막습니다.
4. 개별 메시지 정합성은 messageVersion으로 재접속 누락 복구는 channelSequence로 분리하여 관리합니다.