왜 TUIs가 돌아왔는가

Source: Hacker News

Overview

DHH’s Omarchy is made of three types of user interfaces:

• TUIs – 즉각적인 피드백과 보너스 깃발 포인트를 위해
• Webapps – 37signals(그의 회사)가 SaaS 웹 애플리케이션을 판매하기 때문에
• Native applications – 배포판 스타일에 잘 맞지 않는 피할 수 없는 GNOME‑style 앱

같은 패턴이 약 10년 전 코드 편집기에서도 나타났습니다. 우리는 BBEdit, TextMate(또한 DHH가 홍보한), Notepad++ 및 Sublime과 같은 네이티브 편집기에서 Atom, VS Code 및 그 포크와 같은 Electron‑powered 앱으로 이동했습니다. 하드코어 사용자들은 Vim이나 Emacs로 옮겨가며, 즉각적인 피드백과 높은 사용성을 가장 가파른 학습 곡선과 교환했습니다.

윈도우

교훈은 명확합니다: 네이티브 애플리케이션이 점점 사라지고 있다는 것입니다. 윈도우는 GUI‑라이브러리‑표준이라는 농담을 하고 있습니다—하나의 API가 실패하면 또 다른 API를 만들어 내지만, 그 역시 존재하는 수많은 대안들 사이에서 실패합니다.

• MFC (1992) 는 Win32를 C++로 감쌌습니다. Win32가 우아하지 못했다면, MFC는 다른 턱시도를 입은 Win32와도 같았습니다.
• 그 뒤를 이은 OLE, COM, ActiveX. 이들은 실제 GUI 프레임워크라기보다 컴포넌트 아키텍처였지만, 윈도우 개발의 모든 구석에 퍼져 인지적 복잡성을 높여 마치 키에케거드가 헤밍웨이처럼 읽히게 만들었습니다.

“— Jeffrey Snover, in Microsoft hasn’t had a coherent GUI strategy since Petzold”

그 이후 마이크로소프트는 WinForms, WPF, Silverlight, WinUI, MAUI 를 차례로 도입했지만 지속적인 성공을 거두지는 못했습니다. 많은 기업 및 개인용 데스크톱 애플리케이션이 여전히 Electron에 의존하고 있으며, 제가 기억하는 전체 OS의 일관된 시각적 통합은 Windows 98이나 2000 시절에 국한됩니다.

“— Domenic Denicola, in Windows Native App Development Is a Mess*”

몇 년마다 OS UI API를 다시 만드는 일은 엄청난 작업입니다. 간헐적인 샌드박싱 시도와 “너무 강력한” 기능을 폐기하려는 노력과 결합되면서, 각 새로운 레이어는 이전 프레임워크에서 가능했던 일을 할 수 없는 빈틈을 남깁니다.

Linux

Linux의 UI 불일치는 설계상 의도된 것이었다. 서로 다른 팀들이 서로 다른 결과를 원했고 구현의 자유가 있었다. GTK와 Qt가 두 주요 프레임워크가 되었다. Qt가 더 유명하지만, 두 프레임워크 모두 크로스‑플랫폼 네이티브 개발을 지원한다(예전에 Windows에서 gedit을 성공적으로 컴파일하면서 C 컴파일, 메이크파일, 환경 변수에 대해 많이 배운 적이 있다) 하지만 주로 Linux에서 사용된다.

다행히도 서로 다른 툴킷으로 만든 애플리케이션도 나란히 놓였을 때 “괜찮은” 수준으로 보일 수 있다—이는 서로 다른 Windows 프레임워크들이 달성하지 못하는 점이다. Windows 제어판을 다시 만들려면 엔지니어 시간이 얼마나 걸릴까?

수많은 배포판, 데스크톱 환경, 하드웨어 조합을 테스트하는 것이 어려워 대부분의 기업은 네이티브 Linux 애플리케이션을 회피한다. 그들은 Electron 앱을 배포하거나(잠금 상태를 만들면서) 오픈 API가 존재할 경우 오픈소스 커뮤니티가 스스로 문제를 해결하도록 맡긴다.

macOS

Apple은 한 권의 책으로 된 종교와도 같았다. Apple의 Human Interface Guidelines는 전 세계 모든 UI 강좌에서 인용되었다. Xerox PARC와 Apple은 인간 친화적인 인터페이스가 무엇인지 연구한 두 기관이었다. 몇 십 년이 흐른 지금, Apple은 한때 알려졌던 모든 가이드라인과 일관성을 깨뜨리기 위해 최선을 다하고 있다.

이제 Apple은:

• Fitts’ law을 무시하고 있다 (Hacker News discussion)
• 창 크기 조정을 거의 불가능하게 만들고 있다 (January 2026 post, February 2026 follow‑up)
• 모든 메뉴에 아이콘을 추가하고 있다 (Tonsky’s blog)

macOS는 이제 디자이너가 평화롭게 작업할 수 있는 안전한 피난처가 아니다.

Electron

모두가 Electron 앱의 사용자 경험이 형편없다는 것을 알고 있습니다. 가장 흔한 불만은 메모리 사용량이며, 이는 지난 10년 동안 감소해 왔습니다. 64 GB RAM MacBook Pro를 사용하는 사람으로서 제가 가장 크게 느끼는 불만은 시각적 일관성 부족과 키보드‑주도 워크플로우입니다.

Dock을 보면, 네이티브 앱이 여덟 개(텍스트메이트와 macOS 시스템 유틸리티)와 Electron 앱이 여섯 개(슬랙, 디스코드, 매터모스트, VS Code, 커서, Plex AMP) 있습니다. 그리고 이는 Electron 앱을 전혀 쓰고 싶어 하는 사람의 경우입니다.

Cursor(VS Code에도 동일하게 적용됩니다)를 예로 들어 보겠습니다. 에이전트 패널에서 다음 기능을 요청하고 있을 때, 키보드만으로 사이드 패널에 있는 에이전트 목록으로 이동할 수 있나요? 그것을 아카이브할 수 있나요? 이러한 동작은 모든 macOS 애플리케이션에서 동일해야 하지만, 단축키가 존재하더라도 메뉴에 표시되지 않는 경우가 많습니다. 지난 10년 동안 개발자들은 HTML‑기반 샌드박스 UI에서 이미 제공되는 동작에 대한 메뉴를 추가하는 것을 잊어버렸습니다. 참고로, 슬랙은 다른 앱들보다 이 부분을 더 잘 처리하지만 여전히 완벽하지는 않습니다.

처음부터 다시 시작하기

Dart와 함께 Google은 새로운 장치용으로—Android의 유산 없이—새로운 운영 체제를 설계하고 싶었습니다. 신선한 UI 툴킷(Flutter UI)을 목표로 했지만, 실제 제품이 출시되기 전에 Google은 프로젝트를 포기했습니다. 이는 유망한 백지 상태의 시도가 결코 실현되지 않은 경우 중 하나입니다.

Source: …

Monopoly and Market Share

독점(또는 충분히 큰 시장 점유율)을 확보하는 것이 성공에 필수적이다.

한편, Zed는 Rust에서 같은 일을 수행했다. 그들은 자체 GPU‑렌더러 라이브러리(GPUI)를 설계했으며, 이는 크로스‑플랫폼이다. 높은 속도에도 불구하고 호스트 OS와의 통합이 부족해 개발자가 적절한 바인딩을 추가해야 한다. 개인적으로는 추가 속도보다 OS와 통합된 느린 렌더러를 선호한다.

TUIs

TUI는 빠르고 자동화하기 쉬우며(RIP Automator), 다양한 운영 체제에서 꽤 잘 동작한다. 심각한 X 포워딩 없이도 원격으로 실행할 수 있다.

네이티브 UI 툴킷이 실패할 때, 우리는 기본으로 돌아간다. Claude와 Codex는 명령줄에서 매우 성공적이었다: 사용자는 인터랙션에 집중하고 주변 운영 체제는 잊는다. 클라우드 머신에서 코드와 앱을 구동하거나 iPad에서 GPU‑가 장착된 머신에 원격 접속할 수도 있다.

TUIs는 모든 애플리케이션이 서로 다르게 보이는 포스트‑아포칼립스 세계에서 Apple과 Microsoft가 남긴 공백을 메우고 있다. 이는 예술(컴퓨터 게임 포함)을 할 때는 좋지만, 사용자가 자신의 작업을 수행하도록 방해하지 않는 것이 목표라면 그렇지 않다.

What’s Next

체크박스도 인터페이스의 한 부분이다. 데이터를 입력함으로써 시스템과 상호작용한다. 인터페이스는 생각을 덜 요구할수록 좋다: 스티어링 휠이든 온라인 폼이든, 사용법을 파악하는 데 시간이 들면 그건 나쁜 것이다.

많은 것과 상호작용하면서 일관된 경험을 제공하는 동질적인 인터페이스를 원한다. Command + C가 복사 단축키라는 것을 배우면 어디서든 동일하게 동작하기를 바란다. 특정 상황에서 Ctrl + Shift + C를 기억하거나, 다른 경우에 오른쪽 클릭 → 복사를 해야 한다면 짜증난다.

— John Loeber in Bring Back Idiomatic Design

우리는 기본으로 돌아가야 한다. 모든 개발자는 좋은 사용자 인터페이스(소프트웨어든 아니든)를 만드는 이론을 배워야 한다. Nielsen, Norman, Johnson 같은 사람들의 저작을 참고하라:

• Nielsen – Usability Engineering
• Norman – The Design of Everyday Things
• Johnson – Designing with the Mind in Mind

사용자 디자인을 소프트 스킬이라며 소프트웨어 공학 커리큘럼에서 무시하지 말자. 어떤 강좌에서든 UI가 말이 안 되면 프로젝트는 실패해야 한다. HCI 강좌에서는 완벽한 UI를 목표로 해야 한다. 이는 작업이 필요하지만, 그 작업은 주로 우리가 무엇을 필요로 하는지를 이해하는 데에 관한 것이며, 프로그래밍 자체는 이미 자동화되고 있다.

운영 체제와 툴킷 제작자는 이 투자를 주도해야 한다. 개발자가 사용하고 싶어 하는 접근성 높은 툴킷을 만들고, 진입 장벽을 낮추며, 해당 플랫폼이 가능한 오래 지속되도록 해야 한다. 나는 반드시 크로스‑플랫폼 지원을 주장하는 것은 아니지만, 하나의 해결책이라도 있으면 Electron과 TUI 의존성을 줄이는 데 도움이 될 것이다.