팰월드 멀티 인원수: 초대 코드 4인, 전용 서버 최대 32명과 쾌적한 인원

팰월드 멀티 인원은 방식마다 달라요. 초대 코드로 하는 멀티(자기 게임에서 멀티플레이 옵션을 켜고 호스트하는 방식)는 4명이 넘을 수 없는 상한이고, 전용 서버를 쓰면 최대 32명까지 들어와요. 두 방식이 인원 말고 무엇이 다른지는 초대 코드와 전용 서버 차이에 있어요.

5명 넘게 모이려고 전용 서버를 알아보면 "전용 서버는 32명까지"라는 설명이 먼저 나와요. 이 말은 대개 "서버 한 대 사면 32명이 놀 수 있다"로 읽히는데, 둘 사이에는 몇 겹의 간격이 있고, 그 하나하나가 실제로 놀 수 있는 인원을 설정값보다 훨씬 적게 만들어요.

이 글은 그 숫자를 실제로 정하는 게 무엇인지, 올렸을 때 무엇에 부딪히는지, 그리고 우리 팀에 맞는 값을 어떻게 고르는지를 다뤄요. 서버를 세우는 방법 자체는 전용 서버 구축 순서에 있어요.

설정할 수 있는 숫자

항목은 ServerPlayerMaxNum이고, PalWorldSettings.ini의 그 긴 한 줄 안에 있어요.

OptionSettings=(...,ServerPlayerMaxNum=32,...)

32는 기본값이자 공식적으로 지원하는 상한이에요. 더 올리려는 시도가 있긴 하지만 개발사가 공개한 범위 밖이라 안정성 보장이 없고, 문제가 생겼을 때 참고할 경험도 없어요.

바꾼 뒤에는 서버를 재시작해야 해요. 다른 모든 설정과 같아요(월드 설정 전체 해설).

여기까지는 단순해요. 복잡한 건 다음 절이에요.

머신이 실제로 감당하는 숫자

ServerPlayerMaxNum은 능력이 아니라 약속이에요. 몇 개의 접속을 허용할지 서버에 알려 줄 뿐이고, 그걸 감당할 수 있는지는 아래 머신의 몫이에요. 8명분 성능의 머신에 32를 적으면 아홉 번째 사람이 튕기는 게 아니라 전원이 느려져요.

팰월드 서버 메모리에는 다른 게임과 다른 특징이 하나 있어요. 사용량이 동시 접속 인원이 아니라 월드 규모를 따라간다는 점이에요.

• 누군가 접속하면 조금 늘어나요
• 누군가 나가도 그 사람의 거점은 계속 돌아가요. 건축물도, 배치한 팰도, 생산 라인도 메모리에서 계속 시뮬레이션돼요

그래서 "평소엔 세 명뿐"인 10인 서버도 세 명분을 한참 넘게 써요. 메모리를 먹는 건 그 열 명이 합쳐서 얼마나 지었는가예요.

그러니 인원수만으로는 한 그룹에 메모리가 얼마나 필요한지 알 수 없어요. 직접 세우는 머신이라면 공식 수치와, 월드를 그 수치 너머로 밀어 올리는 요인을 필요 사양에 정리해 뒀어요.

여기서 중요한 건 방향이에요. 같은 여덟 명이라도 석 달을 놀아 각자 꽉 찬 거점을 세 개씩 가지면 시작 때보다 메모리를 꽤 많이 써요. 월드와 함께 기본 사용량이 계속 올라가는 건 이 게임에서 정상이에요.

인원을 올리면 함께 움직이는 것

ServerPlayerMaxNum을 8에서 20으로 바꾸면 한 항목만 바꾼 것 같지만, 실제로는 다른 세 항목에 부딪혀요.

가운데 줄이 가장 많이 걸리는 지점이에요. 거점 상한은 길드 단위이지 사람 단위가 아니에요. 20인 대형 길드가 가질 수 있는 거점은 네 곳, 1인당 0.2개예요. "사람이 늘면 거점도 는다"는 직관과 게임 규칙은 정반대예요.

인원을 올릴 때는 이 세 항목을 같이 보세요. 흔한 구성은 두 가지예요.

• 큰 길드 하나: BaseCampMaxNumInGuild를 올리고(엔진 상한 10) 거점을 공유해요
• 1인 1길드: 이 항목은 기본값으로 두고 BaseCampMaxNum이 충분한지 확인해요

상한이 너무 높을 때의 증상

메모리 부족과 CPU 부족은 증상이 달라요. 구분할 줄 알면 무엇을 늘려야 할지 알 수 있어요.

메모리 부족 —— 서버 프로세스가 통째로 사라져요. 며칠 돌리고 나서야 생기고 재시작하면 다시 며칠 버틴다면, 머신이 작은 게 아니라 가동 시간 동안 쌓인 메모리이고 예약 재시작이 답이에요. 플레이어 쪽에서는 전원이 동시에 끊기고 목록에서도 서버가 없어져요. 리눅스에서는 OOM killer가 한 일이고 dmesg에 기록이 남아요. 이게 가장 나빠요. 종료되는 순간 기록 중이던 세이브가 함께 깨질 수 있거든요(백업과 복원).

CPU 부족 —— 이동 중에 위치가 밀리고, 거점의 팰이 작업 도중에 멈추고, 채집 판정이 한 박자 늦어요. 끊기지는 않고 그냥 하기 불편해져요. 팰의 행동 시뮬레이션은 싱글 코어 성능에 크게 기대기 때문에, 코어 수를 늘리는 것보다 한 코어가 빠른 쪽이 훨씬 효과적이에요. 이걸 가동 시간 동안 쌓인 메모리나 회선 문제와 구분하고 서버 프레임률로 확정하는 순서는 서버 렉, 원인부터 가려내는 순서에 있어요.

둘 다 충분한데 월드가 너무 큼 —— 접속할 때 로딩이 길고 세이브가 수백 MB를 훌쩍 넘어요. 설정 문제가 아니라 새 월드를 시작할 때가 됐다는 신호예요.

숫자를 정하는 방법

실제로 동시에 접속할 인원으로 정하세요. 친구 목록 숫자가 아니에요.

실용적인 방법은 토요일 밤 피크가 몇 명인지 세고, 거기에 2~4를 더해, 그 숫자로 머신을 고르는 거예요. 상한은 재시작만 감수하면 언제든 올릴 수 있지만, 머신이 부족할 때의 경험은 전원이 동시에 겪는 렉이에요. 상한은 낮게, 머신은 넉넉하게.

놓치기 쉬운 게 하나 더 있어요. 상한은 출입문이기도 해요. 32로 두는 건 주소를 알게 된 사람이면 누구나 한 자리를 차지할 수 있다는 뜻이에요. 사람을 막는 건 상한이 아니라 ServerPassword의 역할이에요.

자주 묻는 질문

인원 상한을 32보다 높일 수 있나요?

공식적으로 지원하는 상한은 32예요. 더 큰 값은 개발사가 공개한 범위 밖이라 안정성 보장이 없고, 문제가 생겼을 때 참고할 경험도 없어요.

바꾼 값이 적용되지 않을 때

설정은 시작할 때 한 번만 읽으니 ServerPlayerMaxNum을 바꾼 뒤에는 재시작이 필요해요. 파일을 잘못 고른 경우까지 포함한 원인은 월드 설정 전체 해설에 정리돼 있어요.

진짜 천장은 어디인가

설정 파일의 그 숫자는 아래 머신이 지켜야 할 약속이에요. 둘이 어긋나면 꺾이는 쪽은 머신이지 숫자가 아니에요.

KeepWorlds의 팰월드 전용 서버는 동시 접속 인원으로 요금제가 나뉘고, 다른 월드와 공유하지 않는 전용 머신에서 돌아가요. 친구 목록이 아니라 실제 토요일 밤 피크에 맞춰 요금제를 고르세요. 요금제의 인원을 넘으면 안정성을 약속하지 않고, 메모리가 차오르는 문제는 콘솔의 매일 예약 재시작으로 잡을 수 있어요.