기술 리뷰: 리눅스 콘솔에서 한글 입출력
by 류창우
리눅스를 사용했던 사람들이 종종 이런 질문을 하고는 한다. “왜 리눅스 가상 터미널에서는 한글 입출력이 안 되는가?”
리눅스 콘솔 현황
터미널이란
PC 이전 시대 통상 컴퓨터 터미널이란 키보드와 모니터로 (또는 모니터 대신 프린터) 구성된 물리적인 기기를 말했다. 당시의 컴퓨터는 본체에는 입출력을 담당하는 기능이 아예 없었고, RS-232와 같은 시리얼 통신으로 이러한 터미널에 연결해 키보드와 모니터를 사용했다.
DEC의 VT100이나 VT220 시리즈가 그러한 기기인데, 터미널 에뮬레이터 세팅에서도 자주 보는 이름일 것이다.
( Wikipedia Commons, CC BY 2.0 )
( Wikipedia Commons, CC BY 2.0 )
$ cd /usr/share/terminfo/v/
$ ls vt*
vt-61 vt100-s-bot vt220 vt320-k311 vt52-basic
vt-utf8 vt100-s-top vt220+cvis vt320-nam vt520
vt100 vt100-top-s vt220+cvis8 vt320-w vt520-w
vt100+ vt100-vb vt220+keypad vt320-w-nam vt520ansi
vt100+4bsd vt100-w vt220+pcedit vt320nam vt525
vt100+enq vt100-w-am vt220+sfkeys vt330 vt525-w
vt100+fnkeys vt100-w-nam vt220+ufkeys vt340 vt61
vt100+keypad vt100-w-nav vt220+vtedit vt400 vt61.5
vt100+noapp vt100nam vt220-8 vt400-24 vte
vt100+noapp+pc vt102 vt220-8bit vt420 vte+pcfkeys
vt100+pf1-pf4 vt102+enq vt220-base vt420+lrmm vte-2007
vt100+pfkeys vt102-nsgr vt220-js vt420f vte-2008
vt100-am vt102-w vt220-nam vt420pc vte-2012
vt100-bm vt125 vt220-old vt420pcdos vte-2014
vt100-bm-o vt131 vt220-w vt50 vte-2017
vt100-bot-s vt132 vt220d vt50h vte-2018
vt100-nam vt200 vt300 vt510 vte-2022
vt100-nam-w vt200-8 vt300-nam vt510pc vte-256color
vt100-nav vt200-8bit vt300-w vt510pcdos vte-direct
vt100-nav-w vt200-js vt300-w-nam vt52 vtnt
vt100-putty vt200-old vt320 vt52+arrows
vt100-s vt200-w vt320-k3 vt52+keypad
$
예를 들어 흑백인 VT100 시리즈와 달리 VT220 시리즈에서 컬러 지원이 시작됐었기 때문에 오늘날 터미널 에뮬레이터에서도 vt100으로 설정하면 컬러 표시가 안 되고, vt220으로 설정하면 컬러가 나온다. 이스케이프 시퀀스에 따라 화면을 지우거나, 화면의 특정 위치에 글자를 표시하거나, 심지어 터미널에 스피커도 달려 있어서 삑 소리를 낼 수도 있었다.
당시 한국에서 출시된 터미널 기기 중에서는 한글도 표시되는 기기가 있었다. VT220과 호횐되면서도 한글코드를 입력하면 그 부분을 한글로 바꿔서 보여주는 식으로 커스터마이즈된 제품이었다.
터미널 에뮬레이터란
흔히 터미널 에뮬레이터로 알려진 지금의 터미널 소프트웨어가 “에뮬레이터”로 불리우는 이유는, 이러한 물리적인 기기를 소프트웨어로 흉내내는 프로그램이기 때문이다. 즉 문자나 특정 이스케이프 코드를 화면에서 어떻게 표시할지를 정하는 프로그램이다.
물리적인 터미널을 사용했던 시대는 이제는 오래 전이기 때문에 오늘날 터미널 에뮬레이터는 에뮬레이터로만으로만 머무르지 않고 실제 물리적인 기기가 지원하지 않은 기능을 독자적으로 구현하기도 한다. 이러한 경우 “에뮬레이터”라고 부르는 게 적절한지 의문이 들 수도 있지만, 관행상 터미널 소프트웨어는 터미널 에뮬레이터라고 부르고 있다.
리눅스 콘솔도 터미널 에뮬레이터: vgacon, fbcon
리눅스의 텍스트 입출력 인터페이스인 콘솔도 터미널 에뮬레이터라고 부를 수 있다. “x86의 그래픽 카드에는 텍스트 모드가 하드웨어로 내장되어 있지 않느냐?”라고 반문할 수 있지만, 1980년대부터 내려온 이 80x25 16컬러 VGA 텍스트 모드는 메모리의 특정부분에 문자 코드를 쓰면 화면에 그 글자가 렌더링이 되는 기능이 내장되어 있을 뿐이지, 프로그램에서 출력된 텍스트를 어느 위치에 표시하고, 어떻게 스크롤하고, 이스케이프 시퀀스를 해석해서 그것을 어떻게 화면에 반영하는지는 구현된 소프트웨어에 달려 있기 때문에 터미널 “에뮬레이션” 기능은 여전히 필요하다.
게다가 오늘날에는 이 하드웨어 텍스트 모드를 쓰지 않는 경우가 많다. 오늘날 x86 PC의 BIOS는 UEFI 부팅을 할 때부터 그래픽 모드로 초기화를 한다. 커널도 80x25 모드가 아닌 다양한 모드로 콘솔을 시작할 수 있게 되어 있다. 텍스트모드를 사용하는 콘솔을 vgacon이라고 부르는데 반해 그래픽 모드에서 동작하는 콘솔을 fbcon, “프레임버퍼 콘솔”로 부르고 있다.
콘솔 한글 입출력, 한계와 시도
자 1980-1990년대 PC에서 MS-DOS를 쓸 때도 하드웨어, 램상주 등 여러가지 수단을 사용했고, 여전히 문제는 남아 있었지만 그래도 동작했고 널리 사용되었다. 그런데 왜 리눅스의 콘솔은 2020년대에도 한글이 나오도록 발전되지 않았을까?
현재 vgacon, fbcon 구현의 한계
커널에 구현된 콘솔 중 vgacon은 VGA 텍스트 모드를 사용하므로 그 하드웨어의 제약을 따를 수밖에 없다. 그 중에 문제는 VGA 폰트에서 최대 512 글자까지만 가능한 제약이 있다.
vgacon은 어차피 한글이 안 보이니까 상관없고 fbcon에서만 되면 상관 없다고 생각할 수도 있지만, 아쉽게도 vgacon과 얽혀 있는 fbcon 역시 같은 제약을 갖고 있어 512자 폰트밖에 사용하지 못한다.
커널 수준 구현의 근본적 한계
커널 수준에서 한글 입출력을 구현하는 걸 한번 상상해 보면, 이론상 가능하지만 사실상 불가능하다고 볼 수 있다.
원론적인 이야기로 커널 모드에서 동작하는 소프트웨어는 개발이든 유지 보수든 간에 모든 부분에서 보안 문제에 대한 신경을 많이 써야 한다. 또 GPL 호환 코드만 사용할 수 있어 라이선스 제약도 있다.
실제로 vgacon이나 fbcon은 종종 보안 문제를 겪고는 한다. 2020년에는 아예 보안 버그가 많이 나오는 스크롤 기능을 통째로 삭제해 버리기도 했다.
-
Linux Frame-Buffer Console To Drop Accelerated Scrolling Since It’s Full Of Bugs - phoronix.com
-
CVE-2025-68296 - Debian security tracker
한글 구현이 불가능하지는 않겠지만, 커널에서 대규모의 수정은 매우 민감하다. 입력은 말할 필요도 없다. 한글 입력까지야 어떻게 하겠지만, 일본어나 중국어 처럼 단어 선택이 필요하면 구현하기 매우 어렵다.
방향: 유저스페이스 구현
여기까지 왔으면 자연스럽게 터미널 에뮬레이션을 커널에서 구현하지 말고, 유저스페이스에서 잘 구현하자는 아이디어가 자연스럽게 나온다. 커널 모드에서 수정하는 것보다 훨씬 더 유력한 방향이다.
입력 문제 역시 유저스페이스에서 구현하는 편이 ibus, fcitx와 같은 입력기 프레임워크를 활용할 수 있기 때문에 잘 해결할 수 있다.
유저 스페이스 시도: fbterm, zhcon
프레임버퍼 위에서 구현한 터미널 에뮬레이터로 fbterm과 (지금은 중단된) zhcon이 있다.
하지만 이들 소프트웨어는 10년 이상 꽤 오래 되었고, 그래서 오래된 커널
인터페이스를 사용하는 부분이 문제이다. fbterm이라는 이름처럼 /dev/fb0와
같은 “프레임버퍼” fbdev를 사용하는 부분에서 한계를 가진다. 프레임버퍼
인터페이스는 인터페이스의 메모리를 mmap으로 매핑해서 그래픽 메모리의 픽셀
하나하나를 직접 설정하는 식으로 동작한다. 즉 느리다. GPU 가속같은 건
생각할 수 없다. 텍스트 출력에 그런 것까지 필요하냐고 생각할 수도 있지만,
대량의 입출력이 일어나는 요즘의 터미널 에뮬레이터는 거의 모두가 GPU 가속을
하고 있다. fbterm은 물론이고, 커널에서 동작하는 fbcon도 프레임버퍼 기반이기
때문에 같은 식으로 동작하고, 그래서 느리다는 걸 쉽게 체감할 수 있다.
fbterm은 입력에 관해서도 어느 정도 해법을 제시한다. 앞에서 말한 것과 같이 ibus나 fcitx를 연결할 수 있고 실제로 구현되어 있다. 하지만 그렇게 부드럽게 동작하지는 않는 게, 어디선가 ibus나 fcitx 데몬이 실행 중이라는 가정하에 동작하는데 콘솔 로그인에서는 그러한 세션 관리가 되지 않기 때문이다.
현재: DRM + KMS -> kmscon
그리고 이상적인 해법이 등장한다. 커널 DRM(Direct Rendering Manager)을 사용하면 게임이나 컴포지터처럼 GPU 가속을 활용하는 터미널 에뮬레이터를 만들 수 있다. 커널모드에서 동작하는 fbcon보다도 훨씬 더 빠르게 만들 수 있다. (fbcon은 커널 모드이기는 fbdev 기반이므로 여전히 픽셀 단위로 메모리를 써야 하기 때문이다.)
가장 유력한 후보로 kmscon이 있다. 실제로 fbcon보다 몇배 더 빠르다.
KMS(Kernel Mode Setting)은 커널의 그래픽 모드를 세팅하는 DRM 인터페이스의 일부로, 이를 이용한다는 점에서 kmscon은 이름이 이렇게 붙여졌다. kmscon은 시작할 때부터 커널에 내장된 터미널 에뮬레이션을 대체하겠다는 시도로 시작되었다.
실패해서 다행인(?) 시도: systemd-consoled
kmscon 프로젝트에서 영향을 받은 프로젝트가 있으니 무려 systemd. 리눅스의 모든 것을 다 다시 만들다시피 하는 systemd 답게, 리눅스 콘솔을 대체하는 프로젝트인데 systemd가 발을 담그지 않을 수가 없다.
사실은 kmscon의 개발자가 만들었다. systemd-consoled라는 이름으로 시도했었는데.. 하지만 개발자도 작업을 하지 않으면서 이마저 2015년에 계획이 취소됐다 (앞으로 다시 만들 여지가 남아있지만).
미래일까?: kmscon
왜 메인스트림이 되지 못했을까 싶을 정도로 kmscon은 이미 잘 돌아간다. 한글이 당연히 출력된다. 단지 콘솔에서 실행하면 프레임버퍼 터미널을 실행하는 프로그램일 뿐이었던 fbterm이나 zhcon과는 다르게, kmscon은 getty를 대체하도록 만들어져 있다. 로그인할 때부터 그래픽 모드를 자체적으로 설정하고, 한글이 출력된다.
- kmscon을 설치한다.
- systemd 서비스로 getty 대신 kmscon을 실행한다. tty3에 올라와 있는 getty를
kmscon으로 대체하려면 아마 다음 명령으로 끝날 것이다.
systemctl disable --now getty@tty3.service systemctl enable --now kmsconvt@tty3.service - Ctrl-Alt-F3으로 tty3으로 전환해서 로그인.
Fedora 배포판의 경우 2026년 10월에 릴리스 예정인 Fedora 45부터 커널 모드 fbcon 대신 kmscon을 기본값으로 쓰려는 계획이 있다.
하지만 kmscon도 100% 미래라고 장담할 수는 없다. 이 프로젝트는 10년 가까이 개발이 정체되었다가 작년 2025년에서야 새로운 메인테이너가 릴리스를 하고 있는 등 우여곡절을 겪었다. Fedora가 공격적인 시도를 하고는 있지만, 처음에 가졌던 목표처럼 리눅스 커널 내장 터미널 에뮬레이터를 대체할 수 있을지는 여전히 미지수이다. 특히 입력 쪽은 여전히 아무것도 구현되어 있지 않은 상태로 남아 있다.
안 되는 진짜 이유: 동력이 없다
위와 같이 기술적 장벽들을 살펴보았고, 현재의 방향도 조사해 보았다. 하지만, 리눅스 가상 터미널에서 한글 입출력이 안 되는 진짜 이유는 따로 있다. 바로 현실적인 필요성이 별로 없기 때문이다.
기술적 난이도가 높은 반면, 개선했을 때 얻을 수 있는 것은 많지 않다. 대부분의 사용자는 부팅 후 즉시 GUI 환경에서 로그인을 할 것이다. 솔직히 문제가 있을 때 잠깐 쓰다 돌아가는 용도 아니면 보지도 않는 콘솔에 사람들이 별로 관심을 가지지 않는다. 물리적인 콘솔 터미널에서 한글이 보여야 하는 환경이 얼마나 될까? 트러블슈팅을 위해 콘솔을 사용하는 엔지니어들이 한글을 입출력할 수 있으면 좋겠지만, 영문 메시지로 나온다고 크게 불편하지는 않다. 외로운 서버실에서 한글 로그를 보지 못한다고 해서 업무가 불가능할 정도의 불편함을 느끼지는 않는 것이다.
시작할 때 말한 것처럼 종종 리눅스 가상 터미널에서 왜 한글이 안 되느냐는 질문을 보긴 하지만, 그 사람들이 계속 의문을 갖고 문제를 해결해야 한다고 의견을 모으고 해법을 찾으려 하는 걸 보지는 못했다. 그것이 왜 현재 상태와 같은지 설명하고 있다. 결국 대답은 “그 노력을 들여서 현 상태를 바꿀 만큼 절실한 집단이 존재하지 않는다”는 현실로 답할 수 있다. 대다수의 배포판이 여전히 투박한 vgacon 내지 fbcon을 고수하는 이유가 여기에 있다.
tags: linux - console - terminal - font - input - kmscon