APT를 버리는 문제가 아니라, 경계를 다시 긋는 문제입니다

APT에서 Flatpak으로 옮긴다는 표현은 조금 위험합니다. Debian, Ubuntu 계열에서 APT는 여전히 운영체제 패키지 관리의 기준축입니다. 커널, systemd, OpenSSH, 네트워크 도구, 드라이버, 서버 데몬, 보안 업데이트 흐름은 배포판 저장소 정책 위에서 돌아갑니다. Flatpak은 이 자리를 대체하기보다, 데스크톱 애플리케이션을 배포판 릴리스 주기에서 분리하는 선택지에 가깝습니다.

제가 13년 정도 Linux 서버와 데스크톱을 같이 운영하면서 얻은 기준은 단순합니다. 시스템을 구성하는 패키지는 APT, 사용자가 실행하는 독립형 GUI 앱은 Flatpak 후보로 봅니다. 이 기준을 세우면 “무엇을 옮길지”보다 “무엇을 절대 옮기지 말아야 할지”가 먼저 보입니다. 실제 마이그레이션에서 사고를 줄이는 건 과감한 전환이 아니라 경계 설정이더라고요.

무작정 “기존 앱을 전부 Flatpak으로 바꾸자”로 가면 생각보다 빨리 꼬입니다. 같은 앱을 배포판 패키지와 Flatpak으로 동시에 설치하면 설정 경로, 실행 파일, MIME 연결, 포털 권한, 자동 실행 항목이 서로 다른 층에서 움직입니다. 사용자는 같은 아이콘을 눌렀다고 생각하지만 실제로는 다른 패키징 채널의 앱이 실행될 수 있습니다. 이때 “설정이 사라졌다”가 아니라 다른 설정 디렉터리를 보고 있는 것인 경우가 많습니다.

APT는 운영체제와 서비스 계층, Flatpak은 사용자 앱 계층으로 나뉘는 구조를 보여주는 다이어그램이 잘 맞습니다.

APT와 Flatpak의 차이는 설치 방식보다 운영 책임입니다

APT는 배포판 저장소의 패키지를 시스템 경로에 설치하고, 의존성까지 배포판 기준으로 맞춥니다. 패키지는 대체로 /usr/bin, /usr/lib, /etc, /var 같은 경로와 강하게 연결됩니다. 운영 입장에서는 이 점이 꽤 든든합니다. 보안 업데이트, 서비스 재시작, 설정 파일 관리, 로그 위치가 배포판 관례를 따르거든요.

Flatpak은 앱과 런타임을 별도로 관리하고, 앱을 샌드박스 안에서 실행합니다. 사용자 설정은 대체로 ~/.var/app/앱ID/ 아래에 쌓입니다. 앱은 flatpak run 앱ID 형태로 실행하며, 파일 접근은 Flatpak 권한과 데스크톱 포털(xdg-desktop-portal)의 영향을 받습니다. 그래서 Flatpak은 “최신 GUI 앱을 깔기 쉬운 도구”이면서 동시에 “파일 접근과 시스템 통합을 명시적으로 다뤄야 하는 도구”입니다.

이 표에서 핵심은 “Flatpak이 더 좋다”가 아닙니다. Flatpak은 앱 경계를 명확하게 만들지만, 그만큼 경계 밖 리소스를 쓰려면 권한을 열어야 합니다. 반대로 배포판 패키지는 시스템과 자연스럽게 붙지만, 앱별 격리나 배포판 버전 독립성은 약합니다. 도구의 우열보다 책임 범위가 다릅니다.

Linux 마이그레이션 전에는 설치 목록보다 출처를 먼저 확인하세요

제가 현장에서 제일 먼저 보는 건 패키지 이름이 아니라 어느 채널에서 설치됐는지입니다. 같은 Firefox, 같은 GIMP라도 배포판 패키지, Snap, Flatpak, 수동 압축 해제본이 섞여 있으면 문제를 재현하기 어렵습니다. 특히 Ubuntu 계열은 일부 데스크톱 앱이 apt 명령으로 설치되는 것처럼 보여도 실제로는 다른 패키징 채널로 연결되는 경우가 있어 실행 경로 확인이 중요합니다.

# 현재 APT 설치 상태를 파일로 남깁니다.
apt list --installed > apt-installed.txt
apt-mark showmanual > apt-manual.txt

# Flatpak 앱과 런타임을 분리해서 확인합니다.
flatpak list --app > flatpak-apps.txt 2>/dev/null || true
flatpak list --runtime > flatpak-runtimes.txt 2>/dev/null || true

# 특정 앱의 APT 출처와 버전 후보를 봅니다.
apt policy gimp
apt-cache show gimp | sed -n '1,80p'

# 실행 경로와 데스크톱 런처를 확인합니다.
command -v gimp
which -a gimp
ls /usr/share/applications | grep -i gimp || true
ls ~/.local/share/applications | grep -i gimp || true
ls /var/lib/flatpak/exports/share/applications | grep -i gimp 2>/dev/null || true
ls ~/.local/share/flatpak/exports/share/applications | grep -i gimp 2>/dev/null || true

apt policy에서 Installed는 현재 설치된 버전, Candidate는 저장소 기준으로 설치 또는 업그레이드될 후보입니다. Candidate: (none)에 가깝거나 배포판 저장소의 앱이 업무에 필요한 기능보다 늦게 따라온다면 Flatpak 전환 후보로 표시합니다. 다만 후보가 오래됐다는 이유만으로 서버 도구까지 옮기면 안 됩니다. 서버 도구는 최신 기능보다 재현성과 배포판 보안 흐름이 더 중요한 경우가 많습니다.

실행 경로도 꼭 봐야 합니다. 터미널에서 command -v gimp가 /usr/bin/gimp를 가리키는데 런처는 Flatpak 데스크톱 파일을 가리키는 상황이 생길 수 있습니다. 이러면 터미널에서 실행한 앱과 메뉴에서 실행한 앱이 서로 다른 설정을 씁니다. 버그처럼 보이지만 실제 원인은 런처와 PATH의 불일치입니다.

Flatpak 설치와 Flathub remote는 시스템 단위와 사용자 단위를 구분하세요

Flatpak 자체는 보통 배포판 패키지 관리자로 설치합니다. 여기서 이미 역할 분리가 시작됩니다. 기반 도구는 배포판 패키지로 받고, GUI 앱 배포 채널만 Flatpak remote로 분리하는 방식입니다. 데스크톱 한 대만 쓰면 별 차이가 없어 보이지만, 가족 PC, 홈랩 워크스테이션, 공용 장비처럼 사용자가 여러 명이면 설치 범위가 중요해집니다.

# Debian/Ubuntu 계열에서 Flatpak 기반 도구 설치
sudo apt update
sudo apt install flatpak

# 시스템 전체에 Flathub remote 추가
sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

# 현재 등록된 remote와 설치 범위 확인
flatpak remotes --show-details
flatpak remotes --user --show-details
flatpak remotes --system --show-details

# 앱 목록 확인
flatpak list --app
flatpak list --app --columns=application,name,version,branch,installation

sudo flatpak remote-add는 시스템 설치 범위에 remote를 추가합니다. 반대로 사용자 단위로만 쓰고 싶다면 flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo 형태를 씁니다. 개인 노트북이라면 둘 중 하나로 통일하는 편이 낫습니다. 같은 remote가 사용자 범위와 시스템 범위에 동시에 들어가면 나중에 앱이 어디에 설치됐는지 헷갈립니다.

설치 위치도 달라집니다. 시스템 범위 Flatpak은 보통 /var/lib/flatpak 아래에 있고, 사용자 범위 설치는 ~/.local/share/flatpak 아래에 있습니다. 백업이나 디스크 정리를 할 때 이 차이가 바로 영향을 줍니다. 용량이 부족한 데스크톱이라면 앱뿐 아니라 런타임도 같이 쌓인다는 점을 염두에 두셔야 합니다. 정확한 용량은 설치한 앱과 런타임에 따라 달라지므로, 추측하지 말고 아래처럼 직접 확인하는 게 좋습니다.

# Flatpak 설치 공간 확인
sudo du -sh /var/lib/flatpak 2>/dev/null || true
du -sh ~/.local/share/flatpak 2>/dev/null || true

# 사용하지 않는 런타임 정리 후보 확인 및 제거
flatpak uninstall --unused

# Flatpak 앱, 런타임, 설치 범위를 함께 확인
flatpak list --columns=application,name,type,branch,installation

Flathub remote, 런타임, 앱, 사용자/시스템 설치 범위가 어떻게 이어지는지 보여주는 구성도가 있으면 좋습니다.

APT 앱을 Flatpak으로 옮기는 절차: 한 번에 하나씩, 되돌릴 수 있게

실전에서는 앱 하나를 골라 전환하고 하루 정도 써본 뒤 다음 앱으로 넘어가는 방식이 안전합니다. GIMP 같은 GUI 앱은 좋은 시험 대상입니다. 시스템 서비스가 아니고, 파일 접근 권한 문제가 드러나기 쉽고, 설정 디렉터리 차이도 확인하기 좋기 때문입니다. 이거 진짜 번거로워 보여도, 나중에 문제를 좁히는 데 큰 도움이 됩니다.

1. 배포판 패키지 설치 여부, 버전, 실행 경로, 데스크톱 파일을 확인합니다.
2. 기존 설정 디렉터리를 백업합니다. 바로 삭제하지 않습니다.
3. Flatpak 앱 ID를 확인하고 설치합니다.
4. 실행, 파일 열기, 저장, 플러그인, 기본 앱 연결을 테스트합니다.
5. 문제가 없으면 기존 패키지를 제거하되, 설정 purge는 며칠 뒤에 판단합니다.

# 1. APT 상태 확인
apt policy gimp
command -v gimp
which -a gimp

# 2. 기존 사용자 설정 백업 예시
mkdir -p ~/migration-backup/gimp
cp -a ~/.config/GIMP ~/migration-backup/gimp/ 2>/dev/null || true
cp -a ~/.gimp-* ~/migration-backup/gimp/ 2>/dev/null || true

# 3. Flatpak 앱 검색 및 설치
flatpak search gimp
flatpak install flathub org.gimp.GIMP

# 4. 실행 및 정보 확인
flatpak run org.gimp.GIMP
flatpak info org.gimp.GIMP
flatpak info --show-permissions org.gimp.GIMP

# 5. APT 패키지 제거. 마이그레이션 직후에는 purge보다 remove를 권합니다.
sudo apt remove gimp
sudo apt autoremove

flatpak search에서는 이름보다 Application ID를 확인해야 합니다. org.gimp.GIMP 같은 ID가 이후 실행, 권한 확인, 제거, override, 업데이트에서 계속 쓰입니다. 이름은 사람이 읽는 라벨이고, 운영할 때 필요한 키는 앱 ID입니다.

sudo apt remove는 시스템 패키지를 제거하지만 사용자 홈 디렉터리 설정은 대체로 남깁니다. sudo apt purge는 패키지의 시스템 설정까지 제거하는 데 쓰지만, 사용자 홈 아래 설정까지 항상 정리해주는 만능 청소 도구는 아닙니다. 저는 마이그레이션 당일에는 purge를 피합니다. 되돌릴 일이 생겼을 때 기존 설정이 남아 있으면 복구가 훨씬 빠릅니다.

설정 이전은 앱마다 다릅니다. 기존 설정을 Flatpak 경로로 그대로 복사하면 될 때도 있지만, 버전 차이나 플러그인 경로 차이 때문에 오히려 문제를 만들 수 있습니다. 특히 IDE, 브라우저, 그래픽 도구는 “설정 폴더 전체 복사”보다 내보내기/가져오기 기능을 우선 쓰는 편이 낫습니다.

가장 자주 본 실패 모드: 파일이 안 보이는 건 권한 모델 차이입니다

Flatpak 전환 후 가장 흔한 문제는 “파일이 안 보인다”입니다. 배포판 패키지로 설치한 앱은 홈 디렉터리를 자연스럽게 읽는 경우가 많지만, Flatpak 앱은 샌드박스와 포털을 거칩니다. 그래서 다운로드 폴더는 보이는데 ~/projects, 외장 디스크, NAS 마운트, 숨김 디렉터리는 안 보이는 상황이 생깁니다. 근본 원인은 앱 버그가 아니라 파일시스템 권한이 앱에 부여되지 않았거나, 포털 파일 선택기를 통해 전달된 파일만 접근 가능한 상태인 경우가 많습니다.

# 현재 권한 확인
flatpak info --show-permissions org.gimp.GIMP

# 현재 적용된 사용자 override 확인
flatpak override --user --show org.gimp.GIMP

# 특정 프로젝트 디렉터리만 읽기/쓰기 허용
flatpak override --user --filesystem="$HOME/projects" org.gimp.GIMP

# 읽기 전용으로만 허용하고 싶을 때
flatpak override --user --filesystem="$HOME/reference:ro" org.gimp.GIMP

# 홈 전체 접근을 허용하는 예시. 편하지만 격리 이점은 줄어듭니다.
flatpak override --user --filesystem=home org.gimp.GIMP

# override 초기화
flatpak override --user --reset org.gimp.GIMP

권한을 줄 때는 넓게 열기 전에 좁게 열어보는 편이 좋습니다. 이미지 편집 앱이 ~/projects/design만 필요하다면 해당 디렉터리만 허용합니다. 문서 편집기처럼 여러 작업 폴더를 오가야 한다면 xdg-documents, 특정 마운트 경로, 또는 홈 접근을 검토합니다. 다만 메신저, 뷰어, 단순 유틸리티에 홈 전체 권한을 주는 건 Flatpak을 쓰는 이유를 스스로 줄이는 선택입니다.

개발 도구는 더 까다롭습니다. Flatpak IDE가 프로젝트는 보지만 시스템의 /usr/bin/python, Docker 소켓, SDK 경로, SSH agent, GPG agent를 기대대로 못 볼 수 있습니다. 이 경우 Flatpak이 나쁘다기보다 개발 환경 자체가 호스트 시스템과 강하게 결합돼 있기 때문입니다. IDE를 Flatpak으로 옮길 때는 “편집만 하는가, 빌드와 디버깅까지 하는가”를 기준으로 판단하세요. 빌드, 컨테이너, 디바이스 접근이 많다면 배포판 패키지, 공식 tarball, 또는 전용 툴박스 환경이 더 안정적일 수 있습니다.

전환 후 검증: 실행되는지보다 어느 쪽이 실행되는지 보세요

마이그레이션 검증은 앱이 켜지는 순간 끝나지 않습니다. 실제로 문제는 그 다음에 옵니다. 파일 더블클릭은 기존 앱으로 열리고, 메뉴 런처는 Flatpak을 띄우고, 터미널에서는 예전 바이너리가 실행되는 식입니다. 사용자는 같은 앱을 쓴다고 느끼지만, 시스템은 서로 다른 실행 단위를 다루고 있습니다.

# Flatpak 앱 목록과 설치 범위
flatpak list --app --columns=application,name,version,branch,installation

# Flatpak 업데이트
flatpak update

# APT 쪽 동일 패키지 잔존 여부
apt list --installed 2>/dev/null | grep -i '^gimp/' || true
apt policy gimp

# 실행 경로 확인
command -v gimp || true
which -a gimp || true

# 데스크톱 파일 중복 확인
find /usr/share/applications ~/.local/share/applications /var/lib/flatpak/exports/share/applications ~/.local/share/flatpak/exports/share/applications \
  -iname '*gimp*.desktop' 2>/dev/null -print

# MIME 연결 확인 예시
xdg-mime query default image/png
xdg-mime query default image/jpeg

flatpak list --app에 앱이 있고 flatpak run 앱ID로 정상 실행되면 Flatpak 설치는 된 겁니다. 하지만 apt list --installed에도 같은 앱이 남아 있으면 중복 설치 상태입니다. 이 자체가 항상 장애는 아니지만, 기본 앱 연결과 런처가 섞이면 사용성이 나빠집니다. 장기 운영에서는 하나로 정리하는 편이 낫습니다.

업데이트 루틴도 분리해야 합니다. sudo apt upgrade는 APT 패키지를 갱신하고, flatpak update는 Flatpak 앱과 런타임을 갱신합니다. 둘 중 하나만 자동화하면 절반만 관리하는 셈입니다. 저는 데스크톱 장비에서는 주기적으로 둘 다 실행하고, 오래 안 쓰는 런타임은 flatpak uninstall --unused로 정리합니다.

APT 잔존 패키지, Flatpak 앱 목록, MIME 연결, 업데이트 상태를 한 화면에서 점검하는 대시보드형 이미지가 어울립니다.

APT와 Flatpak을 같이 쓸 때의 패키지 관리 전략

저는 데스크톱 Linux를 운영할 때 패키지를 세 부류로 나눕니다. 첫째, OS와 서비스에 붙은 패키지는 배포판 기본 관리 체계에 남깁니다. 둘째, 독립형 GUI 앱은 Flatpak 후보로 둡니다. 셋째, 개발 도구와 브라우저처럼 시스템 연동이 많은 앱은 테스트 후 결정합니다. 이 셋을 구분하지 않으면 패키지 관리가 취향 싸움처럼 흐릅니다.

현실적인 운영 예시는 이렇습니다. Ubuntu 데스크톱에서 SSH, Git, 빌드 도구, Docker 엔진은 APT로 유지합니다. GIMP, Inkscape, VLC, 일부 메신저는 Flatpak으로 둡니다. VS Code나 JetBrains IDE처럼 프로젝트 빌드와 컨테이너 연동이 많은 도구는 Flatpak으로 먼저 시험 설치한 뒤, 터미널 통합과 SDK 탐지가 불편하면 배포판 저장소나 공식 패키지로 돌아갑니다. 이 접근이 지저분해 보일 수 있지만, 실제 운영에서는 훨씬 덜 고장 납니다.

자동화할 때는 두 세계를 분리해서 써야 합니다. APT는 apt-mark showmanual과 패키지 목록으로 관리하고, Flatpak은 앱 ID 목록으로 관리합니다. 아래처럼 간단한 목록 파일을 만들면 새 장비 세팅이 편해집니다. 관련 글을 운영한다면 “Ubuntu 초기 세팅 체크리스트”나 “Linux 백업 전략” 같은 내부 링크로 이어주기 좋습니다.

# flatpak-apps.txt 예시
org.gimp.GIMP
org.inkscape.Inkscape
org.videolan.VLC

# 목록 파일 기반 설치
while read -r app; do
  [ -z "$app" ] && continue
  flatpak install -y flathub "$app"
done < flatpak-apps.txt

# 현재 설치된 Flatpak 앱 ID만 추출
flatpak list --app --columns=application > flatpak-apps-current.txt

자주 묻는 질문

Flatpak으로 바꾸면 APT는 안 써도 되나요?

아닙니다. Debian/Ubuntu 계열에서는 APT가 시스템 패키지 관리의 중심입니다. Flatpak은 주로 데스크톱 GUI 앱을 배포판 릴리스 주기와 분리해 관리하기 위한 보조 축으로 보는 게 맞습니다.

같은 앱을 APT와 Flatpak으로 같이 설치해도 되나요?

짧은 테스트 기간에는 괜찮습니다. 다만 장기간 유지하는 건 추천하지 않습니다. 실행 경로, 설정 디렉터리, 파일 연결, 런처 항목이 섞이면 문제를 추적하기 어려워집니다. 테스트가 끝나면 한쪽으로 정리하세요.

Flatpak 앱이 느리거나 무겁다고 봐야 하나요?

앱과 런타임 구성에 따라 다르므로 일반화하면 안 됩니다. 다만 런타임이 별도로 설치되고 업데이트되기 때문에 디스크 사용량과 업데이트 대상이 늘 수 있습니다. 실제 판단은 du -sh /var/lib/flatpak ~/.local/share/flatpak, flatpak list --runtime으로 확인하는 게 정확합니다.

마이그레이션 순서는 어떻게 잡는 게 좋나요?

시스템 핵심 패키지가 아닌 독립형 GUI 앱부터 시작하세요. 앱별로 설치, 실행, 파일 열기/저장, 권한, 기본 앱 연결, 업데이트를 확인한 뒤 다음 앱으로 넘어가는 방식이 안전합니다.

권한 관리는 CLI만 써야 하나요?

아닙니다. CLI에서는 flatpak info --show-permissions와 flatpak override를 쓰고, GUI로는 Flatseal 같은 도구를 쓸 수 있습니다. 다만 자동화나 문서화가 필요하면 CLI 명령을 남겨두는 편이 재현성이 좋습니다.

제가 권하는 최종 기준

서버 운영, 시스템 구성, 드라이버, 입력기, 네트워크 도구, 서비스 데몬은 APT를 유지하세요. 이 영역은 배포판의 보안 업데이트와 서비스 관리 흐름을 타는 편이 안정적입니다. 반대로 그래픽 편집기, 미디어 플레이어, 메신저, 독립형 데스크톱 앱은 Flatpak으로 먼저 테스트할 가치가 있습니다. 최신 버전과 앱별 격리의 이점이 실제 사용성으로 이어질 가능성이 큽니다.

브라우저와 개발 IDE는 중간 지대입니다. 브라우저는 인증서, 패스키, 외부 앱 호출, 다운로드 경로를 확인해야 합니다. IDE는 프로젝트 디렉터리, SDK, Docker, SSH/GPG agent, 터미널 통합까지 봐야 합니다. 이 항목에서 문제가 생기면 Flatpak을 고집하지 말고 배포판 패키지나 공식 패키지로 남기는 게 더 실용적입니다.

제가 쓰는 한 줄 기준은 이렇습니다. 운영체제와 서비스는 APT, 독립형 데스크톱 앱은 Flatpak, 호스트와 깊게 엮인 개발 도구는 별도 검증. 이 기준만 잡아도 “설치했는데 왜 설정이 없지?”, “왜 터미널과 런처 결과가 다르지?”, “왜 프로젝트 폴더가 안 보이지?” 같은 시간을 꽤 줄일 수 있습니다.

서버 패키지, GUI 앱, 브라우저, 개발 도구별로 APT와 Flatpak 선택 기준을 나눈 인포그래픽이 마무리에 잘 맞습니다.

마이그레이션은 도구 교체가 아니라 운영 모델 변경입니다. APT는 시스템의 기준선을 안정적으로 잡고, Flatpak은 사용자 앱 레이어를 더 유연하게 만듭니다. 둘을 섞어 쓰는 것이 타협처럼 보일 수 있지만, Linux 데스크톱을 오래 굴려보면 그게 가장 덜 피곤한 전략인 경우가 많습니다.