게임 서버용 VPS 선택 가이드: 필수 사양과 주의사항

어떤 종류의 게임용 VPS를 의미하십니까?

게임 서버용 VPS는 한 가지 용도로는 훌륭한 선택입니다. 바로 여러분과 친구들이 각자의 컴퓨터에서 접속할 수 있는 전용 서버를 운영하는 것입니다. 반면, 사람들이 흔히 말하는 또 다른 의미인 원격 데스크톱을 통해 VPS에서 직접 게임을 플레이하는 용도로는 적합하지 않습니다. 이 두 가지 작업은 서로 상반된 하드웨어 사양을 요구합니다. 전용 서버는 빠른 CPU 코어 하나와 게임 월드를 유지할 충분한 RAM이 필요합니다. 반면 게임 플레이에는 GPU(그래픽 처리 장치)가 필요한데, 일반적인 VPS 요금제에는 GPU가 포함되어 있지 않습니다.

아래의 모든 내용은 첫 번째 용도에 관한 것입니다. 두 번째 용도에 대해서는 많은 사람이 잘못된 서버를 구매하곤 하므로, 시간을 내어 2분 정도 확인해 볼 가치가 있습니다.

VPS에서 게임을 실행할 수 없는 이유

일반적인 VPS는 가상 CPU 코어만 제공하며 그래픽 카드는 제공하지 않습니다. 물리적 호스트로부터 전달되는 하드웨어가 없으므로 게임이 사용할 수 있는 하드웨어 렌더러가 존재하지 않습니다. 다음 명령어로 현재 할당된 장치를 확인할 수 있습니다.

sudo apt install -y pciutils
lspci | grep -iE "vga|3d"

결과로 나타나는 것은 Cirrus Logic이나 virtio GPU 장치와 같은 가상 디스플레이 어댑터입니다. 이는 제공자의 웹 콘솔에서 화면을 보여주기 위한 용도일 뿐, 3D 가속 기능은 없습니다. 이 환경에 데스크톱 환경과 VNC 서버를 설치하고 glxinfo -B을 실행하면 렌더러가 llvmpipe로 표시되는데, 이는 CPU에서 구동되는 Mesa 소프트웨어 렌더러입니다. CPU로 렌더링하는 최신 3D 게임은 초당 프레임 수가 매우 낮아, 외부로 전송되기도 전에 이미 플레이가 불가능한 상태가 됩니다. Windows 인스턴스도 마찬가지입니다. 많은 게임이 실행 시 Direct3D 장치를 생성할 수 없다는 오류를 내며 종료되는데, 이는 장치를 생성할 디스플레이 어댑터 자체가 없기 때문입니다.

두 번째 문제는 원격지에서 사용자에게 도달하는 과정입니다. 원격 서버에서 게임을 플레이하면 모든 프레임이 비디오로 인코딩되어 인터넷을 통해 전송된 뒤, 사용자의 화면에서 디코딩되어야 합니다. 이 과정에서 게임 자체의 입력 지연에 인코딩 및 디코딩 시간이 추가됩니다. 또한 RDP와 VNC는 초당 60프레임의 움직임이 아닌 일반적인 데스크톱 작업을 위해 설계되었습니다. 클라우드 게임 서비스는 실제 GPU 하드웨어와 전용 스트리밍 프로토콜을 사용하여 이 문제를 해결합니다. 일반적인 VPS에는 이 두 가지가 모두 없습니다. 게임을 즐기고 싶다면 GPU 자원을 대여하십시오. 호스팅이 목적이라면 계속해서 읽어 주십시오.

전용 게임 서버의 실제 요구 사항

게임 서버는 시뮬레이션 루프입니다. 서버는 메모리에 월드 데이터를 유지하며 초당 고정된 횟수만큼 시뮬레이션을 진행합니다. 연결된 각 플레이어에게는 해당 플레이어가 볼 수 있는 월드의 일부 정보가 전송됩니다.

이러한 구조가 하드웨어 사양을 결정합니다. 시뮬레이션 루프는 대부분 단일 스레드로 동작하므로 코어 개수보다 코어 클럭 속도가 더 중요합니다. 월드 데이터는 메모리에 상주하므로 보통 RAM 용량이 가장 먼저 도달하는 한계점입니다. 디스크는 게임 플레이 중에는 거의 사용되지 않지만, 데이터를 불러오거나 저장할 때는 사용량이 많아집니다. 네트워크 경로는 핑(ping)을 결정하며, 어떤 요금제를 선택하더라도 이 물리적 경로는 변경되지 않습니다.

싱글 코어 속도가 코어 개수보다 중요합니다

대부분의 게임 서버는 하나의 메인 스레드에서 월드 상태를 업데이트합니다. Minecraft의 틱 루프와 Source 엔진의 서버 프레임이 모두 이런 방식으로 작동합니다. 각 틱에는 처리 제한 시간이 있습니다. Minecraft Java는 초당 20틱으로 실행되며, 각 틱에는 50밀리초의 예산이 주어집니다. 작업이 이 시간 내에 끝나지 않으면 서버는 정확히 다음과 같은 메시지를 출력합니다.

[12:04:51] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2547ms or 50 ticks behind

이 줄은 하나의 스레드가 제한 시간을 초과했음을 의미합니다. 코어를 추가한다고 해서 해당 스레드에 더 많은 시간이 주어지지는 않습니다. 8개의 느린 vCPU를 가진 플랜보다 2개의 빠른 vCPU를 가진 플랜이 틱 레이트를 더 잘 유지합니다. 8개 중 단 하나만이 중요한 작업을 수행하기 때문입니다.

결정하기 전에 반드시 싱글 스레드 속도를 측정하십시오.

sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run

events per second 줄을 확인하십시오. 이 숫자는 단독으로는 의미가 없으며 비교할 때 비로소 가치가 있습니다. 따라서 두 개의 후보 플랜에서 각각 실행한 뒤 결과를 나란히 놓고 비교하십시오. 전체 VPS 벤치마크 실행에서는 디스크와 네트워크도 동일한 방식으로 다룹니다.

물론 추가 코어에도 쓸모는 있습니다. 추가 코어는 틱 스레드의 시간을 뺏지 않으면서 두 번째 게임 서버, 데이터베이스, 야간 백업, 청크 사전 생성 작업을 처리합니다. 서버 소프트웨어들도 점차 분산 처리를 도입하고 있으며, 인기 있는 Minecraft 서버 포크인 Paper는 일부 작업을 메인 틱 스레드 밖으로 분리하기도 합니다. 따라서 구매할 때는 코어 개수가 많은 것보다 소수의 빠른 코어를 선택하는 것이 좋습니다.

플랜 페이지에는 절대 나오지 않지만, 비용을 지불한 빠른 코어가 실제로 온전히 내 것인지 결정하는 지표가 있습니다.

vmstat 1 5

st 열은 가상 CPU가 실행 준비를 마쳤음에도 물리 호스트가 해당 코어를 다른 사용자에게 할당하여 대기한 시간의 비율을 나타냅니다. st가 몇 퍼센트 이상으로 꾸준히 유지된다면 해당 호스트는 과도하게 할당(oversold)된 상태입니다. 서버의 top 수치는 유휴 상태를 나타내더라도, 그 유휴 시간은 사용자가 쓸 수 있는 것이 아니므로 플레이어는 끊김 현상을 느끼게 됩니다.

게임 서버에는 RAM이 얼마나 필요한가?

[
  {
    "label": "Minecraft Java, vanilla",
    "players": 10,
    "ram_gb": 2
  },
  {
    "label": "Minecraft Java, large modpack",
    "players": 10,
    "ram_gb": 8
  },
  {
    "label": "Valheim",
    "players": 10,
    "ram_gb": 4
  },
  {
    "label": "Palworld",
    "players": 32,
    "ram_gb": 16
  }
]

위 수치는 2026년 8월 기준으로 게임 및 모드팩 문서에서 게시하는 초기 할당량입니다. 이는 단일 서버에서 측정한 절대적인 수치가 아니라 지침일 뿐입니다. Vanilla Minecraft Java는 10 명 정도의 플레이어라면 2 GB의 힙 메모리로 원활하게 동작합니다. 같은 인원이라도 대규모 모드팩을 사용하면 8 GB가 필요한데, 이는 모드가 추가하는 엔티티와 생성된 구조물들이 모두 힙 메모리에 상주하기 때문입니다. Valheim의 최소 요구 사양은 2 GB로 명시되어 있으나, 소규모 월드를 운영하는 관리자들은 프로세스가 3 GB 근처에서 안정화된다고 보고하므로 4 GB로 시작하는 것이 합리적입니다. Palworld는 예외적으로 32 명의 최대 플레이어 수에 대해 16 GB를 요구하며, 이는 Pocketpair의 권장 사양입니다.

RAM은 접속자 수에 비례하지 않습니다. 로드된 월드 크기에 비례합니다. 각 플레이어는 자신의 주변 영역을 로드된 상태로 유지하므로, 두 플레이어가 함께 있는 경우보다 맵의 반대편을 탐험하는 두 플레이어가 훨씬 더 많은 자원을 소모합니다. 이것이 바로 "플레이어당 RAM"이 대략적인 지침일 뿐이며 "활성 영역당 RAM"이 실제 결정 요인인 이유입니다. 탐험을 즐기는 소규모 그룹이 인원수의 두 배에 맞춰 설계된 계획보다 더 많은 자원을 필요로 할 수 있는 이유도 여기에 있습니다.

Java 서버에는 두 가지 추가 규칙이 필요합니다. JVM이 힙 크기를 조정하느라 일시 정지하는 일이 없도록 최소 힙과 최대 힙을 동일한 값으로 설정하십시오.

java -Xms4G -Xmx4G -jar server.jar nogui

그다음 여유 공간을 확보하십시오. JVM은 할당된 힙 외에도 스레드 스택과 네이티브 버퍼를 위해 메모리를 사용하며, 커널은 월드 파일을 빠르게 읽기 위해 페이지 캐시가 필요합니다. 6 GB 서버라면 4 GB 힙은 적절하지만 6 GB 힙은 부적절합니다.

두 가지 메모리 오류는 완전히 다른 양상을 보이므로 두 가지 메시지를 모두 숙지해야 합니다. 힙이 너무 작으면 Java 내부에서 오류가 발생하며, 서버는 대개 비정상적인 상태로 계속 동작합니다.

java.lang.OutOfMemoryError: Java heap space

힙이 서버 사양보다 크면 프로세스 자체가 외부에서 강제 종료됩니다. 콘솔에는 Killed 메시지만 출력되며, 실제 원인은 커널 로그에 기록됩니다.

sudo dmesg -T | grep -i "out of memory"

스왑(swap)을 추가하면 프로세스 강제 종료는 막을 수 있지만 근본적인 해결책은 아닙니다. 스왑에서 월드 데이터를 읽어야 하는 틱 루프는 모든 처리 기한을 놓치게 되며, 결과적으로 플레이어는 서버가 충돌하는 대신 멈추는 현상을 겪게 됩니다.

2026년 8월 기준 버전 참고 사항입니다. Minecraft Java 1.20.5 이상 버전은 Java 21을 요구합니다. 이전 런타임으로 실행하면 unsupported class file version 오류가 발생하는데, 이는 컴파일러 메시지처럼 보여 처음 접하는 사람들을 혼란스럽게 합니다.

sudo apt install -y openjdk-21-jre-headless
java -version

게임 서버에서 디스크 속도가 중요한가요?

게임 플레이 중에는 예상보다 덜 중요하지만, 특정 두 시점에서는 매우 중요합니다. 서버가 시작될 때 월드 데이터가 메모리로 읽히고 자동 저장 시 다시 디스크에 기록되므로, 디스크 속도는 부팅 속도와 자동 저장 시 발생하는 일시적인 멈춤 현상으로 나타납니다. 그 사이의 대부분 읽기 작업은 RAM에서 처리됩니다.

이 요약보다 디스크가 더 중요하게 작용하는 두 가지 이유가 있습니다. 플레이어가 이동할 때 새로운 청크나 구역을 디스크에서 불러오는데, 이 읽기 작업은 틱(tick) 예산 내에서 이루어져야 합니다. 대규모 월드에서 자동 저장이 실행되면 한꺼번에 많은 양을 기록하게 되며, 속도가 느린 볼륨에서는 이 쓰기 작업이 루프를 차단하여 앞서 언급한 "Can't keep up" 경고를 발생시킵니다. 이는 처리량(throughput) 문제라기보다 지연 시간(latency) 문제이며, 이것이 바로 VPS에서 NVMe와 SATA SSD의 차이가 단순한 초당 메가바이트(MB/s) 수치보다 더 중요한 이유입니다. 여기서 중요한 것은 작은 작업 하나를 처리하는 데 걸리는 시간입니다.

볼륨 크기는 성장을 고려하여 설정하십시오. 누군가 새로운 곳을 탐험할 때마다 월드 데이터는 커지며, 백업본은 그 크기만큼 배가됩니다. 한 달 동안 매주 du -sh world를 실행해 보면 실제 증가율을 파악할 수 있습니다.

틱 레이트, 핑, 그리고 이 둘의 차이

틱 레이트(Tick rate)는 서버가 초당 세계 상태를 재계산하는 횟수를 의미합니다. Minecraft Java는 20으로 동작하며, Source 엔진 서버는 일반적으로 64로 동작합니다. Minecraft에서 틱 레이트는 게임 설계의 일부이므로 더 높은 수치를 구매할 수 없으며, 목표는 20을 초과하는 것이 아니라 20을 유지하는 것입니다.

핑(Ping)은 플레이어와 서버 사이의 왕복 시간을 의미합니다. 이 두 요소는 서로 다른 불만 사항을 야기하므로, 비용을 지출하기 전에 원인을 구분해야 합니다. 서버가 틱을 놓치면 모든 플레이어가 동시에 래그(rubber-banding)를 겪게 되며, 서버 로그에 해당 내용이 명시됩니다. 반면 특정 플레이어의 네트워크 경로가 길면 해당 플레이어만 래그를 겪고 나머지 그룹은 정상적으로 동작합니다. 더 좋은 CPU를 사용한다고 해서 두 번째 사례가 해결되지는 않습니다.

지연 시간은 요금제가 아니라 물리적 거리에 좌우됩니다

광섬유 속 빛은 1밀리초당 약 200km를 이동합니다. 왕복 거리는 이동 거리의 두 배이므로, 플레이어와 서버 사이의 거리 100km당 최소 지연 시간은 약 1ms입니다. 어떤 서비스 제공업체도 이 물리적 한계를 넘을 수 없으며, 요금제 업그레이드로도 해결되지 않습니다.

[
  {
    "label": "Toronto to New York",
    "distance_km": 550,
    "rtt_floor_ms": 5.5
  },
  {
    "label": "Dallas to Chicago",
    "distance_km": 1290,
    "rtt_floor_ms": 12.9
  },
  {
    "label": "Dallas to Los Angeles",
    "distance_km": 1990,
    "rtt_floor_ms": 19.9
  },
  {
    "label": "New York to London",
    "distance_km": 5570,
    "rtt_floor_ms": 55.7
  },
  {
    "label": "Los Angeles to Sydney",
    "distance_km": 12070,
    "rtt_floor_ms": 120.7
  }
]

위 수치는 대권 거리를 기준으로 계산한 이론적 최솟값입니다. 실제 광케이블은 직선으로 연결되지 않으며, 경로상의 모든 라우터가 지연 시간을 추가하므로 실제 환경에서는 이론적 최솟값의 약 2배 정도가 일반적인 결과입니다. 토론토에서 뉴욕의 서버에 접속하는 경우 거리는 550 km이며, 이론적 최솟값은 5.5 ms이지만 실제로는 10ms 중반대의 지연 시간이 나타납니다. 로스앤젤레스에서 시드니로 연결하는 구간의 최솟값은 120.7 ms이며, 비용을 아무리 지불해도 이 물리적 한계를 단축할 수는 없습니다.

따라서 서버는 사용자가 위치한 곳과 가까운 곳에 배치해야 합니다. 사용자가 대양을 사이에 두고 나뉘어 있다면 누군가는 긴 경로를 이용할 수밖에 없으며, 가장 공평한 해결책은 일반적으로 플레이어가 가장 많이 분포한 지역을 선택하는 것입니다.

추측하지 말고 경로를 직접 측정하십시오:

sudo apt install -y mtr-tiny
mtr -rwzc 100 203.0.113.10

마지막 줄부터 확인하십시오. 마지막 줄은 서버를 의미하며, 해당 지점의 패킷 손실과 지연 시간만이 게임 체감 성능을 결정합니다. 중간 홉에서 나타나는 패킷 손실은 마지막 홉이 정상이라면 대부분 해당 라우터의 ICMP 속도 제한 때문입니다. 라우터는 실제 트래픽을 정상적으로 처리하면서도 프로브 패킷에 대한 응답은 후순위로 미루기 때문입니다. 모든 플레이어는 각기 다른 경로를 거치므로, 각 플레이어가 직접 서버를 대상으로 측정하게 하십시오.

게임에 필요한 포트만 개방하기

게임 서버는 한두 개의 포트만 열면 충분하며, 그 외의 포트는 닫아야 합니다. 일반적인 기본값은 다음과 같습니다.

• Minecraft Java Edition: TCP 25565
• Minecraft Bedrock Edition: UDP 19132
• Valheim: UDP 2456 및 UDP 2457
• Palworld: UDP 8211
• Counter-Strike 2와 같은 Source 엔진 게임: UDP 27015

일부 게임은 추가 쿼리 포트를 사용하므로 반드시 해당 게임의 공식 문서를 확인하십시오. Valheim이 가장 대표적인 예입니다. 2456 포트는 게임 트래픽을 처리하고, 2457 포트는 서버 브라우저 목록에 서버를 표시하기 위한 Steam 서버 쿼리에 응답합니다. Valheim은 UDP만 사용하므로 이 포트들을 TCP로 개방해도 아무런 효과가 없습니다.

방화벽을 활성화하기 전에 반드시 SSH 접속을 허용하십시오. 그렇지 않으면 서버에 스스로 접속할 수 없게 됩니다.

sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo ufw status verbose

많은 호스팅 제공업체는 서버 내부 방화벽과 별개로 제어판에서 네트워크 방화벽을 운영합니다. ufw에서 포트를 열었더라도 제어판에서 닫혀 있으면 연결이 거부됩니다. 외부에서 볼 때는 증상이 동일하므로, 설정 파일을 수정하기 전에 두 곳 모두 확인하십시오.

다른 기기에서 TCP 포트를 확인하는 방법은 간단합니다.

sudo apt install -y netcat-openbsd
nc -vz 203.0.113.10 25565

UDP는 위와 같은 방식으로 테스트할 수 없습니다. 닫힌 UDP 포트는 일반적으로 아무런 응답을 하지 않으므로, 응답이 없다는 사실만으로는 포트 상태를 알 수 없습니다. 대신 서버 측에서 게임 프로세스가 예상한 포트에 바인딩되어 있는지 확인하십시오.

sudo ss -lunp | grep 2456

원격 콘솔 프로토콜인 RCON은 절대 인터넷에 노출하지 마십시오. RCON은 기본적으로 25575 포트를 사용하며, 일반 텍스트 연결을 통해 단일 비밀번호를 전송합니다. 이를 127.0.0.1에 바인딩하고 SSH 터널을 통해서만 접근하십시오. 또한 게임 서버는 권한이 없는 별도의 사용자 계정으로 실행하여, 모드의 버그가 시스템 전체에 영향을 미치지 않도록 하십시오. 새로운 VPS에서의 첫 10분 가이드에서는 이 섹션에서 이미 완료했다고 가정하는 사용자 계정 생성 및 SSH 보안 강화 방법을 다룹니다.

systemd를 사용하여 서버 실행 및 자동 재시작 설정

SSH 세션에서 수동으로 시작한 서버는 세션이 종료되면 함께 죽으며, 재부팅 후에도 다시 시작되지 않습니다. systemd는 이 두 가지 문제를 모두 해결합니다. /etc/systemd/system/minecraft.service 파일을 작성하십시오:

[Unit]
Description=Minecraft Java server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms4G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15
TimeoutStopSec=180

[Install]
WantedBy=multi-user.target

Restart=on-failure 설정은 서버가 충돌했을 때 자동으로 복구하며, 정상적인 종료 시에는 서버를 멈춘 상태로 유지하므로 권장되는 방식입니다. Restart=always 설정은 서버를 의도적으로 중지할 때마다 계속해서 다시 시작하려 합니다. TimeoutStopSec=180 설정은 생각보다 중요합니다. systemctl stop 설정은 SIGTERM 신호를 보내는데, 일반적인 Minecraft 서버는 이 신호를 받아 월드 데이터를 저장한 뒤 종료합니다. 만약 제한 시간이 지나면 systemd는 SIGKILL 신호를 보냅니다. 대규모 월드는 데이터를 디스크에 기록하는 데 기본값인 90초보다 더 긴 시간이 걸릴 수 있으며, SIGKILL이 전달되는 시점에 디스크에 기록되지 않은 데이터는 모두 유실됩니다.

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo journalctl -u minecraft -f

정상적으로 시작되면 Done (12.345s)! For help, type "help"과 같은 줄이 출력됩니다. 만약 유닛 상태가 activating과 failed 사이를 반복한다면 journalctl -u minecraft -n 50에서 원인을 확인할 수 있습니다. 보통 WorkingDirectory 내의 경로가 잘못되었거나 서버 사양보다 힙 메모리 설정이 큰 경우가 많습니다.

systemd는 대화형 콘솔을 제공하지 않으므로 미리 대비해야 합니다. 명령어를 입력하려면 localhost에서 RCON을 사용하거나, 로그인 세션 사이에도 Claude Code 세션을 유지하는 방법과 동일하게 tmux 세션 내에서 서버를 실행하십시오.

Steam을 통해 배포되는 게임 서버는 이 모든 과정 이전에 SteamCMD가 필요합니다. Ubuntu 패키지는 32비트 바이너리이므로 아키텍처 설정 줄이 포함되어 있습니다. 해당 줄을 생략하면 apt 명령어가 설치 후보를 찾을 수 없다는 오류를 반환합니다:

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd

일부 게임 서버는 실행 시간이 길어질수록 메모리 사용량이 증가하며, 이를 근본적으로 해결하기보다는 한가한 시간에 주기적으로 재시작하는 것이 일반적인 우회 방법입니다. systemctl restart을 호출하는 systemd 타이머는 cron 항목보다 관리하기 쉽습니다. systemctl list-timers 명령어를 사용하면 다음 실행 예정 시간을 정확히 확인할 수 있기 때문입니다.

일정 기반으로 월드 백업하기

게임 서버의 모든 데이터는 월드 디렉터리와 플레이어 데이터를 제외하면 언제든 다시 생성할 수 있습니다. 게임을 재설치하는 데는 몇 분이면 충분하지만, 그룹이 함께 건설한 결과물을 다시 만드는 데는 몇 달이 걸릴 수 있습니다.

가장 안전한 백업은 아무런 쓰기 작업이 일어나지 않을 때 수행하는 것입니다. 서버를 1분간 중단하는 것이 이를 보장하는 가장 간단한 방법입니다.

sudo systemctl stop minecraft
sudo tar czf /var/backups/mc-$(date +%F).tgz -C /opt/minecraft world world_nether world_the_end
sudo systemctl start minecraft

매일 밤 서버를 멈추는 것이 불가능하다면, 대신 월드 데이터를 먼저 플러시(flush)하십시오. Minecraft 콘솔에서 save-off는 자동 저장을 중지하고, save-all flush은 대기 중인 모든 데이터를 기록하며, save-on은 복사가 완료된 후 자동 저장을 다시 활성화합니다. 서버가 쓰기 작업을 수행하는 도중에 월드를 복사하면 절반만 기록된 리전 파일이 생성될 수 있으며, 이는 정작 복구가 필요한 시점이 되어서야 문제를 발견하게 됩니다.

최소한 한 개의 사본은 서버 외부 장치에 보관하십시오. 동일한 디스크에 저장된 백업은 디스크 장애 시 함께 소실됩니다. 제공업체의 스냅샷은 편리한 기능일 뿐 진정한 백업은 아닙니다. 동일한 계정 내에 존재하므로 계정 손실 시 함께 사라질 수 있기 때문입니다. 외부 저장소로의 정기적인 restic 백업은 보존 기간 설정과 중복 제거를 지원하므로, 매일 밤 월드를 복사하더라도 디스크 용량을 가득 채우지 않습니다.

그다음에는 반드시 복구를 시도해 보십시오. 한 번도 복구해 보지 않은 백업은 추측에 불과합니다. 어젯밤 생성된 아카이브를 별도의 디렉터리에 추출하고, 테스트 서버를 해당 경로로 지정하여 월드가 정상적으로 로드되는지, 건축물들이 그대로 남아 있는지 확인하십시오.

결정하기 전에 먼저 확인하십시오

1년 단위보다는 1개월 단위로 구매하여 실제 플레이어들과 함께 하룻밤 동안 테스트를 진행하십시오. 단일 스레드 sysbench 수치를 실행한 다음, 모든 플레이어가 서버를 향해 mtr을 실행하도록 하십시오. 전체 VPS 벤치마크 절차에서는 해당 도구들을 사용하는 방법을 단계별로 안내하며 잘못된 결과가 어떤 것인지 보여줍니다. 또한 VPS의 실제 월간 비용을 확인하면 요금제 페이지에 가장 크게 적힌 사양이 아니라, 실제로 서버 성능을 제한하는 자원에 대해 비용을 지불하고 있는지 검토할 수 있습니다.

이 글에서 다루지 않은 내용은 다음 두 게시물에서 이어집니다. VPS에서 Minecraft 서버 구축하기는 위에서 설명한 모든 과정을 가장 많은 사용자가 시작하는 게임을 예로 들어 단계별로 설명합니다. VPS로 운영 가능한 더 넓은 범위의 서비스는 게임을 즐기지 않는 시간에 서버를 유용하게 활용하고 싶다면 읽어볼 가치가 있습니다.

FAQ

게임용 PC를 사는 대신 VPS에서 게임을 할 수 있습니까?

아니요. 일반적인 VPS에는 GPU가 없으며 제공업체의 콘솔을 위한 가상 디스플레이 어댑터만 존재합니다. 따라서 데스크톱 환경을 설치하더라도 glxinfo -B는 소프트웨어 렌더러 llvmpipe를 보고하며, 3D 게임은 초당 몇 프레임 수준으로 동작합니다. GPU를 연결하더라도 원격 플레이는 모든 프레임의 왕복 과정에 비디오 인코딩과 디코딩을 추가하며, RDP와 VNC는 애초에 이러한 용도로 설계되지 않았습니다. VPS는 사용자들이 접속할 전용 서버를 호스팅하기 위한 용도입니다. 게임을 즐기는 것이 목적이라면 GPU 시간을 대여하거나 클라우드 게임 서비스를 이용하십시오.

게임 서버에는 CPU 코어가 몇 개 필요합니까?

대부분의 게임에서는 느린 코어 8개보다 빠른 코어 2개가 더 유리합니다. 월드 시뮬레이션은 하나의 메인 스레드에서 실행되며, 추가 코어는 해당 스레드가 50 ms의 처리 기한을 맞추는 데 도움을 줄 수 없기 때문입니다. sysbench cpu --cpu-max-prime=20000 --threads=1 run으로 후보 플랜을 비교하고 초당 이벤트 처리량 수치를 확인하십시오. 추가 코어는 동일한 서버에서 두 번째 서버나 데이터베이스를 함께 운영할 때 가치가 있습니다. 이러한 워크로드는 틱 스레드의 자원을 점유하지 않고 실행될 수 있기 때문입니다.

Minecraft 서버에는 RAM이 얼마나 필요합니까?

바닐라 월드에서 약 10명의 플레이어가 접속할 경우 2 GB 정도의 힙 메모리가 필요하며, 동일한 인원수의 대규모 모드팩을 운영할 경우 8 GB가 필요합니다. -Xms과 -Xmx을 동일한 값으로 설정하고, 운영체제를 위해 1 GB에서 2 GB 정도의 여유 메모리를 확보하십시오. JVM은 힙 외부의 메모리도 사용하며 커널은 페이지 캐시가 필요하기 때문입니다. 힙 크기가 서버의 물리 메모리보다 크면 커널에 의해 프로세스가 강제 종료되며, 이는 Java 오류가 아닌 dmesg의 메모리 부족(out of memory) 로그로 나타납니다.

서버의 CPU와 RAM이 충분한데도 플레이어들이 렉을 겪는 이유는 무엇입니까?

이러한 현상에는 두 가지 원인이 있습니다. 먼저 서버 로그에서 Can't keep up! Is the server overloaded?을 확인하십시오. 이는 메인 스레드가 50 ms의 틱 예산을 초과했음에도 다른 코어들은 유휴 상태임을 의미합니다. 해당 로그가 없다면 네트워크 경로 문제일 가능성이 높으므로, 각 플레이어가 서버 주소를 대상으로 mtr -rwzc 100 203.0.113.10을 실행하여 마지막 줄을 확인하게 하십시오. 또한 vmstat 1의 st 열을 확인하십시오. 스틸 타임(steal time)이 몇 퍼센트 이상이라면 호스트 서버가 과도하게 할당된 상태이므로, 유휴 상태로 보이는 CPU 자원을 실제로 사용할 수 없는 상황입니다.

게임 서버를 위해 어떤 포트를 열어야 합니까?

게임 전용 포트와 SSH 포트만 열면 됩니다. Minecraft Java는 TCP 25565, Minecraft Bedrock은 UDP 19132, Valheim은 UDP 2456 및 2457, Palworld는 UDP 8211을 사용합니다. ufw enable를 실행하기 전에 SSH 규칙을 먼저 추가하십시오. 그렇지 않으면 서버 접속 권한을 잃게 됩니다. 많은 제공업체가 제어판에서 별도의 방화벽을 운영하므로, 양쪽 모두에서 포트를 열어야 한다는 점을 기억하십시오. RCON 포트 25575는 비밀번호가 평문으로 전송되므로 절대 인터넷에 공개하지 마십시오.