Flatpak의 개요와 배경 이해하기

배포판, 라이브러리 충돌, 그리고 OSTree까지

리눅스 데스크톱에서 Flatpak이 표준처럼 자리 잡은 데에는 분명한 이유가 있다.
그 이유를 이해하려면 단순히 “Flatpak은 패키징 시스템이다”를 넘어서,
리눅스 배포판 구조, 라이브러리 버전 충돌, OSTree라는 기술까지 함께 이해해야 한다.

이 글에서는 다음 질문에 답해본다.

리눅스에서 말하는 배포판이란 무엇인가?
라이브러리 버전 충돌은 왜 발생하는가?
Flatpak은 이 문제를 어떻게 해결하는가?
그 핵심에 있는 OSTree는 무엇인가?

1. 리눅스 배포판이란 무엇인가?

많은 사람들이 “리눅스”를 하나의 운영체제로 생각하지만,
엄밀히 말하면 리눅스는 커널(kernel) 에 불과하다.

우리가 실제로 사용하는 것은 커널 위에 여러 구성 요소를 얹어 만든
리눅스 배포판(Linux Distribution) 이다.

배포판에 포함되는 것들

리눅스 커널
시스템 라이브러리 (glibc 등)
기본 명령어 도구 (GNU coreutils)
패키지 관리자
기본 설정과 정책
(선택적으로) 데스크톱 환경

이 모든 것을 하나로 묶어 제공하는 것이 배포판이다.

대표적인 배포판들

Ubuntu, Debian
Fedora, RHEL, CentOS
Arch Linux
openSUSE

각 배포판은 서로 다른 철학과 정책을 가진다.

2. 배포판마다 다른 패키지 시스템

배포판이 다르다는 것은 단순히 이름만 다른 게 아니다.

패키지 포맷의 차이

배포판 계열	패키지 포맷
Debian / Ubuntu	`.deb`
Fedora / RHEL	`.rpm`
Arch	`.pkg.tar.zst`

패키지 관리자도 다르다

# Ubuntu
apt install nginx

# Fedora
dnf install nginx

# Arch
pacman -S nginx

이 차이 때문에,
같은 프로그램이라도 배포판마다 따로 패키징해야 한다.

3. 라이브러리 버전 충돌은 왜 발생할까?

핵심 원인: 시스템 전역 라이브러리 공유

전통적인 리눅스 시스템은 라이브러리를 전역(shared) 으로 사용한다.

/usr/lib/libssl.so
/usr/lib/libcurl.so

여러 프로그램이 같은 라이브러리 파일을 함께 쓴다.

이 방식은 효율적이지만, 치명적인 문제가 있다.

라이브러리는 계속 변한다

라이브러리는 시간이 지나면서:

함수 추가/제거
함수 시그니처 변경
동작 방식 변경
ABI(Application Binary Interface) 변경

ABI가 깨지면 기존 바이너리는 실행조차 되지 않는다.

충돌이 발생하는 전형적인 상황

프로그램	요구 라이브러리
앱 A	libfoo 1.x
앱 B	libfoo 2.x

하지만 시스템에는 libfoo 한 버전만 설치 가능하다.

👉 하나를 만족시키면 다른 하나가 깨진다.

이게 바로 Dependency Hell이다.

배포판 정책이 문제를 더 키운다

Ubuntu LTS
- 안정성 우선
- 라이브러리 버전 고정
Fedora / Arch
- 최신성 우선
- 잦은 라이브러리 업데이트

👉 최신 앱은 LTS에서 안 돌고
👉 기존 앱은 최신 배포판에서 깨진다

4. Flatpak이 등장한 이유

Flatpak은 이 문제를 정면으로 포기한다.

“시스템 라이브러리를 공유하지 말자.”

Flatpak의 접근 방식

앱을 시스템과 분리
앱별로 필요한 라이브러리 포함
공통 라이브러리는 Runtime으로 묶어 공유
샌드박스 실행

결과적으로:

배포판에 상관없이 실행 가능
의존성 충돌 제거
보안성 향상

5. Flatpak의 핵심 기술, OSTree

Flatpak이 가능한 이유는 내부적으로 OSTree를 사용하기 때문이다.

OSTree란?

리눅스 파일시스템을 Git처럼 관리하는 시스템

OSTree는 패키지가 아니라,
파일시스템 전체를 커밋(commit) 단위로 관리한다.

OSTree의 핵심 특징

1. 커밋 기반 파일시스템

모든 상태는 immutable한 커밋
해시로 식별
Git commit과 유사

2. 콘텐츠 주소 기반 저장

내용이 같으면 한 번만 저장
여러 앱과 런타임이 라이브러리 공유 가능

3. 델타 업데이트

변경된 부분만 다운로드
빠른 업데이트

4. 원자적 업데이트 + 롤백

업데이트 실패 없음
이전 버전으로 즉시 복구 가능

6. Flatpak에서 OSTree는 어떻게 쓰일까?

Flatpak의 앱, 런타임, SDK는 모두 OSTree 저장소에 저장된다.

/var/lib/flatpak/repo
 ├─ objects/
 ├─ refs/
 └─ commits/

업데이트 시:

새 커밋 다운로드
완전히 준비되면
심볼릭 링크 교체

👉 실행 중 깨질 가능성이 없다.

7. Runtime을 나눴다면, 이제 어떻게 바꿀 것인가?

앞에서 본 것처럼:

runtime은 공통 라이브러리 묶음이고
ABI 안정성이 매우 중요하며
여러 앱이 동시에 의존한다

여기서 자연스럽게 질문이 생긴다.

“그럼 runtime은 어떻게 업그레이드해야 할까?”

이 질문에 대한 답이
Flatpak runtime 업그레이드 전략이다.

8. Flatpak Runtime 버전 업그레이드 전략

Runtime은 “자주 바뀌지 않는 기반”이다

Flatpak의 핵심 전제는 다음과 같다.

Runtime은 안정적인 기반이고,
앱은 그 위에서 빠르게 변화한다.

runtime을 자주 바꾸는 순간,
runtime이라는 개념 자체가 무너진다.

Runtime은 항상 명시적인 버전을 가진다

org.freedesktop.Platform//23.08
org.gnome.Platform//45

이 버전은 단순한 숫자가 아니라:

라이브러리 조합의 경계
ABI 호환성 범위
지원 수명 단위

를 의미한다.

앱은 이 runtime 버전에 강하게 고정(pinning) 된다.

왜 runtime은 자동 업그레이드되지 않을까?

runtime이 자동으로 올라간다면:

전역 라이브러리 업데이트와 다를 바 없고
runtime 위의 모든 앱이 동시에 영향을 받는다

👉 Flatpak이 해결하려던 문제가 다시 발생한다.

그래서 Flatpak은:

runtime 자동 전환 ❌
runtime 명시적 선택 ⭕

을 선택했다.

실제 runtime 업그레이드 흐름

1️⃣ 여러 runtime은 공존한다

org.gnome.Platform//44
org.gnome.Platform//45

이 둘이 동시에 설치되는 것은 정상이다.
OSTree 덕분에 중복 파일은 최소화된다.

2️⃣ 새 runtime은 “추가”된다

새 runtime이 나와도 기존 것은 교체되지 않는다.

기존 앱 → 그대로 실행
새 앱 / 업데이트된 앱 → 새 runtime 선택

runtime 업그레이드는 교체가 아니라 확장이다.

3️⃣ runtime 전환은 앱 개발자의 결정이다

runtime: org.gnome.Platform
runtime-version: "46"

이 한 줄은:

이 앱이 어떤 플랫폼 위에서
어떤 ABI 범위를 신뢰하는지

를 명확히 선언한다.

runtime 업그레이드는 앱 단위 계약이다.

EOL: 유일한 강제 조건

runtime은 영원히 유지되지 않는다.

보안 패치 종료
유지보수 종료

이 경우에만:

개발자에게 업그레이드가 요구되고
장기적으로 게시가 제한된다

👉 보안이 이유일 때만 최소한으로 강제

9. 왜 Flatpak은 데스크톱에 적합한가?

GUI 앱은 라이브러리 의존성이 복잡
배포판별 차이가 큼
사용자 시스템을 깨뜨리면 안 됨

Flatpak은:

앱을 안전하게 격리
배포판 차이를 제거
업데이트 실패 리스크 최소화

그래서 리눅스 데스크톱 앱 배포의 표준이 되었다.

정리

배포판: 커널 + 패키지 시스템 + 정책의 묶음
라이브러리 충돌: 전역 공유 구조의 필연적 문제
Flatpak: 앱 중심, 배포판 독립적 패키징
OSTree: 이를 가능하게 하는 Git-like 파일시스템 배포 기술

한 문장 요약

Flatpak은 배포판과 라이브러리 충돌이라는 리눅스의 오래된 문제를, OSTree 기반의 앱 격리와 파일시스템 버전 관리로 해결한 데스크톱 중심 배포 방식이다.

🧾 작성 참고

이 글은 ChatGPT의 도움을 받아 내용을 정리하였습니다.

Command Palette