한 줄 정의

Linux는 서버, 데스크톱, 임베디드 장비에서 쓰이는 Unix 계열 오픈 소스 운영체제 계열이야. 엄밀히 말하면 Linux는 커널이고, 우리가 설치해서 쓰는 Ubuntu, Debian, Fedora, Arch, Lubuntu 같은 것은 커널에 사용자 공간 도구와 패키지 관리자를 얹은 배포판이야.

AI 문맥에서 Linux가 자주 보이는 이유도 여기 있어. 로컬 LLM이나 GPU 서버를 볼 때 Linux는 모델 이름이 아니라 GPU 드라이버, CUDA·ROCm 백엔드, 파일 권한, 쉘, 컴파일러, Docker 같은 컨테이너 경로가 같이 얹히는 실행 바닥이야.

어떻게 작동하나

커널은 프로세스 스케줄링, 메모리, 파일 시스템, 네트워크, 장치 드라이버처럼 운영체제의 낮은 층을 맡아. kernel.org도 Linux가 true multitasking, virtual memory, shared libraries, IPv4·IPv6 네트워킹 같은 Unix 계열 기능을 갖춘다고 설명해. 앱이 직접 하드웨어를 만지는 게 아니라, 시스템 호출과 드라이버를 통해 커널을 거쳐 움직이는 구조라고 보면 돼.

배포판은 이 커널을 사람이 쓸 수 있는 운영체제로 묶어. Ubuntu 계열만 봐도 기본 Ubuntu Desktop, Kubuntu, Xubuntu, Lubuntu가 서로 다른 기본 앱과 데스크톱 환경을 얹지만, Ubuntu 문서 기준으로 패키지와 업데이트는 같은 Ubuntu archive를 공유해. 그래서 “Linux에서 된다”는 말은 보통 커널 하나보다 배포판, 패키지 저장소, 드라이버 설치 방식까지 포함해 읽어야 해.

AI 런타임에서는 어디에 걸리나

llama.cpp 같은 추론 런타임에서는 Linux 차이가 세 군데에서 먼저 걸려.

  • GPU 드라이버와 커널 모듈: /dev/nvidia* 장치가 보이는지, 컨테이너 안에서 호스트 드라이버를 제대로 물고 있는지부터 막힐 수 있어.
  • 패키지와 빌드 경로: 같은 소스라도 Linux에서 직접 컴파일한 CUDA backend와 Windows prebuilt binary는 컴파일러, 라이브러리, 스레드 설정이 달라질 수 있어.
  • 운영 경로: 네이티브 Linux, WSL 2, 원격 서버, Docker 컨테이너를 같은 “Linux 실행”으로 묶으면 장애 지점이 안 보여.

벤치마크 예시

LocalLLaMA 원문은 Windows 11 25H2와 Lubuntu 26.04를 같은 RTX 5080 16GB, i9-14900KF, 64GB DDR5 6800 MT/s 장비에서 비교했어. 설정은 llama.cpp b8929와 CUDA 13.1이었고, 2500개 넘는 토큰 프롬프트를 여러 모델에 넣었어.

그 결과는 한 줄로 뭉개기 어렵다. generation은 Lubuntu가 대체로 +3.4%에서 +8.5% 빠른 정도였지만, prompt processing은 조건에 따라 훨씬 크게 벌어졌어. fully offloaded 모델에서는 +6.8%부터 +21.7%였고, CPU/GPU hybrid 실행에서는 Qwen3.5-35B-A3B가 305 t/s 대 742 t/s, GPT-OSS-120B가 310 t/s 대 649 t/s로 보고됐어. 이건 Linux가 늘 두 배 빠르다는 뜻이 아니라, 운영체제·빌드·스케줄링·드라이버 경로가 벤치마크에 실제로 끼어든다는 뜻에 가까워.

왜 중요한가

Linux는 AI 시스템에서 기본값처럼 깔리는 경우가 많아. 클라우드 GPU 인스턴스, Docker 이미지, 모델 서빙 노드, 내부 배치 작업, 런타임 빌드 문서는 대개 Linux 기준 명령을 먼저 보여 줘. 그래서 문서에 apt, systemd, /dev/nvidia*, LD_LIBRARY_PATH, ulimit, bash 같은 말이 보이면 앱 기능보다 운영체제 층을 보고 있는 거야.

이걸 모르고 모델 이름만 보면 판단이 틀어져. 같은 가중치와 같은 양자화 파일이라도 Linux에서 직접 컴파일한 CUDA backend, Windows prebuilt binary, WSL 2, Docker 컨테이너가 서로 다른 속도와 장애를 만들 수 있어. 특히 로컬 추론에서는 VRAM만큼이나 드라이버 버전, 커널 모듈, CPU thread 설정, 파일 시스템 캐시가 체감 속도에 걸려.

기사 해석에서도 비슷해. 2차 기사들은 같은 llama.cpp 비교를 Linux가 Windows보다 빠르다는 식으로 요약했지만, 원문 Reddit 표를 보면 모델별 prompt와 generation 값이 따로 갈려. 그래서 “Linux가 빠르다”보다 “이 장비와 이 빌드에서는 어떤 단계가 빨라졌나”로 읽는 편이 맞아. 숫자 하나보다 환경표가 먼저야.

주의해서 볼 점

운영체제 전환이나 벤치마크 해석 전에 확인할 것은 네 가지야.

  • 커널과 배포판: Linux 커널과 Linux 배포판을 같은 말처럼 쓰면 안 돼. 커널은 낮은 실행층이고, 배포판은 설치 이미지, 패키지 저장소, 업데이트 정책, 기본 데스크톱까지 묶은 완성품이야. Lubuntu 결과를 Ubuntu Server, Debian, Arch, Fedora로 그대로 옮기면 바로 과해져.
  • GPU 가속: Linux 지원은 GPU 가속 보장이 아니야. NVIDIA라면 드라이버와 CUDA 조합을, AMD라면 ROCm이나 HIP 지원 범위를, 컨테이너라면 호스트 드라이버와 이미지 안 라이브러리 버전을 따로 맞춰야 해. nvidia-smi가 된다고 llama.cpp의 CUDA build가 자동으로 잘 돈다는 뜻은 아니야.
  • 벤치마크 단계: prompt processing과 generation은 병목이 다르고, CPU/GPU hybrid 실행은 스레드 스케줄링과 메모리 이동의 영향을 더 크게 받을 수 있어. Reddit 원문도 이 둘을 나눠 적었기 때문에 유용한 거지, 운영체제 이름 하나로 결론을 내렸기 때문에 유용한 게 아니야.
  • 실행 위치: Windows와 비교할 때도 네이티브 Windows, WSL 2, 듀얼부트 Linux, 원격 Linux 서버를 섞으면 안 돼. 화면은 Windows여도 실제 빌드와 실행이 WSL 안에서 끝나면 사실상 Linux 경로를 쓰는 거야. 설치 문서에서 어느 쉘과 어느 파일 시스템을 전제하는지 먼저 확인하는 편이 덜 헤맨다.