읽는 데 9분
Blender UI를 앱에 쓰는 BUI, 한글 입력은 어디서 막힐까
BUI로 "한글 라벨: 가나다 ABC"가 들어간 화면을 이미지로 그렸더니 영문 ABC만 보이고 한글 자리는 전부 빈 네모였어요. Linux에서 PyPI의 blenderui 0.5.0을 기본 설정 그대로 쓴 결과예요. 글꼴 하나를 지정하자 같은 화면이 제대로 나왔어요. 한글 입력은 이 글꼴 문제와 별개로, 운영체제마다 막히는 지점이 달라요.
BUI는 3D 프로그램 Blender의 화면 부품(숫자를 끌어서 바꾸는 필드, 접히는 패널, 파이 메뉴 등)을 독립 UI 라이브러리로 떼어 낸 오픈소스예요. Blender를 설치하지 않아도 되고, Python·Rust·JavaScript·C·C++·Dear ImGui에서 쓸 수 있어요.
- 기본 정보: 제작자 ppmpreetham, 저장소 생성 2026년 8월 26일, 최신 v0.5.0(11월 8일), GPL-3.0-or-later, Windows·Linux·macOS

README 안에서도 말이 갈려요
README 앞쪽 "누구를 위한 도구인가" 구역은 한계로 "입력기 없음(no input methods)"을 적어 두었어요. 그런데 같은 README의 글꼴 구역과 알려진 한계 구역은 "IME는 Windows에서만"이라고 써요. IME는 자판 입력을 받아 한글 음절로 조합해 주는 입력기를 말해요.
실제 상태는 뒤쪽 설명이 맞아요. CHANGELOG의 0.5.0(11월 8일) 항목에 Windows IME 지원이 들어갔고, 한국어·중국어·일본어 입력이 텍스트 필드에서 동작한다고 적었어요. 계기는 하루 전 올라온 이슈 #14였어요. IME로 입력하면 입력 상자가 어긋난다는 보고였죠. 앞쪽 문구만 보고 "아예 안 된다"로 판단하면 Windows 사정은 틀리게 읽게 돼요.
운영체제별로 코드가 다르게 생겼어요
BUI에서 키 입력은 운영체제별 창 코드(창 호스트)가 받아서 공통 C 코어로 넘겨요. 공통 코어에는 조합 중인 글자를 밑줄로 그리고 후보창 위치를 계산하는 IME 처리가 있어요. 문제는 그 처리까지 조합 정보를 넘겨주는 창 호스트가 Windows 하나뿐이라는 점이에요.

- Windows: 창 코드가 IME 조합 시작·진행·끝 메시지를 받아 공통 코어로 넘겨요. 한국어 입력기만을 위한 분기도 있어요. 조합 중 커서를 한글 한 글자 크기의 깜박이는 블록으로 그리고, 후보창 위치도 한국어 입력기에 맞춰 따로 잡아요.
- Linux(X11): 키 하나가 눌릴 때마다 X11 기본 함수로 그 키의 글자만 얻어요. ibus나 fcitx 같은 입력기와 연결하는 코드(XIM 입력 컨텍스트)가 파일 안에 없어요.
- Linux(Wayland, 실험 단계): 마찬가지로 키 하나의 글자만 얻고, CHANGELOG도 "IME는 아직"이라고 적었어요.
- macOS: 키 이벤트의 글자를 그대로 쓰고, 입력기가 조합 중인 글자를 앱에 알려 주는 macOS 표준 경로(NSTextInputClient)를 구현하지 않았어요. 실제 Mac에서 두벌식으로 쳤을 때 무엇이 들어오는지는 확인하지 못했어요.
정리하면 Linux와 macOS의 기본 창 호스트에는 입력기가 조합한 한글을 공통 코어로 넘기는 연결이 없어요. Python에서 표준 Tk 창을 쓰는 BUI_HOST=tk 경로는 따로 확인해야 해요. 정확한 코드 위치는 글 끝 출처 아래에 모아 두었어요.
완성된 글자는 받고, 그리는 건 글꼴 몫이에요
막히는 곳이 입력 쪽인지 텍스트 필드 쪽인지 나눠 보려고, 입력기가 조합을 끝냈을 때 넘겨줄 완성 글자를 직접 넣어 봤어요. 텍스트 필드를 클릭한 뒤 키 입력으로 "한", "글", "A"를 차례로 보내고 Enter를 눌렀어요. 필드 값은 '한글A'로 저장됐어요. 텍스트 필드 자체는 한글을 받는다는 뜻이에요. 조합 중 밑줄 표시는 이 방법으로 시험할 수 없어서 범위 밖이에요.
그다음은 화면이에요. BUI는 Blender의 UI 글꼴 Inter를 내장하는데, Inter에는 한글이 없어요. README도 "글자별 대체 글꼴이 아직 없어 없는 글자는 네모로 보인다"고 밝혀요. 실제로 그려 보니 그대로였어요.

해결은 간단해요. 실행 전에 환경변수 BUI_FONT에 한글 글꼴 파일 경로를 넣으면 기본 글꼴이 통째로 바뀌어요.
BUI_FONT=/path/to/NotoSansKR.ttf python app.py
다만 기본 글꼴을 바꾸는 방식이라 영문도 그 글꼴로 그려져요. Blender 특유의 Inter 글씨 모양은 포기해야 해요.
대안과 견주면
Dear ImGui도 FAQ에서 "글자 입력은 앱이 올바른 문자 코드를 넘겨야 한다"고 밝혀요. Windows IME는 창 핸들만 넘기면 기본 구현이 IME 위치를 맞춰 주고요. 입력기 연결을 창 쪽 코드에 맡기는 구조는 BUI와 같아요. BUI 위에서 Dear ImGui를 돌리는 모드도 글자를 BUI 창 호스트에서 받으니, 운영체제별 사정이 그대로 따라가요.
Qt는 공식 문서에서 텍스트 편집기가 QInputMethod로 플랫폼 입력기와 연결된다고 설명해요. BUI 기본 창 호스트는 지금 Windows에만 조합 입력 연결이 있어요. Linux·macOS에서 한글 입력이 꼭 필요한 데스크톱 앱이라면 Qt 같은 대안도 함께 검토해 볼 만해요. Qt의 실제 한글 입력은 이번에 시험하지 않았어요.
누구에게 지금 쓸 만할까
제 생각엔 Windows용 사내 도구나 개인 도구라면 지금도 시험해 볼 만해요. Blender에 익숙한 사람을 위한 도구를 만드는 경우가 특히 그래요. Windows 창 코드에는 한국어 입력기 처리가 들어 있고, 한글 표시는 BUI_FONT로 해결돼요.
Linux나 macOS에서 기본 창으로 사용자가 한글을 입력해야 하는 앱이라면 아직 일러요. README는 X11과 macOS IME가 "곧 온다"고 했지만 날짜는 없어요. 몇 가지 조건이 더 있어요.
- 스크린 리더가 BUI 위젯을 읽지 못해요. README가 접근성이 필요한 소프트웨어에는 쓰지 말라고 직접 적었어요.
- BUI를 넣은 프로그램을 배포하면 그 프로그램도 GPL로 배포해야 해요. 사내 배포·상용 배포 전에 따져 볼 조건이에요.
- 성능 수치는 Windows 11 노트북 한 대에서 잰 값이고, Linux·macOS는 아직 재지 않았다고 README가 밝혀요.
확인한 범위
- 기준일: 2026-11-09, BUI 커밋 e8126ca(v0.5.0 직후)
- 직접 한 것: Windows·X11·Wayland·macOS 창 코드와 글꼴 코드를 읽어 입력기 연결 여부를 확인했어요. Linux x86_64, Python 3.12, blenderui 0.5.0에서 한글 라벨·텍스트 필드를 화면 없이 그려 기본 글꼴과
BUI_FONT(Noto Sans KR) 결과를 비교하고, 완성 글자 입력 후 필드 값을 확인했어요. Dear ImGui FAQ와 Qt 문서의 입력기 설명을 대조했어요. - 읽은 것: BUI README 전체, CHANGELOG 0.5.0, 이슈 #14, Dear ImGui FAQ, Qt QInputMethod 문서
- 확인하지 못한 것: 실제 입력기(Windows 한국어 IME, ibus·fcitx, macOS 두벌식)로 친 결과는 확인하지 못했어요. Python의
BUI_HOST=tk(표준 Tk 창) 경로의 한글 입력과 Rust·JavaScript 바인딩의 한글 입력, Qt의 실제 한글 입력 품질도 시험하지 않았어요.
출처

코드 위치(커밋 e8126ca): Windows IME 메시지, 한국어 입력기 분기, X11 키 처리, Wayland 키 처리, macOS keyDown, BUI_FONT, 이슈 #14, Dear ImGui FAQ, Qt QInputMethod
