# 게임 렉 백서 (Game Lag White Paper)

> 온라인 게임에서 렉(뚝뚝 끊김, 순간이동, 고무줄, 몰아치기, 입력 지연, 멈춤, 접속 끊김 등)이 생기는 원인 228가지를 내 화면부터 서버 데이터베이스까지 13개 층과 3개 주제(동기화 설계, 일부에게만 생기는 문제, TCP 재전송)로 나눠 설명하는 백서입니다. MMO 사례를 중심으로 썼지만 대부분은 장르와 상관없이 온라인 게임 전반에 해당합니다. 원인마다 왜 → 그러면 → 화면에서는의 세 단계, 관련 증상, 수치 감각, 해결 담당(게임개발팀·인프라팀·외부)과 팀별 할 일, 그래프 모양과 확인 방법, 공신력 있는 출처(RFC, 커널·OS·클라우드·엔진·DB 공식 문서, 논문)를 담았습니다.

원인은 ID(예: mem-gc)로 가리키고 원인마다 페이지가 있습니다(예: https://jungrok5.github.io/mmo-lag-anatomy/c/mem-gc.html). 수치는 일반적인 서비스 환경의 대표값이고 기본값·버전은 각 원인 페이지의 출처에 근거가 있습니다. 인용할 때는 원인 페이지 주소를 쓰면 됩니다. MIT 라이선스.

## 문서

- [전체 내용(마크다운)](https://jungrok5.github.io/mmo-lag-anatomy/llms-full.txt): 원인·증상·담당·용어·출처 전체를 한 파일로
- [텍스트 판](https://jungrok5.github.io/mmo-lag-anatomy/text.html): 같은 내용을 자바스크립트 없이 한 페이지에서 읽는 HTML
- [게임 렉 백서](https://jungrok5.github.io/mmo-lag-anatomy/): 그림과 직접 조작하는 실험이 있는 원본

## 증상별 원인

- [뚝뚝 끊김](https://jungrok5.github.io/mmo-lag-anatomy/s/stutter.html): 원인 60가지. 움직임이 매끄럽지 않고 짧게 멈췄다 움직이기를 반복합니다.
- [순간이동](https://jungrok5.github.io/mmo-lag-anatomy/s/teleport.html): 원인 47가지. 캐릭터가 이동 과정 없이 멀리 떨어진 위치로 한 번에 옮겨집니다.
- [고무줄](https://jungrok5.github.io/mmo-lag-anatomy/s/rubber.html): 원인 14가지. 내 캐릭터가 앞으로 가다가 방금 지나온 자리로 끌려 돌아갑니다.
- [몰아치기](https://jungrok5.github.io/mmo-lag-anatomy/s/burst.html): 원인 36가지. 멈춰 있던 화면이 다시 움직이면서 밀린 움직임·타격·데미지가 한꺼번에 빠르게 지나갑니다.
- [슬로우모션](https://jungrok5.github.io/mmo-lag-anatomy/s/slowmo.html): 원인 24가지. 모든 것이 느리게 움직입니다. 스킬 시전과 몬스터 이동이 늘어진 것처럼 보입니다. 서버 설계에 따라서는 속도는 그대로인 채 뚝뚝 끊김·순간이동으로 나타나기도 합니다.
- [입력 지연](https://jungrok5.github.io/mmo-lag-anatomy/s/delay.html): 원인 76가지. 누르고 나서 결과가 나타나기까지 시간이 걸립니다. 화면 자체는 매끄러울 수 있습니다.
- [멈춤](https://jungrok5.github.io/mmo-lag-anatomy/s/freeze.html): 원인 67가지. 화면 속 모든 것이 잠깐(0.5초~수 초) 멈췄다가 다시 움직입니다.
- [씹힘·롤백](https://jungrok5.github.io/mmo-lag-anatomy/s/dropped.html): 원인 36가지. 분명히 한 행동이 없던 일이 되거나, 결과가 한참 뒤 뒤집힙니다.
- [접속 끊김](https://jungrok5.github.io/mmo-lag-anatomy/s/disconnect.html): 원인 51가지. 게임 중에 연결이 끊어져 로그인 화면이나 재접속 창으로 돌아갑니다.
- [접속 불가·무한 로딩](https://jungrok5.github.io/mmo-lag-anatomy/s/noconnect.html): 원인 45가지. 게임 안으로 들어가지 못하거나, 로딩·입장 화면에서 멈춰 있습니다.
- [안 보임·유령 개체](https://jungrok5.github.io/mmo-lag-anatomy/s/invisible.html): 원인 20가지. 있어야 할 NPC·몬스터·플레이어가 내 화면에만 없거나, 이미 사라진 개체가 내 화면에만 남아 있습니다.

## L1 클라이언트 게임 프로세스

- [프레임 타임 스파이크](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-hitch.html): 한 프레임 계산이 평소보다 몇 배 오래 걸려 화면이 잠깐 멈춥니다.
- [클라이언트 가비지 컬렉션](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-gc.html): 쓰고 버린 메모리(가비지)를 회수하는 동안 게임 전체가 멈춥니다. 규칙적인 간격으로 뚝뚝 끊기는 것이 특징입니다.
- [메인 스레드 동기 로딩·셰이더 컴파일](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-sync-load.html): 처음 보는 지역·몬스터·이펙트를 그리기 직전에 파일을 읽고 셰이더를 만드느라 멈춥니다.
- [저장장치가 느려 에셋 스트리밍이 밀림](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-asset-stream.html): HDD처럼 느린 저장장치에서는 오픈월드의 텍스처·모델을 읽는 속도가 이동을 따라가지 못해, 개체가 늦게 뜨거나 게임이 읽기를 기다리며 끊깁니다.
- [대규모 인원 렌더링 부하](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-crowd.html): 공성전·월드 보스처럼 수백 명이 한 화면에 들어오면 그리는 비용 자체가 감당이 안 됩니다.
- [메인 스레드 패킷 처리 병목](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-net-mainthread.html): 받은 패킷을 프레임마다 정해진 만큼만 처리하면, 몰려온 패킷이 다음 프레임으로 계속 밀립니다.
- [보간 버퍼가 없거나 짧음](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-no-buffer.html): 서버 패킷을 받자마자 그리면 지터(도착 간격의 흔들림)가 그대로 화면에 드러납니다.
- [과도한 외삽(데드 레커닝)](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-extrap.html): 패킷이 오지 않는 동안 마지막 속도로 계속 움직여 보여 주다가, 틀린 걸 알고 되돌립니다.
- [클라이언트 예측 불일치](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-predict.html): 내 클라이언트가 먼저 움직여 보여 줬는데 서버가 다르게 계산하면 내 캐릭터가 끌려갑니다.
- [고정 타임스텝 따라잡기 폭주](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-fixed-step.html): 한 번 멈춘 뒤 밀린 계산을 몰아서 하다가, 그 계산 때문에 또 밀립니다.
- [시계 동기화 오차](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-clock.html): 클라이언트가 추정한 서버 시각이 틀리면 보간 시점과 쿨타임 판정이 어긋납니다.
- [float 시간 정밀도 손실](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-float-time.html): 게임 시각을 정밀도가 낮은 소수 형식(float)으로 들고 있으면, 켜 둔 시간이 길수록 시간 해상도(구별할 수 있는 가장 작은 시간 차이)가 떨어져 움직임과 이펙트가 떨립니다.
- [V-Sync와 렌더 대기열](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-vsync.html): GPU가 그린 프레임을 몇 장 대기열에 쌓아 두었다가 모니터 주기에 맞춰 내보내는 동안 입력이 늦어집니다.
- [클라이언트 메모리 누수](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-leak.html): 오래 켜 둘수록 메모리가 늘어 점점 느려지다가 결국 게임이 강제로 꺼집니다.
- [클라이언트 크래시](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-crash.html): 처리하지 못한 오류로 게임이 꺼집니다. 플레이어에게는 접속 끊김처럼 보이지만 서버는 정상입니다.
- [게임 보안 모듈(안티치트) 검사](https://jungrok5.github.io/mmo-lag-anatomy/c/cg-anticheat.html): 해킹을 막으려고 게임과 함께 도는 보안 모듈이 주기적으로 검사합니다. 검사가 무겁거나 보안 서버와 주고받는 하트비트(주기적인 생존 확인 신호)가 늦으면 뚝뚝 끊기거나 접속이 끊깁니다.

## L2 클라이언트 OS·기기

- [백그라운드 프로세스의 CPU 점유](https://jungrok5.github.io/mmo-lag-anatomy/c/co-background.html): 백신 검사, 윈도우 업데이트, 방송 프로그램, 브라우저 영상이 코어를 차지하면 게임 스레드가 CPU를 배정받지 못하고 기다립니다.
- [절전 모드·발열 스로틀링](https://jungrok5.github.io/mmo-lag-anatomy/c/co-power.html): 노트북 배터리 모드, 폰 절전 모드, 기기 발열 때문에 CPU·GPU 속도가 떨어집니다. 발열은 처음엔 괜찮다가 한참 뒤부터 느려지는 게 특징입니다.
- [타이머 해상도](https://jungrok5.github.io/mmo-lag-anatomy/c/co-timer.html): 윈도우의 기본 타이머는 15.6ms 단위라 “1ms만 쉬기”가 실제로는 다음 타이머 주기까지, 길게는 15.6ms로 늘어납니다.
- [모바일 앱 백그라운드 전환](https://jungrok5.github.io/mmo-lag-anatomy/c/co-mobile-bg.html): 알림을 보려고 앱을 잠깐 내리면 OS가 몇 초 뒤 앱을 일시 정지(suspend)하고, 그동안 서버는 나를 끊습니다.
- [와이파이 ↔ LTE·5G 전환](https://jungrok5.github.io/mmo-lag-anatomy/c/co-netswitch.html): 집 밖으로 나가며 와이파이가 끊기고 LTE·5G로 바뀌면 내 IP 주소가 바뀌어 기존 연결이 무효가 됩니다.
- [보안 프로그램의 패킷 검사](https://jungrok5.github.io/mmo-lag-anatomy/c/co-security.html): 백신·방화벽이 모든 패킷을 검사하면 지연이 늘고 과하면 게임을 공격으로 오인해 막습니다.
- [수신 버퍼 넘침](https://jungrok5.github.io/mmo-lag-anatomy/c/co-rcvbuf.html): 게임이 바빠서 소켓(OS가 제공하는 네트워크 송수신 인터페이스)에서 패킷을 늦게 꺼내면 OS 버퍼가 넘칩니다.
- [클라이언트 메모리 부족·스왑](https://jungrok5.github.io/mmo-lag-anatomy/c/co-swap.html): 브라우저 탭 수십 개와 게임을 함께 켜 두면 OS가 게임 메모리 일부를 디스크로 내보냅니다.
- [그래픽 메모리(VRAM) 부족](https://jungrok5.github.io/mmo-lag-anatomy/c/co-vram.html): 그래픽 옵션이 요구하는 메모리가 그래픽카드 메모리보다 크면, OS가 텍스처를 PC 메모리로 내보냈다가 다시 가져오느라 뚝뚝 끊깁니다.
- [와이파이 백그라운드 스캔](https://jungrok5.github.io/mmo-lag-anatomy/c/co-wifi-scan.html): OS가 주변 와이파이를 찾으려고 주기적으로 채널을 옮겨 다니는 동안 통신이 잠깐 멈춥니다.
- [NIC 절전·드라이버 문제](https://jungrok5.github.io/mmo-lag-anatomy/c/co-driver.html): 랜카드·와이파이 칩이 패킷 사이에 절전 상태로 들어가면 다시 활성화되는 데 시간이 걸립니다.
- [같은 기기의 다른 앱이 대역폭 점유](https://jungrok5.github.io/mmo-lag-anatomy/c/co-other-apps.html): 클라우드 동기화, 대용량 다운로드, 게임 패치가 같은 PC에서 돌면 게임 패킷이 대기열에서 기다립니다.
- [창 최소화·비활성 시 처리 제한](https://jungrok5.github.io/mmo-lag-anatomy/c/co-unfocused.html): 다른 창을 보거나 게임을 최소화하면 게임과 윈도우가 전기를 아끼려고 게임을 느리게 돌립니다. 돌아오면 밀린 패킷이 몰려오거나, 이미 접속이 끊겨 있습니다.
- [오버레이 프로그램 간섭](https://jungrok5.github.io/mmo-lag-anatomy/c/co-overlay.html): 메신저·런처·녹화·FPS 표시 프로그램이 게임 화면 위에 자기 UI를 덧그리려고 게임의 렌더링 과정에 끼어듭니다(후킹). 프레임마다 작업이 늘고 가끔 게임과 부딪혀 멈칫하거나 게임이 강제로 꺼집니다.
- [디스플레이·입력 장치·프레임 생성 지연](https://jungrok5.github.io/mmo-lag-anatomy/c/co-display-input.html): 핑은 정상인데 조작이 묵직하다면, TV의 영상 처리나 무선 컨트롤러, 프레임 생성 기능이 입력과 화면 사이에 지연을 더했을 수 있습니다.

## L3 집 네트워크

- [와이파이 간섭·신호 약화](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-wifi.html): 신호가 약하거나 간섭이 생기면 무선 구간에서 몇 번씩 다시 보내느라 도착이 들쭉날쭉해집니다.
- [와이파이 채널 혼잡](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-channel.html): 아파트처럼 공유기가 수십 개 있는 곳은 같은 채널을 나눠 쓰느라 전송 기회를 기다립니다.
- [버퍼블로트 (공유기 대기열)](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-bufferbloat.html): 가족 누군가 영상을 올리거나 큰 파일을 받으면 공유기 대기열에 수백 ms 분량의 패킷이 쌓이고, 게임 패킷도 그 뒤에서 기다립니다.
- [NAT 매핑 만료](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-nat.html): 공유기는 한동안 패킷이 오가지 않은 유휴 연결을 NAT 테이블에서 지웁니다. 가만히 있다가 움직이는 순간 접속이 끊기는 흔한 원인입니다.
- [공유기 성능 부족·과열](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-router.html): 값싼 공유기에 기기 수십 대, 연결 수천 개가 몰리면 공유기 자체가 처리를 못 합니다.
- [기지국 핸드오버 (이동 중)](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-handover.html): 버스·지하철로 이동하면 기지국이 바뀌는 동안 통신이 끊깁니다.
- [RRC 상태 전환 지연 (모바일 무선 절전)](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-rrc.html): 폰은 한동안 통신이 없으면 무선 연결을 저전력 상태로 내리고 다음 패킷 때 다시 올리느라 늦어집니다.
- [모바일 신호 약함·음영 지역](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-weak-cell.html): 엘리베이터·지하·건물 안쪽에서는 재전송이 늘고 속도가 떨어지며 결국 접속이 끊깁니다.
- [5G↔LTE 잦은 전환 (5G 경계 지역)](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-5g-flip.html): 5G 신호가 약한 건물 안이나 5G 경계 지역에서는 폰이 5G와 LTE를 자주 오가고, 바뀔 때마다 핑이 튀거나 통신이 잠깐 끊깁니다.
- [공용 와이파이·회사망 제한](https://jungrok5.github.io/mmo-lag-anatomy/c/hn-captive.html): 카페 와이파이 로그인 페이지나 회사 방화벽이 게임 연결을 막습니다.

## L4 인터넷 회선

- [전파 지연 (물리적 거리)](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-distance.html): 빛도 광케이블에서 1초에 약 20만 km밖에 못 갑니다. 먼 서버는 아무리 좋아도 늦습니다.
- [위성 인터넷 (저궤도·정지궤도)](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-satellite.html): 위성 인터넷은 전파가 우주를 오가야 해서, 정지궤도 위성은 왕복만 0.5초가 넘고 Starlink 같은 저궤도 위성은 평소엔 빠르지만 경로를 다시 배정하는 순간 지연이 흔들리고 잠깐 끊기기도 합니다.
- [우회 라우팅](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-routing.html): 통신사끼리의 연결 계약 때문에 가까운 서버도 먼 곳을 돌아서 갑니다.
- [피크 시간 피어링 구간 혼잡](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-peak.html): 저녁 9~11시 무렵에는 영상 트래픽이 폭증해 통신사 간 연결 구간(피어링)이 붐비기 쉽습니다.
- [해저 케이블·국제 회선 장애](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-cable.html): 해저 케이블이 끊기면 수리될 때까지 몇 주(길면 몇 달) 동안 먼 우회 경로로 돌아가고, 남은 회선은 붐빕니다.
- [BGP 경로 변경·수렴](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-bgp.html): 인터넷의 경로 정보가 바뀌어 다시 수렴하는 몇 초~몇십 초(드물게 몇 분) 동안 패킷이 유실됩니다.
- [ECMP 경로 하나의 불량](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-ecmp.html): 통신사와 데이터센터는 같은 목적지로 가는 경로를 여러 개 두고 연결마다 경로 하나를 정해 보냅니다. 경로 하나만 고장 나면 그 경로에 배정된 사람만 계속 렉을 겪습니다.
- [통신사 속도 제한·트래픽 관리](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-shaping.html): 데이터 사용량을 넘기거나 특정 트래픽을 관리하는 요금제에서는 패킷이 늦춰지거나 버려집니다.
- [국가·통신사 단위 UDP 제한·패킷 검사](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-udp-block.html): 일부 망은 특정 UDP 주소·포트를 막거나 UDP 속도를 제한하고 패킷 검사 장비가 알아보지 못하는 프로토콜을 걸러 냅니다. UDP로 통신하는 게임은 그 망에서 접속이 안 되거나 자주 끊깁니다.
- [회선 품질 불량](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-line.html): 단자 접촉 불량이나 낡은 선, 모뎀 이상은 꾸준한 손실과 주기적인 회선 끊김을 만듭니다.
- [DNS 장애·지연](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-dns.html): 서버 이름을 주소로 바꿔 주는 DNS가 느리거나 실패하면 로그인·패치 서버를 찾지 못합니다.
- [DDoS로 인한 공유 회선 포화](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-ddos-path.html): 게임사나 같은 망의 다른 곳을 향한 대량 공격이 공유 회선을 가득 채웁니다.
- [통신사 공유 IP (CGNAT)](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-cgnat.html): 모바일망과 일부 통신사는 여러 가입자가 IP 하나를 나눠 쓰며 유휴 연결의 매핑을 짧은 시간 안에 지웁니다.
- [VPN·게임 가속기 경유](https://jungrok5.github.io/mmo-lag-anatomy/c/isp-vpn.html): VPN이나 게임 가속기를 켜면 패킷이 그 회사의 중계 서버를 거쳐 갑니다. 중계 서버가 멀거나 붐비면 오히려 느려집니다.

## L5 데이터센터 네트워크 장비

- [방화벽 세션 테이블 포화](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-firewall.html): 방화벽은 통과시킨 모든 연결을 세션 테이블에 기록해 추적합니다. 테이블이 다 차면 새 연결을 받을 수 없습니다.
- [DDoS 방어 경유·오탐](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-ddos.html): 공격을 막으려고 트래픽을 스크러빙 센터로 돌리면 경로가 길어지고 정상 사용자를 공격으로 오인해 막기도 합니다.
- [로드밸런서 유휴 타임아웃](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-lb-idle.html): 로드밸런서는 유휴 연결을 일정 시간 뒤 지웁니다. 게임은 연결이 유지된다고 여기다가 접속이 끊깁니다.
- [클라우드 보안 그룹의 연결 추적 만료](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-cloud-conntrack.html): 클라우드 서버에 붙은 방화벽(보안 그룹)도 연결을 추적하고 유휴 연결의 추적 항목은 정해진 시간 뒤 만료됩니다. 로드밸런서 없이 바로 붙는 서버에서도 가만히 있던 플레이어의 접속이 끊길 수 있습니다.
- [클라우드 NAT 게이트웨이 연결·포트 한도](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-nat-gateway.html): 사설 서브넷의 서버가 외부(플랫폼 인증·결제·외부 API)로 나가는 연결은 NAT 게이트웨이가 주소와 포트를 바꿔 내보냅니다. 같은 목적지로 가는 동시 연결이 게이트웨이의 포트 한도를 넘으면 새 연결이 실패합니다.
- [로드밸런서 쏠림·헬스체크 오판](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-lb-imbalance.html): 로드밸런서가 한 서버에만 연결을 몰아주거나, 이미 죽은 서버로 계속 사람을 보냅니다.
- [스위치 마이크로버스트](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-microburst.html): 여러 서버가 같은 순간 수천 명에게 패킷을 한꺼번에 보내면, 그 트래픽이 모이는 스위치 포트의 작은 버퍼가 1ms도 안 돼 넘칩니다.
- [데이터센터 회선 포화](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-uplink.html): 패치 배포·로그 전송·백업이 게임과 같은 회선을 쓰면 회선이 꽉 찹니다.
- [네트워크 장비 장애 전환(페일오버)](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-failover.html): 라우터·방화벽 한 대가 고장 나 예비 장비로 전환(페일오버)되는 몇 초 동안 모두가 멈춥니다.
- [불량 케이블·포트 오류](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-bad-cable.html): 광모듈이나 케이블이 불량이면 그 경로를 지나는 패킷이 일정 비율로 깨집니다.
- [MTU 불일치 (큰 패킷만 사라짐)](https://jungrok5.github.io/mmo-lag-anatomy/c/dc-mtu.html): 중간 구간의 MTU(한 번에 보낼 수 있는 크기)가 줄었는데 크기 초과 알림이 막히면, 큰 패킷만 계속 사라집니다.

## L6 서버 네트워크 카드

- [NIC 인터럽트 단일 코어 집중](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-irq.html): NIC가 패킷 도착 인터럽트를 CPU 코어 하나에만 보내면 그 코어가 병목이 됩니다.
- [링 버퍼 부족](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-ring.html): NIC가 패킷을 잠시 담아 두는 링 버퍼가 작으면, 순간적으로 몰릴 때 버퍼가 넘쳐 패킷이 버려집니다.
- [인터럽트 병합 과다](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-coalesce.html): CPU 부담을 줄이려고 패킷을 모았다 한 번에 알리면, 모으는 시간만큼 늦어집니다.
- [클라우드 PPS 한도 초과](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-cloud-pps.html): 클라우드 서버는 종류마다 초당 패킷 수·대역폭 한도가 있고 넘으면 조용히 버립니다.
- [NIC 대역폭 포화](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-saturate.html): 1Gbps·10Gbps 카드의 한계까지 쓰면 송신 대기열이 길어지고 넘친 패킷은 버려집니다.
- [가상화 오버헤드·노이지 네이버](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-noisy.html): 같은 물리 서버의 다른 가상 머신이 네트워크·CPU를 많이 쓰면 내 서버의 처리가 불규칙하게 밀립니다.
- [클라우드 호스트 점검·라이브 마이그레이션](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-host-maintenance.html): 클라우드 사업자가 물리 서버(호스트)를 점검할 때 가상 머신을 다른 호스트로 옮기거나(라이브 마이그레이션) 잠시 멈춥니다. 그동안 서버 전체가 멈추고 멈춘 시간이 길면 연결이 끊깁니다.
- [NIC 드라이버·펌웨어 문제](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-reset.html): 드라이버 버그나 기능 오동작으로 카드가 멈춰 재시작되는 동안 모든 송수신이 끊깁니다.
- [GRO/LRO 병합 대기 지연](https://jungrok5.github.io/mmo-lag-anatomy/c/nic-offload.html): 여러 패킷을 하나로 묶어 CPU 부담을 줄이는 기능입니다. 설정에 따라 작은 게임 패킷이 함께 묶을 다음 패킷을 잠깐 기다리기도 합니다.

## L7 서버 OS (커널)

- [접속 대기열(backlog) 넘침](https://jungrok5.github.io/mmo-lag-anatomy/c/so-backlog.html): 점검 직후 수만 명이 동시에 접속하면, 커널의 접속 대기열(backlog)이 넘쳐 접속 시도가 버려집니다.
- [파일 디스크립터 한도](https://jungrok5.github.io/mmo-lag-anatomy/c/so-fd.html): 연결 하나마다 파일 디스크립터(fd, OS가 열린 파일·소켓에 붙이는 번호)가 필요한데, 한 프로세스가 열 수 있는 fd 수가 제한되어 있습니다.
- [커널 소켓 버퍼 부족](https://jungrok5.github.io/mmo-lag-anatomy/c/so-sockbuf.html): 송수신 버퍼가 작으면 버스트 트래픽이 몰릴 때 UDP로 받은 패킷은 버려지고, TCP 송신은 버퍼에 여유가 없어 막힙니다.
- [스레드 과다와 컨텍스트 스위칭](https://jungrok5.github.io/mmo-lag-anatomy/c/so-context.html): 코어보다 훨씬 많은 스레드를 돌리면 OS가 번갈아 실행시키는 데만 CPU를 씁니다.
- [CPU 스틸 (가상 머신)](https://jungrok5.github.io/mmo-lag-anatomy/c/so-steal.html): 물리 서버(하이퍼바이저)가 가상 머신의 CPU 시간을 잠시 다른 가상 머신에 넘기는 동안(CPU 스틸) 게임 서버가 멈춥니다.
- [컨테이너 CPU 스로틀링 (CFS 쿼터)](https://jungrok5.github.io/mmo-lag-anatomy/c/so-cpu-quota.html): 컨테이너에 CPU 한도를 걸면, 정해진 주기(보통 100ms) 안에 할당량을 다 쓴 순간 남은 시간 동안 강제로 멈춥니다(스로틀링).
- [서버 전원 관리(C-state·주파수 조절)로 지연 튐](https://jungrok5.github.io/mmo-lag-anatomy/c/so-cstate.html): 쉬는 CPU 코어는 전기를 아끼려고 깊은 절전 상태(C-state)로 들어가고 주파수도 낮춥니다. 패킷이나 타이머가 오면 깨어나고 주파수를 올리는 데 시간이 걸려, 작은 패킷 처리에 지연이 더해집니다.
- [OOM 킬러](https://jungrok5.github.io/mmo-lag-anatomy/c/so-oom.html): 리눅스는 메모리가 바닥나면 메모리를 가장 많이 쓰는 프로세스를 골라 강제로 죽입니다. 대개 게임 서버입니다.
- [메모리 회수·컴팩션으로 인한 멈춤](https://jungrok5.github.io/mmo-lag-anatomy/c/so-reclaim.html): OS가 큰 페이지(huge page)를 만들려고 메모리를 컴팩션하거나 여유 메모리를 회수하는 동안 프로세스가 멈춥니다.
- [시스템 시계 점프 (NTP 스텝)](https://jungrok5.github.io/mmo-lag-anatomy/c/so-timejump.html): 서버 시계가 한 번에 몇 초 앞뒤로 조정되면 시스템 시계에 의존하는 타이머가 한꺼번에 발동하거나 멈춥니다.
- [예약 작업](https://jungrok5.github.io/mmo-lag-anatomy/c/so-cron.html): 매일 같은 시각에 도는 로그 압축·백업·보안 검사가 CPU와 디스크를 차지합니다.
- [OS·커널·드라이버·펌웨어 업데이트 뒤 성능 변화](https://jungrok5.github.io/mmo-lag-anatomy/c/so-os-update.html): 게임 코드는 그대로인데 서버 OS·커널·드라이버·펌웨어를 업데이트한 뒤부터 서버가 느려집니다. 업데이트로 기본값, 스케줄러, CPU 취약점 완화(mitigations), 드라이버 동작이 바뀌기도 합니다.
- [서버 conntrack 테이블 포화](https://jungrok5.github.io/mmo-lag-anatomy/c/so-conntrack.html): 리눅스 방화벽이 모든 연결을 기록하는 연결 추적(conntrack) 테이블이 한도에 닿으면 새 패킷을 버립니다.
- [서버 간 연결의 임시 포트 고갈](https://jungrok5.github.io/mmo-lag-anatomy/c/so-ports.html): 게임 서버가 DB나 다른 서버에 연결을 짧게 자주 맺고 끊으면, 끊긴 연결이 한동안 포트를 점유해 새 연결을 못 엽니다.

## L8 소켓과 프로토콜

- [TCP HOL 블로킹](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-hol.html): TCP는 순서를 지키려고 잃어버린 패킷 하나를 다시 받을 때까지 뒤에 도착한 패킷을 게임에 넘기지 않습니다.
- [TCP RTO와 지수 백오프](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-rto.html): 재전송이 또 실패할 때마다 기다리는 시간이 두 배로 늘어, 짧은 회선 끊김이 긴 멈춤이 됩니다.
- [Nagle 알고리즘 + 지연 ACK](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-nagle.html): 작은 패킷을 모아 보내는 Nagle 알고리즘과 ACK를 늦게 보내는 지연 ACK가 맞물려, 메시지를 나눠 쓸 때마다 40~200ms씩 지연됩니다.
- [느린 클라이언트로 인한 블로킹 전송](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-block-send.html): 회선이 느린 한 명의 송신 버퍼가 가득 찼는데 블로킹 방식(버퍼에 여유가 생길 때까지 호출이 반환되지 않는 전송)으로 보내면, 서버 스레드가 그 한 명을 기다립니다.
- [느린 클라이언트(slow consumer) 처리 정책](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-slow-client.html): 보낼 게 계속 쌓이는 클라이언트에게 서버가 오래된 업데이트를 버리거나 연결을 끊습니다.
- [keepalive 기본값 2시간](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-keepalive.html): 상대가 종료 신호 없이 사라지면 TCP는 한참 뒤에야 감지합니다. keepalive(유휴 연결이 살아 있는지 확인하는 TCP 기능)는 기본으로 꺼져 있고, 켜도 2시간 동안 유휴 상태여야 확인을 시작합니다.
- [UDP 패킷의 IP 단편화](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-fragment.html): MTU(한 번에 보낼 수 있는 크기)를 넘는 UDP 패킷은 IP 계층에서 단편화되고, 프래그먼트 하나만 잃어도 전체가 버려집니다.
- [신뢰성 UDP 재전송 설정](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-reliable-udp.html): UDP 위에 직접 만든 재전송 규칙이 너무 보수적이면 복구가 늦고 너무 공격적이면 회선을 더 막습니다.
- [유휴 후 슬로 스타트](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-slowstart.html): TCP는 한동안 유휴 상태면 혼잡 윈도우(한 번에 보낼 수 있는 양)를 다시 줄여, 갑자기 큰 데이터를 보낼 때 여러 번에 나눠 보냅니다.
- [혼잡 제어로 전송량 급감](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-congestion.html): TCP는 손실을 혼잡 신호로 보고 전송 속도를 30~50% 줄입니다. 와이파이 손실에도 똑같이 반응합니다.
- [RST 강제 종료로 마지막 데이터 유실](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-linger.html): 서버가 연결을 급히 끊으면 마지막으로 보낸 안내나 저장 완료 신호가 사라집니다.
- [블로킹 I/O 구조](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-blocking-io.html): 소켓 하나를 기다리는 동안 스레드가 다른 일을 못 하는 구조에서는 사람이 늘수록 전체가 느려집니다.
- [SO_REUSEPORT 분배 쏠림](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-reuseport.html): 같은 포트를 여러 프로세스가 나눠 받으면, 커널은 접속마다 주소 해시로 담당 프로세스를 정해 두고 바꾸지 않습니다. 담당 프로세스 하나가 멈추면 거기에 배정된 사람만 기다립니다.
- [윈도우 UDP 소켓의 WSAECONNRESET 오류](https://jungrok5.github.io/mmo-lag-anatomy/c/sk-udp-connreset.html): 윈도우 서버가 이미 떠난 클라이언트에게 UDP를 보내면 “포트 없음”(ICMP) 알림이 돌아옵니다. 그 알림 때문에 다음 수신 호출이 오류로 끝나는데 서버 코드가 이 오류를 소켓 자체의 고장으로 처리하면 그 소켓을 쓰는 모두가 영향을 받습니다.

## L9 서버 게임 프로세스

- [틱 예산 초과](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-tick-overrun.html): 한 틱 안에 할 일이 예산을 넘으면 서버의 틱 주기가 늘어지고 그 지역 전체가 느리게 흐르거나 뚝뚝 끊깁니다.
- [시야(AOI) 계산 폭증 (N²)](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-aoi.html): 누가 누구를 볼 수 있는지 모두끼리 비교하면, 인원이 10배가 될 때 계산은 100배가 됩니다.
- [브로드캐스트 폭증](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-broadcast.html): 한 명의 움직임을 그를 보는 모두에게 보내면, 모인 인원의 제곱만큼 보낼 업데이트가 생깁니다.
- [단일 스레드 지역 과부하(핫스팟)](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-hotzone.html): 지역마다 스레드 하나가 맡는 구조에서 한곳에 사람이 몰리면 그 코어 하나만 100%가 됩니다.
- [락 경합](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-lock.html): 여러 스레드가 같은 데이터를 쓰려고 락 하나를 기다리면, 스레드를 늘려도 한 번에 하나씩만 실행됩니다.
- [데드락](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-deadlock.html): 두 스레드가 서로 상대가 잡은 락을 기다리면 영원히 멈춥니다.
- [게임 스레드의 동기 호출](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-sync-call.html): 틱 도중 DB 응답이나 파일 쓰기를 기다리면, 그 시간만큼 서버의 게임 진행 전체가 멈춥니다.
- [메시지 큐 적체](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-queue.html): 요청이 처리 속도보다 빨리 들어와 대기열에 쌓이면, 뒤쪽 요청은 몇 초 뒤에야 처리되거나 버려집니다.
- [타이머 동시 발동 몰림](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-timer-burst.html): 모든 몬스터 리스폰, 모든 버프 만료, 정각 보상이 같은 틱에 몰리면 그 틱만 수십 배 무거워집니다.
- [길찾기 폭주](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-pathfinding.html): 수백 마리 몬스터가 동시에 플레이어를 쫓으며 경로를 계산하면 CPU를 크게 씁니다.
- [직렬화·압축 비용](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-serialize.html): 보낼 데이터를 바이트로 바꾸고 압축하는 데도 CPU가 들고 사람이 많으면 이 비용이 폭증합니다.
- [서버 크래시](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-crash.html): 처리하지 못한 오류로 서버 프로세스가 죽으면, 그 서버에 있던 모두의 접속이 동시에 끊깁니다.
- [스레드 풀 고갈](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-threadpool.html): 작업을 처리할 워커 스레드가 모두 느린 작업에 묶이면 새 요청은 무작정 기다립니다.
- [무한 루프·로직 폭주](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-infinite-loop.html): 버그로 한 틱이 끝나지 않으면 서버가 멈추고 워치독이 강제로 재시작합니다.
- [한 대상에 몰린 전투 (월드 보스)](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-hot-entity.html): 수백 명이 보스 하나를 동시에 때리면, 보스 한 마리의 계산이 한곳에 몰리고 타격 정보가 보는 모두에게 전송됩니다.
- [밀집 지역 진입 시 스폰 폭주](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-spawn-burst.html): 사람이 가득한 마을로 텔레포트하면, 서버는 새로 보이게 된 수백 명의 외형·장비·상태를 한꺼번에 보내야 합니다.
- [개체 누적 (정리되지 않은 아이템·소환물)](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-entity-buildup.html): 사라져야 할 바닥 아이템, 소환물, 끝난 타이머가 정리되지 않고 쌓이면, 서버를 오래 켜 둘수록 매 틱 할 일이 늘어납니다.
- [패치로 트래픽 패턴이 바뀜](https://jungrok5.github.io/mmo-lag-anatomy/c/sp-patch-traffic.html): 새 콘텐츠·이펙트·동기화 항목이 패킷 크기와 빈도를 늘리면, 잘되던 서버가 패치 뒤부터 MTU·대역폭·패킷 수 한도에 걸립니다.

## L10 메모리

- [서버 GC 전체 멈춤](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-gc.html): Java·C# 서버가 가비지를 수집하려고 모든 스레드를 멈추는 동안(stop-the-world) 서버 전체가 멈춥니다.
- [스크립트 엔진의 GC 멈춤](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-script-gc.html): C++ 서버라도 퀘스트·AI·스킬을 Lua 같은 스크립트로 돌리면, 스크립트 엔진의 GC가 도는 동안 그 존이 멈춥니다.
- [할당 폭주](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-alloc.html): 이벤트 중 임시 객체를 대량으로 만들면 GC가 평소보다 훨씬 자주 돕니다.
- [메모리 누수](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-leak.html): 해제되지 않는 메모리가 조금씩 쌓이면 며칠 뒤 GC 폭주·스왑·강제 종료가 일어납니다.
- [GC 스래싱 (힙 여유 부족)](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-gc-thrash.html): 살아 있는 데이터가 힙 한도에 가까워지면, GC가 돌아도 회수할 것이 거의 없어 GC가 쉬지 않고 반복됩니다.
- [스왑](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-swap.html): 메모리가 모자라 OS가 일부를 디스크로 내보내면, 그 메모리를 쓸 때마다 1,000배 넘게 느린 디스크를 기다립니다.
- [캐시 미스](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-cache-miss.html): 데이터가 메모리 여기저기 흩어져 있으면 CPU가 매번 느린 RAM까지 가서 기다립니다.
- [메모리 단편화](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-fragment.html): 할당과 해제를 반복해 빈 공간이 잘게 쪼개지면, 실제로 쓰는 양보다 훨씬 많은 메모리를 점유합니다.
- [NUMA 원격 메모리](https://jungrok5.github.io/mmo-lag-anatomy/c/mem-numa.html): CPU가 두 개인 서버에서 반대편 CPU에 붙은 메모리를 쓰면 접근이 느려집니다.

## L11 디스크

- [동기 로그 쓰기](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-sync-log.html): 게임 스레드가 로그 한 줄마다 디스크 완료를 기다리면, 디스크가 바쁠 때 게임 진행도 같이 멈춥니다.
- [fsync 폭주](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-fsync.html): 데이터를 “확실히” 디스크에 쓰도록 요청하면 디스크에 따라 한 번에 0.1ms~수십 ms가 걸리고, 몰리면 대기열이 길어집니다.
- [클라우드 디스크 버스트 크레딧 소진](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-burst.html): 일부 클라우드 디스크와 작은 서버 사양은 잠깐 기준보다 빠르게 쓸 수 있는 버스트 크레딧이 있어서, 바쁜 시간이 길어져 크레딧이 바닥나면 속도가 갑자기 떨어집니다.
- [IOPS 한도·대기열 포화](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-iops.html): 디스크가 1초에 처리할 수 있는 요청 수를 넘으면 대기열이 길어져 지연이 폭증합니다.
- [디스크 가득 참](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-full.html): 로그와 덤프가 쌓여 디스크가 가득 차면 쓰기가 실패하고 대비가 없으면 서버가 죽습니다.
- [백업·압축·검사 작업](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-backup.html): 새벽 백업, 로그 압축, 보안 검사가 디스크를 독점하면 게임 서버의 읽기·쓰기가 밀립니다.
- [서버의 지연 로딩](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-lazy-load.html): 서버가 던전·맵 데이터를 처음 요청받을 때 디스크에서 읽으면, 그 틱 동안 모두가 멈춥니다.
- [코어 덤프 기록](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-coredump.html): 서버가 죽을 때 수 GB 메모리를 디스크에 기록하느라 재시작이 몇 분씩 늦어지기도 합니다.
- [HDD 탐색 지연](https://jungrok5.github.io/mmo-lag-anatomy/c/dk-hdd.html): HDD는 헤드가 플래터 위를 움직여야(탐색, seek) 해서 흩어진 데이터를 읽고 쓰는 데 한 번에 10ms 가까이 걸립니다.

## L12 데이터베이스

- [인덱스 없는 쿼리](https://jungrok5.github.io/mmo-lag-anatomy/c/db-no-index.html): 인덱스 없이 조건에 맞는 행을 찾으려면 테이블 전체를 읽어야 합니다(풀 스캔).
- [핫 로우 잠금 경합](https://jungrok5.github.io/mmo-lag-anatomy/c/db-hot-row.html): 모두가 같은 행(길드 창고, 경매장 인기 아이템, 서버 전체 카운터)을 고치려 하면 한 명씩만 잠금을 얻습니다.
- [DB 데드락](https://jungrok5.github.io/mmo-lag-anatomy/c/db-deadlock.html): 두 트랜잭션(한 묶음으로 처리되는 DB 작업)이 서로 상대가 잠근 행을 기다리면 DB가 한쪽을 강제로 취소합니다.
- [커넥션 풀 고갈](https://jungrok5.github.io/mmo-lag-anatomy/c/db-pool.html): DB와 맺어 둔 연결 수가 정해져 있어서 느린 쿼리가 연결을 점유하면 나머지는 대기합니다.
- [복제 지연](https://jungrok5.github.io/mmo-lag-anatomy/c/db-replica-lag.html): 쓰기는 주 DB에, 읽기는 복제본에서 하는데 복제본이 늦게 따라오면 방금 쓴 내용이 안 보입니다.
- [체크포인트·로그 플러시](https://jungrok5.github.io/mmo-lag-anatomy/c/db-checkpoint.html): DB가 메모리의 변경분을 주기적으로 디스크에 몰아서 쓰는 순간 쿼리가 느려집니다.
- [콜드 캐시 (재시작 직후)](https://jungrok5.github.io/mmo-lag-anatomy/c/db-cold-cache.html): DB를 재시작하면 메모리 캐시가 비어 있어서 한동안 조회하는 데이터를 모두 디스크에서 읽습니다.
- [로그인 폭주와 N+1 쿼리](https://jungrok5.github.io/mmo-lag-anatomy/c/db-login-storm.html): 캐릭터 하나를 불러올 때 수십 번 따로 조회하면, 수만 명 동시 로그인이 쿼리 수백만 개가 됩니다.
- [대량 배치 작업](https://jungrok5.github.io/mmo-lag-anatomy/c/db-batch.html): 랭킹 집계, 우편 일괄 발송, 오래된 데이터 정리를 운영 중에 돌리면 잠금과 디스크를 차지합니다.
- [DB 장애 전환](https://jungrok5.github.io/mmo-lag-anatomy/c/db-failover.html): 주 DB가 죽어 예비 DB로 전환되는 동안 쓰기가 안 되고 복제되지 못한 마지막 데이터는 사라질 수 있습니다.
- [긴 저장 주기로 인한 진행 유실](https://jungrok5.github.io/mmo-lag-anatomy/c/db-save-interval.html): 부하를 줄이려 몇 분에 한 번만 저장하면, 그 사이 서버가 죽을 때 진행이 사라집니다.
- [캐시 스탬피드](https://jungrok5.github.io/mmo-lag-anatomy/c/db-cache-stampede.html): 인기 데이터의 캐시가 동시에 만료되면 수천 개 요청이 한꺼번에 DB로 몰립니다.
- [오래 열린 트랜잭션](https://jungrok5.github.io/mmo-lag-anatomy/c/db-long-tx.html): 트랜잭션 하나가 오래 열려 있으면 잠금을 계속 잡고 있고 DB가 옛 버전 데이터를 정리(purge)하지 못해 전체가 점점 느려집니다.
- [Redis 느린 명령](https://jungrok5.github.io/mmo-lag-anatomy/c/db-redis-block.html): Redis는 명령을 한 번에 하나씩 처리해서 느린 명령 하나가 그 뒤의 모든 요청을 막습니다.
- [실행 계획 변경으로 인한 쿼리 지연](https://jungrok5.github.io/mmo-lag-anatomy/c/db-plan-flip.html): 코드는 그대로인데 DB가 같은 쿼리를 처리하는 방법(실행 계획)을 바꾸면, 어제 2ms였던 쿼리가 오늘 수백 ms가 됩니다.
- [운영 중 스키마 변경(DDL) 잠금](https://jungrok5.github.io/mmo-lag-anatomy/c/db-ddl-lock.html): 서비스 중에 테이블에 컬럼이나 인덱스를 추가하면, 잠깐 필요한 잠금 하나 때문에 그 테이블을 쓰는 모든 요청이 대기할 수 있습니다.

## L13 서버 구성과 운영

- [게이트웨이·프록시 경유](https://jungrok5.github.io/mmo-lag-anatomy/c/in-gateway.html): 클라이언트와 게임 서버 사이에 중간 서버를 두면, 한 번 거칠 때마다 처리 시간이 붙고 그 서버가 단일 장애 지점이 됩니다.
- [존 이동 (서버 간 이관)](https://jungrok5.github.io/mmo-lag-anatomy/c/in-zone-transfer.html): 다른 지역·던전에 들어갈 때 캐릭터 정보를 다른 서버로 넘기는 과정에서 지연과 실패가 생깁니다.
- [연쇄 장애](https://jungrok5.github.io/mmo-lag-anatomy/c/in-cascade.html): 한 서비스가 느려지면 그걸 부르는 서버들이 응답을 기다리며 묶이고 상관없는 기능까지 멈춥니다.
- [부가 서버 장애](https://jungrok5.github.io/mmo-lag-anatomy/c/in-subservice.html): 채팅·파티·경매장처럼 게임 서버와 따로 도는 서버에 장애가 나면 그 기능만 동작하지 않습니다.
- [배포·재시작](https://jungrok5.github.io/mmo-lag-anatomy/c/in-deploy.html): 업데이트하려고 서버를 재시작할 때 연결을 옮기지 않으면 그 서버에 있던 사람들의 접속이 끊기고, 종료 직전 저장과 재접속이 한꺼번에 몰립니다.
- [오토스케일링 지연](https://jungrok5.github.io/mmo-lag-anatomy/c/in-autoscale.html): 사람이 몰리면 서버를 자동으로 늘리지만 준비에 몇 분이 걸리고 그동안 기존 서버가 과부하입니다.
- [로그·모니터링 과부하](https://jungrok5.github.io/mmo-lag-anatomy/c/in-monitoring.html): 장애가 나면 로그가 폭증하고 로그를 동기로 넘기는 서버는 로그 때문에 더 느려집니다.
- [서버 간 시계 차이](https://jungrok5.github.io/mmo-lag-anatomy/c/in-clock-skew.html): 서버마다 시계가 조금씩 다르면 쿨타임·버프·이벤트 시작 판정이 서버마다 어긋납니다.
- [매크로·봇 과다](https://jungrok5.github.io/mmo-lag-anatomy/c/in-bots.html): 봇은 사람보다 훨씬 자주 요청을 보내 서버 처리량을 잠식합니다.
- [외부 서비스 의존](https://jungrok5.github.io/mmo-lag-anatomy/c/in-external.html): 플랫폼 로그인, 결제, 본인 인증 같은 외부 서비스가 느리거나 멈추면 그 단계에서 막힙니다.
- [매치메이킹·리전 배정 오류](https://jungrok5.github.io/mmo-lag-anatomy/c/in-region-match.html): 가까운 리전 대신 먼 리전의 서버에 배정되면, 회선이 멀쩡해도 그 유저만 핑이 늘 높습니다.
- [TLS 인증서 만료·설정 오류](https://jungrok5.github.io/mmo-lag-anatomy/c/in-cert.html): 로그인·API·패치 서버의 인증서가 만료되거나 중간 인증서가 빠지면, 그 순간부터 새로 연결하는 클라이언트의 TLS 연결이 실패합니다.
- [로그인 대기열 상한·재접속 유예 부족](https://jungrok5.github.io/mmo-lag-anatomy/c/in-login-queue.html): 출시·점검 직후 접속이 몰리면 로그인 대기열이 상한에 닿아 새 대기를 거절하고, 기다리던 유저는 잠깐 끊긴 사이 자리를 잃어 맨 뒤로 돌아갑니다.

## 동기화 설계

- [서버 응답 후에만 연출 (요청-응답 방식)](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-request-response.html): 버튼을 누르면 서버 답이 올 때까지 애니메이션도 소리도 없습니다. 핑이 곧 반응 속도가 됩니다.
- [순차 왕복이 많은 프로토콜 (chatty)](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-chatty.html): 조작 한 번에 서버 왕복이 여러 번 순서대로 필요하면, 핑이 그 횟수만큼 곱해집니다.
- [스킬 선입력 없음](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-no-queue.html): 앞 스킬이 서버에서 끝났다는 확인을 받아야 다음 스킬을 누를 수 있으면, 연계마다 왕복 시간이 끼어듭니다.
- [핑에 먹히는 짧은 판정 구간](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-short-window.html): 회피·패링·가드처럼 반응해야 하는 시간이 짧으면, 핑이 그 시간을 먹어 버려 피할 수 없는 공격이 생깁니다.
- [지연 보상 없는 판정](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-no-lagcomp.html): 서버가 “지금 서버에 있는 위치”로만 명중을 판정하면, 내가 본 화면과 판정이 어긋납니다.
- [지연 보상 과다](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-lagcomp-overreach.html): 공격자 기준으로 너무 멀리 되감아 주면, 맞는 쪽은 이미 숨었는데도 맞습니다.
- [클라이언트 권위](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-client-auth.html): 각자 자기 결과를 결정하면 내 화면은 쾌적하지만 다른 사람 화면과 결과가 어긋나고 해킹에 약합니다.
- [락스텝에서 가장 느린 플레이어 대기](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-lockstep.html): 모두가 같은 턴을 함께 계산하는 구조에서는, 한 명의 입력이 늦으면 모두가 기다립니다.
- [롤백 넷코드의 예측 실패](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-rollback.html): 상대 입력을 예측해 먼저 보여 주다가 틀리면 되감아 다시 계산합니다. 핑이 클수록 되감는 폭이 커집니다.
- [타임스탬프 없는 도착 즉시 재생](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-no-timestamp.html): 서버 이벤트에 발생 시각을 붙이지 않고 받자마자 재생하면, 네트워크 지터 때문에 연출 타이밍이 그대로 들쭉날쭉해집니다.
- [이중 틱 대기](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-double-tick.html): 요청을 다음 틱까지 모았다가 처리하고 결과도 그다음 틱에 보내면 틱 간격이 두 번 더해집니다.
- [너무 엄격한 서버 검증](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-strict-check.html): 이동 속도·쿨타임·사거리를 서버가 너무 엄격하게 검사하면, 지터로 몰려 온 정상 입력까지 거절합니다.
- [호스트(방장) 구조](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-host.html): 한 플레이어의 PC가 서버 역할을 하면, 그 사람의 회선과 PC 성능이 모두의 체감을 정합니다.
- [선연출 뒤 서버 거절](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-optimistic-reject.html): 내 화면에서 먼저 보여 준 타격·스킬을 서버가 나중에 인정하지 않으면, 분명히 본 결과가 없던 일이 됩니다.
- [명령 동기화의 경로 계산 불일치](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-path-mismatch.html): “여기로 가라”만 주고받고 경로는 양쪽이 각자 계산하면, 계산이 조금만 달라도 캐릭터나 몬스터가 다른 경로로 가다가 제자리로 끌려옵니다.
- [낮은 스냅샷 전송률](https://jungrok5.github.io/mmo-lag-anatomy/c/sy-low-send-rate.html): 서버가 위치 업데이트(스냅샷)를 1초에 몇 번만 보내면 보간 버퍼를 그만큼 길게 잡아야 해서, 다른 캐릭터를 더 먼 과거로 봅니다.

## 일부에게만 생기는 문제

- [느린 사람이 남의 화면에서 몰아서 움직임](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-slow-burst.html): 회선이 나쁜 사람의 입력은 들쭉날쭉 몰려서 서버에 도착합니다. 서버가 틱마다 받은 만큼 적용하면, 다른 사람 눈에는 그 캐릭터가 멈칫했다가 한 번에 여러 걸음을 갑니다.
- [도착 즉시 처리하는 서버의 몰아치기](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-event-server.html): 패킷이 도착하는 대로 바로 처리하고 알리는 서버에서는, 느린 사람의 몰려 온 행동이 연달아 즉시 실행됩니다.
- [플레이어별 입력 버퍼 크기](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-input-buffer.html): 서버가 사람마다 입력을 조금 모아 두었다가 한 틱에 하나씩 꺼내 쓰면, 다른 사람 눈에는 매끄럽지만 본인 행동이 서버에서 확정되는 시점은 그만큼 늦어집니다.
- [특정 통신사 사용자에게 몰리는 검증 오탐](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-isp-validation.html): 지터가 큰 회선을 쓰는 사람들은 입력이 몰려 도착해서 서버의 속도·쿨타임 검사에 자주 걸립니다.
- [느린 파티원 한 명과 보스 기믹](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-raid-member.html): 모두가 정해진 순간에 함께 반응해야 하는 레이드 기믹에서는, 느린 한 사람의 늦은 반응이 파티 전체의 실패가 됩니다.
- [몬스터 제어 권한이 느린 클라이언트에 있음](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-mob-control.html): 서버 부하를 줄이려고 몬스터 이동 계산을 근처 플레이어 한 명의 클라이언트에 맡기는 게임이 있습니다. 그 사람 회선이 나쁘면 그 몬스터가 모두의 화면에서 이상하게 움직입니다.
- [특정 캐릭터의 데이터가 비대함](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-heavy-char.html): 아이템·우편이 수천 개 쌓였거나 친구·차단 목록, 버프가 유난히 많은 캐릭터는 접속하고 저장하고 주변에 알릴 양이 남보다 몇 배 큽니다. 회선과 상관없이 그 캐릭터로만 느립니다.
- [채널·인스턴스·페이즈 차이](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-phase.html): 두 캐릭터가 다른 채널이나 인스턴스에 있거나, 퀘스트 진행도에 따라 보이는 NPC가 다른 “페이즈”에 있으면 서로 다른 세상을 봅니다.
- [로딩 중 도착한 등장 알림 폐기](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-loading-drop.html): 존에 들어가자마자 서버가 주변 NPC 등장 알림을 보내는데 클라이언트가 아직 맵을 불러오는 중이라 그 알림을 버립니다.
- [시야 등록 순서 꼬임](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-aoi-race.html): 캐릭터가 시야 격자에 등록되는 순간과 NPC가 격자를 옮기는 순간이 겹치면, 그 NPC의 등장 알림이 누락될 수 있습니다.
- [기준 스냅샷 유실](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-baseline.html): 서버가 “지난번과 달라진 것만” 보내는 방식에서, 처음 한 번 보내는 전체 정보(기준)를 잃으면 그 뒤 변화분을 적용할 수 없습니다.
- [퇴장 알림 유실 (유령 개체)](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-ghost.html): “사라졌다”는 알림을 놓치면, 이미 죽었거나 떠난 NPC·플레이어가 내 화면에만 남습니다.
- [입장 직후 몰리는 등장 정보 유실](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-spawn-burst.html): 존에 들어서는 순간 서버는 주변 개체 수십~수백 개의 등장 정보를 한꺼번에 보냅니다. 이 정보를 비신뢰(unreliable) 채널로 보내거나, 로딩 중이라 소켓을 못 읽는 사이 수신 버퍼가 넘치면 일부가 사라지고 다시 오지 않습니다.
- [개체 ID 재사용 혼동](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-id-reuse.html): 죽은 NPC가 다시 나타날 때 서버가 같은 개체 ID를 다시 쓰면, 그 사이 퇴장 알림을 놓친 클라이언트는 새 NPC를 옛 NPC로 오인합니다.
- [고정 UDP 포트 충돌](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-port-collision.html): 클라이언트가 정해진 로컬 포트를 쓰도록 만들어져 있으면, 같은 PC의 두 번째 클라이언트는 포트를 못 쓰거나 첫 번째와 패킷을 나눠 받습니다.
- [IP·기기 기준 세션 구분 버그](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-session-key.html): 서버나 중간 서버가 연결을 IP나 기기 ID로 구분하면, 같은 PC(같은 공인 IP)의 두 클라이언트를 한 사람으로 인식합니다.
- [멀티 클라이언트 제한](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-multiclient.html): 보안 모듈이나 서버 정책이 한 PC의 여러 클라이언트를 제한하면, 두 번째 클라이언트는 실행·접속이 막히거나 먼저 켠 쪽의 접속이 끊깁니다. 일부 게임은 추가 클라이언트의 기능만 막습니다.
- [백그라운드 창의 처리 제한](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-background.html): 클라이언트 창이 백그라운드에 있으면 게임·엔진·OS가 그 클라이언트의 프레임과 처리를 줄입니다. 받은 패킷을 제때 처리하지 못해 밀리거나 넘칩니다.
- [캐시·에셋 파일 동시 접근 충돌](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-asset-lock.html): 두 클라이언트가 같은 캐시 폴더에 동시에 쓰거나 파일을 잠그면, 한쪽이 NPC 모델·텍스처를 못 불러옵니다.
- [메모리·VRAM 부족으로 스트리밍 실패](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-vram.html): 클라이언트 두 개가 그래픽 메모리를 나눠 쓰면, 새로 필요한 모델·텍스처를 올릴 자리가 없어 일부가 안 그려집니다.
- [표시 옵션 차이](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-display-option.html): 표시 인원 제한, NPC 이름표·모델 숨김, 저사양 모드 같은 옵션이 두 클라이언트에서 다르면 보이는 것이 다릅니다.
- [클라이언트 버전·데이터 불일치](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-version.html): 두 번째 클라이언트가 다른 설치본이거나 패치가 덜 되었으면, 서버가 보낸 새 NPC ID를 몰라 조용히 무시합니다.
- [연결별 전송 예산·우선순위](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-priority.html): 서버가 연결마다 보낼 양에 한도를 두고 가까운 것부터 보내면, 한도가 낮게 잡힌 쪽은 멀리 있는 NPC를 늦게 받거나 못 받습니다.
- [시계 추정 오차로 개체 보류](https://jungrok5.github.io/mmo-lag-anatomy/c/pt-clock-hold.html): 클라이언트가 추정한 서버 시각이 틀리면, 막 도착한 개체 정보를 “아직 미래”라며 보류하거나 “너무 옛날”이라며 버립니다.

## TCP 재전송의 근본 원인

- [무선 구간 손실](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-wireless.html): 와이파이와 모바일망은 무선 구간에서 몇 번 재전송하다가, 그래도 안 되면 패킷을 버립니다. 버려진 패킷은 TCP가 한참 뒤에 다시 보냅니다.
- [병목 대기열 넘침 (혼잡 손실)](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-queue-drop.html): 공유기, 통신사 사이 연결 구간, 데이터센터 회선처럼 가장 좁은 곳의 대기열이 가득 차면 새로 오는 패킷을 버립니다.
- [송신 버스트로 얕은 버퍼 넘침](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-burst.html): 서버가 틱마다 수천 명분 업데이트를 한순간에 몰아 보내면, 스위치의 작은 버퍼나 클라우드의 순간 한도가 1ms도 안 돼 넘쳐 일부가 버려집니다.
- [폴리서의 초과분 폐기](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-policer.html): 통신사 요금제, 클라우드 인스턴스 한도, DDoS 방어 장비는 정해진 속도를 넘는 패킷을 대기열에 넣지 않고 즉시 버리기도 합니다.
- [물리 오류 (불량 선·광모듈·커넥터)](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-physical.html): 케이블 손상, 먼지 낀 광커넥터, 수명이 다한 광모듈은 비트 오류를 만들고 깨진 패킷은 장비가 조용히 버립니다.
- [듀플렉스 불일치](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-duplex.html): 한쪽은 자동 협상, 다른 쪽은 속도·듀플렉스를 고정해 두면 한쪽이 반이중으로 동작하며 부하가 걸릴 때마다 충돌로 패킷을 잃습니다.
- [수신 서버 호스트의 패킷 폐기](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-host-drop.html): 패킷은 서버까지 왔는데 NIC의 링 버퍼(도착한 패킷을 잠시 담아 두는 버퍼)가 넘치거나, 커널의 수신 처리 코어가 포화되어 버려집니다.
- [방화벽·연결 추적의 폐기](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-stateful-fw.html): 방화벽이나 리눅스 연결 추적(conntrack, 지나가는 연결을 테이블에 기록하는 기능)은 테이블이 가득 차거나, 연결 상태가 맞지 않는다고 판단하면 패킷을 버립니다.
- [중간 장비 처리 한도 초과 (방화벽·IPS·DDoS 방어)](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-appliance-pps.html): 방화벽, 침입 방지 장비(IPS), DDoS 방어 장비는 지나가는 패킷을 하나하나 검사합니다. 검사 능력을 넘는 순간부터 처리하지 못한 패킷을 버립니다.
- [MTU 블랙홀 (큰 패킷만 반복 손실)](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-mtu.html): 중간 구간이 받을 수 있는 크기가 작아졌는데 “너무 크다”는 알림(ICMP)이 막히면, 큰 패킷은 몇 번을 다시 보내도 계속 사라집니다.
- [연결 도중 NAT·로드밸런서 매핑 만료](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-mapping.html): 유휴 연결의 매핑(이 연결을 어디로 전달할지 기록한 항목)을 중간 장비가 지우면, 다음에 보내는 패킷은 전달되지 못합니다. 재전송만 반복하다 접속이 끊기거나, 장비가 연결 거부(RST)를 돌려보내 곧바로 끊깁니다.
- [경로 변경·ECMP 불량 경로](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-path.html): 인터넷 경로가 바뀌는 몇 초 동안, 또는 여러 ECMP 경로 중 불량인 경로에 배정된 연결에서 패킷이 사라집니다.
- [지연 급등으로 인한 불필요한 재전송](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-spurious-delay.html): 패킷은 사라지지 않고 잠깐 아주 늦게 도착했을 뿐인데, 그 지연이 RTO보다 길면 보내는 쪽이 손실로 판단해 재전송합니다.
- [순서 뒤바뀜으로 인한 불필요한 빠른 재전송](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-reorder.html): 여러 경로나 묶인 링크를 지나며 패킷 순서가 바뀌면, 받는 쪽이 중복 ACK로 “빠진 패킷 있음”을 알리고 보내는 쪽은 멀쩡한 패킷을 다시 보냅니다.
- [ACK가 늦거나 사라짐 (업로드 포화)](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-ack-path.html): 데이터는 잘 도착했는데 “받았다”는 ACK가 꽉 찬 업로드 대기열에서 늦어지거나 사라지면, 보내는 쪽이 손실로 판단해 재전송합니다.
- [RTO 설정이 환경과 맞지 않음](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-rto-setting.html): RTO 최소값을 너무 낮추면 조금만 늦어도 불필요한 재전송이 나고 기본값(200ms)은 게임 입장에서 너무 길어 한 번 잃을 때마다 오래 멈춥니다.
- [thin stream의 느린 복구](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-thin.html): 게임처럼 작은 패킷을 드문드문 보내면 “뒤따르는 패킷 3개”가 모이기 전에 RTO가 먼저 옵니다. 대용량 전송보다 같은 손실에 훨씬 오래 멈춥니다.
- [중간 장비의 TCP 옵션 제거](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-sack-stripped.html): 일부 방화벽·가속 장비가 TCP 옵션을 지우거나 고치면, 여러 개를 잃었을 때 한 왕복에 하나씩만 복구하거나 윈도우(한 번에 보낼 수 있는 양)가 작아져 느려집니다.
- [제로 윈도우 (재전송처럼 보이는 멈춤)](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-zero-window.html): 받는 쪽 프로그램이 소켓을 제때 읽지 않아 버퍼가 가득 차면, 보내는 쪽은 전송을 멈추고 제로 윈도우 프로브만 보냅니다. 회선 문제가 아닙니다.
- [접속 요청(SYN) 재전송](https://jungrok5.github.io/mmo-lag-anatomy/c/rt-syn.html): 접속 요청이 접속 대기열(backlog) 넘침이나 방화벽 차단으로 사라지면, 클라이언트 OS가 1초 뒤부터 간격을 늘려 가며 다시 보냅니다.

## 판정과 사례

- [관측으로 판정하기](https://jungrok5.github.io/mmo-lag-anatomy/#judge): 범위 → 시점 → 계층 판정 흐름, 판정 신호표, 그래프 모양 13가지, 숫자 읽는 법(평균과 p99)
- [상황별 절차](https://jungrok5.github.io/mmo-lag-anatomy/text.html#playbooks): 패치 이후 렉, 해외 국가·지역 추가
- [실제 장애 사례](https://jungrok5.github.io/mmo-lag-anatomy/text.html#cases): 원개발사·운영사가 공개한 사후 분석과 관련 원인

## 다른 언어

- [English](https://jungrok5.github.io/mmo-lag-anatomy/en/llms.txt)
- [日本語 (Japanese)](https://jungrok5.github.io/mmo-lag-anatomy/ja/llms.txt)
- [简体中文 (Chinese (Simplified))](https://jungrok5.github.io/mmo-lag-anatomy/zh-cn/llms.txt)
- [繁體中文 (Chinese (Traditional, Taiwan))](https://jungrok5.github.io/mmo-lag-anatomy/zh-tw/llms.txt)
- [Deutsch (German)](https://jungrok5.github.io/mmo-lag-anatomy/de/llms.txt)
- [ไทย (Thai)](https://jungrok5.github.io/mmo-lag-anatomy/th/llms.txt)
- [Tiếng Việt (Vietnamese)](https://jungrok5.github.io/mmo-lag-anatomy/vi/llms.txt)
- [Русский (Russian)](https://jungrok5.github.io/mmo-lag-anatomy/ru/llms.txt)
- [Português (Brasil) (Portuguese (Brazil))](https://jungrok5.github.io/mmo-lag-anatomy/pt-br/llms.txt)
- [Español (Spanish)](https://jungrok5.github.io/mmo-lag-anatomy/es/llms.txt)
- [Bahasa Indonesia (Indonesian)](https://jungrok5.github.io/mmo-lag-anatomy/id/llms.txt)

## Optional

- [GitHub 저장소](https://github.com/jungrok5/mmo-lag-anatomy): 소스, 데이터 형식, 기여 방법
- [만든 사람: 오정록](https://jungrok5.github.io/resume/): 이력서