2021년 4월 페도라 34, 그리고 2022년 10월 우분투 22.10을 기준으로 리눅스 데스크톱의 기본 오디오 서버가 조용히 교체됐어요. 거의 20년 가까이 리눅스 사운드를 책임지던 PulseAudio 자리를, PipeWire라는 이름조차 낯선 프로젝트가 가져간 거예요. 사용자 대부분은 업데이트 한 번 했을 뿐인데 스피커나 마이크가 갑자기 바뀐 것도 아니었죠. 그렇다면 리눅스 오디오 서버는 왜, 그리고 어떻게 PulseAudio에서 PipeWire로 넘어가게 됐을까요?
PulseAudio는 무엇이고 왜 오랫동안 표준이었나
PulseAudio는 2004년 등장해 애플리케이션과 사운드카드 사이를 중개하며 볼륨 개별 제어, 네트워크 오디오 전송, 블루투스 연동 같은 기능을 제공한 사운드 서버예요. 페도라 8과 우분투 8.04가 2008년 기준으로 나란히 이 프로젝트를 기본값으로 채택하면서, PulseAudio는 사실상 리눅스 데스크톱 오디오의 표준으로 자리 잡았어요. 초창기에는 잦은 끊김과 지연으로 악명이 높았지만, 시간이 지나며 안정성이 개선됐고 결국 대부분의 배포판이 별다른 고민 없이 채택하는 기본 선택지가 됐어요.
문제는 PulseAudio가 애초에 일반 데스크톱용 오디오 믹싱을 목표로 설계됐다는 점이에요. 녹음 스튜디오나 방송처럼 초저지연이 필요한 전문 오디오 작업은 처음부터 염두에 두지 않았고, 그래서 그런 용도로는 별도로 JACK이라는 완전히 다른 오디오 서버를 병행해서 써야 했어요.
PipeWire란 무엇이고 왜 등장했나
PipeWire는 GStreamer 개발자로 잘 알려진 Wim Taymans가 2015년 ‘Pinos’라는 이름으로 시작해 2017년 지금의 이름으로 바뀐 멀티미디어 프레임워크예요. 처음 목표는 오디오가 아니라 카메라나 화면 캡처 같은 비디오 스트림을 샌드박스 환경에서 안전하게 다루는 것이었는데, 이후 오디오까지 처리 범위를 넓히면서 지금의 형태가 됐어요. PipeWire의 핵심은 PulseAudio 호환 레이어와 JACK 호환 레이어를 동시에 제공해 하나의 서버로 두 세계를 통합했다는 점이에요. 그 결과 기존 PulseAudio용 앱도, JACK 전용 프로 오디오 앱도 별도 수정 없이 그대로 PipeWire 위에서 돌아가게 됐어요.
왜 주요 배포판이 기본값을 PipeWire로 바꿨나
주요 배포판이 PipeWire로 갈아탄 이유는 레이턴시와 전문 오디오 기능을 하나의 서버로 통합할 수 있었기 때문이에요. 페도라 34, 우분투 22.10이 각각 기준이 되어 기본값 전환을 마쳤고, Fedora 워크스테이션처럼 최신 기술을 빠르게 받아들이는 배포판이 먼저 움직였어요. PipeWire는 그래프 기반 라우팅 구조 덕분에 JACK급으로 낮은 레이턴시를 낼 수 있어서, 방송이나 음악 작업을 하는 사용자는 더는 JACK 서버를 따로 설치하고 PulseAudio와 충돌 없이 병행 실행하는 번거로운 설정을 거치지 않아도 돼요. 일반 사용자 입장에서도 오디오 라우팅이 하나의 그래프 안에서 통합 관리되니 앱 간 오디오 전달이 더 매끄러워졌어요.
화면 공유가 편해진 것도 PipeWire 덕분이다
PipeWire는 오디오뿐 아니라 화면 공유용 비디오 스트림까지 같은 방식으로 처리하는 프레임워크예요. 특히 Wayland 디스플레이 서버에서는 보안 모델상 앱이 화면을 마음대로 캡처할 수 없기 때문에, xdg-desktop-portal이라는 중개자를 거쳐 사용자 허가를 받은 뒤 PipeWire가 비디오 버퍼를 스트리밍해주는 구조가 필요했어요. X11에서는 앱이 별다른 권한 요청 없이 화면을 그냥 읽어올 수 있었지만, Wayland 환경에서는 이 방식이 막혀 있었던 거죠. OBS Studio 같은 방송 프로그램이 Wayland 세션에서도 창 공유나 화면 공유를 제대로 지원하게 된 배경에는 이 PipeWire-포털 조합이 있어요.
실사용자가 체감하는 차이는 사실 크지 않다
실사용자 대부분은 PulseAudio에서 PipeWire로 바뀌었다는 사실 자체를 거의 체감하지 못해요. pipewire-pulse라는 호환 레이어가 pactl 같은 기존 명령어와 볼륨 조절 UI를 그대로 지원하기 때문에, GNOME이나 KDE 어떤 데스크톱 환경을 쓰든 겉으로 보이는 소리 설정 화면은 예전과 똑같아요. 다만 체감되는 부분이 아예 없는 건 아니에요. 블루투스 헤드셋을 쓰는 사용자라면 LDAC나 aptX 같은 고음질 코덱 지원이 강화되면서 음질 저하나 연결 끊김이 줄었다는 후기를 자주 볼 수 있고, 여러 앱에서 동시에 소리를 재생해도 지연이나 딱딱거림이 줄었다는 평가도 많아요.
그렇다고 전환이 완전히 매끄럽지만은 않았다
PipeWire 전환이 처음부터 아무 문제 없이 진행된 건 아니에요. 초기 버전에서는 특정 블루투스 기기와의 호환성 문제나 일부 프로 오디오 소프트웨어와의 미묘한 지연 차이가 보고되기도 했고, 아주 예민한 초저지연 작업을 하는 일부 사용자는 여전히 순정 JACK 서버를 고집하기도 해요. 하지만 이런 사례는 시간이 지나며 대부분 패치로 해결됐고, 지금은 일반 사용자든 방송·녹음 사용자든 PipeWire 하나로 예전보다 더 적은 설정으로 더 넓은 용도를 커버할 수 있게 됐어요. 결국 리눅스 오디오 서버가 바뀐 이유는 거창한 게 아니라, 하나의 서버로 일반 데스크톱과 전문 오디오, 화면 공유까지 다 처리할 수 있게 됐기 때문이라는 말로 정리할 수 있어요.
자주 묻는 질문
Q1. PulseAudio에서 PipeWire로 바뀌면 기존 설정이 다 날아가나요?
아니요, pipewire-pulse라는 호환 레이어가 pactl 같은 기존 명령어와 앱을 그대로 지원해서 대부분 사용자는 전환 사실조차 체감하지 못해요.
Q2. 내가 쓰는 배포판이 PulseAudio인지 PipeWire인지 어떻게 확인하나요?
터미널에서 pactl info 명령을 실행해 출력되는 Server Name 항목을 확인하면 바로 알 수 있어요.
Q3. PipeWire로 바꾸면 게임할 때 오디오 딜레이가 줄어드나요?
네, PipeWire는 JACK 수준의 낮은 레이턴시 그래프 구조를 쓰기 때문에 방송이나 녹음처럼 실시간성이 중요한 작업에서 체감 차이가 커요. 다만 일반 게임에서는 차이가 크게 느껴지지 않을 수 있어요.
Q4. JACK을 쓰던 사람도 굳이 PipeWire로 넘어가야 하나요?
꼭 그럴 필요는 없어요. PipeWire가 JACK API를 호환 구현하기 때문에 기존 JACK 전용 앱도 별도 JACK 서버 없이 그대로 동작해요.
Q5. 블루투스 이어폰 음질 문제도 PipeWire가 해결해주나요?
네, PipeWire는 LDAC·aptX 같은 고음질 코덱 지원을 강화해서 PulseAudio 시절보다 블루투스 오디오 끊김과 음질 저하가 줄었다고 보고돼요.
Q6. 아치리눅스 같은 배포판도 PipeWire가 기본인가요?
배포판마다 달라요. 아치리눅스는 사용자가 직접 pipewire 패키지를 설치하고 활성화해야 하는 반면, 최신 페도라와 우분투는 설치 시점부터 기본으로 켜져 있어요.
Wayland vs X11: 리눅스 디스플레이 서버 뭘 써야 할까
40년 가까이 리눅스 데스크톱을 떠받쳐온 X11과 그 후계자로 등장한 Wayland의 구조적 차이, 그리고 지금 어떤 상황에서 무엇을 골라야 하는지를 정리합니다.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.