TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 30 READS

NetBSD에서도 Vulkan이 돌아갑니다 — 마이너 OS에 최신 그래픽 API가 올라가기까지

NetBSD에서도 Vulkan이 돌아갑니다 — 마이너 OS에 최신 그래픽 API가 올라가기까지

"Of course it runs NetBSD"라는 오래된 밈이 있어요. 토스터부터 메인프레임까지 세상 어떤 기계에서도 돌아간다는, 이식성의 대명사가 된 운영체제가 바로 NetBSD거든요. 그런데 이 유서 깊은 BSD 계열 OS에서 이제 최신 그래픽 API인 Vulkan을 쓸 수 있게 됐다는 소식이 나왔어요. GitHub에 vulkan-netbsd라는 프로젝트가 공개된 건데요. 언뜻 보면 꽤 마이너한 뉴스처럼 보이지만, 사실 오픈소스 그래픽 스택이 어떻게 겹겹이 쌓여 있는지, 그리고 하나의 소프트웨어를 다른 OS로 옮기는 게 왜 어려운지를 들여다보기 좋은 소재라서 소개해요.

Vulkan이 뭐냐면요

Vulkan은 크로노스 그룹(Khronos Group)이 관리하는 저수준 그래픽·컴퓨트 API예요. 쉽게 말해 GPU에게 일을 시키는 표준화된 방법인데, 오랫동안 이 역할을 해온 OpenGL의 사실상 후계자예요. OpenGL은 드라이버가 알아서 처리해주는 부분이 많아서 코드는 짧지만, 그만큼 드라이버 내부에서 무슨 일이 벌어지는지 알기 어렵고 CPU 오버헤드도 컸어요. 특히 멀티코어 CPU를 제대로 활용하기 어려운 구조였죠. Vulkan은 반대로 메모리 관리, 동기화, 명령 버퍼 구성 같은 걸 개발자가 직접 제어하게 해요. 코드는 훨씬 길어지지만 GPU에게 일을 시키는 비용이 줄고, 여러 스레드에서 동시에 렌더링 명령을 준비할 수 있어요. 그래서 요즘 게임 엔진이나 에뮬레이터는 물론이고, llama.cpp의 Vulkan 백엔드처럼 머신러닝 추론에까지 쓰이고 있어요.

왜 NetBSD에서는 어려웠을까요

"API 하나 포팅하는 게 뭐가 어렵지?" 싶으실 수 있는데요. 그래픽 스택은 생각보다 훨씬 깊은 우물이에요. Vulkan이 동작하려면 일단 커널에 GPU를 다루는 계층인 DRM/KMS(GPU 메모리 관리와 화면 출력을 담당하는 커널 서브시스템)가 있어야 하고, 그 위에 오픈소스 그래픽 드라이버 모음인 Mesa가 올라가야 해요. 우리가 아는 AMD용 RADV, 인텔용 ANV 같은 Vulkan 드라이버가 다 Mesa 프로젝트 소속이거든요. 문제는 이 스택 전체가 사실상 리눅스를 중심으로 개발된다는 거예요. 드라이버 코드가 리눅스 커널의 메모리 관리 방식이나 동기화 도구를 전제하고 있어서, 다른 OS에서는 그 간극을 메우는 작업이 필요해요. 그래서 FreeBSD는 drm-kmod라는 이름으로 리눅스 DRM 코드를 주기적으로 포팅해서 쓰고, OpenBSD도 자체적으로 포팅본을 유지하고 있어요. NetBSD 역시 리눅스 DRM을 가져온 호환 계층을 갖고 있는데, 그 위에서 Vulkan까지 올라오는 데는 시간이 더 걸렸던 거죠. 이번 프로젝트가 그 마지막 조각을 채워준 셈이에요.

계층화된 설계의 힘

이 소식에서 배울 점은 "NetBSD에서 게임을 돌릴 수 있다"가 아니라, 잘 설계된 추상화 계층이 얼마나 강력한가예요. Mesa는 OS에 의존하는 부분과 GPU 하드웨어에 의존하는 부분을 분리해둔 덕분에, 새 OS 지원을 추가할 때 전체를 다시 쓰는 게 아니라 필요한 계층만 손보면 되는 구조거든요. 리눅스용으로 개발된 드라이버가 BSD 계열에서도 살아 움직이는 건 이 계층화 덕분이에요. 하드웨어 가속이 당장 안 되는 환경이라도 lavapipe 같은 CPU 기반 소프트웨어 구현으로 먼저 Vulkan API를 제공하고, 이후 하드웨어 지원을 넓혀가는 단계적 전략도 이 바닥의 흔한 지혜고요.

한국 개발자에게 주는 시사점

솔직히 말해서 당장 실무에서 NetBSD 위에 Vulkan 앱을 올릴 분은 거의 없을 거예요. 하지만 이 이야기의 구조 자체는 굉장히 보편적이에요. 임베디드 장비에 리눅스용 라이브러리를 올려야 할 때, 크로스플랫폼 제품을 새 OS에 대응시켜야 할 때, 우리는 늘 같은 질문을 만나거든요. "어디까지를 호환 계층으로 때우고, 어디부터를 네이티브로 다시 쓸 것인가?" 이번 사례는 그 결정의 좋은 참고 자료예요. 그리고 니치한 플랫폼 포팅은 오픈소스 기여를 시작하기 좋은 영역이기도 해요. 경쟁자가 적고, 커뮤니티가 작아서 피드백을 빨리 받을 수 있고, 커널부터 유저랜드까지 스택 전체를 훑게 되니 배우는 게 정말 많거든요.

정리하면, 이번 소식은 오픈소스 그래픽 스택의 이식성이 어디까지 왔는지 보여주는 작지만 의미 있는 이정표예요. 여러분은 메이저 플랫폼이 아닌 곳에 뭔가를 포팅해본 경험이 있으신가요? 그때 가장 힘들었던 계층은 어디였나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/segaboy/vulkan-netbsd
SHARE
처리 중...