Show HN: Linux용 WSL, NSL

AI 요약

NSL(NSpawn Subsystem for Linux)은 Linux 데스크톱에서 WSL과 비슷한 개발 환경을 제공하는 도구입니다. Debian, Fedora 등 배포판을 별도 머신으로 실행하고, 개발 도구와 서비스를 호스트 설치 환경과 분리합니다. 머신은 세션이 끝나도 패키지와 파일을 유지하며, 필요할 때 시작합니다.

실행 구조와 호스트 연동

NSL은 공유 VM 하나를 실행하고, 그 안에서 각 머신을 systemd-nspawn 컨테이너로 구동합니다. 프로젝트 디렉터리에서 nsl을 실행하면 기본 머신의 셸이 열리고, nsl run으로 명령 하나만 실행할 수도 있습니다. 명령의 종료 상태는 호스트로 돌아옵니다.

호스트의 $HOME, /run/media/USER, /mnt는 머신 안의 /mnt/host에서 접근합니다. 머신은 호스트 사용자와 같은 사용자명, UID, GID를 쓰므로 호스트 파일에 만든 파일도 해당 사용자 소유로 남습니다. 머신 안에서는 비밀번호 없이 sudo를 쓸 수 있습니다. 개발 서버 포트는 호스트의 127.0.0.1로 전달하며, Waypipe를 이용하면 Wayland 앱도 호스트 데스크톱에 띄울 수 있습니다.

사용 가능한 배포판은 Debian, Ubuntu, Fedora, CentOS Stream, Arch, openSUSE Tumbleweed, openSUSE Leap입니다. 이미지는 매주 다시 빌드하며, 사용 전에 Frostyard의 서명된 게시 워크플로에서 나온 이미지인지 확인합니다. 신뢰하지 않는 소프트웨어를 실행할 때는 --isolated를 지정해 별도 VM을 사용합니다. 이 모드에서는 호스트 파일과 데스크톱, 호스트 작업에 접근할 수 없습니다.

Distrobox와 다른 점

Hacker News 댓글에서는 Distrobox와의 차이가 가장 많이 논의됐습니다. Distrobox는 기본 설정에서 호스트의 $HOME을 컨테이너 안의 $HOME에 연결합니다. NSL은 호스트 파일을 /mnt/host 아래에서 접근하게 하므로, 머신의 기본 경로 설정이나 dotfiles를 바꿔도 호스트 설정에 영향을 주지 않는다는 설명이 나왔습니다. 다만 Distrobox에도 별도 $HOME을 지정할 수 있다는 반론이 있었습니다.

실행 구조도 다릅니다. NSL은 systemd-vmspawn으로 작은 VM 하나를 띄운 뒤, 그 안에서 systemd-nspawn으로 머신별 컨테이너를 실행합니다. Distrobox는 Podman이나 Docker를 사용합니다. 프로젝트 작성자는 NSL을 기존 컨테이너 도구의 대체재라기보다, WSL2처럼 머신이 지속되고 호스트와 제한적으로 연결되는 사용 경험을 Linux에 가져온 도구로 설명했습니다. 댓글에서는 toolbx, mkosi, Nix 컨테이너 등 이미 있는 선택지와 비교해 새 도구가 필요한 이유를 묻기도 했습니다.

격리와 미완성 상태

일반 모드에서도 VM과 컨테이너를 함께 쓰지만, 댓글에서는 호스트 파일과 데스크톱 연동이 실제 보안 경계에 어떤 영향을 주는지 질문했습니다. 컨테이너 탈출과 VM 탈출의 위험 차이, 격리 모드가 기본값이 아닌 점도 논쟁거리였습니다. 게시글은 --isolated가 호스트 파일·데스크톱 접근을 차단한다고 설명하지만, 댓글에서는 어떤 위협 모델을 전제로 삼는지와 성능 비용을 측정했는지 질문이 이어졌습니다.

NSL은 아직 정식 안정 버전이 없습니다. v0.4.0이 현재 설계의 첫 릴리스이며, v0.3.0 이전 버전은 폐기된 프로토타입입니다. 테스트한 호스트 환경은 x86-64 Snow Linux 13, systemd 261.2, QEMU 10.0.13, virtiofsd 1.13.2, GNOME Wayland입니다.

Hacker News 반응

• @thayne — Distrobox와 비교하면 어떤가요?
• @bketelsen — Distrobox는 기본적으로 컨테이너 안의 $HOME에 호스트의 $HOME을 마운트합니다. WSL과 NSL은 그렇게 하지 않는데, 저는 그쪽을 선호합니다. 기본 경로를 바꾸거나 dotfiles를 수정하는 도구를 설치해도 호스트에 영향을 주지 않습니다. 또 다른 차이는 Distrobox가 Podman이나 Docker를 쓰고, NSL은 systemd-nspawn 컨테이너를 실행하는 VM을 쓴다는 점입니다.
• @jm4 — 저도 같은 점이 궁금했습니다. Distrobox는 기본적으로 $HOME을 마운트하지만, 별도 $HOME을 설정하기도 쉽습니다. systemd-nspawn 컨테이너는 Podman이나 Docker와 비교해 어떤 장점이 있나요? 저는 systemd-nspawn은 잘 모르지만 Distrobox와 Podman은 자주 씁니다.
• @graemep — Linux를 일상적으로 쓰는 사람에게 가장 유용해 보입니다. WSL과 비슷하다고만 하지 말고 기존 Linux 컨테이너와 비교해 무엇을 제공하는지 설명해 주세요. WSL은 컨테이너가 아니라 VM이라고 생각했는데요. 몇 달마다 호스트를 다시 설치하게 만드는 개발 의존성 문제도 더 설명이 필요합니다.
• @bketelsen — WSL2는 네트워킹, 파일 공유, 인스턴스별 영구 저장소를 호스트와 연결하는 공유 VM을 씁니다. NSL도 같은 모델을 Linux 네이티브 기술로 구현합니다. 개발자는 무언가를 컴파일하려고 libWhatever3.2-dev를 설치하고, 다음에 Chrome을 실행할 때 미묘하게 시스템이 망가진 걸 뒤늦게 알아차리곤 합니다. devcontainer, Docker, Incus, 별도 VM, 원격 VM 등 해결 방법은 많지만, 저는 WSL2의 사용 경험을 원했습니다.
• @0x457 — VM과 systemd-nspawn을 함께 쓰는 이유가 궁금합니다. WSL2는 Linux 커널이 필요해서 VM을 쓰는 것으로 아는데, 이미 Linux에서 실행한다면 systemd-nspawn만 쓰면 되지 않나요?
• @bketelsen — 그렇게 쓰고 싶다면 nspawn.org가 잘 맞습니다.
• @naman_307 — VM 계층은 주로 호스트를 깨끗하게 유지하려는 목적입니까, 아니면 신뢰하지 않는 의존성이나 에이전트가 작성한 코드를 실행할 때 실제 보안 경계로 취급합니까?
• @ocean2 — 컨테이너 안에서 코드를 컴파일할 때 호스트에서 직접 컴파일하는 것과 비교해 성능 저하를 측정했나요?
• @varispeed — 프로젝트는 멋지지만 사람이 쓴 글을 써 주세요. 웹사이트의 ‘Claudism’은 견디기 힘듭니다.

원문: Hacker News / 번역·요약: Trawling