피드로 돌아가기
Dev.toBackend
원문 읽기
4계층 분리 설계를 통한 Minecraft 표준 UI i18n 경계 문제 해결
How I Designed a 4-Layer i18n Architecture for Minecraft's Standard UI in Spigot
AI 요약
Context
Spigot 플러그인 단독으로는 Minecraft 클라이언트 소유의 표준 UI 및 시스템 메시지 제어가 불가능한 제약 존재. 특히 서버-클라이언트 패킷 내 Translatable 컴포넌트와 클라이언트 사이드 언어 상태의 분리로 인해 단순 메시지 교체 방식의 한계 발생.
Technical Solution
- ProtocolLib Boundary Layer 도입을 통한 서버-클라이언트 패킷 가로채기 및 WrappedChatComponent 제어
- Pure Java Packet Localizer 분리로 Minecraft 런타임 의존성 제거 및 JUnit 기반 독립 테스트 환경 확보
- Server-side ResourcePack 활용을 통한 클라이언트 표준 번역 키(Translation Key) 오버라이드 구현
- Fabric Runtime Sync 계층을 통한 클라이언트 사이드 언어 상태 및 내장 리소스팩 동작 보완
- lang-map.yml 기반의 단일 진실 공급원(SSOT) 구축으로 프로젝트 언어 코드와 Minecraft 로케일 코드 매핑 일원화
- Boundary Adapter 패턴을 적용하여 런타임 종속적인 패킷 처리와 순수 비즈니스 로직(번역)을 엄격히 격리
실천 포인트
1. 제어 불가능한 외부 플랫폼 UI 요소가 있는지 식별
2. 런타임 의존성이 높은 경계 계층과 순수 로직 계층을 분리하여 테스트 가능성 검토
3. 다양한 데이터 소스(파일, 패킷, 외부 모드) 간의 매핑을 위한 SSOT 파일 존재 여부 확인
4. 플랫폼 제약을 우회하기 위한 보완 계층(ResourcePack, Mod 등)의 도입 가능성 분석