마이크로소프트가 안 하면, 커뮤니티가 한다
"리눅스 지원은 계획에 없습니다."
2020년 .NET MAUI가 처음 발표됐을 때 마이크로소프트의 공식 입장이었다. Windows, macOS, iOS, Android, 네 개 플랫폼을 하나의 코드베이스로 아우르겠다는 야심 찬 프로젝트에서 리눅스 데스크톱만 빠졌다. 그로부터 6년, 커뮤니티가 직접 나서 그 빈자리를 채우고 있다. Hacker News에 공유된 논의를 보면, .NET MAUI 리눅스 지원 프로젝트가 실질적인 진전을 이루며 개발자들 사이에서 뜨거운 반응을 얻는 중이다.
크로스플랫폼 UI 프레임워크에서 리눅스가 빠진다는 건, '크로스플랫폼'이라는 이름값을 못 하는 것이었다. 이 움직임이 왜 중요한지, 그리고 .NET 생태계와 리눅스 데스크톱 양쪽에 어떤 파장을 일으킬지 짚어본다.
"네 개 플랫폼" 슬로건에서 리눅스가 빠진 이유
배경부터 정리하자. .NET MAUI(Multi-platform App UI)는 Xamarin.Forms의 후속 프레임워크다. 마이크로소프트가 2022년 정식 출시하면서 내건 슬로건은 "하나의 프로젝트, 하나의 코드베이스, 네 개 플랫폼". 여기서 네 개란 Windows, macOS, iOS, Android다.
리눅스가 빠진 이유는 비즈니스 논리로 설명된다. 마이크로소프트 입장에서 리눅스 데스크톱 사용자 비율은 전체 PC 시장의 3~4% 수준. 엔터프라이즈 고객이 리눅스 데스크톱 앱을 요구하는 경우도 드물다. 투자 대비 수익이 나오지 않는 플랫폼에 엔지니어링 리소스를 쏟을 이유가 없었던 셈이다.
그런데 서버 사이드에서는 이야기가 완전히 다르다. .NET은 이미 리눅스 위 서버 프레임워크로 확고히 자리 잡았다. ASP.NET Core 워크로드 상당수가 리눅스 컨테이너에서 구동된다. AWS와 Azure의 리눅스 인스턴스에서 .NET 앱을 운영하는 건 일상이다. 서버는 되는데 데스크톱 UI만 안 되는 기묘한 비대칭이 수년간 이어져 왔다.
GTK 백엔드를 올리다: 커뮤니티의 구현 전략
Hacker News 스레드에서 확인할 수 있듯, 리눅스 지원은 오픈소스 커뮤니티가 직접 구현에 나선 결과물이다. 핵심은 GTK 기반 렌더링 백엔드를 MAUI 아키텍처 위에 올리는 작업이다. MAUI 자체가 핸들러 패턴으로 설계돼 있어 플랫폼별 네이티브 렌더러를 교체할 수 있는 구조를 갖추고 있다. 이 설계 덕분에 커뮤니티가 리눅스용 백엔드를 끼워 넣는 게 이론적으로 가능했고, 실제로 그 작업이 진행 중이다.
비슷한 시도가 아예 없었던 건 아니다. Avalonia UI가 대표적이다. .NET 기반 크로스플랫폼 UI 프레임워크로 리눅스를 처음부터 지원했다. Uno Platform도 리눅스 데스크톱을 타겟으로 잡았다. 하지만 이들에겐 공통된 한계가 있었다. 마이크로소프트 공식 프레임워크가 아니라는 점. 기업 환경에서 기술 스택을 선택할 때 "마이크로소프트 공식"이라는 딱지가 얼마나 큰 무게를 갖는지, .NET 개발자라면 체감하고 있을 것이다.
MAUI 자체에 리눅스 지원이 붙는다면 이야기가 달라진다. 별도 프레임워크를 배울 필요 없이 기존 MAUI 프로젝트에 리눅스 타겟만 추가하면 된다. 빌드 파이프라인도, NuGet 패키지 의존성도 그대로 유지된다.
리눅스 데스크톱 앱 생태계, 얼마나 바뀔까
리눅스 데스크톱 앱 개발은 오랫동안 파편화 문제를 안고 있었다. GTK냐 Qt냐, Python이냐 C++이냐, Flatpak이냐 Snap이냐. 선택지가 많다는 건 곧 표준이 없다는 뜻이기도 하다.
.NET MAUI의 리눅스 진출이 이 판을 얼마나 바꿀 수 있을까. 낙관만 하기는 어렵다. 리눅스 데스크톱 사용자 규모 자체가 작고, 기업용 데스크톱 앱 수요도 여전히 Windows 중심이다. MAUI가 리눅스를 지원한다고 해서 갑자기 리눅스 데스크톱 앱이 쏟아질 가능성은 낮다.
하지만 몇 가지 의미 있는 변화는 기대할 수 있다. 첫째, 이미 MAUI로 Windows/macOS 앱을 만들고 있는 팀이 리눅스 빌드를 추가하는 한계비용이 극적으로 낮아진다. 둘째, 내부 도구나 키오스크 앱처럼 특정 환경에 배포되는 소프트웨어에서 리눅스 옵션이 열린다. 셋째, 교육기관이나 공공부문처럼 오픈소스 OS를 선호하는 영역에서 .NET 앱의 접근성이 높아진다.
Hacker News 토론에서도 이 지점이 핵심 쟁점이었다. 일부 개발자는 "진작 있었어야 할 지원"이라며 환영했고, 다른 쪽에서는 "Avalonia가 이미 잘 하고 있는데 굳이 MAUI에서 해야 하나"라는 시각도 나왔다. 기존에 Avalonia로 리눅스 앱을 만들어 온 개발자 입장에서는 경쟁 구도가 달라지는 셈이니, 반가움과 경계심이 뒤섞일 수밖에 없다.
마이크로소프트의 오픈소스 전략과 맞물리는 타이밍
마이크로소프트의 리눅스에 대한 태도 변화는 이제 새삼스러운 뉴스가 아니다. "리눅스는 암(cancer)"이라던 스티브 발머 시절을 지나, 사티아 나델라 체제에서 "마이크로소프트는 리눅스를 사랑한다"고 선언했다. WSL(Windows Subsystem for Linux)을 내놓았고, VS Code가 리눅스에서 돌아가며, GitHub Actions 러너 대부분이 Ubuntu다.
서버 인프라에서의 리눅스 포용은 Azure 비즈니스와 직결되기에 적극적이었다. 반면 데스크톱 UI 프레임워크의 리눅스 지원은 Windows 생태계와 정면 충돌할 수 있어 마이크로소프트가 소극적이었다는 해석도 가능하다. Windows의 핵심 경쟁력 중 하나가 풍부한 데스크톱 앱 생태계인데, 그 앱들이 리눅스에서도 돌아가면 Windows를 써야 할 이유가 하나 줄어든다.
커뮤니티 주도라는 점이 마이크로소프트에게는 가장 편한 포지션이다. 직접 엔지니어링 리소스를 투입하지 않으면서도 .NET 생태계의 커버리지는 넓어진다. 문제가 생기면 "공식 지원 범위가 아닙니다"라고 선을 그을 수 있고, 잘 되면 나중에 공식 지원으로 끌어올리면 된다. 오픈소스 프로젝트 운영의 전형적인 패턴이다.
클라우드 워크스테이션 시대, 리눅스 데스크톱의 조용한 부상
한 발짝 물러나 인프라 관점으로 보면 더 흥미로운 그림이 나온다. 클라우드 워크스테이션 서비스가 확대되고 있다. AWS WorkSpaces, Azure Virtual Desktop, GCP 위의 원격 데스크톱 환경에서 리눅스 기반 가상 데스크톱 수요가 조용히 늘고 있다. 이유는 단순하다. 비용이다. Windows 가상 데스크톱에는 OS 라이선스 비용이 얹히지만, 리눅스에는 그 부담이 없다.
기업이 개발자용 클라우드 워크스테이션을 리눅스로 전환할 때, 내부 도구들도 리눅스에서 돌아가야 한다. MAUI의 리눅스 지원은 바로 이 시나리오에서 실질적인 가치를 만든다. .NET 기반 내부 도구를 Windows에서만 쓸 수 있던 조직이, 같은 코드베이스로 리눅스 클라우드 데스크톱에도 배포할 수 있게 되는 것이다.
월 단위 라이선스 비용 차이가 인스턴스 수백 개 규모로 불어나면 무시할 수 없는 금액이 된다. 이런 비용 구조의 변화가 리눅스 데스크톱의 기업 채택을 천천히 밀어올리고 있고, MAUI의 리눅스 지원은 그 흐름에 올라탄 타이밍이다.
남은 과제: 파편화, 성숙도, 그리고 지속가능성
물론 커뮤니티 주도 프로젝트의 한계도 분명하다. 장기적인 유지보수, 네이티브 API 호환성, 성능 최적화 같은 과제가 산적해 있다. 리눅스 특유의 데스크톱 환경 파편화(GNOME vs KDE vs 기타)도 넘어야 할 산이다. GTK 기반으로 구현하면 KDE 환경에서 룩앤필이 어긋나고, 반대도 마찬가지다.
MAUI 자체도 아직 성숙한 프레임워크라 보기 어렵다. Windows와 macOS에서조차 버그 리포트가 꾸준히 올라오고, 퍼포먼스 이슈 논의도 활발하다. 여기에 리눅스라는 변수까지 더해지면 복잡도는 한층 올라간다.
그럼에도 방향 자체는 맞다. .NET이 진정한 크로스플랫폼을 표방하려면 리눅스 데스크톱은 언젠가 채워야 할 퍼즐이었다. 마이크로소프트가 직접 하지 않았을 뿐, 결국 커뮤니티가 그 빈칸을 메우고 있다. Flutter가 리눅스를 지원하고, Electron 앱이 리눅스에서 잘 돌아가는 시대에 MAUI만 리눅스를 외면할 수는 없었다.
핵심은 이것이다. 크로스플랫폼이라는 약속은 예외가 없어야 완성된다. MAUI의 리눅스 지원은 기술적 이정표인 동시에, .NET 생태계가 특정 벤더의 플랫폼 전략에서 한 걸음 더 독립하는 신호탄이다.
