TUI가 다시 돌아온 이유

 (wiki.alcidesfonseca.com)
6P by GN⁺ | ★ favorite | 댓글 4개
  • TUI는 즉각적인 피드백, 자동화 용이성, 운영체제 간 동작 가능성 때문에 다시 주목받고 있으며, Claude와 Codex 같은 도구도 명령줄에서 큰 성공을 거둠
  • Windows, Linux, macOS의 네이티브 GUI는 각각 불안정한 API 전략, 툴킷·환경 분산, 과거 가이드라인과의 일관성 약화로 개발자와 사용자 모두에게 부담을 키움
  • Electron 앱은 메모리 사용량보다 시각적 일관성 부족과 키보드 중심 작업 흐름의 빈틈이 더 큰 문제이며, 메뉴와 단축키 통합도 약해짐
  • Google의 Flutter UI 시도와 Zed의 GPUI처럼 새 UI 스택을 만들려는 움직임이 있었지만, 운영체제 통합이 부족하면 빠른 렌더러만으로는 충분하지 않음
  • 좋은 인터페이스는 사용자가 덜 생각하게 만드는 일관성이 핵심이며, 개발자와 운영체제·툴킷 제작자는 UI 이론과 접근성 높은 툴킷에 더 투자해야 함

TUI가 다시 주목받는 배경

  • DHH의 Omarchy는 TUI, 웹앱, gnome 스타일 네이티브 앱이 섞인 형태로 구성되어 있으며, TUI는 즉각적인 피드백과 “geek points”를 위해 쓰임
  • 약 10년 전 코드 편집기에서도 비슷한 흐름이 있었음
    • BBEdit, Textmate, Notepad++, Sublime 같은 네이티브 편집기에서 Atom, VSCode와 그 파생 앱 같은 Electron 기반 앱으로 이동함
    • 강한 선호를 가진 사용자들은 vim이나 emacs로 이동했고, 즉각적인 피드백과 높은 사용성을 얻는 대신 매우 가파른 학습 곡선을 감수해야 했음

네이티브 GUI가 약해진 이유

  • Windows

    • Windows는 일관된 GUI 라이브러리 전략을 만들지 못했고, 하나의 API가 성공하지 못하면 또 다른 API를 만드는 흐름을 반복함
    • Jeffrey Snover는 Microsoft hasn’t had a coherent GUI strategy since Petzold에서 MFC, OLE, COM, ActiveX가 Windows 개발 전반에 복잡성을 퍼뜨렸다고 표현함
    • Microsoft는 이후 WinForms, WPF, Silverlight, WinUI, MAUI를 거쳤지만 성공하지 못했고, 많은 엔터프라이즈·개인용 데스크톱 앱은 여전히 Electron 앱에 의존함
    • Windows 전체가 시각적으로 일관되게 통합되어 있던 마지막 시기는 Windows 98 또는 Windows 2000에 가까움
    • Domenic Denicola는 Windows Native App Development Is a Mess에서 몇 년마다 OS와 UI API를 다시 만드는 비용이 크고, 샌드박싱과 기능 폐기 시도가 겹치면서 새 계층마다 이전 프레임워크에서 가능했던 일을 못 하는 빈틈이 생긴다고 봄

  • Linux

    • Linux의 UI 불일치는 설계상 생긴 결과에 가까우며, 서로 다른 팀이 서로 다른 목표를 추구할 자유를 가졌음
    • GTK와 Qt가 주요 프레임워크가 되었고, 둘 다 크로스플랫폼 네이티브 개발을 지향했지만 널리 쓰이는 영역은 주로 Linux임
    • 서로 다른 툴킷으로 만든 Linux 앱은 나란히 놓아도 어느 정도 괜찮아 보일 수 있지만, Windows의 여러 프레임워크는 그런 수준의 조화를 이루지 못함
    • 배포판, 데스크톱 환경, 하드웨어 조합이 너무 많아 테스트가 어렵기 때문에 많은 회사는 네이티브 Linux 앱을 만들지 않음
    • 회사들은 보통 Electron으로 Linux를 지원하거나, 공개 API가 있을 때 오픈소스 커뮤니티가 직접 해결하도록 둠

  • macOS

Electron 앱의 한계

  • 가장 많이 거론되는 문제는 메모리 사용량이지만, 지난 10년 동안 메모리 사용량은 줄어드는 추세였음
  • 더 큰 문제는 시각적 일관성 부족과 키보드 중심 작업 흐름의 부족임
  • 64GB RAM MacBook Pro를 쓰는 환경에서도 Dock에는 네이티브 앱 8개와 Electron 앱 6개가 함께 있음
    • 네이티브 앱: TextMate와 macOS 시스템 유틸리티
    • Electron 앱: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
  • Cursor와 VSCode 같은 앱에서는 에이전트 패널에서 기능을 요청한 뒤 키보드만으로 사이드 패널의 에이전트 목록으로 이동하거나 보관하는 작업이 자연스럽지 않음
  • 이런 동작은 모든 macOS 앱에서 같은 방식으로 가능해야 하지만, 단축키가 있더라도 메뉴에 표시되지 않는 경우가 있음
  • 지난 10년 동안 개발자들은 앱에서 가능한 동작을 메뉴에도 추가하는 일을 잊는 경향이 생겼고, 이는 애플리케이션이 샌드박스 안의 HTML로 구현되는 구조와 연결됨
  • Slack은 다른 Electron 앱보다 이런 부분을 더 잘 처리하지만 완벽하지는 않음

새 UI 스택을 다시 만드는 시도

  • Google은 Dart와 함께 Android의 유산이 없는 새 운영체제와 새 기기용 UI 툴킷을 만들고자 했음
  • Google은 Flutter UI라는 새로운 UI 툴킷을 원했지만, 실제 제품이 출시되기 전에 프로젝트를 포기함
  • 이런 시도는 독점적 지위나 충분히 큰 시장 점유율이 있어야 성공할 수 있음
  • Zed는 Rust로 비슷한 방향을 택해 자체 GPU 렌더러 라이브러리인 GPUI를 만들었고, 이 라이브러리는 크로스플랫폼을 지향함
  • GPUI는 속도가 빠르지만 호스트 운영체제와의 통합이 자체적으로 충분하지 않아 개발자가 필요한 바인딩을 직접 추가해야 함
  • 빠른 렌더러보다 운영체제와 잘 통합되는 느린 렌더러가 더 나음

TUI가 채우는 빈틈

  • Apple Automator의 쇠퇴를 떠올리게 하는 맥락에서, TUI는 자동화 가능한 인터페이스로 다시 중요해짐
  • TUI는 원격 실행도 비교적 쉽고, 두통을 유발하는 X forwarding에 의존하지 않아도 됨
  • 네이티브 UI 툴킷이 실패하면 기본으로 돌아가게 되고, 그 결과 TUI가 선택지로 부상함
  • Claude와 Codex는 명령줄에서 큰 성공을 거뒀고, 사용자는 주변 운영체제를 신경 쓰기보다 상호작용 자체에 집중할 수 있음
  • TUI를 통해 클라우드 머신에서 코드와 앱을 다루거나, iPad에서 GPU가 탑재된 머신으로 원격 접속할 수도 있음
  • TUI는 모든 애플리케이션이 서로 다르게 보이는 환경에서 Apple과 Microsoft가 남긴 빈틈을 채우고 있음
  • 서로 다른 외형은 예술이나 컴퓨터 게임에는 좋을 수 있지만, 사용자가 자기 일을 하도록 인터페이스가 물러나야 하는 목적에는 적합하지 않음

앞으로 필요한 방향

  • John Loeber는 Bring Back Idiomatic Design에서 체크박스도 시스템과 상호작용하기 위한 인터페이스이며, 좋은 인터페이스는 사용자가 덜 생각하게 만드는 것이라고 봄
  • 사용자는 많은 것과 상호작용하므로, 일관된 경험을 주는 동질적인 인터페이스가 필요함
  • Command+C가 복사 단축키라면 어디서나 작동해야 하며, 특정 상황에서 CTRL+Shift+C나 우클릭 → 복사를 따로 기억해야 하는 방식은 불편함
  • 모든 개발자는 소프트웨어뿐 아니라 일반적인 사용자 인터페이스를 좋게 만드는 이론을 배워야 함
  • 사용자 디자인을 소프트웨어 공학 교육과정에서 중요하지 않은 소프트 스킬처럼 다루는 태도는 멈춰야 함
  • 어떤 과정에서든 UI가 이해되지 않으면 프로젝트는 실패 처리되어야 하며, HCI 과정에서는 완벽한 UI를 목표로 해야 함
  • 좋은 UI를 만드는 작업은 필요를 이해하는 데 대부분의 노력이 들어가며, 프로그래밍 자체는 이미 자동화되고 있음
  • 운영체제와 툴킷 제작자는 개발자가 쓰고 싶어 하는 접근성 높은 툴킷을 만들고 진입 장벽을 낮추는 투자를 이끌어야 함
  • 반드시 크로스플랫폼 지원을 주장하는 것은 아니지만, 그런 해법이 하나라도 있다면 Electron과 TUI 의존도를 줄이는 데 도움이 될 수 있음
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

colus001   [-]

저도 그렇지만, 개발씬은 과도하게 유행에 민감하다고 생각합니다. TUI 는 그저 GUI 를 제대로 만들 능력 혹은 의지가 없는 회사들이 주도하고 있을 뿐, 얼마나 많은 사람들이 TUI 를 쓰고 있는건지 모르겠네요.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 숫자만 보면 TUI가 인기 있는 진짜 이유는 Claude Code이고, 나머지는 그에 비하면 배경 소음에 가깝다고 봄
    처음 TUI를 만들고 싶어졌던 건 SSH를 통해 앱을 전달한다는 개념 때문이었음. SSH 앱은 로컬 설치가 필요 없다는 점에서 브라우저와 닮아 있음
    https://pico.sh를 재미있게 만지는 큰 이유도 TUI 배포에 사용자 개입이 전혀 필요 없기 때문임

    • 그건 아닌 것 같음. 새 TUI 프로그램이 늘어나기 시작한 시점은 Claude Code가 본격적으로 뜨기 전으로 보임
    • Claude Code가 흐름을 백 배쯤 증폭시킨 건 맞지만, go fzf, Rust ratatui, Python Rich 시절부터 이미 TUI는 크게 늘고 있었음
      무거운 브라우저 기반 UI를 벗어나고 싶다는 욕구와, 터미널 렌더링의 한계를 시험해보고 싶은 호기심이 원인일 것 같음
    • SSH로 앱을 배포하는 발상은 이해하지만, 직렬 포트 타자기 에뮬레이터가 여기까지 살아남은 건 아쉬움
      새롭고 흥미로운 기술로 새 시스템을 만드는 대신 GPU 가속 타자기 에뮬레이터를 만들고 있음. 향수와 기술적 맹목이 섞인 이상한 형태임
      SSH 위로는 어떤 프로토콜이든 흘려보낼 수 있음. 차라리 원격 비트맵 디스플레이에 그리는 쪽으로 나아가면 좋겠음
      X Window는 설계가 훌륭하진 않았지만 네트워크 투명성이 있었고, Plan 9의 devdraw는 원격 그래픽 프로그램이 자산을 올린 뒤 선 그리기 명령을 RPC로 보내는 렌더링 엔진이었음
    • 순수 CLI나 GUI 대신 TUI 앱을 쓰고 싶어지는 동기는 여전히 SSH로 사용할 수 있다는 점임
    • TUI가 인기 있는 이유가 모두가 Claude Code를 따라 하려 해서라는 뜻인지, 아니면 Claude Code 덕분에 TUI 개발이 쉬워졌다는 뜻인지 궁금함

  • vim에서 정말 어려운 건 모달 편집기에서 가장 핵심인 명령 모드 복귀를 위해 손가락을 Escape까지 뻗어야 한다는 점뿐임
    이상적인 흐름은 빠르게 편집하고 즉시 명령 모드로 돌아가는 것인데, Escape를 쓰는 건 역사적 잔재라 짚고 넘어가야 함
    그래서 CapsLock을 Escape로 전역 재매핑하면 됨. Linux와 macOS는 GUI 설정만으로 가능하고, Windows도 레지스트리 키를 만들거나 수정하면 1분 안에 끝남
    그 외에는 vim-tutor로 기본기를 익히고, 시간이 오래 걸리는 작업이 생길 때 찾아보면 되므로 학습 곡선이 어디에 있는지 잘 모르겠음. 문제는 모달 편집에 너무 빨리 익숙해져서 없는 환경이 석기시대처럼 느껴진다는 점임

    • 여러 노트북을 자주 오가며 작업해야 하면 CapsLock을 Escape로 재매핑하는 게 꽤 큰 마찰이 됨. 근육 기억이 계속 방해함
    • CapsLock을 Escape로 바꾸게 만든 사람 중 다시 돌아간 사람을 못 봤음. 체감이 완전히 다름
      요즘은 vim에 hjkl이 필요한 이유가 사실 키보드 배열이 화살표에 나쁘기 때문이라고 생각함. 타자기에는 화살표가 없었지만 컴퓨터에서는 화살표가 핵심임
      스페이스바가 그렇게 클 필요도 없고 양 엄지 모두가 쓸 이유도 없음. 작은 화살표 묶음을 스페이스바의 왼쪽이나 오른쪽 일부 위치로 옮기면 훨씬 나을 것 같음
      hjkl 해킹은 해커용 편집기에서만 통하지만 일반 소프트웨어에서도 화살표를 많이 써야 하고, 지금 배열은 손에 매우 나쁨. 손 전체를 옮기지 않고 엄지로 화살표를 누르려다 염증이 생기기 시작했음
    • 이상하게도 Esc가 멀리 있는 게 효율 때문은 아니고 인체공학적으로 마음에 듦
      손을 들어 홈 포지션에서 벗어났다가 다시 놓게 만들어서, otherwise 가만히 쌓일 RSI 포인트를 줄여줌
      같은 이유로 다른 손은 화살표 키도 자주 씀. 물론 hjkl도 꽤 쓰긴 함
    • Windows라면 PowerToys에 꽤 괜찮은 키보드 재매핑 도구가 들어 있음
      https://github.com/microsoft/PowerToys
    • 손가락이 이미 홈 포지션에 있으니 jj로 매핑하면 끝임
      또 Ctrl + [는 표준 터미널/ASCII에서 Esc라서, Esc까지 손을 뻗는 것보다 좀 더 편할 수 있음

  • 운영체제 업체들의 자기 이익이 무너지며 남은 잿더미가 TUI 유행처럼 보임
    좋은 범용 UI는 하나도 없음. 그나마 브라우저가 가장 낫고 꽤 성공했지만, 샌드박스 때문에 로컬 파일이나 네트워크 접근이 필요한 일에는 부적합하거나 마찰이 큼. 단순한 것을 실행하기엔 오버헤드도 말도 안 되게 큼
    원격 접근은 더 엉망임. Windows 호스트에서 실행 중인 앱을 Mac에서 접근할 수 있는지, 터널 연결로 포워딩할 수 있는지 같은 문제가 생김
    TUI는 필요한 것을 해주는 단순한 범용 프로토콜이고 원격성이 기본임. 로컬에서 쓰는 것이 SSH 연결 위에서도 자연스럽게 동작함
    모든 것을 호환 안 되게 만들거나 생태계에 묶어두는 전략이 이긴다고 생각한 운영체제 업체들에게 보내는 큰 가운데손가락이기도 함

    • TUI는 사용자가 이해하기 쉽고, 자원뿐 아니라 조작 측면에서도 효율적이며, 좋은 터미널에서는 보기에도 좋음
      Notcurses와 Ratatui가 ncurses에 큰 도움을 줬음
    • 현대의 터무니없는 GUI 환경이 실패했기 때문에 xfce4 같은 미니멀 데스크톱 환경으로 계속 돌아오게 됨
      Windows 11이 아주 좋은 예시고, 그 모든 과장이 정말 필요하지 않음

  • TUI가 돌아오지 않았으면 좋겠음. 어떤 날이든 TUI보다 웹 인터페이스를 택하겠음
    지나치게 영리한 폰트를 설치할 필요도 없고, 제대로 표시되도록 터미널 설정을 만질 필요도 없고, 만든 사람이 최고라고 생각한 탐색 단축키를 추측할 필요도 없음
    운영체제 표준 텍스트 탐색이 되는 진짜 텍스트 편집, 비밀번호 관리자와 텍스트 확장기 등과의 더 나은 통합도 있음
    CLI 안에서 살고 단축키 하나로 터미널을 띄우지만, 터미널이 유일한 선택지였던 시절 이후 기술은 크게 발전했고 UI를 만들 더 나은 선택지도 많음

    • 웹 인터페이스도 더 낫지 않음. 기능보다 미학을 위해 설계되고, 각자 배워야 하는 고유한 UI 관용구도 있음
    • 수십 년 동안 vim과 Emacs를 썼지만 몇 년 전 GUI로 옮긴 뒤로는 돌아갈 생각이 안 듦
      이 TUI 유행 전체가 그냥 패션 트렌드처럼 보임

  • 아무도 네이티브 UI 개발에 투자하지 않기 때문임. Electron은 쓰기 쉬운 GUI 스택이 있다면 회사들이 채택한다는 증거임

    • 글에서는 Google이 실제 제품 출시 전에 포기했다고 하지만, Flutter 작업은 계속되고 있고 채택도 늘고 있다고 봄
    • 작은 유틸리티, 예를 들어 정규식으로 파일을 검색하는 도구를 만들 때가 최악임
      큰 앱이라면 패키징과 배포에 드는 시간이 전체에서 작고 파일 크기도 별로 신경 쓰지 않지만, 작은 앱은 그렇지 않음
      Windows용 앱은 쉽고, 작은 바이너리가 폼을 열고 더블클릭으로 실행되며 설치도 필요 없음
      Linux에서 같은 걸 하려면 GTK나 Qt가 설치되어 있다는 보장이 없어서, 독립 실행형으로 만들려면 사실상 운영체제 전체를 같이 보내야 함. 그러면 파일 크기가 커짐
      Python도 Windows 사용자에게 Python이 있어야 하거나 인터프리터를 같이 보내야 해서 곤란함
      그나마 가능한 대안은 Java처럼 단일 .jar 파일을 어떤 시스템에서든 실행하는 방식인데, Oracle이 라이선스를 바꿨고 JavaFX는 더 이상 Java에 포함되지 않음. Swing은 아직 포함됨
      그냥 키보드 단축키가 있는 메뉴바를 보여주고 싶을 뿐인데 왜 모든 운영체제에서 메뉴바에 접근하게 해주는 메뉴바 VM 같은 게 없는지 모르겠음
      Electron으로 브라우저 전체를 보내고 있는 건 바보 같은 일임. 사용자가 Flash의 데스크톱 앱 버전 같은 플랫폼을 설치하고, 모든 앱이 그걸 쓰는 방식이어야 함
      DOS 게임을 배포하는 게 데스크톱 앱보다 쉬울지도 모름. DOS 게임을 돌리고 싶은 사람은 DOS 에뮬레이터를 이미 설치해둘 테니까
    • 투자 부족이라기보다 제대로 된 것을 만들지 않았기 때문에 가까움
      필요한 것은 쓰기 쉽고, 크로스플랫폼이며, 오픈소스이고, 가능하면 선택한 프로그래밍 언어에서 쓸 수 있는 프레임워크임
    • Zed는 실제로 그렇게 했음. 팬이 있는 건 알지만, GUI 시스템을 바닥부터 만들기 위해 엄청난 노력을 들인 것치고는 채택이 폭발적으로 늘어나는 것 같지는 않음
    • wxWidgets와 Qt는 괜찮지 않나 싶음. GTK 2와 3도 괜찮고, 4 이상은 좀 별로임. 이들 중 하나를 쓰는 앱도 많고, Python 바인딩을 통해 쓰는 경우도 흔함
      더 큰 문제는 인력임. 웹 개발을 아는 사람이 많으니 데스크톱에도 그 인력을 쓰고 싶어지고, 데스크톱이 JavaScript인 Electron이면 그게 훨씬 쉬워짐

  • GUI 같은 기능을 다시 만들려는 터미널 UI는 잘 이해가 안 됨. 컴퓨터 인터페이스는 더 좋아져야 하는 것 아닌가
    이제 선과 도형을 그리는 척하려고 문자 격자에 제한될 필요가 없음. Kitty나 iTerm 같은 비표준 터미널 없이는 이미지 표시조차 못 함
    훌륭한 크로스플랫폼 스트리밍 UI 시스템이 없다는 게 아쉬움. 웹은 나름대로 훌륭하지만 이 목적에는 분명 더 나은 무언가가 있을 수 있음. Flutter는 괜찮지만 온디맨드성이 부족하고 Dart에 너무 묶여 있음

    • 이건 현대 GUI 환경의 실패 때문임
      사람들은 GUI를 원하지만 결국 TUI 안의 GUI 같은 것으로 우회해야 함
      휴대 가능하고, 원격 실행 가능하며, 소켓을 노출하지 않아도 더 안전하게 실행할 수 있고, 전체 데스크톱을 띄우지 않아도 되는 무언가를 원함
      루트 없는 창은 사실상 죽었고, 남은 건 웹 인터페이스와 그 모든 문제, 아니면 모두가 이미 가진 SSH 연결만 있으면 되는 TUI임
      예전에는 Tcl/Tk로 대충 만들고 X Window로 창을 띄우면 됐지만, 오늘날엔 쉽지 않고 원격 X를 쓰는 사람도 없음
      최소공배수는 SSH이고, 거기에 맞는 것들만 살아남음
    • 이미지 표시에 대해 말하자면 Sixel은 많은 터미널에서 지원됨[0]
      지원하지 않는 것으로 언급된 여러 터미널도 GNOME VTE 기반인데, 그쪽 지원은 작업 중이고 버그 트래커를 보면 거의 끝난 것 같음
      X11에서 가장 표준 터미널에 가까운 xterm도 여기에 포함됨
      [0] https://www.arewesixelyet.com/
    • TUI는 일을 끝내기 쉽기 때문임. 제대로 된 GUI를 만들면 코드베이스가 갑자기 훨씬 복잡해짐
      탄탄하고 믿을 만한 GUI 툴킷이 있는 것도 아니고, 모두 서로 다른 버그와 주의점으로 가득함
      Flutter는 괜찮다고 하지만, Flutter로 앱을 빌드하는 과정 자체가 악몽이라는 점을 무시해야 함. Flutter 자체도 아무나 컴파일하도록 설계된 느낌은 아니고, 실제로는 배포판이 그 문제를 가려줄 뿐임
    • 크로스플랫폼 스트리밍 UI 시스템은 웹/Jupyter라고 부를 수 있음
      그리고 웹 기반 UI가 꼭 무거워야 하는 것도 아님. HN이 그렇지 않은 것처럼
    • SSH 위에서는 텍스트가 빠르기 때문임. RDP, VNC 같은 그래픽 다시 그리기는 장기적으로 더 느리고 번거로움

  • 항상 터미널을 열어두고, Bash 스크립트로 삶을 자동화하며, VIM/TMUX를 쓰는 입장에서도 대부분의 TUI는 괜찮은 GUI보다 두 걸음 뒤처짐
    제멋대로인 탐색과 단축키, 망가진 복사·붙여넣기, 환경 통합 부족이 대표적임
    핵심 문제는 프로그래밍 언어에 제대로 통합되었거나 표준 라이브러리 일부인 괜찮은 크로스플랫폼 GUI 플랫폼이 없다는 것임
    Swing은 네이티브 브라우저 요소 접근이 부족하고, Tk는 브라우저 컴포넌트와 드래그 앤 드롭이 부족하며, wxWidgets는 커뮤니티가 작고 바인딩도 한 번 이상 되살려야 했던 것으로 보임
    Qt는 언제든 돈을 더 벌려고 망가질 가능성이 있고, KDE가 그렇게 중요하다고 보지도 않으며 KDE 커뮤니티가 장기적으로 포크를 감당할 수 있을지도 의심스러움
    남는 것은 Electron이나 브라우저 컴포넌트에 JavaScript/CSS를 얹고 로컬 서버 콜백을 붙이는 변종들인데, 사소한 앱에도 메모리와 런타임 오버헤드가 큰 건 차치하더라도 프로그래밍 모델 자체가 나쁨
    제대로 된 크로스플랫폼 GUI 툴킷을 만들려면 사용성, 접근성, 디자인, 문서화, 테스트까지 많은 돈과 사람이 필요함. 오픈소스 커뮤니티는 이를 해내지 못했고 GTK는 사실상 Linux 전용이 되었으며, Qt나 Swing을 대체할 현대적 후보도 없음
    TUI가 핵심 문제의 해법은 아니지만, 대안들을 보면 크로스플랫폼 UI를 위해 TUI를 고르는 개발자들은 이해됨. GUI 요구의 80% 정도는 TUI 렌더러가 있는 GUI 툴킷으로도 충분히 가능할 것 같음

    • 프로그래밍 언어가 아니라 C API로 제공되어야 함
      그래야 안정적인 API와 ABI를 제공할 수 있고, 다른 여러 언어에서 복잡한 우회 없이 바인딩할 수 있음. 특히 컴파일 언어에서는 더 중요함
      Qt를 Python에 바인딩하는 건 쉬울 수 있지만 Free Pascal 같은 언어에 붙이려면 C API를 노출하는 중간 C++ 라이브러리가 필요하고, 앱은 그 라이브러리까지 배포해야 함
      안타깝게도 GUI 툴킷 대부분은 C가 아니라 C++나 다른 언어로 작성되어, 개발자가 좋아하는 언어가 아니면 쓰기 고통스럽게 만듦. 주류 중 C로 작성된 거의 유일한 것은 GTK인데, GTK는 적절한 하위 호환성을 거의 신경 쓰지 않음
      라이브러리는 C API만 노출하면 어떤 언어로 작성돼도 된다고 생각할 수 있지만, 널리 배포되어 있지 않은 것이라면 정적 링크를 원할 수 있음. 그런데 C/C++ 밖에서는 이게 문제가 됨
      예를 들어 Lazarus용 FLTK 백엔드를 만들려 했는데[0], FLTK는 C++ 라이브러리고 정적 링크를 권장하므로 독립 실행형 GUI 바이너리를 만들 수 있을 것 같았음
      하지만 C 래퍼를 먼저 만들어야 했고, Linux에서 g++가 링커에 넘겨주는 마법 플래그 없이 C++ 라이브러리를 비 C/C++ 언어에서 정적으로 링크하는 건 고통스러웠으며, Windows나 적어도 msys2에서는 불가능해서 포기함
      [0] https://i.imgur.com/W6XbLkr.png
    • 대부분 동의함. 특히 wxWidgets는 정말 아쉬움
      macOS와 Windows에서 네이티브 외형에 매우 가깝고, Qt보다 훨씬 프로그래밍하기 쉬움. 사용자로서도 가끔 프로그래머로서도 다중 플랫폼 GUI에는 wxWidgets를 가장 선호함
      반대로 Electron이나 브라우저 컴포넌트와 JavaScript/CSS, 로컬 서버 콜백 조합은 사용자로서 정말 싫음. 기능을 포기하고 명령줄로 돌아가더라도 이런 앱은 피하고 싶음
      표준 키보드 단축키도 지원하지 않고, 생긴 것도 이상하게 튀며, 예상치 못한 곳에서 버벅임
      TUI 프레임워크 중에는 거의 그 경지에 다다른 것들도 있음. SSH 등에서 별다른 수고 없이 쓸 수 있다는 점은 좋지만, 잘못된 문제를 푸는 것 같음
      모든 것을 IDE처럼 보이거나 동작하게 만들기보다, 창 관리와 지속성 부분이 덜 형편없는 tmux 같은 것과 더 집중적이고 조합 가능한 CLI를 쓰고 싶음
      readline이 붙은 단순한 REPL을 만들면 표준적이고 예상 가능한 동작을 얻을 수 있음
      그래도 이 흐름이 터미널 에뮬레이터 개선을 밀어붙이는 점은 마음에 듦

  • 살펴본 TUI들은 대체로 NPM 의존인 것 같음
    에이전트들이 보안 타이어 화재가 아닌 무언가로 자기 자신을 다시 쓸 시간조차 없는 것처럼 보여서 이상함
    이 모든 에이전트가 무언가를 장악한다는 흐름은 결국 충분히 빠르지 못한 것 말고는 별 결과를 걱정하지 않아도 되는 쓰레기-전환-쓰레기 스타트업 사람들이 만든 것이라고 생각하게 됨

    • LLM 주변 소프트웨어의 99%는 계속 망가진 채 흔들리는 웹 찌꺼기임
      예를 들어 OpenCode는 아직도 모든 메시지 로그를 유지하고 그 로그를 같은 순서로 SSE 엔드포인트에 보내 다음 응답을 받는 기본을 제대로 못 했고, 문맥 가지치기를 꺼도 프롬프트 캐시 미스가 자주 남
    • Go + Lipgloss + Bubbletea가 보기 좋고 사용 가능한 TUI를 만들거나 생성하는 데 가장 견고하고 성능 좋은 스택임
      개발자 경험도 훌륭하고 npm이 필요 없음
    • curl | bash로 돌아가던 평화로운 보안의 시대여
    • 맞음. 모든 것에 AI를 넣는 데 열광하는 사람들은 거의 JavaScript/TypeScript 개발자이고, 보통 스타트업에서 일하며, AI 분야인 경우도 많음

  • 소프트웨어 개발자가 사용자 인터페이스를 설계하도록 허용되는 것 자체가 이상함
    텍스트가 아닌 사용자 인터페이스를 만들 능력이 없는 것 같음. 배관공이 집을 설계하면 배관이 지나가기 쉽도록 모든 바닥을 아래로 기울여 만들 것 같은 상황임
    여러 창을 움직이고 크기 조절해야 한다면 텍스트 창을 만들고, 빠르게 옵션을 선택해야 하면 텍스트 상자를 만들며, 스타일과 서식이 있는 문서를 빨리 작성해야 하면 서식을 위해 더 많은 텍스트를 쓰게 함
    그런데 정작 그 텍스트를 서식 적용된 상태로 쉽게 볼 앱은 만들지 않음

    • 허용이라니, 이런 오픈소스 TUI 프로젝트 대부분은 자기 문제를 해결하려던 개인이나 작은 팀이 시작한 것임
      허용되는 일이고, 쓰지 않으면 됨
    • 반대쪽 끝에는 Material과 어느 정도 Adwaita가 있음
      보기에는 예쁘지만 앱 스타일 개발이나 파일 관리자 정도를 넘는 복잡한 일에는 거의 쓸모없음
    • 무슨 소리인지 모르겠음. 개발자에게 괜찮은 디자인 시스템을 주면 충분히 잘 만들 수 있음

  • 터미널 안에서 사는 사람들에게 TUI가 좋기 때문임
    시각 콘텐츠로 인한 산만함이 없고, 키보드로 극도로 효율적이며, 이제는 AI가 빠르게 만들어줄 수 있음. 예전에는 정말 고통스러웠음

    • AI가 빠르게 만들어줄 수 있다는 점이 가장 크고, 사실상 유일한 이유라고 봄
    • 이에 대한 귀결은 터미널 안에서 지내는 데 익숙한 사람이 더 많아졌다는 것임
      TUI의 청중이 늘었기 때문에 TUI도 더 흔해졌음
    • TUI에는 세련되고 현대적인 외형을 위해 끝없는 패딩을 넣을 공간이 없음
      80열 텍스트 안에서 제품 관리자가 간소화할 수 있는 것도 거의 없음
답변달기
savvykang   [-]

어떤 빅테크도 브라우저를 버리지 않는 상황이 잘못된거 아닌가요

답변달기
GN⁺   [-]
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이 프로세스 목록을 실제로 페이드아웃시키는 모습을 보면 그렇다

    • 웹 개발을 오래 하다가 네이티브 애플리케이션 개발을 해보고 싶었음. 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 정도였음

답변달기