Flatpak의 미래

• Flatpak은 현재 개발자와 사용자에게 인기를 얻고 있지만, 프로젝트 자체의 개발 정체 문제가 대두됨
• 핵심 개발자의 이탈과 병목 현상으로 신규 기능 반영 및 코드 리뷰가 지연되는 상황임
• OCI 이미지 지원·권한 세분화·오디오 접근 제어 등 다양한 강화 기능이 제안됐으나, 실제로 반영이 더디게 이루어짐
• 프로젝트의 장기적 발전을 위해 컨테이너 기술 표준(OCI) 도입 및 Rust 기반 재구현 방안이 논의됨
• 포털 개선, 드라이버 지원, 네트워크 샌드박싱 등 주요 난제 해결이 Flatpak의 성장의 관건임

Flatpak 프로젝트 개요 및 현황

• Flatpak은 2007년부터 유사 프로젝트로 시작해, 2015년에 XDG-App으로 첫 출시, 2016년 Flatpak으로 명칭 변경 경과를 가짐
• 명령줄 도구, 빌드 툴, 런타임 구성 요소를 제공하며, cgroups, namespaces, bind mount, seccomp, Bubblewrap 등으로 어플리케이션 격리(샌드박싱) 구성 특성을 보임
• OSTree를 기본 전달 방식으로, 최근에는 OCI 이미지 지원도 탑재해 Fedora 등에서 활용됨
• Flathub 앱스토어 성장, 배포판 채택 등 성공적이나, 프로젝트 내부적으로는 활성 개발 둔화 현상을 겪음

개발 답보 현상 및 주요 원인

• 유지 관리와 보안 패치 수준의 활동은 존재하지만, 대규모 신규 기능 개발 및 코드 리뷰는 장기간 정체 현상 발생함
• 주요 개발자의 이탈(Larsson 등)로 리뷰어가 부족해, 신규 기여자 유입이나 대규모 변경이 어려운 환경이 조성됨
• Red Hat 등에서 기여하고 있는 Flatpak 사전 설치(Preinstall) 기능 등도 리뷰 지연 및 담당자 이탈로 통합 완료까지 수개월 소요 경험을 반복함

OSTree와 OCI 이미지 지원

• OSTree는 Flatpak에 성공적으로 적용됐으나, 비표준/제한된 도구 문제로 유지보수 외에는 적극적 발전이 없음
• OCI는 컨테이너 이미지를 위한 광범위한 도구 생태계가 존재해, Flatpak 개발팀 입장에서는 도입 시 유지보수 부담과 중복노력 감소 효과를 기대할 수 있음
• zstd:chunked와 같은 효율적 압축 포맷 지원 등도 신규 PR로 제안됐으나, 지연·미통합 상태 유지됨

권한 관리 및 샌드박스 세분화

• Flatpak은 샌드박싱을 통한 시스템 접근 제한에 초점을 맞추며, 최신 Flatpak에서는 권한 세분화(예: --device=input)가 지원됨
• 리눅스 배포판별로 Flatpak 버전이 달라, 새 권한 기능이 널리 적용되지 못하는 문제와 버전 호환 문제가 발생함
• 오디오 권한의 경우 PulseAudio 대응 한계로 재생·녹음 분리가 어려우며, 이는 PipeWire 등으로 개선 필요성이 제기됨
• 중첩 샌드박싱 지원 미흡으로 웹브라우저 등에서 내부적으로 별도 샌드박스 활용 불가함

D-Bus 및 네트워크 샌드박싱

• Flatpak은 직접 D-Bus에 접근하지 않고 xdg-dbus-proxy를 통해 필터링된 통신 방식을 사용함
• Wick은 필터링 정책을 D-Bus 브로커로 옮겨 정책 동적 적용 및 cgroup 기반 접근제어 실현 의지를 보임
• 네트워크 네임스페이스 구현 미비로 localhost 포트 노출 시 Flatpak 앱 간 의도치 않은 통신 가능성이 존재함(실제 사례: AusweisApp)
• NVIDIA 드라이버는 각 런타임별로 별도 제공되어 과도한 네트워크 트래픽과 업데이트 어려움을 야기함. Valve의 모델을 참고해 호스트 공유, 정적 컴파일 방안 등이 모색됨

포털(Portal) 활용 및 개선 필요성

• 포털은 D-Bus 기반 외부 자원 접근 API로, 파일, 프린트, URL 등 다양한 역할을 수행함
• Documents 포털 등은 파일 단위로는 효과적이나, GIMP·Blender 등 사용성 높은 앱에는 너무 세분화된 권한 모델이 한계로 작용함
• 비밀번호 자동완성, FIDO 키, 음성합성 등 신규 API 제안과 함께, 개발 난이도 완화 및 Rust 재구현 아이디어가 논의됨

Flatpak의 미래(Flatpak-next)

• 향후 Flatpak이 더 이상 개발되지 않는 상황을 가정, OCI 생태계로 대전환(이미지, 레지스트리, 도구, 정책 등 광범위한 활용)이 장기 관점에서 논의됨
• Rust 기반 재구현 등 컨테이너 생태계 일원화로 관리 부담, 유지보수, 확장성 측면에서 장점이 예상됨

질의응답 요약

• OCI 전환 시 기존 Flatpak 앱 처리에 대한 질문에, Flathub의 빌드 자동화 등으로 큰 문제 없다고 답변함
• OCI 레지스트리에 메타데이터 부족 문제는, 비이미지 데이터 표준이 마련되고 있으나, 실제 반영을 위해서는 개발·통합이 필요함
• PipeWire 직접 지원 계획에 대해, 테크니컬 논의가 진행 중이며, PipeWire 정책 기반 통합이 방향임

결론

• Flatpak은 배포 및 샌드박싱 표준 플랫폼으로 자리를 잡았으나, 리뷰 및 신규 개발 정체, 권한/네트워크/드라이버 문제, 미래 표준 전환 등 여러 개선 과제를 품고 있음
• OCI 기반 컨테이너 기술과 Rust 활용은 Flatpak 발전의 새로운 동력으로 부상할 여지가 존재함
• 주요 포인트는 리뷰어 확보, 표준화, 생태계 확장, 사용자 경험 개선 등으로 요약 가능함