Go로 네이티브 GUI 앱을 만드는 새로운 방법, Shirei

Shirei는 Windows에서는 DLL을 직접 로드하고, Linux에서는 X11 및 Wayland 프로토콜을 Go로 직접 구현하여 네이티브 API 접근을 최소화했습니다. macOS의 경우 Cocoa 라이브러리 접근을 위해 cgo를 사용하는 절충안을 택했습니다. 이러한 백엔드 분리(Backend Decoupling) 전략은 배포 및 크로스 컴파일 용이성을 높이지만, macOS 빌드 시에는 해당 환경이 필요하다는 점이 언급되었습니다.

개발자들은 Shirei의 Immediate Mode API 채택에 대해 회의적인 반응을 보입니다. React의 성공 요인을 데이터 기반 UI 설명으로 해석했으나, 커뮤니티에서는 이를 단방향 데이터 흐름(Unidirectional Data Flow)과 혼동하며, 복잡한 UI에서는 Retained Mode가 더 확장성이 높다는 의견이 제기되었습니다. 또한, UI 렌더링 시 데이터 동기화(Data Synchronization) 없이 상태를 관리하는 방식이 진정한 Immediate Mode인지에 대한 논쟁도 있었습니다.

Shirei는 AI 에이전트(AI Agents)가 쉽게 사용할 수 있는 API를 목표로 합니다. 실제로 커밋 기록에 Claude, Codex, Cursor 등 AI 도구가 공동 작업자로 명시되어 있어, AI를 활용한 코드 생성 및 프레임워크 개발 가능성을 시사합니다. 하지만 이러한 대규모 커밋(Massive Commits)은 인간 개발자가 히스토리를 따라가기 어렵게 만들어, 프로젝트 추적성을 저해한다는 비판도 존재합니다.

커뮤니티에서는 SwiftUI, Fyne, Wails 등 기존 Go GUI 프레임워크와의 비교를 통해 Shirei의 경쟁력을 질문합니다. 특히 SwiftUI와 같은 프레임워크는 macOS 네이티브 경험을 제공하며 Go와의 연동도 가능하다는 점에서, Shirei가 제공하는 UX 절충(UX Trade-off)의 가치가 무엇인지 의문을 제기합니다. 또한, 게임 엔진(Game Engine) 기반의 GPU 가속 렌더링 방식과의 차이점 및 Raspberry Pi와 같은 저사양 환경에서의 활용 가능성도 논의되었습니다.

프로젝트가 LRU 캐시(LRU Cache)와 같은 비교적 단순한 라이브러리를 외부 의존성으로 포함하고 있다는 점이 지적되었습니다. 이는 AI가 코드 생성 시에도 여전히 기존 라이브러리를 활용하며, 모든 것을 직접 구현하지는 않는다는 것을 보여줍니다. 또한, AI가 생성한 코드의 품질과 유지보수성에 대한 의문도 제기되며, 이러한 의존성 관리가 AI 시대에도 여전히 중요함을 시사합니다.