대규모 전투 때 게임 서버의 틱이 늦어집니다. 틱 주기를 늘리기 전에 어떤 작업을 측정하고 분산해야 하나요?

틱 주기를 늘리면 한 번에 쓸 시간이 늘어날 수 있지만 반응성과 시뮬레이션 규칙도 바뀝니다. 먼저 어떤 작업 때문에 예산을 넘기는지 보겠습니다. 전투 계산이 많은지, 타이머와 AI가 한 틱에 몰리는지, 저장이나 네트워크 대기가 섞였는지 구분해야 합니다.

한 틱의 시간 예산은 다음 단계까지 끝내야 하는 실행 시간입니다. 전투 판정, AI 판단, 타이머, 저장 요청을 같은 구간에서 처리한다면 어떤 작업이 그 예산을 넘기는지 나눠 기록해야 합니다. 평균 틱은 짧아도 모든 NPC가 같은 틱에 경로를 다시 찾으면 순간적으로 입력 반응이 늦어질 수 있습니다.

예를 들어 모든 NPC가 같은 순간에 경로를 갱신하면 평균 CPU는 괜찮아도 특정 틱만 길어질 수 있습니다. 저는 틱별 실행 시간 분포와 작업 종류별 비용을 기록하고, 반드시 매 틱 실행해야 하는 일과 여러 틱에 나눠도 되는 일을 분리하겠습니다. 중요도가 낮은 AI 갱신이나 통계는 분산할 수 있지만 충돌 판정처럼 순서가 중요한 작업은 임의로 늦추면 규칙이 달라질 수 있습니다.

밀린 시간을 따라잡으려고 제한 없이 연속 틱을 실행하면 더 밀리는 악순환이 생길 수 있습니다. 따라잡기 상한과 과부하 시 정책을 정하고, 실제 시간과 시뮬레이션 시간을 어디에 사용하는지도 명확히 하겠습니다. 동시 접속 수뿐 아니라 한 지역에 몰린 전투를 재현해 지연과 게임 결과를 함께 확인하겠습니다. 서버가 버틴다는 것보다 입력 반응과 규칙이 허용 범위 안에서 유지되는지가 목표입니다.

틱 예산을 작업별로 분해합니다

틱 시작부터 끝까지 wall-clock, CPU, 락·큐·DB 대기를 구분하고 전투 판정·AI·경로 탐색·타이머·직렬화별 비용을 p99와 최악 틱에 기록합니다. 접속자 수가 같아도 한 지역에 투사체와 NPC가 모이면 충돌 후보가 제곱에 가깝게 늘 수 있어 집중 전투를 재현해야 합니다. 모든 타이머가 같은 틱에 만료되는지도 확인합니다.

늦춰도 되는 작업만 분산합니다

입력 적용과 권위 있는 충돌 판정처럼 순서가 규칙인 작업은 임의로 늦추지 않습니다. 통계·일부 AI·경로 계산은 그룹을 나누어 여러 틱에 처리하고, 결과에 월드 버전과 대상 ID를 붙여 계산 중 문이 바뀌면 폐기합니다. 외부 저장은 틱 스레드에서 기다리지 않되 큐 상한과 우선순위를 둡니다. 무제한으로 밀린 틱을 실행하면 새 틱이 더 쌓이므로 따라잡기 횟수와 과부하 시 생략할 비핵심 작업을 정하고, 틱 주기를 바꾼다면 입력 반응·판정 공정성·재현성이 유지되는지 비교하겠습니다.

구체적인 경계 사례

20Hz 서버는 한 틱에 50ms를 쓸 수 있습니다. 전투 15ms, AI 12ms, 직렬화 8ms라면 겉으로 15ms 여유가 있지만 OS 스케줄링·GC·공유 락의 지연까지 포함하면 여유가 줄어듭니다. 목표를 매번 50ms에 딱 맞추기보다 최악 집중 구간을 견딜 여유를 둡니다. CPU 시간과 단조 시계로 잰 실제 경과 시간을 비교하면 계산인지 대기인지 좁힐 수 있습니다.

작업을 다른 스레드로 넘길 때 월드의 가변 객체를 그대로 참조하면 결과가 빠르더라도 중간 상태를 볼 수 있습니다. 불변 입력 스냅샷을 넘기고 결과를 틱 경계에서 현재 세대와 비교해 적용합니다. 오래 걸린 작업을 기다리지 않는 대신 다음 틱에서 안전한 이전 계획을 쓸지 멈출지 정하고, 큐 대기·폐기 결과·스냅샷 복사 비용을 포함해 전체 개선을 평가하겠습니다.