Toolpak 소개 — 이미지 기반 Linux의 개발 도구 배포 구상

AI 요약

iOS, Android, macOS, ChromeOS와 여러 데스크톱 Linux 배포판은 이미지 기반 OS로 옮겨가고 있습니다. 하지만 개발 도구를 설치하고 쓰는 방식은 아직 이 구조에 잘 맞지 않습니다. 기존 배포판에서는 NetworkManager 같은 시스템 구성요소를 개발할 때 필요한 라이브러리나 컴파일러를 호스트에 설치하면 됩니다. 이미지 기반 OS에서는 호스트 파일시스템을 수정하는 방식이 시스템 업데이트를 깨뜨릴 수 있고, 컨테이너에 도구를 넣으면 시스템 디버깅이나 저수준 작업에서 제약이 생깁니다.

기존 접근법의 빈틈

Fedora Silverblue의 rpm-ostree 패키지 오버레이는 호스트를 확장하지만, 패키지 충돌로 시스템이 망가지거나 업데이트가 중단될 위험이 있습니다. 글쓴이는 Silverblue의 다음 세대가 bootc 기반으로 가면서 이 방식을 피할 예정이라고 설명합니다. Android, iOS, Windows처럼 개발 도구를 한데 묶은 오버레이도 있지만, GNOME OS 개발자 확장처럼 OS 자체를 빌드하는 도구 목록에 그치면 커널 개발 등에 필요한 다양한 도구까지 제공하기 어렵습니다.

Toolbox와 distrobox는 전통적인 패키지 설치 경험을 컨테이너 안에 옮깁니다. 하지만 컨테이너 환경을 예상하지 않고 만들어진 도구는 시스템 구성요소를 개발하거나 디버깅할 때 한계에 부딪히고, 컨테이너 경계를 우회해야 할 수 있습니다. Homebrew는 호스트와 별개로 도구 체인을 제공하지만, PATH 우선순위에 따라 도구가 시스템 바이너리를 덮어쓸 수 있습니다. 글에서는 Homebrew에서 설치한 QEMU가 시스템이 사용하는 GLib와 충돌하는 사례를 듭니다. Flatpak은 데스크톱 앱에 맞춰 설계돼 포털과 샌드박스 제약이 있고, 디버깅 도구와 일부 IDE처럼 완전히 작동시키기 어려운 앱도 있습니다.

글쓴이는 프로젝트별 빌드 환경과 개발자가 쓰는 유틸리티를 구분합니다. Buildstream, flatpak-builder, Bazel, Nix 같은 도구로 프로젝트 빌드 환경을 재현하는 문제는 별도로 다루고, Toolpak은 strace, ripgrep, QEMU처럼 호스트 전체에 접근해야 하는 개발 유틸리티를 독립 배포하는 데 초점을 둡니다.

Toolpak의 이미지와 실행 방식

Toolpak은 Discoverable Disk Images(UAPI.3)를 이미지 형식으로 삼는 구상입니다. Verity로 런타임 이미지의 무결성을 확인하고, 빌드 도구가 지원하는 범위에서 재현 가능한 빌드를 지향합니다. 실행 시에는 마운트 네임스페이스를 만들고 Flatpak의 /usr와 /app 분리를 가져옵니다. 공유 런타임 이미지가 /usr를 제공하고, 각 Toolpak 이미지가 주로 담긴 도구 파일을 /app에 둡니다.

도구는 호스트의 다른 자원에 제한 없이 접근합니다. 컨테이너에서 실행해도 도구를 다시 포팅하지 않아도 되게 하려는 설계입니다. 사용자의 PATH 앞에 Toolpak 실행 파일을 배치해 같은 이름의 시스템 도구보다 먼저 찾게 하지만, 실행 파일은 이미지 안의 실제 바이너리를 마운트 네임스페이스에서 실행하는 시작점 역할을 합니다. 글쓴이는 이 방식으로 링커나 공유 라이브러리를 호스트에서 바꾸지 않고 시스템 바이너리를 대체하려 합니다. 다만 GNU tar를 BSD tar로 바꾸는 식의 호환되지 않는 교체 등 충돌을 막을 추가 장치는 더 살펴봐야 한다고 덧붙입니다.

각 도구는 다른 Toolpak에 의존하지 않고 필요한 라이브러리를 자체 이미지에 포함합니다. 전통적인 배포판의 패키지 의존성 해소와 패키지 관리 복잡성을 피하고, 테스트한 환경에서 실행되도록 하려는 선택입니다. 사용자는 앱 스토어에서 도구를 찾아 설치하는 경험을 얻게 됩니다. 도구를 배포하는 개발자가 직접 패키지를 제공하는 모델을 Flathub와 비슷하게 구상합니다. 도구가 시스템 전체에 접근하는 만큼 이미지는 신뢰하는 키로 서명하고, 실행 때 Verity 검사를 거쳐야 합니다. 대표 앱 스토어에 등록하기 전 검토도 필요합니다. Flatpak으로 온전하게 패키징할 수 있는 앱은 Toolpak 대상에서 제외하되, Flatpak에서 기능이 제한되는 IDE 같은 예외는 고려합니다.

빌드 도구에는 의존성 빌드 조율, 콘텐츠 주소 지정 저장소(Content Addressable Storage)를 이용한 캐시, 기본 재현 빌드와 결과 검증, 로컬 개발과 최종 이미지 구성 지원, 라이선스 및 SBOM 처리가 필요합니다. 글쓴이는 Buildstream 플러그인이나 래퍼가 이 조건을 충족할 수 있다고 봅니다. 수년간 논의한 주제이며, Prototypefund 프로젝트의 일부로 프로토타입 작업을 시작했고 몇 주 안에 더 공유할 예정이라고 밝혔습니다.

Reddit 반응

• @u/Morphon — Nix를 다시 만드는 12번째 편이군요. 😉
  • @u/ucsilahsor — Nix는 링커를 명시적으로 수정하므로 이 논의와는 완전히 관련이 없습니다. Toolpak은 그 접근을 피하려고 합니다. Nix가 가장 큰 저장소를 내세우는 이유 가운데 하나는 Python, Ruby, JS 같은 개발 라이브러리를 제공하려고 바이너리를 패치하기 때문입니다. 그 결과 패키지 수가 늘어납니다.
  • @u/Resource_account — ‘관련이 없다’는 말은 지나칩니다. 사용자에게 비슷한 문제를 풀지만 작동 방식은 다르니, 그 차이를 비교하는 게 흥미롭습니다. Nixpkgs 패키지 수에 어떤 단서를 붙이든, Nix에는 이미 잘 관리되는 희귀 도구와 라이브러리 생태계가 있습니다. Toolpak이 이 용도에 더 깔끔한 모델을 만들더라도, 그 규모의 카탈로그와 기여자 기반을 만드는 일은 런타임 설계보다 어렵습니다.
• @u/kolorcuk — 저는 어떤 시스템에서도 Nix 단일 사용자 설치를 이렇게 씁니다. bwrap으로 ~/.nix를 /nix에 마운트하고 사용자 권한으로 Nix를 설치한 뒤, bwrap 안에서 실행합니다. 이 방식과 Toolpak은 정확히 무엇이 다를까요? 제가 이해한 바로는 Toolpak은 uvx나 npx처럼 바이너리 중심입니다. 제 C 프로젝트에서는 호스트 의존성도 분리하기 시작했습니다. 도구라면 정적으로 컴파일하고 빌드 때 의존성을 복제합니다. 라이브러리는 의존성을 복제하거나 사용자가 이미 복제한 경로를 지정합니다.
• @u/sooka_bazooka — 어떻게 작동하는지는 잘 모르겠지만 toolpak install intellij/emacs만 하면 다 잘된다면 정말 좋겠습니다.
  • @u/FlukyS — 제가 제대로 읽었다면, 완전한 데스크톱 앱보다는 toolpak install ruff나 toolpak install cargo처럼 각자 별도 환경에서 실행하는 공용 도구를 설치하는 방식에 가깝습니다.
  • @u/sooka_bazooka — 그렇다면 필요 없겠네요.
• @u/daddyd — 이 아이디어로 새 도구를 만들지 말고 Flatpak 차세대를 개발하면 안 되나요?
  • @u/Wonderful-Citron-678 — 글에서 이유를 설명했으면 좋았겠네요. Flatpak은 샌드박스 앱을 위한 것이고, 이 제안은 정반대로 완전히 샌드박스 밖에서 실행하는 도구를 위한 것입니다. 구현 방식이 겹치지 않습니다.
  • @u/novafunc — Flatpak 다음 버전에는 샌드박스 없는 모드가 생길 예정입니다. 제가 이해한 바로는 현재처럼 모든 앱을 샌드박스에 넣고 구멍을 내는 대신, 앱을 완전히 샌드박스 처리하거나 아예 샌드박스 없이 실행하는 방식입니다. 후자는 더 엄격한 검토와 승인 대상이 됩니다.
  • @u/kaestralblades — 정말 나쁜 모델이며, 제가 Flatpak에 바라던 방식이 아닙니다. Flatpak을 그만 쓸 정도로 싫습니다. 독점 소프트웨어를 막는 보호 장치는 중요합니다. 문서 폴더나 그래픽 카드, 소켓에 접근해야 한다고 해서 앱이 시스템 전체에 접근하게 하고 싶지 않습니다.
  • @u/Die4Ever — 맞습니다. Android 앱 권한처럼 세분화된 Flatpak 권한이 좋습니다.
  • @u/victorian-ice-cream — 참고로 Flatpak Next는 아직 계획 단계가 깊고, 결정된 것은 없습니다.
  • @u/Sirius707 — xkcd 927입니다.
• @u/ABotelho23 — 도구를 사용자 PATH 앞에 넣어 시스템 바이너리를 덮어쓰게 하되 시스템은 망가지지 않게 하고, 그 바이너리가 마운트 네임스페이스를 설정한 다음 이미지 속 실제 바이너리를 실행한다는 대목은… 뭐라고요?
  • @u/Economy_Blueberry_25 — 기본적으로 Flatpak과 비슷하지만 더 밀접하게 결합된 이미지 기반 방식이며, 특별한 경우에만 쓸모가 있을 것 같습니다. 글에서도 Flatpak으로 패키징할 수 있는 앱은 제외한다고 했습니다. Flatpak에서 기능이 제한되는 IDE 같은 앱만 예외입니다.
  • @u/ABotelho23 — 충돌이 없을 거라고 너무 낙관하는 것 같습니다.
• @u/Rimtariro — 기본적으로 Snap보다 못한 버전 같네요. 글에서 Snap을 언급하지 않은 게 재미있습니다.
  • @u/FlukyS — 왜 Snap보다 못하다고 보시나요? 둘이 어떻게 연결되는지 모르겠습니다. Snap은 범용이고 명령줄 도구, 데몬, GUI도 다룰 수 있습니다. Flatpak은 현재 GUI를 겨냥합니다. Toolpak은 Linux 전반에서 uv의 tool 명령처럼 도구를 설치하는 방식에 더 가깝습니다. Toolpak과 Flatpak을 합쳐도 Snap의 모든 기능을 직접 대체하지는 않습니다.
  • @u/whiprush — Python 사용자가 쓸 도구를 고른다는 점을 놓치셨네요. Linux 배포판이 정하는 게 아닙니다.
  • @u/FlukyS — 저도 Python을 쓰지만 배포판에 포함된 Python과 uv를 사용합니다. 배포판이 달라도 도구 버전 차이로 린터 결과가 달라지지 않도록, 팀에서 개발 환경을 한 묶음으로 공유하고 싶습니다. Python과 Node.js, 또는 Python과 Rust를 함께 쓰는 곳도 있습니다. 언어가 달라도 같은 설치 방식을 쓰면 편합니다.
  • @u/whiprush — 이미 지난 10년간 해결된 문제입니다. Ubuntu, Python, uv, mise, Nix 등으로 Python 버전을 여러 개 쓸 수 있습니다. Python 개발자는 Python 도구를, Rust 개발자는 Rust 도구를 고릅니다. Linux 패키징을 중요하게 보는 사람 말고는 모두를 위한 패키지 관리자 하나를 찾지 않습니다.
• @u/duartec3000 — 이미 해법이 있습니다. 권한이 있는 rootful Podman 컨테이너를 쓰면 됩니다. SysExt도 있습니다. Toolpak 같은 도구 모음을 새로 만드는 대신 기존 프로젝트에 기여하면 안 되나요? 글쓴이의 근거는 개인 의견에 기댄 약한 주장 같습니다.
  • @u/victorian-ice-cream — Toolbox, distrobox, SysExt를 써보셨나요? 전통적인 패키지 관리자와 비교할 수 있는 방식은 아닙니다. 오래전부터 있었지만 개발자들은 충분하지 않다고 말해왔습니다.
  • @u/Ghost_x_Knight — 설정만 잘하면 전통적인 패키지 관리자처럼 쓸 수 있습니다. Vanilla OS는 Distrobox 기반 패키지 관리자를 제공하고, KDE Linux는 Distrobox 후속 도구 Kapsule을 계획 중입니다. Kapsule을 터미널에 통합하고 기본 활성화하면 사용자는 컨테이너를 쓴다는 사실을 알아차리지 못할 수도 있습니다.
  • @u/gmes78 — 컨테이너는 추가 작업을 요구합니다. 도구를 쓰려면 컨테이너에 들어가거나 호스트로 전달하는 래퍼 스크립트를 만들어야 하는데, 항상 안정적으로 작동하지는 않습니다.
• @u/cidra_ — 좋아 보입니다. 특히 에이전트 코딩이 늘어나는 시기라 선택적 샌드박싱도 있으면 좋겠습니다. 가정한 Toolpak 위에 bwrap을 겹쳐 쓸 수 있을까요? 구체적인 결과물을 기다립니다. 불변 배포판에서 제가 아쉬워하는 유일한 점입니다.
• @u/vazark — 도구마다 의존성을 묶어야 한다면 AppImage를 쓰면 됩니다. AppImage와 비슷하고 공용 런타임을 추가하는 것처럼 들립니다. 이미지 기반 OS는 사용자 환경의 재현성에는 좋지만 개발 환경에는 적합하지 않습니다. 호스트를 제한 없이 쓰면서 안전을 지키려면 VM이나 Docker, Podman을 쓰면 됩니다. IDE가 Flatpak에서 작동하지 않는 게 문제라면 Flatpak을 고쳐야 합니다.

원문: GNOME Blog / 번역·요약: Trawling