Flatpak의 미래
(lwn.net)- 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 발전의 새로운 동력으로 부상할 여지가 존재함
- 주요 포인트는 리뷰어 확보, 표준화, 생태계 확장, 사용자 경험 개선 등으로 요약 가능함
접근 권한을 아예 막지 말고 어느 디렉터리에 접근하는지 명확히 보여주는 방식이 나은 것 같아요.
안드로이드가 그런 면에서 괜찮은데 이쪽은 권한을 너무 크게 묶어서 필요하지 않은 수준의 권한도 같이 허용해야 하고...
Hacker News 의견
- Wick의 발표에서 Flatpak 프로젝트는 겉보기에는 잘 돌아가는 듯 보이지만 실제로는 활발한 개발이 이뤄지지 않는 상황이라는 점을 강조한 내용 공유, 보안 유지와 간단한 유지보수는 계속되지만 새로운 기능이 거의 추가되지 않는 현상, 많은 기능 제안(Merge Request)이 올라와도 검토하는 이가 없어 답보 상태라는 점은 문제라 생각함, 특히 RHEL 10에서 데스크탑 패키지 제공을 중단하고 Flathub에서 패키지 설치를 권장하면서 Red Hat의 역할이 더욱 중요해졌다고 판단, Red Hat이 Flatpak을 제대로 대체재로 만들고 싶다면 더 많은 자원을 투입해주길 바라는 입장, Flatpak 버전별로 새로운 권한 지원 여부가 달라 backwards compatibility가 필요하다는 Wick의 지적에 공감, 본인이 Flathub에 게임을 배포하면서 오디오와 콘트롤러 권한 문제, --device=input의 미지원 문제, 스피커만 열고 마이크는 차단 같은 세분화된 권한 설정이 불가한 현실을 직접 경험
- Red Hat이 처음엔 Firefox와 Thunderbird를 RHEL 10에 Flatpak 전용으로 배포하려다가, 실제로는 GA 출시 후 rpm 패키지도 제공한 사례 언급, Native Messaging 미지원, 중앙 정책 배포 불가, 데스크탑 통합 문제 등 다양한 이유가 복합적으로 작용했음
- Flatpak이 처음 시작했을 때 원 개발자를 직접 만나 디자인 철학에 대해 토론했던 경험을 공유, Flatpak은 패키지명에 권한이 묶이고, 인스턴스별 분리가 되지 않는 구조가 문제라 설득하려 했었음, 즉, 동일 Flatpak 앱을 여러 인스턴스로 띄워 각기 다른 권한(예: Documents 하위 특정 디렉토리만 허용)으로 분리 실행이 되지 않음, 이러한 구조는 MS, Apple App Store, macOS도 마찬가지라 세상이 모두 잘못 설계하고 있다고 생각, 예를 들어 LibreOffice 문서에서 RCE(원격 코드 실행)이 일어나더라도 내 다른 문서 접근은 막혀야 하며, 벤더가 보안에 신경쓰지 않아도 Flatpak 샌드박스가 보안을 제공해야 한다고 주장
- 이런 보안 목적의 복잡성 증가에 비판적 시각, PC는 내 것이기에 인스턴스별 권한, 샌드박스, 파일 공유 제한 등은 불필요하며 '모든 것은 파일'이라는 전통적 개념 유지 원함, 예시로 Thunderbird, Firefox가 /tmp 디렉토리에 접근하지 못해 첨부파일을 저장/다른 앱에서 열기가 극히 불편해지는 샌드박스 환경에 불만, 컴퓨터의 주인이 개발자가 아니라 사용자가 되어야 한다고 주장, 이런 과도한 보안은 생산성 저하로 이어진다고 생각, Useless Machine에 비유
- Flatpak 개발진도 이 문제를 이해하고 있었을 가능성을 제기, Flatpak이 기술적으로 완벽한 모델을 택했다면 오히려 앱 개발자, 특히 멀티플랫폼 개발자들에게 너무 큰 진입장벽이 되어 Flatpak 자체가 확산되지 못했을 것이라는 현실론
- 인스턴스별 권한 모델이 매우 매력적이지만 환경설정(git config, 폰트 폴더 등)에 대해서는 모든 인스턴스가 동일 접근 권한을 갖도록 옵션화하는 하이브리드 방식이 실용적이라고 제안
- 운영체제 전반을 재설계하여 실행 중인 각 인스턴스에 별도 권한(capabilities) 부여, 디스크 쿼터, 로깅, 프록시, 세밀한 권한 분리 등 다양한 기능을 지원하는 게 바람직하다고 생각, 단순히 Flatpak만의 문제가 아니라고 주장
- QubesOS처럼 하이퍼바이저 기반 샌드박싱 등 철저한 분리가 필요한 파워유저, 보안 민감 사용자에겐 인스턴스별 분리가 좋지만, 대부분의 격리작업은 앱 내부에서 이뤄지는 것이 직관적 접근, 웹브라우저 샌드박싱처럼 Flatpak도 nested sandbox 지원이 이상적이지만 현재는 미지원 상태, 코드서명과 샌드박스 연계, UID 네임스페이스 등 꽤 복잡한 문제도 존재함
- 본인은 Flatpak의 오랜 열성 사용자로서, 혁신적이고 모든 리눅스 배포판에서 최신 앱을 쉽게 쓸 수 있게 해줬지만, 몇 년 간 변화가 없어 점차 관심이 식었다는 경험, 현재는 AUR로 대부분 충족하며 Flatpak 정체 상황이 아쉬움
- Flatpak을 사용자로서 쉽다는 점 빼고는 딱히 좋은 경험이 없었음, 테마, 커서, 파일피커, 퍼미션, Drag&Drop 등 여러 통합문제, 기능 사용을 위한 추가 툴 필요, UX가 떨어지는 이상 샌드박싱 등의 보안 혜택은 무의미하다고 생각, 리눅스에서 바이너리 이식성 문제만 없었어도 Flatpak은 필요 없었을 거라는 입장
- Fedora+GNOME+Flatpak 조합이 한때 매우 혁신적이라 느꼈지만 최근에는 다시 Arch로 돌아간 경험, Arch 저장소가 훨씬 풍부해졌고 AUR를 거의 쓸 일이 없어짐
- 여러 패키지를 관리했던 경험자에게 makedeb 사용 경험을 물으며, makedeb는 PKGBUILD 기반이라 이식성이 뛰어나고, 왜 더 많이 안 알려졌는지 의아하다고 언급
- Drew DeVault의 ‘배포판이 앱 패키징을 담당해야 한다’는 주장에 100% 동의하진 않으나, 오랜 논의문과 참고 링크 소개, 커뮤니티(배포판)가 사용자를 대표해 패키지를 관리한다는 모델이 올바르다고 보는 시각, Flatpak/Snap/AppImage처럼 배포판 외부에서 패키징하는 모델은 근본적으로 좋지 않다고 주장
- 이에 반박하며, 앱을 직접 만드는 개발자가 패키지 관리에 가장 적합함, 특히 소스 비공개 소프트웨어의 경우 법적으로 배포 및 패키징 권한이 독점되며, 오픈소스라 해도 핵심팀이 아닌 사람이 패키징에 임의로 개입하는 것은 불필요한 버그, 릴리즈 지연, 새로운 문제를 유발한다고 생각, 빠르고 최신 업데이트, 패키징 변조 없는 순정 소프트웨어 제공을 원함, Flatpak이 너무 많은 역할을 하려는 게 문제라고 보며, 앱스토어 모델 자체에도 회의적, Windows, macOS에서는 앱스토어 없이도 바이너리 배포가 자유롭고, 최소한의 보안은 코드서명 등 OS 레벨에서 제공한다고 주장, 서드파티 패키징 시스템 주도는 불필요
- 앱 개발자가 직접 배포할 수 있어야 하며, Windows의 간단한 설치 경험을 예로 듦, 유지관리자가 모든 배포판을 지원하는 규모를 갖추기 어렵고 이는 Linux 데스크톱 발전에 걸림돌이라고 봄
- 여러 배포판에 맞춰 일일이 패키징해야 하는 수고로 인해 오히려 의미가 떨어진다는 지적
- 세상 소프트웨어를 전부 배포판이 패키징하는 건 비현실적이라는 의견
- 배포판이 앱 패키징을 잘 못한다는 입장에서, Flatpak 채택이 늘어 기쁨, 개발자가 중간자 없이 자신의 앱을 쉽게 배포할 수 있어야 한다고 생각
- Flatpak이 PulseAudio를 계속 이용해 PipeWire 도입에 뒤처지고 있다는 점, PulseAudio는 스피커와 마이크 권한을 통합해 분리 불가, 즉 앱에 소리출력 권한을 주면 자동으로 마이크에도 접근 가능해 보안상 큰 구멍이라는 지적에 공감
- 윈도우/맥의 디자인 실수나 자유 부족을 조롱하는 리눅스 유저도 자주 보지만, 이런 본질적 디자인 문제 역시 인정해야 한다는 주장, 리눅스 생태계는 책임 소재를 명확히 하지 못한 채 문제를 방치하는 경향이 있다고 생각
- VSCode/Codium을 Python 디버깅 목적으로 Flatpak으로 설치했으나, 권한/설정 문제로 디버거 세팅에 오랜 시간이 소요되었고, 결국 Snap 버전으로 설치하니 모든 문제가 해결됨을 경험
- Flatpak은 대형 앱(예: Chrome, Chromium) 등 데스크탑 애플리케이션에 적합하지만, 시스템 도구에는 부적합하다고 생각
- Emacs Flatpak 버전은 비효율과 좌절만 안겨줬다는 경험
- immutable distro에 Flatpak 기반으로 전환하여 사용할 때 잘 맞을 땐 좋은데, 예상외로 많은 부분이 동작하지 않아 기대에 못 미침, 예를 들어 Godot용 외부 툴 실행, 여러 퍼미션 트윅, Flatpak끼리의 상호 연동문제(예: Firefox와 KeepassDX), Godot와 Krita Flatpak의 크래시, 비 Flatpak AppImage/.rpm 등 이질적 환경 등 다양한 불편을 경험, Flatpak의 더욱 많은 혁신을 바란다고 언급
- Flatpak으로는 Tailscale처럼 가상 네트워크 인터페이스를 생성하는 앱 패키징이 불가능한 구조, macOS는 API를 통해 네트워크 권한을 세분화해 Tailscale도 Mac App Store에서 샌드박스 앱 형태로 배포 가능함
- 해당 API 덕분에 Tailscale의 macOS용 샌드박스 앱 배포 가능, 반면 Silverblue, Bluefin 등 Flatpak에 의존하는 "atomic" Linux 배포판에선 이런 종류의 소프트웨어 사용이 힘든 현상
- OBS Studio처럼 Flatpak은 데스크탑 대형 앱에 유의미, 시스템 서비스처럼 동작하는 Tailscale은 Flatpak보다 배포판 기본 패키지가 적합하다고 생각, Arch Linux에선 공식 패키지로 존재
- Flatpak에서 flatpak-spawn, polkit-exec 등 우회로 가능하나, 이 경우 샌드박스 보호를 거의 포기하게 됨
- Linux 최상단에 세밀한 퍼미션 시스템과 패키징까지 한 번에 해결하려는 시도가 지나치게 복잡, Flatpak의 정체나 개발자 소진현상도 이 때문일 수 있다고 의심, 현대 Linux에 근본적인 권한 체계가 없으니 완벽한 퍼미션 설정보다 우선 당면 과제는 소프트웨어 배포, 패키징, 업데이트 체계라는 현실 인식
- Tailscale 같은 것은 sysext(시스템 익스텐션)으로 가야 하고 Flatpak은 적합하지 않다는 의견
- 플랫팍 배포 제안 관련, Java 기반 KmCaster 앱을 개발하며 Flatpak 포팅 요구를 받았지만 두 번의 설치 방법, 다운로드 통계 관리, 서드파티 저장소 신뢰, 신규 패키지 매니저 증가, 저장소 중복 등 추가 부담만 체감, 실질적으로 장점 없음
- 그럼에도 Flatpak의 긍정적 측면으로 immutable distro에서의 사용 편의, Java 버전 관리 필요성 해소, Flathub 검색 노출, 자동 업데이트 등은 장점이라 언급
- 오픈소스 유지보수자나 개발자는 아니지만, 수많은 Linux 배포판이 모두 같은 패키지 관리 문제를 안고 있는데 힘을 합쳐 Flatpak의 보완 및 보편화에 집중하지 못한다는 것이 이해가 안간다고 생각
- 각 배포판마다 배포(Distribution)의 방식 자체가 다르기 때문에 하나로 통일되기 어렵고, 다양한 선택권이 오픈소스 생태계의 장점이라고 생각, 개인적으로는 전통적인 시스템 패키지 매니저가 더 마음에 듦
- 이런 논리라면 GNOME만 존재해야 하는 셈이고 커뮤니티의 다양성, 의사결정 다양성이 중요하다는 입장
- Flatpak이 내게 전혀 쓸모가 없음, 본인이 사용하지 않는 소프트웨어에 기여를 강요받고 싶지 않음