TUI가 다시 돌아온 이유

1 week ago 6

(wiki.alcidesfonseca.com)

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
- Apple의 Human Interface Guidelines는 전 세계 사용자 인터페이스 수업에서 인용될 정도로 강한 기준이었음
- Xerox PARC와 Apple은 좋은 인간 인터페이스가 무엇인지 연구한 대표적 기관으로 꼽힘
- 최근 Apple은 과거의 가이드라인과 일관성을 깨는 방향으로 움직이고 있음
- macOS는 Fitts의 법칙을 무시하고, 창 크기 조절을 거의 불가능하게 만들며, 수정을 시도한 뒤에도 문제가 이어지고, 모든 메뉴에 아이콘을 추가하는 방향으로 가고 있음
- 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나 우클릭 → 복사를 따로 기억해야 하는 방식은 불편함
모든 개발자는 소프트웨어뿐 아니라 일반적인 사용자 인터페이스를 좋게 만드는 이론을 배워야 함
- Nielsen
- Norman
- Johnson
사용자 디자인을 소프트웨어 공학 교육과정에서 중요하지 않은 소프트 스킬처럼 다루는 태도는 멈춰야 함
어떤 과정에서든 UI가 이해되지 않으면 프로젝트는 실패 처리되어야 하며, HCI 과정에서는 완벽한 UI를 목표로 해야 함
좋은 UI를 만드는 작업은 필요를 이해하는 데 대부분의 노력이 들어가며, 프로그래밍 자체는 이미 자동화되고 있음
운영체제와 툴킷 제작자는 개발자가 쓰고 싶어 하는 접근성 높은 툴킷을 만들고 진입 장벽을 낮추는 투자를 이끌어야 함
반드시 크로스플랫폼 지원을 주장하는 것은 아니지만, 그런 해법이 하나라도 있다면 Electron과 TUI 의존도를 줄이는 데 도움이 될 수 있음