과장하자면 GTNH가 Microsoft보다 Minecraft에 더 많이 기여했다고 볼 수 있음. 직접 조금 기여해서 하는 말만은 아니며, 투입된 정성과 작업량이 놀라운 수준임

현재 Minecraft 개발자 중 과거에 모더였던 사람과 지금도 모더로 활동하는 사람은 얼마나 될지 궁금함

최근 게임 Tribal Trouble(https://github.com/bondolo/tribaltrouble)을 GLFW에서 SDL3로 전환했는데, 대체로 수월한 리팩터링이었음. 독점 전체 화면과 데스크톱 전체 화면에서 몇 가지 문제가 있었지만 결국 해결함
까다로운 화면 모드 처리를 시험하고 문서화하려고 데모도 작성했음. 게임은 Minecraft처럼 Java지만 데모는 최대한 단순하게 만들려고 C를 사용함

Tribal Trouble이라니 정말 오랜만에 듣는 이름임. 개발자들이 게임 개발에 이상하거나 흔치 않은 언어를 쓰고 싶어서 Java를 선택했다고 했던 게 기억남

GLFW에 문제가 있었는지, 어떤 이유로 SDL3 전환을 선택했는지 궁금함

Windows의 독점 전체 화면은 특히 다중 모니터에서 게임을 중단시킬 수 있고, Wayland에서는 진입만 해도 중단된다는 알려진 문제가 있음. 둘 다 보통 스냅샷을 연기할 만한 차단 버그처럼 보여 정식 출시 전에는 고쳐지길 바람

스냅샷은 차단 버그까지 포함한 현재 메인 브랜치의 상태를 그대로 배포하는 것임
안정성 기대 수준은 장기 지원판, 정식판, 출시 후보, 베타, 알파, 스냅샷, 방금 병합된 커밋, 미병합 PR, 초안 PR 등의 순서라고 봄. 큰 버그라면 출시 후보나 베타를 미루고, 치명적 버그라면 병합 자체를 막아야 하지만 CI를 통과해 병합된 버그 때문에 스냅샷을 미룰 이유는 없음
스냅샷은 사용자가 직접 메인을 빌드하지 않고도 실행하고 피드백할 수 있게 현재 상태를 정기적으로 잘라 배포하는 것에 가까움

정식 출시라면 미룰 수 있지만 스냅샷을 연기할 이유는 없음. 현 상태로 배포해야 알려진 문제가 얼마나 자주 발생하는지 원격 측정으로 파악하고, 아직 모르는 문제도 정식 출시 전에 발견할 수 있음
스냅샷이 버그가 없다고 약속한 적은 없으며 오히려 그 반대가 전제임

Minecraft는 별도로 설정하지 않는 한 오래전부터 테두리 없는 전체 화면을 사용했을 것임. 지난 10여 년 동안 여러 플랫폼과 서비스, 앱이 독점 전체 화면을 폐기해 왔음

요즘은 독점 전체 화면보다 전체 화면 창 렌더링이 일반적임. 창 관리자가 맨 앞의 전체 화면 창에도 과거 독점 모드에만 적용하던 것과 같은 최적화를 보통 적용함

스냅샷이니 생길 수 있는 문제이며 다음 스냅샷에서 고쳐질 가능성이 큼

Minecraft를 전혀 모르는 기술자 아빠가 2026년에 가족용 서버를 구축하려면 어떻게 해야 할지 궁금함. 아이들은 현재 iPad와 가끔 오래된 MacBook·Windows PC로 플레이함

Minecraft에는 Java와 Bedrock 두 판이 있음. 모바일·콘솔·Windows Store판은 Bedrock 기반이고, 웹사이트에서 직접 받는 것은 Java판임
표준 Java 서버를 운영하면서 Geyser로 Bedrock 프로토콜을 실시간 변환할 수 있음. 제한이 심한 Bedrock 클라이언트에는 우회 방법이 필요할 수 있지만, 선택지가 더 많은 Java 서버를 중심으로 관리할 수 있음

온라인의 Minecraft JVM 튜닝 지침은 오래됐거나 잘못된 경우가 많으니 무시하는 편이 좋음
최신 JVM을 쓰고 허용 가능한 만큼 최대 메모리를 높인 뒤 ZGC를 사용하면 충분함. 여러 플래그를 근거 없이 조정하거나 에덴 영역 크기와 목표 일시 정지 시간처럼 상충하는 설정을 함께 넣는 지침도 있음
ZGC는 지연 시간이 매우 낮고 힙이 클수록 성능 저하가 줄지만, 객체 헤더 압축을 유지하려면 32GB 미만으로 두는 편이 좋음. 최신 JVM은 메모리 사용량과 전반적인 성능도 개선해 줌

Java판 바닐라 서버 설정법을 따르면 됨. Java판은 Windows·macOS·Linux에서만 실행되지만 Bedrock판보다 버그가 적고 낫다고 봄
성능이 더 필요하면 fabric과 lithium을 설치하면 됨. Paper·Spigot·Purpur 같은 모드는 자동화 시설을 망가뜨릴 수 있어 피하는 편이 좋음

휴대전화와 태블릿의 Minecraft는 Java판보다 폐쇄적이고 제한적이라 선택지가 줄어듦 itzg/docker-minecraft-server를 수년간 안정적으로 사용했으며, 의존성을 일일이 설치하지 않아도 이미지가 모두 처리해 주는 점이 좋았음. Bedrock 서버 이미지도 있지만 제대로 작동시키지는 못했음
가장 수월하게 운영하려면 모두 Windows·Mac·Linux에서 Java판을 써야 하며, 아니면 호스팅 서버인 Realms를 결제하는 방법이 있음

아이들이 iPad로 플레이하려는 선호를 고려하면 Realms도 살펴볼 만함. 약 7달러에 10명 서버를 제공하는 것으로 알고 있지만 Java와 Bedrock 구독이 나뉘고 요금제도 여러 단계로 파편화돼 있음
가족 서버의 목적에 따라 맞지 않을 수도 있지만 아이들이 빠르고 간단하게 함께 플레이하기에는 가장 쉬운 방법임. 오랫동안 Bedrock만 고집하다 Java로 옮긴 뒤 더 빨리 바꾸지 않은 것을 후회한 아이들도 봤음

GLFW를 떠난 이유가 문서화돼 있는지 궁금함. GLFW를 사용하는 프로젝트가 있어 SDL이 더 나은 선택인지 늘 고민하게 됨

이번 업데이트에서 Wayland 지원이 별도 작업 없이 동작하게 됐음. 이전에는 우회 방법이 필요했고, 적용해도 새로운 문제가 계속 생겼지만 대부분 XWayland로 실행하는 데 만족해 크게 신경 쓰지 않았음
SDL3는 Wayland 지원이 기본적으로 탄탄함. Minecraft에서 GLFW는 창 생성, 작업 표시줄 아이콘, 전체 화면, 입력에만 쓰고 나머지는 원시 OpenGL로 처리하므로 전환도 쉬웠음. 이제 Vulkan까지 지원해 Linux 데스크톱과 Steam Deck에서 완전히 현대적인 스택을 사용할 수 있음

SDL은 모바일을 지원하지만 GLFW는 그렇지 않으므로 플랫폼별 코드베이스를 통합하려는 것일 수 있음 SDL3는 Android 4.2에서도 작동하며, Java 없이 SDL3와 ImGui로 앱을 만든 적도 있음

이유 중 하나는 입력기(IME) 지원임

SDL은 거의 어디서나 쓸 수 있는 플랫폼 계층에 가까움. 창, 그래픽, 오디오, 입력, 네트워크, 스레드를 모두 제공하지만 GLFW는 창, 그래픽 문맥, 입력만 제공하므로 나머지 라이브러리를 직접 준비해야 함
모든 프로젝트에 큰 차이는 아닐 수 있지만 SDL이 더 많은 기능을 제공하고 이식성도 더 높음

OpenGL이나 Vulkan 없이도 SDL API만으로 완전한 2D 게임을 만들 수 있음

리듬 게임 osu! 도 최근 SDL2에서 SDL3로 전환해 성능과 지연 시간이 크게 개선됐음. SDL3 도입은 다소 느려 보이며, Minecraft가 지금까지 GLFW를 썼다는 점도 의외임
특히 SDL3 전환 후 osu! 실행 중 Discord 클라이언트를 열어 뒀을 때 생기던 지연이 사라졌으며, YouTube 개발 영상에서 본 내용으로 기억함

Linux 일부 배포판에서는 sdl2-compat와 sdl12-compat가 SDL2·1.2의 기본 구현이라 이미 SDL3를 간접 사용하는 경우가 많음. 덕분에 더 많은 앱이 XWayland보다 지연 시간이 낮은 Wayland에서 네이티브로 작동하고 컨트롤러 지원도 좋아짐
Ubuntu 24.04에는 처음부터 SDL3가 포함되지 않았는데, SDL3가 생각보다 최신이어서 도입 속도가 기대보다 낮은 이유 중 하나로 보임

osu!는 주요 데스크톱 운영체제 3종과 iOS·Android를 모두 지원하고, Wayland 같은 기능도 네이티브로 유지하려다 SDL3 전환에 약 2년이 걸렸음. 이번 전환은 처음으로 실제 최종 단계에 도달한 듯함

SDL3에서 여러 API가 바뀌어 도입이 더 어려우며, 특히 바인딩 라이브러리를 통하면 부담이 커짐

SDL2는 특히 Vulkan·Metal을 포함한 GPU API 추상화에서 노후화가 드러났으므로 SDL3 전환은 타당함. Java판 Linux에서 오래 지속된 입력 지연과 Alt+Tab 문제도 창·입력 계층 변경으로 해결될지 궁금함

실제 전환 대상은 SDL2가 아니라 GLFW였으므로 새로 선택한다면 자연스럽게 SDL3를 고르게 됨

모드를 활발히 지원하려면 Java나 C#처럼 역컴파일과 런타임 수정이 쉬운 언어, 또는 JVM과 .NET CLR을 쓰는 편이 좋아 보임
내부 변경을 하면서 모더까지 고려하면 사실상 추가 비용 없이 훌륭한 모딩 API를 얻을 수 있음

모드가 매우 많은 게임에 정말 필요한 것은 충분히 큰 사용자 기반뿐임. 전념하는 모더에게 약간의 바이너리 패치나 DLL 주입은 장애물이 되지 않음