멀티플레이어 위치 동기화와 래그 버그 해결: 서버 권위·보간·예측 구현법

멀티플레이어 위치 동기화의 래그 버그는 대개 클라이언트가 받은 위치를 즉시 적용하거나 서버와 클라이언트의 이동 규칙이 서로 다를 때 발생한다. 해결의 핵심은 서버를 최종 판정자로 두고 다른 플레이어는 과거 스냅샷을 보간하며 내 캐릭터에는 입력 예측 후 서버 결과로 재조정하는 것이다.

위치 동기화 래그 버그는 왜 발생하는가?

실시간 게임은 패킷이 즉시 도착하지 않는다. 왕복 지연 시간(RTT)이 80ms라면 사용자의 입력이 서버에 도달하고 결과가 다시 돌아오는 데만 약 80ms가 걸린다. 여기에 패킷 지터와 손실까지 더해지면 단순한 좌표 전송은 곧바로 화면 문제로 이어진다.

대표 증상은 다음과 같다.

증상	직접 원인	흔한 잘못된 대응
다른 플레이어가 순간이동한다	패킷 도착 간격이 불규칙하거나 손실됨	마지막 수신 좌표를 즉시 대입
내 캐릭터가 뒤로 튕긴다	클라이언트와 서버의 이동 결과가 다름	서버 좌표를 매 프레임 강제 적용
이동이 느리고 입력이 둔하다	서버 응답을 받은 뒤에만 이동 표시	클라이언트 예측을 사용하지 않음
벽을 통과하거나 속도가 조작된다	클라이언트 위치를 신뢰함	클라이언트가 보낸 좌표를 그대로 저장

특히 transform.position = receivedPosition처럼 수신 패킷마다 위치를 즉시 덮어쓰면 네트워크 지터가 화면의 떨림으로 그대로 드러난다. 서버 틱과 렌더링 프레임도 보통 일치하지 않으므로 수신 시점의 위치를 곧바로 그리는 방식은 구조적으로 불안정하다.

서버 스냅샷과 클라이언트 렌더링 시점의 차이를 보여주는 멀티플레이어 위치 동기화 구조

서버 권위 위치 동기화는 어떻게 설계할까?

서버 권위(Server Authoritative) 모델에서 클라이언트는 위치가 아니라 입력을 전송한다. 서버는 입력, 이동 속도, 충돌 규칙을 검증한 뒤 월드 상태를 갱신하고 스냅샷을 배포한다. 이 구조는 치트 방어와 플레이어 간 상태 일관성에 유리하다.

flowchart LR
  A[클라이언트 입력: 방향, 시퀀스] --> B[게임 서버]
  B --> C[이동·충돌·속도 검증]
  C --> D[권위 상태 갱신]
  D --> E[스냅샷 전송: tick, position, velocity]
  E --> F[다른 플레이어: 보간 렌더링]
  E --> G[본인: 재조정]

권장 패킷 필드

필드	용도
`tick`	서버 상태의 순서와 보간 기준
`sequence`	클라이언트 입력 순서와 재조정 기준
`position`	서버가 확정한 위치
`velocity`	보간 및 외삽 제한에 활용
`inputX`, `inputY`	클라이언트가 보낸 이동 입력
고정 네트워크 틱	서버 설정으로 관리하는 시뮬레이션 시간 단위

서버는 클라이언트의 position을 신뢰하지 않는 편이 안전하다. 이동 요청에서 입력 벡터의 길이를 제한하고 서버의 고정 틱(fixedDeltaTime)으로 속도와 충돌을 계산해야 한다.

// 서버 의사 코드: 60Hz 고정 틱
const float TickDelta = 1f / 60f;
const float MoveSpeed = 5f;

Vector2 input = ClampMagnitude(command.MoveInput, 1f);
Vector2 desired = player.Position + input * MoveSpeed * TickDelta;
player.Position = ResolveCollision(player.Position, desired);

BroadcastSnapshot(serverTick, player.Id, player.Position, player.Velocity,
                  command.Sequence);

다른 플레이어 위치는 스냅샷 보간으로 어떻게 부드럽게 만들까?

원격 플레이어는 최신 서버 상태를 바로 렌더링하지 않고 현재보다 일정 시간 과거의 상태를 그린다. 이를 스냅샷 보간(Snapshot Interpolation)이라고 한다. 예를 들어 서버가 20Hz로 스냅샷을 보내고 보간 지연을 100ms로 설정하면 클라이언트는 버퍼 안의 두 상태를 안정적으로 연결할 가능성이 높아진다.

두 스냅샷의 위치를 p0, p1, 렌더링 시각을 t, 각 스냅샷 시각을 t0, t1이라 하면 보간 비율은 다음과 같다.

\alpha = \operatorname{clamp}\left(\frac{t-t_0}{t_1-t_0}, 0, 1\right)

p(t) = (1-\alpha)p_0 + \alpha p_1

Vector3 Interpolate(Snapshot older, Snapshot newer, double renderTime)
{
    double duration = newer.Time - older.Time;
    float alpha = duration <= 0
        ? 1f
        : Mathf.Clamp01((float)((renderTime - older.Time) / duration));

    return Vector3.Lerp(older.Position, newer.Position, alpha);
}

보간 지연은 얼마로 시작해야 할까?

처음에는 서버 스냅샷 간격의 2~3배로 시작하는 것이 실용적이다. 서버 전송률이 20Hz이면 간격은 50ms이므로 100~150ms를 초기값으로 두고 실제 RTT와 지터를 관찰한다. 지연을 너무 짧게 잡으면 스냅샷이 모자라 외삽이 늘고 너무 길게 잡으면 원격 플레이어가 눈에 띄게 늦게 보인다.

서버 전송률	스냅샷 간격	초기 보간 지연 예시
10Hz	100ms	200~300ms
20Hz	50ms	100~150ms
30Hz	약 33ms	66~100ms

패킷이 잠시 비었을 때 무제한 외삽을 하면 캐릭터가 벽이나 장애물 너머로 보일 수 있다. 마지막 속도로 예측하더라도 최대 외삽 시간을 100~200ms처럼 제한하고 그 이후에는 마지막 위치를 유지하거나 애니메이션만 멈춘다.

내 캐릭터의 입력 지연은 클라이언트 예측으로 어떻게 줄일까?

내 캐릭터까지 서버 응답을 기다리면 조작감이 RTT만큼 늦어진다. 클라이언트 예측(Client-side Prediction)은 입력 직후 로컬에서도 같은 이동 시뮬레이션을 실행해 즉시 반응을 보여준다.

다만 예측은 서버 확정값과 달라질 수 있다. 그래서 서버 스냅샷에 포함된 마지막 처리 입력 시퀀스 ackSequence를 기준으로 이미 서버가 처리한 입력은 버리고 아직 처리되지 않은 입력만 서버 위치에서 다시 적용한다. 이 과정을 재조정(Reconciliation)이라고 한다.

구현 순서

클라이언트가 매 이동 틱마다 증가하는 sequence와 입력을 저장하고 서버로 전송한다.
클라이언트는 같은 이동 함수를 즉시 실행해 로컬 플레이어를 예측 이동시킨다.
서버는 입력을 검증해 시뮬레이션하고 position, ackSequence를 스냅샷으로 돌려준다.
클라이언트는 ackSequence 이전 입력을 제거한 뒤 서버 위치에서 남은 입력을 재실행한다.
오차가 작다면 렌더링 위치만 짧게 보정하고 오차가 크거나 충돌 상태가 다르면 즉시 권위 상태를 적용한다.

void OnAuthoritativeState(Vector3 serverPosition, uint ackSequence)
{
    pendingInputs.RemoveAll(input => input.Sequence <= ackSequence);

    predictedPosition = serverPosition;
    foreach (var input in pendingInputs)
    {
        predictedPosition = SimulateMove(predictedPosition, input);
    }

    float error = Vector3.Distance(renderPosition, predictedPosition);
    if (error > 1.0f)
    {
        renderPosition = predictedPosition; // 큰 오차는 즉시 수정
    }
    else
    {
        correctionTarget = predictedPosition; // 작은 오차는 시각적으로 완화
    }
}

중요한 점은 서버와 클라이언트가 가능한 한 같은 이동 함수를 써야 한다는 것이다. 중력, 가속, 마찰, 충돌 판정 순서, 부동소수점 정밀도가 서로 다르면 재조정이 매번 발생한다. 완전한 결정론이 어려운 엔진 물리라면 캐릭터 이동은 서버가 관리하는 단순한 운동 모델로 분리하는 것도 좋은 선택이다.

래그 버그를 재현하고 고치는 점검 절차

문제는 좋은 네트워크 환경에서 잘 드러나지 않는다. 개발 환경에서 지연과 손실을 의도적으로 주입하고 수치로 확인해야 한다.

측정한다. RTT, 지터, 패킷 손실률, 서버 틱 시간, 스냅샷 크기, 재조정 횟수와 오차 거리를 로그 또는 대시보드에 기록한다.
격리한다. 원격 플레이어 떨림은 보간 버퍼와 전송률을 확인하고, 내 플레이어 튕김은 입력 시퀀스와 서버·클라이언트 시뮬레이션 차이를 우선 확인한다.
검증한다. 100ms 지연, 20ms 지터, 1~3% 패킷 손실 조건에서 이동, 충돌, 방향 전환, 정지, 텔레포트 기능을 반복 테스트한다.

다음 로그는 재조정 문제를 찾는 데 특히 유용하다.

snapshotTick=18420 ackSequence=931
pendingInputs=3
serverPosition=(42.10, 0.00, 18.75)
predictedPosition=(42.18, 0.00, 18.76)
reconciliationError=0.081

reconciliationError가 특정 장애물이나 경사면에서만 급증한다면 네트워크보다 충돌 계산 불일치를 의심해야 한다. 반대로 오차는 작지만 원격 캐릭터가 끊겨 보인다면 스냅샷 도착 간격과 보간 버퍼 길이를 먼저 확인한다.

자주 묻는 질문 (FAQ)

UDP를 쓰면 위치 동기화 래그가 자동으로 해결되나?

아니다. UDP는 오래된 패킷을 기다리지 않아 실시간 상태 전송에 적합하지만 손실과 순서 뒤바뀜을 애플리케이션이 처리해야 한다. tick을 비교해 오래된 스냅샷을 버리고 보간 버퍼를 운영해야 한다.

위치를 매 프레임 보내면 더 부드러워지나?

대개 아니다. 전송 빈도만 높이면 대역폭과 서버 부하가 늘고 혼잡으로 지터가 커질 수 있다. 이동 입력은 높은 빈도로 권위 스냅샷은 게임 장르와 예산에 맞는 틱률로 전송한 뒤 보간으로 화면을 부드럽게 만드는 편이 낫다.

모든 게임에 클라이언트 예측이 필요한가?

아니다. 턴제 게임이나 입력 즉시성이 낮은 게임은 서버 확정 상태만으로 충분할 수 있다. 반면 액션, 슈팅, 레이싱처럼 즉각적인 조작감이 중요한 게임에서는 내 캐릭터 예측이 사실상 필수에 가깝다.

정리

위치 동기화 문제를 “패킷이 늦어서 생기는 현상”으로만 보면 전송 빈도부터 올리기 쉽다. 하지만 안정적인 해법은 역할을 나누는 데 있다. 서버는 판정과 검증을 맡고 원격 플레이어는 스냅샷 보간으로 표시하며 로컬 플레이어는 입력 예측과 재조정으로 조작감을 확보한다.

이 세 가지를 분리한 뒤 실제 지연·지터·손실 조건에서 오차를 측정하면 순간이동과 떨림, 뒤로 튕김을 감에 의존하지 않고 재현 가능한 방식으로 줄일 수 있다.