CPU와 RAM: 게임 서버를 빠르게 만드는 것은 무엇일까요?
RAM은 서버가 얼마나 담을 수 있는지를 정하고, CPU는 얼마나 빨리 생각할 수 있는지를 정합니다. 단일 코어 속도가 가장 중요한 이유와, 코어가 많으면 도움이 되는 경우를 설명합니다.
읽는 시간 6분 · 2026년 10월 21일 업데이트 · 작성: GuavaHost Team
RAM은 서버가 얼마나 담을 수 있는지를 정하고, CPU는 얼마나 빨리 생각할 수 있는지를 정합니다. 사람들이 메모리 탓으로 돌리는 서버 랙은 사실 CPU 문제인 경우가 많으니, 이 문서에서 둘의 차이, 코어 개수보다 단일 코어 속도가 더 중요한 이유, 그리고 어느 쪽이 부족한지 알아보는 방법을 설명합니다.
서로 다른 두 가지 일
- RAM은 용량입니다. 월드, 플레이어, 모드를 담아 둡니다. 부족해지면 서버는 메모리를 비워 내는 동안 버벅이거나 그대로 죽습니다.
- CPU는 속도입니다. 실제 일을 합니다. 몹을 움직이고, AI를 돌리고, 물리 연산과 레드스톤, 제작대, 모든 플러그인을 처리합니다. 부족해지면 서버가 뒤처지고, 모두가 동시에 지연과 고무줄 현상으로 느낍니다.
CPU가 부족한 서버에 RAM을 더해도 아무 효과가 없고, 메모리가 바닥난 서버는 빠른 CPU로도 구할 수 없습니다. 둘 다 충분해야 하지만, 고장 나는 방식이 다릅니다.
틱 예산
게임 서버는 반복 루프로 돌아갑니다. 루프를 한 번 도는 것을 틱이라고 하고, 서버는 각 틱마다 월드의 모든 것을 갱신합니다. 게임은 초당 정해진 틱 수를 기대하므로, 틱마다 쓸 수 있는 시간 예산이 정해집니다.
| 게임 | 목표 속도 | 틱당 시간 |
|---|---|---|
| Minecraft Java | 초당 20틱 | 50 ms |
| Terraria | 초당 60회 갱신 | 약 16.7 ms |
| Counter-Strike 2 | 초당 64틱 | 약 15.6 ms |
틱이 예산보다 오래 걸리면 서버는 속도를 맞출 수 없습니다. Minecraft에서는 TPS(초당 틱 수)가 20 아래로 떨어지고 MSPT(틱당 밀리초)가 50을 넘어가는 모습으로 나타납니다. TPS와 MSPT 읽기 문서에 측정 방법이 나와 있습니다.
이 예산에 RAM은 어디에도 등장하지 않습니다. 매 틱을 제때 끝내는 것은 순전히 일이 얼마나 많은지와 CPU가 그것을 얼마나 빨리 처리하는지의 문제입니다.
단일 코어 속도가 가장 중요한 이유
대부분의 게임 서버는 핵심 시뮬레이션을 하나의 메인 스레드에서 처리합니다. 스레드는 CPU 코어 하나가 처리할 수 있는 한 줄의 작업 흐름이고, 게임 월드는 여러 스레드로 나누기가 어렵습니다. 각 단계가 그 앞 단계에 의존하기 때문입니다. 몹이 밟고 올라설 블록이 어디에 놓였는지 서버가 알기 전에는 몹이 움직일 수 없습니다.
Minecraft, Rust, ARK, Valheim, Project Zomboid, Terraria 모두 이런 방식으로 동작합니다. 그래서 코어 하나의 속도가 서버 전체의 한계를 정합니다. 느린 코어 16개를 가진 CPU가 빠른 코어 8개를 가진 CPU보다 Minecraft 월드를 더 못 돌릴 수 있는데, 월드는 주된 작업에 코어 하나만 쓸 수 있기 때문입니다.
단일 코어 속도는 두 가지에서 나옵니다.
- 클럭 속도, GHz로 표시되며 코어가 1초에 몇 사이클을 도는지를 뜻합니다.
- 사이클당 처리량, CPU 세대가 바뀔 때마다 개선됩니다. 같은 GHz라도 최신 CPU가 구형보다 눈에 띄게 빠른 경우가 많습니다.
큰 CPU 캐시(칩 자체에 있는 아주 빠른 소량의 메모리)도 도움이 됩니다. 게임 서버는 작은 데이터 조각들 사이를 끊임없이 오가기 때문입니다.
코어가 많으면 도움이 되는 경우
여분의 코어가 쓸모없는 것은 아닙니다. 메인 틱이 아닌 모든 일을 맡습니다.
- 배경 작업. 월드 저장, 청크 불러오기와 생성(Paper 같은 서버 소프트웨어는 이 일의 일부를 메인 스레드 밖으로 옮깁니다), 네트워크 데이터 압축, 그리고 배경에서 돌도록 작성된 플러그인 작업입니다.
- Java 가비지 컬렉션. Minecraft Java는 여러 스레드를 써서 쓰지 않는 메모리를 정리하므로, 남는 코어가 있으면 정리 시간이 짧아집니다.
- 프로세스가 둘 이상. Don't Starve Together 서버는 지상과 동굴을 두 개의 별도 프로세스로 돌리고, ARK 클러스터의 맵은 각각 자기 서버입니다. 각각 자기 코어를 쓸 수 있습니다.
- 업데이트와 백업. 게임 업데이트를 받거나 백업을 압축하는 일은 틱 안이 아니라 게임과 나란히 일어납니다.
ARK와 Palworld를 받치는 Unreal Engine을 포함한 일부 최신 엔진은 더 많은 작업을 여분의 스레드로 분산합니다. 그래도 메인 게임 스레드가 속도를 정합니다.
어느 쪽이 부족한가요?
| 보이는 현상 | 유력한 원인 |
|---|---|
| 메모리 그래프가 상한선에 붙어 있음 | RAM |
| 메모리 부족 오류, 또는 불러오는 중에 죽음 | RAM |
| 메모리는 여유로운데 TPS가 떨어지고 MSPT가 올라감 | CPU |
| 거대한 농장, 대형 기지, 생물이 많은 곳 근처에서만 랙 | CPU |
| 몇 시간에 걸쳐 랙이 쌓이고 재시작하면 해결됨 | 대개 메모리 누적, 때로는 엔티티 누적 |
| 한 명만 랙이 걸림 | 둘 다 아님. 그 사람의 핑입니다 |
알아 두면 좋은 사실이 하나 있습니다. GuavaHost 컨트롤 패널의 Usage (사용량) 카드(Overview 탭과 Console 탭에 있습니다)는 플랜 기준 CPU 사용량을 보여 줍니다. 플랜에 CPU 제한이 있으면 그 수치는 플랜의 전체 코어에 대한 비율이고 예를 들어 "of 2 cores"처럼 표시되므로, 100퍼센트는 코어 전부가 바쁘다는 뜻입니다. 게임의 메인 스레드는 코어 하나만 쓸 수 있으니, 2코어 플랜에서 랙이 걸리는데 50퍼센트 정도에 머무르는 서버는 여유가 남아 있어도 메인 스레드를 다 쓰고 있는 것일 수 있습니다. 플랜에 CPU 제한이 없으면 그 수치는 코어 하나에 대한 비율이므로, 랙이 걸리면서 100퍼센트 정도에 머무르는 서버도 같은 이야기입니다. 이것이 메인 스레드 병목의 전형적인 신호입니다.
CPU 병목 랙 해결하기
여기서는 RAM을 더해도 도움이 되지 않습니다. 도움이 되는 것은 메인 스레드가 틱마다 할 일을 줄이는 것입니다.
- 시뮬레이션 거리를 먼저, 그다음 시야 거리를 낮추세요. 시야 거리와 시뮬레이션 거리를 참고하세요.
- 몹 농장에 상한을 두고, 떨어진 아이템과 남는 엔티티를 치우세요.
- 월드를 미리 생성해, 사람들이 노는 동안 새 지형이 만들어지지 않게 하세요.
- 프로파일러로 무거운 플러그인이나 모드를 찾으세요. Minecraft에서는 무료 Spark 플러그인이 각 틱을 무엇이 잡아먹는지 정확히 짚어 줍니다.
- 쌓인 엔티티와 메모리를 비우도록 매일 재시작을 예약하세요.
랙 점검 목록이 이 과정을 순서대로 안내합니다.
GuavaHost에서는 어떻게 적용되나요
모든 GuavaHost 서버는 게임 서버가 의존하는 강한 단일 스레드 성능을 기준으로 고른 AMD Ryzen과 Intel 프로세서에서, NVMe SSD 저장소와 함께 돌아갑니다. 고르는 부분은 RAM이고, 게임과 인원에 맞춰 정하면 되며, 컨트롤 패널의 Manage plan (플랜 관리)으로 언제든 바꿀 수 있고 요금은 일할 계산됩니다. 메모리가 남는데도 서버가 버거우면 그것은 튜닝 작업이며, RAM 문서가 메모리를 더 사도 해결되지 않는 이유를 설명합니다.
아직 해결되지 않았나요? discord.gg/GuavaHost의 Discord에 들어오시면 팀이 도와드립니다.
- cpu
- ram
- performance
- single-thread
- cores
- tick rate
- lag
아직 해결되지 않았나요? 저희 팀이 24시간 대기하며 질문에 답해 드려요.