게임 렉 백서 › 증상별로 찾기

입력 지연: 원인 76가지와 담당

다른 말: 반응이 늦음, 굼뜸, 손맛이 없음

그림이 있는 원본 증상 사전으로 열기 →

누르고 나서 결과가 나타나기까지 시간이 걸립니다. 화면 자체는 매끄러울 수 있습니다.

스킬 버튼을 누르면 0.2~0.5초 뒤 발동. 줍기, 대화, 거래 같은 확인형 행동이 느립니다.

왕복 시간(핑)이 길거나, 어딘가에 대기열이 쌓여 있습니다. 거리, 공유기 대기열, Nagle(작은 패킷을 모았다 보내는 TCP 기능), 서버 대기열을 봅니다. 핑이 낮은데도 늘 굼뜨면 V-Sync·낮은 FPS 같은 내 PC 쪽이나, 행동마다 서버 확인을 기다리는 설계(동기화 방식 장)를 봅니다.

이 증상을 만드는 원인

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

• 대규모 인원 렌더링 부하: 공성전·월드 보스처럼 수백 명이 한 화면에 들어오면 그리는 비용 자체가 감당이 안 됩니다. (게임개발팀·클라이언트 개발)
• 메인 스레드 패킷 처리 병목: 받은 패킷을 프레임마다 정해진 만큼만 처리하면, 몰려온 패킷이 다음 프레임으로 계속 밀립니다. (게임개발팀·클라이언트 개발)
• V-Sync와 렌더 대기열: GPU가 그린 프레임을 몇 장 대기열에 쌓아 두었다가 모니터 주기에 맞춰 내보내는 동안 입력이 늦어집니다. (게임개발팀·클라이언트 개발)

L2 클라이언트 OS·기기

• 절전 모드·발열 스로틀링: 노트북 배터리 모드, 폰 절전 모드, 기기 발열 때문에 CPU·GPU 속도가 떨어집니다. 발열은 처음엔 괜찮다가 한참 뒤부터 느려지는 게 특징입니다. (외부·외부)
• 같은 기기의 다른 앱이 대역폭 점유: 클라우드 동기화, 대용량 다운로드, 게임 패치가 같은 PC에서 돌면 게임 패킷이 대기열에서 기다립니다. (외부·외부)
• 디스플레이·입력 장치·프레임 생성 지연: 핑은 정상인데 조작이 묵직하다면, TV의 영상 처리나 무선 컨트롤러, 프레임 생성 기능이 입력과 화면 사이에 지연을 더했을 수 있습니다. (외부·외부)

L3 집 네트워크

• 와이파이 채널 혼잡: 아파트처럼 공유기가 수십 개 있는 곳은 같은 채널을 나눠 쓰느라 전송 기회를 기다립니다. (외부·외부)
• 버퍼블로트 (공유기 대기열): 가족 누군가 영상을 올리거나 큰 파일을 받으면 공유기 대기열에 수백 ms 분량의 패킷이 쌓이고, 게임 패킷도 그 뒤에서 기다립니다. (외부·외부)
• RRC 상태 전환 지연 (모바일 무선 절전): 폰은 한동안 통신이 없으면 무선 연결을 저전력 상태로 내리고 다음 패킷 때 다시 올리느라 늦어집니다. (게임개발팀·클라이언트 개발)

L4 인터넷 회선

• 전파 지연 (물리적 거리): 빛도 광케이블에서 1초에 약 20만 km밖에 못 갑니다. 먼 서버는 아무리 좋아도 늦습니다. (인프라팀·서버 인프라)
• 위성 인터넷 (저궤도·정지궤도): 위성 인터넷은 전파가 우주를 오가야 해서, 정지궤도 위성은 왕복만 0.5초가 넘고 Starlink 같은 저궤도 위성은 평소엔 빠르지만 경로를 다시 배정하는 순간 지연이 흔들리고 잠깐 끊기기도 합니다. (외부·외부)
• 우회 라우팅: 통신사끼리의 연결 계약 때문에 가까운 서버도 먼 곳을 돌아서 갑니다. (인프라팀·네트워크 인프라)
• 해저 케이블·국제 회선 장애: 해저 케이블이 끊기면 수리될 때까지 몇 주(길면 몇 달) 동안 먼 우회 경로로 돌아가고, 남은 회선은 붐빕니다. (외부·외부)
• 통신사 속도 제한·트래픽 관리: 데이터 사용량을 넘기거나 특정 트래픽을 관리하는 요금제에서는 패킷이 늦춰지거나 버려집니다. (외부·외부)
• VPN·게임 가속기 경유: VPN이나 게임 가속기를 켜면 패킷이 그 회사의 중계 서버를 거쳐 갑니다. 중계 서버가 멀거나 붐비면 오히려 느려집니다. (외부·외부)

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

• DDoS 방어 경유·오탐: 공격을 막으려고 트래픽을 스크러빙 센터로 돌리면 경로가 길어지고 정상 사용자를 공격으로 오인해 막기도 합니다. (인프라팀·네트워크 인프라)
• 데이터센터 회선 포화: 패치 배포·로그 전송·백업이 게임과 같은 회선을 쓰면 회선이 꽉 찹니다. (인프라팀·네트워크 인프라)

L6 서버 네트워크 카드

• NIC 인터럽트 단일 코어 집중: NIC가 패킷 도착 인터럽트를 CPU 코어 하나에만 보내면 그 코어가 병목이 됩니다. (인프라팀·서버 인프라)
• 인터럽트 병합 과다: CPU 부담을 줄이려고 패킷을 모았다 한 번에 알리면, 모으는 시간만큼 늦어집니다. (인프라팀·서버 인프라)
• NIC 대역폭 포화: 1Gbps·10Gbps 카드의 한계까지 쓰면 송신 대기열이 길어지고 넘친 패킷은 버려집니다. (게임개발팀·서버 개발)
• GRO/LRO 병합 대기 지연: 여러 패킷을 하나로 묶어 CPU 부담을 줄이는 기능입니다. 설정에 따라 작은 게임 패킷이 함께 묶을 다음 패킷을 잠깐 기다리기도 합니다. (인프라팀·서버 인프라)

L7 서버 OS (커널)

• 서버 전원 관리(C-state·주파수 조절)로 지연 튐: 쉬는 CPU 코어는 전기를 아끼려고 깊은 절전 상태(C-state)로 들어가고 주파수도 낮춥니다. 패킷이나 타이머가 오면 깨어나고 주파수를 올리는 데 시간이 걸려, 작은 패킷 처리에 지연이 더해집니다. (인프라팀·서버 인프라)
• OS·커널·드라이버·펌웨어 업데이트 뒤 성능 변화: 게임 코드는 그대로인데 서버 OS·커널·드라이버·펌웨어를 업데이트한 뒤부터 서버가 느려집니다. 업데이트로 기본값, 스케줄러, CPU 취약점 완화(mitigations), 드라이버 동작이 바뀌기도 합니다. (인프라팀·서버 인프라)

L8 소켓과 프로토콜

• Nagle 알고리즘 + 지연 ACK: 작은 패킷을 모아 보내는 Nagle 알고리즘과 ACK를 늦게 보내는 지연 ACK가 맞물려, 메시지를 나눠 쓸 때마다 40~200ms씩 지연됩니다. (게임개발팀·서버 개발)
• 유휴 후 슬로 스타트: TCP는 한동안 유휴 상태면 혼잡 윈도우(한 번에 보낼 수 있는 양)를 다시 줄여, 갑자기 큰 데이터를 보낼 때 여러 번에 나눠 보냅니다. (인프라팀·서버 인프라)
• 혼잡 제어로 전송량 급감: TCP는 손실을 혼잡 신호로 보고 전송 속도를 30~50% 줄입니다. 와이파이 손실에도 똑같이 반응합니다. (인프라팀·서버 인프라)
• 블로킹 I/O 구조: 소켓 하나를 기다리는 동안 스레드가 다른 일을 못 하는 구조에서는 사람이 늘수록 전체가 느려집니다. (게임개발팀·서버 개발)

L9 서버 게임 프로세스

• 틱 예산 초과: 한 틱 안에 할 일이 예산을 넘으면 서버의 틱 주기가 늘어지고 그 지역 전체가 느리게 흐르거나 뚝뚝 끊깁니다. (게임개발팀·서버 개발)
• 브로드캐스트 폭증: 한 명의 움직임을 그를 보는 모두에게 보내면, 모인 인원의 제곱만큼 보낼 업데이트가 생깁니다. (게임개발팀·서버 개발)
• 단일 스레드 지역 과부하(핫스팟): 지역마다 스레드 하나가 맡는 구조에서 한곳에 사람이 몰리면 그 코어 하나만 100%가 됩니다. (게임개발팀·서버 개발)
• 락 경합: 여러 스레드가 같은 데이터를 쓰려고 락 하나를 기다리면, 스레드를 늘려도 한 번에 하나씩만 실행됩니다. (게임개발팀·서버 개발)
• 메시지 큐 적체: 요청이 처리 속도보다 빨리 들어와 대기열에 쌓이면, 뒤쪽 요청은 몇 초 뒤에야 처리되거나 버려집니다. (게임개발팀·서버 개발)
• 직렬화·압축 비용: 보낼 데이터를 바이트로 바꾸고 압축하는 데도 CPU가 들고 사람이 많으면 이 비용이 폭증합니다. (게임개발팀·서버 개발)
• 스레드 풀 고갈: 작업을 처리할 워커 스레드가 모두 느린 작업에 묶이면 새 요청은 무작정 기다립니다. (게임개발팀·서버 개발)
• 한 대상에 몰린 전투 (월드 보스): 수백 명이 보스 하나를 동시에 때리면, 보스 한 마리의 계산이 한곳에 몰리고 타격 정보가 보는 모두에게 전송됩니다. (게임개발팀·서버 개발)
• 밀집 지역 진입 시 스폰 폭주: 사람이 가득한 마을로 텔레포트하면, 서버는 새로 보이게 된 수백 명의 외형·장비·상태를 한꺼번에 보내야 합니다. (게임개발팀·서버 개발)
• 개체 누적 (정리되지 않은 아이템·소환물): 사라져야 할 바닥 아이템, 소환물, 끝난 타이머가 정리되지 않고 쌓이면, 서버를 오래 켜 둘수록 매 틱 할 일이 늘어납니다. (게임개발팀·서버 개발)
• 패치로 트래픽 패턴이 바뀜: 새 콘텐츠·이펙트·동기화 항목이 패킷 크기와 빈도를 늘리면, 잘되던 서버가 패치 뒤부터 MTU·대역폭·패킷 수 한도에 걸립니다. (게임개발팀·서버 개발)

L11 디스크

• fsync 폭주: 데이터를 “확실히” 디스크에 쓰도록 요청하면 디스크에 따라 한 번에 0.1ms~수십 ms가 걸리고, 몰리면 대기열이 길어집니다. (게임개발팀·서버 개발)
• 클라우드 디스크 버스트 크레딧 소진: 일부 클라우드 디스크와 작은 서버 사양은 잠깐 기준보다 빠르게 쓸 수 있는 버스트 크레딧이 있어서, 바쁜 시간이 길어져 크레딧이 바닥나면 속도가 갑자기 떨어집니다. (인프라팀·서버 인프라)
• IOPS 한도·대기열 포화: 디스크가 1초에 처리할 수 있는 요청 수를 넘으면 대기열이 길어져 지연이 폭증합니다. (인프라팀·서버 인프라)
• 백업·압축·검사 작업: 새벽 백업, 로그 압축, 보안 검사가 디스크를 독점하면 게임 서버의 읽기·쓰기가 밀립니다. (인프라팀·서버 인프라)
• HDD 탐색 지연: HDD는 헤드가 플래터 위를 움직여야(탐색, seek) 해서 흩어진 데이터를 읽고 쓰는 데 한 번에 10ms 가까이 걸립니다. (인프라팀·서버 인프라)

L12 데이터베이스

• 인덱스 없는 쿼리: 인덱스 없이 조건에 맞는 행을 찾으려면 테이블 전체를 읽어야 합니다(풀 스캔). (게임개발팀·서버 개발)
• 핫 로우 잠금 경합: 모두가 같은 행(길드 창고, 경매장 인기 아이템, 서버 전체 카운터)을 고치려 하면 한 명씩만 잠금을 얻습니다. (게임개발팀·서버 개발)
• DB 데드락: 두 트랜잭션(한 묶음으로 처리되는 DB 작업)이 서로 상대가 잠근 행을 기다리면 DB가 한쪽을 강제로 취소합니다. (게임개발팀·서버 개발)
• 커넥션 풀 고갈: DB와 맺어 둔 연결 수가 정해져 있어서 느린 쿼리가 연결을 점유하면 나머지는 대기합니다. (게임개발팀·서버 개발)
• 체크포인트·로그 플러시: DB가 메모리의 변경분을 주기적으로 디스크에 몰아서 쓰는 순간 쿼리가 느려집니다. (인프라팀·DB 인프라)
• 콜드 캐시 (재시작 직후): DB를 재시작하면 메모리 캐시가 비어 있어서 한동안 조회하는 데이터를 모두 디스크에서 읽습니다. (인프라팀·DB 인프라)
• 로그인 폭주와 N+1 쿼리: 캐릭터 하나를 불러올 때 수십 번 따로 조회하면, 수만 명 동시 로그인이 쿼리 수백만 개가 됩니다. (게임개발팀·서버 개발)
• 대량 배치 작업: 랭킹 집계, 우편 일괄 발송, 오래된 데이터 정리를 운영 중에 돌리면 잠금과 디스크를 차지합니다. (게임개발팀·서버 개발)
• 캐시 스탬피드: 인기 데이터의 캐시가 동시에 만료되면 수천 개 요청이 한꺼번에 DB로 몰립니다. (게임개발팀·서버 개발)
• 오래 열린 트랜잭션: 트랜잭션 하나가 오래 열려 있으면 잠금을 계속 잡고 있고 DB가 옛 버전 데이터를 정리(purge)하지 못해 전체가 점점 느려집니다. (게임개발팀·서버 개발)
• Redis 느린 명령: Redis는 명령을 한 번에 하나씩 처리해서 느린 명령 하나가 그 뒤의 모든 요청을 막습니다. (게임개발팀·서버 개발)
• 실행 계획 변경으로 인한 쿼리 지연: 코드는 그대로인데 DB가 같은 쿼리를 처리하는 방법(실행 계획)을 바꾸면, 어제 2ms였던 쿼리가 오늘 수백 ms가 됩니다. (인프라팀·DB 인프라)
• 운영 중 스키마 변경(DDL) 잠금: 서비스 중에 테이블에 컬럼이나 인덱스를 추가하면, 잠깐 필요한 잠금 하나 때문에 그 테이블을 쓰는 모든 요청이 대기할 수 있습니다. (인프라팀·DB 인프라)

L13 서버 구성과 운영

• 게이트웨이·프록시 경유: 클라이언트와 게임 서버 사이에 중간 서버를 두면, 한 번 거칠 때마다 처리 시간이 붙고 그 서버가 단일 장애 지점이 됩니다. (게임개발팀·서버 개발)
• 연쇄 장애: 한 서비스가 느려지면 그걸 부르는 서버들이 응답을 기다리며 묶이고 상관없는 기능까지 멈춥니다. (게임개발팀·서버 개발)
• 배포·재시작: 업데이트하려고 서버를 재시작할 때 연결을 옮기지 않으면 그 서버에 있던 사람들의 접속이 끊기고, 종료 직전 저장과 재접속이 한꺼번에 몰립니다. (게임개발팀·서버 개발)
• 매크로·봇 과다: 봇은 사람보다 훨씬 자주 요청을 보내 서버 처리량을 잠식합니다. (게임개발팀·서버 개발)
• 매치메이킹·리전 배정 오류: 가까운 리전 대신 먼 리전의 서버에 배정되면, 회선이 멀쩡해도 그 유저만 핑이 늘 높습니다. (게임개발팀·서버 개발)

동기화 설계

• 서버 응답 후에만 연출 (요청-응답 방식): 버튼을 누르면 서버 답이 올 때까지 애니메이션도 소리도 없습니다. 핑이 곧 반응 속도가 됩니다. (게임개발팀·클라이언트 개발)
• 순차 왕복이 많은 프로토콜 (chatty): 조작 한 번에 서버 왕복이 여러 번 순서대로 필요하면, 핑이 그 횟수만큼 곱해집니다. (게임개발팀·서버 개발)
• 스킬 선입력 없음: 앞 스킬이 서버에서 끝났다는 확인을 받아야 다음 스킬을 누를 수 있으면, 연계마다 왕복 시간이 끼어듭니다. (게임개발팀·클라이언트 개발)
• 핑에 먹히는 짧은 판정 구간: 회피·패링·가드처럼 반응해야 하는 시간이 짧으면, 핑이 그 시간을 먹어 버려 피할 수 없는 공격이 생깁니다. (게임개발팀·서버 개발)
• 락스텝에서 가장 느린 플레이어 대기: 모두가 같은 턴을 함께 계산하는 구조에서는, 한 명의 입력이 늦으면 모두가 기다립니다. (게임개발팀·서버 개발)
• 이중 틱 대기: 요청을 다음 틱까지 모았다가 처리하고 결과도 그다음 틱에 보내면 틱 간격이 두 번 더해집니다. (게임개발팀·서버 개발)

일부에게만 생기는 문제

• 플레이어별 입력 버퍼 크기: 서버가 사람마다 입력을 조금 모아 두었다가 한 틱에 하나씩 꺼내 쓰면, 다른 사람 눈에는 매끄럽지만 본인 행동이 서버에서 확정되는 시점은 그만큼 늦어집니다. (게임개발팀·서버 개발)
• 느린 파티원 한 명과 보스 기믹: 모두가 정해진 순간에 함께 반응해야 하는 레이드 기믹에서는, 느린 한 사람의 늦은 반응이 파티 전체의 실패가 됩니다. (게임개발팀·서버 개발)
• 특정 캐릭터의 데이터가 비대함: 아이템·우편이 수천 개 쌓였거나 친구·차단 목록, 버프가 유난히 많은 캐릭터는 접속하고 저장하고 주변에 알릴 양이 남보다 몇 배 큽니다. 회선과 상관없이 그 캐릭터로만 느립니다. (게임개발팀·서버 개발)
• 연결별 전송 예산·우선순위: 서버가 연결마다 보낼 양에 한도를 두고 가까운 것부터 보내면, 한도가 낮게 잡힌 쪽은 멀리 있는 NPC를 늦게 받거나 못 받습니다. (게임개발팀·서버 개발)

TCP 재전송의 근본 원인

• 수신 서버 호스트의 패킷 폐기: 패킷은 서버까지 왔는데 NIC의 링 버퍼(도착한 패킷을 잠시 담아 두는 버퍼)가 넘치거나, 커널의 수신 처리 코어가 포화되어 버려집니다. (인프라팀·서버 인프라)
• 지연 급등으로 인한 불필요한 재전송: 패킷은 사라지지 않고 잠깐 아주 늦게 도착했을 뿐인데, 그 지연이 RTO보다 길면 보내는 쪽이 손실로 판단해 재전송합니다. (외부·외부)
• 순서 뒤바뀜으로 인한 불필요한 빠른 재전송: 여러 경로나 묶인 링크를 지나며 패킷 순서가 바뀌면, 받는 쪽이 중복 ACK로 “빠진 패킷 있음”을 알리고 보내는 쪽은 멀쩡한 패킷을 다시 보냅니다. (인프라팀·네트워크 인프라)
• ACK가 늦거나 사라짐 (업로드 포화): 데이터는 잘 도착했는데 “받았다”는 ACK가 꽉 찬 업로드 대기열에서 늦어지거나 사라지면, 보내는 쪽이 손실로 판단해 재전송합니다. (외부·외부)
• RTO 설정이 환경과 맞지 않음: RTO 최소값을 너무 낮추면 조금만 늦어도 불필요한 재전송이 나고 기본값(200ms)은 게임 입장에서 너무 길어 한 번 잃을 때마다 오래 멈춥니다. (인프라팀·서버 인프라)

그림이 있는 원본 증상 사전 보기