팰월드 서버 렉: 원인부터 가려내는 순서

"서버 렉 걸린다"는 한마디 안에는 서로 관계없는 네 가지 문제가 들어 있어요. 게임 안에서 보면 다 비슷하게 느껴지는데 고치는 자리는 전혀 달라서, 집 Wi-Fi 문제인데 메모리를 더 사거나 재시작 한 번이면 나았을 걸 고치겠다고 서버 지역을 옮기는 일이 실제로 벌어져요.

이 글은 고치는 방법이 아니라 찾아가는 순서예요. 1분이면 대부분을 갈라내는 두 가지 질문, 그래도 남는 것을 확정해 주는 숫자 하나, 그리고 원인별로 어디서 고치는지. 각 갈래 끝에는 그 주제를 깊게 다룬 글이 있어요.

1단계: 서버 문제가 맞나요

설정을 건드리기 전에 이게 누구 문제인지부터 정해요. 질문 두 개면 거의 다 갈려요. 다른 사람도 같이 느끼나요, 그리고 화면이 끊기나요 아니면 조작이 늦게 먹히나요.

세 번째 줄은 2단계와 3단계에서 다루고, 첫 번째 줄은 아래에 따로 한 절을 뒀어요. 세 번째 줄을 뺀 나머지 셋은 공통점이 하나 있어요. 서버 설정을 아무리 만져도 나아지지 않는다는 거예요.

본격적으로 손대기 전에 알아 두면 좋은 지름길이 하나 있어요. 재시작했더니 즉시 멀쩡해진다면 머신이 작은 게 아니에요. 이 테스트 하나로 가장 비싼 오답이 걸러지고, 원인은 가동 시간 동안 쌓인 것 쪽을 가리켜요.

2단계: 서버 프레임률을 직접 읽기

팰월드 서버에는 자기 프레임률이 있어요. "느낌상 렉이 있다"와 "숫자가 이렇다"를 가르는 게 이거예요. 값은 공식 REST API에서 나오고, 서버가 로컬호스트에만 여는 인터페이스예요(켜는 방법과 보안 규칙 하나는 REST API 안내에 있어요).

curl -s -u "admin:$PW" http://127.0.0.1:8212/v1/api/metrics

1.0부터 팰월드 전용 서버의 최대치는 초당 60프레임 안팎이에요. 저희가 운영하는 v1.0.5 서버들은 부담이 없을 때(비어 있거나 한두 명 접속 중일 때) 1분 단위로 하루 종일 재도 59에 머물러요. 아래 기준은 모두 이 값의 비율이라 55가 나와도 걱정할 필요 없어요. 숫자가 뜻하는 건 이래요.

같은 응답에서 같이 볼 값이 셋 더 있어요.

• serverframetime 은 프레임 하나에 걸린 밀리초예요. 프레임률의 역수쯤 되고(60fps면 약 17ms), 평균 프레임률이 움직이기 전에 스파이크가 먼저 여기서 보여요. 평균은 멀쩡한데 몇 초에 한 번씩 걸리는 서버를 잡아내는 값이에요.
• uptime 은 프로세스가 켜진 뒤 지난 초예요. 쌓인 부하의 증거고요. 낮은 프레임률과 긴 가동 시간이 같이 나오면 더 재 볼 것도 없어요.
• basecampnum 은 월드에 있는 거점 수예요. API가 주는 값 중 프레임률과 가장 밀접하게 움직이는 숫자예요. 월드는 사람이 늘어서 무거워지는 게 아니라 지어 놓은 게 늘어서 무거워지거든요.

값은 누가 불평하고 있을 때 재세요. 한가한 아침에 찍은 숫자는 토요일 밤 상황을 전혀 알려 주지 않아요.

3단계: 서버 프레임률을 끌어내리는 네 가지

실제로 자주 나오는 순서예요. 각각 1분 안에 맞는지 아닌지 가려내는 테스트가 있어요.

1. 가동 시간 — 마지막 재시작 뒤로 쌓인 것. 메모리는 사람들이 플레이하는 동안 올라가서, 며칠째 켜져 있는 서버는 오늘 아침 재시작한 서버보다 더 많이 들고 있어요. 테스트는 재시작이에요. 바로 멀쩡해지면 이거예요. 답은 예약 재시작이고, 주기와 공지·저장·정지·시작 순서, 스크립트, 그리고 실제 서버에서 열흘 동안 메모리가 어떻게 움직였는지까지 팰월드 24시간 서버 만들기에 있어요.

2. 월드가 무거워졌다. 거점, 건축물, 일하는 팰, 떨어진 아이템은 전원이 접속을 끊어도 계속 시뮬레이션돼요. 저절로 사라지지 않고요. 테스트는 basecampnum 하나와 눈으로 한 바퀴. 거점 열 몇 개에 자리마다 팰이 꽉 차 있으면 첫 주의 몇 배를 돌리고 있는 거예요. 직접 영향을 주는 설정은 넷이고(bEnableInvaderEnemy, BaseCampWorkerMaxNum, BaseCampMaxNum, DropItemAliveMaxHours — 설정 항목 전체 설명), 먼저 끌 것은 습격이에요.

3. 사람이 몰리는 시간대 — 메인 스레드. 물리, 길 찾기, 전투, 상태 동기화가 전부 한 스레드에서 돌아요. 그래서 코어 수보다 클럭이 천장을 정해요. 테스트는 곡선의 모양이에요. 네 명일 때 멀쩡하고 열 명에서 처지고 사람이 빠지면 돌아오면, 쌓인 부하가 아니라 인원 대비 사양 문제예요. 무엇을 기준으로 잡는지는 필요 사양에, 인원 상한이 숫자 하나가 아닌 이유는 인원 상한 이야기에 있어요.

4. 규칙적인 끊김 — 디스크. 전원이 아주 짧게 얼어붙는 일이 일정한 간격으로 반복되고, 서버가 바쁜지 한가한지와 무관해요. 테스트는 시계예요. 끊기는 간격이 AutoSaveSpan(기본 30초)과 맞아떨어지면 자동 저장이 느린 디스크를 만난 거예요. 이건 네트워크 문제로 오진되는 일이 정말 잦아요. SSD면 끝나요.

둘이 동시에 해당하는 경우도 있어요. 몇 달 된 서버면 대개 그렇고요. 그래도 순서는 위대로 가세요. 재시작은 공짜고 가장 큰 놈을 걸러 주니까요.

클라이언트 프레임 드랍은 다른 숫자예요

이름이 같은 프레임률이 둘이라, 헷갈리면 아무 문제 없는 쪽 기계의 설정을 만지게 돼요. 내 클라이언트 FPS는 내 그래픽카드가 그리는 속도이고, 서버 FPS는 월드가 시뮬레이션되는 속도예요. 둘은 따로 움직여요.

가르는 질문은 하나예요. 조작은 즉시 먹히나요?

알아 둘 값어치가 있는 건 마지막 줄이에요. 건축물이 수백 개에 일하는 팰이 가득한 거점은 서버에는 시뮬레이션 부담이고 내 PC에는 렌더링 부담이라, 지도의 같은 자리에서 두 숫자가 같이 무너져요. 이걸 "우리 거점에서 서버가 렉 걸린다"로 말하고는 엉뚱한 기계를 뒤지게 되고요.

클라이언트 쪽 드랍은 손댈 곳이 전부 내 PC 안이에요. 그래픽 프리셋, 해상도 배율, GPU를 같이 쓰고 있는 다른 프로그램. 전용 서버가 도와줄 수 있는 건 하나도 없어요. 대신 반대쪽 절반이 건강한지는 책임질 수 있고, 그게 이 글의 나머지 내용이에요.

내 회선일 때: 핑과 지역

나만 느낀다면 핑, 그러니까 내 컴퓨터와 서버 사이의 왕복 지연시간이에요. 그리고 서버 지역을 옮겨서 나아지는 렉은 이것 하나뿐이에요. 핑은 숫자 하나지만 성질이 다른 세 구간의 합이라, 어느 구간이 큰지에 따라 할 수 있는 일이 달라져요.

• 물리적 거리. 광섬유 안에서 신호는 직선 1,000 km당 편도 5 ms쯤 걸리고, 실제 회선은 직선이 아니라서 1,500 km쯤 떨어진 곳이면 바닥이 왕복 20 ms 안팎이에요. 장비를 아무리 좋게 해도 이 아래로는 안 내려가요.
• 경유 경로. 같은 두 지점 사이라도 트래픽이 어디를 거치느냐에 따라 왕복이 수십 ms씩 달라져요. 이웃 나라인데도 제3국의 교환 지점을 돌아가는 경로가 잡히는 일이 실제로 있어서, 거리로 계산한 값보다 훨씬 크게 나온다면 거의 이쪽이에요.
• 집 인터넷 구간(라스트 마일). 공유기부터 통신사 접속까지, 그리고 집 안의 Wi-Fi. 국제 구간보다 이쪽이 더 큰 경우가 흔해요. 랜선으로 바꾸는 것만으로 사라지는 "서버 렉"이 생각보다 많아요.

재는 건 몇 분이면 끝나요. Windows는 ping -n 20 대상주소, macOS와 Linux는 ping -c 20 대상주소로 왕복 지연을 재요. 평균만 보지 말고 최솟값과 최댓값의 차이를 같이 보세요. 그 차이가 지터예요. tracert / traceroute는 어느 구간에서 갑자기 수십 ms가 붙는지 보여 주고, Linux에서 mtr -r -c 100 대상주소를 쓸 수 있으면 홉별 손실률까지 한 번에 나와요. 아직 서버가 없다면 후보 지역 안에 있는 아무 공개 호스트를 같은 날 같은 시간대에 연달아 재면 돼요. 목적은 정확한 값이 아니라 후보들 사이의 서열이거든요.

팰월드는 대전 게임이 아니라서 생각보다 너그러워요.

그리고 평균보다 편차가 중요해요. 평균 60 ms인데 30 ms와 120 ms를 오가는 회선이, 계속 120 ms인 회선보다 훨씬 불쾌해요. 손실률도 마찬가지예요. 팰월드는 UDP로 통신해서 잃어버린 패킷을 다시 보내 메우지 않기 때문에, 1%만 넘어가도 평균 핑이 좋든 말든 위치 밀림이 생겨요.

친구들이 여러 나라에 흩어져 있다면 기준은 평균이 아니라 가장 나쁜 사람의 값이에요. 각자 같은 방법으로 후보 지역들을 재서 한 표에 모으고, 후보마다 가장 큰 값을 본 뒤 그게 가장 작은 곳을 골라요. 한 명만 대륙이 다르면 어디를 골라도 그 사람은 150 ms 아래로 내려오지 않으니 미리 말해 두고, 보스 전투 일정만 그 사람 기준으로 잡지 않으면 돼요. 전용 서버의 장점도 여기 있어요. 초대 코드로 열면 방장이 어디 사는지가 그대로 모두의 핑이 되지만, 전용 서버는 사람들 사이 어디든 둘 수 있어요(초대 코드와 전용 서버 차이).

지역은 서버를 열기 전에 정해 두세요. 지역이 바뀌면 접속 주소가 같이 바뀌어서 세이브를 새 서버로 옮기고 전원이 주소를 다시 입력해야 하니, 옮기는 것보다 처음에 제대로 고르는 쪽이 훨씬 싸요.

네트워크 문제처럼 보이지만 아닌 경우가 하나 더 있어요. 버전 불일치예요. 게임이 업데이트된 뒤 옛 빌드로 돌고 있는 서버는 느려지는 게 아니라 아예 아무도 들어오지 못하게 돼요. 세이브를 지키는 업데이트 순서를 보세요.

자주 묻는 질문

팰월드 서버가 왜 렉이 걸리나요?

누가 느끼는지부터 확인하세요. 나만 그러면 내 회선이나 내 PC예요. 전원이 동시에 밀리면 서버를 재시작해 보세요. 즉시 멀쩡해지면 가동 시간 동안 쌓인 부하였고, 예약 재시작을 걸어 두면 다시 오지 않아요. 재시작해도 그대로면 사람들이 불평하는 그 시간에 REST API로 serverfps를 읽으세요. 접속 인원을 따라 처지면 CPU 메인 스레드, 인원이 그대로인데 처지면 무거워진 월드예요.

팰월드 서버 프레임률은 얼마가 정상인가요?

1.0부터 팰월드 전용 서버의 최대치는 60 안팎이고(저희 v1.0.5 서버는 59로 읽혀요) 50 이상이면 정상이에요. 30~50 구간에서 첫 불평이 나오고, 30 아래로 내려가면 위치 밀림과 일하다 멈춘 팰로 월드의 모두가 느껴요. 값은 REST API의 /metrics에서 읽고, 한가할 때가 아니라 서버가 바쁠 때 재세요.

프레임 드랍이 제 PC 문제인가요, 서버 문제인가요?

조작이 즉시 먹히는지를 보세요. 화면만 끊기고 조작은 즉각적이라면 내 그래픽카드 쪽이고, 다른 사람은 아무렇지 않아요. 화면은 부드러운데 타격이 늦게 들어간다면 서버 쪽이고, 같은 순간에 전원이 같이 느껴요. 둘이 동시에, 그것도 지도의 특정 구역에서만 무너진다면 서버 시뮬레이션과 내 PC 렌더링을 함께 잡아먹을 만큼 무거운 거점이에요.

팰월드 서버 핑 몇이면 할 만한가요?

80 ms 아래면 대부분 눈치채지 못하고, 150 ms까지는 충분히 할 만해요. 150~250 ms는 건축과 채집 위주라면 괜찮지만 보스 전투가 답답해요. 다만 숫자 하나로 판단하지 마세요. 평균이 낮아도 값이 들쭉날쭉하면 안정적으로 높은 회선보다 나쁘게 느껴져요.

핑은 낮은데 자꾸 밀려요. 왜 그럴까요?

평균 핑이 낮아도 손실률과 지터가 크면 그렇게 느껴져요. 먼저 Wi-Fi를 랜선으로 바꿔서 집 인터넷 구간의 변수를 없애 보세요. 그래도 같고 전원이 동시에 밀린다면 내 회선이 아니라 서버 쪽이고, 볼 곳은 위의 2단계예요.

거점이 많으면 팰월드 서버가 느려지나요?

같이 노는 사람들이 서버에 주는 부담 중 가장 큰 게 그거예요. 거점과 거기 세운 건축물, 배치한 팰은 전원이 접속을 끊어도 계속 시뮬레이션되기 때문에, 부하는 접속 인원보다 지어 놓은 양을 따라가요. /metrics의 basecampnum이 지켜볼 값이고, 거점 수와 거점당 일꾼 수를 제한하고 습격을 끄는 것이 가장 직접적인 세 가지 방법이에요.

재 볼 사람이 없을 때

위의 전부는 사람들이 불평하는 바로 그 순간에 값을 읽어 줄 누군가가 있다는 가정 위에 있어요. 그런데 그 시각은 보통 아무도 SSH를 붙일 형편이 아닌 시각이죠. 서버 렉의 진짜 어려움이 여기예요. 증거는 그때만 있고, 누가 들여다볼 때쯤이면 서버는 한가해져서 아주 건강한 숫자를 보여 줘요.

KeepWorlds의 팰월드 서버는 그 값을 이미 재 두고 있어요. 프레임률과 접속 인원을 1분마다, 경고선이 그어진 24시간 곡선으로요. "어젯밤에 엄청 심했다"를 복원하는 대신 열어 보면 되고요. 가동 시간 동안 쌓이는 부하는 문제가 되기 전에 처리돼요. 매일 예약 재시작이 정해 둔 시각에 게임 내 공지와 강제 저장을 먼저 하고 메모리를 바닥으로 되돌려 주거든요. 나머지 원인을 좌우하는 설정들, 그러니까 습격과 거점 상한, 거점당 일꾼 수는 SSH로 고치는 .ini 한 줄이 아니라 게임 설정 폼의 입력란이에요.