2024년 5월 커뮤니티 대화에서 IceWhale CTO Tiger와 커뮤니티 개발자 Axel은 CasaOS와 초기 단계의 ZimaOS 앱 생태계가 플랫폼별 패키지 형식에 의존하는 대신 공통 컨테이너 표준을 채택한 이유를 논의했습니다.
핵심 아이디어는 간단했습니다. 개발자가 익숙한 Docker Compose 파일을 재사용하고, 소량의 앱 스토어 메타데이터를 추가하며, 모든 기여를 코어 팀과 직접 조율하지 않고도 앱을 배포할 수 있다면 앱 생태계가 더 빠르게 성장한다는 것입니다.
이는 현재 출시 사양이 아니라 2024년의 기술적 방향이었습니다
이 대화는 ZimaOS가 CasaOS와 공유하던 기반에서 계속 발전하던 시기에 이루어졌습니다. 당시 향후 API, 워크숍, 타사 확장 기능 및 systemd-sysext 모듈화에 관한 발언은 당시의 계획이나 초기 단계 실험을 설명한 것이었습니다. 따라서 모든 개념이 제시된 일정에 맞춰 구현된다는 약속으로 해석해서는 안 됩니다.
초기 맞춤형 JSON 앱 형식이 마찰을 일으킨 이유
Tiger는 초기 CasaOS 앱 스토어가 맞춤형 JSON 형식을 사용했다고 설명했습니다. 이 파일에는 앱 제목, 아이콘, 스크린샷, 구성 세부 정보 등 Docker 이미지에 관한 메타데이터가 포함되었습니다.
문제는 JSON으로 앱을 설명할 수 없다는 것이 아니었습니다. 문제는 기여자 온보딩이었습니다. 앱을 게시하려는 사람은 먼저 CasaOS 전용 형식을 배워야 했습니다. 이 추가 변환 단계 때문에 기존 컨테이너 프로젝트를 설치 가능한 앱으로 전환하는 속도가 제한되었습니다.
Docker Compose가 앱 패키징의 기반이 된 이유
팀은 Docker Compose가 컨테이너 정의를 담을 만큼 확장 가능하면서도 앱 스토어에 필요한 추가 메타데이터를 수용할 수 있다는 점을 확인했습니다. 따라서 기존 Compose 프로젝트를 별도의 패키징 시스템에서 다시 만들지 않고도 적용할 수 있었습니다.
이로 인해 기여 모델이 바뀌었습니다.
- 컨테이너 이미지와 서비스 정의는 익숙한 Docker 규칙을 계속 사용할 수 있었습니다.
- 제목, 아이콘, 스크린샷, 포트, 볼륨 정보와 같은 앱 스토어 필드를 Compose 정의에 추가할 수 있었습니다.
- 기여자는 플랫폼 전용 패키지를 별도로 유지 관리하는 대신 업스트림 작업을 재사용할 수 있었습니다.
- ZimaOS와 CasaOS는 더 폭넓은 셀프 호스팅 생태계의 혜택을 누릴 수 있었습니다.
Docker Compose가 커뮤니티 기여를 어떻게 바꿨는가
인터뷰에서는 초기 커뮤니티 기여 사례를 예로 들었습니다. Tiger는 Wisdom Sky라는 이름으로 알려진 기여자가 Compose 기반 앱 스토어 지원이 도입되던 시기에 하룻밤 만에 약 150개의 컨테이너 이미지를 CasaOS 앱으로 변환했다고 회고했습니다. 팀은 이전에 한 달에 한두 개의 새 앱이 추가되던 속도에서 소폭 증가하는 정도만 예상하고 있었습니다.
이는 2024년 대화에서 나온 일화이며, 모든 앱이 얼마나 빠르게 패키징될 수 있는지를 보여 주는 기준은 아닙니다. 각 앱에는 여전히 올바른 포트, 볼륨, 아키텍처 지원, 권한, 업데이트 동작 및 유지 관리자의 검토가 필요합니다.
타사 앱 스토어가 생태계에 편입되는 방식
팀은 타사 앱 소스 지원에 대해서도 설명했습니다. 모든 커뮤니티 패키지를 공식 카탈로그에 등록하도록 요구하는 대신, 유지 관리자가 독립적인 소스를 호스팅하고 사용자가 이를 CasaOS 또는 ZimaOS에 추가할 수 있었습니다.
이 모델은 선택의 폭을 넓히고 공식 팀의 검토 병목을 줄이지만, 제공 여부와 공식 보증을 분리하기도 합니다. 타사 소스에 앱이 표시된다고 해서 IceWhale이 해당 이미지를 유지 관리하거나, 코드를 감사하거나, 업데이트를 보장하거나, 데이터 처리 방식을 지원한다는 의미는 아닙니다. 사용자는 설치 전에 이미지 게시자, 저장소, 요청된 권한, 연결된 저장 공간, 네트워크 노출 및 업데이트 이력을 확인해야 합니다.
오픈 구성 요소와 독점 제품 코드 사이에서 제안된 균형
Tiger는 ZimaOS가 게이트웨이와 메시지 버스 기반의 일부를 포함한 오픈 CasaOS 구성 요소를 기반으로 구축되고 있으며, 다른 제품 계층은 독점으로 유지될 것이라고 말했습니다. 팀은 오픈 소스 기여를 계속 받고 확장 기능 개발자에게 더 많은 API를 공개하는 방안을 검토하고 있었습니다.
인터뷰에서는 모든 ZimaOS 코드가 오픈 소스가 될 것이라고 주장하지 않았습니다. 재사용 가능한 인터페이스와 커뮤니티 대상 구성 요소는 공개하면서 일부 제품 구현은 비공개로 유지하는 하이브리드 경계를 설명했습니다.
systemd-sysext 모듈화가 가능하게 하려던 것
대화에서는 systemd-sysext를 기반으로 한 매우 초기 단계의 메커니즘이 언급되었습니다. 목표는 정의된 플랫폼 인터페이스를 기반으로 구축하는 것과 비슷한 원리로, 타사가 변경 불가능한 코어를 직접 수정하지 않고 시스템 수준의 확장 기능을 추가할 수 있도록 하는 것이었습니다.
Tiger가 이 작업을 명확히 초기 단계라고 설명했으므로, 이 부분은 아키텍처 맥락으로 읽어야 합니다. 게시물에는 공개 확장 SDK, 안정적인 API 계약, 호환성 정책 또는 확정된 출시일이 제시되지 않았습니다.
더 넓은 원칙: 표준을 재사용하고 새로 만들지 않기
가장 지속적인 핵심은 기존 커뮤니티 표준을 선호한다는 점이었습니다. Docker와 Compose를 재사용하면 IceWhale 팀과 앱 기여자 모두 플랫폼별 작업을 줄일 수 있으며, 앱 스토어를 훨씬 더 큰 셀프 호스팅 소프트웨어 풀과 연결할 수 있습니다.
현재 ZimaOS 개요에서는 시나리오 기반 앱 스토어, 타사 Docker 지원 및 800개가 넘는 앱 카탈로그를 소개하고 있습니다. 이러한 현재 제품 설명은 생태계가 어떻게 발전했는지를 보여 주며, 2024년 인터뷰는 그에 앞선 설계상의 이유를 설명합니다.
원본 앱 스토어 생태계 대화 시청하기
전체 영상에서는 Axel과 Tiger의 대화가 지닌 분위기와 역사적 맥락을 확인할 수 있습니다.
ZimaOS 앱 스토어 생태계 FAQ
CasaOS는 왜 맞춤형 JSON 전용 앱 형식에서 벗어났나요?
맞춤형 형식은 기여자가 추가로 학습해야 하는 단계를 만들었습니다. Docker Compose를 사용하면 유지 관리자가 널리 알려진 서비스 정의를 재사용하고 앱 스토어에 필요한 메타데이터를 추가할 수 있습니다.
타사 ZimaOS 앱 스토어는 공식 앱 스토어와 같은 것인가요?
아니요. 타사 소스는 앱 선택의 폭을 넓힐 수 있지만, 해당 패키지는 다른 사람이 유지 관리하고 검토할 수 있습니다. 사용자는 설치 전에 소스와 컨테이너 구성을 평가해야 합니다.
인터뷰에서 공개 ZimaOS 확장 API가 확정되었나요?
아니요. 팀은 API, 워크숍 및 확장 기능 개발을 검토 중이라고 밝혔습니다. 대화에서는 안정적인 API나 출시 일정이 공개되지 않았습니다.
2024년 5월에 systemd-sysext가 이미 완성된 ZimaOS 기능이었나요?
아니요. Tiger는 모듈화 메커니즘을 매우 초기 단계라고 설명했습니다. 이는 변경 불가능한 코어를 중심으로 확장 기능을 구현할 수 있는 방안으로 제시되었습니다.
ZimaOS의 모든 코드는 오픈 소스인가요?
인터뷰에서는 완전한 오픈 소스 운영 체제가 아니라, 오픈 구성 요소와 독점 제품 코드 사이의 균형을 설명했습니다.
