마인크래프트 서버 직접 만들기 3탄 - 서버 렉 줄이는 설정
작성일 2026-07-25 · SameOS Tools
서버를 열고 친구들이 들어오기 시작하면 다음 고민은 반드시 렉입니다. 그런데 렉이라는 말 안에 사실 세 가지 다른 문제가 섞여 있습니다 - 서버가 세상을 굴리는 계산이 밀리는 것(몹이 순간이동하듯 움직임, 문이 늦게 열림), 인터넷이 느린 것(핑이 높음), 그리고 내 컴퓨터 그래픽이 힘든 것(프레임 저하)입니다. 앞의 것만 서버 설정으로 고칠 수 있고, 이 글은 그 이야기입니다. 순서는 효과가 큰 것부터입니다.
1순위 - 시야 거리가 아니라 시뮬레이션 거리부터
설정 파일에 비슷해 보이는 값이 두 개 있습니다. view-distance는 플레이어에게 얼마나 멀리까지 보여줄지(전송량), simulation-distance는 얼마나 멀리까지 세상을 실제로 굴릴지(계산량)입니다. 몹이 움직이고 작물이 자라고 기계가 도는 건 전부 시뮬레이션 거리 안에서만 일어나는데, 서버를 무겁게 하는 건 바로 이 계산입니다. 그래서 렉이 오면 view보다 simulation을 먼저 줄이는 게 맞습니다 - 보이는 풍경은 그대로인데 서버 부담만 줄어듭니다. 제 서버는 둘 다 기본값 10으로 두고 있지만, 접속 인원이 늘어 버거워지면 simulation부터 8로 내릴 계획으로 운영합니다. 값 1을 줄일 때마다 계산할 청크(세상을 나누는 16×16 블록 단위)가 제곱으로 줄어서 효과가 큽니다.
# server.properties — 렉 관련 핵심 두 줄
view-distance=10 # 보여주는 거리 - 줄이면 전송량 감소 (풍경이 짧아짐)
simulation-distance=10 # 세상을 굴리는 거리 - 줄이면 계산량 감소 (풍경 그대로)
# 렉이 올 때 줄이는 순서:
# simulation-distance 10 → 8 (체감 거의 없음, 효과 큼)
# 그래도 무거우면 view-distance 10 → 8
# 바꾼 뒤 서버 재시작해야 적용됩니다2순위 - 메모리는 많이 줄수록 좋은 게 아닙니다
직관과 반대라 처음에 다들 틀리는 부분입니다. 자바는 쓰고 버린 메모리를 주기적으로 청소(가비지 컬렉션)하는데, 이 청소 순간에는 서버가 아주 잠깐 멈춥니다. 메모리를 크게 줄수록 청소 한 번에 치울 양도 커져서, 램 32GB를 주면 쾌적해지는 게 아니라 몇 초씩 멈칫거리는 서버가 될 수 있습니다. 소규모 서버는 4~6GB면 충분하고, 모드가 많으면 8GB까지가 현실적인 선입니다. 제 서버는 시작 2GB, 최대 6GB로 두고 10인 규모까지 문제없이 돌고 있습니다.
# 서버 실행 명령의 메모리 옵션
java -Xms2G -Xmx6G -jar fabric-server-launch.jar nogui
# -Xms2G 시작할 때 확보하는 메모리
# -Xmx6G 최대 한도 - 소규모 4~6G, 모드 서버 6~8G면 충분
# 32G처럼 무작정 크게 주면 청소(GC) 멈춤이 길어져 역효과
# 서버 컴퓨터에 램이 16G라면 서버에 다 주지 말 것 -
# 운영체제와 다른 프로그램 몫을 남겨야 전체가 안 밀립니다그래서 몇 명까지 받을 수 있나 - 추천 인원표
메모리 이야기가 나온 김에, 제일 많이 받는 질문에 답해 둡니다. 아래는 경험칙 기준의 보수적인 출발점입니다 - 같은 램이어도 CPU 성능과 월드 크기, 위에서 다룬 거리 설정에 따라 달라지므로, 이 인원으로 시작해서 서버가 여유 있으면 늘리는 방향이 안전합니다. 순정과 모드 서버의 차이가 생각보다 큰데, 무거운 모드팩은 기계·배관·마법 계산이 플레이어마다 따라붙어서 같은 램으로 받을 수 있는 인원이 절반 이하로 줄어듭니다.
# 메모리 기준 권장 동시 접속 인원 (보수적 출발점)
[순정(바닐라)·가벼운 모드 몇 개]
2GB → 2~4명
4GB → 5~10명
6GB → 10~20명 # 제 서버: 6GB 상한에 max-players=10 (여유 운영)
8GB → 20~30명
[무거운 모드팩 (기술·마법 대형 모드 수십 개)]
4GB → 2~4명
6GB → 4~6명
8GB → 6~10명
# 이 이상 욕심내면 램보다 CPU 한 코어 성능이 먼저 한계에 옵니다
# 표보다 중요한 것: simulation-distance를 8로 줄이면
# 같은 램으로 위 표보다 더 받을 수 있습니다. 표는 출발점일 뿐,
# 서버가 밀리기 시작하는 인원이 그 서버의 진짜 정원입니다.3순위 - 서버에만 넣어도 되는 최적화 모드
2탄에서 "서버 전용 모드는 접속자가 안 깔아도 된다"고 했는데, 최적화 모드가 바로 그 대표입니다. Fabric 서버라면 Lithium(게임 내부 계산을 더 효율적으로 다시 짠 모드)과 FerriteCore(메모리 사용을 줄이는 모드)가 가장 널리 쓰입니다. 둘 다 게임 규칙을 바꾸지 않고 계산 방식만 바꾸는 것이라 서버에만 넣으면 되고, 친구들은 아무것도 설치할 필요가 없습니다. 모드 파일은 반드시 서버의 게임 버전과 같은 버전으로 받으세요.
# Fabric 서버 기준 - mods 폴더에 넣고 재시작하면 끝
# (Modrinth에서 게임 버전에 맞는 파일로 받기: modrinth.com)
cd ~/minecraft/mods
# Lithium - 게임 계산 최적화 (몹 AI, 물리 등) / 게임 규칙 변화 없음
# FerriteCore - 메모리 사용량 감소
# 받은 예: lithium-fabric-0.x.x+mc26.1.2.jar
# ferritecore-x.x.x-fabric.jar
ls # 두 파일이 fabric-api 옆에 있으면 준비 완료
docker compose restart # (1탄 방식이면: sudo systemctl restart minecraft)그 외에 진짜 효과 있는 것들
설정 바깥에도 몇 가지가 있습니다. 첫째, 월드는 반드시 SSD에 두세요 - 마인크래프트는 세상을 잘게 쪼갠 파일을 쉴 새 없이 읽고 쓰기 때문에, 하드디스크(HDD)에서는 설정을 아무리 만져도 한계가 있습니다. 둘째, 자바를 최신으로 유지하세요 - 1탄에서 버전 함정으로 다뤘지만, 새 자바일수록 청소(GC) 성능 자체가 좋아집니다. 셋째, 자동 백업은 사람이 없는 새벽 시간에 거세요 - 2탄의 백업 스크립트가 도는 몇 초는 서버가 저장에 집중하느라 순간적으로 밀릴 수 있습니다. 넷째, max-players는 실제 올 인원에 맞추세요 - 여유 슬롯 자체는 부담이 아니지만, 인원이 곧 시뮬레이션 부하이므로 감당 가능한 수를 아는 게 운영의 시작입니다.
마무리
정리하면 순서는 이렇습니다 - 시뮬레이션 거리부터, 메모리는 적당히, 최적화 모드는 서버에만, 월드는 SSD에. 이 네 가지로 소규모 서버 렉의 대부분은 잡힙니다. 다음 글은 방향을 바꿔서 서버를 지키는 이야기입니다 - 서버를 열자마자 전 세계 봇들이 마인크래프트 포트를 두드리러 온다는 걸, 제 서버 방화벽 기록으로 직접 보여드리겠습니다.