네이티브 GUI 도구 모음의 혼란과 일관성 붕괴 속에서 터미널 사용자 인터페이스가 다시 주목받는 이유를 살펴본다.
터미널 사용자 인터페이스(TUI)는 다시 유행하고 있다. DHH의 Omarchy는 세 가지 유형의 사용자 인터페이스로 이루어져 있다. 즉각적인 피드백과 덤으로 얻는 긱 포인트를 위한 TUI, 37signals(그의 회사)가 SAAS 웹 애플리케이션을 판매하기 때문에 웹앱, 그리고 배포판의 스타일과는 정말 잘 맞지 않는 피할 수 없는 gnome 스타일의 네이티브 애플리케이션이다.
비슷한 패턴은 약 10년 전 코드 에디터에서도 나타났다. 우리는 BBE dit, Textmate(DHH가 역시 홍보했던), Notedpad++와 Sublime 같은 네이티브 에디터에서 Atom, VSC ode와 그 모든 포크처럼 Electron으로 구동되는 앱으로 넘어왔다. 하드코어 사용자들은 vim이나 emacs로 이동했고, 즉각적인 피드백과 더 높은 사용성을 내가 본 것 중 가장 가파른 학습 곡선과 맞바꾸었다.
교훈은 분명하다. 네이티브 애플리케이션은 지고 있다. Windows는 GUI 라이브러리 표준 농담을 계속하고 있다. 한 API가 성공하지 못하면 또 다른 API를 만들어 내고, 그것마저도 존재하는 수많은 대안의 바다 속에서 실패하게 만든다.
MFC(1992)는 Win32를 C++로 감쌌다. Win32가 세련되지 않았다면, MFC는 다른 턱시도들로 만든 턱시도를 입은 Win32였다. 그 다음에는 OLE가 왔다. COM. ActiveX. 이들 중 어느 것도 진정한 GUI 프레임워크는 아니었다. 그것들은 컴포넌트 아키텍처였다. 하지만 이들은 Windows 개발의 구석구석까지 스며들었고, Kierkegaard가 Hemingway처럼 읽히게 만들 정도의 인지적 복잡성을 도입했다.
— Jeffrey Snover, Microsoft hasn’t had a coherent GUI strategy since Petzold에서
그 이후로 Microsoft는 Winforms, WPF, Silverlight, WinUIs, MAUI를 거쳤지만 성공하지 못했다. 많은 엔터프라이즈 및 개인용 데스크톱 애플리케이션은 여전히 Electron 앱에 의존하고 있으며, 운영체제 전체가 시각적으로 일관되게 통합되었던 마지막 기억은 Windows 98이나 2000에 머물러 있다.
몇 년마다 자기 운영체제와 UI API를 다시 만드는 데는 엄청난 작업이 필요하다는 것이 드러났다. 여기에 샌드박싱과 “너무 강력한” 기능을 폐기하려는 간헐적인 시도까지 겹치면서, 결과적으로 각각의 새 계층에는 빈틈이 생긴다. 이전 프레임워크에서는 가능했던 특정한 일을 할 수 없게 되는 것이다.
— Domenic Denicola, Windows Native App Development Is a Mess에서
Linux에서의 UI 비일관성은 설계에 의해 만들어졌다. 서로 다른 팀들이 서로 다른 결과를 원했고, 그렇게 할 자유가 있었다. GTK와 Qt는 두 개의 지배적인 프레임워크가 되었다. Qt가 그 점으로 가장 잘 알려져 있지만, 둘 다 크로스플랫폼 네이티브 개발을 지원하는 것을 목표로 했다(한때 나는 Windows에서 gedit를 성공적으로 컴파일한 적이 있는데, 그 과정에서 C 컴파일, make 파일, 환경 변수에 대해 많은 것을 배웠다). 하지만 실제로 널리 사용되는 곳은 Linux 세계뿐이다. 다행히도 서로 다른 툴킷으로 만들어진 애플리케이션들은 나란히 놓였을 때 그럭저럭 괜찮아 보일 수 있는데, 이는 Windows의 서로 다른 프레임워크들이 달성하지 못하는 일이다. Windows 제어판을 다시 만드는 데는 엔지니어링 시간이 몇 시간이나 들까?
배포판, 데스크톱 환경, 하드웨어의 백만 가지 조합을 테스트하는 어려움 때문에 대부분의 회사는 네이티브 Linux 애플리케이션을 굳이 만들지 않는다. 대신 Electron으로 대응하거나(봉쇄를 더욱 굳히면서), 오픈 API가 있을 때는 오픈소스 커뮤니티가 스스로 해결하게 놔둔다.
Apple은 한때 하나의 경전 같은 종교였다. Apple의 Human Interface Guidelines는 전 세계 모든 사용자 인터페이스 수업에서 인용되곤 했다. Xerox PARC와 Apple은 좋은 인간 인터페이스가 무엇을 뜻하는지 연구한 두 기관이었다. 몇십 년이 흐른 지금, Apple은 자신을 유명하게 만든 모든 가이드라인과 일관성을 깨기 위해 최선 최악을 다하고 있다.
이제 Apple은 Fitts의 법칙을 무시하고, 창 크기 조절을 거의 불가능하게 만들고 있으며 (고치려 시도한 뒤에도 그렇다), 모든 메뉴에 아이콘을 추가하고 있다. macOS는 더 이상 디자이너들이 평화롭게 작업할 수 있는 안전한 천국이 아니다.
Electron 앱의 사용자 경험이 형편없다는 것은 모두가 안다. 가장 흔한 불만은 메모리 사용량인데, 공정하게 말하자면 지난 10년 동안 줄어들긴 했다. 하지만 내 주된 불만은(나는 보통 64GB RAM MacBook Pro를 쓰기 때문에) 시각적 일관성의 부족과 키보드 중심 워크플로의 부재다. 내 독을 보면, 네이티브 앱이 8개(text mate와 macOS 시스템 유틸리티)이고 Electron 앱이 6개(Slack, Discord, Mattermost, VScode, Cursor, Plexampp)다. 그리고 이건 정말로 Electron 앱을 하나도 쓰지 않고 싶어 하는 사람의 구성이다.
Cursor를 예로 들어 보자(하지만 VSC ode도 마찬가지일 것이다). 에이전트 패널에서 다음 기능을 요청하고 있을 때, 오직 키보드만으로 옆 패널의 에이전트 목록으로 이동할 수 있는가? 그것을 보관 처리할 수 있는가? 이런 동작은 모든 macOS 애플리케이션에서 같아야 하며, 단축키가 있다 해도 메뉴에 표시되지 않는다. 그리고 지난 10년 동안 개발자들은 애플리케이션 안에서 가능한 같은 동작을 수행하는 메뉴를 추가하는 일을 잊어버려 왔다(대부분 애플리케이션이 샌드박스 안의 HTML이기 때문이다). 기록을 위해 말하자면, Slack은 다른 것들보다 이 점을 더 잘하지만 완벽하지는 않다.
Google은 Dart와 함께 Android의 모든 레거시 없이 새로운 기기를 위한 새 운영체제를 설계하려 했다. 새로운 UI 툴킷(Flutter UI)을 원했지만, 실제 제품이 출시되기 전에 프로젝트를 포기했다. 성공하려면 독점이나 충분히 큰 시장 점유율이 필요한 그런 상황 중 하나다.
한편 Zed는 Rust에서 같은 일을 했다. 그들은 자체 GPU 렌더러 라이브러리(GPUI)를 설계했으며, 이것은 크로스플랫폼이다. 높은 속도에도 불구하고, 그것만으로는 호스트 운영체제와의 통합이 부족해서 개발자들이 적절한 바인딩을 추가해야 한다. 개인적으로 나는 추가 속도보다 운영체제와 통합되는 느린 렌더러를 더 선호하겠다.
TUI는 빠르고, 자동화하기 쉬우며(RIP Automator), 서로 다른 운영체제에서도 꽤 잘 작동한다. 두통을 유발하는 X forwarding 없이도 원격으로 실행할 수 있다. 네이티브 UI 툴킷이 실패하면, 우리는 기본으로 돌아간다. Claude와 Codex는 명령줄에서 매우 성공적이었다. 상호작용에 집중하고, 자신을 둘러싼 운영체제는 잊게 된다. 클라우드 머신에서 코드와 앱을 다룰 수도 있고, iPad에서 GPU가 달린 자신의 머신에 원격 접속할 수도 있다. TUI는 모든 애플리케이션이 제각각 다르게 보이는 포스트아포칼립스 세계에서 Apple과 Microsoft가 남긴 공백을 메우고 있다. 예술(컴퓨터 게임을 포함한)을 하고 있다면 좋은 일일 수 있지만, 사용자가 자신의 일을 하도록 방해하지 않는 것이 목표라면 그렇지 않다.
체크박스도 인터페이스의 일부다. 당신은 데이터를 입력함으로써 시스템과 상호작용하기 위해 그것을 사용한다. 인터페이스는 생각을 덜 요구할수록 더 좋다. 인터페이스가 운전대이든 온라인 폼이든, 그것을 사용하는 법을 알아내는 데 조금이라도 시간을 써야 한다면 그건 좋지 않다. 많은 것들과 상호작용할수록, 일관된 경험을 주는 동질적인 인터페이스를 원하게 된다. Command + C가 복사 단축키라는 것을 배웠다면, 그것이 어디서나 동작하길 원한다. 어떤 경우에는 CTRL + Shift + C를 쓰고, 다른 경우에는 오른쪽 클릭 → 복사를 써야 한다는 것을 기억해야 한다면 짜증날 것이다.
— John Loeber, Bring Back Idiomatic Design에서
우리는 기본으로 돌아가야 한다. 모든 개발자는 좋은 사용자 인터페이스(소프트웨어든 아니든!)를 만드는 이론을 배워야 한다. 예를 들어 Nielsen, Norman, Johnson을 읽고, 사용자 디자인을 소프트웨어 공학 커리큘럼에서 중요하지 않은 소프트 스킬처럼 취급하는 일을 멈춰야 한다. 어떤 수업에서든 UI가 전혀 말이 되지 않는다면 그 프로젝트는 낙제해야 한다. 그리고 HCI 수업에서는 완벽한 UI를 목표로 해야 한다. 그것에는 노력이 들지만, 그 노력의 대부분은 우리가 무엇을 필요로 하는지 이해하는 데 있다. 프로그래밍은 이미 자동화되고 있다.
운영체제와 툴킷의 저자들이 이 투자를 이끌어야 한다. 그들은 개발자들이 사용하고 싶어 하는 접근 가능한 툴킷을 만드는 데 집중해야 하고, 진입 장벽을 낮추며, 그런 플랫폼이 가능한 한 오래 지속되도록 해야 한다. 나는 반드시 크로스플랫폼 지원을 주장하는 것은 아니지만, 그런 해법 하나쯤 있다면 Electron과 TUI 의존성을 줄이는 데 도움이 될 것이다.
