▲

TUI가 다시 돌아온 이유

 (wiki.alcidesfonseca.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 2개
  • 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 의존도를 줄이는 데 도움이 될 수 있음

함께 보면 좋은 글 β

▲
colus001 51분전  [-]

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

답변달기
▲
GN⁺ 3시간전  [-]
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 정도였음

답변달기