Ubuntu는 제가 처음 접하고 마음에 들었던 리눅스 배포판 중 하나였기에, 자연스럽게 그 '네이티브' 범용 패키지인 Snap을 선택했습니다. 그런데 최근에 Flatpak을 사용해 보면서, 늘 시스템 자체의 문제라고 여겼던 사소한 불편함들이 사실은 Snap의 샌드박싱 때문에 발생한 것임을 깨달았습니다. 이제 Flatpak을 충분히 사용해 본 결과, 일반적으로 더 나은 선택이라는 결론에 도달하게 되었습니다.
좌절의 순간들
Snap이 발목을 잡기 시작하다
Snap은 백그라운드에서 무난하게 작동하고, 업데이트도 대체로 순서대로 처리되며 필요한 앱을 스토어에서 찾을 수 있습니다. 하지만 Spotify 같은 특정 앱의 문제는 snapd의 상시 실행 데몬과 대기 중인 새로고침(refresh)의 조합에서 비롯됩니다. 이로 인해 앱이 '새로고침 대기(pending refresh)' 상태로 실행되면서 짧지만 성가신 지연이 발생합니다.
VS Code처럼 Snap으로 배포되는 다른 앱들에서는 이런 문제가 드물어 보입니다. 하지만 다른 문제들은 여전히 존재합니다. 예를 들어 Firefox에서는 동영상 재생이 끊기고 부드러운 스크롤이 되지 않는 경우가 종종 있습니다. Snap의 격리(confinement) 기능이 기본적으로 GPU 접근을 제대로 허용하지 않기 때문에 영상이 버벅이고 스크롤이 매끄럽지 못한 것입니다.
그런데 어떤 이유에서인지 저는 Spotify의 지연 현상을 개인적인 문제로 받아들이게 되었습니다. snapd의 백그라운드 오버헤드, 엄격한 격리 정책, 그리고 오디오 시스템과 깨끗하고 직접적인 연결이 필요한 앱의 조합은 최악의 궁합입니다. 게다가 Snap Store는 Canonical 독점이기 때문에 소싱에 유연성이 전혀 없습니다. 네이티브 패키지처럼 배포판 저장소가 출발점일 뿐 확장할 여지가 없다는 뜻입니다.
Flatpak은 처음부터 가볍게 느껴졌다
방해 요소가 적다
Flatpak은 즉각적인 속도 향상이나 화려한 기능을 제공하지는 않았지만, 기본적인 부분을 발목 잡지 않고 처리해 주었습니다. 업데이트 적용 시점을 내가 직접 통제할 수 있어서, 앱을 열 때 새로고침이 적용되기를 기다릴 필요가 없고, 백그라운드에서도 상시 실행되는 데몬이 간섭하지 않습니다.
필요한 앱 대부분을 포괄하는 검증되고 신뢰할 수 있는 옵션도 충분히 제공됩니다. 덕분에 Flatseal을 활용하면 시스템 전체 설정을 건드리지 않고도 개별 앱의 권한을 세부적으로 조정할 수 있습니다.
나란히 놓고 비교해 보면, Flatpak은 평소에는 티가 나지 않지만 정말 중요한 순간에 빛을 발하는 작은 개선들로 미세하지만 의미 있는 우위를 점하고 있습니다.
| 기능 | Snap | Flatpak |
|---|---|---|
| 스토어 개방성 | 단일, Canonical 통제 | Flathub + 추가 원격 저장소 |
| 백그라운드 프로세스 | snapd 상시 실행 | 상시 데몬 없음 |
| 업데이트 제어 | 자동, 큐 방식 | 사용자 제어 |
| 테마 통합 | 부분적, 자주 깨짐 | 개선됐으나 아직 불완전 |
| CLI 경험 | snap run app | flatpak run org.app.Name (다소 장황) |
Snap의 마운트 난잡함
Snap이 설치된 시스템에서 lsblk 명령어를 실행하면 그 결과에 미리 마음의 준비를 하는 것이 좋습니다. 앱이 10개라면 최소 10개의 loop 항목이 생깁니다. 각 Snap이 압축된 SquashFS 이미지를 loop 디바이스로 마운트하기 때문입니다. 그 결과 수많은 loop 항목이 블록 디바이스 목록을 어수선하게 만들고, GNOME Disks 유틸리티 역시 난잡해집니다.
이는 원자적(atomic) 업데이트와 강력한 격리를 지원하기 위한 Snap 설계상 의도된 동작입니다. 하지만 그 대가로 한눈에 파악하기 어려운 복잡한 시스템이 되는 것입니다.
반면 Flatpak은 OSTree를 저장소 배포와 공유 런타임에 활용하고, loop 디바이스 대신 fuse-overlayfs를 통해 마운트합니다. 이 경우 여러 앱이 동일한 중복 제거된 라이브러리 풀을 공유합니다. 개별 프라이빗 환경이 따로 마운트되지 않기 때문에 파일시스템이 더 깔끔하고 점검·감사하기도 쉬워집니다.
Flatpak에도 물론 문제는 있다
하지만 Snap의 문제보다는 나았다
Flatpak의 샌드박싱 역시 깊은 시스템 접근이 필요한 일부 앱에서 가끔 걸림돌이 될 수 있습니다. 저는 VS Codium에서 이를 경험했고, GTK 테마 연동도 가장 매끄럽지는 않습니다.
하지만 큰 차이점은 Flatpak의 이런 문제들은 대체로 눈에 보이고 해결 가능하다는 점입니다. 문제가 발생하면 원인을 파악하고 수정할 수 있으며, 주로 Flatseal로 권한을 조정하면 됩니다. 반면 Snap의 지연은 눈에 보이지 않아서 Snap 탓보다 시스템 탓으로 돌리기 쉽고, 마치 시스템이 사용자에게 등을 돌리는 것처럼 느껴집니다. Flatpak이 만든 진짜 차이는 바로 사용자에게 '통제권'을 돌려준다는 점입니다.
전환 과정 역시 매끄러웠습니다. Flatpak 설치는 간단하고 Flathub 활성화도 어렵지 않아 Spotify 같은 앱을 손쉽게 옮길 수 있었습니다. 다만 한 가지 함정이 있었는데, ubuntu-advantage-tools 같은 일부 패키지가 몰래 snapd를 재설치한다는 점입니다. 이런 가능성을 모른다면 Snap을 완전히 제거한 줄 알지만, 실제로는 여전히 시스템에 남아 있게 됩니다.
결론이 아니라 판단 기준
분명히 해두자면, 제가 Snap에게 한 일은 강등뿐입니다. 여전히 시스템의 일부로 남아 있습니다. 일상용 앱 대부분에는 Flatpak을 선호하지만, 특정 시스템 수준 도구는 Snap으로 유지합니다. 그곳이 어울리는 자리이기 때문입니다. 어느 한쪽이 항상 우월한 것이 아니며, 특정 작업에 맞는 도구가 곧 최고의 도구입니다.
제가 상황별로 선택하는 기준은 다음과 같습니다.
| 시나리오 | 최선의 선택 |
|---|---|
| 데스크톱 일상 앱 (Spotify, GIMP, Inkscape) | Flatpak |
| Ubuntu 시스템 도구 (코어 유틸리티, LXD) | Snap |
| Ubuntu의 Firefox / Thunderbird | 어느 쪽이든 — 둘 다 업스트림에서 직접 유지보수 |
| 엄격한 권한 조정이 필요한 앱 | Flatpak + Flatseal |
| 서버 데몬 또는 백그라운드 서비스 | Snap |
| 배포판 간 최대 호환성 | Flatpak |
결국 깨달은 것은 하나입니다. Linux 패키지 관리자에 대한 이해가 깊어질수록, 저는 점점 더 많은 앱을 Flatpak으로 옮기고 있었다는 사실입니다.