1P by GN⁺ | ★ favorite | 댓글 1개
  • Minecraft 26.3 Snapshot 4는 창 관리·입력·플랫폼 통합 백엔드를 GLFW에서 SDL3로 교체하고, 키보드 입력에 SDL 스캔코드와 키코드를 도입함
  • 키 바인딩은 자판 배열별 코드 대신 물리적 키 위치를 사용하며, Linux에서는 가능하면 Wayland를 우선하고 macOS에서는 네이티브 입력 후보 창을 지원함
  • 사용자 지정 화로·양조 연료용 데이터 컴포넌트가 추가돼 연소 시간, 사용 횟수, 조리·양조 속도를 number provider로 설정할 수 있음
  • 데이터 팩 111.0과 리소스 팩 92.0에서 표지판 클릭 이벤트, 전리품 테이블 참조, 발전 과제 트리거, 몹 생성 환경 속성, 지형 생성 설정과 셰이더가 대폭 바뀜
  • Windows 다중 모니터와 Wayland에서는 독점 전체 화면 충돌이 알려져 있으며, 테스트 버전이 월드를 손상시킬 수 있어 백업하거나 별도 폴더에서 실행해야 함

SDL3 기반 창·입력 시스템

  • 창 관리, 입력, 플랫폼 통합 라이브러리를 GLFW에서 SDL3로 전환
    • 키보드 입력은 물리적 키 위치에 SDL scancode를 사용함
    • 자판 배열에 따라 달라지는 텍스트 편집 단축키에는 SDL keycode를 적용함
  • 키 바인딩은 자판 배열별 키 코드가 아닌 물리적 키를 기준으로 동작함
  • Raw Input 마우스 설정을 제거하고, 게임 플레이 중에는 항상 상대 마우스 모드를 사용함
  • 테두리 없는 전체 화면이 기본 전체 화면 모드가 됐으며, 테두리 없음과 독점 모드 사이를 재시작 없이 전환할 수 있음
    • macOS에서는 독점 전체 화면을 더 이상 지원하지 않음
    • 최소 창 크기는 320×240픽셀
  • Linux에서는 사용할 수 있을 때 Wayland를 네이티브로 우선 사용
  • macOS에서 텍스트 입력 중 키를 길게 누르면 네이티브 악센트·후보 팝업이 표시됨

알려진 전체 화면 문제

  • Windows의 독점 전체 화면은 특정 상황, 특히 다중 모니터 환경에서 게임 충돌을 일으킬 수 있음
  • Wayland에서는 독점 전체 화면에 진입하면 게임이 충돌함

플레이와 인터페이스 변경

  • 관전자 모드 플레이어가 포털과 상호작용해 순간이동할 수 있음
  • 아르마딜로는 액체에 잠겼을 때 몸을 말려고 시도하지 않음
  • 디버그 오버레이에 별도 GUI 배율을 적용할 수 있음
    • F3 + F6의 Debug Options에서 설정함
    • 기본값 Auto는 일반 GUI보다 높은 해상도를 유지하고, Unchanged는 일반 GUI 배율과 일치함
    • 플레이어의 틱당 블록 이동 속도를 보여주는 player_speed와 디스플레이 주사율 표시도 추가됨
  • 크리에이티브 인벤토리의 광물 순서를 비티어 재료, 미정제 티어 재료, 정제 티어 재료 순으로 재배치함
    • 건축 블록은 비티어 광물, 정제 티어 광물, Copper 계열 순이며 항목이 많은 Copper 블록은 뒤쪽에 배치함
    • Natural Blocks 탭은 Overworld → Nether → End 순서로 정리됨

사용자 지정 연료와 아이템 컴포넌트

  • minecraft:cooking_fuel은 Furnace, Smoker, Blast Furnace용 연료를 정의함
    • burn_time은 연소 틱 수, speed_multiplier는 조리·제련 속도를 각각 minecraft:number_provider로 지정함
  • minecraft:brewing_fuel은 Brewing Stand 연료의 사용 횟수와 양조 속도를 정의함
    • 기존 #brewing_fuel 아이템 태그는 제거돼 새 양조 연료 등록에 사용할 수 없음
  • Smoker와 Blast Furnace 레시피는 Furnace와 같은 조리 시간을 사용하며, 속도 향상은 연료 컴포넌트의 minecraft:cooking/speed_default가 담당함
  • 화로·훈연기·용광로의 조리 및 연료 시간 필드는 short에서 integer로 바뀌고 speed_multiplier가 추가됨
  • Brewing Stand의 BrewTimeFuel도 integer로 바뀌며 total_brew_time, total_fuel, speed_multiplier가 추가됨
  • 추가된 데이터 컴포넌트는 다음과 같음
    • minecraft:sign_text_front, minecraft:sign_text_back: 표지판 앞·뒤 텍스트를 저장하고 아이템 툴팁에 표시함
    • minecraft:waxed: 내용물이 왁스 처리됐음을 나타내는 필드 없는 마커임
    • minecraft:cushion/color: 배치된 Cushion에 16가지 염료 색상을 적용함
    • minecraft:villager_food: 주민이 먹을 수 있는 아이템과 영양 수치를 정의함
    • minecraft:mob_visibility: 장비가 몹의 감지 거리에 미치는 비율을 0.0~10.0으로 지정하며, 중첩해도 최대 시야 값은 10.0을 넘지 않음

표지판과 데이터 팩 호환성

  • 데이터 팩 버전은 111.0으로 올라감
  • 표지판 사용자 지정 텍스트의 명령과 클릭 이벤트는 기본적으로 블록 클릭 시 실행되지 않으며, 새 표지판의 텍스트 컴포넌트도 자동 해석되지 않음
    • allow_op_features 필드의 기본값은 false이며, 이전 동작을 복원하려면 명시적으로 true로 설정해야 함
    • 이전 버전에서 저장된 표지판과 표지판 데이터를 담은 minecraft:block_entity_data에는 allow_op_features=true가 적용됨
  • 배치 후 표지판 편집 화면은 왁스 처리되지 않았고 앞면 텍스트를 편집할 수 있는 등, 일반 클릭으로 편집 화면을 열 수 있을 때만 표시됨
  • 표지판은 minecraft:sign_text_front, minecraft:sign_text_back, minecraft:waxed 컴포넌트를 주고받음
  • /spreadplayers가 플레이어를 배치할 수 있는 안전한 블록은 #entities_can_teleport_to 블록 태그로 제어함

레지스트리 참조와 전리품·발전 과제 변경

  • 전용 레지스트리가 있는 전리품 테이블 타입은 레지스트리 요소와 태그 참조를 지원함
    • 단일 요소 필드는 namespaced ID 또는 인라인 값을 받을 수 있음
    • 목록 필드는 인라인 값, 단일·복수 namespaced ID, 인라인 값 목록, # 태그 ID를 받을 수 있음
    • 대상은 advancement, item modifier, loot table, number provider, predicate, recipe, slot source임
  • predicate, item modifier, slot source의 기존 reference 타입은 불필요해져 제거됨
  • 발전 과제 트리거의 여러 필드는 인라인 predicate뿐 아니라 namespaced predicate ID도 받을 수 있음
    • 기존 조건 목록의 암시적 minecraft:all_of 동작이 제거돼 type을 반드시 지정해야 함
    • 여러 block, recipe_id, loot_table 필드는 각각 복수형으로 바뀌고 단일 ID, 목록 또는 태그를 지원함
  • Loot Pool Entry의 conditionscondition, functionsmodifier로 이름이 바뀜
  • Loot Function의 conditionscondition, 함수 타입을 나타내던 functiontype으로 변경됨
    • 인라인 조건 목록은 더 이상 받지 않으며, 같은 동작에는 minecraft:all_of를 명시해야 함
  • Predicate의 타입 필드 conditiontype으로 바뀌고 minecraft:referenceminecraft:block_state_property는 제거됨
    • minecraft:match_block은 블록 ID·태그, 상태, NBT, 컴포넌트와 컴포넌트 predicate를 함께 검사함
  • 인라인 number provider는 type을 항상 명시해야 하며, 더 이상 minecraft:uniform을 기본값으로 사용하지 않음
  • 조리 연료별 연소 시간과 기본 조리·양조 속도 및 양조 횟수를 제공하는 여러 Vanilla number provider가 추가됨

몹 생성과 월드 생성

  • 새 환경 속성 minecraft:gameplay/natural_mob_spawns가 카테고리별 가중치 기반 몹 생성과 엔티티별 spawn cost를 정의함
    • 월드 생성 배치 중에는 Dimension과 Biome만 이 속성을 적용함
    • overlay 수정자는 상위 계층의 카테고리 설정과 같은 엔티티의 spawn cost를 우선 적용함
  • minecraft:gameplay/creature_world_gen_spawn_probability는 월드 생성 중 creature 카테고리 몹 생성 반복 확률을 0 이상 1 미만으로 지정하며 기본값은 0.1임
  • Biome의 spawners, spawn_costs, creature_spawn_probability는 제거되고 새 환경 속성으로 이동함
  • 주변 입자 환경 속성은 타임라인 키프레임 사이의 확률을 보간하며, 하위 계층 입자 목록에 항목을 이어 붙이는 append 수정자를 지원함
  • Noise Settings에서 aquifer와 ore vein 설정을 각각 선택적 aquifers 객체와 ore_veins 목록으로 재구성함
    • 설정이 없으면 해당 aquifer 또는 ore vein을 생성하지 않음
    • 관련 density function 필드는 noise_router에서 새 구조로 이동함
  • Density Function에 sub, div, negate, lerp, floor, round, ceil, truncate, beardifier가 추가됨
    • 여러 기존 인수 이름은 value, left, right, input, noise로 변경됨
    • invertreciprocal로 이름이 바뀜
    • final_density에는 더 이상 beardifier가 암시적으로 더해지지 않음

그래픽과 주요 버그 수정

  • 리소스 팩 버전은 92.0으로 올라감
  • 순서 독립 투명도(order-independent transparency)를 지원하는 셰이더와 OIT_ALWAYS_WRITE_DEPTH 정의가 추가됨
  • core/integrate_depth.fsh는 3D HUD와 항상 위에 표시되는 gizmo의 깊이 버퍼를 메인 깊이 버퍼에 통합함
  • 수정된 주요 문제는 다음과 같음
    • 비 QWERTY 자판과 macOS·CJK 입력 관련 키 바인딩 및 입력 문제
    • Improved Transparency에서 지도 렌더링 충돌, 유리·반투명 객체·파티클·월드 경계 표시 문제
    • 월드 높이 밖 발사체와 최저 높이의 벌집 배치로 발생하던 충돌
    • 월드 생성 heightmap 저장·불러오기 문제와 tick sprint 이후 몹 위치 비동기화
    • Cushion 배치, 색상, 사용자 지정 이름, 연료 시간과 충돌 판정 문제
    • Ender Dragon 피해·비행, 관전자의 포털 사용, /spreadplayers 안전 블록 판정 문제

설치와 테스트 주의사항

  • Snapshot은 Minecraft: Java Edition용이며 Minecraft LauncherInstallations 탭에서 Snapshot을 활성화해 설치함
  • 테스트 버전은 월드를 손상시킬 수 있으므로 백업하거나 기본 월드와 다른 폴더에서 실행해야 함
  • 크로스 플랫폼용 Minecraft server jar도 제공됨
  • 버그는 Minecraft issue tracker, 의견은 Feedback 사이트에서 제출할 수 있음

댓글과 토론

Hacker News 의견들
  • 이 바인딩의 LWJGL 구현은 GTNH 모드팩 팀원이 작성해 vanilla→modded→vanilla의 순환을 다시 완성했음 https://github.com/LWJGL/lwjgl3/pull/1033

    • 과장하자면 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판보다 버그가 적고 낫다고 봄
      성능이 더 필요하면 fabriclithium을 설치하면 됨. Paper·Spigot·Purpur 같은 모드는 자동화 시설을 망가뜨릴 수 있어 피하는 편이 좋음
    • 휴대전화와 태블릿의 Minecraft는 Java판보다 폐쇄적이고 제한적이라 선택지가 줄어듦
      itzg/docker-minecraft-server를 수년간 안정적으로 사용했으며, 의존성을 일일이 설치하지 않아도 이미지가 모두 처리해 주는 점이 좋았음. Bedrock 서버 이미지도 있지만 제대로 작동시키지는 못했음
      가장 수월하게 운영하려면 모두 Windows·Mac·Linux에서 Java판을 써야 하며, 아니면 호스팅 서버인 Realms를 결제하는 방법이 있음
    • 아이들이 iPad로 플레이하려는 선호를 고려하면 Realms도 살펴볼 만함. 약 7달러에 10명 서버를 제공하는 것으로 알고 있지만 Java와 Bedrock 구독이 나뉘고 요금제도 여러 단계로 파편화돼 있음
      가족 서버의 목적에 따라 맞지 않을 수도 있지만 아이들이 빠르고 간단하게 함께 플레이하기에는 가장 쉬운 방법임. 오랫동안 Bedrock만 고집하다 Java로 옮긴 뒤 더 빨리 바꾸지 않은 것을 후회한 아이들도 봤음
  • Icculus가 SDL2에서 SDL3로 게임을 이식하는 훌륭한 영상을 올렸으며, Doom 이식 영상은 여기 있음: https://www.youtube.com/watch?v=ixdeGhsoxy8

    • Chocolate Doom이 SDL3로 이식되는 데다 Icculus가 직접 작업하는 줄은 몰랐음. 알고 있는 Doom 이식판 중에는 Woof! 가 이미 전환함: https://github.com/fabiangreffrath/woof
  • Minecraft가 단순한 게임보다 점점 독자적인 게임 엔진에 가까워지는 모습이 놀라움

  • 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 주입은 장애물이 되지 않음