Minecraft 모드를 여러 버전에 걸쳐 백포팅하기 — 그리고 주민들을 이용한 클라우드 경제 구축하기
요약
Minecraft 모드를 최신 버전에서 이전 버전으로 백포팅하며 겪은 리팩토링 및 API 마이그레이션 과정을 다룹니다. 상표권 문제를 피하기 위한 리브랜딩과 API 변경에 따른 기술적 대응 방안을 설명합니다.
핵심 포인트
- API 마이그레이션은 단순한 치환이 아닌 연쇄적인 코드 수정이 필요함
- 상표권 문제를 방지하기 위한 전략적 리브랜딩의 중요성
- 클라우드 개념(S3, EC2 등)을 게임 내 경제 시스템으로 구현
- 버전 간 API 차이(Identifier, DataComponentTypes 등) 대응 방법
우리에게는 문제가 하나 있었습니다. 모드 이름은 "AWS Swords"였고, Minecraft 1.21.1용으로 제작되었으며, 단독으로는 아주 잘 작동했습니다. 하지만 아무도 Minecraft를 단독으로 플레이하지는 않습니다. 가장 큰 모드팩들 — Prominence II, All The Mods, Create 기반 팩들 —은 모두 1.20.1 버전을 사용하고 있습니다. 그리고 이름에 "AWS"를 사용하는 것은 상표권 문제를 일으켰습니다.
그래서 우리는 유능한 클라우드 아키텍트(Cloud Architect)라면 누구나 하는 일을 했습니다. 바로 리팩토링(Refactoring), 리브랜딩(Rebranding), 그리고 마이그레이션(Migration)입니다. Cloud Swords Mod에 오신 것을 환영합니다 — 이제 1.20.1에서 실행되며, 650개 이상의 모드와 호환되고, 주민 기반의 완전한 클라우드 경제 시스템을 특징으로 합니다.
🎮 학습 관점: 모드를 백포팅(Backporting)하는 것은 클라우드 제공업체의 API 버전 간에 마이그레이션하는 것과 같습니다. 개념은 동일하지만, 모든 메서드 시그니처(Method Signature)가 약간씩 다릅니다. 그리고 주민 경제를 구축하는 것은 서비스 카탈로그(Service Catalogs), 계층형 가격 책정(Tiered Pricing), 그리고 진행 시스템(Progression Systems)에 대해 가르쳐 주는데, 이 모든 것은 실제 클라우드 플랫폼의 개념들입니다.
리브랜딩: AWS Swords → Cloud Swords
먼저, 쉬운 부분부터 시작합니다. 우리는 모든 것을 변경했습니다:
awsswords→cloudswords- "AWS Swords" → "Cloud Swords Mod"
- 서비스별 명칭(Lambda, S3, EC2)은 유지하되, 브랜딩이 아닌 게임 내 설정(Lore)으로 사용
왜일까요? CurseForge/Modrinth에 게시하고 싶은데, 모드 이름에 기업의 상표를 사용하는 것은 위험하기 때문입니다. 이 검들은 클라우드 서비스에서 영감을 받은 것이지, 공식 AWS 제품이라고 주장하는 것이 아닙니다.
백포팅: 1.21.1 → 1.20.1
이 부분이 기술적인 영역입니다. 플레이어의 관점에서 Minecraft 1.21.1과 1.20.1은 비슷해 보이지만, 모딩 API(Modding API)는 크게 변경되었습니다. 우리가 직면했던 모든 차이점은 다음과 같습니다:
| 1.21.1 | 1.20.1 | 영향 (Impact) |
|---|---|---|
Identifier.of("ns", "path") | new Identifier("ns", "path") | 모든 식별자 (Every single identifier) |
| ... |
교훈은 무엇일까요? API 마이그레이션(API migrations)은 결코 "단순한 찾기 및 바꾸기"가 아닙니다. 모든 변경 사항은 연쇄적인 효과를 불러옵니다. DataComponentTypes 변경 하나만으로도 S3 검이 아이템을 저장하는 방식을 새로운 컴포넌트 시스템(component system)에서 다시 원시 NBT 컴파운드(raw NBT compounds)로 재작성해야 했습니다.
// 1.21.1 — 새로운 컴포넌트 시스템 (new component system)
stack.getOrDefault(DataComponentTypes.CUSTOM_DATA, NbtComponent.DEFAULT)
.copyNbt().getList("stored_items", NbtElement.COMPOUND_TYPE);
...
개념은 같지만, API는 완전히 다릅니다. 익숙한 느낌인가요? 마치 AWS SDK v2에서 v3로 마이그레이션하는 것과 같습니다.
7가지 클라우드 주민 직업 (Cloud Villager Professions)
가장 큰 새로운 기능은 주민(villagers)에 의해 구동되는 완전한 경제 시스템입니다. 각 직업은 클라우드 역할을 나타냅니다:
| 직업 (Profession) | 작업대 (Workstation) | 전문 분야 (Specialty) |
|---|---|---|
| 소프트웨어 개발자 (Software Developer) | 클라우드 배포자 (Cloud Deployer) | 검 코어 (Sword cores), Lambda 칩 (Lambda chips) |
| ... |
각 직업은 5단계의 거래 레벨(초보 → 숙련)을 가지며, 숙련(Master) 레벨의 거래에서는 프리미엄 아이템을 잠금 해제하는 커스텀 통화인 **클라우드 크레딧 (Cloud Credits)**을 받습니다.
숙련 레벨 전용 아이템 (Master-Level Exclusive Items)
이 아이템들은 오직 클라우드 크레딧을 사용하여 숙련 주민으로부터만 얻을 수 있는 아이템입니다:
| 아이템 (Item) | 효과 (Effect) | 클라우드 개념 (Cloud Concept) |
|---|---|---|
| 서버리스 함수 (Serverless Function) | 마지막 사망 위치로 텔레포트 | Lambda — 온디맨드(on demand) 실행 |
| ... |
여기에 바닐라(vanilla) 희귀 아이템(토템, 겉날개, 네더의 별)도 클라우드 크레딧으로 구매할 수 있습니다. 클라우드에서는 돈이 문제를 해결하기 때문입니다.
클라우드 사무실 — 마을 구조 (Cloud Office — Village Structure)
우리는 바닐라 마을에 커스텀 구조물인 **클라우드 사무실 (Cloud Office)**을 주입했습니다. 이는 다음과 같은 특징을 가진 7x7x7 건물입니다:
- 3개의 작업대 (보안 터미널, AI 워크벤치, 서버 랙)
- 시각적 구분을 위한 구리 장식
- 마을의 약 50%에서 생성
기술적으로, 이는 Fabric의 ServerLifecycleEvents.SERVER_STARTING을 사용하여 월드 생성(world generation) 전에 마을 구조 풀(structure pool)에 직소(jigsaw) 요소를 주입합니다. 액세스 와이더(access widener)를 통해 StructurePool.elements 필드를 노출합니다.
차원 간 광석 생성 (Ore Generation Across Dimensions)
| 광석 | 차원 | Y 범위 | 맥 크기 (Vein Size) | 청크당 생성량 |
|---|---|---|---|---|
| Cloud Ore | 오버월드 (Overworld) | 0-64 | 6 | 4 |
| ... | ... | ... | ... | ... |
이 진행 과정은 클라우드 지역을 반영합니다: 로컬(오버월드)에서 시작하여, 보조 지역(네더, Nether)으로 확장하고, 최종적으로 글로벌(엔드, End)로 나아갑니다.
Prominence II 호환성 — 650개 이상의 모드
최종 테스트: 650개의 모드가 포함된 모드팩에서도 작동할까요? 네.
- 아이템/블록 ID 충돌 없음
- 에너지 시스템이 Create, Tech Reborn, Mekanism과 공존
- 주민 직업이 VillagersPlus와 함께 작동
- 광석 생성(Ore generation)이 Regions Unexplored 바이옴과 작동
- EMI에서 모든 레시피를 정확하게 표시
- 모든 구조물 유형에서 전리품 주입(Loot injection)이 작동
핵심은 Fabric의 레지스트리 시스템(registry system)을 올바르게 사용하고, 어떤 것도 하드코딩(hardcoding)하지 않은 것이었습니다. 네임스페이스 식별자(Namespaced identifiers), 적절한 태그(tags), 그리고 선택적 의존성(optional dependencies)을 활용했습니다.
배운 점 (Lessons Learned)
| 도전 과제 | 해결책 |
|---|---|
| 버전 간 API 차이 | 모든 변경 사항을 문서화하고 체계적으로 마이그레이션 |
| ... | ... |
다음 단계 (What's Next)
기반은 탄탄합니다: 7개의 검, 기계, 주민, 경제, 광석, 그리고 완전한 모드팩 호환성까지 갖추었습니다. 하지만 이제 시작일 뿐입니다. 다음 포스트에서는 **완전한 마법 시스템 (complete magic system)**을 추가할 예정입니다. 클라우드 운영을 테마로 한 9개의 주문서와 28개의 주문이 포함됩니다. 클라우드에서는 자동화가 곧 마법이기 때문입니다.
전체 소스 코드는 GitHub에서 확인하세요.
저와 연결하기:
저는 Carlos Cortez입니다. 이것은 _Breaking the Cloud_이며, 오늘은 새로운 지역으로 마이그레이션했습니다. 다음 포스트에서 만나요! 🌍
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기