사람들이 차라리 네이티브 앱을 만들었으면 좋겠음. TUI는 명령줄 인터페이스와 진짜 GUI의 단점을 합친 형태처럼 보임
모든 TUI 프로그램은 스크롤을 직접 다시 구현해야 해서, 터미널이 픽셀 단위 스크롤을 지원해도 TUI 프로그램은 줄 단위 스크롤만 지원하고 동작도 제각각임. senpai의 스크롤백은 내가 쓰는 다른 프로그램들과 방식이 달라 자꾸 길을 잃게 됨
인터페이스가 단일 텍스트 패널 이상이라는 정보를 터미널에 드러낼 방법도 없어서 텍스트 선택이 자주 망가짐. 마우스 이벤트를 가로채면 가능하긴 하지만 그건 또 나름 별로임. TUI IRC 클라이언트에서는 텍스트 선택을 하려고 양옆의 잡다한 패널을 숨기는 단축키를 눌러야 했고, 꽤 바보 같은 절차였음
그리드에 맞춰야 한다는 제약은 레이아웃과 디자인 가능성을 크게 제한함. 클릭 가능한 버튼처럼 보이게 스타일링하던 방식, 컨텍스트 메뉴 같은 것들이 떠오름. 예전에 이 문제를 불평한 적도 있음
TUI가 늘어나는 건 전통적 GUI 프레임워크 상태가 좋지 않은 데서 온 안타까운 결과라고 봄. TUI 프레임워크는 비교적 안정적인 편이고, 아주 오래된 걸 써도 크게 거슬리지 않음. ncurses 프로그램은 지금도 자주 쓰지만 Motif 프로그램을 쓰는 모습은 잘 상상되지 않음
반면 GUI 프레임워크는 선택지가 많지 않고 유지보수가 훨씬 더 필요함. 데스크톱 환경은 바뀌고, GUI에 대한 기대도 커짐. TUI 접근성은 정말 별로라고 보지만 확신까지는 못 하겠음. 변화도 심해서 GTK2로 만들었더니 폐기 예정, GTK3로 올렸더니 GTK4로 가라는 식이 반복됨
냉소적으로 보면 Omarchy 같은 것에는 다른 요인도 있음. 일반 GUI인 xfce4-taskmanager는 지루하지만 TUI인 btop은 엄청 해커스러워 보임. 사람들은 터미널 미학을 좋아하고(/r/unixporn 참고), 분위기를 위해 사용성을 희생할 의향도 있어 보임. btop이 프로세스 목록을 실제로 페이드아웃시키는 모습을 보면 그렇다
웹 개발을 오래 하다가 네이티브 애플리케이션 개발을 해보고 싶었음. GNOME 앱을 만들려고 살펴봤는데 C++ 중심이라 꽤 낙담함
이제는 진입 장벽이 더 낮아졌기를 바랐음. 대부분의 개발자가 고수준 언어로 훈련받는 상황에서는 설득력이 약해 보이고, C++의 복잡성이 나를 겁먹게 하는 것 같기도 함
곁가지지만 왜 많은 채팅 클라이언트는 기록을 복사해 붙여넣으면 형식이 엉망이 되게 만드는지 모르겠음. Discord에서는 예를 들면 이렇게 나옴
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
Matrix 클라이언트인 Nheko는 한 번에 한 줄 넘게 선택도 못 하게 함
반면 IRC 클라이언트들은 기본적으로 이런 형태를 제공함
20:41 <username1> message1
20:42 <username2> message2
명령줄 인터페이스를 좋아하지만 TUI는 나도 별로임. 쓸 곳은 있지만 사실상 거칠고 못생긴 GUI에 가깝고, 터미널 공간을 낭비하는 경우도 많음
가끔은 말이 되지만 이상적으로는 작고 짧게 쓰는 앱이나 텍스트 편집 같은 예외에만 쓰는 편이 좋다고 봄
TUI가 좀 약하다고 느끼지만, gtk 같은 UI 도구모음과 비교하면 그나마 덜 나쁜 선택임. 내가 좋아하는 TUI 앱들은 확장성이 좋고 빠릿하며 Linux 명령줄과 잘 통합됨
예를 들어 lf, tig, kakoune은 셸 스크립트와 잘 맞아서 같은 스크립트를 재사용하고 세 앱 모두에서 기능을 확장할 수 있음. 모두 alacritty에서 실행되기 때문에 세 앱과 셸 전반에서 동작하는 하이퍼링크도 만들 수 있음
꿈을 꿀 수 있다면 Emacs나 acme 스타일 통합을 허용하는 단색 미니멀 GUI 도구모음이 있었으면 함
대체로 동의하지만 Tk가 조용히 계속 굴러가며 지금도 유용하다는 점은 짚고 싶음. gitk 같은 예가 있음
TUI가 어떻게 “자동화하기 쉽다”는 건지 모르겠음. 콘솔에 표시되는 GUI와 같은 것 아닌가?
여러 TUI는 프로그램을 열 때 스크립트 언어처럼 동작하는 플래그를 제공함. 게다가 LLM이 제대로 된 네이티브 GUI나 JavaScript 성향의 Electron 앱보다 텍스트 기반 인터페이스와 상호작용하는 쪽이 더 쉽고 비용도 낮음
이 글은 TUI가 “돌아온” 핵심 이유를 놓쳤음. 그 주장 자체도 의심스럽지만, Claude 같은 코딩 에이전트가 대량으로 바이브 코딩되면서 최근 인기가 오른 건 맞아 보임
개발자들은 쉬운 선택을 좋아함. 크로스플랫폼 TUI를 만드는 것이 GUI를 만드는 것보다 쉽기 때문임
웹 앱이 인기를 얻은 이유도 같음. 브라우저 도구로 크로스플랫폼 앱을 만들기 쉬웠기 때문이고, Electron이 뜬 이유도 크로스브라우저 지원 부담을 뺀 같은 맥락임. 반응형 UI를 만드는 일, UI를 크로스플랫폼으로 렌더링하는 일, 사용자 입력을 특히 접근성까지 고려해 처리하는 일은 모두 어려움. 그래서 개발자들은 이런 걸 쉽게 만들어주는 무언가에 바로 뛰어듦
최근에는 TUI 제작을 더 쉽게 만든 변화도 있었음. 고급 기능의 크로스플랫폼 지원이 나아지고, 복잡한 세부사항을 추상화한 유명 라이브러리들이 나왔고, 이런 것들이 최근 TUI 르네상스로 이어진 듯함
그 밖에 글의 논점들은 좀 의심스러움. 예를 들어 저자는 Electron 앱의 약점으로 일관성을 들지만, 인기 있는 TUI에도 관례를 제외하면 일관성은 거의 없음. 코딩 에이전트들은 비슷한 단축키를 채택했지만 대부분 같은 출처인 Claude를 베꼈기 때문임. 그 단축키는 코딩 에이전트 바깥으로는 잘 확장되지 않고, 내가 쓰는 대부분의 TUI는 단축키와 시각 언어가 꽤 다름
“반응형 UI를 만드는 게 어렵다”는 말이 무슨 뜻인지 잘 모르겠음. 웹 쪽 이야기처럼 들리는데, 웹의 아이디어 일부가 관련될 수는 있어도 네이티브 GUI 이야기에서는 주제에서 벗어난 것 같음. 그냥 “좋은 UI를 만드는 것”이나 “UI 도구모음을 만드는 것”을 말한 건가?
“UI를 크로스플랫폼 방식으로 렌더링하는 게 어렵다”는 말도 의문임. 호환 계층이 필요하고 플랫폼 수만큼 구현이 필요하긴 하지만, 단일 플랫폼 지원보다 그렇게 더 어렵지는 않아 보임. 물론 대상 플랫폼들의 렌더링 방식이 너무 달라 공통 API를 설계하기 어려운 경우라면 다르겠지만, 화면에 픽셀을 찍는 수준에서는 그렇지 않을 것 같음. 배율 같은 요소는 처리해야겠지만 그 이상은 꽤 직선적이어야 하고, 아니면 SDL도 있음
아마 모든 플랫폼에서 UI가 “네이티브처럼 보이게” 만드는 이야기를 한 것 같음. 그건 각 플랫폼의 선호 네이티브 GUI 도구모음을 써야 할 수 있고, 서로 매우 다를 뿐 아니라 저수준 렌더링 API보다 훨씬 크고 덜 안정적일 수 있음. 그런 건 인생이 너무 짧음. 색상 테마나 그래픽 스타일 일부를 바꿀 여지는 두겠지만 앱 수준 설정으로 둘 것임. 각 운영체제의 그래픽 설정을 읽느라 시간을 낭비하고 싶지 않음
“사용자 입력, 특히 접근성 처리가 어렵다”는 말도 이상함. 키보드와 마우스 이벤트를 듣는 건 사소한 일임. 접근성 측면에서는 제대로 된 키보드 탐색이 필요하고 전반적 사용성에도 중요하며, 표준 및 사용자 지정 단축키 지원도 필요하겠지만 전체적으로는 나머지보다 훨씬 쉬워 보임 스크린 리더 지원은 관련 플랫폼의 API와 플랫폼 간 차이에 따라 어려울 수 있지만, 그건 입력 문제라기보다 렌더링 문제에 더 가까움
TUI는 “컴백”이라기보다 네이티브 GUI 프로그래밍 지식을 잃어버려서 가진 도구로 최선을 다하는 모습에 가까움. 일관된 개발과 투자가 부족했던 결과임
Qt 같은 몇몇 밝은 예외를 빼면 UI 문명이 붕괴했고 우리는 종말 이후를 사는 느낌임 Preventing the Collapse of Civilization 강연과 운율이 맞는 것처럼 느껴지고, 이제 AI가 많은 코드를 쓰는 상황이라 이런 지식 붕괴가 더 확산될까 걱정됨
lobste.rs에서 이 주제가 나올 때마다 끼어들었으니 여기서도 끼어들어야 할 것 같음. 모든 GUI “제국”이 눈앞에서 무너지고 있음. Windows, macOS, GTK, Mozilla 제품들 모두 그렇다
컴퓨터 과학판 After Virtue가 필요한 느낌이고, 어쩌면 Blow의 온라인 존재감이 그 역할을 하고 있는지도 모름. 어쨌든 일관성을 보여주고, 사용자를 존중하며, 학습과 정성을 보상하던 컴퓨터 인터페이스의 시절이 그리움
이 글은 실질적인 내용이 별로 없고, 저자가 다른 모든 것이 형편없다고 생각한다는 정도만 말하는 것 같음
한 가지 말하자면 Emacs는 텍스트, 키보드, 버튼, 리치 미디어 인터페이스를 위한 훌륭한 플랫폼임
사람들이 Go, Rust, 이제는 Zig로 ncurses가 아닌 TUI 라이브러리를 쓰기 시작했기 때문일 가능성이 큼. 그래도 ncurses가 필요했던 끔찍한 이식성 문제는 해결해줬음
그러고 나서 사람들은 새 터미널을 만들고 그쪽 기술도 밀어붙이기 시작함. 부분적으로는 C 대신 Go, Rust, Zig로 만들 수 있게 됐기 때문임
C와 C++보다 재미있고 덜 짜증 나는 좋은 선택지를 주면, 당연히 사람들은 더 새롭고 유용한 코드를 쓰기 시작함
TUI가 돌아온 진짜 이유는 2026년에 서명되고 공증된 GUI를 배포하려면 Apple에 돈을 내고 Windows용으로는 인증기관에도 돈을 내야 하기 때문임
네이티브 TUI 바이너리도 같은 문제가 있지 않나?
세부 정정: Zed의 GPU 가속 UI 라이브러리는 크로스플랫폼 API인 wgpu가 아니라 gpui임
글이 논지를 제대로 입증했는지는 잘 모르겠지만, MS-DOS 시대를 겪었고 TUI를 늘 좋아했던 사람으로서 끼어들어 봄. afl-fuzz를 써봤다면 아마 알 수 있을 것임
이론적으로 Linux에서 TUI는 훨씬 더 성공했어야 함. 텍스트 기반 미학을 좋아하는 기술 사용자층이 있었고, 투박하고 일관성 없는 GUI 환경이라는 “이점”도 있었음. 비디오 카드가 X 서버에서 제대로 동작하게 만드는 것부터가 문제였던 시절도 있었음
동시에 수십 년 동안 *nix 소프트웨어 개발자들은 오래되고 이국적인 터미널 유형까지 지원해야 한다는 의무감을 느꼈음. 애플리케이션이 DECwriter에서 제대로 렌더링되지 않으면 큰일이라도 나는 식이었고, 그런 제약 아래서는 좋은 TUI를 만들기 어려웠음
MS-DOS 시대에는 Microsoft, Borland, Norton 같은 업체들이 기능적이고 반응 빠른 텍스트 기반 인터페이스를 완성했음. Linux에서는 오랫동안 TUI 설계의 “정점”이 menuconfig라는 괴물이었고, 눈을 가늘게 뜨면 vim도 TUI라고 부를 수 있을 정도였음. 사람들이 실제로 텍스트 모드 콘솔을 쓰던 시절에 기억나는 좋은 Linux TUI는 Norton Commander에서 영감을 받은 파일 관리자 Midnight Commander 정도였음
Lobste.rs 의견들
사람들이 차라리 네이티브 앱을 만들었으면 좋겠음. TUI는 명령줄 인터페이스와 진짜 GUI의 단점을 합친 형태처럼 보임
모든 TUI 프로그램은 스크롤을 직접 다시 구현해야 해서, 터미널이 픽셀 단위 스크롤을 지원해도 TUI 프로그램은 줄 단위 스크롤만 지원하고 동작도 제각각임. senpai의 스크롤백은 내가 쓰는 다른 프로그램들과 방식이 달라 자꾸 길을 잃게 됨
인터페이스가 단일 텍스트 패널 이상이라는 정보를 터미널에 드러낼 방법도 없어서 텍스트 선택이 자주 망가짐. 마우스 이벤트를 가로채면 가능하긴 하지만 그건 또 나름 별로임. TUI IRC 클라이언트에서는 텍스트 선택을 하려고 양옆의 잡다한 패널을 숨기는 단축키를 눌러야 했고, 꽤 바보 같은 절차였음
그리드에 맞춰야 한다는 제약은 레이아웃과 디자인 가능성을 크게 제한함. 클릭 가능한 버튼처럼 보이게 스타일링하던 방식, 컨텍스트 메뉴 같은 것들이 떠오름. 예전에 이 문제를 불평한 적도 있음
TUI가 늘어나는 건 전통적 GUI 프레임워크 상태가 좋지 않은 데서 온 안타까운 결과라고 봄. TUI 프레임워크는 비교적 안정적인 편이고, 아주 오래된 걸 써도 크게 거슬리지 않음. ncurses 프로그램은 지금도 자주 쓰지만 Motif 프로그램을 쓰는 모습은 잘 상상되지 않음
반면 GUI 프레임워크는 선택지가 많지 않고 유지보수가 훨씬 더 필요함. 데스크톱 환경은 바뀌고, GUI에 대한 기대도 커짐. TUI 접근성은 정말 별로라고 보지만 확신까지는 못 하겠음. 변화도 심해서 GTK2로 만들었더니 폐기 예정, GTK3로 올렸더니 GTK4로 가라는 식이 반복됨
냉소적으로 보면 Omarchy 같은 것에는 다른 요인도 있음. 일반 GUI인 xfce4-taskmanager는 지루하지만 TUI인 btop은 엄청 해커스러워 보임. 사람들은 터미널 미학을 좋아하고(/r/unixporn 참고), 분위기를 위해 사용성을 희생할 의향도 있어 보임. btop이 프로세스 목록을 실제로 페이드아웃시키는 모습을 보면 그렇다
이제는 진입 장벽이 더 낮아졌기를 바랐음. 대부분의 개발자가 고수준 언어로 훈련받는 상황에서는 설득력이 약해 보이고, C++의 복잡성이 나를 겁먹게 하는 것 같기도 함
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
Matrix 클라이언트인 Nheko는 한 번에 한 줄 넘게 선택도 못 하게 함
반면 IRC 클라이언트들은 기본적으로 이런 형태를 제공함
20:41 <username1> message1
20:42 <username2> message2
가끔은 말이 되지만 이상적으로는 작고 짧게 쓰는 앱이나 텍스트 편집 같은 예외에만 쓰는 편이 좋다고 봄
예를 들어 lf, tig, kakoune은 셸 스크립트와 잘 맞아서 같은 스크립트를 재사용하고 세 앱 모두에서 기능을 확장할 수 있음. 모두 alacritty에서 실행되기 때문에 세 앱과 셸 전반에서 동작하는 하이퍼링크도 만들 수 있음
꿈을 꿀 수 있다면 Emacs나 acme 스타일 통합을 허용하는 단색 미니멀 GUI 도구모음이 있었으면 함
TUI가 어떻게 “자동화하기 쉽다”는 건지 모르겠음. 콘솔에 표시되는 GUI와 같은 것 아닌가?
이 글은 TUI가 “돌아온” 핵심 이유를 놓쳤음. 그 주장 자체도 의심스럽지만, Claude 같은 코딩 에이전트가 대량으로 바이브 코딩되면서 최근 인기가 오른 건 맞아 보임
개발자들은 쉬운 선택을 좋아함. 크로스플랫폼 TUI를 만드는 것이 GUI를 만드는 것보다 쉽기 때문임
웹 앱이 인기를 얻은 이유도 같음. 브라우저 도구로 크로스플랫폼 앱을 만들기 쉬웠기 때문이고, Electron이 뜬 이유도 크로스브라우저 지원 부담을 뺀 같은 맥락임. 반응형 UI를 만드는 일, UI를 크로스플랫폼으로 렌더링하는 일, 사용자 입력을 특히 접근성까지 고려해 처리하는 일은 모두 어려움. 그래서 개발자들은 이런 걸 쉽게 만들어주는 무언가에 바로 뛰어듦
최근에는 TUI 제작을 더 쉽게 만든 변화도 있었음. 고급 기능의 크로스플랫폼 지원이 나아지고, 복잡한 세부사항을 추상화한 유명 라이브러리들이 나왔고, 이런 것들이 최근 TUI 르네상스로 이어진 듯함
그 밖에 글의 논점들은 좀 의심스러움. 예를 들어 저자는 Electron 앱의 약점으로 일관성을 들지만, 인기 있는 TUI에도 관례를 제외하면 일관성은 거의 없음. 코딩 에이전트들은 비슷한 단축키를 채택했지만 대부분 같은 출처인 Claude를 베꼈기 때문임. 그 단축키는 코딩 에이전트 바깥으로는 잘 확장되지 않고, 내가 쓰는 대부분의 TUI는 단축키와 시각 언어가 꽤 다름
“UI를 크로스플랫폼 방식으로 렌더링하는 게 어렵다”는 말도 의문임. 호환 계층이 필요하고 플랫폼 수만큼 구현이 필요하긴 하지만, 단일 플랫폼 지원보다 그렇게 더 어렵지는 않아 보임. 물론 대상 플랫폼들의 렌더링 방식이 너무 달라 공통 API를 설계하기 어려운 경우라면 다르겠지만, 화면에 픽셀을 찍는 수준에서는 그렇지 않을 것 같음. 배율 같은 요소는 처리해야겠지만 그 이상은 꽤 직선적이어야 하고, 아니면 SDL도 있음
아마 모든 플랫폼에서 UI가 “네이티브처럼 보이게” 만드는 이야기를 한 것 같음. 그건 각 플랫폼의 선호 네이티브 GUI 도구모음을 써야 할 수 있고, 서로 매우 다를 뿐 아니라 저수준 렌더링 API보다 훨씬 크고 덜 안정적일 수 있음. 그런 건 인생이 너무 짧음. 색상 테마나 그래픽 스타일 일부를 바꿀 여지는 두겠지만 앱 수준 설정으로 둘 것임. 각 운영체제의 그래픽 설정을 읽느라 시간을 낭비하고 싶지 않음
“사용자 입력, 특히 접근성 처리가 어렵다”는 말도 이상함. 키보드와 마우스 이벤트를 듣는 건 사소한 일임. 접근성 측면에서는 제대로 된 키보드 탐색이 필요하고 전반적 사용성에도 중요하며, 표준 및 사용자 지정 단축키 지원도 필요하겠지만 전체적으로는 나머지보다 훨씬 쉬워 보임
스크린 리더 지원은 관련 플랫폼의 API와 플랫폼 간 차이에 따라 어려울 수 있지만, 그건 입력 문제라기보다 렌더링 문제에 더 가까움
TUI는 “컴백”이라기보다 네이티브 GUI 프로그래밍 지식을 잃어버려서 가진 도구로 최선을 다하는 모습에 가까움. 일관된 개발과 투자가 부족했던 결과임
Qt 같은 몇몇 밝은 예외를 빼면 UI 문명이 붕괴했고 우리는 종말 이후를 사는 느낌임
Preventing the Collapse of Civilization 강연과 운율이 맞는 것처럼 느껴지고, 이제 AI가 많은 코드를 쓰는 상황이라 이런 지식 붕괴가 더 확산될까 걱정됨
컴퓨터 과학판 After Virtue가 필요한 느낌이고, 어쩌면 Blow의 온라인 존재감이 그 역할을 하고 있는지도 모름. 어쨌든 일관성을 보여주고, 사용자를 존중하며, 학습과 정성을 보상하던 컴퓨터 인터페이스의 시절이 그리움
이 글은 실질적인 내용이 별로 없고, 저자가 다른 모든 것이 형편없다고 생각한다는 정도만 말하는 것 같음
한 가지 말하자면 Emacs는 텍스트, 키보드, 버튼, 리치 미디어 인터페이스를 위한 훌륭한 플랫폼임
사람들이 Go, Rust, 이제는 Zig로 ncurses가 아닌 TUI 라이브러리를 쓰기 시작했기 때문일 가능성이 큼. 그래도 ncurses가 필요했던 끔찍한 이식성 문제는 해결해줬음
그러고 나서 사람들은 새 터미널을 만들고 그쪽 기술도 밀어붙이기 시작함. 부분적으로는 C 대신 Go, Rust, Zig로 만들 수 있게 됐기 때문임
C와 C++보다 재미있고 덜 짜증 나는 좋은 선택지를 주면, 당연히 사람들은 더 새롭고 유용한 코드를 쓰기 시작함
TUI가 돌아온 진짜 이유는 2026년에 서명되고 공증된 GUI를 배포하려면 Apple에 돈을 내고 Windows용으로는 인증기관에도 돈을 내야 하기 때문임
세부 정정: Zed의 GPU 가속 UI 라이브러리는 크로스플랫폼 API인 wgpu가 아니라 gpui임
글이 논지를 제대로 입증했는지는 잘 모르겠지만, MS-DOS 시대를 겪었고 TUI를 늘 좋아했던 사람으로서 끼어들어 봄. afl-fuzz를 써봤다면 아마 알 수 있을 것임
이론적으로 Linux에서 TUI는 훨씬 더 성공했어야 함. 텍스트 기반 미학을 좋아하는 기술 사용자층이 있었고, 투박하고 일관성 없는 GUI 환경이라는 “이점”도 있었음. 비디오 카드가 X 서버에서 제대로 동작하게 만드는 것부터가 문제였던 시절도 있었음
동시에 수십 년 동안 *nix 소프트웨어 개발자들은 오래되고 이국적인 터미널 유형까지 지원해야 한다는 의무감을 느꼈음. 애플리케이션이 DECwriter에서 제대로 렌더링되지 않으면 큰일이라도 나는 식이었고, 그런 제약 아래서는 좋은 TUI를 만들기 어려웠음
MS-DOS 시대에는 Microsoft, Borland, Norton 같은 업체들이 기능적이고 반응 빠른 텍스트 기반 인터페이스를 완성했음. Linux에서는 오랫동안 TUI 설계의 “정점”이 menuconfig라는 괴물이었고, 눈을 가늘게 뜨면 vim도 TUI라고 부를 수 있을 정도였음. 사람들이 실제로 텍스트 모드 콘솔을 쓰던 시절에 기억나는 좋은 Linux TUI는 Norton Commander에서 영감을 받은 파일 관리자 Midnight Commander 정도였음