팰월드 서버 업데이트 방법: 버전 불일치와 세이브를 지키는 순서

팰월드 클라이언트는 스팀이 알아서 올려 주지만, 전용 서버는 아무도 올려 주지 않아요. 그래서 패치가 나온 날의 풍경은 늘 같아요. 어제까지 멀쩡하던 서버에 갑자기 아무도 못 들어가고, 접속 시도는 평소보다 오래 걸리다가 타이틀 화면으로 돌아가요. 이 글은 팰월드 서버 업데이트를 세이브를 잃지 않는 순서로 하는 방법이에요. 서버를 아직 만들지 않았다면 전용 서버 구축 순서부터 보세요.

버전이 어긋나면 플레이어에겐 이렇게 보여요

버전 불일치는 친절한 오류 메시지로 오지 않아요. 그래서 서버를 여는 사람이 제일 먼저 의심하는 건 대개 포트나 방화벽이고, 정작 원인은 빌드 번호예요.

마지막 줄이 판별선이에요. 전원이 동시에 못 들어오면 버전, 한두 명만 못 들어오면 그 사람 환경이에요. 패치가 배포된 뒤 며칠은 전자가 압도적으로 많아요.

확인은 두 곳을 비교하면 끝나요. 게임 메인 메뉴 구석에 적힌 버전과, 서버 시작 로그에 찍히는 버전이에요. REST API를 켜 뒀다면 GET /v1/api/info가 서버 버전을 그대로 돌려줘요(REST API 사용법).

위쪽에 새 빌드가 떴는지 확인하는 법

전용 서버의 앱 ID는 2394010이에요. 게임 본편(1623730)과 다른 번호고, 배포도 따로 이뤄져요. 지금 설치된 빌드 번호는 설치 폴더 안의 매니페스트에 적혀 있어요.

grep buildid /home/palserver/palworld/steamapps/appmanifest_2394010.acf

스팀이 지금 배포 중인 빌드 번호는 SteamCMD에 물어보면 돼요.

steamcmd +login anonymous +app_info_update 1 +app_info_print 2394010 +quit \
  | grep -A 5 '"public"'

branches → public 아래의 buildid가 현재 배포 중인 번호, timeupdated가 그게 올라온 시각이에요. 두 숫자가 다르면 업데이트할 때가 된 거예요.

다만 이 비교를 매번 손으로 할 필요는 없어요. validate를 붙인 app_update는 이미 최신이면 사실상 아무것도 하지 않아요. 그래서 "새 빌드가 있는지 확인하고 있으면 받는다"는 판단 자체를 SteamCMD에 넘겨도 돼요. 비교가 쓸모 있는 경우는 하나예요. 지금 사람이 들어와 있는데 정지해도 되는지를 먼저 알고 싶을 때요.

순서: 공지 → 강제 저장 → 정지 → 업데이트 → 시작

이 다섯 단계의 순서가 이 글의 핵심이에요. 한 단계라도 앞뒤가 바뀌면 잃는 게 생겨요.

PW='충분히 긴 비밀번호'
API='http://127.0.0.1:8212/v1/api'

# 1. 공지: 지금 접속 중인 사람에게 시간을 줘요
curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Server updates in 5 minutes"}'
sleep 300

# 2. 강제 저장: 메모리에 있는 월드를 디스크로 내려요
curl -s -u "admin:$PW" -X POST "$API/save"
sleep 10

# 3. 정지: 프로세스가 완전히 내려간 뒤에 다음 단계로
sudo systemctl stop palworld

# 4. 백업은 여기에서 (다음 절)

# 5. 업데이트
sudo -u palserver steamcmd +force_install_dir /home/palserver/palworld \
     +login anonymous +app_update 2394010 validate +quit

# 6. 시작
sudo systemctl start palworld

REST API 자체를 아직 안 켰다면 PalWorldSettings.ini에서 RESTAPIEnabled=True와 AdminPassword를 먼저 넣어야 해요. 인증은 HTTP Basic이고 사용자 이름은 항상 admin이며, 8212 포트는 방화벽에서 열지 마세요. 개발사가 인터넷에 직접 노출할 설계가 아니라고 못 박아 뒀어요.

세 가지만 더 짚을게요.

• 서버가 떠 있는 채로 app_update를 돌리지 마세요. 리눅스는 실행 중인 프로그램의 파일을 덮어써도 막아 주지 않아요. 프로세스는 옛 바이너리로 계속 돌고 디스크의 파일만 새것이 된 어중간한 상태가 되고, 그 상태는 다음 재시작 때에야 드러나요.
• validate는 매번 붙이세요. 파일 무결성 검사라 시간이 조금 더 걸리지만, 중간에 끊긴 다운로드가 남긴 손상 파일은 이 옵션으로만 잡혀요.
• 업데이트하는 동안에는 아무도 못 들어와요. 용량이 큰 패치는 몇 분이 걸리니, 다 같이 모여서 기다리는 시간에 시작하지 마세요.

업데이트 직전의 완전한 백업 한 번

세이브 형식은 버전에 따라 바뀔 때가 있고, 한 번 새 빌드로 열린 월드는 옛 빌드로 되돌릴 수 없어요. 그래서 백업은 "매일 한 번"과 별개로 업데이트 직전에 손으로 한 번 더 필요해요. 평소에는 쓸 일이 없다가, 딱 한 번 있는 사고에 전부를 좌우해요.

복사할 건 월드 폴더 통째예요. 서버를 정지한 뒤에 복사하세요.

sudo systemctl stop palworld
sudo -u palserver cp -a \
     /home/palserver/palworld/Pal/Saved/SaveGames/0/<WorldID> \
     /home/palserver/backups/pre-update-$(date +%F)

<WorldID>는 서버가 처음 시작할 때 만든 16진수 폴더 이름이에요. 그 안의 Level.sav 하나만 복사한 백업은 복원했을 때 모두가 새 캐릭터로 시작해요. 월드도 거점도 그대로인데 주인이 사라지는 거예요. Players/까지 같이 가져가야 하는 이유와 복원 순서는 팰월드 세이브 데이터: 저장 위치, 백업, 복원 순서에 자세히 있어요.

업데이트 후 월드가 안 열릴 때

먼저 세 가지 중 어느 쪽인지 가르세요. 대응이 전혀 달라요.

가운데가 가장 놀라는 증상이지만, 실제로 사라진 건 아무것도 없어요. 원래 <WorldID> 폴더는 그대로 있고 서버가 그걸 못 읽었을 뿐이에요. 원래 폴더를 지우지 마세요.

되돌리는 방법은 "옛 빌드로 내려가기"가 아니라 업데이트 직전 백업을 새 빌드 위에 복원하기예요. 이유는 두 가지예요. 클라이언트는 이미 새 버전으로 올라갔으니 옛 빌드 서버에는 어차피 아무도 못 들어오고, 월드가 안 열리는 사고의 대부분은 형식 변경이 아니라 정지가 깨끗하지 않아서 생긴 반쯤 쓰인 세이브거든요. SteamCMD에 특정 빌드를 내려받는 download_depot가 있긴 하지만 depot ID와 manifest ID를 직접 찾아야 하고, 위의 이유로 얻는 게 거의 없어요.

복원 순서는 이래요. 서버를 정지하고, 지금 있는 <WorldID> 폴더를 지우지 말고 다른 이름으로 옮겨 둔 다음, 백업을 원래 이름으로 되돌리고, 시작해요. 월드가 열리면 옮겨 둔 폴더는 며칠 지켜본 뒤에 지우세요.

윈도우와 리눅스의 차이

명령과 도구만 다르고 순서는 똑같아요.

윈도우에는 조심할 게 하나 더 있어요. 스팀 클라이언트의 도구 목록으로 서버를 설치했다면 스팀이 서버가 돌아가는 중에 마음대로 업데이트할 수 있어요. 그게 정확히 쓰다 만 세이브를 만드는 방법이에요. 자동 업데이트 설정을 손보거나, 아예 SteamCMD로만 관리하는 쪽이 안전해요.

매일 예약 재시작에 업데이트를 묶기

어차피 서버는 하루에 한 번 멈춰야 해요. 팰월드 서버에는 아직 고쳐지지 않은 메모리 누수가 있어서 예약 재시작이 선택이 아니거든요(메모리 누수와 예약 재시작). 이미 멈추는 김에 시작할 때마다 버전을 확인하게 하면 추가 비용은 사실상 0이에요.

# palworld.service의 [Service] 섹션에 추가
TimeoutStartSec=30min
ExecStartPre=/usr/games/steamcmd +force_install_dir /home/palserver/palworld +login anonymous +app_update 2394010 validate +quit

새벽 재시작이 그대로 버전 점검이 돼요. 패치가 나온 날 아침에는 서버가 이미 새 빌드고, 패치가 없는 날에도 validate가 파일을 전부 검사하느라 시작이 1~2분 더 걸려요. TimeoutStartSec는 빼지 마세요. Type=simple이어도 systemd의 기본 시작 제한 시간 90초가 ExecStartPre에도 걸려서, 큰 패치를 받는 데 그보다 오래 걸리면 도중에 끊기고 서버가 아예 안 떠요. 그 "하루 한 번 멈추기"를 어떻게 거는지는 — 부팅 시 자동 실행, 죽었을 때의 자동 복구와 함께 — 팰월드 24시간 서버 만들기에 있어요.

다만 이 한 줄에는 빠진 게 있어요. 업데이트 전에 백업하지 않아요. 그래서 재시작 직전에 백업이 한 번 도는 구성이 함께 있어야 해요. 백업 없는 자동 업데이트는 몇 달 잘 돌다가 한 번에 크게 잃는 쪽이에요.

자주 묻는 질문

팰월드 서버는 어떻게 업데이트하나요?

순서가 전부예요. 게임 안에 공지를 띄우고, REST API로 강제 저장하고, 서버 프로세스를 정지하고, 세이브 폴더를 통째로 백업한 다음, sudo -u palserver steamcmd +force_install_dir /home/palserver/palworld +login anonymous +app_update 2394010 validate +quit를 돌리고 다시 시작해요. +force_install_dir는 설치 폴더를 가리키고 +login보다 앞에 둬야 해요. 빠지면 SteamCMD가 다른 곳에 한 벌을 더 받고, 서버는 옛 빌드 그대로예요. 돌아가는 서버 위에 덮어쓰면 안 되고, 백업은 업데이트 뒤가 아니라 앞이에요.

업데이트하면 세이브 데이터가 날아가나요?

정상적으로는 안 날아가요. 업데이트는 서버 프로그램 파일만 바꾸고 Pal/Saved/SaveGames/ 안은 건드리지 않아요. 위험한 건 업데이트 자체가 아니라 저장하는 중에 프로세스를 죽이는 것이에요. 강제 저장 → 정지 → 업데이트 순서를 지키고, 그 직전에 월드 폴더를 통째로 한 번 복사해 두세요.

업데이트 후에 서버 접속이 안 되는데 왜 그런가요?

전원이 동시에 못 들어오면 거의 버전 문제예요. 서버가 옛 빌드에 남아 있을 수도 있고, 반대로 서버만 올라가고 누군가의 스팀이 아직 클라이언트를 안 올렸을 수도 있어요. 서버 시작 로그의 버전과 게임 메인 메뉴 구석의 버전을 비교해서 어느 쪽이 뒤처졌는지부터 확인하세요. 한두 명만 못 들어오는 거라면 버전이 아니라 주소나 포트 쪽이에요.

팰월드 전용 서버는 자동으로 업데이트되나요?

기본적으로는 안 돼요. 스팀이 올려 주는 건 클라이언트뿐이고 서버는 그대로 남아요. systemd의 ExecStartPre에 SteamCMD 한 줄을 넣어(큰 다운로드가 끊기지 않게 TimeoutStartSec도 늘려서) 시작할 때마다 검사하게 만들 수는 있지만, 그것만으로는 업데이트 전 백업이 없어요. 자동으로 돌릴 거라면 백업까지 같은 흐름 안에 들어 있어야 해요.

호스팅에선 업데이트가 클릭 한 번이에요

위 단계 중에 어려운 건 하나도 없어요. 어려운 건 패치가 나올 때마다 누군가 그걸 알아채고 있어야 한다는 점이에요. 팰월드는 자주 패치되고, 대체로 평일 낮에 나오고, 그 시간에 서버를 만든 사람은 대개 학교나 회사에 있어요. 그래서 발견은 저녁에 다 같이 들어가려던 순간에 일어나고, 거기서부터 백업하고 업데이트하는 데 또 한참이 걸려요.

KeepWorlds의 팰월드 전용 서버에서는 알아채는 일을 시스템이 맡아요. 버전 가드는 새 빌드가 나오면 자동으로 감지해서 콘솔의 서버 페이지에 알려 줘요. ‘지금 업데이트’를 누르면 나머지는 순서대로 돌아가요. 세이브 데이터를 먼저 백업한 뒤에 업데이트하고 서버를 다시 실행해요. 언제 멈출지는 직접 정하니 한창 놀던 중에 끊길 일이 없어요. 멈추기 전에는 게임 안에 공지가 나가고, 카운트다운을 마치고 강제 저장까지 끝낸 뒤에 정지하니 접속 중이던 사람도 진행을 잃지 않아요. 백업은 콘솔의 내 서버에 시점별로 쌓이고, 돌아가고 싶은 지점을 골라 복원할 수 있어요.