화면 위쪽에 Client와 Server 박스가 있고 그 사이 Network 구간으로 패킷이 오간다. 아래에는 "키 입력 → 결과가 보이기까지" 걸리는 시간을 구간별로 쌓은 막대가 나온다.

• 입력 처리 8ms (클라)
• 업링크 25ms (네트워크)
• 서버 큐 + 틱 30ms (서버)
• 다운링크 25ms (네트워크)
• 렌더링 16ms (클라)

합계는 104ms다. 입력 처리와 렌더링은 클라, 업링크와 다운링크는 네트워크, 서버 큐 + 틱은 서버로 묶인다. 화면 문구는 "체감 렉 = 이 구간들의 합. 어느 구간이 늘었는지 찾는 게 판별입니다."다. 사용자는 합계만 느끼기 때문에 증상만으로는 어느 구간 문제인지 알 수 없고, 구간별 지표를 따로 봐야 한다.

왼쪽 "내 화면" 미니뷰에서 캐릭터와 몬스터가 움직이다가 갑자기 전부 멈추고, 상태 칩이 FPS 60에서 FPS 4로 바뀌며 "화면 · UI · 입력 전부 멈칫"이 뜬다. 오른쪽 프레임타임 막대그래프에는 60fps = 16.7ms 예산선이 있고, 멈춘 구간에서 막대가 200ms대로 솟는다. 같은 순간에도 Ping 45ms · 정상 칩은 그대로다.

클라렉의 신호는 네 가지로 정리된다.

• FPS · 프레임타임 급등: 한 프레임이 수백 ms 걸린다(히치).
• 화면 · UI · 입력이 전부 멈칫: 내 캐릭터, 몬스터, 버튼까지 같이 멈춘다.
• 핑은 정상: 네트워크 지표는 평소와 같다.
• 나만 그럼: 같은 파티원 화면은 멀쩡하다.

흔한 원인으로는 GC 스파이크, 리소스 로딩, 렌더링 과부하, 메인 스레드 블로킹, 저사양 · 발열이 제시된다. 클라 메인 스레드가 한 프레임 안에 일을 끝내지 못하면 화면 갱신과 입력 처리가 함께 멈추므로, UI까지 굳는 것이 클라렉의 특징이다.

미니뷰에서 내 캐릭터는 부드럽게 움직이고 FPS 60, "UI 즉시 반응" 상태다. "공격" 버튼도 바로 눌린다. 그런데 "다른 플레이어"가 잠시 멈췄다가 다른 위치로 튀고 "순간이동 · 러버밴딩" 칩이 뜬다. 오른쪽 RTT (ms) 그래프는 평소 45ms 안팎에서 800ms 근처까지 솟고, 그동안 손실 칩이 패킷 손실 0%에서 패킷 손실 12%로 바뀐다.

네트워크렉의 신호는 다음과 같다.

• 핑 · 손실 · 지터 급등: RTT 그래프가 튀고 손실률이 오른다.
• FPS · UI는 정상: 내 화면은 부드럽고 버튼도 바로 반응한다.
• 다른 캐릭터가 멈췄다 순간이동: 스킬 결과와 피격이 늦게 도착한다.
• 나 또는 같은 망: 같은 와이파이, 지역, 통신사 사용자에게 나타난다. 서버 쪽 회선(IDC 회선 포화, DDoS)이 문제면 서버 전체 유저의 전송 핑이 함께 튄다.

흔한 원인은 와이파이 간섭, 모바일 망 전환, ISP 경로 문제, 대역폭 포화(다운로드 중)다. 클라는 정상적으로 그리고 있지만 서버에서 오는 상태 갱신이 늦거나 빠지니, 다른 캐릭터의 위치처럼 서버가 알려 줘야 하는 정보만 끊긴다.

왼쪽 "서버 틱 처리시간 (ms)" 막대그래프에는 20Hz 예산 = 50ms 선이 있다. 처음에는 막대가 20~30ms대로 예산 안에 있다가, 어느 순간 100ms를 훌쩍 넘기고 칩이 Tick 20Hz에서 Tick 20Hz → 8Hz로 바뀐다. 오른쪽 "채널 3 · 24명" 그리드에서는 24명 전원의 점이 거의 동시에 빨갛게 바뀌고 "전원 동시에 반응 지연"이 뜬다. 이때도 FPS 60과 전송 핑 42ms는 정상 표시다.

서버렉의 신호는 다음과 같다.

• 같은 채널 · 존이 동시에: 나만이 아니라 주변 모두가 같이 느리다.
• FPS · 전송 핑은 정상: 화면은 부드럽고 핑 숫자도 평소와 같다.
• 서버 판정이 필요한 반응이 늦음: 스킬, 피격, 다른 캐릭터 움직임이 모두 늦고, 내 이동만 예측 덕분에 멀쩡하다.
• 서버 틱 시간 > 예산: 틱레이트가 떨어지고 작업 큐가 쌓인다.

흔한 원인은 대규모 전투 · 공성, 몬스터 대량 스폰, DB 응답 대기, 서버 GC, 락 경합이다. 한 채널은 같은 프로세스나 같은 틱 루프에서 처리되는 경우가 많아서, 틱 하나가 늦어지면 그 채널의 모든 플레이어가 똑같이 영향을 받는다.

Client에서 Server로 선이 두 개 이어진다. 위쪽 "전송 핑"은 커널 · 소켓 단에서 재는 TCP RTT라 클라 앱의 프레임 루프에 영향받지 않고, 아래쪽 "앱 핑"은 소켓을 지나 "게임 로직 큐 → 틱"을 거친 뒤 돌아온다. 같은 왕복이라도 앱 핑에는 서버 내부 대기 시간이 더해진다.

화면은 세 상황을 차례로 보여 준다.

• 정상: 전송 핑 41ms, 앱 핑 46ms. "둘 다 낮음 → 정상".
• 네트워크렉: 전송 핑 420ms, 앱 핑 428ms. "둘 다 높음 → 네트워크 구간이 문제". 서버 머신 전체가 멈춘 경우는 예외다.
• 서버렉: 전송 핑 42ms, 앱 핑 380ms. 큐에 작업이 쌓이고 앱 핑 패킷이 그 뒤에서 기다린다. "전송 핑은 정상인데 앱 핑만 높음 → 서버가 문제".

두 값의 차이가 곧 서버 안에서 기다린 시간이다. 아래 문구는 "클라렉이면 앱 핑만 오를 수 있음 (전송 핑은 커널이 재므로 정상)"이다. 클라가 멈춰 있으면 앱 핑 응답을 늦게 꺼내 읽지만, 커널이 재는 TCP RTT는 그대로다. 다만 게임이 핑을 자기 앱 루프에서 재면 클라렉에도 두 값이 함께 오르므로, 프레임타임을 먼저 확인한다.

왼쪽은 세 단계 질문이다. 앞 질문에 "예"면 그 자리에서 결론을 내고, "아니오"면 다음 질문으로 내려간다.

• Q1. FPS · 프레임타임이 튀었다? 예 → 클라렉
• Q2. 전송 핑 · 손실이 튀었다? 예 → 네트워크렉
• Q3. 앱 핑만 높고, 같은 채널이 동시에? 예 → 서버렉

셋 다 아니면 "복합 원인 · 타임스탬프로 구간을 쪼개서 확인"한다. 오른쪽 비교표는 앞 챕터 내용을 한 장으로 모은 것이다.

• 클라렉: 프레임타임 튐, 전송 핑 정상, 앱 핑은 오를 수 있음, 범위는 나만.
• 네트워크렉: 프레임타임 정상, 전송 핑 튐, 앱 핑 튐, 범위는 나 · 같은 망 (서버 회선이면 전체).
• 서버렉: 프레임타임 정상, 전송 핑 정상, 앱 핑 튐, 범위는 채널 전체.

보는 순서는 "프레임타임 → 전송 핑 → 앱 핑 · 영향 범위"다. 범위만 보고 판단하지 않는다. 클라 문제는 앱 핑까지 끌어올리고, 핑을 앱 루프에서 재는 게임이면 전송 핑도 함께 올리므로 프레임타임을 가장 먼저 봐야 뒤 단계의 판단이 흔들리지 않는다.