TECH 으로 돌아가기
TECH HACKER NEWS 7분 읽기 25 READS

블렌더의 UI를 떼어낸 BUI, 어떤 도구이고 무엇을 따져봐야 하나

블렌더의 UI를 떼어낸 BUI, 어떤 도구이고 무엇을 따져봐야 하나
SOURCE IMAGE · HACKER NEWS

3D 소프트웨어 블렌더(Blender)의 사용자 인터페이스는 오랫동안 '손에 감기는 조작감'으로 정평이 나 있다. BUI는 바로 그 인터페이스를 블렌더 본체 코드베이스에서 떼어내, 어떤 애플리케이션에서도 쓸 수 있는 독립 UI 라이브러리로 만든 오픈소스 프로젝트다. 핵심은 C로 작성된 작은 런타임으로, 프로젝트에서는 이를 '키트(kit)'라고 부른다. 키트는 모든 위젯을 하나의 트리로 보관하고 레이아웃을 계산하며, 마우스와 키보드 입력을 처리하고 블렌더와 동일한 방식으로 화면에 그린다. 드로잉 코드 자체가 블렌더 위젯 코드를 C로 포팅한 것이고, 상호작용 규칙도 블렌더를 따른다. 개발자는 위젯 트리를 구성하고 콜백만 작성하면 되며, 레이아웃·입력·드로잉·출력은 모두 네이티브 코드에서 CPU 또는 GPU로 처리된다.

블렌더의 조작감을 그대로

블렌더 UI의 특징은 작은 디테일에서 드러난다. 숫자 필드를 누른 채 드래그하면 커서가 사라지고 값이 손끝을 따라 미끄러지며 화면 끝에 걸리지 않는다. 필드에 '2*pi' 같은 수식을 입력하면 그대로 계산되고, 메뉴에서 'ad cu'라고 치면 'Add Cube'를 찾아낸다. BUI는 이런 상호작용을 C 키트 안에 담아, 파이썬 컴포넌트든 tkinter·Qt 문법이든 러스트·자바스크립트 바인딩이든 동일하게 동작하도록 했다. 즉 언어나 프레임워크를 바꿔도 같은 위젯과 같은 조작감이 유지된다는 것이 설계의 핵심이다.

효율성도 내세우는 지점이다. BUI는 변경된 부분만 다시 그리는 방식(damage rendering)을 쓴다. 창을 열어두고 자리를 비우면 CPU를 전혀 쓰지 않고, 버튼 위에 마우스를 올리면 창 전체가 아니라 그 버튼만 다시 그린다. 프로젝트가 제시한 수치로는 전체 컴포넌트 데모에서 한 프레임을 완전히 그리는 데 약 0.7밀리초, 호버나 숫자 스크럽 같은 부분 갱신은 약 0.05밀리초가 걸린다. 렌더러는 CPU와 GPU 두 가지인데 같은 픽셀을 그리도록 설계되어, 패리티 테스트에서 17만 2,800개 픽셀 중 10개만 3/255를 넘는 차이를 보였다고 한다. GPU 렌더러는 프레임당 CPU 사용량이 절반 수준이지만 약 10MB의 추가 메모리와 GPU 메모리를 요구한다.

언어별 사용 방식

파이썬에서는 CPython 3.11 이상에서 'blenderui' 패키지 하나로 네 가지 API(tkinter 문법, Qt 문법, 블렌더 컴포넌트, Dear ImGui)를 함께 쓸 수 있고, 윈도우·리눅스·macOS용 휠이 배포돼 별도 컴파일이 필요 없다. 기존 tkinter 프로그램은 한 줄도 고치지 않고 BUI 위에서 돌릴 수 있다고 소개한다. 반면 Qt 문법은 주요 위젯 메서드 이름의 약 24%만 구현된 부분 호환이라, 나머지는 AttributeError를 낸다. 러스트는 crates.io의 'blenderui' 크레이트로 제공되며 rsx!와 gpui 스타일 빌더 두 문법을 지원하되 첫 빌드 때 C 키트를 컴파일하므로 CMake와 C 컴파일러, 리눅스에서는 X11 헤더가 필요하다. 자바스크립트/React는 Node 18 이상 또는 Bun에서 동작하지만 사전 빌드 패키지는 윈도우 x64용뿐이다. Dear ImGui 1.93은 기존 코드를 수정 없이 컴파일할 수 있고, 빌드 옵션을 켜면 ImGui 위젯이 블렌더식 위젯으로 바뀐다.

도입 전에 따져볼 한계

프로젝트 설명은 스스로를 'GPUI보다 두 배 좋다'고 표현하지만, 공개된 문서에는 절대 성능 수치만 있을 뿐 GPUI와 직접 비교한 상세 벤치마크는 담겨 있지 않다. 따라서 이 비교 문구는 마케팅 성격의 주장으로 받아들이고, 실제 도입 전에는 자신의 워크로드에서 직접 측정하는 편이 안전하다. 플랫폼 제약도 분명하다. macOS는 아직 CPU 렌더러만 지원하고 자바스크립트는 헤드리스로만 돌며, npm 패키지는 윈도우 x64용만 사전 빌드돼 다른 환경에서는 소스 빌드가 필요하다.

한국 실무자 입장에서 가장 눈여겨볼 한계는 텍스트 처리다. 글자 단위 폰트 폴백이 없어 폰트에 없는 문자는 네모 상자로 표시되고, IME가 아직 지원되지 않으며, 오른쪽에서 왼쪽으로 쓰는 문자는 재배열만 될 뿐 셰이핑은 되지 않는다. IME 부재는 한글 입력이 필요한 데스크톱 애플리케이션에는 사실상 치명적인 제약이므로, 입력 필드에 한글을 받아야 하는 제품이라면 현 시점에서는 적용이 어렵다. 프로젝트는 폰트 폴백과 IME를 '곧 지원 예정'으로 명시하고 있다.

정리하면 BUI는 블렌더의 조작감과 가벼운 자원 사용을 여러 언어로 가져오려는 흥미로운 시도다. 숫자 입력과 설정 패널이 중심이고 영문 위주인 네이티브 툴, 혹은 기존 tkinter·ImGui 코드를 블렌더식 외관으로 바꾸고 싶은 경우에는 검토해 볼 만하다. 다만 아직 초기 단계인 만큼 플랫폼 커버리지와 텍스트·입력 처리의 공백을 먼저 확인하고, 특히 한글 입력 요구가 있다면 IME 지원이 추가될 때까지 기다리는 것이 현실적인 판단이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/ppmpreetham/BUI
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...